db-replicas-views

db-replicas-views (M17)

只读副本和物化视图可以扩展读取能力，但两者都会引入陈旧数据；如果应用假定数据是最新的，就会悄然破坏正确性。这属于性能与扩展（轴 performance）问题；对应关系型 Escala w12（与 M16/M2/M9 共用）。

检查内容

1. 读己之写 — 写入后立即读取同一数据，而该读取可能被路由到尚未追上的异步副本。用户写入一条评论，下一次加载页面时从副本读取，结果评论“消失了”。建议将紧随写入的读取路由到主库，或在需要时使用同步／法定人数读取。
2. 物化视图刷新 — 查询 MATERIALIZED VIEW 时将其视为实时数据，但该视图仅手动刷新／通过缓慢的 cron 刷新／从未刷新，因此提供的是陈旧数据。标记不带 CONCURRENTLY 的 REFRESH MATERIALIZED VIEW（会锁定读取操作），以及没有可见刷新计划的视图。

评分／轴

仅计入性能（关系型 Escala w12；在适用情况下，副本／视图问题对应 NoSQL 配置文件中的 Query／Escala 类别）。

Tier-0（静态）

检测副本路由配置（ORM／驱动程序中的读写分离、多条连接 URL）、针对同一实体的写入→读取序列、CREATE MATERIALIZED VIEW DDL，以及任何 REFRESH 调用（以及是否使用 CONCURRENTLY）。实际的复制延迟和刷新时效属于运行时信息；Tier-0 的结果为 needs_api（绝不会静默通过）。

Tier-1/2（验证查询，Postgres）

-- replication lag (Tier-1, on primary):
SELECT client_addr, state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag_bytes
FROM pg_stat_replication;
-- matview presence + populated state:
SELECT matviewname, ispopulated FROM pg_matviews;

方法 query_stat / schema_introspect。可测量的 replay_lag_bytes 可将读己之写风险确认为 established；物化视图的刷新时效需要应用的刷新计划或 Tier-2 观测——若缺少这些信息，陈旧数据状态为 directional。

发现项

按 schema/finding.schema.json 输出发现项。示例：

• M17.comments.read_your_writes_on_replica — 写入后立即进行的读取被路由到副本 （severity:3、warn，轴为 performance，静态置信度为 directional／Tier-1 置信度为 established， fixable: proposed — 将读取路由到主库）。
• M17.dashboard.matview_no_refresh — 物化视图没有可见的刷新计划 （severity:2、warn，directional／needs_api，fixable: advisory）。
• M17.dashboard.refresh_blocks_readers — REFRESH MATERIALIZED VIEW 不带 CONCURRENTLY （severity:2、warn，根据 DDL 确认为 established，fixable: proposed）。

每项发现：evidence.observed 会逐字引用路由配置／视图 DDL／目录行； verification.reproduce 是上方引用 $DATABASE_URL 的查询；expected_impact 按区间给出 并标注置信度（不使用没有依据的百分比）。

诚实原则

• 对大多数分析／报表读取而言，副本数据陈旧是符合设计的；仅当读取路径需要读取其自身刚写入的数据时才标记，不要笼统地声称“副本很危险”。
• 绝不引用无法测量的延迟数字或陈旧读取概率；要将延迟声明为 established，必须有 Tier-1 依据，否则应标为 directional。
• REFRESH … CONCURRENTLY 要求物化视图上存在唯一索引；请在修复预览中注明这一前提。路由／刷新更改只能标记为 proposed／advisory，绝不能标为 auto。