Use an external database

This page describes how to configure Cyberwatch to use an external database instead of the database deployed as a container of the Cyberwatch instance.


Cyberwatch supports the following databases:

  • MariaDB 10.11
  • MySQL 8.X

Material prerequisites

Cyberwatch recommends the following hardware configuration to ensure proper operation of the application:

  • 2 vCPU
  • 12 Go of RAM
  • 100 Go of disk space

External Database use case

Cyberwatch uses a containerized MariaDB database by default.

However, using an externalized database can be beneficial in some cases.

Cyberwatch requires the use of an external database for any instance that monitors 5000 or more assets. The use of an external database is also possible for smaller instances, considering the advantages and limitations below.

Advantages of using an external database

  • ability to configure and customize database configurations;
  • use of a dedicated server, allowing for more accurate resource allocation;
  • better performance;
  • replication and backup mechanisms that can be more finely tuned.
  • the use of a dedicated server leads to additional infrastructure requirements;
  • the maintenance of the database and the dedicated server is not the responsibility of Cyberwatch, although our teams are available to advise you if necessary.

Configuring the external database

Creating a user and a dedicated database

When using a dedicated database server, it is necessary to create a database with full privileges for a dedicated user. By default, Cyberwatch uses a database and user named olympe.

These operations can be performed by executing the following commands from the database server:

CREATE USER 'olympe'@'%' IDENTIFIED WITH mysql_native_password BY 'password';
GRANT ALL PRIVILEGES ON olympe.* TO 'olympe'@'%';

When assigning privileges, it is necessary to replace it with the Cyberwatch server’s IP address, or its domain name, in the format, as long as its reverse resolution is functional.

Setting a default configuration

In order to actually profit from the performance increase expected through the use of an external database, it is required to configure it based on the size of the Cyberwatch instance. The default configuration is not suitable.

The configuration file to edit can depend on the database used and on the system on which it is installed. In this documentation, we choose to modify the file /etc/my.cnf considering the configuration detailed below.

Before making this modification, you need to move the cbw-root-ca-cert.pem available in /etc/cyberwatch/certs to the database server. It is then necessary to generate a new certificate using the command sudo cyberwatch generate-certificate, to extend the validity of the cyberwatch certificate. When running this command, it is important to enter all the names that will be used to join the database from each node. This certificate and its key are then copied to the database server.

character-set-server       = utf8mb4
collation-server           = utf8mb4_general_ci
innodb_buffer_pool_size    = 2048M
innodb_log_file_size       = 512M
innodb_fast_shutdown       = 0

The first two lines define the charset to be used, in order to avoid any encoding problem later down the line.

The following two lines are minimal InnoDB configurations to be used at the date of the writing of this documentation.

For more information, please refer to the MariaDB documentation regarding the different configuration files:

Adapting the configuration to the size of the database

This default configuration should be adapted based on the size of the Cyberwatch database.

The size of the database typically depends on the number of assets monitored in Cyberwatch.

Two golden rules must be followed in any circumstances for optimal performances:

  • the variable innodb_buffer_pool_size should always be superior to the size of the database;
  • the variable innodb_log_file_size should be about equal or slightly superior to the value of innodb_buffer_pool_size/8.

Other parameters are often modified to improve the performance of the database. Ideally, you should follow recommendations given by the tool MySQLTuner which is commonly used to review a MySQL installation and that makes recommendations adjustments to increase performance and stability.

Using MySQLTuner

MySQLTuner is an open source tool used to audit the configuration of a MySQL database and recommends configurations tweaks to improve the installation performance and stability:

The MySQLTuner tool is embedded in the sidekiq container of the Cyberwatch application and can be used with the following command:

sudo cyberwatch exec sidekiq mysqltuner

Based on the script recommendations, configuration changes can be applied to the database. If you have any question, please feel free to contact our technical support.

Configuration through the base of the Cyberwatch orchestrator

Adapting the Cyberwatch configuration to the external base

First, you need to create a backup for the application database using the sudo cyberwatch backup save command. This archive is available in the directory /var/lib/cyberwatch/backups/ directory, and will be used to finalize the restoration of the Cyberwatch database.

Then, you need to replace from the file /etc/cyberwatch/secrets.env, the MYSQL_PASSWORD and MYSQL_ROOT_PASSWORD values by the external database user one.

In addition, all connection information to the external database can be edited from the /etc/cyberwatch/containers.env file, where it’s necessary to modify:

  • the value of the MYSQL_HOSTNAME field with the address of the database server to contact;
  • the value of the MYSQL_DATABASE field by the name of the dedicated database;
  • the value of the MYSQL_USER field by the name of the dedicated user, created previously.

Reconfigure your instance to not use a local database

sudo cyberwatch configure --no-db

If your instance is more complex than a single node, you need to specify again which configuration to use.

For instance, on a master node, the command is:

sudo cyberwatch configure --no-db --master

Communication with the new base is considered operational when the return of the sudo cyberwatch logs sidekiq command returns:

Start health monitoring server...
Monitoring Redis
Test redis uri redis:6379
Test connection to redis://redis:6379/0
Redis is up and running!
Watch the migration
All migrations completed
Healthcheck completed and reports successful startup
Redis is on the same node, TLS is not required.
Check if MariaDB supports TLS
TLS is available for MariaDB
The root certificate authority has been found and is valid, the MariaDB certificate will be verified.
2023-12-04T16:22:58.483Z pid=1 tid=53x INFO: Rails 7.0.8 application started in production environment

It is then possible to restore the application database by running:

sudo cyberwatch backup restore