A viable solution for MySQL cluster

First, MySQL Cluster
Advantage: Very high availability, very good performance. Each piece of data can have at least one copy stored on different hosts, and redundant copies of the data are synchronized in real time. But its maintenance is very complex, there are some bugs, is not suitable for comparison of the core of the online system, so I do not recommend this.

Second, the DRBD Disk network mirroring scheme
Advantage: Software is powerful, data can be mirrored across physical hosts at the underlying fast device level, and different levels of synchronization can be configured based on performance and reliability requirements. IO operations are kept in order to meet the database's demanding data consistency. However, the non-Distributed file system environment cannot support the mirrored data, and the performance and reliability are contradictory, which is not suitable for the environment with the more demanding performance and reliability requirements, and the maintenance cost is higher than MySQL Replication. In addition, DRBD is officially recommended as one of the highly available MySQL scenarios, so you can consider whether or not to deploy according to the actual environment.

Third, MySQL Replication
In practical scenarios, MySQL replication is one of the most widely used design tools to improve system scalability. Many MySQL users through the replication function to enhance the expansion of the system, through the simple increase in inexpensive hardware equipment multiplied even to improve the performance of the original system, is the majority of MySQL low-end users like one of the features, It is also the most important reason for many MySQL users to choose MySQL.

There are several common MySQL replication architectures, which are explained in a nutshell

MySQL Replication Architecture One:

The general replication schema--master-slaves, which is a schema pattern replicated from one Master to one or more salve, is mainly used for low-pressure application database-side expansion solutions, read-write separation, and master is primarily responsible for writing stress.

MySQL Replication Architecture II:

Cascade replication architecture, that is, master-slaves-slaves, this is to prevent slaves reading pressure is too large, and the configuration of a layer two level slaves, it is easy to solve the master side because the secondary slave too much to become the risk of bottle strength.
MySQL Replication Architecture III:

Dual Master and Cascade replication in conjunction with the architecture, i.e., master-master-slaves, the greatest benefit is that the primary master's write operations are not affected by the replication of the slave cluster, and a single point of failure of the Master master is ensured.
The above is the more common MySQL replication architecture scheme, we can according to their own company's specific environment to design, Mysql load balancer can consider using LVS or haproxy to do, ha software high availability I recommend heartbeat.

MySQL replication is insufficient:

If the master host hardware fails to recover, it can result in some data loss that is not delivered to the slave end. So everyone should be based on their current network planning, choose their own reasonable MySQL schema, with their MySQL DBA and programmer multi-ditch, multi-backup (backup I will at least do local and offsite dual backup), multi-test, data is the biggest thing, not a bit of error, remember to remember.

A viable solution for MySQL cluster