以前、Galera Cluster用のパラメータシート（my.cnf）を考える上でバイナリログの扱いについて悩んだことがあります。この記事では、その時に考えた内容について書いてみたいと思います。

【前提】

そもそもGaleraを使用する上で、バイナリログは必須ではありません。その代わり、Write-Set という独自の単位でノード間で更新情報をやり取りしています。

※ ただし、binlog_format=ROWの設定は必須（Galera Clusterの必須オプション）

そのため、ディスク負荷が気になる（≒サーバースペックが低い）場合は、
log_bin を無効にしても問題はありません。

【問題】

ただし、バイナリログが無効になっていると、ポイントインタイムリカバリ（PITR）が出来ません。
例えば、以下のようなケースで困ったことになってしまいます。

1. 誰かが誤って DROP TABLE; を発行してしまう。
2. すぐ全ノードにイベントが伝わり、DROP TABLEが実行される。
3. データが全て消え、元に戻すことは出来ない。

【対策】

上記のケースで考え得る対策は以下の通りです。

1）意図的に遅延させたスレーブを用意して、そこからDROPが実行されていない時点のデータを救出する。
2）最新のフルバックアップをリストアし、バイナリログで差分を適用（DROP除く）することで消失時点のデータに戻す。

どちらにせよ、Galeraノードでバイナリログを有効にしておく必要があります。

【所感】

基本的に、バイナリログはONにしておいた方が良いと考えられます。
PITRだけを考慮すれば、 sync_binlog = 0 でも問題はないかと思いますので、パフォーマンスへの影響度も最小限に抑えられます。
また、場合によっては特定のノードのみ有効にするなどの方針を採用するのも有効だと思います。

【参考】

Typical misconceptions on Galera Replication for MySQL

---