博士

ロボ子、PostgresのMulti-Masterクラスタにおけるコンフリクト管理についてのプレゼンがあったみたいじゃぞ。

ロボ子

Multi-Masterクラスタですか。Postgres 16で双方向論理レプリケーションがサポートされたものの、Active-Active構成はまだ推奨されないとのことですね。

博士

そうなんじゃ。CAP定理やPACELC設計原則を考えると、整合性、可用性、レイテンシのトレードオフは避けて通れないからの。

ロボ子

PACELC原則では、通常動作時でもレイテンシと整合性のトレードオフがあることを考慮する必要があるのですね。

博士

Multi-Masterクラスタでは、ローカル書き込みを優先するから、データ競合が起きやすいんじゃ。コンフリクトの種類も色々あるみたいじゃぞ。

ロボ子

収束コンフリクト、解決可能なコンフリクト、発散コンフリクト、ファントムコンフリクト… 種類が多いですね。

博士

解決可能なコンフリクトはLast-Write-Winsで自動解決できるけど、データ損失の可能性があるからの。発散コンフリクトは3つ以上のノード間で競合が起きて、データが永続的に不整合になるから特に注意が必要じゃ。

ロボ子

コンフリクトの防止策としては、書き込みターゲットの制御や台帳の使用、CRDTsなどがあるようですね。

博士

そうじゃ。スティッキーセッションを使ったり、アプリケーションサーバを特定のノードに割り当てたりして、不要なクロスノードアクティビティを避けるのが大事じゃ。

ロボ子

CRDTsは、pgEdge Spock拡張やEnterpriseDB BDR拡張で提供されているのですね。数値カラムに対して、差分を適用したり、ノードごとの隠しフィールドを使用したりする方式があるとのことです。

博士

キー管理も重要じゃ。シーケンスオフセットで各ノードのシーケンス開始値をずらしたり、UUIDやSnowflake IDでグローバルユニークキーを生成したりするんじゃ。

ロボ子

シーケンスの安全性も考慮する必要があるのですね。SERIALやBIGSERIALではなく、IDENTITY構文を使用すると。

博士

Divergent INSERT / UPDATEコンフリクトを修正するために、UPDATEをINSERTに変換したり、「ALTER TABLE foo REPLICA IDENTITY FULL;」を設定してTOAST値を強制的にレプリケーションストリームに含める方法もあるみたいじゃ。

ロボ子

履歴の関連性も重要ですね。削除されたレコードの「墓石」レコードを保持したり、ソフトデリートを使用したりすることで、データの追跡が容易になりますね。

博士

Multi-Masterクラスタは便利だけど、コンフリクト管理はしっかりやらないと大変なことになるからの。ロボ子も気をつけるのじゃぞ！

ロボ子

はい、博士。ところで、コンフリクトが起きた時に、一番平和的な解決方法って何でしょう？

博士

それはもちろん、ジャンケンで決めるのじゃ！