Online Mysql master-slave synchronization delay troubleshooting

I. Introduction

        In the past few days online, there has been a problem that the data cannot be found after the business operation is completed. At first, I thought it was because the verification called the verification of other document locations. Later, I took the SQL to the master database and the slave database to check. The library has no data and is delayed for over an hour.

Two, investigation

        Mysql5.7 is used online, in semi-synchronous mode. When communicating with dba, I thought it was the synchronous mode at first, and then the physical backup of the standby database takes four hours every morning. When the main database has ddl, the standby database Stuck, the system did not read data from the library.

        Here are a few questions: ① How can the backup database be used for high availability only once a day in the early morning? Shouldn’t it be real-time synchronization?

        ②The main library has ddl. Since it can still respond to system writes, it means that the binlog data is still being updated. The slave library is synchronized through binlog. Why is there no data?

         Then we talked about it again. The actual structure is as follows:

         As a preparation for high availability, the main library 2 synchronizes the main library in real time. When the main library is down, it will become the main library. Usually, a physical backup file will be generated in the early morning to restore the data to the previous day when there is a problem.

        Although log_slave_update is turned on, the slave library will also record the binlog, and cascade synchronization can be done, but in fact the delay will be relatively large, and the dba still sets to pull the main library. The binlog of the slave library can be synchronized with tools such as data warehouses and Flink.

        The main library 2 is also used as part of the read. The reason for the actual delay is: when the system reads data, the read domain name drifts to the main library 2, and the main library 2 is doing physical backup. When the backup is stuck, the data update is blocked.

Three, solve

        There are several solutions:

        1. Exclude the main library 2 as a read query. This is not planned for the time being. If there are still problems to consider later, what if all three slave libraries are hung up?

        2. Set the blocking time of the main library 2 for physical backup. If the blocking time exceeds a certain period, the backup will be stopped. After a while, it will start from the beginning. This method is better for dba, and bloggers think it is hidden danger, which will easily lead to continuous backup cycle.

        3. Combining physical backup and LVM logical backup, physical backup once a week is enough, and LVM logical backup is used every day. This is also the recommended method of "High Performance Mysql" read by bloggers. Combining 2 will basically not cause problems. But this requires the automation of operation and maintenance development and backup management, and dba feels unnecessary.

Four. Summary

        This involves the basic knowledge related to Mysql synchronization and backup. Bloggers are too lazy to write. Interested students can read "High Performance Mysql"

        The problems caused by different architectures correspond to different optimization solutions, and those who are interested can communicate with each other

Guess you like

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