• WordPress 4.2のutf8mb4移行ではMySQLサーバーとクライアントのバージョンを確認する

WordPress 4.2のutf8mb4移行ではMySQLサーバーとクライアントのバージョンを確認する

公開日: 執筆:佐藤

WordPress 4.2へ更新しただけで、すべてのデータベースがutf8mb4へ移行するわけではありません。現在の文字set、MySQLサーバーのバージョン、PHPから接続するクライアントライブラリのバージョンを分けて確認してください。

WordPress本体のテーブルと、pluginが作った独自テーブルも分けます。本体の更新が完了しても、独自テーブルの長いindexまで問題なく変換できるとは限りません。

utf8mb4へ移行する三つの条件を確認する

WordPress Coreのutf8mb4移行に関する説明では、WordPress 4.2がテーブルを移行する条件を三つに分けています。

条件 確認する内容
現在の文字set utf8を使っているか
MySQLサーバー 5.5.3以上か。MariaDBは10.xを含む
クライアントライブラリ MySQL client librariesは5.5.3以上か。mysqlndは5.0.9以上か

サーバーのバージョンとクライアントライブラリのバージョンは別です。hosting会社から「MySQL 5.5.3以上」と回答を得ても、PHPが使うライブラリまで条件を満たすとは限りません。管理画面、phpinfo、hosting会社への問い合わせなど、管理範囲に合う方法で両方を確認します。

更新作業を外部へ依頼する場合は、「WordPress 4.2へ更新する」だけを完了条件にしません。更新前と更新後のテーブルの文字setを記録し、utf8mb4へ移行したかを報告範囲へ含めてください。

utf8とutf8mb4では一文字に使えるbyte数が違う

WordPressの説明では、utf8は三byteの文字まで、utf8mb4は四byteの文字まで保存できます。WordPress 4.2のrelease案内でも、四byte文字を含む文字範囲へ対応するため、database encodingがutf8からutf8mb4へ変わったと説明されています。

utf8mb4はutf8と後方互換です。ただし、保存できる文字が増えることと、既存のテーブルを無条件に変換できることは別です。indexにはbyte数の上限があるためです。

WordPressの開発資料が前提にする標準設定では、indexの上限は767 byteです。utf8なら一文字三byteなので255文字を扱えますが、utf8mb4では一文字四byteとなり、191文字に収める必要があります。WordPress本体は、meta_key、slug、name、post_nameなど、該当するindexを調整します。

この191文字という値を、すべてのcolumnへ一律に適用してはいけません。問題になるのは、文字列の長さ、indexへ含める範囲、databaseの設定を組み合わせた結果です。

独自テーブルはindexを先に調べる

pluginや独自機能が作ったテーブルは、WordPress本体のindex調整と同じ扱いになるとは限りません。次の順で確認します。

  1. WordPress本体以外のテーブルを一覧にする
  2. 文字列型のcolumnと、そのcolumnを含むindexを調べる
  3. utf8mb4へ変換した場合のbyte数が上限に収まるか確認する
  4. test環境で変換し、errorだけでなく実際のindex定義を確認する
  5. 読み書きするpluginまたは独自codeの動作を確認する

MySQLは、indexが大きすぎても常に分かりやすいerrorを出すとは限らないため、WordPressは自動testの結果だけに頼らず、各indexの大きさを手作業でも確認するよう案内しています。

独自テーブルを変換するために、WordPress 4.2にはmaybe_convert_table_to_utf8mb4( $tablename )が用意されています。この関数はwp-admin/includes/upgrade.phpにあり、テーブル全体がutf8であることを確認してから変換します。ただし、関数があることは、独自テーブルのindex設計が適切であることを保証しません。indexを確認してから使います。

更新前後の記録を残して復旧できるようにする

database encodingの変更は、記事を一件編集する作業とは影響範囲が違います。更新前にdatabaseをbackupし、復元できる手順と担当者を決めてください。pluginやthemeも同時に更新するなら、何が原因か分からなくならないよう、変更単位と確認結果を記録します。

確認表には、少なくとも次を残します。

段階 記録する内容
更新前 WordPress、MySQLサーバー、クライアントライブラリの各バージョン
backup database fileの保存先、取得時刻、復元担当者
更新後 本体テーブルと独自テーブルの文字set
index 変更されたindexと独自テーブルの確認結果
動作確認 投稿、検索、管理画面、plugin固有の読み書き
復旧条件 error、欠損、文字化けが出た場合の戻し方

WordPress 4.2では、utf8mb4へのupgradeは一度だけ試されます。条件を満たさない状態で更新し、あとからMySQLを更新した場合は、自動で再試行されたと決めつけず、テーブルの状態を調べてください。

最初の一手は、WordPressのバージョンだけでなく、MySQLサーバーとクライアントライブラリのバージョンを別々の欄へ書くことです。どちらかを確認できなければ、更新作業の前にhosting会社またはserver管理者へ確認します。

戻る