This is the 17th day of my participation in the August Text Challenge.More challenges in August

  • 📢 welcome to like: 👍 collect ⭐ message 📝 if there are mistakes please correct, give people rose, hand left lingering fragrance!
  • 📢 This article was originally written by Webmote and originally published by Nuggets.
  • 📢 author’s motto: life is toss about, when you don’t toss about life, life will start to toss about you, let us come on together! 💪 💪 💪

Preface 🎏

Aurora for mysql, a mysql – and PostgresQL-compatible relational database built for the cloud, offers the performance and availability of a traditional enterprise database with the simplicity and cost-effectiveness of an open source database.

Although there are many descriptions on the AWS website, it still takes a lot of effort to understand it, so the following is recorded to save some time if there is a need for it.

🎏 1. Basic features

This database is built based on the self-developed engine provided by AWS and has the following features:

  • Boasts throughput 5 times faster than MySql
  • Deployed on the cloud, it can scale quickly
  • The storage capacity can be automatically expanded
  • Up to 15 low-latency copies can be built
  • In addition to the classic single-master cluster, there are multiple master cluster and no service out of the box modes available
  • High availability and persistence
  • Global database, remote disaster recovery
  • Snapshots, backtracking, backups, etc
  • Fault tolerance and self-healing

The ads are done. If anyone wants to buy AWS, don’t contact me. There is no discount for contacting me.

🎏 2. Technical analysis

A picture speaks louder than a thousand words.

Aurora architecture has these differences compared to MySQL RDS single master cluster:

  1. Mysql IO needs to perform log, binlog, data, frame file, and double-write operations. These operations need to be written to local storage and synchronized to the replica instance.

  2. Aurora simplifies IO operations by simply writing LOG files to the storage volume, and of course saves a lot of data when synchronizing the master and slave, just applying frame files and logs. Although no Data is written directly, Data is indispensable to db instances, so thread management of parsing from Log to Data is turned on separately in Aurora’s volume portion.

  3. Aurora is also different from MySql in that it uses the six-node protocol for Quorum. Data is written only after four votes have been cast on the storage volume, while three votes have been cast on the read volume, and the data must be read on the same storage node.

The distributed consistency algorithm is adopted to ensure strong read and write consistency of data.

  1. Aurora’s primary read/write node and read-only copy node share the underlying storage volume in three different availability zones to ensure the data live.

5. Aurora’s read-only copy synchronizes data from the master node or neighboring nodes. The copy is directly applied to mysql’s data cache, allowing the copy to quickly update data, and also synchronize data from the storage volume when necessary, depending on its built-in algorithms.

As with most master/slave replicas, there is a delay in synchronizing data between the slave replicas and the master. The delay guarantee of AWS is less than 100ms, and generally stays at about 10ms stably.

Therefore, if the read-write separation scenario is used, high-consistency transactions should only go to the primary node. Less demanding copies can be read – only copies.

🎏 3. I/O write process analysis

  1. Log records received are queued
  2. Write to the update queue store and return ACK. This is a one-node storage analysis. According to the Quorum protocol, if four nodes return an ACK, the write is considered successful.
  3. Organize logging and identifying log blocks
  4. Negotiates reads and writes with storage nodes

5. Expand logs to data page 6. Periodically record logs and page data to S3 7. Periodically reclaim old page data 8. Periodically verify the validity of data

All steps are asynchronous, and the write performance is delayed mainly in Step 1 and Step 2.

🎏 4. Deployment structure

In a single-master DB cluster, the DB store is a separate virtual storage volume, and the DB instance and DB read-only copy are built on top of this, so it is relatively easy to open the instance in seconds because no data replication is required. There is only one instance, which can be extended as needed.

Only the single-master pattern has been introduced here.

🎏 5. Cluster in multi-primary mode

In a multi-primary cluster, all DB instances can be read and written. Currently, a maximum of four DB instances are supported.

Multi-master mode does not allow a single instance to read and write other read-only policies.

When a DB instance becomes unavailable, there is no failover handling because the other DB instances take over the write operations directly.

To distinguish this availability, AWS calls it continuous availability to distinguish the high availability of a single instance.

Multiple primary clusters need to handle write conflicts. You can also enable the multiple primary strong consistency function to reduce the user burden. In this mode, some performance is sacrificed.

🎏 06. Summary

Routine summary, rational view!

Knot is what ah, knot is I want you to praise but can not get lonely. 😳 😳 😳

👓 have seen this, but also care about a thumbs-up?

👓 has been liked, but also care about a collection?

👓 are collected, but also care about a comment?