PostgreSQL 9.0.1を実行し、ストリーミングレプリケーションで1つの読み取り専用ミラーインスタンスを最新の状態に保ちます。業務時間のIOを削減するために、自動バキュームデーモンによってバキュームされないいくつかのテーブルを除き、自動バキュームがプライマリでオンになります。これらのテーブルは「マテリアライズドビュー」です。
毎晩真夜中に、自動バキュームから除外されたテーブルをクリーンアップするために、データベース全体にバキュームを実行します。そのプロセスがミラー全体に複製されるのか、それともミラーにも真空を設定する必要があるのか疑問に思っていますか？
1
素晴らしい質問です。ストリーミングレプリケーションは先行書き込みログを使用するため、VACUUMによる変更がログに記録されるかどうかに要約されます。
—
DerfK
興味深いことに、読み取り専用ミラーで自動バキュームをオンにしましたが、テーブル統計を見ると、実行されたことはありません。すべてのテーブルには0個のライブ/デッドタプルがリストされており、バキュームまたは分析の履歴は表示されていません。
—
スコットハーバート
developer.postgresql.org/pgdocs/postgres/hot-standby.html-25.5.2。クエリの競合の処理-「WALからのバキュームクリーンアップレコードの適用は、削除される行のいずれかをスナップショットが「見る」ことができるスタンバイトランザクションと競合します。............これは、VACUUM WALがログに記録されているため、私の質問に「はい」ですPGの達人からさらに情報を入手したいと思います！
—
スコットハーバート
動的ビューからのデータは、プライマリとスタンバイで異なることが予想されます。これらのビューはシステム関数を使用してデータを収集し、これらの関数は物理テーブルからではなく、メモリ内のデータ構造からデータを読み取ります。たとえば、プライマリでANALYZEを実行すると、スタンバイでもオプティマイザ統計（クエリプランニングに使用）が更新されますが、テーブルでANALYZEが実行された時間はpg_stat_user_tablesに反映されません。ログ。
—
グルジートシン
結論は、マスターで発生するAUTOVACUUMは、スレーブで実行されているAUTOVACUUMには影響しないということです、正しいですか？これが事実であると仮定すると、更新/削除がなく、挿入だけのテーブルがある場合、マスターで自動バキュームを無効にすることは可能ですが、書き込みと読み取りはスレーブで行われます。
—
ヘンリーチウ