マスタとスレーブの両方で、server-id
        オプションを使用して各サーバに一意のレプリケーション
        ID
        を設定する必要があります。マスタとサーバそれぞれに、1
        から 2^32 - 1
        までの整数から一意の番号を割り当てます。
        たとえば、server-id=3
        のように設定します。
      
マスタサーバで使用できる、バイナリログを制御するオプションについては、項4.10.4. 「バイナリログ」 で説明しています。
以下の表は、スレーブサーバで使用できるオプションを説明したものです。 コマンドラインまたはオプション設定ファイルで指定できます。
注意: レプリケーションでは、以下のオプションを特殊な方法で処理します。
            --master-host
          
            --master-user
          
            --master-password
          
            --master-port
          
            --master-connect-retry
          
        スレーブサーバの起動時に
        master.info
        ファイルが存在しない場合、オプション設定ファイルまたはコマンドラインで指定した値が使用されます。これは、サーバをレプリケーションスレーブとして初めて起動した場合や、RESET
        SLAVE
        を実行してスレーブサーバをシャットダウンし、再起動した場合などに起こることです。
      
        スレーブサーバの起動時に
        master.info
        ファイルが存在する場合は、このファイルの値が使用されます。オプション設定ファイルまたはコマンドラインの対応するオプション値は無視されます。
      
        my.cnf
        ファイルで次のオプションを指定していると仮定します。
      
[mysqld] master-host=this_host
        サーバをレプリケーションスレーブとして初めて起動したとき、サーバは
        my.cnf
        ファイルからこのオプションを読み取って使用します。サーバは次にその値を
        master.info
        ファイルに記録します。次回サーバを起動したとき、サーバは
        master.info
        ファイルからのみマスタホスト値を読み取ります。my.cnf
        ファイルを変更して別のマスタホストを指定しても、反映されません。マスタホスト値を変更したい場合には、
        CHANGE MASTER TO
        を使用する必要があります。
      
MySQL 4.1.1 以降、以下のオプションも特殊な方法で処理されます。
            --master-ssl
          
            --master-ssl-ca
          
            --master-ssl-capath
          
            --master-ssl-cert
          
            --master-ssl-cipher
          
            --master-ssl-key
          
        これらのオプションに対応する値が
        master.info
        ファイルに含まれています。加えて、4.1.1
        のファイル形式では、最初の行に、ファイル内の行数が示されます。古いサーバを
        4.1.1
        にアップグレードすると、新しいサーバの起動時に、master.info
        は自動的に新しい形式にアップグレードされます(4.1.1
        以降のものを 4.1.1
        より前のバージョンにダウングレードした場合、古いサーバを最初に起動する前に、ファイルの最初の行を手動で削除する必要があります)。
      
        サーバは、スタートアップオプションよりも既存の
        master.info
        ファイルを優先するので、場合によっては、これらの値にはスタートアップオプションを使用せず、CHANGE
        MASTER TO
        ステートメントを使用して指定する方が適しています。項4.11.8.1. 「CHANGE MASTER TO」
        を参照してください。
      
以下、スタートアップオプションを使用してスレーブサーバを設定した例です。
[mysqld] server-id=2 master-host=db-master.mycompany.com master-port=3306 master-user=pertinax master-password=freitag master-connect-retry=60 report-host=db-slave.mycompany.com
以下の一覧は、レプリケーション制御に使用できるスタートアップオプションの説明です。
            --log-slave-updates
          
            スレーブの SQL
            スレッドで実行された更新を、スレーブのバイナリログに記録するようにスレーブに指示する。デフォルトではオフ。このオプションを有効にするには、バイナリログを有効にして(--log-bin
            オプションを使用して)スレーブを起動する必要がある。レプリケーションサーバをチェーン状に構成するには、--log-slave-updates
            を使用する。たとえば、次のようにセットアップできる。
          
A -> B -> C
            A はスレーブ B のマスタとして機能し、B
            はスレーブ C のマスタとして機能する。B
            がマスタでもあり、スレーブでもあるこの構成では、--log-slave-updates
            オプションで B を起動する必要がある。A と
            B
            は両方とも、バイナリログを有効にして起動する必要がある。
          
            --log-warnings
          
スレーブにより詳細なメッセージを出力させる。たとえば、ネットワークまたは接続が切断された後で再接続に成功したというメッセージや、各スレーブスレッドがどのように開始したかについての情報メッセージを出力することができる。
このオプションはレプリケーションの使用のみに限定されない。さまざまなサーバアクティビティに関する通知を出力する。
            --master-host=host
          
            マスタレプリケーションサーバのホスト名または
            IP
            アドレスを指定する。このオプションを指定しなければ、スレーブスレッドは開始できない。master.info
            の値を読み取れる場合は、ファイルに書かれている値が優先される。このオプション名は
            --bootstrap-master-host
            などにすべきだったという意見もあるが、現在、そのまま
            --master-host が使用されている。
          
            --master-user=username
          
            マスタへの接続時、スレーブスレッドが認証に使用するアカウントのユーザ名。アカウントには
            REPLICATION SLAVE 権限が必要(MySQL
            4.0.2 より前では、FILE
            権限が必要)。マスタユーザが設定されていない場合、ユーザ
            test
            と想定する。master.info
            の値を読み取れる場合は、この値が優先される。
          
            --master-password=password
          
            マスタへの接続時、スレーブスレッドが認証に使用するアカウントのパスワード。設定しなければ、空白パスワードと見なされる。master.info
            の値を読み取れる場合は、この値が優先される。
          
            --master-port=port_number
          
            マスタがリッスンするポート。設定しなければ、MYSQL_PORT
            のコンパイルされた設定が採用される。configure
            オプションを使用していなければ、これは
            3306 となる。master.info
            の値を読み取れる場合、その値が優先される。
          
            --master-connect-retry=seconds
          
            マスタがダウンした場合、または接続が失われた場合、スレーブスレッドがマスタへの接続を再試行する前に、スリープ状態で待機する秒数。デフォルトは
            60 である。master.info
            の値を読み取れる場合は、その値が優先される。
          
            --master-info-file=filename
          
            スレーブがマスタに関する情報を記録するためのファイル名を指定する。デフォルトでは、データディレクトリの
            mysql.info。
          
            --master-ssl ,
            --master-ssl-ca=file_name ,
            --master-ssl-capath=directory_name ,
            --master-ssl-cert=file_name ,
            --master-ssl-cipher=cipher_list ,
            --master-ssl-key=file_name
          
            これらのオプションは、SSL
            使用によるマスタサーバへの安全なレプリケーション接続をセットアップするために使用する。これらの意味は、項4.4.10.5. 「SSL コマンドラインオプション」
            で説明した
            --ssl、--ssl-ca、--ssl-capath、--ssl-cert、--ssl-cipher、--ssl-key
            の各オプションと同じである。
          
これらのオプションは、MySQL 4.1.1 から使用可能である。
            --max-relay-log-size=#
          
            リレーログを自動的にローテートする際に使用する。
            See 項4.6.8.4. 「SHOW VARIABLES」。
          
            --relay-log=filename
          
            リレーログの場所と名前を指定する。これを使用して、ホスト名に依存しないリレーログ名を指定できる。また、リレーログが大きくなる傾向があり(および
            max_relay_log_size
            の値を小さくしたくない場合で)、リレーログをデータディレクトリとは別の領域に置く必要がある場合にもこのオプションを使用できる。あるいは、複数のディスクに負荷を分散して処理速度を上げる場合にもこのオプションを使用できる。
          
            --relay-log-index=filename
          
リレーログインデックスファイルの場所と名前を指定する。
            --relay-log-info-file=filename
          
            relay-log.info
            に別の名前を指定したり、このファイルをデータディレクトリとは別のディレクトリに配置する。
          
            --relay-log-purge=0|1
          
            リレーログファイルが不要になったときの自動パージを有効または無効にする。これは、SET
            GLOBAL RELAY_LOG_PURGE=0|1
            で動的に変更できるグローバル変数である。デフォルト値は
            1。
          
このオプションは MySQL 4.1.1 から利用可能。
            --relay-log-space-limit=#
          
            スレーブの全リレーログの合計サイズ条件を設定する(0
            は ``無制限''
            という意味)。スレーブマシンのハードディスクが小さい場合に便利である。限度に達すると、SQL
            スレッドが、クエリを実行し終わって不要になったリレーログを削除するまで、I/O
            スレッドは一時停止する(マスタのバイナリログを読み取らない)。注意:
            この制限は絶対値ではない。SQL
            スレッドがリレーログを削除するためにさらにイベントを必要とする場合があり、その場合は削除が可能になるまで、I/O
            スレッドは制限を超えて続行する。続行しなければデッドロックが発生する(MySQL
            4.0.13 より前では発生していた)。
            --relay-log-space-limit
            は、--max-relay-log-size 値の 2
            倍より小さく設定してはいけない。また、--max-relay-log-size
            が 0 の場合は --max-binlog-size 値の
            2
            倍より小さく設定してはいけない。小さく設定した場合、--relay-log-space-limit
            が超過しているために I/O
            スレッドが待機している間、SQL
            スレッドにはパージできるリレーログがなく、I/O
            スレッドは一時的に
            --relay-log-space-limit
            を無視することになる。
          
            --replicate-do-table=db_name.table_name
          
            指定したテーブルに対するクエリのみレプリケーションを限定するようスレーブスレッドに指示する。複数のテーブルを指定するには、コマンドを複数回、各テーブルに
            1
            回ずつ使用する。これは、--replicate-do-db
            とは対照的に、データベースをまたがった更新用に使用する。この一覧の後の説明を参照のこと。
          
            --replicate-ignore-table=db_name.table_name
          
            指定したテーブルを更新するクエリをレプリケートしないことをスレーブスレッドに指示する(そのコマンドが同時に他のテーブルを更新する場合でも)。無視するテーブルを複数指定するには、コマンドを複数回、各テーブルに
            1
            回ずつ使用する。これは、--replicate-ignore-db
            とは対照的に、データベースをまたがった更新用に使用する。この一覧の後の説明を参照のこと。
          
            --replicate-wild-do-table=db_name.table_name
          
指定したワイルドカードパターンに一致するテーブルに対するクエリのみを、レプリケーションすることをスレーブスレッドに指示する。複数のテーブルを指定するには、コマンドを複数回、各テーブルに 1 回ずつ使用する。これは、データベースをまたがった更新用に使用する。この一覧の後の説明を参照のこと。
            例: --replicate-wild-do-table=foo%.bar%
            は、foo
            で始まるデータベースの bar
            で始まるテーブルを使用する更新だけをレプリケートする。
          
            注意: --replicate-wild-do-table=foo%.%
            を使用すると、このルールは CREATE
            DATABASE および DROP
            DATABASE
            にも伝播し、データベース名がデータベースパターン(ここでは
            foo%)に一致した場合、これら
            2
            つののステートメントがレプリケートされる(これは、%
            がパターンであることによって引き起こされる)。
          
            ワイルドカード文字 _ と
            %
            のエスケープにも注意が必要である。たとえば、my_own%db
            データベース(データベースの正確な名前)のすべてのテーブルをレプリケートし、my1ownAABCdb
            データベースのテーブルはレプリケートしない場合、_
            および %
            をエスケープする。この場合、replicate-wild-do-table=my\_own\%db
            のように実行する。このオプションをコマンドラインから指定した場合、システムによっては
            \
            をエスケープする必要がある(たとえば
            bash
            シェルでは、--replicate-wild-do-table=my\\_own\\%db
            と入力する必要がある)。
          
            --replicate-wild-ignore-table=db_name.table_name
          
指定したワイルドカードパターンに一致するテーブルに対するクエリをレプリケートしないことをスレーブスレッドに指示する。無視するテーブルを複数指定するには、コマンドを複数回、各テーブルに 1 回ずつ使用する。これは、 データベースをまたがった更新用に使用する。この一覧の後の説明を参照のこと。
            例:
            --replicate-wild-ignore-table=foo%.bar%
            は、foo
            で始まるデータベースの bar
            で始まるテーブルを使用する更新をレプリケートしない。
          
            注意:
            --replicate-wild-ignore-table=foo%.%
            を実行すると、ルールは CREATE
            DATABASE および DROP
            DATABASE
            にも伝播し、データベース名がデータベースパターン(ここでは
            foo%)に一致するとこれら 2
            つののステートメントがレプリケートされる(これは、%
            がパターンであることによって引き起こされる)。
          
            ワイルドカード文字 _ と
            %
            のエスケープにも注意が必要である。replicate-wild-do-table
            の説明を参照のこと。
          
            --replicate-do-db=database_name
          
            カレントデータベース(USE
            によって選択されたデータベース)が
            database_name
            の場合に、このデータベースに対するクエリだけをレプリケーションするようスレーブに指示する。
            複数のデータベースを指定するには、コマンドを複数回、各データベースに
            1 回ずつ使用する。注意: UPDATE
            some_db.some_table SET foo='bar'
            など、データベースをまたがるクエリは、別のデータベースが選択されていたりデータベースが選択されていなければ、レプリケートされない。データベースをまたがる更新が必要な場合は、3.23.28
            以降を使用し、--replicate-wild-do-table=db_name.%
            を使用する。この一覧の後の説明を参照のこと。
          
            予想しづらい動作例: スレーブを
            --replicate-do-db=sales
            で起動し、USE prices; UPDATE sales.january SET
            amount=amount+1000;
            を実行した場合、このクエリはレプリケートされない。
          
            データベースをまたがる更新が必要な場合は、代わりに
            --replicate-wild-do-table=db_name.%
            を使用する。
          
この ``カレントデータベースのみチェックする'' という動作は、複数のデータベースにまたがる複数のテーブルの削除や更新の場合、コマンドからだけではクエリをレプリケートすべきかどうか判別が難しいということが主な理由になる。また、カレントデータベースのみチェックする方が速い。
            --replicate-ignore-db=database_name
          
            カレントデータベース(USE
            によって選択されたデータベース)が
            database_name
            である場合に、このデータベースに対するクエリをレプリケートしないようスレーブに指示する。無視するデータベースを複数指定するには、コマンドを複数回、各データベースに
            1
            回ずつ使用する。テーブルをまたがる更新を行い、それらの更新をレプリケートしない場合には、このオプションを使用すべきではない。この一覧の後の説明を参照のこと。
          
            予想しづらい動作例: スレーブを
            --replicate-ignore-db=sales
            で起動し、USE prices; UPDATE sales.january SET
            amount=amount+1000;
            を実行した場合、このクエリはレプリケートされる。
          
            データベースをまたがる更新が必要な場合には、代わりに
            --replicate-wild-ignore-table=db_name.%
            を使用する。
          
            --replicate-rewrite-db=from_name->to_name
          
            カレントデータベース(USE
            によって選択されたデータベース)がマスタの
            from_name
            である場合、to_name
            に変換するようスレーブに指示する。テーブルに関連するステートメントだけが影響を受け(CREATE
            DATABASE、DROP DATABASE
            には影響しない)、かつ
            from_name
            がマスタのカレントデータベースである場合のみ影響がある。これは、データベースをまたがった更新には機能しない。注意:
            変換は、--replicate-*
            ルールがテストされる前に行われる。
          
            例:
            replicate-rewrite-db=master_db_name->slave_db_name
          
            --report-host=host
          
            スレーブの登録中にマスタに報告されるスレーブのホスト名または
            IP アドレス。これらは SHOW SLAVE
            HOSTS
            の出力に表示される。スレーブに自らをマスタに登録させない場合、設定しないままにしておく。注意:
            スレーブの接続後、マスタが TCP/IP
            ソケットからスレーブの IP
            アドレスを読み取るだけでは十分ではない。NAT
            および他のルーティングの事情により、この
            IP
            は、マスタまたは他のホストからスレーブに接続するのに有効ではない場合がある。
          
このオプションは MySQL 4.0.0 から利用可能。
            --report-port=port_number
          
スレーブの登録中にマスタに報告するスレーブの接続ポート。スレーブがデフォルト以外のポートをリッスンする場合、または、マスタやその他のクライアントとスレーブ間に特殊なトンネルがある場合だけ、これを設定する。わからない場合は、このオプションは設定しないでおく。
このオプションは MySQL 4.0.0 から利用可能。
            --skip-slave-start
          
            サーバの起動時にスレーブスレッドを開始しないようスレーブサーバに指示する。ユーザが後で
            START SLAVE
            を使用して、スレーブスレッドを開始できる。
          
            --slave_compressed_protocol=#
          
スレーブとクライアントの両方が圧縮をサポートしていれば、値が 1 の場合、そのプロトコルに圧縮が使用される。
            --slave-load-tmpdir=filename
          
            このオプションはデフォルトでは、tmpdir
            変数の値と同じになる。スレーブ SQL
            スレッドが LOAD DATA INFILE
            コマンドをレプリケートするとき、ロードするファイルをリレーログからテンポラリファイルに抽出して、それをテーブルにロードする。マスタにロードされたファイルが非常に大きい場合、スレーブのテンポラリファイルも巨大になる。そのため、tmpdir
            とは別の大きなディスクにテンポラリファイルを置くことが必要になる場合に、このオプションを使用する。その場合、リレーログも大きくなるため、--relay-log
            オプションも使用できる。--slave-load-tmpdir
            は、メモリベースではなく、ディスクベースのファイルシステムをポイントすることが必要。これは、LOAD
            DATA INFILE
            のレプリケートに使用されたテンポラリファイルが、マシンをリブートしても残っていることがスレーブにとって必要なためである。
          
            --slave-net-timeout=#
          
            接続が切断されたと判断して接続を再試行する際、そのために読み取りを中止する前に、マスタからのデータを待つ秒数。最初の再試行は、このタイムアウト直後に行われる。再試行の間隔は、--master-connect-retry
            オプションで制御する。
          
            --slave-skip-errors= [err_code1,err_code2,... |
            all]
          
指定したエラーをクエリが返しても、レプリケーションを続行するようスレーブ SQL スレッドに指示する。通常、エラーが発生するとレプリケーションは停止し、ユーザはデータの不整合を手動で解決できる。なぜエラー発生するのか原因を完全に理解していない場合には、このオプションを使用してはいけない。レプリケーションのセットアップに問題がなく、クライアントプログラムにもバグがなく、および MySQL 自体にもバグがなければ、エラーで中止になることはないはずである。このオプションを乱用すると、スレーブがマスタと大きく非同期となり、ユーザには問題発生の原因もわからなくなる。
            エラーコードには、スレーブエラーログのエラーメッセージおよび
            SHOW SLAVE STATUS
            の出力に示される番号を使用する必要がある。エラーメッセージの全一覧は、ソースディストリビューション内の
            Docs/mysqld_error.txt
            に記載されている。
            サーバのエラーコードの一覧は、項12.1. 「返されるエラー」
            にも記載されている。
          
            all
            の値を使用してすべてのエラーメッセージを無視することもできるが、これは使用すべきではない。言うまでもなく、それを使用すればデータの整合性が保証されない。使用した場合、スレーブのデータがマスタのデータと異なってしまう可能性が十分にある。
          
例:
--slave-skip-errors=1062,1053 --slave-skip-errors=all
        これらのオプションのうちいくつかは、すべての
        --replicate-*
        オプションのように、スレーブサーバの起動時のみ設定でき、実行中は設定できません。これは、将来解決する予定です。
      
        以下は、スレーブがクエリを実行するか無視するかを決定するための
        r--eplicate-*
        ルールの評価順序です。
      
            --replicate-do-db ルールまたは
            --replicate-ignore-db
            ルールがあるか。
          
                Yes: --binlog-do-db および
                --binlog-ignore-db
                と同じようにそれらをテストする(see
                項4.10.4. 「バイナリログ」)。その結果を見る。
              
ignore the query: 無視して終了する。
execute the query: すぐには実行せず、決定を保留して次のステップに進む。
No: 次のステップに移る。
            --replicate-*-table
            ルールはあるか。
          
No: クエリを実行して終了する。
                Yes:
                次のステップに移る。更新されるテーブルのみ、ルールと比較される(INSERT
                INTO sales SELECT * FROM prices
                では、sales
                のみルールと比較される)。複数のテーブルが更新される(複数テーブルステートメントの)場合、最初に一致したテーブル(``do''
                または ``ignore''
                と一致するテーブル)が対象となる(最初のテーブルがルールと比較され、それで決定できない場合は
                2
                番目のテーブルがルールと比較される)。
              
            --replicate-do-table
            ルールはあるか。
          
Yes: テーブルがいずれかに一致するか。
Yes: クエリを実行して終了する。
No: 次のステップに移る。
No: 次のステップに移る。
            --replicate-ignore-table
            ルールはあるか。
          
Yes: テーブルがいずれかに一致するか
Yes: クエリを無視して終了する。
No: 次のステップに移る。
No: 次のステップに移る。
            --replicate-wild-do-table
            ルールはあるか。
          
Yes: テーブルがいずれかに一致するか。
Yes: クエリを実行して終了する。
No: 次のステップに移る。
No: 次のステップに移る。
            --replicate-wild-ignore-table
            ルールはあるか。
          
Yes: テーブルがいずれかに一致するか。
Yes: クエリを無視して終了する。
No: 次のステップに移る。
No: 次のステップに移る。
            --replicate-*-table
            ルールはいずれも一致しなかった。
            これらのルールでテストするテーブルは他にあるか。
          
Yes: ループする。
                No:
                更新対象のすべてのテーブルをテストしたが、どのルールにも一致しなかった。
                --replicate-do-table または
                --replicate-wild-do-table
                ルールがあるか。
              
Yes: クエリを無視して終了する。
No: クエリを実行して終了する。
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.

