- Amazon RDS for PostgreSQLのMulti-AZクラスターは公式にはSnapshot Isolationをサポートしているが、実際にはこれに違反するG-nonadjacentサイクルとLong Fork現象が頻繁に発生する
- テストは独自に構成したPostgreSQLトランザクションワークロードに基づいて実施され、PostgreSQL 13.15から17.4までのすべてのバージョンで整合性エラーが発生した
- これらのエラーは主に読み取り専用セカンダリノードで発生し、
Repeatable ReadレベルでもSnapshot Isolationが破られる
- RDSクラスターはParallel Snapshot Isolationレベルの整合性を提供している可能性があり、これはベースとなるPostgreSQL単一ノードよりも弱いモデルである
- 読み取り専用トランザクションは異なるトランザクション順序を観測する可能性があり、この不一致はデータ整合性エラーにつながることがある
Background
- PostgreSQLはMVCCベースのオープンソースSQL DBであり、さまざまなトランザクション分離レベルを提供する。Repeatable Readは実際にはSnapshot Isolationを意味する
- Amazon RDSはPostgreSQLをマネージドクラスターとして提供しており、Multi-AZ構成はレプリケーションと耐障害性のためのアーキテクチャである
- 基本エンドポイントは読み書き可能で、セカンダリは読み取り専用であり、Serializableレベルはサポートしない
Test Design
- Jepsen PostgreSQLテストツールをRDS向けにラップし、自動化されたトランザクションテストを実施
- トランザクションは特定キーのリストを読むか一意の整数をappendする構造で設計され、Elle checkerでサイクルを検出
- 150 TPSの書き込み、1600 TPSの読み取り負荷で2分以内にLong ForkおよびG-nonadjacentの発生を確認
Results
- 4つのトランザクションで構成されたG-nonadjacentサイクルによってSnapshot Isolation違反を実証
- T₂はT₁の変更を観測したがT₃は見ておらず、T₄はT₃は見たがT₁は見ていない → 時系列順序に相互矛盾が生じる
- これはLong Fork現象であり、Snapshot Isolation違反を証明する強い事例でもある
- Write Skewは発見されず、Parallel Snapshot Isolationの可能性を裏づけている
Discussion
- Multi-AZ RDSは単一ノードのPostgreSQLよりも整合性レベルが低い
- 読み取り専用ノードを使用する際は整合性エラーの可能性があるため、必ず書き込みノードのみを使うか、すべてのトランザクションに少なくとも1回の書き込みを含める方法を検討する必要がある
- 今回の分析は初期テスト段階であり、問題の存在は証明しても不在を保証するものではない
1件のコメント
Hacker Newsのコメント
記事タイトルでは明確に触れられていないが、これはRDSの新機能であるマルチAZクラスターに関するもの
以前の会社で、バックアップスクリプトの
pg_dumpコマンドを並列ワーカー（-jフラグ）を使うように変更したとき、バックアップの復元時に一貫性の問題（重複キーエラーやfk制約エラー）が発生したJepsenは独立してこの作業を行っており、報酬は受け取っていない
この問題が実際に意味するのは、同じ行への書き込みの直後に行われる読み取りが古いデータを返す可能性があるということ
マルチインスタンスのupstream Postgresクラスターでは問題がないのかどうかは明確ではない
投稿されたタイトルは核心を隠している: PostgreSQL 17.4向けRDSはスナップショット分離を正しく実装していない
開発者がスナップショット分離を前提にしている一方で、Amazon RDS for PostgreSQLが実際には並列スナップショット分離しか提供していない場合、特に読み取りレプリカのエンドポイントを使うマルチAZ構成において、どのような安全性の問題やアプリケーションレベルのバグが起こり得るのか気になる
13.15から17.4まで、テストされたすべてのバージョンでこの現象が発生した
Amazon RDSのすべてのバージョンをJepsenテストしてほしい
AWSはドキュメントを更新してこれを周知すべきだろう