The database is the core of all application systems, so ensuring the stable, efficient and safe operation of the database is the top priority of the daily work of all enterprises. Once the database system fails to provide services, it may cause the entire system to be unable to continue to work. Therefore, a successful database architecture also needs to be fully considered in terms of high availability design. The following is an introduction to how to build a highly available MySQL database system.
Students who have done DBA or operation and maintenance should know that the existence of a single point of any device or service will bring huge risks, because once the physical machine goes down or the service module crashes, if a replacement cannot be found in a short period of time equipment, is bound to affect the entire application system. Therefore, how to ensure that there is no single point is our important work. The use of MySQL high availability solution can solve this problem well. Generally, there are the following types:
1. Use MySQL's own Replication to achieve high availability
The Replication that comes with MySQL is what we often call master-slave replication (AB replication). By making a slave machine for the master server, it can quickly switch the business to the slave machine when the master server is down to ensure the normal use of the application. Using AB replication for high availability solutions is also divided into several different architectures:
1. Conventional MASTER---SLAVE solution
Ordinary MASTER---SLAVE is the most commonly used architecture scheme for most small and medium-sized companies at home and abroad. The main advantages are simplicity, less equipment (lower cost) and easy maintenance. This kind of architecture can solve the single point problem, and it can also solve the performance problem of the system to a large extent. One or more SLAVEs (master-slave cascading replication) can be brought behind a MASTER, but this architecture requires that a MASTER must be able to meet all write requests of the system, otherwise it needs to be split horizontally to share the pressure of reading.
Figure 1
Figure II
Figures 1 and 2 show the process of solving single-point problems and using read-write separation to improve performance.
2. DUAL MASTER combined with cascade replication
Dual master and multiple slaves is a more reasonable solution derived from the above solution. The advantage of this scheme is that when either of the two master servers fails, the entire architecture does not need to be adjusted significantly.
Figure 3
Figure 4
Figure 5
The process is shown above. But the situation in Figure 5 is special, that is, what if MASTER-B goes down? The first thing to be sure is that all our Write requests will not be affected, and all Read requests can be accessed normally; but all slave replication will be interrupted, and the data on the slave will begin to lag. At this time, all we need to do is to perform the CHANGE MASTER TO operation on all Slaves and change them to copy from Master A. Since it is impossible for all slave replication to advance the original data source, the exact replication starting point can be found by comparing the timestamp information in the Relay Log on the slave with the timestamp information in Master A, so as to avoid causing data of loss.
2. Use MYSQL CLUSTER to achieve overall high availability
For now, the solution of using MYSQL CLUSTER to achieve overall high availability (ie NDB CLUSTER) is not very popular in domestic companies. The NDB CLUSTER node is actually a multi-node MySQL server, but it does not contain data, so any machine can use it as long as it is installed. When a SQL node in the cluster crashes, the data will not be lost because the node does not store specific data. Figure 6:
Figure 6
3. High availability through MySQL derivatives
Among the current high-availability derivatives of MySQL, the most well-known and popular ones are GALERA CLUSTER and PERCONA XTRDB CLUSTER (PXC). The relevant content is not described in this article for the time being, and interested students can refer to the relevant information for further understanding. The implementation of these two clusters is similar, as shown in Figure 7 and Figure 8:
Figure 7
Figure 8
4. Comparison of advantages and disadvantages of various high-availability solutions
Readers may have found in the introduction of various high-availability design schemes above that no matter which scheme it is, it has its own unique advantages, but there are also more or less limitations. This section will make a pros and cons analysis of the above major schemes for your reference in the selection process.
1、MySQL Replication
Advantages: Simple to deploy, easy to implement, and not complicated to maintain. It is a function that MySQL naturally supports. In addition, it is convenient to switch between the main and standby machines, and the main-standby switch can be automatically completed through third-party software or scripts written by yourself.
Disadvantage: If the master host hardware fails and cannot be recovered, it may cause some data not transmitted to the slave side to be lost.
2、MySQL Cluster （NDB）
Advantages: very high availability, very good performance. Each piece of data has at least one copy on different hosts, and redundant data copies are synchronized in real time.
Disadvantages: maintenance is more complicated, the product is relatively new, there are some bugs, and it is not necessarily applicable to the core online system.
3, GALERA CLUSTER sum PERCONA XTRDB CLUSTER (PXC)
Advantages: Reliability is very high, all nodes can read and write each piece of data at the same time, at least one copy exists on different hosts, and redundant data copies are synchronized in real time.
Disadvantage: As the cluster grows, the performance gets worse and worse.
4. The DRBD disk network mirroring scheme that must be mentioned
In terms of architecture, it is somewhat similar to Replication, except that it is a process of data synchronization through third-party software, which is more reliable than Replication, but also sacrifices performance.
Advantages: The software is powerful, data is mirrored across physical hosts at the underlying block device level, and different levels of synchronization can be configured according to performance and reliability requirements. IO operations are kept in order, which can meet the strict requirements of the database for data consistency.
Disadvantages: The non-distributed file system environment cannot support the simultaneous visibility of mirrored data, that is, the performance and reliability are contradictory, and it cannot be applied to the environment that has strict requirements for both. Maintenance cost is higher than MySQL Replication.
After talking about the advantages and disadvantages of various common architectures, what remains is how to choose a suitable architecture for use in a real production environment. In this regard, everyone has their own ideas and experiences, and it is a matter of opinion as to which scheme is the best. In daily work, the improvement of the structure is not achieved overnight, but a process of continuous evolution, optimization and improvement.
Getui has also experienced the process from single point to master-slave to master-slave + high availability in terms of database, and has also experienced from a single MySQL+redis to MySQL+redis+es, and finally to the present MySQL+redis+es+ The evolution of codis and so on. Each evolution is to solve real problems and pain points in production environments. From MySQL alone, no one architecture can solve all problems (pain points), and a suitable architecture needs to be selected according to the actual situation. The solution implemented by MySQL cluster is very flexible and changeable. It is also a challenge for MySQL workers to choose a suitable architecture, and it is also the driving force for us to continuously study and learn MySQL.