ApsaraDB for Cassandra en configuration haute disponibilité ne nécessite ni détection de délai d'expiration ni relecture des journaux, ce qui minimise l'impact sur le système (de l'ordre de la milliseconde).
| QUORUM | Mécanisme de haute disponibilité | Raft | Région | |
| Détection des pannes | Nouvelle tentative par le nœud coordinateur et le client ; aucune détection de délai d'expiration, relecture des journaux ou réélection du leader requise | Nouvelle tentative par le client, détection de délai d'expiration et relecture des journaux | Nouvelle tentative par le client et réélection du leader | Nouvelle tentative par le client, détection de délai d'expiration et relecture des journaux |
| Temps de réponse | Millisecondes | De 10 secondes à 10 minutes | De 10 secondes à 10 minutes | De 1 minute à 10 minutes |
| Système type | Cassandra | RDS, MongoDB et Redis avec architecture primaire/secondaire | Non applicable | HBase |
Configuration recommandée
Voici les exigences de base pour les configurations haute disponibilité :
Test de panne
Arrêtez l'un des trois nœuds (chacun doté de 2 cœurs CPU et de 4 Go de mémoire) pendant l'exécution d'opérations d'écriture intensives. L'état des opérations du client est le suivant :
L'arrêt d'un nœud n'affecte pas le service Cassandra.