System Administration

Assuming the lx command is at the system PATH, it can be used to operate the installed LeanXcale system. In these examples we use atlantis as the installed host for them.

Command output usually includes information on a per-host basis reporting the progress of the used command.

There are other important commands for system operation not described here. Their description and examples of use can be found later in this document.

Start

The start command starts LeanXcale:

unix$ lx start
start...
atlantis [
    cfgile: /ssd/leandata/xamplelx/lib/lxinst.conf...
    bin/spread -c lib/spread.conf ...
    forked bin/spread...
    bin/spread: started pid 1056053
    bin/kvms -D 192.168.1.224!9999 /ssd/leandata/xamplelx/disk/kvms100/kvmeta ...
    forked bin/kvms...
    ...
]
atlantis [
    kvds103 pid 1056084 alive
    kvms100 pid 1056057 alive
    spread pid 1056053 alive
    kvds102 pid 1056075 alive
    kvds100 pid 1056062 alive
    kvds101 pid 1056066 alive

]
unix$

Here, atlantis started a few processes and, once done, the start command checked out if the processes are indeed alive.

In case not all components can be started successfully, the whole LeanXcale system is halted by the start command.

To start a single host or component, use its name as an argument, like in:

# start the given host
unix$ lx start atlantis
# start the named components
unix$ lx start kvds
# start the named components at the given host
unix$ lx start atlantis kvds

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

unix$ lx start repl1

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.

Start does not wait for the system to be operational. To wait until the system is ready to handle SQL commands, the status command can be used with the -w (wait for status) flag, as in:

unix$ lx status -w running
status: running

Without the -w flag, the command prints the current status, which can be stopped, failed, running, or waiting.

Stop

The stop command halts LeanXcale:

unix$ lx stop
stop...
atlantis [
    kvcon[1056801]: halt
]
atlantis [
    term 1056062 1056066 1056075 1056084 1056057 1056053...
    kill 1056062 1056066 1056075 1056084 1056057 1056053...

]
unix$

SQL Client

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

unix$ lx sql -n lxadmin -p ****
lx% !tables
...

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:

unix$ lx sql -Msession -n lxadmin -p ****
lx% !tables
...

LeanXcale isolation levels are (from strongest to weakest):

  • session_consistency or session: the transaction has as snapshot then one incorporating the changes from the last update transaction in the same session.

  • snapshot_isolation or si: standard snapshot isolation, that is, when the transaction starts gets the current snapshot and all reads are performed over that snapshot.

  • read_committed or rc: each SQL statement gets the current snapshot and reads are performed from that snapshot.

  • raw_read_committed or rawrc: each read performed by an SQL statement get the latest committed value.

  • loader: Special isolation level to accelerate database loads. It is like read committed but it does not perform conflict detection nor logging. This can only be done without any other transactions accessing the database.

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

tls=yes

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

Processes

The procs command reports the running processes for the LeanXcale system:

unix$ lx procs
procs...
atlantis [
    kvds103 pid 1057699 alive running
    kvms100 pid 1057672 alive running
    spread pid 1057668 alive
    kvds102 pid 1057690 alive running
    kvds100 pid 1057677 alive running
    kvds101 pid 1057681 alive running

]

Configuration

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

unix$ lx config
cfgile: /usr/local/leanxcale/lib/lxinst.conf...
#cfgfile /usr/local/leanxcale/lib/lxinst.conf
host localhost
    lxdir /usr/local/leanxcale
    JAVA_HOME /usr/lib/jvm/java-1.11.0-openjdk-amd64
    addr 127.0.0.1
    odata 100
        addr localhost!14004
    kvms 100
        addr 127.0.0.1!14400
    lxmeta 100
        addr 127.0.0.1!16500
    lxqe 100
        addr 127.0.0.1!16000
    kvds 100
        addr 127.0.0.1!15000
    kvds 101
        addr 127.0.0.1!15002
    kvds 102
        addr 127.0.0.1!15004
    kvds 103
        addr 127.0.0.1!15006

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:

unix$ lx config kvms addr

It is also possible to adjust configured values, like in

unix$ lx config -s lxqe mem=500m

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

Refer to section [lx config] for more options and examples.

External Backups

The lxbackup program can be used to perform external backups. Just copy it from the installed bin directory, along with the installed configuration, to the external host.

For details, refer to the [lx backup] and [lxbackup] sections, found later in this document. This is just an example for the impatient.

Setup the external host orion for backups, by copying the backup program and saving and copying the installed configuration:

unix$ lx config -r lxinst.conf
saved lxinst.conf
unix$ scp /usr/local/leanxcale/bin/lxbackup lxinst.conf orion:~

From the external host, perform a full system backup:

orion$ lxbackup -f lxinst.conf
backup...
host atlantis...
backup: lxdump/230720
...
orion$

Or restore it:

orion$ lxbackup -f lxinst.conf -r lxdump/230720
...

The system should not be running while doing a backup. To perform a hot backup, backup just the query engine files as an incremental backup:

orion$ lxbackup -f lxinst.conf -i lxqe
backup...
host atlantis...

Licenses

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

Within leanxcale, there is a license file at the gitlab, in the lxdist project, at .lxlicense.

Also, you can run the kvlicense file to generate one:

unix$ kvlicense
usage: kvlicense yymmdd file
unix$ kvlicense 243012 lxlicense
kvlicense[34951]: license saved at lxlicense with limit Fri Jun 12 2026

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

Adding hosts

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

unix$ lx config

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):

unix$ lxinst -u -f lxinst.conf

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

unix$ lx start blade123