How can we address the issue of read delays when using a one-primary-multi-standby database architecture?
How do we maintain strong consistency?
Hello and welcome to another episode of Cloud Forward.
Today, we'll show you how we can increase the overall throughput capacity of a cluster to solve the problem of delayed reads from standby nodes.
The read-only node provides eventual read consistency by default in a one-primary-multi-standby database architecture.
Although physical replication and shared storage technologies can significantly reduce the latency of read-only nodes, they cannot guarantee that read requests sent to the read-only nodes get the latest data written on the primary node.
As a result, delayed reading from the read-only nodes can cause inconsistency issues, especially for businesses in industries sensitive to data latency.
Let's take a look at how PolarDB addresses the issue.
Watch the full video here to learn more about PolarDB >>
Cloud Forward Episode 5: Cloud-Native Database - PolarDB | Multi-Primary
Cloud Forward Episode 7: Cloud-Native Database - PolarDB | Transparent Read/Write Splitting
ApsaraDB - August 9, 2022
ApsaraDB - August 10, 2022
Alibaba Cloud Community - December 20, 2022
ApsaraDB - August 10, 2022
ApsaraDB - August 9, 2022
ApsaraDB - August 9, 2022
PolarDB is a cloud-native relational database compatible with MySQL, PostgreSQL, and Oracle.
Learn MoreDesigned to address database challenges such as ultra-high concurrency, massive data storage, and large table performance bottlenecks.
Learn MoreLeverage cloud-native database solutions dedicated for FinTech.
Learn MoreLindorm is an elastic cloud-native database service that supports multiple data models. It is capable of processing various types of data and is compatible with multiple database engine, such as Apache HBase®, Apache Cassandra®, and OpenTSDB.
Learn MoreMore Posts by ApsaraDB