ブログ移転をして、サーバーのOSが新しくなっても古いものはまだある。
それはDBの構成周りの設定だ。
うちのブログは5年前から続けていて、 当時でもちょっと古い(安定している)構成になっていたので、今ではだいぶ古くなっている。
CentOS6だったし、5年前でも構成的にはもっとちょっと前の時期のバージョンをつかっていた。
それは単にバージョンアップしただけでは新しくならない。
その一つがMySQL/MariaDBのストレージエンジンだ。
ストレージエンジンというのはMySQL/MariaDBにおいて、データの取扱を司るエンジンで、更新や参照などを行っている。
データベースなので更新中に他の更新をさせないロックなど重要な処理も行われるので、データベースの特徴が現れる部分になる。
昔はMyISAMがデフォルトだったけれども、これはトランザクションに対応していないし、ロックもテーブルロックになっている。
テーブルロックとは、更新をする時テーブル全体をロックして他の人の更新をさせないようになるので、別に関係ない更新でもロック解放待ちになってしまうので、同時に更新するときには遅くなってしまう。
最近はどのDBでも行ロックに対応している。
MySQLの2010年リリースからデフォルトはInnoDBになった。
このブログは2010年以降開設だけれども、それより古いバージョンを使っていたため、MyISAMになっていた。
選択肢としてはInnoDBを選べたのだが、開設当時は特に考えなしに使っていた。
MyISAMはInnoDBに比べて堅牢性には劣るが、高速ではあったらしい。
だが今はInnoDBでも高速且つ堅牢になってきているので、もう変えたほうがいいとおもった。
あまりDBの知識はないが、デフォルトとは違う構成でバージョンが進んだときに何かしら面倒くさいことが起こるかもしれないという野生の勘も言っている。
一応補足しておくが、
CentOSでは今のトレンドよりは数年遅いバージョンが公式リポジトリに登録されている。
安定志向のためある程度バグが出きったものを選んでいるためだ。
だが、セキュリティに関してはちゃんとやっていて、古すぎて公式がパッチを出していなくても
CentOSかRHELの方でちゃんと対応して更新してくれる。
だから古くてもセキュリティ的に危険ってわけではない。
作業記録
作業時には、安全性を考えて更新や参照が入らないようにする。
つまりブログの停止をする。
ウチの環境ではnginxとphp-fpmを停止する。
なお、どんなことが起こるかわからないので、サーバーと同じ構成のCentOSをVMにインストールして検証をした。
何かやるときにはまず検証機を用意することをおすすめする。
まず状況を確認する。
ストレージエンジンはテーブル単位に設定されている。
なお後ほど例となるSQLにはコメントでSQL1やSQL2と名前をつけておいた。
#SQL1 select table_schema, table_name, engine from information_schema.tables ;
SQL1で、どのテーブルがなんのストレージエンジンが設定されているかわかる。
なお、WordPress関連以外のも含む全部のテーブルが出るが、スキーマを見てWordPressのものだけを選ぼう。
#SQL2 ALTER TABLE hogehoge_commentmeta ENGINE=InnoDB; ALTER TABLE hogehoge_comments ENGINE=InnoDB;
SQL2は例だ。
テーブル名は、SQL1で取得したものを使って、変更したいテーブル数分だけ、SQLを作る。
ALTER TABLE テーブル名 ENGINE=InnoDB;
これで終了!
もう一度SQL1を実行して、残っているテーブルがないかを確認しよう。
何もなかったら、WordPressを起動して通常運用をしよう。
ひと悶着あったパターン(僕のパターン)
ひと悶着あったパターンだけれども、
インデックスがあまりよろしくなかった。
最後にMyISAMが残っていないかを確認したときに1件だけ残っていた。
MyISAMではFULLTEXTインデックスという機能があったけれども、MySQL/MariaDB5.5のInnoDBでは未対応だった。
CentOS7 では普通に入れればMariaDB5.5が入るので、これにもろに引っかかった。
ただし、FULLTEXTインデックスを張っていたのは、WordPressではなくプラグインが行っていた。
そしてそのプラグインは現在使っていなかった。
WordPressのプラグインはアンインストールしてもDBの方はそのままにしておくので、こういうのが後々まで残ってしまうこともある。
show index from hogehoge_posts;
まずInnoDBにできなかったテーブルの、Indexを確認する。
すると以下の通りFULLTEXTインデックスが貼られているが、yarppという名前がついているインデックス名からわかったが、yarppというプラグインに関連するインデックスだ。
幸い今使っていなかったのでインデックスを消すことにした。
インデックスの消す方法は以下のようにすればよい。
alter table hogehoge_posts drop index yarpp_title; alter table hogehoge_posts drop index yarpp_content;
このSQLでインデックスを消せる。
その後再びInnoDBに設定するSQLをそのテーブル分だけ実行して無事変わればOK
なお、MariaDBが古いと何かと不便ということがわかったので、
その後最新版にアップグレードした。