以前、Galera Cluster用のパラメータシート(my.cnf)を考える上でバイナリログの扱いについて悩んだことがあります。この記事では、その時に考えた内容について書いてみたいと思います。
【前提】
そもそもGaleraを使用する上で、バイナリログは必須ではありません。その代わり、Write-Set という独自の単位でノード間で更新情報をやり取りしています。
※ ただし、binlog_format=ROWの設定は必須(Galera Clusterの必須オプション)
そのため、ディスク負荷が気になる(≒サーバースペックが低い)場合は、
log_bin を無効にしても問題はありません。
【問題】
ただし、バイナリログが無効になっていると、ポイントインタイムリカバリ(PITR)が出来ません。
例えば、以下のようなケースで困ったことになってしまいます。
- 誰かが誤って DROP TABLE; を発行してしまう。
- すぐ全ノードにイベントが伝わり、DROP TABLEが実行される。
- データが全て消え、元に戻すことは出来ない。
【対策】
上記のケースで考え得る対策は以下の通りです。
1)意図的に遅延させたスレーブを用意して、そこからDROPが実行されていない時点のデータを救出する。
2)最新のフルバックアップをリストアし、バイナリログで差分を適用(DROP除く)することで消失時点のデータに戻す。
どちらにせよ、Galeraノードでバイナリログを有効にしておく必要があります。
【所感】
基本的に、バイナリログはONにしておいた方が良いと考えられます。
PITRだけを考慮すれば、 sync_binlog = 0 でも問題はないかと思いますので、パフォーマンスへの影響度も最小限に抑えられます。
また、場合によっては特定のノードのみ有効にするなどの方針を採用するのも有効だと思います。
【参考】
Typical misconceptions on Galera Replication for MySQL