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)); +
完整补丁参考 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