![リーダーの決定
? リーダー選出という過程はない
? 各メンバーがgossipプロトコルで同期されたメンバーリストから独立に決める
? リーダーはunreachableでないメンバーのうちUpとLeaving状態のものを優先的に選択し、アドレス順に並べて先頭のもの
/**
* Up|Leaving, Joining, Exiting, Downの順に並べ先頭のものがリーダー。同じ状態の場合最小のアドバイスのものを選ぶ。コードは以下を参照。
* https://github.com/akka/akka/blob/v2.4.10/akka-cluster/src/main/scala/akka/cluster/Gossip.scala#L190-L196
*/
val leader = reachableMembers.min(Ordering.fromLessThan[Member] { (a, b) ?
(a.status, b.status) match {
case (as, bs) if as == bs ? Member.addressOrdering.compare(a.address, b.address) <= 0
case (Down, _) ? false
case (_, Down) ? true
case (Exiting, _) ? false
case (_, Exiting) ? true
case (Joining, _) ? false
case (_, Joining) ? true
case _ ? Member.addressOrdering.compare(a.address, b.address) <= 0
}
})](https://image.slidesharecdn.com/akkacluster-161008021009/85/Akka-Cluster-19-320.jpg)
Akka Clusterの耐障害設計
- 1. Akka Clusterの 耐障害設計 安田裕介 Scala 関西 2016 スピーカーノート https://github.com/TanUkkii007/blog/blob/master/akka_cluster_resilience.md
- 2. 自己紹介 ? 安田裕介 ? @TanUkkii007 ? 東京でScalaの仕事をしています ? Akka 好き
- 3. Akka Clusterの適用領域 Basically Soft state Eventually consistent Available client-facingで な分散システム
- 4. Akka Clusterを使う利点 ? 位置透過性 ? サービスの成長に合わせてスケール戦略を切り替えら れる ? スケール戦略が変わってもコードが変わらない ? エコシステム ? シャーディングやレプリケーションなど、分散システ ムでよく用いるアルゴリズムを実装した拡張がある
- 6. Akka Clusterとは？ ? クラスターのメンバーシップ管理を行うAkka拡張 ? Amazon Dynamoやriakに影響を受けている ? gossipプロトコルによるメンバーの状態伝播と、 failure detectorによる障害検知を可能にする
- 7. failure detector ? クラスターのメンバーは互いにハー トビートを送り合っている ? failure detectorはハートビートをも とにメンバーの生死を推測する ? 生きているメンバーはreachable、 死んでいるメンバーはunreachable とマークする
- 8. gossipプロトコルと メンバーシップライフサイク ル ? メンバーには状態があり、gossipプロトコルで他のメン バーと状態を同期する ? gossip収束時に一意に決まるリーダーという役割がある ? リーダーがメンバーの状態を変える行為をリーダーアク ションという ? クラスターに参加するメンバーはjoining状態から始まる ? リーダーはjoining状態のメンバーをup状態にし、クラス ターに参加させる ? down状態になったメンバーは、リーダーによって removed状態にされ、クラスターから取り除かれる doc.akka.io
- 10. 故障の単位：プロセス ? 故障の単位をプロセスという ? アクタープログラミングではプロセスはアクター ? この発表ではAkka Clusterの１ノードをプロセスとする ? つまりAkka ClusterのUNIXプロセスと同義
- 11. 故障の種類 クラッシュストップ故障 オミッション（切り捨て）故障 クラッシュ?リカバリー故障 ビザンチン（任意）故障 Reliable and secure distributed programming, Ch.2
- 12. クラッシュストップ故障 オミッション（切り捨て）故障 クラッシュ?リカバリー故障 ビザンチン（任意）故障 Reliable and secure distributed programming, Ch.2 クラッシュストップ故障
- 13. クラッシュストップ故障 ? 正常に処理を実行していたプロセスがある時刻以降 処理を停止して２度と戻らない故障 ? 故障のなかでもっとも単純 ? Akka Clusterのレイヤーで考えなければならない故 障のほぼ全てはこれ
- 14. クラッシュストップ故障で 停止する処理 ? unreachableなメンバーがいると、gossipプロトコルで状 態を完全に同期できない（gissip非収束状態） ? クラスターの状態を変えるリーダーアクションが行えな くなる ? →メンバーの追加ができない
- 15. gossip非収束状態の解決 ? unreachableなメンバーのハートビート が回復してfailure detectorによって再び reachableになる ? unreachableなメンバーをdown状態にす る クラスターのメンバーがクラッシュストップ故障を起こすと、そのメ ンバーにgossipプロトコルによってクラスターの状態を伝播できなく なる。このときgossipは収束しない。 gossipの非収束を解決する方法 doc.akka.io
- 16. Auto-downing ? デフォルトではunreachableなメンバーを自動的に down状態にはしない ? リーダーがunreachableなメンバーを指定時間後に 自動的にdownする機能にauto-downがある ? auto-downは使ってはならない ＿人人人人人人人人＿ ＞ ＜ ￣Y^Y^Y^Y^Y^Y^Y￣ doc.akka.io
- 18. split brain問題 ? failure detectorがメンバーを死と推 定したとしても、実際には生きてい る場合がある ? 生きているメンバーをクラスターか ら分離すると、結果的にクラスター が分裂する問題をsplit brain問題とい う ? 分離したクラスターの状態は同期出 来ず、誤った情報をクライアントや DBに伝える
- 19. リーダーの決定 ? リーダー選出という過程はない ? 各メンバーがgossipプロトコルで同期されたメンバーリストから独立に決める ? リーダーはunreachableでないメンバーのうちUpとLeaving状態のものを優先的に選択し、アドレス順に並べて先頭のもの /** * Up|Leaving, Joining, Exiting, Downの順に並べ先頭のものがリーダー。同じ状態の場合最小のアドバイスのものを選ぶ。コードは以下を参照。 * https://github.com/akka/akka/blob/v2.4.10/akka-cluster/src/main/scala/akka/cluster/Gossip.scala#L190-L196 */ val leader = reachableMembers.min(Ordering.fromLessThan[Member] { (a, b) ? (a.status, b.status) match { case (as, bs) if as == bs ? Member.addressOrdering.compare(a.address, b.address) <= 0 case (Down, _) ? false case (_, Down) ? true case (Exiting, _) ? false case (_, Exiting) ? true case (Joining, _) ? false case (_, Joining) ? true case _ ? Member.addressOrdering.compare(a.address, b.address) <= 0 } })
- 21. split brain問題を解決するには ? リーダーよりも整合性の高い方法で決定でき、 downを果たせる役割は何か？ ? ２つ以上に分割される場合、どれが正しいクラスタ ーなのか？ ? 正しくないクラスターを決めたとして、そのメンバ ーをどうすべきか？
- 22. split brain resolver ? Keep Reference ? Keep Oldest ? Static Quorum ? Keep Majority ? Lightbend Reactive Platform ? TanUkkii007/akka-cluster-custom-downing split-brain-resolverのストラテジ
- 23. Keep Oldest ? 最古のメンバーがいる側を正のクラスターとする ? 最古のメンバーとは起動時のタイムスタンプがもっとも小さいもの ? そうでない側のメンバーは自らシャットダウンする ? unreachableなメンバーをdownする役割は最古メンバーが担う ? 最古のメンバーはgossip非収束時にも一意に決まる（※例外あり） ? 可用性の点で問題あり。最古のメンバーが故障した場合、全クラスター がシャットダウンする。（オプションで回避可能） val oldest = members.filterNot(_.status == Removed).min(Member.ageOrdering)
- 24. Keep Oldest
- 25. Static Quorum ? 残存メンバーがquorum sizeに満たない場合、そのメンバーを downしする ? 他のメンバーをdownする役割はリーダーが担う ? quorum-size * 2 - 1を超えるメンバーを追加しない限りsplit brainは おきない ? quorum-sizeと総ノード数で可用性を調節可能 ? メンバーの数を固定しなければならない点が弱点。quorumを適用 するロールを限定して他のロールのメンバー数を動的にすると良 い。
- 26. Static Quorum
- 27. FLP Impossibility “非同期なシステムにおいては、 ただ１つのプロセスが故障しただけでも、 完璧に合意できる分散アルゴリズムは存在しない” Fisher, Lynch, Paterson (1985) Impossibility of Distributed Consensus with One Faulty Process 完璧なsplit brain resolverのストラテジはない
- 28. オミッション（切り捨て）故障 クラッシュ?リカバリー故障 ビザンチン（任意）故障 Reliable and secure distributed programming, Ch.2 オミッション（切り捨て）故障 クラッシュストップ故障
- 30. Akka Remoteにおける オミッション故障 ? システムメッセージを送信できず、ローカルとリモートのアクターシ ステム間の状態が同期できなくなったときにオミッション故障となる ? システムメッセージには、リモートスーパーバイザーに管理されたア クターのライフサイクルイベント、watchによる死活監視、リモート アクターのデプロイメントがある ? このときAkka Remoteの状態はquarantinedになり、そのメンバーは unreachableから戻ってこれなくなる ? split brain resolverを使用している場合、unreachableなメンバーはク ラスターから取り除かれ、取り除かれたメンバーはシャットダウンす る→クラッシュストップ故障と全く同じ扱いになる
- 31. オミッション（切り捨て）故障 クラッシュ?リカバリー故障 ビザンチン（任意）故障 Reliable and secure distributed programming, Ch.2 クラッシュ?リカバリー故障 クラッシュストップ故障
- 33. Akka Clusterにおける クラッシュ?リカバリー故障 ? クラッシュして取り除かれたノードが再起動してク ラスターに再加入することを前提としていない ? クラッシュ?リカバリー故障はおきない
- 34. メンバーの識別 ? Akka Clusterはメンバーをhostname:port:uidの３つの識別子で 認識する ? uidはアクターシステム起動時に発行されるユニークなID ? ホストとポートが同じでも、再起動した後ではuidが異なる ? つまりクラッシュして再起動したプロセスは、以前のプロセス と別物と認識される ? →新しくクラスターに加入することと全く同じ：クラッシュ? リカバリー故障はおきない
- 35. 蘇り（incarnation）ノード ? Q: クラッシュしたメンバーはunreachableとなってリーダーアクションが とれなくなるため、再起動してもノードがクラスターに再加入できるの か？ ? A: できる ? クラスターのメンバーと同じホスト：ポートのペアをもつメンバーが加 入（joining）してきた場合、リーダーは古いメンバーを自動的にdownす る ? 同じホスト：ポートのペアをもつメンバーが同時に２つ存在することは ありえない。古いメンバーはクラッシュしたことをリーダーは判断でき る。 ? auto-downやsplit brain resolverを使わなくてもこの機能は働く
Editor's Notes
- #2: Akka Clusterの耐障害設計について話します。TISさんの前セッションを聞いてからこの発表に臨むのがお勧めなのですが、前のセッションに参加した人はどのぐらいいますか？ あとAkka Clusterを使ったり試したことのある方はどれぐらいいますか？ 質問OKにするか。 スピーカーノートのリンクを張ってあるのでご活用ください。
- #3: 自己绍介です。安田裕介といいます。础办办补好きです。よろしくお愿いします。
- #4: Akka Clusterとは何かを説明するまえに、どこで活躍する技術かをはじめにお話します。Akka ClusterはBASEなシステムを構築する際に真価を発揮します。BASEとはsoft-stateによる高い可用性と結果整合性による高いスケーラビリティを主軸にするアプローチです。クラウドの登場により、以前より遥かに簡単にサーバーをスケールアウト/スケールインさせることができるようになりましたが、永続化層はダイナミックにスケールさせることはまだ難しいのが現状です。可用性を高めるにはクライアントにより近いレイヤーでsoft-stateを扱うことが重要になってきます。ダイナミックなメンバー管理と状態管理を得意とするのがAkka Clusterです。
- #5: BASEなシステムを構築する技術の中でもAkka Clusterを選ぶ理由は、アクターの位置透過性が大きいでしょう。AkkaやErlangを始めとするアクタープログラミングでは、位置透過性によりどのスレッドでアクターが動いても同じように動作することが保証されています。この性質によりマシンにコアを追加すればコードを変えることなくアプリケーションをスケールアップすることができます。同様にアクターはどのサーバーで動いても同じように動作するで、ほとんどコードを変えずにスケールアウトに戦略を切り替えることができます。位置透過性はサービスの各段階において適したスケール戦略を少ないコストで可能にします。低コストとは具体的には、どのようなスケール戦略をとるかによってコードを変える必要がないという点と、スレッドや複数マシンへの分散環境の複雑なテストを書く量が少なくて済む点と、すべてのチームメンバーが分散プログラミングに精通している必要がないという点です。またエコシステムも魅力の１つです。
- #6: Akka Clusterの基本を話します。前のセッションでTISさんがAkka Clusterを詳しく説明してくれたので、ここでは基礎をさらりと説明するにとどめます。
- #7: Akka Clusterとは、クラスターのメンバーシップ管理を行うAkkaの拡張です。Amazon Dynamoやriakに影響を受けており、非中央集権的で対称な分散システムを構築するための基盤となります。Akka Clusterには主に２つの機能があります。gossipプロトコルによるメンバーの状態伝播と、failure detectorによる障害検知です。
- #8: Akka Clusterのメンバーは互いにハートビートを送り合っています。failure detectorはハートビートをもとにメンバーの生死を推測します。failure detectorは生きているメンバーをreachable、死んでいるメンバーをunreachableとマークします。
- #9: Akka Clusterのメンバーには状態があります。gossipプロトコルを使ってお互いに状態を同期します。gossipプロトコルで全メンバーに状態を同期したときに、一意に決まるリーダーという役割があります。リーダーはメンバーの状態を変えることに責任があり、その行為をリーダーアクションといいます。 クラスターに参加するメンバーはjoining状態から始まります。リーダーはjoining状態のメンバーをup状態にし、クラスターに参加させます。up状態からクラスターのメンバーと認識されます。またdown状態になったメンバーは、リーダーによってremoved状態にされ、クラスターから取り除かれます。これがクラスターメンバーのライフサイクルです。
- #10: ここからがこの発表の本題です。前のTISさんのセッションがAkka Clusterの光を示したとしたら、ここからは影の部分です。これからAkka Clusterでどのような障害が起きるのか話します。すべての分散システムに言えることですが、耐障害設計は非常に難しいです。しかしここを乗り越えてこそ伝統的なシステムでは到達できないスケーラビリティと可用性を手に入れることができるのです。
- #11: 耐障害性の解説に入る前に、故障の単位を定義しておきましょう。故障の単位をプロセスといいます。アクタープログラミングでは障害の単位はアクターですが、ここではAkka Clusterの１ノードと定義します。これはAkka ClusterアプリケーションのUNIXプロセスと同義になります。
- #12: 耐障害性を議論する際に、どのような故障に対処するのかを定義しなければなりません。故障には主に４つの分類があります。 この４つの故障はそれぞれ下位の故障の上位集合になっています。上位の故障ほど対処が難しいです。
- #14: 正常に処理を実行していたプロセスがある時刻以降処理を停止して２度と戻らない故障をクラッシュストップ故障といいます。故障のなかでもっとも単純な故障です。後により上位の故障を説明しますが、Akka Clusterのレイヤーで考えなければならない故障のほぼ全てはクラッシュストップ故障です。
- #15: クラスターのメンバーの１つがクラッシュストップ故障を起こした場合、どの処理が止まるのか明らかにしましょう。Akka Clusterのレイヤーでは、このとき停止する処理はリーダーアクションです。メンバーの一部がクラッシュストップ故障を起こした場合、そのメンバーはfailure detectorによってunreachableと判定されます。このときクラスターは保守的に振る舞い、クラスターの状態を変えるリーダーアクションを行うことをやめます。具体的にはクラスターに新たなメンバーを追加することができなくなります。
- #16: リーダーアクションを再び行えるようにするには、unreachableなメンバーがfailure detectorによって再びreachableとなるか、down状態にする必要があります。down状態にすると、その状態変化をほかの全メンバーが観測してゴシップは収束し、やがてリーダーはdownしたメンバーをremoved状態にしてクラスターから取り除きます。down状態になるとメンバーの追加が可能になります。
- #17: デフォルトでは、Akka Clusterはunreachableなメンバーを自動的にdown状態にはしません。つまり人の手でdownする必要があります。 自動的に故障したメンバーをdownするには、auto-downというオプションを有効にします。この機能を有効にすると、unreachableなメンバーは指定時間後に自動的にdownします。しかしこの機能は使ってはいけません。なぜ使ってはならないのか、考えてみましょう。
- #18: 根本的な問題は、failure detectorがメンバーをunreachableと判定したとき、そのメンバーは本当に死んでいるのか、ネットワーク遅延や分断なのか、GCによる遅延なのかが分からないということです。よいfailure detectorとは、あくまでノードがダウンしていることを精度良く **推定**できるだけにすぎません。この問題はすべての分散システムに言えることで、分散システムが難しい理由の１つです。downしたメンバーが実は生きていた場合、split brain問題がおきます。
- #19: downと判定したメンバーが本当に停止しているわけではなく、生きていた場合を考えましょう。このメンバーはすでにクラスターから切り離され、状態は同期できなくなっています。このメンバーがクライアントに公開されてしまうと、誤った情報をクライアントに伝え、またその誤った状態をもとにデータベースなどの共有リソースを変更してしまいます。このようにクラスターが分裂してしまうことをsplit brain問題といいます。
- #20: auto-downの危険性をよく理解するためにはAkka Clusterでリーダーがどのように決定されるかを知っておく必要があります。なぜならauto-down機能でメンバーをdown状態にするのはリーダーだからです。Akka Clusterにはリーダー選出という過程は存在しません。リーダーはgossipプロトコルで同期されたメンバーリストから決定論的に決定できます。リーダーはunreachableでないメンバーのうちUpとLeaving状態のものを優先的に選択し、アドレス順に並べて先頭のものです。
- #21: この決定方法ではunreachableなメンバーがいない場合、つまりゴシップが収束しているときにクラスター内でリーダーをユニークに決定できます。しかしunreachableなメンバーが存在すると、メンバーによってどのメンバーがunreachableに見えるのかが異なるため、メンバーによって異なるリーダーを決定する場合があります。例えばネットワーク分断によりクラスターが２つに分断された場合、リーダーは２つできます。各リーダーが相手側をdownするので、split brain状態になります。Akka Clusterのリーダー選出はどのような状況でも可能で可用性が高い代わりに、整合性を犠牲にしています。これは整合性を取っているPaxosやRaftなどの分散合意プロトコルと異なる点です。
- #22: split brain問題に対処するためにはいくつかの観点があり、それにどのような答えを出すかによってsplit brain問題を解決する方法が変わります。 - クラスターの中でリーダーよりももっと整合性の高い方法で決定でき、downを果たせる役割はいないでしょうか？ - クラスターが２つに分割される場合、どちらが正しいクラスターなのでしょうか？ - 正しくないクラスターを決めたとして、そのクラスターのメンバーをどうすべきでしょうか？
- #23: split brain問題を様々な方法で解決するsplit brain resolverを紹介します。実装はLightbend社によるプロプライエタリなものと、私が作ったオープンソース実装があります。 split brain resolverのストラテジにはいくつかあり、この中の２つを紹介します。
- #24: Keep Oldestストラテジは、クラスターがネットワーク分断を起こしたときに、最古のメンバーがいる側を正のクラスターとします。そうでない側のメンバーは自らシャットダウンします。unreachableなメンバーをdownする役割は最古メンバーが担います。 最古メンバーがどのように決まるのかを解説します。クラスターのメンバーは起動したときのタイムスタンプを持っています。状態がRemovedでないメンバーの中でこのタイムスタンプが最小のメンバーが最古メンバーです。リーダーとは異なり、最古メンバーはたとえgossipが収束していなくてもすべてのメンバーで一意に決まります。 Keep Oldestストラテジは可用性の点で問題があります。最古メンバーがクラッシュした場合、全クラスターメンバーがシャットダウンします。これを防ぐためには、`down-if-alone`オプションを有効にします。これにより最古メンバーのみがクラッシュした場合、代わりに最古メンバーがdownされます。
- #25: 最古メンバーの決定はunreachableなメンバーに依存しないので分断されていても全メンバーで一意に決まります。最古メンバーを基準にする限りsplit brainはほぼおきません。
- #26: Static Quorumストラテジはネットワーク分断のさい残存メンバーがquorum sizeに満たない場合、そのメンバーをdownします。メンバー数が９でquorum sizeが５の場合に５：４に分断した場合、５の側が生き残り４の側はdownします。 他のメンバーをdownする役割はリーダーが担います。quorum-size * 2 - 1を超えるメンバーを追加しない限りsplit brainはおきません。Static Quorumの可用性は総ノード数とquorum sizeで調節可能です。Static Quorumはメンバーの数を固定しなければならない点が弱点ですが、特定のロールに固定することで、他のロールはダイナミックにメンバー数を変えることができるので、この設定をお勧めします。
- #27: 分断された場合leaderは２つできる点は変わらないのですが、残存ノードがquorum sizeを満たしているものは片方だけです。
- #28: 残念ながら完璧なsplit brain resolverのストラテジはありません。FLPとして知られる有名な研究の結果では、非同期なシステムにおいては、ただ１つのプロセスが故障しただけでも、分散アルゴリズムによる合意はできないと結論付けています。 split brain resolverの各ストラテジは、合意できないケースが現実のシステムではごく稀な例外になっており、現実的な解法といえます。
- #30: オミッション故障とは、プロセスが送るべきメッセージを送らない、あるいは受信するべきメッセージを受信できない故障です。プロセスがクラッシュした场合も送るべきメッセージを送れないので、オミッション故障はクラッシュストップ故障のより一般的な场合と见ることができます。
- #31: Akka Clusterでは、送るべきはずのシステムメッセージを送信できず、ローカルとリモートのアクターシステム間の状態が同期できなくなったときにオミッション故障となります。システムメッセージはユーザーメッセージとは異なり、exactly-once送信保証で実装されています。具体的にシステムメッセージとは、リモートスーパーバイザーに管理されたアクターのライフサイクルイベント、watchによる死活監視、リモートアクターのデプロイメントが該当します。これらの送信が確認できないときにAkka Remoteの状態はquarantinedになります。quarantinedになると、そのメンバーはunreachableから戻ってこれなくなります。解消するにはクラスターから取り除くかアクターシステムを再起動する必要があります。auto-downやsplit brain resolverを使用している場合、unreachableなメンバーをクラスターから取り除く作業は自動で行われ、取り除かれたメンバーはアクターシステムをシャットダウンします。つまりこの場合Akka Clusterにおいてオミッション故障はクラッシュストップ故障と全く同じ扱いになります。
- #33: クラッシュ?リカバリー故障はプロセスがクラッシュしただけでなく、そこからリカバリーできない、あるいはクラッシュと再起动を繰り返してしまう故障です。リカバリーできない场合、送るべきはずのメッセージを送れないので、オミッション故障と见ることもできます。
- #34: Akka Clusterのレイヤーではクラッシュしてクラスターから取り除かれたノードが再起動してクラスターに再加入することを前提としていません。なのでクラッシュしたままでも問題はなく、クラッシュ?リカバリー故障はおきません。
- #35: Akka Clusterが再起動したノードをどのように扱うかを解説します。Akka Clusterはメンバーを３つの識別子のタプルで認識します。hostname:port:uidです。uidはアクターシステム起動時に発行されるユニークなIDです。このuidによってたとえホストとポートが同じでも、再起動した後ではuidが異なります。つまり再起動してクラスターに再加入することは、新しいメンバーがクラスターに加入することと全く同じです。こうすることによってAkka Clusterはクラッシュ?リカバリー故障を考慮する必要がなく、単純化しています。
- #36: ノードがクラッシュした後再起動してクラスターに加入する際、クラッシュしたメンバーはunreachableとなってリーダーアクションがとれないため、ノードが再加入できるのか疑問が残ります。このような蘇り(incarnation)ノードの扱いについて解説します。クラスターのメンバーと同じホスト：ポートのペアをもつメンバーが加入してきた場合、Leaderは古いメンバーを自動的にdownします。これはauto-downやsplit brain resolverを使わなくても行われます。これによって再起動したノードはクラスターに参加することができます。なぜこのケースでdownが安全に可能かというと、同じホスト：ポートのペアをもつメンバーが同時に２つ存在することはありえないからです。古いメンバーはクラッシュしたということをLeaderは確実に判断できます。このような特徴があるので、基本的にプロセスを再起動することを勧めます。そうすればクラッシュしてもクラスターが縮小することはなく、自動的にもとの大きさに戻ります。
- #37: 複数のDCにAkka Clusterをデプロイしている場合、再起動には注意が必要です。２つのAZ間でネットワーク分断を起こした場合、split brain resolverによって片方のAZのメンバーのみが生き残ります（AZ2とします）。自ら死を選んだもう一方のAZ（AZ1とします）のメンバーは再起動した後、この図のようにjoining状態でネットワーク分断が解消されるまで待ち続け、ネットワーク分断が解消されたら再びクラスターに戻ることが理想です。このときクラスターに加入するための第一seedノードは、生き残った方のAZ2に存在しなければなりません。第一seedノードとはクラスターを０から構築する際の起点になるノードのことで、設定に記述します。
- #38: これがクラスターに加入するための第一seedノードを、AZ1に設定してしまった場合です。再起動したAZ1のノードたちは、それらだけでクラスターを作ってしまい、split brain状態になってしまいます。第一seedノードはクラスターを０から構築する際の起点になるので、split brain resolverで残す判断の基準になるノード群（この場合quorum sizeの３を満たせる側のAZ2）があるAZに置く必要があります。プロセスの再起動を有効にして複数のAZで利用する際は、どのAZをクラスターの正とするか決め、それを固定することをお勧めします。