Documentation Home
MySQL 8.0 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 36.1Mb
PDF (A4) - 36.2Mb


このページは機械翻訳したものです。

17.1.6.5 グローバルトランザクション ID システム変数

このセクションで説明する MySQL Server システム変数は、グローバルトランザクション識別子 (GTID) をモニターおよび制御するために使用されます。 追加情報については セクション17.1.3「グローバルトランザクション識別子を使用したレプリケーション」を参照してください。

  • binlog_gtid_simple_recovery

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

    コマンド行形式 --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_consistencyON に設定されている場合、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_consistencyOFF にデフォルト設定されていました。 これらの以前のリリースとの互換性を維持するために、列挙はデフォルトで OFF に設定され、値を指定せずに --enforce-gtid-consistency を設定すると、値が ON に設定されたと解釈されます。 変数には、値に対する複数のテキストエイリアスもあります: 0=OFF=FALSE1=ON=TRUE2=WARN。 これは他の列挙型とは異なりますが、以前のリリースで使用されていたブール型との互換性は維持されます。 これらの変更は、変数によって返される内容に影響します。 SELECT @@ENFORCE_GTID_CONSISTENCYSHOW VARIABLES LIKE 'ENFORCE_GTID_CONSISTENCY'および SELECT * FROM INFORMATION_SCHEMA.VARIABLES WHERE 'VARIABLE_NAME' = 'ENFORCE_GTID_CONSISTENCY'を使用すると、すべて数値フォームではなくテキストフォームが返されます。 @@ENFORCE_GTID_CONSISTENCY はブールの数値フォームを返しますが、SHOW および情報スキーマのテキストフォームを返すため、これは互換性のない変更です。

  • gtid_executed

    システム変数 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

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

    システム変数 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_modeOFF の場合、この変数を設定しても効果はありません。

    この変数が UUID に設定された後:NUMBER では、トランザクションがコミットまたはロールバックされている場合、他のステートメントの前に明示的な SET GTID_NEXT ステートメントを再発行する必要があります。

    DROP TABLE または DROP TEMPORARY TABLE は、非一時テーブルと一時テーブルの組み合わせ、または非トランザクションストレージエンジンを使用する一時テーブルとトランザクションストレージエンジンを使用する一時テーブルの組み合わせで使用すると、明示的なエラーで失敗します。

  • gtid_owned

    システム変数 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

    システム変数 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_setgtid_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_setgtid_executedgtid_purged の両方に追加されます。

注記

MySQL 5.7.7 以前のバイナリログがサーバーに存在する場合 (たとえば、古いサーバーから MySQL 8.0 へのアップグレード後)、SET @@GLOBAL.gtid_purged ステートメントの発行後、サーバーを再起動する前にサーバー構成ファイルで binlog_gtid_simple_recovery=FALSE を設定する必要がある場合があります。そうしないと、gtid_purged が正しく計算されない可能性があります。 この設定が必要な状況の詳細は、binlog_gtid_simple_recovery の説明を参照してください。