mysqlのレプリケーションを使う(2) バイナリログを削除する
以前に mysqlのレプリケーションを使う で、mysqlのレプリケーション(replication) について記事にしました。
今回は、その続編？というより書き漏れていた mysqlのバイナリログを削除 についてです。
前回の記事の中で、マスター側のmysqlでバイナリログの採取方法について記述していましたが、その削除や、サイクリックにロギングする設定について記述するのを忘れていました。
何も設定されていない、あるいは、削除もしていない場合は、ひたすらバイナリログは増え続けますから、いつのまにか、ディスク容量を圧迫していることもあると思います。
今回は、バイナリログの制御について、簡単に解説してみます。
レプリケーション(replication)とは、
直訳のとおり
複製を意味します。（レプリカ(replica)と語源は一緒なので、こちらがピンとくるかもしれません）
mysqlでレプリケーションと言うと、マスター、スレーブのそれぞれのmysqlサーバーを構築することに他なりません。
マスター１台に対して、スレーブ複数台というのが一般的なmysqlサーバーの構成になります。
一般的には、マスター mysql サーバー でデータベースの更新処理(書き込み)を受け持ち、スレーブ側で参照処理(読み込み)を受け持つことで負荷を分散させたり、バックアップデータベースを作成するなど行うことができます。
上の図は、その典型的なレプリケーションの例を示したものです。
ユーザは、１台のサーバーにアクセスしているつもりですが、実際のデータベースへの書き込み処理は、バックにあるマスターサーバー側で処理され、データベースの読み込み処理は、フロントのスレーブサーバーで処理されます。
特に参照がメインのサーバーでは、かなりの負荷分散が期待されます。
マスターmysqlのバイナリログを削除する
マスター側のmysqlのバイナリログを削除するのは、mysqlにログインをして、SQLで実行します。
mysqlにログインして、現状のバイナリログファイルの一覧を表示する。
$ mysql -uroot -p -Dmysql
password :
mysql> SHOW MASTER LOGS;
+----------------+------------+
| Log_name | File_size |
+----------------+------------+
| bin-log.000001 | 1074149684 |
| bin-log.000002 | 1073741963 |
| bin-log.000003 | 1073742026 |
| bin-log.000004 | 1073741905 |
:
| bin-log.000013 | 1073742045 |
| bin-log.000014 | 1073742074 |
| bin-log.000015 | 30911508 |
+----------------+------------+
15 rows in set (0.00 sec)
|
ここでは、15ファイルもあります。ここでどこまで削除したいかをLog_name列の中から決めます。
例えば、bin-log.000014 （を含まない）より以前までをすべて削除したい場合は、ここで、bin-log.000014 を決めます。
バイナリログファイルを削除する。
mysql> PURGE MASTER LOGS TO 'bin-log.000014';
Query OK, 0 rows affected (1 min 4.12 sec)
mysql> SHOW MASTER LOGS;
+----------------+------------+
| Log_name | File_size |
+----------------+------------+
| bin-log.000014 | 1073742074 |
| bin-log.000015 | 30911508 |
+----------------+------------+
2 rows in set (0.00 sec)
mysql>
|
と、これで削除できました。
この指定では、指定したファイル以前までをすべて削除します。
PURGE MASTER LOGS BEFORE ‘YYYY-MM-DD hh:mm:ss’
を利用すると、指定された日時以前までをすべて削除します。
マスターmysqlのバイナリログをサイクリックに古いものは削除するように設定する
マスターmysqlのバイナリログをサイクリックに古いものは削除するように設定してみましょう。
これも、mysqlにログインをして、SQLで実行します。
mysqlにログインして、現状のバイナリログファイルの一覧を表示する。
$ mysql -uroot -p -Dmysql
password :
mysql> SHOW GLOBAL VARIABLES like 'expire_logs_days';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| expire_logs_days | 0 |
+------------------+-------+
1 row in set (0.01 sec)
mysql>
|
expire_logs_days の値は、バイナリログの保存期間（日）になります。
上記では、0 となっているので、バイナリログの保存期間（日）は、無制限になります。
例えば、30 とすれば、30日 の意味になりますので、約１か月の保存期間を経て、削除されます。
バイナリログファイルの保存期間を30日に設定してみる。
mysql> SET GLOBAL expire_logs_days = 30;
Query OK, 0 rows affected (0.01 sec)
mysql> SHOW GLOBAL VARIABLES like 'expire_logs_days';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| expire_logs_days | 30 |
+------------------+-------+
1 row in set (0.00 sec)
mysql>
|
と、これで30日間保存します。
これは、現状動作しているmysqlに適用しましたが、mysqlがリブートされたら、消えてしまいます。
そこで、mysqlの設定ファイル(/etc/my.conf)の設定も同じように行っておきます。
mysqlの設定ファイル(/etc/my.conf)を編集します。
$ vi /etc/my.conf
...
expire_logs_days = 30
|
と、編集して保存すればOKです。
挿入する位置は、どこでも良いですが、できれば、log-binキー情報の近くが、わかりやすくて良いと思います。
ざっとこんな感じです。
情けない話ですが、すっかり、この設定を忘れていて、マスターMySQLのサーバーのディスク使用率が、98%までになっていました。
もし、この設定を忘れておられるようなら、早めの対応をしておきましょうね。自分みたいに、ディスク使用率が、98%じゃ何もできなくなってしますからね。
ご利用のブラウザは、広告ブロック(AdBlockなど) が適用となっていませんか？
このサイトでは、コンテンツの一部が非表示、あるいは、コメント、お問い合わせの投稿ができない、検索ができないことがあります。
関連記事 :
)
コメントを投稿 :