Skip navigation links
2.11.2 MySQL データベースの他のマシンへのコピー »
Section Navigation      [Toggle]

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

5.0 のインストールから 5.0.10 あるいはそれ以上にアップグレードするには グラント テーブルのアップグレード が必要です。アップグレードしなかった場合、保持したプロシージャおよび機能を作成しても機能しません。この手順に関する説明は、項4.5.4. 「mysql_upgrade — MySQL アップグレードのテーブル チェック」 を参照してください。

注:新しいバージョンのソフトウェアをインストールする前にデータのバックアップを必ず励行してください。MySQL が高品質の維持に努めたにしても、デバックアップを取ってデータを守るのはお客様ご自信です。MySQL AB ではテーブルをダンプして以前のバージョンからテーブルを再ロードすることをお勧めします。5.1.

一般的には、MySQL 5.0 から 5.1 にアップグレードするには以下を行う必要があります。

  • 項2.11. 「MySQL のアップグレード」 の項目をチェックし、その項目でアプリケーションに影響を及ぼすものがないか確認します。

  • この項で後述する変更リストをチェックしそれらの変更リストの一部にアプリケーションに影響を及ぼすものがないか確認します。非互換の変更 の印の付いた項目に特に注意します。これらの非互換の MySQL の以前のバージョンの結果、およびアップグレードする前 に必要な注意事項。

  • MySQL のリリースの中にはテーブルに互換性のない変更をしている場合もあります。(弊社はこれらの変更を避けるように努めていますが、時にリリース間の互換性を取るよりも深刻な問題の修正に迫られる場合があります。)MySQL の リリースの中には新たに権限や機能を加えるためにグラント テーブルの構成に変更を加えているものもあります。

    それらの変更による問題を避けるためには、MySQL の新しいバージョンにアップグレードした後に、mysql_upgrade を実行してテーブル (必要に応じて修正する) をチェックし、グラント テーブルをアップグレードして、新しい機能を利用できるようにそれらが現在の構成になっていることを確認します。項4.5.4. 「mysql_upgrade — MySQL アップグレードのテーブル チェック」 参照。

  • MySQL 5.1 の変更履歴を読んでどのような重要な新機能を 5.1 で使用できるか確認します。項C.1. 「Changes in release 5.1.x (Development)」 参照。

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

  • レプリケーションを使用している場合、レプリケーション設定のアップグレードに関する情報、項5.4.3. 「レプリケーション セットアップのアップグレード」にあります。

以下のリストはアプリケーションに影響を及ぼす可能性があり 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 のヘッダーファイルおよびライブラリが格納されています。

サーバの変更:

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

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

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

  • 非互換の変更: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 によって影響を受ける機能名が MySQL 5.1.13 ではおよそ 200 から 30 に大幅に減少しました。 (IGNORE_SPACE の詳細は、項8.2.4. 「構文解析と解像度のファンクション名」 を参照してください。)この変更によりペーパー操作の一貫性が改善されています。しかしながら、以下の条件に基づく旧 SQL コードの非互換性の可能性も加わっています。

    • IGNORE_SPACE は無効になっています。

    • 機能名に続く余白部分の存在の有無によって同名の (例えば、PI() versus PI ()) 内蔵機能および保持機能間の区別をしています。

    MySQL 5.1.13 の IGNORE_SPACE によりもはや影響を受けない機能には、その戦略は通用しません。前述の非互換に基くコードがある場合以下の手法のいずれかを使用できます。

    • 保持機能名と内蔵機能名が衝突する名前の場合、余白の有無に関係なくスキーマ名修飾語の名前のある保持機能を参照します。例えば、schema_name.PI() あるいは schema_name.PI () と書きます。

    • あるいは、保持機能の名前に衝突しない名前に変更して、機能の実行を新しい名前を使用できるように変更します。

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

    REPAIR TABLE tbl_name QUICK;

  • 非互換の変更: FULLTEXT インデックスの構成は MySQL 5.1.6 で変更になっています。MySQL 5.1.6 あるいはそれ以降にアップグレード後に、REPAIR TABLE ステートメントを FULLTEXT インデックスを含む各テーブルにコールします。

  • 非互換の変更:MySQL 5.1.6 以前では、サーバは一般的なクエリ ログを書いてログ ファイルへのクエリ ログのエントリを遅くします。MySQL 5.1.6 では、サーバのこれらのログのログ機能はさらに柔軟になっています。ログのエントリはログ ファイル (上記のように) あるいは general_log および mySQL データベースの slow_log に書き込まれます。ロギングが有効になると、ディスティネーションのいずれかまたは両方が選択されます。 --log-output オプションはディスティネーションあるいはログ出力のディスティネーションを管理します。項4.11.1. 「一般クエリとスロー クエリのログ出力先の選択」 参照。

    ロギングが有効になると、デフォルトのディスティネーションはこの段階でテーブルにログされます。この点が以前のバージョンと異なる点です。ログをログ ファイルにする設定のサーバを所持している場合には、--log-output=FILE を使用してこの振る舞いを MySQL の 5.1.6 あるいはそれ以降にアップグレードした後に保持します。

  • MySQL 5.1.12 の場合、lc_time_names システム変数は日付および省略文字の記載に使用される言語を管理するロケールを指定します。この変数は DATE_FORMAT()、DAYNAME() および MONTHNAME() 関数の出力に影響を与えます。項4.10.9. 「MySQL サーバのローケル サポート」 参照。

  • MySQL 5.1.6 では、データベースおよびテーブル識別子の特殊文字は相当するディレクトリ名およびファイル名を作成中にエンコードされます。これにより識別子として使用される文字制限が緩やかになります。項8.2.3. 「ファイル名への識別子のマッピング」 参照。mysql_upgrade を実施すると、データベース名およびテーブル名は、それらが特殊文字を含む場合、新しいフォーマットに更新されます。

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

SQL の変更:

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

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

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

    旧バージョンの 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 or 5.1 の旧バージョンから MySQL 5.1.6 あるいはそれ以上にアップグレードするには、項4.5.4. 「mysql_upgrade — MySQL アップグレードのテーブル チェック」 の説明に従ってグラント テーブルを更新する必要があります。.このプロセスにより TRIGGER 権限を SUPER 権限を持っていたすべてのアカウントに割り当てます。グラント テーブルの更新に失敗すると、トリガは実行に失敗する場合があります。(グラント テーブルの更新後、SUPER 権限をもはやそれを必要としないそれらのアカウントから取り消すことができます。）

  • 4 桁の年を表す 200 以内の日付の場合、世紀を含める黙示の変換が DATE_ADD()、DATE_SUB()、+ INTERVAL、および - INTERVAL で実行される日付の計算式に適用されています。(例えば、DATE_ADD('0050-01-01 00:00:00', INTERVAL 0 SECOND) は '2050-01-01 00:00:00' になります。)MySQL 5.1.11 では、これらの操作は不正確な非NULL 値ではなく NULL を返します。(Bug#18997)

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

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

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

C API の変更:

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