alphagov / manuals-publisher

Publishes manuals on GOV.UK
https://docs.publishing.service.gov.uk/apps/manuals-publisher.html
MIT License
7 stars 16 forks source link

Use separate Mongo database for this app (stop sharing with other apps) #893

Open floehopper opened 7 years ago

floehopper commented 7 years ago

Conversation from Slack govuk-developers channel:

@floehopper:

It looks as if contentapi, manuals_publisher, publisher, specialist_publisher and travel_advice_publisher apps all share the same mongo database.

Have I understood this correctly? And if so, is there any reason not to use separate databases for each app? Or do some of the apps "communicate" via the database?

@danielroseman:

content-api and publisher (and panopticon, now dead) did indeed communicate via the database. But content-api is being killed.

And travel-advice-publisher is being split out into its own db any day now

specialist-publisher only stores User information in its database, although I did think it had its own. Everything else is stored directly in the publishing-api.

@floehopper:

ok - that’s useful to know - it sounds as if (at least in the short term) it might make sense to use a separate database for manuals_publisher too

@danielroseman:

yes, talk to @thomasleese about how he's splitting out TAP.

In general it seems like a bad idea to share a database with others applications which presumably have write access.

See also #839.

thomasleese commented 7 years ago

The process I'm going to follow for Travel Advice Publisher (TAP) is as follows.

  1. Take TAP down (book a slot of downtime and alert users).
  2. Take a dump of the database: mongodump -d govuk_content_production --out dump
  3. Restore the dump to a new database: mongorestore --db travel_advice_publisher_production dump/govuk_content_production
  4. Deploy a puppet change to change the database URL.
  5. Take TAP back up and alert the users that it is available to use again.
  6. Update the development configuration to match the production database name one day later (to ensure replication from integration is possible).
  7. Delete unused collections from the new database that were copied from the old one.
floehopper commented 7 years ago

@thomasleese: Thanks!