📫作者简介:小明java问道之路,专注于研究 Java/ Liunx内核/ C++及汇编/计算机底层原理/源码,就职于大型金融公司后端高级工程师,擅长交易领域的高安全/可用/并发/性能的架构设计与演进、系统优化与稳定性建设。
📫 热衷分享,喜欢原创~ 关注我会给你带来一些不一样的认知和成长。
🏆 InfoQ签约作者、CSDN专家博主/后端领域优质创作者/内容合伙人、阿里云专家/签约博主、51CTO专家 🏆
🔥如果此文还不错的话,还请👍关注、点赞、收藏三连支持👍一下博主~
在前面文章中《数据库机房架构与跨城容灾详解》、《MySQL参数调优与实战详解》、《数据库服务器硬件优化与实战详解》、《MySQL复制与高可用水平扩展架构实战》、《MySQL复制原理与主备一致性同步工作原理解析》、《MySQL日志系统以及InnoDB背后的技术》已经讲解了MySQL高可用架构的相关知识。
本文主要讲解数据库备份,包括数据库全量备份(逻辑备份和物理备份)、增量备份以及常见的问题,此举完全是防止有人恶意删库跑路或者无意中删除数据库数据。
Replication 复制技术 或 InnoDB Cluster 基于群组复制仅能负责业务可用性。
为了确保数据安全,除了生产的多活以及副本数据库,我们还需要构建一个完整的离线备份系统。即使所有数据库都已损坏,开发人员也可以从备份中恢复数据。
简单来说就是在独立内存空间,保存一份数据和 log 文件。
对于MySQL数据库,数据库备份分为完全备份和增量备份。
它指的是在当前时间点备份数据库中的所有数据。根据备份内容的不同,完全备份可分为逻辑备份和物理备份。
逻辑备份,是指数据库逻辑内容的备份,以 INSERT 语句的形式备份每个表的内容。
- -- 通过 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 工具。
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=0
地址:https://github.com/maxbube/mydumper
mydumper的优势在于:支持一致备份,可以根据表中的记录进行分区,以便执行多线程备份;对于恢复操作,它也可以是多线程备份;可以多线程的恢复指定单表。
- -- -r 表示每张表导出 number 条记录后保存到一张表
- -- --trx-consistency-only 表示一致性备份
- -- -t 表示 n 个线程并行备份
- mydumper -o /bak -r number --trx-consistency-only -t n
逻辑备份很好,但它需要回复很长时间,因为逻辑备份本质上是执行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
本地存储备份和双倍的磁盘空间会造成一定的资源浪费。
所有需要设置完全备份的频率,由于完全备份相对较大,建议设置每周一次完全备份和实时增量备份的频率。
在这种情况下,最坏的情况是在7天前恢复完整备份,然后通过7天的增量备份恢复。
对于备份文件,可能还需要对其进行备份,备份文件应存储在至少两个机房的不同存储服务器上,即至少需要两个备份文件副本。多备份方法,建议集中化的管理。
备份文件未经验证通常是最大的问题,也是最容易被忽略的问题。备份文件验证的一般逻辑是恢复所有文件,然后通过增量备份进行恢复,然后将恢复的MySQL实例连接到在线MySQL服务器作为从属服务器,然后再次检查数据。
集群备份节点选择问题,建议将备份部署在从属节点或统计节点上。当集群在主节点和从节点之间切换时,如果备份节点没有动态切换,将在写数据库上执行备份。
备份传输导致网络卡流量的速度限制和压缩,从而影响在线服务,所以需要将文件和流量压缩。
在前面文章中《数据库机房架构与跨城容灾详解》、《MySQL参数调优与实战详解》、《数据库服务器硬件优化与实战详解》、《MySQL复制与高可用水平扩展架构实战》、《MySQL复制原理与主备一致性同步工作原理解析》、《MySQL日志系统以及InnoDB背后的技术》已经讲解了MySQL高可用架构的相关知识。
本文主要讲解数据库备份,包括数据库全量备份(逻辑备份和物理备份)、增量备份以及常见的问题,此举完全是防止有人恶意删库跑路或者无意中删除数据库数据。