Add rake task for copying 'main' database to 'ci' database
Merged
requested to merge 368729-create-a-tool-to-migrate-existing-self-managed-customers-to-decomposed into master
We are working towards making decomposed database setup a Beta feature. As part of that, it should be more easy for self-managed customers to migrate from one-database setup to decomposed two-database setup.
This MR adds a rake task that will take care of dumping the gitlabhq_production
database and importing it in gitlabhq_production_ci
database. This rake task will be used by all installation methods that we support.
This rake tasks will be called by installation-specific scripts. A first follow-up MR will be to add the script to Omnibus package. We can then iterate on this to have scripts for other installation methods.
There are some checks before we do anything:
main
databasegitlabhq_production_ci
is accessible and emptyThe dump is sharing some code with the Backup tasks. This makes it possible to override default database settings using the same environment variables as we support for Backups. Because using GITLAB_BACKUP_PGHOST
variables names looked weird, I added support for using GITLAB_OVERRIDE_PGHOST
The database dump is using pg_dump -Fd
, this creates dump files for each table. This allows us to dump and restore using multiple processes.
Related to #368729 (closed)
Using GDK:
database.yml
: comment out ci
section (so Rails is using a single database)gdk psql -c "DROP DATABASE gitlabhq_development_ci";gdk psql -c "CREATE DATABASE gitlabhq_development_ci"
bundle exec rake gitlab:db:decomposition:migrate
gdk psql -d gitlabhq_development -c "SELECT COUNT(*) FROM projects";gdk psql -d gitlabhq_development_ci -c "SELECT COUNT(*) FROM projects";
should matchThis checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.