db-replicas-views

db-replicas-views（M17）

読み取りレプリカとマテリアライズドビューは読み取りをスケールさせますが、どちらも古いデータを生じさせるため、アプリケーションが最新のデータを前提としていると、正確性が気づかないうちに損なわれます。これはパフォーマンスとスケーラビリティ（軸 performance）に関する懸念事項であり、リレーショナルの Escala w12（M16／M2／M9 と共有）にフィードされます。

チェック内容

1. 書き込み後の読み取り — 書き込み直後に同じデータを読み取る際、まだ追いついていない非同期レプリカに読み取りがルーティングされる可能性があります。ユーザーがコメントを書き込んだ後、次のページ読み込みでレプリカから読み取ると、コメントが「消えた」ように見えます。直後の読み取りをプライマリにルーティングするか、必要に応じて同期読み取りまたはクォーラム読み取りを使うことを推奨します。
2. マテリアライズドビューのリフレッシュ — MATERIALIZED VIEW をライブデータのようにクエリしているものの、手動でしかリフレッシュされない、実行頻度の低い cron でリフレッシュされる、または一度もリフレッシュされないため、古いデータを返します。CONCURRENTLY を指定しない REFRESH MATERIALIZED VIEW（読み取りをロックします）と、目に見えるリフレッシュスケジュールのないビューにフラグを立てます。

スコア／軸

performance のみにフィードされます（リレーショナルの 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 — CONCURRENTLY を指定しない REFRESH MATERIALIZED VIEW （severity:2、warn、DDL から established、fixable: proposed）。

各検出結果では、evidence.observed にルーティング設定／ビュー DDL／カタログ行をそのまま引用し、verification.reproduce には $DATABASE_URL を参照する上記のクエリを指定します。expected_impact は確信度のタグを付けた段階的な値とし（裸の % は不可）、確信度も明記します。

誠実さ

• レプリカのデータが古くなることは、ほとんどの分析／レポート読み取りでは設計どおりです。「レプリカは危険」と一律に指摘するのではなく、読み取り経路で書き込んだばかりのデータが必要な場合に限ってフラグを立てます。
• 測定できないラグの数値や古いデータを読む確率を決して引用しないでください。ラグに関する主張は、Tier-1 で確認された場合に established とし、それ以外は directional とします。
• REFRESH … CONCURRENTLY にはマテリアライズドビュー上の一意インデックスが必要です。修正プレビューでは、この前提条件に言及してください。ルーティング／リフレッシュの変更は proposed／advisory であり、決して auto にはしません。