【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南（备份+恢复篇）

MySQL数据库备份

MySQL的数据库备份主要分为两种：全量备份和增量备份。全量备份是指对整个数据库进行完全备份，包括所有的数据和对象。这种备份方法适用于数据库规模较小或者对备份恢复速度要求较高的情况。

而增量备份是指在全量备份的基础上，只备份发生了变化的数据和对象。这种备份方法可以大大减少备份的时间和存储空间，适用于数据库规模较大或者对备份频率要求较高的情况。增量备份可以通过记录修改日志或者使用数据库的存储引擎来实现。

无论是全量备份还是增量备份，都可以提供可靠的数据保护，并在系统故障或数据损坏时进行快速恢复。因此，在进行数据库备份时，需要根据实际情况选择适合的备份策略，并确保备份文件的安全存储和定期测试恢复的可行性。

全量备份

全量备份是对数据库进行完全备份的过程，包括所有表、记录和对象。在MySQL中，可以使用不同的命令进行全量备份。

以使用InnoDB引擎的数据库为例，备份所有库中的全部数据的命令如下：

mysqldump -B --master-data=2 --single-transaction -A | gzip > /opt/backup.sql.gz

备份一个名为dadong的库中的所有数据的命令如下：

mysqldump -B --master-data=2 --single-transaction dadong | gzip > /opt/backup.sql.gz

在执行备份命令时，常用的选项包括–master-data=2和–single-transaction。–master-data=2会在备份文件中添加主从复制所需的信息，以便在恢复时进行主从同步。–single-transaction使用事务来确保备份数据的一致性。

为了提高备份效率和减少备份文件的大小，可以对备份文件进行压缩，如使用gzip命令将备份文件压缩至/opt/all.sql.gz。

全量备份是一种重要的数据保护手段，但也需要注意备份文件的安全存储和定期测试恢复的可行性，以确保在系统故障或数据损坏的情况下能够快速恢复数据。

全量备份应用场景

1. 数据库迁移或升级：使用全量备份可以将原数据库的完整数据备份到目标服务器，确保数据的完整性和一致性。

2. 增加从库：通过全量备份将主库的数据备份到从库，建立数据一致性和冗余备份，提高数据库的可用性和容错性。

3. 数据库数据破坏时：如果执行DDL或DML语句破坏了数据完整性，主从库无法正常工作。可以使用全量备份将数据库还原到执行DDL或DML语句之前的状态，恢复数据完整性。

4. 跨机房灾备：当数据库所在的机房遭受灾难或故障时，为了保证数据的安全和可用性，可使用全量备份将数据库的完整数据复制到具备异地容灾条件的机房，实现跨机房的数据备份和灾难恢复。

5. 硬件故障或删除物理文件导致的数据故障处理：在这种情况下，可以关闭主库，配置从库的VIP等相关设置，然后启动从库提供服务，无需使用备份数据进行恢复。

增量备份

增量数据：指在上一次全量备份数据之后到下一次全备份之间的数据库更新数据。在使用mysqldump命令进行全量备份时，增量数据就是MySQL的二进制日志（binlog）。

在进行全量备份后，如果数据库发生了更新操作，比如插入、更新或删除记录，这些操作将被记录在binlog中。二进制日志包含了对数据库的逐个修改操作，通过解析二进制日志，可以提取出这些增量数据。这些增量数据可以用来恢复数据库到最新的状态，或者用于在备份之间复制数据以保持数据的一致性。

简而言之，增量数据就是在全量备份之后进行的数据更新操作所产生的数据库变化记录，通过解析和应用这些记录，可以实现数据库的增量恢复和数据同步。

binlog

binlog是二进制日志的简称，是MySQL数据库引擎用于记录数据库更新操作的一种日志文件格式。binlog文件记录了用户对数据库进行的更新操作，例如插入、修改、删除表记录等SQL语句信息，但不记录对数据库的查询操作。

binlog以二进制格式存储，不能通过查看文本工具（如cat、vi等）直接查看，需要使用mysqlbinlog工具进行解析和查看。

简而言之，binlog是MySQL数据库引擎用于记录用户对数据库进行的更新操作的二进制日志文件，它能够记录数据变化的SQL语句信息，但不包括查询语句。要查看binlog内容，需要使用专门的工具mysqlbinlog进行解析。

binlog主要作用

binlog的作用主要是用于数据库的主从复制和数据的增量恢复，它记录了数据库的新增、删除和修改操作，可以实现数据的备份、负载均衡和故障恢复等功能。

binlog的作用主要有两个方面

• 主从复制：在数据库主从复制中，主数据库将生成的binlog文件传输给从数据库，从数据库通过解析和应用binlog文件中记录的SQL语句，保持与主数据库的数据一致性。这样可以实现数据的备份、负载均衡和故障恢复等功能。
• 数据恢复：当数据库发生故障时，可以使用binlog日志进行数据的增量恢复。通过解析binlog文件中的SQL语句，可以重新执行这些操作，将数据恢复到故障发生之前的状态，保证数据的完整性。

开启binlog日志功能

MySQL的配置文件my.cnf中，可以通过增加log_bin参数来开启binlog日志，并可以通过赋值来指定binlog日志的文件名。

要开启MySQL的binlog日志步骤

1. 打开MySQL的配置文件my.cnf（路径通常为/etc/my.cnf或/etc/mysql/my.cnf）。
2. 在文件中找到或添加以下行：

log_bin = /path/to/binlog/file

将/path/to/binlog/file替换为你希望保存binlog日志的文件路径和名称。确保所指定的路径存在，并具有适当的权限。

3. 保存并关闭my.cnf文件。
4. 重启MySQL服务器，使配置生效。可以使用以下命令重启MySQL服务：

sudo service mysql restart

5. 确认binlog日志已成功开启。可以使用以下命令登录到MySQL控制台：

mysql -u  -p

注意要替换为你的MySQL用户名。

6. 在MySQL控制台中，运行以下命令查看binlog配置信息：

SHOW VARIABLES LIKE 'log_bin';

如果输出结果中的Value字段显示为ON，则表示binlog日志已成功开启。

mysqlbinlog

mysqlbinlog是MySQL数据库中的一个命令行工具，用于解析和展示binlog文件中的日志事件。

使用mysqlbinlog可以完成以下任务：

1. 查看binlog内容：可以通过mysqlbinlog命令直接读取和展示binlog文件中的日志事件，包括数据库的更改操作。
2. 数据恢复：可以使用mysqlbinlog将binlog文件中的日志事件应用到数据库中，从而实现数据的恢复和还原。
3. 数据审计和分析：可以通过解析binlog文件并将其输出为可读的文本格式，用于数据审计、故障排查和性能分析等。
4. 数据同步和复制：可以使用mysqlbinlog将binlog文件中的日志事件传输到另一个MySQL实例，实现数据库之间的数据同步和复制。

mysqlbinlog提供了丰富的参数选项，使其可以适应各种场景和需求。例如，可以指定要解析的binlog文件、指定输出格式、指定时间范围等。

参数	说明
-d, --database=name	根据指定库拆分binlog（拆分单表binlog可通过SQL关键字过滤）
-r, --result-file=name	指定解析binlog输出SQL语句的文件
-R, --read-from-remote-server	从mysql服务器读取binlog日志，是下面参数的别名
-j, --start-position=#	读取binlog的起始位置点，#号是具体的位置点
–stop-position=#	读取binlog的停止位置点，#号是具体的位置点
–start-datetime=name	读取binlog的起始位置点，name是具体的时间，格式为：2004-12-25 11:25:26
–stop-datetime=name	读取binlog的停止位置点，name是具体的时间，格式为：2004-12-25 11:25:26
–base64-output=decode-rows	解析row级别binlog日志的方法，例如：mysqlbinlog --base64-output=decode-rows -v mysqlbin.000016

mysqlbinlog的使用案例

mysqlbinlog -d rdbTest rdbTest-bin.000001 rdbTest-bin.000002 -r bin.log

这个例子展示了如何利用mysqlbinlog命令将binlog文件解析到bin.log文件中。

mysqlbinlog命令可以通过使用

-d：来指定要解析的数据库，例如指定解析dadong数据库。

-r：用于将解析后的binlog输出成SQL语句，并指定生成的文件名为bin.log。

使用mysqlbinlog的-d参数可以实现按数据库导出binlog的功能。需要注意的是，如果使用了-d参数，更新数据时必须在SQL语句中包含use库名的语句，这样才能正确分出指定数据库的binlog。

例如，插入数据的语句应采用以下格式：

use rdbTest;
insert into test values(1, 'e');

全量备份与增量备份结合

下面以mysqldump命令和binlog日志增量数据为例，讲解企业中按天全备和按周全备的方法。

按天全备与增量备份

	周一00点全量备份	周二00点全量备份	周三00点全量备份
文件	01.sql.gz	02.sql.gz	03.sql.gz
增量数据	周一增量数据	周二增量数据	周三增量数据
binlog	oldboy-bin.000024	oldboy-bin.000037	oldboy-bin.000045
	oldboy-bin.000025	oldboy-bin.000038	oldboy-bin.000046
	oldboy-bin.000026	oldboy-bin.000039	oldboy-bin.000047
	oldboy-bin.index	oldboy-bin.index	oldboy-bin.index

对于按天全备，可以使用mysqldump命令来导出整个数据库的备份。下面是一个示例命令：

mysqldump -u username -p password --all-databases > backup.sql

这个命令会导出所有数据库的备份，并保存到backup.sql文件中。你需要将username和password替换为实际的MySQL数据库的用户名和密码。

对于按周全备，可以使用mysqldump命令结合binlog日志的增量备份。首先，执行全备份命令：

mysqldump -u username -p password --all-databases > backup.sql

然后，使用mysqlbinlog命令将binlog日志解析出增量数据，追加到全备份文件中：

mysqlbinlog binlog-file | mysql -u username -p password

这个命令会将binlog日志文件解析为SQL语句，并通过管道传递给mysql命令执行。你需要将binlog-file替换为实际的binlog日志文件路径。

通过以上方法，可以实现按天全备和按周全备的数据库备份。这样可以确保数据备份的完整性和及时性，以应对潜在的数据丢失和灾难恢复情况。

按天全备的特点

优点：

• 恢复数据时所需的数据文件数量较少，因此恢复时间较短。
• 维护成本较低，不需要频繁处理差异数据。

缺点：

• 每天进行全备份，占用大量存储空间。
• 备份过程会消耗系统资源，可能会对用户体验造成影响。

对于中小型企业而言，按天全备是最常用的备份策略。根据存储空间的情况，可以保留一定数量的全量备份，例如仅保留最近7天的备份数据。对于重要的企业数据，还可以考虑使用磁带机等设备将备份数据存档至一年以上。

针对binlog增量数据的清理，可以在my.cnf配置文件中通过设置"过期清理天数"相关参数（例如expire_logs_days=7）来实现。这样可以保留最近7天的binlog日志。理论上，如果每天进行全备份，那么只需保留一天的binlog日志即可满足需求。

按周全备与增量备份

备份类型	文件名
每周一00全量备份	01.sql.gz
周一增量数据	oldboy-bin.000024
周二增量数据	oldboy-bin.000037
周三增量数据	oldboy-bin.000045
…	…
下周日增量数据	oldboy-bin.000047
oldboy-bin索引	oldboy-bin索引
oldboy-bin索引	oldboy-bin索引
oldboy-bin索引	oldboy-bin索引
oldboy-bin索引	oldboy-bin索引

按周全备特点

优点：

• 每周仅有一个完整备份，因此占用磁盘总空间大小较小。
• 备份次数较少，占用系统资源较少，提供更好的用户体验。

缺点：

• 恢复时需要处理的数据文件较多，增加了恢复的复杂度。
• 维护成本较高，恢复时间可能较长。

对于大型企业来说，由于数据量特大，每天进行全备可能需要很长时间。因此，采用按周全备的策略可以节省数据存储空间，并且不会对用户访问数据库的体验产生太大的影响。

MySQL的备份方式

逻辑备份

逻辑备份是通过将MySQL数据库中的数据（包括库表）以SQL语句的形式直接输出或生成备份文件的方式进行备份，其中使用mysqldump命令实现。

逻辑备份具有如下特点

优点：

• 操作简单、方便和可靠。
• 备份的数据可以在不同的平台、版本、软件和操作系统之间迁移和恢复。
• 可实现对分库分表的备份。

缺点：

• 备份速度比物理备份慢。
• 恢复效率相对较低。

常用的工具包括

• mysqldump：MySQL官方自带的最常用逻辑备份工具，可实现对分表分库的备份。
• mydumper：一个在GPL许可下发布的高性能MySQL备份和恢复工具集。

逻辑备份在以下企业应用场景中适用：

• 数据量不是特别大的场景，例如备份前的数据不超过30GB。这个参考值主要考虑备份效率与管理员使用复杂度间的平衡。

然而，当存在跨版本、跨软件的升级或数据迁移时，物理备份通常无法使用。此时，通常会使用mysqldump工具进行数据处理，例如：

• 恢复数据到测试库。
• 通过执行SQL语句人为删除数据。
• 在主从复制中使用。

案例：备份多个表

可以使用以下语法来备份多个表：

mysqldump -u 用户名 -p 数据库名 表名1 表名2 > 备份的文件名

例如，备份库1中的表1、表2和表3可以使用以下命令：

mysqldump -u 用户名 -p 库1 表1 表2 表3 > 库1.sql

同样地，备份库2中的表1、表2和表3可以使用以下命令：

mysqldump -u 用户名 -p 库2 表1 表2 表3 > 库2.sql

备份一个或多个表的语法如下：

mysqldump [选项] 数据库名 [表名……]

备份一个或多个库的语法如下：

mysqldump [选项] –databases 数据库名……

备份所有数据库的语法如下：

mysqldump [选项] –all-databases

以上是备份多个表和多个库的语法和用法。你可以根据实际需求进行相应的调整和使用。

压缩和解压备份

以下是压缩备份和解压备份的代码示例：

压缩备份：

# mysqldump -B --master-data=2 dadong | gzip > /opt/t.sql.gz

这将使用mysqldump工具备份数据库dadong并将结果压缩为/opt/t.sql.gz文件。

解压备份：

# zcat t.sql.gz > t1.sql

这将解压缩/opt/t.sql.gz文件并将结果保存为t1.sql文件。另外，你还可以使用以下命令直接解压缩并删除源文件：

# gzip -d t.sql.gz

这会将t.sql.gz解压缩为t.sql文件，并删除原始的压缩文件。

请确保在操作过程中，确认目标路径和文件名与你需要的一致，并根据需要调整命令行中的数据库名称和文件路径。

mysqldump重要参数说明

下面是对mysqldump命令中一些重要参数的说明：

• -B, --database:

这个参数会在备份的数据中包含建库（create）以及"use库"的语句。可以同时备份多个库，只需要在参数后面直接添加多个库名。使用-B参数可以在数据库恢复时自动创建建表语句。

• -A, --all-databases:

备份所有的数据库。

• -F, --flush-logs:

刷新binlog日志，生成新的binlog文件。在将来进行增量恢复时，可以从这个新的binlog文件开始。如果备份多个库，每个库都会刷新一次binlog。如果只想刷新一次binlog，可以加上–lock-all-tables或–master-data参数。

• -x, --lock-all-tables:

在备份过程中，对所有数据库的表执行全局读取锁定操作，同时禁用-single-transaction和–lock-tables参数的功能。

• -l, --lock-tables:

将所有的表锁定为只读。

• –single-transaction:

备份InnoDB引擎的数据表时，通常会启用此选项，以获得一致性的数据快照备份。这个选项将设置备份会话的隔离级别为可重复读，并将整个备份过程放在一个事务中，以确保备份期间不会看到其他连接会话中已提交的数据。也就是说，备份开始时刻的数据是什么样的，备份结果就是什么样的。相当于对表进行加锁备份数据。但是，此参数允许备份期间进行写入操作，与使用-x参数锁定表不同，后者在备份期间不允许写入操作。启用此参数会关闭–lock-tables选项。

• -R, --routines:

备份存储过程和函数数据。

• -d, --no-data:

只备份库表结构（以SQL语句形式），不包含行数据。

• -t, --no-create-info:

只备份表内行数据（以SQL语句形式），不包含表结构。

• -T, --tab=name:

将库表和数据分离成不同的文件，行数据以纯文本形式存储，表结构以SQL语句形式存储。默认情况下，这个功能在5.6版本中是没有被授权的，需要修改my.cnf文件的参数。

• –master-data={1|2}:

在备份结果中包含binlog日志文件名及对应的binlog位置点（即"change master"命令）。–master-data=2会记录备份时刻的二进制日志位置，并将其注释掉。而–master-data=1则不会注释掉。

• –triggers:

备份触发器数据。

• –compact:

只显示少量有用的输出，适用于学习和测试环境调试。

single-transaction

当使用mysqldump的–single-transaction选项备份InnoDB表时，会开启一个事务并将整个备份过程放入其中。这样做可以确保在备份过程中不会看到其他连接已提交的数据变更。换句话说，在备份开始时刻的数据状态就是备份结果中的数据状态，就好像表被锁定一样。但需要注意的是，这个选项允许在备份期间进行数据写入，与使用-x选项锁定表并禁止写入的情况不同。

以下是一个操作示例：

# mysqldump -B --master-data=2 --single-transaction dadong | gzip > /opt/all.sql.gz

物理备份

冷备份

一种常见的物理备份方法是使用cp、rsync、tar、scp等复制工具将MySQL数据文件复制成多份。然而，直接复制的方式备份会引起数据丢失，因为在备份期间数据仍可以进行写入操作。

另外，在恢复数据库时，对新数据库的路径和配置也有要求，通常需要与原数据库的配置保持一致（包括版本、路径和配置选项），以确保数据正常恢复。通常情况下，人工停库或锁库后再进行物理复制是保证备份期间数据一致性的方法。然而，在生产环境中，通常不允许停机或锁表，除非事先申请停机或锁表时间。因此，使用传统的Linux命令拷贝工具进行冷备份是一种粗放的方式，应尽量避免使用。在进行大规模数据库迁移时，先停机然后进行物理迁移是一种高效的解决方案。

热备份

除了直接通过Linux命令行复制MySQL数据文件，还存在一些第三方的开源或商业物理热备份工具，如xtrabackup。使用这些工具可以实现物理全备份和增量备份。热备份是在不影响用户体验的情况下进行的备份方法。这些工具通常提供了更灵活和可靠的备份机制，可以确保数据的一致性，并能够有效地进行增量备份，减少备份时间和存储空间的占用。

物理备份的特点

物理备份与逻辑备份相比，具有以下优点和缺点。在企业中，根据需求，可以互补使用这两种备份方法。

优点

1. 速度快：物理备份通过直接复制数据文件，备份过程简单高效，可以快速完成备份任务。
2. 效率高：由于物理备份是直接复制数据文件，不需要解析数据，备份和恢复的效率较高。

缺点：

1. 不容易跨平台、跨版本、跨软件、跨操作系统：物理备份的数据文件格式通常与特定的数据库版本、软件和操作系统相关，无法直接在其他平台或软件上进行恢复操作。
2. 恢复过程复杂：由于物理备份涉及到数据库的路径、配置等细节，恢复时需要确保路径和配置与原数据库一致，这增加了恢复的复杂度。
3. 使用较复杂：物理备份可能需要借助第三方工具或命令行操作，相对于逻辑备份而言使用起来可能更复杂一些。

物理备份常用工具：

在Linux环境下，常用的物理备份工具有以下几种：

1. cp：是一个命令行工具，用于复制文件和目录。可以通过将数据库文件复制到备份目录来进行物理备份。
2. tar：是一个常用的压缩和打包工具，在备份时可以使用tar将数据库文件打包到备份文件中进行备份。
3. xtrabackup：是一个基于InnoDB存储引擎的开源热备份工具。与传统的冷备份工具不同，xtrabackup可以在数据库运行时进行备份，不需要停止数据库服务。

优化建议

• 对于总数据量超过30GB的数据库，可以考虑使用xtrabackup进行热备份，以提高备份的效率。
• 对于不希望影响数据库服务的情况，可以选择在数据库的从库上进行备份。在备份时，可以停止SQL线程从应用中读取数据，然后使用cp或tar等工具将数据库文件打包备份。这种方案称为冷备份，可以保证备份过程不影响数据库的正常服务。

MySQL数据库恢复

在进行数据库恢复时，需要注意以下事项：

1. 字符集关联：字符集的正确设置对于数据恢复至关重要。如果字符集设置不正确，恢复的数据可能会出现乱码问题。确保在恢复过程中，使用正确的字符集配置，以避免乱码问题的发生。

2. 使用MySQL命令和source命令进行恢复：MySQL命令和source命令是常用的数据库恢复工具。它们的原理是将备份文件中的SQL语句重新执行到数据库中，从而实现数据恢复的过程。在使用这些命令时，需要确保备份文件的SQL语句正确无误，并且执行过程中没有错误或中断。

优化建议

1. 在进行数据库恢复之前，确保备份文件的字符集与目标数据库的字符集一致。这样可以避免因字符集不匹配而导致的数据乱码问题。

2. 在使用MySQL命令或source命令恢复数据库时，建议先进行备份文件的验证，确保备份文件完整且没有损坏。可以使用checksum等工具对备份文件进行校验，以确保数据的完整性。

3. 在进行数据恢复之前，建议先在测试环境或备份数据库中进行恢复测试，以确保恢复过程的顺利进行，并且恢复后的数据符合预期。

利用source命令恢复数据库

要通过source命令来恢复数据库，请按照以下步骤执行：

1. 首先，进入MySQL数据库控制台。在命令行中输入以下命令并按Enter键：

mysql -u root -p密码

这将使用root用户和密码登录到MySQL数据库。

2. 登录成功后，使用以下命令切换到目标数据库：

mysql> use 数据库

将"数据库"替换为实际的目标数据库名称。

3. 接下来，使用source命令来执行脚本文件。脚本文件可以是一个SQL文件或者是一个压缩包。如果是压缩包，需要在MySQL登录前进入压缩包所在的文件夹。

mysql> source back_db.sql

将"back_db.sql"替换为实际的脚本文件名称。

请注意，如果脚本文件不在当前路径下，需要提供脚本文件的完整路径。

通过以上步骤，您将能够使用source命令成功恢复数据库。记得在执行任何数据库恢复操作之前，确保先备份您的数据以确保安全。

MySQLDump恢复数据库

在执行使用gzip解压缩之前，请先确保已经备份了数据库以确保安全。以下是使用gzip解压缩的步骤：

1. 备份数据库并创建测试数据。在终端中执行以下命令：

# mysqldump -B --master-data=2 dadong | gzip > /opt/backup.sql.gz

这将备份名为"dadong"的数据库并将其输出到/opt/backup.sql.gz文件中。

2. 解压缩压缩包。在终端中执行以下命令：

# gzip -d /opt/backup.sql.gz

这将解压缩/opt/backup.sql.gz文件，并生成一个名为backup.sql的解压缩后的文件。

3. 恢复数据库。在终端中执行以下命令：

# mysql 

这将使用mysql命令将backup.sql文件中的数据库恢复到MySQL中。

请注意，gzip命令的参数：

• -c 将输出写入标准输出，并保留原始文件。

• -d 解压缩压缩文件。

如果使用mysqldump导出数据库时指定了-B参数，则在恢复时无需特定库名。因为-B参数会生成包含"use backup"和"create database backup"的脚本，这类似于在恢复时执行"use backup"命令。

使用以上步骤，您将能够成功使用gzip解压缩并恢复数据库。请谨慎操作，并在执行任何数据库操作前先备份数据以确保安全。

System指令

注：如果不想退出MySQL，在执行恢复语句时可以使用系统命令。

在MySQL命令行中，执行以下命令将当前目录切换到/root目录:

mysql> system cd /root
mysql> system mysqldump -B --master-data=2 --single-transaction -B backup | gzip > /opt/all.sql.gz

以上是执行在MySQL命令行中切换到指定目录、退出MySQL、确认当前目录以及进行数据库备份并压缩的步骤。使用"–single-transaction"参数可以确保备份过程中不会锁定表，提高备份的稳定性和一致性。

使用zcat读取压缩包数据（直接导入数据库）

zcat /opt/backup.sql.gz >/opt/backup.sql
mysql </opt/backup.sql

下节预告

综上所述基本上完成了MySQL数据库的数据备份和恢复实现，下一节会面向物理备份的恢复实战，对于“【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南（xtrabackup恢复指南）”。