Burst Statisticsのアップグレードが3.69%で止まる原因と直し方
Burst Statisticsのデータベースアップグレードが3.69%で停止し、SQLエラーが何度も記録される場合、wp_optionsテーブルに残ったアップグレード実行フラグを削除すると移行処理がリセットされ、症状が収まる。
アップグレードが3.69%で止まりSQLエラーが続く原因
Burst Statisticsはアクセス解析プラグインだ。バックグラウンドでデータベースの移行処理を実行する際、進捗状況をwp_optionsテーブルのオプションとして記録する。このフラグが何らかの理由で削除されずに残ると、管理画面には「バックグラウンドでアップグレードが実行中です。現在の進捗は3.69%です」という趣旨の通知が表示され続ける。
照合順序の不一致が比較処理を止める
最初に起こりやすいのが照合順序（コレーション）の不一致だ。データベースのテーブルやカラムごとに文字の並び順と比較規則を定める設定があり、MySQLではutf8mb4_unicode_ciとutf8mb4_unicode_520_ciのように複数の種類が存在する。
統計テーブルのplatformカラムとプラットフォームテーブルのnameカラムを比較しようとしたとき、双方の照合順序が異なると「照合順序の混在により演算が実行できない」というSQLエラーが発生する。比較処理はそこで停止し、移行処理全体が失敗に終わる。
存在しないカラムを参照してエラーが繰り返される
移行処理が途中まで進行した状態で中断すると、データベースのスキーマと実行中のクエリが噛み合わなくなる。アップグレード処理が統計テーブルのreferrerカラムを参照しようとしても、そのカラムは既に削除済みか存在しないため、「Unknown column」というエラーがphpエラーログに数百件単位で蓄積する。
さらにホスティング移行などのタイミングでデータベースの取り込みが不完全だった場合、page_idカラムが欠落するなど別の不整合も発生しやすい。結果として複数のSQLエラーが同時期に記録される。
アップグレードフラグが残留して移行を再実行し続ける
移行処理が失敗すると、本来なら終了時に削除されるはずのフラグ（burst_db_upgrade_move_referrers_to_sessions）がwp_optionsテーブルに残る。プラグインはアクセスのたびにこのフラグの存在を確認し、未完了と判断して移行を再実行しようとする。ところが移行は既に実行済みで、カラム構成が変わってしまった状態のため、何度実行しても同じSQLエラーで失敗する。
これが数ヶ月にわたって進捗が3.69%のまま停止しているように見える仕組みだ。フラグを削除して「移行は完了済み」と認識させれば、再実行ループは止まる。
アップグレードフラグを削除して移行をリセットする手順
症状を解消するには、残留したフラグをwp_optionsテーブルから削除する。SQLを直接実行する方法と、PHPのスニペットで削除する方法の2つがある。まず全体の流れを確認しよう。
この手順では取り除くのはフラグだけであり、アクセスログや統計データが保存されたテーブルには手を加えない。
phpMyAdminでSQLを実行して削除する
レンタルサーバーの管理画面からphpMyAdminを開き、対象サイトのデータベースを選択する。SQLタブに以下のクエリを入力して実行する。
DELETE FROM wp_options WHERE option_name = 'burst_db_upgrade_move_referrers_to_sessions';WordPressのデータベースプレフィックスがwp_以外の場合（例えばwp_ab12_など）は、wp_optionsの箇所を実際のプレフィックスに置き換える。プレフィックスはwp-config.phpの「$table_prefix」で確認できる。
実行後に「1行が削除されました」のような結果が表示されれば成功だ。該当行が存在しない場合は既に削除済みか、プレフィックスが異なる可能性がある。
PHPスニペットで削除する方法
phpMyAdminにアクセスできない場合や、コードから安全に削除したい場合は、以下のPHPスニペットを子テーマのfunctions.phpに一時的に追加する方法がある。
add_action( 'admin_init', function () {
delete_option( 'burst_db_upgrade_move_referrers_to_sessions' );
} );このコードを追加したら、WordPress管理画面を一度開く。admin_initフックが実行され、フラグが削除される。削除を確認したら、このコードは必ずfunctions.phpから取り除く。残しておくと管理画面を開くたびに削除処理が走り続けるためだ。
functions.phpを直接編集せずに済ませたい場合は、Code Snippetsなどのコード管理プラグインを使って同じコードを一時的に実行する手もある。
削除後に確認すること
- Burst Statisticsのダッシュボードから進捗表示が消えたか
- phpエラーログに新しいSQLエラーが記録されていないか
- 統計グラフや概要データが正常に表示されるか
- プラグインを無効化せずに済むか
進捗表示が消えて統計も正常に表示されれば、この問題は解決している。もし通知が残る場合は、キャッシュ系プラグインの一時停止やブラウザキャッシュの削除も試すとよい。
照合順序の不一致を確認して統一する
フラグを削除しても照合順序の混在エラーが再発する場合は、テーブル間の照合順序を統一する必要がある。特にBurst Statisticsが作成したテーブルと、WordPress標準テーブルの間で照合順序が異なる場合に比較演算が失敗しやすい。
各テーブルの照合順序を調べる
phpMyAdminで該当データベースを開き、Burst Statistics関連のテーブルを選択して「構造」タブを確認する。各カラムの「照合順序」列にutf8mb4_unicode_ciやutf8mb4_unicode_520_ciなどの値が表示される。統計テーブルとプラットフォームテーブルで値が異なると、比較演算でエラーが発生する。
WordPressの標準データベースは、多くの環境でutf8mb4_unicode_ciが使われている。新旧のMySQLバージョンが混在するサーバー移行を経ると、utf8mb4_unicode_520_ciのテーブルが混ざることがある。
照合順序を統一するSQL
照合順序を統一するには、ALTER TABLEでテーブル全体を変換する。以下は統計テーブルをutf8mb4_unicode_ciに揃える例だ。
ALTER TABLE wp_burst_statistics CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;実際のテーブル名やプレフィックスは環境によって異なるため、phpMyAdminでBurst Statistics関連のテーブル名を確認してから実行する。1つずつ確認し、不一致があるテーブルだけを変換すると安全だ。
照合順序の変換は既存データの文字情報を保持したまま実行されるが、作業前に必ずデータベース全体のバックアップを取る。変換後は統計画面とサイトの表示を確認する。
統計データを保ったままプラグインを復旧する
フラグの削除や照合順序の統一で解決しない場合、プラグインの再インストールを検討する。ただし、Burst Statisticsが記録したアクセスログを消さないように、データ保持の設定を確認してから進める。
アンインストール時にデータを残す設定
プラグインの設定画面に「データ保持」や「アンインストール時にデータを削除する」という趣旨の項目がある場合、そのチェックがオフになっていることを確認する。オフのままアンインストールすると、データベーステーブルが残り、再インストール後に統計が復元される。
この設定が見当たらない場合は、作業前にphpMyAdminからデータベース全体をエクスポートして手元に保存しておく。これだけで再インストールの失敗リスクを大幅に下げられる。
プラグインを無効化して再インストールする
WordPress管理画面の「プラグイン」からBurst Statisticsを無効化する。その後、プラグイン一覧から削除し、「新規プラグインを追加」から最新版をインストールして有効化する。データテーブルが残っていれば、統計は引き継がれる。
再インストール後は、ダッシュボードの進捗表示が消えていることと、統計データが正常に表示されることを確認する。もしエラーログに新しいSQLエラーが記録される場合は、照合順序の不一致を再度確認する。
よくある質問
アップグレードフラグを削除すると統計データは消えるのか
消えない。wp_optionsテーブルのフラグは移行処理の進捗管理専用であり、アクセスログや集計データは別のテーブルに保存されている。フラグの削除は「移行処理が完了済み」とプラグインに知らせるだけだ。
phpMyAdminが使えない場合はどうするのか
PHPスニペットを子テーマのfunctions.phpに追加して削除できる。Code Snippetsなどのプラグインを使えば、functions.phpを直接編集せずに同じ処理を実行できる。いずれも削除確認後にコードを取り除くこと。
SQLを実行しても進捗表示が消えない場合は
まずデータベースプレフィックスが正しいか確認する。wp_以外のプレフィックスを使っている場合、SQL文のwp_optionsの箇所を置き換える必要がある。また、ページキャッシュやオブジェクトキャッシュが有効だと管理画面の表示が古いままになるため、キャッシュのクリアも試す。
照合順序の統一をしないとどうなるのか
フラグ削除後も再びSQLエラーが発生し、統計の集計が正しく動作しない可能性がある。特にサーバー移行を経た環境では、テーブルごとに照合順序がばらつきやすい。不一致を解消しておくと、今後のプラグインアップデートにも強くなる。
プラグインを削除して再インストールしても問題ないのか
データ保持の設定が正しければ問題ない。ただし、フラグ削除という軽量な対処で解決できるケースが多いため、再インストールは最後の手段として考えるのが安全だ。どうしても再インストールする場合は、作業前に必ずデータベースをバックアップする。
この記事のポイント
- アップグレードの進捗が3.69%で止まる原因は、wp_optionsに残った実行フラグ
- burst_db_upgrade_move_referrers_to_sessionsを削除すると再実行ループが止まる
- SQLとPHPスニペットの2通りの削除方法がある
- 照合順序の不一致もSQLエラーの引き金になるため確認する
- 再インストール前には必ずデータベースのバックアップを取る
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている