mysql binlog限流问题总结_MySQL

问题背景：

新建备库级联到主库会将主库上大量的binlog拉到本地保存为relaylog，这个阶段会导致主库网络流量非常大，从而引发主库的查询更新等受到影响。

解决思路：

1. 在备库拉主库binlog的IO线程上做限流：每拉一定数据量M的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://*.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’的时间，但主备复制延时低于此值后，复制不再受此限流的影响。