LeanXcale v2.2 User’s Guide

System start depends on how the system has been installed. For bare-metal installations, the administrator installing the system is responsible for adding a system service that brings LeanXcale into operation when the machine starts, and stops LeanXcale before halting the system.

For AWS installations, starting the instance starts the LeanXcale service, and stopping the instance stops LeanXcale before the instance stops.

For Docker installations, starting a container starts the LeanXcale service on it, and, for safety, LeanXcale should be halted before halting the container (otherwise Docker might decide to time-out and stop the container before LeanXcale did fully stop).

To check for license status or to install a new license you can use the lx license command.

For a local installation, use just

For docker installs, each container must include its own license. The DB in the container does not start the DB unless a valid license is found. But, the container must be running to check the license status and to install new licenses. Refer to the section on starting docker containers for help on that.

For example, to list the license status for the container lx1 we can run

To install a new license, just copy the license file to the container as shown here

The license status should be ok now:

You can run the kvlicense file to generate a license file:

This binary is not built by default and is not included in the distribution Ask for help if you need it.

When using replication, you can start one of the replicas (1 or 2):

This addressing scheme can be used in many other commands. See the reference for the lx command later in this document for a full description of addressing.

The lxmeta component watches the status for other components and will stop the system when there is a failure that cannot be recovered online.

Should the system crash or fail-stop, upon a system restart, lxmeta will guide the system recovery.

At start time, each system component checks out its on-disk information and decides to start either as a ready component or as a component needing recovery.

The lxmeta process, guides the whole system start process following these steps:

The command lx status can be used both to inspect the system status and the recovering process, or to wait until the recovery process finishes and the system becomes available for queries.

To use the database with the standard SQL client, you can use this command supplying the user name and secret:

It is suggested not to give the password in the command line, but to open the connection later within the sql prompt, to prevent listing the password in the process list for the underlying password. This was just an example.

The isolation model can be set using the -M argument, as in:

LeanXcale isolation levels are (from strongest to weakest):

Communication between the SQL client and the query engine(s) is not encrypted by default. Install using the tls property to ask for encrypted communications.

The lx sql command does this on its own, but, when using a connection URL on a standard JDBC client, add the

property to the connection property set. This tells the leanXcale client driver to use TLS.

The lx config command prints or updates the configuration used for the LeanXcale system:

The configuration printed provides more details than the configuration file (or command line arguments) used to install.

NB: when installing into AWS or docker, the configuration printed might lack the initial aws or docker property used to install it.

It is possible to ask for particular config entries, like done here:

It is also possible to adjust configured values, like in

used to adjust the lxqe mem property to be 500m in all lxqe components configured.

Logs are kept on a per-system directory, named log, kept at the install directory for each system.

Log files have names similar to

Here, the component name comes first, and then, the date and time when the log file was created. When a log file becomes too big, a new one is started for the given component.

It is convenient to use the lx logs command to list and inspect logs. It takes care of reaching the involved log files on the involved hosts.

For example, to list all log files:

Here, atlantis was the only system installed.

We can give host and/or component names as in many other commands to focus on those systems and/or components.

For example, to just just logs for kvms processes:

Or, to list only those for the kvms100:

To list logs for the atlantis host:

To list logs for kvms components within atlantis:

To list logs for kvms components at atlantis and kvds at orion:

With flag -p, logs are printed in the output instead of being listed.

Flag -g greps the logs for lines with the given expression. For example:

And, flag -c copies the logs to the given directory

When printing and copying the logs, only the last log file for each component are used. To operate on all the logs and not just on the last one, use flag -a too:

Backups can be made to a external location (recommended to tolerate disk failures) or within an installed host. External backups (i.e., to an external location) are made using the lxbackup tool, installed at the bin directory, which works with a given configuration file. Internal backups (i.e., to a directory on installed hosts) are made using the lx backup command.

Using lxbackup is exactly like using lx backup with a few differences:

By default, internal backups (lx backup), the backup is $LXDIR/dump at the host used to issue backup commands. The convention is to use the first host to keep backups.

The lxbackup command can be found at the installed $LXDIR/bin directory on any installed host. If you are not sure regarding the $LXDIR value, use this command to find it:

Flag -d for lx makes it change to the $LXDIR directory before running the given command.

The detailed configuration file to be used with lxbackup is created at lxinst.conf when installing. The configuration can be retrieved also by the lx config command. For example:

On external backups, the backup directory is ./dump unless otherwise specified to the backup command.

This directory can be a mount point or a link to a remote directory to keep backups at a different machine.

Directories under dump/ are named using the date, with .1, .2, etc. appended if more than one backup is created on the same date. If the backup is incremental, a final + is added to the directory name.

For example, create a full, cold, backup on the installed system (e.g., atlantis) when leanXcale is not running:

The printed path is the path for the directory keeping the backup, as used when restoring it.

This backup is not encrypted and is not compressed. Flag -z gzips backed up files, and flag -C also encrypts them. These flags are also used when restoring a backup.

For example, this behaves like the previous example, but encrypts and compresses the backup

To setup the external host orion for backups, copy the backup program and save and copy the installed configuration:

And then, to create a full, ecnrypted, cold, backup on orion:

In the examples that follow, orion is used as the external backup host.

An important note is that file modification times are preserved in backup files. They are used to learn if a file must be copied or not in an incremental backup. If a backup is relocated to a different place, and later copied back into the standard location, preserve file modification times in the process.

Using flag -z makes the tool gzip backup files, preserving modification times despite compression.

To add more hosts to a existing install, edit the configuration file to add the extra hosts. The command:

can print the configuration if it is no longer available.

Once the new host(s) are added, run the install program to update the new hosts (and install them):

And finally, start the DB on the new host(s). For example, if we added a host named blade123, we can run:

To report an issue, use lx report to gather system information. This program collects information from the system and builds an archive to be sent to support.

As printed by the command output, the resulting tar file should be sent to support.

The archive includes:

When kvms is still running, the archive includes also: