Warning: Skipping the data of table mysql.event. Specify the –events option explicitly.
MySQLデータベースをmysqldumpでバックアップする際にWarningが表示された。今までは表示されたことがなかったのに。読んで字の如く、mysql.eventというテーブルはスキップした、と書いてある。
eventテーブルって・・・なんだったっけ。
それもダンプしたい時は以下のオプションを付けてmysqldumpする。
–events
ダンプしなくて良くて、でもエラーメッセージも消したい場合は以下のオプション。
–events –ignore-table=mysql.event
http://www.linuxbrigade.com/warning-skipping-data-table-mysql-event/
今、借りているVPSの一つ、ConoHaが停止させられた。メールの文面を見ると、支払いができていないらしい（プログラムで送信されたメールのようだが変数が正しく置換されていなくて少し戸惑ったが）。諸般の事情でクレジットカード払いから口座引き落としに変更してもらったのだが、トラブっているのかもしれないと思って「支払うから方法を教えて」とメールしてみた。折り返しのメールで、「入金は確認していて手違いでした」の連絡が来た。改めて引き落とし口座を確認したら、きちんと引き落としされていた。低姿勢で「お金払います」といったが、引き落としをちゃんと確認していればもっと強気で言えたのに。
サーバは停止されていたが、すぐに復旧された。もともと開発用に借りていたサーバで、数ヶ月くらい寝かしたままだったので問題はなかったのだが、止まっていたMySQLの起動ができなくて困ってしまった。
Another MySQL daemon already running with the same unix socket.
んー。どうもVPSは強制停止させられた状態っぽい。強制終了されたので、sockファイルが削除されずに残ってしまっている感じ。確認したらやっぱりファイルがあったので、削除した。
rm /var/lib/mysql/mysql.sock
これで起動できた。
調べてみたら、あと連絡が3日ほど遅かったら、VPSが削除されるような感じだった。もし、この状態で本当に削除されていたら、当然データの復旧は難しいと思うのだが（バックアップはあるだろうけど）、どういう責任をとったんだろうと、ふと不思議に思った。
今回は実害がなかったのでクレームは入れない（開発を再開するきっかけになったから）。でも、厳重注意だね。
自社サービスの問い合わせで「ログインできない」「データが消えている」というクレームをもらうことがある。今までのところ、ほぼその全てが「利用者側の誤った操作」によるものだ。たちの悪いことに自分に責任があることがわかっているにもかかわらずとぼけて問い合わせしてくるような人もいるようだ。
無料のサービス・全て自己責任で、というのがインターネット登場当時の昔の一般的な考え方だったかと思うが、昨今では無料サービスでも懇切丁寧なサポートを求める人が多いようだ（自分の意に沿わない返答だったからといってブログで「サービスが悪い」と書いたりする輩もいるからムカつくのだが）。
それはさておき、データの保全性と操作の履歴を確認できるよう、自社サービスにMySQLのバイナリログを出力するよう設定してある。このデータとapacheのログを見れば、だいたいいつ誰がどういう操作をしたのかというのは見当がつく。apacheのログはテキストだが、MySQLはその名の通りバイナリ。そのままテキストエディタで開くと、文字化けするところがあるのでやや見づらい。ということで、以下のコマンドを使って確認する。
mysqlbinlog ./mysql-bin.000004
スクロールして確認する場合は「| less」、テキストファイルに書き出すには「> ./log.dump」みたいな感じで。バイナリログはプログラムのバグ確認にも有効でとっても便利な機能だ。しかし「それでも俺はやってない」的なクレームもあるが、それはもう放置だよ。勝手にやってくれ。
mysqlのバックアップファイルをコマンドラインから復元する際のコマンドのメモ。
mysql -h localhost -u username -p -B dbname < /path/to/backup.dump
最近シェルが使えない環境ばかりだったから、ウェブベースの復元ツールを探したりして手間がかかってたけど、自分のサーバで必要に迫られて、かつやり方を完全に忘れていたので、検索してしまった。
忘れないようにメモしておく。
MySQLのバックアップで躓いたのでメモ。
クライアントからの依頼でサーバの移行作業中、MySQLのバックアップができなくて困った。phpMyAdminからエクスポートしようとしたのだけれど、ダウンロードしたファイルが0キロバイトになってしまう。何故だろうと調べたら、どうやらデータ量が多すぎるため、PHPでエラーが出ているような感じ。たった40MiB程度のデータしかないのに。root権のない専用サーバだから付属のphpMyAdminの設定を変更することもできない。専用サーバなんだから単にフリーソフトを置いとくだけ、とかやめてくれよ。
ドキュメントルートに別途phpMyAdminを入れようかと思ったけど、はまってしまうと怖いので専用のツールがないか調べてみたらありました。phpMyBackupPro（略してpMBP）。
まずダウンロード、展開してサーバにアップロード。次にパーミッションの変更。「global_conf.php」「export/」のファイル、ディレクトリをそれぞれ777に変更。そしてウェブからアクセスする。「MySQL data is not correct.」というメッセージが出ていても気にしない（データベースに接続できていませんという意味らしいので表記を直してほしいな）。メニューのconfigurationタブからホスト名、ユーザ名、パスワードを入力して保存する。この時点で表示されているエラーも消える。
ちなみに借りているサーバでは、デフォルトのホスト名がlocalhostになっていた。これはこれでいいはずなのだが、ユーザ名とパスワードを正しく入力しても何時まで経ってもエラーが消えない。まさか、と思って記述を127.0.0.1にしたらうまく動いてくれた。まったくこのサーバは異常だと思う。普通のサーバらしく設定してくれさえすればなんの問題もないのに。
その後、メニューのbackupをクリックし、バックアップしたいデータベースを選んで、「Backup」ボタンをクリックし、「File successfully saved as hoge.1363399936.sql」などと表示されたらバックアップは無事終了。最初にパーミッションを変更したexport/にファイルが保存されている。
このツールはインポート機能も備えているので、次回、これも試してみるとしよう。