xpressMEの引越しについて

[匿名]

toemon様

いつもお世話になります。

実はこのたび、xpressMEで構築してきたサイトを、

別サーバーへ引越しできないかと考えております。

理由としましては、現在のサーバースペックが非力なのと、

MySQLのバージョンが4.0であるため、今後のことを考えての試みです。

(現在)

hd_1.03(xcl 2.1.6)

XPressME271-ver1.09

PHP 5.2.11

MySQL 4.0

記事数：1,000記事くらい

さくらサーバー(共有)

(引越し先)

hd_1.04(xcl 2.1.7)

XPressME_Integration_Kit_Ver2.1.4

wordpress 2.8.6

PHP 5.2.11

MySQL 5.X

さくらサーバー(共有)

CMSサイトの引越しは初めてのことなので、

まずは色々調べてみたところ、いくつかの方法がある事が

わかりました。

１．wordpressの「ツール」→「エクスポート・インポート」機能を使う

２．xoopsのバックアップモジュールを使う

３．MySQLでエクスポート、インポートを行う

【以下、試してみた結果です】

---

１．wordpressの「ツール」→「エクスポート・インポート」機能を使う

wordpress自体にエクスポート、インポート機能があるので、

これを使って行えないか試してみました。

記事の数が多いと、エクスポートの際にタイムアウトをしてしまうのと、

インポートの際に、アップ容量(2MB)を超えてしまうということが

わかりました。

今回の引越しも、1,000記事程度あるので、

普通にエクスポート、インポートができない状況です。

同じような問題に関する記事があったので、

こちらのサイトを参考に、php.iniでリミットの設定変更をしてみました。

php.iniに以下を追加

<code>memory_limit=34M<br />
post_max_size=33M<br />
upload_max_filesize=32M<br />
max_execution_time=600</code>

すると、インポートの際のアップロード量の許容は34MBに変わりましたが、

エクスポートにおける設定が反映されていないようで、タイムアウト？してしまいます。

投稿ユーザーを追加して、試しに記事を２～３個追加。

新しく追加したユーザーを指定してのエクスポートは問題なく行えました。

であれば、分割してエクスポートできればいいのでは？と思い、

以下のプラグインをインストール。

Advanced Export

月ごとに分割してエクスポートできるというプラグインです。

が、こちらで1ヶ月間を指定してみましたが、

やはりエクスポートできず。

とここまでで断念しました。

---

２．xoopsのバックアップモジュールを使う

xoops用のバックアップモジュールではどうかと、

以下の２つのモジュールを試してみました。

・MyX_BackUp

・Backpack

どちらもxoops全体のDBをバックアップ、

またはモジュールごとにバックアップできるというものです。

まず、全体のDBをバックアップしてみたところ、

以下のようなエラーが表示されました。

<code>Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 22300086 bytes) in /home/***</code>

モジュール単位でのエクスポートでも同様のエラーが出現しました。

見るからにメモリー不足のようですが、

php.iniでもmemory_limit=34Mとしているのに、

反映されていないようです。

試しに128MBにしてみましたが、それでも駄目でした。

ちなみに、別のモジュールの場合はバックアップ(引越し)できました。

---

３．MySQLでエクスポート、インポートを行う

MySQLを触るのは初の試みなので、

無謀のように思えましたが、なんとなく触ってみました。

(現在のサイトのMySQL)

まず、xpressMEに関連する以下のDBをダウンロード。

<code>a13519_news_comments<br />
a13519_news_d3forum_link<br />
a13519_news_links<br />
a13519_news_options<br />
a13519_news_postmeta<br />
a13519_news_posts<br />
a13519_news_terms<br />
a13519_news_term_relationships<br />
a13519_news_term_taxonomy<br />
a13519_news_usermeta<br />
a13519_news_users<br />
a13519_news_views</code>

***.sqlというファイルをエクスポートしました。

容量は40MBくらいです。

開いたところ、Shift-JISのためか、文字化けしていたので、

UTF8に変換して修正。

引越し先の接頭語に合わせないと駄目？と思いまして、

接頭語を一括変換。

wordpressの引越しに関する情報を収集していく中で、

引越し先に移動させるファイルは以下の2つであるということが判明。

wp-config.php

wp-content

これらファイルを現在のサーバーからダウンロードして、

引越し先にアップロード。

引越し先のMySQLへ、先ほどの***.sqlをインポート・・・。

そう上手くいくはずがなく・・・。

インポート中になぜかログアウトしてしまう始末。

おそらく、MySQLのインポートに(最長: 16,384 KiB) とあるので、

容量オーバー？だったからなのでしょうか。

---

と、試行錯誤してみましたが、

壁にぶち当たった次第でございます。

現在のサイトと引越し先でxpressMEとSQLのバージョンが違うのと、

DB容量が大きいことが原因なのでしょうか。

何かよい方法があれば、ご教授願いたい次第でございます。

毎度恐れ入りますが、どうぞよろしくお願いいたします。

[toemon]

wordpressの引越しに関する情報を収集していく中で、

引越し先に移動させるファイルは以下の2つであるということが判明。

wp-config.php

wp-content

これらファイルを現在のサーバーからダウンロードして、

引越し先にアップロード。

wp-contentの上書きはプラグインやアップロードファイルの移転のためなので問題ないですが

wp-config.phpのほうは

XPressME271-ver1.09とXPressME_Integration_Kit_Ver2.1.4では処理の仕方がまったく異なっているので、上書きすると、まったく動作しなくなります。

後はphpMyAdminでのエクスポート、インポートが可能ということであれば、

エクスポート後、加工を施したファイルをインポートすればよいでしょう。

（インポート前にインポート先にすでに該当テーブルがあるようなら、削除)

エクスポートファイルの加工内容
• ファイルの文字コードがutf-8でなければ修正
• データベースのテーブル名（プレフィックス)
• 旧サイトのリンクURLから新サイトURLに一括置き換え
• CHARSET=の部分がutf-8になっていなければ修正

と、いったところでしょうか

[匿名]

toemon様

ありがとうございます。

wp-contentの上書きはプラグインやアップロードファイルの移転のためなので問題ないですが

wp-config.phpのほうは

XPressME271-ver1.09とXPressME_Integration_Kit_Ver2.1.4では処理の仕方がまったく異なっているので、上書きすると、まったく動作しなくなります。

なるほど、確かに、ファイルの構文が全く違っていますね。

後はphpMyAdminでのエクスポート、インポートが可能ということであれば、

エクスポート後、加工を施したファイルをインポートすればよいでしょう。

xpressMEの場合、以下のDBに分かれていると思いますが、

a13519_news_comments

a13519_news_d3forum_link

a13519_news_links

a13519_news_options

a13519_news_postmeta

a13519_news_posts

a13519_news_terms

a13519_news_term_relationships

a13519_news_term_taxonomy

a13519_news_usermeta

a13519_news_users

a13519_news_views

容量が大きいのは「a13519_news_posts」ですよね。

例えば、これを分割加工してインポートするという感じでしょうか。

その場合、INSERT INTO *****_news_posts以下のを分割するのだと思いますが、

分割されたファイルには、それぞれINSERT INTO *****_news_postsの上の部分は必要なのでしょうか。

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;

/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;

/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;

/*!40101 SET NAMES ujis */;

—

— テーブルの構造 *****_news_posts

—

CREATE TABLE *****_news_posts (

ID bigint(20) unsigned NOT NULL auto_increment,

post_author mediumint(8) NOT NULL default ‘0’,

post_date datetime NOT NULL default ‘0000-00-00 00:00:00’,

post_date_gmt datetime NOT NULL default ‘0000-00-00 00:00:00’,

post_content longtext NOT NULL,

post_title text NOT NULL,

post_category int(4) NOT NULL default ‘0’,

post_excerpt text NOT NULL,

post_status varchar(20) NOT NULL default ‘publish’,

comment_status varchar(20) NOT NULL default ‘open’,

ping_status varchar(20) NOT NULL default ‘open’,

post_password varchar(20) NOT NULL default ”,

post_name varchar(200) NOT NULL default ”,

to_ping text NOT NULL,

pinged text NOT NULL,

post_modified datetime NOT NULL default ‘0000-00-00 00:00:00’,

post_modified_gmt datetime NOT NULL default ‘0000-00-00 00:00:00’,

post_content_filtered text NOT NULL,

post_parent bigint(20) NOT NULL default ‘0’,

guid varchar(255) NOT NULL default ”,

menu_order int(11) NOT NULL default ‘0’,

post_type varchar(20) NOT NULL default ‘post’,

post_mime_type varchar(100) NOT NULL default ”,

comment_count bigint(20) NOT NULL default ‘0’,

PRIMARY KEY (ID),

KEY post_name (post_name),

KEY type_status_date (post_type,post_status,post_date,ID),

KEY post_parent (post_parent)

) TYPE=MyISAM AUTO_INCREMENT=5115 ;

[toemon]

その場合、INSERT INTO *****_news_posts以下のを分割するのだと思いますが、

分割されたファイルには、それぞれINSERT INTO *****_news_postsの上の部分は必要なのでしょうか。

不要です。

インサートはMySQL に対するSQL文で実行されますので、

分割を行う場合、適切な位置で分割して（SQL構文の途中行で分割しない）、インポートする順番を間違えなければ、OKです。

ただ、CREATE TABLE の部分で

TYPE=MyISAM AUTO_INCREMENT=5115 ;

とありますが、DEFAULT CHARSET　が設定されていないのは気になります

こちらの環境では

ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=5115 ;

のようになっていました。

[匿名]

toemon様

不要です。

インサートはMySQL に対するSQL文で実行されますので、

分割を行う場合、適切な位置で分割して（SQL構文の途中行で分割しない）、インポートする順番を間違えなければ、OKです。

ありがとうございます！

何度かエラーを繰り返しながらも、

データを移行することが出来ました。

ただ、カテゴリーとタグが反映されないようです。

これらもDB上に書かれているのだと思いますが、

通常の方法ではインポートされないのでしょうか。

ただ、CREATE TABLE の部分で

TYPE=MyISAM AUTO_INCREMENT=5115 ;

とありますが、DEFAULT CHARSET　が設定されていないのは気になります

こちらの環境では

ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=5115 ;

のようになっていました。

確かに、Mysql4では

TYPE=MyISAM AUTO_INCREMENT=5115 ;なっていますが、

Mysql5に移行した時点で

ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=5115 ;

に変わりました。

[toemon]

ただ、カテゴリーとタグが反映されないようです。

これらもDB上に書かれているのだと思いますが、

通常の方法ではインポートされないのでしょうか。

カテゴリーとタグは

a13519_news_terms

a13519_news_term_relationships

a13519_news_term_taxonomy

が正しくインポートされていれば、反映されるはずです。

phpMyAdminでテーブルに格納されているデータを確認してみてください。

修正する場合は、該当テーブルを個別にエクスポートし、

テーブルプレフィックスの修正等を行ったうえで、

新規サーバー上から、該当テーブルを削除したのち、個別にインポートしてみてください。（一気にやるより、個別にやった方がエラー発生時に対処しやすいと思います。）

参考

a13519_news_terms　には、

　カテゴリーとタグの名前が登録されています。

a13519_news_term_taxonomy　は

　a13519_news_terms　とのリレーショナルID(term_id)と、

　タグなのかカテゴリなのかといった情報が入っています。

a13519_news_term_relationships　は

　投稿とのリレーショナルID(object_id)と

　a13519_news_term_taxonomyとのリレーショナルID(term_taxonomy_id)が

　入っています。

　これは、投稿数が1000あれば1000以上の登録があるハズです。

[匿名]

toemon様

ご丁寧にありがとうございます。

ちなみに、こちらのテーブルは、以前のバージョンには存在していないようですが、

新バージョンに引っ越すにあたって、特に触る必要はないのでしょうか。

a13519_news_group_role

a13519_news_notify_reserve

参考

a13519_news_terms　には、

　カテゴリーとタグの名前が登録されています。

a13519_news_term_taxonomy　は

　a13519_news_terms　とのリレーショナルID(term_id)と、

　タグなのかカテゴリなのかといった情報が入っています。

a13519_news_term_relationships　は

　投稿とのリレーショナルID(object_id)と

　a13519_news_term_taxonomyとのリレーショナルID(term_taxonomy_id)が

　入っています。

　これは、投稿数が1000あれば1000以上の登録があるハズです。

こちらを参考に、再度中身を確認して挑戦してみたいと思います。

ありがとうございます。

[投稿者]

投稿