質問とコンテキスト
PostgreSQL 18のパブリッシャーが、分析用サブスクリプション、監査用コンシューマー、および一時的なバックフィルジョブに対応しています。一部のコンシューマーがオフラインのままになっており、WALのリサイクルが妨げられ、ディスクが急速に消費されています。idle_replication_slot_timeoutに対するロールアウト、オブザーバビリティ、無効化、およびリカバリを設計してください。
面接官が評価するポイント
- スロットがWALを保持する理由と、アイドルタイムアウトが実際にいつ有効になるかを説明できるか。
- ロジカルスロットとフィジカルスロット、サブスクリプションのリカバリ、および再構築の境界を区別できているか。
- 削除のセーフガード、アラート、監査可能性、およびディスク圧迫の制御を設計できるか。
- コンシューマーの復旧後に、再スナップショット（resnapshot）、再構築、または人間による確認のパスを提供できるか。
まず確認すべき明確化のための質問
コンシューマーのセマンティクス
各スロットは何を提供していますか？ダウンタイム中のデータ損失は許容されますか、それともコンシューマーは特定の境界から再開する必要がありますか？一時的なバックフィルスロットには明示的な最大有効期間がありますか？
リソースと時間枠
WALとディスクの残量はどれくらいあり、各スロットのrestart_lsnとコンシューマーの遅延（lag）はどの程度ですか？チェックポイントはどのくらいの頻度で実行されますか？メンテナンスウィンドウ中にサブスクリプションやコンシューマーを再構築できますか？
変更権限
自動無効化は誰が承認しますか？事前にコンシューマーの確認、チケット、または二重承認が必要ですか？ディザスタリカバリやコンプライアンス監査のために恒久的に保護する必要があるスロットはどれですか？
30秒での回答
各スロットの所有者、目的、アクティビティ、および保持されているWALのインベントリを作成し、クリティカル、リカバリ可能、一時的の各スロットに分類します。リカバリ可能なスロットには事前アラート付きのアイドルタイムアウトを設定し、クリティカルなスロットは自動無効化を行わずにアラートのみを発報します。無効化はチェックポイント中に発生するため、スロットの状態、理由、およびディスクメトリクスを監査証跡に記録します。復旧時は、データ損失契約に従って再開、再スナップショット、またはバックアップリストアを選択します。
詳細なソリューション
1. スロット保持の仕組みを説明する
レプリケーションスロットにより、パブリッシャーは未確認のコンシューマーが必要とするWALを保持します。restart_lsnが遅れているロジカルスロットはWALのライフタイムを延ばし、オフラインのコンシューマーは通常の増加を無制限のリスクへと変化させる可能性があります。ポリシーを設定する前に、スロット名、データベース、プラグイン、コンシューマー、および所有者を記録します。
2. スロットを分類する
クリティカル、リカバリ可能、および一時的のクラスを使用します。クリティカルなスロットには人的対応とより大きなキャパシティバジェットが必要です。リカバリ可能なスロットは警告後に期限切れとなる場合があります。一時的なスロットは作成時に有効期限が設定されます。アプリケーションがクリティカルなスロットを使い捨てとしてマークできないよう、保護対象リストはコンシューマーが送信する設定の外部に保持します。
3. アイドルタイムアウトを正しく使用する
PostgreSQL 18のidle_replication_slot_timeoutは、設定された期間を超えてレプリケーション接続によって使用されていないスロットを無効化します。0に設定すると無効になります。無効化はチェックポイント時にトリガーされるため、実際の時間は閾値を超えることがあります。この設定はサーバーレベルのものであり、スロットごとのビジネス分類を置き換えるものではありません。
4. オブザーバビリティとアラートを構築する
スロットタイプ、データベース、restart_lsn、アクティブ状態、無効化の理由、フェイルオーバーまたは同期状態を確認するために、pg_replication_slotsを定期的に読み取ります。保持されているWALバイト数と最古スロットの経過時間を計算します。増加率、ディスクのヘッドルーム、アイドル時間、および切迫した無効化について、所有者とリカバリランブックを含めてアラートを発報します。
5. チェックポイントと競合状態を処理する
タイムアウトの評価はチェックポイント中に実行されるため、設定された閾値は正確な期限ではありません。コンシューマーは閾値付近で再接続する可能性があります。最終使用時刻、チェックポイント時刻、および最終的な無効化理由を記録してください。ポリシーを変更したりスロットを削除したりする前に、同名作成、スタンバイ同期、または進行中のサブスクリプションリカバリがないか確認します。
6. リカバリを設計する
無効化後、コンシューマーは以前の境界が引き続き利用可能であると想定することはできません。ダウンタイム中の損失が許容される場合は、新しいスロットを作成して初期スナップショットを取得します。損失が許容されない場合は、バックアップまたは保持されたWALからリストアし、サブスクリプションを再構築します。古いスロット、データ境界、スナップショット時刻、および検証証拠を記録します。
7. キャパシティと変更管理を連携させる
WALディレクトリが制限に近づいた場合、低優先度のバックフィルを一時停止し、WALを生成するバッチ処理を制限して、プライマリの可用性を保護します。未知のスロットを削除してはなりません。タイムアウトの変更を段階的にロールアウトし、WALの増加、チェックポイント、レプリケーション遅延、およびコンシューマーエラーを観察してから、ポリシーを調整します。
優れた回答の例
所有者を記録したスロットカタログを維持し、スロットをクリティカル、リカバリ可能、一時的に分類します。リカバリ可能および一時的なスロットにはアイドルタイムアウトを設定し、クリティカルなスロットはアラートのみを発報します。無効化はチェックポイント中に発生するため、監視システムによってチェックポイント時刻と実際の理由を記録します。日次レポートで保持WAL、アイドル時間、およびディスクリスクを計算し、閾値に達した場合はバックフィルを一時停止して所有者に通知します。無効化後のリカバリパスでは、データ損失契約に従って再スナップショット、バックアップリストア、または承認された再構築を選択し、すべてのアクションを監査対象とします。
よくある間違い
- チェックポイントを無視し、タイムアウトが切れた瞬間にスロットが無効化されると思い込む。
- すべてのスロットに短いタイムアウトを適用し、ディザスタリカバリ用や監査用のスロットを削除してしまう。
restart_lsnから保持WALを計算せず、activeのみを監視する。- データやスナップショットの境界が失われたかどうかを判断せずにコンシューマーを再接続する。
- ディスクインシデント発生時に未知のスロットを削除し、稼働中のレプリケーションパスを破壊してしまう。
- 所有者、保護リスト、または実行可能なリカバリランブックが存在しない。
フォローアップの質問と回答
idle_replication_slot_timeoutはいつ有効になりますか？
スロットがレプリケーション接続によって設定値より長く使用されていない状態になった後、その後のチェックポイント中に無効化がトリガーされるため、遅延が発生する場合があります。
フィジカルスロットも自動的に期限切れにすべきですか？
それはディザスタリカバリの契約に依存します。フィジカルスロットはスタンバイによって必要とされる場合があるため、自動無効化を許可する前に別の保護メカニズムを確認してください。
1つのスロットによって保持されているWALはどのように計算しますか？
現在のWAL位置とスロットのrestart_lsnを比較し、スロットごとの最も古い位置、増加率、およびディスクヘッドルームを集計します。active単体では容量リスクを把握できません。
復帰したコンシューマーは再開できますか？
必要なWALがまだ存在し、スロットが有効なままである場合に限られます。無効化またはWAL削除後は、再スナップショット、バックアップリストア、または明示的なデータギャップの許容が必要です。
一時的なバックフィルスロットの放置・リークを防ぐにはどうすればよいですか？
作成時に有効期限と所有者を記録し、個別にアラートを設定し、無効化の前に確認状態へと移行させ、事後にWALのリサイクルが回復することを確認します。