====延迟检测方法：
informaiton_shcema.user_statisitics
select * from information_schema.user_statistics where user='#mysql_system#'\G
1、Seconds_Behind_Master 理论上列出了备库的延迟，并不总是准确的。SQL线程当前执行的binlog（实际上是relay log）中的timestamp和IO线程最新的timestamp的差值，这就是通常大家认为的 Seconds_Behind_Master 值，并不是某个SQL的实际执行耗时；
2、更为严谨的是在MASTER上执行SHOW BINARY LOGS 的结果是
+------------------+--------------+
| Log_name | File_size |
+------------------+--------------+
| mysql-bin.000009 | 1073742063 |
| mysql-bin.000010 | 107374193 |
+------------------+--------------+
而在SLAVE上执行SHOW SLAVE STATUS\G 的结果是：
Master_Log_File: mysql-bin.000009
Read_Master_Log_Pos: 668711237
Relay_Master_Log_File: mysql-bin.000009
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
***
Exec_Master_Log_Pos: 654409041
***
Seconds_Behind_Master: 3296
***
这时候，SLAVE实际的延迟应该是：
mysql-bin.000009 这个binlog中的binlog position 1073742063 和 SLAVE上读取到的binlog position之间的差异延迟，即：
1073742063 - 654409041 = 419333022 个binlog event
并且还要加上 mysql-bin.000010这个binlog已经产生的107374193个binlog event，共
107374193 + 419333022 = 526707215 个binlog event
3、可以在MASTER上维护一个监控表，它只有一个字段，存储这最新最新时间戳（高版本可以采用event_scheduler来更新，低版本可以用cron结合自动循环脚本来更新），在SLAVE上读取该字段的时间，只要MASTER和SLAVE的系统时间一致，即可快速知道SLAVE和MASTER延迟差了多少。
不过，在高并发的系统下，这个时间戳可以细化到毫秒，否则哪怕时间一致，也是有可能会延迟数千个binlog event的。
4、pt-heartbeat
过大的复制延迟没有太多的调优空间，大部分是禁止某些额外的工作以减少备库的负载。最简单的方法是设置innodb，使其不那么频繁的刷新磁盘，这样事务提交的更快些。
innodb_flush_log_at_trx_commit=2
innodb_locks_unsafe_for_binlog =1
myisam的delay_key_write = all
牺牲安全换速度，如果提升备库为主库，要记得把这些选项设置为安全值。
informaiton_shcema.user_statisitics
select * from information_schema.user_statistics where user='#mysql_system#'\G
1、Seconds_Behind_Master 理论上列出了备库的延迟，并不总是准确的。SQL线程当前执行的binlog（实际上是relay log）中的timestamp和IO线程最新的timestamp的差值，这就是通常大家认为的 Seconds_Behind_Master 值，并不是某个SQL的实际执行耗时；
2、更为严谨的是在MASTER上执行SHOW BINARY LOGS 的结果是
+------------------+--------------+
| Log_name | File_size |
+------------------+--------------+
| mysql-bin.000009 | 1073742063 |
| mysql-bin.000010 | 107374193 |
+------------------+--------------+
而在SLAVE上执行SHOW SLAVE STATUS\G 的结果是：
Master_Log_File: mysql-bin.000009
Read_Master_Log_Pos: 668711237
Relay_Master_Log_File: mysql-bin.000009
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
***
Exec_Master_Log_Pos: 654409041
***
Seconds_Behind_Master: 3296
***
这时候，SLAVE实际的延迟应该是：
mysql-bin.000009 这个binlog中的binlog position 1073742063 和 SLAVE上读取到的binlog position之间的差异延迟，即：
1073742063 - 654409041 = 419333022 个binlog event
并且还要加上 mysql-bin.000010这个binlog已经产生的107374193个binlog event，共
107374193 + 419333022 = 526707215 个binlog event
3、可以在MASTER上维护一个监控表，它只有一个字段，存储这最新最新时间戳（高版本可以采用event_scheduler来更新，低版本可以用cron结合自动循环脚本来更新），在SLAVE上读取该字段的时间，只要MASTER和SLAVE的系统时间一致，即可快速知道SLAVE和MASTER延迟差了多少。
不过，在高并发的系统下，这个时间戳可以细化到毫秒，否则哪怕时间一致，也是有可能会延迟数千个binlog event的。
4、pt-heartbeat
过大的复制延迟没有太多的调优空间，大部分是禁止某些额外的工作以减少备库的负载。最简单的方法是设置innodb，使其不那么频繁的刷新磁盘，这样事务提交的更快些。
innodb_flush_log_at_trx_commit=2
innodb_locks_unsafe_for_binlog =1
myisam的delay_key_write = all
牺牲安全换速度，如果提升备库为主库，要记得把这些选项设置为安全值。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29974949/viewspace-1769600/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
