A typical MySQL deployment involves one Master handling writes and multiple Slaves to scale the reads.

The term “slave” has been used in MySQL because the Slave servers have to perform every task in copying from the Master binlog, then updating their relay logs and finally committing to the Slave databases. The Master plays no role in replication here other than storing the replication events in the binlog.

This kind of Master - Slave set up imposes several limitations:
- Slave lag
- Stale or old data
- Data loss
- Manual failover which is error-prone and time consuming

In SchoonerSQL™, there is no concept of “slaves” inside a synchronous cluster. It’s far more accurate to use the term “Read Masters” because of our unique synchronous approach and replication architecture. SchoonerSQL uses a push mechanism of replication events coupled with faster processing through multiple parallel threads. This ensures that the Master and each Read Master’s data in a synchronous cluster is always consistent. So you can write data to a Master and at the same time query it from any Read Masters and get fully consistent data.

SchoonerSQL Synchronous Replication Architecture

Schooner’s approach provides several benefits:

• Zero data loss
• Guaranteed data consistency across all nodes
• No stale data
• Zero lag
• Faster response time than traditional MySQL
• Immediate automated failover to any of the nodes in the cluster, since the data is always consistent, for full service continuity.

This type of replication is very useful for Websites or Enterprises looking for a scalable MySQL - InnoDB with no lost or stale data and no slave lag.