《Mysql主从同步之Slave延迟状态监控实例讲解》由会员分享，可在线阅读，更多相关《Mysql主从同步之Slave延迟状态监控实例讲解（8页珍藏版）》请在金锄头文库上搜索。
1、MysqlMysql 主从同步之主从同步之 SlaveSlave 延迟状态监控实例讲解延迟状态监控实例讲解针对主从同步过程中 slave 延迟状态的监控梳理如下：在 mysql 日常维护工作中，对于主从复制的监控主要体现在：1）检查数据是否一致；2）监控主从同步延迟，同步延迟的检查工作主要从下面两方面着手：1.一般的做法就是根据 Seconds_Behind_Master 的值来判断 slave 的延迟状态。可以通过监控 show slave statusG 命令输出的 Seconds_Behind_Master 参数的值来判断，是否有发生主从延时。? 1 2 3 4 5 6 7 8 9 10
2、 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27mysql show slave statusG; * 1. row * Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.101 Master_User: slave Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000004 Read_Master_Log_Pos: 761249 Relay_Log_File: mys
3、ql-relay-bin.000008 Relay_Log_Pos: 761408 Relay_Master_Log_File: mysql-bin.000004 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: huanqiu,huanpc Replicate_Ignore_DB: mysql Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 La
4、st_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 761249 Relay_Log_Space: 761620 Until_Condition: None Until_Log_File: 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master
5、_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 101 Master_UUID: b667a58f-d6e0-11e6-8c0a-fa163e2d66ac Master_Info_File: /data/mysq
6、l/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_
7、Set: Executed_Gtid_Set: Auto_Position: 0 1 row in set (0.00 sec) ERROR: No query specified以上是 show slave statusG 的输出结果，需要监控下面三个参数：1）Slave_IO_Running：该参数可作为 io_thread 的监控项，Yes 表示 io_thread的和主库连接正常并能实施复制工作，No 则说明与主库通讯异常，多数情况是由主从间网络引起的问题；2）Slave_SQL_Running：该参数代表 sql_thread 是否正常，YES 表示正常，NO 表示执行失败，具体就是
8、语句是否执行通过，常会遇到主键重复或是某个表不存在。3）Seconds_Behind_Master：是通过比较 sql_thread 执行的 event 的 timestamp和 io_thread 复制好的 event 的 timestamp(简写为 ts)进行比较，而得到的这么一个差值；NULL表示 io_thread 或是 sql_thread 有任何一个发生故障，也就是该线程的 Running 状态是 No，而非 Yes。0 该值为零，是我们极为渴望看到的情况，表示主从复制良好，可以认为lag 不存在。正值 表示主从已经出现延时，数字越大表示从库落后主库越多。负值 几乎很少见，我只是听
9、一些资深的 DBA 说见过，其实，这是一个BUG 值，该参数是不支持负值的，也就是不应该出现。-Seconds_Behind_Master 的计算方式可能带来的问题：relay-log 和主库的 bin-log 里面的内容完全一样，在记录 sql 语句的同时会被记录上当时的 ts，所以比较参考的值来自于 binlog，其实主从没有必要与 NTP 进行同步，也就是说无需保证主从时钟的一致。其实比较动作真正是发生在 io_thread 与 sql_thread 之间，而 io_thread 才真正与主库有关联，于是，问题就出来了，当主库 I/O 负载很大或是网络阻塞，io_thread 不能及时复
10、制 binlog（没有中断，也在复制），而 sql_thread 一直都能跟上 io_thread 的脚本，这时 Seconds_Behind_Master 的值是 0，也就是我们认为的无延时，但是，实际上不是，你懂得。这也就是为什么大家要批判用这个参数来监控数据库是否发生延时不准的原因，但是这个值并不是总是不准，如果当 io_thread 与 master 网络很好的情况下，那么该值也是很有价值的。之前，提到 Seconds_Behind_Master 这个参数会有负值出现，我们已经知道该值是 io_thread 的最近跟新的 ts 与 sql_thread 执行到的 ts差值，前者始终是大
11、于后者的，唯一的肯能就是某个 event 的 ts 发生了错误，比之前的小了，那么当这种情况发生时，负值出现就成为可能。-简单来说，就是监控 slave 同步状态中的：1）Slave_IO_Running、Slave_SQL_Running 状态值，如果都为 YES，则表示主从同步；反之，主从不同步。2）Seconds_Behind_Master 的值，如果为 0，则表示主从同步不延时，反之同步延时。2.上面根据 Seconds_Behind_Master 的值来判断 slave 的延迟状态，这么做在大部分情况下尚可接受，但其实是并不够准确的。对于 Slave 延迟状态的监控，还应该做到下面的
12、考虑：首先，我们先看下 slave 的状态：mysql show slave statusG;* 1. row *slave_IO_State: Waiting for master to send event* 035 棋牌 Master_Log_File: mysql-bin.000327Read_Master_Log_Pos: 668711237Relay_Log_File: mysql-relay-bin.002999Relay_Log_Pos: 214736858Relay_Master_Log_File: mysql-bin.000327slave_IO_Running: Yess
13、lave_SQL_Running: Yes* 988 棋牌 Skip_Counter: 0Exec_Master_Log_Pos: 654409041Relay_Log_Space: 229039311*Seconds_Behind_Master: 3296*可以看到 Seconds_Behind_Master 的值是 3296，也就是 slave 至少延迟了 3296 秒。我们再来看下 slave 上的 2 个 REPLICATION 进程状态：mysql show full processlistG;* 1. row *Id: 6User: system userHost:db: NULL
14、Command: ConnectTime: 22005006State: Waiting for master to send eventInfo: NULL* 2. row *Id: 7User: system userHost:db: NULLCommand: ConnectTime: 3293State: UpdatingInfo: UPDATE * SET * WHERE *可以看到 SQL 线程一直在执行 UPDATE 操作，注意到 Time 的值是 3293，看起来像是这个 UPDATE 操作执行了 3293 秒，一个普通的 SQL 而已，肯定不至于需要这么久。实际上，在 REPLICATION 进程中，Time 这列的值可能有几种情况：1）SQL 线程当前执行的 binlog（实际上是 relay log）中的 timestamp 和 IO 线程最新的 timestamp 的差值，这就是通常大家认为的 Seconds_Behind_Master 值，并不是某个 SQL 的实际执行耗时；2）SQL 线程当前如果没有活跃 SQL 在执行的话，Time 值就是 S
