Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Right now, we only use the 'last' database server as the 'master_db' in the platform settings. With this URL, we create and revoke grants, databases, load dumps, etc. in effect, right now, we have absolutely no way of handling multiple database servers.
The frontend does have handling for multiple database servers: when you create a site, you get prompted to choose the database server if you have many configured, so that is not the issue. The issue is that this setting doesn't actually *do* anything in the backend.
Choosing the server in the frontend should generate an appropriate settings.php and create the site on the right server. This means we will need credentials for every server in the pool. Those would be stored in the platform configuration until #586000: make a "server verify" task lands. The configuration should be indexed by the FQDN of the database server so it can be easily accessible without needing the frontend. Right now this means that we'll need to trigger a site-wide platform verification when editing the database server, and inject in there all the proper credentials. Furthermore, we'll need a way to tell to which database we will connect to in provision_db_connect()...
This is basically blocking #485646: Site migration fails on multiple SQL servers.
Comments
Comment #1
anarcat commentedA workaround we could also use at this point would be to pass a proper master_db to every task all the time. it's a crude hack but could work for the time being.
Comment #2
bwood commentedsubscribing
Comment #3
anarcat commentedHere's how I migrate sites between database servers manually:
# mysql -h mysql3.koumbit.net -e "GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES ON site_913.* TO site_913@aegir.koumbit.net identified by 'XXXXX';"
# mysqldump -u site_913 -pXXXXX -l site_913 -h mysql2.koumbit.net | pv | mysql -u site_913 -pXXXXX -h mysql3.koumbit.net site_913
# sed -i -e 's/mysql2.koumbit.net/mysql3.koumbit.net/' sites/site_913/drushrc.php sites/site_913/settings.php
So that's basically what aegir will need to do. The only trouble is the time between the dump and the sed during which data can be changed on the site. The site should therefore be put offline during that migration.
Also note the use of "pv" is just a cool tool that shows a progress bar and is not required for the migration.
Comment #4
bwood commentedThanks. From the initial description I take it that Aegir can not yet install a site onto webserver C and dbserver D. Would it work to install the site and then manually correct settings.php to point to the dbserver? If I do that, I think future uses of 'provision verify' may "correct" my edited settings.php to reflect the wrong webserver. (I'll try this.) If that is the case I wonder whether there is a workaround to prevent verify from overwriting my edit...
Comment #5
anarcat commentedI don't think verify will overwrite your configuration, if the site is properly configured in the frontend, and as long as the drushrc.php has the right settings, settings.php will be recreated properly.
Comment #6
adrian commentedThis is a bit better now.
#723288: Introduce the concept of 'shortnames' for all major entities. will manage the storage issue for server verify.
Comment #7
adrian commentedthis is now fixed.
Each server has the relevant database setting in it's own config file (populated by the verify task).
When creating a site you select which server to use for the database, and it loads the configs as needed.
on a platform you can have sites using different db servers, and they work entirely atomically without
messing with each other in any way
they also keep their settings when migrated between platforms.