How to Monitor MariaDB Replication

1. Monitoring Replication Status Using SQL Queries

MariaDB provides several SQL commands that allow DBAs to monitor the health of replication. These queries help you understand the status of both the I/O thread and SQL thread on the slave server, as well as other critical replication metrics.

a. SHOW SLAVE STATUS

The most important command for monitoring replication is SHOW SLAVE STATUS. It provides a comprehensive view of the replication status, including the current state of the replication process, errors, and lag.

SHOW SLAVE STATUS\G;

Key fields to monitor:

• Slave_IO_Running: Indicates whether the slave is connected to the master and reading the binary logs.

  • Expected value: Yes

• Slave_SQL_Running: Indicates whether the SQL thread is applying the received binary log entries to the slave.

  • Expected value: Yes

• Seconds_Behind_Master: Shows how much the slave lags behind the master, in seconds. A value of 0 means the slave is caught up with the master.

  • Ideal value: 0 (or a low number)

• Last_Error: Shows any errors encountered during the replication process. This is useful for diagnosing issues.

• Read_Master_Log_Pos: The current position in the master’s binary log that the slave has read up to.

• Exec_Master_Log_Pos: The position in the master’s binary log that the slave has executed.

Example Output:

*************************** 1. row ***************************
              Slave_IO_State: Waiting for master to send event
                 Master_Host: 192.168.1.100
                 Master_User: replica_user
                 Master_Port: 3306
               Connect_Retry: 60
             Master_Log_File: mariadb-bin.000001
         Read_Master_Log_Pos: 574
              Relay_Log_File: mariadb-relay-bin.000001
               Relay_Log_Pos: 714
       Slave_IO_Running: Yes
      Slave_SQL_Running: Yes
        Seconds_Behind_Master: 0
           Last_Error: None

b. SHOW MASTER STATUS (On the Master)

To check the status of the master and ensure it is generating binary logs correctly, you can run:

SHOW MASTER STATUS\G;

This shows the current position in the binary log that the slave should be following. Compare this with the slave's Exec_Master_Log_Pos to detect any replication lag.

2. Monitor for Replication Lag

Replication lag is the time difference between the master and slave in terms of executed transactions. It's essential to monitor replication lag to ensure the slave is as close to real-time as possible.

a. Seconds_Behind_Master

The Seconds_Behind_Master field in SHOW SLAVE STATUS indicates how far behind the slave is compared to the master. A value of 0 means the slave is up to date. A higher value indicates the slave is lagging behind the master.

SHOW SLAVE STATUS\G;

Key metric to monitor:

• Seconds_Behind_Master: Should ideally be 0. If this is consistently high, the slave is falling behind the master, indicating potential performance issues.

3. Monitor Replication Errors

Replication errors can disrupt the replication process. Use the following techniques to catch and troubleshoot errors.

a. Last_SQL_Error and Last_IO_Error

These fields in SHOW SLAVE STATUS provide details on the most recent errors that occurred during the replication process. Regularly monitoring these fields can help detect issues early.

SHOW SLAVE STATUS\G;

Look for:

• Last_SQL_Error: Indicates errors related to SQL thread execution on the slave.
• Last_IO_Error: Indicates errors related to reading binary logs from the master.

Example of error output:

Last_IO_Error: error connecting to master 'replica_user@192.168.1.100:3306' - retry-time: 60 retries: 5
Last_SQL_Error: Error executing row event: 'Duplicate entry '1' for key 'PRIMARY''

If errors are found, use STOP SLAVE; to stop the replication process, fix the issue (e.g., fix the duplicate entry or connectivity issue), and restart replication with START SLAVE;.

---

4. Monitoring System Variables for Replication Health

MariaDB system variables provide important information about replication performance and issues.

a. SHOW STATUS for Replication Variables

Use SHOW STATUS to monitor variables related to replication performance.

SHOW GLOBAL STATUS LIKE 'Slave_running';

This will show whether the slave replication is running.

SHOW GLOBAL STATUS LIKE 'Rpl_%';

Other key replication-related variables to monitor:

• Rpl_status: Displays replication status.
• Rpl_rejected_connections: Shows the number of connection attempts that failed due to replication configuration issues.

b. Binary Log File Monitoring

Monitoring the size and number of binary log files can give you insight into how fast changes are occurring on the master. The SHOW BINARY LOGS command shows all binary logs, which can be useful to track how much data is being written.

SHOW BINARY LOGS;

Use this to calculate the rate at which binary logs are generated and identify periods of high transaction volume.

---

5. Using Tools for Monitoring Replication

There are several tools available that can help you monitor replication in MariaDB in a more automated and graphical way.

a. Percona Monitoring and Management (PMM)

Percona Monitoring and Management (PMM) is a great tool for monitoring MariaDB replication. It provides real-time query performance monitoring and allows you to track replication lag, errors, and other key metrics through an intuitive dashboard.

• Features:
  • Real-time replication status.
  • Query analytics to see which queries may be slowing down replication.
  • Alerts and notifications for replication lag.

b. Zabbix

Zabbix is a popular open-source monitoring tool that supports MariaDB replication monitoring. You can set up custom templates to monitor replication status, track lag, and set up alerts for failures.

• Features:
  • Customizable dashboards to monitor replication.
  • Automatic alerts when replication lag exceeds a defined threshold.
  • Visualizations of replication health metrics.

c. Nagios

Nagios is another widely used monitoring solution that can be configured to track MariaDB replication health.

• Features:
  • Nagios can monitor SHOW SLAVE STATUS output and alert if any issues arise.
  • It can also track replication lag and generate alerts if thresholds are breached.
  • Provides log monitoring for replication errors.

d. ClusterControl

ClusterControl offers an advanced GUI-based approach to managing MariaDB clusters, replication setups, and Galera clusters. It provides real-time monitoring and alerting for replication issues.

• Features:
  • Real-time replication status tracking.
  • Automatic failover and failback in case of failures.
  • Query analysis for identifying bottlenecks affecting replication.

e. Monitoring via mysqladmin Tool

The mysqladmin tool is a command-line utility to monitor various aspects of MariaDB, including replication.

mysqladmin extended-status | grep -i 'slave'

This command will show various replication-related metrics.

---

6. Configure Replication Alerts

To ensure that you are always informed about replication issues, it's essential to configure automated alerts. Many monitoring tools such as Zabbix, PMM, and Nagios support alerting based on thresholds.

• Replication Lag Alert: Set an alert if Seconds_Behind_Master exceeds a certain value (e.g., 30 seconds).
• Replication Stopped Alert: Set an alert if Slave_IO_Running or Slave_SQL_Running shows No.
• Replication Error Alert: Monitor the Last_SQL_Error and Last_IO_Error fields for any recent errors and set up alerts for immediate notification.

---

7. Log-Based Monitoring

You can also monitor MariaDB replication using the error logs and binary logs:

• Error Log: If replication encounters an issue, MariaDB logs it in the error log file. Regularly checking the error logs ensures you catch replication errors early.

tail -f /var/log/mysql/error.log

• Binary Logs: Regular monitoring of binary logs helps ensure that they are being read and processed correctly by the slave.

SHOW BINARY LOGS;

---

Conclusion

Monitoring MariaDB replication is critical for maintaining a healthy replication environment. Using SQL queries like SHOW SLAVE STATUS, monitoring system variables, and employing external tools like Percona PMM, Zabbix, and Nagios can provide comprehensive insights into replication health. Setting up automated alerts ensures you catch any replication lag, errors, or stoppages before they become a problem.

Setting Up Master-Slave Replication in MariaDB

 Step-by-Step Guide to Setting Up Master-Slave Replication in MariaDB

1. Prerequisites

Before you start, ensure the following:

• MariaDB is installed on both the master and slave servers.
• Both servers can communicate with each other (pingable via IP or hostname).
• The master and slave have unique server IDs.
• You have administrative access to both MariaDB servers.

2. Configure the Master Server

Step 2.1: Edit the MariaDB Configuration File

On the master server, edit the my.cnf  file to enable replication settings.

sudo nano /etc/my.cnf   # or /etc/mysql/my.cnf, depending on the OS

Add the following configuration under the [mysqld] section:

[mysqld]
server-id = 1  # Unique ID for the master (can be any number)
log-bin = /var/log/mysql/mariadb-bin  # Path to the binary log
binlog-format = mixed  # Binary log format (can be row, statement, or mixed)

Step 2.2: Restart MariaDB

Restart MariaDB to apply the changes:

sudo systemctl restart mariadb

Step 2.3: Create a Replication User

Create a user on the master server that the slave will use for replication. This user should have the REPLICATION SLAVE privilege:

CREATE USER 'replica_user'@'%' IDENTIFIED BY 'replica_password';
GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'%';
FLUSH PRIVILEGES;

'replica_user'@'%': % allows the user to connect from any host. You can restrict it to the slave's IP if preferred.

REPLICATION SLAVE: Grants the required privileges for replication.

Step 2.4: Obtain Master Log File Information

To get the binary log file and position, which will be needed for configuring the slave:

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Note down the File and Position values. These will be used later in the slave configuration.

Step 2.5: Unlock the Master Tables

After obtaining the binary log information, release the lock:

UNLOCK TABLES;

3. Configure the Slave Server

Step 3.1: Edit the Slave Configuration File

On the slave server, edit the my.cnf file:

sudo nano /etc/my.cnf

Add the following settings under the [mysqld] section:

[mysqld]
server-id = 2  # Unique ID for the slave
relay-log = /var/log/mysql/relay-bin  # Relay log location
log_bin = /var/log/mysql/mariadb-bin  # Optional: To make slave a potential future master

server-id: This must be unique. Since it's the slave, you can use a different ID than the master.

relay-log: The relay log is where the slave stores the incoming replication data from the master.

Step 3.2: Restart MariaDB

Restart MariaDB on the slave to apply the changes:

sudo systemctl restart mariadb

Step 3.3: Configure the Slave for Replication

Now, configure the slave with the master’s details and log file information obtained earlier:

CHANGE MASTER TO
MASTER_HOST='master_ip',
MASTER_USER='replica_user',
MASTER_PASSWORD='replica_password',
MASTER_LOG_FILE='mariadb-bin.000001',
MASTER_LOG_POS=120;

`MASTER_HOST`: The IP address or hostname of the master server. 

 `MASTER_LOG_POS`: These are the file and position noted from the master.”

Step 3.4: Start Slave Replication

Once the slave is configured, start the replication process:

START SLAVE;

Step 3.5: Verify Slave Status

To verify that the replication is working, run the following command on the slave:

SHOW SLAVE STATUS\G;

Look for the following fields:
- Slave_IO_Running: Yes
- Slave_SQL_Running: Yes
- Seconds_Behind_Master: 0 (or a low number)

If both Slave_IO_Running and Slave_SQL_Running are Yes, the replication is set up and working correctly.

4. Monitor Replication

Step 4.1: Check Replication Health

On the slave, use the following command to check replication health:

SHOW SLAVE STATUS\G;

Monitor the Seconds_Behind_Master value. A consistent value of 0 or a low number indicates that replication is functioning properly.

Seconds_Behind_Master: If this is consistently high, it may indicate replication lag.

Last_Error: Any errors here will give you clues to troubleshoot issues with replication.

Step 4.2: Restart Slave if Necessary

If replication stops for any reason, you can restart the slave with the following commands:

STOP SLAVE;
START SLAVE;

5. Common Troubleshooting Tips

- **Check Permissions**: Ensure the replication user has REPLICATION SLAVE privileges.
- **Firewall Issues**: Ensure port 3306 is open between the master and slave.
- **Sync Issues**: If replication falls too far behind, consider re-syncing the slave.

 If the slave has fallen too far behind, you may need to reinitialize replication by re-syncing the database from the master (using mysqldump or similar).

Conclusion

Setting up master-slave replication in MariaDB is a straightforward process that provides many benefits, such as improved read scalability and high availability. By following these steps and monitoring the health of the replication, you can ensure a stable and reliable replication environment.

Oracle Database Product Life Cycle Support 19C ( Doc ID 742060.1)

 

Oracle Database Product Life Cycle Support  23ai, 19c Long Term & Innovation Releases !

Oracle has just changed their product life cycle support for their database technology especially.

There are two types of releases now: Long Term Release , and Innovation Release

Long Term Release:  are ideal for use cases that benefit from less frequent upgrades to newer releases. This type of release offers highest stability. The long term release will have 5 years of Premier Support.

Innovation Release:  is a release between long term releases. This type of releases will provide new enhancements and capabilities. it will have short period of Premier support which is 2 years. The idea here is to provide cutting edge technologies for rapidly evolving technologies.

Oracle 19c (long term release):

Premier Support (PS) ends April 30, 2024, two years of waived Extended Support (ES) fees will be in effect from May 1, 2024 until April 30, 2026. Fees will be required beginning May 01, 2026 through April 30, 2027

Oracle 21c (innovation release):  April 30, 2025

Oracle 23ai (long term release):  released in the cloud, not on premise yet. Expected Premier support will end April 30, 2029.

oracle official reference documentation: Doc ID 742060.1

How to Install and Secure MariaDB on RHEL 8: Step-by-Step Guide

 How to Install and Secure MariaDB on RHEL 8: Step-by-Step

Introduction

MariaDB is a popular open-source database management system, often chosen for its speed, reliability, and open development model. If you're working with Red Hat Enterprise Linux (RHEL) 8 and want to set up a MariaDB server, . This guide will walk you through the complete installation process of MariaDB on RHEL 8, from adding the necessary repositories to securing your database server.

Preparing Your RHEL 8 System

Before installing MariaDB, ensure your system is up-to-date to avoid compatibility issues and have the latest security patches.

Step 1: Update Your System

Run the following command to update all packages:

sudo dnf update -y

Updating your system ensures that you're starting from a clean and secure environment.

---

2. Adding the Official MariaDB Repository

RHEL 8's default package repositories do not always contain the latest version of MariaDB. Adding the official MariaDB repository allows you to install and update MariaDB easily.

Step 2: Create a MariaDB Repository File

1. Create a new repo file for MariaDB in /etc/yum.repos.d/.

   sudo  /etc/yum.repos.d/MariaDB.repo <<EOF
   [mariadb]
   name = MariaDB
   baseurl = http://yum.mariadb.org/10.5/rhel8-amd64
   gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
   gpgcheck=1
   EOF
   

   Replace 10.5 with the version of MariaDB you wish to install. You can check the MariaDB download page for available versions.

2. Import the GPG Key To verify the packages, import MariaDB’s official GPG key:

   
   sudo rpm --import https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
   

---

3. Installing MariaDB

Now that the repository is added, you can proceed with the installation of the MariaDB server and client.

Step 3: Install MariaDB Server and Client

sudo dnf install -y MariaDB-server MariaDB-client

The -y flag automatically answers "yes" to prompts during the installation process.

---

4. Starting and Enabling MariaDB Service

Once MariaDB is installed, the next step is to start and enable it so it automatically starts on boot.

Step 4: Start the MariaDB Service

sudo systemctl start mariadb

This starts the MariaDB server, which will now be running in the background.

Step 5: Enable MariaDB to Start on Boot

sudo systemctl enable mariadb

Enabling MariaDB ensures that it starts automatically whenever your system boots.

Step 6: Verify the Service Status

To confirm that MariaDB is active and running, use the following command:

sudo systemctl status mariadb

---

5. Securing the MariaDB Installation

It’s crucial to secure your MariaDB installation by setting a root password, removing anonymous users, and restricting remote root access.

Step 7: Secure MariaDB with mysql_secure_installation

sudo mysql_secure_installation

During this process, you will be prompted to:

• Set a strong root password.
• Remove anonymous users.
• Disallow root login remotely.
• Remove test databases and access to them.
• Reload privilege tables to apply changes.

Answer the prompts as recommended to harden your MariaDB installation.

---

6. Verifying the Installation

After securing your installation, confirm that MariaDB is properly installed and configured.

Step 8: Access the MariaDB Shell

sudo mysql -u root -p

You’ll be prompted for the root password you set during the mysql_secure_installation process.

Step 9: Check the MariaDB Version

Once inside the MariaDB shell, run the following command to verify the version:

SELECT VERSION();

Step 10: Exit the MariaDB Shell

exit;

---

7. Configuring Firewall for MariaDB Access

If your RHEL system uses firewalld, you'll need to open port 3306 for MariaDB to allow external connections.

Step 11: Allow MariaDB Through the Firewall

sudo firewall-cmd --permanent --zone=public --add-service=mysql
sudo firewall-cmd --reload

These commands allow traffic on port 3306, which is MariaDB's default port.

Step 12: Verify Firewall Rules

sudo firewall-cmd --list-all

This confirms that the mysql service is allowed through the firewall.

---

8. Configuring MariaDB for Optimal Performance

MariaDB's configuration file is typically located at /etc/my.cnf.d/mariadb-server.cnf. For optimal performance, you may need to make adjustments based on your server's specifications and the workload.

Step 13: Edit the Configuration File

sudo nano /etc/my.cnf.d/mariadb-server.cnf

Step 14: Recommended Settings for Better Performance

Add or modify the following parameters in the [mysqld] section:

[mysqld]
bind-address = 0.0.0.0                # Allow remote connections
max_connections = 200                 # Adjust as per your application needs
innodb_buffer_pool_size = 1G          # Set to 60-80% of server memory for InnoDB
innodb_log_file_size = 256M           # Optimize based on write load
character-set-server = utf8mb4        # Use UTF-8 encoding for broad compatibility
collation-server = utf8mb4_general_ci

Step 15: Restart MariaDB to Apply Changes

sudo systemctl restart mariadb

---

9. Creating a Test Database and User

It’s a good idea to create a test database and user to confirm everything is working as expected.

Step 16: Create a Test Database and User

1. Login to MariaDB

   sudo mysql -u root -p

2. Create a Database

   CREATE DATABASE test_db;

3. Create a User and Grant Privileges

   CREATE USER 'test_user'@'localhost' IDENTIFIED BY 'secure_password';
   GRANT ALL PRIVILEGES ON test_db.* TO 'test_user'@'localhost';
   FLUSH PRIVILEGES;
   

4. Exit the MariaDB Shell

   exit;

---

10. Test the New User Access

You can test access to the new database using the newly created user:

mysql -u test_user -p -D test_db

Enter the password set for test_user to confirm that you can access the test_db database.

Comparison of MariaDB and MySQL

 Comparison of MariaDB and MySQL

This table summarizes the key differences between MariaDB and MySQL, covering aspects like development philosophy, licensing, features, and performance.

 

Daily DBA Scripts for MariaDB

 MariaDB: Essential DBA Practices for Daily Operations

Introduction

MariaDB, a popular open-source relational database, offers high performance, flexibility, and scalability. However, managing a MariaDB database on a day-to-day basis requires constant vigilance and optimization. As a Database Administrator (DBA), having a toolkit of scripts and monitoring techniques is crucial to ensure that your database runs smoothly and efficiently.

In this post, we'll explore essential MariaDB scripts, DBA best practices, and performance tips that can help you maintain and optimize your database operations.

---

Daily DBA Scripts for MariaDB

A DBA’s daily tasks include health checks, performance monitoring, backup routines, and identifying optimization opportunities. Below are some of the fundamental scripts to make your daily operations smooth and manageable.

1. Checking Database Health and Status

To start your day as a DBA, you should quickly check the health and status of your MariaDB server. This provides a snapshot of uptime, connections, and overall performance.

SHOW GLOBAL STATUS;
SHOW VARIABLES LIKE 'version';
SHOW VARIABLES LIKE 'uptime';
SHOW VARIABLES LIKE 'max_connections';

The above script provides details like server version, uptime, and the maximum number of connections, ensuring everything is functioning properly.

---

2. Monitoring Connections and Load

Active connections and thread status directly impact the performance and availability of your database. Monitoring these metrics helps to identify potential overloading issues.

SHOW STATUS LIKE 'Threads%';
SHOW STATUS LIKE 'Connections';
SHOW STATUS LIKE 'Aborted_connects';

By keeping an eye on threads and connections, you can anticipate potential bottlenecks and avoid system overloads.

---

3. Identifying and Optimizing Slow Queries

One of the most significant tasks for a DBA is identifying slow queries that could degrade the performance of your database.

Enable and Monitor the Slow Query Log:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1; -- Log queries taking longer than 1 second
SHOW GLOBAL STATUS LIKE 'Slow_queries';

Slow queries are a major factor in database performance issues. Regularly reviewing and optimizing these queries can greatly improve overall efficiency.

---

4. Monitoring Database and Table Sizes

Understanding the size and growth rate of your tables and databases helps manage storage and allows for capacity planning.

SELECT table_schema AS 'Database', 
       ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS 'Size (MB)'
FROM information_schema.tables
GROUP BY table_schema
ORDER BY SUM(data_length + index_length) DESC;

This script helps identify the largest databases and tables, helping you manage disk space effectively.

---

5. Checking Index Usage and Efficiency

Indexes are vital for efficient data retrieval. Monitoring and analyzing index usage ensure your queries are running as fast as possible.

SHOW INDEX FROM your_table_name;

Regularly reviewing indexes allows you to ensure that they are being used correctly and that the correct columns are indexed for your query patterns.

---

6. Viewing Running Queries and Processes

Keeping an eye on currently running queries helps identify and troubleshoot long-running processes.

SHOW FULL PROCESSLIST;

If you find a problematic query, you can terminate it using its process ID:

KILL query_id;

This is particularly useful when a query is blocking resources or taking too long to execute.

---

7. Monitoring and Managing Replication

If your environment uses replication, it is crucial to check its status to ensure that data is being replicated correctly and timely.

SHOW SLAVE STATUS\G
SHOW MASTER STATUS;

Monitoring replication helps maintain data consistency and availability in a distributed setup.

---

8. Regular Backups for Data Protection

Backing up databases is one of the most critical tasks for a DBA. An automated daily backup script ensures that your data is safe.

#!/bin/bash

USER="root"
PASSWORD="your_password"
BACKUP_DIR="/backup/mariadb"
DATE=$(date +%Y%m%d)

mkdir -p "$BACKUP_DIR"
mysqldump -u "$USER" -p"$PASSWORD" --all-databases > "$BACKUP_DIR/all_databases_$DATE.sql"

Make sure to schedule this script using cron jobs or any other scheduling tool to have daily backups ready for disaster recovery.

---

9. Reviewing User Privileges

Ensuring proper user access helps maintain security and prevents unauthorized access to critical data.

SELECT user, host, db, table_name, column_name, privilege_type 
FROM information_schema.column_privileges;

Following the principle of least privilege ensures that users only have the access necessary for their roles.

---

Performance Tips for Monitoring and Optimization

To maintain a high-performance MariaDB environment, active monitoring and optimization are required. Here are some tips to help improve database performance:

1. Use EXPLAIN for Query Optimization

Before executing a query, use EXPLAIN to understand how MariaDB processes it. This allows you to make necessary optimizations.

EXPLAIN SELECT * FROM your_table WHERE column = 'value';

If you see ALL in the type column, it indicates a full table scan, which is a performance red flag. Use indexing and query refactoring to improve performance.

---

2. Set Up Alerts for Critical Performance Metrics

Use monitoring tools like Nagios, Zabbix, or built-in MariaDB monitoring tools to set up alerts for:

• High CPU load
• Memory usage spikes
• Disk I/O saturation
• Slow queries exceeding a threshold

Proactive alerting ensures you can address issues before they affect users.

---

3. Enable Query Caching (If Applicable)

MariaDB offers query caching to speed up frequently executed, unchanged queries.

SET GLOBAL query_cache_size = 16M; -- Enable with size
SET GLOBAL query_cache_type = 'ON';

Monitor cache efficiency:

SHOW STATUS LIKE 'Qcache%';

Note: Query cache is effective only when queries and data don’t change frequently.

---

4. Monitor and Rotate Logs

Regularly monitor log files to track query performance, errors, and general database activity.

cat /var/log/mysql/error.log

Rotate logs using logrotate to prevent disk space issues:

FLUSH LOGS;

---

5. Regularly Optimize Tables

Defragmenting tables by running OPTIMIZE TABLE can help improve performance and reclaim unused space.

OPTIMIZE TABLE your_table_name;

Regularly running OPTIMIZE TABLE on frequently updated tables can enhance performance.

---

6. Leverage Performance Schema for Advanced Monitoring

The Performance Schema provides in-depth metrics about resource usage, memory, and locking.

SET GLOBAL performance_schema = 'ON';
SELECT * FROM performance_schema.events_statements_current;

By leveraging this schema, you can track down performance bottlenecks at a more granular level.

---

Conclusion

As a MariaDB DBA, the health, performance, and security of your database are in your hands. The scripts and best practices provided in this guide will help you proactively manage your database, maintain optimal performance, and prepare for any issues that may arise. Remember, constant monitoring and optimization are key to a well-managed MariaDB environment.