Example: MySQL master failover (this would apply to any hot/cold master configuration, like PostgreSQL, Pacemaker/Corosync configurations, etc.)
-
Create new instance with database_master role
-
Have it synchronize with the live database_master (determine liveness by looking at the instance that is in deploy state)
-
Change current database_master to undeploy (don't actually push the undeploy configuration though)
-
Push deploy configuration to webapp and database_slave instances
At this point, the application and slaves should notice that there is no database_master in the deploy stage. They have the logic in Puppet to put their applications in a read-only or buffered mode.
-
Once synchronization of the new database_master is finished, push configuration to the old database_master to undeploy.
-
Push configuration to the new database_master to deploy.
-
Push configuration to all database_slave and webapp instances to deploy.

I'm probably missing something here. Is this possible with the current model and process? If not, what do we need to do to be able to support it?
- You would have to have a special lifecycle stage for the new master so that it will sync with the current master. Otherwise, if you put it in
deploy, dependent instances may think that the new instance is the master to use. This will break the application because it assumed the master was ready for use. In my mind, there would be a pre_deploy stage. The scenario for a master would look for existing masters in deploy and setup like a slave until they are put into deploy.
- How do we know that synchronization of the new master has completed? Polling? Is there are post-sync hook for MySQL/PostgreSQL?
- It could be possible to combine block device migration with this. We take an existing slave, grab its block device, and then we just have to wait for the new data to be synchronized. This would be a lot harder to automate though.
Example: MySQL master failover (this would apply to any hot/cold master configuration, like PostgreSQL, Pacemaker/Corosync configurations, etc.)
Create new instance with
database_masterroleHave it synchronize with the live
database_master(determine liveness by looking at the instance that is indeploystate)Change current
database_mastertoundeploy(don't actually push theundeployconfiguration though)Push
deployconfiguration towebappanddatabase_slaveinstancesAt this point, the application and slaves should notice that there is no
database_masterin thedeploystage. They have the logic in Puppet to put their applications in a read-only or buffered mode.Once synchronization of the new
database_masteris finished, push configuration to the olddatabase_mastertoundeploy.Push configuration to the new
database_mastertodeploy.Push configuration to all
database_slaveandwebappinstances todeploy.I'm probably missing something here. Is this possible with the current model and process? If not, what do we need to do to be able to support it?
deploy, dependent instances may think that the new instance is the master to use. This will break the application because it assumed the master was ready for use. In my mind, there would be apre_deploystage. The scenario for a master would look for existing masters indeployand setup like a slave until they are put intodeploy.