Installation Guide

Before installing, it is important to know that LeanXcale has a distributed architecture and it consists of several components:

There are other components not described above, used by the system, that are not relevant for the user and are not described here. For example, spread is a communication bus used by LeanXcale components.

Query processing is performed partially on the query engine (lxqe) and partially on the storage engines (kvds). A query has a query plan and all algebraic operators below joins are pushed down to kvds and the joins and any operator above are processed by the query engine (lxqe).

The components listen on network ports to provide services to other components and to client applications:

To install, you need:

The install program itself requires a unix system with python 3.7 (or later).

Your sales representative will provide you with a valid license file. In case you have any issues with it, please send an email to sales@leanxcale.com.

The LeanXcale zip distribution can be found at:

There is a zip file per version. Download the latest version.

If needed, install the required software dependencies on your system:

Here, and in what follows, unix$ is the system prompt used in commands and examples.

Working on the directory where the distribution has been downloaded, unzip the LeanXcale zipped distribution:

Here, you type the command after the unix$ prompt, and the following lines are an example of the expected output.

Verify that the process completed successfully and there is a directory lxdist (with the distribution packages) and the lxinst program:

To install, run the lxinst program and, as an option, supply the name of the installation directory (/usr/local/leanxcale by default):

The command takes the zipped LeanXcale distribution from ./lxdist, and installs it at the target folder.

The detailed configuration file built by the install process is saved at lxinst.conf, as a reference.

The database has users (different from UNIX users). The user lxadmin is the administrator for the whole system. During the install you are asked to type a password for lxadmin.

To complete the install, a license must be added, as explained in the next section.

The installation creates the lx command. Use it to execute commands to operate the installed system.

At the end of the installation, the install program prints suggestions for adjusting the PATH variable so that lx will be available as any other command. For example, as done with:

when the install directory is /usr/local/leanxcale.

The lx command can be found at the bin directory in the install directory. For example, at /usr/local/leanxcale/bin/lx when installing at /usr/local/leanxcale.

In what follows, we assume that lx is on the system PATH.

The first command used is usally the one to install a license file:

It is also possible to put the license file at ~/.lxlicense, and the install process will find it and install it on the target system(s). == Docker Installs

When a preinstalled leanXcale docker image is available, disregard this section and proceed as described in the next one.

This section explains how to create containers from leanXcale images and how to install licenses and change the lxadmin password for them.

Provided the leanXcale image named lx:2, and the docker network lxnet, this command runs a leanXcale docker container:

In this command, the container name is lx1, the network used lxnext, and the image used lx:2. The port redirection -p…​ exports the SQL port to the underlying host.

It is important to know that:

The container name (lx1) can be used to issue commands. For example, this removes the container after stopping it:

The installed container includes the lx command. Use it to execute commands to operate the installed DB system.

It is possible to attach to the container and use the ''lx'' command as it can be done on a bare metal host install:

Here, we type docker attach lx1 on the host, and lx version on the docker container prompt.

Note that if you terminate the shell reached when attaching the docker container, it will stop. Usually, this is not desired.

It is possible to execute commands directly on the executed container. For example:

executes lx version on the container.

The program lxaws is used to list or remove AWS installs. This program is not built as such. To create it, copy lxinst to lxaws and use it.

Given a region, without any tags, it lists the tags installed:

Given a tag, it lists the tag resources as found on AWS:

It is also possible to supply just the base tag without the domain, as in

With flag -e prints commands to set environment variables with resources found, as an aid to run other scripts.

When more than one tag is asked for, or more than one instance/volume is found, variable names are made unique adding a number to the name, for example:

With flag -d, it removes the resources for the tags given. In this case, tags must be given explicitly in the command line.

To list, open, and close ports exported by the AWS install to the rest of the world, use lxaws flags -p (print ports), -o (open ports), and -c (close ports).

In all cases, the first argument is the tag for the install. The tag can be just the AWS install tag name, without .aws.leanxcale.com.

For example, this command lists the open ports:

Here, the protocol and port (or port range) is printed for each set of open ports. The CIDR printed shows the IP address range that can access the ports, and is 0.0.0.0/0 when anyone can access them.

Before with each port range, the name for the open port range is printed. This name is set by the default install, and can be set when opening ports as shown next.

To open a port range, use -o and give as arguments the tag for the install, the protocol, first and last port in range, the CIDR (or any if open to everyone), and a name to identify why this port range is open (no spaces). For example:

The new port will be shown as open if we ask for ports:

As another example:

To close a port, use -c and give as arguments the tag for the install, the protocol, a port within the range of interest, and the CIDR used to export the port. Note that any can be used here too instead of the CIDR 0.0.0.0/0 For example:

Here, we used the -v flag (verbose) to see what is going on.

As another example, this can be used to close the open port range 8888-10000 from the example above:

Peering connections can be used to bridge two VPCs at AWS.

One peer asks the other peer to accept a peering connection, the peer accepts the connection, and network routes and security group rules for access are configured.

Peering connections are handled using lxaws with the peering connection flags. If you do not have lxaws, copy lxinst to a file named lxaws and give it execution permissions.

These are the flags for peering connections:

To request a peering connection, supply as arguments

For example:

Here, we could have used xample.aws.leanxcale.com instead. The command prints the peering connection identifier, to be used for setting up networking and asking the peer administrator to accept the peering request.

To accept a peer request, supply as an argument the peering connection id, as in:

In either case, once the dialed peer accepts the request, networking must be set supplying as arguments

For example:

Our local CIDR block is 10.0.120.0/24. This must be given to the peer, so the peer system can setup routing for this block to our network, along with the VPC id and our security group id.

This information can be retrieved using lxaws as described in the previous section. For example:

Should it be necessary, the CIDR block used by the install can be set when installing the system (but not later), using the property awsnet, as in

Note that only the network address bytes used are given, instead of using 10.0.120.0/24.

Once done with a peering connection, it can be dismantled supplying both the tag and the peering connection identifier. The identifier is always given because, when accepting a peering request, the peering connection does not belong to us. But, using the command above you can retrieve such identifier easily.

When peering is no longer desired, the peering connection can be removed.

Removing the peering connection also removes the routing entries for it and the security group access rules added when it was setup.

By default, lxinst installs components to exploit the machine(s) used for the install.

It is possible to perform small installs using flag -s like in

And, it is possible to perform medium size installs using flag -m, as in

A small install limits the number of kvds to 4, and per-component memory to 1GiB.

A medium install limits the number of kvds to 8, but does not limit per-component memory and tries to use the default allocation policy.

Installs are configured using a file that describes the hosts and components installed. The file may include properties for the whole installation, or for individual hosts and components.

To perform custom installations, use a configuration file. You can fine-tune your installation in order to adapt the default installation to your needs, resources, and requirements.

The configuration file describes hosts and components installed.

To install using a configuration file, use the lxinst flag -f to use it, as in:

The configuration file has an initial section describing global properties, then a series of hosts each one including a series of properties and a series of components with properties.

The file consists of plain text lines. The character # can be used to add comments (the rest of the line is ignored). Each line declares a property, perhaps with a value, or starts a host or component declaration.

Lines declaring hosts start with host, those declaring components start with a component type name. All other lines declare properties.

A host configuration starts using the host keyword and the name for the host (which usually is the host name used to reach the host on the network). It is recommended to use the host name instead of using localhost.

A property is declared with a single line with the property name, then blanks, and then the property value. If the property has no value, it is considered as a boolean and it is set to true.

Properties declared before the first host declaration are global, and may be overridden later by properties defined within a host or component.

All declarations after a host declaration are defined for that host, until another host declaration is found.

All properties defined a component declaration, before another one is declared, are defined for that component.

Those required components and properties not specified by the user are added by the install program with default values.

Variables HOME and USER may be used when defining properties. The variable LXDIR may be used as well and refers to the install (or disk) directory for the host or component.

A component may be repeated adding the option x N to specify how many instances are wanted. When not used, each component declared stands for a single component, but many of the same type can be added for components like kvds.

For docker installs, specify docker before the first host.

For example, when installing at the host named atlantis, this can be a configuration file:

In this file, the property lxdir (leanXcale install directory) is defined as a global property, and applies to all hosts defined.

Then, a single host (atlantis) is defined. When no host is configured, localhost is used as the default.

For the configured host, two of the required components are configured:

Note that components required (e.g. lxmeta) but not specified are added by the install program itself.

For a docker installation, specify docker and try not to specify specific paths or hostnames for the installed system. For example:

The installer has a default memory split allocation among components. To specify the memory size for the lxqe and kvds components we can include them in the configuration file and include the mem attribute for them, as done here:

It is suggested not to use more memory in total than the physical memory available on the system (minus the one used by the operating system and leaving a small amount unused for safety).

We suggest to give half the memory to the lxqe component and the other half to all the kvds components (evenly distributed).

Note that by default the install tries to use available memory, unless a small or medium install was selected.

To specify the maximum disk size for the disk usage, specify it for the components using a significant space on disk (most notably kvds for table storage, and lxqe for the transactional log). For example:

The network address (including port) used by the query engine to listen for client connections is 14420. To use another port, specify the network address for the lxqe component:

But it may be easier to move the base port address used to a range other than 14000. This can be done defining the global (or host) property baseport, as done here:

Refer to the [LeanXcale Components and Ports] section for more details regarding network port usage.

To install optional components, specify them in the configuration file. It is customary to add them on the first host installed. For example:

adds both stats and odata to the installation. As they are optional components, they are never installed by default.

The OpenDATA port is usually 14004 unless configured otherwise.

The default user and password for the stats web page is lxadmin.

Here we provide more details on configuration files.

This property defines the directory used by the install, and relies on the HOME environment variable on each host involved:

To use a host just for stats, without any DB component, use only as the value for the stats property:

To include a web interface in your install, add web as a property for the host. The server port is 5000. For example:

In some cases it is desirable to install one host with just the lx command, to operate the rest of the hosts installed (perhaps just during the install process). For example, when installing from a laptop and wanting to have the lx command installed at the laptop to operate a set of hosts being installed.

This can be done adding the nodb attribute to a host. For example:

Specific ssh and scp commands may be given to reach the installed hosts. Should the installed hosts use different ssh and scp command to reach each other, properties sshi and scpi can be used to given them.

This is an example:

Hosts may be replicated, but either all hosts must have replicas or none of them. To define a replica for a host, add another host and define mirror for it using the replicated host name as the property value. For example:

configures a system with two replicated hosts. That is, four hosts where two ones are a mirror of the other two ones.

In replicated configurations, the set of initial hosts is designated as the first replica (or replica-1) and the mirror hosts are known as the second replica.

Component names in this case include a final .r1 or .r2 to reflect the replica they belong to. For example, kvds100.r1 is likely to be a component in this configuration.

When using a configuration file, just define the property aws before anything. You can specify the region, instance type, disk size, and AWS tag. The disk size is in GiB. The tag is a string and should not include blanks.

For example, using this file:

you can run:

This can be done also using the command line:

The partition mounted at /usr/local/leanxcale for the DB storage is 30GiB by default. You can change this using the aswdisk property. It is formatted using a compressed ZFS.

In the installed system, the user running the DB is lx, and LeanXcale is added to the UNIX system as a standard (disabled) systemd service. The instance is left running. You can stop it on your own if that is not desired.

To install multiple instances, install using multiple host names:

By default, private IP addresses for hosts are in 10.0.120.0/24. To use a different network, keep 10.0 and pick your own 3rd byte as in

Properties with upper-case names are exported as environment variables for the process(es) executing the component involved. This includes both global properties and host properties as well. For example, to enable debug flags DOM for the kv datastore:

These are other properties not described before.