スレーブ サーバをコントロールする SQL ステートメント

1. CHANGE MASTER TO 構文

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

2. LOAD DATA FROM MASTER 構文

LOAD DATA FROM MASTER

この機能は終了しました。今後は使わないことを勧めます。MySQLの将来のバージョンでは取り除かれることもあります。

LOAD DATA FROM MASTER と LOAD TABLE FROM MASTER の現在のインプリメンテーションがとても制限されているので、これらのステートメントは MySQL のバージョン 4.1 以降では廃止予定です。今後のバージョンでは、さらに進歩した技術(「online backup」 と呼ばれる物) を紹介する予定です。その技術は、さらに多くのストレージ エンジンと機能する更なる利点を持ちます。

MySQL 5.1 以前のバージョンで LOAD DATA FROM MASTER か LOAD TABLE FROM MASTER を利用する為に推奨する代替方法は、mysqldump か mysqlhotcopy を利用する事です。後者は Perl と2つの Perl モジュール(DBI と DBD:mysql)を必要とし、MyISAM と ARCHIVE テーブルにだけ機能します。mysqldump を利用すると、マスタ上に SQL ダンプを作成でき、それらをスレーブ上の mysql クライアントにパイプ(またはコピー)できます。これは全てのストレージ エンジンに機能するという利点を持ちますが、SELECT を利用して機能する為スピードが大変遅いです。

このステートメントは、マスタのスナップショットを撮り、それをスレーブにコピーします。それは、スレーブが正しい位置から複製を始めるように MASTER_LOG_FILE と MASTER_LOG_POS の値を更新します。--replicate-*-do-* と --replicate-*-ignore-* オプションを利用して指定されたテーブルとデータベースの除外ルールは支持されています。マスタからテーブルをロードする時にスレーブを混乱させる --replicate-rewrite-db="db1->db3" と --replicate-rewrite-db="db2->db3" のような非固有マッピングを設定する為に、ユーザはこのオプションを利用できるので、--replicate-rewrite-db は考慮に入れられて いません。

このステートメントは次の条件に従い利用できます：

もし大きいテーブルをロードしていたら、マスタとスレーブの両方で net_read_timeout と net_write_timeout の値を増やす必要があるでしょう。詳しくは 項 「システム変数」 を参照してください。

LOAD DATA FROM MASTER は mysql データベースから何もコピー しない 事に注意してください。これは、マスタとスレーブ上で異なるユーザと権限を持つ事を簡単にします。

LOAD DATA FROM MASTER を利用する為には、 マスタに接続する為に利用される複製アカウントはマスタ上に RELOAD と SUPER 権限を持ち、ロードしたい全てのマスタ テーブルに SELECT 権限を持つ必要があります。ユーザが SELECT 権限を持たない全てのマスタ テーブルは LOAD DATA FROM MASTER に無視されます。これは、マスタがユーザからそれらを隠す為に起こります。LOAD DATA FROM MASTER は、ロードするデータベースを知る為に SHOW DATABASES をコールしますが、SHOW DATABASES はユーザが何かしらの権限を持つデータベースだけを返します。詳しくは 項11. 「SHOW DATABASES 構文」 を参照してください。スレーブ サイドでは、LOAD DATA FROM MASTER を発行するユーザはデータベースをドロップし作成する権限と、コピーされるテーブルを持つ必要があります。

3. LOAD TABLE tbl_name FROM MASTER 構文

LOAD TABLE tbl_name FROM MASTER

この機能は終了しました。今後は使わないことを勧めます。MySQLの将来のバージョンでは取り除かれることもあります。

LOAD DATA FROM MASTER と LOAD TABLE FROM MASTER の現在のインプリメンテーションがとても制限されているので、これらのステートメントは MySQL のバージョン 4.1 以降では廃止予定です。今後のバージョンでは、さらに進歩した技術(「online backup」 と呼ばれる物) を紹介する予定です。その技術は、さらに多くのストレージ エンジンと機能する更なる利点を持ちます。

MySQL 5.1 以前のバージョンで LOAD DATA FROM MASTER か LOAD TABLE FROM MASTER を利用する為に推奨する代替方法は、mysqldump か mysqlhotcopy を利用する事です。後者は Perl と2つの Perl モジュール(DBI と DBD:mysql)を必要とし、MyISAM と ARCHIVE テーブルにだけ機能します。mysqldump を利用すると、マスタ上に SQL ダンプを作成でき、それらをスレーブ上の mysql クライアントにパイプ(またはコピー)できます。これは全てのストレージ エンジンに機能するという利点を持ちますが、SELECT を利用して機能する為スピードが大変遅いです。

マスタからスレーブにテーブルのコピーをトランスファします。このステートメントは主に LOAD DATA FROM MASTER 操作をデバッグしながらインプリメントされます。LOAD TABLE を利用するには、マスタ サーバに接続するのに利用されるアカウントはマスタ上に RELOAD と SUPER 権限を持ち、マスタ テーブルをロードする為に SELECT 権限を持つ必要があります。スレーブ サイドでは、LOAD TABLE FROM MASTER を発行するユーザはテーブルをドロップし作成する権限を持つ必要があります。

LOAD DATA FROM MASTER の条件もこれに適応します。例えば、LOAD TABLE FROM MASTER は MyISAM テーブルに対してのみ機能します。

LOAD DATA FROM MASTER のタイム アウト ノートもこれに適応します。

4. MASTER_POS_WAIT() 構文

SELECT MASTER_POS_WAIT('master_log_file', master_log_pos)

このオプションはステートメントではなく関数です。これはスレーブがマスタのバイナリ ログ内の指定された位置までのイベントを読み込み、実行した事を保証する為に利用されます。完全な説明は 項 「その他の関数」 を参照してください。

5. RESET SLAVE 構文

RESET SLAVE

RESET SLAVE がスレーブがマスタのバイナリ ログ内の複製位置を忘れるよう働きかけます。このステートメントは再スタートの時に利用する為の物です。これは master.info と relay-log.info ファイル、全てのリレー ログを削除し、そして新しいリレー ログをスタートします。

注意:スレーブ SQL スレッドによって完全に実行されていなくても全てのリレー ログが削除されます。(もし STOP SLAVE ステートメントを発行していたり、スレーブが高負荷であると、複製スレーブ上にこの状態が存在しやすくなります。)

master.info ファイル内に格納された接続情報は、対応するスタートアップ オプション内で指定された値を利用して速やかにリセットされます。この情報は、マスタ ホスト、マスタ ポート、マスタ ユーザ、そしてマスタ パスワードのような値を含みます。もしスレーブ SQL スレッドが停止した時テンポラリ テーブルの複製の最中で、そして RESET SLAVE が発行されると、これらの複製テンポラリ テーブルはスレーブ上で削除されます。

6. SET GLOBAL SQL_SLAVE_SKIP_COUNTER 構文

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = N

このステートメントは、マスタから次の N イベントをスキップします。これはステートメントによって引き起こされた複製から回復するのに役に立ちます。

このステートメントは、スレーブ スレッドが起動していない時のみ有効です。そうでなければ、エラーを発生させます。

7. SHOW SLAVE STATUS 構文

SHOW SLAVE STATUS

このステートメントは、スレーブ スレッドに不可欠なパラメータ上にステータス情報を提供します。mysql クライアントを利用してこのステートメントを発行すると、より読みやすい水平方向のレイアウトを得る為に、セミコロンではなく \G ステートメント ターミネータを利用する事ができます。

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
       Slave_IO_State: Waiting for master to send event
          Master_Host: localhost
          Master_User: root
          Master_Port: 3306
        Connect_Retry: 3
      Master_Log_File: gbichot-bin.005
  Read_Master_Log_Pos: 79
       Relay_Log_File: gbichot-relay-bin.005
        Relay_Log_Pos: 548
Relay_Master_Log_File: gbichot-bin.005
     Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
      Replicate_Do_DB:
  Replicate_Ignore_DB:
           Last_Errno: 0
           Last_Error:
         Skip_Counter: 0
  Exec_Master_Log_Pos: 79
      Relay_Log_Space: 552
      Until_Condition: None
       Until_Log_File:
        Until_Log_Pos: 0
   Master_SSL_Allowed: No
   Master_SSL_CA_File:
   Master_SSL_CA_Path:
      Master_SSL_Cert:
    Master_SSL_Cipher:
       Master_SSL_Key:
Seconds_Behind_Master: 8

SHOW SLAVE STATUS は次のフィールドを返します。

START SLAVE [thread_type [, thread_type] ... ]
START SLAVE [SQL_THREAD] UNTIL
    MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos
START SLAVE [SQL_THREAD] UNTIL
    RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos

thread_type: IO_THREAD | SQL_THREAD

STOP SLAVE [thread_type [, thread_type] ... ]

thread_type: IO_THREAD | SQL_THREAD