Schedule icon
Query icon
Switch icon
SlackIncomingWebhook icon
If icon
Log icon

CrateDB Shard Allocation and Cluster Reroute Sentinel

Audit CrateDB sys.shards for unassigned primary and replica partitions, dispatch Slack incident alerts, and automate ALTER CLUSTER REROUTE commands.

Categories
DataInfrastructure

CrateDB is a distributed, open-source SQL database built on Lucene, optimized for machine data, IoT telemetry, and real-time analytical workloads. In a distributed CrateDB cluster, data tables are partitioned across primary and replica shards distributed across cluster nodes. When data nodes restart, suffer transient network partitions, or encounter temporary disk watermarks, shards can fail allocation and remain stuck in UNASSIGNED states. Unassigned primary shards cause immediate query failures and partition unreachability, while unassigned replica shards leave tables vulnerable to complete data loss if an active node fails. This blueprint provides automated surveillance over sys.shards, detects unassigned primary and replica states, alerts engineering teams via Slack, and automates safe cluster rerouting using ALTER CLUSTER REROUTE RETRY FAILED.

How it works

  1. Scheduled trigger (every_fifteen_minutes) initiates cluster health checks every 15 minutes, with manual runs supported via customizable inputs.
  2. Diagnostic probe (probe_unassigned_shards) connects to CrateDB over the PostgreSQL wire protocol (port 5432) via io.kestra.plugin.jdbc.postgresql.Query and queries sys.shards for any partitions whose routing state is not STARTED.
  3. Classification logic evaluates the query output using Pebble templating, discerning whether any unassigned partitions are primaries (CRITICAL), replicas only (WARNING), none (HEALTHY), or if the database connection failed (PROBE_FAILED).
  4. Routing task (route_by_health) branches execution along dedicated handling paths according to the classified severity.
  5. On CRITICAL or WARNING states, structured Slack incident cards notify operations channels with impacted cluster endpoints, shard counts, and partition severities.
  6. Guarded remediation (check_remediation) checks whether auto_reroute is enabled and dry_run is disabled. If confirmed, execute_reroute_retry dispatches ALTER CLUSTER REROUTE RETRY FAILED; to re-trigger allocation for stuck shards without administrative intervention.
  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 evaluated shard metrics to task logs.

What you get

  • Automated continuous surveillance of CrateDB shard routing states across all cluster schemas and tables.
  • Differentiated incident alerting separating critical primary partition drops from degraded replica allocations.
  • Automated self-healing cluster reroute capabilities that safely resolve transient shard allocation failures.
  • Safe operational gating with dry-run toggles and permission separation via namespace secrets.
  • Full execution traceability and audit logging without leaking database credentials in logs or alert payloads.

Who it's for

  • Platform Engineers and SREs maintaining production CrateDB clusters for IoT, logging, and metrics.
  • Database Administrators managing distributed storage partitions and replica durability.
  • Data Engineers deploying real-time telemetry ingestion pipelines that depend on constant table write availability.

Why orchestrate this with Kestra

  • Declarative YAML definition consolidates cluster health monitoring, conditional severity branching, and automated self-healing into version-controlled GitOps workflows.
  • Native PostgreSQL JDBC plugin connectivity connects directly to CrateDB's native wire protocol without external agent binaries or Python container overhead.
  • Built-in conditional routing and dry-run safety gates isolate discovery from remediation commands.
  • Immutable execution history provides cryptographic compliance and operational logs documenting cluster recovery actions.
  • Resilient error trapping ensures cluster monitoring failures trigger immediate operational escalations.

Prerequisites

  • CrateDB cluster running with PostgreSQL wire compatibility enabled (default port 5432).
  • Database user with read access to sys.shards and administrative permissions to run ALTER CLUSTER REROUTE.
  • Slack incoming webhook URL for operational incident dispatch.

Secrets

  • CRATEDB_USERNAME: Username for authenticating to the CrateDB PostgreSQL wire interface (e.g. crate).
  • CRATEDB_PASSWORD: Password for the CrateDB database user.
  • SLACK_WEBHOOK_URL: Incoming webhook URL for posting incident cards to Slack.

Quick start

  1. Configure CRATEDB_USERNAME, CRATEDB_PASSWORD, 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 CrateDB cluster.
  3. Review the execution log in the Kestra UI to verify shard query execution from sys.shards.
  4. Enable the every_fifteen_minutes schedule trigger to activate automated continuous monitoring and remediation.

How to extend

  • Add allocation reason diagnostics by querying sys.allocations when unassigned shards persist across consecutive runs.
  • Integrate PagerDuty alerting via io.kestra.plugin.pagerduty.notifications.PagerDutyAlert for immediate on-call escalation during critical primary shard outages.
  • Attach table-level optimization using OPTIMIZE TABLE <table> WITH (max_num_segments = 1) to compact fragmented Lucene segments during off-peak hours.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.