あなたの説明は合理的な要約です、はい。大まかに次の 3 つのレベルがあります。
"UPDATE mytable SET a=nextval('some_sequence'), b=current_timestamp WHERE id=$1" のような高レベルの SQL クエリ
「主キー値id=42のテーブルabcで、タプルが新しい値に更新されました(a = 11、b = 12314234321)」のような論理行の変更。これらはこの形式でディスクに記録されるのではなく、executor 内で生成される中間段階であり、次のように変換されます。
ブロック レベルの変更が xlog に書き込まれ、次にヒープに書き込まれます。たとえば、「テーブルスペース 1 に格納されている dboid 9191 の relfilenode 12312.1 に関連して、ブロック 41231 バイト オフセット 0x0012 が 0xde 0xad 0xbe 0xef 0x01 に変更されました」
(すべての数字は完全に構成されています)
WAL ベースのレプリケーションは最下位レベルで行われ、データベース内のファイルへのブロックの変更が記録されます。わかりました。それほど単純ではありませんが、レプリケーションを理解するためには十分でしょう。
スタンドアロン マスターでは、SQL が実行され、WAL および に記録される行の変更が生成されshared_buffers
ます。次に、WAL が再生され、変更がデータベース ヒープに適用されます。(繰り返しますが、bgwriter によるダーティ ライトバックなどがあるため、それほど単純ではありませんが、今のところはそれで十分です)。
WAL ベースのレプリケーションでは、マスターが WAL を維持し、レプリカに送信するか、アーカイブします。レプリカは、独自の WAL を作成して再生する代わりに、別の場所のマスターから WAL を再生し、それを使用してデータベース ヒープとそのshared_buffers
.
次に、ファイルベースのレプリケーションの両方のケースで、スレーブサーバーはどのようにログ更新を適用しますか?
レプリカはrestore_command
、前のアーカイブの最後に達すると、次の WAL アーカイブを要求するために を実行します。次に、回復プロセスが WAL アーカイブの読み取りを開始し、レコードごとに処理します。
ソースで がどのようにrestore_command
使用されているかを見て、それがどのように呼び出されているかを確認してください。
とストリーミング レプリケーション?
レプリカの walreceiver はアップストリームの walsender に接続し、wal レコードを受信します。これらはファイルに書き込まれ、リカバリ プロセスによって読み取られます。
どちらの場合もリカバリ部分は同じですが、違いはアップストリームから WAL を受け取る方法だけです。マスターでクラッシュ リカバリを実行する場合のリカバリもほぼ同じです。それもWALを再生するだけです。
具体的には、どのプロセスがこれを処理し、どのように処理するのでしょうか?
このための最良のリファレンスは、ソース コード、特にコメントと README ファイルです。
pg_xlogdump
を使用して、WAL に実際に何が含まれているかを確認することを強くお勧めします。次に、関連する WAL レコードのドキュメントを読んで、各レコード タイプの機能を理解してください。
また、src/backend/access/transam/README
とを読むことから始めsrc/backend/access/transam/xlog.c
ます。
関連する README に既に記載されている内容を繰り返すつもりはありません。これは、私の説明よりも正しい可能性が高いためです。