目標復旧時間（RTO）とは、障害から復旧するために必要な時間のことです。 データベースシステムの高可用性を測定するために使用される主要なメトリックです。 MySQL Community Edition をベースに開発された AliSQL は、クラッシュリカバリプロセスを大幅に最適化し、インスタンスの起動を高速化し、RTO を短縮し、迅速なサービスリカバリを実現します。
最適化の概要
最適化項目 | 最適化されたオブジェクトまたはプロセス | 最適化の効果 |
表領域チェック | 通常のインスタンス起動時間が 73% 短縮されます。ダウンタイムからの復旧時間が 95% 以上短縮されます。起動時のメモリ使用量が 81% 以上削減されます。 | |
並列バッファープール初期化 | バッファープールの初期化時間が 80% 以上短縮されます。 | |
REDO ログのスキャンと適用 | REDO ログの適用時間が 80% 以上短縮されます。 | |
UNDO ログレコード構造 | 100 万レコードの大規模トランザクションのリカバリ時間は約 0 秒で、無視できます。 | |
コミットされていないトランザクションのロールバック | 100 万レコードの大規模トランザクションのロールバック時間は約 0 秒で、無視できます。 | |
破損データのスキャンと特定 | 10 GB の汎用クエリログテーブルのリカバリ時間は約 0 秒で、無視できます。 |
大規模テーブルの起動最適化
表領域チェックは、クラッシュリカバリの基本です。RDS インスタンスに 100 万テーブルなど、多数のテーブルが存在する場合、インスタンスの起動とクラッシュリカバリのプロセスが遅くなり、大量のメモリリソースが占有されます。 AliSQL は、ファイルスキャン、データディクショナリ読み取り、テーブルオブジェクト構築などのコアプロセスを最適化しています。 これにより、多数のテーブルが関係するシナリオでテーブルをスキャンするために必要な時間が大幅に短縮されます。 次の表に、最適化の効果を示します。
シナリオ | MySQL Community Edition（最適化前） | AliSQL（最適化後） | 改善 |
通常の起動時間 | 90.7 秒 | 24.1 秒 | 73% 以上短縮 |
クラッシュリカバリ時間 | 521.7 秒 | 25 秒 | 95% 以上短縮 |
起動時のメモリ使用量 | 高 | 81% 以上削減 | 大幅に最適化 |
有効化する方法
マイナーエンジンバージョン：RDS インスタンスで MySQL 8.0 を実行している場合、マイナーエンジンバージョンは 20240731 以降である必要があります。
主要パラメーター：
loose_fetch_raw_tablespace_at_startup。 このパラメーターはデフォルトで有効になっています。 このパラメーターが有効になっている場合、インスタンスの起動時に必要なメタデータのみがロードされ、冗長な情報のロードは遅延されます。 これにより、メモリ使用量と起動時間が短縮されます。
バッファープールの初期化の高速化
バッファープールは、InnoDB のコアメモリ構造です。 バッファープールを初期化するには、メモリ割り当てと管理構造の構築が必要です。 MySQL Community Edition は、インスタンスレベルでの並列バッファープール初期化をサポートしています。 ただし、ロック構造とグローバル統計の更新には、依然として同時実行性のボトルネックが存在します。 AliSQL は並列バッファープール初期化を最適化し、並列初期化プロセスにおけるボトルネックを解消し、大容量メモリを搭載したインスタンスのバッファープール初期化時間を大幅に短縮します。 次の表に、最適化の効果を示します。
シナリオ | MySQL Community Edition（最適化前） | AliSQL（最適化後） | 改善 |
512 GB のバッファープールの初期化時間 | 19.7 秒 | 3.8 秒 | 80% 以上短縮 |
有効化する方法
マイナーエンジンバージョン：
RDS インスタンスで MySQL 8.0 を実行している場合、マイナーエンジンバージョンは 20220530 以降である必要があります。
RDS インスタンスで MySQL 5.7 を実行している場合、マイナーエンジンバージョンは 20230531 以降である必要があります。
主要パラメーター：
innodb_buffer_pool_init_optimize。 このパラメーターはデフォルトで有効になっています。 このパラメーターが有効になっている場合、システムは自動的に並列バッファープール初期化を最適化し、ロックと同期化のボトルネックを解消します。
REDO ログの並列適用
REDO ログは、データの整合性を確保するための MySQL データベースの先行書き込みログ（WAL）ログです。 REDO ログのスキャンと適用は、クラッシュリカバリ中の重要なステップです。 MySQL Community Edition は、シングルスレッドのスキャンとシリアル化された適用のみをサポートしています。 その結果、4 GB の REDO ログなど、大量の REDO ログをリカバリするには数分かかります。 AliSQL はパイプラインメカニズムを導入して REDO ログのスキャンと適用を並列化し、リカバリ速度を大幅に向上させます。 次の表に、最適化の効果を示します。
シナリオ | MySQL Community Edition（最適化前） | AliSQL（最適化後） | 改善 |
4 GB のアクティブな REDO ログの適用時間 | 118.7 秒 | 22.6 秒 | 80% 以上短縮 |
適用速度 | 基準速度 | 500% 以上向上 | 大幅に改善 |
有効化する方法
マイナーエンジンバージョン：RDS インスタンスで MySQL 8.0 を実行している場合、マイナーエンジンバージョンは 20241231 以降である必要があります。
主要パラメーター：innodb_parallel_redo_threads。 デフォルト値：1。 このパラメーターはデフォルトで無効になっています。
innodb_parallel_redo_threadsパラメーターを 2 より大きい値（例：4）に手動で設定する必要があります。 このパラメーターは、REDO ログの並列適用のスレッド数を指定します。 このパラメーターを設定して、REDO ログのスキャンと適用を高速化できます。
高速トランザクションリカバリ
クラッシュリカバリ中に、REDO ログが適用された後、MySQL は UNDO ログを使用してアクティブなトランザクションのテーブルロックをリカバリする必要があります。 MySQL Community Edition では、すべての UNDO ログレコードを 1 行ずつスキャンして、トランザクションによって管理されているテーブルに関する情報を取得する必要があります。 その結果、数百万レコードのトランザクションなど、大規模トランザクションのリカバリに必要な時間が大幅に増加します。 AliSQL は UNDO ログレコードの構造を拡張して、高速な UNDO ログの特定とスキャンを実装します。 これにより、トランザクションのリカバリ時間が大幅に短縮されます。 次の表に、最適化の効果を示します。
シナリオ | MySQL Community Edition（最適化前） | AliSQL（最適化後） | 改善 |
100 万レコードの大規模トランザクションのリカバリ時間 | 6.8 秒 | 約 0 秒で、無視できます | 完全に最適化 |
有効化する方法
マイナーエンジンバージョン：
RDS インスタンスで MySQL 8.0 を実行している場合、マイナーエンジンバージョンは 20230630 以降である必要があります。
RDS インスタンスで MySQL 5.7 を実行している場合、マイナーエンジンバージョンは 20230831 以降である必要があります。
主要パラメーター：innodb_trx_resurrect_table_lock_accelerate。 デフォルト値：OFF。 このパラメーターはデフォルトで無効になっています。
innodb_trx_resurrect_table_lock_accelerateパラメーターを ON に手動で設定する必要があります。 このパラメーターが有効になっている場合、システムは高速 UNDO ログスキャンメカニズムを有効にして、大規模トランザクションリカバリを高速化します。
非同期トランザクションロールバック
MySQL は内部 XA トランザクションを使用して、バイナリログと InnoDB 間の整合性を確保します。 トランザクションをコミットするために、システムは最初に InnoDB 準備フェーズを実行し、トランザクションを準備済み状態に保ち、準備済みトランザクションをバイナリログに書き込み、トランザクションをコミットします。 クラッシュリカバリ中に、コミットされていないトランザクションのコミットまたはロールバックは、バイナリログによって決定されます。 準備済み状態のトランザクションは、コミットされていないトランザクションと見なされます。 MySQL Community Edition では、コミットされていないトランザクションのロールバックは同期操作です。 これにより、数百万レコードのトランザクションなど、大規模トランザクションのリカバリ時間が大幅に増加します。 AliSQL はコミットされていないトランザクションのロールバックを非同期に変更するため、インスタンスの起動がブロックされず、インスタンスを迅速にリカバリできます。 次の表に、最適化の効果を示します。
シナリオ | MySQL Community Edition（最適化前） | AliSQL（最適化後） | 改善 |
100 万レコードの大規模トランザクションのロールバック時間 | 100 秒 | 約 0 秒で、無視できます | 完全に最適化 |
有効化する方法
マイナーエンジンバージョン：
RDS インスタンスで MySQL 8.0 を実行している場合、マイナーエンジンバージョンは 20220530 以降である必要があります。
RDS インスタンスで MySQL 5.7 を実行している場合、マイナーエンジンバージョンは 20230531 以降である必要があります。
主要パラメーター：
async_binlog_recovery。 このパラメーターはデフォルトで有効になっています。 このパラメーターが有効になっている場合、システムはコミットされていないトランザクションを非同期にロールバックするメカニズムを有効にして、インスタンスの起動を高速化します。
汎用クエリログリカバリの最適化
TABLE モードでは、MySQL 汎用クエリログはユーザー操作を CSV テーブルに記録します。 クラッシュリカバリ中にこのテーブルで破損が検出された場合、MySQL Community Edition は全表スキャンを実行して破損データを特定し、再構築します。 これにより、10 GB などの大規模データボリュームのリカバリ時間が大幅に増加します。 AliSQL は逆スキャンやファイル切り捨てなどの手法を使用して破損したログテーブルを迅速にリカバリし、インスタンスの起動遅延を大幅に短縮し、インスタンスリカバリを高速化します。 次の表に、最適化の効果を示します。
シナリオ | MySQL Community Edition（最適化前） | AliSQL（最適化後） | 改善 |
10 GB の汎用クエリログテーブルのリカバリ時間 | 270 秒 | 約 0 秒で、無視できます | 完全に最適化 |
有効化する方法
マイナーエンジンバージョン：
RDS インスタンスで MySQL 8.0 を実行している場合、マイナーエンジンバージョンは 20241130 以降である必要があります。
RDS インスタンスで MySQL 5.7 を実行している場合、マイナーエンジンバージョンは 20241130 以降である必要があります。
主要パラメーター：
reverse_repair_general_log_on_boot。 このパラメーターはデフォルトで有効になっています。 このパラメーターが有効になっている場合、システムは逆スキャンとファイル切り捨てを有効にして、汎用クエリログテーブルのリカバリを高速化します。
その他の最適化
AliSQL は、二重書き込みバッファー内のデータを確認するプロセスも最適化します。 マイナーエンジンバージョンを最新バージョンに更新することをお勧めします。