MySQL的主从复制,实际上就是Master记录自己的执行日志binlog,然后发送给Slave,Slave解析日志并执行,来实现数据复制 对于复制效率,binlog的大小是非常重要的因素,因为它涉及了I/O和网络传输 主从复制涉及到了两端:master/slave,看下这两端可以如何优化 (1)master 端 master端有2个参数可以控制 Binlog_Do_DB : 设定哪些数据库需要记录Binlog Binlog_Ignore_DB : 设定哪些数据库不要记录Binlog 这两项很重要,指定必要数据库,忽略不需要复制的数据库,可以减少binlog的大小,提高了I/O效率,加快网络传输 但这两项也同样比较危险,需要谨慎使用,因为可能会有主从数据不一致和复制出错的风险 因为MySQL判断是否须要复制某个Event,不是根据产生该Event的语句所在的数据库,而是根据执行时所在的默认数据库,也就是登录时指定的数据库,或运行“USE DATABASE”中所指定的数据库 如果执行语句中明确指定了数据库名称,而这个数据库是被指定不记录Binlog的,那么这个语句在slave中执行时就会出错 例如 garbage 库是被指定不记录日志的 product 库是指定要记录日志的 执行下面的语句 use product; delete from garbage.junk; delete语句会被发送给slave,但slave中没有garbage库,所以执行时报错,复制失败 (2)slave 端 slave端有6个参数可以控制 Replicate_Do_DB : 设定须要复制的数据库,多个DB用逗号分隔 Replicate_Ignore_DB : 设定可以忽略的数据库 Replicate_Do_Table : 设定须要复制的Table Replicate_Ignore_Table : 设定可以忽略的Table Replicate_Wild_Do_Table : 功能同Replicate_Do_Table,但可以带通配符来进行设置 Replicate_Wild_Ignore_Table : 功能同Replicate_Ig-nore_Table,可带通配符设置 slave端的配置优化效果要明显小于master端的,因为master端日志都写完了,日志也传过来了 但这几个参数可以帮助我们减少日志的应用量,因为设置了过滤,实际写入的sql数量变少了,slave端的复制也就加快了