Distributed Database Transaction Replication via Change Notifications

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Databases are challenging to distribute while maintaining ACID properties, leading to costly and complex deployment and maintenance in existing 'shared nothing' and 'shared disk' models, and read replica models suffer from data lag and loss when promoted to primary.

Innovation Solution

Implementing a distributed database system with read-write and read-only nodes, where read-write nodes generate change notifications for read-only nodes to efficiently replicate system transactions, ensuring atomicity and consistency without data lag, and offloading durability operations to a separate storage layer.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a distributed database system is implemented using shared nothing or shared disk models, then fault tolerance and scalability are improved, but deployment cost and system complexity increase

Engineering Contradiction:

Improvefault toleranceVSAvoiddeployment complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The database system is segmented into read-write nodes and read-only nodes, with each node having specialized responsibilities. Read-write nodes handle data modification and generate change notifications, while read-only nodes consume these notifications to maintain synchronized copies. This segmentation allows the system to achieve distributed fault tolerance while keeping individual node complexity manageable.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

Change notifications serve as an intermediary mechanism between read-write nodes and read-only nodes. Instead of direct peer-to-peer communication or complex coordination protocols, the system uses standardized change notifications to transfer data modifications, simplifying the interaction model and reducing overall system complexity.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Productivity

If read replica models are used to scale read processing, then read capacity is improved, but data consistency and completeness deteriorate due to asynchronous replication lag

Engineering Contradiction:

Improveread processing capacityVSAvoiddata consistency

Core Design Contradiction:

ProductivityVSLoss of information

Solution Approach 1:

The system implements continuous change notification streaming from read-write nodes to read-only nodes. Instead of periodic or batch synchronization, change notifications are propagated continuously as they are generated, ensuring that read-only nodes maintain near-real-time synchronized copies of the data, eliminating replication lag and maintaining data consistency.

Inventive Principle:

Principle #20Continuity of useful action

Solution Approach 2:

The system employs a feedback mechanism where read-only nodes monitor the receipt and application of change notifications. This feedback ensures that data consistency is maintained across the distributed system, allowing read scaling without sacrificing data completeness or consistency.

Inventive Principle:

Principle #23Feedback

3Loss of information

If system transactions are replicated to read-only nodes, then data consistency is improved, but network traffic and replication overhead increase

Engineering Contradiction:

Improvedata consistencyVSAvoidnetwork traffic

Core Design Contradiction:

Loss of informationVSLoss of energy

Solution Approach 1:

The system extracts only the essential change notification data from system transactions and transmits only this extracted information to read-only nodes. By taking out only the necessary change information rather than replicating entire transactions or data sets, the system maintains data consistency while minimizing network traffic and replication overhead.

Inventive Principle:

Principle #2Taking out (Extraction)

4Productivity

If read-only nodes operate asynchronously with the primary database, then replication performance is improved, but data loss occurs when promotion to primary is needed

Engineering Contradiction:

Improvereplication performanceVSAvoiddata durability

Core Design Contradiction:

ProductivityVSReliability

Solution Approach 1:

Read-only nodes continuously apply change notifications in advance, maintaining synchronized data copies before any potential promotion scenario occurs. This preliminary action ensures that when a read-only node needs to be promoted to primary, it already has all necessary data changes applied, eliminating data loss and ensuring immediate data durability.

Inventive Principle:

Principle #10Preliminary action

Data Source

PatentUS9280591B1Efficient replication of system transactions for read-only nodes of a distributed database

Publication Date: 2016.03.08 AMAZON TECH INC

AI summary

A distributed database system may efficiently replicate system transactions one or more read-only nodes. An update to a distributed database may be received. One or more system transactions may be performed to apply the update. For each system transaction, one or more change notifications may be generated which indicate changes to be applied in order to perform the system transaction. A particular one of the change notifications may be identified as the last change to be applied in order to complete the system transaction. The change notifications may be sent to one or more read-only nodes. The read-only nodes may process read requests for the distributed database system. The identified change notification may indicate to the read-only nodes the last change to be applied prior to presenting a state of the database that includes the system transaction when servicing read requests.