Amazon Aurora MySQL3におけるバイナリログの最適化

本記事は、2024年5月17日に公開された Binary logging optimizations in Amazon Aurora MySQL version 3 を翻訳したものです。

MySQLのバイナリログ(binlog)は、MySQLサーバ上のデータベースの変更を”イベント”と呼ばれる論理フォーマットでキャプチャするために使用されます。これらのデータベース変更には、DCL(CREATE USERやGRANTなど)、DDL(CREATE TABLE、ALTER TABLEなど)、DML(INSERT、UPDATE、DELETEなど)が含まれます。そのような変更がMySQLでコミットされると、サーバは 2-phase commit(2PC)を用いてトランザクションのバイナリログイベントをストレージエンジンのコミットをアトミックに永続化します。ACID (原子性、一貫性、独立性、永続性)準拠とデータベース変更のログ記録によって、他のMySQLサーバ(ReadReplica)への論理レプリケーションを容易にし、データベースの復旧プロセスを支援し、フルデータベースバックアップの上に論理的な変更を再適用することで特定の時点までデータベースインスタンスを復元できるようになります。

しかし、この ACID 準拠を強制すると、書き込みの量の増加、データベース復旧時間の長期化、高い並列度でクエリが実行されている環境でのロック競合など、追加の負荷がかかる可能性があります。特定時点への復元(PITR)やReadReplicaを使った水平スケーリングの場合、バイナリログをデータベースサーバに論理的に適用する必要があり、大量の書き込みワークロードの下ではレプリケーションラグが発生し、目標復旧時間(RTO)が長くなる可能性があります。例えば、DDL文をReadReplicaやスタンバイデータベースサーバに複製する必要がある場合、完了するまでその他のログイベントの適用がブロックされます。

2015年にAmazon Aurora MySQL互換エディションがリリースされると、お客様はこれらの要件を満たすためにバイナリログを利用する必要がなくなりました。カスタムビルドされたAmazon Auroraストレージアーキテクチャでは、レプリケーション、リカバリ、PITRがすべて透過的にストレージレイヤで処理され、バイナリログを有効にする必要がありません。これらの革新的な技術により、リカバリ時間やACID準拠を犠牲にすることなく、高い並行ワークロードをアベイラビリティーゾーンやAWS リージョン間でミリ秒のレプリケーションラグでスケーリングできるようになりました。

この記事では、Amazon Aurora MySQLでのバイナリログの使用例、これまでにAmazon Aurora MySQLに追加されたバイナリログ機能の強化、さらにはMySQLネイティブのバイナリログ機能のサポートについて説明します。

バイナリログの使用例

Amazon Aurora MySQLでは、高可用性や水平スケーラビリティのためにバイナリログは必要ありませんが、以下のようなバイナリログを利用したユースケースがあります：

Amazon Aurora MySQL に移行する場合、バイナリログレプリケーションを利用して、Amazon Aurora MySQL を MySQL データベースインスタンスのレプリカとして構成することで、ダウンタイムを最小限に抑えた移行を行うことができます。詳しくは、Amazon Aurora MySQL DBクラスタへのデータ移行を参照してください
Amazon RDS Blue/Green デプロイメントでは、論理的なバイナリログレプリケーションを使用して、メジャーバージョンアップグレードなどの本番システムへの変更を最小限のダウンタイムで行う
Amazon Aurora zero-ETL integration with Amazon Redshift、またはMaxwellやDebeziumなどのツールを使用して、Aurora MySQLデータベースクラスタからキャッシュ、データウェアハウス、データレイクなどの他のソースにデータベースの変更をストリーミングする
Spirit や gh-ost などのオンラインスキーマ変更ツールを使用すると、アプリケーションへの影響を最小限に抑えながら、本番システムにスキーマ変更をデプロイする

バイナリログ機能の向上

Amazon Aurora MySQLチームは、長年にわたるお客様の使用事例とフィードバックに基づき、追加のコミュニティ機能のサポートを通じてバイナリログ機能を追加し、スケーラビリティの高い分散Auroraストレージを活用して Amazon Aurora MySQL におけるバイナリロギングの実装を最適化してきました。以下の各リリースでは、4つの主要な領域でバイナリロギングの効率とパフォーマンスを改善するために様々な変更が行われています。

Binary log replication consumer threads

Amazon Aurora MySQL バージョン 2.10 で、binary log I/O cache を導入しました。binary log I/O cache は、書き込みDBインスタンス上の循環キャッシュ内に最新のバイナリログ変更イベントを保持することで、Aurora ストレージレイヤからの読み取り I/O を最小限に抑えることを目的としています。この I/O 待ち時間の改善により、レプリケーションコンシューマスレッドが変更ログイベントを取得する速度が向上し、特に高い同時実行書き込みワークロード下で、フォアグラウンドトランザクションとバイナリログコンシューマがアクティブなバイナリログファイルのロックを競合する可能性を低減します。これらの改善の詳細については、Introducing binlog I/O cache in Amazon Aurora MySQL to improve binlog performance を参照してください。

前述したように、バイナリログの一般的なユースケースの1つは、Aurora MySQL データベースクラスタからデータウェアハウスなどの他のソースにデータベースの変更をストリーミングすることです。Amazon Aurora MySQL バージョン 3.05 では、Amazon Aurora zero-ETL integration with Amazon Redshift をリリースしました。この機能により、ペタバイト単位の transactional データに対して Amazon Redshift を使用したリアルタイムアナリティクスとマシンラーニング (ML) が可能になります。トランザクションデータが Aurora に書き込まれてから数秒以内に、そのデータを Amazon Redshift で利用可能にし、抽出、変換、ロード (ETL) 操作を実行する複雑なデータパイプラインを構築およびメンテナンスする必要がなくなります。Amazon Aurora zero-ETL integration with Amazon Redshift を使用すると、Maxwell や Debezium などのツールを使用して変更データキャプチャインフラストラクチャをセットアップおよび構成する必要がありません。Amazon Aurora MySQL が自動的に変更データキャプチャインフラストラクチャをセットアップ、構成、管理し、変更をAuroraストレージレイヤから直接Amazon Redshiftデータウェアハウスにストリーミングします。

Binary log replication applier threads

Amazon Aurora MySQLバージョン3.05では、Amazon Aurora MySQLのバイナリログレプリカにインメモリリレーログキャッシュを導入しました。この改善により、リレーログキャッシュを有効にしていないデータベースクラスタと比較して、バイナリログレプリケーションのスループットが最大40%向上します。この機能強化は、シングルスレッドのバイナリログレプリケーションを使用する場合、または GTID auto-positioning を有効にしてマルチスレッドレプリケーションを使用する場合に自動的に有効になります。

Amazon Aurora MySQL バージョン 3.06 以降では、2 つ以上のセカンダリインデックスを持つ大きなテーブルのトランザクションをレプリケートする際に、バイナリログレプリケーションのパフォーマンスを向上させる最適化を導入しました。この機能は、Aurora MySQL バイナリログレプリカでセカンダリインデックスの変更を並列に適用するバックグラウンドスレッドのプールを導入し、レプリケーションアプライヤスレッドですでに利用可能な replica_parallel_workers を補足します。この最適化に関する詳細については、バイナリログレプリケーションの最適化を参照してください。

DML throughput and latency

バイナリログのコミットプロセスを最適化するために、MySQL はバイナリロググループコミットなど、イベントの順序に影響を与えず、より効率的にバイナリログに変更を書き込むための最適化を多数実装しています。しかし、この同期ポイントは、高い書き込みスループット作業負荷を持つDBインスタンスに競合領域をもたらす可能性があります。

Amazon Aurora MySQL バージョン3.03.1では、Amazon Aurora MySQL enhanced binary log (拡張バイナリログ)を導入しました。Amazon Aurora MySQLの拡張バイナリログは、バイナリログの変更イベントの順序をAuroraストレージレイヤにオフロードすることで、コミット順序やコミットされたトランザクションの耐久性を犠牲にすることなく、データベースエンジンがAurora分散ストレージをフルに活用してこの競合を減らすことを可能にします。Amazon Aurora MySQL拡張バイナリログ(binlog)の紹介で概説したテストに基づくと、これらの最適化は、拡張バイナリログを有効にしていないデータベースクラスタと比較して、高い同時書き込みワークロードで最大40%のスループット向上をもたらしました。

Binary log recovery

トランザクションをコミットするとき、バイナリログイベントは、アクティブなバイナリログファイルに正しい順序で書き込まれ、永続化されなければなりません。大量のバイナリログデータを生成するトランザクションの場合、起動時のバイナリログリカバリプロセスでは、トランザクションに関するメタデータを収集するために全バイナリログファイルをスキャンし、これを使ってストレージエンジン(InnoDB)データとの整合性を確保する必要があります。バイナリログファイルのサイズが大きい場合、このプロセスに数分以上かかる可能性があり、バイナリログリカバリ時間に比例して影響を与えます。

上記の Amazon Aurora MySQL 拡張バイナリログは、MySQL バイナリログリカバリプロセスのリカバリ時間も改善します。拡張バイナリログでは、Aurora 分散ストレージレイヤの最適化により、時間のかかるバイナリログファイルのスキャンを避けることができます。

これらの改善により、バイナリログリカバリ時間を最大 99% 短縮でき、数分かかっていたものが数秒で完了するようになります。以下の表に、リカバリ時間をまとめています。

Transaction size	Binlog Recovery Time (Seconds)			Total Engine Recovery Time (Seconds)
Transaction size	Community Binlog	Enhanced Binlog	Percent Improvement	Community Binlog	Enhanced Binlog	Percent Improvement
1 GB	303.42	0.47	99.85%	332	26	92.17%
5 GB	1,296.39	0.50	99.96%	1318	34	97.42%
50 GB	15,879.49	0.61	100%	15904	21	99.87%

詳細については、Amazon Aurora MySQL enhanced binary log (binlog) を参照してください。

Additional MySQL support

これまで説明してきたAmazon Aurora MySQL の最適化に加えて、バージョン1と2ですでに利用可能だった機能に加えて、MySQL コミュニティの機能のネイティブサポートが追加されました。

Amazon Aurora MySQL バージョン3.01.0では、バイナリログレプリケーションフィルタのサポートを追加しました。レプリケーションフィルタを使用すると、バイナリログファイルに書き込まれる内容とレプリカに適用される内容を設定できます。この機能は、特定のテーブルやデータベースをレプリカDBインスタンスにのみレプリケートするなどの使用例で役立ちます。レプリケーションフィルターの詳細については、Aurora MySQL でレプリケーションフィルタを構成するをご覧ください。

MySQL 8では dynamic privileges が追加され、SESSION_VARIABLES_ADMIN データベース特権の下で、一部の制限されたセッション変数が利用可能になりました。Amazon Aurora MySQL バージョン3では、この特権を持つユーザは以下のことがセッションレベルで可能になります。

sql_log_binを変更できるようになりました。これは、バイナリログに記録したくない操作、例えばアーカイブジョブやバイナリログ消費者に複製したくないDDL文を実行する場合に便利です。Amazon Aurora MySQL バージョン2ではネイティブで sql_log_bin を設定できませんでしたが、バージョン2.12で mysql.rds_disable_session_binlog mysql.rds_enable_session_binlog のストアードプロシージャが追加されました
さらに、セッションレベルで binlog_format を変更できるようになりました。バイナリログには ROW、MIXED、STATEMENT の3つの形式があります。ほとんどのユースケースでは、各行の変更イベントをログに記録する ROWベースのロギングが推奨されます。しかし、アーカイブやデータパージ時の一括 UPDATE/DELETE 操作では、ログが肥大化する可能性があります。もう1つの一般的なユースケースは、pt-table-checksum などのオープンソースツールを使用する場合で、これには binlog_format を statement に設定する必要があります。binlog_format を使えば、これらの操作でネイティブにセッションレベルのバイナリログ形式を変更できます。Amazon Aurora MySQL バージョン2ではネイティブでセッションレベルの binlog_format を設定できませんでしたが、バージョン2.12で mysql.rds_set_session_binlog_format のストアドプロシージャが追加されました

Amazon Aurora MySQL バージョン3.04では、mysql.rds_gtid_purged ストアドプロシージャが追加されました。gtid_purged システム変数は、サーバ上のどのバイナリログファイルにも存在しない、サーバ上でコミットされたすべてのトランザクションの GTID で構成される GTID セットです。これは主に、2つの MySQL データベースサーバ間のバイナリログレプリケーションの自動ポジショニングを設定する際に使用され、ユーザがレプリケーションを簡単に設定できるようになります。MySQL の GTID の詳細については、Global Transaction Identifiers を使用したレプリケーションを参照してください。

まとめ

この投稿では、過去数年間にAmazon Aurora MySQLで行われたバイナリロギングの最適化と改善について説明しました。これらの継続的な改善により、変更データを利用する新しいユースケースや、データベースのパフォーマンスとリカバリ時間を改善することができました。

Amazon Aurora MySQLの新しいリリースと機能の詳細については、リリースノートを参照し、RSSフィードを購読してください。

Amazon Aurora MySQL のバイナリロギングの詳細については、Aurora MySQL バイナリロギングの設定を参照してください。

Amazon Aurora MySQL バージョン3へのアップグレードの詳細については、Aurora MySQL バージョン3 および Amazon Aurora MySQL バージョン3へのアップグレードを参照してください。

About the Author

Marc Reilly is a Senior Database engineer on the Amazon Aurora MySQL team.

翻訳は、Principal Database SA, Aurora Product の星野が担当しました。

Amazon Web Services ブログ