このページは機械翻訳したものです。
このセクションで説明する MySQL Server システム変数は、グローバルトランザクション識別子 (GTID) をモニターおよび制御するために使用されます。 追加情報については セクション17.1.3「グローバルトランザクション識別子を使用したレプリケーション」を参照してください。
-
コマンド行形式 --binlog-gtid-simple-recovery[={OFF|ON}]
システム変数 binlog_gtid_simple_recovery
スコープ グローバル 動的 いいえ SET_VAR
ヒントの適用いいえ 型 Boolean デフォルト値 ON
この変数は、MySQL の起動または再起動時に GTID の検索中にバイナリログファイルがどのように繰り返されるかを制御します。
MySQL 8.0 のデフォルトである
binlog_gtid_simple_recovery=TRUE
の場合、gtid_executed
およびgtid_purged
の値は、最新のバイナリログファイルともっとも古いバイナリログファイルのPrevious_gtids_log_event
の値に基づいて起動時に計算されます。 計算の詳細は、gtid_purged
システム変数 を参照してください。 この設定は、サーバーの再起動時に 2 つのバイナリログファイルにのみアクセスします。 サーバー上のすべてのバイナリログが MySQL 5.7.8 以降を使用して生成された場合、binlog_gtid_simple_recovery=TRUE
は常に安全に使用できます。MySQL 5.7.7 以前のバイナリログがサーバーに存在する場合 (たとえば、古いサーバーから MySQL 8.0 へのアップグレード後)、
binlog_gtid_simple_recovery=TRUE
を使用すると、次の 2 つの状況でgtid_executed
およびgtid_purged
が正しく初期化されないことがあります:最新のバイナリログは MySQL 5.7.5 以前によって生成され、
gtid_mode
は一部のバイナリログではON
でしたが、最新のバイナリログではOFF
でした。MySQL 5.7.7 以前で
SET @@GLOBAL.gtid_purged
ステートメントが発行され、SET @@GLOBAL.gtid_purged
ステートメントの時点でアクティブだったバイナリログはまだパージされていません。
いずれかの状況で不正な GTID セットが計算された場合、あとで
binlog_gtid_simple_recovery=FALSE
を使用してサーバーを再起動しても、正しくありません。 これらの状況のいずれかが適用されるか、サーバーに適用される可能性がある場合は、サーバーを起動または再起動する前にbinlog_gtid_simple_recovery=FALSE
を設定します。binlog_gtid_simple_recovery=FALSE
が設定されている場合、gtid_purged
システム変数 で説明されているgtid_executed
およびgtid_purged
の計算方法は、次のようにバイナリログファイルを繰り返すように変更されます:最新のバイナリログファイルからの
Previous_gtids_log_event
および GTID ログイベントの値を使用する代わりに、gtid_executed
の計算は最新のバイナリログファイルから繰り返され、Previous_gtids_log_event
の値と、Previous_gtids_log_event
値が見つかった最初のバイナリログファイルからの GTID ログイベントを使用します。 サーバーの最新のバイナリログファイルに GTID ログイベントがない場合 (たとえば、gtid_mode=ON
が使用されたが、あとでサーバーがgtid_mode=OFF
に変更された場合)、このプロセスには時間がかかることがあります。もっとも古いバイナリログファイルからの
Previous_gtids_log_event
の値を使用する代わりに、gtid_purged
の計算はもっとも古いバイナリログファイルから繰り返され、空でないPrevious_gtids_log_event
値または GTID ログイベント (GTID の使用がその時点から開始されることを示す) が見つかった最初のバイナリログファイルからのPrevious_gtids_log_event
の値を使用します。 サーバーの古いバイナリログファイルに GTID ログイベントがない場合 (たとえば、gtid_mode=ON
がサーバー上で最近のみ設定された場合)、このプロセスには時間がかかることがあります。
-
コマンド行形式 --enforce-gtid-consistency[=value]
システム変数 enforce_gtid_consistency
スコープ グローバル 動的 はい SET_VAR
ヒントの適用いいえ 型 列挙 デフォルト値 OFF
有効な値 OFF
ON
WARN
この変数の値に応じて、GTID を使用して安全にログに記録できるステートメントのみを実行できるようにすることで、サーバーは GTID 整合性を強制します。 GTID ベースのレプリケーションを有効にする前に、この変数を
ON
に設定する必要があります。enforce_gtid_consistency
で構成できる値は次のとおりです:OFF
: すべてのトランザクションが GTID 整合性に違反することを許可されます。ON
: GTID 整合性に違反するトランザクションは許可されていません。WARN
: すべてのトランザクションは GTID 整合性に違反できますが、この場合は警告が生成されます。
--enforce-gtid-consistency
は、ステートメントに対してバイナリロギングが行われた場合にのみ有効になります。 バイナリロギングがサーバーで無効になっている場合、またはステートメントがフィルタによって削除されたためにバイナリログに書き込まれない場合、GTID の整合性は、ログに記録されていないステートメントに対してチェックまたは適用されません。enforce_gtid_consistency
がON
に設定されている場合、GTID セーフステートメントを使用してログに記録できるステートメントのみが記録されるため、ここにリストされている操作はこのオプションとともに使用できません:トランザクション内の
CREATE TEMPORARY TABLE
またはDROP TEMPORARY TABLE
ステートメント。トランザクションおよび非トランザクションテーブルの両方を更新するトランザクションまたはステートメント。 すべての非トランザクションテーブルが一時テーブルの場合、非トランザクション DML は同じトランザクションまたはトランザクション DML と同じステートメントで許可されるという例外があります。
MySQL 8.0.21 より前の
CREATE TABLE ... SELECT
ステートメント。 MySQL 8.0.21 からは、アトミック DDL をサポートするストレージエンジンに対してCREATE TABLE ... SELECT
ステートメントが許可されます。
詳細は、セクション17.1.3.7「GTID ベースレプリケーションの制約」を参照してください。
MySQL 5.7 より前およびそのリリースシリーズの初期リリースでは、ブール
enforce_gtid_consistency
はOFF
にデフォルト設定されていました。 これらの以前のリリースとの互換性を維持するために、列挙はデフォルトでOFF
に設定され、値を指定せずに--enforce-gtid-consistency
を設定すると、値がON
に設定されたと解釈されます。 変数には、値に対する複数のテキストエイリアスもあります:0=OFF=FALSE
、1=ON=TRUE
、2=WARN
。 これは他の列挙型とは異なりますが、以前のリリースで使用されていたブール型との互換性は維持されます。 これらの変更は、変数によって返される内容に影響します。SELECT @@ENFORCE_GTID_CONSISTENCY
、SHOW VARIABLES LIKE 'ENFORCE_GTID_CONSISTENCY'
およびSELECT * FROM INFORMATION_SCHEMA.VARIABLES WHERE 'VARIABLE_NAME' = 'ENFORCE_GTID_CONSISTENCY'
を使用すると、すべて数値フォームではなくテキストフォームが返されます。@@ENFORCE_GTID_CONSISTENCY
はブールの数値フォームを返しますが、SHOW
および情報スキーマのテキストフォームを返すため、これは互換性のない変更です。 -
システム変数 gtid_executed
システム変数 gtid_executed
スコープ グローバル スコープ グローバル、セッション 動的 いいえ 動的 いいえ SET_VAR
ヒントの適用いいえ SET_VAR
ヒントの適用いいえ 型 文字列 単位 set of GTIDs グローバルスコープで使用する場合、この変数には、
SET
gtid_purged
ステートメントによって設定されたサーバーおよび GTID で実行されたすべてのトランザクションのセットの表現が含まれます。 これは、SHOW MASTER STATUS
およびSHOW REPLICA | SLAVE STATUS
の出力のExecuted_Gtid_Set
カラムの値と同じです。 この変数の値は GTID セットです。詳細は、GTID セット を参照してください。サーバーが起動すると、
@@GLOBAL.gtid_executed
が初期化されます。 バイナリログを反復してgtid_executed
に移入する方法の詳細は、binlog_gtid_simple_recovery
を参照してください。 GTID は、トランザクションの実行時、またはSET
gtid_purged
ステートメントの実行時にセットに追加されます。任意の時点でバイナリログに存在できるトランザクションのセットは、
GTID_SUBTRACT(@@GLOBAL.gtid_executed, @@GLOBAL.gtid_purged)
と同等です。つまり、まだパージされていないバイナリログ内のすべてのトランザクションに相当します。RESET MASTER
を発行することで、この変数のグローバル値 (ただし、セッション値ではない) は空の文字列にリセットされます。 GTID は、セットがRESET MASTER
によってクリアされるときを除いてセットから削除されません。一部の旧リリースでは、この変数はセッションスコープとともに使用することもできます。セッションスコープには、現在のセッションでキャッシュに書き込まれる一連のトランザクションの表現が含まれていました。 セッションスコープは非推奨になりました。
-
gtid_executed_compression_period
コマンド行形式 --gtid-executed-compression-period=#
システム変数 gtid_executed_compression_period
スコープ グローバル 動的 はい SET_VAR
ヒントの適用いいえ 型 Integer デフォルト値 (≥ 8.0.23) 0
デフォルト値 (≤ 8.0.22) 1000
最小値 0
最大値 4294967295
この数のトランザクションが処理されるたびに、
mysql.gtid_executed
テーブルを圧縮します。 サーバーでバイナリロギングが有効になっている場合、この圧縮方法は使用されず、代わりにmysql.gtid_executed
テーブルはバイナリログのローテーションごとに圧縮されます。 バイナリロギングがサーバーで無効になっている場合、圧縮スレッドは、指定された数のトランザクションが実行されるまでスリープしてから、ウェイクアップしてmysql.gtid_executed
テーブルの圧縮を実行します。 このシステム変数の値を 0 に設定すると、スレッドはウェイクアップしないため、この明示的な圧縮方法は使用されません。 かわりに、圧縮は必要に応じて暗黙的に行われます。MySQL 8.0.17 から、
InnoDB
トランザクションは、InnoDB
以外のトランザクションに対する個別のプロセスによってmysql.gtid_executed
テーブルに書き込まれます。 サーバーにInnoDB
トランザクションとInnoDB
以外のトランザクションが混在している場合、このシステム変数によって制御される圧縮はこのプロセスの作業を妨げ、処理速度が大幅に低下する可能性があります。 このため、そのリリースから、gtid_executed_compression_period
を 0 に設定することをお薦めします。MySQL 8.0.23 から、
InnoDB
およびInnoDB
以外のトランザクションが同じプロセスでmysql.gtid_executed
テーブルに書き込まれ、gtid_executed_compression_period
のデフォルト値は 0 です。詳しくはmysql.gtid_executed テーブル圧縮をご覧ください。
-
コマンド行形式 --gtid-mode=MODE
システム変数 gtid_mode
スコープ グローバル 動的 はい SET_VAR
ヒントの適用いいえ 型 列挙 デフォルト値 OFF
有効な値 OFF
OFF_PERMISSIVE
ON_PERMISSIVE
ON
GTID ベースのロギングを有効にするかどうか、およびログに含めることができるトランザクションのタイプを制御します。 グローバルシステム変数を設定するには、十分な権限が必要です。 セクション5.1.9.1「システム変数権限」 を参照してください。
gtid_mode=ON
を設定するには、enforce_gtid_consistency
が true である必要があります。 この変数を変更する前に、セクション17.1.4「オンラインサーバーでの GTID モードの変更」 を参照してください。ログに記録されるトランザクションは、匿名にすることも GTID を使用することもできます。 匿名トランザクションは、特定のトランザクションを識別するためにバイナリログファイルと位置に依存します。 GTID トランザクションには、トランザクションの参照に使用される一意の識別子があります。 様々なモードは次のとおりです:
OFF
: 新規トランザクションとレプリケートされたトランザクションの両方が匿名である必要があります。OFF_PERMISSIVE
: 新しいトランザクションは匿名です。 レプリケートされたトランザクションは、匿名トランザクションまたは GTID トランザクションのいずれかです。ON_PERMISSIVE
: 新規トランザクションは GTID トランザクションです。 レプリケートされたトランザクションは、匿名トランザクションまたは GTID トランザクションのいずれかです。ON
: 新規トランザクションとレプリケートされたトランザクションの両方が GTID トランザクションである必要があります。
ある値から別の値への変更は、一度に 1 つのステップにしかできません。 たとえば、
gtid_mode
が現在OFF_PERMISSIVE
に設定されている場合、OFF
またはON_PERMISSIVE
に変更できますが、ON
には変更できません。gtid_purged
およびgtid_executed
の値は、gtid_mode
の値に関係なく永続的です。 したがって、gtid_mode
の値を変更した後でも、これらの変数には正しい値が含まれます。 -
システム変数 gtid_next
スコープ セッション 動的 はい SET_VAR
ヒントの適用いいえ 型 列挙 デフォルト値 AUTOMATIC
有効な値 AUTOMATIC
ANONYMOUS
UUID:NUMBER
この変数は、次の GTID を取得するかどうかとその取得方法を指定するために使用されます。
このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、
REPLICATION_APPLIER
権限 (セクション17.3.3「レプリケーション権限チェック」 を参照) または制限付きセッション変数の設定に十分な権限 (セクション5.1.9.1「システム変数権限」 を参照) が必要です。gtid_next
では、次のいずれかの値を使用できます:AUTOMATIC
: 自動的に生成される次のグローバルトランザクション ID を使用します。ANONYMOUS
: トランザクションはグローバル識別子を持たず、ファイルと位置のみで識別されます。UUID
:NUMBER
形式のグローバルトランザクション ID。
前述のどのオプションが有効かは、
gtid_mode
の設定によって異なります。詳細は、セクション17.1.4.1「レプリケーションモードの概念」 を参照してください。gtid_mode
がOFF
の場合、この変数を設定しても効果はありません。この変数が
UUID
に設定された後:NUMBER
では、トランザクションがコミットまたはロールバックされている場合、他のステートメントの前に明示的なSET GTID_NEXT
ステートメントを再発行する必要があります。DROP TABLE
またはDROP TEMPORARY TABLE
は、非一時テーブルと一時テーブルの組み合わせ、または非トランザクションストレージエンジンを使用する一時テーブルとトランザクションストレージエンジンを使用する一時テーブルの組み合わせで使用すると、明示的なエラーで失敗します。 -
システム変数 gtid_owned
スコープ グローバル、セッション 動的 いいえ SET_VAR
ヒントの適用いいえ 型 文字列 単位 set of GTIDs この読取り専用変数は、主に内部で使用されます。 その内容はスコープによって異なります。
グローバルスコープで使用される場合、
gtid_owned
は、サーバーで現在使用されているすべての GTID のリストを、それらを所有するスレッドの ID とともに保持します。 この変数は主に、マルチスレッドレプリカがトランザクションがすでに別のスレッドに適用されているかどうかをチェックする場合に役立ちます。 アプライヤスレッドは、トランザクションを処理している間は常にトランザクション GTID の所有権を取得するため、@@global.gtid_owned
には処理中の GTID と所有者が表示されます。 トランザクションがコミット (またはロールバック) されると、適用者スレッドは GTID の所有権を解放します。セッションスコープとともに使用された場合、
gtid_owned
は、このセッションによって現在使用されており、所有されている単一の GTID を保持します。 この変数は主に、クライアントがgtid_next
を設定してトランザクションに GTID を明示的に割り当てたときに GTID の使用をテストおよびデバッグする場合に役立ちます。 この場合、@@session.gtid_owned
は、トランザクションがコミット (またはロールバック) されるまで、クライアントがトランザクションを処理している間は常に GTID を表示します。 クライアントがトランザクションの処理を終了すると、変数はクリアされます。 セッションにgtid_next=AUTOMATIC
が使用されている場合、gtid_owned
はトランザクションのコミットステートメントの実行中に短時間のみ移入されるため、適切な時点で@@global.gtid_owned
が読み取られるかどうかはリストされますが、対象のセッションからは監視できません。 セッションでクライアントによって処理される GTID を追跡する必要がある場合は、session_track_gtids
システム変数によって制御されるセッション状態トラッカを有効にできます。
-
システム変数 gtid_purged
スコープ グローバル 動的 はい SET_VAR
ヒントの適用いいえ 型 文字列 単位 set of GTIDs gtid_purged
システム変数 (@@GLOBAL.gtid_purged
) のグローバル値は GTID セットで、サーバー上でコミットされたが、サーバー上のバイナリログファイルには存在しないすべてのトランザクションの GTID で構成されます。gtid_purged
は、gtid_executed
のサブセットです。 GTID の次のカテゴリがgtid_purged
にあります:レプリカでバイナリロギングを無効にしてコミットされたレプリケートされたトランザクションの GTID。
現在パージされているバイナリログファイルに書き込まれたトランザクションの GTID。
ステートメント
SET @@GLOBAL.gtid_purged
によってセットに明示的に追加された GTID。
サーバーが起動すると、
gtid_purged
のグローバル値は GTID のセットに初期化されます。 この GTID セットの計算方法については、gtid_purged
システム変数 を参照してください。 MySQL 5.7.7 以前のバイナリログがサーバーに存在する場合は、サーバー構成ファイルでbinlog_gtid_simple_recovery=FALSE
を設定して、正しい計算を生成する必要がある場合があります。 この設定が必要な状況の詳細は、binlog_gtid_simple_recovery
の説明を参照してください。RESET MASTER
を発行すると、gtid_purged
の値が空の文字列にリセットされます。特定の GTID セット内のトランザクションが適用されたことをサーバーに記録するために、
gtid_purged
の値を設定できますが、それらはサーバー上のバイナリログには存在しません。 このアクションのユースケースの例は、サーバー上の 1 つ以上のデータベースのバックアップをリストアするが、サーバー上のトランザクションを含む関連するバイナリログがない場合です。重要GTID は、符号付き 64 ビット整数 (2 から 63 の累乗から 1 を引いた数) の負でない値までのサーバーインスタンスでのみ使用できます。
gtid_purged
の値をこの制限に近づく数に設定すると、後続のコミットによってサーバーで GTID が不足し、binlog_error_action
で指定されたアクションが実行される可能性があります。 MySQL 8.0.23 からは、サーバーインスタンスが制限に近づいたときに警告メッセージが発行されます。MySQL 8.0 からは、
gtid_purged
の値を設定する方法が 2 つあります。gtid_purged
の値を指定した GTID セットに置き換えるか、gtid_purged
によってすでに保持されている GTID セットに指定した GTID セットを追加できます。 サーバーに既存の GTID がない場合 (たとえば、既存のデータベースのバックアップをプロビジョニングする空のサーバーがある場合)、両方の方法で同じ結果が得られます。 サーバー上にすでに存在するトランザクションと重複するバックアップを復元する場合、たとえば、破損したテーブルを mysqldump を使用して作成されたソースからの部分的なダンプで置き換える場合 (ダンプが部分的であっても、サーバー上のすべてのトランザクションの GTID を含む)、gtid_purged
の値を置き換える最初の方法を使用します。 サーバー上にすでに存在するトランザクションとは無関係なバックアップをリストアする場合 (たとえば、2 つの異なるサーバーからのダンプを使用してマルチソースレプリカをプロビジョニングする場合)、gtid_purged
の値に追加する別の方法を使用します。-
gtid_purged
の値を指定した GTID セットに置き換えるには、次のステートメントを使用します:SET @@GLOBAL.gtid_purged = 'gtid_set'
gtid_set
は、gtid_purged
の現在の値のスーパーセットである必要があり、gtid_subtract(gtid_executed,gtid_purged)
と交差していてはなりません。 つまり、新しい GTID セットには、gtid_purged
にすでに存在する GTID が含まれている必要があり、まだパージされていない GTID をgtid_executed
に含めることはできません。gtid_set
には、@@global.gtid_owned
にある GTID、つまりサーバーで現在処理されているトランザクションの GTID も含めることができません。その結果、
gtid_purged
のグローバル値はgtid_set
に設定され、gtid_executed
の値はgtid_set
とgtid_executed
の以前の値の和集合になります。 -
指定した GTID セットを
gtid_purged
に追加するには、GTID セットの前にプラス記号 (+) を付けて次のステートメントを使用します:SET @@GLOBAL.gtid_purged = '+gtid_set'
gtid_set
は、gtid_executed
の現在の値と交差できません。 つまり、新しい GTID セットには、gtid_purged
にもすでに存在するトランザクションを含め、gtid_executed
の GTID を含めないでください。gtid_set
には、@@global.gtid_owned
にある GTID、つまりサーバーで現在処理されているトランザクションの GTID も含めることができません。その結果、
gtid_set
がgtid_executed
とgtid_purged
の両方に追加されます。
MySQL 5.7.7 以前のバイナリログがサーバーに存在する場合 (たとえば、古いサーバーから MySQL 8.0 へのアップグレード後)、SET @@GLOBAL.gtid_purged
ステートメントの発行後、サーバーを再起動する前にサーバー構成ファイルで binlog_gtid_simple_recovery=FALSE
を設定する必要がある場合があります。そうしないと、gtid_purged
が正しく計算されない可能性があります。 この設定が必要な状況の詳細は、binlog_gtid_simple_recovery
の説明を参照してください。