PDF (US Ltr)
- 26.8Mb
PDF (A4)
- 26.8Mb
このセクションで説明する mysqld オプションおよびシステム変数を使用して、バイナリログの操作に影響を与えたり、バイナリログにどのステートメントが書き込まれたかを制御したりできます。バイナリログの追加情報については、セクション5.2.4「バイナリログ」を参照してください。MySQL サーバーのオプションとシステム変数の使用に関する追加情報については、セクション5.1.3「サーバーコマンドオプション」およびセクション5.1.4「サーバーシステム変数」を参照してください。
次のリストでは、バイナリログを有効化したり構成したりするための起動オプションについて説明します。バイナリロギングで使用するシステム変数については、このセクションの後半で説明します。
-
コマンド行形式 --binlog-row-event-max-size=#型 数値 デフォルト (64 ビットプラットフォーム, ≥ 5.6.6) 8192デフォルト (64 ビットプラットフォーム, ≤ 5.6.5) 1024デフォルト (32 ビットプラットフォーム, ≥ 5.6.6) 8192デフォルト (32 ビットプラットフォーム, ≤ 5.6.5) 1024最小値 256最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295行ベースのバイナリログイベントの最大サイズをバイト単位で指定します。可能であれば、行はこのサイズより小さいイベントにグループ化されます。値は 256 の倍数であるべきです。デフォルトは、MySQL 5.6.6 以降では 8192、それより前では 1024 です。セクション17.1.2「レプリケーション形式」を参照してください。
-
コマンド行形式 --log-binシステム変数 log_binスコープ グローバル 動的 いいえ 型 ファイル名 バイナリロギングを有効化します。サーバーはデータを変更するすべてのステートメントのログをバイナリログに記録し、これはバックアップとレプリケーションに使用されます。セクション5.2.4「バイナリログ」を参照してください。
オプション値 (指定された場合) はログシーケンスのベース名です。サーバーは、ベース名に数字サフィクスを追加することで、バイナリログファイルを次々に作成します。ベース名を指定することをお勧めします (その理由は セクションB.5.8「MySQL の既知の問題」を参照してください)。そうでない場合、MySQL はベース名として
host_name-binMySQL 5.6.5 以降のサーバーは、インデックスファイルからエントリを読み取るときに、エントリに相対パスが含まれるかどうかをチェックし、さらにそうである場合は、パスの相対部が
--log-binオプションを使用して設定された絶対パスに置き換えられます。絶対パスは変わりません。このような場合、使用される新しいパスを有効にするために、インデックスを手動で編集する必要があります。MySQL 5.6.5 より前は、バイナリログまたはリレーログファイルの位置を変更するときは、手動介入が必要でした。(Bug #11745230、Bug #12133)このオプションを設定することで、
log_binシステム変数はON(または1) に設定されます (ベース名にではなく)。MySQL 5.6.2 以降では、バイナリログファイル名 (パス付き) はlog_bin_basenameシステム変数として使用できます。 -
コマンド行形式 --log-bin-index=file_name型 ファイル名 バイナリログファイル名のインデックスファイル。セクション5.2.4「バイナリログ」を参照してください。ファイル名を省略した場合、および
--log-binでこれを指定しなかった場合、MySQL はファイル名としてhost_name-bin.index -
--log-bin-trust-function-creators[={0|1}]コマンド行形式 --log-bin-trust-function-creatorsシステム変数 log_bin_trust_function_creatorsスコープ グローバル 動的 はい 型 ブール デフォルト FALSEこのオプションは対応する
log_bin_trust_function_creatorsシステム変数を設定します。引数が指定されない場合、このオプションは変数を 1 に設定します。log_bin_trust_function_creatorsは、ストアドファンクションおよびトリガー作成に対して MySQL がどのように制限を適用するかに影響します。セクション20.7「ストアドプログラムのバイナリロギング」を参照してください。 -
--log-bin-use-v1-row-events[={0|1}]コマンド行形式 --log-bin-use-v1-row-events[={0|1}]導入 5.6.6 システム変数 log_bin_use_v1_row_eventsスコープ グローバル 動的 いいえ 型 ブール デフォルト 0バージョン 2 バイナリログ行イベントを MySQL 5.6.6 以降で使用できます。ただし、バージョン 2 イベントは前の MySQL Server リリースで読み取れません。このオプションを 1 に設定することで、mysqld はバージョン 1 ロギングイベント （これが、以前のリリースで使用されるバイナリログイベントの唯一のバージョン） を使用してバイナリログを書き込み、古いスレーブで読み取れるバイナリログを生成します。
--log-bin-use-v1-row-eventsを 0 (デフォルト) に設定することで、mysqld はバージョン 2 バイナリログイベントを使用します。このオプションに使用される値は、読み取り専用
log_bin_use_v1_row_eventsシステム変数から取得できます。--log-bin-use-v1-row-eventsは主に、NDB$EPOCH_TRANS()(バージョン 2 バイナリログ行イベントが必要) を競合検出関数として使用してレプリケーション競合検出および解決をセットアップするときに役立ちます。したがって、このオプションと--ndb-log-transaction-idは互換性がありません。詳細は、セクション18.6.11「MySQL Cluster レプリケーションの競合解決」を参照してください。
-
コマンド行形式 --log-short-format型 ブール デフォルト FALSEバイナリログおよびスロークエリーログがアクティブ化されている場合、これらのログに記録する情報を少なくします。
ステートメント選択オプション 次のリスト内のオプションは、どのステートメントがバイナリログに書き込まれ、レプリケーションマスターサーバーによってそのスレーブに送られるかを制御します。マスターから受け取ったステートメントのどれを実行または無視すべきかを制御する、スレーブサーバーのオプションもあります。詳細については、セクション17.1.4.3「レプリケーションスレーブのオプションと変数」を参照してください。
-
コマンド行形式 --binlog-do-db=name型 文字列 このオプションは、
--replicate-do-dbがレプリケーションに影響するのと同様にバイナリロギングに影響します。このオプションの影響は、ステートメントベースまたは行ベースロギング形式のどちらが使用されるかに依存します (
--replicate-do-dbの影響がステートメントベースまたは行ベースレプリケーションのどちらが使用されたかに依存すると同じ)。指定されたステートメントのログを記録するために使用される形式が、binlog_formatの値で示される形式と必ずしも同じではないことに留意してください。たとえば、CREATE TABLEやALTER TABLEなどの DDL ステートメントは、有効になっているロギング形式にかかわらず、常にステートメントとしてログが記録されるため、--binlog-do-dbの次のステートメントベースルールはステートメントのログが記録されるかどうかの判断に常に適用されます。ステートメントベースのロギング デフォルトデータベース (つまり、
USEで選択されたもの) がdb_nameであるステートメントだけが、バイナリログに書き込まれます。複数のデータベースを指定するには、このオプションを複数回 （データベースごとに 1 回） 使用します。ただし、このようにしても、別のデータベースが選択されているとき （またはデータベースが選択されていないとき） に、UPDATEなどのクロスデータベースステートメントのログは記録されません。some_db.some_tableSET foo='bar'警告複数のデータベースを指定するには、このオプションの複数インスタンスを使用する必要があります。データベース名にカンマを含めることができるため、カンマ区切りリストを指定した場合は、リストは単一データベースの名前として扱われます。
ステートメントベースロギングを使用するときに想定される、機能しない例: サーバーが
--binlog-do-db=salesで起動され、次のステートメントを発行する場合、UPDATEステートメントのログは記録されません。USE prices; UPDATE sales.january SET amount=amount+1000;この「デフォルトデータベースをチェックするだけ」動作の主な理由は、ステートメントだけから複製すべきかどうかを知ることが難しいことです (たとえば、複数のデータベースをまたがって動作する複数テーブル
DELETEステートメントまたは複数テーブルUPDATEステートメントを使用する場合)。また、必要がない場合、すべてのデータベースではなくデフォルトデータベースだけをチェックする方が早いです。もう 1 つのケースは自明ではないかもしれませんが、オプションを設定するときに指定されなかったけれども所定のデータベースが複製されます。サーバーが
--binlog-do-db=salesで起動される場合、--binlog-do-dbの設定時にpricesが含まれなかったけれども、次のUPDATEステートメントのログが記録されます。USE sales; UPDATE prices.discounts SET percentage = percentage + 10;UPDATEステートメントが発行されたときにsalesがデフォルトデータベースであるため、UPDATEのログが記録されます。行ベースのロギング ロギングはデータベース
db_nameに制限されます。db_nameに属するテーブルへの変更だけがログに記録されます。デフォルトデータベースはこれに影響しません。サーバーが--binlog-do-db=salesで起動され、行ベースロギングが有効であると想定すると、次のステートメントが実行されます。USE prices; UPDATE sales.february SET amount=amount+100;salesデータベース内のfebruaryテーブルへの変更が、UPDATEステートメントに従ってログに記録されます。これはUSEステートメントが発行されたかどうかにかかわらず発生します。ただし、行ベースロギング形式および--binlog-do-db=salesを使用するときは、次のUPDATEによって行われた変更のログは記録されません。USE prices; UPDATE prices.march SET amount=amount-25;USE pricesステートメントがUSE salesに変更された場合でも、UPDATEステートメントの結果は依然としてバイナリログに書き込まれません。--binlog-do-db処理でステートメントベースロギングと行ベースロギング間のもう 1 つの重要な違いは、複数のデータベースを参照するステートメントに関して発生します。サーバーが--binlog-do-db=db1で起動され、次のステートメントが実行されると想定します。USE db1; UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;ステートメントベースロギングを使用している場合、両方のテーブルへの更新がバイナリログに書き込まれます。一方、行ベース形式を使用するときは、
table1への変更だけがログに記録されます。table2は別のデータベース内にあり、UPDATEによって変更されません。ここで、USE db1ステートメントの代わりに、USE db4ステートメントが使用されたものとします。USE db4; UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;この場合、ステートメントベースロギングを使用するときに
UPDATEステートメントはバイナリログに書き込まれません。一方、行ベースロギングを使用するときは、table1への変更のログは記録されますが、table2へはそうなりません。つまり、--binlog-do-dbによって指定されたデータベース内のテーブルへの変更のみがログに記録され、デフォルトデータベースの選択はこの動作に影響しません。 -
コマンド行形式 --binlog-ignore-db=name型 文字列 このオプションは、
--replicate-ignore-dbがレプリケーションに影響するように、バイナリロギングに影響します。このオプションの影響は、ステートメントベースまたは行ベースロギング形式のどちらが使用されるかに依存します (
--replicate-ignore-dbの影響がステートメントベースまたは行ベースレプリケーションのどちらが使用されたかに依存すると同じ)。指定されたステートメントのログを記録するために使用される形式が、binlog_formatの値で示される形式と必ずしも同じではないことに留意してください。たとえば、CREATE TABLEやALTER TABLEなどの DDL ステートメントは、有効になっているロギング形式にかかわらず、常にステートメントとしてログが記録されるため、--binlog-ignore-dbの次のステートメントベースルールはステートメントのログが記録されるかどうかの判断に常に適用されます。ステートメントベースのロギング デフォルトデータベース (つまり、
USEで選択されたもの) がdb_nameであるステートメントのログを記録しないようにサーバーに指示します。MySQL 5.6.12 より前は、このオプションにより、デフォルトデータベースが指定されなかった場合 (つまり、
SELECTDATABASE()がNULLを返したとき) は、完全修飾テーブル名を含むステートメントのログを記録しませんでした。MySQL 5.6.12 以降では、デフォルトデータベースがないときは、--binlog-ignore-dbオプションは適用されず、常にこのようなステートメントのログが記録されます。(Bug #11829838、Bug #60188)行ベース形式 データベース
db_name内のテーブルへの更新のログを記録しないようにサーバーに指示します。現在のデータベースは影響しません。ステートメントベースロギングを使用するとき、次の例は予期するとおりに機能しません。サーバーが
--binlog-ignore-db=salesで起動され、次のステートメントを発行すると想定します。USE prices; UPDATE sales.january SET amount=amount+1000;--binlog-ignore-dbがデフォルトデータベース (USEステートメントで決定) にのみ適用されるため、このような場合はUPDATEステートメントのログが記録されます。salesデータベースがステートメントで明示的に指定されたため、ステートメントはフィルタされませんでした。一方、行ベースロギングを使用するときは、UPDATEステートメントの結果はバイナリログに書き込まれず、これはsales.januaryテーブルへの変更がログに記録されないことを意味します。この例では、--binlog-ignore-db=salesによって、マスターのsalesデータベースのコピー内のテーブルに加えられたすべての変更がバイナリロギングのために無視されます。無視するデータベースを複数指定するには、このオプションを複数回 (データベースごとに 1 回) 使用します。データベース名にカンマを含めることができるため、カンマ区切りリストを指定した場合は、リストは単一データベースの名前として扱われます。
クロスデータベース更新を使用していて、それらの更新ログを記録したくない場合は、このオプションを使用しないでください。
チェックサムオプション MySQL 5.6.2 以降では、MySQL はバイナリログチェックサムの読み取りと書き込みをサポートします。これらは、ここで示す 2 つのオプションを使用して有効化されます。
-
--binlog-checksum={NONE|CRC32}コマンド行形式 --binlog-checksum=type導入 5.6.2 型 文字列 デフォルト (≥ 5.6.6) CRC32デフォルト (≤ 5.6.5) NONE有効な値 NONECRC32このオプションを有効にすることで、マスターはバイナリログに書き込まれるイベントのチェックサムを書き込みます。
NONEに設定すると無効になり、そうしない場合は、アルゴリズムの名前を使用してチェックサムが生成されます。現在のところ、CRC32 チェックサムだけがサポートされます。MySQL 5.6.6 以降では、CRC32 がデフォルトです。このオプションは MySQL 5.6.2 で追加されました。
-
--master-verify-checksum={0|1}コマンド行形式 --master-verify-checksum=name導入 5.6.2 型 ブール デフォルト OFFこのオプションを有効にすることで、マスターはチェックサムを使用してバイナリログからのイベントを検証し、不一致の場合はエラーで停止します。デフォルトで無効になっています。
このオプションは MySQL 5.6.2 で追加されました。
スレーブ （リレーから） ログによるチェックサム読み取りを制御するには、--slave-sql-verify-checksum オプションを使用します。
テストおよびデバッグのオプション 次のバイナリログオプションは、レプリケーションテストおよびデバッグで使用されます。これらは通常操作での使用を意図していません。
-
コマンド行形式 --max-binlog-dump-events=#型 数値 デフォルト 0このオプションは、レプリケーションのテストとデバッグのために、MySQL テストスイートで内部的に使用されます。
-
コマンド行形式 --sporadic-binlog-dump-fail型 ブール デフォルト FALSEこのオプションは、レプリケーションのテストとデバッグのために、MySQL テストスイートで内部的に使用されます。
-
--binlog-rows-query-log-eventsコマンド行形式 --binlog-rows-query-log-events導入 5.6.2 型 ブール デフォルト FALSEこのオプションは MySQL 5.6.2 で追加され、
binlog_rows_query_log_eventsを有効にします。MySQL 5.6.1 以前のスレーブサーバーまたは mysqlbinlog のバージョンのためにログを生成するときは、OFF(デフォルト) に設定する必要があります。
次の一覧で、バイナリロギングを制御するためのシステム変数について説明します。これらはサーバー起動時に設定でき、それらの一部は SET を使用して実行時に変更できます。バイナリロギングを制御するために使用されるサーバーオプションは、このセクションですでにリストされています。sql_log_bin および sql_log_off 変数については、セクション5.1.4「サーバーシステム変数」を参照してください。
-
コマンド行形式 --binlog-cache-size=#システム変数 binlog_cache_sizeスコープ グローバル 動的 はい 型 数値 デフォルト 32768最小値 4096最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295トランザクション中にバイナリログへの変更を保持するキャッシュのサイズ。サーバーがトランザクションストレージエンジンをサポートし、サーバーのバイナリログが有効 (
--log-binオプション) になっている場合は、バイナリログキャッシュがクライアントごとに割り当てられます。大きなトランザクションをよく使用する場合、パフォーマンスを向上するためにこのキャッシュサイズを増やすことができます。Binlog_cache_useおよびBinlog_cache_disk_useステータス変数は、この変数のサイズを調整するために役立つことがあります。セクション5.2.4「バイナリログ」を参照してください。binlog_cache_sizeはトランザクションキャッシュのみのサイズを設定します。ステートメントキャッシュのサイズはbinlog_stmt_cache_sizeシステム変数によって管理されます。 -
導入 5.6.2 システム変数 binlog_checksumスコープ グローバル 動的 はい 型 文字列 デフォルト (≥ 5.6.6) CRC32デフォルト (≤ 5.6.5) NONE有効な値 NONECRC32この変数が有効のときは、マスターはバイナリログに各イベントのチェックサムを書き込みます。
binlog_checksumは値NONE(無効) およびCRC32をサポートします。デフォルトは MySQL 5.6.6 以降ではCRC32、それより前はNONEです。binlog_checksumが無効 (値NONE) のときは、サーバーは各イベントのイベント長 （チェックサムではなく） を書き込んでチェックすることで、すべてそろったイベントのみをバイナリログに書き込んでいることを検証します。この変数の値を変更すると、バイナリログがローテーションします。チェックサムは常にバイナリログファイル全体に (その一部だけにではなく) 書き込まれます。
この変数は MySQL 5.6.2 で追加されました。
MySQL 5.6.6 以降では、マスター上のこの変数をスレーブで認識されない値に設定すると、スレーブは独自の
binlog_checksum値をNONEに設定し、レプリケーションをエラーで停止します。(Bug #13553750、Bug #61096) 古いスレーブとの下位互換性が懸念される場合は、明示的に値をNONEに設定することをお勧めします。 -
binlog_direct_non_transactional_updatesコマンド行形式 --binlog-direct-non-transactional-updates[=value]システム変数 binlog_direct_non_transactional_updatesスコープ グローバル、セッション 動的 はい 型 ブール デフォルト OFFトランザクションテーブルおよび非トランザクションテーブルの両方への更新がトランザクションに含まれるときは、並列問題によってスレーブが不整合になる可能性があります。MySQL は、非トランザクションステートメントをトランザクションキャッシュに書き込むことで （コミット時にフラッシュされる）、これらのステートメント間の因果関係を維持しようとします。ただし、トランザクションに代わって非トランザクションテーブルに行われた変更がほかの接続にただちに可視になるときに、問題が起こります (これらの変更がただちにバイナリログに書き込まれない場合があるため)。
binlog_direct_non_transactional_updates変数は、この問題に対する 1 つの可能な回避策を提供します。デフォルトでは、この変数は無効です。binlog_direct_non_transactional_updatesを有効にすることで、非トランザクションテーブルへの更新が、トランザクションキャッシュではなく直接バイナリログに書き込まれます。binlog_direct_non_transactional_updatesは、ステートメントベースバイナリロギング形式を使用して複製されるステートメントにのみ機能します。つまり、binlog_formatの値がSTATEMENTのとき、またはbinlog_formatがMIXEDで、与えられたステートメントがステートメントベース形式を使用して複製されているときにのみ機能します。バイナリログ形式がROWのとき、またはbinlog_formatがMIXEDに設定され、与えられたステートメントが行ベース形式で複製されるときは、この変数は効果がありません。重要この変数を有効にする前に、トランザクションおよび非トランザクションテーブルの間に依存関係がないことを確認する必要があります。このような依存関係の例は、ステートメント
INSERT INTO myisam_table SELECT * FROM innodb_tableです。そうでない場合、このようなステートメントによって、スレーブとマスターの間に相違が発生する可能性があります。MySQL 5.6 では、バイナリログ形式が
ROWまたはMIXEDのとき、この変数は効果がありません。(Bug #51291) -
コマンド行形式 --binlog-error-action[=value]導入 5.6.22 システム変数 binlog_error_actionスコープ グローバル、セッション 動的 はい 型 列挙 デフォルト IGNORE_ERROR有効な値 IGNORE_ERRORABORT_SERVERサーバーがバイナリログに書き込みめないとき (マスターのログが不整合になり、レプリケーションスレーブが同期を失う可能性がある) に何が起きるかを制御します。以前のリリースでは、名前
binlogging_impossible_modeを使用していました。MySQL 5.6 では、
binlog_error_actionのデフォルトはIGNORE_ERRORで、サーバーがエラーのログを記録し、ロギングを停止してから、更新の実行を継続することを意味します。これは、古いバージョンの MySQL Server との下位互換性を提供するためです。この変数をABORT_SERVERに設定すると、サーバーがバイナリログに書き込めないときはロギングを停止し、シャットダウンします。これが推奨される設定です (特に複雑なレプリケーション環境で)。 -
コマンド行形式 --binlog-format=formatシステム変数 binlog_formatスコープ グローバル、セッション 動的 はい 型 列挙 デフォルト (≥ 5.6.10-ndb-7.3.1) MIXEDデフォルト STATEMENT有効な値 ROWSTATEMENTMIXEDこの変数はバイナリロギング形式を設定し、
STATEMENT、ROW、MIXEDのいずれかが可能です。セクション17.1.2「レプリケーション形式」を参照してください。binlog_formatは、起動時に--binlog-formatオプションで、または実行時にbinlog_format変数で設定されます。注記実行時にロギング形式を変更できますが、レプリケーションの進行中に変更することは推奨されていません。これは一つには、スレーブがマスターの
binlog_format設定に従わず、所定の MySQL Server が独自のロギング形式のみを変更できるという事実によります。MySQL 5.6 では、デフォルト形式は
STATEMENTです。例外: MySQL Cluster NDB 7.3 以降では、デフォルトはMIXEDです。ステートメントベースレプリケーションは MySQL Cluster ではサポートされていません。グローバルまたはセッション
binlog_format値を設定するには、SUPER権限が必要です。この変数への変更がいつ有効になり、影響はどのくらい長く続くかを管理するルールは、ほかの MySQL サーバーシステム変数の場合と同じです。詳細については、セクション13.7.4「SET 構文」を参照してください。
MIXEDが指定されている場合、行ベースレプリケーションだけが適切な結果になることが保証されている場合を除き、ステートメントベースレプリケーションが使用されます。たとえば、これはユーザー定義関数 (UDF) またはUUID()関数がステートメントに含まれているときに発生します。このルールの例外は、MIXEDがストアドファンクションおよびトリガーのために常にステートメントベースレプリケーションを使用することです。レプリケーション形式を実行時に切り替えることができない例外もあります。
ストアドファンクションまたはトリガー内から。
セッションが現在行ベースレプリケーションモードで、開いている一時テーブルを持つ場合。
トランザクション内から。
これらの場合に形式を切りかえようとするとエラーになります。
バイナリログ形式は次のサーバーオプションの動作に影響を与えます。
--replicate-do-db--replicate-ignore-db--binlog-do-db--binlog-ignore-db
これらの影響の詳細は、個々のオプションの説明に記載されています。
-
binlog_gtid_recovery_simplifiedコマンド行形式 --binlog-gtid-recovery-simplified導入 5.6.23 システム変数 binlog_gtid_recovery_simplifiedスコープ グローバル 動的 いいえ 型 ブール デフォルト FALSEMySQL バージョン 5.6.21 では、この変数は
simplified_binlog_gtid_recoveryとして追加され、MySQL バージョン 5.6.23 では、その名前がbinlog_gtid_recovery_simplifiedに変わりました。デフォルトでは、MySQL はクラッシュからリカバリするときに、バイナリログファイルを反復して一番古いファイルから始めて GTID イベントを検索するため、大量のバイナリログファイルがある場合はこれに時間がかかることがあります。このオプションを有効にすることで、代わりに一番新しいバイナリログファイルから GTID イベントが検索されます。
Previous_gtids_log_eventおよびGtid_log_eventが検出されると、gtid_executedとgtid_purgedはリカバリ中に通常どおりこれらのイベントを使用して初期化されます。GTID イベントが検出されない場合は、2 番目のスキャンが一番古いバイナリログファイルから GTID イベントを検索します。これらのファイルのどちらにも GTID イベントが含まれない場合は、これ以上バイナリログファイルは検索されず、gtid_executedとgtid_purgedは空の文字列に設定されます。 -
コマンド行形式 --binlogging-impossible-mode[=value]導入 5.6.20 非推奨 5.6.22 システム変数 binlogging_impossible_modeスコープ グローバル、セッション 動的 はい 型 列挙 デフォルト IGNORE_ERROR有効な値 IGNORE_ERRORABORT_SERVERこのオプションは非推奨で、今後の MySQL リリースで削除される予定です。名前が変更された
binlog_error_actionを使用して、サーバーがバイナリログに書き込めないときに何が起きるかを制御してください。 -
導入 5.6.6 システム変数 binlog_max_flush_queue_timeスコープ グローバル 動的 はい 型 数値 デフォルト 0最小値 0最大値 100000グループコミットを進める前にフラッシュキューからのトランザクション読み取り (および、
sync_binlogが 0 より大きい場合はログとディスクの同期) をどのくらい続けるか (マイクロ秒単位)。値が 0 (デフォルト) の場合、タイムアウトはなく、キューが空になるまでサーバーは新しいトランザクションの読み取りを続けます。通常、
binlog_max_flush_queue_timeを 0 に設定されたままでかまいません。サーバーが大量の接続 (たとえば、100 以上)、および低遅延要件の多くの短いトランザクションを処理する場合、0 より大きな値を設定して、ディスクへのフラッシュを強制的により頻繁にすることが役立つ場合があります。この変数は MySQL 5.6.6 で追加されました。
-
導入 5.6.6 システム変数 binlog_order_commitsスコープ グローバル 動的 はい 型 ブール デフォルト ONこの変数が有効の場合は (デフォルト)、トランザクションはバイナリログに書き込まれる順序と同じ順序でコミットされます。無効の場合は、トランザクションは並列にコミットされる場合があります。場合によっては、この変数を無効にすることでパフォーマンスが向上することがあります。
この変数は MySQL 5.6.6 で追加されました。
-
コマンド行形式 --binlog-row-image=image_type導入 5.6.2 システム変数 binlog_row_image=image_typeスコープ グローバル、セッション 動的 はい 型 列挙 デフォルト full有効な値 full(すべてのカラムをログに記録)minimal(変更されたカラムおよび、行を特定するために必要とされたカラムのみをログに記録)noblob(不要な BLOB カラムおよび TEXT カラム以外のすべてのカラムをログに記録)MySQL 行ベースレプリケーションでは、各行変更イベントに 2 つのイメージ、つまり「前」イメージ (更新される行を検索するときにこれらのカラムが照合される) と「後」イメージ (変更を含む) が含まれます。通常、MySQL は前イメージと後イメージの両方のためにすべての行 （つまり、すべてのカラム） のログを記録します。ただし、両方のイメージにすべてのカラムが厳密に含まれている必要はなく、多くの場合、実際に必要なカラムのログのみを記録することでディスク、メモリー、およびネットワーク使用量を節約できます。
注記行を削除するときは、削除後に伝達する変更後の値がないため、前イメージのみのログが記録されます。行を挿入するときは、照合される既存の行がないため、後イメージのみのログが記録されます。行を更新するときのみ、前イメージと後イメージの両方が必要で、両方がバイナリログに書き込まれます。
前イメージについては、行を一意に識別するために必要な最小カラムセットのログが記録されることのみが必要です。行を含むテーブルに主キーがある場合、主キーカラムだけがバイナリログに書き込まれます。そうではなく、テーブルに一意キーがあり、そのカラムのすべてが
NOT NULLの場合は、一意キー内のカラムのログのみを記録する必要があります。(テーブルにNULLカラムなしの主キーまたは一意キーがない場合、すべてのカラムが前イメージで使用され、それらのログが記録される必要があります。)後イメージでは、実際に変更されたカラムのログのみを記録する必要があります。MySQL 5.6 ではサーバーに、
binlog_row_imageシステム変数を使用して full または minimal 行のログを記録させることができます。この変数は実際には、次のリストで示す 3 つの可能な値の 1 つを取ることができます。full: 前イメージと後イメージの両方にすべてのカラムのログを記録します。minimal: 変更する行を識別するために必要なカラムのみのログを前イメージに記録し、実際に変更されるカラムのみのログを後イメージに記録します。noblob: すべてのカラム (fullと同じ) のログを記録しますが、行の識別に必要がない、または変更されなかったBLOBおよびTEXTカラムは除きます。
注記この変数は MySQL Cluster ではサポートされません。設定しても
NDBテーブルのロギングには影響しません。(Bug #16316828)デフォルト値は
fullです。MySQL 5.5 以前は、前イメージと後イメージの両方に常に full 行イメージが使用されます。MySQL 5.6 以降のマスターから以前のバージョンの MySQL を実行するからスレーブに複製する必要がある場合、マスターは常にこの値を使用してください。minimalまたはnoblobを使用するときは、ソーステーブルと宛先テーブルの両方について次の条件が true の場合にのみ、所定のテーブルに対して削除と更新が正しく機能することが保証されます。すべてのカラムが同じ順番で存在する必要があります。それぞれのカラムがもう一方のテーブル内の対応するものと同じデータ型を使用する必要があります。
これらのテーブルの主キー定義が同じである必要があります。
(つまり、これらのテーブルは同じである必要がありますが、テーブルの主キーの一部でないインデックスがある場合にはそれらは除きます。)
これらの条件が満たされない場合は、宛先テーブル内の主キーカラム値が、削除または更新のための一意一致を提供するために不十分であることが判明する場合があります。この場合、警告またはエラーは発行されません。マスターとスレーブはサイレントに相違し、一貫性がなくなります。
バイナリロギング形式が
STATEMENTのときは、この変数を設定しても効果はありません。binlog_formatがMIXEDのときは、binlog_row_imageの設定は行ベース形式を使用してログが記録される変更に適用されますが、この設定はステートメントとしてログが記録される変更には影響しません。グローバルまたはセッションレベルのいずれかで
binlog_row_imageを設定しても、暗黙的にコミットされません。これは、トランザクションの進行中にトランザクションに影響を与えずにこの変数を変更できることを意味します。 -
導入 5.6.2 システム変数 binlog_rows_query_log_eventsスコープ グローバル、セッション 動的 はい 型 ブール デフォルト FALSEbinlog_rows_query_log_eventsシステム変数は行ベースロギングにのみ影響します。有効のときは、MySQL 5.6.2 以降のサーバーは行クエリーログイベントなどの情報ログイベントをそのバイナリログに書き込みます。この情報は、デバッグおよび関連する目的 (マスター上で発行された元のクエリーを行更新から再構成できないときにそのクエリーを取得する、など) のために使用できます。これらのイベントは通常、バイナリログを読み取る MySQL 5.6.2 以降のプログラムで無視されるため、レプリケーションまたはバックアップからのリストア時に問題は発生しません。これは、MySQL 5.6.1 以前の mysqld または mysqlbinlog では true ではありません。ログを読み取る古いバージョンのプログラムが情報ログイベントに遭遇すると、それは失敗し、その時点で読み取りを停止します。MySQL 5.6.1 以前の配布からのスレーブレプリケーション MySQL サーバーおよびその他のリーダー (たとえば、mysqlbinlog) がバイナリログを読み取れるようにするには、ログ記録中は
binlog_rows_query_log_eventsを無効にする必要があります。 -
コマンド行形式 --binlog-stmt-cache-size=#導入 5.6.1 システム変数 binlog_stmt_cache_sizeスコープ グローバル 動的 はい 型 数値 デフォルト 32768最小値 4096最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295この変数は、トランザクション中に発行される非トランザクションステートメントを保持するバイナリログログ用キャッシュのサイズを決定します。サーバーがトランザクションストレージエンジンをサポートし、かつサーバーでバイナリログが有効 （
--log-binオプション） になっている場合は、個別のバイナリログトランザクションおよびステートメントキャッシュが各クライアントに割り当てられます。トランザクション中に大きな非トランザクションステートメントを頻繁に使用する場合は、このキャッシュサイズを増やしてパフォーマンスを向上させることができます。Binlog_stmt_cache_useおよびBinlog_stmt_cache_disk_useステータス変数は、この変数のサイズを調整する場合に役立つ場合があります。セクション5.2.4「バイナリログ」を参照してください。binlog_cache_sizeシステム変数はトランザクションキャッシュのサイズを設定します。 -
システム変数 log_binスコープ グローバル 動的 いいえ バイナリログが有効かどうか。
--log-binオプションが使用されている場合、この変数の値はONです。そうでない場合、OFFです。この変数は、バイナリロギングのステータス (有効または無効) についてのみ報告します。--log-binが設定されている値を実際に報告するわけではありません。セクション5.2.4「バイナリログ」を参照してください。
-
導入 5.6.2 システム変数 log_bin_basenameスコープ グローバル 動的 いいえ 型 ファイル名 デフォルト datadir + '/' + hostname + '-bin'バイナリログファイルの名前と完全パスを保持します。
log_binシステム変数とは異なり、log_bin_basenameは--log-binサーバーオプションで設定される名前を反映します。log_bin_basenameシステム変数は MySQL 5.6.2 で追加されました。 -
導入 5.6.4 システム変数 log_bin_indexスコープ グローバル 動的 いいえ 型 ファイル名 バイナリログファイル名のインデックスファイル。
log_bin_indexシステム変数は MySQL 5.6.4 で追加されました。 -
コマンド行形式 --log-bin-use-v1-row-events[={0|1}]導入 5.6.6 システム変数 log_bin_use_v1_row_eventsスコープ グローバル 動的 いいえ 型 ブール デフォルト 0MySQL 5.6.6 以降で使用可能なバージョン 2 バイナリロギングが使用されているかどうかを示します。値 1 は、サーバーがバージョン 1 ロギングイベント （MySQL 5.6.5 および以前の MySQL Server リリースで使用されるバイナリログイベントの唯一のバージョン） を使用してバイナリログを書き出していて、古いスレーブで読み取れるバイナリログを生成していることを示します。値 0 は、バージョン 2 バイナリログイベントが使用されていることを示します。
この変数は読み取り専用です。バージョン 1 および バージョン 2 バイナリイベントバイナリロギングを切りかえるには、mysqld を
--log-bin-use-v1-row-eventsオプションで再起動する必要があります。MySQL Cluster レプリケーションのアップグレードを実行するとき以外では、
--log-bin-use-v1-eventsは主に、NDB$EPOCH_TRANS()(バージョン 2 バイナリ行イベントロギングが必要) を使用してレプリケーション競合検出および解決をセットアップときに役立ちます。したがって、このオプションと--ndb-log-transaction-idは互換性がありません。注記MySQL Cluster NDB 7.3 以降はデフォルトでバージョン 2 バイナリログ行イベントを使用します。アップグレードまたはダウングレードを計画するとき、および MySQL Cluster Replication を使用してセットアップする場合は、このことに留意してください。
詳細は、セクション18.6.11「MySQL Cluster レプリケーションの競合解決」を参照してください。
-
コマンド行形式 --log-slave-updatesシステム変数 log_slave_updatesスコープ グローバル 動的 いいえ 型 ブール デフォルト FALSEスレーブサーバーがマスターサーバーから受け取った更新のログをスレーブ独自のバイナリログに記録する必要があるかどうか。この変数を有効にするには、スレーブでバイナリロギングを有効にする必要があります。セクション17.1.4「レプリケーションおよびバイナリロギングのオプションと変数」を参照してください。
-
導入 5.6.2 システム変数 master_verify_checksumスコープ グローバル 動的 はい 型 ブール デフォルト OFFこの変数を有効にすることで、マスターはバイナリログから読み取るときにチェックサムを検査します。
master_verify_checksumはデフォルトでは無効になっています。その場合は、マスターはバイナリログからのイベント長を使用してイベントを検証するため、すべてそろったイベントだけがバイナリログから読み取られます。この変数は MySQL 5.6.2 で追加されました。
-
コマンド行形式 --max-binlog-cache-size=#システム変数 max_binlog_cache_sizeスコープ グローバル 動的 はい 型 数値 デフォルト 18446744073709551615最小値 4096最大値 18446744073709551615トランザクション内の非トランザクションステートメントがこのバイト数より多くのメモリーを必要とする場合、サーバーはMulti-statement transaction required more than 'max_binlog_cache_size' bytes of storageエラーを生成します。最小値は 4096 です。可能な最大値は 16E バイト (エクサバイト) です。推奨される最大値は 4G バイトです。これは、MySQL が現在 4G バイトより大きなバイナリログ位置で作業できないという事実によります。
注記MySQL 5.6.7 より前では、64 ビット Windows プラットフォームは、この変数に格納された値を 4G に切り捨てました (これより大きい値に設定されたとしても) (Bug #13961678)。
max_binlog_cache_sizeはトランザクションキャッシュのみのサイズを設定します。ステートメントキャッシュの上限値はmax_binlog_stmt_cache_sizeシステム変数によって管理されます。MySQL 5.6 では、
max_binlog_cache_sizeのセッションの可視性はbinlog_cache_sizeシステム変数のものと一致します。つまり、この値の変更は、値が変更されたあとに起動された新しいセッションにのみ影響します。 -
コマンド行形式 --max-binlog-size=#システム変数 max_binlog_sizeスコープ グローバル 動的 はい 型 数値 デフォルト 1073741824最小値 4096最大値 1073741824バイナリログへの書き込みによって、現在のログファイルサイズがこの変数の値を超えた場合、サーバーはバイナリログをローテーションします (現在のファイルを閉じて、新しいものを開きます)。最小値は 4096 バイトです。最大値およびデフォルト値は 1G バイトです。
トランザクションはバイナリログにひとまとまりで書き込まれ、複数のバイナリログ間に分割されることはありません。このため、大きなトランザクションの場合、
max_binlog_sizeより大きいバイナリログファイルが見られることがあります。max_relay_log_sizeが 0 の場合、max_binlog_sizeの値がリレーログにも適用されます。 -
コマンド行形式 --max-binlog-stmt-cache-size=#導入 5.6.1 システム変数 max_binlog_stmt_cache_sizeスコープ グローバル 動的 はい 型 数値 デフォルト 18446744073709547520最小値 4096最大値 18446744073709547520トランザクション内の非トランザクションステートメントがこのバイト数より多くのメモリーを必要とする場合、サーバーはエラーを生成します。最小値は 4096 です。最大値およびデフォルト値は、32 ビットプラットフォームでは 4G バイト、64 ビットプラットフォームでは 16E バイト (エクサバイト) です。
注記MySQL 5.6.7 より前では、64 ビット Windows プラットフォームは、この変数に格納された値を 4G に切り捨てました (これより大きい値に設定されたとしても) (Bug #13961678)。
max_binlog_stmt_cache_sizeはステートメントキャッシュのみのサイズを設定します。トランザクションキャッシュの上限値はmax_binlog_cache_sizeシステム変数によって排他的に管理されます。 -
コマンド行形式 --sync-binlog=#システム変数 sync_binlogスコープ グローバル 動的 はい 型 数値 デフォルト 0最小値 0最大値 4294967295この変数の値が 0 より大きい場合は、
sync_binlogコミットグループがバイナリログに書き込まれたあとに、MySQL サーバーはそのバイナリログをディスクに同期します (fdatasync()を使用)。sync_binlogのデフォルト値は 0 で、これはディスクに同期しません。この場合、サーバーはオペレーティングシステムに依存して、ほかのファイルに関してバイナリログの内容をときどきフラッシュします。値 1 が一番安全な選択です (クラッシュの場合にバイナリログから失われるコミットグループが最大で 1 つです)。しかし、一番遅い選択でもあります (ディスクにバッテリ付きキャッシュがある場合を除きます。その場合は同期が非常に速くなります)。