基于 EBS 快照备份恢复的常见问题
本文介绍基于 EBS 快照备份恢复的常见问题以及解决方案。
备份问题
使用基于 EBS 快照备份,你可能遇到以下问题:
升级后备份无法工作
从低版本的集群升级到 v6.5.0+ 后,进行卷快照备份,备份可能会失败,错误信息如下:
error="min resolved ts not enabled"
原因是 PD 配置 min-resolved-ts-persistence-interval
值为 0,即关闭了 PD 全局一致性 min-resolved-ts 服务。EBS 卷快照需要此服务获取集群全局一致性时时间戳。可通过 SQL 语句或 pd-ctl 检查配置:
使用 SQL 语句检查 PD
min-resolved-ts-persistence-interval
配置:SHOW CONFIG WHERE type='pd' AND name LIKE '%min-resolved%'如果全局一致性 min-resolved-ts 服务关闭,则输出显示如下:
+------+------------------------------------------------+------------------------------------------------+-------+ | Type | Instance | Name | Value | +------+------------------------------------------------+------------------------------------------------+-------+ | pd | basic-pd-0.basic-pd-peer.tidb-cluster.svc:2379 | pd-server.min-resolved-ts-persistence-interval | 0s | +------+------------------------------------------------+------------------------------------------------+-------+ 1 row in set (0.03 sec)如果全局一致性 min-resolved-ts 服务打开,则输出显示如下:
+------+------------------------------------------------+------------------------------------------------+-------+ | Type | Instance | Name | Value | +------+------------------------------------------------+------------------------------------------------+-------+ | pd | basic-pd-0.basic-pd-peer.tidb-cluster.svc:2379 | pd-server.min-resolved-ts-persistence-interval | 1s | +------+------------------------------------------------+------------------------------------------------+-------+ 1 row in set (0.03 sec)使用 pd-ctl 工具检查 PD
min-resolved-ts-persistence-interval
配置:kubectl -n ${namespace} exec -it ${pd-pod-name} -- /pd-ctl min-resolved-ts如果全局一致性 min-resolved-ts 服务关闭,则输出显示如下:
{ "min_resolved_ts": 439357537983660033, "persist_interval": "0s" }如果全局一致性 min-resolved-ts 服务打开,则输出显示如下:
{ "is_real_time": true, "min_resolved_ts": 439357519607365634, "persist_interval": "1s" }
解决方案(二选一):
使用 SQL 语句更新 PD
min-resolved-ts-persistence-interval
配置:SET CONFIG pd `pd-server.min-resolved-ts-persistence-interval` = "1s"使用 pd-ctl 工具更新 PD
min-resolved-ts-persistence-interval
配置:kubectl -n ${namespace} exec -it ${pd-pod-name} -- /pd-ctl config set min-resolved-ts-persistence-interval 1s
备份无法启动或者启动后立即失败
issue 链接:#4781
现象一:应用备份 CRD yaml 文件后,pod/job 并没有创建。备份无法启动。
通过以下命令查看 TiDB Operator pod 信息:
kubectl get po -n ${namespace}查看 TiDB Operator controller manager pod 的 log 信息:
kubectl -n ${namespace} logs ${tidb-controller-manager}检查 log 信息是否包含以下错误:
```shell metadata.annotations: Too long: must have at most 262144 bytes, spec.template.annotations: Too long: must have at most 262144 bytes ```原因:因为 TiDB 使用 annotation 来传递 PVC 或 PV 的配置信息,每个备份 job 的 annotation 最大的限制是 256 KB,当 TiKV 集群规模较大时,PVC 或 PV 的信息会大于 256 KB 导致 Kubernetes API 调用失败。
现象二:应用备份 CRD yaml 文件后,pod/job 创建成功。备份立即失败。
通过现象一类似的方法查看 backup job 的 log 信息,得到以下错误:
exec /entrypoint.sh: argument list too long原因:TiDB Operator 使用环境变量的方式,在 backup pod 启动前,把 PVC 或 PV 的信息注入 backup pod 环境变量中,并启动备份任务。因操作系统环境变量限制在 1 MB 左右,当 PVC 或 PV 配置信息大于 1 MB 时,backup pod 无法取得环境变量,导致备份失败。
问题场景:集群包含大量的 TiKV 节点 (40+) 或者配置了较多卷,且使用了 TiDB Operator v1.4.0-beta.2 或者更早的版本。
解决方案:升级 TiDB Operator 到最新版本。
备份失败后,备份 CR 无法删除
issue 链接:#4778
现象:删除备份 CR 卡住。
问题场景:使用了 TiDB Operator 版本 v1.4.0-beta.2 或者更早的版本。
解决方案:升级 TiDB Operator 到最新版本。
备份失败
相关的问题:#13838
现象:应用备份 CRD yaml 文件后,pod/job 创建成功。备份立即失败。
检查备份 log 信息是否包含以下错误:
GC safepoint 437271276493996032 exceed TS 437270540511608835
问题场景:在大集群 (20+ tikv) 中,集群使用 BR 进行大规模数据恢复后,再发起卷备份操作。
解决方案:打开 grafana ${cluster-name}
-TiKV-Details 监控页面,展开 Resolved-TS,检查 Max Resolved TS gap 面板。确认是否有数值较大(大于 1 min) 的 Max Resolved TS,找到对应的 TiKV 重启。
恢复问题
使用基于 EBS 快照恢复,你可能遇到以下问题:
恢复集群失败,报错 keepalive watchdog timeout
现象:BR 数据恢复子任务失败,第一个 BR 恢复子任务恢复成功 (volume complete),第二个子任务失败。打印失败任务 log,发现以下 log 信息:
error="rpc error: code = Unavailable desc = keepalive watchdog timeout"
问题场景:数据规模较大且使用的 v6.3.0 版本的 TiDB 集群。
解决方案:
升级 TiDB 集群到 v6.4.0 或者更高的版本。
编辑 TiDB 集群配置,调大 TiKV
keepalive
参数:config: | [server] grpc-keepalive-time = "500s" grpc-keepalive-timeout = "10s"
恢复时间太长(大于 2 小时)
问题场景:使用 TiDB v6.3.0 的版本,或者 v6.4.0 版本。
解决方案:
升级 TiDB 集群版本至 v6.5.0+。
在 BR spec 中,临时提升卷性能进行恢复,待恢复完成后,再手动降低卷性能参数。通过指定参数来获得更高的恢复卷配置, 例如指定
--volume-iops=8000
,以及--volume-throughput=600
或者更高配置。spec: backupType: full restoreMode: volume-snapshot serviceAccount: tidb-backup-manager toolImage: pingcap/br:v8.1.0 br: cluster: basic clusterNamespace: tidb-cluster sendCredToTikv: false options: - --volume-type=gp3 - --volume-iops=8000 - --volume-throughput=600