ndb_restore を使う
MySQL Cluster のバックアップには ndb_mgm -e "START BACKUP" を用いるとオンラインバックアップしてくれて素敵というか、それ以外だと mysqldump しかないんですが、こいつは確かテーブルのロックとかしまくって危なかった気がする。
と言うことで、取得したバックアップを ndb_restore する時の手順と注意。むっちゃハマった。
というか、試しに mysqldump してリストアしなおしてみたんだけど、700Mbyte ちょっとのリストアに10分以上かかって禿げ上がりそうだったので……。
読む前にndb_restore のオプションについて解説
むっちゃ色々あるっぽいけど、今回は以下だけ理解してればいいです。
-c : 使用する API ノードの IP を指定する -n : バックアップを作成した NDBD ノード番号 -b : 対象バックアップの ID -m : テーブル定義を構成する（メタ）データの復元を行う -r : バックアップからデータベースリストアを行う --include-databases : 指定したデータベースのみ復旧させる
あと、--include-databases 指定した場合、データベース自体の復元はしてくれないっぽいので、予め自分で作成しておく必要はあるもよう。
ndb_restore は万能じゃない
なにも考えずに production 環境から、毎晩取得してるバックアップを持ってきて ndb_restore してみた。
[root@WEB1 ~]# ndb_restore -n 11 -b 9 -m --include-databases=production ./BACKUP-9 Nodeid = 11 Backup Id = 9 backup path = ./BACKUP-9 Including Databases: production Opening file './BACKUP-9/BACKUP-9.11.ctl' File size 449272 bytes Backup version in files: ndb-6.3.11 ndb version: mysql-5.5.20 ndb-7.2.5 Stop GCP of Backup: 938753 Failed to initialize consumers NDBT_ProgramExit: 1 - Failed
はいアウトォー！
って、consumers って何さしてんだよ、google 先生も消費者って直訳すんなよ死んじゃうよォ。あとなんでもかんでも失敗したら 1 とか -1 とかだして Failed とか言ってればいいやっていう文化先生嫌いです。
修正しましょう
以下の記事のコメント部分「空きスロットが必要です」という解説を読んでティンときたので、動かしている API(mysqld) ノード( 192.168.1.11[WEB1] | 192.168.1.12[WEB2] ) のうち、.1.11[WEB] 側を停止してみます。
漢(オトコ)のコンピュータ道: MySQL Cluster 7.2見参！Webでも使える熱いヤツがやってきた。
[root@WEB1 ~]# /etc/init.d/mysqld stop SUCCESS!! [root@WEB1 ~]# ndb_restore -c 192.168.1.11 -n 11 -b 9 -m --include-databases=production ./BACKUP-9
や、やったー！動き出しましたよプロデューサさん！
このあとは、ndbd の数だけバックアップが作成されているはず（今回は11と12の2つありました）なので、その分を -m に代わり -r をつけてリカバリします。
[root@WEB1 ~]# ndb_restore -c 192.168.1.11 -n 11 -b 9 -r --include-databases=production ./BACKUP-9 [root@WEB1 ~]# ndb_restore -c 192.168.1.11 -n 12 -b 9 -r --include-databases=production ./BACKUP-9
