====== Database Rollback ======
===== Background =======
When a Master database fails or inappropriate data is populated into the Master during production deployments, a replicated slave can be "promoted" as Master to take over it.
===== Steps to do =======
  * Take full database backup
  * Stop Slave replicating from the Master
  * Ensure Slave is detached from the Master by verifying the respective (Binary & Relay) logs.
  * Deploy the release & backfill tasks. Changes should get updated only in Master.
  * After successful deployment, data updates and full deployment testing/verification, reconnect the existing Slave to Master.
  * In case of unsuccessful deployment, as a process of rollback, detach the Master
  * Promote the original Slave as a new Master.
  * Connect the old Master as a new Slave to the new Master. So that the new Slave starts replicating from the Master. When both new Master and new Slave are in Sync, revert the Master and Slave (i.e. the new Slave is now the Master and the new Master is now the Slave, thus effectively setting the Master and Salve back to their original roles, at the start of deployment
  * No change in application end.

===== Application Database Configuration =======
<code>
production:
  adapter: mysql
  encoding: utf8
  database: cbprod
  username: cbpuser
  port: 3306
  password: ***
  host: 10.166.152.12
  pool: 23

production_slave_database:
  adapter: mysql
  encoding: utf8
  database: cbprod
  username: cbpuser
  port: 3306
  password: ***
  host: 10.166.152.13
  pool: 23
 </code>