Amazon Technologies, Inc.

Alexander Richard Keyes

Somasundaram Perianayagam

Akshat Vig

James Christopher Sorenson

Vaibhav Jain

Rishabh Jain

Stefano Stefani

Amit Gupta

Sharatkumar Nagesh Kuppahally

Douglas Brian Terry

Oren Yossef

Arijit Choudhury

Nathan Pellegrom Riley

Mark Roper

Akanksha Fouzdar

Tate Andrew Certain

Tony Petrossian

Sudhir Konduru

Anshul Gupta

Shitanshu Aggarwal

Wei Xiao

Rajaprabhu Thiruchi Loganathan

Adam Douglas Morley

Ming-Chuan Wu

Ravi Math

Hao He

Chase Kernan

Lokendra Singh Panwar

Sanjay Shanthakumar

Joon Ahn

Arturo Hinojosa

Wen Han Albert Huang

Jin Kyoung Kwon

Dharmik Dipakbhai Ghoghari

Debjyoti Roy

Yang Nan

Krishnan Seshadrinathan

A database table may be synchronously replicated across regions of a provider network. When a write request to an item of the table is received at one region, a local version of the item may be obtained as well as any additional versions of the item corresponding to inflight writes that target the item from a multi-region replication append-only log. An updated version of the item is then generated based on the local version of the item and the additional versions, which is appended to the multi-region replication append-only log. A conditional write is performed to update the local version of the item with the updated version of the item. If successful, a response indicates that the write request was successful.

Synchronous cross-region replication for a multi-writer database

A geographically distributed data store including a number of geographically distributed regions may be implemented using replication groups that include multiple regions configured according to replication criteria. First tier replication of particular changes to data stored in the distributed data store may be performed in compliance with the replication criteria, where management of replication state is performed with respect to replication across the replication groups. Independent of the first tier replication, individual replication groups may implement second tier replication of changes to data where management of replication state is performed with respect to replication within the particular replication group. Replication group configuration may be determined using the replication criteria which may include thresholds for replication resource utilization, replication latency and utilization of data change logs.

Group replication for highly global workloads

Replicas may be added to a multi-leader replica group for a data set. A new replica may be added to a group of replicas by copying a version of the data set according to a point in time to the new replica. As updates may occur at different ones of the replicas when the new replica is added, updates that occurred at a source replica for the snapshot and other replicas may be replicated by the different replicas according to the point in time at which the snapshot is created without blocking updates at any of the replicas in the replica group.

Adding replicas to a multi-leader replica group for a data set

A request to perform a batch of operations is provided to a distributed database. The request comprises instructions for validating a condition. An association between the request and a unique identifier is stored. An item in the distributed database is locked and the condition is validated. The system that initiates processing of the batch of operations. A second request, comprising the identifier, is received. The second request is responded to by providing information indicative of the status of processing the first request, based on the stored association. The lock is released when processing of the first request has completed.

Idempotent transaction requests

A distributed database maintains a table on a first plurality of partitions. A request to restore the table to a point-in-time is received. The database determines, based on log data of the partitions, a maximum version number of an operation processed by the partitions. The log data is processed to exclude, from the restoration, operations whose transactions were started after the point-in-time, by setting the version number of those operations to be greater than the maximum version number. The log data is then applied to a second plurality of partitions, where the version number of each applied operation is less than or equal to the determined maximum version number.

Transactionally consistent point-in-time restore

A service provider network may provider one or more global cloud services across multiple regions. A client may submit a request to create multiple replicas of a service resource in respective instantiations of a service in the multiple regions. The receiving region of the request may determine the capacities of the multiple regions as to serving respective replicas of the service resource. The receiving region may provide a response to the client based on the determined capacities of the regions.

Capacity management for global resources

Scalable architecture for propagating updates may be implemented for data replicated from a data set. A node may receive updates to items in a data set that have been committed to the data set. The node may determine whether the update should be applied to a replicated portion of the data set. For updates that should be applied, the node may identify another node that hosts the replicated portion of the data set and send a request to the other node to perform a conditional atomic operation to apply the update to the item in the replicated portion of the data set. The condition may compare a version identifier associated with an update and a current version identifier for the item at the other node. If the condition evaluates true, then the update to the item in the replicated portion may be performed.

Scalable architecture for propagating updates to replicated data

Transaction operations may be graphed in order to determine performance compliance of transactions. An event to analyze transactions may be detected. Transactions to analyze for the event may be identified and a description of transaction operations for the identified transactions may be obtained. A graph of the transaction operations may be generated to indicate the dependencies between transactions and an evaluation of the graph may be performed to determine whether the transactions were performed with serializable isolation.

Graphing transaction operations for transaction compliance analysis

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.

Ordering transaction requests in a distributed database according to an independently assigned sequence

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.

Global table management operations for multi-region replicated tables

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.

Streaming committed transaction updates to a data store

Growing community of inventors

Seattle, WA, United States of America

Alexander Richard Keyes