Abstract: The use of log marking (otherwise known as “coloring”) of sub-portions of a log that records actions (e.g., data operations) performed by a computing system. The log is composed of multiple sub-portions, such as virtual log files, which are successively added to the log as the log grows. For instance, the sub-portions may be virtual log files of the log. The principles described herein change the use of log marking depending on which sub-portion of the log is being marked. If the computing system fails, and recovery is needed, the recovery process can thus deterministically identify where the last written log record is.

Abstract: Use of a log service computing system to apply a log to storage segments in the context of there being a primary compute system that operates upon data, and secondary compute system(s) that are at the ready to be promoted to the new primary compute system should the old primary compute system fail. Rather than have each of the primary and secondary compute systems maintain their own replicated of the entire data locally, the data is separated in storage segments that are collectively distributed amongst multiple storage segment servers.

Abstract: The mounting a drive to two or more computing systems. For instance, the drive may be mounted to a first computing system so as to be writable (and potentially readable) by the first computing system. But also, the drive is also mounted to one or more other computing systems so as to be only readable by those one or more computing systems. This allows for multiple computing systems to have access to the drive without risk that the data thereon will become corrupt. In one embodiment, the only user data stored on that drive is a single file of fixed size. Thus, even when user data is written into the fixed-size file, the management data stored (that keeps track of the files) on the drive does not change.

Abstract: Adaptive adjusting of the growth of a persistent log. The persistent log has a log record generator that adds log records to the persistent log. In addition, there are multiple log consumers that consume records from the persistent log. The log consumers publish log processing parameters with respect to the persistent log. The log processing parameters are then used to determine an appropriate adjustment in the growth of the log, which adjustments may then be executed. As an example, the log processing parameter may be a log consumption progress, in which case the log generator may be caused to slow down the generation of log records, thereby slowing the growth of the log.

Abstract: The mounting a drive to two or more computing systems. For instance, the drive may be mounted to a first computing system so as to be writable (and potentially readable) by the first computing system. But also, the drive is also mounted to one or more other computing systems so as to be only readable by those one or more computing systems. This allows for multiple computing systems to have access to the drive without risk that the data thereon will become corrupt. In one embodiment, the only user data stored on that drive is a single file of fixed size. Thus, even when user data is written into the fixed-size file, the management data stored (that keeps track of the files) on the drive does not change.

Abstract: The bifurcation of a log into a fixed-size log portion and a growable log portion. Log records are first written to the fixed-size log portion. At some point, the older log records within the fixed-size log portion are destaged to the growable log portion. Destaging may involve copying the log records from the fixed-size log portion and tacking the log record onto the end of the growable log portion. This destaging might occur one sub-portion (e.g., one virtual log file) at a time. The more recent log records are within the fixed-size log portion. Accordingly, new writes to the log occur to the fixed-size log portion. Furthermore, a large portion of the reads are of the more recent log records within the fixed-size log portion. Thus, optimizing performance within the fixed-size log portion results in significant improvement in the performance of the overall log.

Abstract: Use of a log service computing system to apply a log to storage segments in the context of there being a primary compute system that operates upon data, and secondary compute system(s) that are at the ready to be promoted to the new primary compute system should the old primary compute system fail. Rather than have each of the primary and secondary compute systems maintain their own replicated of the entire data locally, the data is separated in storage segments that are collectively distributed amongst multiple storage segment servers.

Abstract: The use of log marking (otherwise known as “coloring”) of sub-portions of a log that records actions (e.g., data operations) performed by a computing system. The log is composed of multiple sub-portions, such as virtual log files, which are successively added to the log as the log grows. For instance, the sub-portions may be virtual log files of the log. The principles described herein change the use of log marking depending on which sub-portion of the log is being marked. If the computing system fails, and recovery is needed, the recovery process can thus deterministically identify where the last written log record is.

Abstract: Brokering log records so as to prevent log records that are not yet persisted in a persistent log from being disseminated. The log records may be generated as a primary compute system performs operations. Upon receiving a request for a log record, the broker component determines whether the requested log record has been persisted in a persistent log. If the broker component determines that the log record has been persisted in the persistent log, the broker component responds to the request by causing the requested log record to be provided to the requesting entity (e.g., a secondary compute system). On the other hand, if the log record cannot yet determine that the log record has been persisted in the persistent log, the broker component prevents the log record from being provided to the requesting entity. This prevents data from being inconsistent during recovery.