• Overview
  • Schooner MySQL with Active Cluster
    • High Availability with High Performance
    • Optimizing InnoDB for Top Performance
    • Solving MySQL Replication Problems
    • Reducing Sharding and Consolidating Slaves
    • Consolidating with Integrated Multi-Instance
    • Simplified Cluster Administration
  • Schooner Membrain
  • Supported Platforms
  • Pricing and Licensing
  • The Schooner Advantage

Solving the Problems of MySQL Replication

Users who need high availability from MySQL with InnoDB typically deploy it in a master-slave configuration. This is done for sheer reliability — since hardware can fail — and to improve performance by distributing the total read workload across servers. It's common to use multiple slaves with one master. Adding MySQL slaves and managing the cluster is a cumbersome manual process. The traditional distributions of MySQL with InnoDB have the potential for slaves to lag minutes or even hours behind the master. Having a slave take over to become the master after a master node fails is also a time-consuming manual process that can lead to long service outages. In-flight data at the time of failure can be lost.

Schooner MySQL with Active Cluster (or Schooner MySQL) solves these problems by providing high-speed fully synchronous replication among MySQL nodes, enabling transparent recovery in seconds from the failure of a master. As transactions execute, Schooner MySQL dynamically communicates the associated database updates to all nodes in the cluster, using low-overhead networking calls. Schooner MySQL keeps all nodes at the same commit level for every transaction at all times. Schooner's solution is superior to the legacy MySQL approach, which uses a transaction log that replays transactions sequentially from a single thread on slave nodes after they have been completed on the master. These slave nodes typically lag behind the master by at least minutes, and the master and slaves are mutually inconsistent at any point in time. Slave lag can cause read transactions to operate on stale data.

The slave lag in traditional MySQL also greatly complicates the recovery process after a master or slave fails. Recovery to an operational state usually means costly administrator intervention, potential site outage, and lost transactions. With Schooner's synchronous replication, all nodes are at exactly the same consistency levels at all times. This enables failure recovery of both master and slave nodes to be fully automatic with no lost transactions. When a failed machine is brought back on-line it is automatically recovered and brought to the current state concurrent with ongoing execution of new transactions. This also means that recovery from a slave failure is transparent and happens in seconds, because none of the slaves need to catch up and become current.

The result with Schooner: no downtime, no lost transactions, full database consistency, and no headaches for your DBAs.

Scale smart, with Schooner.