良いですね。日曜大工でRDBMSを作るのはもっと市民権を獲得しうる趣味だと確信しています。

分散システムを作る際に気をつける事を語ると毎度長くなってしまうのですが、データ指向アプリケーションデザイン、通称イノシシ本に書いてある事をベースラインに説明すると明快であると気づきました。

• レプリケーションされるのはトランザクションログだけで良いです。それ以外の一切のものはトランザクションログから再構成できます

  • ユーザに完了を報告する際に必ず永続化されるべき情報と、ユーザから読み出しが起きた時に何らかの加工をすべき情報との間に線引きが必要です

  • 加工をいつどこでやるかは分散DB側の裁量に委ねられています。ログの複製と同時にページへのApplyを行うのがAurora式ですが、ログの永続化と報告だけ先に済ましてしまい、Applyに関しては適宜暇な時に流すのがSocratesとかAlloyDB、という違いがありますがどちらを選んだからといって大きな間違いは無いです。

• 通信プロトコルは枯れてるものならどれを使っても劇的な違いはありません。僕ならgRPCを選びます

• 故障直前にメッセージを正しく送れる保証がないので、生き残っている側が定期的に生存報告を送る事で死活確認するしかありません。RaftのプロトコルはAppendLogのRPCの中に生存報告が含まれており無駄が少ないです

• RaftであればLeaderからの生存報告が途絶えたと判定するまでのタイムアウト時間を各Candidatesが乱数で決定し、その時間が経過したらLeaderに立候補します。Leaderの生存報告待ちだった他のCandidatesは一番最初に観測した（充分最新の）立候補に投票するので、乱数で決定する事になります。Paxosベースだと実装の幅があるのですがRaftのこの乱数タイムアウト立候補方式の方が引き継ぎが速いという利点があります

• インスタンス同士のメンバシップはLeaderがステートマシンの中で管理するべき情報の一部です。つまり参加や離脱に関してはLeaderが認識してそのメンバシップ状態をアプリの情報とは別のレイヤーで共有し続けます。ですのでLeaderと通信できる限りは漏れなく認識できています

  • CockroachDBの論文の中で報告されていた事によると、障害やノード追加によるメンバシップ変更に伴うリバランス時には障害への耐性が弱まってしまうのでJoint Consensusという方法でメンバシップ変更前後のそれぞれの状態に対するメッセージの通信を独立して行う事で解決したと言っています。曰くシンプルで堅牢なアルゴリズムとの事ですがちょっと説明は難しいです

Raftの挙動については英語ですがこのアニメーションの図解が一番わかり易いと思っています。

https://thesecretlivesofdata.com/raft/

もっと質問がありましたらどんどん聞いてください。