High Availability

ScaleBase delivers MySQL high availability – automating fail over in the event of database failure.

MySQL replication is a widely used mechanism for data replication between two MySQL databases.  However, replication alone is not sufficient to ensure database high availability. The failover process itself is the key.  It does not account for a way to recognize database crashes.  When this occurs, performing automated failover to the slave database is very difficult.  It requires coding your applications correctly, so that when specific exceptions occur, the connection can be closed and then reopened. This is very difficult to implement at the application level.  Scalebase automates this failover process, ensuring high availability, guaranteeing 100% database up-time.

Another important issue regarding database high availability is that failover process can often be a destructive action. Database failover typically implies the loss of data, which makes the master (former) database unusable. After a failover, when the slave database is updated, those updates are often not populated back to the primary database, thereby making the database unusable. In this case, such updates must be manually recreated.  Scalebase automates this process also, ensuring perfect data continunity.

Using ScaleBase:

• MySQL replication transports the data from a master database to one or more slave databases.
• The slave databases’ replication laga are constantly examined. A broken replication or a large replication lag in a slave databases will disable failover process, and will create an alert notification.
• If the master database crashes, ScaleBase performs a transparent failover. The application will not be aware of any changes: no broken connections, no connection re-open, and no broken statements or prepared statements – providing MySQL high availability.
• The failover determination process takes less then 5 seconds. During this processes, the state of the master database is checked several times for vital signs. This is done several ways, including network, database connection and more – thus eliminating “false alarms” and conducting a failover only where there is indeed a true failure.
• If the master database was only temporarily disconnected because of a short network glitch, no failover occurs and it is automatically reconnected. The application is never even aware of the short outage.
• After failover, if the master database becomes active again it will not get any traffic, as it is now stale.