GoldenDB数据库备份恢复机制详解

[solihawk1024]

GoldenDB 基于 XtraBackup 实现备份恢复，支持全量/增量备份和单库/集群恢复，保证数据一致性。

原文标题：数据库系列之GoldenDB备份恢复

原文作者：牧羊人的方向

原文链接： http://mp.weixin.qq.com/s?__biz=MzI3MzUzMjIxNA==&mid=2247484320&idx=1&sn=9b8207afbbd87de284094e09367e1f0d&

冷月清谈：

GoldenDB 的备份恢复基于 Percona XtraBackup 工具，通过拷贝数据库文件和日志进行物理备份，速度较快。XtraBackup 备份流程包括记录 xtrabackup_log、拷贝数据文件、执行 FTWRL 获取一致性位点、拷贝结构文件和获取 binlog 位置。恢复流程则涉及启用内嵌 InnoDB 实例、回放日志、应用变更和回滚未提交事务。

GoldenDB 备份类型包括数据文件备份（全量和增量）、binlog 日志备份、活跃事务列表备份和集群元数据备份。数据备份策略支持定时和实时两种模式。binlog 日志默认每 2 小时备份一次。活跃事务列表每 30 秒查询一次，并每 60 秒归档一次。集群元数据备份包括全量备份和 DDL 操作时的增量备份。

备份过程会占用磁盘 IO 和网络 IO，并短暂持有 FTWRL 锁。恢复过程同样会占用磁盘 IO 和网络 IO，且数据库需要启停操作。建议备份操作避开批处理业务高峰期，恢复操作则需停业务并禁用代理。

GoldenDB 的备份流程包括：数据备份（定时和实时两种方式）、binlog 日志备份、活跃事务列表备份和集群元数据备份。恢复流程包括单 DB 恢复（全量和增量两种方式）和集群恢复。集群恢复涉及元数据恢复、每个 Group 的 DB 恢复、应用 binlog、回滚事务、主机 DB 打包和备机解压等步骤。

怜星夜思：

1、GoldenDB 使用 XtraBackup 进行备份，相比于 mysqldump 等逻辑备份工具，除了速度优势外，还有什么其他优点？
2、文章提到了 FTWRL 会导致 DML 堵塞，在实际生产环境中，如何降低 FTWRL 的影响？
3、GoldenDB 的增量备份是如何实现的？它与全量备份相比，有哪些优缺点？

原文内容

GoldenDB备份恢复是基于xtrabackup实现的，本文简要介绍GoldenDB备份恢复流程和实现原理。

1、备份恢复原理

1.1 xtrbackup备份恢复原理

Xtrbackup是基于innodb的在线备份工具，它通过拷贝数据库文件和日志的方式完成物理备份，因此相对逻辑备份速度会更快。

1）Xtrabackup备份流程

1. 记录xtrabackup_log。

2. 拷贝所有表的*. ibd数据文件和ibdata1文件到指定备份目录。

3. 执行命令：FLUSH TABLE WITH READ LOCK

4. 拷贝.frm、.MYD、.MYI、misc files。

5. 获取binlog日志的position

6. 执行命令UNLOCK TABLES

7. 结束xtrabackup备份任务，拷贝xtrabackup_log

Xtrabackup备份为了获取一致性位点，依赖于全局读锁（FTWRL）。在持有锁的这段时间，整个数据库实质上不能对外提供写服务的。此外，由于FTWRL需要关闭表，如有大查询，会导致FTWRL等待，进而导致DML堵塞的时间变长。即使是备库，也有SQL线程在复制来源于主库的更新，上全局锁时，会导致主备库延迟。

• Xtrabackup全量备份语句

xtrabackup --backup --target-dir=/mnt/data/all/ --user=root --password=123456 --socket=/tmp/mysqld.sock

• Xtrabackup增量备份语句

xtrabackup --backup --target-dir=/mnt/data/v1/ --incremental-basedir=/mnt/data/all/ --user=root --password=123456 --socket=/tmp/mysqld.sock

2）xtrabackup恢复流程

全备恢复会启用xtrabackup内嵌的innodb实例，回放xtrabackup日志xtrabackup_log，将提交的事务信息变更应用到innodb数据/表空间，同时回滚未提交的事务。

• 恢复语句

xtrabackup --copy-back --target-dir=/mnt/data/all/

1.2 备份恢复架构图

GoldenDB集群备份恢复是基于xtrabackup实现的，备份的时候将表数据、binlog、GTM活跃事务列表和元数据信息备份到备份存储上，恢复的时候指定备份的目录和文件进行恢复。

1.3 备份文件类型

1.3.1 data数据文件备份

Data数据文件备份是对表数据的备份，分为全量备份和增量备份。全量备份是拷贝所有表的*. ibd数据文件和ibdata1文件到指定备份目录，增量备份是拷贝所有表从上次全量备份产生的增量数据变化，文件后缀名. delta和.meta。数据备份完成后会拷贝拷贝.frm、.MYD、.MYI、misc files等表结构文件信息，最后将所有备份文件压缩在在“$dbip_FULL_$back_start_time.xbstream”文件内。

1.3.2 binlog日志备份

Binlog日志备份是备份数据节点$HOME/data/binlog目录下的binlog二进制文件，用于恢复过程中的数据一致性恢复。

1.3.3 活跃事务列表备份

活跃事务列表GTID备份用于保证全局节点恢复数据一致性。

1.3.4 集群元数据备份

集群的元数据备份包括数据字典，用户密码，索引信息等。

1.4 备份恢复策略

1）data数据备份策略

• 定时备份：根据定时备份策略定时发起，备份模式包括不备份、全量备份和增量备份

• 实时备份：在运维平台手动发起，满足特定场景下的实时备份和恢复需求

2）binlog日志备份策略

• 每个DB节点定时备份binlog日志，默认备份间隔2小时

• DBagent参数binlog_backup_interval设置

3）活跃事务列表备份策略

• 每隔30 s向GTM查询当前活跃事务列表信息和向DBagent查询当前binlog位置信息，并将查询结果信息保存在.current 文件中

• 每隔60 s查看.current文件是达到1 M，如果达到1 M，将.current文件归档到backup_root_directory配置路径下的子目录“Active_TX_Archive”下

• 由clustermanager.ini中参数active_tx_timing_query控制，1表示打开

4）集群元数据备份策略

• 全量备份：由CM通知，将整个集群元数据信息全部备份

• 增量备份：在DDL操作时，将相关数据字典信息和索引信息备份下来

1.5 备份恢复影响

1）备份过程的影响

• 磁盘IO：从本地磁盘读数据，占用磁盘读IO

• 网络IO：从本地上传到NFS共享目录，影响DB服务器的网络IO

• 表加锁：备份过程中会有短暂的flush table with read lock锁

因此，建议建议备份操作与批处理业务操作放在不同的时间段执行

2）恢复过程的影响

• 磁盘IO：数据文件拷贝到待恢复数据磁盘上，占用磁盘写IO

• 网络IO：从备份设备恢复数据到DB服务器上，影响DB服务器的网络IO

• 恢复过程中DB会有启停操作

因此，建议恢复过程中停业务，禁用proxy。

2、备份流程

2.1 data数据备份流程

Data数据备份分为定时备份和实时备份，二者在备份流程上区别不大。Data数据备份流程如下所示：

1. MDS将备份任务入库，对应的表是mds.timing_backup_task_info

2. MDS接收到备份结果后入库，相应的表是：gdb_cluster_backup_history_detail和goldendb_omm.gdb_cluster_backup_history

3. 备份文件保存在$HOME/backup_root

4. 备份可以指定主节点备份或者备节点备份

2.2 binlog日志备份流程

Binlog日志备份流程如下：

1. binlog日志通过DBagent定时任务备份，默认备份间隔为2小时

2. 备份文件默认保存在备份路径的BINLOG_BACKUP 目录下

3. 当前备份记录会保存在etc/dbagent_info/binlogbackup.info，作为下一个备份开始位置

4. 参数binlog_backup_interval控制是否备份binlog

2.3 活跃事务列表备份流程

活跃事务列表GTID备份流程：

1. CM每隔30 s向GTM查询当前活跃事务列表信息和向DBagent查询当前binlog位置信息，并将查询结果信息保存在备份路径的.current 文件中

2. CM每隔60 s查看.current文件是达到1 M，如果达到1 M，将.current文件归档到backup_root_directory配置路径下的子目录“Active_TX_Archive”下

2.4 集群元数据备份

集群元数据备份流程：

1. CM向MDS发送元数据备份，全量备份该集群下数据字典、密码信息和索引信息

2. DDL操作时，MDS会增量备份数据字典和索引信息

3、恢复流程

3.1 单个DB恢复流程

单个DB的恢复分为全量恢复和增量恢复：全量恢复仅使用全量备份文件进行恢复；增量恢复是使用全量备份文件再使用增量备份文件进行恢复。单DB恢复流程如下：

1. 获取恢复所需要的文件

2. 通过全量备份文件（及增量文件）恢复DB

3. 应用binlog 文件

4. 回滚恢复时刻的活跃事务

3.2 集群恢复流程

集群恢复也分为全量恢复和增量恢复，集群恢复流程如下：

1. 对集群的元数据进行恢复。

2. 恢复集群中每个Group的DB

1. 获取恢复所需要的文件。

2. 通过全量备份文件（及增量文件）恢复主机DB

3. 对主机DB应用binlog 文件

4. 对主机DB回滚恢复时刻的活跃事务

5. 对主机DB打tar包

6. 将主机生成的tar包解压到每个备机DB

3. 设定GTM的最大GTID值。

参考资料：

1. https://blog.csdn.net/jolly10/article/details/80065204

2. https://www.cnblogs.com/cchust/p/4603599.html

3. https://www.cnblogs.com/cchust/p/5452557.html

4. GoldenDB分布式数据库备份恢复技术

[Gale407v]

@solihawk1024

GoldenDB 的增量备份是如何实现的？它与全量备份相比，有哪些优缺点？

增量备份的恢复速度其实比全量备份慢，因为它需要应用多次备份文件。所以选择哪种备份方式需要根据实际情况权衡。

[MidnightOwl519]

@solihawk1024

GoldenDB 使用 XtraBackup 进行备份，相比于 mysqldump 等逻辑备份工具，除了速度优势外，还有什么其他优点？

除了楼上两位提到的速度和在线备份，XtraBackup 还能备份 MyISAM 表，虽然现在 MyISAM 用的少了，但一些老系统可能还在用，这点也算是一个小优势吧。

[RoaringTiger218]

@solihawk1024

GoldenDB 使用 XtraBackup 进行备份，相比于 mysqldump 等逻辑备份工具，除了速度优势外，还有什么其他优点？

关于XtraBackup 的优点，我补充一点，它可以支持在线备份，也就是在备份过程中数据库仍然可以正常提供服务，这对于 24 小时不间断运行的业务来说至关重要，减少了停机维护时间。

[MidnightOwl519]

@solihawk1024

文章提到了 FTWRL 会导致 DML 堵塞，在实际生产环境中，如何降低 FTWRL 的影响？

还可以考虑在业务低峰期进行备份，错开高峰期，可以最大程度地减少对用户的影响。

[ShimmeringSeal612]

@solihawk1024

GoldenDB 使用 XtraBackup 进行备份，相比于 mysqldump 等逻辑备份工具，除了速度优势外，还有什么其他优点？

对于“GoldenDB 使用 XtraBackup 进行备份，相比于 mysqldump 等逻辑备份工具，除了速度优势外，还有什么其他优点？”这个问题，我觉得很重要的一点是XtraBackup是物理备份，它直接拷贝数据文件，所以恢复速度也更快，这对于大型数据库来说非常关键。另外，物理备份对数据库版本依赖较小，迁移到不同版本的数据库也比较方便。

[CrystalBear411]

补充一下，增量备份的粒度可以控制，例如可以每天进行一次全量备份，然后每小时进行一次增量备份，这样可以根据需要恢复到不同的时间点，灵活性更高。

[RubyDragon432]

@solihawk1024

GoldenDB 的增量备份是如何实现的？它与全量备份相比，有哪些优缺点？

关于“GoldenDB 的增量备份是如何实现的？它与全量备份相比，有哪些优缺点？”，其实增量备份是基于上次全量备份的基础上，只备份变化的数据，这样可以大大减少备份的数据量和时间。它的优点是备份速度快，占用存储空间小。缺点是恢复的时候需要依赖全量备份和所有的增量备份，操作稍微复杂一些，如果中间某个备份文件丢失，会导致恢复失败。

[RedFox202]

@solihawk1024

文章提到了 FTWRL 会导致 DML 堵塞，在实际生产环境中，如何降低 FTWRL 的影响？

针对“文章提到了 FTWRL 会导致 DML 堵塞，在实际生产环境中，如何降低 FTWRL 的影响？”这个问题，我想说，可以考虑使用 Percona XtraBackup 的 --lock-ddl-per-table 选项，它可以对每个表进行 DDL 锁，而不是全局锁，从而减少对 DML 的影响。

[Arcane69f]

@solihawk1024

文章提到了 FTWRL 会导致 DML 堵塞，在实际生产环境中，如何降低 FTWRL 的影响？

降低 FTWRL 影响的另一个方法是优化数据库，例如减少长事务，确保查询语句的效率，这样可以缩短 FTWRL 持有锁的时间。