Galera Clusterは一貫性をどのように保証しますか？

Question

高可用性SQLソリューションを探しています。 https://www.percona.com/blog/2012/11/20/understanding-multi-node-writing-conflict-metrics-in-percona-xtradb-cluster-and-galera/

writesetが実際に与えられたノードに適用されたとき、彼は

を言い、それはオープンで検出したすべてのロック コンフリクト（：私は読んでの記事の一つは、ガレラクラスタに「事実上同期」についてでした 上の未コミットコミットメント）トランザクションによって、そのオープントランザクションがロールバックされます。

と

複製スレッドによって適用されているWritesetsは常にコミットされたトランザクションとWriteSet競合場合はどうなりますか

に勝ちますか？

また、彼は言う：

Writesetsは、その後、（順番に）すべてのノードで「認定」されています。

Galera ClusterはどのようにしてWriteSetをクラスタ上で注文しますか？ WriteSetsを注文した隠しマスタノードはありますか？動物園のようなもの？または何？

Answer 1

（このアンサーは、直接ないあなたの質問に取り組むんが、ガレラは「良い」であることをあなたに自信を与えることがあります。）

ガレラ（PXC、など）で

、二つの一般的な時間があるときに、トランザクション失敗することがあります。トランザクションが実行され、アクションが現在同じノード上で実行されているものと比較されているノードで

1. 。競合が発生した場合、いずれかのトランザクションが停止しているか（innodb_lock_wait_timeoutと考える）、またはデッドロックされている（ロールバックされている）。

2. はCOMMIT時点で、情報は、他のすべてのノードに送信されます。ノード上の何か、または保留中のもの（gcache内）に対してトランザクションをチェックします。競合が発生した場合は、問題が発生する旨のメッセージが返送されます。したがって、元のノードにはCOMMITが失敗します。このため、COMMIT文でもエラーをチェックする必要があります。

は、シングルノードシステムと同様に、デッドロックがが通常トランザクション全体を再生することによって解決されます。 autocommitの場合

、文は失敗した後の再試行の小さな、設定可能な、数は、そこにあります。だから、もう一度、エラーをチェックしてください。ただし、再試行がすでに試行されているため、プログラムを中止することができます。

現在（私の意見では）ガレラは、少なくとも3物理的に異なる場所に少なくとも3つのノードで、MySQLのための最高の可能なHAソリューションです。障害のシングルポイント障害から効果的に保護されます。 （Oracleからのグループレプリケーション/ InnoDBクラスタは間もなく登場し、非常に有望です。）

「重要な読み取り」の問題にはGaleraの解決策がありますが、対策を講じる必要があります。 wsrep_sync_waitを参照してください。 （この記事の執筆時点では、InnoDB Clusterには解決策がありません）

PXC/Galeraに移行する際のコーディングの相違点については、http://mysql.rjweb.org/doc.php/galeraのヒント（その一部は上記に含まれています）を参照してください。

Answer 2

これは2番目の質問です（Galeraが書き込みセットを注文する方法について）。

Galeraはトーテムプロトコルに基づいて拡張仮想同期（EVS）を実装しています。 Totemプロトコルは、トークンを持つノードだけが（私が理解するように）新しい要求を送信することを許されるトークンパッシングのフォームを実装します。したがって、一度に1つのノードだけがトークンを持つので、書き込みは順序付けられます。学歴については

、あなたはこれらを見ることができます：

The Totem Single-Ring Ordering and Membership Protocol

The database state machine and group communication issues