MySQL 5.1 リファレンスマニュアル :: 5 レプリケーション :: 5.1 レプリケーション設定 :: 5.1.3 レプリケーションのオプションと変数
« 5.1.2.3 ステートメント ベースと行ベースのレプリケーション比較

5.1.4 レプリケーションでの管理タスク »
Section Navigation      [Toggle]
  • 5.1 レプリケーション設定
  • 5.1.1 レプリケーションのセットアップ方法
  • 5.1.2 レプリケーション フォーマット
  • 5.1.3 レプリケーションのオプションと変数
  • 5.1.4 レプリケーションでの管理タスク

5.1.3. レプリケーションのオプションと変数

ここでは、スレーブ レプリケーション サーバに使用するオプションを説明します。これらのオプションはコマンド ラインまたはオプション ファイルで指定します。

マスタとスレーブ (複数) では、server-id オプションを使用して、ユニークなレプリケーション ID を設置します。それぞれのサーバには、 1 から 232 – 1 までの範囲のユニークな正整数を使用します。それぞれの ID は別の ID と重複しないようにしてください。例:server-id=3

バイナリ ロギングをコントロールするためにマスタ サーバに使用できるオプションは 項4.11.4. 「バイナリ ログ」 を参照してください。

スレーブ サーバ レプリケーション オプションのいくつかは、特別の方法で扱います。それぞれが無視される、という意味においては、スレーブの起動時に master.info ファイルが存在し、オプションの値を含む場合です。次のオプションはこのように扱います。

  • --master-host

  • --master-user

  • --master-password

  • --master-port

  • --master-connect-retry

  • --master-ssl

  • --master-ssl-ca

  • --master-ssl-capath

  • --master-ssl-cert

  • --master-ssl-cipher

  • --master-ssl-key

MySQL 5.1 の master.info ファイル フォーマットには、SSL オプションに対応する値を含みます。さらに、ファイルフォーマットは、その最初のラインとしてラインの数をファイルに含みます。(項5.5.5. 「レプリケーション リレーとステータス ファイル」 参照) 古いバージョン (MySQL 4.1.1以前) から新しいバージョンにアップグレードする場合は、新しいサーバは master.info ファイルを新しいフォーマットへ起動とともに自動的にアップグレードします。しかし、新しいサーバを古いバージョンにダウングレード (格下げ) する場合には、古いサーバを起動させる前に、まず手動で最初のラインを取り除く必要があります。

master.info ファイルが存在しない状態でスレーブ サーバを起動する場合には、オプション ファイルまたはコマンド ラインで指定されたルールの値が適用されます。これは、一番最初にレプリケーション スレーブとしてサーバを起動するとき、または RESET SLAVE の実行後にスレーブをシャットダウンし再起動した場合などに起こります。

master.info ファイルがスレーブ起動時に存在する場合は、サーバはそのファイル内にあるものを使用し、ファイルにリストされた値に呼応するオプションを無視します。このため、master.info の値に呼応するスタートアップ オプションとは異なる値でスレーブ サーバを起動する場合には、その異なる値が影響を与えることはありません。つまりサーバは master.info ファイルを使用し続けるということです。異なる値を使用するには、master.info ファイルを取り除いてから再起動するか、または CHANGE MASTER TO ステートメントを使用して、スレーブ実行中に値をリセットすることをお勧めします。

my.cnf ファイルで次のルールを指定したとします。

[mysqld]
master-host=some_host

レプリケーション スレーブとして初めてサーバを起動するとき、そのサーバは my.cnf ファイルからのオプションを読み込み、使用します。そして、master.info ファイルの値を記録します。そして、この次にサーバを起動するときには、master.info ファイルからの値をマスタ ホスト値として読み込み、オプション ファイルの値は無視されます。my.cnf ファイルを修正する場合に、some_other_host で別のサーバ ホストを指定するときには、この変更は反映されません。よって、CHANGE MASTER TO を使用します。

サーバが、記述したばかりのスタートアップ オプションよりも、既存 master.info ファイルを優先するため、これらの値をスタートアップ オプションに使用するよりも、CHANGE MASTER TO ステートメントを使用して値を指定する方が賢明です。詳細は、項12.6.2.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

次のリストは、レプリケーションをコントロールするオプションと変数について説明します。これらのオプションの多くは、CHANGE MASTER TO ステートメントを使用してサーバ実行中にリセットできます。しかし、--replicate-* のようなオプションは、スレーブ サーバが起動するときにだけセットできます。

  • --log-slave-updates

    スレーブは通常、マスタ サーバから受けるアップデートを自身のバイナリ ログに記録しない。つまり、スレーブの SQL スレッドで実行された更新を、スレーブのバイナリログに記録するようにスレーブに指示する。このオプションを有効にするには、バイナリログを有効にする --log-bin オプションを使用して、スレーブを起動する必要がある。レプリケーション サーバをチェーン状に構成するには、--log-slave-updates を使用する。たとえば、次のようにレプリケーション サーバをセットアップできる。

    A -> B -> C
    

    A はスレーブ B のマスタとして機能し、B はスレーブ C のマスタとして機能する。この構成では、B がマスタでもあり、スレーブでもある。 そのため、A と B は両方とも、--log-bin オプションでバイナリログを有効にして起動し、--log-slave-updates オプションで B を起動する必要がある。これにより、Aから受けたアップデートは B のバイナリ ログに記録される。

  • --log-warnings[=level]

    このオプションは、スレーブにより詳細なメッセージを出力させる。たとえば、ネットワークまたは接続が切断された後で再接続に成功したというメッセージや、それぞれのスレーブ スレッドがどのように開始したかについての情報メッセージを出力することができる。 このオプションはデフォルト設定。これを無効にするには、 --skip-log-warnings オプションを使用する。中断された接続は、その値が 1 を越えない限り、エラー ログには記録されない。

  • --master-connect-retry=seconds

    マスタがダウンするか接続不可の場合にマスタへ再接続を試行する前に、スレーブ スレッドがスリープ状態になる秒数。master.info ファイルの値が読み込れる場合、その値が優先される。設定しなければ、デフォルトで 60 秒。--slave-net-timeout の値に基づくマスタからのデータ読み込みに対してタイムアウトするまで、スレーブによる再接続の自動呼び出しは行われない。再接続の試行の回数は、--master-retry-count で制限する。

  • --master-host=host_name

    マスタ レプリケーション サーバのホスト名または IP アドレスを指定する。master.info の値を読み取れる場合は、ファイルで指定する値が優先になる。マスタ ホストを指定しない場合、スレーブ スレッドは開始されない。

  • --master-info-file=file_name

    マスタの情報をスレーブが記録するファイルに使う名前。デフォルトの名前は master.info で、データ ディレクトリにある。

  • --master-password=password

    マスタへの接続時に、スレーブスレッドが認証に使用するアカウントのパスワード。master.info の値を読み取れる場合は、この値が優先される。設定しなければ、空白パスワードと見なされる。

  • --master-port=port_number

    マスタがリスニングするTCP/IP ポート番号。 master.info の値を読み取れる場合、その値が優先される。 設定しなければ、コンパイルされた設定 (3306) が採用される。

  • --master-retry-count=count

    スレーブがギブアップするまで、マスタへの接続を試行する回数。再接続のインターバルは --master-connect-retry で設定する。再接続のトリガは、--slave-net-timeout オプションのスレーブのデータ読み込みのタイム アウトに基づく。デフォルト値は 86400。

  • --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 を使用してマスタ サーバに接続する安全なレプリケーション接続のセットアップに使用するオプション。 --ssl、--ssl-ca、--ssl-capath、--ssl-cert、--ssl-cipher、--ssl-key などの意義は、項4.8.7.3. 「SSL コマンド オプション」 を参照する。master.info ファイルのをが読み取れる場合は、それが優先される。

  • --master-user=user_name

    マスタへの接続時に、スレーブ スレッドが認証に使用するアカウントのユーザ名。アカウントには REPLICATION SLAVE 権限が必要。master.info の値を読み取れる場合は、その値が優先される。 マスタ ユーザ名が設定されていない場合、名前は test と想定する。

  • --max-relay-log-size=size

    サーバがリレー ログを自動的にローテートするサイズ。詳細は 項5.5.5. 「レプリケーション リレーとステータス ファイル」 を参照。

  • --read-only

    スレーブ スレッドまたは SUPER 権限を持つユーザ以外からはアップデートを受けないようにスレーブに設定。これで、スレーブ サーバがクライアントからのアップデートを受けないように設定できる。このオプションは TEMPORARY には適用されない。

  • --relay-log=file_name

    リレー ログの名前。デフォルトでは host_name-relay-bin.nnnnnn である。host_name はスレーブ サーバ ホストの名前、nnnnnn はシーケンス番号でのリレー ログ。このオプションを指定して、ホスト名とは独立したリレー ログ名を作成できる。あるいは、リレー ログが大きくなり、max_relay_log_size を下げない場合は、データ ディレクトリとは別の場所に置く必要がある。またはディスク間の負荷バランスにあわせてスピードを上げる場合にも使用できる。

  • --relay-log-index=file_name

    リレー ログ インデックス ファイルに使用する名前。デフォルトでは host_name-relay-bin.index で、データ ディレクトリにある。host_name はスレーブ サーバの名前。

  • --relay-log-info-file=file_name

    スレーブがリレー ログの情報を記録するファイルに使う名前。デフォルトの名前は relay-log.infoで、データ ディレクトリにある。

  • --relay-log-purge={0|1}

    リレー ログ ファイルが不要になったときの自動パージを有効または無効にする。デフォルト値は 1 (=有効)。 これは、SET GLOBAL relay_log_purge = N で動的に変更できるグローバル変数である。

  • --relay-log-space-limit=size

    このオプションは、スレーブのすべてのリレー ログの合計サイズ条件 (上限) を設定する。値 0 は 「無制限'」という意味。スレーブ サーバ ホストのハードディスクに限りが場合に便利である。上限に達すると、SQL スレッドが、キャッチアップしてクエリを実行し終えて、不要になったリレー ログを削除するまで、I/O スレッドがマスタ サーバからのバイナリ ログ イベントの読み込みを一時的に停止する。注意:この上限は絶対的なものではない。SQL スレッドがリレー ログを削除するためにさらにイベントを必要とする場合があり、その場合は削除が可能になるまで、I/O スレッドは制限を超えて続行する。続行しなければデッドロックが発生する。--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-db=db_name

    デフォルトのデータベース db_name のステートメントにレプリケーションを制限するようスレーブに指示する。つまり、USE で選択したもの。一つ以上のデータベースを指定するには、このコマンドを数回使用する。これは、クロス データベース ステートメントの複製には使用しない。これは、別のデータベースを選択、あるいはデータベースを全く選択しない、UPDATE some_db.some_table SET foo='bar' のようなものである。

    警告

    複数のデータベースを指定するには、このオプションに複数のインスタンスを使う必要がある。データベース名にはカンマが含まれているため、カンマ区切りのリストの場合に、リストが単一のデータベースの名前として扱われます。

    以下は、期待とは沿わない可能性がある事柄の一例です。--replicate-do-db=sales オプションでスレーブを起動し、マスタに次のステートメントを発行するが、UPDATE ステートメントが複製されない。

    USE prices;
    UPDATE sales.january SET amount=amount+1000;
    

    「 デフォルト データベースをチェックするだけ」 という動作の主な理由は、ステートメントだけでは複製をするべきかどうかの判断が難しいということである。たとえば、複数テーブルの DELETE ステートメント、または複製テーブルの UPDATE ステートメントの場合は、複数のデータベースに作用するこということである。さらに必要がない限り、すべてのデータベースよりも府デフォルト データベースだけをチェックする方が速いということである。

    クロス データベース アップデートを行うには、--replicate-wild-do-table=db_name.% を使用する方が好ましい。詳細は 項5.5.6. 「サーバのレプリケーション ルール評価」 を参照。

  • --replicate-do-table=db_name.tbl_name

    指定テーブルへのレプリケーションを限定するようスレーブスレッドに指示。一つ以上のテーブルを指定するには、これを数回使用する。これは、--replicate-do-db とは対照的に、クロス データベース アップデートに利用できる。詳細は 項5.5.6. 「サーバのレプリケーション ルール評価」 を参照。

  • --replicate-ignore-db=db_name

    db_name のデフォルト データベースである場合のステートメントを複製しないようスレーブに指示。このデータベースは、USE で選択したものである。無視するテーブルを一つ以上指定するには、このオプションを複数回使用する。クロス データベース アップデートを使用していて、そのアップデートを複製しない場合は、このオプションを使用しない。詳細は 項5.5.6. 「サーバのレプリケーション ルール評価」 を確認。

    以下は、期待とは沿わない可能性がある事柄の一例です。--replicate-ignore-db=sales オプションでスレーブを起動し、マスタに次のステートメントを発行するが、UPDATE ステートメントが複製される。

    USE prices;
    UPDATE sales.january SET amount=amount+1000;
    

    注意

    上記の例では、--replicate-ignore-db はデフォルト データベースだけに適用されるため、ステートメントの複製が行えます。(USE ステートメントで設定。) sales データベースはステートメントで明確に指定があったために、ステートメントはフィルタされない。

    クロス データベース アップデートを行うには、--replicate-wild-ignore-table=db_name.% を使用する方が好ましい。詳細は 項5.5.6. 「サーバのレプリケーション ルール評価」 を参照。

  • --replicate-ignore-table=db_name.tbl_name

    指定テーブルを更新するステートメントを複製しないようスレーブ スレッドに指示。同一のステートメントで別のテーブルが更新されている可能性がある場合でも。一つ以上のテーブルを指定するには、これを複数回、それぞれのテーブルに使用する。これは、--replicate-ignore-db とは対照的に、クロス データベース アップデートに利用できる。詳細は 項5.5.6. 「サーバのレプリケーション ルール評価」 を参照。

  • --replicate-rewrite-db=from_name->to_name

    デフォルト データベースをto_name にトランスレートするようスレーブに指示。このデータベースは、USE で選択したものであり、from_name がマスタのものである場合である。テーブルに関わるステートメントだけに影響し (CREATE DATABASE、DROP DATABASE、ALTER DATABASE などのステートメントは例外)、 from_name がマスタのデフォルト データベースである場合だけである。これはクロス データベース アップデートには利用できない。データベース名のトランスレーションは、 --replicate-* ルールでテストする前に行う。

    このオプションをコマンド ラインに使用し、‘>’ キャラクタがコマンドのインタープリタとして特別である場合は、オプション値を指定する。次はその例である。

    shell> mysqld --replicate-rewrite-db="olddb->newdb"
    
  • --replicate-same-server-id

    スレーブ サーバで使用する。循環レプリケーションによる無限ループを防ぐために、デフォルトでは 0 に設定されている。1 で設定する場合、スレーブは自身のサーバ ID を持つイベントをスキップしない。通常、これは特別なコンフィギュレーションでのみ有効である。--log-slave-updates を使用している場合は、1 を設定することはできない。デフォルトで、スレーブ I/O スレッドにスレーブ サーバの ID がある場合は、バイナリ ログにバイナリ ログ イベントを書き込まない。(スレーブ デスク使用量の最適化。) そのため、 --replicate-same-server-id を使用する場合は、スレーブがスレーブ SQL スレッドで実行するイベントを自分のものとして読み取るようにする前に、このオプションでスレーブを起動する。

  • --replicate-wild-do-table=db_name.tbl_name

    スレーブ スレッドにステートメントへのレプリケーションを制限するよう指示。このステートメントは指定のデータベースとテーブル名パターンと一致するテーブルのアップデートのことである。パターンには ‘%’ そして ‘_’ などのワイルドカード文字が含まれる。これは、LIKE パターン マッチング オペレータとして同一の意義を持つ。一つ以上のテーブルを指定するには。このオプションを複数回、それぞれのテーブルに使用する。クロス テーブル アップデートにも使用できる。詳細は項5.5.6. 「サーバのレプリケーション ルール評価」 を参照。

    例:--replicate-wild-do-table=foo%.bar% はデータベース名が foo で、テーブル名が bar で、それぞれ始まるテーブルを使用しているアップデートだけを複製する。

    テーブル名のパターンが % の場合、テーブル名と一致し、オプションはデータベース レベル ステートメントに適用する。(CREATE DATABASE、DROP DATABASE、ALTER DATABASE) たとえば、--replicate-wild-do-table=foo%.% オプションを使用する場合、データベース レベル ステートメントは、データベース名が foo% のパーターンと一致する場合に複製する。

    リテラルのワイルドカード文字をデータベースまたはテーブル名パターンに含むには、バックスラッシュでそれらをエスケープする。たとえば、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.tbl_name

    スレーブ スレッドにステートメントを複製しないように指示する。このステートメントは、任意のワイルドカード パターンと一致するテーブルもの。無視するテーブルを一つ以上指定するには、このオプションをそれぞれのテーブル毎に使用する。じれはクロス データベース アップデートでも利用できる。詳細は 項5.5.6. 「サーバのレプリケーション ルール評価」 を参照。

    例:--replicate-wild-ignore-table=foo%.bar% はデータベース名が foo で、テーブル名が bar で、それぞれ始まるテーブルを使用しているアップデートを複製しない。

    このマッチング (一致) がどのように行われるかは、--replicate-wild-do-table の詳細を参照のこと。オプション値にリテラルのワイルドカード文字を含むルールはに関しては、--replicate-wild-ignore-table と同様である。

  • --report-host=slave_name

    スレーブ レジストレーションでマスタにレポートするスレーブのホスト名または IP アドレス。この値はマスタ サーバの SHOW SLAVE HOSTS に出力される。スレーブ自体をマスタとして登録しない場合は、この値をそのままにしておく。スレーブ接続時に、マスタが単にTCP/IP ソケットからスレーブの IP アドレスを読み込む、ということは十分とは言えない。NAT およびルーティングの問題で、この IP はマスタまたは別のホストからスレーブへの接続に対して有効でない可能性がある。

  • --report-port=slave_port_num

    スレーブに接続するTCP/IP ポート番号。スレーブ登録でマスタにレポートする。スレーブが非デフォルトのポートでリスニングしている場合、または、マスタもしくは別のクライアントからスレーブへ特別のトンネルがある場合のみに設定する。これについて定かでない場合は、このオプションは使用しない。

  • --skip-slave-start

    スレーブ サーバにサーバ起動時にスレーブ スレッドを開始しないように指示。このスレッドを後で開始するには、START SLAVE ステートメントを使用する。

  • --slave_compressed_protocol={0|1}

    このオプションが 1 で設定する場合に、スレーブとマスタの両方がこれをサポートするときには、スレーブ/マスタ間に圧縮プロトコールを使用する。デフォルトは 0 (非圧縮)。

  • --slave-load-tmpdir=file_name

    スレーブが一時ファイルを作成するディレクトリの名前。このオプションは、デフォルトで tmpdir システム変数の値と同等である。スレーブ SQL スレッドは LOAD DATA INFILE ステートメントを複製するとき、リレー ログから一時ファイルにロードするファイルを抽出し、それをテーブルにロードする。マスタへのロード ファイルが大きい場合は、スレーブの一時ファイルも大きくなる。そのため、スレーブに一時ファイルを余裕があるファイルシステム内のディレクトリに置くよう指示することを検討するとよい。その場合、リレー ログもまた大きくなるため、そのファイルシステムのリレー ログを置くために --relay-log オプションを使用することを検討する。

    このオプションで指定するディレクトリはディスク ベースのファイルシステムを使用する。メモリ ベースのファイルシステムは不可。LOAD DATA INFILE での複製に使用する一時ファイルは、マシンの再起動に耐える必要があるためである。このディレクトリはまた、システム スタートアップのプロセスでオペレーティング システムによってクリアされたものとは別のものである必要がある。

  • --slave-net-timeout=seconds

    スレーブが読み取りを中止する前に、マスタからのデータを待つ秒数。スレーブが接続切断と判断して再接続を試行するときのもの。最初の接続試行はタイムアウト直後に行われる。再試行のインターバルは、--master-connect-retry オプションでコントロールできる。再接続の試行回数は --master-retry-count オプションで設定する。デフォルトでは、3600 秒 (1時間)。

  • --slave-skip-errors=[err_code1,err_code2,...|all]

    通常、スレーブでエラーが起こるとレプリケーションは停止する。これは、データの不一致を手動で解決する機会でもある。このオプションはスレーブ SQL スレッドにオプション値にリスト化したエラーをステートメントが返す場合でも、レプリケーションを続けるよう指示する。

    エラーの原因が明確ではない場合は、このオプションを使用しない。レプリケーション セットアップやクライアント プログラムにバグがなく、MySQL自体にもバグがない場合は、レプリケーションを抑制するエラーは起こり得ない。このオプションの無差別的な使用は、スレーブがマスタとの同期化を妨げることに繋がる。そのため、十分な理解が必要である。

    エラー コードに関しては、スレーブのエラー ログおよび SHOW SLAVE STATUS 出力のエラー メッセージによって提供される数字を使用する。サーバ エラー コードに関しては Error Codes and Messages を参照のこと。

    all を使用してスレーブにすべてのエラー メッセージを無視し、何が起きようとも複製を続けるよう指示ことも可能ではあるが、できるだけ、この値の使用は避ける。all を使用するということは、データの整合性を確証できない。これを行ったがために、スレーブとマスタのデータに相違が発生した場合に、バグ報告などでクレームしてはいけない。そのため、十分な注意が必要である。

    例:

    --slave-skip-errors=1062,1053
    --slave-skip-errors=all
    
Copyright © 1997, 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices
Top / Previous / Next / Up / Table of Contents
© 2010, Oracle Corporation and/or its affiliates