このページは機械翻訳したものです。
このセクションで説明する 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有効な値 OFFONWARNこの変数の値に応じて、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 グローバルスコープで使用する場合、この変数には、
SETgtid_purgedステートメントによって設定されたサーバーおよび GTID で実行されたすべてのトランザクションのセットの表現が含まれます。 これは、SHOW MASTER STATUSおよびSHOW REPLICA | SLAVE STATUSの出力のExecuted_Gtid_Setカラムの値と同じです。 この変数の値は GTID セットです。詳細は、GTID セット を参照してください。サーバーが起動すると、
@@GLOBAL.gtid_executedが初期化されます。 バイナリログを反復してgtid_executedに移入する方法の詳細は、binlog_gtid_simple_recoveryを参照してください。 GTID は、トランザクションの実行時、またはSETgtid_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有効な値 OFFOFF_PERMISSIVEON_PERMISSIVEONGTID ベースのロギングを有効にするかどうか、およびログに含めることができるトランザクションのタイプを制御します。 グローバルシステム変数を設定するには、十分な権限が必要です。 セクション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有効な値 AUTOMATICANONYMOUSUUID: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 の説明を参照してください。