Advanced Mysql road (nine) --- Mysql master-slave replication

introduction:

1. What is the 28 principles?

In the build environment, we operate 80 per cent of the database query, only 20% are additions and deletions

2. Why do we need now most companies need to Mysql master-slave replication architecture?

In the rapid development of the Internet today, a single site architecture has to protect the stability of the site, the individual is unable to support the Mysql database access the same amount of time tens of millions, according to the 28 principles, we were Mysql master-slave replication architecture optimization (only additions and deletions to the main library, a query from the library) can be solved to a certain extent, lead to problems down the database load conditions under high concurrency.

Mysql database common architecture

Note: Each method has its own advantages and disadvantages, so when making architecture, we must be based on actual business analysis, is the best fit

1. The Lord copy: From the main authorized to connect to each other, read each other binlog log and update process to the local database; as long as the other data changes, and that they follow the change;

2. Master-slave replication: connecting the main library licensed from the library remotely, read binlog log and update process to the local database; after the main library to write data from the library will automatically sync up (from the library along with the main library variants);

3. Annulus

4. cascade

Mysql master-slave replication principle

master server changes the recording data of binary binlog log, when the master data is changed, it is changed to write the binary log;

slave server on the master binary logs to detect whether changes in a certain time interval, if the change occurs, a start I / OThread request master binary event,

At the same time the master node for each I / O thread starts a thread dump, send a binary event, and stored into, read from the binary log log from the relay node local log relay node from the SQL thread starts, in local playback,

Such that their data remains consistent and the master node, the last I / OThread SQLThread and will go to sleep once awakened is waiting.

In other words:

• Library generated from two threads, one I / O thread, a thread SQL;
• I / O requests binlog thread to the main library, and the resulting written binlog local relay-log (relay log) file;
• Primary library will generate a log dump thread, from a library used to I / O threads pass the binlog;
• SQL thread reads the relay log files in the log and resolve to execute sql statement one by one;

Note that:

1. vmaster operating statements recorded in the binlog log and then granted permission slave remote connections (master must open binlog binary logging; usually for data security considerations, but also open the slave binlog function).
2. slave open two threads: IO thread and the SQL thread. Where: IO thread is responsible for reading the contents of master binlog to the relay log relay log in; SQL thread is responsible for reading out the binlog contents from the relay log log, and updates to the slave database, so we can guarantee slave data and master data retention agreement.
3. Mysql Mysql replication requires at least two services, of course, Mysql services can be distributed on different servers, you can also start multiple services on a single server.
4. Mysql Mysql replicate best to ensure that the same version on the master and slave servers (if you can not meet the same version, then make sure the version master slave master node is lower than the version from the node)
5. Two between master and slave nodes to be synchronized time
   

Mysql replication process

The first part is the master binary log record. Prior to the completion of each transaction update data, master record these changes in the binary log. MySQL transaction serial writes binary log, even if the transaction statements are executed cross. After the completion of the event written to the binary log, master notification storage engine submission services.

The second part is the slave to the master copy to its own binary log relay log. First, slave to start a worker thread --I / O thread. I / O thread opens a connection on a common master, and start binlog dump process. Binlog dump process reads events from the master's binary log, if you have to keep up with master, it will sleep and wait for the master to generate a new event. I / O thread will relay these events are written to the log. SQL slave thread (SQL slave thread) processing the final step of the process. SQL thread reads events from the relay log and replay of events in which the update data slave to make it consistent with the data in the master. As long as the thread and I / O threads consistent relay log usually located in the OS cache, so the overhead is small relay logs.

In addition, the master also has a worker thread: MySQL and other connections, like, slave master open a connection will make the master start a thread. Replication process has a very important limitation - replicated on the slave is serialized, that is parallel update on the master can not operate in parallel on the slave.

Precautions:

1）主从复制是异步的逻辑的SQL语句级的复制
2）复制时，主库有一个I/O线程，从库有两个线程，I/O和SQL线程
3）实现主从复制的必要条件是主库要开启记录binlog功能
4）作为复制的所有Mysql节点的server-id都不能相同
5）binlog文件只记录对数据库有更改的SQL语句（来自主库内容的变更），不记录任何查询（select，show）语句

Mysql master-slave replication workflow details

1) MySQL supports one-way, asynchronous replication, the replication server acts as a primary server, while one or more other servers act as from the server. MySQL replication master server-based tracking in the binary log of all changes to the database (update, delete, etc.). Therefore, to copy, you must enable binary logging on the master server. Each received from the server has been recorded from the primary server to update its binary logs stored on the primary server.

When a connection from the master server, it informs the primary server to the location of the last successful update read from the log server. Since then the server received from any of the update occurs, and performs the same updates on the local machine. Then blocked the main server and waits for notification of new updates.
Server to perform backups without interfering with the primary server from a master server in the backup process can continue to process updates.

2) MySQL using three thread to execute the copy function, wherein the two threads (Thread IO threads and the Sql) from the server, another thread (Thread IO) in the main server.
When issuing START SLAVE, creating an I / O from the server thread to connect it to the master server and send the statement recorded thereon the binary log. Primary server creates a thread to send the binary log contents to the slave. I.e., the thread can be threaded on the server based Binlog Dump in SHOW PROCESSLIST output.

/ O thread reads the contents of the main server thread Binlog Dump I transmitted from the server and copies the data from the server to the local data directory file, i.e., relay logs. The third thread is the SQL thread, created by the server to read the relay logs and executes the update log contains. From the server, the update statement is read and divided into two independent tasks.

When launched from the server, its I / O thread can quickly obtain all the binary log contents from the master server, even if the SQL thread lags far behind to perform the update.

From the synchronized main data to complete the process:

1. Sart slave execute command from the master copy switch is turned on, to start from the master copy on the server Slave.

2. At this point, IO thread Slave servers will pass on the master has been authorized copy user permissions requests a connection master server and requests (log file name and location is the implementation of change master replication service from the specified location to perform binlog log file in the configuration of the main after the command specified) begin sending binlog log content

3. After Master server receives a request from the IO threads Slave servers responsible for copying the IO thread on which the information is read in batches IO threads Slave server request log file specified binlog binlog log information after the designated position, then return to the Slave IO thread end. The information returned in addition to the binlog log contents, as well as in the Master server record IO thread. In addition to the information returned in a specified binlog location update.

4. When the Slave IO thread to the log server acquires the content server Master IO thread sends the log file and the location point, the contents will be sequentially written to the log binlog Slave terminal itself Relay Log (i.e. relay log) file (Mysql-relay Master server can tell when -bin.xxx) the very end, and a new binlog filename and location records to master-info file so that next time read the end of the new master binlog log file and specify the new location of the log binlog start reading take the new binlog log content

5. Slave server SQL thread real-time detection of a local Relay Log in IO thread the new log, and then promptly put the contents of Relay LOG file is parsed into sql statement, and on its own Slave server by parsing the SQL statement positional order execution applications such sql statement, and record the current application relay log file name and location of the points in relay-log.info.

Mysql main advantage of replication from

1. In the work can be performed from a server query (that is, we often say that the reading function), reducing the pressure of the main server; (the main library to write, read from the library, step-down)
2. From the master server backup, to avoid affecting the primary server during backup services; (data security)
3. When the primary server is a problem, it can be switched from the server. (To improve performance)

Mysql master-slave replication shortcomings and solutions

1. Loss of consistency ------ "Solution: If a business requires strong consistency, then you need to force the main library reading