mysql限流_mysql binlog限流问题总结

业务场景：

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

+

a. SOL_SOCKET级别对应的应用层所设置的缓冲区大小

b. IPPROTO_TCP级别对应的传输层设置的拥塞窗口大小

stackovreflow上有人遇到利用setsocketopt设置SOL_SOCKET级别的SO_RCVBUF但无效果的问题。解决方法为同时设置SOL_SOCKET级别的TCP_WINDOW_CLAMP。(注：TCP_WINDOW_CLAMP应该属于IPPROTO_TCP级别)

3) 至少设置备库才有效，从2048到UINT_MAX(2*1024*1024)，检测主库网卡流出/备库网卡流入从4.8M 到 15.4M。

4) 需要注意的是，此参数是在连接建立之前设置，更改此参数需要重启主备之间的复制。

从运维角度看，动态设置某个比较接近‘0’的时间，但主备复制延时低于此值后，复制不再受此限流的影响。

3.考虑到瓶颈在网络带宽和磁盘I/O上，可以改进架构，改为slave级联的架构，但是维护的成本会相应增加，需要权衡场景。

4.考虑使用SSD