问题现象
发现从库mysql_slave的参数Seconds_Behind_Master越来越大。已排除主从服务器时间不一致；那么主要就判断两点：是io thread慢还是 sql thread慢？先观察show slave status\G 。
判断3个参数（参数后面的值是默认空闲时候的正常值）：
Slave_IO_State: Waiting for master to send event
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Seconds_Behind_Master: 0
1.sql thread慢的表现：
Seconds_Behind_Master越来越大
Slave_SQL_Running_State: Reading event from the relay log
2.io thread慢的表现：
Seconds_Behind_Master为0
Slave_SQL_Running_State: 显示正常值
Slave_IO_State:显示忙碌状态
本文观察到的值：
Slave_IO_State: Queueing master event to the relay log
Seconds_Behind_Master: 30880
Slave_SQL_Running_State: Reading event from the relay log
上述三个参数，推断是sql thread慢
同步延迟信息详见如下：
mysql> show master status \G*************************** 1. row ***************************File: mysql-bin.000057Position: 214873221Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 838ad3df-a43d-11e8-8b02-6c92bf7daa8d:1,efd10b43-a43c-11e8-85d8-6c92bf7d9fd1:1-1342023811 row in set (0.00 sec)
从库延迟：
mysql> show slave status \G*************************** 1. row ***************************Slave_IO_State: Queueing master event to the relay logMaster_Host: 192.168.10.111Master_User: replMaster_Port: 3306Connect_Retry: 60Master_Log_File: mysql-bin.000057Read_Master_Log_Pos: 214813221Relay_Log_File: relay-bin.00045Relay_Log_Pos: 28055325Relay_Master_Log_File: mysql-bin.000057Slave_IO_Running: YesSlave_SQL_Running: YesExec_Master_Log_Pos: 94286319Relay_Log_Space: 956058939Seconds_Behind_Master: 30880Master_Server_Id: 113306Master_UUID: efd10b43-a43c-11e8-85d8-6c92bf7d9fd1Master_Info_File: mysql.slave_master_infoSQL_Delay: 0SQL_Remaining_Delay: NULLSlave_SQL_Running_State: Reading event from the relay logMaster_Retry_Count: 86400Retrieved_Gtid_Set: efd10b43-a43c-11e8-85d8-6c92bf7d9fd1:153917-55474510Executed_Gtid_Set: 838ad3df-a43d-11e8-8b02-6c92bf7daa8d:1,efd10b43-a43c-11e8-85d8-6c92bf7d9fd1:1-54003557Auto_Position: 11 row in set (0.00 sec)
注意： Seconds_Behind_Master: 30880
分析步骤：
开始怀疑是参数配置的差异，比对/etc/my.cnf后发现，发现配置并无差异。
从库使用操作系统命令dstat观察，发现繁忙时候，slave的IO写速度上不去
[root@mysql ~]# dstatYou did not select any stats, using -cdngy by default.----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--usr sys idl wai hiq siq| read writ| recv send| in out | int csw0 0 100 0 0 0| 19k 686k| 0 0 | 0 0 | 231 6480 0 99 1 0 0| 0 1388k| 798B 396B| 0 0 | 358 15960 0 99 1 0 0| 0 1676k| 244B 170B| 0 0 | 397 19490 0 99 1 0 0| 0 1796k|1490B 236B| 0 0 | 451 21070 0 99 1 0 0| 0 1764k| 244B 170B| 0 0 | 414 21040 0 100 0 0 0| 0 1536k|1068B 170B| 0 0 | 390 16490 0 99 1 0 0| 0 1516k| 244B 170B| 0 0 | 373 15750 0 99 1 0 0| 0 1552k| 34k 500B| 0 0 | 410 16020 0 100 0 0 0| 0 1556k| 126B 236B| 0 0 | 363 15270 0 99 1 0 0| 0 1384k| 60B 170B| 0 0 | 349 13690 0 99 1 0 0| 0 1440k| 13k 434B| 0 0 | 400 15130 0 100 0 0 0| 0 1800k| 612B 170B| 0 0 | 418 19050 0 99 0 0 0| 0 1484k| 246B 236B| 0 0 | 622 15680 0 99 1 0 0| 0 1272k| 60B 170B| 0 0 | 347 12940 0 99 1 0 0| 0 1624k| 126B 236B| 0 0 | 400 18150 0 99 1 0 0| 0 1580k| 60B 170B| 0 0 | 358 17120 0 100 0 0 0| 0 1536k| 22k 302B| 0 0 | 395 15830 0 100 0 0 0| 0 1440k| 514B 368B| 0 0 | 383 17650 0 99 1 0 0| 0 1596k| 28k 500B| 0 0 | 446 2151看到从库的写只能达到每秒1.5M左右，IO性能不是很好，也印证了初步的推测。
那么问题来了，
要如何优化IO性能比较差的slave呢？
简单，本文做了如下两个参数的修改：
mysql> set global innodb_flush_log_at_trx_commit=2;Query OK, 0 rows affected (0.00 sec)mysql> set global sync_binlog=20 ;Query OK, 0 rows affected (0.00 sec)
innodb_flush_log_at_trx_commit和sync_binlog这两个参数又是个啥？
innodb_flush_log_at_trx_commit
1. innodb_flush_log_at_trx_commit设置为0，log buffer将每秒一次地写入log file中，并且log file的flush(刷到磁盘)操作同时进行.该模式下，在事务提交的时候，不会主动触发写入磁盘的操作。
2. innodb_flush_log_at_trx_commit设置为1，每次事务提交时MySQL都会把log buffer的数据写入log file，并且flush(刷到磁盘)中去.
3. innodb_flush_log_at_trx_commit设置为2，每次事务提交时MySQL都会把log buffer的数据写入log file.但是flush(刷到磁盘)操作并不会同时进行。该模式下,MySQL会每秒执行一次 flush(刷到磁盘)操作。
注意：
由于进程调度策略问题,这个“每秒执行一次 flush(刷到磁盘)操作”并不是标准意义上的保证100%的“每秒”。
sync_binlog
sync_binlog 的默认值是0，像操作系统刷其他文件的机制一样，MySQL不会同步到磁盘中去而是依赖操作系统来刷新binary log。
当sync_binlog =N (N>0) ，MySQL 在每写 N次二进制日志binary log时，会使用fdatasync()函数将它的写二进制日志binary log同步到磁盘中去。
注意:
如果启用了autocommit，那么每一个语句statement就会有一次写操作；否则每个事务对应一个写操作。mysql服务默认是autocommit打开的。
如上sync_binlog,autocommit,innodb_flush_log_at_trx_commit三个参数，详见从库mysql_slave设置如下：
mysql> show variables like '%sync_binlog%';+---------------+-------+| Variable_name | Value |+---------------+-------+| sync_binlog | 0 |+---------------+-------+1 row in set (0.01 sec)mysql>mysql> show variables like '%innodb_flush_log_at_trx_commit%';+--------------------------------+-------+| Variable_name | Value |+--------------------------------+-------+| innodb_flush_log_at_trx_commit | 1 |+--------------------------------+-------+1 row in set (0.00 sec)mysql> show variables like '%autocommit%';+---------------+-------+| Variable_name | Value |+---------------+-------+| autocommit | ON |+---------------+-------+1 row in set (0.00 sec)
根据上述分析过程，修改如下值：
mysql> set global sync_binlog=20;mysql> set global innodb_flush_log_at_trx_commit=2;
接下来，我们观察和验证从库同步情况
1. 使用dstat命令观察磁盘IO，下图可以看到从库的写有原来的每秒1.5M左右提升为4M以上，
[root@mysql ~]# dstatYou did not select any stats, using -cdngy by default.----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--usr sys idl wai hiq siq| read writ| recv send| in out | int csw0 0 100 0 0 0| 19k 686k| 0 0 | 0 0 | 231 6480 0 99 1 0 0| 0 4756k| 882B 462B| 0 0 | 601 66900 0 99 1 0 0| 0 4208k| 430B 236B| 0 0 | 642 87710 0 99 1 0 0| 0 4452k| 428B 170B| 0 0 | 607 78030 0 99 1 0 0| 0 7964k| 26k 500B| 0 0 | 589 68350 0 99 1 0 0| 0 3832k|1166B 170B| 0 0 | 368 24670 0 99 1 0 0| 0 4584k|2042B 236B| 0 0 | 523 46320 0 99 1 0 0| 0 4972k|1296B 170B| 0 0 | 661 92980 0 99 1 0 0| 0 4792k|1046B 236B| 0 0 | 606 96340 0 99 1 0 0| 0 5244k|3032B 212B| 0 0 | 745 99650 0 99 0 0 0| 0 4648k| 796B 170B| 0 0 |1166 19k0 0 99 1 0 0| 0 4608k| 21k 434B| 0 0 | 827 14k0 0 99 0 0 0| 0 4552k|1858B 236B| 0 0 | 971 17k0 0 99 0 0 0| 0 4580k| 980B 170B| 0 0 | 936 17k0 0 99 1 0 0| 0 8332k| 21k 434B| 0 0 | 940 13k0 0 99 0 0 0| 0 4136k|1112B 236B| 0 0 |1112 20k0 0 99 0 0 0| 0 4940k| 796B 170B| 0 0 |1045 19k0 0 99 0 0 0| 0 4496k| 22k 500B| 0 0 | 951 15k0 0 99 0 0 0| 0 4652k| 862B 170B| 0 0 |1022 18k0 0 99 0 0 0| 0 5472k|1546B 236B| 0 0 | 950 15k0 0 99 0 0 0| 0 2616k| 20k 434B| 0 0 | 901 15k0 0 99 1 0 0| 0 9564k|2410B 170B| 0 0 | 958 14
2. 从库使用 show slave status \G，观察到Seconds_Behind_Master: 21202在持续缩小和主库的差距。Seconds_Behind_Master:由原来的30880降为21202，且在持续减少中。
mysql> show slave status \G*************************** 1. row ***************************Slave_IO_State: Queueing master event to the relay logMaster_Host: 192.168.10.111Master_User: replMaster_Port: 3306Connect_Retry: 60Master_Log_File: mysql-bin.000057Read_Master_Log_Pos: 214833221Relay_Log_File: relay-bin.00045Relay_Log_Pos: 28064325Relay_Master_Log_File: mysql-bin.000057Slave_IO_Running: YesSlave_SQL_Running: YesExec_Master_Log_Pos: 544925182Relay_Log_Space: 973436169Master_SSL_Allowed: NoSeconds_Behind_Master: 21202Replicate_Ignore_Server_Ids:Master_Server_Id: 113306Master_UUID: efd10b43-a43c-11e8-85d8-6c92bf7d9fd1Master_Info_File: mysql.slave_master_infoSQL_Delay: 0SQL_Remaining_Delay: NULLSlave_SQL_Running_State: Waiting for dependent transaction to commitMaster_Retry_Count: 86400Retrieved_Gtid_Set: efd10b43-a43c-11e8-85d8-6c92bf7d9fd1:153917-55504200Executed_Gtid_Set: 838ad3df-a43d-11e8-8b02-6c92bf7daa8d:1,efd10b43-a43c-11e8-85d8-6c92bf7d9fd1:1-54771730Auto_Position: 11 row in set (4.98 sec)
至此，Seconds_Behind_Master越来越打的问题得到解决。
