金点分享 | 数据库系列之GoldenDB备份恢复

2022-03-15 00:00:00 数据 文件 备份 增量 恢复

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。

  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值。


来源 https://mp.weixin.qq.com/s/o3GzcUlvwVCERtppE18Ang

相关文章