PDF (US Ltr)
- 36.1Mb
PDF (A4)
- 36.2Mb
このページは機械翻訳したものです。
このセクションで説明する mysqld オプションおよびシステム変数を使用して、バイナリログの操作に影響を与えたり、バイナリログにどのステートメントが書き込まれたかを制御したりできます。 バイナリログの追加情報については、セクション5.4.4「バイナリログ」を参照してください。 MySQL サーバーのオプションとシステム変数の使用に関する追加情報については、セクション5.1.7「サーバーコマンドオプション」およびセクション5.1.8「サーバーシステム変数」を参照してください。
次のリストでは、バイナリログを有効化したり構成したりするための起動オプションについて説明します。 バイナリロギングで使用するシステム変数については、このセクションの後半で説明します。
-
コマンド行形式 --binlog-row-event-max-size=#システム変数 (≥ 8.0.14) binlog_row_event_max_sizeスコープ (≥ 8.0.14) グローバル 動的 (≥ 8.0.14) いいえ SET_VARヒントの適用 (≥ 8.0.14)いいえ 型 Integer デフォルト値 8192最小値 256最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295行ベースのバイナリロギングを使用する場合、この設定は、行ベースのバイナリログイベントの最大サイズに対する弱い制限 (バイト単位) です。 可能であれば、バイナリログに格納されている行は、この設定の値を超えないサイズのイベントにグループ化されます。 イベントを分割できない場合は、最大サイズを超えることができます。 値は 256 の倍数である必要があります (そうでない場合は切り捨てられます)。 デフォルトは 8192 バイトです。
-
コマンド行形式 --log-bin=file_name型 ファイル名 バイナリログファイルに使用するベース名を指定します。 バイナリロギングが有効になっている場合、サーバーは、データを変更するすべてのステートメントをバイナリログに記録します。バイナリログは、バックアップとレプリケーションに使用されます。 バイナリログは、ベース名と数値拡張子を持つ一連のファイルです。
--log-binオプションの値は、ログ順序のベース名です。 サーバーは、ベース名に数値の接尾辞を追加して、バイナリログファイルを順番に作成します。--log-binオプションを指定しない場合、MySQL はバイナリログファイルのデフォルトのベース名としてbinlogを使用します。 以前のリリースとの互換性のために、文字列なしまたは空の文字列を指定して--log-binオプションを指定した場合、ベース名はホストマシンの名前を使用してhost_name-binバイナリログファイルのデフォルトの場所はデータディレクトリです。 ベース名に先頭の絶対パス名を追加して別のディレクトリを指定することで、
--log-binオプションを使用して別の場所を指定できます。 サーバーは、使用されたバイナリログファイルを追跡するバイナリログインデックスファイルからエントリを読み取るときに、エントリに相対パスが含まれているかどうかを確認します。 その場合、パスの相対部分は、--log-binオプションを使用して設定された絶対パスに置き換えられます。 バイナリログインデックスファイルに記録された絶対パスは変更されません。このような場合は、新しいパスを使用できるようにインデックスファイルを手動で編集する必要があります。 バイナリログファイルのベース名と指定されたパスは、log_bin_basenameシステム変数として使用できます。以前の MySQL バージョンでは、バイナリロギングはデフォルトで無効になっており、
--log-binオプションを指定した場合は有効になっていました。 MySQL 8.0 からは、--log-binオプションを指定するかどうかにかかわらず、バイナリロギングはデフォルトで有効になっています。 例外は、バイナリロギングがデフォルトで無効になっている場合に、mysqld を使用して--initializeまたは--initialize-insecureオプションを指定してデータディレクトリを手動で呼び出すことによって、データディレクトリを初期化する場合です。 この場合、--log-binオプションを指定することでバイナリロギングを有効にできます。 バイナリロギングが有効になっている場合、サーバー上のバイナリロギングのステータスを示すlog_binシステム変数は ON に設定されます。バイナリロギングを無効にするには、起動時に
--skip-log-binまたは--disable-log-binオプションを指定できます。 これらのオプションのいずれかが指定され、--log-binも指定されている場合は、後で指定するオプションが優先されます。 バイナリロギングが無効になっている場合、log_binシステム変数は OFF に設定されます。GTID がサーバーで使用されているときに、異常シャットダウン後にサーバーを再起動するときにバイナリロギングを無効にすると、GTID の一部が失われ、レプリケーションが失敗する可能性があります。 通常のシャットダウンでは、現在のバイナリログファイルから GTID のセットが
mysql.gtid_executedテーブルに保存されます。 これが発生しなかった異常なシャットダウンのあと、バイナリロギングがまだ有効になっている場合は、回復中に GTID がバイナリログファイルからテーブルに追加されます。 サーバーの再起動に対してバイナリロギングが無効になっている場合、サーバーはバイナリログファイルにアクセスして GTID を回復できないため、レプリケーションを開始できません。 バイナリロギングは、通常のシャットダウン後に安全に無効にできます。--log-slave-updatesおよび--slave-preserve-commit-orderオプションにはバイナリロギングが必要です。 バイナリロギングを無効にする場合は、これらのオプションを省略するか、--log-slave-updates=OFFおよび--skip-slave-preserve-commit-orderを指定します。--skip-log-binまたは--disable-log-binが指定されている場合、MySQL はこれらのオプションをデフォルトで無効にします。--log-slave-updatesまたは--slave-preserve-commit-orderを--skip-log-binまたは--disable-log-binとともに指定すると、警告またはエラーメッセージが発行されます。MySQL 5.7 では、バイナリロギングが有効になっているときにサーバー ID を指定する必要がありました。そうしないと、サーバーが起動しません。 MySQL 8.0 では、
server_idシステム変数はデフォルトで 1 に設定されています。 バイナリロギングが有効になっている場合、このデフォルトのサーバー ID を使用してサーバーを起動できるようになりましたが、server_idシステム変数を設定してサーバー ID を明示的に指定しないと、情報メッセージが発行されます。 レプリケーショントポロジで使用されるサーバーの場合、サーバーごとにゼロ以外の一意のサーバー ID を指定する必要があります。バイナリログの形式と管理については、セクション5.4.4「バイナリログ」 を参照してください。
-
コマンド行形式 --log-bin-index=file_nameシステム変数 log_bin_indexスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 ファイル名 バイナリログインデックスファイルの名前。バイナリログファイルの名前が含まれます。 デフォルトでは、
--log-binオプションと拡張子.indexを使用してバイナリログファイルに指定された値と同じ場所とベース名を持ちます。--log-binを指定しない場合、デフォルトのバイナリログインデックスファイル名はbinlog.indexです。 文字列または空の文字列を指定せずに--log-binオプションを指定した場合、デフォルトのバイナリログインデックスファイル名は、ホストマシンの名前を使用してhost_name-bin.indexバイナリログの形式と管理については、セクション5.4.4「バイナリログ」 を参照してください。
ステートメント選択オプション. 次のリストのオプションは、バイナリログに書き込まれ、レプリケーションソースサーバーによってその複製に送信されるステートメントに影響します。 レプリカには、ソースから受信したどのステートメントを実行または無視するかを制御するオプションもあります。 詳細は、セクション17.1.6.3「Replica Server のオプションと変数」を参照してください。
-
コマンド行形式 --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, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;ステートメントベースロギングを使用している場合、両方のテーブルへの更新がバイナリログに書き込まれます。 一方、行ベース形式を使用するときは、
table1への変更だけがログに記録されます。table2は別のデータベース内にあり、UPDATEによって変更されません。 ここで、USE db1ステートメントの代わりに、USE db4ステートメントが使用されたものとします。USE db4; UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.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であるステートメントのログを記録しないようにサーバーに指示します。デフォルトのデータベースがない場合、
--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データベースのソースコピー内のテーブルに対して行われた all の変更をバイナリロギングのために無視します。無視するデータベースを複数指定するには、このオプションを複数回 (データベースごとに 1 回) 使用します。 データベース名にはカンマを含めることができるため、カンマ区切りリストを指定すると、リストは単一のデータベースの名前として扱われます。
クロスデータベース更新を使用していて、それらの更新ログを記録したくない場合は、このオプションを使用しないでください。
チェックサムオプション. MySQL では、バイナリログチェックサムの読み取りと書き込みがサポートされています。 これらは、ここで示す 2 つのオプションを使用して有効化されます。
レプリカによる (リレーログからの) チェックサムの読み取りを制御するには、--slave-sql-verify-checksum オプションを使用します。
テストおよびデバッグのオプション. 次のバイナリログオプションは、レプリケーションテストおよびデバッグで使用されます。 これらは通常操作での使用を意図していません。
次の一覧で、バイナリロギングを制御するためのシステム変数について説明します。 これらはサーバー起動時に設定でき、それらの一部は SET を使用して実行時に変更できます。 バイナリロギングを制御するために使用されるサーバーオプションは、このセクションですでにリストされています。
-
コマンド行形式 --binlog-cache-size=#システム変数 binlog_cache_sizeスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 32768最小値 4096最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295トランザクション中にバイナリログに対する変更を保持するメモリーバッファーのサイズ。 (
log_binシステム変数を ON に設定して) サーバーでバイナリロギングが有効になっている場合、サーバーがトランザクションストレージエンジンをサポートしていれば、クライアントごとにバイナリログキャッシュが割り当てられます。 トランザクションのデータがメモリーバッファ内の領域を超えた場合、余分なデータは一時ファイルに格納されます。 バイナリログの暗号化がサーバーでアクティブな場合、メモリーバッファは暗号化されませんが、バイナリログキャッシュの保持に使用される一時ファイルは (MySQL 8.0.17 から) 暗号化されます。 各トランザクションがコミットされると、メモリーバッファをクリアし、一時ファイル (使用されている場合) を切り捨てることで、バイナリログキャッシュがリセットされます。大規模なトランザクションを頻繁に使用する場合は、一時ファイルへの書込みを削減または排除することで、このキャッシュサイズを増やしてパフォーマンスを向上させることができます。
Binlog_cache_useおよびBinlog_cache_disk_useステータス変数は、この変数のサイズを調整するために役立つことがあります。 セクション5.4.4「バイナリログ」を参照してください。binlog_cache_sizeはトランザクションキャッシュのみのサイズを設定します。ステートメントキャッシュのサイズはbinlog_stmt_cache_sizeシステム変数によって管理されます。 -
コマンド行形式 --binlog-checksum=nameシステム変数 binlog_checksumスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 文字列 デフォルト値 CRC32有効な値 NONECRC32この変数を有効にすると、ソースは各イベントのチェックサムをバイナリログに書き込みます。
binlog_checksumは、NONE(チェックサムを無効にする) およびCRC32の値をサポートしています。 デフォルトはCRC32です。binlog_checksumが無効 (値NONE) のときは、サーバーは各イベントのイベント長 （チェックサムではなく） を書き込んでチェックすることで、すべてそろったイベントのみをバイナリログに書き込んでいることを検証します。ソースでこの変数をレプリカで認識されない値に設定すると、レプリカは独自の
binlog_checksum値をNONEに設定し、エラーでレプリケーションを停止します。 古いレプリカとの下位互換性に問題がある場合は、値を明示的にNONEに設定できます。MySQL 8.0.20 まで、グループレプリケーションはチェックサムを使用できず、バイナリログでのチェックサムの存在をサポートしないため、サーバーインスタンスがグループメンバーになるように構成するときに
binlog_checksum=NONEを設定する必要があります。 MySQL 8.0.21 からは、グループレプリケーションでチェックサムがサポートされるため、グループメンバーはデフォルト設定を使用できます。チェックサムはバイナリログファイル全体に対して書き込まれる必要があり、バイナリログの一部に対してのみ書き込まれないため、
binlog_checksumの値を変更するとバイナリログがローテーションされます。 トランザクション内のbinlog_checksumの値は変更できません。binlog_transaction_compressionシステム変数を使用してバイナリログのトランザクション圧縮が有効になっている場合、圧縮されたトランザクションペイロード内の個々のイベントのチェックサムは書き込まれません。 代わりに、GTID イベントに対してチェックサムが書き込まれ、圧縮されたTransaction_payload_eventに対してチェックサムが書き込まれます。 -
binlog_direct_non_transactional_updatesコマンド行形式 --binlog-direct-non-transactional-updates[={OFF|ON}]システム変数 binlog_direct_non_transactional_updatesスコープ グローバル、セッション 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 OFF同時実行性の問題のため、トランザクションにトランザクションテーブルと非トランザクションテーブルの両方に対する更新が含まれる場合、レプリカに一貫性がなくなる可能性があります。 MySQL は、非トランザクションステートメントをトランザクションキャッシュに書き込むことで （コミット時にフラッシュされる）、これらのステートメント間の因果関係を維持しようとします。 ただし、トランザクションに代わって非トランザクションテーブルに行われた変更がほかの接続にただちに可視になるときに、問題が起こります (これらの変更がただちにバイナリログに書き込まれない場合があるため)。
binlog_direct_non_transactional_updates変数は、この問題に対する 1 つの可能な回避策を提供します。 デフォルトでは、この変数は無効です。binlog_direct_non_transactional_updatesを有効にすることで、非トランザクションテーブルへの更新が、トランザクションキャッシュではなく直接バイナリログに書き込まれます。MySQL 8.0.14 では、このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。
binlog_direct_non_transactional_updatesは、ステートメントベースバイナリロギング形式を使用して複製されるステートメントにのみ機能します。つまり、binlog_formatの値がSTATEMENTのとき、またはbinlog_formatがMIXEDで、与えられたステートメントがステートメントベース形式を使用して複製されているときにのみ機能します。 バイナリログ形式がROWのとき、またはbinlog_formatがMIXEDに設定され、与えられたステートメントが行ベース形式で複製されるときは、この変数は効果がありません。重要この変数を有効にする前に、トランザクションおよび非トランザクションテーブルの間に依存関係がないことを確認する必要があります。このような依存関係の例は、ステートメント
INSERT INTO myisam_table SELECT * FROM innodb_tableです。 そうしないと、このようなステートメントによってレプリカがソースと相違する可能性があります。バイナリログ形式が
ROWまたはMIXEDの場合、この変数は無効です。 -
コマンド行形式 --binlog-encryption[={OFF|ON}]導入 8.0.14 システム変数 binlog_encryptionスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 OFFこのサーバー上のバイナリログファイルおよびリレーログファイルの暗号化を有効にします。
OFFがデフォルトです。ONは、バイナリログファイルおよびリレーログファイルの暗号化をオンに設定します。 暗号化を有効にするためにバイナリロギングをサーバー上で有効にする必要はないため、バイナリログのないレプリカ上のリレーログファイルを暗号化できます。 暗号化を使用するには、MySQL Server 鍵リングサービスを提供するように鍵リングプラグインをインストールして構成する必要があります。 これを行う手順は、セクション6.4.4「MySQL キーリング」 を参照してください。 サポートされている任意のキーリングプラグインを使用して、バイナリログ暗号化鍵を格納できます。バイナリログ暗号化を有効にしてサーバーをはじめて起動すると、バイナリログとリレーログが初期化される前に新しいバイナリログ暗号化鍵が生成されます。 このキーは、各バイナリログファイル (サーバーでバイナリロギングが有効になっている場合) およびリレーログファイル (サーバーにレプリケーションチャネルがある場合) のファイルパスワードを暗号化するために使用され、ファイルパスワードから生成された以降の鍵を使用してファイル内のデータが暗号化されます。 リレーログファイルは、グループレプリケーションアプライヤチャネルや暗号化のアクティブ化後に作成される新しいチャネルなど、すべてのチャネルに対して暗号化されます。 バイナリログインデックスファイルとリレーログインデックスファイルは暗号化されません。
サーバーの実行中に暗号化をアクティブ化すると、その時点で新しいバイナリログ暗号化鍵が生成されます。 例外は、以前にサーバー上で暗号化がアクティブであり、その後無効になっていた場合です。その場合、以前に使用されていたバイナリログ暗号化鍵が再度使用されます。 バイナリログファイルとリレーログファイルはただちにローテーションされ、新しいファイルとそれ以降のすべてのバイナリログファイルおよびリレーログファイルのファイルパスワードは、このバイナリログ暗号化鍵を使用して暗号化されます。 既存のバイナリログファイルとリレーログファイルがサーバー上にまだ存在する場合、それらは自動的に暗号化されませんが、不要になった場合はパージできます。
binlog_encryptionシステム変数をOFFに変更して暗号化を非アクティブにすると、バイナリログファイルとリレーログファイルはただちにローテーションされ、それ以降のすべてのロギングは暗号化されません。 以前に暗号化されたファイルは自動的に復号化されませんが、サーバーはそれらを読み取ることができます。 サーバーの実行中に暗号化をアクティブ化または非アクティブ化するには、BINLOG_ENCRYPTION_ADMIN権限 (または非推奨のSUPER権限) が必要です。 グループレプリケーションアプライヤチャネルはリレーログローテーションリクエストに含まれないため、これらのチャネルの暗号化されていないロギングは、ログが通常の使用でローテーションされるまで開始されません。バイナリログファイルとリレーログファイルの暗号化の詳細は、セクション17.3.2「バイナリログファイルとリレーログファイルの暗号化」 を参照してください。
-
コマンド行形式 --binlog-error-action[=value]システム変数 binlog_error_actionスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 列挙 デフォルト値 ABORT_SERVER有効な値 IGNORE_ERRORABORT_SERVERバイナリログへの書き込み、フラッシュ、同期ができないなどのエラーがサーバーで発生した場合に何が起こるかを制御します。これにより、ソースバイナリログが矛盾し、レプリカが同期を失う可能性があります。
この変数のデフォルトは
ABORT_SERVERで、バイナリログでこのようなエラーが発生するたびに、サーバーはロギングを停止してシャットダウンします。 再起動時に、予期しないサーバーが停止した場合と同様にリカバリが続行されます (セクション17.4.2「レプリカの予期しない停止の処理」 を参照)。binlog_error_actionがIGNORE_ERRORに設定されている場合、サーバーでこのようなエラーが発生すると、進行中のトランザクションが続行され、エラーがログに記録されてからロギングが停止され、更新の実行が続行されます。 バイナリロギングを再開するには、log_binを再度有効にする必要があります。これにはサーバーの再起動が必要です。 この設定により、古いバージョンの MySQL との下位互換性が提供されます。 -
コマンド行形式 --binlog-expire-logs-seconds=#システム変数 binlog_expire_logs_secondsスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 2592000最小値 0最大値 4294967295バイナリログの有効期限を秒単位で設定します。 有効期限の終了後、バイナリログファイルを自動的に削除できます。 削除は起動時およびバイナリログがフラッシュされるときに発生する可能性があります。 ログのフラッシュは、セクション5.4「MySQL Server ログ」に記載されているように発生します。
デフォルトのバイナリログ有効期限は 2592000 秒で、30 日 (30*24*60*60 秒) です。 デフォルトは、
binlog_expire_logs_secondsと非推奨のシステム変数expire_logs_daysのどちらにも起動時に設定された値がない場合に適用されます。binlog_expire_logs_secondsまたはexpire_logs_daysのいずれかの変数にゼロ以外の値が起動時に設定されている場合、この値はバイナリログの有効期限として使用されます。 これらの両方の変数にゼロ以外の値が起動時に設定されている場合、binlog_expire_logs_secondsの値がバイナリログの有効期限として使用され、expire_logs_daysの値は警告メッセージとともに無視されます。バイナリログの自動パージを無効にするには、
binlog_expire_logs_secondsに値 0 を明示的に指定し、expire_logs_daysに値を指定しないでください。 以前のリリースとの互換性のために、expire_logs_daysに値 0 を明示的に指定し、binlog_expire_logs_secondsに値を指定しないと、自動パージも無効になります。 その場合、binlog_expire_logs_secondsのデフォルトは適用されません。バイナリログファイルを手動で削除するには、
PURGE BINARY LOGSステートメントを使用します。 セクション13.4.1.1「PURGE BINARY LOGS ステートメント」を参照してください。 -
コマンド行形式 --binlog-format=formatシステム変数 binlog_formatスコープ グローバル、セッション 動的 はい SET_VARヒントの適用いいえ 型 列挙 デフォルト値 ROW有効な値 ROWSTATEMENTMIXEDこの変数はバイナリロギング形式を設定し、
STATEMENT、ROW、MIXEDのいずれかが可能です。 セクション17.2.1「レプリケーション形式」を参照してください。binlog_formatは起動時または実行時に設定できますが、後で説明するように、一部の条件下ではこの変数を実行時に変更できないか、レプリケーションが失敗することを除きます。デフォルトは
ROWです。 例外: NDB Cluster では、デフォルトはMIXEDです。ステートメントベースのレプリケーションは NDB Cluster ではサポートされません。このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。
この変数への変更がいつ有効になり、影響はどのくらい長く続くかを管理するルールは、ほかの MySQL サーバーシステム変数の場合と同じです。 詳細は、セクション13.7.6.1「変数代入の SET 構文」を参照してください。
MIXEDが指定されている場合、行ベースレプリケーションだけが適切な結果になることが保証されている場合を除き、ステートメントベースレプリケーションが使用されます。 たとえば、これはユーザー定義関数 (UDF) またはUUID()関数がステートメントに含まれているときに発生します。各バイナリロギング形式が設定されている場合のストアドプログラム (ストアドプロシージャーとストアドファンクション、トリガー、およびイベント) の処理方法の詳細は、セクション25.7「ストアドプログラムバイナリロギング」 を参照してください。
レプリケーション形式を実行時に切り替えることができない例外もあります。
レプリケーション形式は、ストアドファンクションまたはトリガー内から変更できません。
セッションにオープン一時テーブルがある場合、セッション (
SET @@SESSION.binlog_format) のレプリケーション形式は変更できません。いずれかのレプリケーションチャネルにオープン一時テーブルがある場合、レプリケーション形式はグローバルに変更できません (
SET @@GLOBAL.binlog_formatまたはSET @@PERSIST.binlog_format)。レプリケーションチャネルアプライヤスレッドが現在実行されている場合、レプリケーション形式はグローバルに変更できません (
SET @@GLOBAL.binlog_formatまたはSET @@PERSIST.binlog_format)。
これらのいずれかの場合 (または現在のレプリケーション形式を設定しようとする場合) にレプリケーション形式を切り替えようとすると、エラーになります。 ただし、
PERSIST_ONLY(SET @@PERSIST_ONLY.binlog_format) を使用してレプリケーション形式をいつでも変更できます。これは、このアクションによってランタイムグローバルシステム変数の値が変更されず、サーバーの再起動後にのみ有効になるためです。一時テーブルが存在する場合、実行時にレプリケーション形式を切り替えることはお勧めしません。一時テーブルはステートメントベースレプリケーションの使用時にのみログに記録されますが、行ベースレプリケーションと混在レプリケーションではログに記録されないためです。
レプリケーションソースサーバーでロギング形式を変更しても、レプリカのロギング形式は一致するように変更されません。 レプリケーションの進行中にレプリケーション形式を切り替えると、レプリカでバイナリロギングが有効になっている場合に問題が発生し、ソースが
ROWまたはMIXED形式のロギングを使用している間に、変更によってレプリカでSTATEMENT形式のロギングが使用されることがあります。 レプリカは、ROWロギング形式で受信したバイナリログエントリを独自のバイナリログで使用するためにSTATEMENT形式に変換できないため、レプリケーションが失敗する可能性があります。 詳細は、セクション5.4.4.2「バイナリログ形式の設定」を参照してください。バイナリログ形式は次のサーバーオプションの動作に影響を与えます。
--replicate-do-db--replicate-ignore-db--binlog-do-db--binlog-ignore-db
これらの影響の詳細は、個々のオプションの説明に記載されています。
-
binlog_group_commit_sync_delayコマンド行形式 --binlog-group-commit-sync-delay=#システム変数 binlog_group_commit_sync_delayスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 0最小値 0最大値 1000000バイナリログファイルをディスクに同期する前にバイナリログのコミットが待機するマイクロ秒数を制御します。 デフォルトでは、
binlog_group_commit_sync_delayは 0 に設定されており、これは遅延がないことを意味します。binlog_group_commit_sync_delayをマイクロ秒遅延に設定すると、必要なグループがグループごとの時間単位が少なくなるため、一度により多くのトランザクションをディスクに同期でき、トランザクションのグループをコミットするための全体的な時間が短縮されます。sync_binlog=0またはsync_binlog=1が設定されている場合、binlog_group_commit_sync_delayによって指定された遅延は、同期の前 (またはsync_binlog=0の場合は先に進む前) にすべてのバイナリログコミットグループに適用されます。sync_binlogが 1 より大きい値 n に設定されている場合、遅延はすべての n バイナリログコミットグループのあとに適用されます。binlog_group_commit_sync_delayを設定すると、レプリカを持つ (またはフェイルオーバー後に存在する可能性のある) サーバー上のパラレルコミットトランザクションの数を増やすことができるため、レプリカに対するパラレル実行を増やすことができます。 この効果を活用するには、レプリカサーバーにslave_parallel_type=LOGICAL_CLOCKが設定されている必要があります。また、binlog_transaction_dependency_tracking=COMMIT_ORDERも設定されている場合は、この効果が重要になります。binlog_group_commit_sync_delayの設定をチューニングする場合は、ソースのスループットとレプリカのスループットの両方を考慮することが重要です。binlog_group_commit_sync_delayを設定すると、バイナリログを持つサーバー (ソースまたはレプリカ) 上のバイナリログへのfsync()呼び出しの数を減らすこともできます。binlog_group_commit_sync_delayを設定すると、サーバー上のトランザクションの待機時間が長くなり、クライアントアプリケーションに影響する可能性があることに注意してください。 また、同時実行性の高いワークロードでは、遅延によって競合が増加し、スループットが低下する可能性があります。 通常、遅延を設定する利点は欠点を上回っていますが、最適な設定を決定するには、チューニングを常に実行する必要があります。 -
binlog_group_commit_sync_no_delay_countコマンド行形式 --binlog-group-commit-sync-no-delay-count=#システム変数 binlog_group_commit_sync_no_delay_countスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 0最小値 0最大値 1000000binlog_group_commit_sync_delayで指定された現在の遅延を中断する前に待機するトランザクションの最大数。binlog_group_commit_sync_delayが 0 に設定されている場合、このオプションは無効です。 -
コマンド行形式 --binlog-max-flush-queue-time=#非推奨 はい システム変数 binlog_max_flush_queue_timeスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 0最小値 0最大値 100000binlog_max_flush_queue_timeは非推奨であり、将来の MySQL リリースでは最終的に削除対象としてマークされます。 以前は、このシステム変数は、グループコミットを続行する前にフラッシュキューからトランザクションの読取りを続行する時間をマイクロ秒単位で制御していました。 効果はなくなりました。 -
コマンド行形式 --binlog-order-commits[={OFF|ON}]システム変数 binlog_order_commitsスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 ONこの変数がレプリケーションソースサーバー (デフォルト) で有効になっている場合、ストレージエンジンに発行されるトランザクションコミット命令はシングルスレッド上で直列化されるため、トランザクションは常にバイナリログに書き込まれるのと同じ順序でコミットされます。 この変数を無効にすると、複数のスレッドを使用してトランザクションコミット命令を発行できます。 バイナリロググループのコミットと組み合わせて使用すると、単一のトランザクションのコミット率がスループットのボトルネックになるのを防ぐため、パフォーマンスが向上する可能性があります。
トランザクションは、関連するすべてのストレージエンジンがトランザクションのコミット準備を完了したことを確認した時点で、バイナリログに書き込まれます。 その後、バイナリロググループのコミットロジックは、バイナリログの書き込みが行われたあとにトランザクションのグループをコミットします。
binlog_order_commitsが無効になっている場合、このプロセスに複数のスレッドが使用されているため、コミットグループ内のトランザクションはバイナリログ内の順序とは異なる順序でコミットされる可能性があります。 (単一のクライアントからのトランザクションは常に時系列順にコミットされます。) 多くの場合、これは問題ではありません。個別のトランザクションで実行される操作は一貫した結果を生成する必要があり、そうでない場合は、かわりに単一のトランザクションを使用する必要があります。ソースとマルチスレッドのレプリカのトランザクション履歴が同一であることを確認する場合は、レプリカに
slave_preserve_commit_order=1を設定します。 -
binlog_rotate_encryption_master_key_at_startupコマンド行形式 --binlog-rotate-encryption-master-key-at-startup[={OFF|ON}]導入 8.0.14 システム変数 binlog_rotate_encryption_master_key_at_startupスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 Boolean デフォルト値 OFFサーバーの起動時にバイナリログマスターキーをローテーションするかどうかを指定します。 バイナリログマスターキーは、バイナリログファイルおよびサーバー上のリレーログファイルのファイルパスワードを暗号化するために使用されるバイナリログ暗号化鍵です。 バイナリログ暗号化 (
binlog_encryption=ON) を有効にしてサーバーをはじめて起動すると、新しいバイナリログ暗号化鍵が生成され、バイナリログマスターキーとして使用されます。binlog_rotate_encryption_master_key_at_startupシステム変数もONに設定されている場合、サーバーが再起動されるたびにバイナリログ暗号化鍵が生成され、後続のすべてのバイナリログファイルおよびリレーログファイルのバイナリログマスターキーとして使用されます。binlog_rotate_encryption_master_key_at_startupシステム変数がOFF(デフォルト) に設定されている場合、サーバーの再起動後に既存のバイナリログマスターキーが再度使用されます。 バイナリログ暗号化鍵とバイナリログマスターキーの詳細は、セクション17.3.2「バイナリログファイルとリレーログファイルの暗号化」 を参照してください。 -
コマンド行形式 --binlog-row-event-max-size=#システム変数 (≥ 8.0.14) binlog_row_event_max_sizeスコープ (≥ 8.0.14) グローバル 動的 (≥ 8.0.14) いいえ SET_VARヒントの適用 (≥ 8.0.14)いいえ 型 Integer デフォルト値 8192最小値 256最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295行ベースのバイナリロギングを使用する場合、この設定は、行ベースのバイナリログイベントの最大サイズに対する弱い制限 (バイト単位) です。 可能であれば、バイナリログに格納されている行は、この設定の値を超えないサイズのイベントにグループ化されます。 イベントを分割できない場合は、最大サイズを超えることができます。 値は 256 の倍数である必要があります (そうでない場合は切り捨てられます)。 デフォルトは 8192 バイトです。
このグローバルシステム変数は読取り専用で、サーバーの起動時にのみ設定できます。 したがって、その値を変更するには、
SETステートメントでPERSIST_ONLYキーワードまたは@@persist_only修飾子を使用する必要があります。 -
コマンド行形式 --binlog-row-image=image_typeシステム変数 binlog_row_imageスコープ グローバル、セッション 動的 はい SET_VARヒントの適用いいえ 型 列挙 デフォルト値 full有効な値 full(すべてのカラムをログに記録)minimal(変更されたカラムおよび、行を特定するために必要とされたカラムのみをログに記録)noblob(不要な BLOB カラムおよび TEXT カラム以外のすべてのカラムをログに記録)MySQL 行ベースレプリケーションの場合、この変数は行イメージをバイナリログに書き込む方法を決定します。
このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。
MySQL 行ベースレプリケーションでは、各行変更イベントに 2 つのイメージ、つまり「前」イメージ (更新される行を検索するときにこれらのカラムが照合される) と「後」イメージ (変更を含む) が含まれます。 通常、MySQL は前イメージと後イメージの両方のためにすべての行 （つまり、すべてのカラム） のログを記録します。 ただし、両方のイメージにすべてのカラムが厳密に含まれている必要はなく、多くの場合、実際に必要なカラムのログのみを記録することでディスク、メモリー、およびネットワーク使用量を節約できます。
注記行を削除するときは、削除後に伝達する変更後の値がないため、前イメージのみのログが記録されます。 行を挿入するときは、照合される既存の行がないため、後イメージのみのログが記録されます。 行を更新するときのみ、前イメージと後イメージの両方が必要で、両方がバイナリログに書き込まれます。
前イメージについては、行を一意に識別するために必要な最小カラムセットのログが記録されることのみが必要です。 行を含むテーブルに主キーがある場合、主キーカラムだけがバイナリログに書き込まれます。 そうではなく、テーブルに一意キーがあり、そのカラムのすべてが
NOT NULLの場合は、一意キー内のカラムのログのみを記録する必要があります。 (テーブルにNULLカラムなしの主キーまたは一意キーがない場合、すべてのカラムが前イメージで使用され、それらのログが記録される必要があります。) 後イメージでは、実際に変更されたカラムのログのみを記録する必要があります。binlog_row_imageシステム変数を使用して、サーバーに完全な行または最小限の行を記録させることができます。 この変数は実際には、次のリストで示す 3 つの可能な値の 1 つを取ることができます。full: 前イメージと後イメージの両方にすべてのカラムのログを記録します。minimal: 変更する行を識別するために必要なビフォアイメージのカラムのみをログに記録します。SQL ステートメントで値が指定されたか、自動増分によって生成されたアフターイメージのカラムのみをログに記録します。noblob: すべてのカラム (fullと同じ) のログを記録しますが、行の識別に必要がない、または変更されなかったBLOBおよびTEXTカラムは除きます。
注記この変数は NDB Cluster ではサポートされていません。設定しても
NDBテーブルのロギングには影響しません。デフォルト値は
fullです。minimalまたはnoblobを使用するときは、ソーステーブルと宛先テーブルの両方について次の条件が true の場合にのみ、所定のテーブルに対して削除と更新が正しく機能することが保証されます。すべてのカラムが同じ順番で存在する必要があります。それぞれのカラムがもう一方のテーブル内の対応するものと同じデータ型を使用する必要があります。
これらのテーブルの主キー定義が同じである必要があります。
(つまり、これらのテーブルは同じである必要がありますが、テーブルの主キーの一部でないインデックスがある場合にはそれらは除きます。)
これらの条件が満たされない場合は、宛先テーブル内の主キーカラム値が、削除または更新のための一意一致を提供するために不十分であることが判明する場合があります。 この場合、警告やエラーは発行されず、ソースとレプリカは暗黙的に相違するため、一貫性が損なわれます。
バイナリロギング形式が
STATEMENTのときは、この変数を設定しても効果はありません。binlog_formatがMIXEDの場合、binlog_row_imageの設定は行ベースの形式を使用して記録された変更に適用されますが、この設定はステートメントとして記録された変更には影響しません。グローバルまたはセッションレベルのいずれかで
binlog_row_imageを設定しても、暗黙的にコミットされません。これは、トランザクションの進行中にトランザクションに影響を与えずにこの変数を変更できることを意味します。 -
コマンド行形式 --binlog-row-metadata=metadata_typeシステム変数 binlog_row_metadataスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 列挙 デフォルト値 MINIMAL有効な値 FULL(すべてのメタデータが含まれます)MINIMAL(含まれるメタデータの制限)行ベースロギングの使用時にバイナリログに追加されるテーブルメタデータの量を構成します。
MINIMAL(デフォルト) に設定すると、SIGNEDフラグ、カラム文字セットおよびジオメトリタイプに関連するメタデータのみがログに記録されます。FULLに設定すると、カラム名、ENUMまたはSET文字列値、PRIMARY KEY情報など、テーブルの完全なメタデータがログに記録されます。拡張メタデータは、次の目的で使用されます:
レプリカは、テーブル構造がソースと異なる場合、メタデータを使用してデータを転送します。
外部ソフトウェアでは、メタデータを使用して行イベントをデコードし、データウェアハウスなどの外部データベースにデータを格納できます。
-
コマンド行形式 --binlog-row-value-options=#システム変数 binlog_row_value_optionsスコープ グローバル、セッション 動的 はい SET_VARヒントの適用いいえ 型 Set デフォルト値 ''有効な値 PARTIAL_JSONPARTIAL_JSONに設定すると、JSON ドキュメントの小さい部分のみを変更する更新に領域効率のよいバイナリログ形式を使用できるようになります。これにより、行ベースのレプリケーションでは、JSON ドキュメントの変更された部分のみがバイナリログ内の更新のアフターイメージに書き込まれます (完全なドキュメントは書き込まれません)。 これは、JSON_SET()、JSON_REPLACE()およびJSON_REMOVE()の任意の順序を使用して JSON カラムを変更するUPDATEステートメントに対して機能します。 変更にドキュメント全体よりも多くの領域が必要な場合、またはサーバーが部分更新を生成できない場合は、かわりにドキュメント全体が使用されます。このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。
サポートされている値は
PARTIAL_JSONのみです。binlog_row_value_optionsの設定を解除するには、その値を空の文字列に設定します。binlog_row_value_options=PARTIAL_JSONは、バイナリロギングが有効で、binlog_formatがROWまたはMIXEDに設定されている場合にのみ有効になります。 ステートメントベースレプリケーション always は、binlog_row_value_optionsに設定された値に関係なく、JSON ドキュメントの変更された部分のみを記録します。 節約される領域の量を最大化するには、このオプションとともにbinlog_row_image=NOBLOBまたはbinlog_row_image=MINIMALを使用します。完全な JSON ドキュメントはビフォアイメージに格納され、部分更新はアフターイメージにのみ格納されるため、binlog_row_image=FULLはこれらのいずれかよりも少ない領域を節約します。mysqlbinlog 出力には、
BINLOGステートメントを使用して base-64 文字列としてエンコードされたイベントの形式で部分的な JSON 更新が含まれます。--verboseオプションが指定されている場合、mysqlbinlog は擬似 SQL ステートメントを使用して部分的な JSON 更新を読取り可能な JSON として表示します。レプリカ上の JSON ドキュメントに変更を適用できない場合、MySQL レプリケーションはエラーを生成します。 これには、パスの検索の失敗も含まれます。 この安全性チェックおよびその他の安全性チェックでも、レプリカ上の JSON ドキュメントがソース上の JSON ドキュメントと相違しており、部分更新が適用されても、理論的にはレプリカ上に有効だが予期しない JSON ドキュメントを生成できることに注意してください。
-
コマンド行形式 --binlog-rows-query-log-events[={OFF|ON}]システム変数 binlog_rows_query_log_eventsスコープ グローバル、セッション 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 OFFこのシステム変数は、行ベースのロギングにのみ影響します。 有効にすると、サーバーは行クエリーログイベントなどの情報ログイベントをバイナリログに書き込みます。 この情報は、行の更新から再構築できない場合にソースに対して発行された元のクエリーを取得するなど、デバッグおよび関連する目的で使用できます。
このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。
これらの情報イベントは通常、バイナリログを読み取る MySQL プログラムによって無視されるため、バックアップからレプリケートまたは復元するときに問題は発生しません。 これらを表示するには、mysqlbinlog
--verboseオプションを-vvまたは--verbose --verboseとして 2 回使用して、冗長性レベルを上げます。 -
コマンド行形式 --binlog-stmt-cache-size=#システム変数 binlog_stmt_cache_sizeスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 32768最小値 4096最大値 (64 ビットプラットフォーム) 18446744073709551615最大値 (32 ビットプラットフォーム) 4294967295トランザクション中に発行された非トランザクションステートメントを保持するバイナリログのメモリーバッファーのサイズ。 (
log_binシステム変数を ON に設定して) サーバーでバイナリロギングが有効になっている場合、サーバーがトランザクションストレージエンジンをサポートしていれば、クライアントごとに個別のバイナリログトランザクションとステートメントキャッシュが割り当てられます。 トランザクションで使用される非トランザクションステートメントのデータがメモリーバッファ内の領域を超えると、余分なデータが一時ファイルに格納されます。 バイナリログの暗号化がサーバーでアクティブな場合、メモリーバッファは暗号化されませんが、バイナリログキャッシュの保持に使用される一時ファイルは (MySQL 8.0.17 から) 暗号化されます。 各トランザクションがコミットされたあと、バイナリログステートメントキャッシュはメモリーバッファーをクリアし、一時ファイルが使用されている場合は切り捨ててリセットされます。トランザクション中に大規模な非トランザクションステートメントを頻繁に使用する場合は、一時ファイルへの書込みを削減または排除することで、このキャッシュサイズを増やしてパフォーマンスを向上させることができます。
Binlog_stmt_cache_useおよびBinlog_stmt_cache_disk_useステータス変数は、この変数のサイズを調整する場合に役立つ場合があります。 セクション5.4.4「バイナリログ」を参照してください。binlog_cache_sizeシステム変数はトランザクションキャッシュのサイズを設定します。 -
binlog_transaction_compressionコマンド行形式 --binlog-transaction-compression[={OFF|ON}]導入 8.0.20 システム変数 binlog_transaction_compressionスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 OFFこのサーバー上のバイナリログファイルに書き込まれるトランザクションの圧縮を有効にします。
OFFがデフォルトです。binlog_transaction_compression_level_zstdシステム変数を使用して、圧縮に使用される zstd アルゴリズムのレベルを設定します。バイナリログのトランザクション圧縮が有効になっている場合、トランザクションペイロードは圧縮され、単一のイベント (
Transaction_payload_event) としてバイナリログファイルに書き込まれます。 圧縮されたトランザクションペイロードは、レプリケーションストリームでレプリカ、他のグループレプリケーショングループメンバー、または mysqlbinlog などのクライアントに送信されている間、圧縮状態のままであり、圧縮状態のままリレーログに書き込まれます。 したがって、バイナリログトランザクション圧縮では、トランザクションの作成者と受信者 (およびそのバックアップ) の両方に記憶領域が節約され、トランザクションがサーバーインスタンス間で送信されるときにネットワーク帯域幅が節約されます。binlog_transaction_compression=ONを直接有効にするには、サーバーでバイナリロギングを有効にする必要があります。 MySQL サーバーインスタンスにバイナリログがない場合、MySQL 8.0.20 からのリリースであれば、binlog_transaction_compressionの値に関係なく、圧縮されたトランザクションペイロードを受信、処理および表示できます。 このようなサーバーインスタンスによって受信された圧縮トランザクションペイロードは、圧縮された状態でリレーログに書き込まれるため、レプリケーショントポロジ内の他のサーバーによって実行される圧縮から間接的にメリットが得られます。このシステム変数は、トランザクションのコンテキスト内では変更できません。 このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。
バイナリログのトランザクション圧縮の詳細 (圧縮されているイベントと圧縮されていないイベントの詳細、トランザクション圧縮が使用されている場合の動作の変更など) は、セクション5.4.4.5「バイナリログトランザクション圧縮」 を参照してください。
-
binlog_transaction_compression_level_zstdコマンド行形式 --binlog-transaction-compression-level-zstd=#導入 8.0.20 システム変数 binlog_transaction_compression_level_zstdスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 3最小値 1最大値 22binlog_transaction_compressionシステム変数によって有効になる、このサーバー上のバイナリログトランザクション圧縮の圧縮レベルを設定します。 この値は、圧縮作業を決定する整数で、1 (最小作業量) から 22 (最大作業量) までです。 このシステム変数を指定しない場合、圧縮レベルは 3 に設定されます。圧縮レベルが高くなると、データ圧縮率が高くなり、トランザクションペイロードに必要なストレージ領域およびネットワーク帯域幅が削減されます。 ただし、データ圧縮に必要な労力も増加し、元のサーバーでは時間と CPU およびメモリーリソースがかかります。 圧縮作業の増加には、データ圧縮率の増加と線形関係はありません。
このシステム変数は、トランザクションのコンテキスト内では変更できません。 このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。
-
binlog_transaction_dependency_trackingコマンド行形式 --binlog-transaction-dependency-tracking=valueシステム変数 binlog_transaction_dependency_trackingスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 列挙 デフォルト値 COMMIT_ORDER有効な値 COMMIT_ORDERWRITESETWRITESET_SESSIONマルチスレッドレプリカ (
slave_parallel_workersが 0 より大きい値に設定されているレプリカ) を持つレプリケーションソースサーバーの場合、binlog_transaction_dependency_trackingは、レプリカが並列で実行できるトランザクションを判断するのに役立つように、バイナリログにソースが記録する依存性情報のソースを指定します。 指定可能な値は次のとおりです。COMMIT_ORDER: 依存性情報は、ソースコミットタイムスタンプから生成されます。 これはデフォルトです。WRITESET: 依存性情報はソース書込みセットから生成され、異なるタプルを書き込むトランザクションはパラレル化できます。WRITESET_SESSION: 依存性情報はソース書込みセットから生成され、異なるタプルを書き込むトランザクションはパラレル化できますが、同じセッションからの 2 つの更新を並べ替えることはできません。
WRITESETおよびWRITESET_SESSIONモードでは、COMMIT_ORDERモードで返されるものよりも最適化されていないトランザクション依存性は提供されません。WRITESETまたはWRITESET_SESSIONを値として設定すると、ソースは、空または部分書込みセットを持つトランザクション、主キーまたは一意キーのないテーブルを更新するトランザクション、および外部キー関係の親テーブルを更新するトランザクションに対してCOMMIT_ORDERモードを使用します。WRITESETまたはWRITESET_SESSIONをbinlog_transaction_dependency_trackingの値として設定するには、(OFFに設定されていない) アルゴリズムを指定するようにtransaction_write_set_extractionを設定する必要があります。 MySQL 8.0 のデフォルトでは、transaction_write_set_extractionはXXHASH64に設定されています。transaction_write_set_extractionに選択した値は、binlog_transaction_dependency_trackingの値がWRITESETまたはWRITESET_SESSIONのままである間は再度変更できません。特定の行を変更した最新のトランザクションについて保持およびチェックされる行ハッシュの数は、
binlog_transaction_dependency_history_sizeの値によって決まります。グループレプリケーションの場合、
binlog_transaction_dependency_tracking=WRITESET_SESSIONを設定すると、グループワークロードに応じてグループメンバーのパフォーマンスを向上させることができます。 Group Replication は、binlog_transaction_dependency_trackingに設定された値とは関係なく、リレーログからトランザクションを適用するときに、証明後に独自のパラレル化を実行します。 ただし、binlog_transaction_dependency_trackingの値は、グループレプリケーションメンバーのバイナリログへのトランザクションの書込み方法に影響します。 これらのログ内の依存関係情報は、メンバーがグループに参加または再参加するたびに発生する分散リカバリのドナーバイナリログからの状態転送プロセスを支援するために使用されます。 -
binlog_transaction_dependency_history_sizeコマンド行形式 --binlog-transaction-dependency-history-size=#システム変数 binlog_transaction_dependency_history_sizeスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 25000最小値 1最大値 1000000メモリーに保持され、特定の行を最後に変更したトランザクションの検索に使用される行ハッシュの数の上限を設定します。 このハッシュ数に達すると、履歴がパージされます。
-
コマンド行形式 --expire-logs-days=#非推奨 はい システム変数 expire_logs_daysスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 0最小値 0最大値 99バイナリログファイルを自動的に削除するまでの日数を指定します。
expire_logs_daysは非推奨であり、将来のリリースで削除される予定です。 代わりに、バイナリログの有効期限を秒単位で設定するbinlog_expire_logs_secondsを使用してください。 どちらのシステム変数にも値を設定しない場合、デフォルトの有効期限は 30 日です。 削除は起動時およびバイナリログがフラッシュされるときに発生する可能性があります。 ログのフラッシュは、セクション5.4「MySQL Server ログ」に記載されているように発生します。binlog_expire_logs_secondsも指定した場合、expire_logs_daysにゼロ以外の値を指定すると無視され、かわりにバイナリログの有効期限としてbinlog_expire_logs_secondsの値が使用されます。 この状況では、警告メッセージが発行されます。expire_logs_daysのゼロ以外の値は、binlog_expire_logs_secondsが指定されていないか、0 として指定されている場合にのみバイナリログの有効期限として適用されます。バイナリログの自動パージを無効にするには、
binlog_expire_logs_secondsに値 0 を明示的に指定し、expire_logs_daysに値を指定しないでください。 以前のリリースとの互換性のために、expire_logs_daysに値 0 を明示的に指定し、binlog_expire_logs_secondsに値を指定しないと、自動パージも無効になります。 その場合、binlog_expire_logs_secondsのデフォルトは適用されません。バイナリログファイルを手動で削除するには、
PURGE BINARY LOGSステートメントを使用します。 セクション13.4.1.1「PURGE BINARY LOGS ステートメント」を参照してください。 -
システム変数 log_binスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 Boolean サーバー上のバイナリロギングのステータスを表示します。有効 (
ON) または無効 (OFF) のいずれかです。 バイナリロギングが有効になっている場合、サーバーは、データを変更するすべてのステートメントをバイナリログに記録します。バイナリログは、バックアップとレプリケーションに使用されます。ONはバイナリログが使用可能であることを意味し、OFFはバイナリログが使用されていないことを意味します。--log-binオプションを使用すると、バイナリログのベース名と場所を指定できます。以前の MySQL バージョンでは、バイナリロギングはデフォルトで無効になっており、
--log-binオプションを指定した場合は有効になっていました。 MySQL 8.0 からは、--log-binオプションを指定するかどうかに関係なく、log_binシステム変数がONに設定されたバイナリロギングがデフォルトで有効になります。 例外は、バイナリロギングがデフォルトで無効になっている場合に、mysqld を使用して--initializeまたは--initialize-insecureオプションを指定してデータディレクトリを手動で呼び出すことによって、データディレクトリを初期化する場合です。 この場合、--log-binオプションを指定することでバイナリロギングを有効にできます。--skip-log-binまたは--disable-log-binオプションが起動時に指定された場合、バイナリロギングは無効になり、log_binシステム変数はOFFに設定されます。 これらのオプションのいずれかが指定され、--log-binも指定されている場合は、後で指定するオプションが優先されます。バイナリログの形式と管理については、セクション5.4.4「バイナリログ」 を参照してください。
-
システム変数 log_bin_basenameスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 ファイル名 バイナリログファイルのベース名とパスを保持します。これらは
--log-binサーバーオプションで設定できます。 最大可変長は 256 です。 MySQL 8.0 では、--log-binオプションが指定されていない場合、デフォルトのベース名はbinlogです。 MySQL 5.7 との互換性のために、--log-binオプションが文字列なしまたは空の文字列とともに指定されている場合、デフォルトのベース名はhost_name-bin -
コマンド行形式 --log-bin-index=file_nameシステム変数 log_bin_indexスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 ファイル名 バイナリログインデックスファイルのベース名とパスを保持します。これは、
--log-bin-indexサーバーオプションで設定できます。 最大可変長は 256 です。 -
log_bin_trust_function_creatorsコマンド行形式 --log-bin-trust-function-creators[={OFF|ON}]システム変数 log_bin_trust_function_creatorsスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 OFFこの変数は、バイナリロギングが有効な場合に適用されます。 ストアドファンクションの作成者が、安全でないイベントがバイナリログに書き込まれる原因となるストアドファンクションを作成しないことを信頼できるかどうかを制御します。 0 (デフォルト) に設定した場合、ユーザーは
CREATE ROUTINEまたはALTER ROUTINE権限に加えてSUPER権限を持たないかぎり、ストアドファンクションを作成または変更することが許可されません。 0 に設定することで、関数をDETERMINISTIC特性で、あるいはREADS SQL DATAまたはNO SQL特性で宣言する必要があるという制約も強制されます。 変数が 1 に設定された場合、MySQL はストアドファンクション作成にこれらの制約を強制しません。 この変数はトリガー作成にも適用されます。 セクション25.7「ストアドプログラムバイナリロギング」を参照してください。 -
コマンド行形式 --log-bin-use-v1-row-events[={OFF|ON}]非推奨 8.0.18 システム変数 log_bin_use_v1_row_eventsスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 Boolean デフォルト値 OFFこの読取り専用システム変数は非推奨です。 サーバーの起動時にシステム変数を
ONに設定すると、MySQL 5.6 の時点でデフォルトであるバージョン 2 バイナリログ行イベントではなく、バージョン 1 バイナリログ行イベントを使用してバイナリログを書き込むことによって、MySQL Server 5.5 以前を実行しているレプリカで行ベースレプリケーションが有効になります。 -
コマンド行形式 --log-slave-updates[={OFF|ON}]システム変数 log_slave_updatesスコープ グローバル 動的 いいえ SET_VARヒントの適用いいえ 型 Boolean デフォルト値 ONレプリケーションソースサーバーから受信した更新を、レプリカ独自のバイナリログに記録するかどうか。
この変数を有効にすると、レプリカはソースから受信し、レプリケーション SQL スレッドによって実行された更新をレプリカ独自のバイナリログに書き込みます。 バイナリロギングは
--log-binオプションによって制御され、デフォルトで有効になっていますが、更新をログに記録するにはレプリカでも有効にする必要があります。 セクション17.1.6「レプリケーションおよびバイナリロギングのオプションと変数」 を参照してください。--skip-log-binを指定してバイナリロギングを無効にしないかぎり、log_slave_updatesはデフォルトで有効になっています。この場合、MySQL はレプリカ更新ロギングもデフォルトで無効にします。 バイナリロギングが有効になっているときにレプリカ更新ロギングを無効にする必要がある場合は、レプリカサーバーの起動時に--log-slave-updates=OFFを指定します。log_slave_updatesを有効にすると、レプリケーションサーバーをチェーンできます。 たとえば、このようにレプリケーションサーバーをセットアップするとします。A -> B -> Cここで、
AはレプリカBのソースとして機能し、BはレプリカCのソースとして機能します。 これが機能するには、Bがソースとレプリカの両方である必要があります。 バイナリロギングが有効で、log_slave_updatesが有効になっている場合 (デフォルト設定)、Aから受信した更新はBによってバイナリログに記録されるため、Cに渡すことができます。 -
log_statements_unsafe_for_binlogコマンド行形式 --log-statements-unsafe-for-binlog[={OFF|ON}]システム変数 log_statements_unsafe_for_binlogスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 ONエラー 1592 が発生した場合、生成された警告をエラーログに追加するかどうかを制御します。
-
コマンド行形式 --master-verify-checksum[={OFF|ON}]システム変数 master_verify_checksumスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 OFFこの変数を有効にすると、ソースはチェックサムを検査してバイナリログから読み取られたイベントを検証し、不一致が発生した場合はエラーで停止します。
master_verify_checksumはデフォルトで無効になっています。この場合、ソースはバイナリログのイベント長を使用してイベントを検証し、バイナリログから完全なイベントのみが読み取られるようにします。 -
コマンド行形式 --max-binlog-cache-size=#システム変数 max_binlog_cache_sizeスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 18446744073709551615最小値 4096最大値 18446744073709551615トランザクション内の非トランザクションステートメントがこのバイト数より多くのメモリーを必要とする場合、サーバーはMulti-statement transaction required more than 'max_binlog_cache_size' bytes of storageエラーを生成します。 最小値は 4096 です。 可能な最大値は 16EiB (exbibytes) です。 推奨される最大値は 4G バイトです。これは、MySQL が現在 4G バイトより大きなバイナリログ位置で作業できないという事実によります。
max_binlog_cache_sizeはトランザクションキャッシュのみのサイズを設定します。ステートメントキャッシュの上限値はmax_binlog_stmt_cache_sizeシステム変数によって管理されます。max_binlog_cache_sizeのセッションの可視性は、binlog_cache_sizeシステム変数の可視性と一致します。つまり、その値を変更すると、値が変更された後に開始される新しいセッションにのみ影響します。 -
コマンド行形式 --max-binlog-size=#システム変数 max_binlog_sizeスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 1073741824最小値 4096最大値 1073741824バイナリログへの書き込みによって、現在のログファイルサイズがこの変数の値を超えた場合、サーバーはバイナリログをローテーションします (現在のファイルを閉じて、新しいものを開きます)。 最小値は 4096 バイトです。 最大値およびデフォルト値は 1G バイトです。 暗号化バイナリログファイルには、
max_binlog_sizeに含まれる追加の 512 バイトヘッダーがあります。トランザクションはバイナリログにひとまとまりで書き込まれ、複数のバイナリログ間に分割されることはありません。 このため、大きなトランザクションの場合、
max_binlog_sizeより大きいバイナリログファイルが見られることがあります。max_relay_log_sizeが 0 の場合、max_binlog_sizeの値がリレーログにも適用されます。GTID がサーバーで使用されている場合、
max_binlog_sizeに到達したときに、システムテーブルmysql.gtid_executedにアクセスして GTID を現在のバイナリログファイルから書き込めないと、バイナリログをローテーションできません。 この状況では、サーバーはそのbinlog_error_action設定に従って応答します。IGNORE_ERRORが設定されている場合、サーバーにエラーが記録され、バイナリロギングが停止されます。または、ABORT_SERVERが設定されている場合、サーバーはシャットダウンします。 -
コマンド行形式 --max-binlog-stmt-cache-size=#システム変数 max_binlog_stmt_cache_sizeスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 18446744073709547520最小値 4096最大値 18446744073709547520トランザクション内の非トランザクションステートメントがこのバイト数より多くのメモリーを必要とする場合、サーバーはエラーを生成します。 最小値は 4096 です。 最大値およびデフォルト値は、32 ビットプラットフォームでは 4G バイト、64 ビットプラットフォームでは 16E バイト (エクサバイト) です。
max_binlog_stmt_cache_sizeはステートメントキャッシュのみのサイズを設定します。トランザクションキャッシュの上限値はmax_binlog_cache_sizeシステム変数によって排他的に管理されます。 -
システム変数 original_commit_timestampスコープ セッション 動的 はい SET_VARヒントの適用いいえ 型 数値 レプリケーションによる内部使用用。 レプリカでトランザクションを再実行する場合、これは元のソースでトランザクションがコミットされた時間に設定され、エポック以降マイクロ秒単位で測定されます。 これにより、元のコミットタイムスタンプをレプリケーショントポロジ全体に伝播できます。
このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、
REPLICATION_APPLIER権限 (セクション17.3.3「レプリケーション権限チェック」 を参照) または制限付きセッション変数の設定に十分な権限 (セクション5.1.9.1「システム変数権限」 を参照) が必要です。 ただし、この変数はユーザーが設定するためのものではなく、レプリケーションインフラストラクチャによって自動的に設定されることに注意してください。 -
システム変数 sql_log_binスコープ セッション 動的 はい SET_VARヒントの適用いいえ 型 Boolean デフォルト値 ONこの変数は、現在のセッションでバイナリログへのロギングを有効にするかどうかを制御します (バイナリログ自体が有効になっていると仮定します)。 デフォルト値は
ONです。 現在のセッションのバイナリロギングを無効または有効にするには、セッションsql_log_bin変数をOFFまたはONに設定します。レプリカにレプリケートしないソースに変更を加えている間にバイナリロギングを一時的に無効にするには、セッションに対してこの変数を
OFFに設定します。このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。
トランザクションまたはサブクエリー内で
sql_log_binのセッション値を設定することはできません。「この変数を
OFFに設定すると、GTID がバイナリログ内のトランザクションに割り当てられなくなります」。 これは、GTID をレプリケーションに使用している場合、バイナリロギングがあとで再度有効になった場合でも、この時点からログに書き込まれる GTID はその意味で発生したトランザクションを考慮しないため、それらのトランザクションは失われることを意味します。 -
コマンド行形式 --sync-binlog=#システム変数 sync_binlogスコープ グローバル 動的 はい SET_VARヒントの適用いいえ 型 Integer デフォルト値 1最小値 0最大値 4294967295MySQL サーバーがバイナリログをディスクに同期する頻度を制御します。
sync_binlog=0: MySQL サーバーによるバイナリログのディスクへの同期を無効にします。 代わりに、MySQL サーバーは、ほかのファイルの場合と同様に、バイナリログをディスクにフラッシュするためにオペレーティングシステムに依存します。 この設定は最高のパフォーマンスを提供しますが、電源障害またはオペレーティングシステムがクラッシュした場合は、バイナリログに同期されていないトランザクションがサーバーによってコミットされている可能性があります。sync_binlog=1: トランザクションがコミットされる前にバイナリログをディスクに同期できるようにします。 これは最も安全な設定ですが、ディスク書込み数が増加したためにパフォーマンスに悪影響を与える可能性があります。 電源障害またはオペレーティングシステムがクラッシュした場合、バイナリログから欠落しているトランザクションは準備完了状態にすぎません。 これにより、自動回復ルーチンはトランザクションをロールバックでき、バイナリログからトランザクションが失われないことが保証されます。sync_binlog=(NNは 0 または 1 以外の値): バイナリログは、Nバイナリログコミットグループが収集されたあとにディスクに同期されます。 電源障害またはオペレーティングシステムがクラッシュした場合は、バイナリログにフラッシュされていないトランザクションがサーバーによってコミットされている可能性があります。 この設定は、ディスク書込み数が増加したため、パフォーマンスに悪影響を与える可能性があります。 値を大きくするとパフォーマンスは向上しますが、データ損失のリスクは高くなります。
トランザクションで
InnoDBを使用するレプリケーション設定で永続性と一貫性を最大限に高めるには、次の設定を使用します:sync_binlog=1。innodb_flush_log_at_trx_commit=1。
注意多くのオペレーティングシステムや一部のディスクハードウェアは、ディスクへのフラッシュ操作を行なったと欺きます。 フラッシュが行われていなくても、行われたと mysqld に通知される可能性があります。 この場合、推奨設定であってもトランザクションの永続性は保証されず、最悪の場合は停電によって
InnoDBデータが破損する可能性があります。 バッテリーバックアップのディスクキャッシュを SCSI ディスクコントローラ内やディスク自体で使用すると、ファイルフラッシュの速度が上がり、操作が安全になります。 ハードウェアキャッシュ内のディスク書き込みのキャッシュを無効にすることもできます。 -
transaction_write_set_extractionコマンド行形式 --transaction-write-set-extraction[=value]システム変数 transaction_write_set_extractionスコープ グローバル、セッション 動的 はい SET_VARヒントの適用いいえ 型 列挙 デフォルト値 XXHASH64有効な値 OFFMURMUR32XXHASH64マルチスレッドレプリカ (
slave_parallel_workersが 0 より大きい値に設定されているレプリカ) を持つレプリケーションソースサーバーの場合、binlog_transaction_dependency_trackingはWRITESETまたはWRITESET_SESSIONに設定され、ソース書込みセットから依存性情報を生成します。transaction_write_set_extractionは、トランザクション中に抽出された書込みのハッシュに使用されるアルゴリズムを指定します。このシステム変数の値を変更するには、binlog_formatをROWに設定する必要があります。WRITESETまたはWRITESET_SESSIONがbinlog_transaction_dependency_trackingの値として設定されている場合、transaction_write_set_extractionを設定してアルゴリズムを指定する必要があります (OFFに設定されていません)。 MySQL 8.0 のデフォルトでは、transaction_write_set_extractionはXXHASH64に設定されています。binlog_transaction_dependency_trackingの現在の値はWRITESETまたはWRITESET_SESSIONですが、transaction_write_set_extractionの値は変更できません。グループレプリケーションの場合、
transaction_write_set_extractionをXXHASH64に設定する必要があります。 トランザクションから書込みを抽出するプロセスは、すべてのグループメンバーの競合検出および証明のためにグループレプリケーションで使用されます。 セクション18.9.1「グループレプリケーションの要件」を参照してください。MySQL 8.0.14 では、このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。