binlog_gtid_simple_recovery

この変数は、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 が正しく初期化されないことがあります:

いずれかの状況で不正な GTID セットが計算された場合、あとで binlog_gtid_simple_recovery=FALSE を使用してサーバーを再起動しても、正しくありません。 これらの状況のいずれかが適用されるか、サーバーに適用される可能性がある場合は、サーバーを起動または再起動する前に binlog_gtid_simple_recovery=FALSE を設定します。

binlog_gtid_simple_recovery=FALSE が設定されている場合、gtid_purged システム変数 で説明されている gtid_executed および gtid_purged の計算方法は、次のようにバイナリログファイルを繰り返すように変更されます:

enforce_gtid_consistency

この変数の値に応じて、GTID を使用して安全にログに記録できるステートメントのみを実行できるようにすることで、サーバーは GTID 整合性を強制します。 GTID ベースのレプリケーションを有効にする前に、この変数を ON に設定する必要があります。

enforce_gtid_consistency で構成できる値は次のとおりです:

--enforce-gtid-consistency は、ステートメントに対してバイナリロギングが行われた場合にのみ有効になります。 バイナリロギングがサーバーで無効になっている場合、またはステートメントがフィルタによって削除されたためにバイナリログに書き込まれない場合、GTID の整合性は、ログに記録されていないステートメントに対してチェックまたは適用されません。

enforce_gtid_consistency が ON に設定されている場合、GTID セーフステートメントを使用してログに記録できるステートメントのみが記録されるため、ここにリストされている操作はこのオプションとともに使用できません:

詳細は、セクション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

グローバルスコープで使用する場合、この変数には、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

この数のトランザクションが処理されるたびに、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 ベースのロギングを有効にするかどうか、およびログに含めることができるトランザクションのタイプを制御します。 グローバルシステム変数を設定するには、十分な権限が必要です。 セクション5.1.9.1「システム変数権限」 を参照してください。gtid_mode=ON を設定するには、enforce_gtid_consistency が true である必要があります。 この変数を変更する前に、セクション17.1.4「オンラインサーバーでの GTID モードの変更」 を参照してください。

ログに記録されるトランザクションは、匿名にすることも GTID を使用することもできます。 匿名トランザクションは、特定のトランザクションを識別するためにバイナリログファイルと位置に依存します。 GTID トランザクションには、トランザクションの参照に使用される一意の識別子があります。 様々なモードは次のとおりです:

ある値から別の値への変更は、一度に 1 つのステップにしかできません。 たとえば、gtid_mode が現在 OFF_PERMISSIVE に設定されている場合、OFF または ON_PERMISSIVE に変更できますが、ON には変更できません。

gtid_purged および gtid_executed の値は、gtid_mode の値に関係なく永続的です。 したがって、gtid_mode の値を変更した後でも、これらの変数には正しい値が含まれます。

gtid_next

この変数は、次の GTID を取得するかどうかとその取得方法を指定するために使用されます。

このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、REPLICATION_APPLIER 権限 (セクション17.3.3「レプリケーション権限チェック」 を参照) または制限付きセッション変数の設定に十分な権限 (セクション5.1.9.1「システム変数権限」 を参照) が必要です。

gtid_next では、次のいずれかの値を使用できます:

前述のどのオプションが有効かは、gtid_mode の設定によって異なります。詳細は、セクション17.1.4.1「レプリケーションモードの概念」 を参照してください。 gtid_mode が OFF の場合、この変数を設定しても効果はありません。

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

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

gtid_owned

この読取り専用変数は、主に内部で使用されます。 その内容はスコープによって異なります。

gtid_purged

gtid_purged システム変数 (@@GLOBAL.gtid_purged) のグローバル値は GTID セットで、サーバー上でコミットされたが、サーバー上のバイナリログファイルには存在しないすべてのトランザクションの GTID で構成されます。gtid_purged は、gtid_executed のサブセットです。 GTID の次のカテゴリが gtid_purged にあります:

サーバーが起動すると、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 つ以上のデータベースのバックアップをリストアするが、サーバー上のトランザクションを含む関連するバイナリログがない場合です。

MySQL 8.0 からは、gtid_purged の値を設定する方法が 2 つあります。 gtid_purged の値を指定した GTID セットに置き換えるか、gtid_purged によってすでに保持されている GTID セットに指定した GTID セットを追加できます。 サーバーに既存の GTID がない場合 (たとえば、既存のデータベースのバックアップをプロビジョニングする空のサーバーがある場合)、両方の方法で同じ結果が得られます。 サーバー上にすでに存在するトランザクションと重複するバックアップを復元する場合、たとえば、破損したテーブルを mysqldump を使用して作成されたソースからの部分的なダンプで置き換える場合 (ダンプが部分的であっても、サーバー上のすべてのトランザクションの GTID を含む)、gtid_purged の値を置き換える最初の方法を使用します。 サーバー上にすでに存在するトランザクションとは無関係なバックアップをリストアする場合 (たとえば、2 つの異なるサーバーからのダンプを使用してマルチソースレプリカをプロビジョニングする場合)、gtid_purged の値に追加する別の方法を使用します。