Binlog in Redo 機能は、トランザクションコミット時にバイナリログのコンテンツを redo ログに書き込むことで、同期ディスク I/O 操作を削減し、データベースパフォーマンスを向上させます。
前提条件
データベースバージョン：
MySQL 8.4
MySQL 8.0：マイナーエンジンバージョンは 20200430 以降である必要があります。インスタンスのマイナーエンジンバージョンをアップグレードするには、「マイナーエンジンバージョンのアップグレード」をご参照ください。
インスタンスの
sync_binlogパラメーターを1に、binlog_order_commitsパラメーターをOFFに設定してください。詳細については、「インスタンスパラメーターの設定」をご参照ください。インスタンスのデータレプリケーションモードを非同期レプリケーションに設定してください。詳細については、「データレプリケーションモードの照会と変更」をご参照ください。
背景情報
ミッションクリティカルな MySQL シナリオでは、データセキュリティを確保するために、トランザクションがコミットされる際に、バイナリログと redo ログを同期的にディスクにフラッシュする必要があります。これは、次の 2 つのパラメーターを両方とも 1 に設定する必要があることを意味します。
sync_binlog = 1;
innodb_flush_log_at_trx_commit = 1;標準の MySQL では、トランザクションコミットごとに、バイナリログ用と redo ログ用に 2 回の同期ディスク I/O 操作が必要です。この要件によりコミット効率が低下し、その影響はクラウドディスクでより顕著になります。
トランザクションコミットの効率を向上させるために、AliSQL は Binlog in Redo 機能を導入しました。この機能は、persist_binlog_to_redo=ON パラメーターを設定することで有効になり、デフォルトでは無効になっています。トランザクションがコミットされると、この機能はバイナリログのコンテンツを redo ログとマージして一緒に書き込みます。redo ログを永続化するために必要な同期 I/O 操作は 1 回だけで、これによりバイナリログデータもディスクにフラッシュされます。この設計により、標準の MySQL でバイナリログと redo ログに必要だった 2 回の個別の I/O 操作が不要になり、レイテンシーが大幅に削減され、スループットが向上します。
さらに、Binlog in Redo は、バッチ処理とグループコミットのメカニズムを使用して、高同時実行シナリオにおける GTID 割り当てによるロック競合を緩和します。このアプローチにより、ロックの競合が減り、高いパフォーマンスが保証されます。
バックグラウンドスレッドがバイナリログファイルを非同期に書き込み、定期的にバッチでデータを追記します。これにより、リアルタイムの fsync 呼び出しによるファイルシステムへの圧力が回避され、全体的な I/O 効率が向上します。データベースが予期せず再起動した場合でも、システムは redo ログ内に保存されているバイナリログデータを再生することで、バイナリログファイルの整合性を自動的に復元でき、データ整合性が確保されます。
Binlog in Redo 機能は、バイナリログのフォーマットを変更しません。バイナリログに基づくレプリケーションやサードパーティ製のツールは影響を受けません。
注意事項
Binlog in Redo 機能を有効にした後、物理バックアップファイルを使用して高性能ローカルディスクインスタンスを自己管理型データベースに復元するには、RDS が提供する XtraBackup ツールを使用する必要があります。XtraBackup ツールをインストールするには、「ツールの準備」をご参照ください。
パラメーター
persist_binlog_to_redo
Binlog in Redo 機能を有効または無効にします。これはグローバルシステム変数です。有効な値：
ONまたはOFF。このパラメーターへの変更は、インスタンスを再起動することなく即座に有効になります。説明この機能を有効にするには、
persist_binlog_to_redoをONに設定することに加えて、binlog_order_commitsをOFFに設定し、インスタンスのデータレプリケーションモードを非同期レプリケーションに設定する必要もあります。インスタンスパラメーターの設定方法の詳細については、「インスタンスパラメーターの設定」をご参照ください。
データレプリケーションモードの設定方法の詳細については、「データレプリケーションモードの照会と変更」をご参照ください。
インスタンスの
sync_binlogパラメーターが 1 に設定されていない場合、上記のパラメーターを設定しても Binlog in Redo 機能は有効になりません。この場合、Binlog Parallel Flush 機能を使用してインスタンスのパフォーマンスを最適化することを推奨します。sync_binlog_interval
バイナリログが非同期に永続化される間隔。これはグローバルシステム変数であり、
persist_binlog_to_redo = ONの場合にのみ有効です。デフォルト値は 50 で、単位はミリ秒 (ms) です。ほとんどの場合、デフォルト値で十分です。このパラメーターへの変更は、インスタンスを再起動することなく即座に有効になります。
パフォーマンスベンチマーク
テスト環境
アプリケーションサーバー：Alibaba Cloud Elastic Compute Service (ECS) インスタンス
RDS インスタンスの仕様：32 コア、128 GB のメモリ、ESSD クラウドディスク
インスタンスタイプ：High-availability Edition (データレプリケーションモード：非同期レプリケーション)
テストケース
以下の組み込み Sysbench テストケースを使用しました。
oltp_update_non_index
oltp_write_only
テスト結果
oltp_update_non_index
Binlog in Redo を有効にすると、低同時実行シナリオでは TPS が大幅に増加し、高同時実行シナリオでは顕著に増加し、レイテンシーが低下します。
oltp_write_only
Binlog in Redo を有効にすると、低同時実行および高同時実行シナリオの両方で TPS が大幅に増加し、レイテンシーが低下します。
結論
oltp_update_non_indexテストケースには単一ステートメントトランザクションのみが含まれているため、コミットがより頻繁に行われます。対照的に、oltp_write_onlyには複数ステートメントトランザクション (2 つのUPDATEステートメント、1 つのDELETEステートメント、1 つのINSERTステートメント) が含まれているため、コミットの頻度は低くなります。その結果、oltp_update_non_indexのパフォーマンス向上は、oltp_write_onlyよりも顕著です。64 未満の同時接続数では、Binlog in Redo 機能はパフォーマンスを大幅に向上させ、レイテンシーを削減します。これにより、ほとんどの本番ワークロードで効果的です。
256 を超える同時接続数では、Binlog in Redo 機能はより高いピークパフォーマンスとより低いレイテンシーを提供し、突然のトラフィックスパイクをより適切に処理できるようになります。