phpMyAdmin で MySQL サーバの状態を見る。

図1 状態モニタ
図1 状態モニタ
 TODOS・何でも情報交換で phpMyAdmin での MySQL のログの確認みたいな話が出ていて,その件についてちょっと調べたので,覚え書として書いておく。
 
 phpMyAdmin 4.0 (多分) 以降を使っている場合,状態モニタというグラフのページがある。ログインして,テータベースを選択せずにメニューから, 状態 > モニタ と進むと,グラフが見える。サーバがまともに動いている場合,グラフだけで十分ではないかと思うんだが,必要ならここから slow_query_log や general_log を参照できる。
図2 無効
図2 無効
graphページで,「使用方法/セットアップ」をクリックしたときに,以下のメッセージ(図2も参照)が出るようなら, xxx_log の値を ‘ON’ に log_output の値を ‘TABLE’ に変更しなければいけない。
   slow_query_log および general_log は無効です。
   log_output はテーブルに設定されていません。
 
 もし,特権ユーザなら自分で値を変えられるが,普通は管理者に頼むことになる。まあ, root 権限でログインしないと,この辺は変えられないはずで,あんまり誰でも変えられるようだと,そのサーバは大問題だろう(爆)。
 正常動作しているサーバなら, general_log は必要ないかな?サイズが馬鹿でかくなって,他を圧迫する恐れがあるし。もしとるなら,サイズで切り出して,どこかに保管するような管理をする必要があるだろう。変数の値を変更するなら,何はともあれ, root 権限でログイン。
 
  コマンドラインからやる場合:
   SET GLOBAL slow_query_log = ON;
   SET GLOBAL log_output= TABLE;

 
  phpMyAdmin からやる場合:
   1.データベースは選択せずにメニューの変数をクリック。
    フィルタの「含まれている文字」フォームに “slow query log” その後,値を ‘ON’ に編集。
    保存
   2.フィルタの「含まれている文字」フォームに “log output” その後,値を ‘TABLE’ に編集。
    保存。
 
 一応,ログアウト。
図3 有効
図3 有効

 これで, root 権限でログインしたとき,状態モニタで, “slow_query_log” が参照できるようになった。
 
 これだけだと, mysqld を再起動すると,元の設定に戻ってしまう。設定を維持させるためには, my.ini/my.cnf の [mysqld] に以下の2行を付け加える。
   slow_query_log = ON
   log_output = TABLE
 
 前記のように, root 権限で状態モニタから “slow_query_log” が使えるようになったわけだが,ちょっと不便である。 WordPress の MySQL アカウントでログインしたときだって,使えないと意味ないでしょ。いつも root でログインなんて,非現実的だ。で,くりくりさんに TODOS・何でも情報交換で「こういう場合,一般ユーザにはどの程度権限を与えるべきでしょうか」とちょっと聞いてみた。「データベースだけでも参照はできますよ」というお返事だった。そんなわけで,以下のコマンドをやってみた。
 slow_log テーブルは mysql データベース上にあるので,
 
   GRANT SELECT (lock_time, start_time, rows_examined, db, rows_sent, query_time, sql_text, user_host) ON mysql.slow_log TO ‘WP-user’@’localhost’;
 
 これだと,非常に限定的な権限になるので,まぁ,許容可能かなと思う。
 
 現時点で,うちの WordPress の MySQL 用アカウントの権限は,下記のようになっている。
————
GRANT USAGE ON *.* TO ‘WP-user’@’localhost’ IDENTIFIED BY ‘passphrase’;
GRANT ALL PRIVILEGES ON WPdatabase.* TO ‘WP-user’@’localhost’;
GRANT SELECT (lock_time, start_time, rows_examined, db, rows_sent, query_time, sql_text, user_host) ON mysql.slow_log TO ‘WP-user’@’localhost’;
————

青ざめちゃいました-#3。

 ひゃー,ひどい目にあった。もっとも,誰にも文句の言えない事態なのだが。

 昨日, MariaDB と phpMyAdmin について書きかけて,ふと, MariaDB のエラーログを見てみたら,なんかいろいろ出てて,手動でアップデートしてたからまずかったのかなと,いじり始めて,熱中してたら,穴に落ちた。連続でやっていたので,何が悪かったのかよくわからないという間抜けな事態。何年かにいっぺんやらかしますナ。

 結局, SQL サーバの復旧に失敗して, MariaDB 10.0.12 をインストールしなおした。本当は,復旧にかかわりあわずにサクッと,インストールしなおして,データベースの再構築をやればよかったのだが,なんと,久しぶりに,直近のバックアップをしていなかったという事態で,あきらめ悪く,イジイジとやっていたのだ。のど元過ぎると,バックアップをしないで,落とし穴のあるところに行くという……我ながら,学習能力なさすぎ。

 結局,英語記事がひとつと,昨日の午前中に書いた, MariaDB と phpMyAdmin 関連の記事が消えた。

 どうせ,こうなるなら,早いところ, SQL サーバの復旧をあきらめるんだったなぁ。そんなわけでとんでもない時間でありまする。

本家のお世話-#105。(MariaDB10.0.11へアップデート)

 本題に入る前に。
 林隆三が亡くなった。訃報の中に「急死」という表現が見られた。林さん, 70 歳だったそうである。今どきとしては,まだ若いと言える。落ち込む。
 心より,ご冥福をお祈りする(合掌)。

 MariaDB10.0.11 にアップデートした (サーバOS : Windows7HP+SP1(x86))。手順は,下記の通り。

 何はともあれ,バックアップ。特に, MariaDB と MyDB

 で,アップグレード。

  1. mariadb-10.0.11-win32.zip をダウンロード。
  2. Zip を展開。
  3. コントロールパネル >> 管理ツール >> サービス
    と行って, MyDB のサービスを停止。
  4. MariaDB の中身をすべて削除。その後, bin,include,lib,share の4つとライセンス関係のファイルを MariaDB の中にコピーする。
  5. コントロールパネル >> 管理ツール >> サービス
    と行って, MyDB のサービスを開始。

 以上。

 ついでに, phpMyAdmin 4.2.3 へのアップデートもやっておいた。 ChangeLog はこんな感じ。
 もう少し,情報がいるという方は,本家のお世話-#102。(phpMyAdmin 4.2.0へアップデート)でもご覧ください m(_”_)m。

本家のお世話-#100。(MariaDB10へアップグレード)

投稿アップデート情報  追記(6/30)

 3月31日に, MariaDB10 初の正式版が出たので,本日,自鯖上 (Windows7HP+SP1(x86)) の MariaDB を 10 にアップグレードしてみた。アップグレードなんだが,元が MariaDB5.5 なので,手順は前回のアップデートと変わらない。

 何はともあれ,バックアップ。特に, MariaDB と MyDB

 で,アップグレード。

  1. mariadb-10.0.10-win32.zip をダウンロード。
  2. Zip を展開。
  3. コントロールパネル >> 管理ツール >> サービス
    と行って, MyDB のサービスを停止。
  4. MariaDB の中身をすべて削除。その後, bin,include,lib,share の4つとライセンス関係のファイルを MariaDB の中にコピーする。
  5. コントロールパネル >> 管理ツール >> サービス
    と行って, MyDB のサービスを開始。

 以上。

追記(6/30):
 書き忘れていたが,アップグレード後,エラーログを見たら “Please use mysql_upgrade to fix this error.” が出ていると思うので, mysql_upgrade やること。

本家のお世話-#96。(MariaDB5.5.36へアップデート)

 本日,自鯖上 (Windows7HP+SP1(x86)) の MariaDB を 5.5.36 にアップデートした。 Changelog は,こんな感じ。

 何はともあれ,バックアップ。特に, MariaDB と MyDB

 で,アップデート。

  1. mariadb-5.5.36-win32.zip をダウンロード。
  2. Zip を展開。
  3. コントロールパネル >> 管理ツール >> サービス
    と行って, MyDB のサービスを停止。
  4. MariaDB にある bin,include,lib,share の4つを,そっくり,新しいものと入れ替える。
  5. コントロールパネル >> 管理ツール >> サービス
    と行って, MyDB のサービスを開始。

 以上。

本家のお世話-#89。(MariaDB5.5に移行)

投稿アップデート情報  追記(12/21)  追記2(12/25)  追記3(2014/6/6)

MaintenanceNotice 昨日は,一生懸命取り組んでいた。何にって,くりくりさんとの話にも出ていた Windows7HP+SP1(x86) 上での MySQL から MariaDB 移行に(汗)。

 まずは,全サーバデータのバックアップ。
 次に,右図の表示をする maintenance.html を作り,作業のために,以下の行をドキュメントルートの .htaccess の頭に追記した。(参考: mod_rewrite<IfModule>Webサイトのメンテナンス中画面を出す正しい作法と.htaccessの書き方

     ErrorDocument 503 /maintenance.html

     RewriteEngine On
     RewriteCond %{REQUEST_URI} !=/maintenance.html
     RewriteCond %{REMOTE_ADDR} !=IP address for Admin
     RewriteRule ^.*$ – [R=503,L]

     Header set Retry-After “Wed, 18 Dec 2013 01:00:00 GMT”

 ここに,「特定のモジュールの存在に関わらず動作する 設定ファイルの原本が必要なときにのみこのセクションを使用してください。 通常の動作では、ディレクティブを <IfModule> セクションの中に 入れる必要はありません。」と書いてあったので, <IfModule> はいらないかなと思いはずした。

 さて,さっき作った maintenance.html をサイト上に表示するようにして, MariaDB5.5 への移行に取り掛かった。

 MariaDB をクリーンインストールする。今回,エンジンは MyISAM から InnoDB に変えてみたい。 MySQL を使い始めたときにすべてのテーブルを MyISAM で作った。最近, InnoDB のメリットをよく聞くのでやってみたくて仕方なかった。もっとも,そうしたって,よくわかっていないから,生かしきれないと思うけど(爆)。それに,移行で泥沼にはまっている話もちょくちょく見かけたので,二の足を踏んでいた。だって,何か起きたら対処しきれないじゃないヨ,もともと,よくわかってないんだから-Haha。

 MariaDB はデフォルトで InnoDB らしい。この機会に,テーブルを作り変えてもいいや。

ステップ1 MySQL をアンインストールする。

  1. すべての WordPress プラグインを無効にする。
  2. さっきやったサーバのバックアップとは別に,すべてのデータベースを sql ファイルとしてバックアップする。
  3. ダッシュボードのツールから WordPress のすべての記事・コメントをエクスポートする。この時点では,可能なら WordPress Importer を使おうと思っていた。後述の理由で,結局あきらめたが。
  4. サービスを停止する。
    コントロールパネル >> 管理ツール >> サービス
    MySQL のサービスを選んで,停止。
  5. サービスを削除する。
    cmd.exe を管理者として実行。
    > sc delete MySql
  6. フォルダ MySQL と MyDATA を削除(<--- これらには,自鯖の MySQL 関係のものがはいっている)。

ステップ2 MariaDB をインストールする。

  1. mariadb-5.5.34-win32.zipMariaDB からダウンロードする。
  2. Installing MariaDB Windows ZIP packages にざっと目を通してから, mysql_install_db.exe について を読んだ。
  3. Zip を展開する。 MariaDB と MyDB というフォルダをサーバウェア用のパーティション Drive_SV に作り,展開でできたものを MariaDB フォルダにコピーする。

    cmd.exe を管理者として実行。
    > cd Drive_SV:\MariaDB\bin
    > mysql_install_db.exe –datadir=Drive_SV:\MyDB –service=MyDB –password=secret

    これにより,root のパスワードが設定され, MyDB の中には my.ini が作られる。

  4. コントロールパネル >> 管理ツール >> サービス
    MySQL のサービスを選んで,開始。
    もし,「スタートアップの種類」が「自動」になっていない場合は,自動になおしておく。

ステップ3 phpMyAdmin で MariaDB にアクセスする。

  1. phpMyAdmin から root として,MariaDB にアクセスする。
    バックアップしていた phpmyadmin データベースをインポートする。
  2. WordPress 用ユーザを作り, WordPress データベース用に Grant 以外のすべての privileges を付与し Global privileges は一定与えないこと。パスワードも設定する。 WordPress 用のデータベースを作成する。 collation は utf8_general_ci にする。
    ログアウト。

WordPress Importer でインポートしたが,結局止めてしまった理由。

 新しく WordPress をインストールした後, WordPress Importer でコンテンツをインポートした。間の悪いことに作業がほぼ終わってから,このプラグインが <object> などのある種のタグを移してくれないことに気づいた。 html 関係のどんなタグが対象になるのか調べるのも鬱陶しくて,この方法はやめることにした。これに結構時間かかってたんだけどね。

ステップ4 phpMyAdmin ですべてのWordPress のデータを復元する。

  1. InnoDB を使いたいので,バックアップファイル上の ‘ENGINE=MyISAM’ を ‘ENGINE=InnoDB’ に置き換えた。
  2. phpMyAdmin に WordPress ユーザとしてログインし,データベースにアクセス。
    WordPress のデータベース上の現データをエクスポート。
    現在の WordPress のデータベース上のテーブルをすべて削除。ところで,バックアップした sql ファイルには,全部が含まれていて大きいが,これを編集するのも面倒なので, php.ini のアップロードの制限を作業中だけちょっと変更した。
  3. バックアップをインポートしたら,エラーが出た。アララ。
         #1214 – The used table type doesn’t support FULLTEXT indexes

    もともと, MyISAM だったので, FULLTEXT indexes が使われていたみたい。調べてみたら, YARPP が post_title と post_content のキーとして使っていた。ウーム。 しかし,フォーラムに, we can use YARPP on the InnoDB というのがあったので読んでみたら,性能は落ちるけど, InnoDB でも使えんことはないよと,プラグインの作者が言っていたので,「エイヤッ」と全 FULLTEXT indexes 関連行を削除した。(そういえば, MySQL5.6 は InnoDBでも FULLTEXT に対応したよね。–12/25追記)

  4. もっ一回,全テーブル削除。

    書き換えたファイルをインポートしたら,あらまたエラーが……
         #1064 – You have an error in your SQL syntax;

    これは,えっと,私のミスであった。 FULLTEXT indexes を消したときに “,” の消し忘れ。
         KEY `post_author` (`post_author`),   <<--------この ',' が残っていたのヨ。      ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=xxxx ; で, ',' を削除。

  5. 全テーブル削除。

    3度目の正直。ナンチャッテ。インポート。おっ,通った。

ステップ5 通常営業に戻る。

  1. WordPess にログイン。
    全プラグインを有効化して,挙動をチェック。

    .htaccess を元に戻して,メンテ終了。

  2. 実のところ,作業後, Jetpack が親サイトでエラーを吐いている。

         Your website needs to be publicly accessible to use Jetpack: site_inaccessible
         Error Details: The Jetpack server was unable to communicate with your site https://MySITE
         [IXR -32300: transport error: http_request_failed SSL certificate problem: self signed
         certificate in certificate chain]

    でも,調べてみたところ,メンテのせいではないようだ。そんなわけで, Jetpack フォーラム での情報待ちです。

 MariaDBについては,移行完了ってところ。拍手×2。

追記(12/21):
 MyISAM から InnoDB に変更して以来, YARPP プラグインの性能低下がはなはだしい。予想以上のひどさである。 YARPP のページの示唆通り,元に戻したほうが賢明だ。

  1. phpMyAdmin にログイン。
  2. WordPress 用のデータベースを選択。
  3. wp_posts テーブルを選択。
  4. 上のナビバーから ‘操作’ を選択。
  5. ストレージエンジンを Innodb から MyISAM に変更。
  6. テーブルオプションの ‘実行’ をクリック。
  7. phpMyAdmin をログアウト。

 ところが,この変更を YARPP が認識してくれない。こういう操作のための機能も用意されているのだが,うまく働かない。解決策を探しに, YARPP サポートフォーラムに行ったら, MyISAM Override check doesn’t work というのがあった。 hussong の方法をやってみた。

  1. まず, YARPP を無効にする。
  2. phpMyAdmin にログイン。
  3. WordPress 用のデータベースを選択。
  4. wp_options テーブルを選択。
  5. 上のナビバーから ‘SQL’ を選択。
  6. SELECT * FROM `wp_options` WHERE option_name LIKE "yarpp%" をやる。
  7. 見つかったのをすべて削除。 yarpp_fulltext_disabled = 1 というのがあるはずなので,これを yarpp_fulltext_disabled = 0 に変更する。
  8. phpMyAdmin をログアウト。
  9. YARPP を有効にする。
  10. 元の設定はすべて消えてしまうので, YARPP の設定をやり直す。

 これで,タイトルと内容の検討オプションが使える。ヤレヤレ。

追記2(12/25):
 「Jetpack の不具合について。」というのを書いた。

追記3(2014/6/22):
 WordPressでの「SSL3_READ_BYTES:sslv3 alert handshake failure」を解決というのを書いた。