MySQL Tag Archive

会社のマシンがいろいろあって今時のスペックのものに変わったので、これまでローカルで xampp for windows を使ってカスタマイズとか実験とかしていた WordPress の環境を、仮想PC にインストールした Vine 4.1 上に移すために試行錯誤。

問題になるのはやはり MySQL のバージョンが、既存の環境では 4.0.25 (Vine 3.2) で、Vine 4.1 では 5.0.27 となっていること。そもそも 4.0.x 系統と 4.1.x 系統の間でも断絶があったりするのに、一気に 5.0.x 系統へのアップグレードは不安が残ります。

最小インストールした Vine 4.1 に Apache2 やら PHP4 やら MySQL やらを apt-get で突っ込んで、必要なプログラムのインストールを確認した後に、 4.0.25 からデータベースを mysqldump でダンプして、インポートしてみました。

素の状態でインストールしたときは、見事に文字化け。やはり上手くはいかないようで。

my.cnf の書き換えで対応

で、MySQL 文字化け でぐぐると、それっぽい情報がたくさん出てくる出てくる。MySQL で使われる文字コードを統一して、余計なことをしないようにするのが無難なようで、MySQL5にACCESSやADO.NETでアクセスした際に、文字化けをしないようにするのは？～MySQL関係 を参考に、以下のようにすると文字化けは解決しました。my.cnf は 初期状態では存在しなかったので、

$ cp /usr/share/mysql/my-medium.cnf /etc/my.cnf

としてやって作成しました。以下はその my.cnf に対して追記した内容です。

[client]
default-character-set=utf8

[mysqld]
default-character-set=utf8
skip-character-set-client-handshake

[mysqldump]
default-character-set=utf8

[mysql]
default-character-set=utf8

それぞれの設定箇所に、 default-character-set=utf8 を追加してやり、MySQL を再起動。skip-character-set-client-handshake はクライアント/サーバー間でのキャラクターセットの変換を行わないというオプションのようですね。これで、サーバ内では文字コードが UTF-8 に統一されたはず。

その後、データベースの作成も、

mysql> CREATE DATABASE データベース DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;

としてやることで、文字コードを UTF-8 と指定。

そうしてからのインポートでは無事に文字化けもせずに内容が表示されるようになりました。
使用した WordPress のバージョンは 2.2.1 の本家版。日本語リソースを突っ込んで日本語化したものです。

最初 PHP は 5 を入れたんだけれど、動かないプラグインがあったりで、結局は 4 系統(4.4.7)に戻しました。php.ini 内の mbstring については編集する必要もなく、デフォルトの設定で動きました。ただ、memory_limit = 8MB では PHP Fatal error: Allowed memory size of 8388608 bytes exhausted とか出て途中で落ちてしまったので、そこだけ 64MB に変更して稼働させています。

さて、仮想環境でも問題なく動くようなら、サーバの OS もアップグレードしたいところだなあ。もう１台マシンを調達して交換の準備をするとしますかね。

MySQL | PHP | WordPress | コンピュータ | 日記

Nucleus で構築したサイトのWordPress への移行を実験中。一番の難問は、やはりデータのコンパート。

WordPress Japan のフォーラムにもnucleusからwordpressへの移行というトピックがあり、その中で紹介されていた、wp-convert を試してみました。

このスクリプト、ドキュメントらしいドキュメントが同梱のHTML 文書だけなので少し苦労。
とりあえず、WordPress で使用するデータベースを作成し、一度インストール作業を終えてからコンバートを実施してみました。

使用したバージョンは、Nucleus が 3.24、WordPress がME 2.1.3 です。一応現在の最新版になるのかな。

in_start_screen.html に書かれているように、import-nucleus.php をエディタで編集して、データベースへの接続情報を書いてやるようですね。

$DB_source_host		//Nucleus データベースサーバのホスト名
$DB_source_database	//Nucleus で使用しているデータベース名
$DB_source_user		//$DB_source_database へ接続する際のユーザ名
$DB_source_password	//$DB_source_user のパスワード
$DB_dest_host		//WordPress データベースサーバのホスト名
$DB_dest_database	//WordPress で使用しているデータベース名
$DB_dest_user		//$DB_dest_database へ接続する際のユーザ名
$DB_dest_password	//$DB_dest_user のパスワード

以上を適切に編集し、保存した後にimport-nucleus.php へアクセスすると、ウィザードに従ってコンバート作業が行えるようになります。
私の場合はどちらのシステムも文字コードがUTF-8 だったので、文字コードの変換作業などは必要ありませんでしたが、場合によってはその部分も適切に変更する必要があるかも。
最終的になんかSQLエラーが結構出ましたが、記事自体はしっかりとWordPress 側でも取り込まれました。

カテゴリも一応全部コピーされているのですが、WordPress の管理画面のカテゴリ部分では、そのカテゴリに属する記事の件数が0のままで、すわ全部編集し直すの面倒(´･ω･`) と思ったりもしましたが、単に1つの記事を保存し直せば、その部分の数字は適切に戻るようです。

あとは、画像保存のパスなどが一応気を利かせて変換してくれるのですが、相対パスだったり、ルートがwp-content/ 直下で美しくなかったりするので、in_step_2.php の117行目あたりの記述を適当に変更してやる必要がありそうです。

MySQL | Nucleus | WordPress

仮想環境にVine4.0を入れてあるので、MySQL4.1へのデータ移行のテストと同時にWordPressのアップグレードのテストも行ってみました。

WordPress2.1自体のインストールはME版と代わりがないので、とりあえずは初期状態でインストール。その後バックアップしたデータをリストアする方法でどんな動作をするかを試してみました。

[u1@vmware wp-includes]# mysql -uroot -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 63 to server version: 5.0.27-standard
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> drop database wordpress;
Query OK, 14 rows affected (0.01 sec)
mysql> create database wordpress;
Query OK, 1 row affected (0.00 sec)
mysql> 
mysql> exit
Bye
[u1@vmware wp-includes]# mysql -uroot -p wordpress <wordpress_2007-01-26_04h02m.Friday.sql
Enter password: 
ERROR 1071 (42000) at line 129: Specified key was too long; max key length is 1000 bytes

やはり一筋縄ではいかない模様。Specified key was too longでぐぐってみると、いくつか参考になりそうなサイトを発見。

Gentoo Forums :: View topic - Stabilisation of dev-db/mysql-4.1.14によると、どうも主キーの長さが1000バイトを越えているのが原因の模様。UTF8で計算されているから、超過してしまうのですね。実際に引っかかった箇所は、

CREATE TABLE `wp_bdprss_items` (
  `item_feed_url` varchar(240)  NOT NULL default '',
  `item_url` varchar(255)  NOT NULL default '',
  `item_name` varchar(255)  NOT NULL default '',
  `ref_number` int(5) NOT NULL default '0',
  `text` text NOT NULL,
  `item_time` int(15) default NULL,
  `item_update_time` int(15) NOT NULL default '0',
  PRIMARY KEY  (`item_feed_url`,`item_url`),
  KEY `feed_index` (`item_feed_url`),
  KEY `update_index` (`item_update_time`),
  KEY `time_index` (`item_time`)
) TYPE=MyISAM;

というような感じで、(240+255+255)*3=2250 ってことであっさりオーバー。CHARACTER SET latin1を追加してやることで、解決するようなので、

CREATE TABLE `wp_bdprss_items` (
  `item_feed_url` varchar(240) CHARACTER SET latin1 NOT NULL default '',
  `item_url` varchar(255) CHARACTER SET latin1 NOT NULL default '',
  `item_name` varchar(255) CHARACTER SET latin1 NOT NULL default '',
  `ref_number` int(5) NOT NULL default '0',
  `text` text NOT NULL,
  `item_time` int(15) default NULL,
  `item_update_time` int(15) NOT NULL default '0',
  PRIMARY KEY  (`item_feed_url`,`item_url`),
  KEY `feed_index` (`item_feed_url`),
  KEY `update_index` (`item_update_time`),
  KEY `time_index` (`item_time`)
) TYPE=MyISAM;

としてやって、再度読み込ませてみたらエラーは消えますた。

あとはプラグインの動作チェックかな。

wp_pagenaviがページ数のカウントがおかしくなっていたけれど、2.1対応版が公開されていたので、交換したら解決。その他については、とりあえず動いているような感じかなぁ。

MySQL | WordPress