Abstract: Technologies are described for performing replication within a database environment. Where a database transaction is replicated at multiple replica nodes, a replica node is selected as a coordinator replica node for the transaction. The other replica node or nodes are designated as follower replica nodes for the transaction. A follower replica node sends the coordinator replica node a precommit notification when the follower replica node has precommitted the transaction. The coordinator replica node sends the follower replica node a postcommit notification to commit the transaction when the transaction has been precommitted by all of the replica nodes to which the transaction is to be replicated.

Abstract: Disclosed herein are system, method, and computer readable device embodiments for parallel replication of databases across row-store and column-store table formats. An embodiment operates by maintaining a replication log and a storage-level recovery log formatted according to separate respective log formats, logging a record-level SQL execution result, and replicating at least one database table from a primary server to at least one replica server. The primary server and the at least one replica server may each be configured to store data according to one table format of a row-store table format and a column-store table format, such that the primary server's table format is different from the at least one replica server's table format.

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: 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 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: 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: 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: Technologies are described for facilitating replay of requests for database operations. A plurality of requests for database operations are received. Each of the plurality of requests includes a type, an access unit identifier, and a chronological identifier. Execution dependencies are determined between the plurality of requests based on the type, access unit identifier, and chronological identifier of each of the plurality of requests. The execution dependencies are stored.

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: An oldest version timestamp is received from a first database. A current commit timestamp is received from a second database configured to asynchronously replicate the first database. The current global commit timestamp corresponds to a commit transaction executed in the first database and subsequently replicated in the second database. A first test query is then issued to the second database including a request for a current timestamp of the second database. A second test query is issued to the primary database requesting records associated with a target update version that has a target timestamp equal to the current snapshot timestamp. A determination is then made that a first return associated with the first test query and a second return associated with the second test query are identical indicating a successful validation. Related apparatus, systems, techniques and articles are also described.

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: 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: Disclosed herein are system, method, and computer readable device embodiments for parallel replication of databases across row-store and column-store table formats. An embodiment operates by maintaining a replication log and a storage-level recovery log formatted according to separate respective log formats, logging a record-level SQL execution result, and replicating at least one database table from a primary server to at least one replica server. The primary server and the at least one replica server may each be configured to store data according to one table format of a row-store table format and a column-store table format, such that the primary server's table format is different from the at least one replica server's table format.

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: 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: Disclosed herein are system, method, and computer program product embodiments for utilizing a transaction control block for providing reader-writer access to transaction commit status. An embodiment operates by receiving a row read request and determining that the row is versioned. The system determines that a first timestamp information for a row destroy transaction associated with the row exists in a transaction control block and retrieves the first timestamp information from the transaction control block.