Skip to content
This repository has been archived by the owner on Jun 12, 2020. It is now read-only.

Checkpoint Lock

RIch Prohaska edited this page Apr 23, 2014 · 8 revisions

Checkpoint Lock

The tokudb_checkpoint_lock session variable provides a mechanism for an application to lock out TokuDB checkpoints. This mechanism can be used to take consistent snapshots of the TokuDB fractal tree files and recovery log files while TokuDB is running. It can be used when (a) copying the TokuDB files of a running MySQL server, or (b) when creating file system snapshots or block device snapshots that store the TokuDB files of a running MySQL server.

Grab the checkpoint lock

set tokudb_checkpoint_lock=1

This operation attempts to locks out TokuDB checkpoints. When this operation returns, TokuDB checkpoints are locked out. If there is a TokuDB checkpoint in progress, this operation will stall until it completes. More than one session can simultaneously lock out TokuDB checkpoints.

Release the checkpoint lock

set tokudb_checkpoint_lock=0

This operation releases the session's checkpoint lock if owned by this session.

Client session disconnect

TokuDB will release the checkpoint lock if it is held by a client session when the client session disconnects.

Long checkpoint lock outs should be avoided

The TokuDB recovery log gets trimmed at the end of a checkpoint. If TokuDB checkpoints are locked out, the TokuDB recovery log can get arbitrarily large. If the MySQL server crashes, then TokuDB recovery will take time proportional to the size of its recovery log.

Implementation

The TokuDB checkpoint safe lock is a fair reader writer lock used to control TokuDB checkpoints. A write lock on the checkpoint safe lock is held for the duration of a checkpoint. A read lock on the checkpoint safe lock prohibits any TokuDB checkpoints from occurring.

Clone this wiki locally