I have a big database (~250GB) in Aurora getting lots of inserts. There's only one instance, so I'd like to create a replica for redundancy. While we are doing nightly snapshots, we would prefer a more fault tolerant system, and it appears that using aurora replicas would provide automatic failover.
My question: What exactly happens when I use the console and create a replica? Will a new instance come up and begin pulling data from the master instance? Could that affect database performance? I'm sure that it will take some time before the replica "catches up" and loads the 250GB; how will I know when it's "finished"?
Don't want to have any downtime, so I'm a bit afraid to push the "create replica" button without knowing what it does...
Read replicas are available in Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle, and SQL Server as well as Amazon Aurora.
Replication with Aurora MySQL Each cluster can have up to five read replicas created this way, each in a different Region.
In RDS, Failover to read replica is done manually, which could lead to data loss. You can use Multi-AZ (Standby instance) feature for automatic failover, and to prevent downtime and data loss. In Aurora, Failover to read replica is done automatically to prevent data loss. Failover time is faster on Aurora.
No. Amazon Aurora's replication is bundled into the price. You are charged based on the storage your database consumes at the database layer, not the storage consumed in Amazon Aurora's virtualized storage layer.
What exactly happens when I use the console and create a replica?
A new instance is started as part of the cluster, and it has access to the master's data -- or, perhaps more precisely, the cluster's data. All Aurora instances are members of a "cluster," even if it's only a cluster of one master server. Aurora replication, within the same region, is starkly different than MySQL native replication.
Will a new instance come up and begin pulling data from the master instance?
Not really. As described above, the new instance will come up and be able to read from the master's backing store -- it doesn't have its own separate storage.
Aurora runs on 3 sets of 2 copies of the working data, mirrored and replicated across the availability zones in the region. This logical entity is called the Cluster Volume.
The cluster volume spans multiple Availability Zones in a single region, and each Availability Zone contains a copy of the cluster volume data.
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Managing.html
(The docs say each AZ contains "a copy," which is true, but it's mirrored.)
Aurora replicas read from this data -- for all practical purposes, synchronously.
Q: How far behind the primary will my replicas to be?
Since Amazon Aurora Replicas share the same data volume as the primary, there is virtually no replication lag. We typically observe lag times in the 10s of milliseconds.
— https://aws.amazon.com/rds/aurora/faqs/
Could that affect database performance?
It shouldn't.
I'm sure that it will take some time before the replica "catches up" and loads the 250GB; how will I know when it's "finished"?
No, it really shouldn't. Once the replica instance becomes accessible, it should be up-to-date, because it's reading the same data from the same place that the master is writing. Metrics related to Aurora replica lag are accessible in the console.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With