Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 27.1Mb
PDF (A4) - 27.2Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


2.11.1.3 MySQL 5.5 から 5.6 へのアップグレード

注記

MySQL 5.6.6 以降では、MySQL Server のいくつかのパラメータのデフォルト値が、前のリリースと異なっています。このセクションで後述するこれらの変更に関する注記、特に後方互換性の維持が懸念事項である場合は、それらのオーバーライドに関する注記を参照してください。

注記

新しいバージョンのソフトウェアをインストールする前にデータのバックアップを必ず励行してください。MySQL は、高水準の品質を保証するため多大な努力を行なっていますが、バックアップを取ってデータを保護してください。

以前のバージョンから 5.6 にアップグレードするには、アップグレードの前に mysqldump でテーブルをダンプし、アップグレード後にダンプファイルをリロードすることを、MySQL は推奨します。すべてのデータベースをダンプに含めるには、--all-databases オプションを使用します。データベースにストアドプログラムが含まれる場合は、--routines オプションおよび --events オプションも使用します。

一般的に、MySQL 5.5 から 5.6 へのアップグレードを行う場合は次を実行します。

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

    • セクション2.11.1「MySQL のアップグレード」に、更新に関する一般的な情報があります。

    • このセクションで後述する変更リスト内の項目によって、現在の MySQL インストールに該当するアップグレードの問題を識別できます。そこで説明されている互換性の欠如の一部は、アップグレードの前に注意する必要があります。ほかの点はアップグレードのあとで扱うようにしてください。

    • MySQL 5.6 リリースノートでは、5.6 で使用できる主な新機能や、MySQL の以前のリリースとは異なるものについて説明しています。これらの変更の一部には互換性がない場合があります。

    既知の問題または非互換の変更というマークが付いている変更に特に注意してください。以前のバージョンの MySQL との互換性がないこれらの変更では、アップグレードする前に注意を払う必要があることがあります。弊社の目的はそれらの変更を避けることですが、各リリースの間の非適合性よりもさらに深刻な問題を修正するために必要である場合もあります。使用しているインストールに当てはまるアップグレードの問題に、特別な処置を必要とする互換性の欠如が関係している場合は、互換性の欠如の説明にある手順に従ってください。これには、テーブルのダンプとリロード、あるいは CHECK TABLEREPAIR 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 インストールに、インプレースアップグレード後の変換に長い時間がかかる可能性のある大量のデータが含まれている場合は、必要な変換とその実行に関係する作業を評価するための仮のデータベースインスタンスを作成すると役立つことがあります。mysql データベースの完全なコピーと、データを含まないその他のすべてのデータベースを含む MySQL インスタンスのコピーを作成します。このダミーのインスタンスに対してアップグレードの手順を実行し、必要になるアクションを確認して、元のデータベースインスタンスで実際のデータ変換を実行するときに関係する作業をよりよく評価できるようにします。

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

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

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

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

    パラメータ 古いデフォルト 新しいデフォルト
    back_log 50 max_connections を使用した自動サイズ設定
    binlog_checksum NONE CRC32
    --binlog-row-event-max-size 1024 8192
    flush_time 1800 (Windows の場合) 0
    innodb_autoextend_increment 8 64
    innodb_buffer_pool_instances 1 8 (プラットフォームに依存)
    innodb_checksum_algorithm INNODB CRC32
    innodb_concurrency_tickets 500 5000
    innodb_file_per_table 0 1
    innodb_old_blocks_time 0 1000
    innodb_open_files 300 innodb_file_per_tabletable_open_cache を使用した自動サイズ設定
    innodb_stats_on_metadata ON OFF
    join_buffer_size 128KB 256KB
    max_allowed_packet 1MB 4MB
    max_connect_errors 10 100
    sync_master_info 0 10000
    sync_relay_log 0 10000
    sync_relay_log_info 0 10000

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

    • innodb_file_per_table は有効です (以前は無効)。

    • innodb_checksum_algorithmCRC32 です (以前は INNODB)。

    • binlog_checksumCRC32 です (以前は NONE)。

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

    [mysqld]
    innodb_file_per_table=0
    innodb_checksum_algorithm=INNODB
    binlog_checksum=NONE

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

    • innodb_file_per_table の新しいデフォルトは有効で、アップグレード後に ALTER TABLE 操作を行うとシステムのテーブルスペース内の InnoDB テーブルが個々の .ibd ファイルに移動されます。innodb_file_per_table=0 を使用するとこれを防ぐことができます。

    • innodb_checksum_algorithm=INNODB を設定することにより、このリリースにアップグレードしたあとでバイナリのダウングレードが可能になります。CRC32 を設定することにより、InnoDB は MySQL の古いバージョンが使用できないチェックサムを使用します。

    • 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 で使用される形式) であるアカウントになります。

    SET old_passwords = 1;
    CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'mypass';

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

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

    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 カラムを、ほかのカラムと一致するように修正できます。

    • old_passwords を 0 に設定してから、SET PASSWORD および PASSWORD() を使用してアカウントに新しいパスワードを割り当てます。これにより、Password カラムが 4.1 パスワードハッシュを持つようになり、mysql_native_password プラグインと一致します。これが、推奨されるアカウントの修正方法です。

    • あるいは、データベース管理者はプラグインがパスワードハッシュ形式に一致するように mysql_old_password を変更してから、権限をフラッシュできます。mysql_old_password プラグインおよび 4.1 より前のパスワードハッシュは非推奨であり、MySQL の将来のバージョンではサポートされなくなるため、この方法は推奨されません。

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

    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 オプションが含まれますが、次のように条件コメントで囲みます。

    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 ... */ を使用して書き込まれています。

  • 互換性のない変更: TIMEDATETIME、および TIMESTAMP カラムについては、MySQL 5.6.4 より前に作成されたテーブルに必要なストレージは、5.6.4 以降で作成されたテーブルに必要なストレージとは異なります。これは、5.6.4 で、これらの時間型が少数部を持つことを許可するように変更されたためです。MySQL 5.5 から MySQL 5.6.4 以降にアップグレードしたあと、MySQL 5.5 から MySQL 5.6 の TIMEDATETIME、および 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 COLUMNCHANGE COLUMNMODIFY COLUMNADD INDEX、および FORCE 操作に関して、古い時間カラムを 5.6 形式にアップグレードします。したがって、次のステートメントは、古い形式のカラムを含むテーブルをアップグレードします。

    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 番目の手順を使用します。

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

    1. テーブルの元の .frm ファイルを、テーブルスペースをインポートするサーバーのデータディレクトリにコピーします。

    2. テーブルの .frm ファイルを、InnoDB ストレージエンジンの代わりに Memory ストレージエンジンを使用するように変更します。この変更には、.frm ファイル内の、テーブルのストレージエンジンタイプを定義する 7 バイトを変更する必要があります。16 進の編集ツールを使用する場合:

      • 次に示すように、オフセット位置 0003 のバイト legacy_db_type を、0c (InnoDB) から 06 (Memory) に変更します。

        00000000  fe 01 09 06 03 00 00 10  01 00 00 30 00 00 10 00
      • 残りの 6 バイトには固定のオフセットはありません。.frm ファイルで InnoDB を検索し、その他の 6 バイトを含む行を探します。行は次に示すようになります。

        00001010  ff 00 00 00 00 00 00 06  00 49 6e 6e 6f 44 42 00  |.........InnoDB.|
      • 行が次のようになるようにバイトを変更します。

        00001010  ff 00 00 00 00 00 00 06 00 4d 45 4d 4f 52 59 00
    3. ALTER TABLE ... ENGINE=INNODB を実行して、テーブル定義を InnoDB データディクショナリに追加します。これにより、新しい形式の時間データ型を持つ InnoDB テーブルが作成されます。ALTER TABLE 操作が正常に完了するためには、.frm ファイルがテーブルスペースに対応していなければなりません。

    4. ALTER TABLE ... IMPORT TABLESPACE を使用してテーブルをインポートします。

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

    1. SHOW CREATE TABLE の出力からテーブルの定義を使用して、外部キーのあるテーブルを再作成します。この時点では、正しくない時間カラムフォーマットは問題ではありません。

    2. INFORMATION_SCHEMA.TABLE_CONSTRAINTS および INFORMATION_SCHEMA.KEY_COLUMN_USAGE から外部キー情報を選択して、すべての外部キー定義をテキストファイルにダンプします。

    3. すべてのテーブルを削除し、外部キーのないテーブルに関する前述の手順のステップ 1 から 4 で説明されているテーブルのインポートプロセスを完了します。

    4. インポート操作が完了したら、テキストファイルに保存した外部キー定義から外部キーを追加します。

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

    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)

SQL の変更
  • 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 データ型は非標準的な方式であるという点でほかのデータ型と異なります。

    • NULL 属性で明示的に宣言されない TIMESTAMP カラムには、NOT NULL 属性が割り当てられます。(ほかのデータ型のカラムは、NOT NULL として明示的に宣言されない場合、NULL 値が許可されます。)そのようなカラムを NULL に設定すると、カラムは現在のタイムスタンプに設定されます。

    • テーブル内の最初の TIMESTAMP カラムは、NULL 属性や明示的な DEFAULT または ON UPDATE 句で宣言されない場合、DEFAULT CURRENT_TIMESTAMP および ON UPDATE CURRENT_TIMESTAMP 属性が自動的に割り当てられます。

    • 最初のカラムに続く TIMESTAMP カラムは、NULL 属性または明示的な DEFAULT 句で宣言されない場合、DEFAULT '0000-00-00 00:00:00' (ゼロタイムスタンプ) が自動的に割り当てられます。そのようなカラムに対して明示的な値を指定しない挿入された行については、カラムに '0000-00-00 00:00:00' が自動的に割り当てられて、警告は発生しません。

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

    [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 を、代わりに次のように処理します。

    • 明示的に NOT NULL として宣言されない TIMESTAMP カラムでは、NULL 値が許可されます。そのようなカラムを NULL に設定することで、カラムは現在のタイムスタンプではなく NULL に設定されます。

    • TIMESTAMP カラムに DEFAULT CURRENT_TIMESTAMP または ON UPDATE CURRENT_TIMESTAMP 属性が自動的に割り当てられません。これらの属性は、明示的に指定する必要があります。

    • NOT NULL として宣言され、明示的な DEFAULT 句を持たない TIMESTAMP カラムは、デフォルト値を持たないものとして処理されます。そのようなカラムについて明示的な値を指定しない挿入された行の場合、結果は SQL モードによって異なります。厳密 SQL モードが有効である場合、エラーが発生します。厳密 SQL モードが有効でない場合、カラムには暗黙的なデフォルトの '0000-00-00 00:00:00' が割り当てられ、警告が発生します。これは、MySQL が DATETIME などのほかの時間型を処理する方法に類似しています。

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

    1. スレーブを停止してアップグレードし、explicit_defaults_for_timestamp の任意の値で構成してから起動します。

      スレーブは、マスターから受信したバイナリログの形式から、マスターが古い (explicit_defaults_for_timestamp の導入に先行する) こと、およびマスターからの TIMESTAMP カラムが古い TIMESTAMP 動作を使用していることを認識します。

    2. マスターを停止してアップグレードし、スレーブに使用されるのと同じ explicit_defaults_for_timestamp の値で構成してから起動します。


User Comments
Sign Up Login You must be logged in to post a comment.