次のセクションにあるすべての項目を読み、いずれかの項目がアプリケーションに影響を及ぼすかどうか確認します。

既知の問題または非互換の変更というマークが付いている変更に特に注意してください。以前のバージョンの MySQL との互換性がないこれらの変更では、アップグレードする前に注意を払う必要があることがあります。弊社の目的はそれらの変更を避けることですが、各リリースの間の非適合性よりもさらに深刻な問題を修正するために必要である場合もあります。使用しているインストールに当てはまるアップグレードの問題に、特別な処置を必要とする互換性の欠如が関係している場合は、互換性の欠如の説明にある手順に従ってください。これには、テーブルのダンプとリロード、あるいは CHECK TABLE や REPAIR TABLE などのステートメントの使用が含まれる場合があります。

ダンプとリロードの手順については、セクション2.11.4「テーブルまたはインデックスの再作成または修復」を参照してください。USE_FRM オプションを使う REPAIR TABLE に関係する手順は、アップグレードの前に実行する必要があります。テーブルの作成に使用したものとは異なるバージョンの MySQL でこのステートメントを使用すると (つまり、アップグレード後にこのステートメントを使用すると)、テーブルが破損することがあります。セクション13.7.2.5「REPAIR TABLE 構文」を参照してください。

新しいバージョンの MySQL にアップグレードする前に、現在使用している MySQL のバージョンとアップグレードするバージョンとの間でテーブルの形式または文字セットまたは照合順序に変更があったかどうかを、セクション2.11.3「テーブルまたはインデックスの再構築が必要かどうかのチェック」で確認してください。その場合、それらの変更により MySQL バージョン間に互換性の欠如が生じている場合は、セクション2.11.4「テーブルまたはインデックスの再作成または修復」の手順を使用して影響されるテーブルをアップグレードすることが必要になります。

MySQL の新しいバージョンにアップグレードしたら、mysql_upgrade を実行します (セクション4.4.7「mysql_upgrade — MySQL テーブルのチェックとアップグレード」を参照してください)。このプログラムはテーブルを確認し、必要に応じて修復を試みます。また、付与テーブルを更新して最新の構造を持つようにし、新しい機能を活用できるようにします。(MySQL のリリースの中には、新たに権限や機能を加えるために付与テーブルの構造に変更を加えているものもあります。)

mysql_upgrade では、ヘルプテーブルの内容はアップグレードされません。アップグレードの手順については、セクション5.1.10「サーバー側のヘルプ」を参照してください。

MySQL Server を Windows 上で使用する場合は、セクション2.3.7「Windows 上の MySQL をアップグレードする」を参照してください。

レプリケーションを使用する場合は、レプリケーションのセットアップのアップグレードについてセクション17.4.3「レプリケーションセットアップをアップグレードする」を参照してください。

MySQL 5.6.6 以降では、MySQL Server のいくつかのパラメータのデフォルト値が、前のリリースと異なっています。これらの変更の目的は、初期設定のままで優れたパフォーマンスを提供し、データベース管理者が設定を手動で変更する必要性を低下させることです。これらの変更は、フィードバックの取得に伴い将来のリリースでのリビジョンにつながる場合があります。

パラメータが異なる静的なデフォルト値を持つ場合もあります。あるいは、静的な値を使用するのではなく、ほかの関連するパラメータやサーバーホスト構成に基づく公式を使用して、サーバーが起動時にパラメータを自動サイズ設定する場合もあります。たとえば、back_log の現在の設定は、以前のデフォルトの 50 で、max_connections の値に比例する量に応じて上方に調整されます。自動サイズ設定の背後には、固定値よりも適切だと思われるパラメータ設定について、決定を下すために利用できる情報をサーバーが持つ場合、その決定を下すという考え方があります。

次の表は、デフォルトへの変更を要約したものです。これらはすべて、サーバー起動時に明示的な値を指定することによってオーバーライドできます。

以前のリリースとの互換性に関して、もっとも重要な変更は:

したがって、既存の MySQL インストールからアップグレードする場合で、これらのパラメータの値を以前のデフォルトからまだ変更しておらず、後方互換性が懸念事項である場合は、これらを以前のデフォルト値に明示的にセットするとよいでしょう。たとえば、サーバーのオプションファイルに次の行を挿入します。

Press CTRL+C to copy
 
[mysqld]
innodb_file_per_table=0
innodb_checksum_algorithm=INNODB
binlog_checksum=NONE

これらの設定により、互換性が次のように維持されます。

MySQL 5.6.5 では、4.1 より前のパスワードと mysql_old_password 認証プラグインは非推奨です。MySQL 4.1 より前で使用される古いハッシュ形式で格納されているパスワードは、ネイティブのパスワードハッシュ方式を使用するパスワードよりもセキュアでないため、使用しないようにしてください。4.1 より前のパスワードハッシュを持つアカウントを使用して接続することを防ぐために、secure_auth システム変数はデフォルトで有効になりました。(このようなパスワードハッシュを持つアカウントに対して接続を許可するには、--secure_auth=0 を使用してサーバーを起動してください。)

データベース管理者は、mysql_old_password 認証プラグインを使用するアカウントを、代わりに mysql_native_password を使用するように変換することが推奨されます。アカウントのアップグレード手順については、セクション6.3.8.3「4.1 よりも前のパスワードハッシュ方式と mysql_old_password プラグインからの移行」を参照してください。

既知の問題: MySQL 5.6 の以前の開発バージョンの一部 (5.6.6 から 5.6.10) では、サーバーが、パスワードハッシュと認証プラグインが一致しないアカウントを作成することがあります。たとえば、デフォルトの認証プラグインが mysql_native_password の場合、次のステートメントのシーケンスにより、プラグインが mysql_native_password だが、4.1 より前のパスワードハッシュ (mysql_old_password で使用される形式) であるアカウントになります。

Press CTRL+C to copy
 
SET old_passwords = 1;
CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'mypass';

この不一致により、MySQL Server に接続できない、SET PASSWORD を OLD_PASSWORD() または old_passwords=1 で使用できない、などの現象が発生します。

MySQL 5.6.11 では、この不一致は発生しなくなりました。代わりに、サーバーがエラーを生成します。

Press CTRL+C to copy
 
mysql> SET old_passwords = 1;
mysql> CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'mypass';
ERROR 1827 (HY000): The password hash doesn't have the expected
format. Check if the correct password algorithm is being used with
the PASSWORD() function.

不一致の影響を受けているアカウントを処理するには、データベース管理者はそのアカウントの mysql.user テーブルの行の plugin カラムまたは Password カラムを、ほかのカラムと一致するように修正できます。

互換性のない変更: あるカラムの DEFAULT 値が、テーブル作成時の sql_mode 値に対しては有効だが、行の挿入または更新を行うときの sql_mode 値に対しては無効であるということが起こり得ます。例:

Press CTRL+C to copy
 
SET sql_mode = '';
CREATE TABLE t (d DATE DEFAULT 0);
SET sql_mode = 'NO_ZERO_DATE,STRICT_ALL_TABLES';
INSERT INTO t (d) VALUES(DEFAULT);

この場合、0 は CREATE TABLE に対しては受け入れられるべきですが、INSERT に対しては受け入れられるべきではありません。しかし、サーバーは挿入または更新時の DEFAULT 値を現在の sql_mode に対して評価しませんでした。この例では、INSERT は成功し、'0000-00-00' を DATE カラムに挿入します。

MySQL 5.6.13 では、サーバーは適切な sql_mode チェックを適用して、挿入時または更新時に警告またはエラーを生成します。

その結果、ステートメントベースのロギング (binlog_format=STATEMENT) を使用している場合に、レプリケーションに関する非互換性が生じます。スレーブがアップグレードされた場合、アップグレードされていないマスターが次の例をエラーなしで実行しますが、INSERT はスレーブで失敗し、レプリケーションは停止します。

これに対処するには、マスター上のすべての新しいステートメントを停止し、スレーブが追い付くのを待ちます。そのあと、スレーブに続いてマスターをアップグレードします。あるいは、新しいステートメントを停止できない場合は、マスターで一時的に行ベースのロギングに変更し (binlog_format=ROW)、すべてのスレーブが、この変更の時点までに生成されたすべてのバイナリログを処理するまで待ちます。そのあと、スレーブに続いてマスターをアップグレードし、マスターをステートメントベースのロギングに戻します。

互換性のない変更: MySQL 5.6.11 以降では、CREATE TABLE ... [SUB]PARTITION BY ALGORITHM=n [LINEAR] KEY (...) をサポートします。これは、KEY のパーティション化が MySQL 5.1 Server と互換性を持つテーブルを作成するのに使用できます (n=1)。(Bug #14521864、Bug #66462) この構文は MySQL 5.5.31 以降の MySQL 5.5 ではサポートされていますが、MySQL 5.6.10 以前では受け入れられません。MySQL 5.5.31 以降の MySQL 5.5 リリースの mysqldump には、このオプションを使用してテーブルをダンプするときに ALGORITHM オプションが含まれますが、次のように条件コメントで囲みます。

Press CTRL+C to copy
 
CREATE TABLE t1 (a INT)
/*!50100 PARTITION BY KEY */ /*!50531 ALGORITHM = 1 */ /*!50100 ()
      PARTITIONS 3 */

このような CREATE TABLE ステートメントを含むダンプを MySQL 5.6.10 以前の MySQL 5.6 Server にインポートする場合、バージョン付きコメントは無視されず構文エラーが発生します。したがって、このようなダンプファイルをインポートする前に、MySQL 5.6 Server がコメントを無視するように変更するか (文字列 !50531 が出現するたびにそれを削除するか、!50611 に置換することによって)、あるいは削除します。

これは、MySQL 5.6.11 以降を使用して作成されたダンプファイルでは問題になりません。ここでは ALGORITHM オプションは /*!50611 ... */ を使用して書き込まれています。

互換性のない変更: TIME、DATETIME、および TIMESTAMP カラムについては、MySQL 5.6.4 より前に作成されたテーブルに必要なストレージは、5.6.4 以降で作成されたテーブルに必要なストレージとは異なります。これは、5.6.4 で、これらの時間型が少数部を持つことを許可するように変更されたためです。MySQL 5.5 から MySQL 5.6.4 以降にアップグレードしたあと、MySQL 5.5 から MySQL 5.6 の TIME、DATETIME、および TIMESTAMP 型にもアップグレードすることを推奨します。ALTER TABLE は現在、MySQL 5.5 および MySQL 5.6.4 (以降) のバイナリ形式の時間カラムを含むテーブルの作成を許可しますが、このため、.frm ファイルが利用できない場合にテーブルを再作成するのがより困難になります。さらに、MySQL 5.6.4 では、前述の時間型はスペース効率が改善されています。MySQL 5.6.4 での時間型の変更の詳細は、Storage Requirements for Date and Time Typesを参照してください。

MySQL 5.6.16 では、ALTER TABLE は、ADD COLUMN、CHANGE COLUMN、MODIFY COLUMN、ADD INDEX、および FORCE 操作に関して、古い時間カラムを 5.6 形式にアップグレードします。したがって、次のステートメントは、古い形式のカラムを含むテーブルをアップグレードします。

Press CTRL+C to copy
 
ALTER TABLE tbl_name FORCE;

テーブルを再構築しなければならないため、この変換は INPLACE アルゴリズムを使用して実行することはできません。そのため、これらの場合に ALGORITHM=INPLACE を指定するとエラーになります。必要であれば、ALGORITHM=COPY を指定します。

ALTER TABLE は、時間形式の変換を実行しない場合には、SHOW WARNINGS: TIME/TIMESTAMP/DATETIME columns of old format have been upgraded to the new format で表示できるメッセージを生成します。

前記の互換性のない変更で説明した時間型の変更のため、DATETIME 型および TIMESTAMP 型を含む、MySQL 5.6.4 より前のテーブルを MySQL 5.6.4 (以降) にインポートすると失敗します。これらの時間型を持つ MySQL 5.5 テーブルを MySQL 5.6.4 (以降) にインポートする場合が、この問題が発生する可能性がもっとも高いシナリオです。

次の手順では、元の MySQL 5.6.4 より前の .frm ファイルを使用して、5.6.4 (以降) と互換性のある行構造を持つテーブルを再作成する回避策について説明します。この手順には、.frm ファイルを目的のインスタンスのデータディレクトリにコピーし、ALTER TABLE を使用してテーブルのストレージエンジンタイプを InnoDB に戻すことで、MySQL 5.6.4 より前の元の .frm ファイルを、InnoDB の代わりに Memory ストレージエンジンを使用するように変更することが含まれます。テーブルに外部キーがない場合は最初の手順を使用します。テーブルに外部キーが含まれる場合は、追加の手順を含む 2 番目の手順を使用します。

テーブルに外部キーがない場合:

テーブルに外部キーがある場合:

互換性のない変更: MySQL 5.6 では、character_set_server が ucs2、utf16、utf16le、または utf32 の場合、全文ストップワードファイルがロードされ、latin1 を使用して検索されます。サーバーの文字セットが ucs2、utf16、utf16le、または utf32 である間に、FULLTEXT インデックスを持つテーブルが作成された場合は、次のステートメントを使用して修復してください。

Press CTRL+C to copy
 
REPAIR TABLE tbl_name QUICK;

互換性のない変更: MySQL 5.6.20 では、Bug #69477 に対するパッチにより、BLOB で書き込まれる Redo ログのサイズが Redo ログファイルサイズの 10% に制限されます。この新しい制限の結果として、innodb_log_file_size は、テーブルの行で見つかった最大の BLOB データサイズの 10 倍よりも大きい値に設定するべきです。innodb_log_file_size 設定がすでに、最大の BLOB データサイズの 10 倍になっているか、テーブルに BLOB データが含まれない場合は、アクションは不要です。

MySQL 5.6.22 では、Redo ログ BLOB の書き込み制限は 合計 Redo ログサイズ (innodb_log_file_size * innodb_log_files_in_group) の 10% に緩められました。(Bug #19498877)

MySQL 5.5 では予約されていなかった一部のキーワードが、MySQL 5.6 では予約されている場合があります。セクション9.3「予約語」を参照してください。

YEAR(2) データ型には、使用する前に考慮する必要のある特定の問題があります。MySQL 5.6.6 以降、YEAR(2) は非推奨です。既存のテーブル内の YEAR(2) カラムは以前のとおりに扱われますが、新規または変更したテーブルでは YEAR(2) は YEAR(4) に変換されます。詳細は、セクション11.3.4「YEAR(2) の制限と YEAR(4) への移行」を参照してください。

MySQL 5.6.6 では、値 DEFAULT をストアドプロシージャーまたはストアドファンクションのパラメータや、ストアドプログラムのローカル変数に割り当てることは (SET var_name = DEFAULT ステートメント)、明示的に不許可です。これは、以前にはサポートされておらず、許可されるという説明もありませんでしたが、何らかの都合で既存のコードでこの構造が使用されていた場合のために、互換性のない変更としてフラグが付けられました。システム変数に DEFAULT を割り当てることは以前と同様に許可されますが、DEFAULT をパラメータやローカル変数に割り当てると、構文エラーになります。

MySQL 5.6.6 以降へのアップグレード後、この構造を使用する既存のストアドプログラムが起動されると、構文エラーになります。5.6.5 以前の mysqldump ファイルが 5.6.6 以降にロードされると、ロード操作は失敗し、影響を受けるストアドプログラム定義を変更する必要があります。

MySQL では、TIMESTAMP データ型は非標準的な方式であるという点でほかのデータ型と異なります。

これらの非標準の動作は TIMESTAMP についてはデフォルトのままですが、MySQL 5.6.6 以降では非推奨となり、起動時に次の警告が表示されます。

Press CTRL+C to copy
 
[Warning] TIMESTAMP with implicit DEFAULT value is deprecated.
Please use --explicit_defaults_for_timestamp server option (see
documentation for more details).

警告が示すように、非標準の動作をオフにするには、新しい explicit_defaults_for_timestamp システム変数を起動時に有効にします。この変数を有効にすると、サーバーは TIMESTAMP を、代わりに次のように処理します。

レプリケーションに使用されるサーバーをアップグレードする場合は、まずスレーブをアップグレードしてからマスターをアップグレードします。マスターとそのスレーブとの間のレプリケーションは、すべてが explicit_defaults_for_timestamp の同じ値を使用しているという条件で、機能するはずです。