业务场景:
新建slave连到master,执行start slave时master险些被“搞死”。
分析:新建slave连到master时,会将主库上大量的binlog(几百G)拉取到本地保存为relay log,会导致两个问题
1、主库网络带宽被占满 。
2、主库的磁盘I/O负载很高。
解决思路:
1. 在slave拉取master的binlog时,在I/O thread上做限流:每拉取一定数据量master的binlog则sleep时间N。
这个测试效果比较明显,但存在如下几个问题:
1) 参数比较难控制,需要DBA根据实际场景调整来获得预期的网络流量,这个过程可能需要多次尝试才可能获取到预期行为
2) 存在抖动,在sleep时刻明显能观察到不均匀的网络流量
2. 在socket的选型上做改进
1) 对主备库的IO线程使用的连接都设置socket属性。
2) 灵感来自facebook mysql中引入的rpl_send_buffer_size参数:对主库的dump线程增加SNDBUF参数控制以优化主库发送的速度。
NET* net = &thd->net; + if (rpl_send_buffer_size && + (setsockopt(net->vio->mysql_socket.fd, SOL_SOCKET, SO_SNDBUF, + &rpl_send_buffer_size, sizeof(rpl_send_buffer_size)) == -1 || + setsockopt(net->vio->mysql_socket.fd, IPPROTO_TCP, TCP_WINDOW_CLAMP, + &rpl_send_buffer_size, sizeof(rpl_send_buffer_size)) == -1)) + sql_print_warning(“Failed to set SO_SNDBUF with (error: %s).”, + strerror(errno)); +
完整补丁参考 https://github.com/facebook/mysql-5.6/commit/d3b0c7814090bded6563fee7d46d2ae41ed32a60
其中,主库的dump线程连接描述符NET的设置有两点:
a. SOL_SOCKET级别对应的应用层所设置的缓冲区大小
b. IPPROTO_TCP级别对应的传输层设置的拥塞窗口大小
stackovreflow上有人遇到利用setsocketopt设置SOL_SOCKET级别的SO_RCVBUF但无效果的问题。解决方法为同时设置SOL_SOCKET级别的TCP_WINDOW_CLAMP。(注:TCP_WINDOW_CLAMP应该属于IPPROTO_TCP级别)
http://stackoverflow.com/questions/2223825/setting-tcp-receive-window-in-c-and-working-with-tcpdump-in-linux
http://linux.die.net/man/7/tcp
3) 至少设置备库才有效,从2048到UINT_MAX(2*1024*1024),检测主库网卡流出/备库网卡流入从4.8M 到 15.4M。
4) 需要注意的是,此参数是在连接建立之前设置,更改此参数需要重启主备之间的复制。
从运维角度看,动态设置某个比较接近‘0’的时间,但主备复制延时低于此值后,复制不再受此限流的影响。
3.考虑到瓶颈在网络带宽和磁盘I/O上,可以改进架构,改为slave级联的架构,但是维护的成本会相应增加,需要权衡场景。
4.考虑使用SSD
本文出自 “老徐的私房菜” 博客,请务必保留此出处http://laoxu.blog.51cto.com/4120547/1413257
mysql binlog限流问题总结,布布扣,bubuko.com
原文:http://laoxu.blog.51cto.com/4120547/1413257