First, the delay from the master copy
Where :( 1 https://blog.csdn.net/u010522235/article/details/51865978)
the DDL main library (alter, drop, repair, create ) a delay resulting in a read-only node
might 1: Read-only node of the primary database synchronization is carried out serial DDL, DDL operations if a long execution time of the main libraries, may consume the same time in the library preparation, such as in a master database table to add a field to 500W takes 10 minutes, then on a read node will also takes 10 minutes, so the read-only node delay 600S, other common operations such as:
MySQL> NN column ALTER the Add Table Test VARCHAR (10);
MySQL> Table Test ALTER the Add index (JJ);
possible 2: there is a very long time to execute the query is executed on a read-only node then this clog DDL query from the main library, read node table is locked until the end of the inquiry, which led to the delay of data read-only nodes. Can be viewed on a read node connected by executing the command state is show processlist: Waiting for table metadata lock
Solution:
For 1 may be, can only say that before the operation may bring impact to have considered, in the case of 2, can kill off large queries on a read-only node, you can restore the data read-only nodes and the master node Synchronize
For binary logs, because of its write time occurs when a transaction is committed, it is assumed that produces a binary log 1G, you need to submit the transaction time will include the time it is written 1G log. There is a saying in Oracle, a transaction submitted are flat rate, regardless of the size of the transaction. This is a MySQL database is not established. That is, MySQL binary submission rate depends on the size of the transaction log is generated, the speed of the transaction commits is not flat.
Worse, MySQL master-slave replication latency under large transaction. Also assume that a large transaction performed one hour on the primary server, you need to transfer from the server at the end of the submission period. From master worst case delay for at least one hour, if needed from the server performs one hour, then the delay from the master copy may be 2 hours. Such limitations do not exist physically copied, or the reason described above, the transaction commit process, the log has been transmitted and playback.
In short, for the MySQL database, the time does not allow any large transaction execution. To do so, the large transaction split into a small sub-transaction to perform. This is the basic miscellaneous formulas, and yet has a very different and Oracle. In short, Airbender, Gladius, no good or bad, learn to understand the differences, mastery square up like Zhen Feng Qingyang realm.
If follow basic formulas, split large transactions small transactions, MySQL will not have a particularly large delay from I / O-threaded server. However, SQL thread delay still can not be solved.
Early in MySQL5.6, the introduction of concurrent copy, this copy is concurrent database level, which means that a SQL thread can handle a continuous transaction database, without waiting for the completion of other databases. This version of the concurrent copy, can be understood as a database SQL thread.
MySQL 5.7 introduced multi-threaded slave replication mechanism (hereinafter referred to as MTS, Multi-Thread Slave, also known as parallel copy parallel replication). For example a company many times before electricity supplier business, after opening parallel replication, replication latency decreased from 8 hours to 0, to solve the immediate problem of latency.
However, MTS Group to implement mechanisms based, in short, on the main parallel execution of how, on how to play back from the server . Here there is a possibility that if the master server parallelism insufficient effects from parallelism machine will be greatly reduced.
However, if the primary server is single-threaded or a small number of concurrently executing threads, the current MTS or there will be a delay mechanism. MySQL 8.0 is based on the latest MTS writeset is the ultimate solution. I.e. two transactions, as long as the updated record does not overlap (Coverlap), then from the machine can be executed in parallel without a group, even if the primary server single thread of execution, can still play back from the server in parallel. I believe this is the most perfect solution Road, MTS final form
Summary of
MySQL 5.7 introduced Enhanced Multi-Threaded Slave to solve the decades-long obsession MySQL replication latency issues, reminding some of the ignorance of the PostgreSQL user again, do not stay ahead for MySQL impression, not necessarily physical replication definitely better than logic copy has an advantage, while MySQL MTS 5.7 has been completely solve the delay problem.
Profile open MTS:
# slave
slave-parallel-type=LOGICAL_CLOCK #基于组提交的并行复制方式
slave-parallel-workers=16 #并行复制测试 开启16个线程 效果最佳
master_info_repository=TABLE #开启MTS功能后，务必将参数master_info_repostitory设置为TABLE，这样性能可以有50%~80%的提升。这是因为并行复制开启后对于元master.info这个文件的更新将会大幅提升，资源的竞争也会变大。在之前 InnoSQL 的版本中，添加了参数来控制刷新master.info这个文件的频率，甚至可以不刷新这个文件。因为刷新这个文件是没有必要的，即根据master-info.log这个文件恢复本身就是不可靠的。在MySQL5.7中，推荐将master_info_repositor
y设置为TABLE，来减小这部分的开销
relay_log_info_repository=TABLE
relay_log_recovery=ON