ProductionDataBaseSync_DataMacro

AllForCompany/ProductionDataBaseSync_DataMacro

Fork 0

Commit Graph

Author	SHA1	Message	Date
Misaka_Company	03d7bcea39	feat(health): 被动式健康检查 API（FastAPI，覆盖服务健康+数据健康）在同步进程内内置 FastAPI/uvicorn HTTP endpoint (GET /health)，返回结构化健康快照，便于运维/监控被动探活： - 服务健康：cycle_lag（核心指标，超过 3×poll_interval 判 unhealthy）、队列状态（pending/error/dead/cleaned 实时查）、capture 累计（enqueued/ deferred/aged_out）、最近 cycle 时间/耗时/错误。 - 数据健康：解析最近一次定时 compare_ids 报告（不跑全量 compare 太重）、实时查 SyncLogArchive 异常痕迹（AgedOut/降级）、SyncQueue dead 行样本。 status 三态：healthy(200) / degraded(503, 有dead/error/aged_out/compare 不一致) / unhealthy(503, 主循环停滞)。状态码映射便于按码告警。线程模型：uvicorn 占主线程，capture/apply/cleanup 循环跑后台 daemon 线程， NSSM 停服务时主线程退出、daemon 自动终止。health.enabled=false 时退化为旧行为（同步循环占主线程）。Web 层(routes/)与业务逻辑(HealthChecker) 解耦，后期加运维接口（compare触发/死信管理/metrics）零结构改动。零 SQL/零 schema 改动。新增依赖 fastapi/uvicorn[standard]。	2026-08-05 12:13:14 +08:00
Misaka_Company	7cef5153e6	fix(capture): 读不到源行时按日志年龄延迟重试，根治降级Delete致数据丢失 Insert/Update 日志回读不到源行时，旧逻辑无条件降级为 Delete，在 ACE 引擎可见性延迟（批量插入约11s窗口）下误伤，导致该 Insert 的行不仅没进 SQL 反而被空打 Delete 并清理 Access 日志，数据永久丢失（8/4 事件根因：氩弧焊.接收 16255-16259 缺失）。改为按 Access 日志年龄（capture_defer_seconds=60）决定动作： - 年龄 < 阈值：DEFER，跳过不入队，Access 日志保留，下一轮 cycle 重读； - 年龄 >= 阈值：AGED-OUT，入队直接标 dead 待人工（usp_SyncApply 只选 pending，不会执行任何破坏性 SQL），归档表记 ProcessedOperateType=AgedOut。零 schema/SQL 改动：cleanup 只删 Status=applied 的日志，DEFER 行不入队则无 applied 行、AGED-OUT 标 dead 非 applied，两者 Access 日志均保留，与既有 cleanup/apply/service 逻辑天然自洽。详见 docs/plan-capture-defer-by-age.md 与 docs/incremental-sync-flow.md。	2026-08-05 11:00:58 +08:00
Misaka_Company	fb025bb061	chore: project scaffold for access-datamacro sync	2026-07-14 11:12:34 +08:00

Author

SHA1

Message

Date

Misaka_Company

03d7bcea39

feat(health): 被动式健康检查 API（FastAPI，覆盖服务健康+数据健康）

在同步进程内内置 FastAPI/uvicorn HTTP endpoint (GET /health)，返回结构化
健康快照，便于运维/监控被动探活：

- 服务健康：cycle_lag（核心指标，超过 3×poll_interval 判 unhealthy）、
  队列状态（pending/error/dead/cleaned 实时查）、capture 累计（enqueued/
  deferred/aged_out）、最近 cycle 时间/耗时/错误。
- 数据健康：解析最近一次定时 compare_ids 报告（不跑全量 compare 太重）、
  实时查 SyncLogArchive 异常痕迹（AgedOut/降级）、SyncQueue dead 行样本。

status 三态：healthy(200) / degraded(503, 有dead/error/aged_out/compare
不一致) / unhealthy(503, 主循环停滞)。状态码映射便于按码告警。

线程模型：uvicorn 占主线程，capture/apply/cleanup 循环跑后台 daemon 线程，
NSSM 停服务时主线程退出、daemon 自动终止。health.enabled=false 时退化为
旧行为（同步循环占主线程）。Web 层(routes/)与业务逻辑(HealthChecker)
解耦，后期加运维接口（compare触发/死信管理/metrics）零结构改动。

零 SQL/零 schema 改动。新增依赖 fastapi/uvicorn[standard]。

2026-08-05 12:13:14 +08:00

Misaka_Company

7cef5153e6

fix(capture): 读不到源行时按日志年龄延迟重试，根治降级Delete致数据丢失

Insert/Update 日志回读不到源行时，旧逻辑无条件降级为 Delete，在 ACE
引擎可见性延迟（批量插入约11s窗口）下误伤，导致该 Insert 的行不仅没进
SQL 反而被空打 Delete 并清理 Access 日志，数据永久丢失（8/4 事件根因：
氩弧焊.接收 16255-16259 缺失）。

改为按 Access 日志年龄（capture_defer_seconds=60）决定动作：
- 年龄 < 阈值：DEFER，跳过不入队，Access 日志保留，下一轮 cycle 重读；
- 年龄 >= 阈值：AGED-OUT，入队直接标 dead 待人工（usp_SyncApply 只选
  pending，不会执行任何破坏性 SQL），归档表记 ProcessedOperateType=AgedOut。

零 schema/SQL 改动：cleanup 只删 Status=applied 的日志，DEFER 行不入队
则无 applied 行、AGED-OUT 标 dead 非 applied，两者 Access 日志均保留，
与既有 cleanup/apply/service 逻辑天然自洽。

详见 docs/plan-capture-defer-by-age.md 与 docs/incremental-sync-flow.md。

2026-08-05 11:00:58 +08:00

Misaka_Company

fb025bb061

chore: project scaffold for access-datamacro sync

2026-07-14 11:12:34 +08:00

3 Commits