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

OceanBase Major Compaction Stall & Auto-Resume Sentinel

Audit OceanBase CDB_OB_MAJOR_COMPACTION for suspended or errored merges, dispatch Slack incident alerts, and automate ALTER SYSTEM RESUME MERGE.

Categories
DataInfrastructure

OceanBase is an enterprise distributed relational database featuring a hybrid LSM-tree storage architecture. Dynamic writes and transaction updates land continuously in active memory tables (MemTables). During scheduled or triggered daily major freezes, OceanBase compacts and merges in-memory data with static baseline SSTables via Major Compaction. If major compaction becomes suspended (IS_SUSPENDED = 'YES') or encounters fatal errors (IS_ERROR = 'YES'), memory occupied by frozen MemTables cannot be recycled. If MemTable memory exhaustion occurs, write operations across all user tenants stall (OB_ALLOCATE_MEMORY_FAILED -4013), disrupting mission-critical transactional services. This blueprint provides automated continuous surveillance over oceanbase.CDB_OB_MAJOR_COMPACTION, detects suspended or degraded compactions, alerts operations via Slack, and automates safe remediation using ALTER SYSTEM RESUME MERGE TENANT = all_user.

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_major_compaction_health) connects to OceanBase over the MySQL wire protocol (port 2881) via io.kestra.plugin.jdbc.mysql.Query and queries oceanbase.CDB_OB_MAJOR_COMPACTION for any tenants where compaction is suspended, errored, or stalled.
  3. Classification logic evaluates query output using Pebble templating, discerning whether any tenant compactions are suspended or errored (CRITICAL), all operating normally (HEALTHY), or if the database connection failed (PROBE_FAILED).
  4. Routing task (route_by_compaction_health) switches execution along dedicated paths according to the classified severity.
  5. On CRITICAL state, structured Slack incident cards notify operations channels with impacted cluster endpoints, tenant counts, failure diagnostics, and remediation states.
  6. Guarded remediation (check_remediation) checks whether auto_resume is enabled and dry_run is disabled. If confirmed, execute_resume_merge dispatches ALTER SYSTEM RESUME MERGE TENANT = all_user; to unblock suspended merges across user tenants.
  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 tenant counts to task logs.

What you get

  • Automated continuous surveillance of OceanBase LSM-tree major compaction across all cluster tenants.
  • Early detection of suspended merges and error states before MemTable memory exhaustion triggers write stalls.
  • Automated self-healing cluster unfreeze capabilities executing ALTER SYSTEM RESUME MERGE.
  • Differentiated operational alerting directing DBAs straight to affected tenant IDs and error messages.
  • Full execution traceability and audit logging without leaking database credentials in logs or alert payloads.

Who it's for

  • Database Administrators and SREs managing high-throughput production OceanBase clusters.
  • Platform Engineers responsible for distributed transactional database availability and SLA compliance.
  • Data Infrastructure Teams deploying large-scale OLTP and HTAP workloads on OceanBase.

Why orchestrate this with Kestra

  • Declarative YAML definition unifies distributed storage maintenance, conditional severity triage, and automated self-healing into version-controlled GitOps workflows.
  • Native MySQL JDBC plugin connectivity communicates directly with OceanBase'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 compaction recovery timelines and cluster maintenance cycles.
  • Cloud-native scheduling and flow-level error-trapping ensure continuous sentinel operation independent of external cron infrastructure.

Prerequisites

  • OceanBase cluster running with MySQL wire compatibility enabled (default port 2881).
  • Database user with read permissions on oceanbase.CDB_OB_MAJOR_COMPACTION and administrative privileges to run ALTER SYSTEM RESUME MERGE.
  • Slack incoming webhook URL for operational incident dispatch.

Secrets

  • OCEANBASE_USERNAME: Username for authenticating to the OceanBase MySQL wire interface (e.g. root@sys).
  • OCEANBASE_PASSWORD: Password for the OceanBase database user.
  • SLACK_WEBHOOK_URL: Incoming webhook URL for posting incident cards to Slack.

Quick start

  1. Configure OCEANBASE_USERNAME, OCEANBASE_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 OceanBase cluster.
  3. Review the execution log in the Kestra UI to verify major compaction query execution from oceanbase.CDB_OB_MAJOR_COMPACTION.
  4. Enable the every_fifteen_minutes schedule trigger to activate automated continuous monitoring and remediation.

How to extend

  • Add OBServer node status checks via oceanbase.GV$OB_SERVERS to detect hardware disk faults causing compaction stalls.
  • Integrate PagerDuty alerting via io.kestra.plugin.pagerduty.notifications.PagerDutyAlert for immediate escalation during severe cluster-wide compaction freezes.
  • Attach tenant resource unit inspection via oceanbase.DBA_OB_TENANTS to detect memory watermark breaches.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.