Stockages clé-valeur

Un stockage clé-valeur est le type de base de données que la console liste comme Key-value store, avec la mention « Works with Redis clients. » Les applications s’y connectent avec les bibliothèques clientes et les commandes Redis qu’elles utilisent déjà. Les connexions clé-valeur externes fonctionnent de la même manière et peuvent pointer vers Redis, Valkey ou un autre serveur qui parle le protocole Redis.

Stockages clé-valeur managés

Les nouveaux stockages clé-valeur managés exécutent Valkey 9.1.2 avec les modules JSON, Bloom et Search. Ils sont créés, redimensionnés, mis en pause, publiés, liés aux charges de travail et sauvegardés comme toute base de données managée. Leur création nécessite Personal ou supérieur.

Chaque liaison dispose de son propre utilisateur ACL. Il peut exécuter les commandes ordinaires de données, de connexion, de transaction et de pub/sub, ainsi que charger et exécuter des scripts ; il ne peut pas administrer les ACL, vider ou tuer des scripts, ni gérer des fonctions.

L’explorateur parcourt les clés, affiche les valeurs, et définit, supprime et fait expirer des clés lorsque vous y êtes autorisé ; la console exécute des commandes Redis.

Un stockage clé-valeur peut aussi s’exécuter sur plusieurs serveurs en Business et Enterprise. Ses copies suivent toujours le primaire de façon asynchrone.

Passer à Valkey

Les stockages créés avant 2.12 continuent d’exécuter Redis. Ils fonctionnent comme avant ; rien ne change tant que vous ne les faites pas passer à Valkey.

Move to Valkey, sur la page du stockage, copie chaque clé dans Valkey sur le même nœud et fait basculer le stockage sur celui-ci :

1. La boîte de dialogue vérifie d’abord le stockage et affiche le nombre de clés et la pause d’écriture attendue.
2. Confirmez. Les écritures sont suspendues pendant la copie des clés ; les lectures continuent de fonctionner.
3. Lorsque les nombres de clés correspondent, le stockage bascule sur Valkey. Il conserve ses identifiants, son port publié et ses liaisons ; les clients connectés se reconnectent.

Les données Redis restent sur le nœud jusqu’à ce que les nombres correspondent. En cas d’échec, le stockage revient à Redis.

Le passage est refusé avant toute modification lorsque :

• le stockage ne s’exécute pas ;
• son nœud exécute un démon Docker qui ne prend pas en charge Valkey ; mettez d’abord le démon à jour ;
• il contient des clés qui ne peuvent pas être copiées : filtres Bloom ou cuckoo, séries temporelles, ensembles de vecteurs ou index de recherche ;
• l’environnement de son app est isolé.

Les groupes de consommateurs de flux (streams) sont transférés avec leur dernier identifiant livré, mais pas leurs entrées en attente. Lorsqu’un stockage comporte des entrées en attente, la boîte de dialogue en indique le nombre, et le passage nécessite une confirmation explicite.

API : GET (vérification) et POST /api/databases/managed/{id}/move-to-valkey, avec acceptPendingStreamLoss: true pour accepter la perte des entrées de flux en attente. MCP : actions move_to_valkey_check et move_to_valkey de manage_managed_database. Scope : databases:edit.

Sauvegardes

Une sauvegarde clé-valeur ne se restaure que dans le moteur dont elle provient : une sauvegarde Redis dans un stockage qui exécute Redis ou dans un nouveau stockage, une sauvegarde Valkey dans un stockage qui exécute Valkey ou dans un nouveau stockage. Effectuez une nouvelle sauvegarde après Move to Valkey afin que votre dernière sauvegarde corresponde au moteur. Voir Sauvegardes des bases de données.

Les sauvegardes lisent le stockage par réplication ; l’utilisateur d’une connexion clé-valeur externe a donc besoin des commandes de réplication (REPLCONF, SYNC). L’enregistrement d’une politique de sauvegarde et chaque exécution le vérifient.