Aerospike Client Partition-Map Tend Interval for Rolling Upgrades

Question

Zero-Downtime Cluster Migration
When performing a rolling upgrade on an Aerospike 6.x cluster, each node restart triggers a change in the cluster size and a subsequent update to the partition map. Clients cache this map to route requests to the correct node, but a delay exists between the server-side change and the client-side refresh.

Control Plane Trade-offs
The client refreshes the partition map based on a configured tend interval. If a request is routed using a stale map during a node restart, the client may encounter PARTITION_UNAVAILABLE or NODE_NOT_AVAILABLE errors before the map is synchronized. While reducing the tend interval minimizes this staleness window, excessively low values can increase control-plane traffic and overhead on the cluster.

Current client libraries, such as Java 6.x and Go 1.50+, provide configuration knobs for the tend interval and retry logic, but there is no standardized guidance for the optimal balance during a migration window.

What is the recommended tend interval for small clusters to minimize transient errors without overwhelming the control plane?
  How does the interaction between the tend interval and the MIGRATE_PARTITION redirect behavior affect the necessity of application-level idempotent retries?

Tasadduq Burney · Answer

Direct Answer
For small Aerospike clusters (five nodes or fewer), a tend interval of 2 to 5 seconds is the commonly cited starting point during rolling upgrades. This window reduces the chance of routing with a stale partition map without flooding the control plane. Values below 2 seconds scale control-plane traffic roughly in proportion to client count and can degrade upgrade throughput.

Confirmed Facts vs. Likely Explanation
Confirmed behavior: The tend interval governs how often a client re-fetches the partition map from the cluster. When a node restarts, the map version changes, and clients continue using the cached version until the next tend cycle. MIGRATE_PARTITION redirects and PARTITION_UNAVAILABLE errors are the visible symptoms of this lag.
Likely explanation: The 2–5 second recommendation is a heuristic, not a hard specification. It assumes a small cluster with moderate client concurrency. The exact safe floor depends on your Aerospike server version (6.1.x vs. 6.2.x and later may differ in notification semantics), client library version, and the number of concurrent client connections per node.

Steps for a Rolling Upgrade Window

Set the client tend interval to 2–5 seconds before the upgrade begins. In Java clients this is typically ClientPolicy.tendInterval; in Go clients it is ClientPolicy.TendInterval. Confirm the exact field name for your client version.
Keep application-level retries idempotent. The tend interval reduces but does not eliminate stale-map errors during the brief window between server-side partition change and client refresh.
Monitor PARTITION_UNAVAILABLE and NODE_NOT_AVAILABLE occurrences during the upgrade. A sharp decline after lowering the interval confirms the parameter's effect.

Verification Commands
Use scoped read-only checks to observe map transitions:
asinfo -v pmap
asinfo -v partition-change
Compare client-side "partition map refresh" log timestamps against server-side events to measure convergence time.

Missing Diagnostic
Which client library and exact version are you running (for example, Java 6.x or Go 1.50+)? The available tend-interval knobs and their defaults differ by client, and that detail determines whether 2 seconds is safe or too aggressive for your connection count.

Aerospike Client Partition-Map Tend Interval for Rolling Upgrades

Zero-Downtime Cluster Migration

Control Plane Trade-offs

1 answer

Direct Answer

Confirmed Facts vs. Likely Explanation

Steps for a Rolling Upgrade Window

Verification Commands

Missing Diagnostic

Your perspective belongs here.

0 question comments