Abstract: Record-level transaction conflicts may be detected at storage nodes of a database back-end storage service. When a prepare statement is received, a storage node can determine whether another prepare statement acting on at least one of the same records has succeeded. If so, then the storage node can indicate to the database access application that there is a conflict, allowing the database access application to wait to try again or abort the transaction.

Abstract: Scalable garbage collections is performed by a distributed storage system. Garbage collection events are detected by a distributed storage system for different portions of a table. Garbage collection is performed for individual ones of the different portions of the table responsive to detecting the garbage collection events, including identifying one or more versions of a record to reclaim from the different portions of the table based on transaction status information and reclaiming the one or more versions of the record.

Abstract: Rowblock modifications may be performed at record-aware distributed storage systems. Record-aware distributed storage systems may implement a storage service engine that can evaluate access requests to a table and make rowblock modification determinations based on the evaluation. The storage service engine can instruct storage nodes of the record-aware distributed storage system to perform the rowblock modifications.

Abstract: Requests for records are performed at a record-aware distributed storage system. A request at a storage service engine for records received from a database access application has a time value identified corresponding to a state of a table and storage nodes that store the records. Requests are sent to the storage nodes to obtain the records. The storage nodes may identify rowblocks with respective record identifier ranges and time value ranges corresponding to the records and the time value for the access request. A result may be returned to the database access application based on the records received from the storage nodes.

Abstract: Scalable recovery of a database is performed by a distributed data store. Storage nodes can monitor connection status of database access applications that have attached respective portions of a table stored at the storage nodes to provide access to the table. A connection failure of a database access application can be detected. Transactions associated with the failed database access application can be identified and determination of transactions that are not committed made. The storage nodes can remove versions of records of the table associated with the transaction as part of recovering the respective portions of the table from the connection failure of the database access application.

Abstract: A data storage system includes a head node and mass storage devices. The head node is configured to flush data stored in a storage of the head node to a set of the mass storage devices of the data storage system. A head node may flush both current version data and point-in-time version data to the set of mass storage devices. Also, the data storage system maintains an index that indicates storage locations of data for particular portions of a volume before and after the data is flushed to the set of mass storage devices. In some embodiments an index includes a current version reference for a volume or portion of a volume and one or more point-in-time snapshot references.

Abstract: A block-based storage system hosts logical volumes that are implemented via multiple replicas of volume data stored on multiple resource hosts in different failure domains. Also, the block-based storage service allows multiple client computing devices to attach to a same given logical volume at the same time. In order to prevent unnecessary failovers, a primary node storing a primary replica is configured with a health check application programmatic interface (API) and a secondary node storing a secondary replica determines whether or not to initiate a failover based on the health of the primary replica.

Abstract: A block-based storage system hosts logical volumes that are implemented via multiple replicas of volume data stored on multiple resource hosts in different failure domains. Also, the block-based storage service allows multiple client computing devices to attach to a same given logical volume at the same time. In order to prevent unnecessary failovers, a primary node storing a primary replica is configured with a health check application programmatic interface (API) and a secondary node storing a secondary replica determines whether or not to initiate a failover based on the health of the primary replica.

Abstract: A storage service supports attachment of multiple clients to a distributed storage object and further supports persistent reservations that govern types of access the respective clients are granted with respect to the distributed storage object. In order to efficiently distribute reservation state changes to multiple partitions of the distributed storage object hosted by different data storage units/servers, existing connections are used between the data storage units/servers hosting the partitions of the distributed storage object and the connected clients to propagate reservation state changes.

Abstract: A data storage system includes multiple head nodes and data storage sleds. Volume data is replicated between a primary and one or more secondary head nodes for a volume partition and is further flushed to a set of mass storage devices of the data storage sleds. Volume metadata is maintained in a primary and one or more secondary head nodes for a volume partition and is updated in response to volume data being flushed to the data storage sleds. Also, the primary and secondary head nodes store check-points of volume metadata to the data storage sleds, wherein in response to a failure of a primary or secondary head node for a volume partition, a replacement secondary head node for the volume partition recreates a secondary replica for the volume partition based, at least in part, on a stored volume metadata checkpoint.

Abstract: A storage service supports attachment of multiple clients to a distributed storage object and further supports persistent reservations that govern types of access the respective clients are granted with respect to the distributed storage object. In order to efficiently distribute reservation state changes to multiple partitions of the distributed storage object hosted by different data storage units/servers, existing connections are used between the data storage units/servers hosting the partitions of the distributed storage object and the connected clients to propagate reservation state changes.

Abstract: A data storage system includes a head node and mass storage devices. The head node is configured to store volume data and flush volume data to the mass storage devices. Additionally, the head node is configured to determine a quantity of data partitions and/or parity partitions to store for a chunk of volume data being flushed to the mass storage devices in order to satisfy a durability guarantee. For chunks of data for which complete copies are also stored in an additional data storage system, the head node is configured to reduce the quantity of data partitions and/or parity partitions stored such that required storage space is reduced while still ensuring that the durability guarantee is satisfied.

Abstract: A storage service supports attachment of multiple clients to a distributed storage object and further supports persistent reservations that govern types of access the respective clients are granted with respect to the distributed storage object. In order to efficiently distribute reservation state changes to multiple partitions of the distributed storage object hosted by different data storage units/servers, existing connections are used between the data storage units/servers hosting the partitions of the distributed storage object and the connected clients to propagate reservation state changes.

Abstract: A block-based storage system hosts logical volumes that are implemented via multiple replicas of volume data stored on multiple resource hosts in different failure domains. Also, the block-based storage service allows multiple client computing devices to attach to a same given logical volume at the same time. In order to prevent unnecessary failovers, a primary node storing a primary replica is configured with a health check application programmatic interface (API) and a secondary node storing a secondary replica determines whether or not to initiate a failover based on the health of the primary replica.

Abstract: A block-based storage system hosts logical volumes that are implemented via multiple replicas of volume data stored on multiple resource hosts in different failure domains. Also, the block-based storage service allows multiple client computing devices to attach to a same given logical volume at the same time. In order to prevent unnecessary failovers, a primary node storing a primary replica is configured with a health check application programmatic interface (API) and a secondary node storing a secondary replica determines whether or not to initiate a failover based on the health of the primary replica.

Abstract: A data storage system includes multiple head nodes and data storage sleds. A control plane of the data storage system designates, for a volume partition, one of the head nodes to function as a primary head node storing a primary replica of the volume partition and designates two or more other head nodes to function as reserve head nodes storing reserve replicas of the volume partition. Additionally, the primary head node causes volume data for the volume partition to be erasure encoded and stored on multiple mass storage devices in different ones of the data storage sleds.

Abstract: A data storage system includes multiple head nodes and data storage sleds. Volume data is replicated between a primary and one or more secondary head nodes for a volume partition and is further flushed to a set of mass storage devices of the data storage sleds. Volume metadata is maintained in a primary and one or more secondary head nodes for a volume partition and is updated in response to volume data being flushed to the data storage sleds. Also, the primary and secondary head nodes store check-points of volume metadata to the data storage sleds, wherein in response to a failure of a primary or secondary head node for a volume partition, a replacement secondary head node for the volume partition recreates a secondary replica for the volume partition based, at least in part, on a stored volume metadata checkpoint.

Abstract: The present disclosure generally relates to creating virtualized block storage devices whose data is replicated across isolated computing systems to lower risk of data loss even in wide-scale events, such as natural disasters. The virtualized device can include at least two volumes, each of which is implemented in a distinct computing system. In the case of a failed volume, a new volume can be created and populated with data from the surviving volume. During population, new writes can continue to be replicated to the new volume. The population process can write data from the surviving volume to the new volume “under” new writes, such that the population process does not overwrite data included in the new writes.

Abstract: The present disclosure generally relates to creating virtualized block storage devices whose data is replicated across isolated computing systems to lower risk of data loss even in wide-scale events, such as natural disasters. The virtualized device can include at least two volumes, each of which is implemented in a distinct computing system. Each volume can be implemented by at least two computing devices, a first of which is configured as a primary device to which reads from and writes to the volume are directed. To ensure consistency in the distributed device, a multi-tier authority service is implemented, in which a cross-computing system authority service designates a volume as having authority to accept writes to the virtualized device, and in which a second tier authority service designates a computing device as having authority to accept writes to the volume.

Abstract: A data storage system includes multiple head nodes and data storage sleds. Volume data is replicated between a primary and one or more secondary head nodes for a volume partition and is further flushed to a set of mass storage devices of the data storage sleds. Volume metadata is maintained in a primary and one or more secondary head nodes for a volume partition and is updated in response to volume data being flushed to the data storage sleds. Also, the primary and secondary head nodes store check-points of volume metadata to the data storage sleds, wherein in response to a failure of a primary or secondary head node for a volume partition, a replacement secondary head node for the volume partition recreates a secondary replica for the volume partition based, at least in part, on a stored volume metadata checkpoint.