悩んだり調べたりした過程も書いているので、記事が長くなってしまった。まとめるのが下手だ。早くスレーブサーバでもバイナリログを有効にする方法が知りたい人は読み飛ばしてください。
MySQLでレプリケーションを組みました。レプリケーションサーバでは、こちらの都合でサーバを停止することができるので、停止して安全にmysqldumpによるバックアップをしています。 その時点でのフルバックアップはmysqldumpでとれるのですが、差分バックアップに使うにはバイナリログも同時にバックアップする必要があります。バイナリログがスレーブサーバでも有効になっていれば、バイナリログファイルが作成されるので、特にそれ以上のバックアップは必要ないと思っていました。
マスターサーバとスレーブサーバの設定ファイルは、基本的に同じ設定だと思います。スレーブサーバで参照を分散させている場合は、メモリ割り当てなどは違う部分はあるのかもしれませんが、やっぱり基本的に同じになると思います。 レプリケーションをするために、マスターサーバはバイナリログを出すことは絶対に必要です。そのバイナリログをスレーブサーバは取得して、同じクエリを発行して、マスターサーバと同じ状態を保っています。 だから、スレーブサーバでもマスターサーバと同じ設定でバイナリログを有効にしているので、ある意味バックアップができていると思っていました。
運用してしばらくしていて気がついたけど、スレーブサーバのバイナリログのファイルの容量が少なすぎる。バイナリログなので小さいサイズになっているが、それでも小さすぎる。そして、ローテートされたログのファイルサイズも全部同じ。毎日同じ量のクエリなんてありえないはずなのに…。念のため、マスターのバイナリログを確認すると、容量は毎日違うし、けっこうな大きさになっているファイルばかりだった。 スレーブのバイナリログの中身を確認すると、どうもログのローテートが行われた日付とかくらいしか内容がない。つまりクエリ自体が全くないことになっていた。
設定ファイルでは、スレーブサーバでもバイナリログは有効になっていたし、確かにバイナリログもつくられているので、スレーブではバイナリログはでない仕様なのかな、と勝手に思った。しかし、レプリケーション構成で、デュアルマスター構成︵2台でお互いにマスター且つスレーブ︶や、スレーブがまた下位のスレーブのマスターになる複数台の構成というものがあり、レプリケーションのマスターになるためにはバイナリログをださないといけないと考えるとどうもおかしい。 設定ファイルの記述間違いもないので、再起動だけしてみるとバイナリログのファイルサイズが大きくなったので、もしかしたらこれは何かのミスでうまく作動していなくて、今まで有効になっていなかったのかなと思った。マスターでクエリを発行して、レプリケーションのバイナリログのサイズを確認したが、ファイルサイズに変更がない。やっぱりうまくいってないみたいだ。 mysqlbinlogコマンドを使って、スレーブのバイナリログをちゃんと見ると、どうも再起動したことなどがログで残っているだけだった。ここから推測すると、このスレーブサーバ自身だけにうったクエリはバイナリログに記録されるが、レプリケーションされたクエリは記録されないのではないかと思った。
じゃぁ、どうやってバイナリログをバックアップしたらよいのか？ マスターサーバからバイナリログをMySQLの機能じゃなくて、コピーとかするべきなのか。いや、マスターからのバイナリログがリレーログに1度記録されてからクエリを実行しているから、リレーログをバックアップとして見るべきなのか。でも、リレーログも1日とかで前日の分がなくなってしまうので、これを別にバックアップしないといけなくなる。なんか変だ。 釈然としないまま、ネット上をいろいろ調べていて、発見した。というか、普通にMySQLのリファレンスマニュアルに書いてあった。起動時に--log_bin、--log-slave-updatesオプションを使って起動するか、下記のことを設定ファイルに追加するだけだった。
長くなったけど、ようやくすっきりした。mysqldumpによるフルバックアップが1週間ごとなので、スレーブサーバのバイナリログは、念のため10日分の保存にした。これで何かあっても、きっと差分の部分までスレーブサーバにあるファイルだけでリストアができるはず。
MySQLでレプリケーションを組みました。レプリケーションサーバでは、こちらの都合でサーバを停止することができるので、停止して安全にmysqldumpによるバックアップをしています。 その時点でのフルバックアップはmysqldumpでとれるのですが、差分バックアップに使うにはバイナリログも同時にバックアップする必要があります。バイナリログがスレーブサーバでも有効になっていれば、バイナリログファイルが作成されるので、特にそれ以上のバックアップは必要ないと思っていました。
マスターサーバとスレーブサーバの設定ファイルは、基本的に同じ設定だと思います。スレーブサーバで参照を分散させている場合は、メモリ割り当てなどは違う部分はあるのかもしれませんが、やっぱり基本的に同じになると思います。 レプリケーションをするために、マスターサーバはバイナリログを出すことは絶対に必要です。そのバイナリログをスレーブサーバは取得して、同じクエリを発行して、マスターサーバと同じ状態を保っています。 だから、スレーブサーバでもマスターサーバと同じ設定でバイナリログを有効にしているので、ある意味バックアップができていると思っていました。
運用してしばらくしていて気がついたけど、スレーブサーバのバイナリログのファイルの容量が少なすぎる。バイナリログなので小さいサイズになっているが、それでも小さすぎる。そして、ローテートされたログのファイルサイズも全部同じ。毎日同じ量のクエリなんてありえないはずなのに…。念のため、マスターのバイナリログを確認すると、容量は毎日違うし、けっこうな大きさになっているファイルばかりだった。 スレーブのバイナリログの中身を確認すると、どうもログのローテートが行われた日付とかくらいしか内容がない。つまりクエリ自体が全くないことになっていた。
設定ファイルでは、スレーブサーバでもバイナリログは有効になっていたし、確かにバイナリログもつくられているので、スレーブではバイナリログはでない仕様なのかな、と勝手に思った。しかし、レプリケーション構成で、デュアルマスター構成︵2台でお互いにマスター且つスレーブ︶や、スレーブがまた下位のスレーブのマスターになる複数台の構成というものがあり、レプリケーションのマスターになるためにはバイナリログをださないといけないと考えるとどうもおかしい。 設定ファイルの記述間違いもないので、再起動だけしてみるとバイナリログのファイルサイズが大きくなったので、もしかしたらこれは何かのミスでうまく作動していなくて、今まで有効になっていなかったのかなと思った。マスターでクエリを発行して、レプリケーションのバイナリログのサイズを確認したが、ファイルサイズに変更がない。やっぱりうまくいってないみたいだ。 mysqlbinlogコマンドを使って、スレーブのバイナリログをちゃんと見ると、どうも再起動したことなどがログで残っているだけだった。ここから推測すると、このスレーブサーバ自身だけにうったクエリはバイナリログに記録されるが、レプリケーションされたクエリは記録されないのではないかと思った。
じゃぁ、どうやってバイナリログをバックアップしたらよいのか？ マスターサーバからバイナリログをMySQLの機能じゃなくて、コピーとかするべきなのか。いや、マスターからのバイナリログがリレーログに1度記録されてからクエリを実行しているから、リレーログをバックアップとして見るべきなのか。でも、リレーログも1日とかで前日の分がなくなってしまうので、これを別にバックアップしないといけなくなる。なんか変だ。 釈然としないまま、ネット上をいろいろ調べていて、発見した。というか、普通にMySQLのリファレンスマニュアルに書いてあった。起動時に--log_bin、--log-slave-updatesオプションを使って起動するか、下記のことを設定ファイルに追加するだけだった。
[mysqld] log_bin = /var/log/mysql log_slave_updates expire_log_days = 10log_binは、バイナリログを出力するディレクトリ。 log_slave_updatesは、スレーブでもマスターから送られてきたクエリもバイナリログに出力する。 expire_log_daysは、バイナリログをいくつ保存するかの設定。このオプションは記述しなくても、デフォルトで10が指定されている。
長くなったけど、ようやくすっきりした。mysqldumpによるフルバックアップが1週間ごとなので、スレーブサーバのバイナリログは、念のため10日分の保存にした。これで何かあっても、きっと差分の部分までスレーブサーバにあるファイルだけでリストアができるはず。
