WordPress と DROPBOXの連携 WordPress Backup to Dropbox エラーを回避する
かれこれ1年以上も前からDROPBOXでwordpressのデータをバックアップしています。
なかなか使いやすくクラウド上なので特に意識することなく楽にバックアップが取れるのでお勧めです。
Dropboxとは
Dropbox(ドロップボックス)は、人気のオンラインストレージサービスです。インターネット上のオンラインストレージとローカルにある複数のPCとの間でデータの共有や同期を可能とするサービスです。無料版のアカウントでも2GBの容量を利用可能です。
下記のリンクから登録(PCへインストール)すると無料で500Mバイト増量され合計2.5Gバイトになります(^^;
公式サイト→ DROPBOX
ということで何気にサーバログを見てみると下記のようなエラーをerror.logに見つけました。
[Mon Jun 06 01:12:03 2016] [error] [client 49.212.XXX.XX] WordPress \xe3\x83\x87\xe3\x83 \xbc\xe3\x82\xbf\xe3\x83\x99\xe3\x83\xbc\xe3\x82\xb9\xe3\x82\xa8\xe3\x83\xa9\xe3\x83\xbc: Column 'offset' cannot be null for query INSERT INTO `wp_wpb2d_processed_files` (`file`, `uploadid`, `offset`) VALUES ('/var/www/wordpress/wp-content/backup-6baaa/index.php', NULL, NULL) made by do_action_ref_array, call_user_func_array, run_dropbox_backup, WPB2D_BackupController->execute, WPB2D_BackupController->backup_path, WPB2D_Processed_Files->add_files, WPB2D_Processed_Base->upsert
どうやらDROPBOXと連携してバックアップを取っている 「WordPress Backup to Dropbox」というプラグインのようです。
-rw-r--r-- 1 root root 32219 3月 27 02:45 2016 error_log-20160327 -rw-r--r-- 1 root root 20444 4月 3 02:51 2016 error_log-20160403 -rw-r--r-- 1 root root 48574 4月 10 02:33 2016 error_log-20160410 -rw-r--r-- 1 root root 30213 4月 17 02:50 2016 error_log-20160417 -rw-r--r-- 1 root root 24102 4月 24 03:14 2016 error_log-20160424 -rw-r--r-- 1 root root 19867 5月 1 03:21 2016 error_log-20160501 -rw-r--r-- 1 root root 52158 5月 8 03:14 2016 error_log-20160508 -rw-r--r-- 1 root root 22972 5月 15 02:21 2016 error_log-20160515 -rw-r--r-- 1 root root 44764245 5月 22 03:25 2016 error_log-20160522 -rw-r--r-- 1 root root 103924448 5月 29 03:52 2016 error_log-20160529 -rw-r--r-- 1 root root 89407451 6月 5 02:45 2016 error_log-20160605 -rw-r--r-- 1 root root 104046940 6月 12 03:06 2016 error_log-20160612
上記のようにerror_log-20160522ファイルから40Mバイト以上のログとなっているのでハードディスクを圧迫しかねない。
といってもそれほど緊急性は、ないけれどいきなりログが増えているのはただ事じゃない。
よくよく見ていると5月20日の朝方のDROPBOXへのバックアップからなっているらしい。 調べてみるとyum.logでのソフトウェアの更新は、行われていなかった。
この「WordPress Backup to Dropbox」自体も更新(手動)は、5月12日なのでこれも原因ではないようだ。
ほかのものを調べてみるとどうやらWordPress自体のバージョンアップの日付が5月20日になっているのでこれが原因なのかもしれないということが分かった。
このエラーメッセージでとりあえずググってみると
英文サイトしかヒットしなかったので仕方なたどり着いた記事が
こちら ---> https://wordpress.org/support/topic/column-offset-cannot-be-null
wardpressの公式サイトのフォーラムなので信頼性が高いかな?と翻訳しながらみてみると
質問者は、私と同じようにエラーメッセージが出てどうにかならないかと質問しているようです。
*******************************************************************************************
I think this happened after the last update, but I’m not completely sure about it.
Anyway, I was warned by my maintainer that my error_log_php file was getting very big (it reached over 270 MB in size), so I took a look at it and found out tons of lines like this one:
[22-Dec-2015 08:47:42 UTC] WordPress errore sul database Column ‘offset’ cannot be null per la query INSERT INTO’wp_wpb2d_processed_files'(‘file’,’uploadid’,’offset’) VALUES ([$PATH_TO_FILE], NULL, NULL) fatta da do_action_ref_array, call_user_func_array, run_dropbox_backup, WPB2D_BackupController->execute, WPB2D_BackupController->backup_path, WPB2D_Processed_Files->add_files, WPB2D_Processed_Base->upsert
The error is the same for all the files being sent to dropbox, the only change is in $PATH_TO_FILE.
I had to stop wpb2db to avoid this issue, so any help would be *VERY* appreciated…
Thanks in advance
*******************************************************************************************
調べるとエラーログのサイズが270Mを超えて容量が圧迫されてサーバが停止してしまうかもみたいなことが書かれています。
ちなみにこの掲示板では、WordPress Backup to Dropboxの4.4.1バージョンでダメです。と書かれており追記で4.5のバージョンでもまだ修正されていないと報告されています。
私のWordPress Backup to Dropboxのバージョンは、H28.6.17現在の最新バージョンは、4.5なのでまだ修正されていないようです。
私なりの解釈だとこのエラーをみると
「 wp_wpb2d_processed_filesのテーブルのoffsetというカラム(項目)にNULLは、insert into (データ登録)出来ない 」
というように見えます。
この掲示板では、wordpress-backup-to-dropbox/Classes/Processed/Files.php
このファイルのNULL値を変えて 0(ゼロ)を入力するようにしたら上手くいくというように書いていましたので実際にやってみます。
69 $this->upsert(array( 70 'file' => $file, 71 'uploadid' => null, 72 'offset' => null, 73 )); 74 }
最終行近く72行目に
'offset' => null,
上記のNULLを0(ゼロ)に変更します。これだけです。
'offset' => 0,
これで実際にバックアップを行ってみます。
ログをtail -f error.log で監視していましたがエラーが出力されることがありませんでした。
順序が逆になりましたがPhpMyAdminでデータベースを確認すると
上記のようにwp_wpb2d_processed_filesというテーブルのoffsetカラムのデータ型がint型(整数)なのでNULL文字は、エラーになりますよね。
今までなぜかこのテーブル自体使っていなかったようです。実際もう一つの別のデータべースの同テーブルは、selectしても中には、何も入力されていなかったです。どういった状況になるとこのテーブルを使用するのかわかりませんが現在のところバグなので修正しておきます。
このサイトのテーブルは、データが入っていたのでこのエラーが出ていたようです。
ちなみにこちらのデータの一部は、以下になります。
きちんとoffsetのカラムには、0(ゼロ)が入りました。
このテーブル自体必要なのかどうかわかりませんが私と同じようなエラーが出ている方は、NULLを0(ゼロ)に変えれば問題なくなるようです。
参考にしてください。
*****************************************************************************
にほんブログ村