Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /home/sinxcerity/www/wp-includes/pomo/plural-forms.php on line 210

Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /home/sinxcerity/www/wp-content/plugins/wp-markdown/markdownify/markdownify.php on line 299
Nucleus データベースをMySQL4.0から5.1へ変更した時の戦慄 | SINxGularity

Nucleus データベースをMySQL4.0から5.1へ変更した時の戦慄

さくらでMySQL4.0から5.1へ変更。
で、さっき壮大に失敗して顔面蒼白になったわ。。

管理画面(phpmyadmin)で既存の4.0DB(DBは4.0A)からデータをsqlでエクスポート

ターミナル(teraterm)を使ってmysql.dumpも作成

管理画面(phpmyadmin)でデータベース削除!

管理画面(phpmyadmin)で5.1データベース作成(DBが5.1Bになった)

管理画面(phpmyadmin)でさっきのデータをインポート

文字化け!&レイアウトぐちゃぐちゃ!失敗!

DB破壊=サイト死亡(顔面蒼白)

で、そこからの復旧作業。


管理画面(phpmyadmin)で作ったばかりの5.1DBを削除!

管理画面(phpmyadmin)で4.0DBを再作成
(DBが4.0Cになった、もう4.0Aには戻れない)

管理画面(phpmyadmin)でsqlをインポート!

エラー表示!ぎゃあああああ!

ターミナル(teraterm)を使ってmysql.dumpを逆流させる

・・・なんとかなった。dumpしといて助かった。。。

5.1にしなきゃいけない理由があるからまたチャレンジするけど。

そんな感じよ。

追記:その1 状況を整理しよう。

俺はsakuraで借りてるスペースでNucleusCMSを複数稼動させている。
NucleusにはEUC版,UTF8版と異なる文字コードのバージョンがあって、
うちだとほとんどUTF-8版を使ってるんだけど、
N3.1jにあるNucleus(一番最初に作ったやつ)だけがEUC-JP版。

で、MYSQL4.0⇒5.1だけど、UTF8の方はなんとか移行できた。
残すはN3.1j、misakiが使ってる場所のやつだけ。

今その地点

ちなみに昨日のタイトル文字化けNucleus本体にバグというか不具合があった。

まさか本体の仕様とは、、、問題の切り分けが大変だったわ
この対策でUTF8版は上手くいきました。 残るはEUC版です。

追記:その2 原点に立ち返ってみよう。

UTF8で書かれたsqlデータをcharset:utf8でUTF8版Nucleusにインポートした際の不具合(タイトルだけ文字化け)が起きたのは、
Nucleus本体の問題でエクスポートデータが壊れていたわけじゃなかったんだろう。
こんな感じよ
タイトルも本文も同じUTF8で書かれているのにタイトルだけが文字化けするというのはさっぱり意味がわからなかったし。

でもEUC版は明らかに不具合を起こしてる。
EUCで書かれたsqlデータをcharset:EUCとしてEUC版Nucleusにインポートしてるのに、その全てが得体の知れない文字に化けるんだから。
ujis⇒EUC、EUC⇒ujis、など色々やってみたけどぜんぜん駄目。

ならN3.1jで動いてるNucleusをEUC版からUTF8版にアップグレードした上で、
EUCで書かれたsqlファイルをUTF8sqlファイルに変換してインポートしてみたらどうか?
UTF8sqlをcharset:UTF8としてUTF8版にインポートするのは問題ない。というのは確定事項。
元々EUC版は排除して全部UTF8版に変更したかった。この際一挙両得を狙ってみようか。
それともそうしなさいという啓示なのか。

N3.1jのバックアップsqlファイルはEUCで書かれている。

それをUTF8に文字コード変換する(別ファイルとして保存、オリジナルは残す)

Nucleus3.31sp_EUCをNucleus3.41_UTF8にアップグレード。

sakuraの管理画面(phpmyadmin)からUTF8で書き直したsqlファイルを逆流させる。

エラーが出る。何度やっても同じ場所でエラーがでてインポートが中断する。
しかもエラー表示が文字化けして読めない。いや、つまり文字化けしてるから進まないのか。

エラー文にかかれている文字の中から当たり前に表示されている文字列を頼りに逆探知。

sqlファイルの中から該当の文字化けを起こしている場所を見つける。
全部で7箇所、いずれも2005年に投稿されたコメント。
元から文字化けしていたようなのでこれを削除させてもらう。

再度逆流インポート。

上手くいった!ように見えたがまだわからない。体裁を装ってるだけかも。

N3.1j上で新規投稿してみると、
Unknown column ‘IPOSTED’ in ‘field list’
「ipostedカラムが無いよ」とmysql errorが出た。
該当のテーブルを確認してみると、確かにそんな名前のカラムは無い。
同じ名前のものでもsinxnの方には有る。
もしやアップグレードの手順が足りてないか?確認してみる、確実に足りてなかった。

追加のアップグレードスクリプト実行を忘れていた。から、行う。
Nucleusアップデートスクリプト

上手くいった、ように見える。今確認作業中
(sqlファイルの中にまだスパムデータが残っていたのでそれも削除。スッキリ)

しかし、これで全てのNucleusがUTF8版になって、
俺はEUCの呪縛から開放される事になったわけでよかったかもよ!

追記;その3 今後の為に環境を整備しておく

ターミナル接続して現在のDBの情報をチェックする。

まずMySQLにログイン
%mysql -u [username] -h [hostname] [dbname] -p
パスワード入力を求められる。入力する。⇒mysqlコマンド受付画面になる。

ステータスを確認する。
mysql > status

————–
mysql? Ver 14.14 Distrib 5.1.30, for portbld-freebsd7.1 (i386) using? 5.2

Connection id:????????? 5528053
Current database:?????? [DBname]
Current user:?????????? [DBname@IPaddress]
SSL:??????????????????? Not in use
Current pager:????????? more
Using outfile:????????? ”
Using delimiter:??????? ;
Server version:???????? 5.1.36 FreeBSD port: mysql-server-5.1.36
Protocol version:?????? 10
Connection:???????????? [DBhostname] via TCP/IP
Se rver characterset:??? ujis
Db???? characterset:??? ujis
Client characterset:??? ujis
Conn.? characterset:??? ujis
TCP port:?????????????? 3306
Uptime:???????????????? 11 days 45 min 15 sec
————–

ふっ ujisになってるじゃないかYO
(ujisのデータベースにutf8でデータを書き込んでいるという気持ちの悪い状態)
現状特に問題は無いようだけど今後の不具合を減らす為に環境整備しておこうとおもう。

もっと詳しくcharacter-setを確認する
mysql> show variables like “char%”;

+————————–+———————————-+
| Variable_name??????????? | Value??????????????????????????? |
+————————–+———————————-+
| character_set_client???? | ujis???????????????????????????? |
| character_set_connection | ujis???????????????????????????? |
| character_set_database?? | ujis???????????????????????????? |
| character_set_filesystem | binary?????????????????????????? |
| character_set_results??? | ujis???????????????????????????? |
| character_set_server???? | ujis???????????????????????????? |
| character_set_system???? | utf8???????????????????????????? |
| character_sets_dir?????? | /usr/local/share/mysql/charsets/ |
+————————–+———————————-+

完全にujisで設定されているようです、本当にありがとうございました。
ujisで設定されてるところをUTF8に変更する作業に入ります。

まずはdatabaseのcharcter_setをUTF8にする
mysql> alter database [DBname] character set utf8;

次にclient,connection,resultsのcharcter_setをUTF8にする。
mysql> set names utf8;

この状態でもう一度
mysql> show variables like “char%”;

+————————–+———————————-+
| Variable_name??????????? | Value??????????????????????????? |
+————————–+———————————-+
| character_set_client???? | utf8???????????????????????????? |
| character_set_connection | utf8???????????????????????????? |
| character_set_database?? | utf8???????????????????????????? |
| character_set_filesystem | binary?????????????????????????? |
| character_set_results??? | utf8???????????????????????????? |
| character_set_server???? | ujis???????????????????????????? |
| character_set_system???? | utf8???????????????????????????? |
| character_sets_dir?????? | /usr/local/share/mysql/charsets/ |
+————————–+———————————-+
8 rows in set (0.00 sec)

server以外のcharcter_setがutf8に設定されました。

この作業はデータベースにすでにutf8でデータが書き込まれた状態で行いましたが、
それでも特に問題無いようです。本来は事前にやっておくべき事だとは思いますが。

※問題有りだったようです。これを事前にやっておけば下記の不具合は起こらなかったはず

Nucleus MySQL wavedash問題

そんな感じよ。

4 comments on "Nucleus データベースをMySQL4.0から5.1へ変更した時の戦慄"

  1. クエでどうしても狩らないといけない
    初めて手を出すMOBを叩いたら
    そこら中のがリンクしてきて祭りになったけど
    高級瞬間回復とかのんで何とかしのいだ。的な。
    でもクエ品はでなかったからもう一度。的な。
    そんなかんじね。わかった。
    がんばってください><ノ

Post a comment on "Nucleus データベースをMySQL4.0から5.1へ変更した時の戦慄"

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