Postgres 先行書き込みログ

#イントロ

これは、Postgres の論理レプリケーションについて詳しく説明する第 2 部です。パート 1 を最後まで読んでいない場合は、 レプリカのアイデンティティ、必ずチェックしてください。このパートでは、先行書き込みログの仕組み、ログ先行書き込みを使用する理由、およびそのさまざまなコンポーネントと設定について説明します。

#先行書き込みログ

先行書き込みログは、論理レプリケーションに必要な 4 つのコンポーネントのうちの 1 つです。これらはデータの耐久性を確保するために使用され、データの一貫性が保たれ、データ損失から保護されることを意味します。サーバー マシンに障害が発生した場合でも、先行書き込みログにより変更が保持されることが保証されます。

Postgres では WAL がデフォルトで有効になっていますが、ディスク容量が WAL ファイルを使用するために必要な要件をすべて満たしていることが重要です。さまざまなパラメーターを構成して、ログに書き込まれる情報の量とログに含まれる共有メモリの量を決定できます。

#先行書き込みログはどのように機能しますか?

先行書き込みログは、各状態の変更を、一意の識別子を持つコマンドとして追加専用ファイル内に保存します。この追加専用ファイルの各コマンドには、変更を複製するために必要なすべての情報が含まれています。

これらのコマンドは、変更が行われる前に保存されます。変更がコミットされると、レコードにマークが付けられ、変更がすでに行われたことがシステムに示されます。システムに障害が発生した場合、ログ内のコマンドを、中断したコマンドから順番に読み取ることができます。

Postgres は、チェックポイントが完了し、データがディスクにフラッシュされたときにログをパージします。

#先行書き込みログのコンポーネント

1. ログ
2. チェックポイント
3. バッファー
4. ログシーケンス番号 (LSN)
5. レプリケーションスロット

#ログ

WAL ログは、さまざまなトランザクションが保存されるファイルです。これらのログは、データベースに変更が加えられる前にディスクに書き込まれます。

#チェックポイント

チェックポイントは、すべてのデータがチェックポイント前の情報で更新されていることが保証される、ログ ファイル内の一連のトランザクション内のポイントです。 WAL ファイルは最新のチェックポイントから回復するため、これらはクラッシュの場合に特に重要です。ここでシステムは REDO 操作を実行します。

#バッファー

Postgres では、テーブルに対してデータを読み書きする作業単位としてバッファを参照します。先行書き込みログのバッファは通常、トランザクション ログ バッファと呼ばれます。これらは、WAL データの保存に割り当てられるメモリの量を決定します。これについては、この記事の後半で説明するときに構成します。 wal_buffers パラメータ。

#ログシーケンス番号 (LSN)

ログ シーケンス番号は、WAL 内の個々のトランザクションに割り当てられる 64 ビットの整数で、INSERT 位置を示します。これらは、単一のログ ストリーム内で一意のバイト オフセットであり、新しいトランザクションごとに増加し、データ型は pg_lsn です。 LSN は、異なるトランザクション間のデータ量をバイト単位で判断するのに役立ちます。

#レプリケーションスロット

レプリケーション スロットは、WAL データをレプリカに送信するためのレプリケーション接続の予約です。これらは、データの損失を防ぐために使用されます。 Postgres はこれらを使用して WAL に必要なデータを保持し、必要な変更がすべて行われるまでデータが削除されないようにします。

#WAL設定

WAL の使用中にデータベースのパフォーマンスを制御するために設定できる重要なパラメータがいくつかあります。これらには次のものが含まれます。

• wal_level
• fsync そして wal_sync_method
• wal_buffers
• checkpoint_flush_after
• max_replication_slots
• max_slot_wal_keep_size

#wal_level

この設定は、ログに書き込まれる情報の量を制御します。 Postgres レプリケーションの場合、ほとんどの場合、デフォルトのレプリカを使用することになります。

ただし、可能な値は 3 つあります。 wal_level:

• minimal – 最小限の情報のみをログに書き込みます。これは本番環境では推奨されません。
• replica (デフォルト) – レプリケーションを可能にするのに十分な情報を書き込みます
• logical – 論理レプリケーションを可能にするのに十分な情報を書き込みます。これが必要となるのは、 変更データキャプチャを有効にする。

#fsync と wal_sync_method

の fsync パラメータは、WAL ファイルをディスクに書き込むかどうかを決定します。デフォルトでは、これはオンに設定されています。クラッシュ時にデータ損失が発生する可能性があるため、この設定を無効にしないでください。

いつ fsync が有効になっている場合は、変更して WAL ファイルをディスクに書き込む特定の方法を指定できます。 wal_sync_method。このパラメータは次のように設定されています fsync デフォルトでは。

• fsync （デフォルト）
• open_datasync
• fdatasync
• fsync_writethrough
• open_sync

パフォーマンスのためにこれらの設定を微調整したり、特定のハードウェアに適応させたりする場合を除き、これらのパラメータの両方にデフォルト設定を使用することをお勧めします。

#wal_buffers

これは、まだディスクに書き込まれていない WAL データに使用される共有メモリの量を指します。通常、最適なパフォーマンスを得るには、デフォルトの -1 が適切です。この値を増やすと、WAL によって使用される共有メモリが増加し、ディスクへのコミットを続ける必要がなくなります。

バッファの場合、これを大きな値に設定しても、通常は大きな利点は得られません。ただし、複数のコミットが同時に発生するサーバーでの書き込みパフォーマンスが向上し、チェックポイント後の応答時間が増加する可能性があります。

synchronous_commit パラメータのデフォルトがオンになっているため、クラッシュ時の耐久性のリスクが回避されます。耐久性を考慮する必要があるのは、次の場合のみです。 synchronous_commit = off。

なぜなら wal_buffers サーバーの起動時にのみ設定できるため、postgres.conf ファイルで設定することをお勧めします。この値は、次のコマンドを実行して設定できます。 ALTER SYSTEM SET wal_buffers = 12MB;

#チェックポイント_フラッシュ_後

このパラメータを使用すると、すでに書き込まれたデータをディスクにフラッシュするまでのページ数を指定できます。正しく構成されている場合、WAL に挿入されたトランザクションの待ち時間を短縮できます。

データをディスクにフラッシュすることで、キャッシュ内のダーティ データの量が減り、チェックポイントでのディスクへの更新 (fsync) が向上します。これは、チェックポイントの期間とチェックポイント中に消費されるメモリに影響します。

値 0 は強制ライトバックを無効にしますが、通常サイズのデータ操作のパフォーマンスが向上する可能性があります。高い チェックポイント_フラッシュ_後 この値を指定すると、バルク データ操作のパフォーマンスが向上しますが、pg_wal_directory のサイズが大幅に増加する可能性があります。

この値は、次のコマンドを実行して設定できます。 ALTER SYSTEM SET checkpoint_flush_after = 8MB;

#max_replication_slots

max_replication_slots サーバーが使用できるレプリケーション スロットの最大数を指します。レプリケーション スロットは、一度に 1 つのプロセスによってのみ使用できます。このパラメータを使用するには、wal_level をレプリカ以上に設定する必要があります。このパラメータのデフォルトは 10 です。ただし、これを変更する場合は、現在のスロット数よりも小さくすることはできないことに注意してください。そうしないと、サーバーが起動しません。

このパラメータの値を変更するには、次のコマンドを実行します。 ALTER SYSTEM SET max_replication_slots = 20;

#max_slot_wal_keep_size

このパラメータは、チェックポイント時にレプリケーション スロットが保持する WAL ファイルの最大サイズを指定します。このサイズは、レプリケーションによって生じる潜在的な遅延も考慮しながら、ディスクに書き込まれるデータ量を制限するのに役立ちます。単位が指定されていない場合は、デフォルトでメガバイトが使用されます。

レプリケーション スロットのサイズを確認するには:

SELECT
  slot_name,
  wal_status,
  pg_size_pretty(
    pg_wal_lsn_diff(
      pg_current_wal_lsn(), restart_lsn)) AS retained_wal,
  active,
  restart_lsn 
FROM pg_replication_slots;

#先行書き込みログを使用する理由は何ですか?

データの損失は、データ エンジニアにとって悪夢です。 WAL は、他の方法では実現できない災害復旧を提供します。先行書き込みログにより、プライマリ データベース ログから変更をレプリケートする際に、データの整合性と一貫性が確保されます。変更は最初に WAL に書き込まれるため、プライマリ データベースのパフォーマンスを犠牲にする必要はありません。両方の長所を活かすことができます。

WAL は I/O を増加させますが、WAL を有効にしたシステムの全体的なパフォーマンスは、そうでないシステムよりも良好になる傾向があります。これは、WAL の 2 つの主な動作によるものです。 シーケンシャル書き込み そして チェックポイント。

WAL は、データベースへのランダム書き込みではなく、シーケンシャル書き込みを利用します。シーケンシャル書き込みはより効率的であり、トランザクションのコミットがより速くなり、システムのパフォーマンスが向上します。

WAL 内のチェックポイントにより、データをすぐにファイルに書き込む必要がなくなります。まず、データが WAL ファイルに順番に書き込まれます。次に、非同期プロセスがトリガーされます。 チェックポイントタイムアウト または max_wal_size パラメータのいずれか最初に来るもの。

先行書き込みログに関するもう 1 つの懸念事項は、ストレージの使用量です。幸いなことに、WAL は一時的なものであり、保持設定に基づいてデータベースから定期的に削除されます。データベース ストレージが増加しない限り、最大 1GB の WAL で問題なく動作します。

#結論

先行書き込みログは、Postgres レプリケーションを使用する場合、災害復旧の状況を大きく変える可能性があります。データベースでの動作を保証するためのさまざまなパラメータが多数提供されているため、データベースに変更を加える必要があるという確信が得られます。