WordPress のバックアッププラグイン BackWPup のDBバックアップのログに、警告が挙がるようになったので調べてみると、 古い mysql データベースのutf8と utf8mb4 の問題に突き当たり、ひとまずプラグインを改変して済ませます。
BackWPupログに警告が
ロリポップレンタルサーバにWordPressで構成している、当ブログの定期的なデータバックアップ(サイトファイルとデータベース)は、以前導入したプラグインBackWPupが担ってくれているのですが、先日その作業ログを久しぶりに確認してみると、連日次のような警告が挙がっているのを発見(発生時のプラグインバージョンはv4.0.0)。
データベースバックアップ開始間もなく、
1 |
警告: mysqli::set_charset(): Error executing query |
という警告が出るも、バックアップ自体はそのまま進行している模様。
phpMyAdminエクスポートと比較
試しにWordPress管理者サイトのプラグインページ上で、データベースのみのバックアップを手動実行してみると、やはり同じ警告が出るもジョブはそのまま完走しました。
次に、Lolipopレンタルサーバのユーザ管理サイトからphpMyAdminを使って、データベースをsqlファイルにエクスポートしてみました(こちらは特に警告もなく完走)。
こうして得られた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 をキーワードにレポジトリ内検索。
使用されているファイルが判明、mysql関連のクラスが収録されたインクルードファイルでした。
その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; } -略- |
再びデータベースのみのバックアップを手動実行してみると、思った通り警告は無くなりました。
バックアップ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でした。
テーブルを選択後、操作タブ内でもストレージエンジンをInnoDBへ変更することが可能です。
問題がないかサイトの挙動を確認しながら、InnoDBへの移行を進めました。
WordPressでは、 utf8 を utf8mb4 へ一括変換する関数 maybe_convert_table_to_utf8mb4 が用意されているので、環境が充実次第、いずれ移行しようと思います。