📫作者简介：小明java问道之路，专注于研究 Java/ Liunx内核/ C++及汇编/计算机底层原理/源码，就职于大型金融公司后端高级工程师，擅长交易领域的高安全/可用/并发/性能的架构设计与演进、系统优化与稳定性建设。
📫 热衷分享，喜欢原创~ 关注我会给你带来一些不一样的认知和成长。
🏆 InfoQ签约作者、CSDN专家博主/后端领域优质创作者/内容合伙人、阿里云专家/签约博主、51CTO专家 🏆
🔥如果此文还不错的话，还请👍关注、点赞、收藏三连支持👍一下博主~
本文目录
本文导读
在前面文章中《数据库机房架构与跨城容灾详解》、《MySQL参数调优与实战详解》、《数据库服务器硬件优化与实战详解》、《MySQL复制与高可用水平扩展架构实战》、《MySQL复制原理与主备一致性同步工作原理解析》、《MySQL日志系统以及InnoDB背后的技术》已经讲解了MySQL高可用架构的相关知识。
本文主要讲解数据库备份，包括数据库全量备份（逻辑备份和物理备份）、增量备份以及常见的问题，此举完全是防止有人恶意删库跑路或者无意中删除数据库数据。
一、备份数据库的重要性
Replication 复制技术 或 InnoDB Cluster 基于群组复制仅能负责业务可用性。
为了确保数据安全，除了生产的多活以及副本数据库，我们还需要构建一个完整的离线备份系统。即使所有数据库都已损坏，开发人员也可以从备份中恢复数据。
简单来说就是在独立内存空间，保存一份数据和 log 文件。
二、数据库全量备份
对于MySQL数据库，数据库备份分为完全备份和增量备份。
1、完全（全量）备份——逻辑备份
它指的是在当前时间点备份数据库中的所有数据。根据备份内容的不同，完全备份可分为逻辑备份和物理备份。
逻辑备份，是指数据库逻辑内容的备份，以 INSERT 语句的形式备份每个表的内容。
1.1、mysqldump
-
-- 通过 mysqldump 进行全量的逻辑备份
-
-- -A 表示备份所有数据库
-
-- --single-transaction 表示进行一致性的备份。
-
-- backup.sql 保存到此文件中
-
-- 注：mysqldump不需要登录到数据库中就可以备份和恢复库和表
-
mysqldump
-A
--single-transaction > backup.sql
在上面的命令中，最终的备份文件称为 backup.sql。文件备份 backup.sql 本质上是一个文本文件，记录sql语句，这就是我们所说的逻辑备份。
恢复逻辑备份非常简单。它是在文件中执行SQL语句。此时，可以使用以下SQL语句：
mysql < backup.sql尽管 mysqldump 简单易用，但由于它是由单个线程备份的，所以速度会相对较慢，因此MySQL推出了 mysqlpump 工具。
1.2、mysqlpump
mysqlpump 命令与 mysqldump 几乎相同，唯一的区别是它可以设置备份的线程数，可以在备份过程中查看备份进度。
mysqlpump 的并行备份与数据一致性冲突（并发线程超过1），数据一致性问题仅存在于5.7.11之前。在以后的版本中可以同时添加 --default-parallelism=N（默认并行）、 --single-transaction（单个事务） 这两个参数。官方文档：https://dev.mysql.com/doc/refman/5.7/en/mysqlpump.html#option_mysqlpump_default-parallelism
Before MySQL 5.7.11, use of the --single-transaction option is mutually exclusive with parallelism. To use --single-transaction, disable parallelism by setting --default-parallelism to 0 and not using any instances of --parallel-schemas:
mysqlpump --single-transaction --default-parallelism=01.3、mydumper 工具
地址：https://github.com/maxbube/mydumper
mydumper的优势在于：支持一致备份，可以根据表中的记录进行分区，以便执行多线程备份；对于恢复操作，它也可以是多线程备份；可以多线程的恢复指定单表。
-
-- -r 表示每张表导出 number 条记录后保存到一张表
-
-- --trx-consistency-only 表示一致性备份
-
-- -t 表示 n 个线程并行备份
-
mydumper
-o
/bak
-r number
--trx-consistency-only -t n
2、完全（全量）备份——物理备份
逻辑备份很好，但它需要回复很长时间，因为逻辑备份本质上是执行INSERT…SELECT…操作。
物理备份直接备份数据库的物理表空间文件和重做日志，而不是通过逻辑 INSERT 获取数据。因此，物理备份的速度通常比逻辑备份快，恢复速度也更快，物理备份只能恢复整个实例的数据，而不能恢复指定的表。
-
-- 物理备份命令
-
-- 在命令行下输入 clone 命令进行本地实例的 MySQL 物理备份
-
CLONE
LOCAL DATA DIRECTORY
=
'/path/**/**';
物理备份实现机制多于逻辑备份复制，建议使用MySQL的官方物理备份工具。
三、数据库增量备份
逻辑备份和物理备份都是全量整个数据库的备份。然而，数据库中的数据不断变化。不可能每小时每分钟增量备份数据库。
在生产环境中，通过“完全备份+增量备份”来构建完整的备份策略。
增量备份是备份日志文件（MySQL数据库中的二进制日志文件），因为二进制日志保存了对数据库的所有更改，所以“完全备份+增量备份”可以实现时间点恢复，即“完全备份”可以恢复到任何时间点。
在完全备份期间，将记录与此备份对应的时间点，通常是GTID（Global transaction identifiers,也称之为全局事务ID）位置。
增量备份可以在这一点之后 redo log，从而可以实现基于时间点的恢复。如果对二进制日志进行了一些数据库删除操作，则可以跳过这些点，然后重新播放后续的二进制日志，以便对极端的数据库删除场景执行灾难恢复。
-
-- 实时增量备份 MySQL 的二进制日志语句
-
-- --read-from-remote-server 表示从远程由--host指定 MySQL 上拉取二进制日志
-
-- --raw 表示根据二进制的方式进行拉取
-
-- --stop-never 表示永远不要停止，即一直拉取一直保存
-
-- binlog.* 表示从这个文件开始拉取。
-
mysqlbinlog
--read-from-remote-server --host=host_name --raw --stop-never binlog.*
-
-
-
-- 通过 mysqlbinlog 解析二进制日志进行恢复
-
mysqlbinlog binlog.
*……
| mysql
-u root
-p
四、数据库备份的常见问题
1、备份策略
本地存储备份和双倍的磁盘空间会造成一定的资源浪费。
所有需要设置完全备份的频率，由于完全备份相对较大，建议设置每周一次完全备份和实时增量备份的频率。
在这种情况下，最坏的情况是在7天前恢复完整备份，然后通过7天的增量备份恢复。
对于备份文件，可能还需要对其进行备份，备份文件应存储在至少两个机房的不同存储服务器上，即至少需要两个备份文件副本。多备份方法，建议集中化的管理。
2、备份文件验证
备份文件未经验证通常是最大的问题，也是最容易被忽略的问题。备份文件验证的一般逻辑是恢复所有文件，然后通过增量备份进行恢复，然后将恢复的MySQL实例连接到在线MySQL服务器作为从属服务器，然后再次检查数据。
3、集群备份节点选择问题
集群备份节点选择问题，建议将备份部署在从属节点或统计节点上。当集群在主节点和从节点之间切换时，如果备份节点没有动态切换，将在写数据库上执行备份。
4、压缩文件
备份传输导致网络卡流量的速度限制和压缩，从而影响在线服务，所以需要将文件和流量压缩。
总结
在前面文章中《数据库机房架构与跨城容灾详解》、《MySQL参数调优与实战详解》、《数据库服务器硬件优化与实战详解》、《MySQL复制与高可用水平扩展架构实战》、《MySQL复制原理与主备一致性同步工作原理解析》、《MySQL日志系统以及InnoDB背后的技术》已经讲解了MySQL高可用架构的相关知识。
本文主要讲解数据库备份，包括数据库全量备份（逻辑备份和物理备份）、增量备份以及常见的问题，此举完全是防止有人恶意删库跑路或者无意中删除数据库数据。
转载：https://blog.csdn.net/FMC_WBL/article/details/128123606