MySQL :: MySQL 5.6 リファレンスマニュアル :: 17.1.4.3 レプリケーションスレーブのオプションと変数

MySQL 5.6 リファレンスマニュアル / ... / レプリケーションスレーブのオプションと変数

17.1.4.3 レプリケーションスレーブのオプションと変数

オプションはコマンド行またはオプションファイルで指定します。多くのオプションは、サーバーの動作中に CHANGE MASTER TO ステートメントを使用して設定できます。システム変数値は SET を使用して指定します。

サーバー ID マスターと各スレーブでは、server-id オプションを使用して、範囲が 1 から 2³² − 1 の一意レプリケーション ID を確立する必要があります。「一意」とは、各 ID が、ほかのレプリケーションマスターまたはスレーブで使用されるほかのあらゆる ID とは異なっている必要があるということです。my.cnf ファイルの例:

[mysqld]
server-id=3

レプリケーションスレーブの起動オプション

このセクションでは、レプリケーションスレーブサーバーを制御するための起動オプションについて説明します。これらのオプションの多くは、サーバーの動作中に CHANGE MASTER TO ステートメントを使用して設定できます。--replicate-* などのその他のオプションは、スレーブサーバーが起動するときにのみ設定できます。レプリケーションに関連するシステム変数はこのセクションの後半で説明します。

--abort-slave-event-count

コマンド行形式 --abort-slave-event-count=#

型数値

デフォルト 0

最小値 0

このオプションが 0 (デフォルト) 以外の正の整数値に設定されると、次のようにレプリケーションの動作に影響します。スレーブ SQL スレッドが起動したあと、値ログイベントの実行が許可され、スレーブ SQL スレッドはマスターからのネットワーク接続が切断されたかのようにそれ以上イベントを受け取りません。スレーブのスレッドの実行は継続し、SHOW SLAVE STATUS からの出力には Slave_IO_Running および Slave_SQL_Running カラムの両方に Yes が表示されますが、それ以降のイベントはリレーログから読み取られません。

このオプションは、レプリケーションのテストとデバッグのために、MySQL テストスイートで内部的に使用されます。本番環境設定で使用することを想定していません。
--disconnect-slave-event-count

コマンド行形式 --disconnect-slave-event-count=#

型数値

デフォルト 0

このオプションは、レプリケーションのテストとデバッグのために、MySQL テストスイートで内部的に使用されます。
--log-slave-updates

コマンド行形式 --log-slave-updates

システム変数 log_slave_updates

スコープグローバル

動的いいえ

型ブール

デフォルト OFF

通常、スレーブはマスターサーバーから受け取った更新をそれ自身のバイナリログに書き込みません。このオプションによって、スレーブはその SQL スレッドによって実行される更新をそれ自身のバイナリログに書き込みます。このオプションを有効にするには、--log-bin オプションを使用してスレーブを起動してバイナリロギングを有効にする必要もあります。MySQL 5.5 より前では、--log-slave-updates オプションを使用しても、--log-bin オプションでサーバーを起動することなくサーバーは起動せず、エラーで失敗します。MySQL 5.6 では、警告が生成されるだけです。(Bug #44663) --log-slave-updates はレプリケーションサーバーをチェーンするときに使用されます。たとえば、このようにレプリケーションサーバーをセットアップするとします。
```
A -> B -> C
```
ここでは、A はスレーブ B のマスターとして機能し、B はスレーブ C のマスターとして機能します。これが機能するには、B はマスターかつスレーブである必要があります。バイナリロギングを有効にするために A と B の両方を --log-bin で起動し、A から受け取った更新が B によってそのバイナリログに記録されるように B を --log-slave-updates オプションで起動する必要があります。
--log-slow-slave-statements

コマンド行形式 --log-slow-slave-statements (≤ 5.6.10)

削除 5.6.11

型ブール

デフォルト OFF

スロークエリーログが有効化されている場合、このオプションはスレーブでの実行に long_query_time 秒を超える時間がかかったクエリーのロギングを有効にします。

このコマンド行オプションは MySQL 5.6.11 で削除され、log_slow_slave_statements システム変数によって置き換えられました。システム変数はオプションと同じ方法でコマンド行またはオプションファイルに設定できるため、サーバー起動時に何らかの変更を行う必要はありませんが、システム変数は実行時に値を検査または設定することも可能です。

コマンド行形式	`--abort-slave-event-count=#`
型	数値
デフォルト	`0`
最小値	`0`

コマンド行形式	`--disconnect-slave-event-count=#`
型	数値
デフォルト	`0`

コマンド行形式	`--log-slave-updates`
システム変数	`log_slave_updates`
スコープ	グローバル
動的	いいえ
型	ブール
デフォルト	`OFF`

コマンド行形式	`--log-slow-slave-statements` (≤ 5.6.10)
削除	5.6.11
型	ブール
デフォルト	`OFF`

--log-warnings[=level]

コマンド行形式	`--log-warnings[=#]`
システム変数	`log_warnings`
スコープ (≥ 5.6.4)	グローバル
スコープ (≤ 5.6.3)	グローバル、セッション
動的	はい
型	数値
デフォルト	`1`
最小値	`0`
最大値 (64 ビットプラットフォーム)	`18446744073709551615`
最大値 (32 ビットプラットフォーム)	`4294967295`

サーバーは、それが実行していることに関するメッセージをより多くエラーログに記録します。レプリケーションに関して、サーバーは、それがネットワークまたは接続障害後の再接続に成功したことの警告を生成し、各スレーブスレッドがどのように起動したかに関する情報を提供します。このオプションはデフォルトでは (1) が有効です。無効にするには、--log-warnings=0 を使用します。値が 1 より大きい場合、中止された接続がエラーログに書き込まれ、新しい接続の試行についてのアクセス拒否エラーが書き込まれます。セクションB.5.2.11「通信エラーおよび中止された接続」を参照してください。

注記

このオプションの影響はレプリケーションに制限されません。サーバーアクティビティー全体を対象として警告を生成します。

--master-info-file=file_name

コマンド行形式 --master-info-file=file_name

型ファイル名

デフォルト master.info

マスターの情報をスレーブが記録するファイルに使用する名前。データディレクトリ内のデフォルト名は master.info です。このファイルの形式については、セクション17.2.2.2「スレーブステータスログ」を参照してください。

コマンド行形式	`--master-info-file=file_name`
型	ファイル名
デフォルト	`master.info`

--master-retry-count=count

コマンド行形式	`--master-retry-count=#`
非推奨	5.6.1
型	数値
デフォルト	`86400`
最小値	`0`
最大値 (64 ビットプラットフォーム)	`18446744073709551615`
最大値 (32 ビットプラットフォーム)	`4294967295`

スレーブマスターに接続を試みる回数 (これを超えると中断)。再接続は、CHANGE MASTER TO ステートメントの MASTER_CONNECT_RETRY オプションによって設定された間隔で (デフォルトは 60) で試行されます。再接続は、--slave-net-timeout オプションに応じてスレーブによるデータ読み取りがタイムアウトしたときにトリガーされます。デフォルト値は 86400 です。値 0 は「永続」を意味し、スレーブは永久に接続を試みます。

このオプションは MySQL 5.6.1 以降で非推奨となり、将来の MySQL リリースで削除される予定です。代わりに、CHANGE MASTER TO ステートメントの MASTER_RETRY_COUNT オプションを使用するように、アプリケーションを更新してください。

--max-relay-log-size=size

コマンド行形式	`--max-relay-log-size=#`
システム変数	`max_relay_log_size`
スコープ	グローバル
動的	はい
型	数値
デフォルト	`0`
最小値	`0`
最大値	`1073741824`

このサイズで、サーバーはリレーログファイルを自動的にローテーションします。この値がゼロでない場合は、サイズがこの値を超えたときにリレーログは自動的にローテーションされます。この値がゼロ (デフォルト) の場合、リレーログローテーションが発生するサイズは max_binlog_size の値によって決められます。詳細については、セクション17.2.2.1「スレーブリレーログ」を参照してください。

--read-only

コマンド行形式 --read-only

システム変数 read_only

スコープグローバル

動的はい

型ブール

デフォルト false

スレーブがスレーブスレッドまたは SUPER 権限を持つユーザー以外からの更新を許可しなくなります。スレーブサーバーで、スレーブがクライアントからは受け付けず、確実にそのマスターサーバーからのみ更新を受け付けるようにするには、これが役立つ場合があります。この変数は TEMPORARY テーブルには適用されません。
--relay-log=file_name

コマンド行形式 --relay-log=file_name

システム変数 relay_log

スコープグローバル

動的いいえ

型ファイル名

リレーログのベース名。デフォルトベース名は host_name-relay-bin です。別のディレクトリを指定するために先頭に絶対パス名を付けたベース名が指定されないかぎり、サーバーはデータディレクトリにファイルを書き込みます。サーバーは、ベース名に数値サフィクスを追加することで、順番にリレーログファイルを作成します。

MySQL がサーバーオプションを解析する方法が原因で、このオプションを指定する場合は、値を指定する必要があります。デフォルトベース名はオプションが実際に指定されない場合にのみ使用されます。値を指定しないで --relay-log オプションを使用する場合、予期しない動作になる場合があります。この動作は、使用されるほかのオプション、それらが指定される順序、およびそれらがコマンド行でまたはオプションファイルのどちらで指定されたかに依存します。MySQL がサーバーオプションをどのように処理するかについて詳しくは、セクション4.2.3「プログラムオプションの指定」を参照してください。

このオプションを指定した場合、指定された値はリレーログインデックスファイルのベース名としても使用されます。--relay-log-index オプションを使用して別のリレーログインデックスファイルを指定することで、この動作をオーバーライドできます。

MySQL 5.6.5 以降は、サーバーがインデックスファイルからエントリを読み取るときに、エントリに相対パスが含まれるかどうかをチェックします。その場合、パスの相対部は --relay-log オプションを使用して設定された絶対パスに置き換わります。絶対パスは変わりません。このような場合、使用される新しいパスを有効にするために、インデックスを手動で編集する必要があります。MySQL 5.6.5 より前は、バイナリログまたはリレーログファイルの位置を変更するときは手動介入が必要でした。(Bug #11745230、Bug #12133)

次のタスクを実行するときに、--relay-log オプションが役立つ場合があります。
- 名前がホスト名に依存しないリレーログを作成する。
- リレーログが非常に大きくなる傾向があり、max_relay_log_size を小さくしたくないため、リレーログをデータディレクトリ以外の領域に置く必要がある場合。
- ディスク間のロードバランシングを使用して速度を上げるため。
MySQL 5.6.2 以降では、リレーログファイル名 (およびパス) を relay_log_basename システム変数から取得できます。
--relay-log-index=file_name

コマンド行形式 --relay-log-index=file_name

システム変数 relay_log_index

スコープグローバル

動的いいえ

型ファイル名

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

MySQL がサーバーオプションを解析する方法が原因で、このオプションを指定する場合は、値を指定する必要があります。デフォルトベース名はオプションが実際に指定されない場合にのみ使用されます。値を指定しないで --relay-log-index オプションを使用する場合、予期しない動作になる場合があります。この動作は、使用されるほかのオプション、それらが指定される順序、およびオプションがコマンド行またはオプションファイルのどちらで指定されたに依存します。MySQL がサーバーオプションをどのように処理するかについて詳しくは、セクション4.2.3「プログラムオプションの指定」を参照してください。

このオプションを指定した場合、指定される値はリレーログのベース名としても使用されます。--relay-log オプションを使用して別のリレーログファイルベース名を指定することで、この動作をオーバーライドできます。
--relay-log-info-file=file_name

コマンド行形式 --relay-log-info-file=file_name

型ファイル名

デフォルト relay-log.info

スレーブがリレーログの情報を記録するファイルに使用する名前。データディレクトリ内のデフォルト名は relay-log.info です。このファイルの形式については、セクション17.2.2.2「スレーブステータスログ」を参照してください。
--relay-log-purge={0|1}

コマンド行形式 --relay-log-purge

システム変数 relay_log_purge

スコープグローバル

動的はい

型ブール

デフォルト TRUE

リレーログファイルが不要になるとすぐに自動的にパージすることを無効または有効にします。デフォルト値は 1 (有効)です。これは SET GLOBAL relay_log_purge = N で動的に変更できるグローバル変数です。--relay-log-recovery オプションを使用するときにリレーログのパージを無効にすると、データ一貫性が危険にさらされるため、クラッシュセーフではありません。
--relay-log-recovery={0|1}

コマンド行形式 --relay-log-recovery

型ブール

デフォルト FALSE

サーバー起動直後のリレーログ自動リカバリを有効にします。リカバリプロセスでは、新しいリレーログファイルを作成し、SQL スレッド位置をこの新しいリレーログに初期化し、I/O スレッドを SQL スレッド位置に初期化します。その後、マスターからのリレーログ読み取りが続行されます。これは、破損した可能性のあるリレーログが処理されないことを保証するために、レプリケーションスレーブでクラッシュ後に使用してください。デフォルト値は 0 (無効)です。

クラッシュセーフなスレーブを提供するには、このオプションを有効にし (1 に設定)、--relay-log-info-repository を TABLE に設定し、relay-log-purge を有効にする必要があります。relay-log-purge が無効なときに --relay-log-recovery オプションを有効にすることで、パージされなかったファイルからリレーログを読み取り、データ矛盾が発生し、クラッシュセーフでなくなるリスクが抑止されます。詳細は、クラッシュセーフレプリケーションを参照してください。

MySQL 5.6.6 より前で、このオプションがマルチスレッドスレーブで有効の場合、スレーブはエラーで失敗し、そのスレーブで CHANGE MASTER TO を実行できません。MySQL 5.6.6 以降では、START SLAVE UNTIL SQL_AFTER_MTS_GAPS を使用してリレーログ内のギャップを処理できます。このステートメントを実行したあと、CHANGE MASTER TO を使用してこのスレーブを新しいマスターにフェイルオーバーできます。(Bug #13893363)

コマンド行形式	`--read-only`
システム変数	`read_only`
スコープ	グローバル
動的	はい
型	ブール
デフォルト	`false`

コマンド行形式	`--relay-log=file_name`
システム変数	`relay_log`
スコープ	グローバル
動的	いいえ
型	ファイル名

コマンド行形式	`--relay-log-index=file_name`
システム変数	`relay_log_index`
スコープ	グローバル
動的	いいえ
型	ファイル名

コマンド行形式	`--relay-log-purge`
システム変数	`relay_log_purge`
スコープ	グローバル
動的	はい
型	ブール
デフォルト	`TRUE`

--relay-log-space-limit=size

コマンド行形式	`--relay-log-space-limit=#`
システム変数	`relay_log_space_limit`
スコープ	グローバル
動的	いいえ
型	数値
デフォルト	`0`
最小値	`0`
最大値 (64 ビットプラットフォーム)	`18446744073709551615`
最大値 (32 ビットプラットフォーム)	`4294967295`

このオプションは、スレーブのすべてのリレーログの合計サイズ (バイト単位) の上限を設定します。値 0 は「制限なし」を表します。これは、ディスク領域が制限されているスレーブサーバーホストに役立ちます。制限に達した場合、SQL スレッドが追い付いて未使用のリレーログの一部を削除するまで、I/O スレッドはマスターサーバーからのバイナリログイベントの読み取りを停止します。この制限は絶対ではありません。SQL スレッドがリレーログを削除する前により多くのイベントを必要とする場合があります。その場合、SQL スレッドが一部のリレーログを削除できるようになるまで I/O スレッドは制限を超えます。そうしないとデッドロックになるためです。--relay-log-space-limit を --max-relay-log-size (または --max-relay-log-size が 0 の場合は --max-binlog-size) の値の 2 倍未満に設定しないでください。その場合、I/O スレッドが空き領域を待機する可能性があります。--relay-log-space-limit を超えたけれども、SQL スレッドはパージするリレーログを持たず、I/O スレッドを満たすことができないためです。この場合、I/O スレッドは強制的に --relay-log-space-limit を一時的に無視します。

--replicate-do-db=db_name

コマンド行形式 --replicate-do-db=name

型文字列

このオプションの影響は、ステートメントベースまたは行ベースのどちらのレプリケーションを使用中かによって異なります。

ステートメントベースのレプリケーション デフォルトデータベース (つまり、USE で選択されたもの) が db_name であるステートメントにレプリケーションを限定するように、スレーブ SQL スレッドに指示します。複数のデータベースを指定するには、このオプションを複数回 (データベースごとに 1 回) 使用します。ただし、このようにすると別のデータベースは選択される (またはデータベースが選択されない) けれども、UPDATE some_db.some_table SET foo='bar' などのクロスデータベースステートメントを複製しません。

警告

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

ステートメントベースレプリケーションを使用するときに期待するとおりに機能しない例: スレーブが --replicate-do-db=sales で起動され、マスターで次のステートメントを発行する場合、UPDATE ステートメントは複製されません。
```
USE prices;
UPDATE sales.january SET amount=amount+1000;
```
この「デフォルトデータベースだけをチェックする」動作の主な理由は、ステートメントだけから複製すべきかどうかを知るのが難しいためです (たとえば、複数のデータベースをまたがって動作する複数テーブルDELETE ステートメントまたは UPDATE ステートメントを使用する場合)。また、必要がない場合、すべてのデータベースではなくデフォルトデータベースだけをチェックする方が早いです。

行ベースのレプリケーション データベース db_name にレプリケーションを制限するように、スレーブ SQL スレッドに指示します。db_name に属するテーブルだけが変更されます。現在のデータベースはこれに影響しません。スレーブが --replicate-do-db=sales で起動され、行ベースレプリケーションが有効である場合、次のステートメントがマスターで実行されます。
```
USE prices;
UPDATE sales.february SET amount=amount+100;
```
スレーブ上の sales データベース内の february テーブルが UPDATE ステートメントに従って変更されます。これは USE ステートメントが発行されたかどうかに関係なく発生します。ただし、行ベースレプリケーションと --replicate-do-db=sales の使用時に、次のステートメントをマスターで発行してもスレーブに影響はありません。
```
USE prices;
UPDATE prices.march SET amount=amount-25;
```
ステートメント USE prices が USE sales に変更された場合でも、UPDATE ステートメントの結果は複製されません。

--replicate-do-db が行ベースレプリケーションとステートメントベースレプリケーションでどのように扱われるかについてもう 1 つ重要な違いは、複数のデータベースを参照するステートメントで発生します。スレーブが --replicate-do-db=db1 で起動され、次のステートメントがマスターで実行されるものとします。
```
USE db1;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
```
ステートメントベースレプリケーションを使用する場合、両方のテーブルがスレーブで更新されます。しかし、行ベースレプリケーションを使用するときは、table1 だけがスレーブで影響を受けます。table2 は別のデータベース内にあるため、スレーブ上の table2 は UPDATE によって変更されません。ここで、USE db1 ステートメントの代わりに、USE db4 ステートメントが使用されたものとします。
```
USE db4;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
```
このケースで、ステートメントベースレプリケーションを使用するときは、UPDATE ステートメントの影響はスレーブではありません。しかし、行ベースレプリケーションを使用する場合は、UPDATE はスレーブ上の table1 を変更しますが、table2 は変更しません。つまり、--replicate-do-db によって指定されたデータベース内のテーブルのみが変更され、デフォルトデータベースを選択してもこの動作に影響しません。

クロスデータベース更新を機能させる必要がある場合は、代わりに --replicate-wild-do-table=db_name.% を使用してください。セクション17.2.3「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。

注記

このオプションは、--binlog-do-db がバイナリロギングに影響するのと同じ方法でレプリケーションに影響し、--replicate-do-db がレプリケーション動作にどのように影響するかに対してレプリケーション形式がどのように影響するかは、--binlog-do-db 動作に対してロギング形式がどのように影響するかと同じです。

このオプションは、BEGIN、COMMIT、または ROLLBACK ステートメントに影響しません。
--replicate-ignore-db=db_name

コマンド行形式 --replicate-ignore-db=name

型文字列

--replicate-do-db と同様に、このオプションの影響はステートメントベースまたは行ベースのどちらのレプリケーションが使用されるかによって異なります。

ステートメントベースのレプリケーション デフォルトデータベース (つまり、USE で選択されたもの) が db_name であるステートメントを複製しないようにスレーブ SQL スレッドに指示します。

行ベースのレプリケーション データベース db_name 内のテーブルを更新しないようにスレーブ SQL スレッドに指示します。デフォルトデータベースは影響しません。

ステートメントベースレプリケーションを使用する場合、次の例は予期したとおりに機能しません。スレーブが --replicate-ignore-db=sales で起動され、次のステートメントをマスターで発行するものとします。
```
USE prices;
UPDATE sales.january SET amount=amount+1000;
```
このような場合 UPDATE ステートメントは複製されます。--replicate-ignore-db が (USE ステートメントで指定された) デフォルトデータベースにのみ適用されるためです。sales データベースがステートメントで明示的に指定されたため、ステートメントはフィルタされませんでした。しかし、行ベースレプリケーションを使用するときは、UPDATE ステートメントの影響はスレーブに伝達されず、sales.january テーブルのスレーブのコピーは変更されません。この例では、sales データベースのマスターのコピー内のテーブルに加えられたすべての変更は、--replicate-ignore-db=sales によってスレーブで無視されます。

無視するデータベースを複数指定するには、このオプションを複数回 (データベースごとに 1 回) 使用します。データベース名にカンマを含めることができるため、カンマで区切られたリストを指定すると、リストは単一データベースの名前として扱われます。

クロスデータベース更新を使用していて、これらの更新を複製したくない場合は、このオプションを使用しないでください。セクション17.2.3「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。

クロスデータベース更新を機能させる必要がある場合、代わりに --replicate-wild-ignore-table=db_name.% を使用してください。セクション17.2.3「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。

注記

このオプションは、--binlog-ignore-db がバイナリロギングに影響するのと同じ方法でレプリケーションに影響し、--replicate-ignore-db がレプリケーション動作にどのように影響するかに対してレプリケーション形式がどのように影響するかは、--binlog-ignore-db 動作に対してロギング形式がどのように影響するかと同じです。

このオプションは、BEGIN、COMMIT、または ROLLBACK ステートメントに影響しません。
--replicate-do-table=db_name.tbl_name

コマンド行形式 --replicate-do-table=name

型文字列

レプリケーションを特定のテーブルに制限するようにスレーブ SQL スレッドに指示することで、レプリケーションフィルタを作成します。複数のテーブルを指定するには、このオプションを複数回 (テーブルごとに 1 回) 使用します。--replicate-do-db とは対照的に、これはクロスデータベース更新とデフォルトデータベース更新の両方に機能します。セクション17.2.3「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。

このオプションは、テーブルに適用されるステートメントにのみ影響します。ストアドルーチンなど、ほかのデータベースオブジェクトにのみ適用されるステートメントには影響しません。ストアドルーチンに作用するステートメントをフィルタするには、1 つまたは複数の --replicate-*-db オプションを使用します。
--replicate-ignore-table=db_name.tbl_name

コマンド行形式 --replicate-ignore-table=name

型文字列

指定されたテーブルを更新するステートメントを複製しないように (ほかのテーブルが同じステートメントによって更新される可能性があったとしても) スレーブ SQL スレッドに指示することで、レプリケーションフィルタを作成します。無視するテーブルを複数指定するには、このオプションを複数回 (テーブルごとに 1 回) 使用します。--replicate-ignore-db とは対照的に、これはクロスデータベース更新に機能します。セクション17.2.3「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。

このオプションは、テーブルに適用されるステートメントにのみ影響します。ストアドルーチンなど、ほかのデータベースオブジェクトにのみ適用されるステートメントには影響しません。ストアドルーチンに作用するステートメントをフィルタするには、1 つまたは複数の --replicate-*-db オプションを使用します。
--replicate-rewrite-db=from_name->to_name

コマンド行形式 --replicate-rewrite-db=old_name->new_name

型文字列

デフォルトデータベース (つまり、USE で選択されたもの) を to_name に変換するレプリケーションフィルタを作成するように (それがマスター上の from_name であった場合)、スレーブに指示します。(CREATE DATABASE、DROP DATABASE、ALTER DATABASE などのステートメントではなく) テーブルに関係するステートメントだけが影響されます (from_name がマスター上のデフォルトデータベースの場合のみ)。複数の書き換えを指定するには、複数回このオプションを使用します。サーバーは、一致する from_name 値で最初のものを使用します。データベース名変換は、--replicate-* ルールがテストされる前に行われます。

このオプションを使用するときにテーブル名がデータベース名で修飾されるステートメントは、--replicate-do-table などのテーブルレベルレプリケーションフィルタリングオプションで機能しません。名前が a のデータベースがマスター上にあり、名前が b のものがスレーブ上にあり、それぞれにテーブル t が含まれ、--replicate-rewrite-db='a->b' でマスターを起動したものとします。あとで、DELETE FROM a.t を実行します。この場合、関連のあるフィルタリングルールは、次に示した理由で機能しません。
1. テーブル t がスレーブのデータベース b 内にあるため、--replicate-do-table=a.t は機能しません。
2. --replicate-do-table=b.t は、元のステートメントを照合しないため無視されます。
3. --replicate-do-table=*.t も、--replicate-do-table=a.t と同等に処理されるため機能しません。
同様に、--replication-rewrite-db オプションはクロスデータベース更新では機能しません。

このオプションをコマンド行で使用するときに、「>」がコマンドインタープリターに固有である場合は、オプション値を引用符で囲みます。例:
```
shell> mysqld --replicate-rewrite-db="olddb->newdb"
```
注記

MySQL 5.6.7 より前では、マルチスレッドスレーブはこのオプションを正しく処理しませんでした。(Bug #14232958)
--replicate-same-server-id

コマンド行形式 --replicate-same-server-id

型ブール

デフォルト FALSE

スレーブサーバーで使用されるべきです。循環レプリケーションの原因となる無限ループを避けるため、通常はデフォルト設定の 0 を使用してください。1 に設定すると、スレーブはそれ自身のサーバー ID を持つイベントをスキップしません。通常は、これはまれな構成でのみ役立ちます。--log-slave-updates が使用されている場合、1 に設定できません。デフォルトでは、バイナリログイベントのサーバー ID がスレーブのものである場合、スレーブ I/O スレッドはリレーログにそれらを書き込みません (この最適化はディスク使用量の節約に役立ちます)。--replicate-same-server-id を使用する場合、このオプションでスレーブを確実に起動してから、スレーブ SQL スレッドで実行したいスレーブ独自のイベントをスレーブで読み取ってください。
--replicate-wild-do-table=db_name.tbl_name

コマンド行形式 --replicate-wild-do-table=name

型文字列

更新されるテーブルが指定されたデータベースおよびテーブル名パターンに一致するステートメントにレプリケーションを制限するようにスレーブスレッドに指示することで、レプリケーションフィルタを作成します。パターンには「%」および「_」ワイルドカード文字を含めることができます。これらは LIKE パターンマッチング演算子と同じ意味を持ちます。複数のテーブルを指定するには、このオプションを複数回 (テーブルごとに 1 回) 使用します。これはクロスデータベース更新に役立ちます。セクション17.2.3「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。

このオプションはテーブル、ビュー、およびトリガーに適用されます。ストアドプロシージャーと関数、またはイベントには適用されません。後者のオブジェクトで作用するステートメントをフィルタするには、1 つまたは複数の --replicate-*-db オプションを使用します。

例: --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

コマンド行形式 --replicate-wild-ignore-table=name

型文字列

何らかのテーブルが指定されたワイルドカードパターンに一致するステートメントをスレーブスレッドが複製するのを抑止する、レプリケーションフィルタを作成します。無視するテーブルを複数指定するには、このオプションを複数回 (テーブルごとに 1 回) 使用します。これはクロスデータベース更新に役立ちます。セクション17.2.3「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。

例: --replicate-wild-ignore-table=foo%.bar% は、データベース名が foo で始まりテーブル名が bar で始まるテーブルを使用する更新を複製しません。

照合の仕組みについては、--replicate-wild-do-table オプションの説明を参照してください。オプション値にリテラルワイルドカード文字を含めるためのルールは、--replicate-wild-ignore-table 場合と同じです。
--report-host=host_name

コマンド行形式 --report-host=host_name

システム変数 report_host

スコープグローバル

動的いいえ

型文字列

スレーブ登録中にマスターに報告されるスレーブのホスト名または IP アドレス。この値は、マスターサーバーでの SHOW SLAVE HOSTS の出力に出現します。マスターにスレーブ自身を登録しない場合は、値を設定しないままにします。

注記

スレーブ接続後にマスターが TCP/IP ソケットからスレーブの IP アドレスを読み取るだけでは十分ではありません。NAT およびその他のルーティングの問題により、その IP はマスターまたはほかのホストからスレーブへの接続に有効でない可能性があります。
--report-password=password

コマンド行形式 --report-password=name

システム変数 report_password

スコープグローバル

動的いいえ

型文字列

スレーブ登録中にマスターに報告されるスレーブのアカウントパスワード。この値は、--show-slave-auth-info オプションが指定された場合にマスターサーバーでの SHOW SLAVE HOSTS の出力に出現します。

このオプションの名前は別の方法で暗示されることもありますが、--report-password は MySQL ユーザー権限システムに接続されないため、MySQL レプリケーションユーザーアカウントのパスワードとは必ずしも同じとはかぎりません（または同じである可能性は高くありません）。

コマンド行形式	`--replicate-do-db=name`
型	文字列

コマンド行形式	`--replicate-ignore-db=name`
型	文字列

コマンド行形式	`--replicate-do-table=name`
型	文字列

コマンド行形式	`--replicate-ignore-table=name`
型	文字列

コマンド行形式	`--replicate-rewrite-db=old_name->new_name`
型	文字列

コマンド行形式	`--replicate-same-server-id`
型	ブール
デフォルト	`FALSE`

コマンド行形式	`--replicate-wild-do-table=name`
型	文字列

コマンド行形式	`--replicate-wild-ignore-table=name`
型	文字列

コマンド行形式	`--report-host=host_name`
システム変数	`report_host`
スコープ	グローバル
動的	いいえ
型	文字列

コマンド行形式	`--report-password=name`
システム変数	`report_password`
スコープ	グローバル
動的	いいえ
型	文字列

--report-port=slave_port_num

コマンド行形式	`--report-port=#`
システム変数	`report_port`
スコープ	グローバル
動的	いいえ
型	数値
デフォルト (≥ 5.6.5)	`[slave_port]`
デフォルト (≤ 5.6.4)	`0`
最小値	`0`
最大値	`65535`

スレーブに接続するための TCP/IP ポート番号で、スレーブ登録中にマスターに報告されます。スレーブが非デフォルトポートで待機している場合、またはマスターまたはほかのクライアントからスレーブへの特別なトンネルがある場合にのみ、これを設定します。確実でない場合は、このオプションを使用しないでください。

MySQL 5.6.5 より前は、このオプションのデフォルト値は 3306 でした。MySQL 5.6.5 以降では、表示される値はスレーブで実際に使用されるポート番号です (Bug #13333431)。この変更は SHOW SLAVE HOSTS によって表示されるデフォルト値にも影響します。

--report-user=user_name

コマンド行形式 --report-user=name

システム変数 report_user

スコープグローバル

動的いいえ

型文字列

スレーブ登録中にマスターに報告されるスレーブのアカウントユーザー名。この値は、--show-slave-auth-info オプションが指定された場合にマスターサーバーでの SHOW SLAVE HOSTS の出力に出現します。

このオプションの名前は別の方法で暗示されることもありますが、--report-user は MySQL ユーザー権限システムに接続されないため、MySQL レプリケーションユーザーアカウントの名前とは必ずしも同じとはかぎりません（または同じである可能性は高くありません）。
--show-slave-auth-info

コマンド行形式 --show-slave-auth-info

型ブール

デフォルト FALSE

--report-user および --report-password オプションで起動されたスレーブのマスターサーバーでの、SHOW SLAVE HOSTS の出力にスレーブユーザー名とパスワードを表示します。
--slave-checkpoint-group=#

コマンド行形式 --slave-checkpoint-group=#

導入 5.6.3

型数値

デフォルト 512

最小値 32

最大値 524280

ブロックサイズ 8

SHOW SLAVE STATUS によって表示されるマルチスレッドスレーブステータスを更新するためにチェックポイント操作が呼び出される前に、スレーブが処理できる最大トランザクション数を設定します。このオプションを設定しても、マルチスレッドが有効でないスレーブには影響しません。

このオプションは、--slave-checkpoint-period オプションとの組み合わせで、どちらかの制限を超えたときに、チェックポイントが実行され、トランザクションの数と最後のチェックポイントから経過した時間の両方を追跡するカウンタがリセットされる、という方法で機能します。

このオプションの最小許容値は 32 です (サーバーが -DWITH_DEBUG を使用して構築された場合を除く、その場合の最小値は 1)。効果的な値は常に 8 の倍数です。そのような倍数でない値に設定することもできますが、サーバーは値を格納する前に次に小さい 8 の倍数に丸めます。(例外: このような丸めはデバッグサーバーでは実行されません。)サーバーの構築方法にかかわらず、デフォルト値は 512 であり、最大許容値は 524280 です。

--slave-checkpoint-group は MySQL 5.6.3 で追加されました。
--slave-checkpoint-period=#

コマンド行形式 --slave-checkpoint-period=#

導入 5.6.3

型数値

デフォルト 300

最小値 1

最大値 4G

Unit millisecond

SHOW SLAVE STATUS によって表示されるマルチスレッドのスレーブステータスを更新するためにチェックポイント操作が呼び出される前に、経過できる最大時間（ミリ秒単位）を設定します。このオプションを設定しても、マルチスレッドが有効でないスレーブには影響しません。

このオプションは、--slave-checkpoint-group オプションとの組み合わせで、どちらかの制限を超えたときに、チェックポイントが実行され、トランザクションの数と最後のチェックポイントから経過した時間の両方を追跡するカウンタがリセットされる、という方法で機能します。

このオプションの最小許容値は 1 です (サーバーが -DWITH_DEBUG を使用して構築された場合を除く、その場合の最小値は 0)。サーバーの構築方法にかかわらず、デフォルト値は 300 であり、最大可能値は 4294967296 (4G バイト) です。

--slave-checkpoint-period は MySQL 5.6.3 で追加されました。
--slave-parallel-workers

コマンド行形式 --slave-parallel-workers=#

導入 5.6.3

型数値

デフォルト 0

最小値 0

最大値 1024

レプリケーションイベント（トランザクション）を並列に実行するためのスレーブワーカースレッドの数を設定します。この変数を 0 (デフォルト) に設定すると、並列実行が無効になります。最大値は 1024 です。

並列実行が有効のときは、スレーブ SQL スレッドはスレーブワーカースレッドのコーディネーターとして機能し、トランザクションはそれらにデータベースごとに分散されます。これは、スレーブ上のワーカースレッドは、ほかのデータベースへの更新が完了するのを待たずに、所定のデータベースに基づいてトランザクションを次々に処理できることを意味します。スレーブでのマルチスレッドの現在の実装は、データがデータベースごとに分割されていて、所定のデータベース内の更新が正しく機能するようにマスターの場合と同様に相対順序で行われることを前提としています。ただし、2 つのデータベース間でトランザクションを調整する必要はありません。

異なるデータベースでのトランザクションは、スレーブではマスターとは異なる順序が実行されることがあるという事実のため、最後に実行されたトランザクションをチェックしても、マスターからの以前のすべてのトランザクションがスレーブ上で実行されたことが保証されません。これは、マルチスレッド化したスレーブを使用する場合にロギングとリカバリに影響します。スレーブ上でマルチスレッドを使用したときにバイナリロギング情報をどのように解釈すればよいかについては、セクション13.7.5.35「SHOW SLAVE STATUS 構文」を参照してください。また、START SLAVE UNTIL がマルチスレッドスレーブでサポートされないことを意味します。

マルチスレッドが有効のときは、slave_transaction_retries は 0 に等しいとして処理され、変更できません。(現在のところ、トランザクションの再試行はマルチスレッドスレーブではサポートされません。)

MySQL 5.6.7 以降では、異なるデータベース内のテーブル間に外部キー関係を適用すると、マルチスレッドスレーブが並列モードではなくシーケンシャルを使用することになり、これがパフォーマンスに悪影響を与える可能性があることも認識するようにしてください。(Bug #14092635)

このオプションは MySQL 5.6.3 で追加されました。

注記

このオプション (または対応する slave_parallel_workers システム変数) に設定される値は、MySQL 5.6.3 で正しく処理されるとはかぎりません。この問題は MySQL 5.6.4 で修正されました (Bug #13334470)。
--slave-pending-jobs-size-max=#

コマンド行形式 --slave-pending-jobs-size-max=#

導入 5.6.3

型数値

デフォルト 16M

最小値 1024

最大値 18EB

Unit bytes

ブロックサイズ 1024

マルチスレッドスレーブの場合、このオプションは、まだ適用されていないイベントを保持するスレーブワーカーキューに使用可能な最大メモリー量 (バイト単位) を設定します。このオプションを設定しても、マルチスレッドが有効でないスレーブには影響しません。

このオプションの可能な最小値は 1024 で、デフォルトは 16M バイトです。可能な最大値は 18446744073709551615 (16E バイト) です。1024 の正確な倍数でない値は、保存される前に次に大きい 1024 の倍数に丸められます。

重要

このオプションの値はマスターの max_allowed_packet の値以上である必要があります。そうでない場合は、マスターから到着する処理すべきイベントが残っているときにスレーブワーカーキューがいっぱいになる場合があります。

このオプションは MySQL 5.6.3 で追加されました。
--skip-slave-start

コマンド行形式 --skip-slave-start

型ブール

デフォルト FALSE

サーバーの起動時にスレーブスレッドを起動しないように、スレーブサーバーに指示します。スレッドをあとで起動するには、START SLAVE ステートメントを使用します。
--slave_compressed_protocol={0|1}

コマンド行形式 --slave-compressed-protocol

システム変数 slave_compressed_protocol

スコープグローバル

動的はい

型ブール

デフォルト OFF

このオプションが 1 に設定されている場合は、スレーブとマスターの両方がサポートしている場合は、マスター/スレーブプロトコルに圧縮を使用します。デフォルトは 0 (圧縮なし) です。
--slave-load-tmpdir=file_name

コマンド行形式 --slave-load-tmpdir=path

システム変数 slave_load_tmpdir

スコープグローバル

動的いいえ

型ディレクトリ名

デフォルト /tmp

スレーブが一時ファイルを作成するディレクトリの名前。このオプションはデフォルトでは、tmpdir システム変数の値と同じです。スレーブ SQL スレッドは、LOAD DATA INFILE ステートメントを複製するときに、リレーログからロードされるファイルを一時ファイルに抽出してから、それらをテーブルにロードします。マスターでロードされるファイルが非常に大きい場合は、スレーブの一時ファイルも非常に大きくなります。このため、このオプションを使用して、利用可能な多くの空き領域を持つファイルシステム内にあるディレクトリに一時ファイルを置くように、スレーブに指示することをお勧めします。この場合、リレーログも非常に大きいため、--relay-log オプションを使用してそのファイルシステムにリレーログも置くことをお勧めします。

このオプションで指定するディレクトリは (メモリーベースファイルシステムではなく) ディスクベースファイルシステムに配置してください。LOAD DATA INFILE の複製に使用される一時ファイルがマシン再起動後も存続する必要があるためです。このディレクトリは、システム起動プロセス中にオペレーティングシステムによってクリアされるものではいけません。
slave-max-allowed-packet=bytes

コマンド行形式 --slave-max-allowed-packet=#

導入 5.6.6

型数値

デフォルト 1073741824

最小値 1024

最大値 1073741824

MySQL 5.6.6 以降では、このオプションがスレーブ SQL スレッドおよび I/O スレッドの最大パケットサイズ（バイト単位）を設定するので、行ベースレプリケーションを使用する大きな更新が max_allowed_packet を超えていることが原因でレプリケーションが失敗することはありません。(Bug #12400221、Bug #60926)

対応するサーバー変数 slave_max_allowed_packet は常に、1024 の正の整数の倍数である値を持ちます。このような倍数でない値に設定しても、値は次に大きい 1024 の倍数に自動的に丸められます。(たとえば、--slave-max-allowed-packet=10000 でサーバーを起動する場合、使用される値は 9216 です。値として 0 に設定すると、1024 が使用されます。)このような場合、切り捨ての警告が発行されます。

最大 (およびデフォルト) 値は 1073741824 (1G バイト) で、最小は 1024 です。
--slave-net-timeout=seconds

コマンド行形式 --slave-net-timeout=#

システム変数 slave_net_timeout

スコープグローバル

動的はい

型数値

デフォルト 3600

最小値 1

マスターからの後続のデータを待機する秒数 (これ以降は、スレーブは接続が切断されていると見なし、読み取りを中止し、再接続を試行)。最初の再試行はタイムアウトの直後に発生します。再試行の間隔は CHANGE MASTER TO ステートメントの MASTER_CONNECT_RETRY オプションで制御され、再接続の試行回数は --master-retry-count オプションによって制限されます。デフォルトは 3600 秒 (1 時間) です。

コマンド行形式	`--report-user=name`
システム変数	`report_user`
スコープ	グローバル
動的	いいえ
型	文字列

コマンド行形式	`--show-slave-auth-info`
型	ブール
デフォルト	`FALSE`

コマンド行形式	`--slave-pending-jobs-size-max=#`
導入	5.6.3
型	数値
デフォルト	`16M`
最小値	`1024`
最大値	`18EB`
Unit	`bytes`
ブロックサイズ	`1024`

コマンド行形式	`--skip-slave-start`
型	ブール
デフォルト	`FALSE`

コマンド行形式	`--slave-compressed-protocol`
システム変数	`slave_compressed_protocol`
スコープ	グローバル
動的	はい
型	ブール
デフォルト	`OFF`

コマンド行形式	`--slave-load-tmpdir=path`
システム変数	`slave_load_tmpdir`
スコープ	グローバル
動的	いいえ
型	ディレクトリ名
デフォルト	`/tmp`

コマンド行形式	`--slave-max-allowed-packet=#`
導入	5.6.6
型	数値
デフォルト	`1073741824`
最小値	`1024`
最大値	`1073741824`

コマンド行形式	`--slave-net-timeout=#`
システム変数	`slave_net_timeout`
スコープ	グローバル
動的	はい
型	数値
デフォルト	`3600`
最小値	`1`

slave-rows-search-algorithms=list

コマンド行形式	`--slave-rows-search-algorithms=list`
導入	5.6.6
型	セット
デフォルト	`TABLE_SCAN,INDEX_SCAN`
有効な値	`TABLE_SCAN,INDEX_SCAN` `INDEX_SCAN,HASH_SCAN` `TABLE_SCAN,HASH_SCAN` `TABLE_SCAN,INDEX_SCAN,HASH_SCAN` (INDEX_SCAN,HASH_SCAN と同等)

slave_allow_batching を使用して行ベースロギングとレプリケーションのために大量の行を準備するときに、このオプションは行の一致がどのように検索されるか、つまり、主キー、一意キー、または何らかのほかのキーを使用する検索、またはキーをまったく使用しない検索にハッシュを使用するかどうかを制御します。このオプションは、リスト INDEX_SCAN、TABLE_SCAN、HASH_SCAN から 2 つの値（または 3 つも可）のカンマ区切りリストを取ります。リストを引用符で囲む必要はありませんが、引用符を使用するかどうかにかかわらず、リストに空白文字を含めてはいけません。可能な組み合わせ (リスト) とその結果を次の表に示します。

使用されるインデックス/オプション値	`INDEX_SCAN,HASH_SCAN` または `INDEX_SCAN,TABLE_SCAN,HASH_SCAN`	`INDEX_SCAN,TABLE_SCAN`	`TABLE_SCAN,HASH_SCAN`
主キーまたは一意キー	インデックススキャン	インデックススキャン	インデックスに基づくハッシュスキャン
(ほかの) キー	インデックスに基づくハッシュスキャン	インデックススキャン	インデックスに基づくハッシュスキャン
インデックスなし	ハッシュスキャン	テーブルスキャン	ハッシュスキャン

リスト内でアルゴリズムが指定される順序は、SELECT または SHOW VARIABLES ステートメントで表示される順序と違いはありません (直前に示した表で使用されるものと同じ)。デフォルト値は TABLE_SCAN,INDEX_SCAN で、これはインデックスを使用できるすべての検索はそれらを使用し、インデックスなしの検索はテーブルスキャンを使用することを意味します。

INDEX_SCAN,TABLE_SCAN,HASH_SCAN を指定することは、INDEX_SCAN,HASH_SCAN を指定する場合と同じ結果になります。主キーまたは一意キーを使用しない検索にハッシュを使用するには、このオプションを INDEX_SCAN,HASH_SCAN に設定します。すべての検索にハッシュを強制的に使用するには、TABLE_SCAN,HASH_SCAN に設定します。

このオプションは MySQL 5.6.6 で追加されました。

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

コマンド行形式	`--slave-skip-errors=name`
システム変数	`slave_skip_errors`
スコープ	グローバル
動的	いいえ
型	文字列
デフォルト	`OFF`
有効な値	`OFF` `[list of error codes]` `all` `ddl_exist_errors`
有効な値	`OFF` `[list of error codes]` `all` `ddl_exist_errors`
有効な値	`OFF` `[list of error codes]` `all`

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

このオプションは、エラーが発生している理由を完全に理解しないかぎり使用しないでください。レプリケーションセットアップとクライアントプログラムにバグがなく、MySQL 自体にバグがない場合は、レプリケーションを停止するエラーは発生しないはずです。このオプションを無計画に使用すると、スレーブとマスターの同期が絶望的に取れなくなり、これがなぜ発生したかの見当がつかなくなります。

エラーコードについては、スレーブエラーログおよび SHOW SLAVE STATUS の出力のエラーメッセージによって提供される数値を使用してください。付録B「エラー、エラーコード、および一般的な問題」にはサーバーエラーコードがリストされています。

非推奨値 all を使用して、スレーブにすべてのエラーメッセージを無視させて、何が発生しても継続させることもできます（ただし、使用すべきではありません）。言うまでもなく、all を使用した場合、データの完全性に関して保証はありません。スレーブのデータがマスター上のものとかなり違っていても不満を言わないで下さい（バグレポートを出さないでください）。以上のことを警告しました。

MySQL 5.6 と MySQL Cluster NDB 7.3 以降では、追加の簡略版 ddl_exist_errors がサポートされ、これはエラーコードリスト 1007,1008,1050,1051,1054,1060,1061,1068,1094,1146 に相当します。

例:

--slave-skip-errors=1062,1053
--slave-skip-errors=all
--slave-skip-errors=ddl_exist_errors

--slave-sql-verify-checksum={0|1}

コマンド行形式 --slave-sql-verify-checksum=value

導入 5.6.2

型ブール

デフォルト 0

有効な値
0

1

このオプションが有効のときは、スレーブはリレーログから読み取られたチェックサムを調べて、不一致があった場合にスレーブはエラーで停止します。デフォルトで無効になっています。

このオプションは MySQL 5.6.2 で追加されました。

コマンド行形式	`--slave-sql-verify-checksum=value`
導入	5.6.2
型	ブール
デフォルト	`0`
有効な値	`0` `1`

スレーブステータスログをテーブルに記録するためのオプション

MySQL 5.6 以降では、レプリケーションスレーブステータス情報をファイルではなくテーブルに記録できます。マスター情報ログおよびリレーログ情報ログの書き込みは、ここで示す、MySQL 5.6.2 で追加された 2 つのサーバーオプションを使用して個別に構成できます。

--master-info-repository={FILE|TABLE}

コマンド行形式 --master-info-repository=FILE|TABLE

導入 5.6.2

型文字列

デフォルト FILE

有効な値
FILE

TABLE

このオプションにより、サーバーはそのマスター情報ログをファイルまたはテーブルに書き込みます。ファイル名はデフォルトで master.info になります。ファイルの名前は --master-info-file サーバーオプションを使用して変更できます。

このオプションのデフォルト値は FILE です。TABLE を使用する場合、ログは mysql データベースの slave_master_info テーブルに書き込まれます。

--master-info-repository オプションは MySQL 5.6.2 で追加されました。
--relay-log-info-repository={FILE|TABLE}

コマンド行形式 --relay-log-info-repository=FILE|TABLE

導入 5.6.2

型文字列

デフォルト FILE

有効な値
FILE

TABLE

このオプションにより、サーバーはそのリレーログ情報のログをファイルまたはテーブルに記録します。ファイル名はデフォルトで relay-log.info になります。ファイルの名前は --relay-log-info-file サーバーオプションを使用して変更できます。

このオプションのデフォルト値は FILE です。TABLE を使用する場合、ログは mysql データベースの slave_relay_log_info テーブルに書き込まれます。

レプリケーションをクラッシュセーフにするために、このオプションは TABLE に設定する必要があります。さらに、--relay-log-recovery オプションを有効にする必要があります。詳細は、クラッシュセーフレプリケーションを参照してください。

--relay-log-info-repository オプションは MySQL 5.6.2 で追加されました。

コマンド行形式	`--relay-log-info-repository=FILE\|TABLE`
導入	5.6.2
型	文字列
デフォルト	`FILE`
有効な値	`FILE` `TABLE`

情報ログテーブルとその内容は、所定の MySQL Server にローカルと見なされます。MySQL 5.6.9 以降では、それらは複製されず、それらへの変更はバイナリログに書き込まれません。(Bug #14741537)

詳細については、セクション17.2.2「レプリケーションリレーおよびステータスログ」を参照してください。

廃止されたレプリケーションスレーブオプション

次のオプションは MySQL 5.5 で削除されました。MySQL 5.6 でこれらのオプションを使用して mysqld を起動しようとすると、サーバーは次で停止します: 不明な変数エラー.これらのオプションにすでに関連付けられているレプリケーションパラメータを設定するには、CHANGE MASTER TO ... ステートメントを使用する必要があります (セクション13.4.2.1「CHANGE MASTER TO 構文」を参照してください)。

影響するオプションをこのリストに示します。

--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

レプリケーションスレーブで使用されるシステム変数

次の一覧で、レプリケーションスレーブサーバーを制御するためのシステム変数について説明します。これらはサーバー起動時に設定でき、それらの一部は SET を使用して実行時に変更できます。レプリケーションスレーブで使用されるサーバーオプションは、このセクションですでにリストされています。

init_slave

コマンド行形式 --init-slave=name

システム変数 init_slave

スコープグローバル

動的はい

型文字列

この変数は init_connect に似ていますが、SQL スレッドが起動するたびにスレーブサーバーによって実行される文字列です。文字列の形式は init_connect 変数の場合と同じです。

注記

SQL スレッドは、クライアントに確認応答を送信してから init_slave を実行します。このため、START SLAVE が戻されるときに init_slave が実行されていることは保証されません。詳細については、セクション13.4.2.5「START SLAVE 構文」を参照してください。
log_slow_slave_statements

導入 5.6.11

システム変数 log_slow_slave_statements

スコープグローバル

動的はい

型ブール

デフォルト OFF

スロークエリーログが有効のときは、この変数はスレーブで実行するために long_query_time 秒を超える時間がかかったクエリーのロギングを有効にします。この変数は MySQL 5.6.11 で追加されました。

コマンド行形式	`--init-slave=name`
システム変数	`init_slave`
スコープ	グローバル
動的	はい
型	文字列

導入	5.6.11
システム変数	`log_slow_slave_statements`
スコープ	グローバル
動的	はい
型	ブール
デフォルト	`OFF`

master_info_repository

コマンド行形式	`--master-info-repository=FILE\|TABLE`
導入	5.6.2
システム変数	`master_info_repository`
スコープ	グローバル
動的	はい
型	文字列
デフォルト	`FILE`
有効な値	`FILE` `TABLE`

この変数の設定によって、スレーブがマスターステータスおよび接続情報のログを FILE (master.info) または TABLE (mysql.slave_master_info) のどちらに記録するかが決まります。

この変数の設定は、sync_master_info システム変数の設定による影響にも直接影響します。詳細については、変数の説明を参照してください。

この変数は MySQL 5.6.2 で追加されました。

relay_log

コマンド行形式 --relay-log=file_name

システム変数 relay_log

スコープグローバル

動的いいえ

型ファイル名

リレーログファイルの名前。
relay_log_basename

導入 5.6.2

システム変数 relay_log_basename

スコープグローバル

動的いいえ

型ファイル名

デフォルト datadir + '/' + hostname + '-relay-bin'

リレーログファイルの名前と完全パスを保持します。

relay_log_basename システム変数は MySQL 5.6.2 で追加されました。

コマンド行形式	`--relay-log=file_name`
システム変数	`relay_log`
スコープ	グローバル
動的	いいえ
型	ファイル名

導入	5.6.2
システム変数	`relay_log_basename`
スコープ	グローバル
動的	いいえ
型	ファイル名
デフォルト	`datadir + '/' + hostname + '-relay-bin'`

relay_log_index

コマンド行形式	`--relay-log-index`
システム変数	`relay_log_index`
スコープ	グローバル
動的	いいえ
型	ファイル名
デフォルト	`host_name-relay-bin.index`

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

relay_log_info_file

コマンド行形式	`--relay-log-info-file=file_name`
システム変数	`relay_log_info_file`
スコープ	グローバル
動的	いいえ
型	ファイル名
デフォルト	`relay-log.info`

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

relay_log_info_repository

導入 5.6.2

システム変数 relay_log_info_repository

スコープグローバル

動的はい

型文字列

デフォルト FILE

有効な値
FILE

TABLE

この変数によって、スレーブのリレーログ内での位置が FILE (relay-log.info) または TABLE (mysql.slave_relay_log_info) のどちらに書き込まれるかが決まります。

この変数の設定は、sync_relay_log_info システム変数の設定による影響にも直接影響します。詳細については、変数の説明を参照してください。

この変数は MySQL 5.6.2 で追加されました。

relay_log_recovery

コマンド行形式	`--relay-log-recovery`
システム変数	`relay_log_recovery`
スコープ	グローバル
動的 (≥ 5.6.6)	いいえ
動的 (≤ 5.6.5)	はい
型	ブール
デフォルト	`FALSE`

サーバー起動直後のリレーログ自動リカバリを有効にします。リカバリプロセスでは、新しいリレーログファイルを作成し、SQL スレッド位置をこの新しいリレーログに初期化し、I/O スレッドを SQL スレッド位置に初期化します。その後、マスターからのリレーログ読み取りが続行されます。MySQL 5.6.5 以前では、このグローバル変数を動的に変更できました。MySQL 5.6.6 以降は読み取り専用です。(Bug #13840948) MySQL Server バージョンにかかわらず、--relay-log-recovery オプションでスレーブを起動することで、その値を変更できます。これは、レプリケーションスレーブでクラッシュが発生したあとに、破損した可能性のあるリレーログが処理されないことを保証するために使用するべきであり、クラッシュセーフなスレーブを保証するために使用する必要があります。デフォルト値は 0 (無効)です。

relay_log_recovery が有効であり、スレーブがマルチスレッドモードで動作中に発生したエラーが原因で停止したときでも、ログにギャップがある場合には CHANGE MASTER TO を実行できません。MySQL 5.6.6 以降では、START SLAVE UNTIL SQL_AFTER_MTS_GAPS を使用して確実にすべてのギャップが処理されてから、単一スレッドモードに戻ったり CHANGE MASTER TO ステートメントを実行したりするようにしてください。

rpl_stop_slave_timeout

コマンド行形式	`--rpl-stop-slave-timeout=seconds`
導入	5.6.13
システム変数	`rpl_stop_slave_timeout`
スコープ	グローバル
動的	はい
型	整数
デフォルト	`31536000`
最小値	`2`
最大値	`31536000`

MySQL 5.6.13 以降では、この変数を設定することで、タイムアウトまでに STOP SLAVE が待機する時間（秒単位）を制御できます。これは、STOP SLAVE ステートメントと、スレーブへのさまざまなクライアント接続を使用するほかのスレーブ SQL ステートメントとの間のデッドロックを回避するために使用できます。rpl_stop_slave_timeout の最大値およびデフォルト値は 31536000 秒 (1 年) です。最小は 2 秒です。

slave_checkpoint_group

コマンド行形式	`--slave-checkpoint-group=#`
導入	5.6.3
システム変数	`slave_checkpoint_group=#`
スコープ	グローバル
動的	はい
型	数値
デフォルト	`512`
最小値	`32`
最大値	`524280`
ブロックサイズ	`8`

SHOW SLAVE STATUS によって表示されるマルチスレッドスレーブステータスを更新するためにチェックポイント操作が呼び出される前に、スレーブが処理できる最大トランザクション数を設定します。この変数を設定しても、マルチスレッドが有効ではないスレーブには影響しません。

この変数は、slave_checkpoint_period システム変数との組み合わせで、どちらかの制限を超えたときに、チェックポイントが実行され、トランザクションの数と最後のチェックポイントから経過した時間の両方を追跡するカウンタがリセットされる、という方法で機能します。

この変数の最小許容値は 32 です (サーバーが -DWITH_DEBUG を使用して構築された場合を除く、この場合の最小値は 1)。効果的な値は常に 8 の倍数です。そのような倍数でない値に設定することもできますが、サーバーは値を格納する前に次に小さい 8 の倍数に丸めます。(例外: このような丸めはデバッグサーバーでは実行されません。)サーバーの構築方法にかかわらず、デフォルト値は 512 であり、最大許容値は 524280 です。

slave_checkpoint_group は MySQL 5.6.3 で追加されました。

slave_checkpoint_period

コマンド行形式	`--slave-checkpoint-period=#`
導入	5.6.3
システム変数	`slave_checkpoint_period=#`
スコープ	グローバル
動的	はい
型	数値
デフォルト	`300`
最小値	`1`
最大値	`4G`
Unit	`millisecond`

SHOW SLAVE STATUS によって表示されるマルチスレッドのスレーブステータスを更新するためにチェックポイント操作が呼び出される前に、経過できる最大時間（ミリ秒単位）を設定します。この変数を設定しても、マルチスレッドが有効ではないスレーブには影響しません。

この変数は、slave_checkpoint_group システム変数との組み合わせで、どちらかの制限を超えたときに、チェックポイントが実行され、トランザクションの数と最後のチェックポイントから経過した時間の両方を追跡するカウンタがリセットされる、という方法で機能します。

この変数の最小許容値は 1 です (サーバーが -DWITH_DEBUG を使用して構築された場合を除く、この場合の最小値は 0)。サーバーの構築方法にかかわらず、デフォルト値は 300 であり、最大可能値は 4294967296 (4G バイト) です。

slave_checkpoint_period は MySQL 5.6.3 で追加されました。

slave_compressed_protocol

コマンド行形式 --slave-compressed-protocol

システム変数 slave_compressed_protocol

スコープグローバル

動的はい

型ブール

デフォルト OFF

スレーブ/マスタープロトコルの圧縮を使用するかどうか (スレーブとマスターの両方がサポートしている場合)。

slave_exec_mode

コマンド行形式	`--slave-exec-mode=mode`
システム変数	`slave_exec_mode`
スコープ	グローバル
動的	はい
型	列挙
デフォルト	`IDEMPOTENT` (NDB) `STRICT` (Other)
有効な値	`IDEMPOTENT` `STRICT`

IDEMPOTENT または STRICT モードがレプリケーション競合解決とエラーチェックで使用されるかどうかを制御します。IDEMPOTENT モードでは、キーが重複しているエラーとキーが見つからないエラーが抑制されます。

このモードは、MySQL Cluster レプリケーションのマルチマスターレプリケーション、循環レプリケーション、およびその他の特別なレプリケーションシナリオに必要です。(詳しくは、セクション18.6.10「MySQL Cluster レプリケーション: マルチマスターと循環レプリケーション」およびセクション18.6.11「MySQL Cluster レプリケーションの競合解決」を参照してください。)MySQL Cluster で提供される mysqld は、slave_exec_mode に明示的に設定される値を無視し、これを常に IDEMPOTENT として扱います。

MySQL Server 5.6 では、STRICT モードがデフォルト値です。これを変更しないでください。現在のところ、IDEMPOTENT モードは NDB でのみサポートされます。

slave_load_tmpdir

コマンド行形式 --slave-load-tmpdir=path

システム変数 slave_load_tmpdir

スコープグローバル

動的いいえ

型ディレクトリ名

デフォルト /tmp

LOAD DATA INFILE ステートメントを複製するためにスレーブが一時ファイルを作成するディレクトリの名前。
slave_max_allowed_packet

導入 5.6.6

システム変数 slave_max_allowed_packet

スコープグローバル

動的はい

型数値

デフォルト 1073741824

最小値 1024

最大値 1073741824

MySQL 5.6.6 以降では、この変数はスレーブ SQL スレッドおよび I/O スレッドの最大パケットサイズを設定するので、更新が max_allowed_packet を超えたことが原因で、行ベースレプリケーションを使用する大きな更新がレプリケーションに失敗することはありません。

このグローバル変数は常に、1024 の正の整数の倍数である値を持ちます。そうでない何らかの値に設定しても、値は次に大きい 1024 の倍数に自動的に丸められて、格納または使用されます。slave_max_allowed_packet を 0 に設定すると、1024 が使用されます。(このような場合、切り捨ての警告が発行されます。)デフォルトおよび最大値は 1073741824 (1G バイト) で、最小は 1024 です。

slave_max_allowed_packet は --slave-max-allowed-packet オプションを使用して、起動時に設定することもできます。
slave_net_timeout

コマンド行形式 --slave-net-timeout=#

システム変数 slave_net_timeout

スコープグローバル

動的はい

型数値

デフォルト 3600

最小値 1

マスター/スレーブ接続から後続のデータを待機する秒数 (これ以降は、読み取りを中止)。

slave_parallel_workers

コマンド行形式	`--slave-parallel-workers=#`
導入	5.6.3
システム変数	`slave_parallel_workers`
スコープ	グローバル
動的	はい
型	数値
デフォルト	`0`
最小値	`0`
最大値	`1024`

レプリケーションイベント（トランザクション）を並列に実行するためのスレーブワーカースレッドの数を設定します。この変数を 0 (デフォルト) に設定すると、並列実行が無効になります。最大値は 1024 です。

並列実行が有効のときは、スレーブ SQL スレッドはスレーブワーカースレッドのコーディネーターとして機能し、トランザクションはそれらにデータベースごとに分散されます。これは、スレーブ上のワーカースレッドは、ほかのデータベースへの更新が完了するのを待たずに、所定のデータベースに基づいてトランザクションを次々に処理できることを意味します。スレーブでのマルチスレッドの現在の実装は、データがデータベースごとに分割されていて、所定のデータベース内の更新が正しく機能するようにマスターの場合と同様に相対順序で行われることを前提としています。ただし、2 つのデータベース間でトランザクションを調整する必要はありません。

異なるデータベースでのトランザクションは、スレーブではマスターとは異なる順序が実行されることがあるという事実のため、最後に実行されたトランザクションをチェックしても、マスターからの以前のすべてのトランザクションがスレーブ上で実行されたことが保証されません。これは、マルチスレッド化したスレーブを使用する場合にロギングとリカバリに影響します。スレーブ上でマルチスレッドを使用したときにバイナリロギング情報をどのように解釈すればよいかについては、セクション13.7.5.35「SHOW SLAVE STATUS 構文」を参照してください。また、START SLAVE UNTIL がマルチスレッドスレーブでサポートされないことを意味します。

マルチスレッドが有効のときは、slave_transaction_retries は 0 に等しいとして処理され、変更できません。(現在のところ、トランザクションの再試行はマルチスレッドスレーブではサポートされません。)

この変数は MySQL 5.6.3 で追加されました。

注記

この変数 (または対応する --slave-parallel-workers オプション) の値セットは MySQL 5.6.3 で正しく処理されるとはかぎりません。この問題は MySQL 5.6.4 で修正されました (Bug #13334470)。

slave_pending_jobs_size_max

導入	5.6.3
システム変数	`slave_pending_jobs_size_max`
スコープ	グローバル
動的	はい
型	数値
デフォルト	`0`
最小値	`1024`
最大値	`18EB`
Unit	`bytes`
ブロックサイズ	`1024`

マルチスレッドスレーブの場合、この変数は、まだ適用されていないイベントを保持するスレーブワーカーキューに使用可能な最大メモリー量 (バイト単位) を設定します。この変数を設定しても、マルチスレッドが有効ではないスレーブには影響しません。

この変数の可能な最小値は 1024 で、デフォルトは 16M バイトです。可能な最大値は 18446744073709551615 (16E バイト) です。1024 の正確な倍数でない値は、保存される前に次に大きい 1024 の倍数に丸められます。

重要

この変数の値はマスターの max_allowed_packet の値以上である必要があります。そうでない場合は、マスターから到着する処理すべきイベントが残っているときにスレーブワーカーキューがいっぱいになる場合があります。

slave_pending_jobs_size_max は MySQL 5.6.3 で追加されました。

slave_rows_search_algorithms

導入	5.6.6
システム変数	`slave_rows_search_algorithms=list`
スコープ	グローバル
動的	はい
型	セット
デフォルト	`TABLE_SCAN,INDEX_SCAN`
有効な値	`TABLE_SCAN,INDEX_SCAN` `INDEX_SCAN,HASH_SCAN` `TABLE_SCAN,HASH_SCAN` `TABLE_SCAN,INDEX_SCAN,HASH_SCAN` (INDEX_SCAN,HASH_SCAN と同等)

slave_allow_batching を使用して行ベースロギングとレプリケーションのために大量の行を準備するときに、slave_rows_search_algorithms 変数は行の一致がどのように検索されるか、つまり、主キー、一意キー、または何らかのほかのキーを使用する検索、またはキーをまったく使用しない検索にハッシュを使用するかどうかを制御します。このオプションは、リスト INDEX_SCAN、TABLE_SCAN、HASH_SCAN から少なくとも 2 つの値のカンマ区切りリストを取ります。値は文字列を想定するため、値は引用符で囲む必要があります。また、値に空白文字を含めてはいけません。可能な組み合わせ (リスト) とその結果を次の表に示します。

使用されるインデックス/オプション値	`INDEX_SCAN,HASH_SCAN` または `INDEX_SCAN,TABLE_SCAN,HASH_SCAN`	`INDEX_SCAN,TABLE_SCAN`	`TABLE_SCAN,HASH_SCAN`
主キーまたは一意キー	インデックススキャン	インデックススキャン	インデックスハッシュ
(ほかの) キー	インデックスハッシュ	インデックススキャン	インデックスハッシュ
インデックスなし	テーブルハッシュ	テーブルスキャン	テーブルハッシュ

リスト内でアルゴリズムが指定される順序は、ここで示すように、SELECT または SHOW VARIABLES ステートメントで表示される順序と違いはありません。

mysql> SET GLOBAL slave_rows_search_algorithms = "INDEX_SCAN,TABLE_SCAN";
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW VARIABLES LIKE '%algorithms%';
+------------------------------+-----------------------+
| Variable_name                | Value                 |
+------------------------------+-----------------------+
| slave_rows_search_algorithms | TABLE_SCAN,INDEX_SCAN |
+------------------------------+-----------------------+
1 row in set (0.00 sec)

mysql> SET GLOBAL slave_rows_search_algorithms = "TABLE_SCAN,INDEX_SCAN";
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW VARIABLES LIKE '%algorithms%';
+------------------------------+-----------------------+
| Variable_name                | Value                 |
+------------------------------+-----------------------+
| slave_rows_search_algorithms | TABLE_SCAN,INDEX_SCAN |
+------------------------------+-----------------------+
1 row in set (0.00 sec)

デフォルト値は TABLE_SCAN,INDEX_SCAN で、これはインデックスを使用できるすべての検索はそれらを使用し、インデックスなしの検索はテーブルスキャンを使用することを意味します。

INDEX_SCAN,TABLE_SCAN,HASH_SCAN を指定することは、INDEX_SCAN,HASH_SCAN を指定する場合と同じ結果になります。主キーまたは一意キーを使用しない検索にハッシュを使用するには、この変数を INDEX_SCAN,HASH_SCAN に設定します。すべての検索にハッシュを強制的に使用するには、TABLE_SCAN,HASH_SCAN に設定します。

この変数は MySQL 5.6.6 で追加されました。

slave_skip_errors

コマンド行形式	`--slave-skip-errors=name`
システム変数	`slave_skip_errors`
スコープ	グローバル
動的	いいえ
型	文字列
デフォルト	`OFF`
有効な値	`OFF` `[list of error codes]` `all` `ddl_exist_errors`
有効な値	`OFF` `[list of error codes]` `all` `ddl_exist_errors`
有効な値	`OFF` `[list of error codes]` `all`

レプリケーションは通常、スレーブでエラーが発生したときに停止します。これは、データ内の不一致を手動で解決する機会です。この変数は、ステートメントが変数値にリストされたエラーを返すときに、レプリケーションを継続するようにスレーブ SQL スレッドに指示します。

slave_sql_verify_checksum

導入 5.6.2

システム変数 slave_sql_verify_checksum

スコープグローバル

動的はい

型ブール

デフォルト 1

有効な値
0

1

スレーブ SQL スレッドはリレーログから読み取られたチェックサムを使用してデータを検証します。不一致があった場合、スレーブはエラーで停止します。

注記

スレーブ I/O スレッドは常に、ネットワークからイベントを受け取るときに可能であればチェックサムを読み取ります。

slave_sql_verify_checksum は MySQL 5.6.2 で追加されました。

slave_transaction_retries

コマンド行形式	`--slave-transaction-retries=#`
システム変数	`slave_transaction_retries`
スコープ	グローバル
動的	はい
型	数値
デフォルト	`10`
最小値	`0`
最大値 (64 ビットプラットフォーム)	`18446744073709551615`
最大値 (32 ビットプラットフォーム)	`4294967295`

InnoDB デッドロック、またはトランザクションの実行時間が InnoDB の innodb_lock_wait_timeout、または NDB の TransactionDeadlockDetectionTimeout または TransactionInactiveTimeout を超えたために、レプリケーションスレーブ SQL スレッドがトランザクションの実行に失敗した場合、自動的に slave_transaction_retries 回再試行してからエラーで停止します。デフォルト値は 10 です。

マルチスレッドスレーブを使用するときは、トランザクションを再試行できません。つまり、slave_parallel_workers が 0 より大きい場合は、slave_transaction_retries が 0 に等しいとして扱われ、変更できません。

slave_type_conversions

コマンド行形式	`--slave-type-conversions=set`
システム変数	`slave_type_conversions`
スコープ	グローバル
動的	いいえ
型	セット
デフォルト
有効な値 (≥ 5.6.13)	`ALL_LOSSY` `ALL_NON_LOSSY` `ALL_SIGNED` `ALL_UNSIGNED`
有効な値 (≤ 5.6.12)	`ALL_LOSSY` `ALL_NON_LOSSY`

行ベースレプリケーションを使用するときにスレーブで有効なタイプ変換モードを制御します。MySQL 5.6.13 以降では、その値はリスト ALL_LOSSY、ALL_NON_LOSSY、ALL_SIGNED、ALL_UNSIGNED からのゼロ個以上の要素のカンマ区切りセットです。この変数を空の文字列に設定すると、マスターとスレーブの間のタイプ変換が禁止されます。変更を有効にするには、スレーブの再起動が必要です。

ALL_SIGNED および ALL_UNSIGNED は MySQL 5.6.13 で追加されました (Bug#15831300)。行ベースレプリケーションで属性の昇格と降格に適用できるタイプ変換モードの詳細については、行ベースレプリケーション: 属性の昇格と降格を参照してください。

sql_slave_skip_counter

システム変数 sql_slave_skip_counter

スコープグローバル

動的はい

型数値

マスターからのイベントのうち、スレーブサーバーがスキップすべき数。

このオプションは GTID ベースレプリケーションと互換性がなく、--gtid-mode=ON のときにゼロ以外の値に設定してはいけません。MySQL 5.6.10 以降では、そのようにすることは明確に禁止されています。(Bug #15833516) GTID を採用するときにトランザクションをスキップする必要がある場合は、代わりにマスターから gtid_executed を使用してください。これを行う方法については、空のトランザクションの注入を参照してください。

重要

この変数を設定することで指定される数のイベントをスキップして、スレーブがイベントグループの途中で開始する場合、スレーブは次のイベントグループの開始を見つけるまでスキップを続け、そのポイントから開始します。詳細については、セクション13.4.2.4「SET GLOBAL sql_slave_skip_counter 構文」を参照してください。

sync_master_info

コマンド行形式	`--sync-master-info=#`
システム変数	`sync_master_info`
スコープ	グローバル
動的	はい
型	数値
デフォルト (64 ビットプラットフォーム, ≥ 5.6.6)	`10000`
デフォルト (64 ビットプラットフォーム, ≤ 5.6.5)	`0`
デフォルト (32 ビットプラットフォーム, ≥ 5.6.6)	`10000`
デフォルト (32 ビットプラットフォーム, ≤ 5.6.5)	`0`
最小値	`0`
最大値 (64 ビットプラットフォーム)	`18446744073709551615`
最大値 (32 ビットプラットフォーム)	`4294967295`

レプリケーションスレーブでのこの変数の影響は、次の段落で説明するように、スレーブの master_info_repository が FILE または TABLE のどちらに設定されているかによって異なります。

master_info_repository = FILE sync_master_info の値が 0 より大きい場合は、スレーブはすべての sync_master_info イベントのあとにその master.info ファイルをディスクに同期します (fdatasync() を使用)。0 の場合は、MySQL サーバーは master.info ファイルからディスクへの同期を実行しません。代わりに、サーバーはオペレーティングシステムに依存して、ほかのファイルと同様にその内容を定期的にフラッシュします。

master_info_repository = TABLE sync_master_info の値が 0 より大きい場合は、スレーブはすべての sync_master_info イベントのあとにそのマスター情報リポジトリテーブルを更新します。0 の場合は、テーブルは更新されません。

sync_master_info のデフォルト値は、MySQL 5.6.6 以降では 10000、その前は 0 です。

sync_relay_log

コマンド行形式	`--sync-relay-log=#`
システム変数	`sync_relay_log`
スコープ	グローバル
動的	はい
型	数値
デフォルト (64 ビットプラットフォーム, ≥ 5.6.6)	`10000`
デフォルト (64 ビットプラットフォーム, ≤ 5.6.5)	`0`
デフォルト (32 ビットプラットフォーム, ≥ 5.6.6)	`10000`
デフォルト (32 ビットプラットフォーム, ≤ 5.6.5)	`0`
最小値	`0`
最大値 (64 ビットプラットフォーム)	`18446744073709551615`
最大値 (32 ビットプラットフォーム)	`4294967295`

この変数の値が 0 より大きい場合は、すべての sync_relay_log イベントがリレーログに書き込まれたあとに、MySQL サーバーはそのリレーログをディスクに同期します (fdatasync() を使用)。

sync_relay_log を 0 に設定すると、ディスクへの同期は実行されません。この場合、サーバーはオペレーティングシステムに依存してほかのファイルに関してリレーログの内容をときどきフラッシュします。

MySQL 5.6.6 より前は、0 がこの変数のデフォルトでした。MySQL 5.6. 以降では、デフォルトは 10000 です。

値 1 が一番安全な選択です (クラッシュの場合にリレーログから失われるイベントが最大で 1 つです)。しかし、一番遅い選択でもあります (ディスクにバッテリ付きキャッシュがある場合を除きます。その場合は同期が非常に速くなります)。

sync_relay_log_info

コマンド行形式	`--sync-relay-log-info=#`
システム変数	`sync_relay_log_info`
スコープ	グローバル
動的	はい
型	数値
デフォルト (64 ビットプラットフォーム, ≥ 5.6.6)	`10000`
デフォルト (64 ビットプラットフォーム, ≤ 5.6.5)	`0`
デフォルト (32 ビットプラットフォーム, ≥ 5.6.6)	`10000`
デフォルト (32 ビットプラットフォーム, ≤ 5.6.5)	`0`
最小値	`0`
最大値 (64 ビットプラットフォーム)	`18446744073709551615`
最大値 (32 ビットプラットフォーム)	`4294967295`

スレーブでのこの変数の影響は、サーバーの relay_log_info_repository 設定（FILE または TABLE）、これが TABLE の場合は、さらにリレーログ情報テーブルで使用されるストレージエンジンがトランザクション対応か（InnoDB など）そうでないか（MyISAM）に依存します。これらの要因が、sync_relay_log_info 値がゼロおよびゼロより大きい場合にサーバーの動作にどのように影響するかを次の表で示します。

`sync_relay_log_info`	`relay_log_info_repository`
	`FILE`	`TABLE`
	`FILE`	トランザクション対応	トランザクション対応でない
`N > 0`	スレーブは各 `N` トランザクション後にその `relay-log.info` ファイルをディスクに同期します (`fdatasync()` を使用)。	テーブルは各トランザクション後に更新されます。(`N` は事実上無視されます。)	テーブルは各 `N` イベント後に更新されます。
`0`	MySQL サーバーは `relay-log.info` ファイルからディスクへの同期を実行しません。代わりに、サーバーはオペレーティングシステムに依存してほかのファイルと同様にその内容を定期的にフラッシュします。	テーブルは各トランザクション後に更新されます。(`N` は事実上無視されます。)	テーブルは更新されません。

sync_relay_log_info のデフォルト値は、MySQL 5.6.6 以降では 10000、それより前は 0 です。

PREV HOME UP NEXT