A delay line mysql standby large, master node writes frequently, slave node can not accumulate large relay-log even write.
Reference: https://www.cnblogs.com/conanwang/p/6006444.html
Why is there a large number of relay-log
first of all the need to start with mysql synchronization mechanism, the synchronization -> semi-synchronous
database instance Master node concurrent run multiple threads at the same time commit the transaction, the transaction submitted in accordance with the logic of time (No. database LSN) sequentially writing binary log log, slave node writes through the I / O thread-local relay log log, in order to ensure data consistency standby, slave node must perform in the same order, if the order is inconsistent easily cause inconsistent standby data repository risks of. But the slave node has only a single thread to execute SQL relay log in log replay the transaction was submitted to the main library, there is a delay caused by standby database- Treatment
recommendations can physically handle direct physical resolved
a. Use Disk SSD
b. Disk group raid10
c. handle IO from the file system level problems / kernel level of optimization
mysql treatment of
think of ways to let the slave multi-threaded execution log Relay
MySQL 5.6 release introduces concurrent replication (schema level), based on the core idea of copying schema level concurrency: "Table concurrent data submitted under different schema do not affect each other, namely slave node can function in a SQL-like threads with each assigned to relay log in different schema, to relay the transaction log replay has been submitted in the main library, keeping data consistent with the main library. "
MySQL 5.6 based on schema level can solve the concurrent copy table when business data on different database library, but actual production is often most or all of the business data tables are placed in the same schema, in this scenario, even if slave_parallel_workers > 0 settings can not be executed concurrently in the main library relay log records submitted data. The case of high concurrency, because the slave can not be executed concurrently with the business data tables under a schema, will still result in the case of primary and delays.
MySQL 5.7 introduced Enhanced Muti-threaded slaves, slave configuration when slave_parallel_workers> 0 and global.slave_parallel_type = 'LOGICAL_CLOCK', to support the next schema, slave_parallel_workers a worker threads concurrently executing the main relay log database transaction submission. But to achieve the above function, which can be performed concurrently in a transaction binary log in to submit a master machine marks, although MySQL 5.6 has introduced a binary log group commit, but the transaction will not be executed concurrently marked.
MySQL 5.7 GA version introduced Enhanced Multi-threaded Slaves function, solve the problem before the release of the active and standby data replication latency, open the function parameters are as follows:
# slave机器
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-type=DATABASE #兼容MySQL 5.6基于schema级别的并发复制
slave-parallel-workers=4 ＃开启多线程复制
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON