Mysql5.7→8でハマった。(そして解決法がなにも書いていない記事)

| コメント(0) | トラックバック(0)

ええ、ハマりましたとも。

ちょっとね。だいぶね。

いろいろと振り回されて、かなり時間喰いました。

複合的要因が絡み合ってね。バカヤローといいたい気分ですよ。ええ。

 きっかけはですね。またサーバが飛んだんですけども。

 たぶんあれ、サーバに使ってるマシンが悪いんだろうなあ。次飛んだら、あきらめてサーバとして使うのやめるか。

 などと考えつつも、今回はろくに記事がないのと飛んだ直後だったのでバックアップデータが取ってあったのですよ。

 

 なので気楽に、そうだこの際だからMovable Typeをバージョンアップして、ついでにOSをこの間出たばかりのubuntu20.04LTSにしちゃおうか、なんて考えた......のが間違いでした。

 

 Movable Typeは、ブログデータをデータベースに入れて管理しているわけです。で、データベースソフトはMysqlを使っており、またこれが一番王道で、特にMovable Type 7(今回乗り換えようとしたバージョン)ではMysqlしかサポートしなくなっちゃった......んじゃなかったかな。

 ところがubuntu20.04LTSの公式リポジトリには、Mysql8.0しか入ってないのですよ。今まで使ってたのはMysql5.7。6や7はないので、通常のバージョンアップには違いないのですがね。

 

これがね。変わったところが多すぎるんですよ。

 

 まずね、接続のパスワード認証の方式からして、違う。ので、Mysqlに接続するアプリのほとんどが、そのままでは接続できない。Mysqlの方を昔のほうにするか、接続するアプリの方を今のに合わせるか、どっちかにするしかないんですよね。

 ま、これは気がついていれば、変更作業自体はそんなめんどくさいことじゃありません。

 次が、データベース他の文字コードの変更。

 なんでか知らないけど、Mysql5.7まではlatin1、ラテン文字がデフォルトだったようです。で、8.0からはutf8mb4がデフォルト。まあ、今の趨勢に合わせたといえば正しい変更判断と言えるでしょうけど。

 5.7の時はそんなこと知らずに(そして気にせずに)、デフォルトのまま作ってましたから、データベースがlatin1。つーか、latin1で日本語管理できるのかとそっちの方が驚き。いやまあ、データベースの中では文字化けしてたんでしょうな。文字化けしても一定の法則で、一対一対応してれば、管理は可能だというのは頭では理解できるのですけどね。

 で、これを8.0に持っていく。その方法がわからない。ググっても、ますますわからなくなるばかり。

 あるページには5.7から8.0へのdumpデータの移行は不可能、従ってbinalyでdumpしてそのデータを使う、と書いてある。でもそれが書いてある他のブログや記事は見あたらない。で、これを試してみたんだけど、文字化けする。

 8.0のほうもlatin1に設定すれば見られるはず、だよなと設定を変えてみても直らない。(あとでわかったのだけど、これはブラウザのキャッシュが強力すぎて、sift+f5でもきちんと読み込み直しをしてなかったみたい)

 んじゃま、5.7の方をutf8mb4に変更してからdumpとってみるか......とも考えたんですが、ちゃんと動いているシステムの方に変更を加えるのは怖い。(そして、あとでわかったのですが、それやっても全然意味ない......みたい) 最後の手段としては考えるにしても、今はやめておこうと。

 というわけで、5.7のdatabaseとclient、8.0のdatabaseとclientの言語をそれぞれlatin1にしたりutf8mb4にしたりの順列組合せを全通り試して......そして全部ダメでした。

(と思ってしまったのは、今考えると、先ほど述べたブラウザのキャッシュのせいかもしれない。途中で一回、設定から閲覧データとキャッシュとクッキー全部削除したのになあ......)

 いろいろいじっている最中、とつぜん先ほど通ったコマンドにエラーメッセージが出るようになってしまったことも何回か。どうもいじってるうちにデータベース壊しちゃったみたいで、DROPコマンドで削除したり。で、これを何回か繰り返すと、今度はMysqlの管理部分のデータがぶっ壊れて、データに齟齬があるとかいうエラーメッセージを出すようになり、仕方なくデーターベースを再インストールして最初からやり直したのも3~4回(ぐだぐだすぎてよく覚えてない)。

 あとは、5.7を8.0にバージョンアップ(インプレイスリリース)して、データベースを(バージョンアップの過程で)自動的に変更してくれることを期待するというのも考えたのですけど、先ほど述べたように、動いているシステムに手を加えるのは怖いので、これも最後の手段にして(実際3~4回以上ぶっ壊しているわけですし)。

 移行したいデータはブログだけなので、Movable Typeの方の機能を使って、データを移動させるという手も考えました。が、よく読んだら、「異なるバージョンのMovable Typeにはインポートできません」だそうで。古いのはMT6、新しいのはMT7なので移行できません。

 ......と最初思ったのですけど、それは今までの方を6から7にバージョンアップすれば良いじゃん、と気がつきまして。Movable Typeの場合は、Mysqlと違って、移行が上手く行かなくても元のバージョンにリロールするのは簡単なのですよ。ディレクトリ名入れ替えるだけで良いので。

 というわけで、さっそくやってみたのですが......旧サーバからエクスポートしたファイルの、新サーバへのインポートが上手く行かない。

 しかもエラーメッセージ「An error occurred while reading the request movabletype」って、エラーの原因について実質なにもいっていないという。

 さすがにこれには途方にくれました。

 で、ぼんやりエクスポートしたzipファイルの中身を覗いてたら、「これ、zipでまとめてあるけど、単純に、無圧縮と同じファイルなんじゃないか?」と気がつきまして。無圧縮の際に使うimportディレクトリにzipの解凍した中身を置いてインポートしたら、なんとか上手く行きました。

......書いてて思ったんですが、この記事、Mysql5.7から8.0のデータ移行に関して、何の情報にもなってませんね。

まとめると、こういうことです。

 

  1. mysql8.0はログインパスワード認証のデフォルトが違うので、非対応アプリから使う場合には旧式の認証に戻す必要がある。
  2. 5.7から8.0へのデータ移行はデフォルトの文字コードが違うので、文字コードを合わせる必要がある。(たぶん8.0をlatin1にするのが一番簡単でトラブルも少ないが、将来性において若干不安が残る)
  3. 可能なら、データ移行はアプリの方でやった方が(簡単でトラブルも少なく)よい。
  4. ブラウザのキャッシュには気をつけろ。場合によっては別々のブラウザを使うべき。

仕事しながらとはいえ、これで1ヶ月かかったもんなあ......。

« もちろんTRPGも遊んだ。  |  それで、ぶっ飛んだ記事。 »

トラックバック(0)

トラックバックURL: https://crossbow.mydns.jp/mt/mt-tb.cgi/691

コメントする

この記事について

このページは、makiyamaが2020年6月11日 18:33に書いた記事です。

ひとつ前の記事は「もちろんTRPGも遊んだ。」です。

次の記事は「それで、ぶっ飛んだ記事。」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

2022年7月

          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            

ウェブページ

  • PC
  • RPG
  • Dugeons&Dragons
  • Traveller
  • Cthulhu
Powered by Movable Type 7.3.1