Abstract: Technologies are described for facilitating database system recovery in a distributed database environment having a master node and at least one slave node. The master node maintains an in-memory reference that includes transaction identifiers and their corresponding commit identifiers. When a slave node requests that a commit identifier be assigned to a transaction, the transaction and commit identifiers for the transaction are added to the in-memory reference. The commit identifier is sent by the master node to the slave node. The slave node writes a log entry to a commit log that includes the transaction identifier and the assigned commit identifier. If the database system is interrupted before the slave node writes the commit log entry, the slave node can request the commit identifier for the transaction from the master node, which retrieves the identifier from the in-memory reference.

Abstract: A transaction management service layer monitors a plurality of read and write transactions being executed by the data engines by way of client libraries at each of a plurality of data engines. In addition, the transaction management server layer maintains and coordinates transaction timestamp and sequence numbers that are shared by the plurality of data engines. The transaction management service layer identifies and resolves conflicts among the plurality of transactions. The transaction management service layer is a separate and independent service that is isolated from other components of the plurality of data engines. Related apparatus, systems, techniques and articles are also described.

Abstract: Technologies are described for facilitating transaction processing within a database environment having a coordinator node, a first worker node, and at least a second worker node. The coordinator node receives local transaction tokens from the first and the at least a second worker nodes. The coordinator nodes determines a synchronized transaction token using at least the local transaction tokens from the first and the at least a second worker nodes. The coordinator node sends the synchronized transaction token to the first and the at least a second worker nodes.

Abstract: Technologies are described for performing replication of data within a database environment having a source node and a replica node. The source node executes a database operation on at least one database table stored by the source node. The source node asynchronously sends the database operation to the replica node. A prepare commit request is synchronously sent from the source node to the replica node. The source node receives a synchronous precommit acknowledgement from the replica node. The precommit acknowledgement indicates that the database operation was executed at the replica node. The source node commits a transaction associated with the database operation.

Abstract: Technologies are described for facilitating transaction processing within a database environment having a coordinator node, a first worker node, and at least a second worker node. The first worker node sends a request from to the coordinator node for at least a first synchronization token maintained by the coordinator node. The first worker node receives the at least a first synchronization token from the coordinator node. The first worker node assigns the at least a first synchronization token to a snapshot as a snapshot ID value. The snapshot is executed at the first worker node. The first worker node forwards the snapshot ID value to the at least a second worker node.

Abstract: Technologies are described for performing synchronization within a database environment. A source host stores multiple database tables and a replica host stores copies of the multiple database tables. During synchronization, replication log replay is blocked at the replica node, and a multithreaded process locks the multiple database tables of the source hosts, reactivates replication log generation for each of the multiple database tables, and then unlocks the database tables. A synchronization timestamp is acquired and used to synchronize the multiple database tables with the copies of the multiple database tables. After synchronization, replication log replay is reactivated at the replica host for the copies of the multiple database tables.