Skip navigation links
2.12.2 MySQL のダウングレード »
Section Navigation      [Toggle]

2.12.1.1. MySQL 5.0 から 5.1 へのアップグレード

5.0 のインストールから 5.0.10 以降にアップグレードしたあとで、権限テーブルをアップグレードする必要があります。アップグレードしなかった場合、保持したプロシージャーおよび機能を作成しても機能しません。このアップグレードを実行するには、mysql_upgrade を実行します。

注意

新しいバージョンのソフトウェアをインストールする前にデータのバックアップを必ず励行してください。MySQL が高品質の維持に努めたにしても、デバックアップを取ってデータを守るのはお客様ご自信です。

前のバージョンから 5.1 にアップグレードするときに、アップグレードの前に mysqldump を使ってテーブルをダンプし、アップグレード後にダンプファイルを再度読み込むように MySQL から勧められます。

一般に、MySQL 5.0 から 5.1 にアップグレードするときに、次のことを行うようにしてください。

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

    • 項2.12.1. 「MySQL のアップグレード」 に、更新に関する一般的な情報があります。

    • この節のあとのほうにある変更リストの項目によって、現在の MySQL インストールに適用されるアップグレードの問題を識別できます。

    • MySQL 5.1 の変更履歴では、5.1 で使用できる重要な新機能、または MySQL 5.0 にあった機能とは異なる機能について説明しています。これらの変更の一部には互換性がない場合があります。Changes in Release 5.1.x (Production) を参照してください。

  • 既知の問題または非互換の変更というマークが付いている変更に特に注意してください。以前のバージョンの MySQL との互換性がないこれらの変更では、アップグレードする前に注意を払う必要があることがあります。

    私たちの目的はそれらの変更を避けることですが、時として各リリースの間に、非適合性よりもさらに深刻である問題を修正することの方が大切なこともあります。自分のインストールに当てはまるアップグレードの問題に特別な処置を必要とする互換性の欠如が関係している場合は、互換性の欠如の説明にある手順に従ってください。これにはよくダンプと再読み込み、または CHECK TABLE や REPAIR TABLE などのステートメントの使用が関係してきます。

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

  • 新しいバージョンの MySQL にアップグレードしたあとで、mysql_upgrade を実行します (mysql_upgrade を参照)。このプログラムはテーブルを確認し、必要に応じて修復を試みます。また、権限テーブルを更新して現在の構造を持つようにし、新しい機能を活用できるようにします。(MySQL のリリースの中には新たに権限や機能を加えるために権限テーブルの構成に変更を加えているものもあります。)

  • 項2.12.3. 「テーブルインデックスを再作成する必要があるかどうかの確認」 を確認して、テーブルインデックスに影響する、キャラクタセットまたは照合の変更が行われたかどうか確認します。変更が行われた場合は、項2.12.4. 「テーブルまたはインデックスの再作成または修復」 の手順を使用して、影響を受けたインデックスを再作成する必要があります。

  • Windows 上で MySQL サーバーを稼働している場合には、項2.3.14. 「Windows を使用した MySQL をアップグレードする」 を参照してください。

  • レプリケーションを使用している場合、レプリケーション設定のアップグレードに関する情報、Upgrading a Replication Setupにあります。

MySQL インストールにインプレースアップグレード後のコンバートに長い時間がかかることがある大量のデータが含まれている場合は、必要な変換とその実行に関係する作業を評価するための「仮の」データベースインスタンスを作成すると役立つことがあります。mysql データベースとデータのないその他のすべてのデータベースの完全なコピーを含む MySQL インスタンスのコピーを作成します。この仮のインスタンスでアップグレードの手順を実行し、必要になる操作を確認して、元のデータベースインスタンスで実際のデータ変換を実行するときに関係する作業をよりよく評価できるようにします。

次のリストでは、アプリケーションに影響を及ぼす可能性があり、MySQL 5.1 にアップグレードするときに注意を要する変更について説明します。

設定の変更:

  • MySQL 5.1.11 以前で MySQL をソースから SSL サポート付きでビルドする場合、configure を --with-openssl あるいは --with-yassl オプションのいずれかで実行します。MySQL 5.1.11 では、それらのオプションは両方とも --with-ssl オプションで置き換えられています。デフォルトで、--with-ssl でバンドルした yaSSL ライブラリを使用できます。OpenSSL を選択するには、オプションを --with-ssl=path として与え、そこでは path はディレクトリで OpenSSL のヘッダーファイルおよびライブラリが格納されています。

サーバーの変更:

  • 既知の問題: アップグレードの前にダンプファイルを生成し、アップグレード後にそのファイルを再度読み込むために mysqldump を使って実行するダンプには、次の問題があります。

    MySQL 5.0.40 より前では、mysqldump は、インデックスを設定したカラムの接頭辞長を使って SPATIAL インデックス定義を表示します。この接頭辞長は MySQL 5.0 では受け入れられますが、MySQL 5.1 では受け入れられません。5.0.40 より古いバージョンの MySQL の mysqldump を使用する場合、SPATIAL インデックスを含むテーブルは、ダンプファイルを MySQL 5.1 以降に再度読み込むときにエラーの原因になります。

    たとえば、あるテーブル定義が、MySQL 5.0 でダンプしたときに次のようになっているとします。 

    CREATE TABLE `t` (
 `g` geometry NOT NULL,
 SPATIAL KEY `g` (`g`(32))
) ENGINE=MyISAM DEFAULT CHARSET=latin1

    SPATIAL インデックス定義は、MySQL 5.1 では受け入れられません。これを回避するには、ダンプファイルを編集して接頭辞を削除します。 

    CREATE TABLE `t` (
 `g` geometry NOT NULL,
 SPATIAL KEY `g` (`g`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

    ダンプファイルは大きくなることがあるので、テーブル定義とデータを別々にダンプして定義の編集を簡単にすることをお勧めします。 

    shell> mysqldump --no-data other_args > definitions.sql
shell> mysqldump --no-create-info other_args > data.sql

    次に、definitions.sql と data.sql をこの順に再度読み込む前に、definitions.sql を編集します。

    MySQL 5.1 にアップグレードする前に 5.0.40 以降の MySQL 5.0 のバージョンにアップグレードする場合、この問題は起こりません。

  • 既知の問題: MySQL 5.1.30 より前では、CHECK TABLE ... FOR UPGRADE ステートメントは、MySQL 5.1.24 で行われた互換性のない照合の変更を確認しませんでした。(これは、そのステートメントを実行させる mysqlcheck および mysql_upgrade にも影響します。)

    5.1.30 で行われた修正より前では、バイナリアップグレード (アップグレードとアップグレード後のダンプファイルの再読み込みの前に mysqldump を使ってダンプテーブルなしで実行します) によってテーブルが壊れました。修正後は、CHECK TABLE ... FOR UPGRADE は問題を正しく検出し、修復が必要なテーブルについて警告を行います。

    ただし、この修正には後方互換性がないので、次の状況下ではダウングレードの問題が発生する可能性があります。

    1. この修正を含む MySQL のバージョンにバイナリアップグレードを実行する。

    2. CHECK TABLE ... FOR UPGRADE (または mysqlcheck または mysql_upgrade) を実行してテーブルをアップグレードする。

    3. この修正を含まない MySQL のバージョンにバイナリダウンロードを実行する。

    解決方法は、ダウングレードとダウングレード後のダンプファイルの再読み込みの前に mysqldump を使ってテーブルをダンプすることです。または、影響を受けたインデックスを削除して再作成します。

  • 既知の問題: MySQL では、ASCII 以外のキャラクタがあるテーブル名のエンコーディングを導入しています (項5.2.3. 「識別子からファイル名へのマッピング」 を参照)。MySQL 5.0 から 5.1 以降へのバイナリアップグレード後は、サーバーは ASCII 以外のキャラクタがある名前を認識し、#mysql50# 接頭辞をその名前に追加します。

    MySQL 5.1.31 では、mysql_upgrade は、次のコマンドを実行してそれらの名前をエンコードします。 

    mysqlcheck --all-databases --check-upgrade --fix-db-names --fix-table-names

    MySQL 5.1.31 より前では、mysql_upgrade はこのコマンドを実行しないため、英数字以外のキャラクタを含むデータベース名またはテーブル名がある場合は、このコマンドを手動で実行するようにしてください。

    MySQL 5.1.23 より前では、mysqlcheck コマンドは、表示のための名前のエンコーディングを実行しません。この問題を回避するには、影響を受ける各表示を削除して再作成します。

    mysqlcheck は、特殊なキャラクタのエンコーディングに使用する @ キャラクタのリテラルインスタンスを含む名前を修正できません。このキャラクタを含むデータベースまたはテーブルがある場合は、MySQL 5.1 にアップグレードする前に mysqldump を使用してダンプしてから、アップグレード後にダンプファイルを再度読み込みます。

  • 既存の問題: MySQL 5.0 から 5.1.23 より前の 5.1 のバージョンにアップグレードするときに、mysqlcheck (または mysqlcheck を実行する mysql_upgrade) の実行によるテーブルのアップグレードが引用符付きの識別子として記述する必要のある名前で失敗します。この問題を回避するには、影響を受ける各テーブルの名前を、引用符を必要としない名前に変更します。 

    RENAME TABLE `tab``le_a` TO table_a;
RENAME TABLE `table b` TO table_b;

    テーブルの名前を変更したあとで、mysql_upgrade プログラムを実行します。次に、テーブルの名前を元の名前に戻します。 

    RENAME TABLE table_a TO `tab``le_a`;
RENAME TABLE table_b TO `table b`;

  • 既知の問題: ビューの作成に関連して、サーバーは arc ディレクトリをデータベースディレクトリ内に作成し、.frm ファイルの無用なコピーをその場所に維持しました。それらのコピーの作成と名前の変更の手順、および arc ディレクトリの作成は、MySQL 5.1.29 で中断されました。

    この変更は、古いサーバーバージョンにダウングレードするときに、次の状況下で明らかになる問題の原因になります。

    1. MySQL 5.1.29 以降でビュー v_orig を作成する。

    2. ビューの名前を v_new に変更してから、v_orig に戻す。

    3. 古い 5.1.x サーバーにダウングレードし、mysql_upgrade を実行する。

    4. v_orig の名前を再度 v_new に変更しようとする。この操作は失敗します。

    この問題の回避方法として、次のいずれかの方法を使用します。

    • ダウングレードとダウングレード後のダンプファイルの再読み込みの前に、mysqldump を使ってデータをダンプします。

    • ダウングレード後にビューの名前を変更する代わりに、ビューを削除して再作成します。

  • 非互換の変更: テーブルインデックスを再作成する必要がある場合があるキャラクタセットまたは照合の変更が、MySQL 5.1.21、5.1.23、および 5.1.24 で行われました。詳細については、項2.12.3. 「テーブルインデックスを再作成する必要があるかどうかの確認」をご参照ください。

  • 非互換の変更: MySQL 5.1 の実装ではランタイム時のコンポーネントのローディングおよびアンローディングをサーバーの起動なしで行うプラグイン API をサポートしています。The MySQL Plugin API。プラグイン API には mysql.plugin テーブルが必要です。MySQL の旧バージョンからアップグレードしたあとで、mysql_upgrade コマンドを実行してこのテーブルを作成するようにしてください。mysql_upgrade を参照してください。

    プラグインは plugin_dir システム変数で指定されたディレクトリにインストールされます。この変数はまたサーバーがユーザー定義関数 (UDF) をロードするロケーションを管理し、この点が MySQL の旧バージョンから変更になっています。つまり、すべての UDF ライブラリファイルは現在はプラグインのディレクトリにインストールする必要があります。MySQL の旧バージョンからアップグレードする際、UDF ファイルをプラグインのディレクトリに移行する必要があります。

  • 非互換の変更:table_cache システムの変数は table_open_cache に名前が変わっています。table_cache を参照するすべてのスクリプトは新しい名前を使用できるように更新する必要があります。

  • 非互換の変更: MySQL 5.1.36 で、プラグイン可能なストレージエンジンなどのプラグインを読み込むためのオプションが、ブール型から tristate 形式に変更されました。実装がオーバーラップしていますが、以前に形式 --plugin_name=0 または --plugin_name=1 のオプションを使用した場合は、代わりにそれぞれ --plugin_name=OFF または --plugin_name=ON を使用するようにしてください。詳細については、Server Options for Loading Pluginsをご参照ください。

  • 非互換の変更: MySQL 5.1.24 から 5.1.31 まで、UPDATE ステートメントが変更され、NULL を NOT NULL カラムに割り当てると厳密な SQL モードが有効になっていないときでもエラーが発生しました。MySQL 5.1.24 より前の元の動作では、厳密な SQL モードでのみそのような割り当てによってエラーが発生し、厳密な SQL モードでない場合はカラムがカラムデータ型の暗黙のデフォルト値に設定され、警告が生成されました。(暗黙のデフォルト値については、項6.1.4. 「データ型デフォルト値」 を参照してください。)

    この変更は、元の動作に依存するアプリケーションで互換性の問題の原因になりました。また、厳密な SQL モードを有効にしないで UPDATE ステートメントで NULL を NOT NULL カラムに割り当てるアプリケーションでは、元の動作のサーバーとそうでないサーバーとの間でレプリケーションの問題の原因にもなりました。この変更は MySQL 5.1.32 で元に戻され、UPDATE は再び元の動作になりました。それでも、変更された UPDATE 動作のサーバーとそうでないサーバーとの間で複製する場合は問題が起こることがあります。

  • 非互換の変更: MySQL 5.1.29 では、MySQL 5.0 との互換性を確保するため、デフォルトのバイナリログモードが MIXED から STATEMENT に変更されました。

  • 非互換の変更: MySQL 5.1.25 で、サーバーが準備済みステートメントを処理する方法に変更が加えられました。これは、SQL レベルで処理される準備済みステートメント (PREPARE ステートメントを使用します) と、バイナリのクライアント/サーバープロトコルを使って処理される準備済みステートメント (mysql_stmt_prepare() C API 関数を使用します) に影響します。

    以前は、準備済みステートメントで参照されるテーブルまたはビューのメタデータの変更は、ステートメントが次に実行されるときにサーバークラッシュの原因になるか、実行時にエラーが発生し、あとでクラッシュが起こる原因になることがありました。たとえば、テーブルを削除し、別の定義を使ってそのテーブルを再作成したあとにこれが起こることがありました。

    今では、準備済みステートメントが参照するテーブルまたはビューのメタデータ変更は検出され、ステートメントが次に実行されるときにステートメントが自動的に再準備されます。メタデータ変更は、テーブルの作成、削除、変更、名前変更、切り捨てを行ったり、テーブルの分析、最適化、修復を行ったりするような DDL ステートメントで行われます。再準備は、参照されるテーブルまたはビューがテーブル定義キャッシュからフラッシュされたあとにも、キャッシュに新しいエントリの領域を作るために暗黙的に、または FLUSH TABLES に従って明示的に行われます。

    再準備は自動的に行われますが、その程度に応じて準備済みステートメントのパフォーマンスは低下します。

    テーブルの内容の変更 (たとえば、INSERT または UPDATE を使用します) も、SELECT ステートメントも、再準備の原因にはなりません。

    前のバージョンの MySQL と互換性がないということは、準備済みステートメントが実行ごとに異なるカラムセットまたは異なるカラム型を返す場合があるということです。たとえば、準備済みステートメントが SELECT * FROM t1 である場合は、t1 を変更して別のカラム番号を含めると、次の実行では前の実行と異なるカラム番号が返されます。

    古いバージョンのクライアントライブラリでは、この動作の変更を処理できません。新しいサーバーで準備済みステートメントを使用するアプリケーションでは、新しいクライアントライブラリにアップグレードすることを強くお勧めします。

    ステートメントの再準備に対するこの変更に伴い、table_definition_cache システム変数のデフォルト値が 128 から 256 に増やされました。この増加の目的は、準備済みステートメントが、新しいエントリの領域を作るために、参照されるテーブルまたはビューがキャッシュからフラッシュされることに起因する再準備を必要とする可能性を少なくすることです。

    再準備の数を追跡する新しいステータス変数 Com_stmt_reprepare が導入されました。

  • 非互換の変更: MySQL 5.1.23 では、ストアドルーチン内で、SHOW または DESCRIBE ステートメントのカーソルの宣言は許可されなくなりました。一部のインスタンスではこの宣言が偶然機能することがありましたが、もうサポートされていません。多くの場合、この変更の回避方法は、カーソルで SELECT クエリーを使用して、SHOW ステートメントと同じ情報を生成する INFORMATION_SCHEMA テーブルから読み取ることです。

  • 非互換の変更: SHOW CREATE VIEW は、カラムごとに AS alias_name 節を使用してビュー定義を表示します。式からカラムを作成する場合、デフォルトのエイリアスは式テキストになり、かなり長くなることがあります。MySQL 5.1.23 では、CREATE VIEW ステートメントのカラム名のエイリアスは、64 文字の最大カラム長 (256 文字の最大エイリアス長ではありません) に対して確認されます。その結果、いずれかのカラムエイリアスが 64 を超えた場合、SHOW CREATE VIEW の出力から作成されたビューは失敗します。これは、レプリケーションまたはダンプファイルの読み込みで問題の原因になることがあります。追加情報と回避方法については、Restrictions on Views を参照してください。

  • 非互換の変更: 格納されたプログラム (ストアドプロシージャーとストアドファンクション、トリガー、およびイベント) と ASCII 以外のシンボルを含むビューで、いくつかの問題が識別されました。これらの問題には、これらのオブジェクトを格納されたフォーマットとの間で変換するときの不完全なキャラクタセット情報に起因する変換エラーが関係していました。

    これらの問題を扱うために、これらのオブジェクトの表現が MySQL 5.1.21 で変更されました。ただし、この修正は、格納されたすべてのプログラムとビューに影響します。(たとえば、「作成のコンテキストがない」ことに関する警告が表示されます。) 5.1.21 より前のリリースの古い定義の使用に関するサーバーからの警告を回避するには、5.1.21 以降にアップグレードしたあとで、格納されたプログラムとビューを mysqldump を使ってダンプしてから再度読み込み、新しい定義で再作成するようにしてください。元々オブジェクトを定義したときに定義に使用した ASCII 以外のキャラクタセットに名前を付ける --default-character-set オプションを使って mysqldump を呼び出します。

  • 非互換の変更: MySQL 5.1.20 では、mysqld_safe は、logger コマンドをサポートするシステムで syslog へのエラーログをサポートしています。--log-error オプションの代わりに新しい --syslog および --skip-syslog オプションを使用して、ログの動作を制御できます。mysqld_safe にその説明があります。

    5.1.21 以降、デフォルトは --skip-syslog で、5.1.20 より前のリリースでエラーログファイルを記述するデフォルトの動作と互換性があります。

    5.1.20 のみ、次の条件が適用されます。: 1) デフォルトは syslog の使用です。これは、5.1.20 より前のリリースと互換性がありません。2) 場合によっては、syslog へのログ記録が正しく行われないことがあります。これらの理由により、MySQL 5.1.20 の使用は避けてください。

  • 非互換の変更: MySQL 5.1.18 では、プラグインインタフェースとプラグインインタフェースによるシステム変数の処理が変更されました。InnoDB が組み込まれていない場合、またはプラグインとして読み込まれていない場合、--skip-innodb などのコマンドラインオプションはエラーの原因になるようになりました。InnoDB が使用できない場合でもエラーにならないようにする場合は、--loose-skip-innodb を使用するようにしてください。プラグインが存在するかどうかわからない場合、およびプラグインがないためにオプションが必ず無視されても操作を続ける場合は、すべてのコマンドラインオプションで --loose 接頭辞修飾子を使用するようにしてください。(--loose の動作方法に関する説明については、Using Options on the Command Line を参照してください。)

  • 非互換の変更: MySQL 5.1.15 では、InnoDB はトランザクションタイムアウト時に最後のステートメントだけをロールバックします。トランザクションタイムアウトが発生した場合、新しいオプションの --innodb_rollback_on_timeout は、InnoDB がトランザクション全体を中断してロールバックするようにします (MySQL 4.1 の場合と同じ動作です)。

  • 非互換の変更:MySQL 5.1.15 では、以下の条件を read_only システム変数を有効にするために適用します。

    • read_only を明示のロック (LOCK TABLES で取得) 中に有効にしようとしたりあるいは未処理のトランザクションがある場合、エラーが発生します。

    • ほかのクライアントが明示のテーブルロックを掛けていたり未処理のトランザクションがある場合、read_only の有効化はロックが解除されトランザクションが終了するまでブロックされます。read_only の有効化がペンディング中には、ほかのクライアントによるテーブルロックあるいはトランザクションの開始もまた read_only が設定されるまでブロックされます。

    • read_only はグローバル読み込みロック (FLUSH TABLES WITH READ LOCK で取得) 中でもそれがテーブルロックを実行しないために有効にできます。

    以前は、read_only の有効化は明示のロックあるいはトランザクションが未処理の場合でもすぐに有効になり、ステートメントのデータの変更はサーバーで同時に行われていました。

  • 非互換の変更: IGNORE_SPACE によって影響を受ける関数名の数が MySQL5.1.13 ではおよそ 200 から 30 に大幅に減少しました。(IGNORE_SPACE の詳細は、項5.2.4. 「関数名の構文解析と解決」 を参照してください。) この変更によりペーパー操作の一貫性が改善されています。ただし、次の条件に依存する旧 SQL コードの非互換性の可能性も生じます

    • IGNORE_SPACE は無効化されています。

    • ファンクション名に続く余白の有無は、同名を持つ組み込み関数と保存ファンクション (例: PI() 対 PI ()) を区別するのに用いられます。

    MySQL 5.1.13 よりあとで IGNORE_SPACE に影響を受けないファンクションに対しては、その方法は機能しません。前置の非互換性に対応するコードがある場合は、次のうちどちらのアプローチも使えます。

    • 保存ファンクションに組み込み関数とコンフリクトを引き起こす名前が存在する場合、余白の有無にかかわらず、修飾語付随のスキーマ名を持つ保存ファンクションを参照してください。たとえば、schema_name.PI() またはschema_name.PI () と書いてください。

    • または、ストアドファンクションの名前を相反しない名前に変更し、新しい名前を使用するために関数の呼び出しを変更します。

  • 非互換の変更: utf8 カラムでは、フルテキストのパーサーが幾つかの非単語の句読点および余白文字を単語文字として不正確に解釈するため、検索した場合不正確な検索結果を返す場合があります。修正には MySQL 5.1.12 のフルテキスト parser の変更が含まれ、FULLTEXT インデックスを utf8 カラムに持つテーブルは REPAIR TABLE で修正する必要があります。 

    REPAIR TABLE tbl_name QUICK;

  • 非互換の変更: ストレージエンジンが実行時にプラグイン可能であるため、使用しないストレージエンジンと無効なストレージエンジンの区別が適用されなくなりました。MySQL 5.1.12 では、これは NO_ENGINE_SUBSTITUTION SQL モードに影響します。Server SQL Modes にその説明があります。

  • 非互換の変更: FULLTEXT インデックスの構造が MySQL 5.1.6 で変更されました。MySQL 5.1.6 以降にアップグレードしたあとは、FULLTEXT インデックスのあるテーブルは REPAIR TABLE で修復する必要があります。 

    REPAIR TABLE tbl_name QUICK;

  • 非互換の変更: MySQL 5.1.6 では、ログテーブルを実装するときの、一般クエリーログおよび遅いクエリーログのデフォルトの保存先は TABLE でした。MySQL 5.1.21 では、このデフォルトは FILE に変更されました。これは MySQL 5.0 とは互換性がありますが、以前のリリースの MySQL 5.1 とは互換性がありません。MySQL 5.0 から 5.1.21 以降にアップグレードする場合、ログオプションの変更は必要ありません。ただし、5.1.6 から 5.1.20 にアップグレードし、さらに 5.1.21 以降にアップグレードする場合、TABLE のログを使用していたときは、--log-output=TABLE オプションを使用して、サーバーのテーブルログ記録の動作を明示的に保持してください。

  • 非互換の変更: コンマを含む列挙型の値がある ENUM カラムでは、コンマは内部的に 0xff にマップされました。ただし、これによりコンマは値に含まれる真の 0xff キャラクタと区別できなくなりました。このことはもう起こらなくなりました。ただし、この修正では、値に真の 0xff を含む ENUM カラムがあるテーブルをダンプして再度読み込む必要があります。5.1.15 より古いバージョンの MySQL 5.1 から 5.1.15 以降のバージョンにアップグレードする前に、現在のサーバーで mysqldump を使ってテーブルをダンプします。

  • MySQL 5.1.12 の場合、lc_time_names システム変数は日付および省略文字の記載に使用される言語を管理するロケールを指定します。この変数は DATE_FORMAT()、DAYNAME() および MONTHNAME() 関数の出力に影響を与えます。MySQL Server Locale Support を参照してください。

  • MySQL 5.1.9 では、mysqld_safe はもはや黙示的に mysqld-max をそれが存在した場合でも呼び出しません。代わりに、それは --mysqld あるいは --mysqld-version オプションがほかのサーバーを明示的に指定しないかぎり mysql を呼び出します。これまで黙示的に mysqld-max の呼び出しを使用していた場合、これからは適切なオプションを使用する必要があります。MySQL 5.1.12 では、別個の mysqld-max サーバーはなくなったため、変更は必要ありません。

SQL の変更:

  • 既知の問題: MySQL 5.1.17 以降、パーサーが無効なコードを SQL 条件ハンドラで受け付け、これがサーバークラッシュや格納されたプログラムでの予期しない実行動作につながっていました。特に、パーサーは、条件ハンドラがハンドラ宣言を包含するブロックのラベルを参照することを許可しました。ブロックラベルのスコープにラベル付きブロック内で宣言されたハンドラのコードは含まれないため、これは不正でした。

    5.1.17 では、パーサーはこの無効な構成を拒否しますが、バイナリアップグレードを実行した場合 (データベースのダンプと再読み込みを行わずに)、その構成を含む既存のハンドラは無効なままになるので、ハンドラが予想どおりに機能しているように見えても書き換えるようにしてください。

    影響を受けるハンドラを見つけるには、mysqldump を使用して、すべてのストアドプロシージャーとストアドファンクション、トリガー、およびイベントをダンプします。次に、それらをアップグレードしたサーバーに再度読み込んでみます。不正なラベル参照を含むハンドラは拒否されます。

    条件ハンドラ、および無効なジャンプを避けるよう条件ハンドラを記述する方法については、項8.8.4.2. 「ハンドラのための DECLARE」 を参照してください。

  • 非互換の変更: パーサーは、SELECT 1 /* + 2 など、*/ で正しく閉じられていない /* ... */ を含むステートメントを受け付けました。MySQL 5.1.23 では、閉じられていない /* コメントを含むステートメントは構文エラーで拒否されるようになりました。

    この修正は、互換性の欠如の原因になる可能性があります。ビュー、ストアドルーチン、トリガー、およびイベントで末尾の */ をコメントから切り捨てる原因になった Bug#26302 のために、それらの型のオブジェクトは、今では構文が無効であるとして拒否される定義で格納される可能性があります。そのようなオブジェクトは、削除して再作成し、それらの定義に切り捨てられたコメントが含まれないようにしてください。

  • 非互換の変更: あいまいなエイリアスを含む複数テーブルの DELETE ステートメントで、間違ったテーブルから行を削除するなど、意図しない副作用が発生することがありました。例 : 

    DELETE FROM t1 AS a2 USING t1 AS a1 INNER JOIN t2 AS a2;

    MySQL 5.1.23 では、エイリアス宣言は、table_references 部分でのみ宣言できます。ステートメント内のほかの部分では、エイリアス参照は許可されますが、エイリアス宣言は許可されません。許可されなくなったエイリアスを含むステートメントは、書き換える必要があります。

  • 非互換の変更: MySQL 5.1.8 では、TYPE = engine_name は ENGINE = engine_name テーブルオプションに対してまだ類義語として受け入れられますが、警告が表示されます。このオプションは MySQL 5.1.7 では使用できず、MySQL 5.4 ではすべて削除されて、構文エラーが生成されることに注意してください。

    TYPE は MySQL 4.0 以降は使用していません。

  • 非互換の変更: トリガーの名前空間は MySQL 5.0.10 で変更されました。トリガー名は以前はテーブルごとに一意でなければなりませんでした。現在はそれらはスキーマ (データベース) ごとに一意です。この変更によって DROP TRIGGER 構文は現在テーブル名の代わりにスキーマ名を使用しています (スキーマ名はオプションで、削除された場合は現在のスキーマが使用されます)。

    5.0.10 より古いバージョンの MySQL 5 から MySQL 5.0.10 以降にアップグレードするときは、すべてのトリガーを削除して再作成しなければ DROP TRIGGER はアップグレード後は機能しなくなります。以下のその手順を示します。

    1. MySQL 5.0.10 あるいはそれ以降にアップグレードすると INFORMATION_SCHEMA.TRIGGERS テーブルでトリガー情報にアクセスできます。(これは 5.0.10 より前のトリガーでも機能するはずです。)

    2. 以下の SELECT ステートメントですべてのトリガー定義をダンプします。 

      SELECT CONCAT('CREATE TRIGGER ', t.TRIGGER_SCHEMA, '.', t.TRIGGER_NAME,
              ' ', t.ACTION_TIMING, ' ', t.EVENT_MANIPULATION, ' ON ',
              t.EVENT_OBJECT_SCHEMA, '.', t.EVENT_OBJECT_TABLE,
              ' FOR EACH ROW ', t.ACTION_STATEMENT, '//' )
INTO OUTFILE '/tmp/triggers.sql'
FROM INFORMATION_SCHEMA.TRIGGERS AS t;

      そのステートメントは INTO OUTFILE を使用していますので、FILE 権限を持つ必要があります。ファイルはサーバーホストに作成されます。必要に応じて、別のファイル名を使用します。100% 安全であるためには、トリガー定義を triggers.sql ファイルで確認し、そのファイルのバックアップを取るとよいでしょう。

    3. サーバーを停止してすべてのトリガーをすべての .TRG ファイルをデータベースのディレクトリから削除して削除します。ロケーションをデータディレクトリに変更して以下のコマンドを発行します。 

      shell> rm */*.TRG

    4. サーバーを起動し triggers.sql ファイルを使用してすべてのトリガーを再度作成します。 

      mysql> delimiter // ;
mysql> source /tmp/triggers.sql //

    5. SHOW TRIGGERS ステートメントを使用して、すべてのトリガーが正常に作成されたことを確認します。

  • 非互換の変更: MySQL 5.1.6 で TRIGGER 権限が導入されています。以前は、SUPER 権限はトリガーの作成あるいは削除に必要でした。今それらの操作には TRIGGER 権限が必要です。これやセキュリティーの改善に行われたもので、トリガーを作成するためにもはやグラントユーザーには SUPER 権限は必要ありません。しかし、トリガーの DEFINER 節で指定されたアカウントは SUPER 権限を持つという条件が TRIGGER 権限の条件に変わっています。前のバージョンの MySQL 5.0 または 5.1 から MySQL 5.1.6 以降にアップグレードするときは、mysql_upgrade を実行して必ず権限テーブルを更新してください。これにより、TRIGGER 権限を SUPER 権限を持っていたすべてのアカウントに割り当てます。グラントテーブルの更新に失敗すると、トリガーは実行に失敗する場合があります。権限テーブルの更新後、SUPER 権限をもはやそれを必要としないそれらのアカウントから取り消すことができます。

  • キーワードの幾つかが MySQL 5.1 で予約されます。それらは MySQL 5.0 では予約されなかったものです。項5.3. 「MySQL での予約語の扱い」 を参照してください。

  • LOAD DATA FROM MASTER および LOAD TABLE FROM MASTER ステートメントは今後は使用しません。推奨している代案については、項8.6.2.2. 「LOAD DATA FROM MASTER 構文」 を参照してください。

  • プラグイン API に使用される INSTALL PLUGIN および UNINSTALL PLUGIN ステートメントは新規です。同様にフルテキストインデックスの parser プラグインに関連した FULLTEXT インデックス作成用の WITH PAPER 節も新規です。The MySQL Plugin API.

C API の変更:

  • 非互換の変更:MySQL 5.1.7 では、mysql_stmt_attr_get() C API 関数は STMT_ATTR_UPDATE_MAX_LENGTH の無署名 int ではなく boolean を返します。(Bug#16144)