Phabricator conceptually supports putting application databases on different hosts: for example, separating applications with high load (maniphest, worker) or unusual access/usage/workload patterns (file) onto different machines to improve scalability or make administration easier.
In particular, we have planned for this since ancient times and already establish separate connections to each database and do not perform JOIN operations between databases, so the majority of database behaviors should already handle this change seamlessly. The cluster.databases configuration can also support selecting which databases are available on hosts.
What will need changes are administrative tools. In particular:
- .php patches in autopatches/ will just work, but .sql autopatches do not currently have the metadata they need to identify which database to connect to. In most-dumb mode, we need to start adding comment headers to them.
- quickstart.sql is a complete mess.
- The behavior of bin/storage dump is somewhat unclear/ambiguous (probably: dump a specific master).
- Perhaps bin/storage destroy should also destroy a specific master? This is easier to make go either way.
- bin/storage adjust and "Database Status" need to be database/host aware.
- Database setup checks likely need to be database/host aware.
- This is a good opportunity to remove mysql.implementation and mysql.configuration-provider. The former we can infer and the latter will be obsolete.
A possible solution to the quickstart and migration problems is that we just maintain every schema on every database, and start tracking patches per-master. At first glance this is a little goofy/weird, but would possibly make patch management much easier, particularly when you decided to move databases.