いまさらの phpMyAdmin インポートエラーの対処の備忘録 | WordPressのカスタマイズ

WordPress が 6.0 になったら、プラグイン Google XML Sitemap でエラーがでるようになってしまった。ほどなく、アップデートされて エラーは出なくなったが、オールクリアとなったわけではなくいまだ Notice が出ている。

プラグインに頼っていると、こういうエラーで使えなくなるのが、なんとももどかしいのである。であるからにして、これも自作してしまおうかなどと、ローカルにデータベースのクローンなどを用意しようと始めたのではあるけれど・・・。

phpMyAdmin の インポートにおける incorrect format parameter という error

ということで、いきなりエラーが出てつまづいてしまったのである。
ただこのエラー、incorrect format parameter というのは、この文字列をみると SQL におけるエラーかと、ややこしそうな感じがするけれど実は単純なことで、ネットをちょっと探ってみればすぐに解決できることである。なんてことはなく、読み込むファイルサイズが大きくて、php.ini の設定を超えてしまうから出るということである。
であるからにして、その php.ini の次の２つの値を少し大きなものに変更してやればこのエラーは出なくなる。もともとの値は、2M と 8M だったと思う。ファイルサイズからして 16M でもよさそうだったが、32M でやってみた。
post_max_size = 32M
upload_max_filesize = 32M

スクリプトがタイムアウトにて中断

いざ、インポート処理が始まってはみたものの、表示される内容に全く動きはなく、それでもハードディスクのアクセスランプは時折チカチカとして動いているようなので、しばらく様子をみる。
そして、やっとというか表示が変わってみると、赤い帯があって少しいやな雰囲気を感じることとなる。

「スクリプトがタイムアウトしました。インポートを完了させたいのであれば同じファイルを再送信すればインポートが再開されます。」
と、教えてくれているし、「同じファイルを再送信」の部分がリンクになっているのでそれをクリックすると、インポートの最初のページへと戻してくれるので、再び、ファイルを指定して始めさせる。

が、再び待つことしばし、次に表示された画面も、ほぼ赤い部分が占めていて、大量の文字でうめられている。
何かエラーがあってこの先には進めない！
と、いうようなことが表示されていたと思う。（プリントスクリーンしたつもりが、できていなかったので正確に何と表示されていたのかは定かではなし。）

これはどうも、中断させてしまうと再開させてもだめなようである。
ならば、タイムアウトさせない方法はと？これもネットをちょっと探ってみれば、先人たちが教えてくださっているので、その方法はすぐにわかる。今度は、phpMyAdmin の方の設定を変更するということ。

ファイル -> phpMyAdmin/libraries/config.default.php
$cfg[‘ExecTimeLimit’] = 0;

この、デフォルトで 300 になっていた ExecTimeLimit の値を、0 に変更する。( 0 for no limit ) と書いてある通り、0 を指定すると制限なしになるということである。

そして、再チャレンジ。
随分と待たされる。長いなぁ！と思って時計を見てから16分かかってやっと終了した。長いなぁ、と思ってからの16分だから、優に20分以上はかかったのだと思う。ちなみに、この時に使った インポートファイルは zip で圧縮されたファイルで、そのサイズは 10.9MB だった。そして我が PC は Windows11 からは見放された、Core I5 の老 Windows10 マシーンである。まぁ、何はともあれ、これでエラーもなく、問題なくインポートされていた。

と、いうことで、php.ini やら phpMyAdmin の config.default.php の変更した設定をもとに戻して、めでたしめでたしである。
と、いいつつ、実はというとなんだけれど、もっと速く処理できる方法もある。まぁ、ちょっとだけ、手間は余計にかかるけれど。
それは、サイズの大きいテーブルはそれぞれ個別に圧縮せずにエクスポートし、それ以外の小さいものはまとめて圧縮せずにエクスポートして、それぞれ別々にインポートさせるというやり方である。

大きいテーブルを個別にインポート

ちなみに、我が WordPress サイトの各テーブルの状況は以下のようになっている。画像サイトなので、相当な数の画像をアップロードしていることにより、wp_posts テーブルよりも wp_postmeta テーブルのほうが巨大になっていて、これが最大であり、タイムアウトして中断していたのも wp_postmeta テーブルなのであった。

Server : PHP 8.0.8 : phpMyAdmin 4.0.10.18
localhost : PHP 8.0.8 : phpMyAdmin 5.1.1

wp_cbnetpo_ping_optimizer	3.1 MiB
wp_commnetmeta	13.5 KiB
wp_comments	20 KiB
wp_links	3.6 KiB
wp_options	859.8 KiB
wp_postmeta	121.3 MiB
wp_posts	51.3 MiB
wp_termmeta	4 KiB
wp_terms	68.6 KiB
wp_term_relationships	1.3 MiB
wp_term_taxonomy	55.5 KiB
wp_usermeta	14.7 KiB
wp_users	7.1 KiB

と、いうことで、wp_posts テーブルと wp_postmeta テーブルはそれぞれ個別にエクスポートさせ、残りはまとめてということにした。はじめは全て圧縮せずにと思っていたのだけれど、結局、思うところあって wp_postmeta だけを非圧縮ということでやった。エクスポートしたファイルのサイズはそれぞれ以下のごとし。

postmeta.sql	108,309 KB
posts.sql.zip	5,758 KB
others.sql.zip	390 KB

postmeta テーブルのファイルサイズが 108 MB もあるので、php.ini の post_max_size と upload_max_filesize の設定値は 128M にして、このときは phpMyAdmin の ExecTimeLimit の設定値はデフォルトの 300 のまま変更せずに実行させた。
まずは、postmeta テーブルからインポートさせたが、中断することもなく無事に処理された。と、いうことで後の2つも問題なく済み、phpMyAdmin の ExecTimeLimit がデフォルト値のままで中断することなく終わったということからも分かる通り、まとめてやったときの半分の時間もかからなかったと思う。

まぁ、実のところ、自的にはこの方法を先にやっていたのであるけれど、時間制限がなければまとめてできるのだろうかと、ちょっと興味があったので後からもう一度試してみたということなのである。自分のデータベースで得た結果が、全ての場合において有効であるとは全く言えないのではあるけれど、サイズ的な状況など近いものがあれば、ちょっと手間をかけてみるのも、時間の節約にはなるのかもしれない。