Skip navigation links
8.6.2.2 LOAD DATA FROM MASTER 構文 »
Section Navigation      [Toggle]

8.6.2.1. CHANGE MASTER TO 構文

CHANGE MASTER TO master_def [, master_def] ...

master_def:
    MASTER_BIND = 'interface_name'
  | MASTER_HOST = 'host_name'
  | MASTER_USER = 'user_name'
  | MASTER_PASSWORD = 'password'
  | MASTER_PORT = port_num
  | MASTER_CONNECT_RETRY = interval
  | MASTER_HEARTBEAT_PERIOD = interval
  | MASTER_LOG_FILE = 'master_log_name'
  | MASTER_LOG_POS = master_log_pos
  | RELAY_LOG_FILE = 'relay_log_name'
  | RELAY_LOG_POS = relay_log_pos
  | MASTER_SSL = {0|1}
  | MASTER_SSL_CA = 'ca_file_name'
  | MASTER_SSL_CAPATH = 'ca_directory_name'
  | MASTER_SSL_CERT = 'cert_file_name'
  | MASTER_SSL_KEY = 'key_file_name'
  | MASTER_SSL_CIPHER = 'cipher_list'
  | MASTER_SSL_VERIFY_SERVER_CERT = {0|1}

CHANGE MASTER TO は、スレーブサーバーがマスタサーバーに接続、また更新するときに利用するパラメータを変更します。それは master.info と relay-log.info ファイルのコンテンツの更新もします。

MASTER_USER、MASTER_PASSWORD、MASTER_SSL、MASTER_SSL_CA、MASTER_SSL_CAPATH、MASTER_SSL_CERT、MASTER_SSL_KEY、MASTER_SSL_CIPHER、および MASTER_SSL_VERIFY_SERVER_CERT は、マスターに接続する方法に関する情報をスレーブに提供します。MASTER_SSL_VERIFY_SERVER_CERT は、MySQL 5.1.18 で追加されました。SSL Command Options で --ssl-verify-server-cert オプションについて説明されているように使用されます。

MASTER_CONNECT_RETRY は、接続再試行の間で待機する秒数を指定します。デフォルトは 60 です。再接続試行の数は、--master-retry-count サーバーオプションによって制限されます。詳細については、Replication and Binary Logging Options and Variables を参照してください。

SSL オプション (MASTER_SSL、MASTER_SSL_CA、MASTER_SSL_CAPATH、MASTER_SSL_CERT、MASTER_SSL_KEY、MASTER_SSL_CIPHER)、および MASTER_SSL_VERIFY_SERVER_CERT は、SSL サポートなしでコンパイルされたスレーブ上でも変更できます。それらは master.info ファイルに保存されますが、有効な SSL サポートを持つサーバーを利用しなければ無視されます。

特定のパラメータを指定しない場合は、次の説明に示されている場合を除き、その古い値が保持されます。たとえば、MySQL マスタに接続するためのパスワードが変更されたら、スレーブに新しいパスワードについて指示するためにこれらのステートメントを発行するだけでよいのです。 

STOP SLAVE; -- if replication was running
CHANGE MASTER TO MASTER_PASSWORD='new3cret';
START SLAVE; -- if you want to restart replication

変更しないパラメータを指定する必要はありません。(ホスト、ポート、ユーザー、など)

MASTER_HOST と MASTER_PORT は、マスターホストのホスト名 (または、IP アドレス) とその TCP/IP ポートです。

次の 2 つのオプション (MASTER_BIND と MASTER_HEARTBEAT_PERIOD) は MySQL Cluster NDB 6.3 以降で使用できますが、メインラインの MySQL 5.1 ではサポートされていません。

  • MASTER_BIND は、複数のネットワークインタフェースを備えたレプリケーションスレーブ上で使用され、マスターへの接続にスレーブのどのネットワークインタフェースが選択されるかを決定します。またこのような場合に、--master-bind オプションを使用してスレーブの mysqld プロセスを起動することによって、どのネットワークインタフェースが使用されるかを決定することもできます。

    レプリケーションスレーブを特定のネットワークインタフェースにバインドする機能は、MySQL Cluster NDB 6.3.4 で追加されました。

  • MASTER_HEARTBEAT_PERIOD は、レプリケーションハートビートの間隔を秒単位で設定するために使用されます。イベントによってマスターのビンログが更新された場合は常に、次のハートビートを待機している期間がリセットされます。interval は、0 ～ 4294967 秒の範囲と百分の 1 秒の分解能を持つ 10 進値です。ゼロ以外の最小値は 0.001 です。ハートビートは、ビンログファイル内に未送信のイベントが interval より長い期間にわたって存在しなくなった場合にのみ、マスターによって送信されます。

    interval を 0 に設定すると、ハートビートが完全に無効になります。interval のデフォルト値は、slave_net_timeout を 2 で割った値に等しくなります。

    @@global.slave_net_timeout を現在のハートビート間隔より小さい値に設定すると、警告が発行されます。RESET SLAVE を発行すると、ハートビート間隔がデフォルト値にリセットされます。

    MASTER_HEARTBEAT_PERIOD は、MySQL Cluster NDB 6.3.4 で追加されました。

注意

レプリケーションでは、Unix ソケットファイルを使用できません。TCP/IP を使用してマスター MySQL サーバーに接続できる必要があります。

もし MASTER_HOST か MASTER_PORT を指定すると、スレーブはマスタサーバーが以前とは違うと仮定します。(たとえ現在の値と等しいホストやポート値を指定したとしても) この場合、マスタバイナリログ名と位置の古い値は適応しないとみなされるため、もしステートメント内の MASTER_LOG_FILE と MASTER_LOG_POS を指定しなければ、MASTER_LOG_FILE='' と MASTER_LOG_POS=4 が静かにそれに加えられます。

MASTER_HOST='' を設定する、つまり、その値を空の文字列に明示的に設定することは、この値をまったく設定しないことと同じではありません。このオプションを空の文字列に設定すると、それ以降の START SLAVE が失敗します。この問題は、MySQL 6.0 で対処されています。(Bug#28796)

MASTER_LOG_FILE と MASTER_LOG_POS は、次にスレットがスタートするマスタから、スレーブ I/O スレッドが読み込みを始めなければいけない座標です。もしそれらのどちもを指定しなければ、RELAY_LOG_FILE か RELAY_LOG_POS を指定することができません。MASTER_LOG_FILE または MASTER_LOG_POS のどちらも指定されていない場合、スレーブは、CHANGE MASTER TO が発行される前のスレーブ SQL スレッドの最後の座標を使用します。これは、ただ単に使用するパスワードを変更したいだけのときに、スレーブ I/O スレッドと比べてスレーブ SQL スレッドが遅かったとしても、レプリケーション内に切れ目がないことを保証します。

CHANGE MASTER TO はすべてのリレーログファイルを削除し、RELAY_LOG_FILE または RELAY_LOG_POS が指定されていないかぎり、新しいリレーログファイルを開始します。その場合、リレーログは保管されます。relay_log_purge グローバル変数は静かに 0 に設定されます。

CHANGE MASTER TO は、マスターのスナップショットがあり、それに対応するログとオフセットを記録している場合にスレーブを設定するのに役立ちます。そのスナップショットをスレーブにロードしたあと、スレーブ上で CHANGE MASTER TO MASTER_LOG_FILE='log_name_on_master'、MASTER_LOG_POS=log_offset_on_master を実行できます。

次の例は、マスタとマスタのバイナリログ座標を変更します。これは、マスタを複製するためにスレーブを設定したいときに利用します。 

CHANGE MASTER TO
  MASTER_HOST='master2.mycompany.com',
  MASTER_USER='replication',
  MASTER_PASSWORD='bigs3cret',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='master2-bin.001',
  MASTER_LOG_POS=4,
  MASTER_CONNECT_RETRY=10;

次の例は、あまり利用されない操作を表しています。これは、何かの理由でもう一度実行したいリレーログをスレーブが持っているときに利用します。これを行うためには、マスタにはアクセス不可能でなければいけません。CHANGE MASTER TO を利用し、SQL スレッドをスタートさせるだけでよいです。START SLAVE SQL_THREAD) 

CHANGE MASTER TO
  RELAY_LOG_FILE='slave-relay-bin.006',
  RELAY_LOG_POS=4025;

クラッシュのあとの復旧のために、スタンドアロンの非スレーブサーバーを含む非レプリケーションセットアップ内で 2 番目の操作を使用することもできます。サーバーがクラッシュして、バックアップを格納したと仮定してください。サーバーのバイナリログ (リレーログではなく通常のバイナリログ)、名づけられた (たとえば)myhost-bin.* を再生したいでしょう。まず、次の手順とまったく同じように作業しなかったためにサーバーが誤ってバイナリログを消去してしまう、という場合に備えて、これらのバイナリログのバックアップコピーを安全なところに作成してください。更なる安全のために SET GLOBAL relay_log_purge=0 を利用してください。--log-bin オプションは利用せず、その代わりに、--replicate-same-server-id、--relay-log=myhost-bin (サーバーにこれらの通常のバイナリログがリレーログだと信じさせるため) そして --skip-slave-start オプションを利用してサーバーをスタートさせてください。サーバーがスタートしたら、これらのステートメントを発行してください。 

CHANGE MASTER TO
  RELAY_LOG_FILE='myhost-bin.153',
  RELAY_LOG_POS=410,
  MASTER_HOST='some_dummy_string';
START SLAVE SQL_THREAD;

サーバーがそれ自身のバイナリログを読み込み、実行するので、クラッシュの修復を達成します。修復が終了したら、STOP SLAVE を起動し、サーバーをシャットダウンし、master.info と relay-log.info ファイルを削除し、そして元のオプションを利用してサーバーを再スタートさせてください。

MASTER_HOST オプション (たとえダミー値を利用していても) を指定するには、それがスレーブだとマスタに信じさせることが必要です。