日志备份故障处理

本文列出了在使用日志备份功能时,可能会遇到的故障及相应的解决方法。

如果遇到未包含在此文档且无法解决的问题,可以在 AskTUG 社区中搜索答案或提问。

在使用 br restore point 命令恢复下游集群后,无法从 TiFlash 引擎中查询到数据,该如何处理?

在 v6.2.0 版本中,使用 PITR 功能恢复下游集群数据时,并不支持恢复下游的 TiFlash 副本。恢复数据之后,需要执行如下命令手动设置 schema 或 table 的 TiFlash 副本:

ALTER TABLE table_name SET TIFLASH REPLICA @count;

在 v6.3.0 及以上版本,PITR 恢复数据完成之后,BR 会自动依照上游对应时刻的 TiFlash 副本数量执行 ALTER TABLE SET TIFLASH REPLICA 语句。你可以通过以下 SQL 语句检查 TiFlash 副本的设置状态:

SELECT * FROM INFORMATION_SCHEMA.tiflash_replica;

需要注意,PITR 目前不支持在恢复阶段直接将数据写入 TiFlash ,因此 TiFlash 副本在 PITR 完成恢复之后并不能马上可用,而是需要等待一段时间从 TiKV 节点同步数据。要查看同步进度,可以查询 INFORMATION_SCHEMA.tiflash_replica 表中的 progress 信息。

日志备份任务的 status 变为 ERROR,该如何处理?

在运行日志备份过程中,遇到错误后经过重试也无法恢复的故障场景,任务会被设置为 ERROR 状态,如:

br log status --pd x.x.x.x:2379 ● Total 1 Tasks. > #1 < name: task1 status: ○ ERROR start: 2022-07-25 13:49:02.868 +0000 end: 2090-11-18 14:07:45.624 +0000 storage: s3://tmp/br-log-backup0ef49055-5198-4be3-beab-d382a2189efb/Log speed(est.): 0.00 ops/s checkpoint[global]: 2022-07-25 14:46:50.118 +0000; gap=11h31m29s error[store=1]: KV:LogBackup:RaftReq error-happen-at[store=1]: 2022-07-25 14:54:44.467 +0000; gap=11h23m35s error-message[store=1]: retry time exceeds: and error failed to get initial snapshot: failed to get the snapshot (region_id = 94812): Error during requesting raftstore: message: "read index not ready, reason can not read index due to merge, region 94812" read_index_not_ready { reason: "can not read index due to merge" region_id: 94812 }: failed to get initial snapshot: failed to get the snapshot (region_id = 94812): Error during requesting raftstore: message: "read index not ready, reason can not read index due to merge, region 94812" read_index_not_ready { reason: "can not read index due to merge" region_id: 94812 }: failed to get initial snapshot: failed to get the snapshot (region_id = 94812): Error during requesting raftstore: message: "read index not ready, reason can not read index due to merge, region 94812" read_index_not_ready { reason: "can not read index due to merge" region_id: 94812 }

此时,你需要根据错误提示来确认故障的原因并恢复故障。确认故障恢复之后,可执行下面的命令来恢复备份任务:

br log resume --task-name=task1 --pd x.x.x.x:2379

备份任务恢复后,再次查询 br log status,任务状态变为正常,备份任务继续执行。

● Total 1 Tasks. > #1 < name: task1 status: ● NORMAL start: 2022-07-25 13:49:02.868 +0000 end: 2090-11-18 14:07:45.624 +0000 storage: s3://tmp/br-log-backup0ef49055-5198-4be3-beab-d382a2189efb/Log speed(est.): 15509.75 ops/s checkpoint[global]: 2022-07-25 14:46:50.118 +0000; gap=6m28s

执行 br log resume 命令恢复处于暂停状态的任务时报 ErrBackupGCSafepointExceeded 错误,该如何处理?

Error: failed to check gc safePoint, checkpoint ts 433177834291200000: GC safepoint 433193092308795392 exceed TS 433177834291200000: [BR:Backup:ErrBackupGCSafepointExceeded]backup GC safepoint exceeded

暂停日志备份任务后,备份程序为了防止生成变更日志的 MVCC 数据被 GC,暂停任务程序会自动将当前备份点 checkpoint 设置为 service safepoint,允许保留最近 24 小时内的 MVCC 数据。当超过 24 小时后,备份点 checkpoint 的 MVCC 数据已经被 GC,此时程序会拒绝恢复备份任务。

此场景的处理办法是:先执行 br log stop 命令来删除当前的任务,然后执行 br log start 重新创建新的日志备份任务,同时做一个全量备份,便于后续做 PITR 恢复操作。