Cluster cache management
Caching is one of the most important features of any database (DB) because it helps reduce
the disk I/O. The most frequently accessed data is stored in a memory area called the
buffer cache. When a query runs frequently, it retrieves the data
directly from the cache instead of the disk. This is faster and provides better scalability
and application performance. You configure PostgreSQL cache size by using the
shared_buffers parameter. For more information, see Memory
After a failover, cluster cache management (CCM) in Amazon Aurora PostgreSQL-Compatible Edition is designed to improve application and database recovery performance. In a typical failover situation without CCM, you might see a temporary but significant performance degradation. This occurs because when the failover DB instance starts, the buffer cache is empty. An empty cache is also known as a cold cache. The DB instance must read from the disk, which is slower than reading from the cache.
When you implement CCM, you choose a preferred reader DB instance, and CCM continuously synchronizes its cache memory with that of the primary, or writer, DB instance. If a failover occurs, the preferred reader DB instance is promoted to the new writer DB instance. Because it already has a cache memory, known as a warm cache, this minimizes the impact of the failover on the application performance.
How does cluster cache management work?
Failover DB instances are located in different availability zones from the primary, writer DB instance. The preferred reader DB instance is the priority failover target, which is specified by assigning it the tier-0 priority level.
Note
The promotion tier priority is a value that specifies the order in which an Aurora reader is promoted to the writer DB instance after a failure. Valid values are 0–15, where 0 is the first priority and 15 is the last priority. For more information about the promotion tier, see Fault tolerance for an Aurora DB cluster. Modifying the promotion tier doesn't cause an outage.
CCM synchronizes the cache from the writer DB instance to the preferred reader DB instance. The reader DB instance sends the set of buffer addresses that are currently cached to the writer DB instance as a bloom filter. A bloom filter is a probabilistic, memory-efficient data structure that is used to test whether an element is a member of a set. Using a bloom filter prevents the reader DB instance from sending the same buffer addresses to the writer DB instance repeatedly. When the writer DB instance receives the bloom filter, it compares the blocks in its buffer cache and sends frequently used buffers to the reader DB instance. By default, a buffer is considered frequently used if it has a usage count greater than three.
The following diagram shows how CCM synchronizes the buffer cache of the writer DB instance with the preferred reader DB instance.
For more information about CCM, see Fast
recovery after failover with cluster cache management for Aurora PostgreSQL
(Aurora documentation) and Introduction to Aurora PostgreSQL cluster cache management
Limitations
The CCM feature has the following limitations:
-
The reader DB instance must have the same DB instance class type and size as the writer DB instance, such as
r5.2xlargeordb.r5.xlarge. -
CCM is not supported for Aurora PostgreSQL DB clusters that are part of Aurora global databases.
Use cases for cluster cache management
For some industries, such as retail, banking, and finance, delays of only a few milliseconds can cause application performance issues and result in a significant loss of business. Because CCM helps recover application and database performance by continuously synchronizing the buffer cache of the primary database instance to the preferred backup instance, it can help prevent businesses losses associated with failovers.
