Maximizing Availability During Maintenance on the NetApp Instaclustr Platform

Summary 

Most Instaclustr-managed clusters stay fully available during scheduled maintenance when they are configured for high availability. This guide explains what happens during maintenance requiring a rolling restart, the minimum configuration each technology needs for zero-downtime maintenance, and what to avoid doing while a maintenance window is open. 

What happens during a maintenance window 

Routine maintenance, including operating system patching and minor or major version upgrades, is applied through a rolling restart. Each node in a data centre is taken offline, updated, and brought back one at a time. Your cluster stays up throughout, provided it is configured for the availability levels below. 

Minimum high availability configuration by technology 

  • Cassandra: replication factor 3, client consistency level LOCAL_QUORUM, with a retry policy configured. 
  • Kafka: topics configured with replication factor 3. 
  • Kafka Connect: 3 or more nodes in the cluster. 
  • Zookeeper: 3 or more nodes in the cluster. 
  • OpenSearch: minimum of 1 replica shard on all indices, client configured to connect to multiple nodes or through a load balancer. 
  • PostgreSQL: at least 2 nodes in the cluster. Instaclustr’s automation performs one controlled switchover when the primary node’s turn in the restart cycle arrives; client connection strings need to tolerate a new primary. 
  • Cadence: 2 or more nodes in the cluster. A restarting node briefly loses its share of capacity during its own restart step; this is not a zero-downtime guarantee, but a load-balanced or multi-node client endpoint should not see errors. 
  • ClickHouse: 2 or more replicas per shard. 

If your cluster does not meet the minimum for its technology, plan for a brief availability gap during each node’s restart and size your expectations for the maintenance window accordingly. 

General rules that apply across every technology 

  1. Avoid schema, topology, or configuration changes during a scheduled maintenance window. A rolling restart already puts one node out of service at a time. A concurrent change increases the chance that change lands on, or depends on, the node currently down. 
  2. Configure client-side retry policies. Nearly every scenario below is reduced in severity or eliminated entirely by a client that retries on connection failure instead of surfacing the error immediately and failing. 
  3. Check for an active maintenance event before starting routine maintenance work of your own. Maintenance events are visible in the Instaclustr Console, the Cluster Management API. If one is scheduled or in progress on a cluster, it is your recommended to defer schema changes, for example, until it is complete. 
  4. Confirm clients are still connecting as expected once a maintenance event finishes and contact our support staff if you have any concerns either prior to an upgrade or after upgrade if you have concerns. 
  5. Use exclusion windows for sensitive periods. Most maintenance conflicts are avoidable by using Exclusion Windows either to indicate you are making risky client-side changes or are going through a period of high load or increased stability requirements. 

Per-Technology Detail 

Cassandra 

  • Avoid running TRUNCATE during a maintenance window. It requires every node to be reachable and will fail if even one node is down. Use retry logic or create a new table instead of truncating during periods of maintenance. 
  • Avoid concurrent, overlapping schema changes from multiple clients or applications. This can cause schema disagreement, and an in-progress restart extends the window before it resolves. 
  • CREATE, ALTER, and DROP for keyspaces, tables and indexes generally tolerate a rolling restart and become consistent once all nodes are back up. Keep changes single and sequential rather than concurrent. 

Kafka, Kafka Connect, and Zookeeper 

  • Avoid creating or leaving replication-factor-1 topics on a cluster due for maintenance. RF1 partitions will go completely offline for the duration of the restart. Raise replication factor before the window opens. 
  • Avoid creating very large numbers of topics or partitions right before maintenance. High partition counts slow broker shutdown. 
  • Kafka Connect: don’t assume a failed connector task will restart itself. Restart it explicitly and confirm it succeeded. 
  • Recommended baseline: RF3 on production topics. 

OpenSearch 

  • Avoid creating zero-replica indices and leaving them in place through a maintenance window. A restarted node holding the only shard makes that index unavailable. Set replicas to at least 1 first. 
  • Baseline: at least 1 replica shard on every index, client connected to multiple nodes or a load balancer. 

ClickHouse 

  • Each shard should have at least 2 replicas to support high availability. Instaclustr provisions ClickHouse Keeper on an odd number of nodes (typically three) to maintain quorum and ensure cluster coordination. 

PostgreSQL 

  • For two node clusters with synchronous mode set to strict, writes won’t be acknowledged while the secondary is down for its restart. This configuration is not suitable for high availability. 
  • Don’t assume a single-node cluster stays available during maintenance. No failover target means a full, however brief outage. 
  • Use 2 or more nodes and a connection string that tolerates a new primary, not a hardcoded primary node’s address. 

Cadence 

  • Avoid hardcoding a connection to a single node’s address. Use the multi-node or load-balanced endpoint so a restart doesn’t route you to a down node. 
  • Avoid scheduling unusually high workflow-creation volume to coincide with maintenance; sustained high creation rates can add load to the underlying persistence layer. 
  • Use 2 or more nodes. Cadence tolerates rolling restarts well by design. 

Controlling timing with exclusion windows 

If a period is genuinely sensitive, such as a product launch, a high-traffic event, or month-end processing, configure a recurring exclusion window in the Instaclustr Console, Cluster Management API, or Terraform (for a one-off exclusion outside a recurring pattern, contact support). Maintenance will not be scheduled during your configured hours, except when Instaclustr needs to act on an unscheduled stability issue. 

If you have a recurring sensitive period and have not configured one, it is worth a few minutes to set one up rather than relying on informal timing. See the Exclusion Times documentation on the Instaclustr support site for setup steps. 

Checklist before your next maintenance window 

  1. Confirm your cluster meets the high availability baseline for its technology. 
  2. Confirm client-side retry policies are configured. 
  3. Check for any objects like OpenSearch indices or Kafka topics that may not have the correct replication factor, before the window opens.
  4. If the timing is genuinely sensitive, configure an exclusion window in advance, not after the notification email arrives. 
  5. After maintenance completes, re-verify custom configuration overrides and check for any lingering degraded state, such as consumer lag, shard allocation delay, or a changed connection string.