MySQL のバックアップとリストア・リカバリ

MySQL のバックアップとリストア・リカバリを行う方法として、パッケージ付属の mysqldump および mysqlbinlog の使い方(コマンドライン)を整理しておきます。

なお、この記事は、過去記事『MySQL 5.5.9 のバックアップ/リカバリ』を元に加筆・修正して、コンパクトにまとめたものです。

また、ここでは下記を前提としています。

MySQLのバージョン・・・5.5 mysql管理者rootのパスワード・・・無し 対象データベース・・・wordpress mysqldump以降のバイナリログファイル・・・mysql-bin.000111, mysql-bin.000112 1.バックアップ

全データベースをバックアップする。

[root ~]# mysqldump -u root -pxxxxxxxx –single-transaction –flush-logs –all-databases > mysqldump_`date +%Y%m%d%H%M`.sql 2.リストア・リカバリ

全データベースのリストアする。

[root ~]# mysql -u root -pxxxxxxxx < mysqldump_201201101616.sql

※特定のデータベースをリストアする場合は...

[root ~]# mysql -u root -pxxxxxxxx リストアしたいデータベース名 < mysqldump_201201101616.sql

上記リストアの後に、バイナリログによるロールフォワードを行う。

[root ~]# mysqlbinlog -u root 続きを読む »

mysqlbinlog: unknown variable ‘default-character-set=utf8’ への対処方法

mysqlbinlog を実行した際に次のようなメッセージが返ってくる場合、原因は恐らく MySQL のオプションファイル my.cnf にあると思われます。

[root ~]# mysqlbinlog mysql-bin.000222 | more mysqlbinlog: unknown variable ‘default-character-set=utf8’

私も悩まされました。 旧バージョンでの先人の経験も参考にして、実際に MySQL 5.5.11 で試した結果と合わせて、次のような結論付けをしています。

原因と対処方法

原因は、my.cnf※ の[client]グループに default-character-set=utf8 が指定されていることです。

対処方法は、my.cnf※ の[client]グループから default-character-set=utf8 を削除することです。

その後、MySQLを再起動して、再度 mysqlbinlog を実行してください。今度は正常に実行できるはずです。

※ mycnf はグローバルオプション設定用のオプションファイルとして、/etc/mycnf が既定で存在します。ここで触れている[client]グループの設定は、MySQL にアクセスしようとするすべてのクライアントに対する共通設定を行う効果を持ちます。 しかしながら、クライアントは概ねそれぞれが参照権限のあるところに MySQLへのアクセス情報を持つことが通例でしょう。少なくとも、当サイトで使用しているMySQLサーバに対するクライアントはそうです。したがって、当サイトのMySQL 5.5.11 では [client]グループごと削除してしまいました。

なお、MySQL 5.5.10、5.5.11 の/etc/my.cnf にはデフォルトで[client]グループは存在しません。

MySQL 5.5.x のバックアップ/リカバリ

WordPressのためというのが現在の主な用途ですが、MySQLを稼働させています(記事投稿時点での最新バージョン5.5.9を使用)。 さて、そうなるとMySQLには大切なデータを保存していることになるので、データの保全性とブログの可用性向上のためにバックアップ/リカバリの構築が必要になります。

もちろん、高いレベルを求めれば切りがありませんので、最も手軽で簡単な方法を採りたいと考え、まずはmysqldumpでのバックアップ運用とmysql、mysqlbinlogを使用した復旧(リストア&リカバリ)の手順を構築しておこうと思います。

【可用性要件】

要件は、 「毎日夜中に全データベースのバックアップを取る」 ということです。

【バックアップ】

オンラインバックアップを行うことにします。バックアップ設定手順は次の通りです。

1.cronの確認 [root ~]# ps -ef | grep crond root 17548 1 0 2010 ? 00:00:01 crond ←稼働している! root 55239 44276 0 23:07 pts/0 00:00:00 grep crond

稼働していない場合の対応には文字数が必要なので、ここでは割愛します。

2.crontabの確認 [root ~]# cat /etc/crontab SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 37 * * * * root run-parts /etc/cron.hourly 続きを読む »