# 备份与恢复

# 任务描述

本关任务:
备份数据库,然后再恢复它。

# 相关知识

为了完成本关任务,你需要掌握:

  1. MySQL 的恢复机制;
  2. MySQL 提供的备份与恢复工具。

# MySQL 的恢复机制

和大多数 DBMS 一样,MySQL 利用备份、日志文件实现恢复。

具体理论知识在此不详细介绍。

# MySQL 的备份与恢复工具

MySQL 提供了以下工具:

  • 逻辑备份工具:mysqldump
  • 物理备份工具:mysqlbackup (仅限商用版)
  • 日志工具:mysqlbinlog
  • 还原工具:mysql
  • 管理工具:mysqladmin
# mysqldump

逻辑备份工具,它产生一系的 SQL 语句,执行这些语句可以重建原数据库的所有对象和数据。缺省输出是控制台,可以通过重定向符号,将其产生的 SQL 语句集合存入到某个文件。

mysqldump 可以备份服务器上的全部数据库,也可以指定某些数据库,或者一个数据库中的某些表。

mysqldump -h127.0.0.1 -uroot -p123123 [options] --databases db_name

--databases 参数用指定数据库名,后面可跟一个或多个数据库的名字,多个数据库名间用空格隔开。

mysqldump 命令行工具还可以带若干参数,可选的参数多达几十个,详见官方参考手册。这里只介绍一个:

--flush-logs 刷 MySQL 日志,即重新开始一个日志文件。

重新开始一个新的日志文件,对未来确定哪些日志更有用很有帮助。通常海量备份前的日志文件,其重要性会降低许多,因为有备份在手,除非备份文件出故障,你可能不再需要使用之前的日志文件。

# mysqlbackup

mysqlbackup 是 MySQL 的物理备份工具,只有付费的商用企业版才有。

# mysql

mysql 是 MySQL 最重要的客户端管理工具,通常用户都是通过 mysql 登录到 MySQL 服务器,进行各种操作。此外,还可以直接通过它执行 SQL 脚本,还原或创建新库。

mysql -h127.0.0.1 -uroot -p12313 < mydb.sql

这样会直接执行 mydb.sql 的脚本。通过 mysqldump 备份出来的脚本文件,可以用该方法直接用来恢复原数据库。

# mysqladmin

mysqladmin 是 MySQL 服务器的管理工具,一般用于配置服务器,也可以用来创建或删除数据库:

mysqladmin [options] command [command-arg] [command [command-arg]]

常用的 command (执行命令) 有:

  • create db_name 创建数据库
  • drop db_name 删除数据库
  • flush-logs 刷日志
  • flush-tables 刷表,所有表数据写入磁盘盘
  • kill id,id,... 杀死某些进程
  • password new_password 修改 (登录者的) 登录密码
  • ping 检查服务器是否可用
  • status 显示服务器状态
  • variables 显示各配置参数的值

同样,该工具也支持不少可选的参数,详见官方手册。

# mysqlbinlog

mysqlbinlog 是 MySQL 的日志管理工具。在需要手工介入的故障恢复中,该工具必不可少。当然,平常也可以用它查看日志。

mysqlbinlog  mysql-bin.000983

上面的例子,用来查看日志文件 mysql-bin.000983。MySQL 的日志文件具有相同的前缀,后面的数字是日志文件的顺序。这个前缀是可配置的。比如,也可能是 binlog.*,例如:

1668350674044

执行日志文件会导致日志所记录的事件重新做一遍,这样可以恢复一个给定时间段的数据,恢复的方法如下:

mysqlbinlog [option] binlog_files | mysql -u root -p

介质故障的恢复通常需要把最近一次备份后所有的日志文件全部列上。

mysqlbinlog 也支持几十个可选的参数,比如:

  • --disable-log-bin 在通过日志恢复数据库期间不再写日志
  • --no-defaults 不使用 MySQL 默认的设置

其它参数数详情请参考官方文档。

MySQL 还有其它一些工具 (如 mysqlimport,mysqlshow 等),这里不一一介绍。

# 编程要求

设有居民人口登记数据库 residents, 请为该数据库做一次静态的 (你一个人独享服务器) 海量逻辑备份,备份文件命名为 residents_bak.sql。 然后再用该逻辑备份文件恢复数据库。

评测程序并不检查备份文件的名字,你可以用其它文件名,但要保证备份和恢复时,使用同一个文件。备份和恢复的命令分别写在 test1_1.sh 和 test1_2.sh 文件中。

  • test1_1.sh - 作备份
  • test1_2.sh - 作恢复

切莫把两个文件弄反了。

test1_1.sh

# 你写的命令将在 linux 的命令行运行
# 对数据库 residents 作海量备份,备份至文件 residents_bak.sql:
mysqldump -h127.0.0.1 -uroot --databases residents > residents_bak.sql

test1_2.sh

# 你写的命令将在 linux 的命令行运行
# 利用备份文件 residents_bak.sql 还原数据库:
mysql -h127.0.0.1 -uroot < residents_bak.sql

# 备份 + 日志:介质故障的发生与数据库的恢复

# 任务描述

本关任务:

模拟介质故障的发生,以及如何利用备份和备份之后的日志恢复数据库。

# 相关知识

只要有备份文件,和自上次备份以来的日志文件,即使发生介质故障导致整个数据库丢失,也可以在更换介质后,恢复数据库。上一关已介绍有关知识。

在生产环境中,数据库文件、备份文件、日志文件都不会存放在同一介质上,甚至都不会存放在同一地理空间。为的就是灾难发生后,有机会恢复数据。

本关将摸拟介质故障的发生与数据库的恢复。你要使用的工具包括:

  • mysql
  • mysqldump
  • mysqlbinlog

上一关已经介绍了它们的用法。

# 编程要求

摸拟介质故障的发生与数据库的恢复。依时间顺序发生下列事件 (其中标记为红色的部分将由你来完成,其余部分由评测程序完成):

  1. 时间点 1:数据库 train 有业务数据产生;
  2. 时间点 2:对数据库 train 作一次海量备份,同时新开日志;
  3. 时间点 3:数据库 train 又有业务数据产生;
  4. 时间点 4:故障发生;
  5. 时间点 5:恢复数据库,保证两次发生的业务数据都不丢失。

请你完成时间点 2 和时间点 5 (标注红色的部分) 的工作,将完成任务的脚本填写到对应文件中:

  • 对数据库 train 作一次海量逻辑备份同时开新日志:test2_1.sh
  • 利用备份文件和日志文件恢复数据库: test2_2.sh

切莫把两个文件弄反了。

所有其它工作,评测程序会替你完成:

  • 在发生业务数据的时间点,会批量写入数据;
  • 在故障发生的时间点,数据库 train 会被 drop 掉。
  • 在 drop 数据库之前,评测程序会将备份后新开的日志文件保存为 log/binlog.000018

这里,评测程序总是替你找到你需要的那个日志文件,并保存在一个固定的日志文件中,供你恢复使用。但在实践中,日志文件是一直在变化的,即便是在这样一个由你独享服务器实例的环境下,两次点击 “评测” 按钮,日志文件也会因评测程序多次写入数据,加上你的备份与恢复操作而发生变化,当日志文件达到一定规模时,MySQL 还会自动开启新日志文件。在本地实验时,自己要学会识别你需要哪个或哪些日志文件。

test2_1.sh

# 这是 shell 脚本,将在 linux 命令行上执行
# 命令行上可省略密码的指定
# 请写出对数据库 train 作逻辑备份并新开日志文件的命令,备份文件你可以自己命名 (如 train_bak.sql):
mysqldump -h127.0.0.1 -uroot --flush-logs --databases train > train_bak.sql;

test2_2.sh

# 这是 shell 脚本,将在 linux 命令行上执行
# 命令行上可省略密码的指定
# 请写出利用逻辑备份和日志恢复数据库的命令:
mysql -h127.0.0.1 -uroot < train_bak.sql;
mysqlbinlog --no-defaults log/binlog.000018 | mysql -uroot;