PDF (US Ltr)
- 26.8Mb
PDF (A4)
- 26.9Mb
HTML Download (TGZ)
- 7.1Mb
HTML Download (Zip)
- 7.2Mb
オプションはコマンド行またはオプションファイルで指定します。多くのオプションは、サーバーの動作中に CHANGE MASTER TO ステートメントを使用して設定できます。システム変数値は SET を使用して指定します。
サーバー ID
マスターと各スレーブでは、server-id オプションを使用して、範囲が 1 から 232 − 1 の一意レプリケーション ID を確立する必要があります。「一意」とは、各 ID が、ほかのレプリケーションマスターまたはスレーブで使用されるほかのあらゆる ID とは異なっている必要があるということです。my.cnf ファイルの例:
[mysqld]
server-id=3
このセクションでは、レプリケーションスレーブサーバーを制御するための起動オプションについて説明します。これらのオプションの多くは、サーバーの動作中に CHANGE MASTER TO ステートメントを使用して設定できます。--replicate-* などのその他のオプションは、スレーブサーバーが起動するときにのみ設定できます。レプリケーションに関連するシステム変数はこのセクションの後半で説明します。
-
Property Value コマンド行形式 --abort-slave-event-count=#型 数値 デフォルト 0最小値 0このオプションが 0 (デフォルト) 以外の正の整数
値に設定されると、次のようにレプリケーションの動作に影響します。スレーブ SQL スレッドが起動したあと、値ログイベントの実行が許可され、スレーブ SQL スレッドはマスターからのネットワーク接続が切断されたかのようにそれ以上イベントを受け取りません。スレーブのスレッドの実行は継続し、SHOW SLAVE STATUSからの出力にはSlave_IO_RunningおよびSlave_SQL_Runningカラムの両方にYesが表示されますが、それ以降のイベントはリレーログから読み取られません。このオプションは、レプリケーションのテストとデバッグのために、MySQL テストスイートで内部的に使用されます。本番環境設定で使用することを想定していません。
-
--disconnect-slave-event-countProperty Value コマンド行形式 --disconnect-slave-event-count=#型 数値 デフォルト 0このオプションは、レプリケーションのテストとデバッグのために、MySQL テストスイートで内部的に使用されます。
-
Property Value コマンド行形式 --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オプションで起動する必要があります。 -
Property Value コマンド行形式 --log-slow-slave-statements(<= 5.6.10)削除 5.6.11 型 ブール デフォルト OFFスロークエリーログが有効化されている場合、このオプションはスレーブでの実行に
long_query_time秒を超える時間がかかったクエリーのロギングを有効にします。このコマンド行オプションは MySQL 5.6.11 で削除され、
log_slow_slave_statementsシステム変数によって置き換えられました。システム変数はオプションと同じ方法でコマンド行またはオプションファイルに設定できるため、サーバー起動時に何らかの変更を行う必要はありませんが、システム変数は実行時に値を検査または設定することも可能です。 -
Property Value コマンド行形式 --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「通信エラーおよび中止された接続」を参照してください。注記このオプションの影響はレプリケーションに制限されません。サーバーアクティビティー全体を対象として警告を生成します。
-
Property Value コマンド行形式 --master-info-file=file_name型 ファイル名 デフォルト master.infoマスターの情報をスレーブが記録するファイルに使用する名前。データディレクトリ内のデフォルト名は
master.infoです。このファイルの形式については、セクション17.2.2.2「スレーブステータスログ」を参照してください。 -
Property Value コマンド行形式 --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オプションを使用するように、アプリケーションを更新してください。 -
Property Value コマンド行形式 --max-relay-log-size=#システム変数 max_relay_log_sizeスコープ グローバル 動的 はい 型 数値 デフォルト 0最小値 0最大値 1073741824このサイズで、サーバーはリレーログファイルを自動的にローテーションします。この値がゼロでない場合は、サイズがこの値を超えたときにリレーログは自動的にローテーションされます。この値がゼロ (デフォルト) の場合、リレーログローテーションが発生するサイズは
max_binlog_sizeの値によって決められます。詳細については、セクション17.2.2.1「スレーブリレーログ」を参照してください。 -
Property Value コマンド行形式 --read-onlyシステム変数 read_onlyスコープ グローバル 動的 はい 型 ブール デフォルト falseスレーブがスレーブスレッドまたは
SUPER権限を持つユーザー以外からの更新を許可しなくなります。スレーブサーバーで、スレーブがクライアントからは受け付けず、確実にそのマスターサーバーからのみ更新を受け付けるようにするには、これが役立つ場合があります。この変数はTEMPORARYテーブルには適用されません。 -
Property Value コマンド行形式 --relay-log=file_nameシステム変数 relay_logスコープ グローバル 動的 いいえ 型 ファイル名 リレーログのベース名。デフォルトベース名は
host_name-relay-binMySQL がサーバーオプションを解析する方法が原因で、このオプションを指定する場合は、値を指定する必要があります。デフォルトベース名はオプションが実際に指定されない場合にのみ使用されます。値を指定しないで
--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システム変数から取得できます。 -
Property Value コマンド行形式 --relay-log-index=file_nameシステム変数 relay_log_indexスコープ グローバル 動的 いいえ 型 ファイル名 リレーログインデックスファイルに使用する名前。データディレクトリ内のデフォルト名は
host_name-relay-bin.indexhost_nameはスレーブサーバーの名前です。MySQL がサーバーオプションを解析する方法が原因で、このオプションを指定する場合は、値を指定する必要があります。デフォルトベース名はオプションが実際に指定されない場合にのみ使用されます。値を指定しないで
--relay-log-indexオプションを使用する場合、予期しない動作になる場合があります。この動作は、使用されるほかのオプション、それらが指定される順序、およびオプションがコマンド行またはオプションファイルのどちらで指定されたに依存します。MySQL がサーバーオプションをどのように処理するかについて詳しくは、セクション4.2.3「プログラムオプションの指定」を参照してください。このオプションを指定した場合、指定される値はリレーログのベース名としても使用されます。
--relay-logオプションを使用して別のリレーログファイルベース名を指定することで、この動作をオーバーライドできます。 -
--relay-log-info-file=file_nameProperty Value コマンド行形式 --relay-log-info-file=file_name型 ファイル名 デフォルト relay-log.infoスレーブがリレーログの情報を記録するファイルに使用する名前。データディレクトリ内のデフォルト名は
relay-log.infoです。このファイルの形式については、セクション17.2.2.2「スレーブステータスログ」を参照してください。 -
Property Value コマンド行形式 --relay-log-purgeシステム変数 relay_log_purgeスコープ グローバル 動的 はい 型 ブール デフォルト TRUEリレーログファイルが不要になるとすぐに自動的にパージすることを無効または有効にします。デフォルト値は 1 (有効)です。これは
SET GLOBAL relay_log_purge =で動的に変更できるグローバル変数です。N--relay-log-recoveryオプションを使用するときにリレーログのパージを無効にすると、データ一貫性が危険にさらされるため、クラッシュセーフではありません。 -
Property Value コマンド行形式 --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) -
Property Value コマンド行形式 --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を一時的に無視します。 -
Property Value コマンド行形式 --replicate-do-db=name型 文字列 このオプションの影響は、ステートメントベースまたは行ベースのどちらのレプリケーションを使用中かによって異なります。
ステートメントベースのレプリケーション デフォルトデータベース (つまり、
USEで選択されたもの) がdb_nameであるステートメントにレプリケーションを限定するように、スレーブ SQL スレッドに指示します。複数のデータベースを指定するには、このオプションを複数回 (データベースごとに 1 回) 使用します。ただし、このようにすると別のデータベースは選択される (またはデータベースが選択されない) けれども、UPDATEなどのクロスデータベースステートメントを複製しません。some_db.some_tableSET 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=を使用してください。セクション17.2.3「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。db_name.%注記このオプションは、
--binlog-do-dbがバイナリロギングに影響するのと同じ方法でレプリケーションに影響し、--replicate-do-dbがレプリケーション動作にどのように影響するかに対してレプリケーション形式がどのように影響するかは、--binlog-do-db動作に対してロギング形式がどのように影響するかと同じです。このオプションは、
BEGIN、COMMIT、またはROLLBACKステートメントに影響しません。 -
Property Value コマンド行形式 --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=を使用してください。セクション17.2.3「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。db_name.%注記このオプションは、
--binlog-ignore-dbがバイナリロギングに影響するのと同じ方法でレプリケーションに影響し、--replicate-ignore-dbがレプリケーション動作にどのように影響するかに対してレプリケーション形式がどのように影響するかは、--binlog-ignore-db動作に対してロギング形式がどのように影響するかと同じです。このオプションは、
BEGIN、COMMIT、またはROLLBACKステートメントに影響しません。 -
--replicate-do-table=db_name.tbl_nameProperty Value コマンド行形式 --replicate-do-table=name型 文字列 レプリケーションを特定のテーブルに制限するようにスレーブ SQL スレッドに指示することで、レプリケーションフィルタを作成します。複数のテーブルを指定するには、このオプションを複数回 (テーブルごとに 1 回) 使用します。
--replicate-do-dbとは対照的に、これはクロスデータベース更新とデフォルトデータベース更新の両方に機能します。セクション17.2.3「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。このオプションは、テーブルに適用されるステートメントにのみ影響します。ストアドルーチンなど、ほかのデータベースオブジェクトにのみ適用されるステートメントには影響しません。ストアドルーチンに作用するステートメントをフィルタするには、1 つまたは複数の
--replicate-*-dbオプションを使用します。 -
--replicate-ignore-table=db_name.tbl_nameProperty Value コマンド行形式 --replicate-ignore-table=name型 文字列 指定されたテーブルを更新するステートメントを複製しないように (ほかのテーブルが同じステートメントによって更新される可能性があったとしても) スレーブ SQL スレッドに指示することで、レプリケーションフィルタを作成します。無視するテーブルを複数指定するには、このオプションを複数回 (テーブルごとに 1 回) 使用します。
--replicate-ignore-dbとは対照的に、これはクロスデータベース更新に機能します。セクション17.2.3「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。このオプションは、テーブルに適用されるステートメントにのみ影響します。ストアドルーチンなど、ほかのデータベースオブジェクトにのみ適用されるステートメントには影響しません。ストアドルーチンに作用するステートメントをフィルタするには、1 つまたは複数の
--replicate-*-dbオプションを使用します。 -
--replicate-rewrite-db=from_name->to_nameProperty Value コマンド行形式 --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を実行します。この場合、関連のあるフィルタリングルールは、次に示した理由で機能しません。テーブル
tがスレーブのデータベースb内にあるため、--replicate-do-table=a.tは機能しません。--replicate-do-table=b.tは、元のステートメントを照合しないため無視されます。--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)
-
Property Value コマンド行形式 --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_nameProperty Value コマンド行形式 --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_nameProperty Value コマンド行形式 --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場合と同じです。 -
Property Value コマンド行形式 --report-host=host_nameシステム変数 report_hostスコープ グローバル 動的 いいえ 型 文字列 スレーブ登録中にマスターに報告されるスレーブのホスト名または IP アドレス。この値は、マスターサーバーでの
SHOW SLAVE HOSTSの出力に出現します。マスターにスレーブ自身を登録しない場合は、値を設定しないままにします。注記スレーブ接続後にマスターが TCP/IP ソケットからスレーブの IP アドレスを読み取るだけでは十分ではありません。NAT およびその他のルーティングの問題により、その IP はマスターまたはほかのホストからスレーブへの接続に有効でない可能性があります。
-
Property Value コマンド行形式 --report-password=nameシステム変数 report_passwordスコープ グローバル 動的 いいえ 型 文字列 スレーブ登録中にマスターに報告されるスレーブのアカウントパスワード。この値は、
--show-slave-auth-infoオプションが指定された場合にマスターサーバーでのSHOW SLAVE HOSTSの出力に出現します。このオプションの名前は別の方法で暗示されることもありますが、
--report-passwordは MySQL ユーザー権限システムに接続されないため、MySQL レプリケーションユーザーアカウントのパスワードとは必ずしも同じとはかぎりません （または同じである可能性は高くありません）。 -
Property Value コマンド行形式 --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によって表示されるデフォルト値にも影響します。 -
Property Value コマンド行形式 --report-user=nameシステム変数 report_userスコープ グローバル 動的 いいえ 型 文字列 スレーブ登録中にマスターに報告されるスレーブのアカウントユーザー名。この値は、
--show-slave-auth-infoオプションが指定された場合にマスターサーバーでのSHOW SLAVE HOSTSの出力に出現します。このオプションの名前は別の方法で暗示されることもありますが、
--report-userは MySQL ユーザー権限システムに接続されないため、MySQL レプリケーションユーザーアカウントの名前とは必ずしも同じとはかぎりません （または同じである可能性は高くありません）。 -
Property Value コマンド行形式 --show-slave-auth-info型 ブール デフォルト FALSE--report-userおよび--report-passwordオプションで起動されたスレーブのマスターサーバーでの、SHOW SLAVE HOSTSの出力にスレーブユーザー名とパスワードを表示します。 -
Property Value コマンド行形式 --slave-checkpoint-group=#導入 5.6.3 型 数値 デフォルト 512最小値 32最大値 524280ブロックサイズ 8SHOW SLAVE STATUSによって表示されるマルチスレッドスレーブステータスを更新するためにチェックポイント操作が呼び出される前に、スレーブが処理できる最大トランザクション数を設定します。このオプションを設定しても、マルチスレッドが有効でないスレーブには影響しません。このオプションは、
--slave-checkpoint-periodオプションとの組み合わせで、どちらかの制限を超えたときに、チェックポイントが実行され、トランザクションの数と最後のチェックポイントから経過した時間の両方を追跡するカウンタがリセットされる、という方法で機能します。このオプションの最小許容値は 32 です (サーバーが
-DWITH_DEBUGを使用して構築された場合を除く、その場合の最小値は 1)。効果的な値は常に 8 の倍数です。そのような倍数でない値に設定することもできますが、サーバーは値を格納する前に次に小さい 8 の倍数に丸めます。(例外: このような丸めはデバッグサーバーでは実行されません。)サーバーの構築方法にかかわらず、デフォルト値は 512 であり、最大許容値は 524280 です。--slave-checkpoint-groupは MySQL 5.6.3 で追加されました。 -
Property Value コマンド行形式 --slave-checkpoint-period=#導入 5.6.3 型 数値 デフォルト 300最小値 1最大値 4GSHOW SLAVE STATUSによって表示されるマルチスレッドのスレーブステータスを更新するためにチェックポイント操作が呼び出される前に、経過できる最大時間 （ミリ秒単位） を設定します。このオプションを設定しても、マルチスレッドが有効でないスレーブには影響しません。このオプションは、
--slave-checkpoint-groupオプションとの組み合わせで、どちらかの制限を超えたときに、チェックポイントが実行され、トランザクションの数と最後のチェックポイントから経過した時間の両方を追跡するカウンタがリセットされる、という方法で機能します。このオプションの最小許容値は 1 です (サーバーが
-DWITH_DEBUGを使用して構築された場合を除く、その場合の最小値は 0)。サーバーの構築方法にかかわらず、デフォルト値は 300 であり、最大可能値は 4294967296 (4G バイト) です。--slave-checkpoint-periodは MySQL 5.6.3 で追加されました。 -
Property Value コマンド行形式 --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=#Property Value コマンド行形式 --slave-pending-jobs-size-max=#導入 5.6.3 型 数値 デフォルト 16M最小値 1024最大値 18EBブロックサイズ 1024マルチスレッドスレーブの場合、このオプションは、まだ適用されていないイベントを保持するスレーブワーカーキューに使用可能な最大メモリー量 (バイト単位) を設定します。このオプションを設定しても、マルチスレッドが有効でないスレーブには影響しません。
このオプションの可能な最小値は 1024 で、デフォルトは 16M バイトです。可能な最大値は 18446744073709551615 (16E バイト) です。1024 の正確な倍数でない値は、保存される前に次に大きい 1024 の倍数に丸められます。
重要このオプションの値はマスターの
max_allowed_packetの値以上である必要があります。そうでない場合は、マスターから到着する処理すべきイベントが残っているときにスレーブワーカーキューがいっぱいになる場合があります。このオプションは MySQL 5.6.3 で追加されました。
-
Property Value コマンド行形式 --skip-slave-start型 ブール デフォルト FALSEサーバーの起動時にスレーブスレッドを起動しないように、スレーブサーバーに指示します。スレッドをあとで起動するには、
START SLAVEステートメントを使用します。 -
--slave_compressed_protocol={0|1}Property Value コマンド行形式 --slave-compressed-protocolシステム変数 slave_compressed_protocolスコープ グローバル 動的 はい 型 ブール デフォルト OFFこのオプションが 1 に設定されている場合は、スレーブとマスターの両方がサポートしている場合は、マスター/スレーブプロトコルに圧縮を使用します。デフォルトは 0 (圧縮なし) です。
-
Property Value コマンド行形式 --slave-load-tmpdir=pathシステム変数 slave_load_tmpdirスコープ グローバル 動的 いいえ 型 ディレクトリ名 デフォルト /tmpスレーブが一時ファイルを作成するディレクトリの名前。このオプションはデフォルトでは、
tmpdirシステム変数の値と同じです。スレーブ SQL スレッドは、LOAD DATA INFILEステートメントを複製するときに、リレーログからロードされるファイルを一時ファイルに抽出してから、それらをテーブルにロードします。マスターでロードされるファイルが非常に大きい場合は、スレーブの一時ファイルも非常に大きくなります。このため、このオプションを使用して、利用可能な多くの空き領域を持つファイルシステム内にあるディレクトリに一時ファイルを置くように、スレーブに指示することをお勧めします。この場合、リレーログも非常に大きいため、--relay-logオプションを使用してそのファイルシステムにリレーログも置くことをお勧めします。このオプションで指定するディレクトリは (メモリーベースファイルシステムではなく) ディスクベースファイルシステムに配置してください。
LOAD DATA INFILEの複製に使用される一時ファイルがマシン再起動後も存続する必要があるためです。このディレクトリは、システム起動プロセス中にオペレーティングシステムによってクリアされるものではいけません。 -
slave-max-allowed-packet=bytesProperty Value コマンド行形式 --slave-max-allowed-packet=#導入 5.6.6 型 数値 デフォルト 1073741824最小値 1024最大値 1073741824MySQL 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 です。
-
Property Value コマンド行形式 --slave-net-timeout=#システム変数 slave_net_timeoutスコープ グローバル 動的 はい 型 数値 デフォルト 3600最小値 1マスターからの後続のデータを待機する秒数 (これ以降は、スレーブは接続が切断されていると見なし、読み取りを中止し、再接続を試行)。最初の再試行はタイムアウトの直後に発生します。再試行の間隔は
CHANGE MASTER TOステートメントのMASTER_CONNECT_RETRYオプションで制御され、再接続の試行回数は--master-retry-countオプションによって制限されます。デフォルトは 3600 秒 (1 時間) です。 -
slave-rows-search-algorithms=listProperty Value コマンド行形式 --slave-rows-search-algorithms=list導入 5.6.6 型 セット デフォルト TABLE_SCAN,INDEX_SCAN有効な値 TABLE_SCAN,INDEX_SCANINDEX_SCAN,HASH_SCANTABLE_SCAN,HASH_SCANTABLE_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_SCANINDEX_SCAN,TABLE_SCANTABLE_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]Property Value コマンド行形式 --slave-skip-errors=nameシステム変数 slave_skip_errorsスコープ グローバル 動的 いいえ 型 文字列 デフォルト OFF有効な値 OFF[list of error codes]allddl_exist_errors有効な値 OFF[list of error codes]allddl_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}Property Value コマンド行形式 --slave-sql-verify-checksum=value導入 5.6.2 型 ブール デフォルト 0有効な値 01このオプションが有効のときは、スレーブはリレーログから読み取られたチェックサムを調べて、不一致があった場合にスレーブはエラーで停止します。デフォルトで無効になっています。
このオプションは MySQL 5.6.2 で追加されました。
MySQL 5.6 以降では、レプリケーションスレーブステータス情報をファイルではなくテーブルに記録できます。マスター情報ログおよびリレーログ情報ログの書き込みは、ここで示す、MySQL 5.6.2 で追加された 2 つのサーバーオプションを使用して個別に構成できます。
-
--master-info-repository={FILE|TABLE}Property Value コマンド行形式 --master-info-repository=FILE|TABLE導入 5.6.2 型 文字列 デフォルト FILE有効な値 FILETABLEこのオプションにより、サーバーはそのマスター情報ログをファイルまたはテーブルに書き込みます。ファイル名はデフォルトで
master.infoになります。ファイルの名前は--master-info-fileサーバーオプションを使用して変更できます。このオプションのデフォルト値は
FILEです。TABLEを使用する場合、ログはmysqlデータベースのslave_master_infoテーブルに書き込まれます。--master-info-repositoryオプションは MySQL 5.6.2 で追加されました。 -
--relay-log-info-repository={FILE|TABLE}Property Value コマンド行形式 --relay-log-info-repository=FILE|TABLE導入 5.6.2 型 文字列 デフォルト FILE有効な値 FILETABLEこのオプションにより、サーバーはそのリレーログ情報のログをファイルまたはテーブルに記録します。ファイル名はデフォルトで
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 で追加されました。
情報ログテーブルとその内容は、所定の 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 構文」を参照してください)。
影響するオプションをこのリストに示します。
次の一覧で、レプリケーションスレーブサーバーを制御するためのシステム変数について説明します。これらはサーバー起動時に設定でき、それらの一部は SET を使用して実行時に変更できます。レプリケーションスレーブで使用されるサーバーオプションは、このセクションですでにリストされています。
-
Property Value コマンド行形式 --init-slave=nameシステム変数 init_slaveスコープ グローバル 動的 はい 型 文字列 この変数は
init_connectに似ていますが、SQL スレッドが起動するたびにスレーブサーバーによって実行される文字列です。文字列の形式はinit_connect変数の場合と同じです。注記SQL スレッドは、クライアントに確認応答を送信してから
init_slaveを実行します。このため、START SLAVEが戻されるときにinit_slaveが実行されていることは保証されません。詳細については、セクション13.4.2.5「START SLAVE 構文」を参照してください。 -
Property Value 導入 5.6.11 システム変数 log_slow_slave_statementsスコープ グローバル 動的 はい 型 ブール デフォルト OFFスロークエリーログが有効のときは、この変数はスレーブで実行するために
long_query_time秒を超える時間がかかったクエリーのロギングを有効にします。この変数は MySQL 5.6.11 で追加されました。 -
Property Value コマンド行形式 --master-info-repository=FILE|TABLE導入 5.6.2 システム変数 master_info_repositoryスコープ グローバル 動的 はい 型 文字列 デフォルト FILE有効な値 FILETABLEこの変数の設定によって、スレーブがマスターステータスおよび接続情報のログを
FILE(master.info) またはTABLE(mysql.slave_master_info) のどちらに記録するかが決まります。この変数の設定は、
sync_master_infoシステム変数の設定による影響にも直接影響します。詳細については、変数の説明を参照してください。この変数は MySQL 5.6.2 で追加されました。
-
Property Value コマンド行形式 --relay-log=file_nameシステム変数 relay_logスコープ グローバル 動的 いいえ 型 ファイル名 リレーログファイルの名前。
-
Property Value 導入 5.6.2 システム変数 relay_log_basenameスコープ グローバル 動的 いいえ 型 ファイル名 デフォルト datadir + '/' + hostname + '-relay-bin'リレーログファイルの名前と完全パスを保持します。
relay_log_basenameシステム変数は MySQL 5.6.2 で追加されました。 -
Property Value コマンド行形式 --relay-log-indexシステム変数 relay_log_indexスコープ グローバル 動的 いいえ 型 ファイル名 デフォルト *host_name*-relay-bin.indexリレーログのインデックスファイルの名前。データディレクトリ内のデフォルト名は
host_name-relay-bin.indexhost_nameはスレーブサーバーの名前です。 -
Property Value コマンド行形式 --relay-log-info-file=file_nameシステム変数 relay_log_info_fileスコープ グローバル 動的 いいえ 型 ファイル名 デフォルト relay-log.infoスレーブがリレーログの情報を記録するファイルの名前。データディレクトリ内のデフォルト名は
relay-log.infoです。 -
Property Value 導入 5.6.2 システム変数 relay_log_info_repositoryスコープ グローバル 動的 はい 型 文字列 デフォルト FILE有効な値 FILETABLEこの変数によって、スレーブのリレーログ内での位置が
FILE(relay-log.info) またはTABLE(mysql.slave_relay_log_info) のどちらに書き込まれるかが決まります。この変数の設定は、
sync_relay_log_infoシステム変数の設定による影響にも直接影響します。詳細については、変数の説明を参照してください。この変数は MySQL 5.6.2 で追加されました。
-
Property Value コマンド行形式 --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ステートメントを実行したりするようにしてください。 -
Property Value コマンド行形式 --rpl-stop-slave-timeout=seconds導入 5.6.13 システム変数 rpl_stop_slave_timeoutスコープ グローバル 動的 はい 型 整数 デフォルト 31536000最小値 2最大値 31536000MySQL 5.6.13 以降では、この変数を設定することで、タイムアウトまでに
STOP SLAVEが待機する時間 （秒単位） を制御できます。これは、STOP SLAVEステートメントと、スレーブへのさまざまなクライアント接続を使用するほかのスレーブ SQL ステートメントとの間のデッドロックを回避するために使用できます。rpl_stop_slave_timeoutの最大値およびデフォルト値は 31536000 秒 (1 年) です。最小は 2 秒です。 -
Property Value コマンド行形式 --slave-checkpoint-group=#導入 5.6.3 システム変数 slave_checkpoint_group=#スコープ グローバル 動的 はい 型 数値 デフォルト 512最小値 32最大値 524280ブロックサイズ 8SHOW SLAVE STATUSによって表示されるマルチスレッドスレーブステータスを更新するためにチェックポイント操作が呼び出される前に、スレーブが処理できる最大トランザクション数を設定します。この変数を設定しても、マルチスレッドが有効ではないスレーブには影響しません。この変数は、
slave_checkpoint_periodシステム変数との組み合わせで、どちらかの制限を超えたときに、チェックポイントが実行され、トランザクションの数と最後のチェックポイントから経過した時間の両方を追跡するカウンタがリセットされる、という方法で機能します。この変数の最小許容値は 32 です (サーバーが
-DWITH_DEBUGを使用して構築された場合を除く、この場合の最小値は 1)。効果的な値は常に 8 の倍数です。そのような倍数でない値に設定することもできますが、サーバーは値を格納する前に次に小さい 8 の倍数に丸めます。(例外: このような丸めはデバッグサーバーでは実行されません。)サーバーの構築方法にかかわらず、デフォルト値は 512 であり、最大許容値は 524280 です。slave_checkpoint_groupは MySQL 5.6.3 で追加されました。 -
Property Value コマンド行形式 --slave-checkpoint-period=#導入 5.6.3 システム変数 slave_checkpoint_period=#スコープ グローバル 動的 はい 型 数値 デフォルト 300最小値 1最大値 4GSHOW SLAVE STATUSによって表示されるマルチスレッドのスレーブステータスを更新するためにチェックポイント操作が呼び出される前に、経過できる最大時間 （ミリ秒単位） を設定します。この変数を設定しても、マルチスレッドが有効ではないスレーブには影響しません。この変数は、
slave_checkpoint_groupシステム変数との組み合わせで、どちらかの制限を超えたときに、チェックポイントが実行され、トランザクションの数と最後のチェックポイントから経過した時間の両方を追跡するカウンタがリセットされる、という方法で機能します。この変数の最小許容値は 1 です (サーバーが
-DWITH_DEBUGを使用して構築された場合を除く、この場合の最小値は 0)。サーバーの構築方法にかかわらず、デフォルト値は 300 であり、最大可能値は 4294967296 (4G バイト) です。slave_checkpoint_periodは MySQL 5.6.3 で追加されました。 -
Property Value コマンド行形式 --slave-compressed-protocolシステム変数 slave_compressed_protocolスコープ グローバル 動的 はい 型 ブール デフォルト OFFスレーブ/マスタープロトコルの圧縮を使用するかどうか (スレーブとマスターの両方がサポートしている場合)。
-
Property Value コマンド行形式 --slave-exec-mode=modeシステム変数 slave_exec_modeスコープ グローバル 動的 はい 型 列挙 デフォルト IDEMPOTENT(NDB)STRICT(Other)有効な値 IDEMPOTENTSTRICTIDEMPOTENTまたは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でのみサポートされます。 -
Property Value コマンド行形式 --slave-load-tmpdir=pathシステム変数 slave_load_tmpdirスコープ グローバル 動的 いいえ 型 ディレクトリ名 デフォルト /tmpLOAD DATA INFILEステートメントを複製するためにスレーブが一時ファイルを作成するディレクトリの名前。 -
Property Value 導入 5.6.6 システム変数 slave_max_allowed_packetスコープ グローバル 動的 はい 型 数値 デフォルト 1073741824最小値 1024最大値 1073741824MySQL 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オプションを使用して、起動時に設定することもできます。 -
Property Value コマンド行形式 --slave-net-timeout=#システム変数 slave_net_timeoutスコープ グローバル 動的 はい 型 数値 デフォルト 3600最小値 1マスター/スレーブ接続から後続のデータを待機する秒数 (これ以降は、読み取りを中止)。
-
Property Value コマンド行形式 --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)。 -
Property Value 導入 5.6.3 システム変数 slave_pending_jobs_size_maxスコープ グローバル 動的 はい 型 数値 デフォルト 0最小値 1024最大値 18EBブロックサイズ 1024マルチスレッドスレーブの場合、この変数は、まだ適用されていないイベントを保持するスレーブワーカーキューに使用可能な最大メモリー量 (バイト単位) を設定します。この変数を設定しても、マルチスレッドが有効ではないスレーブには影響しません。
この変数の可能な最小値は 1024 で、デフォルトは 16M バイトです。可能な最大値は 18446744073709551615 (16E バイト) です。1024 の正確な倍数でない値は、保存される前に次に大きい 1024 の倍数に丸められます。
重要この変数の値はマスターの
max_allowed_packetの値以上である必要があります。そうでない場合は、マスターから到着する処理すべきイベントが残っているときにスレーブワーカーキューがいっぱいになる場合があります。slave_pending_jobs_size_maxは MySQL 5.6.3 で追加されました。 -
Property Value 導入 5.6.6 システム変数 slave_rows_search_algorithms=listスコープ グローバル 動的 はい 型 セット デフォルト TABLE_SCAN,INDEX_SCAN有効な値 TABLE_SCAN,INDEX_SCANINDEX_SCAN,HASH_SCANTABLE_SCAN,HASH_SCANTABLE_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_SCANINDEX_SCAN,TABLE_SCANTABLE_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 で追加されました。
-
Property Value コマンド行形式 --slave-skip-errors=nameシステム変数 slave_skip_errorsスコープ グローバル 動的 いいえ 型 文字列 デフォルト OFF有効な値 OFF[list of error codes]allddl_exist_errors有効な値 OFF[list of error codes]allddl_exist_errors有効な値 OFF[list of error codes]allレプリケーションは通常、スレーブでエラーが発生したときに停止します。これは、データ内の不一致を手動で解決する機会です。この変数は、ステートメントが変数値にリストされたエラーを返すときに、レプリケーションを継続するようにスレーブ SQL スレッドに指示します。
-
Property Value 導入 5.6.2 システム変数 slave_sql_verify_checksumスコープ グローバル 動的 はい 型 ブール デフォルト 1有効な値 01スレーブ SQL スレッドはリレーログから読み取られたチェックサムを使用してデータを検証します。不一致があった場合、スレーブはエラーで停止します。
注記スレーブ I/O スレッドは常に、ネットワークからイベントを受け取るときに可能であればチェックサムを読み取ります。
slave_sql_verify_checksumは MySQL 5.6.2 で追加されました。 -
Property Value コマンド行形式 --slave-transaction-retries=#システム変数 slave_transaction_retriesスコープ グローバル 動的 はい 型 数値 デフォルト 10最小値 0最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295InnoDBデッドロック、またはトランザクションの実行時間がInnoDBのinnodb_lock_wait_timeout、またはNDBのTransactionDeadlockDetectionTimeoutまたはTransactionInactiveTimeoutを超えたために、レプリケーションスレーブ SQL スレッドがトランザクションの実行に失敗した場合、自動的にslave_transaction_retries回再試行してからエラーで停止します。デフォルト値は 10 です。マルチスレッドスレーブを使用するときは、トランザクションを再試行できません。つまり、
slave_parallel_workersが 0 より大きい場合は、slave_transaction_retriesが 0 に等しいとして扱われ、変更できません。 -
Property Value コマンド行形式 --slave-type-conversions=setシステム変数 slave_type_conversionsスコープ グローバル 動的 いいえ 型 セット デフォルト 有効な値 (>= 5.6.13) ALL_LOSSYALL_NON_LOSSYALL_SIGNEDALL_UNSIGNED有効な値 (<= 5.6.12) ALL_LOSSYALL_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)。行ベースレプリケーションで属性の昇格と降格に適用できるタイプ変換モードの詳細については、行ベースレプリケーション: 属性の昇格と降格を参照してください。 -
Property Value システム変数 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 構文」を参照してください。
-
Property Value コマンド行形式 --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 です。 -
Property Value コマンド行形式 --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 つです)。しかし、一番遅い選択でもあります (ディスクにバッテリ付きキャッシュがある場合を除きます。その場合は同期が非常に速くなります)。
-
Property Value コマンド行形式 --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_inforelay_log_info_repositoryFILETABLEトランザクション対応 トランザクション対応でない N> 0スレーブは各
Nトランザクション後にそのrelay-log.infoファイルをディスクに同期します (fdatasync()を使用)。テーブルは各トランザクション後に更新されます。(
Nは事実上無視されます。)テーブルは各
Nイベント後に更新されます。0MySQL サーバーは
relay-log.infoファイルからディスクへの同期を実行しません。代わりに、サーバーはオペレーティングシステムに依存してほかのファイルと同様にその内容を定期的にフラッシュします。テーブルは更新されません。
sync_relay_log_infoのデフォルト値は、MySQL 5.6.6 以降では 10000、それより前は 0 です。
User Comments
User comments in this section are, as the name implies, provided by MySQL users.
The MySQL documentation team is not responsible for, nor do they endorse, any of
the information provided here.
[ERROR] Failed to open the relay log './zeus-relay-bin.000009' (relay_log_pos 251)
120216 17:11:31 [ERROR] Could not find target log during relay log initialization
When I changed the name from zeus to perseo.
My solution was to delete the files with old server name, I mean zeus-relay-* and delete relay-log.info.
It just worked for me.
However, in our reasonably high traffic environment (each master has three slaves on a very low-latency network, a 1G compressed binlog takes about a week to rotate), setting this value to 30 seconds caused recurring replication problems. The slaves started and stopped replicating with the message "Waiting to reconnect after a failed master event read." stop slave - start slave did not fix them (in fact we believe it made the problem worse). Removing the slave_net_timeout value from mysql.ini fixed replication immediately.