View source for 18372002. CONSENSUS PROTOCOL FOR ASYNCHRONOUS DATABASE TRANSACTION REPLICATION WITH FAST, AUTOMATIC FAILOVER, ZERO DATA LOSS, STRONG CONSISTENCY, FULL SQL SUPPORT AND HORIZONTAL SCALABILITY simplified abstract (Oracle International Corporation)

=CONSENSUS PROTOCOL FOR ASYNCHRONOUS DATABASE TRANSACTION REPLICATION WITH FAST, AUTOMATIC FAILOVER, ZERO DATA LOSS, STRONG CONSISTENCY, FULL SQL SUPPORT AND HORIZONTAL SCALABILITY=


==Organization Name==

[[:Category:Oracle International Corporation|Oracle International Corporation]]


[[Category:Oracle International Corporation]]

==Inventor(s)==

[[:Category:Lik Wong of Palo Alto CA (US)|Lik Wong of Palo Alto CA (US)]][[Category:Lik Wong of Palo Alto CA (US)]]

[[:Category:Leonid Novak of Castro Valley CA (US)|Leonid Novak of Castro Valley CA (US)]][[Category:Leonid Novak of Castro Valley CA (US)]]

[[:Category:Sampanna Salunke of San Carlos CA (US)|Sampanna Salunke of San Carlos CA (US)]][[Category:Sampanna Salunke of San Carlos CA (US)]]

[[:Category:Mark Dilman of Sunnyvale CA (US)|Mark Dilman of Sunnyvale CA (US)]][[Category:Mark Dilman of Sunnyvale CA (US)]]

[[:Category:Wei-Ming Hu of Palo Alto CA (US)|Wei-Ming Hu of Palo Alto CA (US)]][[Category:Wei-Ming Hu of Palo Alto CA (US)]]

==CONSENSUS PROTOCOL FOR ASYNCHRONOUS DATABASE TRANSACTION REPLICATION WITH FAST, AUTOMATIC FAILOVER, ZERO DATA LOSS, STRONG CONSISTENCY, FULL SQL SUPPORT AND HORIZONTAL SCALABILITY - A simplified explanation of the abstract==


This abstract first appeared for US patent application 18372002 titled 'CONSENSUS PROTOCOL FOR ASYNCHRONOUS DATABASE TRANSACTION REPLICATION WITH FAST, AUTOMATIC FAILOVER, ZERO DATA LOSS, STRONG CONSISTENCY, FULL SQL SUPPORT AND HORIZONTAL SCALABILITY

==Simplified Explanation==

The abstract describes a consensus protocol-based replication approach where a leader server asynchronously executes database transactions, replicates change operations asynchronously, and replicates transaction commits synchronously.

* Leader server performs change operations on a copy of the database
* Leader server creates replication log records for each change operation
* Leader server returns a result to the client without waiting for consensus from followers
* Leader server creates commit log records for commits and waits for consensus
* Replication of change operations is done asynchronously
* Replication of transaction commits is done synchronously

== Potential Applications ==
This technology could be applied in distributed databases, cloud computing environments, and systems requiring high availability and fault tolerance.

== Problems Solved ==
1. Ensures consistency and reliability in replicated databases
2. Improves fault tolerance by allowing for asynchronous replication of change operations

== Benefits ==
1. Increased performance by executing transactions asynchronously
2. Enhanced data reliability through synchronous replication of commits

== Potential Commercial Applications ==
Optimized for use in cloud computing platforms for improved scalability and fault tolerance.

== Possible Prior Art ==
One possible prior art could be the use of traditional consensus protocols in distributed systems for replication and fault tolerance.

=== Unanswered Questions ===

=== How does this technology handle network partitions and latency issues? ===
This article does not address how the replication approach handles network partitions and latency issues. It would be important to understand the system's behavior in such scenarios to ensure data consistency and availability.

=== What are the potential security implications of this replication approach? ===
The article does not discuss the security aspects of the replication approach. Understanding how data integrity and confidentiality are maintained in the replication process is crucial for assessing the overall security of the system.


==Original Abstract Submitted==

A consensus protocol-based replication approach is provided. For each change operation performed by a leader server on a copy of the database, the leader server creates a replication log record and returns a result to the client. The leader does not wait for consensus for the change operation from the followers. For a commit, the leader creates a commit log record and waits for consensus. Thus, the leader executes database transactions asynchronously, performs replication of change operations asynchronously, and performs replication of transaction commits synchronously.



[[Category:G06F16/27]]
[[Category:G06F16/22]]
[[Category:G06F16/23]]