现有2台DB服务器,分别用于A业务与B业务,其中A业务比较重要,需要对A业务的1个DB(TaeOss)进行热备,大概有40G的数据,并用业务B的DB服务器作为备机,服务器分布如下: 10.137.143.151 A业务 10.137.143.152 B业务 开发那边的要求是: 在导出A业务的DB(TaeOss)时,不能对A业务有影响。同时在B业务的DB服务器上进行恢复时,也不能有较大影响,尽量控制在1分钟以内。 采取的方案: 1、mysqldump:属于逻辑备份,会存在锁表,但考虑到数据量比较大,锁表的时间会比较长,业务不允许,pass掉; 2、xtrabackup:属于物理备份,不存在锁表,但考虑到2台DB使用的都是共享表空间,同时在业务B的数据库进行恢复时,一是时间比较长,二是数据肯定不正确,pass掉(测试过); 3、mydumper:属于逻辑备份,是一个多线程、高性能的数据逻辑备份、恢复的工具,且锁表的时间很短(40G数据,10分钟以内),同时会记录binlog file和pos,业务可以接受。 mydumper主要有如下特性: (1)、任务速度要比mysqldump快6倍以上; (2)、事务性和非事务性表一致的快照(适用于0.2.2以上版本); (3)、快速的文件压缩; (4)、支持导出binlog; (5)、多线程恢复(适用于0.2.1以上版本); (6)、以守护进程的工作方式,定时快照和连续二进制日志(适用于0.5.0以上版本)。 mydumper安装: # yum install glib2-devel mysql-devel zlib-devel pcre-devel # tar zxvf mydumper-0.6.2.tar.gz # cd mydumper-0.6.2 # cmake . # make # make install 参数如下:
由于DB是部署在比较老的SuSE Linux 10服务器上,安装mydumper时依赖的库比较多,会比较繁琐,同时采用本地备份的话,也会占用大量的磁盘I/O,所以我们选择在同网段的另一台centos 6.4(10.137.143.156)服务器进行备份。 步骤如下: 1、在“10.137.143.151、10.137.143.152”上对“10.137.143.156”进行临时授权 # mysql -uroot -e "grant all privileges on *.* to 'backup'@'10.137.143.156' identified by 'backup2015';" # mysql -uroot -e "flush privileges;" 2、在“10.137.143.156”上对“10.137.143.151”的DB(TaeOss)进行备份 # mydumper -h 10.137.143.151 -u backup -p backup2015 -B TaeOss -t 8 -o /data/rocketzhang 3、将备份数据恢复到“10.137.143.152” # myloader -h 10.137.143.152 -u backup -p backup2015 -B TaeOss -t 8 -o -d /data/rocketzhang 4、主从关系建立:10.137.143.151(主)、10.137.143.152(从) 在“10.137.143.151”建立授权账号: # mysql -uroot -e "grant replication slave on *.* to 'repl'@'10.137.143.152' identified by 'repl123456';" # mysql -uroot -e "flush privileges;" 在“10.137.143.156”查看记录下的binlog信息:
在“10.137.143.152”如下操作: # vim /etc/my.cnf …… replicate-do-table = TaeOss.% replicate-wild-do-table = TaeOss.% …… # service mysqld reload # mysql -uroot -e "change master to master_host='10.137.143.151',master_user='repl',master_password='repl123456',master_log_file='mysql-bin.002205',master_log_pos=456584891;" # mysql -uroot -e "start slave;" # mysql -uroot -e "show slave status\G;" 出现如下信息:
看来是存在主键冲突,导致主从复制失败。 问题分析: 在主DB(10.137.143.151)上执行: # mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS mysql-bin.002205 > mysql-bin.002205.txt # grep -C 8 529864938 mysql-bin.002205.txt
大概的意思是,在主DB上存在对t_evil_detect_uin_blacklist表的insert操作时,发生了主键冲突,当在从端进行同步的时候,也出现了主键冲突,从而导致主从同步失败。 临时的解决办法: 导出从端的表TaeOss.t_evil_detect_uin_blacklist # mysqldump -uroot --opt TaeOss t_evil_detect_uin_blacklist > TaeOss.t_evil_detect_uin_blacklist.sql 去掉TaeOss.t_evil_detect_uin_blacklist.sql其中的主键语句:
然后再导入: # mysql -uroot TaeOss < TaeOss.t_evil_detect_uin_blacklist.sql # mysql -uroot -e "stop slave;" # mysql -uroot -e "start slave;" # mysql -uroot -e "show slave status\G;"
|