「クラッシュ」タグアーカイブ

WordPressでデータベース接続確立エラーになり、Not enough memory for blob データベースの修復(Repair)もできない時の対処法

データベースエラーになった時の状況確認

データベース接続確率エラーとWordpressで表示される時の状況確認。

・インストール後やサーバー移転後ずっとエラーなのか、ある時急にエラーになったのか
→ 最初からの場合は、データベース名、ホスト名、ユーザー名、パスワード、プリフィックスなど何かしらが間違えている可能性が高い。
まずはwp-config.phpの中のデータベースの設定などを確認。

ある時を境に、急にエラーになった場合は下記確認。

・サーバー側のエラーなのか、データベースのテーブルが壊れているのか
→ サーバーがダウンしている、メンテナンス中などの場合もこのエラーが表示される場合がある。緊急でないなら数時間~1日待ってみる。
国内サーバーなら、ホスティング会社のWebサイトなどに障害状況が掲載される場合が多いのでチェック。
海外サーバーなら、カスタマーサポートにメールかチャットで連絡してみる。

データベースの異常を確認するには、phpMyAdminにログインして、テーブルが「in use」になっているかどうかを確認すれば、データベースが壊れているかはすぐに分かる。

 

phpMyAdminを使いたくない(使い方が分からない)人は?

蛇足だが、phpMyAdminを使いたくない人は、

wp-config.phpのどこかに

define( 'WP_ALLOW_REPAIR', true );

と記述してから

ブログURL/wp-admin/ にアクセスしてみてWordPressからDBの修復を試みる事ができる。

これで修復できればいいが、できない場合は下記へ。
 

phpMyAdminからのデータベース修復

サーバーの管理画面などからphpMyAdminへログイン。

該当のデータベースを開くと

テーブルで「in use」となっているものがあり、「in use」は、破損を意味している。
今回は、wp_options が死んでいる。
あと他にも、wp_commentmeta もよく死ぬ。

壊れているテーブルの左のチェックボックスを選択してから上のメニューで「Repair table」を選ぶ。

日本語版だったら「テーブルの修復」かな?

上に緑で「Your SQL query has been executed successfully」って出たので、やった!成功だ!と思いきやエラーでした。

「Not enough memory for blob at 64384 (need 16862691..」

need xxxxx の部分の数字が途方もなく大きいので、これはもうまともな手法では直せないなと理解。

このエラーが出た時は 修復(repair)では直せない。

ちなみに、シェルアクセスでコマンドを打っても同じ、当然WordPressのdefine( ‘WP_ALLOW_REPAIR’, true );で、管理画面からリペアを試みても無理だ。
 

データベースのバックアップの復元、それが無いならサーバー管理会社にお願いしてリストア(ロールバック)してもらう。

自分で定期的なバックアップをとっていればそれをリストアしてもいい。

データベースのバックアップなんかしてねーって場合は、サーバーの運営会社(ホスティング会社)に連絡して最新のデータベースのバックアップへ復元してもらうしかない。

WordPressの最も簡単なバックアップ方法。データベースと画像のバックアップ。サーバークラッシュに備えよう

WordPressのバックアップは大丈夫?データベース(記事内容)、画像、とテンプレートのバックアップ方法

 
ブログを一生懸命書いても、ミスでテンプレート上書き(アップデートも含む)してしまったり、サーバーに不具合があったり、プラグインの相性が悪くデータベースが壊れてしてしまったりする。
 
大切なブログのデータをバックアップして守ろう。
 
 

WordPressの全データをバックアップしよう

 
 
大きく分けて、バックアップには3つの手順が必要。
 
1. データベース(書いた記事の文章)のバックアップ
2. 画像・写真のバックアップ
3. テンプレート(ブログの外観)のバックアップ
 
 

1. データベース(文章)のバックアップ方法

 
絶対に必要なものがこれ。データベースのバックアップだ。これは書いた文章そのもの。最も大切なものだ。

これにはphpMyAdminを使ってデータベースをダンプ(つまりエクスポート)する方法と、プラグインを使う方法がある。

phpMyAdminはややハードルが高い人もいるかと思うので、ここではプラグイン「WP-DBManager」を使う方法を紹介する。

まず、プラグインのWP-DBManagerを入れる。プラグインの新規追加で「WP-DBManager」と検索すればすぐ出てくる。

プラグインを有効化してから→「DB Options」をクリック。
db-backup

MySQLダンプのパスとMySQLのパスは自動で入力されているはずだが、サーバー環境によっては自動で入力されない場合もある。
“no mysqldump in /usr/local/bin /usr/bin /bin”となっていると、自動で入力されていないので自分で入力しなきゃいけない。

自動で入力されている場合は触らなくてOk。

自動で入力されないサーバーの代表格がお名前.com共有サーバーSD

この場合手動で下記入力
Path To mysqldump:
/usr/local/mysql/bin/mysqldump

Path To mysql:
/usr/local/mysql/bin/mysql

db-backup-bk1

バックアップフォルダへのパスは自動で入力されるはず。こんな感じで。
Path To Backup:
/export/sd203/www/jp/r/e/gmoserver/9/2/xxxxxxxx/xxxxxxx.com/blog/wordpress-4.2.2-ja-jetpack-undernavicontrol/wp-content/backup-db

db-backup-bk2

ちなみに確認方法は、
FTPで、Path To Backupのパスを見る。バックアップフォルダが自動で出来ている場合は、その中の、「1450050232_-_DB名.sql」というのがDBバックアップ。自動でバックアップフォルダが出来ていない場合(サーバーの仕様による)手動でbackup-dbと言う名前のフォルダを作るなどの作業が必要な場合もある。

心配ならDBバックアップはローカルに移しておくといい。

これで文章データは週1回自動でバックアップされていく。「DB Options」の画面でバックアップ頻度とかは変えられる。

テーマとか、テンプレートのカスタマイズのバックアップ、画像のバックアップをする場合は、wp-contentのフォルダをローカルに移しておけ。

 
 

2. 画像・写真のバックアップ方法

 
画像のバックアップもしておこう。文章データ(データベース)と画像データがあれば、仮にサーバーがクラッシュした場合であっても、記事の復元は可能なので安心だ。
 
wp-content/uploads の中にアップロードした画像や写真が保存されている。不安ならこれをFTPソフトなどで、ローカルに移動させておくといい。

2015/12
2016/01
2016/02

などと、年月毎にフォルダに格納されている。
images-backup

これで月が替わるごとにバックアップすれば完璧だ。

 
 

3. テンプレート(ブログの外観)のバックアップ方法

 
更に、テンプレートをカスタマイズしている場合は、テンプレート(ブログの外観)もしておこう。これは再びテンプレートphpフィアルを編集しない限りは最初の1回だけのバックアップで大丈夫だ。
 
wp-content/themes の中身をFTPソフトでローカルに移しておこう。

ちなみに、テンプレートは全くカスタマイズしていない場合、基本的にはバックアップは不要。