测试环境：
Red Hat Enterprise Linux Server release 6.3 (Santiago)
Server version: 5.6.22-log MySQL Community Server (GPL)

我搭建了1主3从的环境，准备测试MHA架构，过程中发现，测试并发插入的时候，从库1可以跟上，从库2,3跟不上

如何判断是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: Waiting for master to send event
Seconds_Behind_Master: 313
Slave_SQL_Running_State: Reading event from the relay log
因此推断是sql thread慢

为啥只有slave2,3慢，而slave1可以跟上呢，开始怀疑是参数配置的差异，比对/etc/my.cnf后发现，配置无差异
因此排除这个原因，后来用dstat观察，发现繁忙时候，slave的IO写速度上不去
slave1：
$ dstat
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
0 0 100 0 0 0|9308B 11k| 0 0 | 3B 3B| 63 63
3 4 54 40 0 0| 88k 10M| 45k 9438B| 0 0 |1857 2579
3 3 59 35 0 1| 80k 7552k| 40k 8486B| 0 0 |1675 2307
3 3 56 38 0 0| 72k 7824k| 42k 8816B| 0 0 |1727 2348
3 4 52 41 0 1| 96k 9688k| 49k 10k| 0 0 |2029 2874
3 4 54 39 0 0| 96k 8880k| 45k 9410B| 0 0 |1905 2674
3 3 53 40 0 1| 96k 9776k| 58k 10k| 0 0 |1935 2671
3 3 58 36 0 0| 64k 7848k| 40k 8420B| 0 0 |1724 2357
3 5 52 40 0 1| 96k 8936k| 49k 10k| 0 0 |1948 2680
3 4 51 42 0 1| 96k 9400k| 49k 10k| 0 0 |1988 2760
3 4 52 41 0 0| 88k 9752k| 49k 10k| 0 0 |2058 2868
4 4 51 41 0 1| 96k 9680k| 49k 9938B| 0 0 |1990 2750
3 3 59 35 0 0| 80k 7632k| 39k 8288B| 0 0 |1668 2275
3 4 52 42 0 1| 80k 8504k| 46k 9146B| 0 0 |1860 2523
3 4 51 42 0 0| 80k 8496k| 43k 8684B| 0 0 |1882 2516
2 3 65 30 0 0| 64k 5976k| 30k 6440B| 0 0 |1326 1802
3 4 53 40 0 1| 72k 8360k| 59k 10k| 0 0 |1859 2538
3 4 51 42 0 1| 96k 8840k| 53k 10k| 0 0 |1958 2648
2 4 51 43 0 0| 72k 7352k| 40k 7760B| 0 0 |1633 2219
3 4 51 42 0 1| 88k 7920k| 31k 6770B| 0 0 |1767 2373
3 3 54 40 0 0| 80k 8528k| 40k 8750B| 0 0 |1859 2549

slave2:
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
2 1 50 47 0 1|8192B 1168k| 55k 10k| 0 0 | 533 771
1 1 51 48 0 0|8192B 1048k| 33k 7046B| 0 0 | 427 622
1 1 51 48 0 0|8192B 1080k| 58k 9806B| 0 0 | 500 709
1 1 50 48 0 0| 0 1864k| 51k 8486B| 0 0 | 502 669
1 2 51 47 0 0|8192B 1120k| 42k 8156B| 0 0 | 496 674
1 1 51 47 0 0|8192B 1160k| 32k 6350B| 0 0 | 467 655
1 2 51 47 0 0| 0 1288k| 50k 10k| 0 0 | 563 797
1 1 51 47 0 0|8192B 1200k| 43k 8486B| 0 0 | 493 728
2 1 50 47 0 0|8192B 1024k| 45k 8816B| 0 0 | 481 659
1 1 50 48 0 0|8192B 1248k| 49k 9450B| 0 0 | 517 772
1 1 50 48 0 0| 0 1264k| 47k 9146B| 0 0 | 516 756
1 2 50 47 0 1|8192B 1144k| 50k 10k| 0 0 | 520 765
1 1 51 48 0 0|8192B 1200k| 51k 8156B| 0 0 | 484 716
1 2 50 48 0 0|8192B 968k| 50k 9278B| 0 0 | 470 684
1 1 50 48 0 0|8192B 1128k| 39k 7892B| 0 0 | 476 679
1 1 51 47 0 0| 0 1248k| 45k 9476B| 0 0 | 523 760
1 2 50 48 0 0|8192B 1448k| 41k 7826B| 0 0 | 552 805
1 1 50 48 0 0|8192B 1120k| 44k 8090B| 0 0 | 470 692

slave3:
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
1 1 50 49 0 0|8192B 1328k|1167B 170B| 0 0 | 385 515
1 1 51 48 0 0|8192B 1128k| 754B 170B| 0 0 | 325 449
1 1 50 49 0 0| 0 920k| 474B 314B| 0 0 | 279 381
0 1 50 49 0 0|8192B 664k|1633B 170B| 0 0 | 226 291
1 1 50 49 0 0|8192B 1200k|1250B 170B| 0 0 | 353 475
1 1 50 48 0 0| 0 1432k|1632B 170B| 0 0 | 402 551
1 1 51 48 0 0| 16k 1752k|1045B 170B| 0 0 | 487 664
1 1 50 48 0 0|8192B 1648k| 12k 170B| 0 0 | 461 636
1 1 51 48 0 0| 0 1272k| 886B 170B| 0 0 | 380 501
1 1 50 49 0 0|8192B 1000k|1023B 170B| 0 0 | 300 400
1 1 50 48 0 0|8192B 1096k| 747B 170B| 0 0 | 332 442
1 1 50 48 0 0|8192B 1448k|1003B 170B| 0 0 | 416 557
1 1 50 48 0 0| 0 1592k|1174B 170B| 0 0 | 450 614
1 1 51 48 0 0|8192B 1416k|1028B 170B| 0 0 | 404 552
0 1 50 49 0 0|8192B 1128k|1031B 170B| 0 0 | 331 447
1 1 51 48 0 0|8192B 1160k|1185B 170B| 0 0 | 340 458
1 1 50 49 0 0| 0 1120k| 633B 170B| 0 0 | 326 453
1 0 50 49 0 0|8192B 656k|8886B 170B| 0 0 | 221 288
1 1 50 49 0 0|8192B 1128k|1619B 170B| 0 0 | 335 451

slave1可以达到每秒9M的写入IO,而slave2,3只能达到每秒1M多，IO性能差很多，后来分析了下存储，发现是有很大差异的，也印证了我的推测

那么问题来了，要如何优化IO性能比较差的slave呢，其实很简单，修改两个参数
mysql> set global sync_binlog=20 ;
Query OK, 0 rows affected (0.00 sec)

mysql> set global innodb_flush_log_at_trx_commit=2;
Query OK, 0 rows affected (0.00 sec)

innodb_flush_log_at_trx_commit
如果innodb_flush_log_at_trx_commit设置为0，log buffer将每秒一次地写入log file中，并且log file的flush(刷到磁盘)操作同时进行.该模式下，在事务提交的时候，不会主动触发写入磁盘的操作。
如果innodb_flush_log_at_trx_commit设置为1，每次事务提交时MySQL都会把log buffer的数据写入log file，并且flush(刷到磁盘)中去.
如果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打开的

修改参数后，slave2,3也一样可以跟上slave1的速度了
slave2,3:
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
3 2 94 2 0 0| 32k 80k| 49k 10k| 0 0 |1042 658
3 2 94 1 0 1| 32k 72k| 49k 10k| 0 0 |1258 964
2 2 95 2 0 0| 32k 72k| 44k 9146B| 0 0 |1126 882
2 1 95 2 0 0| 32k 72k| 41k 8486B| 0 0 | 959 659
2 2 96 1 0 0| 32k 72k| 47k 9476B| 0 0 |1153 841
2 2 95 2 0 0| 24k 72k| 39k 8090B| 0 0 | 866 504
2 2 96 1 0 0| 24k 72k| 42k 7562B| 0 0 | 908 663
2 1 95 2 0 0| 40k 72k| 52k 10k| 0 0 |1084 685
3 1 94 2 0 1| 40k 80k| 54k 11k| 0 0 |1204 873
2 2 96 1 0 0| 16k 32k| 30k 6044B| 0 0 | 846 802
2 1 97 1 0 0| 24k 32k| 35k 7760B| 0 0 |1059 888
2 1 95 3 0 0| 32k 856k| 44k 9278B| 0 0 | 943 551
2 1 94 3 0 0| 32k 104k| 42k 8618B| 0 0 | 986 704
2 1 96 1 0 0| 24k 72k| 34k 7034B| 0 0 | 863 682
2 2 95 2 0 0| 32k 64k| 45k 8684B| 0 0 |1052 750
2 2 90 7 0 0| 24k 416k| 38k 7166B| 0 0 | 906 722
3 2 93 2 0 1| 32k 80k| 57k 10k| 0 0 |1069 829
3 2 94 1 0 0| 32k 72k| 42k 8486B| 0 0 |1076 942
2 1 96 1 0 0| 24k 72k| 37k 7496B| 0 0 | 859 575
2 2 94 2 0 1| 32k 64k| 43k 8684B| 0 0 |1138 1011
3 2 94 1 0 0| 32k 72k| 42k 9014B| 0 0 |1099 782
2 3 94 2 0 0| 32k 72k| 50k 10k| 0 0 |1332 1359
2 2 95 2 0 0| 24k 72k| 34k 6902B| 0 0 | 921 799
2 2 94 2 0 0| 40k 72k| 55k 11k| 0 0 |1318 1016
1 2 96 2 0 0| 32k 80k| 41k 8882B| 0 0 |1020 719
而且我观察到slave2,3的写入数量减少了两个数量级，从1M多下降到70k

优化mysql slave的同步速度的更多相关文章

  1. 从零到千万用户，我是如何一步步优化MySQL数据库的？

    写在前面 很多小伙伴留言说让我写一些工作过程中的真实案例,写些啥呢?想来想去,写一篇我在以前公司从零开始到用户超千万的数据库架构升级演变的过程吧. 本文记录了我之前初到一家创业公司,从零开始到用户超千 ...

  2. 简单的方式优化mysql

    参考博客 自己笔记本上向mysql导入txt数据,有一个table导入了将近4个小时,而且多个table之间都是相互之间存在关系的,所以做联合查询的时候你会发现问题会十分的多,我之前联合查询两个表就死 ...

  3. TCMalloc优化MySQL、Nginx内存管理

    TCMalloc的全称为Thread-Caching Malloc,是谷歌开发的开源工具google-perftools中的一个成员. 与标准的glibc库的Malloc相比,TCMalloc库在内存 ...

  4. 优化MySQL，还是使用缓存？读一篇文章有感

    今天我想对一个Greenfield项目上可以采用的各种性能优化策略作个对比.换言之,该项目没有之前决策强加给它的各种约束限制,也还没有被优化过. 具体来说,我想比较的两种优化策略是优化MySQL和缓存 ...

  5. 处理一则MySQL Slave环境出现ERROR 1201 (HY000): Could not initialize master info structure的案例

    mysql> start slave; ERROR (HY000): Slave failed to initialize relay log info structure from the r ...

  6. jemalloc优化MySQL、Nginx内存管理

    上一篇文章<TCMalloc优化MySQL.Nginx.Redis内存管理>,下面来看下jemalloc jemalloc源于Jason Evans 2006年在BSDcan confer ...

  7. TCMalloc优化MySQL、Nginx、Redis内存管理

    TCMalloc(Thread-Caching Malloc)与标准glibc库的malloc实现一样的功能,但是TCMalloc在效率和速度效率都比标准malloc高很多.TCMalloc是 goo ...

  8. Mysql slave 同步错误解决

    涉及知识点 mysql 主从同步 ,参考: MySQL数据库设置主从同步 mysqlbin log查看, 参考:MySQL的binlog日志 解决slave报错, 参考: Backup stopped ...

  9. MYSQL之性能优化 ----MySQL性能优化必备25条

    今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显.关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我 们程序员需要去关注的事情.当我们去设计数据库表结构,对操作数 ...

随机推荐

  1. db_recovery_file_dest_size 修改大一点及删除归档日志 |转|

    今天给客户测 试问题,让客户把数据发过来了.解压缩后一看,他们还是用的oracle 815版本的(他们exp导出时,带了导出日志,从导出日志中看出来是oracle 815版本的),不过没有关系,低版本 ...

  2. emacs之开始就加载tag

    ~/emacsConfig/original-tags.el (setq tags-table-list ' ( "~/emacsConfig/etags/muduo" " ...

  3. JVM内存管理之GC算法精解（五分钟让你彻底明白标记/清除算法）

    相信不少猿友看到标题就认为LZ是标题党了,不过既然您已经被LZ忽悠进来了,那就好好的享受一顿算法大餐吧.不过LZ丑话说前面哦,这篇文章应该能让各位彻底理解标记/清除算法,不过倘若各位猿友不能在五分钟内 ...

  4. Excel不同工作簿之间提取信息

    Sub 不同工作簿间提取信息() '用于单个字段信息的提取: Dim w As Workbook, wb1 As Workbook, wb2 As Workbook, wb3 As Workbook ...

  5. Hadoop单机环境搭建整体流程

    1.   Ubuntu环境安装和基本配置 本例程中在MAC上安装使用的虚拟机Ubuntu系统(64位,desktop): 基本配置 考虑到以后涉及到hadoop的应用便于权限的管理,特别地创建一个ha ...

  6. 业务SQL优化

    1,个人开户报表统计 优化前语句,执行时间80多秒 SELECT a.DA AS f_da, a.account_name AS f_account_name, a.sex AS f_sex, a.n ...

  7. STL sort

    STL的sort()算法,数据量大时采用Quick Sort,分段递归排序,一旦分段后的数据量小于某个门槛,为避免Quick Sort的递归调用带来过大的额外负荷,就改用Insertion Sort. ...

  8. sqlldr加载 数据文件的字段超出最大长度

    SQLLOAD数据的时候,建表给的字段给够了,建表已经给到VHARCHAR2(1024)了,实际数据是VHARCHAR2(256).加载报错"数据文件的字段超出最大长度"查了半天, ...

  9. 2_python之路之多级菜单

    python之路之多级菜单 1.使用知识点 (1)列表,字典的使用 (2)if条件判断语句 (3)for/while循环的使用 2.代码详细 #!/usr/bin/env python # _*_ c ...

  10. python‘s second day for me

    in     not in 主要用来检测一些字符串是否存在,或者避免一些字符串 while True: comment = input('请输入你的评论') if '顾清秋' in comment: ...