Répliques et fragments

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.

Types de fragment

La réplication utilise trois types de fragments :

  • primaire
  • fragment réplique synchrone
  • fragment réplique asynchrone

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.

Figure 1. Chemin de la communication entre un fragment primaire et un fragment réplique
Une transaction communique avec un fragment primaire. Le fragment primaire communique avec des fragments réplique, qui peuvent exister sur une ou plusieurs machines virtuelles Java.

Fragments réplique synchrones minimum

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.

Réplication et chargeurs

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 :

  • Le fragment primaire peut envoyer la transaction au fragment réplique, puis tombe en panne avant de valider vers la base de données.
  • Le fragment primaire peut valider vers la base de données, puis tomber en panne avant d'envoyer au fragment réplique.

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

  • Envoi de la transaction avec les résultats de la transaction précédente.
  • Ecriture dans la base de données et tentative de validation de la transaction.
  • Si la base de données valide, validation dans eXtreme Scale. Si elle ne valide pas, annulation de la transaction.
  • Enregistrement du résultat.

Côté fragment réplique

  • Réception et mise en mémoire tampon d'une transaction.
  • Pour tous les résultats, envoi avec la transaction, validation de toutes les transactions mises en mémoire tampon et suppression des transactions annulées.

Côté fragment réplique lors d'un basculement

  • Pour toutes les transactions mises en mémoire tampon, fourniture des transactions au chargeur et tentative par ce dernier de valider les transactions.
  • Le chargeur doit avoir été écrit de manière à rendre chaque transaction idempotente.
  • Si la transaction est déjà dans la base de données, le chargeur n'effectue aucune opération.
  • Si la transaction n'est pas dans la base de données, le chargeur applique la transaction.
  • Une fois que toutes les transactions ont été traitées, le nouveau fragment primaire peut commencer à servir les demandes.

Ce protocole garantit que la base de données est au même niveau que l'état du nouveau fragment primaire.