熊崎 宏樹:データベースを専門としない人からパワポ絵の解像度でこの質問がされたなら「はい大体そんな感じです」と答えるのですが、わざわざ僕宛に質問をしている時点で質問者はただものではないので詳しく説明します。 まず「LSNをmaster nodeが発行する」の所から正しくないのではないかと思います。手元でRDBMSを作った時の知見ですが、ログデータはリカバリのために任意のLSNからそのログの実体までを高速に索引できる必要があり、その際の一番合理的な実装は「ログのオフセットをそのままLSNにする」という方法です。そして、ログのオフセットを取得する一番簡単な方法は「エンキューが成功した段階でロガーからオフセットを教えてもらう」です。つまりLSNはmaster nodeではなくstorage node側で発行しており、それを適宜教えてもらいながらmaster nodeが続くトランザクションのログを生成する、という設計でも僕の脳内のAuroraは矛盾無く動きます。オフセットが計算さえできれば良いのでmaster nodeでLSNを発行する事はそれはそれで可能ではありますがどうなっているかはわかりません。 そして、一台に制限される、というのは明確に誤りで、最近のAuroraはmulti-masterクラスタに対応しています[ドキュメント][スライド資料1][スライド資料2][スライド資料2の発表動画]。実装できるほどの技術詳細までは公開されていないようですが、仕組みとしては意外と素朴で、master nodeがログを書く際に「このページに最後に触ったときのLSNはXXXXだったはずで、その前提の上で今度はこのログを追記してね」とストレージに送信し、ストレージはそれに対しページのLSNを確認し「このページに最後に触ったときのLSNはYYYYになってるからそのトランザクションは今すぐ中止してください」と返事をすることで複数のmaster nodeによるトランザクションを実現しています。平たく言うとロガーにCASコマンドを投げ続ける形でOptimistic Concurrency Controlの枠組みで解決しています。 複数のマスターがページを奪い合う最悪の場合、両方のmasterがそれぞれLSNのあてが外れてアボートすることになります。こういうケースはOracle RACでも同様に問題になりますが、ページの実体に対して責任を持つのがストレージレイヤーのnodeであるというのは興味深いアーキテクチャと言えます。ここでmaster nodeでLSNを発行する場合を考えると複数のmaster nodeが同一のLSNで別のログを生成してしまうことに対するタイブレーカーが必要になるはずで、それっぽい物がAWS側の発表資料からは感じられないので、やはりLSNはstorage nodeが作っているのではないかと想像しています。