Abstract: Implementations of the present disclosure include providing, at each node in a set of nodes of a database system, a table partition of a plurality of table partitions, the plurality of table partitions being provided by partitioning a table using a primary key, providing, at each node in the set of nodes of the database system, a secondary index partition of a plurality of secondary index partitions, each secondary index partition including a replicate table of at least a portion of the table, the plurality of secondary index partitions being provided by partitioning the table using one or more secondary keys, and for at least one operation executed on a table partition, executing a replication protocol to replicate the at least one operation on a secondary index partition that corresponds to the table partition.

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 data workload capture, workload replay, and comparing the performance of a plurality of database systems. A plurality of requests for database operations are received from one or more database clients. The requests for database operations are executed. For the plurality of requests for database operations, execution context information is generated for a plurality of execution contexts. For the plurality of requests for database operations, a plurality of performance measures are generated. The execution context information and the performance measures are stored in a workload capture store, such as a file. The workload capture file is useable to replay the captured workload at a second database system using at least a portion of the execution context information and at least a portion of the performance measures.

Abstract: RTR of a database transaction to a replica table may include receiving replication and transaction commit log entries (representing a database transaction). The replication log entry has a row-ID value, and the row at the replica table has a row-ID value. The replication log entry may be dispatched to a parallel log replayer and the associated transaction commit log entry to a transaction commit log replayer. The row-ID values may be compared, and the replication log entry is replayed at the parallel log replayer based on the comparison. The database transaction may then be committed to the replica table by replaying the associated transaction commit log entry at the transaction log replayer, wherein the database transaction is associated with row-level parallel replay having transactional consistency and DDL replication and reconstruction of a DDL statement at the replica system is associated with one or multiple metadata update log entries.

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: Innovations in the area of server-side processing when committing transactions to disk in a distributed database system can improve computational efficiency at database nodes and/or reduce network bandwidth utilization. For example, when transactions are committed in a database system, at a master node of the database system, a server uses different threads for certain processor-intensive operations and certain I/O-intensive operations.

Abstract: Innovations in the area of server-side processing when committing transactions to disk in a distributed database system can improve computational efficiency at database nodes and/or reduce network bandwidth utilization. For example, when transactions are committed in a database system, at a master node of the database system, a server uses different threads for certain processor-intensive operations and certain I/O-intensive operations. Or, as another example, when transactions are committed in a database system, at a master node of the database system, a server groups jobs for I/O requests.

Abstract: RTR of a database transaction to a replica table may include receiving replication and transaction commit log entries (representing a database transaction). The replication log entry has a row-ID value, and the row at the replica table has a row-ID value. The replication log entry may be dispatched to a parallel log replayer and the associated transaction commit log entry to a transaction commit log replayer. The row-ID values may be compared, and the replication log entry is replayed at the parallel log replayer based on the comparison. The database transaction may then be committed to the replica table by replaying the associated transaction commit log entry at the transaction log replayer, wherein the database transaction is associated with row-level parallel replay having transactional consistency and DDL replication and reconstruction of a DDL statement at the replica system is associated with one or multiple metadata update log entries.

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.

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 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: Implementations of the present disclosure include providing, at each node in a set of nodes of a database system, a table partition of a plurality of table partitions, the plurality of table partitions being provided by partitioning a table using a primary key, providing, at each node in the set of nodes of the database system, a secondary index partition of a plurality of secondary index partitions, each secondary index partition including a replicate table of at least a portion of the table, the plurality of secondary index partitions being provided by partitioning the table using one or more secondary keys, and for at least one operation executed on a table partition, executing a replication protocol to replicate the at least one operation on a secondary index partition that corresponds to the table partition.

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: Technologies are described for facilitating data workload capture, workload replay, and comparing the performance of a plurality of database systems. A plurality of requests for database operations are received from one or more database clients. The requests for database operations are executed. For the plurality of requests for database operations, execution context information is generated for a plurality of execution contexts. For the plurality of requests for database operations, a plurality of performance measures are generated. The execution context information and the performance measures are stored in a workload capture store, such as a file. The workload capture file is useable to replay the captured workload at a second database system using at least a portion of the execution context information and at least a portion of the performance measures.

Abstract: A computer implemented method is provided for determining a delay between a first database and an associated replicated database by replicating transactions of the first database in the replicated database, determining a delay between the two databases based on a commit timestamp from the first database and a timestamp associated with the commit transaction becoming visible in the replicated database. Then, after a predefined period of time has elapsed since replicating the commit transaction, determining a second delay based on a timestamp associated with a heartbeat log and a replicated database system time. And, selectively determining to execute or deny a statement received by the replicated database based on the second delay. Related apparatus, systems, techniques and articles are also described.

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.