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: Lock table management is provided for a lock manager of a database system, in which lock management is provided in a manner that is fast and efficient, and that conserves processing, memory, and other computational resources. For example, the lock table management can use a hashmap in which keys and values are stored in separate arrays, which can be loaded into separate CPU cache lines.

Abstract: Techniques are described for use in database and data management systems to efficiently capture and replicate changes that occur in database tables. The changes are captured in a transaction-consistent order, and in a format that may easily be searched and accessed using common relational queries.

Abstract: Technologies are described for facilitating transaction processing in a distributed database environment. A database client sends database operations to a slave node, which mediates execution of the transaction. A connection between the database client and the slave node is associated with an identifier, and the transaction has an identifier. The database client sends a commit request to a master node over a network connection between the master node and the database client. The commit request includes the transaction identifier. The commit request can also include an indication of database nodes executing operations in the transaction.

Abstract: Lock table management is provided for a lock manager of a database system, in which lock management is provided in a manner that is fast and efficient, and that conserves processing, memory, and other computational resources. For example, the lock table management can use a hashmap in which keys and values are stored in separate arrays, which can be loaded into separate CPU cache lines.

Abstract: Techniques are described for use in database and data management systems to efficiently capture and replicate changes that occur in database tables. The changes are captured in a transaction-consistent order, and in a format that may easily be searched and accessed using common relational queries.

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: Lock table management is provided for a lock manager of a database system, in which lock management is provided in a manner that is fast and efficient, and that conserves processing, memory, and other computational resources. For example, the lock table management can use a hashmap in which keys and values are stored in separate arrays, which can be loaded into separate CPU cache lines.

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: Techniques are described for use in database and data management systems to efficiently capture and replicate changes that occur in database tables. The changes are captured in a transaction-consistent order, and in a format that may easily be searched and accessed using common relational queries.

Abstract: A computer implemented method is provided comprising receiving a group of transaction logs from a first database, allocating transaction logs from the group of transaction logs to a first queue and to a second queue, generating an end-of-group transaction log indicative of an end of the group of transaction logs, allocating the end-of-group log to the first queue and the second queue; replaying transaction logs from the first queue including the end-of-group transaction log allocated to the first queue, replaying transaction logs from the second queue including the end-of-group transaction log allocated to the second queue; and changing visibility of one or more transactions in response to replaying the end-of-group transaction log allocated to the first queue and the end-of-group transaction log allocated to the second queue. Related apparatus, systems, techniques and articles are also described.

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 in a distributed database environment. A database client sends database operations to a slave node, which mediates execution of the transaction. A connection between the database client and the slave node is associated with an identifier, and the transaction has an identifier. The database client sends a commit request to a master node over a network connection between the master node and the database client. The commit request includes the transaction identifier. The commit request can also include an indication of database nodes executing operations in the transaction.

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 provided for reducing or eliminating transaction consistency anomalies that can occur during data replication, such as during database table replication. For example, commit values can be used to coordinate requests so that the requests are not performed on database tables with inconsistent data.

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.

Abstract: Techniques are described for use in database and data management systems to enable a database transaction to read uncommitted data from another database transaction on a selective (e.g., transaction-specific) basis, without requiring a change in the isolation level of either transaction (or related transactions). Accordingly, transaction speeds may be increased, and operations to audit or debug ongoing database transactions are also facilitated.

Abstract: Technologies are described for facilitating the processing of requests for database operations in a distributed database environment. Criteria are defined for processing a request for a database operation according to first or second snapshot isolation protocols. A request for a database operation is received and it is determined if the snapshot isolation protocol criteria are met. If the criteria are met, the request can be processed using a local snapshot identifier value of a worker node. If the criteria are not met, the local snapshot identifier value is synchronized with another node, and the request processed using the updated snapshot identifier value.

Abstract: Technologies are described for facilitating transaction processing in a distributed database environment. A database client sends database operations to a slave node, which mediates execution of the transaction. A connection between the database client and the slave node is associated with an identifier, and the transaction has an identifier. The database client sends a commit request to a master node over a network connection between the master node and the database client. The commit request includes the transaction identifier. The commit request can also include an indication of database nodes executing operations in the transaction.

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.