Garelaについての覚書

業務でPercona/Galeraで触る機会があり、いろいろと調べたので備忘的にメモです。

製品概要

GlobalなTransactionID

  • Garela では、クラスタ内の各ノードの状態は、 Global Transaction ID(GTID) という一意の識別子で表される。GTIDはMySQL5.6で実装された機能として一般に認知されているが、それとは別機能としてGarelaに独自に実装されている。

  • Garelaは内部的に持っている GTID を State UUIDOridinal Sequence Number に分解して、 grstate.dat というファイルに書き出す。

WriteSet Replicaton の同期シーケンス

  • 更新系の処理は、 Write Set Replication(WSREP) という機構により同期される
  • cluster構成 あるいは DB recordが変わる度に state change が発生する。wsrep APIは state change をフックし、WSREP providerにfunction callを発行する。呼ばれたWSREP providerはトランザクションを write set にまとめ、cluster内の他ノードと通信、certificate と replicationを行う
  • 所謂、 2相コミット(Two-Phase Commit)

クラスタに新ノード加入時の初期同期処理

スプリットブレインとgarbd

  • 一般に分散型のDBシステムには、分散合意問題という課題がある。ざっくり言うと、総計100台のノードがあり、それがお互いに通信できない、40台と60台に分裂してしまった時に、それぞれのグループに対し、色々なアプリケーションが別々のCRUD=更新系処理ができてしまっていいのか?ダメなのか?(別の言い方をすると、更新処理はACID特性を満たす必要があるのか?)そういう状況でも、システムが全体として意図とおりに動作する設計にしたいとすると、どういう設計/実装にすべきか?データの一貫性はどの程度保証できる?みたいな話
  • Galeraの場合、「あらかじめ全体の総数を覚えておき、自分が現在通信可能なノードの総数が過半数を割る(50%以下)時は、そのノードはトランザクション処理の実行機能を自主的にdisableする」という感じの点呼&多数決システム( Quorum )を採用している。
  • 50%でもダメなので、クラスの総ノード数が偶数だと場合によっては全員死ぬ。なので、奇数ノードが良いとされている。じゃあ、お金の都合で2台しか用意できない人はどうすれば?という問題を解決するために garbd が用意されている。 garbd はDB機能は持たないが、点呼の頭数に数えられるはノード。これを使うことでスプリットブレイン的な意味では、3ノードクラスタになる

[1] 参考: MySQLの専門家集団Perconaのビジネス戦略に迫る https://enterprisezine.jp/dbonline/detail/9542