can anyone elaborate on the difference between AWS Read Replica and readable Standby instances which AWS has offered recently?
I assume you're talking about the Readable Standby Instances available in Preview at the time of writing this.
Compared to the traditional read replicas, the main difference is the kind of replication involved. Replication to read replicas happens asynchronously. That means read replicas aren't necessarily up to date with the main database. This is something your workload needs to be able to deal with if you want to use that.
Readable standby instances on the other hand use synchronous replication. When you read from one of those instances your data will be up to date.
There are also a couple of other differences between the capabilities, but some things aren't finalised yet. The main difference is the kind of replication.
Related
I have just read Google's Cloud SQL's high availability documentation.
From what I understood in order for Google to:
Guarantee no data loss in case of primary node failure.
Allow clients to use standby node as read replica with strong consistency.
Google has to replicate writes in a synchronous way across multiple zones.
This seems like a very costly operation that should affect write transactions' latency. I however personally have not observed any significant latency differences between HA and non-HA version of GCP's Postgres.
How is it possible?
Not a definitive answer, but i hope it helps anyway.
The technology used here is the same that is used for regional persistent disks, which are highly optimized for these kind of multi-zone write scenarios. This basically means that the operation is costly but not as costly as you seem to expect. However even Google itself acknowledges the fact that there will be increased write latency. From a page directly linked from the documentation you shared:
Regional persistent disks are an option when write performance is less critical than data redundancy across multiple zones.
Documentation
You're confusing Read Replicas, HA and Legacy HA.
Cloud SQL some time ago was using Legacy HA which uses an explicit instance that replicates from the primary instance (in some way it is a read replica). In this particular case there could be replication lag because as you mention, the writes are synchronous and the performance could be impacted.
Legacy HA it is only available for MySQL.
In the case of Postgres it is expect you do not see a difference between HA and non-HA because in fact Postgres does not use this Legacy HA and uses the current HA schema which uses a single Regional Disk. non-HA also uses a single disk, the difference is that the disk is Zonal.
In other words, both (HA and non-HA) use a single disk, what changes is the scope of the disk (Regional or Zonal).
Finally since it is only a disk, there's no need to replicate like in a Read Replica or Legacy HA.
I have a 2 instance RDS Aurora cluster (one writer and one reader). Is there any reason my reader instances need to be the same size as the writer?
Is there any problem creating a cluster with a
db.r3.4xlarge (writer) and a
db.r3.2xlarge (reader)?
My writer uses a lot more CPU load than my reader so I want to scale the reader down so it's not just wasting money. It never even uses 1/2 the CPU as the writer. Any issues with this? I looked through the AWS documentation but I can't find any mention of it.
Yes, you can use it, but there can be two potential issues to consider:
Your replica may not keep up with the writer. You already observed that that replicas use much as resources than writer so this shouldn't be a problem.
If writer fails, your replica will become new writer. Thus if your writer must support heavy load, the new writer, on smaller instance, my under-perform.
I am currently assessing whether to use RDS MySQL Multi-AZ or Single AZ with Read Replica.
Considerations are budget and performance, as Multi-AZ cost twice as much as Single AZ and have no ability to offload read operations, Single AZ with Read Replica seems to be a logical choice.
However, I saw a way to manually 'promote' the Read Replica to master in the event of master's failure, but is there a way to automate this?
Note: There was a similar question but it did not address my question:
Read replicas in RDS AWS
I think the problem is that you are a bit confused with these features. Let me help - you can launch AWS RDS in Multi-AZ deployment mode. In this case, AWS will do the following:
It will allocate a DNS record for you. This DNS record represents a single entry point to your master database, which is, lets assume, currently active and able to serve connections.
In the case of master failure for any reason, AWS will simply address hidden by the DNS record (quite fast, within 1-2 minutes) to be pointed to your stand by, which is located on another AZ.
When the master will become available again, then your stand by, which have served writes also needs now to synchronize everything with the master. You do not need to take care about it - AWS will manage it for you
In case of read replica:
AWS will allocate you 2 different DNS records - one for master, another for read replica. Read replica can be on the same AZ as a master, or even in an another Region
You can, and must in you application choose what DNS name to use in different scenarios. I mean, you, most probably, will have 2 different connection pools - one for master, another for read replica. Replication itself will be asynchronous
In the case of read replica, AWS solves the problem of replication by its own - you do not need to worry about it. But since the replica is read only AWS does not solve, by nature, the synchronization problem between read replica and master, because the replica is aimed to be read only, it should not accept any write traffic
Addressing your question directly:
Technically, you can try to make you read replica serve as a failover, but in this case you will have to implement a custom solution for synchronization with the master, because during the time the master was down, your read replica certainly received N amount of writes. AWS does not solve this synchronization problem in this case
In redards to Mutli-AZ - you cannot use your Multi-AZ standby as read replica, since it is not supported in AWS. I highly recommend to check out this documentation. I think it will help you sort the things out, have a nice day!)
I need to scale the Aurora DB up and then back down at later sometime but I dont need any downtime not even a bit. I though of doing it by creating aurora replica and promoting it then scaling primary and promoting back to primary. But this involve downtime. Please suggest any alternative way.
i would first ask you in what sense do you need to scale up? writing? reading? if you currently run a server with a high-read/low-write ratio, i'd suggest another read-replica (or more) and then configure your application specifically to use the read replica in those specific cases where you're only making queries and not modifying the data. in this sense, you're offloading your writes to a separate instance of the same data and letting the primary deal with mostly writes. if you did this, i'd also suggest spreading out the read replicas across other availability zones, in case the AZ of your primary goes down, another read-replica will be auto-promoted to primary.
armed with that info, i would suggest you scale up with read replicas that your application is configured to use, then you can bring down those replicas as you scale down without ever bringing down the Aurora primary. it's more of a configuration problem in dealing with multiple RDS endpoints, essentially.
HTH.
one caveat is that there is some delay in replication between primary and read replicas (my instances show about 10-20 milliseconds), so you have to keep this in mind if you perform a write then a read in fast succession -- if your first read after the initial write happens 'too fast', the replica might not see the change and may either see no data (if you're creating) or stale data (if you're updating).
in general, this isn't an issue until you're under some heavy load and the writes on the primary are backed up and you start reading from the read replica before the writes have been applied to the primary.
HTH.
I am a newbie to amazon RDS. I have set up a db instance in RDS. I want to try the RDS read replicas feature.
I have few queries:
For what kind of applications read replicas are suitable?
Is the read replica replicates synchronously or asynchronously data to other read replicas?
Is it the substitute of the Multi AZ deployments?
How is it better than the master slave or master master replication in MYSQL.
If we have replicas on EC2 will it work the same way as RDS read replicas work
Thanks in advance.
For what kind of applications read replicas are suitable?
It is best suited if your application is
Read intensive and is used by several read clients
Can adopt ( live with ) a minor lag between the data written to db and data replicated to read replicas.
Is the read replica replicates synchronously or asynchronously data to other read replicas?
The replication is asynchronous, so expect a small lag for replication
Is it the substitute of the Multi AZ deployments ?
Multi AZ setup and Read Replica compliment each other; they aren't replacement or substitute for each other. Multi AZ setup is for High Availability ( Out of the Box Setup By AWS ) whereas Read Replica is purely to reduce / distribute the load on the Database Instances to improve the read performance and to avoid bottlenecks to the databases for writes and read. You can / need to write your application logic to divert your reads to Read Replica and Writes to Main Instance; to make the best use of the setup.
Generally people mix and match both Multi AZ and Read Replica(s) depending on the application and load.
How is it better than the master slave or master master replication in MYSQL
The comparison of the master master vs master slave depends on several factors like data, data volume, operation like write or read, load etc. you need to work to see exactly how the system performs with either of the setup.
The best advantage you go with Multi AZ / Read Replica is that, you can offload the DB management activities and overhead of supervising the replica setup and health to AWS; instead of you managing those by yourself.
If we have replicas on EC2 will it work the same way as RDS read replicas work
This is again more like corollary to the Q4. When try to install a database in your EC2 instance you need to take care ( monitor & manage ) - EC2 Instance Patches, Database Instance Patches, Replication Setup, Replication Lag, Availability.
Whereas when you leave that to AWS by using Read Replica they manage all the above for you. It is your call to choose which ever is best for you either depending on the application requires which involves factors like cost, availability, compliance etc.