JepsenがAmazon RDS for PostgreSQL 17.4を検証！あの整合性に問題発覚か？
引用元：https://news.ycombinator.com/item?id=43833195
ソフトウエアの文章は、Jepsenみたいに直接的で要点だけ、飾り気なく書くのが理想だよ。「Amazon RDS for PostgreSQLのSnapshot Isolation違反を指摘」みたいなね。昔はmemeを使ったブログも好きだったけど、他のSTEM分野みたいにシンプルで分かりやすい書き方が恋しいんだ。
昔いた会社の社内ブログで技術記事書いたら、普通はあんま反応なかったんだけど、meme入れたらみんな超気に入ってくれた経験があるんだ。Kubecostの話とか、PythonからCを呼ぶ話とか、内容は結構技術的だったんだけどね。やっぱmemeとか視覚的なもの入れると、普段関係ない人でも興味持ってくれるみたい。正直このトレンドは好きじゃないけど、広い読者に届けるには仕方ないのかな。Jepsenはそうじゃなくて、あの厳密なアプローチと飾り気ない文章はすごいと思う。
面白いね、だって俺、Jepsenの初期の頃覚えてるけど、memeにめっちゃ頼ってたもん（名前自体「call me maybe」とかcarly rae jepsenから来てるし）し、aphyrも彼のカラフルな実生活のパーソナリティを隠そうとしなかった（今もだけど）よ :-) 例えば、https://aphyr.com/posts/282-call-me-maybe-postgres なんか見てみて、めっちゃmeme使ってるから。
俺のお気に入りは”UUIDs as Primary Keys”（小見出し：”Just Say No”）かな．:) memeだらけって感じじゃないけど、素晴らしいイラストがあるんだ！ 例えば、UUID v4のidbファイルのデータ断片化のこの可視化とか：https://cdn.zappy.app/b1b54bb0c780c0f6dd891475589aeee3.png
memeが効果的な理由は多分二つあると思うよ．一つは、memeが難しい技術の分かりやすい比喩になっていた場合、比喩が重要だったってこと。
二つ目は、視覚化だよ．文章は視覚的にすればするほど良いし、グラフやイラストを使ってコンセプトを見せることが一番大事だね．
俺はもうmemeだらけのブログ記事を読みたい気分じゃないんだ．特に，たった一段落の内容を無理やり引き延ばしてるだけのことが多すぎるからね．最近はセキュリティ脆弱性関連の記事が多分一番ひどいよ．
ちょうど，昔のJepsenがどれだけ恋しいか考えてたんだ．あの飾り気なく直接的な感じは同じだけど，memeがいっぱいだった頃のね．例えば，昔のredisの記事 https://aphyr.com/posts/283-call-me-maybe-redis を見てみてよ．
Jepsenは最高だよ，いろんな意味でね！
isolation levels，ってことね！
Amazonは技術文書に関する健全な文化があることで知られてるけど，俺もそれに賛同できるよ．このコメントは俺個人の考えであって，会社のもんじゃないからね．それについて考察してる公開記事がこれだよ．https://quartr.com/insights/business-philosophy/amazon-s-wri…
これ、ヘッドラインにも記事にもあんまり明確に書かれてないんだけど、これってMulti-AZ clustersっていう、RDSの新しめの機能の話なんだよね。
みんながよく知ってるMulti-AZ instancesとは違うんだ。（分かりにくいね）
Multi-AZ instancesってのはRDSの昔からの機能で、プライマリDBが別のAZにあるセカンダリDBに同期的にレプリケーションされるんだ。プライマリが落ちたらRDSがセカンダリにフェールオーバーする。
Multi-AZ clustersはセカンダリが2つあって、トランザクションは少なくともどっちか片方に同期的にレプリケーションされる。これだとセカンダリが壊れたり性能落ちたりしても、Multi-AZ instancesより頑丈。
セカンダリへの読み込みアクセスもできるんだ。
Multi-AZ clustersはきっと内部にもっと”魔法”があるんだろうね、だって僕が知る限りVanilla Postgresの機能じゃないから。
たぶんこれがJepsenテストで落ちちゃった理由だと思うな。
なんでこんな魔法が必要なのか面白いね。Vanilla Postgresだってquorum commitでこれできるのに。Patroniでも同じMulti-AZ clusterみたいな構成組めるし、（バグは別として）トランザクションを失ったり、永続化されてないトランザクションを見えちゃったりしないように、必要な連携をやってくれるはずだよ。
ただ、Postgresにも似たようなパターンを可能にしちゃう欠点はまだある。
クライアントがコミット途中で落ちちゃった非レプリケートトランザクションは、すぐに見えちゃうんだ。
だから例の場合、T1がパーティションされたリーダーで起きて、コミット中に切断されて、T2もパーティションされたノードで起きて、T3とT4が後で新しいリーダーで起きたら、同じ結果になるはず。
でも、これは今回のテストでフォルトインジェクションしてないって話と合わないな。
追記：このパターンがレプリカとプライマリでのコミット順序の不整合で説明できるって投稿に気づいてなかった。
その修正方法について講演したことあるのに、ちょっと恥ずかしいね。
質問です
もしMulti-AZ instancesの中でスナップショット違反が起きてるなら、シングルリージョンで複数リードレプリカみたいな構成でも起きうるのかな？
でもMulti-AZ構成の方がラグが大きいから気づきやすいだけ？
WAL shippingを使った同期レプリカはPostgresの枯れた機能だよ。RDSの裏側でもそれ使ってると思うし、それで整合性バグがあるとしたらすごく驚くね。
AWSが”Semi synchronous”って呼んでる2つのレプリカ構成は、僕が知る限りベースのPostgresにはない。
AWSは何か独自のレプリケーション戦略を使ってるはずで、それは同期レプリケーションとは違うバグがあるだろうし、あんまり実戦で鍛えられてないだろうね。
でもAWS以外誰もRDSの実装詳細を知らないから、これは全部根拠のない推測で、あんまり意味ないんだけどね。
この手のレプリケーション、Vanilla Postgresでsynchronous_standby_namesにANY 3 (s1, s2, s3, s4)みたいに設定すればできるんじゃないの？
ドキュメントはこれ。
https://www.postgresql.org/docs/current/runtime-config-repli…
ANYの設定じゃ無理だと思うよ。
せいぜい一部のレプリカが他のより古くなるだけ。
でもレプリカAがtx1は書いたけどtx2は書いてない、レプリカBがtx2は書いたけどtx1は書いてない、みたいな2つの矛盾する状態を返すことはないはず。
Long ForkとかParallel Snapshotってのはそういう話でしょ。
だからAmazon Multi-clusterは変更を順番ぐちゃぐちゃにしてレプリケートしてるってことなのかな？
まあ、そういう感じ。
これって「ただ」PostgreSQLの振る舞いが原因なんじゃないかと思うんだ。
レプリカではトランザクションコミットの見える順番はWALレコードの順番で決まる。
プライマリでは、トランザクションを書いたバックエンドが、そのトランザクションが十分に永続化されたって気づいた時 based on で決まる。
このスレッドの別のコメントも見てみて。
https://news.ycombinator.com/item?id=43843790
これ、大事な補足だよね。RDS（Auroraじゃない）には昔からsingle-AZとmulti-AZがあって、本番はmulti-AZってのが常識だったんだけど、今はmulti-AZインスタンスとmulti-AZクラスターがあるから言葉が曖昧になっちゃったんだよね。multi-AZインスタンスでも、AWS的にはクラスターじゃなくても実質2つのノードがまとまってるんだよ。
いい調査だね！今の開発者はトランザクションのこと全然知らない人が多いし、ましてIsolation levelなんて絶対知らないね。シニアでもDBトランザクションのこと clueless なCRUD開発者とかいるし。でもトランザクションって性能やエラー回避にすごく大事なんだよ。俺の経験だと、SQL ServerでIsolation levelを変えたらロック競合が劇的に減ってユーザー大喜びだったけど、教えるまで誰もIsolation levelなんて知らなかったよ。
これ、シニア開発者だけじゃないよ。Isolation level全然知らないシステムアーキテクトとか、ACIDとCAPのConsistencyを混同してる人にだって会ったことあるし。小売業でレースコンディションだらけなのにIsolation levelが使われてなくて悲しいよ。スタートアップはひどいけど、BigCoのOracleとかMSSQL開発者は基本ができてるって意味で評価高いね。
25年以上働いてるけど、Isolation levelが面接で出たのって1回だけしか覚えてないな。問題にならないと誰も気にしないんだよね。
俺たち全然違うキャリアだったみたいだね。同じ年数なのに180度逆だよ。俺の面接ではIsolation levelは毎回必ず聞かれたし、知らないと落ちるくらいコアな質問だったな、例外なく。
そうかもね。俺のキャリアはスタートアップとか小さい会社が多かったんだけど、そういうとこってDBの基本がひどく欠けてたんだよ。
関わったことある”エンタープライズ”なHR製品で、全データが数百列ある単一のMS SQL Serverテーブルに入ってたの知ってる？
基本スプレッドシートをDBにしたみたいなやつで、10年以上前の話だけど、衝撃だったね。
20年くらい前、スタートアップで自分のORM作ってる奴がいたんだけど、謎だったな。
プリペアドステートメント使わず、バグだらけのカスタムエスケープで、本番でSQL injectionしょっちゅう起きてたよ。
トランザクション意識のなさって、サーバーレスとかEdgeの文脈で特に感じるね。
バックエンドがクライアントの要求だけで決まっちゃうみたいなとこで、DBクエリがReact Hooksみたいにモデル化されてるのとか見たことあるけど、俺の経験上、ひどい結果になったよ。
たぶん、そのうちほとんどのエンジニアはLLMが出したクソコードを写すだけで、実際何が起きてるか全然分からなくなるだろうね（ShopifyとかだとMSが3分の1はLLMで書いてるって自慢してるらしいし）。
そうなると新しいエンジニアも育たないよ。だってエンジニアの仕事なくなるなら、学ぶ意味なくない？
これってまさにLLMの二面性だと思うんだ。色々なDBトランザクションモデルについて説明を求めたら、仕組みとかどれを選べばいいかとか、どう適用するかとか完璧に教えてくれる。でもLLMが作るコードには、トランザクションで直せるバグも結構含まれてるだろうね。
それってLLMがちょっと良い検索エンジンみたいなものだからだよ。Postgresのドキュメント見れば幻覚見ずに分かることだし。でもそのコンテキストで正しいコードを作れないって点は君の言う通りだね。
もっとコメントを表示（1）
若手におすすめの勉強法はもう10年変わらないよ。週末にSQL DBの入門書を読んで、次の週末は今仕事で使ってるDBの本を読むんだ。そうすればプロジェクトのDBエキスパートになれる可能性高いよ。
数年前に似た状況あったよ。Read CommittedからRead Committed Snapshotに変えたら、今や億稼ぐプロダクトのパフォーマンスが劇的に改善したんだ。
でもこれやる時に注意なのが、blocking readに頼ってるコード（例えばselect with existsとか）は全部ダメになること。明示的なロックとかで書き直す必要があるね。
DBトランザクションを知らないのにこの業界で稼いでる奴らがいるって衝撃は置いといて… 俺の推測だけど… 多分ウェブスケールなMongoDBとか使ってたんじゃない？
へえ、面白いね。前の会社でバックアップスクリプトのpg_dumpコマンドを並列（-jフラグ）使うように変えたら、リストア時にたまーに不整合（duplicate keyエラーとかfk constraintエラー）らしきエラーが出るようになったんだ。当時AWSにもPostgresのメーリングリストにも報告しようとしたけど、再現できなくてどこにも辿り着けなかった。結局シングルスレッドに戻したよ。今回の問題と関係あるのかな？
テスト環境は単一インスタンスだったの？ それとも別のAZにスタンバイがある構成？ それともここでテストされたみたいなmulti-azクラスター？
スタンバイインスタンス（”replica”ってRDS用語で言うとね）でpg_dump動かした時にそれを見たんだ。プライマリはmulti-azインスタンスだったよ。だからここでテストされたのとは正確には違うだろうけど、RDSがPostgresに裏側でどんな変更加えてるのか気になるね。
これ読んだ感じだと、write直後にreadすると古いデータが見えるってことかな。multi AZなRDSインスタンスで、write完了前に全層に更新が行き渡らないから、すぐ読むとデータが見えなかったり古い値だったりするのかも。PostgreSQLのsnapshottingからして変な値は見えなさそう。最終的に整合するレースコンディションみたいだね。それともlong forkのトランザクションは完了しないって読んだ？
これは単に古いデータって話じゃないと思うな。「最近のトランザクションを反映しない、ある時点の整合スナップショット」って意味のstale dataとは違う。ここで起きてるのは、セカンダリへのread-onlyトランザクションが、あるトランザクションTは見れるのに、Tより論理的に前に終わってるはずのトランザクションを見逃す可能性があるってことだと思う。
Jepsenの記事で言ってる「レプリカへの読み取り専用トランザクションは，ある処理を見たのに，それより前に起きたはずの別の処理を見逃すかも」ってとこ，直感的に気になってたけど，記事の例（処理1， 2， 3， 4）がどうしてそうなるのかよく分かんないんだ．例では処理2だけが読み取り専用で，レプリカから読むってこと？つまり，処理1， 3， 4はプライマリ，処理2だけがレプリカってこと？
うん，その通りだよ．プライマリとレプリカの間で，処理の見え方が順番通りにならないことがあるってことだね．
WALは一つのスレッドで動いてて，それぞれの場所では特定時点での整合性は保たれるんだ．でも，二つの場所の間ではズレる可能性がある．
RDS Multi-AZ clusterはShared buffersにちゃんと反映されるまで待たないで，WALの同期だけ待つから，これは普通にありえる動きだよ．
PostgreSQLでsynchronous_commitをonにした時と同じ感じ．別に驚くことじゃないね．
あー，なるほどね…．もしプライマリで処理3が処理1より先に終わったのに，レプリカを読む処理2は処理1だけを見る，みたいなことが起きるのは，レプリカ側では処理1が処理3より先に終わったみたいに見えることがあるから，ってこと？
どんなことが起きるか分かりやすい例を出すね．例えば，gps_coordinateが更新されたらpostal_codeを更新，次にcityを更新って順番で進むはずのデータがあるとする．
通常なら，データは「何も変わってない」→「gpsだけ更新」→「gpsとpostal更新」→「全部更新」の順でしか見れないはずだよね．
でも，Jepsenが見つけたみたいに，処理の順番がズレることがあると，「postalだけ更新されて他は前と同じ」とか「cityだけ更新されて他は前と同じ」みたいな，「ありえない」状態が見えちゃうことがあるってこと．
本来の更新順序を無視した，中途半端な適用状態を見ることがありえるって話だよ．
Jepsenが報酬なしで独自にやったってのは，RDBMSの関係者からしたら，最高の日でも聞きたくない知らせだよね．社内では心配するメールが飛び交っただろうな〜って想像できるよ．
aphylにはいつものことながら，脱帽だね．
エンジニアと，その担当のRDSディレクターの間にいる，3段階くらいの中間管理職の人たちのことかな．
ステークホルダーっていうのは，システムに関係あるビジネス上の人全部のことだよ－お客さんとか，エンジニアとか，マネージャーとかね．
RDBMSはこれ→（リンク省略）
報告を受ける側は，むしろ喜んだ方がいいと思うな．
Jepsenの検証で無傷で済んだとこなんて今までないけど，Aphyrにやられたってことは，真剣に向き合ってもらってるってことだからね．
これって、upstreamのマルチインスタンスPostgresクラスターでは問題じゃないってことで合ってる？AWSがクラスター構成でなんかしてるか、この挙動を引き起こすパッチ当てたって理解でOK？
いい質問だね！AWSのレプリケーションアーキテクチャを標準のPostgresで再現できるほどはまだ理解してないんだ。この挙動はシングルノードのPostgresでは起きないみたいだけど、一部のレプリケーション設定だと起きるかもね！
Postgresのレプリケーションって色んなやり方があって、結果も色々だってことは分かってるよ。例えば、PatroniについてのBin Wangさんのレポートはこれだよ：[リンク]
シングルインスタンスでは問題ないけど、マルチインスタンス（プライマリ＋レプリカ）で影響するんだ。プライマリとレプリカ間でスナップショットの挙動に一貫性がないのが原因だよ。セカンダリはWALのコミット順で可視性を判断するけど、プライマリはコミット完了を知ったタイミングで決まるんだ。
それぞれのノード内では一貫してるけど、プライマリとセカンダリ間では順序が違うことがある。この問題への対応は進んでるけど、まだWIPだよ。
matashiiさんありがとう——これで絶対に説明がつくね。この異常はプライマリとセカンダリ間のコミット/可視性の順序の違いが原因だって、別のメールでも示唆されてたんだ。
これについてどこかに記述があるかな？リンクできるやつ。
[リンク]が関係ありそうに見えるけど、確信はないんだ。もしそうなら、レポートを更新したいな。
私のメールは[メールアドレス]だよ、もしよかったら連絡してね。 :-)
あのスレッドは同じ問題だよ。原因は、プライマリとセカンダリでトランザクションの可視性順序が違うこと。プライマリはWAL挿入と可視化マークの順が違う可能性があり、セカンダリはWAL順で判断するんだ。これを直すにはプライマリもWAL順にすればいいけど、トランザクションごとの耐久性設定がそれを難しくしてるんだ。WAL順にすると非同期トランザクションは待つか、read-your-writesを諦める必要がある。これが議論が止まってる理由だよ。
個人的にはread-your-writesを諦める方がいいと思ってる。
二人ともありがとう！
この記事を更新して、これについて議論したよ。AWSのブログにもアップデートがあるんだ。
:-) [リンク]
あなたにとってのマルチインスタンスのupstream Postgresクラスターって何？Postgresにはマスターフェイルオーバーの公式サポートはないよ。レプリケーションを使って自分でツール（Patroniとか）を作るんだ。
AWSはPostgresにパッチを当てて、2つのインスタンスにレプリケートさせて、片方が承認すればOKとしてるみたい。
個人的にはファイルシステムレベルのレプリケーション（drbdみたいに）がPostgresには良いと思う。これは昔のAWS Multi-AZがやってたやつ。でもスループットは低いし、セカンダリから読めないんだ。
＞個人的な意見では、ファイルシステムレベルのレプリケーション（drbdみたいなのを想像してみて）の方がPostgreSQLには良いアプローチだと思うな
それは基本的には、彼らのAuroraバリアントがやってることだよ。
クラスター化された共有ストレージを使って、従来のレプリケーションはキャッシュを無効にするためだけに使ってるんだ（それでレプリカは、共有ストレージ上のメモリとかキャッシュに読み込まれたデータがいつ変わったかを知れるんだ）。
うん、違うよ。
これは彼らが何をしたかの、もっと詳しい概要だよ：[YouTubeリンク]
特にここを見て：[YouTubeリンク]
投稿されたタイトルは本題を隠してるね。
RDS for PostgreSQL 17.4はスナップショット分離を適切に実装してない、ってことだよ。
HNではJepsenレポートのタイトルで揉めがちだから背景を説明するね。レポートはクライアントとの長い協力の成果で、タイトル決めは「厳しすぎる？」「一番大事な点？」など激論になることも。色んな試行錯誤の結果、僕は全てのレポートを「Jepsen: ＜system＞ ＜version＞」と命名することにしたんだ。HNでは好きなようにリンクテキストを選んでいいよ :-)
作者と投稿者（それにコメントしてる人！）が全部同じ人なんだから、あなたの選択（タイトル）でいいと思うよ :)
HNでスレッドが上位にあること、GP（一つ上のコメント）がスレッドで上位にあること、それにみんながJepsenレポートがいかに面白いかを知ってるって事実だけで、伝えたいことは十分に伝わるはずだよ。
君のコメントもね。Multi-AZ clustersの話だけど、これはトランザクション保証の神様Kyle Kingsburyからの指摘だからAWSは無視できないはずだよ。これはPostgresのRDSの選択肢の一つで、特にスタンバイ2つの場合に言えることだ。［1］
AWSの分厚いRDSマニュアルには、Multi-AZ clustersのisolationやグローバルな読み取り一貫性についてほとんど記述がないんだ。ライターはスタンバイ1つを待つけど、リーダーは別のスナップショットを見ちゃうのかな？［1］［2］
もっとコメントを表示（2）
＞彼らのドキュメントにはそんな保証はない
まあ、ユーザーとしては、そこにちゃんと書いてほしいな。Snapshot Isolationが機能として文書化されてる素のPostgresから、Multi-AZのRDSに移行するなら、両者がどう違うか知りたいだろうし。
モデレーターにメールして、リンク先の記事からコピペしたこのフレーズにタイトルを変えてって頼んだんだよ：
＞Amazon RDS for PostgreSQL multi-AZ clusters violate Snapshot Isolation
開発者がSnapshot Isolationを前提にしてるのに、Amazon RDS for PostgreSQLが実際にはParallel Snapshot Isolationしか提供してない場合、特にRead Replicaエンドポイントを使うmulti-AZ構成で、どんな安全性やアプリレベルのバグが起こり得るのかな？
「git push」みたいな例で言うと、トランザクションで読んでから書き込む流れで、不整合な状態のコミットハッシュができちゃうことがあるんだ。
こういうことを理解するのが難しいから、問題回避も難しいんだよね。だから、たぶん一番簡単な対策は「writerエンドポイントだけを使うこと」になりそう。
でも、特に可用性が失われる状況でその方法がテストされてないのは意外だったな。
ちょっと考えてみてよ。記事にコメントしたとするじゃん。最初にコメントした人は”初コメバッジ”をもらえるとするね。
今、User1がコメントして、次にUser2がコメントしたとしよう。
User1は（別のトランザクションで）コメントが1個しかないことを確認して、バッジをもらう。
User2も同じように確認して（別のトランザクションで）、やっぱりコメントが自分のが1個だけだって見て、バッジをもらっちゃうんだ。
Snapshot isolationならこれはありえない。別のトランザクションでのチェックの少なくともどちらか一方は、コメントが2個あるって見るはずだからね。
記事にあるParallel Snapshotについての原文は読む価値ありだよ。https://scispace.com/pdf/transactional-storage-for-geo-repli…
＞これらの現象はテストされた全てのバージョン、13．15から17．4までで発生しました
メジャーバージョンアップしたの失敗だったかなって心配したけど、どうやらそうじゃないみたいだね。これはリグレッションじゃなくて、単なる機能要求か長年のバグってことだね。
Amazon RDSのいろんな種類も全部Jepsenでテストされると最高だね。
実はこれ、僕（すごくゆっくりだけど、時々夜とか週末に！）取り組んでるんだよね。Peter Alvaroと僕は、RDS for MySQLでの安全性問題についてもここで報告したことあるよ。https://jepsen.io/analyses/mysql-8.0.34#fractured-read-like-…
クラウドプロバイダーが新しいデータベースサービスを発表するたびに、Jepsenテストを依頼して、全ての課題が解決されるか少なくとも文書化されるまで改善を繰り返すような世界があればいいのにね。残念ながら、ここでは信頼性ってそんなに高い優先度じゃないみたい。引き続き頑張って！
AWSはこれについて説明するためにドキュメントを更新する必要があると思うな。Snapshot isolationの修正って、レイテンシとかスループットのパフォーマンスを悪化させちゃうのかな？それとも、今のままで十分強いって主張するのかな。どっちにしても、何か言わないとダメだよね。
AWSからの理想的な解決策は、バグを直して、ドキュメントに書いてある通りの保証をちゃんと提供することだと思うよ。
同意だよ。でも、これ簡単な修正じゃなさそう。同等だと思って選んだ仕組みが、実際はそうじゃなかったって感じなんじゃないかな。それを入れ替えるには、すごく時間もテストも必要になると思うよ。
＞入れ替えるには、すごく時間もテストも必要になる
ラッキーなことに、正しい振る舞いを検証するための自動化されたスイートが［1］あるんだぜ！
1： https：／／github．com／jepsen－io／rds
パフォーマンスを壊さずにこれを簡単に直す方法はないよ。だいたい、分散システムにタダ飯はないっていうか、AWSはこの特定のセットアップで整合性の保証を緩めるトレードオフを選んで、それをあんまりちゃんと宣伝しなかったんだと思うな。
これバグみたいだね。でも問題はドキュメントにこのシナリオでの保証について詳しく書かれてないこと。誰か書いてある場所教えてくれると嬉しいな…
いや、キミのコメントの下にある引用文にはv13以降って書いてあるし、上にドキュメントに書いてないって書いてあるけど。Bugとかguaranteeって言葉で、あんまり詳しくない読者を混乱させてない？
Microsoft SQL Serverはどうかなって思ったんだけど、ちゃんとテストリストに入ってたわ。これね。
https://jepsen.io/analyses
Microsoft SQL Serverのライセンス違反かも？ MicrosoftはJepsenの解析にお金払ってないみたいだし（もしかして公開したくないのかな 笑）
＞ MicrosoftはJepsenの解析にお金払ってないみたいだし（もしかして公開したくないのかな 笑）
もし俺がたまにテキトーな（Microsoftがそうって言ってるわけじゃなくて、あくまで例ね）データベースベンダーで、製品が99.95%のユースケースでOKで残りの修正がめちゃくちゃ大変なら、Jepsenに解析させないように金払う可能性の方が高いかも。だって、依頼して欠陥が明るみに出たら、それまで満足してた人たちまで離れちゃうかもしれないじゃん。
でも、この記事の解析は無償でやられたみたいだし、レポートや調査の価値はお金だけじゃないってことみたいだね。
僕が問題を正しく理解してるなら、たぶんAuroraは大丈夫だと思う。
僕の理解だと、multi-azは複数の準同期レプリカ構成で、1つのレプリカだけトランザクションを確認すればいいんだ。
Auroraは準同期レプリケーションじゃなくて、共有ストレージを使ったクラスター構成で、キャッシュ無効化のために違うレプリケーション設定を使ってるからね。
AuroraはたぶんまだPostgreSQL 17は提供してないと思うな。
”彼らがテストした全てのPostgreSQLバージョン、13.15（AWSがサポートしてた一番古いバージョン）から17.4（一番新しいバージョン）までで発生した。”
って書いてあるから、v17でも違いはなさそうだね。
