CHANGE MASTER TO master_def [, master_def] ...

master_def:
    MASTER_HOST = 'host_name'
  | MASTER_USER = 'user_name'
  | MASTER_PASSWORD = 'password'
  | MASTER_PORT = port_num
  | MASTER_CONNECT_RETRY = count
  | 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'

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 はどのようにマスタに接続すかという事について情報を提供します。

SSL オプション(MASTER_SSL、MASTER_SSL_CA、MASTER_SSL_CAPATH、MASTER_SSL_CERT、MASTER_SSL_KEY、そして MASTER_SSL_CIPHER) は、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 はマスタホストと、その TCP/IP ポートのホスト名(または IP アドレス) です。 もし MASTER_HOST が localhost と同等であれば、その時は MySQL の別の部分と同じで、ポート番号は無視されるという事に注意してください。(例えば、もし Unix ソケットファイルが利用できる場合)

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

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

CHANGE MASTER は、RELAY_LOG_FILE か RELAY_LOG_POS を指定しない限り、全てのリレー ログ ファイルを削除し、新しい物をスタートします。その場合、リレー ログは保管されます。relay_log_purge グローバル変数は静かに0に設定されます。

CHANGE MASTER は、マスタのスナップショットを持っていて、それに対応するログとオフセットを記録した時に、スレーブを設定するのに役立ちます。スナップショットをスレーブにロードした後、スレーブ上で 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 オプション(たとえダミー値を利用していても) を指定するには、それがスレーブだとマスタに信じさせる事が必要です。