您的位置:首页 > 数据库 > MySQL

mysql之mysqldump备份恢复

2015-11-08 16:22 489 查看
mysql数据备份,其重要性不言而喻。大体上我们比较常用到的有mysqldump、Xtrabackup和用lvm快照来备份,或者是有专门的mysql复制备份服务器。

特性:

逻辑备份工具,比物理备份速度慢,但更灵活,可以修改一些信息,而且跨平台也简单。
如果数据量大于1G最好还是用物理备份。
单线程的备份工具,网上有一个多线程逻辑备份工具,叫做mysqldumper,有兴趣的朋友可以看看。
可以实现Innodb存储引擎的热备或MyISAM、Aria的温备。
自身不能实现增量或是差异备份,如果备份的是全部的库可以用备份二进制日志文件的方式来实现。
相当于是mysql的客户端,只要能够连到服务器就可以远程备份。

备份用户要有以下权限:

SELECT, RELOAD, SUPER, REPLICATION CLIENT

命令使用和常用选项:
mysqldump [options] [db_name [tbl_name ...]]

-A, --all-databases备份所有库。
-B, --databases指定要备份的库。
-F, --flush-logs滚动二进制日志。更容易记录备份时二进制日志的位置。
-x, --lock-all-tables
锁定所有表。读锁。用于温备。用于不支持事务的存储引擎。
--single-transaction创建一个大事务,以用于热备。只能用于事务存储引擎,如InnoDB。
--master-data[0|1|2]同步二进制日志位置标记。0: 不记录,1:记录CHANGE MASTER语句
2:记录为注释的CHANGE MASTER语句

备份代码:
--events: 备份事件调度器代码
--routines: 备份存储过程和存储函数
--triggers:备份触发器

备份:
添加备份用户:

MariaDB [(none)]> GRANT SELECT, RELOAD, SUPER, REPLICATION CLIENT ON *.* TO 'backup'@'localhost' IDENTIFIED BY 'abcd1234';
Query OK, 0 rows affected (0.00 sec)


如我这里备份hellodb的库:
[root@nfs binlogs]# mysqldump -ubackup -p  --lock-all-tables --flush-logs --master-data=2 --all-databases >  /backup/`date +%Y%m%d_%H:%M`.full.sql
[root@nfs backup]# cd /backup
[root@nfs backup]# ls
20151107_22:29.full.sql
这个命令是直接输出到屏幕的,所以需要重定向到文件才行。

用head -n 30来查看备份文件,可以看到:
-- CHANGE MASTER TO MASTER_LOG_FILE='master-bin.000017', MASTER_LOG_POS=245;
这个就是由--master-data=2添加的信息,说明备份表的时候的二进制日志文件的位置。
这是一个新的二进制日志文件,是--flush-log的功能。这样在恢复或做二进制日志的增量备份也容易些。
因为有的的表是MyISAM的,所以用了--lock-all-tables做的锁定,实现温备。 如果备份单个库,表都是InnoDB的可以换成--single-transaction来生成大事务做热备。

注意用head或其它命令来查看一下文件是否是备份文件,万一是报错信息就哭了。

增量备份: 会了防止二进制日志的损坏。

因为二进制日志文件是全局的,所以如果备份了全部的库,可以用这个办法。如果有多个库而只备份了一个库或是只备份了一个表。那就麻烦了,一般来说最好不要这么干。
备份:

假如:因为数据的修改,000017日志里面有了很多信息,这时想做个增量备份的话,就可以直接FLUSH LOGS,来滚动日志。然后把原来的日志内容复制出去。

MariaDB [hellodb]> SHOW MASTER STATUS;        #查看当前使用的日志是否还是000017。
+-------------------+----------+--------------+------------------+
| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+------------------+
| master-bin.000017 |     8012 |              |                  |
+-------------------+----------+--------------+------------------+
1 row in set (0.00 sec)    #如果日志不是000017,那就要复制17到现在这个日志文件了。

MariaDB [hellodb]> FLUSH LOGS;
Query OK, 0 rows affected (0.01 sec)

MariaDB [hellodb]> SHOW MASTER STATUS;    #一定要做好所使用的日志的记录
+-------------------+----------+--------------+------------------+
| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+------------------+
| master-bin.000018 |      245 |              |                  |
+-------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

MariaDB [hellodb]>
发现使用的日志文件已经变了。这时我们就可以用mysqlbinlog来把日志文件的内容给复制出去了。
因为二进制日志文件是二进制的,要用这个命令才能打开日志。
[root@nfs binlogs]# ls        #二进制日志文件的目录
master-bin.000001  master-bin.000004  master-bin.000007  master-bin.000010  master-bin.000013  master-bin.000016  master-bin.index
master-bin.000002  master-bin.000005  master-bin.000008  master-bin.000011  master-bin.000014  master-bin.000017
master-bin.000003  master-bin.000006  master-bin.000009  master-bin.000012  master-bin.000015  master-bin.000018
[root@nfs binlogs]# mysqlbinlog --start-position=245 master-bin.000017 > /backup/`date +%Y%m%d_%H:%M`.1.sql
[root@nfs binlogs]# cd /backup
[root@nfs backup]# ls
20151107_22:29.full.sql  20151107_22:52.1.sql


恢复:
1、关闭sql_log_bin会话变量,暂时停止二进制日志的定入。恢复过程中的修改语句就不要写入日志了。
2、恢复完全备份。
3、恢复增量备份(没有增量备份就是完全备份之后的所有二进制日志了)
MariaDB [hellodb]> SET sql_log_bin=0;
Query OK, 0 rows affected (0.00 sec)
MariaDB [hellodb]> source /backup/20151107_22:29.full.sql
MariaDB [hellodb]> source /backup/20151107_22:52.1.sql
MariaDB [hellodb]> SET sql_log_bin=1;
做及时点回原就再把增量备份之后的二进制日志文件恢复一下就可以了。用mysqldump做备份再做增量太麻烦了。一般如果二进制日志所在磁盘的安全性高也就不用做增量了,到时候再直接恢复二进制日志也一样。而且如果数据量大也就不用mysqldump备份了。

这二天上火,嘴角干裂加口腔溃疡,一冷鼻炎还犯了。我的天啊。


本文出自 “大蕃茄” 博客,请务必保留此出处http://fanqie.blog.51cto.com/9382669/1710719
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: