# Amazon Aurora の信頼性
Aurora は、信頼性、耐久性の高い、および耐障害性を持つように設計されています。Aurora DB クラスターは、Aurora レプリカの追加や複数のアベイラビリティーゾーンへの配置などを行うことで可用性を向上させるように設計できます。さらに Aurora には、信頼できるデータベースソリューションとして使用できるさまざまな自動機能があります。
**Topics**
+ [ストレージの自動修復](#Aurora.Overview.AutoRepair)
+ [存続できるページキャッシュ](#Aurora.Overview.CacheWarming)
+ [計画外の再起動からの復旧](#Aurora.Overview.RestartRecovery)
## ストレージの自動修復
Aurora では、データの複数のコピーを 3 つのアベイラビリティーゾーンに保持するため、ディスク障害によってデータが失われる可能性が最小限に抑えられます。Aurora は、クラスターボリュームを構成するディスクボリュームの障害を自動的に検出します。ディスクボリュームのセグメントで障害が発生すると、Aurora はすぐにそのセグメントを修復します。Aurora はディスクセグメントを修復するときに、クラスターボリュームを構成する他のボリューム内のデータを使用して、修復されるセグメントのデータが最新であるようにします。その結果、Aurora ではデータ損失が回避され、ディスク障害から回復するためのポイントインタイム復元を実行する必要性が低減します。
## 存続できるページキャッシュ
Aurora では、各 DB インスタンスのページキャッシュはデータベースとは別のプロセスで管理されるため、ページキャッシュはデータベースとは無関係に存続できます。(ページキャッシュは Aurora MySQL では InnoDB バッファプール、Aurora PostgreSQL ではバッファキャッシュとも呼ばれます。)
まれにデータベース障害が発生した場合でも、ページキャッシュはメモリに残るため、データベースの起動時に現在のデータページがページキャッシュに「ウォームアップ」されます。これにより、ページキャッシュを「ウォームアップ」するために読み取り I/O 操作を実行するための初期クエリの必要性がバイパスされ、パフォーマンスが向上します。
Aurora MySQL では、再起動およびフェイルオーバー時のページキャッシュの動作は次のとおりです。
+ リーダーインスタンスを再起動せずに、ライターインスタンスを再起動できます。
+ ライターインスタンスの再起動時にリーダーインスタンスが再起動しなくても、ページキャッシュは失われません。
+ ライターインスタンスの再起動時にリーダーインスタンスが再起動した場合、ページキャッシュが失われます。
+ リーダーインスタンスが再起動すると、ライターインスタンスとリーダーインスタンスのページキャッシュが両方とも存続します。
+ DB クラスターがフェイルオーバーした場合、その効果はライターインスタンスが再起動したときと似ています。新しいライターインスタンス（以前のリーダーインスタンス）ではページキャッシュは存続しますが、リーダーインスタンス（以前のライターインスタンス）ではページキャッシュは存続しません。
Aurora PostgreSQL の場合、クラスターキャッシュ管理を使用して、フェイルオーバー後にライターインスタンスになる指定されたリーダーインスタンスのページキャッシュを保持できます。詳細については、「[Aurora PostgreSQL のクラスターキャッシュ管理によるフェイルオーバー後の高速リカバリ](AuroraPostgreSQL.cluster-cache-mgmt.md)」を参照してください。
## 計画外の再起動からの復旧
Aurora は、計画外の再起動からほぼ瞬時に復旧し、バイナリログなしでアプリケーションデータを提供し続けるように設計されています。Aurora は、パラレルスレッドで非同期に復旧します。これにより、計画外の再起動の直後にデータベースを開き、使用できるようにします。
詳細については、[Aurora DB クラスターの耐障害性](Concepts.AuroraHighAvailability.md#Aurora.Managing.FaultTolerance)および[データベースの再起動時間を短縮するための最適化](AuroraMySQL.MySQL80.md#ReducedRestartTime)を参照してください。
以下に示しているのは、Aurora MySQL のバイナリログ記録と計画外の再起動からの復旧に関する考慮事項です。
+ Aurora でバイナリログ記録を有効にすると、計画外の再起動後の復旧時間に直接影響を与えます。これは、DB インスタンスで強制的にバイナリログ復旧が実行されるためです。
+ 使用するバイナリログ記録のタイプは、ログ記録のサイズと効率に影響を与えます。データベースアクティビティの量が同じでも、バイナリログの形式によって記録される情報の量が異なります。`binlog_format` パラメータの以下の設定により、ログデータの量が異なることになります。
+ `ROW` - ログデータの量が最も多い
+ `STATEMENT` - ログデータの量が最も少ない
+ `MIXED` - ログデータの量が中程度。通常、データ整合性とパフォーマンスのバランスが最も良くなります
バイナリログデータの量は復旧時間に影響を与えます。バイナリログに記録されているデータが多いほど、DB インスタンスが復旧中に処理するデータが多くなり、復旧時間が長くなります。
+ バイナリログ記録を使用して計算オーバーヘッドを削減し、復元時間を短縮するために、拡張バイナリログを使用できます。拡張バイナリログにより、データベースの復元時間が最大 99% 向上します。詳細については、「[Aurora MySQL の拡張バイナリログの設定](AuroraMySQL.Enhanced.binlog.md)」を参照してください。
+ Aurora では、DB クラスター内でデータをレプリケートしたり、ポイントインタイムリカバリ (PITR) を実行したりするために、バイナリログは不要です。
+ 外部レプリケーション (または外部バイナリログストリーミング) にバイナリログが不要な場合は、`binlog_format` パラメータを `OFF` に設定して、バイナリログ記録を無効にすることをお勧めします。これにより、復旧時間が短くなります。
Aurora バイナリログ記録とレプリケーションの詳細については、「[Amazon Aurora でのレプリケーション](Aurora.Replication.md)」を参照してください。さまざまな MySQL レプリケーションタイプの影響の詳細については、MySQL ドキュメントの「[ステートメントベースおよび行ベースレプリケーションのメリットとデメリット](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html)」を参照してください。