Avec eXtreme Scale, il est possible de répliquer une base de données en mémoire ou un fragment d'une machine virtuelle Java (JVM) vers une autre. Un fragment représente une partition qui est placée dans un conteneur. Plusieurs fragments représentant différentes partitions peuvent coexister dans un même conteneur. Chaque partition a une instance qui est un fragment primaire et un nombre configurable de fragments réplique. Les fragments réplique sont synchrones ou asynchrones. Les types et le positionnement des fragments réplique est déterminé par eXtreme Scale à l'aide d'une règle de déploiement qui spécifie les nombres minimum et maximum de fragments synchrones et asynchrones.
La réplication utilise trois types de fragments :
Le fragment primaire reçoit toutes les opérations d'insertion, d'actualisation et de suppression. Le fragment primaire ajoute et supprime des fragments réplique, réplique les données vers les fragments réplique et gère les validations et les annulations des transactions.
Les fragments réplique synchrones maintiennent le même état que le fragment primaire. Lorsqu'un fragment primaire réplique des données vers un fragment réplique synchrone, la transaction n'est validée qu'après avoir été validée dans le fragment réplique synchrone.
Les fragments réplique asynchrones ne sont pas forcément dans le même état que le fragment primaire. Lorsqu'un fragment primaire réplique des données vers un fragment réplique asynchrone, il n'attend pas la validation de ce dernier.
Lorsqu'un fragment primaire se prépare à valider des données, il vérifie combien de fragments réplique synchrones ont élu de valider la transaction. Le fragment réplique élit de valider la transaction lorsqu'il traite normalement cette dernière. Si quelque chose ne va pas dans le fragment réplique synchrone, celui-ci décide de ne pas valider. Pour qu'un fragment primaire valide, le nombre de fragments réplique synchrones qui élisent de valider doit correspondre au paramètre minSyncReplica de la règle de déploiement. Si ce nombre est trop bas, le fragment primaire ne valide pas la transaction et une erreur se produit. Cette action garantit la disponibilité du nombre de fragments réplique synchrones avec les bonnes données. Les fragments réplique synchrones qui ont rencontré des erreurs se réenregistrent pour corriger leur état. Pour plus d'informations sur le réenregistrement, voir Récupération des fragments réplique.
Le fragment primaire lève une erreur ReplicationVotedToRollbackTransactionException si trop peu de fragments réplique synchrones ont élu de valider.
En principe, le fragment primaire écrit de manière synchrone les modifications dans la base de données via le chargeur. Le chargeur et la base de données sont toujours synchrones. Lorsque le fragment primaire bascule vers un fragment réplique, la base de données et le chargeur risquent de ne plus l'être. Exemple :
Dans les deux cas, le fragment réplique est décalé par rapport à la base de données : en avance ou en retard d'une transaction. Cette situation est inacceptable. eXtreme Scale utilise un protocole spécial et un contrat avec l'implémentation du chargeur afin de résoudre ce problème sans validation en deux phases. Le protocole fonctionne de la manière suivante :
Côté fragment primaire
Côté fragment réplique
Côté fragment réplique lors d'un basculement
Ce protocole garantit que la base de données est au même niveau que l'état du nouveau fragment primaire.