Percona XtraDB Cluster設計の迷いどころ（現在進行形）

今、とあるサービスに Percona XtraDB Cluster を突っ込むことを画策しているんですが、今まさに迷っている真っ最中なのでメモしておきます。誰か何か思いついたら教えてください。

Percona XtraDB Cluster(以下PXC)というか Galera Replication の仕組みというかコンセプトというか自体が、「マルチマスターなMySQL *の* クラスター」なわけで、PXCを使えばこれは簡単に実現できます。

が。

PXCでマルチマスターすると、バイナリーログの扱いがちょっと問題になってきます。
wsrep providerが提供するPXC内の同期はGalera Cacheと呼ばれる専用のバイナリーログ(からヘッダーを取り除いたもの)に格納され、同期されます。Galera Cacheのファイルは（どういう仕組みなのか調べてないけれど）原則として一定サイズで（必要に応じて拡張され、必要なくなったら元に戻る）、これだけ見てるとInnoDBログファイルみたいにシーケンシャルに書いて、ファイルの末端に言ったら先頭に戻っている気がしなくもないです（調べてないです）

これは別にどうでも良いんですが、Galera Cacheを使って同期されたデータは log-slave-updates で拾えず、つまりバイナリーログは *更新SQLを受け取ったmysqldのみ* が保存します。
この前提かつマルチマスターにすると、

バ　イ　ナ　リ　ー　ロ　グ　が　複　数　台　に　分　散　さ　れ　、　ポ　イ　ン　ト　イ　ン　タ　イ　ム　リ　カ　バ　リ　ー　が　出　来　な　い

ことになるんじゃないでしょうか。ってか、今のところなってます。
分散するところまでは良いです。バックアップ用と割り切れば、 MariaDB 10.0のマルチソースレプリケーション とか、 MySQL 5.7のLabs版 でlog-slave-updatesもアリな気はします。MySQLには 由緒正しいN:1レプリケーション もありますが、今回はデータをごにょごにょしたいのではなくバイナリーログの保全が目的になるのでちょっとこの方式は取れなそうです。

いや、MariaDB 10.0もMySQL 5.7も *シリアライズを保証できない* 時点で完全にアウトなんですけどね :(

バイナリーログを一箇所に集めたところで、PITRの為に流しなおす範囲のバイナリーログを全てデコードして、時間順に並べ変えて…としても、バイナリーログは秒までしか時間を保存しないので、その間に同じレコードが2度更新されたりすると、どっちが最終状態として正しいのか判らなくなってPITRの一貫性が崩れる。

かといってGalera Cacheは上手く吸い上げてやるにはファイルの機構がバイナリーログとは違いそうだし、なんともかんともはや。。

codershipのフォーラムでも未対応ってことになってた（URLわかんなくなった。。）んですが、一応 *将来ね！* って雰囲気ではありました。

どうしようかなー。。


【2014/01/15 14:59】
今現在はこんなことを考えてます。。

この故に、代表マスター(と勝手に命名)トポロジーというのを考えていて、それはWrite用のVIP(代表でマスターになるノード。そいつが転けたら他のノードに割り当てる)とRead用のVIP(リードはバラけて大丈夫なので3台ストライピング)とか考えてるんですが、これならMHAで略

— yoku0825 (@yoku0825) 2014, 1月 15

PlanetMySQL Voting: Vote UP / Vote DOWN