バイナリアップグレードまたはバイナリダウングレードでは、テーブルをダンプしてリロードせずに、あるバージョンの MySQL を既存のバージョンの上に「インプレース」でインストールします。
既存のバージョンのサーバーが動作している場合は、それを停止します。
別のバージョンの MySQL をインストールします。新しいバージョンが元のバージョンより新しい場合はアップグレードになり、古い場合はダウングレードになります。
新しいバージョンのサーバーを起動します。
多くの場合、MySQL の以前のバージョンのテーブルは新しいバージョンで問題なく使用できます。ただし、このセクションで説明するように、テーブルまたはテーブルのインデックスの再構築が必要になるような変更が生じることもあります。ここで説明する問題のいずれかの影響を受けるテーブルがある場合は、必要に応じてそのテーブルまたはインデックスをセクション2.11.4「テーブルまたはインデックスの再作成または修復」に記載の手順を使用して再構築します。
テーブルの非互換性
ARCHIVE
テーブルを含む MySQL 5.0 インストールから MySQL 5.1 へのバイナリアップグレードのあと、これらのテーブルにアクセスすると、mysql_upgrade または CHECK TABLE ... FOR UPGRADE
を実行済みでもサーバーがクラッシュします。この問題を回避するには、アップグレードの前に mysqldump を使用してすべての ARCHIVE
テーブルをダンプし、アップグレード後に MySQL 5.1 にリロードします。MySQL 5.1 から 5.0 へのバイナリダウングレードでも同じ問題が生じます。
アップグレードの問題は MySQL 5.6.4 で修正されています。サーバーは MySQL 5.0 で作成された ARCHIVE
テーブルを開けます。ただし、引き続き推奨されるアップグレード手順は、アップグレードの前に 5.0 の ARCHIVE
テーブルをダンプし、アップグレード後にリロードする手順です。
インデックスの非互換性
MySQL 5.6.3 では、ROW_FORMAT=DYNAMIC
または ROW_FORMAT=COMPRESSED
を使用する InnoDB
テーブルについては、インデックスプリフィクスキーの長さ制限は 767 バイトから 3072 バイトに増加しました。詳細は、セクション14.6.7「InnoDB テーブル上の制限」を参照してください。この変更は、MySQL 5.5.14 にも移植されています。これら以上のリリースのいずれかから、長さ制限が短い以前のリリースにダウングレードする場合、インデックスプリフィクスキーを 767 バイトに切り捨てることができます。そうしないとダウングレードが失敗することがあります。この問題は、ダウングレードするサーバー上で構成オプション innodb_large_prefix
が有効であった場合にのみ生じる可能性があります。
テーブルのダンプおよびリロードを実行せずにバイナリアップグレードを実行する場合、MySQL 4.1 から 5.1 以上に直接アップグレードすることはできません。これは、MySQL 5.0 の MyISAM
テーブルインデックスの形式の非互換な変更によるものです。MySQL 4.1 から 5.0 にアップグレードし、すべての MyISAM
テーブルを修復してください。その後、MySQL 5.0 から 5.1 にアップグレードし。テーブルをチェックして修復します。
文字セットまたは照合順序の処理の変更により、文字セットの順序が変更されることがあり、そのために、影響を受ける文字セットまたは照合順序を使用するインデックスのエントリの順序が正しくなくなることがあります。こうした変更から、いくつかの問題が生じることがあります。
比較の結果が前の結果と異なる
インデックスエントリの順序付けが間違っているために一部のインデックス値を見つけることができない
ORDER BY
の結果の順序付けが間違っているCHECK TABLE
によってレポートされるテーブルを修復する必要がある
これらの問題の解決方法は、インデックスを削除して再作成するか、テーブル全体をダンプしてリロードすることにより、影響を受ける文字セットまたは照合順序を使用するインデックスを再構築することです。場合によっては、影響を受けるカラムを変更して、別の照合順序を使用するようにすることができます。インデックスの再構築については、セクション2.11.4「テーブルまたはインデックスの再作成または修復」を参照してください。
再構築する必要のあるインデックスがテーブルにあるかどうかを確認するには、次のリストを参照してください。このリストは、インデックスの再構築が必要な文字セットまたは照合順序の変更が導入された MySQL のバージョンを示しています。各エントリは、変更が行われたバージョンと、その変更の影響を受ける文字セットまたは照合順序を示しています。変更が特定のバグレポートに関連付けられている場合は、そのバグ番号が示されています。
このリストは、バイナリアップグレードとバイナリダウングレードの両方に適用されます。たとえば、Bug #27877 は MySQL 5.1.24 で修正されたため、5.1.24 より前のバージョンから 5.1.24 以上のバージョンへのアップグレード、および 5.1.24 以上から 5.1.24 より前のバージョンへのダウングレードに適用されます。
多くの場合、CHECK TABLE ... FOR UPGRADE
を使用して、インデックスの再構築が必要なテーブルを識別できます。次のメッセージがレポートされます。
Table upgrade required.
Please do "REPAIR TABLE `tbl_name`" or dump/reload to fix it!
これらの場合には、mysqlcheck --check-upgrade または mysql_upgrade も使用できます。これらは CHECK TABLE
を実行します。ただし、CHECK TABLE
を使用できるのは、ダウングレードではなくアップグレードのあとだけです。また、CHECK TABLE
は、すべてのストレージエンジンに適用できるとは限りません。CHECK TABLE
がサポートするストレージエンジンの詳細は、セクション13.7.2.2「CHECK TABLE 構文」を参照してください。
これらの変更により、インデックスの再構築が必要になります。
-
MySQL 5.1.24 (Bug #27877)
'ß'
LATIN SMALL LETTER SHARP S (ドイツ語) を含むカラムのutf8_general_ci
またはucs2_general_ci
照合順序を使用するインデックスに影響します。このバグフィックスでは、元の照合順序のエラーが修正されましたが、'ß'
が、以前は異なるという比較結果だった文字と同じという比較結果になるという、非互換性が導入されました。影響を受けるテーブルは、MySQL 5.1.30 では
CHECK TABLE ... FOR UPGRADE
で検出できます (Bug #40053 を参照してください)。この問題の回避策は、MySQL 5.1.62、5.5.21、および 5.6.5 で実装されています。回避策には、影響されるカラムを
utf8_general_mysql500_ci
およびucs2_general_mysql500_ci
照合順序を使用するように変更することが含まれます。この照合順序では、元の 5.1.24 より前のutf8_general_ci
およびucs2_general_ci
の順序付けを維持します。 -
MySQL 5.0.48、5.1.23 (Bug #27562)
'`'
GRAVE ACCENT、'['
LEFT SQUARE BRACKET、'\'
REVERSE SOLIDUS、']'
RIGHT SQUARE BRACKET、'~'
TILDE のいずれかの文字を含むカラムでascii_general_ci
照合順序を使用するインデックスに影響があります影響を受けるテーブルは、MySQL 5.1.29 では
CHECK TABLE ... FOR UPGRADE
で検出できます (Bug #39585 を参照してください)。 -
MySQL 5.0.48、5.1.21 (Bug #29461)
eucjpms
、euc_kr
、gb2312
、latin7
、macce
、ujis
のいずれかの文字セットを使用するカラムのインデックスに影響があります影響を受けるテーブルは、MySQL 5.1.29 では
CHECK TABLE ... FOR UPGRADE
で検出できます (Bug #39585 を参照してください)。