1. MySQL database master-slave synchronization delay principle.
Answer: When it comes to the principle of master-slave synchronization delay of MySQL database, we must start from the principle of master-slave replication of MySQL database. The master-slave replication of MySQL is a single-threaded operation. The master database generates binlog for all DDL and DML, and binlog is written sequentially. , so the efficiency is very high. The Slave_IO_Running thread of the slave goes to the main library to get logs, which is very efficient. Next, the problem is coming. The Slave_SQL_Running thread of the slave implements the DDL and DML operations of the main library in the slave. The IO operations of DML and DDL are random, not sequential, and the cost is much higher. Other queries on the slave may also generate lock contention. Since Slave_SQL_Running is also single-threaded, a DDL card master needs to be executed for 10 minutes. Then all subsequent DDLs will wait for this DDL to be executed before continuing, which leads to a delay. Some friends will ask: "The same DDL on the main library also needs to be executed for 10 minutes, why is the slave delayed?" The answer is that the master can be concurrent, but the Slave_SQL_Running thread cannot.
2. How is the master-slave synchronization delay of MySQL database generated?
Answer: When the TPS concurrency of the main database is high, the amount of DDL generated exceeds the range that a sql thread of the slave can bear, then the delay occurs, and of course, there may be lock waiting with the large query statement of the slave.
3. MySQL database master-slave synchronization delay solution
A: The simplest solution to reduce the slave synchronization delay is to optimize the architecture and try to make the DDL of the main library execute quickly. In addition, the main library is written, which has high data security, such as sync_binlog=1, innodb_flush_log_at_trx_commit = 1 and other settings, while the slave does not need such high data security, it is completely possible to set sync_binlog to 0 or close binlog, innodb_flushlog can also be set to 0 to improve the execution efficiency of sql. The other is to use a better hardware device than the main library as the slave.
MySQL 5.6.3 already supports multi-threaded master-slave replication. The principle is similar to that of Dingqi. Dingqi uses tables to do multi-threading. Oracle uses database (schema) as a unit to do multi-threading. Different libraries can use different replication threads.
sync_binlog=1
This makes MySQL synchronize the binary log’s contents to disk each time it commits a transaction
By default, the binlog is not synced with the hard disk on every write. So if the operating system or machine (not just the MySQL server) crashes, it is possible that the last statement in the binlog is lost. To prevent this, you can use the sync_binlog global variable (1 is the safest value, but also the slowest) to make binlog sync with disk after every N binlog writes. Even if sync_binlog is set to 1, in the event of a crash, there may be inconsistencies between table contents and binlog contents. If using InnoDB tables, the MySQL server processes the COMMIT statement, it writes the entire transaction to the binlog and commits the transaction into InnoDB. If a crash occurs between operations, on restart, the transaction is rolled back by InnoDB, but still exists in the binlog. The --innodb-safe-binlog option can be used to increase consistency between InnoDB table contents and binlog. (Note: --innodb-safe-binlog is not required in MySQL 5.1; this option is obsolete due to the introduction of XA transaction support), this option can provide a greater degree of safety, making the per-transaction binlog (sync_binlog=1 ) and (the default is true) the InnoDB log is synchronized with the hard disk, the effect of this option is that when restarting after a crash, after the transaction is rolled back, the MySQL server cuts the rolled back InnoDB transaction from the binlog. This ensures that binlog feeds back the exact data for InnoDB tables, etc., and keeps the slave in sync with the master (not receiving rolled back statements).
innodb_flush_log_at_trx_commit (this works)
Complaining that Innodb is 100x slower than MyISAM? Then you probably forgot to adjust this value. The default value of 1 means that every transaction commit or out-of-transaction command needs to flush the log to disk, which is time-consuming. Especially when using battery backed up cache. Setting it to 2 is fine for many applications, especially those transferred from MyISAM tables, which means that they are not written to the hard disk but written to the system cache. Logs will still be flushed to disk every second, so you generally won't lose more than 1-2 seconds of updates. Setting it to 0 will be faster, but the security aspect is relatively poor. Even if MySQL hangs, the transaction data may be lost. A value of 2 is only possible to lose data when the entire operating system hangs.
Reference: http://www.linuxidc.com/Linux/2014-05/101450.htm