Editing the configuration fileΒΆ

Kognitio is designed to behave sensibly without any additional configuration settings so often you will not need to use a server configuration file at all. The server configuration file has the same contents regardless of how you deploy Kognitio. Howwever how you access and edit the file is dependent on the deployment option:

Kognitio on Hadoop

Server configuration for Kognitio on Hadoop is done in a similar way to cluster configuration.

You can place default settings in kodoop/config/server_defaults.cfg and Kognitio on Hadoop will also take settings from the kodoop/config/recommended_settings.cfg file, which contains settings that Kognitio recommend are applied to Kognitio on Hadoop systems.

There is a template file kodoop/examples/template-server.cfg which can be used as a base for your configuration.

Refer to the Kognitio pdf documentation for the various server configuration settings.

Kognitio standalone

Kognitio Standalone configuration files are held in the /opt/kognitio/wx2/etc directory.

They have a similar form to Microsoft Windows .ini files, in that related parts of the configuration are grouped together, and each group is introduced by a keyword in square brackets.

There are two types of configuration files:

  • config - global configuration file. Holds information that is appropriate for replication across all Kognitio Nodes

  • local_config - local Configuration file. Holds information specific to an individual Kognitio Node is specified on that node

The global config file contains various global parameters and settings that control a Kognitio cluster. This file can be accessed via command line on any of the Kognitio Nodes, with the Linux command wxviconf. Only users that are members of the wxadmin group may edit the file, this includes the wxadmin user and the wxroot user by default.

wxviconf is a tool which automatically replicates any configuration changes across all nodes in a cluster. Thus the global config file should never be edited directly on any of the nodes - always use the wxviconf tool.

Default values exist for all possible configuration file entries and will be used if neither configuration file overrides it. If an entry exits in both configuration files, then the local file entry will be used in preference to the global one.

Configuration parameters

The global config file contains a list of key = value pairs, each setting a global parameter. These parameters are permanent, and persistent across system restarts and reboots. The parameters are organized into sections, where each section has a descriptive heading enclosed in square brackets. The headings include [general], [boot options], [runtime parameters], [security], [disks] and others. Each parameter must be in the correct section to take effect, for example the system_id parameter must always be in the [general] section. Binary parameters can take values of 0 or 1, or True or False.

Note that some parameters can only be set by the wxroot user by default. All parameters require a system restart to take effect, and some require a full newsys to take effect.

Below is one example of a global config file

# This file should only be edited with wxviconf or wxconftool!

# The general section contains details about the hardware and daemons and how they communicate.

#The boot options describe how the RDBMS system should be configured.
[boot options]

# The runtime parameters, which can also be change dynamically via SQL, allow certain aspects of the RDBMS to be altered.
[runtime parameters]
# specify the lock timeout

# the disks section defines parameters related to disk resources

# fs defines parameters relating to the filesystem
  • system_id defines the name of the cluster. This is how you define which nodes belong to which system - only nodes with the same system_id will be considered part of the same system during network discovery. Thus, if you have 4 nodes on the same network, where 2 have a config file with system_id=prod1, and 2 have system_id=prod2, they will be considered 2 separate systems and will not interact with eachother (note, this is not recommended). If using a license, the system_id must match the system_id on the license.

  • raid_cluster_size defines The type of software RAID in use. A cluster size of 1 means software RAID is switched off. A cluster size of 2 implies mirrored disk resources, similar to a series of RAID 1 arrays (Thus halving the available disk capacity). A cluster size of 3 or more implies striping with distributed parity, similar to a series of RAID 5 arrays. Note that the total number of disk resources in the system that are visible to kognitio must be divisible by the specified cluster size. For example, if a cluster size of 4 is specified on a system with 12 visible disk resources (across all nodes), then 3 RAID arrays will be created, each containing 4 disk resources. Within each array, data will be striped over 3 disks, with the fourth being used for parity. Note that changes to the raid_cluster_size will only take effect during newsys (when you reinstall from scratch).

  • sparse_file causes disk data to be held in a flexible sparse file rather allocating and zeroing a dedicated number of disk blocks. This is useful for recommissioning systems quickly for testing purposes. If sparse_file is turned off, then recommissioning will zero all disk resources, which could take a long time. Production systems should always be commissioned with sparse_file=no (the default).

  • desired_slabs sets the number of slabs the system should have (see <> for more information on slabs). This setting will only take effect during newsys.

This is not a complete list of all available parameters.