From 6006d59a90d8a2be1d709953f86eeaddd1ea3543 Mon Sep 17 00:00:00 2001 From: Dorota Wojcik Date: Thu, 17 Sep 2026 16:08:50 +0200 Subject: [PATCH 1/2] update: clarify Valkey cluster backup, resharding, and conversion limits --- .../valkey/concepts/valkey-cluster.md | 36 ++++++++++++++----- 1 file changed, 28 insertions(+), 8 deletions(-) diff --git a/docs/products/valkey/concepts/valkey-cluster.md b/docs/products/valkey/concepts/valkey-cluster.md index f7ddde8dd..f7e862a41 100644 --- a/docs/products/valkey/concepts/valkey-cluster.md +++ b/docs/products/valkey/concepts/valkey-cluster.md @@ -167,6 +167,13 @@ of primary nodes in your cluster changes, Aiven reshards the cluster automatical Resharding redistributes the hash slots, and the keys they hold, across the available primary nodes to keep the slots evenly balanced across shards. +Resharding has a few prerequisites: + +- Your service must run Valkey `9.0` or later. +- All nodes in the service must be in the `Running` state. +- No other change that alters the instance size or cloud region can be in progress at the + same time. + Resharding runs as part of a service plan change that adds or removes primary nodes. Aiven manages the entire process: @@ -195,26 +202,39 @@ more information, see [Memory management](/docs/products/valkey/concepts/memory- ## Backup and restore -Aiven for Valkey automatically backs up your clustered service. Each primary node backs up -the data for the hash slots it owns, and Aiven stores these backups in a remote location. -Backups run independently for each primary and need no coordination from your application. +Aiven for Valkey automatically backs up your clustered service. For each shard, Aiven +backs up a replica if the shard has one, or the primary if it doesn't. This keeps the +extra backup load off primaries where possible. Aiven stores these backups in a remote +location. Backups run independently for each shard and need no coordination from your +application. + +If a reshard is still moving slots when a backup is due, Aiven waits for the new layout to +settle before starting the backup. If the topology changes while a backup is running, for +example during a reshard or failover, the backup fails and retries automatically. + +Cluster mode doesn't support delta backups: Every backup is a full backup. To restore a cluster, Aiven combines the stored backups with the recorded hash slot layout, so your data returns to the same slot distribution. The cluster must keep the same number of primary nodes for a restore to succeed. :::note -Cluster backups are not point-in-time recovery (PITR). Because each primary node is backed -up independently, backups are not consistent across shards. A restored cluster reflects -each primary's data as of its own backup, not a single moment in time across the whole -cluster. Design your application to tolerate this if you rely on a restore. +Cluster backups are not point-in-time recovery (PITR). Because each shard is backed up +independently, backups are not consistent across shards. A restored cluster reflects each +shard's data as of its own backup, not a single moment in time across the whole cluster. +Design your application to tolerate this if you rely on a restore. ::: ## Limitations and considerations - Valkey clustering is in [limited availability (LA)](/docs/platform/concepts/service-and-feature-releases#limited-availability-). -- Valkey clustering is supported for new services only. +- Valkey clustering is supported for new services only. You can't convert an existing + standalone service to a cluster plan, or a clustered service back to standalone. +- Migrating data into a cluster from an external Redis or Valkey server isn't supported. +- Aiven doesn't guarantee that a shard's primary and its replicas land in different + availability zones. If they land in the same zone, an outage of that zone can make the + whole shard unavailable. - Performance factors - Network latency between shards can affect cross-shard operations. From 4193f7e6485966ed818d4a7eef36704168cd6ece Mon Sep 17 00:00:00 2001 From: Dorota Wojcik Date: Thu, 17 Sep 2026 17:22:26 +0200 Subject: [PATCH 2/2] feedback --- docs/products/valkey/concepts/valkey-cluster.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/products/valkey/concepts/valkey-cluster.md b/docs/products/valkey/concepts/valkey-cluster.md index f7e862a41..5ae6af039 100644 --- a/docs/products/valkey/concepts/valkey-cluster.md +++ b/docs/products/valkey/concepts/valkey-cluster.md @@ -169,10 +169,10 @@ primary nodes to keep the slots evenly balanced across shards. Resharding has a few prerequisites: -- Your service must run Valkey `9.0` or later. - All nodes in the service must be in the `Running` state. - No other change that alters the instance size or cloud region can be in progress at the same time. +- No other reshard can already be in progress. Resharding runs as part of a service plan change that adds or removes primary nodes. Aiven manages the entire process: @@ -232,9 +232,9 @@ Design your application to tolerate this if you rely on a restore. - Valkey clustering is supported for new services only. You can't convert an existing standalone service to a cluster plan, or a clustered service back to standalone. - Migrating data into a cluster from an external Redis or Valkey server isn't supported. -- Aiven doesn't guarantee that a shard's primary and its replicas land in different - availability zones. If they land in the same zone, an outage of that zone can make the - whole shard unavailable. +- Aiven places a shard's primary and its replicas in different availability zones when + possible, but this isn't guaranteed. If they land in the same zone, an outage of that + zone can make the whole shard unavailable. - Performance factors - Network latency between shards can affect cross-shard operations.