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


MySQL 5.6 リファレンスマニュアル  /  ...  /  レプリケーションセットアップをアップグレードする

17.4.3 レプリケーションセットアップをアップグレードする

レプリケーションセットアップに関与するサーバーをアップグレードするときに、アップグレードの手順は現在のサーバーバージョンとアップグレード後のバージョンによって異なります。

このセクションは、古いバージョンの MySQL から MySQL 5.6 にレプリケーションをアップグレードすることに割り当てられます。4.0 サーバーは 4.0.3 以降であるべきです。マスター上のレプリケーションユーザーには、ハッシュ方式の変更により、MySQL バージョン 4.1.1 以降で生成されたパスワードハッシュが必要です。詳細は、セクション6.1.2.4「MySQL でのパスワードハッシュ」を参照してください。

以前の MySQL リリースシリーズから 5.6 にマスターをアップグレードするときは、最初にこのマスターのすべてのスレーブが同じ 5.6.x リリースを使用していることを確認してください。そうでない場合は、まずスレーブをアップグレードしてください。各スレーブをアップグレードするには、シャットダウンし、適切な 5.6.x バージョンにアップグレードし、再起動してから、レプリケーションを再開してください。アップグレード後にスレーブによって作成されるリレーログは 5.6 形式です。

厳密な SQL モードでの操作に影響する変更があると、更新後のスレーブでレプリケーションが失敗する場合があります。たとえば、MySQL 5.6.13 以降では、サーバーは、厳密モード (STRICT_TRANS_TABLES または STRICT_ALL_TABLES) で時間データ型の DEFAULT 値への 0 の挿入を制限します。ステートメントベースロギング (binlog_format=STATEMENT) を使用する場合にレプリケーションで非互換になるのは、スレーブがアップグレードされた場合、アップグレードされていないマスターがエラーなしで実行するステートメントが、スレーブ上で失敗することがあり、するとレプリケーションが停止します。これに対処するには、マスター上のすべての新しいステートメントを停止し、スレーブが追い付くのを待ちます。それからスレーブをアップグレードします。あるいは、新しいステートメントを停止できない場合は、マスターで一時的に行ベースのロギングに変更し (binlog_format=ROW)、すべてのスレーブが、この変更の時点までに生成されたすべてのバイナリログを処理するまで待ちます。それからスレーブをアップグレードします。

スレーブがアップグレードされたあとに、マスターをシャットダウンし、スレーブと同じ 5.6.x リリースにアップグレードしてから、再起動します。一時的にマスターを行ベースロギングに変更した場合は、ステートメントベースロギングに戻します。5.6 マスターは、アップグレード前に書き込まれた古いバイナリログを読み取って、それらを 5.6 スレーブに送信できます。スレーブは、古い形式を認識し、適切に処理します。アップグレード後にマスターによって作成されるバイナリログは 5.6 形式です。これらも 5.6 スレーブによって認識されます。

つまり、MySQL 5.6 にアップグレードするときは、マスターを 5.6 にアップグレードする前に、スレーブが MySQL 5.6 である必要があります。5.6 から古いバージョンへのダウングレードは、それほど簡単には機能しません。ダウングレードに進む前に 5.6 バイナリログまたはリレーログを削除できるように、それらが完全に処理されたことを確認する必要があります。

レプリケーションセットアップを以前のバージョンにダウングレードすることは、ステートメントベースから行ベースレプリケーションに切り替えたあと、および最初の行ベースステートメントが binlog に書き込まれたあとには実行できません。セクション17.1.2「レプリケーション形式」を参照してください。

アップグレードによっては、ある MySQL シリーズから次のものに移行するときに、データベースオブジェクトの削除と再作成が必要になる場合があります。たとえば、照合順序の変更には、テーブルインデックスの再構築が必要な場合があります。このような操作が必要な場合は、詳細をセクション2.11.1.3「MySQL 5.5 から 5.6 へのアップグレード」で参照してください。これらの操作をスレーブとマスターで個別に実行し、これらの操作をマスターからスレーブに複製することを無効にするのがもっとも安全です。 これを実現するには、次の手順を使用してください。

  1. すべてのスレーブを停止してそれらをアップグレードします。マスターに接続しないように、--skip-slave-start オプションでそれらを再起動します。データベースオブジェクトの再作成に必要なテーブル修復または再構築操作 (REPAIR TABLEALTER TABLE の使用など)、またはテーブルまたはトリガーのダンプおよびリロードを実行します。

  2. マスター上でバイナリログを無効にします。マスターを再起動しないでこれを行うには、SET sql_log_bin = 0 ステートメントを実行します。または、マスターを停止して、--log-bin オプションなしで再起動します。マスターを再起動する場合、クライアント接続を拒否することもお勧めします。たとえば、すべてのクライアントが TCP/IP を使用して接続する場合は、マスターを再起動するときに --skip-networking オプションを使用します。

  3. バイナリログが無効の状態で、データベースオブジェクトの再作成に必要なテーブル修復または再構築操作を実行します。これらの操作がログに記録されてあとでスレーブに送信されることを回避するには、この手順の間バイナリログを無効にする必要があります。

  4. マスター上でバイナリログを再度有効にします。以前に sql_log_bin を 0 に設定した場合、SET sql_log_bin = 1 ステートメントを実行します。バイナリログを無効にするためにマスターを再起動した場合は、クライアントとスレーブが接続できるように --log-bin あり、--skip-networking なしで再起動します。

  5. 今度は --skip-slave-start オプションなしで、スレーブを再起動します。

グローバルトランザクション識別子を持つレプリケーションが MySQL 5.6.7 で導入されました。GTID をサポートしないバージョンの MySQL から、サポートするバージョンに既存のレプリケーションセットアップをアップグレードする場合、GTID ベースレプリケーションのすべての要件をセットアップが満たすことを確認する前に、マスターまたはスレーブで GTID を有効にしないでください。セクション17.1.3.2「GTID を使用したレプリケーションのセットアップ」を参照してください。GTID ベースレプリケーションを使用するために既存のレプリケーションセットアップを変換することに関する情報が含まれています。


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