このセクションで説明する 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_table
SET 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 より前は、このオプションにより、デフォルトデータベースが指定されなかった場合 (つまり、
SELECT
DATABASE()
が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
有効な値 NONE
CRC32
このオプションを有効にすることで、マスターはバイナリログに書き込まれるイベントのチェックサムを書き込みます。
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
有効な値 NONE
CRC32
この変数が有効のときは、マスターはバイナリログに各イベントのチェックサムを書き込みます。
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_ERROR
ABORT_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
有効な値 ROW
STATEMENT
MIXED
この変数はバイナリロギング形式を設定し、
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
スコープ グローバル 動的 いいえ 型 ブール デフォルト FALSE
MySQL バージョン 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_ERROR
ABORT_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
スコープ グローバル、セッション 動的 はい 型 ブール デフォルト FALSE
binlog_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
スコープ グローバル 動的 いいえ 型 ブール デフォルト 0
MySQL 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 つです)。しかし、一番遅い選択でもあります (ディスクにバッテリ付きキャッシュがある場合を除きます。その場合は同期が非常に速くなります)。