Schedule icon
RedisCLI icon
Switch icon
SlackIncomingWebhook icon
If icon
Log icon

KeyDB Active-Replica Multi-Master Peering Sentinel

Audit KeyDB active-replica multi-master replication links, detect peering dropouts, dispatch Slack alerts, and automate REPLICAOF healing.

Categories
DataInfrastructure

KeyDB is an open-source, multithreaded alternative to Redis engineered for high-throughput caching and in-memory key-value processing. A cornerstone capability of KeyDB is Active-Replica (multi-master) replication, wherein two or more instances are configured with active-replica yes to accept concurrent write and read operations while synchronizing mutations bidirectionally. In production, transient cross-datacenter network partitions, high CPU thread starvation, or peer process restarts can sever the active peering connection, flipping master_link_status or master_global_link_status to down. When an active-replica link drops, both nodes continue serving independent application writes, resulting in diverging key state and potential reconciliation conflicts. This blueprint provides automated continuous surveillance over INFO replication, detects severed peering links, alerts operations via Slack, and automates safe remediation using REPLICAOF reconnection commands.

How it works

  1. Scheduled trigger (every_fifteen_minutes) initiates diagnostic health verification every 15 minutes, with manual runs supported via customizable inputs.
  2. Diagnostic probe (probe_replication_info) connects to the local KeyDB instance over the Redis wire protocol (port 6379) via io.kestra.plugin.redis.cli.RedisCLI and executes INFO replication.
  3. Classification logic evaluates the command output using Pebble templating, discerning whether any peering links are down (CRITICAL), if synchronization is in progress (WARNING), if all links are up (HEALTHY), or if the instance connection failed (PROBE_FAILED).
  4. Routing task (route_by_replication_health) switches execution along dedicated paths according to the classified severity.
  5. On CRITICAL or WARNING states, structured Slack incident cards notify operations channels with local node endpoints, companion peer addresses, and remediation statuses.
  6. Guarded remediation (check_remediation) checks whether auto_reconnect is enabled and dry_run is disabled. If confirmed, execute_reconnect dispatches REPLICAOF <peer_host> <peer_port> via RedisCLI to re-establish active-replica synchronization.
  7. On PROBE_FAILED, dedicated alerts notify administrators of unreachable ports or authentication failures.
  8. Audit log task (log_audit_summary) writes execution metadata and classified status to task logs.

What you get

  • Automated continuous surveillance of KeyDB active-replica multi-master peering health.
  • Early detection of severed bidirectional replication links before data divergence widens.
  • Automated self-healing reconnection executing REPLICAOF commands without manual administrator intervention.
  • Differentiated incident routing separating active network disconnections from transient background syncs.
  • Full execution traceability and audit logging without leaking database credentials in logs or alert payloads.

Who it's for

  • Platform Engineers and SREs maintaining high-availability KeyDB active-active caching clusters.
  • Database Administrators managing multithreaded in-memory data tiers and real-time session stores.
  • Backend Architects relying on multi-master low-latency key-value stores for distributed microservices.

Why orchestrate this with Kestra

  • Declarative YAML definition unifies distributed cache peering surveillance, conditional severity triage, and automated self-healing into version-controlled GitOps workflows.
  • Native Redis CLI plugin connectivity communicates directly with KeyDB's native wire protocol without external agent daemons or Python container overhead.
  • Built-in conditional routing and dry-run safety gates isolate discovery from remediation commands.
  • Immutable execution history provides operational evidence documenting peering recovery timelines and network degradation intervals.
  • Cloud-native scheduling and flow-level error-trapping ensure continuous sentinel operation independent of external cron infrastructure.

Prerequisites

  • KeyDB cluster running with active-replica yes enabled (default port 6379).
  • Network connectivity permitting TCP communication from Kestra to KeyDB instances.
  • Slack incoming webhook URL for operational incident dispatch.

Secrets

  • KEYDB_PASSWORD: Password for authenticating to the KeyDB instance via RedisCLI (optional if protected mode disabled).
  • SLACK_WEBHOOK_URL: Incoming webhook URL for posting incident cards to Slack.

Quick start

  1. Configure KEYDB_PASSWORD (if applicable) and SLACK_WEBHOOK_URL in your Kestra namespace secrets.
  2. Deploy this blueprint to your Kestra instance and trigger an initial run with dry_run: true to verify connectivity against your KeyDB server.
  3. Review the execution log in the Kestra UI to verify INFO replication output parsing.
  4. Enable the every_fifteen_minutes schedule trigger to activate automated continuous monitoring and remediation.

How to extend

  • Add companion node inspection to probe both multi-master nodes simultaneously and compare replication offsets.
  • Integrate PagerDuty alerting via io.kestra.plugin.pagerduty.notifications.PagerDutyAlert for persistent multi-master split-brain outages.
  • Attach memory fragmentation checks using INFO memory to identify allocator pressure across worker threads.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.