Databases
    Updated May 2026
    MariaDB logo

    MariaDB Monitoring

    Monitor MariaDB InnoDB buffer pool, slow queries, replication lag, and Galera Cluster `wsrep_*` state (cluster size, flow control, donor/joiner) in real time — the MariaDB-specific signals MySQL monitoring misses.

    Start Free TrialView Docs

    Why monitor MariaDB?

    MariaDB is the default database on most cPanel hosts and the standard for Galera HA clusters. When the cluster loses quorum, flow control kicks in, or one node falls out of sync, every site on the box can suddenly go read-only. Monitoring surfaces cluster state before split-brain or stuck connections.

    Auto-discovery via Xitogent — no manual configuration required
    Real-time query throughput and slow query detection
    InnoDB buffer pool hit ratio and page metrics
    Replication lag and slave status monitoring
    Connection pool usage and thread state tracking
    Table lock and deadlock detection
    Works on both Linux and Windows servers
    1-minute metric collection intervals
    What is MariaDB monitoring?

    MariaDB monitoring, explained

    MariaDB monitoring catches Galera cluster instability, replication drift, slow queries, and connection saturation before they cause split-brain, replica failover storms, or hosting-account-wide slowness. For cPanel WordPress hosts, Galera HA clusters, and any MariaDB workload, per-database visibility plus Galera-specific wsrep_* state is what separates a clean 30-second failover from a multi-hour outage. Xitoring auto-discovers your MariaDB, reads native status views plus Galera state, and routes alerts to Slack, PagerDuty, Telegram, or your existing on-call.

    Metrics

    What we monitor

    Queries per Second

    Rate of SELECT, INSERT, UPDATE, and DELETE statements.

    Slow Queries

    Number of queries exceeding the configured long_query_time threshold.

    InnoDB Buffer Pool Hit Rate

    Percentage of page reads served from buffer pool vs disk.

    InnoDB Row Operations

    Rate of row reads, inserts, updates, and deletes in InnoDB.

    Connections

    Active threads, connected threads, and max_connections usage.

    Thread States

    Distribution of thread states (running, sleeping, locked, etc.).

    Replication Lag

    Seconds_Behind_Master and slave I/O/SQL thread status.

    Table Locks

    Table lock waits and immediate lock acquisitions.

    Temporary Tables

    Rate of temporary tables created on disk vs in memory.

    Binary Log

    Binary log size and event count for replication tracking.

    Aborted Connections

    Failed connection attempts and aborted client connections.

    Handler Operations

    Handler read/write rates indicating storage engine activity.

    Triggers & Alerts

    Configurable alert triggers

    Set up custom triggers in your dashboard to get notified the moment MariaDB metrics cross your defined thresholds.

    MariaDB monitoring trigger configuration dashboard

    Replication Lag

    critical

    Fires when slave falls behind master, risking data inconsistency and stale reads.

    Slow Queries

    warning

    Triggers when slow query rate exceeds threshold, indicating unoptimized queries or missing indexes.

    Buffer Pool Hit Rate

    warning

    Alerts when InnoDB buffer pool hit ratio drops, causing increased disk I/O.

    Connection Usage

    critical

    Fires when active connections approach max_connections, risking connection refused errors.

    Table Lock Waits

    warning

    Triggers when table lock contention increases, degrading concurrent query performance.

    Aborted Connections

    critical

    Alerts when connection failures spike, indicating authentication issues or network problems.

    01

    Importance of MariaDB Monitoring

    MariaDB handles critical data for web applications, e-commerce platforms, and enterprise systems. Without monitoring, slow queries, replication drift, and connection exhaustion can silently degrade user experience and risk data loss.

    • Detect slow queries before they impact application response times
    • Monitor InnoDB buffer pool efficiency to optimize memory allocation
    • Track replication health to ensure read replicas stay consistent
    • Identify connection pool exhaustion from application servers
    • Prevent table lock contention in high-concurrency environments
    MariaDB monitoring dashboard with query throughput and InnoDB metrics
    MariaDB performance analysis with connection pool and lock monitoring
    02

    Why Choose Xitoring

    Xitoring delivers enterprise-grade MariaDB monitoring with zero-config setup. Our lightweight agent auto-discovers your MariaDB instances, starts collecting metrics in under 60 seconds, and integrates with your existing notification channels.

    • One-command install — no complex YAML or config files
    • 15+ global monitoring nodes for low-latency checks
    • Unified dashboard for servers, databases, and uptime
    • Flexible alerting via Slack, PagerDuty, Telegram & more
    • Historical data retention for capacity planning & audits
    Xitoring MariaDB monitoring overview
    Alert notification channels configuration
    Use cases

    Common MariaDB monitoring scenarios

    Where MariaDB typically runs today — and what could go wrong if no one's watching.

    WordPress and other websites on hosting servers

    When many websites share the same database server, one slow plugin or runaway query can quietly drag down every site on the box. We pinpoint where the slowdown is coming from so the team can fix the source instead of restarting blindly.

    Clusters that stay online during failures

    Production setups run several copies of the database so one failure can't bring the app down. When the copies disagree or lose contact with each other, the whole cluster can suddenly stop accepting changes. We catch the drift early so the safety net keeps working.

    Databases sitting behind a connection gateway

    A connection gateway in front of the database speeds up queries and shields the database from connection storms — but it adds a moving part. We watch both layers as one unit so issues are caught in whichever piece introduced them, not after they cascade.

    Before you start

    Prerequisites for MariaDB

    Make sure you've got these in place — most installs are a 60-second job once they are.

    • MariaDB 10.11 LTS, 11.4 LTS, or 11.8 LTS running on the server
    • performance_schema = ON in the [mysqld] section
    • A monitoring user with PROCESS, REPLICATION CLIENT, and SELECT on performance_schema (plus SUPER or REPLICATION_CLIENT for Galera wsrep_* status on cluster nodes)
    Setup Guide

    Get started in minutes

    1

    Install Xitogent on your server

    If you haven't already, install the lightweight Xitogent monitoring agent on your server.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Create a monitoring user

    Create a dedicated MariaDB user for metric collection with minimal privileges:

    CREATE USER 'xitoring'@'%' IDENTIFIED BY 'your_password'; GRANT REPLICATION CLIENT ON *.* TO 'xitoring'@'%' WITH MAX_USER_CONNECTIONS 5; GRANT PROCESS ON *.* TO 'xitoring'@'%'; GRANT SELECT ON performance_schema.* TO 'xitoring'@'%'; FLUSH PRIVILEGES;
    3

    Enable the MariaDB integration

    Use the Xitoring dashboard or CLI to enable the MariaDB integration.

    sudo xitogent integrate
    4

    Configure alert thresholds (optional)

    Set custom thresholds for query rate, buffer pool hit ratio, or replication lag to get notified when something needs attention.

    5

    Verify it's working

    Run this command on the server to confirm Xitogent picked up the integration. Fresh metrics will start streaming to your dashboard within ~30 seconds.

    sudo xitogent status
    Compare

    Considering alternatives?

    See how Xitoring stacks up against the alternatives for MariaDB monitoring — flat pricing, deeper integrations, and one agent that covers your whole stack.

    See all comparisons

    Frequently asked questions

    What is MariaDB monitoring?
    MariaDB monitoring is the continuous collection of database performance data — threads, query throughput, InnoDB buffer pool hit ratio, slow queries, replication lag, deadlocks — PLUS the MariaDB-specific Galera Cluster `wsrep_*` namespace (cluster status, flow control, donor/joiner state, member count) — combined with alerting when those metrics breach thresholds. The Galera signals are what separates MariaDB monitoring from generic MySQL monitoring.
    How is MariaDB monitoring different from MySQL?
    The core engine vocabulary is shared (Threads_connected, Innodb_buffer_pool_*, Slow_queries). MariaDB diverges in: (1) Galera Cluster monitoring uses the `wsrep_*` namespace — completely absent from vanilla MySQL; (2) tools like MariaDB MaxScale and ClusterControl; (3) ColumnStore and Spider storage engines; (4) ThreadPool plugin connection model; (5) replication GTID format differs from MySQL's. Use this integration for MariaDB and Galera; use the dedicated MySQL integration for MySQL/RDS/Aurora.
    How do I monitor a MariaDB Galera Cluster?
    Xitogent reads the `wsrep_*` status namespace on each cluster node: `wsrep_cluster_status` (Primary = quorum healthy; Non-Primary = quorum lost, cluster goes read-only), `wsrep_cluster_size` (split-brain detection), `wsrep_local_state_comment` (Synced/Donor/Desync/Joiner/Joined), `wsrep_local_recv_queue_avg` (apply backpressure), `wsrep_flow_control_paused` (replication-throttling time fraction). Alert on quorum loss, donor state lasting > expected SST window, and flow control > 0.1.
    What does wsrep_local_state_comment mean?
    It's the human-readable cluster member state. Healthy steady state: `Synced` (replicating and accepting writes). Transitional: `Joiner` (receiving state transfer), `Joined` (state transfer complete, catching up), `Donor`/`Desynced` (providing SST to another node — read/write capable but counted as desynced). Persistent non-`Synced` state outside of expected operations is a problem. Xitogent surfaces transitions in real time.
    How do I detect Galera flow control bottlenecks?
    `wsrep_flow_control_paused` is the fraction of time (0.0–1.0) the cluster paused writes due to a slow node falling behind on apply. Values above 0.1 mean a node can't keep up — usually CPU-bound apply, slow disk, or `gcs.fc_limit` set too low. Pair with `wsrep_local_recv_queue_avg` to identify the lagging node. Tune by increasing apply threads (`wsrep_slave_threads`) or scaling node hardware.
    How do I monitor MariaDB on cPanel / Plesk?
    On cPanel/Plesk hosts, MariaDB usually runs as a single instance fronting all customer databases. Install Xitogent on the host, grant the monitoring user `PROCESS`, `REPLICATION CLIENT`, and `SELECT` on `performance_schema`, and Xitogent picks up per-database stats automatically. Per-database query counts and slow query rates surface the noisy account before it slows every site on the box.
    What is MariaDB MaxScale and how do I monitor it?
    MaxScale is MariaDB's official proxy for query routing, R/W splitting, and connection pooling. Monitor MaxScale's own health endpoints alongside the MariaDB integration for per-backend state, current connections, and routing decisions. Together they give you full request-path visibility from app → MaxScale → MariaDB backend nodes.
    Can I monitor multiple MariaDB instances on one server?
    Yes. Run multiple MariaDB instances on different ports (or in containers) and configure Xitogent with each socket/host+port — every instance is tracked separately in the dashboard with its own metrics, alerts, and history. Useful for staging+production on the same box, or per-tenant database isolation.
    What MariaDB versions are supported?
    MariaDB 10.11 LTS, MariaDB 11.4 LTS, and MariaDB 11.8 LTS (current, with vector search) are fully supported, plus standalone or Galera-clustered deployments. The integration auto-detects whether Galera is active and surfaces `wsrep_*` metrics only on cluster nodes. ColumnStore, Spider, and ThreadPool plugins are detected and surfaced where present.

    Start monitoring MariaDB today

    Set up in under 60 seconds. No credit card required. Full metrics from day one.

    Start Free Trial

    Keep exploring

    Related Integrations