ApsaraDB RDS:バイナリログキャッシュのフリーフラッシュ機能の使用

機能の有効化

以下のコマンドを実行して、バイナリログキャッシュのフリーフラッシュ機能を有効化します。

SET GLOBAL loose_binlog_cache_free_flush = on;

変更は即時反映されます。インスタンスを再起動する必要はありません。

機能の有効状態の確認

SHOW GLOBAL VARIABLES LIKE 'loose_binlog_cache_free_flush';

しきい値の調整

loose_binlog_cache_free_flush_limit_size パラメーターは、変換をトリガーする最小バイナリログデータサイズを設定します。デフォルト値は 256 MB であり、これはバイナリログデータが 256 MB を超えるトランザクションのみがフリーフラッシュ処理パスを使用することを意味します。

より小規模なトランザクションにも最適化を適用するには、しきい値を低下させます。

SET GLOBAL loose_binlog_cache_free_flush_limit_size = <size-in-bytes>;

機能の無効化

SET GLOBAL loose_binlog_cache_free_flush = off;

バイナリログキャッシュ

各セッションには専用のバイナリログキャッシュが割り当てられます。これは、メモリ内領域（binlog_cache_size で制限）とディスク上の一時ファイルの組み合わせです。トランザクションのイベントがメモリ内制限を超えると、一時ファイルへオーバーフローします。

コミット時に、エンジンはキャッシュからすべてのイベントを読み取り、終了位置およびチェックサムを更新したうえで、書き込みロック下でバイナリログファイルへ書き込みます。このロックは、イベントが中断なく書き込まれることを保証しますが、フラッシュ全体の期間中、他のトランザクションをブロックします。

大規模トランザクションによるバイナリログ書き込みの影響

トランザクションのバイナリログキャッシュが数十 GB に達すると、コミット時のフラッシュによって以下の 2 つの問題が発生します。

• 書き込みリクエストのブロック：フラッシュ全体の期間中、書き込みロックが保持されるため、他のトランザクションによる書き込みが阻止されます。

• I/O リソースの枯渇：大規模なシーケンシャル書き込みにより I/O リソースが消費され、インスタンスが応答しなくなる可能性があります。

バイナリログキャッシュのフリーフラッシュによる解決方法

AliSQL は、バイナリログキャッシュ機構を最適化し、キャッシュ内の一時ファイルを直接バイナリログファイルへ変換できるようにしています。これを実現するための 2 つの変更点は以下のとおりです。

• ヘッダー領域の事前確保：イベントが一時ファイルへ書き込まれる際に、バイナリログファイルのヘッダー用に先頭に領域が確保されます。一時ファイルがバイナリログファイルへ変換される際、この確保済み領域に必要なヘッダーが書き込まれるため、別途書き込みを行う必要がありません。

• 終了位置の事前計算：各イベントは、確保済み領域のサイズに基づいて終了位置を計算するため、変換後に位置情報はすでに正しく設定されています。

変換後のバイナリログファイルの内容

大規模トランザクションがコミットされる際、一時ファイルの先頭に確保された領域には、変換前に以下のデータが書き込まれます。

データ	説明
ファイルヘッダー	バイナリログファイルであることを識別する 4 バイトのマジックナンバー [0xFE 'bin']
ヘッダーイベント	フォーマット記述イベントおよび以前のグローバルトランザクション ID（GTID）イベント
空イベント	無視可能なタイプのイベントで、残りの確保済み領域を埋めます
GTID イベント	コミット時に生成される、当該トランザクションのグローバルトランザクション ID（GTID）

ファイルの残りの部分には、トランザクションの元のイベント（クエリイベント、テーブルマップイベント、行ベースイベント、XID イベント）がそのまま保持されます。