Abstract: Transaction requests may be ordered in a distributed database according to an independently assigned sequence. Different distributed system nodes, such as a transaction coordinator and a storage node may independently assign sequence numbers to requests to access a distributed database. A storage node may receive the request from a transaction coordinator with an assigned sequence number and another request to which the storage node may assign a sequence number. The storage node can then order performance of the requests based on the sequence numbers.

Abstract: Changes made to a database table are accumulated, in durable storage, and snapshots of partitions of the table are obtained. For successive snapshots of a partition, the system accesses a previous snapshot, applies changes from the accumulated changes, and stores the updated snapshot to a durable data store. The accumulated changes and the successive partition snapshots are made available to restore the database to any point in time across a continuum between successive snapshots. Although each partition of the table may have a backup snapshot that was generated at a time different from when other partition snapshots were generated, changes from respective change logs may be selectively log-applied to distinct partitions of a table to generate an on-demand backup of the entire table at common point-in-time across partitions. Point-in-time restores of a table may rely upon a similar process to coalesce partition snapshots that are not aligned in time.

Abstract: A data storage service implements encoding techniques for generating compound partition keys, compound clustering keys, or a combination for more flexibility in storing data in a key-value database system. In some aspects a request to store data with multiple partition keys and/or multiple clustering keys may be received. Length information may be added to the partition keys, and the results concatenated together to form a compound partition key used to store the data in the database. Ordering information may be added to the clustering keys, and the results concatenated together to form a compound clustering key, to be used in storing and sorting data in the database. In some cases, the clustering keys may be made a uniform length, such as by padding keys, as necessary, to have a length that is a multiple of an arbitrary number, and then dividing the clustering keys into chunks of that arbitrary number.

Abstract: A system that implements a data storage service may store data for database tables in multiple replicated partitions on respective storage nodes. In response to a request to restore a given table that was backed up in a remote storage system (e.g., key-value durable storage system), the service may create a new table, and may import a copy of each of the partitions of the given table from the remote storage system into the new table. The request to restore the table may specify a modified value for a configuration parameter for the table or for one of its partitions. The service may apply the new configuration parameter value to the table or its partitions during the restore operation. The new configuration parameter value may indicate an increase or decrease in storage capacity or throughput capacity, and its application may automatically trigger a partition split or move operation.

Abstract: Systems and methods are disclosed to implement, in a database system, global table management operations for global tables or objects that are replicated across multiple locations. In embodiments, for a regional replica of a global table, a requested change to a metadata property of the replica (e.g., an attribute data type, a write throughput limit, or a time-to-live setting) is propagated to other replicas of the global table at other locations. In embodiments, before performing the requested management operation, the database system may first verify that the operation can be successfully performed in all locations. In embodiments, the operation may be performed optimistically without verification, and rolled back if it cannot be performed everywhere. In embodiments, to serialize management operations on a global table, the database system may check for other pending management operations via a shared control object, and proceed when any pending operations are finished.

Abstract: Updates performed as part of transaction requests to a data store may be included in a stream of updates. Updates to items in the data store that are included in transactions determined not to be committed to the data store may be excluded from the stream of updates. Records in the stream of updates may include an identifier for the transaction that included the update described by the record. The identifier for the transaction may be used to identify updates to other items in the data store that are included in the same transaction.

Abstract: Systems and methods are provided to implement a database system configured to return the state of a data item upon failure of a condition check on the data item during a conditional write. In embodiments, a write request may specify an indicator to return the item state upon condition failure. The request may specify multiple database operations to execute as a transaction, where failure of a single condition check will cause the entire transaction to fail and an item state causing the failure to be returned. The returned state of the data item may include a selection of the item's attributes specified by the request. Advantageously, these features allow a client to easily obtain the precise cause of a write's failure. Moreover, because the item state is returned only when a conditional write fails and only when requested, the response size of most write requests remains unchanged.

Abstract: Systems and methods are disclosed to implement, in a database system, global table management operations for global tables or objects that are replicated across multiple locations. In embodiments, for a regional replica of a global table, a requested change to a metadata property of the replica (e.g., an attribute data type, a write throughput limit, or a time-to-live setting) is propagated to other replicas of the global table at other locations. In embodiments, before performing the requested management operation, the database system may first verify that the operation can be successfully performed in all locations. In embodiments, the operation may be performed optimistically without verification, and rolled back if it cannot be performed everywhere. In embodiments, to serialize management operations on a global table, the database system may check for other pending management operations via a shared control object, and proceed when any pending operations are finished.

Abstract: A system that implements a data storage service may store data for a database table in multiple replicated partitions on respective storage nodes. In response to a request to back up a table, the service may back up individual partitions of the table to a remote storage system independently and (in some cases) in parallel, and may update (or create) and store metadata about the table and its partitions on storage nodes of the data storage service and/or in the remote storage system. Backing up each partition may include exporting it from the database in which the table is stored, packaging and compressing the exported partition for upload, and uploading the exported, packaged, and compressed partition to the remote storage system. The remote storage system may be a key-value durable storage system in which each backed-up partition is accessible using its partition identifier as the key.

Abstract: A system that implements a data storage system may store data for a database table in multiple replicated partitions on respective storage nodes. An export of an active database partition may generate an exported copy of the database partition. A first exported copy may be stored locally on a source node and a second exported copy of the database partition may be sent to a recipient node. The source node may validate the first copy responsive to sending the second copy and may perform the validation while the second copy is being sent and processed at the recipient node. If the first copy cannot be validated, the source node may cause the second copy to be invalidated and abort further processing of the second copy. The source node may also cause the second copy to be marked as invalid to prevent reliance on an invalid database partition copy.

Abstract: A selective data restoration technique is disclosed. A request to recover data in a dataset is received along with an identifier of a particular portion of the data to be recovered. The request may specify a time that indicates a desired recovery state (e.g., recover the values as they were at the time). Change data is determined for the specified time. For example, data stream filters generate recovery data by applying filters (e.g., keys) to a time window batch of the stream data. The stream data may correspond to changes to a data set, and the recovery data may correspond to only a portion of the dataset (e.g., a portion of a table). The system performs a recovery action, based on the recovery data, using the recovery data to automatically restore data in a data store, or providing the recovery date to the requesting entity, for example.

Abstract: In response to determining that a secondary index is to be created for a particular table of a non-relational database service, a service component verifies that automated transmission of change records of the table to a log-structured journal has been configured. A given change record comprises a before-image and an after-image associated with a committed database write, and is assigned a unique sequence number. A change record propagator for the secondary index examines change records stored in the journal, and transmits selected change records to an index storage node. The index storage node builds the secondary index using the selected change records.

Abstract: A system that implements a data storage service may store data for a database table in multiple replicated partitions on respective storage nodes. In response to a request to back up a table, the service may back up individual partitions of the table to a remote storage system independently and (in some cases) in parallel, and may update (or create) and store metadata about the table and its partitions on storage nodes of the data storage service and/or in the remote storage system. Backing up each partition may include exporting it from the database in which the table is stored, packaging and compressing the exported partition for upload, and uploading the exported, packaged, and compressed partition to the remote storage system. The remote storage system may be a key-value durable storage system in which each backed-up partition is accessible using its partition identifier as the key.

Abstract: Information describing changes to a collection of items maintained by a database may be stored in a log file. The information in the log file may be converted into a stream of records describing the changes. The records may be directed to a computing node selected for performing a trigger function in response to the change, based on applying a hash function to a portion of the record, identifying a hash space associated with a value output by the hash function, and mapping from the hash space to the selected computing node.

Abstract: Various systems and methods to efficiently store backups of partitions of a database are disclosed. An indication to take a current snapshot of a partition of the database is received. A log size and operation type statistics are determined for a portion of the change log for the partition. A snapshot type is determined for the partition based at least in part on the log size and the operation type statistics, where the snapshot type specifies a log-based snapshot or a full snapshot. The snapshot is stored as metadata indicating a point in the change log if the determined snapshot type is log-based snapshot or stored as complete data of the partition if the determined snapshot type is full snapshot.

Abstract: Information describing changes to a collection of items maintained by a database may be stored in a log file. The information in the log file may be converted into a stream of records describing the changes. The records may be directed to a computing node selected for performing a trigger function in response to the change, based on applying a hash function to a portion of the record, identifying a hash space associated with a value output by the hash function, and mapping from the hash space to the selected computing node.

Abstract: Methods and apparatus for conditional master election in a distributed database are described. A plurality of replicas of a database object are stored by a distributed database service. Some types of operations corresponding to client requests directed at the database object are to be coordinated by a master replica. Client access to the database object is enabled prior to election of a master replica. In response to a triggering condition, a particular replica is elected master. The master coordinates implementation of operations with one or more other replicas in response to client requests.

Abstract: Disclosed are systems and methods for generating consistent backups. A central coordinator informs each node storing a partition of the time to perform a backup. At the designated time, each node blocks updates for a corresponding time interval measured by its local clock. Each node performs the backup operation according to its own local clock. Consistent backups may be generated in spite of clock skew between the local clocks as long as the time interval is at least as long as a maximum local clock skew (among the nodes performing the backup). In some systems the maximum local clock skew may be reduced, by a round-trip update latency from a client, for example.

Abstract: In response to determining that continuous data protection is to be enabled for a particular table of a database service, a service component verifies that automated transmission of change records of the table to a log-structured journal has been configured. A given change record comprises a before-image and an after-image associated with a committed database write, and is assigned a unique sequence number. In response to a determination to restore the table as of a specified point in time, a restore record set is identified from the journal with respect to a selected snapshot of the table. The restore record set includes change records which are not represented in the snapshot and are to be represented in the restored table. A restore result table is created using the selected snapshot and the restore record set.

Abstract: Transaction requests may be ordered in a distributed database according to an independently assigned sequence. Different distributed system nodes, such as a transaction coordinator and a storage node may independently assign sequence numbers to requests to access a distributed database. A storage node may receive the request from a transaction coordinator with an assigned sequence number and another request to which the storage node may assign a sequence number. The storage node can then order performance of the requests based on the sequence numbers.