Provides infrastructure layer compute capabilities, including both bare metal and virtual servers with various optimizations includins compute, memory, IO, and disk. Also supports accelerations options such as GPUs, FPGAs, Inferentia and Trainium.
Provides image recognition capability for images (in batch or real-time) and video that provides a analysis of the content such as real-world objects, faces, celebrities, and path mapping.
Provides a publish/subscribe notification service with multiple subscription types including Amazon Simple Queue Service (SQS), Amazon Kinesis Data Firehose, AWS Lambda, generic HTTPS endpoints, SMS and email.
A serverless, fully-managed, message queue service that supports producing, store, and consuming messages and enables loose coupling between applications.
Provides private networking capability spanning multiple availability zones and supporting subnets, routing, network access control groups, security groups and gateways.
Provides tracing of service invocations in distributed applications for observability, allowing users to diagnose issues or optimize their service interactions.
All about Cloud, mostly about Amazon Web Services (AWS)
Amazon Aurora: Global Database vs Multi-Master
2020-07-19 / 648 words / 4 minutes
To some, the terms “Global Database” and “Multi-Master” could be a little confusing. Is a “global database” also “multi-master”? Could a “multi-master” database be a global database? Amazon Aurora for Amazon RDS offers both options. Are they actually the same thing? If not, how are they different? This post explains Amazon Aurora: Global Databases vs Multi-Master.
Global Database
Amazon Aurora for Amazon RDS Global Database bears a striking similarity to cross-region RDS Read Replicas. Where RDS gives you a master and up-to 5 read replicas that can sit in other AWS regions, Global Database gives you a primary cluster and up-to 5 secondary clusters. Where RDS allows read-replicas to read from other read-replicas, Global Database allows 16 Aurora Replicas as part of the secondary cluster. Both allow the replicas to be promoted to master.
There are some subtle differences though. With RDS, a read-replica is created in another region. With Aurora Global Database, the emphasis is much more on region, so a region is added to the Global Database.
In both cases through, there is still one single point that client applications can write to, which is the primary instance in the case of RDS, or the primary instance in the primary cluster in the case of Aurora.
The impact of this is that if that primary instance fails, it takes the time required to detect that failure and then then time for another instance to be promoted from replica to primary to recover from that failure. While this may be less than a minute for RDS databases, and much faster for Aurora, for a high volume, write-intensive transaction processing system this may be too great of an impact.
Aurora Global Database is an single master database.
Multi-Master
Multi-master quite simply provides multiple database instances which all accept write operations. In fact, every instance in the cluster is a master. There is no need to promote a read replica in the event of a failure, the remaining masters can handle writes while a new master is started. Whereas Aurora Global Database deployments are highly available, Multi-Master deployments are continuously available.
There is nothing in RDS which provides the same capabilities. Probably the best example of a multi-master database is Oracle RAC.
Multi-master isn’t always the right solution though. If the same data blocks are written to by multiple masters at the same time, the write fails. For this reason, it’s best if multi-master is used with segmented workloads where each master can support a segment of the workload. For example, if a company supports a northeast, southeast and mid-Atlantic regions, it could dedicate a master to each region to avoid conflicts, but allow applications to instantly switch masters in the event of a failure.
Unfortunately, MySQL is the only supported engine for Aurora Multi-Master at this time. It isn’t available for Postgres.
Similarities
For any distributed system it takes time for changes to propagate around the system. For Aurora Global Database, when writes occur at the master the changes must be replicated to the secondary clusters in different AWS regions. For Aurora Multi-Master, changes need to propagate around the cluster. This is much faster, but both a susceptible to read-after-write issues. These occur when a write occurs and the same data is immediately read. The data read could be stale if it is read from a different instance (or cluster).
This problem is worse with global databases than with multi-master due to the latency involved in long distance replication, but for multi-master it can be avoided altogether by configuring cluster-wide consistency.
Conclusions
Global Databases and Multi-master really are really different! Global Databases are like a hub-and-spoke arrangement where all writes happen at the hub and are replicated out to the spokes. Multi-master is like a mesh where writes can happen anywhere and they are replicated to all other instances. Both are great tools for a solution architects toolbox.
All data and information provided on this site is for informational
purposes only. cloudninja.cloud makes no representations as to accuracy,
completeness, currentness, suitability, or validity of any information
on this site and will not be liable for any errors, omissions, or
delays in this information or any losses, injuries, or damages
arising from its display or use. All information is provided on an
as-is basis.
This is a personal weblog. The opinions expressed here represent my
own and not those of my employer. My opinions may change over time.
