Galera Clusterでバイナリログは有効にすべきか

この記事は最終更新から6年以上経過しています。内容が古くなっている可能性があります。

以前、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


 

 

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃オープンソースデータベースのサポート業務に従事している有資格者で構成された技術サポートチームがPerconaに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次