この項ではあまりあり得ないケースだが旧バージョンが新しいバージョンより優れている場合における旧 MySQL バージョンにへのダウングレードの手順について説明します。
同じリリースのシリーズ (たとえば、5.0.13 から 5.0.12) 内でのダウングレード際の一般的な規則としては新しいバイナリを旧バージョンの上段にインストールすることです。この場合データベースにはなにもする必要はありません。いつものように、この場合もバックアップを取ります。
以下の項目はダウングレードする際に必ず実施するチェックリストを示したものです。
ダウングレードするリリースシリーズのアップグレードの項を読み、実際に必要な機能がないことを確認します。項2.12.1. 「MySQL のアップグレード」 を参照してください。
そのバージョンのダウングレードの項ある場合には、それも同様に読む必要があります。
ダウングレード先のバージョンと現在のバージョンの間に追加された新機能を確認するには、変更ログを参照してください (MySQL Change History)。
項2.12.3. 「テーブルインデックスを再作成する必要があるかどうかの確認」 を確認して、現在のバージョンの MySQL とダウングレード先のバージョンの間にキャラクタセットまたは照合の変更が行われたかどうかを確認します。変更が行われており、その変更がテーブルインデックスに影響を及ぼす場合は、項2.12.4. 「テーブルまたはインデックスの再作成または修復」 の手順を使用して、影響を受けるインデックスを再作成する必要があります。
MySQL のフォーマットファイルやデータファイルを MySQL の同じリリースのバージョン内にかぎり同じアーキテクチャーの異なるバージョン間で移動できます。
1 つのリリースシリーズから別のリリースシリーズにダウングレードする場合、テーブルストレージフォーマットの互換性が取れなくなる場合があります。その場合は、mysqldump を使用して、ダウングレードする前にテーブルをダンプします。ダウングレードしたら、mysql あるいは mysqlimport を使用してダンプファイルをロードしテーブルを作成します。参考例は、項2.12.5. 「MySQL データベースのほかのマシンへのコピー」 を参照してください。
ダウンロードした際のテーブルフォーマット変更による非互換問題の一般的な現象はテーブルを開くことができないことです。そのような場合には、以下の手順に従います。
新バージョンからダウングレードしている旧 MySQL サーバーを停止します。
旧バージョンにダウングレードしている新しい MySQL サーバーを再起動します。
mysqldump を使用して旧サーバーにアクセスできなかったテーブルをダンプして新たにダンプファイルを作成します。
新しい MySQL サーバーを停止して旧サーバーを再起動します。
旧サーバーにダンプファイルをロードします。これでテーブルにアクセスでるはずです。
mysql
データベース内のシステムテーブルの構造が変更され、ダウングレードによって一部の機能が失われるか、何らかの調整が必要になる場合もあります。以下に例を示します。
MySQL 5.1 では、トリガーの作成に
TRIGGER権限が必要です。MySQL 5.0 では、TRIGGER権限はなく、代わりにSUPERが必要です。MySQL 5.1 から 5.0 にダウングレードする場合は、5.1 でTRIGGER権限を持っていたアカウントにSUPER権限を付与する必要があります。トリガーは MySQL 5.0 で追加されたため、5.0 から 4.1 にダウングレードする場合は、トリガーをまったく使用できません。
