Mysql transaction, synchronization, backup

I. Introduction

        When sharing master-slave synchronization delay troubleshooting in the department before online Mysql master-slave synchronization delay troubleshooting_tingmailang's blog-CSDN blog , colleagues have some new problems, and some colleagues' understanding of transactions, synchronization, and backup is limited to the Internet Some blogs and communities, not in-depth and not completely correct, do some analysis here

2. Analysis

for example:

1. Why is the data in the slave library not updated to the disk and buffer when the physical backup is stuck?

2. In semi-synchronous mode, will the stuck slave library affect the transaction submission of the main library?

3. Why is LVM logical backup recommended for high-performance Mysql? How does it implement snapshot mirroring without blocking disk writes?

1. Here is a simple drawing of the master-slave module of Mysql

innodb is a configurable engine of mysql, which is equivalent to a plug-in

 

2. The transaction starts

After the transaction starts, write undolog first, and generate a doubly linked list in the table space segment, which is the so-called version chain, which is used for transaction rollback and MVCC

Redolog records all data page changes, so undolog changes will be recorded to ensure persistence

Modify the buffer line data, the buffer area will be written to the disk by various strategies such as capacity and time frequency

 

3. Transaction submission

When the transaction is committed, the main library writes to the binlog, which is clearly stated in "Innodb Storage Engine"

After writing to the binlog, the background thread of mysql transfers the data to the slave library, and the main library decides whether to wait for the ack response according to the synchronization mode. We use the semi-synchronization mode

After receiving data from the library, write to relaylog, another asynchronous thread writes to the buffer, if log_slave_update is enabled, it will also write to the binlog of the slave library

 

Analyze several issues below

1. Why is the data in the slave library not updated to the disk and buffer when the physical backup is stuck?

Physical backup is a copy of the disk file, so the relaylog of the slave library is written normally, but changing the disk file from the relaylog will cause the file to be changed, which is mutually exclusive with the copy

2. In semi-synchronous mode, will the stuck slave library affect the transaction submission of the main library?

In fact, in any mode, the main library will eventually submit. The default timeout time is 10s. Our online dba sets 1s. Even if the main library does not receive the ack signal when the timeout expires, the transaction will be completed

So how is semi-synchronous better than asynchronous? It just reduces the probability of a situation, that is, after the main library sends out, the slave library does not receive it successfully, but the main library is down, and the slave library will become the main library. At this time, the master and slave will be inconsistent. (In the case of asynchronous, this possibility is much larger than that of semi-synchronous)

So if the timeout master library automatically ends the transaction, and the slave library has not received it at this time, isn’t it still inconsistent? The mysql slave library will send its own gtid to the main library. When the main library is compared with its own gtid, it will automatically find out what is missing from the library, and will send these binlogs to the slave library.

3. Why is LVM logical backup recommended for high-performance Mysql? How does it implement snapshot mirroring without blocking disk writes?

​LVM logical backup is based on Linux's CoupOnWrite mechanism. It does not copy files when backing up. If the disk is written, it will copy the smallest unit of fan-shaped data pages through subprocesses, that is, copy-on-write. Therefore, there is almost no Will conflict with writing, even the conflict of the smallest unit will end soon (redis' rdb persistence is also based on this mechanism)

3. Summary

1. Mysql transactions are realized by Innodb’s undolog and redolog. Undolog records row data changes and forms a doubly linked list on the table space side for rollback and MVCC. Redolog records data page changes to restore to the situation before mysql crashed.

2. Mysql master-slave synchronization is divided into three methods: full synchronization, semi-synchronization, and asynchronous, but no matter which one is just to determine whether the main library needs to wait

3. Backup is divided into physical backup and logical backup. LVM logical backup is based on the Coupopwrite mechanism of Linux, which is recommended by "High Performance Mysql"

In addition to the above analysis of actual operation verification and research on "High Performance MySQL" and "Innodb Storage Engine", bloggers and DBAs have also gone through in-depth discussions. If you have any objections, welcome to discuss.

Guess you like

Origin blog.csdn.net/m0_69270256/article/details/128311652