Working with Checkpoints

<< Click to Display Table of Contents >>

Navigation:  Administering SQLstream Blaze >

Working with Checkpoints

Previous pageReturn to chapter overviewNext page

All SQLstream metadata, and all local data stored in tables associated with the SYS_FTRS row store, are stored in an in-memory database.

This data is only saved to a persistent store (a data file) when SQLstream s-Server is shut down gracefully, or when the user explicitly creates a checkpoint as described in User-initiated Checkpoints below.

When SQLstream s-Server is shut down normally, data in the in-memory database is serialized to disk. This is called a checkpoint.

Both creating or restoring checkpoints can only be done when the server is not running. The checkpoint script will give an error message if you try to run it when the server is also running.

Starting or stopping the server normally involves using checkpoints. Before you start it the first time, the server script creates an initial checkpoint. And when you stop the server normally, it creates a checkpoint immediately after the server stops, then restores from that checkpoint when you restart the server.

How are checkpoints saved?

Checkpoints are saved into the $SQLSTREAM_HOME/catalog/checkpoint directory in the form of a data file.

Note: $SQLSTREAM_HOME refers to the installation directory for s-Server, such as /opt/sqlstream/5.1.0.XXX.

Previous checkpoints are compressed into a tarball and moved into the $SQLSTREAM_HOME/catalog/checkpoints.old directory.

What happens if the SQLstream s-Server process is killed or cancelled?

Any changes made to local data and to the metadata will be lost.

Specifying a Checkpoint

You can specify an initial checkpoint in /etc/default/s-Serverd. A checkpoint creates a known good point from which SQLstream s-Server can start applying changes recorded to the log when recovering after a crash or unexpected shutdown. This allows you to have the server start on server bootup in a known state.

To do so, add the following line to /etc/default/s-Serverd:

SQLSTREAM_INITIAL_CHECKPOINT=<checkpoint name>

 

Restarting sserverd from a Checkpoint

To roll back to an old checkpoint when running as a service, copy the desired checkpoint into $SQLSTREAM_HOME/catalog/checkpoint (the default checkpoint) and restart sserverd.

User-initiated Checkpoints

You can manually invoke the checkpointing mechanism.

On an installed system, simulate a clean-exit checkpoint by running

$ checkpoint --create

 

This command creates a tarball backup of the checkpoint directory, and then copies the current catalog to the checkpoint directory. (The checkpoint directory contains the files you need when promoting a SQLstream application from dev to test to production, i.e., the files you would want to move to the target system.)

Working with Named Checkpoints

You can create a named checkpoint to created a named tarball for transfer to the target system. On the source system, enter the following command:

$ checkpoint --createnamed foobar

 

Then transfer that named tarball to the target system, such as by using a command like the following:

$ scp catalog/checkpoints.named/foobar.tgz \

                   target-system:installed-dir/catalog/checkpoints.named

 

Once you have done so, you can restore the entire checkpoint on the target system by using a command along the following lines:

$ checkpoint --restorenamed foobar

 

You can use --deleteNamed <name> to delete a named checkpoint.

You can also use --listNamed to list named repositories.

Note: The checkpoint script is located in $SQLSTREAM_HOME/bin. It relies on a script called defineAspenRuntime.sh. This script also manages the server and various other utilities, and reads the various environment files for the server, the catalog, and other system elements.