Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 27.1Mb
PDF (A4) - 27.2Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


17.1.4.4 バイナリログのオプションと変数

バイナリロギングで使用する起動オプション

バイナリロギングで使用されるシステム変数

このセクションで説明する mysqld オプションおよびシステム変数を使用して、バイナリログの操作に影響を与えたり、バイナリログにどのステートメントが書き込まれたかを制御したりできます。バイナリログの追加情報については、セクション5.2.4「バイナリログ」を参照してください。MySQL サーバーのオプションとシステム変数の使用に関する追加情報については、セクション5.1.3「サーバーコマンドオプション」およびセクション5.1.4「サーバーシステム変数」を参照してください。

バイナリロギングで使用する起動オプション

次のリストでは、バイナリログを有効化したり構成したりするための起動オプションについて説明します。バイナリロギングで使用するシステム変数については、このセクションの後半で説明します。

  • --binlog-row-event-max-size=N

    コマンド行形式 --binlog-row-event-max-size=#
    許可されている値 (32 ビットプラットフォーム, <= 5.6.5) 数値
    デフォルト 1024
    最小値 256
    最大値 4294967295
    許可されている値 (32 ビットプラットフォーム, >= 5.6.6) 数値
    デフォルト 8192
    最小値 256
    最大値 4294967295
    許可されている値 (64 ビットプラットフォーム, <= 5.6.5) 数値
    デフォルト 1024
    最小値 256
    最大値 18446744073709551615
    許可されている値 (64 ビットプラットフォーム, >= 5.6.6) 数値
    デフォルト 8192
    最小値 256
    最大値 18446744073709551615

    行ベースのバイナリログイベントの最大サイズをバイト単位で指定します。可能であれば、行はこのサイズより小さいイベントにグループ化されます。値は 256 の倍数であるべきです。デフォルトは、MySQL 5.6.6 以降では 8192、それより前では 1024 です。セクション17.1.2「レプリケーション形式」を参照してください。

  • --log-bin[=base_name]

    コマンド行形式 --log-bin
    システム変数 名前 log_bin
    スコープ グローバル
    動的 いいえ
    許可されている値 ファイル名

    バイナリロギングを有効化します。サーバーはデータを変更するすべてのステートメントのログをバイナリログに記録し、これはバックアップとレプリケーションに使用されます。セクション5.2.4「バイナリログ」を参照してください。

    オプション値 (指定された場合) はログシーケンスのベース名です。サーバーは、ベース名に数字サフィクスを追加することで、バイナリログファイルを次々に作成します。ベース名を指定することをお勧めします (その理由は セクションB.5.8「MySQL の既知の問題」を参照してください)。そうでない場合、MySQL はベース名として host_name-bin を使用します。

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

    コマンド行形式 --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}]

    導入 5.6.6
    コマンド行形式 --log-bin-use-v1-row-events[={0|1}]
    システム変数 名前 log_bin_use_v1_row_events
    スコープ グローバル
    動的 いいえ
    許可されている値 (>= 5.6.6) ブール
    デフォルト 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

    コマンド行形式 --log-short-format
    許可されている値 ブール
    デフォルト FALSE

    バイナリログおよびスロークエリーログがアクティブ化されている場合、これらのログに記録する情報を少なくします。

ステートメント選択オプション  次のリスト内のオプションは、どのステートメントがバイナリログに書き込まれ、レプリケーションマスターサーバーによってそのスレーブに送られるかを制御します。マスターから受け取ったステートメントのどれを実行または無視すべきかを制御する、スレーブサーバーのオプションもあります。詳細については、セクション17.1.4.3「レプリケーションスレーブのオプションと変数」を参照してください。

  • --binlog-do-db=db_name

    コマンド行形式 --binlog-do-db=name
    許可されている値 文字列

    このオプションは、--replicate-do-db がレプリケーションに影響するのと同様にバイナリロギングに影響します。

    このオプションの影響は、ステートメントベースまたは行ベースロギング形式のどちらが使用されるかに依存します (--replicate-do-db の影響がステートメントベースまたは行ベースレプリケーションのどちらが使用されたかに依存すると同じ)。指定されたステートメントのログを記録するために使用される形式が、binlog_format の値で示される形式と必ずしも同じではないことに留意してください。たとえば、CREATE TABLEALTER 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=db_name

    コマンド行形式 --binlog-ignore-db=name
    許可されている値 文字列

    このオプションは、--replicate-ignore-db がレプリケーションに影響するように、バイナリロギングに影響します。

    このオプションの影響は、ステートメントベースまたは行ベースロギング形式のどちらが使用されるかに依存します (--replicate-ignore-db の影響がステートメントベースまたは行ベースレプリケーションのどちらが使用されたかに依存すると同じ)。指定されたステートメントのログを記録するために使用される形式が、binlog_format の値で示される形式と必ずしも同じではないことに留意してください。たとえば、CREATE TABLEALTER 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}

    導入 5.6.2
    コマンド行形式 --binlog-checksum=type
    許可されている値 (<= 5.6.5) 文字列
    デフォルト NONE
    有効な値 NONE
    CRC32
    許可されている値 (>= 5.6.6) 文字列
    デフォルト CRC32
    有効な値 NONE
    CRC32

    このオプションを有効にすることで、マスターはバイナリログに書き込まれるイベントのチェックサムを書き込みます。NONE に設定すると無効になり、そうしない場合は、アルゴリズムの名前を使用してチェックサムが生成されます。現在のところ、CRC32 チェックサムだけがサポートされます。MySQL 5.6.6 以降では、CRC32 がデフォルトです。

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

  • --master-verify-checksum={0|1}

    導入 5.6.2
    コマンド行形式 --master-verify-checksum=name
    許可されている値 ブール
    デフォルト OFF

    このオプションを有効にすることで、マスターはチェックサムを使用してバイナリログからのイベントを検証し、不一致の場合はエラーで停止します。デフォルトで無効になっています。

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

スレーブ (リレーから) ログによるチェックサム読み取りを制御するには、--slave-sql-verify-checksum オプションを使用します。

テストおよびデバッグのオプション  次のバイナリログオプションは、レプリケーションテストおよびデバッグで使用されます。これらは通常操作での使用を意図していません。

  • --max-binlog-dump-events=N

    コマンド行形式 --max-binlog-dump-events=#
    許可されている値 数値
    デフォルト 0

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

  • --sporadic-binlog-dump-fail

    コマンド行形式 --sporadic-binlog-dump-fail
    許可されている値 ブール
    デフォルト FALSE

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

  • --binlog-rows-query-log-events

    導入 5.6.2
    コマンド行形式 --binlog-rows-query-log-events
    許可されている値 ブール
    デフォルト 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=#
    システム変数 名前 binlog_cache_size
    スコープ グローバル
    動的 はい
    許可されている値 (32 ビットプラットフォーム) 数値
    デフォルト 32768
    最小値 4096
    最大値 4294967295
    許可されている値 (64 ビットプラットフォーム) 数値
    デフォルト 32768
    最小値 4096
    最大値 18446744073709551615

    トランザクション中にバイナリログへの変更を保持するキャッシュのサイズ。サーバーがトランザクションストレージエンジンをサポートし、サーバーのバイナリログが有効 (--log-bin オプション) になっている場合は、バイナリログキャッシュがクライアントごとに割り当てられます。大きなトランザクションをよく使用する場合、パフォーマンスを向上するためにこのキャッシュサイズを増やすことができます。Binlog_cache_use および Binlog_cache_disk_use ステータス変数は、この変数のサイズを調整するために役立つことがあります。セクション5.2.4「バイナリログ」を参照してください。

    binlog_cache_size はトランザクションキャッシュのみのサイズを設定します。ステートメントキャッシュのサイズは binlog_stmt_cache_size システム変数によって管理されます。

  • binlog_checksum

    導入 5.6.2
    システム変数 名前 binlog_checksum
    スコープ グローバル
    動的 はい
    許可されている値 (<= 5.6.5) 文字列
    デフォルト NONE
    有効な値 NONE
    CRC32
    許可されている値 (>= 5.6.6) 文字列
    デフォルト CRC32
    有効な値 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_formatMIXED で、与えられたステートメントがステートメントベース形式を使用して複製されているときにのみ機能します。バイナリログ形式が ROW のとき、または binlog_formatMIXED に設定され、与えられたステートメントが行ベース形式で複製されるときは、この変数は効果がありません。

    重要

    この変数を有効にする前に、トランザクションおよび非トランザクションテーブルの間に依存関係がないことを確認する必要があります。このような依存関係の例は、ステートメント INSERT INTO myisam_table SELECT * FROM innodb_table です。そうでない場合、このようなステートメントによって、スレーブとマスターの間に相違が発生する可能性があります。

    MySQL 5.6 では、バイナリログ形式が ROW または MIXED のとき、この変数は効果がありません。(Bug #51291)

  • binlog_error_action

    導入 5.6.22
    コマンド行形式 --binlog-error-action[=value]
    システム変数 名前 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

    コマンド行形式 --binlog-format=format
    システム変数 名前 binlog_format
    スコープ グローバル、セッション
    動的 はい
    許可されている値 列挙
    デフォルト STATEMENT
    有効な値 ROW
    STATEMENT
    MIXED
    許可されている値 (>= 5.6.10-ndb-7.3.1) 列挙
    デフォルト MIXED
    有効な値 ROW
    STATEMENT
    MIXED

    この変数はバイナリロギング形式を設定し、STATEMENTROWMIXED のいずれかが可能です。セクション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

    導入 5.6.23
    コマンド行形式 --binlog-gtid-recovery-simplified
    システム変数 名前 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_executedgtid_purged はリカバリ中に通常どおりこれらのイベントを使用して初期化されます。GTID イベントが検出されない場合は、2 番目のスキャンが一番古いバイナリログファイルから GTID イベントを検索します。これらのファイルのどちらにも GTID イベントが含まれない場合は、これ以上バイナリログファイルは検索されず、gtid_executedgtid_purged は空の文字列に設定されます。

  • binlogging_impossible_mode

    導入 5.6.20
    非推奨 5.6.22
    コマンド行形式 --binlogging-impossible-mode[=value]
    システム変数 名前 binlogging_impossible_mode
    スコープ グローバル、セッション
    動的 はい
    許可されている値 列挙
    デフォルト IGNORE_ERROR
    有効な値 IGNORE_ERROR
    ABORT_SERVER

    このオプションは非推奨で、今後の MySQL リリースで削除される予定です。名前が変更された binlog_error_action を使用して、サーバーがバイナリログに書き込めないときに何が起きるかを制御してください。

  • binlog_max_flush_queue_time

    導入 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 で追加されました。

  • binlog_order_commits

    導入 5.6.6
    システム変数 名前 binlog_order_commits
    スコープ グローバル
    動的 はい
    許可されている値 ブール
    デフォルト ON

    この変数が有効の場合は (デフォルト)、トランザクションはバイナリログに書き込まれる順序と同じ順序でコミットされます。無効の場合は、トランザクションは並列にコミットされる場合があります。場合によっては、この変数を無効にすることでパフォーマンスが向上することがあります。

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

  • binlog_row_image

    導入 5.6.2
    コマンド行形式 --binlog-row-image=image_type
    システム変数 名前 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_formatMIXED のときは、binlog_row_image の設定は行ベース形式を使用してログが記録される変更に適用されますが、この設定はステートメントとしてログが記録される変更には影響しません。

    グローバルまたはセッションレベルのいずれかで binlog_row_image を設定しても、暗黙的にコミットされません。これは、トランザクションの進行中にトランザクションに影響を与えずにこの変数を変更できることを意味します。

  • binlog_rows_query_log_events

    導入 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=#
    システム変数 名前 binlog_stmt_cache_size
    スコープ グローバル
    動的 はい
    許可されている値 (32 ビットプラットフォーム) 数値
    デフォルト 32768
    最小値 4096
    最大値 4294967295
    許可されている値 (64 ビットプラットフォーム) 数値
    デフォルト 32768
    最小値 4096
    最大値 18446744073709551615

    この変数は、トランザクション中に発行される非トランザクションステートメントを保持するバイナリログログ用キャッシュのサイズを決定します。サーバーがトランザクションストレージエンジンをサポートし、かつサーバーでバイナリログが有効 (--log-bin オプション) になっている場合は、個別のバイナリログトランザクションおよびステートメントキャッシュが各クライアントに割り当てられます。トランザクション中に大きな非トランザクションステートメントを頻繁に使用する場合は、このキャッシュサイズを増やしてパフォーマンスを向上させることができます。Binlog_stmt_cache_use および Binlog_stmt_cache_disk_use ステータス変数は、この変数のサイズを調整する場合に役立つ場合があります。セクション5.2.4「バイナリログ」を参照してください。

    binlog_cache_size システム変数はトランザクションキャッシュのサイズを設定します。

  • log_bin

    システム変数 名前 log_bin
    スコープ グローバル
    動的 いいえ

    バイナリログが有効かどうか。--log-bin オプションが使用されている場合、この変数の値は ON です。そうでない場合、OFF です。この変数は、バイナリロギングのステータス (有効または無効) についてのみ報告します。--log-bin が設定されている値を実際に報告するわけではありません。

    セクション5.2.4「バイナリログ」を参照してください。

  • log_bin_basename

    導入 5.6.2
    システム変数 名前 log_bin_basename
    スコープ グローバル
    動的 いいえ
    許可されている値 ファイル名
    デフォルト datadir + '/' + hostname + '-bin'

    バイナリログファイルの名前と完全パスを保持します。log_bin システム変数とは異なり、log_bin_basename--log-bin サーバーオプションで設定される名前を反映します。

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

  • log_bin_index

    導入 5.6.4
    システム変数 名前 log_bin_index
    スコープ グローバル
    動的 いいえ
    許可されている値 ファイル名

    バイナリログファイル名のインデックスファイル。

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

  • log_bin_use_v1_row_events

    導入 5.6.6
    コマンド行形式 --log-bin-use-v1-row-events[={0|1}]
    システム変数 名前 log_bin_use_v1_row_events
    スコープ グローバル
    動的 いいえ
    許可されている値 (>= 5.6.6) ブール
    デフォルト 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
    システム変数 名前 log_slave_updates
    スコープ グローバル
    動的 いいえ
    許可されている値 ブール
    デフォルト FALSE

    スレーブサーバーがマスターサーバーから受け取った更新のログをスレーブ独自のバイナリログに記録する必要があるかどうか。この変数を有効にするには、スレーブでバイナリロギングを有効にする必要があります。セクション17.1.4「レプリケーションおよびバイナリロギングのオプションと変数」を参照してください。

  • master_verify_checksum

    導入 5.6.2
    システム変数 名前 master_verify_checksum
    スコープ グローバル
    動的 はい
    許可されている値 ブール
    デフォルト OFF

    この変数を有効にすることで、マスターはバイナリログから読み取るときにチェックサムを検査します。master_verify_checksum はデフォルトでは無効になっています。その場合は、マスターはバイナリログからのイベント長を使用してイベントを検証するため、すべてそろったイベントだけがバイナリログから読み取られます。

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

  • max_binlog_cache_size

    コマンド行形式 --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=#
    システム変数 名前 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=#
    システム変数 名前 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=#
    システム変数 名前 sync_binlog
    スコープ グローバル
    動的 はい
    許可されている値 (32 ビットプラットフォーム) 数値
    デフォルト 0
    最小値 0
    最大値 4294967295
    許可されている値 (64 ビットプラットフォーム) 数値
    デフォルト 0
    最小値 0
    最大値 4294967295

    この変数の値が 0 より大きい場合は、sync_binlog コミットグループがバイナリログに書き込まれたあとに、MySQL サーバーはそのバイナリログをディスクに同期します (fdatasync() を使用)。sync_binlog のデフォルト値は 0 で、これはディスクに同期しません。この場合、サーバーはオペレーティングシステムに依存して、ほかのファイルに関してバイナリログの内容をときどきフラッシュします。値 1 が一番安全な選択です (クラッシュの場合にバイナリログから失われるコミットグループが最大で 1 つです)。しかし、一番遅い選択でもあります (ディスクにバッテリ付きキャッシュがある場合を除きます。その場合は同期が非常に速くなります)。


User Comments
Sign Up Login You must be logged in to post a comment.