Salesforce, Inc.

Pavilion Data Systems, Inc.

Suhas Dantkale

Venkeepuram R Satish

Raghuraman Govindasamy

Benjamin Busjaeger

James E Mace

Kaushal Mittal

Matthew Woicik

Michael Abebe

Techniques are disclosed that pertain to a database system having a log owner and log tailers. The log owner maintains a transaction log and the log tailers replay the transaction log. A log tailer may receive a set of requests to perform a database transaction that involves a write operation to write a record and a subsequent read operation to read that record. As a part of performing the transaction, the log tailer may issue a request to the log owner to log the write operation in the transaction log and the log tailer may insert the record into a local memory structure of the log tailer. After receiving a response from the log owner that the write operation has been logged, the log tailer may permit the subsequent read operation to access the record from the local memory structure without requesting the record from the log owner.

Mechanisms for accessing database records locally

Techniques are disclosed relating to restarting a database node. A database node may allocate memory segments that include a restart segment for storing data records. The database node may spawn processes to read a log and replay log records of the log to update the restart segment to store data records. The database node may determine to perform a restart operation to transition from a first mode to a second mode. Performing the restart operation may include ceasing reading the log at a stop position and storing, based on the stop position, database state information that enables the processes to resume reading the log from the stop position. The database node may further deallocate the memory segments except for the restart segment and terminate the processes. After performing the restart operation, the database node may spawn the processes, which may resume reading the log based on the database state information.

Database node soft restart

A storage server includes a first controller, a second controller and physical drives. The first controller receives a request to store data in a virtual block address (VBA) of a virtual drive, determines a physical block address (PBA) of a physical drive on which to store the data, and sends to the physical drive a command to store the data at the PBA. The first controller generates a first metadata update for a first metadata table associated with the virtual drive, wherein the first metadata update indicates a mapping of the VBA to the PBA. The first controller generates a second metadata update for a second metadata table that identifies statuses of PBAs, wherein the second metadata update indicates that the PBA is valid. The first controller writes an entry to a cache in a memory, the entry comprising the first metadata update and the second metadata update.

Low latency metadata log

A storage server includes an IO controller, a management controller and physical drives. The IO controller generates multiple metadata updates and writes a cache entry that includes the multiple metadata updates to a first cache in memory of the management controller. The IO controller additionally writes a copy of the cache entry to a second cache in a memory of the IO controller and increments a commit pointer in the first and second caches to indicate that the metadata updates are committed.

Growing community of inventors

Cupertino, CA, United States of America

Suhas Dantkale