How to solve the master-slave database synchronization delay problem?

How to solve the problem that after the record is inserted in the main database, it cannot be read from the slave database in time, and how to avoid this problem from the structure. I have seen a new version database table
on the Internet, and then use mysql proxy to determine whether the data is up to date, and then Routing to the main library or the slave library, is this solution feasible? How does it work?

Author: Jiang Jian
Link : https://www.zhihu.com/question/20025096/answer/82440882
Source: Zhihu The
copyright belongs to the author. For commercial reprints, please contact the author for authorization, and for non-commercial reprints, please indicate the source.

The solution suggested by the subject seems very unreliable.
However, mysql-proxy has little contact with it, and whether it can implement the appeal function is somewhat uncertain. Even if it does, it is not recommended to use it for this purpose, and the official website itself does not recommend using it in the production environment.

Regarding the master-slave delay, my experience is as follows:
the
master can handle all the business on the master database, and the slave database only does disaster recovery, backup, and statistical report work that
does not require high real-time performance; If there is a delay,
generally speaking , just wait slowly. Trying to restart the db and other operations cannot be solved, and it will take longer because the large transaction is rolled back and then redone.
If the delay of N days cannot be solved,
then redo the slave.
Why is there a delay of N days, is it just because of the single thread from the library?
I feel that most of them use mixed binlog_format on the main library. Due to certain limitations, they cannot be based on statement, so they have to be copied in row mode.
Then if the current sql is a full table scan, when it is sent to the slave for execution, it is a full table scan many times.
Generally speaking, show proceslist on the slave to see what the current system user is executing, that is the problem SQL. If the pos point has not moved, you can also go to the binlog corresponding to the main library to check what is being executed.
When there is a delay, check the CPU and disk status of the current slave.
Generally speaking , if the slave library has no other services, it is already the limit for the CPU to run a full core due to a single thread. If the disk io is full, confirm whether there are other processes or mysql threads affecting it (for example, the slave library is dumping or the oversized sql is being executed), and you can also try to adjust several parameters about the io on the slave.
From the library raid card, be sure to The write strategy set to write back
This is a big hit for me, and it took me a few months to find out why my SSD io performance is so bad. Batch
dml operation If the batch dml operation is not processed, there will be delays. It is recommended to perform the low-peak business period and adjust the batch operation, such as 10,000 dml lines at a time, sleep for a while, and then 10,000 dml lines. The specific number of lines and sleep need to be determined according to the business, and it is good to ensure that the slave library is not delayed. A few other tips: If there is a frequent short-time delay, try to increase the hardware configuration of the slave library, such as sata SSD, pcie, etc. Delay monitoring is in place, and pt-heart-beat can be used to accurately monitor the delay value. Find out in time. For versions later than 5.5, semi-synchronous replication can be considered, which can solve the problem caused by a small amount of delay, but the performance loss of tps is relatively large. Upgrade to MySQL 5.7, multi-threaded replication, almost perfectly solves the slave library delay caused by single-threaded replication. Author: Jiang Jian











Link: https://www.zhihu.com/question/20025096/answer/82440882
Source: Zhihu The
copyright belongs to the author. For commercial reprints, please contact the author for authorization, and for non-commercial reprints, please indicate the source.

The solution suggested by the subject seems very unreliable.
However, mysql-proxy has little contact with it, and whether it can implement the appeal function is somewhat uncertain. Even if it does, it is not recommended to use it for this purpose, and the official website itself does not recommend using it in the production environment.

Regarding the master-slave delay, my experience is as follows:
the
master can handle all the business on the master database, and the slave database only does disaster recovery, backup, and statistical report work that
does not require high real-time performance; If there is a delay,
generally speaking , just wait slowly. Trying to restart the db and other operations cannot be solved, and it will take longer because the large transaction is rolled back and then redone.
If the delay of N days cannot be solved,
then redo the slave.
Why is there a delay of N days, is it just because of the single thread from the library?
I feel that most of them use mixed binlog_format on the main library. Due to certain limitations, they cannot be based on statement, so they have to be copied in row mode.
Then if the current sql is a full table scan, when it is sent to the slave for execution, it is a full table scan many times.
Generally speaking, show proceslist on the slave to see what the current system user is executing, that is the problem SQL. If the pos point has not moved, you can also go to the binlog corresponding to the main library to check what is being executed.
When there is a delay, check the cpu and disk status of the current slave
Generally speaking, if there is no other business from the library, for single-threaded reasons, it is already the limit for the CPU to run a full core. If the disk io is full, confirm whether there are other processes or mysql threads affecting it (for example, the slave library is dumping or the oversized sql is being executed), and you can also try to adjust several parameters about the io on the slave.
From the library raid card, be sure to The write strategy set to write back
This is a big hit for me, and it took me a few months to find out why my SSD io performance is so bad. Batch
dml operation If the batch dml operation is not processed, there will be delays. It is recommended to perform the low-peak business period and adjust the batch operation, such as 10,000 dml lines at a time, sleep for a while, and then 10,000 dml lines. The specific number of lines and sleep need to be determined according to the business, and it is good to ensure that the slave library is not delayed. A few other tips: If there is a frequent short-time delay, try to increase the hardware configuration of the slave library, such as sata SSD, pcie, etc. Delay monitoring is in place, and pt-heart-beat can be used to accurately monitor the delay value. Find out in time. For versions later than 5.5, semi-synchronous replication can be considered, which can solve the problem caused by a small amount of delay, but the performance loss of tps is relatively large. Upgrade to MySQL 5.7, multi-threaded replication, almost perfectly solves the slave library delay caused by single-threaded replication.