さくらインターネットのレンタルサーバで WordPress 2.9 へアップグレードできない方へ

お知らせ (5/3, 2010): 旧データベースは、削除直後からアクセス不可になったとコメント欄に投稿されました。 ですので、エクスポートに失敗してしまった場合の復旧は不可能になりました。 ご注意ください。

お知らせ (1/31, 2010): エクスポートをやり直さなければならなくなった場合の、旧 phpMyAdmin へのアクセス方法についての Tips が、コメント欄に投稿されていますので、該当される方は参考になさってください。

お知らせ (12/26, 2009): 100MB 以上の大きなデータベースを移行する際の Tips が、コメント欄に投稿されていますので、該当される方は参考になさってください。

先日リリースされた WordPress 2.9 ですが、大きな変更点としてMySQL 4.1 以上のサーバ要件でないとインストールできない仕様となりました。

このブログは、さくらインターネット(以下 さくら)のレンタルサーバを2年ほど利用してきたのですが、データベース バージョンが、当時から利用していた MySQL 4.0.x だったため、WordPress 2.9 へのアップデート時にエラーとなり、アップデートできません。。 一体どうすれば!?

結論から言うと、さくらのレンタルサーバーは、’09年の4月ごろから MySQL 5.1 へ対応しており、サーバ コントロールパネルで変更が可能になっていました。(ユーザーなのに知らなかった…:P) しかし残念なことに、さくらのサイト内にも、ググッてもなかなか「コレだ!」というわかりやすい移行手順が見つかりません。

そこで今回は、旧データベース(MySQL 4.0)から新データベース(MySQL 5.1)への一連の移行手順を、スクショ多用でメモしておこうと思います。 単純に、WordPress データベースのバックアップ手順としても参考になるのではないかと思います。

今回の手順はざっと以下の5項目です。

  1. 旧データベース(MySQL 4.0)のエクスポート
  2. 旧データベース(MySQL 4.0)の削除
  3. 新データベース(MySQL 5.1)の新規作成
  4. 新データベース(MySQL 5.1)へ旧データをインポート
  5. wp-config.php ファイルの更新(一部 書き換え)

最後に役に立つ情報を書いていますので、一度 最後まで目を通しておいてくださいね。
では、作業をはじめましょう。

【1】旧データベース(MySQL 4.0)のエクスポート

旧データベースでの作業は、新データベースを作ってしまうと、やり直すことができませんので、慎重に作業を進めてください。
データのエクスポートには phpMyAdmin を利用します。
phpMyAdmin にログインします。
(クリックで拡大)

ログイン時に言語が「日本語 – Japanese (utf-8)」になっていることを確認してください。
(クリックで拡大)

わからない場合は、ログイン直後に、下のスクショを参考にし、プルダウンで「日本語 – Japanese (utf-8)」が選択されているか確認します。
(クリックで拡大)
これが他のものになっていると、新データベースへインポートした際に文字化け(文字抜けによる大幅なレイアウトの崩れ)等、失敗の原因になってしまいます。

データベース名をクリックしてテーブル一覧を表示させた状態で「エクスポート」タブをクリックして、エクスポート画面を表示させます。
(クリックで拡大)
エクスポート設定はもはや「鉄板設定」とでもいうべきもので、通常のバックアップと全く同じ設定です。
確認事項は以下の通り。 スクショもあわせて参考にしてください。

  1. エクスポート枠内のデータベース内テーブルを「全選択
  2. SQL」ラジオボタンが オン
  3. 構造」にチェック
    1. DROP TABLEを追加」にチェック
    2. AUTO_INCREMENT 値を追加する」にチェック
    3. テーブル名やフィールド名を逆クォートで囲む」にチェック
  4. データ」にチェック
    1. 完全な INSERT 文を作成する」にチェック
    2. 長い INSERT 文を作成する」にチェック
    3. BLOBに16新数表記を利用する」にチェック
  5. ファイルに保存する」にチェック

こんなところでしょうか。 赤文字は特に確認が必要な項目です。 中には、チェックの必要がないものもあるかもしれませんが、上記の状態で書き出して問題ありません。
「実行」をクリックすると「データベース名.sql」ファイルがダウンロードされます。

【2】旧データベース(MySQL 4.0)の削除

データベースの削除は、サーバコントロールパネル上で簡単に行えます。
(クリックで拡大)
簡単に行えますが、一度削除してしまうと、元に戻すことはできませんので、エクスポートの作業は十分確認しておいてください。
「データベースの削除」ボタンをクリックすると、確認のダイアログが表示され、「OK」をクリックすることでデータベースをまるごと削除することができます。
(クリックで拡大)

【3】新データベース(MySQL 5.1)の新規作成

旧データベースの削除が完了したら、新たなデータベースを作成します。
(クリックで拡大)
データベース バージョンの選択で、MySQL 5.1 が選択されているのを確認し、新たなデータベース用のパスワードを入力して「*送信する*」ボタンをクリックします。
新たなデータベースが作成され、phpMyAdmin で新データベースへアクセス出来るようになりました。

【4】新データベース(MySQL 5.1)へ旧データをインポート

新データベースへアクセスするために phpMyAdmin へログインします。
(クリックで拡大)

「MySQL接続の照合順序」というプルダウンに「utf8_unicode_ci」が選択されているのを確認します。
(クリックで拡大)
既に、「登録データベース名」「information_schema」という2つのデータベースが存在しているはずです。 「登録データベース名」をクリックして、テーブル表示にし(テーブルが0という画面になります)、その状態で「インポート」タブをクリックしてインポート画面を呼び出します。
(クリックで拡大)
インポート画面では、先程 エクスポートした .sql ファイルを選択する以外、特に設定を変更する必要はありません。 ファイルの文字セットが「utf8」になっているか確認しておいてください。 ファイルの指定ができたら、「実行する」ボタンをクリックしてインポートを開始します。

インポート処理は、少し時間がかかります。(数秒〜数十秒 程度)
正常にインポートが完了すると、以下のようにインポートが完了した旨のメッセージが表示されます。
(クリックで拡大)

【5】wp-config.php ファイルの更新(一部 書き換え)

インポートが完了したら、WordPress の wp-config.php ファイル内のデータベース設定を変更します。

define(‘DB_HOST’, ‘mysql???.db.sakura.ne.jp’);

上記の部分を新しい DB のホストアドレスに変更します。
パスワードも変更した場合は、

define(‘DB_PASSWORD’, ‘???‘);

上記部分を新しいものに変更します。
更新が完了したらアップロードします。 これで新データベースからブログデータを取得するようになります。 ブラウザで確認してみましょう。

以上でデータベースの移行はおわりです。
WordPress 2.9 へもアップグレードすることができます。

エクスポート時に失敗していても大丈夫!?

※以下の記事は、さくらインターネットのサーバー仕様が変更されたため、無効になりました。 旧データベースは、削除直後にアクセス不可となったようです。
(情報 thanks!: beryuさん

一連の手順から、お気づきの方もおられると思いますが、実は万が一、エクスポート時に失敗したまま、旧データベースをサーバコントロールパネルで削除してしまっても、旧データベースは残っているので、作業を復旧させることが可能です。(phpMyAdmin 内でテーブルを削除してしまった場合は不可能です)
ですので、もし、何らかの理由で旧データベースのエクスポートをやり直したい場合は、旧データベースの phpMyAdmin ログイン画面の URL を控えておくと、旧データベースへアクセスすることができます。(旧データベースへの phpMyAdmin と新データベースへの phpMyAdmin の URL が異なっている点に注意してください

※もし、URL を控えていなかった場合は、以下ごぶりんさんのコメントを参照してください。 ただし、旧 phpMyAdmin ログイン画面でのサーバ選択 mysql?.sakura.ne.jp の ? を忘れてしまうとアクセス出来ないので注意しましょう。

無事に新データベースへ移行できたのに、旧データベースが残っているのが気持ち悪いと思われる方も、再度、旧データベースへログインし、テーブルを削除することができますね。
ただし、さくらのメンテナンスで、いずれは旧データベースは削除(クリアー)されると思いますので、削除後の旧データベースの運用復帰は基本的にできないものと考えましょう。 削除後に「やっぱり MySQL 4.0 で運用しよう」と思い直した場合は、旧データベースからしっかりとデータをエクスポートした後、新たにサーバコントロールパネルで MySQL 4.0 のデータベースを作成し、その際 指定されたホストアドレスへ移行するようにしましょう。

なにかおかしな点があれば、コメント欄へよろしくおねがいします^:)^


さくらインターネットのレンタルサーバで WordPress 2.9 へアップグレードできない方へ」への43件のフィードバック

  1. データベースが100MB以上あるため、新データベースへインポートできません。
    そこで、bigdumpというツールを使いました。インポートは成功しますが、文字化けしてしまいます。
    何かいい方法はないものでしょうか?

  2. トマト さん
    コメントありがとうございます。

    このブログが、10MB にも満たない容量でしたので、インポートも一発で終わったのですが、それだけの容量となると、テーブルを分割したりする必要があるのではないでしょうか?
    しかし、単一テーブルの容量が大きいとそれだけでもインポートできない可能性もありますよね。。

    どなたか、分割ツールを併用されたことのある方で、お分かりになる方のフォローをお待ちしてます!:-c

  3. 解説通りに進めて無事移行できました。
    めちゃめちゃ助かりました。本当に有り難うございました(深いおじぎ)。

  4. 細川 さん
    コメントありがとうごいます。
    いえいえ、こちらこそお役に立てて嬉しいです(深いおじぎ):)

  5. できました!
    「bigdump」のコードを見てみると、70行目に
    $db_connection_charset = ”;
    というのがあったので「utf8」をいれて
    $db_connection_charset = ‘utf8’;
    にして実行してみると・・・できました。
    これでmysql5.0に以降できます。
    ここまでの道のりが長かった・・・。
    :)>-

  6. トマト さんこんばんは。
    おー!なんと素晴らしい!<:-p
    文字コードの記述が必要だったんですね。 おつかれさまでした!
    みなさんも是非とも参考になさってください!:)

  7. ジュリママさん コメントありがとうございます。
    無事に移行できてよかったですね!

    このポストが、沢山の方のお役に立っているようで、嬉しい限りです:)

  8. 私の所では、DBファイルが50Mくらい会って、アップデートを悩んでいましたが、無事ここに書いているのと、bigdumpを使って更新出来ましたー。
    ありがとうございました。

  9. shingoy さんコメントありがとうございます。
    無事に更新できてよかったですね!
    大きなDBに bigdump 様様ですね:)

  10. bagelさん、大感謝!
    仕事用webサイト(さくらインターネット)のmysqlバージョンアップ、予備知識なく始めたので、ファイルサイズの問題やら文字コードの問題やら、つい2時間ほど前まで、もう復旧できないんじゃないか。。。と真っ青になってました。
    ぐぐって見つけたこの記事と、bigdumpサマサマです。
    御礼を言わずにはいられない!
    ありがとうございました。

  11. わかだんな さん コメントありがとうございます。
    無事に復旧&移行されたようで、よかったですね!<:-p
    bigdump サマ大活躍だったんですねw
    お役に立てたようで、嬉しいです:)

  12. はじめまして。
    お世話になります。
    貴ブログに書かれていた方法を行った者です。

    新しいphpmyadminに、ダウンロードしておいたファイルをインポートしようとすると、

    #1007 – Can’t create database ‘●●●●●●●’; database exists

    というエラーメッセージが表示されます。

    ネットで検索したらこのエラーは、
    “データベースを作成しようとしたときに、すでに同名のデータベースが存在していた場合に表示されます。 ”
    との事のようで、どうしてもインポートがうまくいきません。

    データベース削除した後の旧phpmyadminにアクセスしてみたところ、データベースは(0)の状態になってしまっていました。

    このような場合、過去のデータはもうあきらめてまた一から作っていくしか方法はないものでしょうか。

    お手数お掛けしますが、ご教示していただければ幸いです。

  13. やせリンゴ さん コメントありがとうございます。

    エラーが出るとのことですが、私もはじめてのケースなので少し Google で調べてみました。
    (ex. phpmyadminによるエクスポートとリストア
    確かに、同様のエラーが起こっている方が居られるようですね。

    今回の場合、旧 phpMyAdmin のデータベースが (0) の状態というのも、なぜそうなってしまったのかが判りません。 私は実際に、旧 phpMyAdmin からやり直した経験から今回の記事を書きましたが、旧 phpMyAdmin の状態を保証するものではないので、もしかすると、何らかの条件で (0) になってしまったのかもしれません。

    wp-config.php の状態を元に戻しても、作業前のブログ等が見えなくなっているのであれば、旧DB は失われており、復旧が困難な状態であると思われます。
    もし見えるようでしたら、旧DB からの復旧は、まだ可能なはずです。

    本当にデータが失われたとすれば、とても残念に思いますし、この記事のどこがいけないのかも改善しなければと思うのですが、なにかお心当たりのあることなど、お教えいただけると助かりますが、いかがでしょうか。

    要領を得ないお返事ですみません。。
    よろしくお願いします。

  14. bagel様 

    丁寧なお答を、ありがとうございました。

    私以外にもこういう症状の方がいたんですね。
    “phpmyadminによるエクスポートとリストア”に書かれている事をやってみようと思います。
    それと、指摘していただいたwp-config.phpについても試してみます。

    今日、明日は都合があり、できません。
    結果は、またこの場を借りて、ご連絡させていただきます。

    もし復旧ができなかったとしても、「それはそれでで仕方ない」と割り切って、気持ちを切り替えてやっていこうと思います。

    1年ほど個人的なブログをやっていたのですが、またワードプレスの勉強をするつもりで、作っていこうかと。

    いずれにしても、復旧できるか試してみます。
    いろいろヒントを与えてくださり、改めてお礼を申し上げます。
    ありがとうございました。

  15. やせリンゴ さん お返事ありがとうございます。
    エクスポートしたファイルを触るだけで解決するといいのですが。。その際、ファイルの文字コードが変わらない様にも注意した方が良いようですね。

    いずれにしても現時点で、これまでやってこられたブログが、消えてしまわないことを祈っております。
    その後の経過も是非、お聞かせくださいね。

  16. #1007 ? Can’t create database ‘●●●●●●●’; database exists
    になる件ですが、私もなりました。

    どうもエクスポートするときにhogehoheを選択して落としてしまったようです。
    本当はその下の名称を全選択してエクスポートしなければならなかったみたいでした。
    ここを間違えるとエクスポートファイル名が「データベース名.sql」ファイルではなく「サーバ名.sql」ファイルになりました。

    削除後でも再度4.xでデータベース作成してログイン後に、昔と同じサーバ名(mysql?.sakura.ne.jp)を選択してログインすると削除した状況でログインできるので、そこに一時的にインポートして、再度正しくエクスポートすれば手順どおりにWP.2.9.1に上げられました。

  17. ごぶりん さん コメントありがとうございます。

    なるほど!テーブルではなく、データベースを選択してエクスポートすると確かにそうなると思います。
    旧phMyAdmin へのアクセスについては厳密に書いていなかったのですが、ゴブリンさんの書かれた手順の方がわかりやすいと思いました。
    本文の説明も補足しておこうと思います。
    ありがとうございました!

    やせリンゴさんにも参考になるんじゃないかと思います。

  18. ピンバック: Hello world! « HAGE_BLOG
  19. はじめまして。
    大変有用な情報を共有していただき、ありがとうございます!
    私もこちらを拝見して、さくらのDBサーバをMySQL4→MySQL5.1に移行させて頂きました。
    ただ、一点だけ想定外の事象が発生したので、情報共有のためご報告申し上げます。

    本文中に”旧データベースをサーバコントロールパネルで削除してしまっても、旧データベースは残っているので、作業を復旧させることが可能です。”とありますが、サーバコントロールパネルから削除操作を行った直後から、旧データベースにアクセス出来なくなってしまいました。
    phpMyAdminの旧ログインURLから今まで通りのログイン操作を試みると「#1045 – Access denied for user: (ユーザ名)」と表示される上、今まで運用していたphp製のサイトからも旧データベースに接続出来なくなっていました。
    これらの現象は、2010年5月3日午前3時頃に行った削除操作から、5分も経たない間に発生したものです。

    幸い、エクスポート操作がうまく出来ていたので被害はありませんでしたが、さくらのレンタルサーバ側の挙動が変更になっている可能性がありそうです。

  20. beryu さんコメントありがとうございます!

    いつかこの時が来るとは思っていましたが、とうとう旧データベースへのアクセスが直後に閉じられる仕様になりましたか。

    まあ、大容量データベースでない限り、皆さんこの記事のとおりでスンナリ移行しておられる様なので、大丈夫だとは思っていますが、大容量データベースを運用されている方は注意してくださいね。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

For spam filtering purposes, please copy the number 3188 to the field below: