mysql binlog限流问题总结

标签：facebook   sleep   mysql   流量   

业务场景：

新建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

mysql binlog限流问题总结

标签：facebook   sleep   mysql   流量   

原文地址：http://laoxu.blog.51cto.com/4120547/1413257