Salesforce, Inc.

Salesforce Com, Inc.

Kaushal Mittal

Thomas Fanghaenel

Terry Chong

Rohit Agrawal

Aditya Dharmanand Shetty

Vaibhav Arora

James E Mace

Suhas Dantkale

Jun Chen

Shao-Yuan Ho

Matthew Woicik

Techniques for downgrading of database software. Code areas that may affect downgradability may be delineated with code markers. Changes to these sections can be made to prevent a new database version from being built unless a process is taken to indicate that any new features be designated as available, but not yet allowed for N software releases. This provides a downgrade window of N releases that will support functionality currently allowed by the database. In response to receiving a downgrade request to a target older database software version, that request can be permitted if all the database features are available or allowed in the target version. If at least one of the database features is not available in the target version, the downgrade requested is not permitted. If the request is permitted, the downgrade operation is commenced.

Downgrading database software via a downgradability test

The disclosed techniques reduce a responsiveness time for a secondary node state of a database in switching from a second computing node to replace a first computing node acting in a primary node state, with both computing nodes performing the same database queries. The second node receives information regarding queries performed by the first node while in the primary state. In some embodiments, the second node retrieves, from a transaction log, log records detailing operations performed for database transactions. In some embodiments, the second node inserts, based on the log records, data records of the transactions into an in-memory cache of the second node that stores chains of database records from different transactions. Upon receiving sufficient information to switch to the primary state, the second node changes a mode of operation during failover making a committed transaction available for reads by subsequent database queries prior to record reordering.

Early database transaction visibility

Techniques are disclosed relating to index metadata that is usable for accessing multi-level data structures. A computer system may operate a database, including maintaining a set of records having a set of corresponding keys. The computer system may create multi-level data structures that facilitate key range lookups against those records. A given multi-level data structure may store key information indicative of a subset of the corresponding keys. The computer system may create separate index metadata that is usable for accessing the multi-level data structures. The index metadata may specify indications of key information that is stored in the multi-level data structures and locations of the multi-level data structures. The computer system may perform a key range lookup that includes using the index metadata to determine a particular set of the multi-level data structures whose key information corresponds to a key range of the key range lookup.

Index for multi-level data structures

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

Techniques are disclosed relating to merge operations for multi-level data structures, such as log-structured merge-trees (LSM trees). A computer system may store, in a database, a plurality of files as part of an LSM tree and a plurality of database key structures. A given one of the plurality of database key structures may indicate, for a corresponding one of the plurality of files, a set of key ranges derived from database records that are included in the corresponding file. The computer system may determine, using ones of the plurality of database key structures, a key range overlap that is indicative of an extent of overlap of key ranges from a set of the plurality of files with respect to a particular key range. Based on the determined key range overlap, the computer system may assign a priority level to a merge operation that involves the set of files.

Merges using key range data structures

Techniques are disclosed relating to building an in-memory multi-level data structure useable to determine presence or absence of key ranges in files consisting of database records. In various embodiments, a computer system operates a database, including maintaining a set of records having a set of corresponding keys that are accessible in key-sorted order and generates a multi-level data structure that facilitates key range lookups against the set of records. The generating may include accessing ones of the set of keys in key-sorted order and determining, for a particular accessed key that includes a set of characters, an intermediate level within the multi-level data structure and a subset of the characters of the particular accessed key for insertion. The computer system may insert, starting at the intermediate level, information that identifies the subset of characters, with the inserting being performed without traversing any levels before the intermediate level.

Growing community of inventors

Dublin, CA, United States of America

Kaushal Mittal