基于mysql5.6实现的同城多IDC间的mysql部分库表数据复制方案

近期刚刚实施了一套同城多IDC间的mysql主从同步方案，主要功能是实现的一主多从数据复制，但真正实施起来确又并不是如此简单。

最主要的制约因素无外乎就是通信带宽和数据量负载大小。
方案实施的背景：

4个集群的IDC机房间通过20Mb专线相互连通；
选取IDC A的mysql数据库作为master；
该master角色的mysql数据库，会有一部分表的数据量异常大，单表过亿；
该master数据库的binlog日志量平均每天60GB；
数据同步使用需求是，只需对数据库中的部分库表做同步即可，这部分小表的数据量分别在个位数到百万之间；
业务使用需求是，主从之间数据同步，同步延时只要控制在2分钟以内，就可以满足上层的业务使用需求。

基于以上情况的分析：
专线带宽有限，不可能复制全部库表数据，也不可能达到实时复制；
IDC间有库表复制需求的表只是一部分，这些表的存量数据在几条到一百万条之间；
复制策略设计为mysql master-->middle slave-->slave，master和middle slave位于同一IDC机房私网内；
第一阶段mysql主从，用于实现从全部库表中过滤出需要使用的部分表；
第二阶段mysql middle alve -->slave，用于实现指定的表在集群间的数据复制；

一、IDC内部mysql部分表主-从复制
IDC A mysql ha 双机部署在server1和server2上面，使用共享存储，双机软件为heartbeat。主、备机的硬件配置相同。对外服务使用的vip。在该方案 中，正常情况下mysql服务运行在主机上，而备机server2一直处在热备待机状态，资源大部分时间内是没有被利用到的。

这次我们把mysql从部署在数据库备机server2上面。因为在mysql ha进行主备切换时，要使用备机上的mysql用户、3306端口以及其它资源文件，所以在新增一个mysql实例作为slave时，需要完全得避开与这些资源的使用冲突。

1、mysql从的数据复制策略说明：
为减少对应用程序层面的干扰，暂不考虑在mysql主机上进行分库处理，因此也就无法使用binlog-do-db功能来控制仅复制指定的数据库（比如把待复制的表放入一个新的库中，然后基于这个库进行mysql主从间的数据复制）。

注：使用binlog-do-db参数并不安全，因为它会仅让指定的库打印binlog日志。这在发生意外故障，就无法满足进行全部库的日志回滚的要求了。

我 们选择使用在mysql从上通过Replicate-do-table功能，来控制哪些表的数据会被写入到mysql slave的数据库中，而这一操作的背景条件是在mysql主、从之间是进行的全部的数据库表复制（仅在从机上决定写入数据库时再按表做判断和过滤操 作）。

这个数据复制操作，是在IDC A局域网内主、备机网卡2通过网线直接，使用mysql主从复制功能中的mysql IO thread进行。主机的网卡1是用于业务生产使用。

每 天的binlog日志数据量大约有60GB，这些全部要复制到从机。从机只有先把binlog复制过来后，才能根据表过滤规则判断是否需要入库。从机会把 复制来的binlog存放在relaylog中，从中仅过滤出与过滤条件相符的库表事件，然后执行并记录到自己的binlog中。

通过以上设计， 在IDC A的mysql slave上只保留了我们需要在IDC间进行数据复制的那些小表，slave本身基于这些小表而产生的binlog日志量成功降低到每天100MB。通过 IDC间的专线，甚至是直接使用互联网带宽实施IDC间的这部分数据表的数据复制同步，可行性都是很高的。

mysql间的主从复制本来就是异步的，任何形式的实时热备的要求，都是在耍流氓。不同的技术满足不同的场景，绝大数企业是承受不了同城热备的成本的。

2、mysql从的部署信息说明：
安装目录：/data/mysql-middle-slave/mysql
数据目录：/data/mysql-middle-slave/mysql_datadir
sock文件：/data/mysql-middle-slave/mysql.sock
pid文件：  /data/mysql-middle-slave/mysql_datadir/server2_HA.pid
配置文件：/data/mysql-middle-slave/mysql_conf/my.cnf
监听端口：9000
错误日志：/var/log/mysqld-slave.log
启动脚本：/etc/init.d/mysqld-slave  可以使用service mysqld-slave  start/stop/restart管理
在server2本机登录middle-slave的mysql方法：mysql --port=9000--socket=/data/mysql-middle-slave/mysql.sock -uroot -p

3、mysql主从复制使用的网段
在IDC A的mysql主、备HA双机之间是通过主机的网卡2传输的双机心跳监测数据。网卡1是对外提供mysql服务的网卡，目前平均流量在100Mbps。
为减少对生产环境的影响，我们使用网卡2作为mysql主从间数据复制使用的网卡。主机为10.0.0.1，备机为10.0.0.2 。

4、主从部分表数据复制方案实施步骤
（1）在主机上执行授权配置
设置mysql数据复制账户
mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'10.0.0.2' IDENTIFIED BY 'repl';
mysql> flush privileges;
在mysql主机上对slave开放3306端口的授权
ACCEPT     tcp  --  10.0.0.2             0.0.0.0/0           state NEW tcp dpt:3306

（2）从库配置my.cnf
server-id = 2
log-bin=/data/mysql-middle-slave/mysql_datadir/mysql-bin
binlog_format=mixed
binlog_cache_size = 4M
max_binlog_size = 1024M
expire-logs-days = 10
slow_query_log = 0
long_query_time = 10
log-error = /var/log/mysqld-slave.log
slave-skip-errors = all
log_slave_updates = 1
skip-slave-start

#mysql replication policy

replicate_wild_do_table=mydatabase.code
replicate_wild_do_table=mydatabase.info
replicate_wild_do_table=mydatabase.location
replicate_wild_do_table=mydatabase.controller
replicate_wild_do_table=mydatabase.user_level
replicate_wild_do_table=mydatabase.check_type
replicate_wild_do_table=mydatabase.code_price
replicate_wild_do_table=mydatabase.service_info
replicate_wild_do_table=mydatabase.user_param
replicate_wild_do_table=mydatabase.method_info
replicate_wild_do_table=mydatabase.thread_code

（3）从主库导出一份数据快照
使用mysqldump来得到一个数据快照可分为以下几步：
因为主库设置的是transaction_isolation = REPEATABLE-READ，所以支持以下方法导出一致性的数据。仅导出需要实现主从复制的表。
mysqldump -uroot -p --single_transaction --master-data=2 mydatabase  code info location controller user_level check_type code_price service_info user_param method_info thread_code > master_partial.sql

（4）拷贝备份数据至从库并导入
先确认从库上已经按正确字符集要求创建了数据库，再执行数据导入。
CREATE DATABASE `mydatabase` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

mysql --port=9000 --socket=/data/mysql-middle-slave/mysql.sock -uroot -p mydatabase < master_partial.sql

（5）在备份文件master_partial.sql查看binlog和pos值

head -25 master_partial.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=122; #举例，大概22行

（6）从库设置从这个日志点同步并启动

mysql> change master to master_host='10.0.0.1',
  -> master_user='repl',
  -> master_password='repl',
  -> master_port=3306,
  -> master_log_file='mysql-bin.000001',
  -> master_log_pos=122;

mysql> start slave;

mysql> show slave status\G;

观察mysql主从同步线程的状态。

如果因故需要暂停主从复制，可以从机上执行：mysql>stop slave;

mysql从上的数据复制功能在重启mysqld服务后，需要手工登录mysql，并执行start slave进行开启。

（7）临时中止与恢复主从数据复制
从mysql5.6版本开始，在mysql slave上执行了stop slave命令后，虽然中止了主从间的数据复制服务，但主从复制的配置信息仍然会被保存在缓存中。所以如果此时继续执行start slave命令，则会正常得继续前面中断的主从复制工作。
如果在执行了stop slave命令后，又重启了mysql slave的服务，那么就需要重新做一遍主、从间数据复制的配置了。先前的主从配置信息，在重启后不复存在。

（8）主从间数据库表状态不一致时的处理办法
可以有各种情况会造成mysql slave的库表数据状态与master不一致。
这时可以先停止主从复制：在从机上登录mysql并执行stop slave；
在mysql从上执行reset slave；
重新按前面的操作方法，从master上导出一份库表数据并传输到从机上，导入mysql从；
在mysql从上，根据上一步中得到的备份文件大约第25行注明的master binlog信息，重新设置change master to主从复制配置；
在mysql从上，执行start slave，重新开启主从复制；
使用show slave status\G查看主从复制状态；

注： 在执行reset slave命令时，mysql slave会清除本地的一些日志文件（it clears the master info and relay log info repositories, deletes all the relay log files, and starts a new relay log file ）。

（9）怎么在现有的库表之外，按需增减主从间进行数据复制的表
停从机的mysql数据复制服务，stop slave，reset slave；
修改从机的my.cnf文件，更新要过滤的库表信息；
重启从机的mysqld服务；
重新配置主、从间的数据同步、主从复制；

二、IDC间的mysql数据复制
按照 mysql master-->middle slave-->slave的实施策略，其它3个IDC的mysql都去和IDC A的mysql slave进行数据复制同步。
需要明确的是其它3个IDC的mysql都并不是一个空的数据库，而是原本就和IDC A的库表结构、规模相同、相当的。我们在实施另外3个IDC mysql与IDC A的mysql slave进行数据复制时，仍然需要使用Replicate-do-table功能来设置过滤条件，仅允许指定的部分表可以同步数据。
与此同时，其它3个IDC的数据库中未参与到主从复制中的那些库表，仍然需要继续被自己集群内的业务应用进行读、写。

这里就不再重复主从配置方法了，请参照前面即可。该方案实施后，在现有网络条件下、现有数据量条件下，运行良好。

在对以上方案进行反复测试的过程中，我也发现mysql服务并不会去检查slave上表的数据是否真得与master上在各个方面都是完全一致的。你完全可以在不影响到主从复制间发生表主键冲突的条件下，向slave上的表中插入数据。
而且，在仅同步mysql主从间的一部分表的条件下，无论是master上还是slave上的那些没参与到主从数据复制任务中的库表，仍然可以像往常一样得读写，而不会相互影响或制约。