いつからかは定かでないが，最近， o6asan.com での自動保存ができなくなっていた。 o6asan’s soliloquy と o6asan’s soliloquy-part2 では問題なし。
それとは別に， 29 日に php_opcache.dll がらみで， Apache のエラーログを見ていたときに多量の「WordPress database error Duplicate entry ‘0’ for key ‘PRIMARY’ for query INSERT INTO `WordPress DB table name` ～」に気づいた。
昨日，ふとそのエラーのことを思い出して，対処してやろうと，エラーログをのぞきに行ったら， Notes 関係のものがたくさんあるということに気づいた。ここに至って，このエラーと自動保存の根が一緒だと気付いた。そんでもって，このエラーは 23 日に始まっていた。 MariaDB のアップデートのときに，何かまずいことをやらかしたに違いない (-_-;)。
ログに含まれているテーブル名を確認したところ， `wp_postmeta`, `wp_posts`, `wp_redirection_logs`, `wp_sitemeta` の 4 つだった。 phpMyAdmin にログインして，無問題の wp_2_postmeta と wp_postmeta の構造をじっくり見比べてみた。 wp_postmeta の meta_id に AUTO_INCREMENT がないじゃん。ほかのテーブルも， ID に AUTO_INCREMENT がない。多分，このせいだ。
何はともあれ，全データをバックアップの後，修復に取り掛かった。
コマンドラインでやるなら，下みたいになるのかな。
ALTER TABLE `WordPress のデータベース名`.`wp_postmeta` CHANGE `meta_id` `meta_id`
BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;
`wp_postmeta` と `wp_posts` については，問題無しだったが， `wp_redirection_logs` と `wp_sitemeta` では下記のエラーが出た。
#1062: ALTER TABLE causes auto_increment resequencing, resulting in duplicate entry ‘1’ for key ‘PRIMARY’
`wp_redirection_logs` は単に Redirection プラグインのログなので，空にしてやってから，上の手順を再実行。テーブルを空にするのを CUI でやるなら，こんな感じになるんかね。
TRUNCATE `WordPress のデータベース名`.`wp_redirection_logs`;
`wp_sitemeta` のほうは中のデータが絶対にいるので，ひとまず空にして，上の手順を再実行したのち，さっきバックアップした sql ファイルから `wp_sitemeta` の INSERT 文を切り出し，テーブルに再インポートした。
Apache のエラーログから，問題のエラーが消えて，親サイトの自動保存も生き返った。めでたしめでたし。
自己流の修復なので，あまりあてにしないでくださいませ m(_”_)m。
追記(9/6)：
BulletProof Security .50.8 へのアップデートのときに，どうやっても， “Network/Multisite BPS plugin Network Activation correction:” が消えないトラブルに遭遇した。で，フォーラムに相談に行ってきた。素早い対応をもらって解決したわけだが，これも AUTO_INCREMENT がらみだったようだ。どうも，2・3日前に読んだ phpMyAdmin のバグ関連の気がするのだが，真相は，藪の中。溜息。
まあ，とにかく，消えるべきものは消えた。これで，安心して眠れるワ (^_^;)。
This website uses cookies.