mydumper对MySQL部分数据库进行热备

 

Mydumper介绍
Mydumper是一个针对MySQL和Drizzle的高性能多线程备份和恢复工具。开发人员主要来自MySQL,Facebook,SkySQL公司。目前已经在一些线上使用了Mydumper。
Mydumper主要特性：
  • 轻量级C语言写的
  • 执行速度比mysqldump快10倍
  • 事务性和非事务性表一致的快照(适用于0.2.2以上版本)
  • 快速的文件压缩
  • 支持导出binlog
  • 多线程恢复(适用于0.2.1以上版本)
  • 以守护进程的工作方式，定时快照和连续二进制日志(适用于0.5.0以上版本)
  • 开源 (GNU GPLv3)
Mydumper安装
# yum install glib2-devel mysql-devel zlib-devel pcre-devel # wget http://launchpad.net/mydumper/0.5/0.5.1/+download/mydumper-0.5.1.tar.gz # tar zxvf mydumper-0.5.1.tar.gz -C ../software/ # cmake . # make # make install
1
2
3
4
5
6		 # yum install glib2-devel mysql-devel zlib-devel pcre-devel
# wget http://launchpad.net/mydumper/0.5/0.5.1/+download/mydumper-0.5.1.tar.gz
# tar zxvf mydumper-0.5.1.tar.gz -C ../software/
# cmake .
# make
# make install
mydumper参数介绍：
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83		 -B, --database 需要备份的库

-T, --tables-list 需要备份的表，用，分隔

-o, --outputdir 输出目录

-s, --statement-size Attempted size of INSERT statement in bytes, default 1000000

-r, --rows 试图分裂成很多行块表

-c, --compress 压缩输出文件

-e, --build-empty-files 即使表没有数据，还是产生一个空文件

-x, --regex 支持正则表达式

-i, --ignore-engines 忽略的存储引擎，用，分隔

-m, --no-schemas 不导出表结构

-k, --no-locks 不执行临时共享读锁 警告：这将导致不一致的备份

-l, --long-query-guard 长查询，默认60s

--kill-long-queries kill掉长时间执行的查询(instead of aborting)

-b, --binlogs 导出binlog

-D, --daemon 启用守护进程模式

-I, --snapshot-interval dump快照间隔时间，默认60s，需要在daemon模式下

-L, --logfile 日志文件

-h, --host

-u, --user

-p, --password

-P, --port

-S, --socket

-t, --threads 使用的线程数，默认4

-C, --compress-protocol 在mysql连接上使用压缩

-V, --version

-v, --verbose 更多输出, 0 = silent, 1 = errors, 2 = warnings, 3 = info, default 2

myloader参数介绍：

-d, --directory 导入备份目录

-q, --queries-per-transaction 每次执行的查询数量, 默认1000

-o, --overwrite-tables 如果表存在删除表

-B, --database 需要还原的库

-e, --enable-binlog 启用二进制恢复数据

-h, --host

-u, --user

-p, --password

-P, --port

-S, --socket

-t, --threads 使用的线程数量，默认4

-C, --compress-protocol 连接上使用压缩

-V, --version

-v, --verbose 更多输出, 0 = silent, 1 = errors, 2 = warnings, 3 = info, default 2

mydumper输出文件：
metadata:元数据 记录备份开始和结束时间，以及binlog日志文件位置。 table data:每个表一个文件 table schemas:表结构文件 binary logs: 启用--binlogs选项后，二进制文件存放在binlog_snapshot目录下 daemon mode:在这个模式下，有五个目录0，1，binlogs，binlog_snapshot，last_dump。 备份目录是0和1，间隔备份，如果mydumper因某种原因失败而仍然有一个好的快照， 当快照完成后，last_dump指向该备份。
1
2
3
4
5
6
7		 metadata:元数据 记录备份开始和结束时间，以及binlog日志文件位置。
table data:每个表一个文件
table schemas:表结构文件
binary logs: 启用--binlogs选项后，二进制文件存放在binlog_snapshot目录下
daemon mode:在这个模式下，有五个目录0，1，binlogs，binlog_snapshot，last_dump。
备份目录是0和1，间隔备份，如果mydumper因某种原因失败而仍然有一个好的快照，
当快照完成后，last_dump指向该备份。
mydumper用例
 
1
2
3
4
5
6
7
8
9
10
11		 # mydumper -B ttlsa_com -o /home/data/bak -b
# ls
binlog_snapshot metadata ttlsa_com.my_area-schema.sql ttlsa_com.my_area.sql
# cat metadata
Started dump at: 2012-02-20 11:40:21
SHOW MASTER STATUS:
Log: mysqld-bin.000001
Pos: 191363
Finished dump at: 2012-02-20 11:40:22
# mydumper -B ttlsa_com -o /home/data/bak -b -D --snapshot-interval=30
# myloader -d /home/data/bak/last_dump -o -B ttlsa_com //还原
 
现有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;"

 

 
 
posted @ 2017-09-21 13:49  chenghuan  阅读(528)  评论(0)    收藏  举报