はじめに
前回に引き続き、galera clusterのtechnical descriptionを読んでいきます。
Technical Description — Galera Cluster Documentation
これ、全部やると全8回になるなぁ。。。どうしようかなぁ。。。（弱気）でもどれも大事そうだからなぁ。。。とりあえずState Transfersは知りたいので、そこまでは1つずつ進んでいくことにします。
CERTIFICATION-BASED REPLICATION
証明ベースのレプリケーションはグループコミュニケーションとトランザクション並べ替え技術を使い同期を実現します。
トランザクションは1つのノード、またはレプリカで楽天的に実行し、コミットするときにそれらは一貫性を保つために調整された証明プロセスを実行します。同時発生するトランザクションの中で、順番を成立させるサービスをブロードキャストすることで、全ノードでの整合性を達成します。
WHAT CERTIFICATION-BASED REPLICATION REQUIRES
すべてのデータベースシステムに証明ベースのレプリケーションを実することは不可能です。いくつか必要なデータベースの特徴があります。
- Transactional Database
- Atomic Changes
- レプリケーションエベントはデータベースとATOMICに変更できる必要があります。特に、一連のデータベースに対する操作は、すべて実行し終えたか、まったく実行していない状態か、そのどちらである必要があります。
- Global Ordering
HOW CERTIFICATION-BASED REPLICATION WORKS
証明ベースのレプリケーションの基本的な考えは、トランザクションがコミットポイントに到達するまでに実行されることであり、コンフリクトが一切ないことが望ましい。これは楽観的な実行と呼ばれる。
clientがCOMMITコマンドを発行するとき、実際のCOMMITが実行される前ではあるが、変更された行のトランザクションと主キーによって行われたすべての変更は、write-setに収集されます。データベースは他のすべてのノードにこのwrite-setを送ります。
write-setは決定論的に受ける証明テストより、プライマリーキーを用います。これはクラスターの各ノードで行われ、write-setを元にノードを増やします。これによってwrite-setを各ノードが適用するかどうかを決定します。
もし証明テストが失敗すれば、ノードはwrite-setを破棄し、クラスターは元のトランザクションにロールバックします。テストが成功すれば、トランザクションはコミットし、write-setはクラスターの残りに適用されます。
CERTIFICATION-BASED REPLICATION IN GALERA CLUSTER
galera clusterにおける証明ベースのレプリケーションの実装は、トランザクションのグローバル順序付けに依存します。
galera clusterはそれぞれのトランザクションにシーケンス番号を割り当てます。トランザクションがコミット地点にたどり着くと、ノードはシーケンス番号が最後にトランザクションが成功した番号と反しているかを確認します。それら2つが関係している間は、トランザクションはそれぞれのノードはお互いに影響を与えません。intervalの間のすべてのトランザクションは、問題となるトランザクションとすべての主キー競合を確認します。競合を検出すれば、証明テストに失敗します。
順序は決定的で、すべてのレプリカがトランザクションを同じ順番で受け取ります。すなわち、すべてのノードは同じ決定をトランザクションの結果実施するのです。トランザクションを開始したノードは、トランザクションをコミットしたかどうかをクライアントとなるアプリケーションに通知できます。
おわりに
訳が不自然なところが多いですが。。。write-setと呼ばれる一連のcommitセットの単位で、それにidを付与してクラスタに配布、primary-keyを元にしてコミットの競合がないかを確認（証明）。これが失敗すれば破棄し、成功すれば受け入れる、という風に読めました。
まだまだ続きます！毎朝書いていこうかな。
