Percona Live was held at the beginning of April this year and the Acquia team was there. This was a really great conference and I want to start by encouraging any DBA/database developer who uses MySQL in a production environment to go to the Percona Live conference. It's a great place to hear about new functionality, new products and how other companies are using MySQL at scale. Large companies like Google, Facebook and Twitter as well as hot startups like Box all send representatives to share their knowledge.
At Acquia we use the Percona version of MySQL as our standard data store for all hosted Drupal sites as well as for lots of internal projects. Since all our production servers use MySQL replication to provide high availability and our databases are continuously growing we're always looking to get better performance out of replication. The new replication enhancements in MySQL 5.6 and 5.7 are promising better performance but need some work in the application and tools to deliver on that performance. At this year's conference I decided to take a new look at the current state of external high availability and failover solutions to see what enhancements they could deliver and how much effort would be involved in implementing them.
I want to summarize and compare four of the more interesting products that are currently available. I will also point out if there are Drupal specific things to keep in mind when choosing between them. All these tools are open source and free.
Back in August 2013, I wrote the original version of this article on my Drupal Gardens blog.
Two weeks ago I had a great opportunity to spend a few days working with Moshe Weitzman (moshe weitzman), Justin Randell (beejeebus), Alex Bronstein (effulgentsia), and Stéphane Corlosquet (scor) to look at the challenges and best practices for using the new Drupal 8 configuration system (a.k.a. CMI) to move changes between a local development environment and one or more server environments. We developed ideas, considered new modules for Drupal 8, and tried to figure out if there were any changes to Drupal 8 core that would be needed to make the system better for developers.
One outcome of this was two new modules Configuration log and Configuration Read-only mode. These were written to help demonstrate the capabilities of the new configuration system and enabled us to implement key elements of possible new configuration staging and management workflows. An additional outcome was a number of enhancements by Moshe to the latest version of Drush to facilitate the import and export of configuration.
The screencast video below walks through the process of moving configuration from a local development version of a site, up to a development environment on a server and then to a "live" environment using Acquia Cloud Free. The "live" environment was detected in settings.php and that logic triggered the Configuration Read-only mode module to prevent any configuration changes in the administrative forms. We also used a Cloud Hook to automatically import new configuration when a new git tag was deployed to the "live" environment.
Whether you are just moving to Drupal or upgrading to a new version of Drupal, if you are starting with an existing website, you are facing the same problem: Your migration timeline.
Drupal.org provides a number of pre-packaged distributions (e.g., Drupal Commons, DKAN, etc.) that allow users get a fully-featured Drupal installation up and running in no time, but maintaining an installed distribution can be tricky. You may need to juggle distribution updates with contrib module updates, core updates, and your own customizations. If you aren't careful, it can be come a maintenance nightmare!