まずは,全サーバデータのバックアップ。
次に,右図の表示をする 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 をアンインストールする。
ステップ2 MariaDB をインストールする。
cmd.exe を管理者として実行。
> cd Drive_SV:MariaDBbin
> mysql_install_db.exe –datadir=Drive_SV:MyDB –service=MyDB –password=secret
これにより,root のパスワードが設定され, MyDB の中には my.ini が作られる。
ステップ3 phpMyAdmin で MariaDB にアクセスする。
WordPress Importer でインポートしたが,結局止めてしまった理由。
新しく WordPress をインストールした後, WordPress Importer でコンテンツをインポートした。間の悪いことに作業がほぼ終わってから,このプラグインが <object> などのある種のタグを移してくれないことに気づいた。 html 関係のどんなタグが対象になるのか調べるのも鬱陶しくて,この方法はやめることにした。これに結構時間かかってたんだけどね。
ステップ4 phpMyAdmin ですべてのWordPress のデータを復元する。
もともと, MyISAM だったので, FULLTEXT indexes が使われていたみたい。調べてみたら, YARPP が post_title と post_content のキーとして使っていた。ウーム。 しかし,フォーラムに, we can use YARPP on the InnoDB というのがあったので読んでみたら,性能は落ちるけど, InnoDB でも使えんことはないよと,プラグインの作者が言っていたので,「エイヤッ」と全 FULLTEXT indexes 関連行を削除した。(そういえば, MySQL5.6 は InnoDBでも FULLTEXT に対応したよね。–12/25追記)
書き換えたファイルをインポートしたら,あらまたエラーが……
#1064 – You have an error in your SQL syntax;
これは,えっと,私のミスであった。 FULLTEXT indexes を消したときに “,” の消し忘れ。
KEY `post_author` (`post_author`), <<--------この ',' が残っていたのヨ。
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=xxxx ;
で, ',' を削除。
3度目の正直。ナンチャッテ。インポート。おっ,通った。
ステップ5 通常営業に戻る。
.htaccess を元に戻して,メンテ終了。
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 のページの示唆通り,元に戻したほうが賢明だ。
ところが,この変更を YARPP が認識してくれない。こういう操作のための機能も用意されているのだが,うまく働かない。解決策を探しに, YARPP サポートフォーラムに行ったら, MyISAM Override check doesn’t work というのがあった。 hussong の方法をやってみた。
SELECT * FROM `wp_options` WHERE option_name LIKE "yarpp%"
をやる。yarpp_fulltext_disabled = 1
というのがあるはずなので,これを yarpp_fulltext_disabled = 0
に変更する。これで,タイトルと内容の検討オプションが使える。ヤレヤレ。
追記2(12/25):
「Jetpack の不具合について。」というのを書いた。
追記3(2014/6/22):
WordPressでの「SSL3_READ_BYTES:sslv3 alert handshake failure」を解決というのを書いた。
This website uses cookies.
View Comments
おはようございます。
いつのまに!!MariaDBに
内容をみると結構エラーに遭遇されたようで・・・。
お疲れ様です。mariadbで検索するとほとんどがlinuxででてきますがwindowsではかなりめずらしいですよね。
くりくりさん,おはようございます。
はい,ちょっと,やってみました(笑)。
MariaDBそのもののエラーには,ほとんど遭遇しなかったんですヨ。ストレージエンジンにしたって,無理にInooDBに変えなければすんなりだったでしょうし。そういえば-本記事にも追記しましたが-MySQLは5.5からFULLTEXTに対応したんでしたネ。
MriaDBの新my.iniは,ほぼデフォルトで使っているせいもあって,
[mysqld]
datadir=Drive_SV:\MyDB
[client]
だけです。異様にスッキリでしょ。bin\mysqld --consoleをやったときは,旧my.iniを使ったのですが,当然というかexplicit_defaults_for_timestamp=trueについてのエラーが出ました。しかし,bin\mysqld --consoleは,後で使わないファイルを結構生成するので,初めからmysql_install_db.exeで行ったほうがいいと思って,本記事では触れませんでした。
後で書こうと思っていますが,一番手を焼いたのはJetpackです。これ,いまだになんでそんなことが起こったのかわからないのですが,ルートサイトで使えなくなっちゃいまして,昨日やっと解決しましたが,参りました。