タグ別アーカイブ: MySQL

MySQL5.6インストール

先日リリースされたMySQL5.6の導入方法のメモです。

 

環境はCentOS5.8(64bit)になります。

 

まず、RPMが用意されているので、落とします。

ココからダウンロード

 

とりあえず、MySQL Server本体と、接続するためのClientがあれば基本操作はこなせるので、

その二つを落とします。

  • MySQL Server本体
    Linux – Generic (glibc 2.5) (x86, 64-bit), RPM Package
    MySQL Server
    (MySQL-server-5.6.10-1.linux_glibc2.5.x86_64.rpm)
  • Client
    Linux – Generic (glibc 2.5) (x86, 64-bit), RPM Package
    Client Utilities
    (MySQL-client-5.6.10-1.linux_glibc2.5.x86_64.rpm)

 

落としたRPMをサーバまでもっていきます。

※サーバ上で直接落とす場合は、

$ wget http://dev.mysql.com/get/Downloads/MySQL-5.6/MySQL-server-5.6.10-1.linux_glibc2.5.x86_64.rpm/from/http://cdn.mysql.com/
$ wget http://dev.mysql.com/get/Downloads/MySQL-5.6/MySQL-client-5.6.10-1.linux_glibc2.5.x86_64.rpm/from/http://cdn.mysql.com/

そして、インストール・・・しようとすると、

「公開鍵がインポートされていないために信頼できる提供元かどうかわからない」旨の警告が出ます。

無視するコマンドオプションもあった気がしますが、

このページに取得方法が載っています。

上記ページに書いてある方法が面倒であれば、

書いてあるキーの部分をコピペしてキーファイルを作ってしまうという手もありますw

そして、公開鍵をインポートした上で、

 # rpm --import mysql_pubkey.asc
 # yum localinstall MySQL-server-5.6.10-1.linux_glibc2.5.x86_64.rpm
 # yum localinstall MySQL-client-5.6.10-1.linux_glibc2.5.x86_64.rpm

以上で、インストールは完了です。

 

 

インストール後、いざ接続してみようとすると接続できませんでした・・・

原因は、5.6はRPMで入れると初期パスワードがランダムで設定されるからでした。

こちらの記事のおかげですぐに解決しました。

 


MySQL5.6の気になる機能

MySQL5.6のGA(Generally Available)版が近日リリースされるとの噂を聞きました。

リリースされたらすぐに使うかもしれない(少なくとも検証はするはず)ので、

以前から気になっていた魅力的な新機能や改善点をピックアップしておきたいと思います。

 

  1. レプリケーションの自動フェイルオーバー

    MySQL Utilities(に含まれるmysqlfailover)と組み合わせることで、
    レプリケーションマスタの障害時に自動フェイルオーバーができるようになった。
    今までも、MHAというDeNA社が社内開発したものをOSSで公開したツールを利用することで可能でしたが、
    調べてみたところMySQL Utilitiesの方が導入・設定が簡単そうなことと、
    正式サポートの安心感があるので嬉しい機能です。

  2. サブクエリの高速化

    Semi Joinが利用できるクエリ(基本的にはOR条件ではないEXISTS句やIN句)が最適化されて高速化された。
    これは、よく遅くて困るところなので、どれほどのものかかなり気になります。

  3. InnoDBのFULLTEXTインデックスサポート

    マルチバイトUTF-8にどこまで対応しているのかが不明ですが、本当に正しく使用できるのであれば気になる機能です。

 

あとは、オプティマイザとCPU効率がかなり良くなったとのことなので、 単純に性能向上がどれほどのものか気になります。

 

この間のチューニンガソンでは、「5.6にしたら遅くなった・・・」と言っていた方がいたので、

単発のクエリはあまり期待できない気がしますが、

オラクルの公式ブログのグラフでは単位時間あたりのトランザクション数が倍くらいに向上している図があったので、

並列処理の効率アップは期待できそうです。


MySQLがクラッシュした時にやったこと

先日、当然MySQLのプロセスがダウンし、
正常に再起動しない事態となりました。

バックアップは日次のみで、最悪の場合は日次バックアップに戻すとしても、
できることなら最新のデータを保持したまま復旧したいということで、
できる限りのデータを救い上げて復旧するために行なった手順をメモしておきます。
緊急だったので、手順の是非はありますが、とりあえず以下の通りです。

 

  1. 起動スクリプト(/etc/init.d/mysqld)ではなく、mysqld_safeによる起動を試みる
  2. 強制リカバリモードでの起動(innodb_force_recoveryのレベルを1つずつあげながら、起動するまで)
  3. mysqldumpでデータを抜き出す
    (クラッシュしているテーブルに当たるとエラーで止まるので、都度除外しながら)
  4. 3で発覚した、クラッシュしているテーブルの復旧を試みる
  5. 最後の手段!同環境の別サーバを立ててデータを移行する
  6. クラッシュしていて抜き出せなかったテーブルを手動で復旧する

 

1. 起動スクリプト(/etc/init.d/mysqld)ではなく、mysqld_safeによる起動を試みる

# /usr/bin/mysqld_safe --user=root &

この時点では、原因が分からなかったので別の方法でとりあえず起動させてみようということで行いましたが、
あとで調べたら、起動スクリプト(/etc/init.d/mysqld)も中でmysqld_safeを呼んでいるらしく、この作業は時間の無駄でした・・・

起動ログ(/var/log/mysqld.log)を見ると、クラッシュリカバリに失敗して起動できていないことがわかったので、

2. 強制リカバリモードでの起動(innodb_force_recoveryのレベルを1つずつあげながら、起動するまで)

# vi /etc/my.conf
[mysqld]
 innodb_force_recovery = 1    #1~6まで、起動するまで一つずつ上げていく

1~2まで特に変わらず起動失敗。3で起動はするけどデータベースが認識できていない感じでした。
4でやっと一応ちゃんと動く形で起動しました。

 
復旧に入ろうにもとりあえず、救えるだけのデータは救ってから・・・ということでとりあえずバックアップを取ります。

mysqldumpでデータを抜き出す
(クラッシュしているテーブルに当たるとエラーで止まるので、都度除外しながら)

 # mysqldump -uroot -pパスワード DB名 > /tmp/backup.dump

クラッシュしているテーブルに当たるとエラーを吐いて止まります。
とりあえず、クラッシュしているテーブルは都度スキップしながら救えるだけ救います。

 # mysqldump -uroot -pパスワード --ignoretable=壊れているテーブル名 DB名 > /tmp/backup.dump

「–ignoretable=壊れているテーブル名」は壊れているテーブル分だけ繰り返します。

3で発覚した、クラッシュしているテーブルの復旧を試みる

 # mysqlcheck -r DB名 壊れているテーブル名 -u root -pパスワード

起動時のリカバリシーケンスで失敗しているので、期待薄な気はしていたのですがやはり駄目でした・・・
不幸中の幸いで壊れているテーブル、最悪中身は無くても良かったので、
とりあえず先に進みます。

 

最後の手段!同環境の別サーバを立ててデータを移行する

ここは、ただのMySQLサーバ構築なので割愛します。
イメージバックアップがあったので、一から作る必要はなかったのですが、
権限周りだけ再設定が必要でした。
そして、データを入れます。

 # mysql -uroot -pパスワード DB名 < /tmp/backup.dump

 

クラッシュしていて抜き出せなかったテーブルを手動で復旧する

とりあえず、最悪中身は無くても良いテーブルだったので、
DDLだけ流してテーブル構造だけ先に戻してアプリを復旧させ、
後で日次バックアップから入れられるだけのデータを入れました。

 
後でわかったのですが、
クラッシュしたのはMySQL5.0のバグとのことでした・・・(サポート公式回答済み)
古いバージョン使い続けるのは良くないということと、
費用がきつくても被害が大きくなる場合は、
最低限フェイルセーフレプリケーションだけでもやるべきだな~痛感した一件でした。。。

そもそも、無駄に高い国内DCなんて使わずに、
Amazon RDSを使えば、こんな心配もせずに済むんですけどねw