TL;DR:
max_allowed_packetを恒久的に増やすには、my.cnfの[mysqld]セクションにmax_allowed_packet=1Gを追加し、MySQL を再起動してください。再起動なしですぐに修正したい場合は、MySQL クライアントでSET GLOBAL max_allowed_packet=1073741824;を実行します。変更内容はSHOW VARIABLES LIKE 'max_allowed_packet';で確認できます。
Contents

MySQL が max_allowed_packet の値よりも大きいデータパケットを含むクエリを受信すると、「Packet too large」エラーをスローして接続を切断します。これは WordPress 環境でよく見られる MySQL エラーで、WP STAGING の Push、大規模なデータベースインポート、サイト移行などのときに発生します。デフォルト値は大規模な WordPress サイトが必要とする値に対して低めに設定されていますが、お使いのホスティング環境に合った方法さえ見つかれば、増やすのは簡単です。
たとえば、パケットサイズが小さすぎて WP STAGING の Backup 復元が失敗する場合、エラーメッセージに問題となったクエリのサイズが表示されるので、それに応じて max_allowed_packet を調整できます。WP STAGING の現行バージョンでは、Plugin がサーバーの最大許容パケットサイズに基づいてデータベースクエリを動的に制御・実行しますが、直接インポートやサードパーティツールには依然として MySQL 自体の制限が適用されます。
MySQL の max_allowed_packet サイズを変更するには 2 つの方法があります。MySQL 設定ファイルでの恒久的な変更と、SQL による一時的な変更です。どちらも以下で説明します。
max_allowed_packet が制御するもの
max_allowed_packet システム変数は、MySQL クライアントとサーバー間の単一通信パケットの最大サイズを設定します。クエリ・結果行・ストアドルーチンの定義がこの上限を超えると、MySQL は接続を終了し、エラーをログに記録します。
よく見られる症状のパターン:
- 「Packet too large」: MySQL がクエリを即座に拒否します。
- 「MySQL server has gone away」: 長時間のインポート中に接続が切断されます。
- サイトに大きな投稿リビジョン・シリアライズされたオプション値・post meta に保存された画像メタデータが含まれる場合の、WP STAGING での Push または復元の失敗。
mysqldumpによる復元中や phpMyAdmin インポート中のエラー。
当社のサポートキューでよくある原因は、post meta として保存された大きな画像ライブラリや投稿リビジョンを含む WP STAGING の Push です。新しいホストへの移行を妨げることもあります。移行の前に上限を把握しておけば、移行の途中でインポートが失敗するのを防げます。
どの方法を使うべきか
| 環境 | 最適な方法 |
|---|---|
| SSH アクセス可能な VPS または専用サーバー | my.cnf を編集 (恒久的) |
| 共有ホスティング (SSH なし) | ホスティング業者に連絡してください。phpMyAdmin で現在値の確認はできますが、恒久的な変更はできません |
| AWS RDS for MySQL | AWS コンソールで DB パラメータグループを変更 |
| DigitalOcean Managed MySQL | コントロールパネルの「Configuration」タブから設定 |
| 再起動なしですぐに修正したい場合 | SET GLOBAL SQL コマンド (一時的で、再起動でリセットされます) |
MySQL がどの設定ファイルを読み込んでいるか不明な場合は、ターミナルで mysql --verbose --help | grep my.cnf を実行すると、検索順序の全体を確認できます。
max_allowed_packet を恒久的に設定する方法
恒久的な変更は MySQL サーバーの再起動後も維持されます。方法はお使いのホスティング環境によって異なります。
変更を加える前に、現在の値を確認して出発点を把握しておきましょう。SSH アクセスのあるサーバーでは、MySQL クライアントで SHOW VARIABLES LIKE 'max_allowed_packet'; を実行します。共有ホスティングでは、phpMyAdmin から Variables を開き、max_allowed_packet を検索します。新しい値は、想定される最大パケットより十分に大きく設定してください。復元やインポートが失敗すると、エラーメッセージに問題となったクエリのサイズが表示されるので、その数値を下限の目安にします。
VPS または専用サーバー: my.cnf を編集する
1. MySQL 設定ファイルを開きます。 MySQL サーバーのインストールディレクトリにある my.ini (Windows) または my.cnf (Linux または macOS) を開きます。ほとんどの Linux システムでは、このファイルは /etc/mysql/my.cnf または /etc/my.cnf にあります。MySQL がどのファイルを読み込むか不明な場合は、まず mysql --verbose --help | grep my.cnf で正確なパスを確認してください。
2. [mysqld] セクションを見つけます。 このディレクティブは 必ず [mysqld] の下に書く必要があり、[mysql] や [client] ではいけません。間違ったセクションに書いてしまうのが、修正したように見えても効果が出ない最もよくある原因です。
3. 値を設定します。 [mysqld] の下で max_allowed_packet 行を探すか追加します。値を 1 GB に設定するには:
[mysqld]
max_allowed_packet=1G
4. ファイルを保存し、MySQL を再起動します。
sudo systemctl restart mysql
5. 新しい値を確認します。
SHOW VARIABLES LIKE 'max_allowed_packet';
共有ホスティング: phpMyAdmin で確認する
SSH アクセスのない共有ホスティングでは、phpMyAdmin から Variables に移動して max_allowed_packet を検索することで、現在の値を確認できます。恒久的に増やすには、ホスティング業者に連絡してください。これは共有コントロールパネル外の管理者アクセスを必要とする、サーバーレベルの設定です。
マネージドデータベース: AWS RDS と DigitalOcean
クラウドのマネージド MySQL サービスでは、設定ファイルではなくコントロールパネルから変数を変更します:
- AWS RDS for MySQL: AWS コンソールで DB インスタンスを開き、関連付けられたパラメータグループに移動して
max_allowed_packetを設定します。変更を有効にするには、更新したパラメータグループを適用してインスタンスを再起動してください。 - DigitalOcean Managed MySQL: データベースクラスタの Configuration タブに移動して、
max_allowed_packetをそこで更新します。
どちらのプラットフォームでも、大規模な新しいホストへの移行の前に値を設定し、途中でインポートが失敗しないようにしてください。
max_allowed_packet を一時的に設定する方法
max_allowed_packet 変数は、単一の SQL コマンドでグローバルに設定できます。これは再起動なしで即座に有効になりますが、MySQL サーバーが再起動するとリセットされます。変更を永続化したい場合は、必ず my.cnf での恒久的な編集も行ってください。
サーバー再起動までの間、全員の max_allowed_packet を 1 GB に変更するには:
SET GLOBAL max_allowed_packet=1073741824;
すぐに確認します:
SHOW VARIABLES LIKE 'max_allowed_packet';
この方法は、今まさに失敗している復元やインポートを解除したり、設定ファイルに反映する前に適切な値をテストしたりするのに便利です。
修正が反映されない場合の対処
変更後に SHOW VARIABLES LIKE 'max_allowed_packet'; が依然として古い値を返す場合は、次のチェックリストを順に確認してください:
1. 設定セクションが間違っている。 このディレクティブは [mysqld] の下に書く必要があります。ファイルを開いて、max_allowed_packet 行のすぐ上にあるセクションヘッダーを確認してください。
2. 設定ファイルが間違っている。 MySQL は複数のファイルを特定の順序で読み込み、最後に一致した値が優先されます。実際の検索パスを確認してください:
mysql --verbose --help | grep my.cnf
3. MySQL が再起動されていない。 サービスが正常に再起動されたか確認してください:
sudo systemctl status mysql
4. ファイルが保存されていない、または読み取り不可。 ファイルが保存されていること、MySQL に読み取り権限があることを確認してください。
5. レプリカノード。 レプリケーション環境では、SET GLOBAL は接続したノードにのみ適用されます。各レプリカで個別に設定ファイルの更新が必要です。
6. クライアント側の制限。 一部のデータベースクライアントは接続時に max_allowed_packet を設定します。クライアント値がサーバー値より低い場合、サーバー設定にかかわらずクライアントの制限が適用されます。
新しくプロビジョニングされた my.cnf に [mysql] エントリだけがあって [mysqld] セクションヘッダーが欠落していた場合に、修正が静かに失敗するのを目にしたことがあります。MySQL はエラーなくファイルを解析しますが、ディレクティブは無視されます。
サーバーのメモリ制限エラーは、同じログファイル内で MySQL のパケットエラーと同時に現れることがあります。その修正については PHP の memory_limit 超過エラーを参照してください。同じ設定セクションの原則が当てはまります。PHP の max_input_vars 制限についても、サーバー設定ファイルを編集する同じ方法で解決できます。