すべてのプロダクト
Search
ドキュメントセンター

ApsaraDB RDS:Binlog パラレル フラッシュ

最終更新日:May 13, 2026

AliSQL はパフォーマンスを向上させるため、バイナリログのコミットステージ用に Binlog パラレル フラッシュという最適化機能を搭載しています。この最適化を有効にすると、インスタンスの書き込みパフォーマンスを大幅に向上させることができます。

前提条件

  • インスタンスで、次のいずれかのデータベースバージョンが実行されていること:

    • MySQL 8.4

    • マイナーエンジンバージョンが 20230930 以降の MySQL 8.0

      説明

      [基本情報] ページの [設定情報] セクションで [マイナーエンジンバージョンのアップグレード] ボタンを探します。このボタンが表示されている場合は、クリックして現在のバージョンを確認できます。表示されていない場合、インスタンスは最新バージョンです。詳細については、「マイナーエンジンバージョンのアップグレード」をご参照ください。

  • インスタンスの sync_binlog パラメータが 1 に設定されていないこと。

背景情報

13ca93f432f146db197ded0b18b3023042978ae3ee7812bef3267aa4ca532dedQzpcVXNlcnNccWl5aW5ndGFuXEFwcERhdGFcUm9hbWluZ1xpRGluZ1RhbGtcNDI5ODE1NTU5N192MlxJbWFnZUZpbGVzXDE3MTEwMTA5NTg1MTRfMjVEODNBODItRjNCMi00OGYxLUE1RDMtNzkzNkU5REIxNjQ5LnBuZw==.png

MySQL では、すべてのトランザクションはコミットステージでバイナリログに書き込む必要があります。これはシリアルプロセスであり、上の図が示すように、あるトランザクションがバイナリログに書き込めるのは、先行するトランザクションが完了した後のみです。

このプロセスは時間もかかります。バイナリログへの書き込み前に、バイナリログキャッシュに保存されているすべてのイベントをパースし、チェックサムとログ位置を設定し、GTID イベントを生成する必要があります。これらのイベントがバイナリログファイルに書き込まれるのは、その後です。このシリアルで時間のかかるプロセスは、インスタンスの書き込みパフォーマンスに大きなボトルネックとなります。このボトルネックを解消するため、AliSQL は Binlog パラレル フラッシュという最適化機能を搭載しています。

最適化の詳細

バイナリログバッファ

7d62745838385a745eefff4a18d6f6ae712c7f429c11d5456c9288e66c0685d9QzpcVXNlcnNccWl5aW5ndGFuXEFwcERhdGFcUm9hbWluZ1xpRGluZ1RhbGtcNDI5ODE1NTU5N192MlxJbWFnZUZpbGVzXDE3MTEwMTEwNTY5ODBfRkE0RTZEOEYtMTg0NC00NzFiLTg0RTYtRjIxQTYyNjk4OEQwLnBuZw==.png

AliSQL は、バイナリログバッファを導入することで、標準のロジックを強化しています。位置が割り当てられた後、複数のスレッドがバイナリログイベントをバイナリログバッファに並列で書き込むことができます。その後、バックエンドスレッドがバイナリログバッファの内容をバイナリログファイルに書き込みます。この設計により、従来はシリアルに実行されていたステップ (パース、チェックサムとログ位置の値の入力、GTID イベントの生成など) を並列で実行できるようになります。これにより、トランザクションのコミット時にバイナリログを書き込む際のパフォーマンスのボトルネックが大幅に軽減されます。

パラレルグループコミット

MySQL では、トランザクションはコミットステージにおいて、グループ単位でバイナリログと REDO ログに書き込みを行います。この技術はグループコミットと呼ばれ、I/O 操作をまとめることでパフォーマンスを向上させます。今回の最適化では、グループコミットの概念を維持しつつ、次の図に示すように Binlog パラレル フラッシュ機能と統合しています。

49080702daa3a9709047732fbb09ebe2c40954015a22dc572926f5f706cdec34QzpcVXNlcnNccWl5aW5ndGFuXEFwcERhdGFcUm9hbWluZ1xpRGluZ1RhbGtcNDI5ODE1NTU5N192MlxJbWFnZUZpbGVzXDE3MTEwMTEzMzE1ODZfRUVEQUNGMkEtMTE4RS00YmU4LUE0RDItQjZGRDg2NjEzMDE0LnBuZw==.png

Binlog パラレル フラッシュの最適化を適用すると、各トランザクションはシリアルに GTID を割り当て、バイナリログバッファ内のスペースを確保します。その後、複数のグループがバイナリログバッファに並列で書き込むことができます。REDO ログが永続化され、バックエンドスレッドによるバイナリログへの書き込みが完了した後、システムはトランザクションのグループ全体をコミットします。

バイナリログの永続化

f8acb0a238e8f535995bc410175c5b167240ab1ee31b97091d438c41812720b7QzpcVXNlcnNccWl5aW5ndGFuXEFwcERhdGFcUm9hbWluZ1xpRGluZ1RhbGtcNDI5ODE1NTU5N192MlxJbWFnZUZpbGVzXDE3MTEwMTExMTgzOTBfOUMxQTkzNjktRTczNi00ZjIwLUFGNzktRUFCNERBOENBNDcwLnBuZw==.pngBinlog パラレル フラッシュの最適化では、バックエンドスレッドが定期的にバイナリログファイルを永続化します。デフォルトでは、これは 1 秒に 1 回行われます。

パラメータ

loose_binlog_parallel_flush

このグローバルシステム変数は、Binlog パラレル フラッシュ機能を有効または無効にします。有効な値は on または off です。このパラメータへの変更は、インスタンスを再起動することなく、すぐに有効になります。

パフォーマンスへの影響

テスト環境

このテストでは、次の表に示すように、4 つの異なる ApsaraDB RDS for MySQL インスタンス仕様でパフォーマンスを比較しました。

製品

バージョン

vCPU とメモリ

ストレージタイプ

ストレージサイズ

ApsaraDB RDS for MySQL

8.0 (マイナーエンジンバージョン 20230930)

16 vCPU 32 GB

ESSD PL1

1000 GB

16 vCPU 32 GB

SSD

1000 GB

64 vCPU 128 GB

ESSD PL1

1000 GB

64 vCPU 128 GB

SSD

1000 GB

パラメータ設定

テストインスタンスでは、高性能パラメータテンプレートを使用し、パフォーマンスに関連する 2 つのパラメータを sync_binlog = 1000 および innodb_flush_log_at_trx_commit = 2 に設定しました。

テストスクリプト

パフォーマンステストでは、SysBench の oltp_update_non_index スクリプトを使用しました。テストデータセットは 100 個のテーブルで構成され、各テーブルには 100,000 行が含まれます。

テスト結果

テスト結果を次の図に示します。同時実行性の高いワークロードにおいて、Binlog パラレル フラッシュ機能は、標準の MySQL 実装と比較してパフォーマンスを大幅に向上させます。ピーク時のパフォーマンス向上率は 10%~30% です。

5387087b82ed9e5a496a96425aee3abbe3cd103f9e53f63b92eae933526933a3QzpcVXNlcnNccWl5aW5ndGFuXEFwcERhdGFcUm9hbWluZ1xpRGluZ1RhbGtcNDI5ODE1NTU5N192MlxJbWFnZUZpbGVzXDE3MTA0ODMyODY1NTlfOTdCMkI0NTktNTYzMi00ZmU2LUJEMTMtOEQwMjg5QTYwQTVCLnBuZw==.png