MT4.2がとにかく重い
ブログ記事が複数ブログでも全体で900記事超になると、MovableType4が、重くて、重くて。画面遷移だけで、ものすごく時間がかかるようになってしまいました。
普段の更新すら満足にできない状況になってきたので、どうにかしないと、と思って、サーバをさくらのレンタルサーバのスタンダードプランからプレミアムプランへ移行してみたのですが、それでも重い。
MySQLの方が速いらしい
で、ネットで検索してみたところ、どうもMT4では、データベースはSQLiteよりもMySQLの方が快適ということを、皆さん記事で書かれているので、MySQLは使ったことないのですが、移行することにしました。
MT3の環境では、MT全体で2000記事近くあっても、SQLiteはさくさく動くし、バックアップも簡単だし、快適だったんですけどねえ。
MT4.25のシステムメニューでバックアップ
さて、移管の方法ですが、データベースの変換ができないか、とかも思って調べたのですが、よくわからず、MT4.25搭載のバックアップを使ってデータを移行することにしました。
複数ブログ全体をバックアップしたいので、システムメニュー>ツールバックアップで、「圧縮しない・分割しない」でバックアップしました。
このとき、事前に必ず、mt-config.cgiにバックアップ先のtempディレクトリへのファイルパスを自分の管理しているサーバの領域に変更しておかないと、バックアップファイルがサーバのルートあたりに出来たりしてとんでもないことになります。
また、ファイルパスを変更していても、tempフォルダを作成していないとエラーが表示されますので、注意。
バックアップが作成されたら、tempフォルダからダウンロードして念のためバックアップします。
現在のmtフォルダ及びSQLiteのデータベースフォルダの名称を変更します。
新しいMT4.25を新しく作成したmtフォルダにアップロード。
事前にさくらのレンタルサーバコントロール画面で申し込んでおいたMySQLの情報を使って、新MT4.25インストール時にデータベース設定をします。
システムメニューのツール>復元を使い、復元します。
新MT4.25のimportフォルダに(なければ作成)、先ほどダウンロードしたバックアップファイルをアップロード。
バックアップファイル参照ボタンはさわらずに、復元ボタンを押します。
そうすると、importフォルダにアップロードしたファイルを使って、復元が始まります。
復元時のあれこれ
さて、1回目は、なぜかバックアップに失敗しました。
原因がわからなかったので、とりあえず、次のことをして旧MTから再度バックアップしたファイルを使うと、今度はバックアップできました。
・旧MTと同名になるmy_first_blogをMT管理画面から削除。
・my_first_blogのフォルダを作ってなかったので作成。
・作りかけだったブログを削除。
あと、一回目のバックアップに失敗し、ブログを全部削除したのですが、システムテンプレートを削除しないで、新バックアップファイルをimportしたら、同名のシステムテンプレートが2個ずつ出来てしまいましたので、片方を後で削除しました。
また、システム全体のバックアップではないので、blogidが変更になり、設定していたmultiblogがうまく作動せず、プラグイン画面の設定を新しいblogidに変更し直しました。
また、何が原因かわかりませんが、「旨~い!」の「~」が今までは全角で入力できていたものが、全て?に変更になり、半角に変更しました。
また、これは確定ではありませんが、カテゴリとブログ記事がうまく関連づけられていないと思える箇所もあり、一度そのカテゴリを削除し、再度設定し直しました。
あと、システム画面からバックアップしたせいか、グローバルテンプレートもカスタムフィールドもちゃんとバックアップできていました。
それぞれのブログからバックアップした場合、グローバルテンプレートもバックアップしてくれるのかどうかは不明です。
MT4.25のSQLiteからMySQLへのデータベース変更まとめ
とりあえず移行作業は思ったより何事もなく移行でき、ほっとしています。
MySQLの感想は、確かに、SQLiteの時よりかなり動作が軽快になったような気がします。
あっという間とはいきませんが、それなりにまあ、使える範囲ないかな。
なんかMT4って、表示されてから、操作できるようになるまで、ワンクッションあるんだよね。これは、データベース変えても変わらずな感じ。
とりあえずこれで、通常の更新ができそうで、ほっとしています。
コメントする