WordPress のバックアッププラグイン BackWPup のDBバックアップのログに、警告が挙がるようになったので調べてみると、 古い mysql データベースのutf8と utf8mb4 の問題に突き当たり、ひとまずプラグインを改変して済ませます。
BackWPupログに警告が
ロリポップレンタルサーバにWordPressで構成している、当ブログの定期的なデータバックアップ（サイトファイルとデータベース）は、以前導入したプラグインBackWPupが担ってくれているのですが、先日その作業ログを久しぶりに確認してみると、連日次のような警告が挙がっているのを発見（発生時のプラグインバージョンはv4.0.0）。
図1.BackWPupログの警告
データベースバックアップ開始間もなく、
|
1 |
警告: mysqli::set_charset(): Error executing query |
という警告が出るも、バックアップ自体はそのまま進行している模様。
phpMyAdminエクスポートと比較
試しにWordPress管理者サイトのプラグインページ上で、データベースのみのバックアップを手動実行してみると、やはり同じ警告が出るもジョブはそのまま完走しました。
図2.BackWPup DBジョブ手動実行
次に、Lolipopレンタルサーバのユーザ管理サイトからphpMyAdminを使って、データベースをsqlファイルにエクスポートしてみました（こちらは特に警告もなく完走）。
図3.phpMyAdmin DBエクスポート
こうして得られた2つのsqlファイルを比べてみても、ほぼ同じようなファイルサイズなことからも、BackWPupによるバックアップアーカイブに問題は無さそうです。
|
1 2 3 |
$ ls -l *.sql -rw-r--r-- 1 user user 150414955 Mar 10 14:46 BackWPup.sql -rw-rw-r-- 1 user user 149669553 Mar 10 14:00 phpMyAdmin.sql |
警告発出元を特定
とは言えこのままにしておくのも気持ちが悪いので、実際にプラグイン構成ファイルのどこで警告が発せられているか、探ってみます。
BackWPup公式GitHubにて、警告の出ていた set_charset をキーワードにレポジトリ内検索。
図4.GitHubレポジトリ内検索
使用されているファイルが判明、mysql関連のクラスが収録されたインクルードファイルでした。
図5.検索結果でファイル特定
その227行目付近にある setCharset 関数の定義を以下に抜粋します（日本語注釈はこちらで書き足したもの）。
|
227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 |
public function setCharset($charset) { ※wp-config.phpのDB_CHARSETがutf8でも、接続中のセッションがutf8mb4いけそうならそちらを使う。 if ($charset === 'utf8' && $this->getConnection()->set_charset('utf8mb4') === true) { return 'utf8mb4'; } ※wp-config.phpのDB_CHARSETで接続中ならそのまま。 if ($this->getConnection()->set_charset($charset) === true) { return $charset; } ※wp-config.phpのDB_CHARSETがutf8mb4でも、接続中のセッションがutf8ならutf8を使う。 if ($charset === 'utf8mb4' && $this->getConnection()->set_charset('utf8') === true) { return 'utf8'; } trigger_error( sprintf( __('Cannot set DB charset to %s', 'backwpup'), $charset ), E_USER_WARNING ); return false; } |
関数実行時に渡す引数には、 wp-config.php の変数 DB_CHARSET が使われているので、その値は utf8 のはず。
|
35 36 |
/** データベーステーブルのキャラクターセット (ほとんどの場合変更する必要はありません。) */ define('DB_CHARSET', 'utf8'); |
関数内の3つあるIF文の最初の条件で、接続中のセッションの charset を utf8mb4 に設定できるかの試行時に、 Error executing query を返されているのが、警告として挙がっているようです。
BackWPup導入当時には見られなかった事象なので、その後のプラグインアップデートでこのIF文が上に追加されたのでしょう。
BackWPupを改変して暫定対策
いわゆる「寿司ビール問題」を例として、不完全なUTF-8とも揶揄されるutf8から、完全体utf8mb4への移行はいずれ必要とは思いますが、稼働中の大切なブログなのでutf8のまま警告回避するよう、上述のphpファイルを次のように改変します（問題のIF文をコメントアウト）。
|
227 228 229 230 231 232 233 234 235 |
public function setCharset($charset) { # if ($charset === 'utf8' && $this->getConnection()->set_charset('utf8mb4') === true) { # return 'utf8mb4'; # } if ($this->getConnection()->set_charset($charset) === true) { return $charset; } -略- |
再びデータベースのみのバックアップを手動実行してみると、思った通り警告は無くなりました。
図6.BackWPup 警告なくジョブ完了
バックアップsqlファイルの中身やファイルサイズも問題無いので、最後にこのプラグインの自動更新を無効にしておきました。
utf8mb4化への道のりは
現在のウェブホスティング環境は大雑把に次の通り。
- mysql : v5.1.72 utf8_general_ci MyISAM
- php v7.4(CGI)
対して、utf8mb4に必要な要件は、
- mysql : v5.5〜 InnoDB
mysqlのアップグレードは実質、現行の内容をエクスポートし、新しいスキーマへインポートする手順になるのですが、ホスティングはお得なロリポップライトプランなので、利用できるスキーマは1個限り。移行の過程で現行スキーマを一旦削除しなくてはならないのはさすがに恐怖です。
一方、ストレージエンジンを古いMyISAMからInnoDBへ変換するには、次のSQL文をテーブル単位で実行するだけ。
|
1 |
ALTER TABLE [DBNAME.TABLENAME] ENGINE = InnoDB; |
テーブルロックのMyISAMに対し、行ロックのInnoDBの方がパフォーマンス向上が見込めるも、実DBファイルサイズやメモリ消費は増加すると言われています。
phpMyAdminでテーブル一覧を確認、WordPress関連のテーブルは全てMyISAMでした。
図7.WordPressテーブル全てMyISAM
テーブルを選択後、操作タブ内でもストレージエンジンをInnoDBへ変更することが可能です。
図8.phpMyAdminでのテーブル操作
問題がないかサイトの挙動を確認しながら、InnoDBへの移行を進めました。
WordPressでは、 utf8 を utf8mb4 へ一括変換する関数 maybe_convert_table_to_utf8mb4 が用意されているので、環境が充実次第、いずれ移行しようと思います。
