博士

やっほー、ロボ子！今日のITニュースはPostgresのWAL（Write-Ahead Log）とデータベース変更のリスニングについてじゃ。

ロボ子

WALですか、博士。データベースの変更を記録するものですよね。それがどうリスニングと関係するんですか？

博士

そうじゃ、ロボ子。Postgresの`NOTIFY`って機能があるんじゃが、これが高スループットだとボトルネックになるらしいのじゃ。それに、メッセージが失われる可能性もあるみたいじゃぞ。

ロボ子

`NOTIFY`にそんな問題があったとは知りませんでした。WALを使えば、その問題を解決できるんですか？

博士

その通り！WALはデータベースへのすべての変更のログじゃから、これを利用して変更をキャッチできるのじゃ。レプリケーションとか、バックアップにも使われるすごい奴なんじゃぞ。

ロボ子

なるほど。WALをリスニングするためには、何か設定が必要なんですか？

博士

`wal_level`を`logical`に設定する必要があるのじゃ。設定を変えたら、データベースを再起動するのを忘れちゃダメだぞ！

ロボ子

`wal_level`を`logical`に、ですね。それから、物理レプリケーションと論理レプリケーションの違いは何ですか？

博士

物理レプリケーションはバイト単位で複製するから速いんじゃが、同じPostgresのバージョンじゃないとダメなんじゃ。論理レプリケーションは高レベルなWALレコードを使うから、違うバージョンでも大丈夫じゃが、ちょっと遅いのじゃ。

ロボ子

バージョンが違う環境でもレプリケーションできるのは便利ですね。PublicationとReplication Slotについても教えてください。

博士

Publicationはどのテーブルのどの操作を追跡するかをPostgresに教えるものじゃ。Replication SlotはWALリスナー専用のWALコピーで、リスナーがどこまで読んだかを覚えておくのじゃ。

ロボ子

Replication Slotがあるおかげで、リスナーがオフラインになってもWALレコードが失われないんですね。

博士

そうそう！一時的なスロットと永続的なスロットがあるんじゃ。永続的なスロットは、リスナーがオフラインでもWALレコードを保持してくれるから安心じゃ。

ロボ子

WALリスナーの実装には、`Postgrex.ReplicationConnection`を使うんですね。

博士

`START_REPLICATION`クエリでPostgresにWALレコードの送信を開始させるのじゃ。Heartbeatの処理も忘れずに！

ロボ子

Heartbeatに応答しないと、接続が切れてしまうんでしょうか？

博士

その通り！PostgresからのPrimary Keep-Alive Messageに応答して、受信した`XLogData`メッセージを確認応答する必要があるのじゃ。

ロボ子

`XLogData`メッセージからWALレコードをデコードして、`BEGIN`、`INSERT`、`COMMIT`などのメッセージを処理するんですね。クラッシュリカバリについても考慮が必要ですね。

博士

リスナーがクラッシュしてもメッセージを失わないように、Postgresはリスナーが確認応答するまでWALレコードを保持してくれるんじゃ。メッセージの重複を避けるために、メッセージ処理はべき等である必要があるぞ。

ロボ子

WALとリスニングについて、よく理解できました！`NOTIFY`の課題をWALで解決できるのは素晴らしいですね。

博士

じゃろじゃろ？WALは奥が深いからの。ところでロボ子、WALって、まるで私たちが毎日書いている日記みたいじゃない？

ロボ子

日記ですか？

博士

そう！全部記録されてて、後から振り返れる！でも、私の日記はたまにめちゃくちゃなことが書いてあるから、WALの方が優秀かも…！