ApsaraDB RDS:binlog キャッシュフリーフラッシュの使用

機能の有効化

次のコマンドを実行して binlog キャッシュフリーフラッシュを有効にします：

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 リソースを消費し、インスタンスが応答しなくなる可能性があります。

binlog キャッシュフリーフラッシュによる解決策

AliSQL は、キャッシュ内の一時ファイルを直接バイナリログファイルに変換できるように、バイナリログキャッシュのメカニズムを最適化します。これは、次の2つの変更によって可能になります：

• 予約済みヘッダースペース：イベントが一時ファイルに書き込まれる際、先頭にバイナリログファイルのヘッダー用のスペースが予約されます。一時ファイルがバイナリログファイルに変換されると、その予約済みスペースが必要なヘッダーで埋められます。別途書き込みを行う必要はありません。

• 事前計算された終了位置：各イベントは予約済みスペースのサイズに基づいて自身の終了位置を計算するため、変換後にはすでに位置が正しい値になっています。

変換されたバイナリログファイルの内容

大規模なトランザクションがコミットされると、変換前に一時ファイルの先頭にある予約済みスペースが次のデータで埋められます：

データ	説明
ファイルヘッダー	[0xFE 'bin']ファイルをバイナリログファイルとして識別する 4 バイトのマジックナンバー
ヘッダーイベント	フォーマット記述イベントと直前のグローバルトランザクション ID (GTID) イベント
空のイベント	残りの予約済みスペースを埋める、無視できるタイプのイベント
GTID イベント	コミット時に生成される、コミット中トランザクションの GTID

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