Replica state
Job details
| Name: | Replica state |
| Platform: | Mariadb |
| Category: | Cluster and Replication |
| Description: | This job collects the number of bytes received and sent from from other Galera Cluster nodes. |
| Long description: | |
| Version: | 1.2 |
| Default schedule: | 60s |
| Requires engine install: | No |
| Compatibility tag: | ./instance[databasetype=‘mariadb’] |
Parameters
| Name | Default value | Description |
|---|---|---|
| return_status | 1 | Return status value (ALARM – 2, WARNING – 1, or OK – 0) when replica changes occurs. |
| keep_status | 10 | For how long (in minutes) the jobs status will be kept when replica changes occurs. |
Job Summary
- Purpose: This monitoring job in dbWatch Control Center focuses on monitoring changes in replica states in a MariaDB database environment.
- Why: The job is crucial for ensuring the consistency and reliability of database replication. It helps in identifying if an instance becomes a replica or if an existing replica’s role changes which could impact database operations significantly. Prompt detection of such changes can help in maintaining the stability of the database cluster.
- Manual checking: To check the same manually, you can query the database for its current replication status and compare it to historical data to identify changes.
Job Details
- Job Name: Replica state
- Version: 1.2
- Company: dbwatch.no
- Description: This job checks if replica changes occur, for example, changes in the role of an instance between master and replica.
Monitoring Mechanics
- The job retrieves the role status of instances to determine if they are running as a replica (formerly known as ‘STANDBY’) or a master.
- It stores and compares the last known state against the current state to detect any changes.
- Parameters like ‘return_status’ and ‘keep_status’ help in configuring the sensitivity of change detection and the duration for retaining job status respectively.
Operational Logic
- The script checks the current replica status and compares it with previous data to determine if there has been a transition from master to replica or vice versa.
- Various conditions are set to trigger different status messages including:
- “Running as Slave (replica) host.”
- “Running as Master (source) host.”
- Significant status changes like “changed from MASTER to REPLICA“ or the reverse, including the time since the last status change.
Output Presentation
- Scheduled Frequency: Every 60 seconds
- The database’s replica state information gets updated in the dbWatch report which includes:
- Details such as status between replication SQL and replication I/O threads.
- Relevant changes highlighted in a status table which captures details on replica state transitions.