Schedule icon
Query icon
If icon
SlackIncomingWebhook icon
Log icon

MySQL Replica IO Thread Stagnation and Lag Sentinel

Automated MySQL replication lag monitoring with Kestra. Query SHOW REPLICA STATUS and alert Slack on replication thread stoppage or lag spikes.

Categories
DataInfrastructure

MySQL read replicas are critical for offloading read traffic from primary database masters and serving as hot standby targets. If network latency surges, intensive long-running writes block the SQL thread, or binary log coordinates desynchronize, the replica falls behind (Seconds_Behind_Master) or stops replication entirely.

This blueprint connects to MySQL replicas via JDBC, executes SHOW REPLICA STATUS, evaluates Seconds_Behind_Master, Replica_IO_Running, and Replica_SQL_Running, and immediately alerts database administrators via Slack when replication halts or breaches latency SLAs.

How it works

  1. periodic_replication_lag_check runs on a 5-minute schedule.
  2. check_replica_status executes SHOW REPLICA STATUS via JDBC to fetch current replication telemetry.
  3. evaluate_replication_health evaluates whether Replica_IO_Running == 'Yes', Replica_SQL_Running == 'Yes', and Seconds_Behind_Master is below threshold.
  4. If threads are halted or lag exceeds threshold, alert_dba_slack dispatches an urgent diagnostic alert to Slack.
  5. If replication is synchronized, log_replication_healthy records normal operation.
  6. errors block catches connection drops or query failures.

What you get

  • Automated detection of broken replication threads (Last_Error) and lag spikes.
  • Zero dedicated replication monitoring agents required.
  • Rich Slack notifications with replica coordinates and error details.

Who it's for

  • Database Administrators (DBAs) managing MySQL read replicas and High Availability.
  • Backend and Platform Engineers routing read queries to secondary nodes.
  • SREs maintaining database uptime SLAs.

Why orchestrate this with Kestra

Kestra features native JDBC MySQL plugins that query replication state directly, evaluate status parameters with Pebble expressions, and route alerts seamlessly without custom daemon scripts.

Prerequisites

  • MySQL 5.7+ / 8.0+ replica database.
  • Database user with REPLICATION CLIENT privileges.
  • A Slack incoming webhook URL.

Secrets

  • MYSQL_PASSWORD: Password for the MySQL monitor user.
  • SLACK_WEBHOOK: Incoming Webhook URL for Slack alerts.

Inputs

  • database_host: MySQL replica host address.
  • database_port: MySQL port (default: 3306).
  • database_name: Database name.
  • database_username: Database user name.
  • max_seconds_behind_master_threshold: Allowed replication lag in seconds (default: 300).

Quick start

  1. Import this blueprint into your Kestra instance.
  2. Configure the MYSQL_PASSWORD and SLACK_WEBHOOK secrets.
  3. Run manually to test replica connectivity.
  4. Enable the schedule trigger for continuous sentinel monitoring.

How to extend

  • Add automated tasks to temporarily drain traffic from lagging replicas.
  • Route critical alerts to PagerDuty or OpsGenie.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.