SQLiteを使用したWordPressを動かして約1年半が経った。
バージョンアップは恒例のエラー対策が必要だ。
WordPress 6.7のバージョンアップ時は先人の知恵を拝借して大慌てで対策を施し難を逃れた。
6.8のバージョンアップの時は準備万端で望んだものの、何事も無く通過して肩すかしを食らったのだが、6.8.2でいきなりデータベースエラーとなった。
6.8.2はメンテナンスアップデートなので、そんな更新があるとは思っていなかった。手動でバックアップをとっておらず軽い気持ちでアップデートしてしまって大慌てしてしまったものだ。
もちろんオリジナル自動バックアップ機能で前日分も適切に取ってはあったので、気にする程の事では無いのだが、やっぱりいきなりだと焦ってしまう。
「SiteGuard WP Plugin」には、本体やプラグインに更新があると「アップデート通知」がメールで送信される機能がある。
これを利用して意図的に自動アップデートは使わずに、更新通知を受け取ってから毎回手動でアップデートをしている。動作保証外の環境なので、いつ何のアップデートでおかしくなるか分からない。
特に「SiteGuard WP Plugin」なんかは、プラグインそのもののソースに変更を加えているので、アップデート前にソースをダウンロードしてきて、自身向けの変更箇所を特定してから更新を行う必要がある。
そうしないと、想定通りに動作しない状況だ。
今回、たまたま「WordPress 6.9」へバージョンアップしたとのニュースを見つけた。
かなりの機能追加がされたとのことで、おそらく何も考えずにアップデートすると、面倒な事になるなるだろうと思われた。その後に「SiteGuard WP Plugin」から更新通知が届いた。
まずはWordPressのソースをダウンロードしてきて、version.phpを確認する。
$wp_db_version = 60717;おっと、やっぱり変わってる。これは絶対エラーになるね！
と分かったところで手動でバックアップを取った後、「WordPress 6.9」の更新実行をかけてみる。
どうせエラーになるんだろ！
としばらく待っていると、やっぱり例のエラーだ。
ここで手動でデータベースのファイルをダウンロードしてきて、
UPDATE wp_options SET option_value = '60717' WHERE option_name = 'db_version';を実行する
ついでに、ゴミデータをDELETEで一気に消して、最後に「VACUUM」を実行。
最近Cocoonのアクセスログ機能の利用を始めたからだろうか。ちょっと前まで3MB位だったのに8MBのデータベースファイルになっている。
「VACUUM」を実行すると一気に4MBまで圧縮された。なんと半分がゴミだ。。。
もしかしたら多少はレスポンスが良くなったかも知れない。
データベースファイルの上書きアップロードを終えて、ブラウザーの更新をかけると「データベースは最新です」のメッセージ。無事更新が終わった。
この間30秒くらいの作業時間だろうか。手慣れた物だ。
実のところ多少時間がかかっても、閲覧者にはいつも通りに表示されるので全く問題は無い。管理画面が死んでいるだけである。
データベースファイルを直接上書きするため、ダウンロード後から作業中のCocoonアクセスログは消失してしまうから、なるべく短時間の方が良いのだ。
この辺のスクリプトを組んで、サーバー側で更新アップデートをすることも可能なのだけど、いかんせん保証外の動作環境なので、他の原因で障害が発生するとどうしようもない。余計なことをしない方が安全だ。
ということで、今のところテストしながら手動でアップデートし続けている。
面倒な事には変わらないのだが実は結構楽しい。というか、記事を書くよりこちらが主目的だったりする。いつ来るか分からないトラブルに対して、いかに早く復旧できるかの実戦訓練なのだ。
コメント