DBA 必知的 MYSQL 备份与还原方法

sdchy

一mysqldump 备份结合 binlog 日志恢复
　　说明：MySQL 备份一般采取全库备份加日志备份的方式，例如每天执行一次全备份，每小时执行一次二进制日志备份。这样在 MySQL 故障后可以使用全备份和日志备份将数据恢复到最后一个二进制日志备份前的任意位置或时间。
　　Binlog 功能默认是关闭的，没有开启。
　　查看 binlog，用 mysqlbinlog -v mysql-bin.000001
　　主从同步
　　恢复数据库
　　开启 binary log 功能：通过编辑 my.cnf 中的 log-bin 选项可以开启二进制日志；形式如右：log-bin[=DIR/[filename]] ，注释：每次重启 mysql 服务或运行 mysql> flush logs;都会生成一个新的二进制日志文件，这些日志文件的 number 会不断地递增，除了生成上述的文件外还会生成一个名为 filename.index 的文件。这个文件中存储所有二进制日志文件的清单又称为二进制文件的索引。

　　说明：bin-log 因为是二进制文件，不能通过文件内容查看命令直接打开查看，mysql 提供两种方式查看方式。

　　查看指定的二进制日志中的事件：

　　该命令还包含其他选项以便灵活查看：

　　总结：上述方式可以查看到服务器上存在的二进制日志文件及文件中的事件，但是想查看到文件中具体的内容并应于恢复场景还得借助 mysqlbinlog 这个工具。
　　语法格式：mysqlbinlog [options] log_file ...
　　输出内容会因日志文件的格式以及 mysqlbinlog 工具使用的选项不同而略不同。
　　mysqlbinlog 的可用选项可参考 man 手册。

　　说明：无论是本地二进制日志文件还是远程服务器上的二进制日志文件，无论是行模式、语句模式还是混合模式的二进制日志文件，被 mysqlbinlog 工具解析后都可直接应用与MySQL Server 进行基于时间点、位置或数据库的恢复。
　　下面我们就来演示如何使用 binlog 恢复之前删除数据（id=2那条记录）
　　注意：在实际生产环境中，如果遇到需要恢复数据库的情况，不要让用户能访问到数据库，以避免新的数据插入进来，以及在主从的环境下，关闭主从。

　　delete from bdqn.test where>　　# cd/usr/local/mysql/data/
　　# mysqlbinlog -v mysql-bin.000002
　　显示结果如下：（复制的日志）
　　# at 219

　　#170316 21:52:28 server>　　SET TIMESTAMP=1489672348/*!*/;
　　SET @@session.pseudo_thread_id=2/*!*/;
　　SET @@session.foreign_key_checks=1,@@session.sql_auto_is_null=0, @@session.unique_checks=1,@@session.autocommit=1/*!*/;
　　SET @@session.sql_mode=1075838976/*!*/;
　　SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
　　/*!\C utf8 *//*!*/;
　　SET@@session.character_set_client=33,@@session.collation_connection=33,
　　@@session.collation_server=33/*!*/;
　　SET @@session.lc_time_names=0/*!*/;
　　SET @@session.collation_database=DEFAULT/*!*/;
　　BEGIN
　　/*!*/;
　　# at 287

　　#170316 21:52:28 server>　　# at 337

　　#170316 21:52:28 server>　　BINLOG '
　　nJjKWBMBAAAAMgAAAFEBAAAAAGwAAAAAAAEABGJkcW4ABHRlc3QAAgMPAjwAAkNzPjQ
　　=nJjKWCABAAAALQAAAH4BAAAAAGwAAAAAAAEAAgAC//wCAAAABGxpc2kNztGj
　　'/*!*/;
　　### DELETE FROM `bdqn`.`test`
　　### WHERE
　　### @1=2
　　### @2='lisi'
　　# at 382

　　#170316 21:52:28 server>　　COMMIT/*!*/;
　　说明：可以从上图可以看出来 delete 时间发生 position 是 287，事件结束 position 是413。
　　②恢复流程：直接用 bin-log 日志将数据库恢复到删除位置 287 前,然后跳过故障点,再进行恢复下面所有的操作,命令如下
　　由于之前没有做过全库备份，所以要使用所有 binlog 日志恢复，所以生产环境中需要很长时间恢复，导出相关 binlog 文件。
　　③删除 bdqn 数据库（删除 bdqn 和恢复数据之前，要关闭 binlog 功能）
　　作用：mysqldump 是 mysql 自带的备份和数据转移的工具。
　　它只产生 sql 语句（即 sql 命令）封装在文件，而不是真实的数据。
　　Mysqldump 是逻辑备份，不是物理备份，备份的是 SQL 语句，而不是数据文件。
　　Mysqldump 适用于小型数据库，数据容量一般是在几个 G 大小，当数据量很大的情况下，不建议使用 mysqldump。
　　导出对象：可以针对单个表、多个表、单个数据库、多个数据库、所有数据库。
　　#mysqldump [选项] 库名 [表名1] [表名2] … > /备份路径/备份文件名
　　//导出指定数据库的单个或多个表
　　#mysqldump [选项] --databases 库名1 [库名2] … > /备份路径/备份文件名
　　//导出指定的数据库或多个数据库
　　#mysqldump [选项] --all-databases > /备份路径/备份文件名
　　//导出所有的数据库
　　#mysqldump -uroot -p123456 --flush-logs bdqn > /opt/bdqn.sql
　　//导出数据库bdqn,其中“—flush-logs”这个选项是完整备份完毕后开启一个新的binlog
　　#mysql -uroot -p123456 bdqn < /opt/bdqn.sql
　　//从备份文件导入数据库bdqn
　　下面用一个具体的实验说明用mysqldump实现全库备份+binlog的数据恢复
　　4）开始全库备份（注意：全库备份不会备份 binlog 日志文件）
　　5）备份 mysqldump 全库备份之前的所有的 binlog 日志文件（注意：真是生产环境中可能不止一个 binlog 文件）

　　6）因为全库备份之前的 binlog 已经备份了，现在就删除它们（即新产生的 binlog 之前的所有的 binlog 删除）

　　①使用 mysqldump 的备份进行全库恢复（即恢复到全部备份时候的所有数据）

　　②分析新开启的 binlog 日志文件（我这里是 mysql-bin.000002）里面误操作的事件的起始位置和终止位置，只要跳过这一段事件即可
　　复制的日志：
　　# at 219

　　#170318 21:14:42 server>　　SET TIMESTAMP=1489842882/*!*/;
　　SET @@session.pseudo_thread_id=5/*!*/;
　　SET @@session.foreign_key_checks=1,@@session.sql_auto_is_null=0, @@session.unique_checks=1,@@session.autocommit=1/*!*/;
　　SET @@session.sql_mode=1075838976/*!*/;
　　SET @@session.auto_increment_increment=1,@@session.auto_increment_offset=1/*!*/;
　　/*!\C utf8 *//*!*/;
　　SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.
　　collation_server=33/*!*/;
　　SET @@session.lc_time_names=0/*!*/;
　　SET @@session.collation_database=DEFAULT/*!*/;
　　BEGIN
　　/*!*/;
　　# at 291

　　#170318 21:14:42 server>　　# at 339

　　#170318 21:14:42 server>　　BINLOG '
　　wjLNWBMBAAAAMAAAAFMBAAAAAGwAAAAAAAEABGJkcW4AAml0AAIDDwI8AALyyJ5K
　　wjLNWCABAAAAMQAAAIQBAAAAAGwAAAAAAAEAAgAC//wBAAAACHpoYW5nc2FuqD2KLg
　　=='/*!*/;
　　### DELETE FROM `bdqn`.`it`
　　### WHERE
　　### @1=1
　　### @2='zhangsan'
　　# at 388

　　#170318 21:14:42 server>　　COMMIT/*!*/;
　　③开始使用全库备份后的增量备份的 binlog 日志文件备份文件进行对全库恢复后的增量数据的恢复

　　总结：从上图显示可以看出数据恢复到正常状态，实际生产环境中 mysql 数据库的备份是周期性重复操作，所有通常是要编写脚本实现，通过 crond 计划任务周期性执行备份脚本。
　　周日凌晨1点全库备份；
　　周一到周六凌晨每隔4个小时增量备份一次
　　设置 crontab 任务，每天执行备份脚本：

　　2）编写 mysqlfullbackup.sh 脚本（即 mysql 全库备份脚本）

　　3）编写 mysqldailybackup.sh 脚本（即 mysql 增量备份脚本）

　　发送邮件测试：
　　安装 libmysqlclient.so.18
　　再次测试：
　　二使用 xtrabackup 进行 MySQL 数据库备份
　　前面介绍mysqldump 备份方式是采用逻辑备份，其最大的缺陷就是备份和恢复速度都慢，对于一个小于 50G 的数据库而言，这个速度还是能接受的，但如果数据库非常大，那再使用 mysqldump 备份就不太适合了。
　　这时就需要一种好用又高效的工具，xtrabackup就是其中一款，号称免费版的 InnoDB HotBackup。
　　目前主流的有两个工具可以实现物理热备：ibbackup 和 xtrabackup；
　　ibbackup 是商业软件，需要授权，非常昂贵。
　　xtrabackup 功能比 ibbackup 还要强大，但却是开源的。因此我们这里就来介绍 xtrabackup 的使用。
　　xtrabackup：专用于备份 InnoDB 和 XtraDB 引擎的数据；
　　innobackupex：这是一个 perl 脚本，在执行过程中会调用 xtrabackup 命令，这样用该命令即可以实现备份 InnoDB，也可以备份 MyISAM 引擎的对象。
　　(1)备份过程快速、可靠；
　　(2)备份过程不会打断正在执行的事务；
　　(3)能够基于压缩等功能节约磁盘空间和流量；
　　(4)自动实现备份检验；
　　(5)还原速度快。
　　官方链接地址：
　　http://www.percona.com/software/percona-xtrabackup；
　　可以下载源码编译安装，也可以下载适合的 RPM 包或使用 yum 进行安装或者下载二进制源码包。
　　wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/binary/tarball/percona-xtrabackup-2.4.4-Linux-x86_64.tar.gz
　　Xtrabackup 中主要包含两个工具：
　　xtrabackup：是用于热备份 innodb,xtradb 表中数据的工具，支持在线热备份，可以在不加锁的情况下备份 Innodb 数据表，不过此工具不能操作 Myisam 引擎表；
　　innobackupex：是将 xtrabackup 进行封装的 perl 脚本，能同时处理 Innodb 和 Myisam，但在处理 Myisam 时需要加一个读锁。
　　由于操作 Myisam 时需要加读锁，这会堵塞线上服务的写操作，而 Innodb 没有这样的限制，所以数据库中 Innodb 表类型所占的比例越大，则越有利。
　　#wget https://www.percona.com/downloads/percona-toolkit/2.2.19/RPM/percona-toolkit-2.2.19-1.noarch.rpm
　　至此就完成了xtrabackup的安装，下面就可以启动备份了。
　　2）创建备份用的目录（full：全备存放的目录；inc：增量备份存放的目录）
　　在使用 innobackupex 进行备份时，还可以使用 --no-timestamp 选项来阻止命令自动创建一个以时间命名的目录；如此一来，innobackupex 命令将会创建一个 BACKUP-DIR 目录来存储备份数据。
　　还可以加 —database 选项指定要备份的数据库，这里指定的数据库只对 MyISAM 表有效，对于 InnoDB 数据来说都是全备（所有数据库中的 InnoDB 数据都进行了备份，不是只备份指定的数据库，恢复时也一样）。
　　下面我们大体看一下这几个文件：
　　说明：xtrabackup_binlog_pos_innodb 和 xtrabackup_binary 在这个版本里面没有了，因为版本较新，这两个文件在新版给删除了，只存在于老版本。
　　我这里直接使用删除数据目录文件来模拟损坏。
　　一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据文件仍处理不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。
　　在准备（prepare）过程结束后，InnoDB 表数据已经前滚到整个备份结束的点，而不是回滚到 xtrabackup 刚开始时的点。
　　innobakupex 命令的 --apply-log 选项可用于实现上述功能。如下面的命令：
　　--apply-log 指明是将日志应用到数据文件上，完成之后将备份文件中的数据恢复到数据库中：

　　在实现“准备”的过程中，innobackupex通常还可以使用--use-memory选项来指定其可以使用的内存的大小，默认通常为100M。如果有足够的内存可用，可以多划分一些内存给prepare的过程，以提高其完成速度。
　　说明：innobackupex 命令的 --copy-back 选项用于执行恢复操作，其通过复制所有数据相关的文件至 mysql 服务器 DATADIR 目录中来执行恢复过程。innobackupex 通过backup-my.cnf 来获取 DATADIR 目录的相关信息。

　　⑧正式开始还原增量备份
　　⑨重新启动二进制日志并验证还原数据

　　附：Xtrabackup 的“流”及“备份压缩”功能
　　作用：Xtrabackup 对备份的数据文件支持“流”功能，即可以将备份的数据通过 STDOUT 传输给 tar 程序进行归档，而不是默认的直接保存至某备份目录中。
　　要使用此功能，仅需要使用 --stream 选项即可。如：
　　看不清截图的可以看下面复制粘贴的命令：
　　# innobackupex --user=root --password=&quot;123456&quot;--stream=tar /opt/mysqlbackup/full/ | gzip >/opt/mysqlbackup/full/full_`date+%F_%H%M%S`.tar.gz
　　（再补充一句，现实生产环境中，基本上都要用流与备份压缩功能，因为这样可以很大程度上节省空间）
　　链接：http://zpf666.blog.51cto.com/11248677/191345