分散トランザクション全体で 2 フェーズ コミットがどのように機能するかを調べています。フェーズの最後の部分で、トランザクション コーディネーターが各ノードにコミットする準備ができているかどうかを尋ねることは、私の理解です。全員が同意した場合は、先に進んでコミットするように指示します。
次の失敗を防ぐものは何ですか?
各ノードは、分散トランザクションについて何も知らない通常のデータベースを実行していると想定しています。私は何を取りこぼしたか？
いいえ、元の投稿者のシナリオでは、一部のノードが既にコミットされているため、ロールバックするように指示されていません。クラッシュしたノードが利用可能になると、トランザクション コーディネーターが再びコミットするように指示します。
ノードは「準備」フェーズで肯定的に応答したため、クラッシュから戻った場合でも「コミット」できる必要があります。
みんなの答えをまとめると：
分散トランザクションで通常のデータベースを使用することはできません。データベースは、トランザクション コーディネーターを明示的にサポートする必要があります。
一部のノードはすでにコミットされているため、ノードはロールバックするように指示されていません。何が起こるかというと、クラッシュしたノードが戻ってくると、トランザクション コーディネーターがコミットを終了するようにノードに指示します。
いいえ、ポイント 4 は正しくありません。各ノードは、トランザクションをコミットまたはロールバックできたことを安定したストレージに記録するため、クラッシュしてもコマンドどおりに実行できます。クラッシュしたノードが復旧したら、トランザクションがコミット前の状態にあることを認識し、関連するロックやその他の制御を元に戻し、コーディネーター サイトに接続してトランザクションのステータスを収集しようとする必要があります。
問題は、クラッシュしたノードが復旧しない場合にのみ発生します (その後、他のすべてがトランザクションが正常であると判断するか、クラッシュしたノードが復旧したときに発生します)。
2 フェーズ コミットは絶対確実というわけではなく、99% のケースで動作するように設計されています。
「プロトコルは、各ノードに先行書き込みログを備えた安定したストレージがあること、ノードが永遠にクラッシュしないこと、先行書き込みログのデータがクラッシュで失われたり破損したりしないこと、および任意の 2 つのノードが通信できることを前提としています。お互いに。"
2 フェーズ コミットの問題を解決するには、さまざまな方法があります。それらのほとんどすべてが、Paxos の 3 フェーズ コミット アルゴリズムの変種として最終的に完成します。Google で Paxos ベースの Chubby lock サービスを設計した Mike Burrows 氏は、私が見た講演で、分散コミット アルゴリズムには「Paxos と正しくないもの」の 2 種類があると述べました。
クラッシュしたノードが再起動したときにできることの 1 つは、「このトランザクションについて聞いたことがありません。コミットする必要があったのでしょうか?」と言うことができます。コーディネーターに送られ、コーディネーターは投票が何であったかを伝えます。
これはより一般的な問題の例であることに注意してください。クラッシュしたノードは、回復する前に多くのトランザクションを見逃す可能性があります。したがって、回復時に、それ自体を使用可能にする前に、コーディネーターまたは別のレプリカと通信することが非常に重要です。ノード自体がクラッシュしたかどうかを判断できない場合、事態はさらに複雑になりますが、それでも扱いやすいものになります。
データベースの読み取りにクォーラム システムを使用する場合、不整合はマスクされます (データベース自体に認識されます)。