Aerospike Client Partition-Map Tend Interval for Rolling Upgrades
0 reputation · 29 Jul 2021, 17:15 UTC
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_PARTITIONredirect behavior affect the necessity of application-level idempotent retries?
aerospike