Multiple MySQLs Make a Marvelous Multisite Machine

Larry Garfield
10 Feb 2017

(Because alliterations are always appropriate.)

As we hinted at previously when rolling out Apache Solr 6.3, we’re rolling out new functionality for many of our containers to support multiple databases on a single service. We’re happy to report that next up is the big one: MySQL now supports multiple databases, and restricted users.

If all you need is a single database, as is often the case, nothing changes. If you want multiple databases or want to allow only read-only access in some cases then this is for you. When declaring a MySQL/MariaDB service in your  services.yaml  file, you can now specify additional configuration. That includes multiple databases, like so:

    type: mysql:10.0
    disk: 2048
            - main
            - legacy

That creates two separate databases,  main  and  legacy . Of course, to access them you still need an endpoint, which is a set of credentials. You can define those, too, and give them access to one or multiple databases and give them read-only, read-and-write, or admin (do everything) permissions. Then each endpoint can be referenced separately in your application’s  to give some applications different access to different databases. See our newly-updated documentation for step by step instructions.

What can I do with it?

As suggested by the example above, one main use is to host a legacy database for content migration. Or perhaps one that’s being staged from an external legacy system. In those cases it’s common to want your application to have only read-access or read-write-no-schema access to it. You can now do that. Your application will have two different MySQL connections with the appropriate permissions and do whatever it’s going to do.

Another use case is multiple applications. fully supports multi-app projects, where a single project is composed of multiple microservices, possibly even written in different languages. Now each of those mini-applications can have its own database without the added overhead and cost of another service instance. Plus, because they can use different endpoints the applications can’t read from each other’s databases… unless you want them to.

It’s also useful for Drupal’s multi-site functionality. Drupal has the ability to run multple instances off of a single code base, each with its own database. That’s generally only useful in cases where the sites are virtually identical in code and configuration, just differ in content (and maybe theme). Now, each instance can have its own database without spinning up a dozen extra service instances, and they can all be updated and backed up together. (If the sites are distinct sites, though, it’s still going to be far less work to just make them separate projects so that they can be developed and maintained separately.)

Of course, that’s just the use cases we envision. What other uses do you have? We’d love to hear about what cool stuff you’re doing with