WordPressプラグインBackWPupとmysql5.1のutf8mb4非対応問題

公開 | 更新 

WordPress のバックアッププラグイン BackWPup のDBバックアップのログに、警告が挙がるようになったので調べてみると、  古い mysql データベースのutf8と utf8mb4 の問題に突き当たり、ひとまずプラグインを改変して済ませます。

BackWPupログに警告が

ロリポップレンタルサーバWordPressで構成している、当ブログの定期的なデータバックアップ(サイトファイルとデータベース)は、以前導入したプラグインBackWPupが担ってくれているのですが、先日その作業ログを久しぶりに確認してみると、連日次のような警告が挙がっているのを発見(発生時のプラグインバージョンはv4.0.0)。

図1.BackWPupログの警告

図1.BackWPupログの警告

データベースバックアップ開始間もなく、

という警告が出るも、バックアップ自体はそのまま進行している模様。

 

phpMyAdminエクスポートと比較

試しにWordPress管理者サイトのプラグインページ上で、データベースのみのバックアップを手動実行してみると、やはり同じ警告が出るもジョブはそのまま完走しました。

図2.BackWPup DBジョブ手動実行

図2.BackWPup DBジョブ手動実行

次に、Lolipopレンタルサーバのユーザ管理サイトからphpMyAdminを使って、データベースをsqlファイルにエクスポートしてみました(こちらは特に警告もなく完走)。

図3.phpMyAdmin DBエクスポート

図3.phpMyAdmin DBエクスポート

こうして得られた2つのsqlファイルを比べてみても、ほぼ同じようなファイルサイズなことからも、BackWPupによるバックアップアーカイブに問題は無さそうです。

 

警告発出元を特定

とは言えこのままにしておくのも気持ちが悪いので、実際にプラグイン構成ファイルのどこで警告が発せられているか、探ってみます。

BackWPup公式GitHubにて、警告の出ていた set_charset をキーワードにレポジトリ内検索。

図4.GitHubレポジトリ内検索

図4.GitHubレポジトリ内検索

使用されているファイルが判明、mysql関連のクラスが収録されたインクルードファイルでした。

図5.検索結果でファイル特定

図5.検索結果でファイル特定

その227行目付近にある setCharset 関数の定義を以下に抜粋します(日本語注釈はこちらで書き足したもの)。

関数実行時に渡す引数には、 wp-config.php の変数 DB_CHARSET が使われているので、その値は utf8 のはず。

関数内の3つあるIF文の最初の条件で、接続中のセッションの charsetutf8mb4 に設定できるかの試行時に、 Error executing query を返されているのが、警告として挙がっているようです。

BackWPup導入当時には見られなかった事象なので、その後のプラグインアップデートでこのIF文が上に追加されたのでしょう。

 

BackWPupを改変して暫定対策

いわゆる「寿司ビール問題」を例として、不完全なUTF-8とも揶揄されるutf8から、完全体utf8mb4への移行はいずれ必要とは思いますが、稼働中の大切なブログなのでutf8のまま警告回避するよう、上述のphpファイルを次のように改変します(問題のIF文をコメントアウト)。

再びデータベースのみのバックアップを手動実行してみると、思った通り警告は無くなりました。

図6.BackWPup 警告なくジョブ完了

図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文をテーブル単位で実行するだけ。

テーブルロックのMyISAMに対し、行ロックのInnoDBの方がパフォーマンス向上が見込めるも、実DBファイルサイズやメモリ消費は増加すると言われています。

phpMyAdminでテーブル一覧を確認、WordPress関連のテーブルは全てMyISAMでした。

図7.WordPressテーブル全てMyISAM

図7.WordPressテーブル全てMyISAM

テーブルを選択後、操作タブ内でもストレージエンジンをInnoDBへ変更することが可能です。

図8.phpMyAdminでのテーブル操作

図8.phpMyAdminでのテーブル操作

問題がないかサイトの挙動を確認しながら、InnoDBへの移行を進めました。

 

WordPressでは、 utf8 を utf8mb4 へ一括変換する関数 maybe_convert_table_to_utf8mb4 が用意されているので、環境が充実次第、いずれ移行しようと思います。

 

created by Rinker
¥3,278 (2024/04/17 02:03:19時点 Amazon調べ-詳細)

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA