MariaDB Agent Manager Sub-command Reference

This page is part of MariaDB's Documentation.

The parent of this page is: Reference for MariaDB Agent Manager

Topics on this page:

Overview
mariadb_agent_manager agent-installation
mariadb_agent_manager create-user
mariadb_agent_manager diagnose
mariadb_agent_manager encrypt-creds
mariadb_agent_manager fluent-bit
mariadb_agent_manager init
mariadb_agent_manager install
mariadb_agent_manager restart
mariadb_agent_manager start
mariadb_agent_manager status
mariadb_agent_manager stop
mariadb_agent_manager uninstall
mariadb_agent_manager upgrade

Overview

The MariaDB Agent Manager sub-commands are listed below.

`mariadb_agent_manager agent-installation`

To backup an Agent Manager installation, use the agent-installation sub-command with the -s or --save-state command-line option:

$ mariadb_agent_manager agent-installation -s

To restore an Agent Manager installation, use the agent-installation sub-command with the -r or --restore command-line option:

$ mariadb_agent_manager agent-installation -r

To restore the credentials and configuration files from an Agent Manager installation, use the agent-installation sub-command with the -a or --apply-saved-creds command-line option:

$ mariadb_agent_manager agent-installation -a

After performing a restore, the services must be restarted for the changes to take effect.

`mariadb_agent_manager create-user`

To create a database user or MaxScale user, use the create-user sub-command:

$ mariadb_agent_manager create-user

In each topology, the user accounts should be created on different nodes:

With Single Node Enterprise Server, the user account should be created on the ES node.
With the Xpand topology, the user account should be created on a single node in the Xpand cluster, and the Xpand cluster replicates the user account to all nodes.
With the Replicated Transactions and Multi-Node Analytics topologies, the user account should be created on the primary node, and the primary node replicates the user to all replica nodes.
With the Galera Cluster topology, the user account should be created on a single node in the Primary Component, and the node replicates the user account to all nodes in the Primary Component.
With any topology that uses MaxScale, the MaxScale user should be created on each individual MaxScale node.

`mariadb_agent_manager diagnose`

To run monitoring diagnostics, use the diagnose sub-command:

$ mariadb_agent_manager diagnose

When the diagnose sub-command is executed, MariaDB Agent Manager reports details about the operating system, disk usage, files and directories in use, the systemd mode, whether SELinux is enabled, and other system diagnostics. MariaDB Agent Manager also performs connectivity tests.

`mariadb_agent_manager encrypt-creds`

To ingest the credentials file and encrypt the credentials, use the encrypt-creds sub-command:

$ mariadb_agent_manager encrypt-creds -p ~/credentials.json

The following files have been successfully created:
Encrypted credentials:    /home/USER/.config/mariadb-agent-manager/cred.json
Secret key:               /home/USER/.config/mariadb-agent-manager/.key.txt

The -p option specifies the path to the credentials file. Alternatively, the REMOTE_AGENT_CREDENTIALS environment variable can be used.

MariaDB Agent Manager encrypts the credentials and saves the encrypted credentials to its configuration directory.

After the credentials have been encrypted, MariaDB Agent Manager deletes the credentials file. If you need to preserve the credentials file, ensure that you have a backup.

`mariadb_agent_manager fluent-bit`

Fluent Bit integration is provided to collect and process logs from servers. Fluent Bit integration is only available on servers that have an API Key configured.

To use the Fluent Bit integration, use the fluent-bit sub-command:

$ mariadb_agent_manager fluent-bit [OPTIONS]

The following command-line options are supported:

The -i and --install options can be used to install the Fluent Bit binaries and dependencies. Alternatively, the INSTALL_FLUENT_BIT environment variable can be used. When running in user systemd mode, the user must be in the sudo group to install Fluent Bit.
The -u and --un-install options can be used to uninstall the Fluent Bit binaries. Alternatively, the UNINSTALL_FLUENT_BIT environment variable can be used.
The -r and --register-user-conf options can be used to register a user-provided Fluent Bit configuration file instead of the default configuration file. Alternatively, the REGISTER_USER_CONF environment variable can be used. The configuration file is saved to the configuration directory. After changing the Fluent Bit configuration file, the services must be restarted.
The -x and --unregister-user-conf options can be used to unregister a user-provided Fluent Bit configuration file. Alternatively, the UNREGISTER_USER_CONF environment variable can be used.

Fluent Bit integration is configured for servers using the "logging" attribute, which is enabled by default:

{
  "datacenter": {
    "name": "Example Data Center",
    "location": "Oregon, US",
    "database_services": [
      {
        "name": "example-standalone",
        "type": "standalone",
        "servers": [
          {
            "name": "mdb1",
            "type": "server",
            "hostname": "mdb1.example.com",
            "logging": {
              "mode": "enabled",
              "path": [
                "/var/log/mysql/error.log",
                "/var/test.log"
              ]
            }
          }
        ]
      }
    ]
  }
}

`mariadb_agent_manager init`

To initialize a configuration file using the built-in wizard, use the init sub-command:

$ mariadb_agent_manager init

After the command is executed, follow the prompts to specify your configuration file and credentials files. By default, configuration.json is used for the configuration file, mariadb-credentials.json is used for the database credentials file, and maxscale-credentials.json is used for the MaxScale credentials file.

Then, follow the prompts to configure details about your data center, database services, servers, and the corresponding exporters.

When the init sub-command is executed on a node that already has services and credentials configured, MariaDB Agent Manager asks the user whether the existing configuration should be reloaded or whether a new configuration should be created.

For additional information, see "Configuration Wizard".

`mariadb_agent_manager install`

To install MariaDB Agent Manager, use the install sub-command:

$ mariadb_agent_manager install

When the install sub-command is executed on a node where a MariaDB database or MaxScale is installed, MariaDB Agent Manager prompts the user to ask whether a database user or MaxScale user should be automatically created. In each topology, the user accounts should be created on different nodes:

With Single Node Enterprise Server, the user account should be created on the ES node.
With the Xpand topology, the user account should be created on a single node in the Xpand cluster, and the Xpand cluster replicates the user account to all nodes.
With the Replicated Transactions and Multi-Node Analytics topologies, the user account should be created on the primary node, and the primary node replicates the user to all replica nodes.
With the Galera Cluster topology, the user account should be created on a single node in the Primary Component, and the node replicates the user account to all nodes in the Primary Component.
With any topology that uses MaxScale, the MaxScale user should be created on each individual MaxScale node.

If the -s flag is specified, MariaDB Agent Manager skips the prompt about user creation.

When the install sub-command is executed and debug logging is enabled, MariaDB Agent Manager writes a summary of disk usage to the log:

DEBUG	pdc/config_utl.go:851	Disk Usage:	{"Filesystem": "ext2/ext3", "Size": "10 GB", "Used": "3.3 GB", "Avail": "6.9 GB", "Use%": "32%", "Mounted on": "/"}

`mariadb_agent_manager restart`

To restart monitoring, use the restart sub-command:

$ mariadb_agent_manager restart

`mariadb_agent_manager start`

To start monitoring, use the start sub-command:

$ mariadb_agent_manager start -c ~/configuration.json -t ~/tls.json -k ~/skysql-api-key.txt -f

The -c option specifies the path to the configuration file. Alternatively, the REMOTE_AGENT_CONFIG environment variable can be used.
The -t option specifies the path to a TLS parameters file. Alternatively, the REMOTE_AGENT_TLS_PARAMETERS environment variable can be used.
The -k option specifies the path to a file that contains your SkySQL API Key. Alternatively, the REMOTE_AGENT_API_KEY environment variable can be used. Setting the API key is only required the first time that the services are started on the Forwarding Host, because MariaDB Agent Manager saves the API key to a file. If the option or environment variable are not set, MariaDB Agent Manager prompts the user to enter the API key.
The -f option indicates that the node is a Forwarding Host. Alternatively, the FORWARDING_SERVER environment variable can be used. If the host is not defined in the configuration file, MariaDB Agent Manager assumes that it is a dedicated Forwarding Host. If the host is defined in the configuration file, MariaDB Agent Manager handles it as a combination Forwarding and Monitored Host.

The MariaDB Agent Manager daemon automatically obtains and refreshes the bearer token as needed, which is used by Prometheus and skysql-uni-exporter to push metrics to SkySQL Monitoring.

MariaDB Agent Manager starts its components using systemd. MariaDB Agent Manager has two different modes for its systemd services:

The services can be started in "system" mode, which means that the root user or sudo is used.
The services can be started in "user" mode, which means that the current user is used.

For additional information about each systemd mode, see "MariaDB Agent Manager Systemd Reference".

`mariadb_agent_manager status`

To check the status of the services, use the status sub-command:

$ mariadb_agent_manager status

`mariadb_agent_manager stop`

To stop monitoring, use the stop sub-command:

$ mariadb_agent_manager stop

`mariadb_agent_manager uninstall`

To uninstall MariaDB Agent Manager, use the uninstall sub-command:

$ mariadb_agent_manager uninstall

On Forwarding Hosts, the uninstall sub-command supports the -u command-line option, which instructs MariaDB Agent Manager to unregister from the Remote Observability Service SkySQL Observability service all services that the Forwarding Host serves, before uninstalling all local services. After the services are unregistered, there can be a short delay before the services are removed from the monitoring dashboards.

On Monitored Hosts, the uninstall sub-command should be executed without the -u flag to uninstall each node's local services.

`mariadb_agent_manager upgrade`

To upgrade MariaDB Agent Manager to the latest release, use the upgrade sub-command:

$ mariadb_agent_manager upgrade

The -c and --check-availability options can be used to check upgrade availability. Alternatively, the CHECK_UPGRADE_AVAILABILITY environment variable can be used.
The -u and --run-upgrade options can be used to upgrade MariaDB Agent Manager. Alternatively, the RUN_UPGRADE environment variable can be used. When this option is provided, Agent Manager performs the following steps:
1. Download the latest version (unless a local tarball is specified using -b)
2. Stop services
3. Backup current installation
4. Uninstall the current installation
5. Install the downloaded version
6. Restore the configuration and credentials
The -m and --restart-monitoring options can be used to restart monitoring after successful upgrade. Alternatively, the RESTART_MONITORING environment variable can be used.
The -b and --tarball-path options can be used to specify the full path to a local tarball to use for the upgrade. Alternatively, the TARBALL_PATH environment variable can be used.