Amazon Aurora | High Availability and Replication Flashcards
Can I share an encrypted Aurora snapshot?
High Availability and Replication
Amazon Aurora | Database
Yes, you can share encrypted Aurora snapshots.
How does Amazon Aurora improve my database’s fault tolerance to disk failures?
High Availability and Replication
Amazon Aurora | Database
Amazon Aurora automatically divides your database volume into 10GB segments spread across many disks. Each 10GB chunk of your database volume is replicated six ways, across three Availability Zones. Amazon Aurora is designed to transparently handle the loss of up to two copies of data without affecting database write availability and up to three copies without affecting read availability. Amazon Aurora storage is also self-healing. Data blocks and disks are continuously scanned for errors and repaired automatically.
How does Aurora improve recovery time after a database crash?
High Availability and Replication
Amazon Aurora | Database
Unlike other databases, after a database crash Amazon Aurora does not need to replay the redo log from the last database checkpoint (typically 5 minutes) and confirm that all changes have been applied, before making the database available for operations. This reduces database restart times to less than 60 seconds in most cases. Amazon Aurora moves the buffer cache out of the database process and makes it available immediately at restart time. This prevents you from having to throttle access until the cache is repopulated to avoid brownouts.
What kind of replicas does Aurora support?
High Availability and Replication
Amazon Aurora | Database
Amazon Aurora MySQL and Amazon Aurora PostgreSQL support Amazon Aurora Replicas, which share the same underlying volume as the primary instance. Updates made by the primary are visible to all Amazon Aurora Replicas. With Amazon Aurora MySQL, you can also create MySQL Read Replicas based on MySQL’s binlog-based replication engine. In MySQL Read Replicas, data from your primary instance is replayed on your replica as transactions. For most use cases, including read scaling and high availability, we recommend using Amazon Aurora Replicas.
You have the flexibility to mix and match these two replica types based on your application needs:
Feature Amazon Aurora Replicas MySQL Replicas
Number of replicas Up to 15 Up to 5
Replication type Asynchronous (milliseconds) Asynchronous (seconds)
Performance impact on primary Low High
Act as failover target Yes (no data loss) Yes (potentially minutes of data loss)
Automated failover Yes No
Support for user-defined replication delay No Yes
Support for different data or schema vs. primary No Yes
Can I have cross-region replicas with Amazon Aurora?
High Availability and Replication
Amazon Aurora | Database
Yes, with Aurora MySQL you can setup a cross-region Aurora Replica from the RDS console. The cross-region replication is based on single threaded MySQL binlog replication and the replication lag will be influenced by the change/apply rate and delays in network communication between the specific regions selected. Aurora PostgreSQL does not currently support cross-region replicas.
Can I create Aurora Read Replicas on the cross-region replica cluster?
High Availability and Replication
Amazon Aurora | Database
Yes, you can add Aurora Replicas on the cluster that will share the same underlying storage as the cross-region replica. The cross-region replica acts as the primary on the cluster and the Aurora Replicas on the cluster will typically lag behind the primary by 10s of milliseconds.
Can I failover my application from my current primary to the cross-region replica?
High Availability and Replication
Amazon Aurora | Database
Yes, you can promote your cross-region replica to be the new primary from the RDS console. The promotion process typically takes a few minutes depending on your workload. The cross-region replication will stop once you initiate the promotion process.
Can I prioritize certain replicas as failover targets over others?
High Availability and Replication
Amazon Aurora | Database
Yes. You can assign a promotion priority tier to each instance on your cluster. When the primary instance fails, Amazon RDS will promote the replica with the highest priority to primary. If there is contention between 2 or more replicas in the same priority tier, then Amazon RDS will promote the replica that is the same size as the primary instance. For more information on failover logic, read the Amazon Aurora User Guide.
Can I modify priority tiers for instances after they have been created?
High Availability and Replication
Amazon Aurora | Database
You can modify the priority tier for an instance at any time. Simply modifying priority tiers will not trigger a failover.
Can I prevent certain replicas from being promoted to the primary instance?
High Availability and Replication
Amazon Aurora | Database
You can assign lower priority tiers to replicas that you don’t want promoted to the primary instance. However, if the higher priority replicas on the cluster are unhealthy or unavailable for some reason, then Amazon RDS will promote the lower priority replica.
How can I improve upon the availability of a single Amazon Aurora database?
High Availability and Replication
Amazon Aurora | Database
You can add Amazon Aurora Replicas. Amazon Aurora Replicas share the same underlying storage as the primary instance. Any Amazon Aurora Replica can be promoted to become primary without any data loss and therefore can be used for enhancing fault tolerance in the event of a primary DB Instance failure. To increase database availability, simply create 1 to 15 replicas, in any of 3 AZs, and Amazon RDS will automatically include them in failover primary selection in the event of a database outage.
What happens during failover and how long does it take?
High Availability and Replication
Amazon Aurora | Database
Failover is automatically handled by Amazon Aurora so that your applications can resume database operations as quickly as possible without manual administrative intervention.
If you have an Amazon Aurora Replica, in the same or a different Availability Zone, when failing over, Amazon Aurora flips the canonical name record (CNAME) for your DB Instance to point at the healthy replica, which is in turn is promoted to become the new primary. Start-to-finish, failover typically completes within 30 seconds.
If you do not have an Amazon Aurora Replica (i.e. single instance), Aurora will first attempt to create a new DB Instance in the same Availability Zone as the original instance. If unable to do so, Aurora will attempt to create a new DB Instance in a different Availability Zone. From start to finish, failover typically completes in under 15 minutes.
Your application should retry database connections in the event of connection loss.
If I have a primary database and an Amazon Aurora Replica actively taking read traffic and a failover occurs, what happens?
High Availability and Replication
Amazon Aurora | Database
Amazon RDS will automatically detect a problem with your primary instance and begin routing your read/write traffic to an Amazon Aurora Replica. On average, this failover will complete within 30 seconds. In addition, the read traffic that your Amazon Aurora Replicas were serving will be briefly interrupted.
How far behind the primary will my replicas be?
High Availability and Replication
Amazon Aurora | Database
Since Amazon Aurora Replicas share the same data volume as the primary instance, there is virtually no replication lag. We typically observe lag times in the 10s of milliseconds. For MySQL Read Replicas, the replication lag can grow indefinitely based on change/apply rate as well as delays in network communication. However, under typical conditions, under a minute of replication lag is common.
What is Amazon Aurora Multi-Master?
High Availability and Replication
Amazon Aurora | Database
At re:Invent 2017, we announced the preview for Amazon Aurora Multi-Master, a new feature of the Aurora MySQL-compatible edition that adds the ability to scale out write performance across multiple Availability Zones, allowing applications to direct read/write workloads to multiple instances in a database cluster and operate with higher availability.
