xpressMEの引越しについて
永らくありがとうございました › フォーラム › インストール › xpressMEの引越しについて
- このトピックには6件の返信、2人の参加者があり、最後に
匿名により13年、 1ヶ月前に更新されました。
-
投稿者投稿
-
2009 年 12 月 9 日 9:19 AM #2625
匿名
ゲスト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サイトの引越しは初めてのことなので、
まずは色々調べてみたところ、いくつかの方法がある事が
わかりました。
1.wordpressの「ツール」→「エクスポート・インポート」機能を使う
2.xoopsのバックアップモジュールを使う
3.MySQLでエクスポート、インポートを行う
【以下、試してみた結果です】
1.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に変わりましたが、
エクスポートにおける設定が反映されていないようで、タイムアウト?してしまいます。
投稿ユーザーを追加して、試しに記事を2~3個追加。
新しく追加したユーザーを指定してのエクスポートは問題なく行えました。
であれば、分割してエクスポートできればいいのでは?と思い、
以下のプラグインをインストール。
Advanced Export
月ごとに分割してエクスポートできるというプラグインです。
が、こちらで1ヶ月間を指定してみましたが、
やはりエクスポートできず。
とここまでで断念しました。
2.xoopsのバックアップモジュールを使う
xoops用のバックアップモジュールではどうかと、
以下の2つのモジュールを試してみました。
・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にしてみましたが、それでも駄目でした。
ちなみに、別のモジュールの場合はバックアップ(引越し)できました。
3.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容量が大きいことが原因なのでしょうか。
何かよい方法があれば、ご教授願いたい次第でございます。
毎度恐れ入りますが、どうぞよろしくお願いいたします。
2009 年 12 月 9 日 11:51 AM #3009toemon
キーマスター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になっていなければ修正
と、いったところでしょうか
2009 年 12 月 9 日 3:14 PM #3010匿名
ゲスト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 ;
2009 年 12 月 9 日 11:36 PM #3011toemon
キーマスターその場合、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 ;
のようになっていました。
2009 年 12 月 10 日 9:36 AM #3012匿名
ゲスト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 ;
に変わりました。
2009 年 12 月 10 日 10:38 AM #3013toemon
キーマスターただ、カテゴリーとタグが反映されないようです。
これらも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以上の登録があるハズです。
2009 年 12 月 11 日 12:58 AM #3014匿名
ゲスト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以上の登録があるハズです。
こちらを参考に、再度中身を確認して挑戦してみたいと思います。
ありがとうございます。
-
投稿者投稿
- フォーラム「インストール」には新規投稿および返信を追加できません。