Introduction

MariaDB replication cluster typically refers to a cluster of MariaDB servers that use replication for data synchronization. MariaDB supports various forms of replication, but a common scenario involves using Galera Cluster for synchronous multi-master replication. There is also a traditional master-slave MariaDB replication setup involving one master server and one or more slave servers. This form of replication is asynchronous, meaning that changes made on the master are propagated to the slaves after some delay.

Galera Cluster

Galera Cluster is a synchronous multi-master cluster for MariaDB. It provides high availability and fault tolerance by allowing multiple nodes to write to the cluster simultaneously. Galera uses a certification-based replication mechanism, ensuring consistency across all nodes.

Traditional master-slave Cluster

• Master Server:
  • The master server is the primary server where write operations (INSERT, UPDATE, DELETE) are performed.
  • It maintains the original dataset.
  • It logs changes made to the database in the binary log.
• Slave Server(s):
  • Slave servers are read-only replicas of the master.
  • They replicate changes from the master, effectively mirroring its dataset.
  • Slaves can be used for read scaling and backup purposes.
• This form of replication is suitable for scenarios where read scaling and data redundancy are primary considerations, and some delay in data consistency is acceptable.

From app version 4.0.0 both topologies are covered through the Mode field of the configuration: Cluster (Galera), Standalone (a single server) and Master Slave Replication (a traditional master-slave replication group, discovered as a MariaDB Replication Group with the master and every replica as MariaDB Server resources).

Key Use cases

Discovery Use cases

• It discovers the MariaDB cluster and its component Mysql instances.
• Publishes relationships between resources to have a topological view and ease of maintenance.
• In Master Slave Replication mode it discovers the replication group (MariaDB Replication Group) from any one member: the master through SHOW SLAVE STATUS, the replicas through SHOW SLAVE HOSTS, each as a MariaDB Server with its databases.

Monitoring Use cases

• Provides usage, performance and capacity metrics of the MariaDB servers and databases (connections, threads, commands, InnoDB buffer pool, network, database and index sizes).
• In Master Slave Replication mode it reports, per server, the replication role (master / slave), the replica IO and SQL thread state, seconds behind master and the lag in bytes, and alerts when the master changes (failover), when no writable master is left and when a replication thread stops.
• Concern alerts will be generated for each metric to notify the administrator regarding the issue with the resource.

Supported Target Version

• Validated on MariaDB version 10.3.35-MariaDB
• The Master Slave Replication mode (4.0.0) is validated on MariaDB 10.11 (10.11.14) with classic binlog / GTID replication.

Prerequisites

• OpsRamp Classic Gateway(Linux) 14.0.0 and above.
• OpsRamp Nextgen Gateway version 14.0.0 and above.
• Provided IpAddress/hostname, Credentials (SSH and MariaDB database) should work for accessing MariaDB cluster.
• The SSH credentials should be same for all the MariaDB cluster nodes
• The MariaDB credentials should be the same for all the MariaDB node instances.
• Ensure that the provided IP address/host name, port, and credentials are valid and accessible for successful integration.
  • Verify network connectivity from the gateway using:
    ping <IP Address/Host Name>
  • Check port accessibility using:
    telnet <IP Address/Host Name> <Port>
  • Validate SSH access using the provided credentials:
    ssh -p <Port> <username>@<IP Address/Host Name>
• Verify MariaDB Database connection to end device mysql -h <NodeIP / HostName> -u <userName> -P 3306 -p<password>.
• mysql CLI command must work on the DB server.
• Additional prerequisites for Master Slave Replication mode:
  • Enter the address of one member of the replication group (preferably the current master) as IP Address/Host Name. Do not use a floating / virtual IP: the other members are discovered automatically.
  • Every replica must run with report_host set to a name that resolves from the configured node (DNS or /etc/hosts), so that SHOW SLAVE HOSTS on the master lists it. The app resolves the name with getent hosts <report_host>.
  • Replicas must run with read_only=ON. The writable server (read_only=OFF) is treated as the master by the role and failover metrics.
  • The MariaDB user needs, on every member, the privileges for SHOW SLAVE STATUS (REPLICA MONITOR; REPLICATION CLIENT before MariaDB 10.5) and SHOW SLAVE HOSTS (REPLICATION MASTER ADMIN; REPLICATION SLAVE before MariaDB 10.5), in addition to the privileges used for the server and database metrics.
  • The MariaDB user must be allowed to connect from the other members (for example 'user'@'<subnet>%'): the configured node queries the master over port 3306 to list the replicas.
  • Verify on a member: mysql -h <member> -u <userName> -P 3306 -p<password> -e "SHOW SLAVE STATUS\G", -e "SHOW SLAVE HOSTS;" (on the master) and -e "SELECT @@GLOBAL.read_only;".

    Note

    • Where ipPath is path where ip command binary is present. for example: if ip command is present in /usr/sbin, then provide PATH=/usr/sbin:$PATH.

    • As we are utilizing a remote SSH connection, if the environment PATH does not include the binary path for the command, you may encounter a command not found exception.

    • As part of discovery we are fetching the serial number and system UUID of the individual nodes. These details are fetched through command-line(SSH).

    • If the SSH credentials being provided are root users, no changes need to be made.

    • If the SSH credentials being provided are of a non-sudo user, then we need to make an entry in the /etc/sudoers file as the following:

      

Hierarchy of MariaDB Cluster

• For MariaDB cluster:
  • MariaDB Cluster
    • MariaDB Server
      • MariaDB Database
• For a standalone MariaDB server:
  • MariaDB Server
  • MariaDB Database

The MariaDB Replication Group resource is named <configured address> Replication Group and is keyed on the configured address, so it keeps its identity across failovers while the master / slave roles move between the MariaDB Server resources. Replication metrics are published on the group with one component per server (host name).

Notes: For the execution of remote SSH/CLI commands, ensure the provision of SSH credentials for the MariaDB server and credentials for the specific MariaDB instance.

Supported Metrics

Default Monitoring Configurations

MariaDB has default Global Device Management Policies, Global Templates, Global Monitors and Global metrics in OpsRamp. Users can customize these default monitoring configurations as per their business use cases by cloning respective global templates and global Device Management Policies. OpsRamp recommends doing this activity before installing the app to avoid noise alerts and data.

From app version 4.0.0 (Master Slave Replication mode) the MariaDB Replication Group native type has its own global template, monitor (MariaDB Replication Group Monitor, 15 minutes) and device management policy of version 4, created per mode. The failover status and the slave IO / SQL running metrics ship with alerting enabled; role, seconds behind master and lag in bytes ship without thresholds.

1. Default Global Device Management Policies

   OpsRamp has a Global Device Management Policy for each Native Type of MariaDB. You can find those Device Management Policies at Setup > Resources > Device Management Policies, search with suggested names in global scope. Each Device Management Policy follows below naming convention:

   {appName nativeType - version}

   Ex: mariadb MariaDB Cluster - 1(i.e, appName = mariadb, nativeType = MariaDB Cluster , version = 1)

2. Default Global Templates

   OpsRamp has a Global template for each Native Type of MariaDB. You can find those templates at Setup > Monitoring > Templates, search with suggested names in global scope. Each template follows below naming convention:

   {appName nativeType 'Template' - version}

   Ex: mariadb MariaDB Cluster Template- 1(i.e, appName = mariadb, nativeType = MariaDB Cluster, version = 1)

3. Default Global Monitors

   OpsRamp has a Global Monitors for each Native Type which has monitoring support. You can find those monitors at Setup > Monitoring > Monitors, search with suggested names in global scope. Each Monitors follows below naming convention:

   {monitorKey appName nativeType - version}

   Ex: MariaDB Cluster Monitor mariadb MariaDB Cluster 1 (i.e, monitorKey =MariaDB Cluster Monitor, appName = mariadb, nativeType = MariaDB Cluster, version = 1)

Configure and Install the MariaDB Integration

1. From All Clients, select a client.
2. Go to Setup > Account.
3. Select the Integrations and Apps tab.
4. The Installed Integrations page, where all the installed applications are displayed.
   Note: If there are no installed applications, it will navigate to the Available Integrations and Apps page.
5. Click + ADD on the Installed Integrations page. The Available Integrations and Apps page displays all the available applications along with the newly created application with the version.
   Note: You can even search for the application using the search option available. Also you can use the All Categories option to search.
6. Click ADD in the MariaDB application.
7. In the Configurations page, click + ADD. The Add Configuration page appears.
8. Enter the below mentioned BASIC INFORMATION:

Notes:

• Ip Address/Host Name and Port should be accessible from Gateway.
• App Failure Notifications: If turned on, you will be notified in case of an application failure that is, Connectivity Exception, Authentication Exception.

9. Select the below mentioned Custom Attribute:

Note: The custom attribute that you add here will be assigned to all the resources that are created by the integration. You can add a maximum of five custom attributes (key and value pair).

10. In the RESOURCE TYPE section, select:

    • ALL: All the existing and future resources will be discovered.
    • SELECT: You can select one or multiple resources to be discovered.

11. In the DISCOVERY SCHEDULE section, select Recurrence Pattern to add one of the following patterns:

    • Minutes
    • Hourly
    • Daily
    • Weekly
    • Monthly

12. Click ADD.

Now the configuration is saved and displayed on the configurations page after you save it.
Note: From the same page, you may Edit and Remove the created configuration.

13. Under the ADVANCED SETTINGS, Select the Bypass Resource Reconciliation option, if you wish to bypass resource reconciliation when encountering the same resources discovered by multiple applications.

    Note: If two different applications provide identical discovery attributes, two separate resources will be generated with those respective attributes from the individual discoveries.

14. Click NEXT.

15. (Optional) Click +ADD to create a new collector by providing a name or use the pre-populated name.

16. Select an existing registered profile.

17. Click FINISH.

The application is installed and displayed on the INSTALLED INTEGRATION page. Use the search field to find the installed integration.

Modify the Configuration

• See Modify an Installed Integration or Application article.

  Note: Select the MariaDB application.

View MariaDB details

To discover resources for MariaDB,

1. Navigate to Infrastructure > Search > DATABASES > MariaDB.
2. The MARIADB page is displayed, select the application name.
3. The RESOURCE DETAILS page appears from the right.
4. Click the ellipsis (…) on the top right and select View details.

5. Navigate to the Attributes tab to view the discovery details.

6. Click the Metrics tab to view the metric details for MariaDB.

View resource metrics

To confirm MariaDB monitoring, review the following:

• Metric graphs: A graph is plotted for each metric that is enabled in the configuration.
• Alerts: Alerts are generated for metrics that are configured as defined for integration.

Resource Filter Input Keys

Click here to view the Supported Input Keys

Resource Type	Supported Input Keys
MariaDB Replication Group	General Attributes
	resourceName
	hostName
	aliasName
	dnsName
	ipAddress
	macAddress
	os
	make
	model
MariaDB Server	General Attributes
	resourceName
	hostName
	aliasName
	dnsName
	ipAddress
	macAddress
	os
	make
	model
	Custom Attributes
	datadir
	MariaDB version
	Root Resource IPAddress
	Root Resource Name
	Root Resource HostName
	Domain Attributes
	parentResourceName
	parentResourceId
	parentResourceIPAddress
	parentResourceHostName
MariaDB Database	General Attributes
	resourceName
	hostName
	aliasName
	dnsName
	ipAddress
	macAddress
	os
	make
	model
	Custom Attributes
	CATALOG NAME
	DEFAULT CHARACTER SET NAME
	DEFAULT COLLATION NAME
	MariaDB Server Name
	SQL PATH
	Root Resource IPAddress
	Root Resource Name
	Root Resource HostName
	Domain Attributes
	parentResourceName
	parentResourceId
	parentResourceIPAddress
	parentResourceHostName

Supported Alert Custom Macros

Customize the alert subject and description with below macros then it will generate alert based on customisation.

Supported macros keys:

Click here to view the alert subject and description with macros

${resource.name}	${resource.ip}	${resource.mac}
${resource.aliasname}	${resource.os}	${resource.type}
${resource.dnsname}	${resource.alternateip}	${resource.make}
${resource.model}	${resource.serialnumber}	${resource.systemId}
${parent.resource.name}	${Custome Attributes on the resource}

${parentResourceName}	${parentResourceId}	${parentResourceIPAddress}
${parentResourceHostName}	${Domain attributes on the resource}

Risks, Limitations & Assumptions

• Application can handle Critical/Recovery failure alert notifications for below two cases when user enables App Failure Notifications in configuration
  • Connectivity Exception
  • Authentication Exception
• Application cannot control monitoring pause/resume actions based on above alerts. Metrics can be used to monitor MariaDB resources and can generate alerts based on the threshold values.
• Master Slave Replication mode:
  • mariadb_replication_failoverStatus = 1 (MASTER CHANGED, warning) is raised on the first poll after the writable server changed and clears on the next poll once the new master is stable; 2 (NO MASTER, critical) stays as long as no member is writable. A “Fetch latest values” request reports the state but does not reset it.
  • Role and failover detection rely on read_only being OFF only on the master. Writable replicas are reported as Master as well, and the failover status is then unreliable.
  • The master has no SHOW SLAVE STATUS row, so slave IO / SQL running, seconds behind master and lag are reported for replicas only; the master reports the role metric.
  • A replica is discovered when the master lists it in SHOW SLAVE HOSTS (report_host) or when it replicates from a member and was discovered before. A previously discovered member that is unreachable stays in the group (its metrics are not collected) until it is reachable again and found to be detached from the group.
  • A promoted replica (RESET SLAVE ALL, writable) stays in the group as the new master; replicas that are re-pointed to it are enumerated on the following discovery.
  • Configure a node address, not a floating / virtual IP: through a VIP the member discovered behind it changes identity on every failover.
• OpsRamp has provided 22 as default Port for SSH and 3306 as default Port for MariaDB. Users can modify this value from the application configuration page at any point of time if required.
• Component level thresholds can be configured on each resource level.
• The Template Applied Time will only be displayed if the collector profile (Classic and NextGen Gateway) is version 18.1.0 or higher.
• The minimum supported version for the option to get the latest snapshot metric is Nextgen-14.0.0.
• This application supports both Classic Gateway and NextGen Gateway.

Version History

Application Version	Bug fixes / Enhancements
4.0.0	Added the Master Slave Replication mode (persona) for traditional master-slave replication setups: new root native type MariaDB Replication Group and six replication metrics (role, failover status, slave IO / SQL thread state, seconds behind master, lag in bytes) with alerts on master change (failover), on no writable master and on stopped replication threads. Discovery now fails with the actual SSH / MariaDB login error (for example ERROR 1045 Access denied) instead of completing silently. Major version: templates, monitors and device management policies of version 4 are created for all native types; 3.x installations keep version 3 until upgraded.
3.1.2	Added support to the following domain attributes for each non-root resource. parentResourceName parentResourceId parentResourceIPAddress parentResourceHostName Note: If parentResourceId is missing but other attributes are present, run a full discovery once to capture the parentResourceId details.
3.1.0	Added support for the SSLEnabled flag. This implementation introduces third-party CI alert mapping and OpsQL-based enhancements. Configure alert mappings to target CI systems through the application configuration. After configuration, the system automatically forwards alerts to the corresponding third-party platforms and maps them to the specified CIs, ensuring consistent integration and efficient alert management. Previously, resource filters in the app configuration required manual entry of resource core and custom attributes. With this enhancement, the configuration is moved to OpsQL-based filtering, where users can see the keys auto-populated as needed.
3.0.1	Added support for the latest metrics, Activity Logger updates, and DebugHandler changes.
3.0.0	Support has been added for MariaDB databases.
2.0.0	Persona changes to support Cluster and Standalone MariaDB configurations.
1.0.0	Initial version with Discovery and Monitoring Implementations.

×