直接结论：轮询REST API比查日志或数据库更可靠解耦；需校验status="completed"、error为空、end_time非空；超时按预期时长×1.5设；须处理Timeout（指数重试）、ConnectionError（告警退出）、401/404（人工介入）；响应字段须防御性读取，禁用硬索引。
直接结论：用 requests 轮询备份服务暴露的 REST API 端点，配合状态码和响应体字段判断任务是否成功，比解析日志或查数据库更可靠、解耦更强。
怎么设计轮询逻辑避免假成功
很多备份服务（如 mysqldump 封装的 Web 服务、Percona XtraBackup 的管理接口、或自研备份平台）返回 202 Accepted 后需轮询 /api/v1/backup/{task_id}。关键不是“有没有返回”，而是看字段：
-
"status"字段必须是"completed"（而非"running"或"queued"） -
"error"字段必须为null或空字符串（有些服务会返回"error": ""） - 建议同时校验
"end_time"是否非空，防止服务端未更新时间就返回 completed - 超时时间别设成固定 60 秒——大库备份可能耗时数小时，应按预期备份时长 × 1.5 设置
timeout_seconds
requests 调用时必须处理的三类错误
实际运行中，requests.get() 失败不只因为网络断开：
-
requests.exceptions.Timeout：API 响应慢于timeout=参数，需重试（建议最多 3 次，指数退避） -
requests.exceptions.ConnectionError：服务宕机或 DNS 失败，此时轮询无意义，应立即告警并退出 - HTTP 状态码为
404或401：说明task_id错误或 token 过期，不能当“任务失败”处理，要单独记录并人工介入
示例片段：
立即学习“Python免费学习笔记（深入）”；
try:
resp = requests.get(url, headers=headers, timeout=30)
resp.raise_for_status() # 抛出 4xx/5xx
except requests.exceptions.Timeout:
retry_count += 1
time.sleep(2 ** retry_count)
continue
except requests.exceptions.ConnectionError:
alert("Backup API unreachable")
break
如何从响应体安全提取状态字段
别直接写 resp.json()["status"]——字段缺失、类型错（比如 "status": 1）、JSON 解析失败都会崩。必须做防御性读取：
- 用
.get("status", "")替代方括号索引 - 对值做类型检查：
isinstance(status_val, str) and status_val.strip() - 错误信息优先读
resp.json().get("error") or resp.json().get("message")，不同服务字段名不统一 - 如果响应是
text/plain（比如某些 Shell 包装的 API），别硬转 JSON，先resp.text.strip()再匹配关键词如"SUCCESS"
为什么不用 MySQL 自身状态表轮询
有人想查 information_schema.PROCESSLIST 或自建 backup_tasks 表，但问题明显：
- 备份进程可能已退出，但状态表未及时更新（事务未提交、应用崩溃）
- 权限限制：监控脚本账号通常只有
SELECT，无法写入状态表 - 耦合度高：一旦备份逻辑换工具（比如从
mysqldump切到mydumper），状态表结构就得改 - API 是契约接口，字段语义明确；数据库表是实现细节，随时可能重构
真正难的是处理长时间运行任务的中断恢复——比如轮询中途机器重启，得靠 task_id 幂等查询，而不是重新触发备份。
