Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Bonnes pratiques
Vous trouverez ci-dessous les meilleures pratiques recommandées pour MemoryDB. La mise en œuvre de ces bonnes pratiques améliore les performances et la fiabilité de votre cluster.
**Topics**
+ [Résilience dans MemoryDB](disaster-recovery-resiliency.md)
+ [Bonnes pratiques : Pub/Sub et I/O multiplexage amélioré](best-practices-pubsub.md)
+ [Bonnes pratiques : redimensionnement des clusters en ligne](best-practices-online-resharding.md)
# Résilience dans MemoryDB
L'infrastructure AWS mondiale est construite autour des AWS régions et des zones de disponibilité. AWS Les régions fournissent plusieurs zones de disponibilité physiquement séparées et isolées, connectées par un réseau à faible latence, à haut débit et hautement redondant. Avec les zones de disponibilité, vous pouvez concevoir et exploiter des applications et des bases de données qui basculent automatiquement d’une zone de disponibilité à l’autre sans interruption. Les zones de disponibilité sont plus hautement disponibles, tolérantes aux pannes et évolutives que les infrastructures traditionnelles à un ou plusieurs centres de données.
Pour plus d'informations sur AWS les régions et les zones de disponibilité, consultez la section [Infrastructure AWS mondiale](https://aws.amazon.com/about-aws/global-infrastructure/).
Outre l'infrastructure AWS globale, MemoryDB propose plusieurs fonctionnalités pour répondre à vos besoins en matière de résilience des données et de capture instantanée.
**Topics**
+ [Atténuation des défaillances](faulttolerance.md)
# Atténuation des défaillances
Lorsque vous planifiez votre implémentation de MemoryDB, vous devez planifier de manière à ce que les défaillances aient un impact minimal sur votre application et vos données. Les rubriques dans cette section présentent les approches que vous pouvez entreprendre pour éviter d'éventuelles défaillances de vos applications et données.
## Atténuation des défaillances : clusters MemoryDB
Un cluster MemoryDB est composé d'un seul nœud principal sur lequel votre application peut à la fois lire et écrire, et de 0 à 5 nœuds de réplication en lecture seule. Toutefois, nous vous recommandons vivement d'utiliser au moins une réplique pour une haute disponibilité. Chaque fois que des données sont écrites sur le nœud principal, elles sont conservées dans le journal des transactions et mises à jour de manière asynchrone sur les nœuds répliques.
**Cas d'échec d'un réplica en lecture**
1. MemoryDB détecte la réplique défaillante.
1. MemoryDB met le nœud défaillant hors ligne.
1. MemoryDB lance et approvisionne un nœud de remplacement dans le même AZ.
1. Le nouveau nœud se synchronise avec le journal des transactions.
Pendant ce temps, votre application peut continuer à lire et à écrire en utilisant les autres nœuds.
**MemoryDB Multi-AZ**
Si Multi-AZ est activé sur vos clusters MemoryDB, un primaire défaillant sera détecté et remplacé automatiquement.
****
1. MemoryDB détecte la défaillance du nœud principal.
1. MemoryDB bascule vers une réplique après s'être assurée qu'elle est cohérente avec le primaire défaillant.
1. MemoryDB lance une réplique dans l'AZ du serveur principal défaillant.
1. Le nouveau nœud se synchronise avec le journal des transactions.
Le basculement vers un nœud de réplica est généralement plus rapide que la création et la mise en service d'un nouveau nœud principal. Cela signifie que votre application peut reprendre l'écriture sur votre nœud principal plus rapidement.
Pour de plus amples informations, veuillez consulter [Minimiser les temps d'arrêt dans MemoryDB avec Multi-AZ](autofailover.md).
# Bonnes pratiques : Pub/Sub et I/O multiplexage amélioré
Lorsque vous utilisez Valkey ou Redis OSS version 7 ou ultérieure, nous vous recommandons d'utiliser Pub/Sub fragmenté[.](https://valkey.io/topics/pubsub/) Vous améliorez également le débit et la latence grâce au [ I/O multiplexage amélioré](https://aws.amazon.com/memorydb/features/#Ultra-fast_performance), qui est automatiquement disponible lors de l'utilisation de Valkey ou de Redis OSS version 7 ou ultérieure et ne nécessite aucune modification du client. Il est idéal pour les pub/sub charges de travail, qui sont souvent limitées par le débit en cas de connexions client multiples.
# Bonnes pratiques : redimensionnement des clusters en ligne
Le *repartitionnement * implique l'ajout de partitions ou de nœuds à votre cluster, ou leur suppression, et la redistribution des espaces clés. En conséquence, plusieurs aspects peuvent avoir un impact sur l'opération de repartitionnement, tels que la charge sur le cluster, l'utilisation de la mémoire et la taille globale des données. Pour bénéficier de la meilleure expérience possible, il est recommandé de suivre les bonnes pratiques générales relatives au cluster en vue d'une distribution uniforme des modèles de charge de travail. En outre, il est recommandé de respecter les étapes suivantes.
Avant de lancer le repartitionnement, procédez comme suit :
+ **Testez votre application** – Testez le comportement de votre application lors du repartitionnement dans un environnement intermédiaire si possible.
+ **Obtenez une notification anticipée pour les problèmes de mise à l'échelle** – Le repartitionnement est une opération gourmande en calculs. C'est pourquoi nous recommandons de maintenir l'utilisation du processeur en dessous de 80 % sur les instances multicœurs et à moins de 50 % sur les instances monocœurs lors du repartage. Surveillez les métriques de MemoryDB et initiez le repartage avant que votre application ne commence à détecter des problèmes de dimensionnement. Les métriques qu'il est utile de suivre sont `CPUUtilization`, `NetworkBytesIn`, `NetworkBytesOut`, `CurrConnections`, `NewConnections`, `FreeableMemory`, `SwapUsage` et `BytesUsedForMemoryDB`.
+ **Assurez-vous qu'une mémoire suffisante est disponible avant de procéder à une diminution d'échelle** – Si vous procédez à une diminution d'échelle, assurez-vous que cette mémoire disponible sur les partitions à conserver est au moins égale à une fois et demi la mémoire utilisée sur les partitions que vous prévoyez de supprimer.
+ **Initiez le repartitionnement pendant les heures creuses** – Cette pratique permet de réduire l'impact de la latence et du débit sur le client pendant l'opération de repartitionnement. Elle permet aussi d'exécuter le repartitionnement plus rapidement, car un plus grand nombre de ressources peut être utilisé pour la redistribution des emplacements.
+ **Vérifiez le comportement hors délai du client** – Certains clients peuvent observer une latence plus élevée lors d'un redimensionnement des clusters en ligne. La configuration de votre bibliothèque client avec un délai d'expiration supérieur peut être une aide en offrant au système le temps de se connecter même en cas de conditions de charge plus importantes sur le serveur. Dans certains cas, vous pouvez ouvrir un grand nombre de connexions sur le serveur. Dans ces cas, pensez à ajouter un backoff exponentiel à la logique de reconnexion. Cela peut empêcher qu'une rafale de nouvelles connexions atteignent le serveur simultanément.
Pendant le repartitionnement, appliquez les recommandations suivantes :
+ **Évitez les commandes coûteuses** : évitez d'exécuter des opérations de calcul I/O intensives, telles que les commandes `KEYS` et`SMEMBERS`. Nous suggérons cette approche, car ces opérations augmentent la charge sur le cluster et ont un impact sur ses performances. Utilisez à la place les commandes `SCAN` et `SSCAN`.
+ **Suivez les bonnes pratiques Lua** – Évitez les longues exécutions de scripts Lua et déclarez toujours les clés utilisées dans les scripts Lua en amont. Nous recommandons cette approche pour déterminer que le script Lua n'utilise pas de commandes inter-emplacements. Veillez à ce que les clés utilisées dans les scripts Lua appartiennent au même emplacement.
Après le repartitionnement, notez ce qui suit :
+ La diminution d'échelle peut être partiellement réussie si la mémoire sur les partitions cibles est insuffisante. Si un tel résultat se produit, vérifiez la mémoire disponible et réessayez l'opération, si nécessaire.
+ Il n'est pas procédé à la migration des emplacements ayant des éléments volumineux. En particulier, les emplacements avec des éléments supérieurs à une post-sérialisation de 256 Mo ne font pas l'objet d'une migration.
+ Les commandes `FLUSHALL` et `FLUSHDB` ne sont pas prises en charge dans les scripts Lua lors d’une opération de repartitionnement.