Cycles de vie des fragments

Les fragments passent par différents états et événements pour prendre en charge la réplication. Le cycle de vie d'un fragment inclut la connexion, l'exécution, l'arrêt, le basculement et la gestion des erreurs. Les fragments peuvent passer de l'état de fragment de réplique à celui de fragment primaire afin de gérer les modifications d'état du serveur.

Evénements de cycle de vie

Lorsque les fragments primaires et répliques sont placés et démarrés, ils passent par une série d'événements qui leur permettent d'être en ligne et en mode écoute.

Fragment primaire

Le service de catalogue place un fragment primaire pour une partition. Le service de catalogue s'attache également à équilibrer les emplacements de fragment primaire et à lancer le basculement des fragments primaires.

Lorsqu'un fragment devient un fragment primaire, il reçoit du service de catalogue une liste de fragments réplique. Le nouveau fragment primaire crée un groupe de fragments réplique et enregistre tous les fragments réplique.

Lorsque le fragment primaire est prêt, un message signalant qu'il est prêt s'affiche dans le fichier SystemOut.log pour le conteneur d'exécution. Pour ouvrir le message ou le message CWOBJ1511I, répertorie le nom de mappe, le nom du groupe de mappes et le numéro de partition du fragment primaire démarré.

CWOBJ1511I: mapName:mapSetName:partitionNumber (primary) is open for business.
Pour plus d'informations sur le positionnement de fragments par le service de catalogue, reportez-vous à la rubrique Placement de fragment.
Fragment réplique

Les fragments réplique sont principalement contrôlés par le fragment primaire à moins que le fragment réplique détecte un problème. Pendant un cycle de vie normal, le fragment primaire place, enregistre et annule l'enregistrement d'un fragment réplique.

Lorsque le fragment primaire initialise un fragment réplique, un message affiche le journal décrivant où s'exécute le fragment réplique pour indiquer que ce dernier est disponible. Pour ouvrir le message ou le message CWOBJ1511I, répertorie le nom de mappe, le nom du groupe de mappes et le numéro de partition du fragment réplique. Le message suivant s'affiche :

CWOBJ1511I: mapName:mapSetName:partitionNumber (synchronous replica) is open for business.
ou
CWOBJ1511I: mapName:mapSetName:partitionNumber (asynchronous replica) is open for business.

Fragment réplique asynchrone : Un fragment réplique scrute les données dans son fragment primaire. Le fragment réplique ajustera automatiquement l'intervalle auquel il scrute ces données s'il n'en reçoit pas du fragment primaire, ce qui est l'indice qu'il est à niveau avec ce dernier. Il ajustera également cet intervalle s'il reçoit une erreur pouvant indiquer que le fragment primaire est en panne ou qu'il y a un problème réseau.

Lorsqu'un fragment réplique passe en mode homologue, il imprime le message suivant dans son fichier SystemOut.log. Ce message peut apparaître plusieurs fois par message CWOBJ1511. Il s'imprimera à nouveau si le fragment réplique se connecte à un autre fragment primaire ou en cas d'ajout de mappes modèles.
CWOBJ1543I: Le fragment réplique asynchrone objectGridName:mapsetName:partitionNumber a démarré ou a continué à se répliquer à partir du fragment primaire. Réplication en cours pour les mappes : [nomMappe]

Fragment réplique synchrone : Lorsque le fragment réplique démarre pour la première fois, il n'est pas encore en mode homologue. Lorsqu'un fragment réplique est en mode homologue, il reçoit les données du fragment primaire au fur et à mesure de leur arrivée dans ce dernier. Avant de passer en mode homologue, le fragment réplique a besoin d'une copie de toutes les données existant dans le fragment primaire.

Le fragment réplique synchrone copie les données depuis le fragment primaire comme cela se passe vers un fragment réplique asynchrone, en scrutant le fragment primaire. Lorsqu'il copie les données existantes à partir du fragment primaire, il passe en mode homologue et commence à recevoir les données en même temps que celles-ci parviennent au fragment primaire.

Lorsqu'un fragment réplique atteint le mode homologue, il imprime un message dans son fichier SystemOut.log. La valeur de temps se réfère à la durée qu'il a fallu au fragment réplique pour obtenir toutes ses données initiales du fragment primaire. La valeur de temps s'affiche comme étant zéro ou étant très faible si le fragment primaire ne comporte aucune donnée existante à répliquer. Ce message peut apparaître plusieurs fois par message CWOBJ1511. Il s'imprimera à nouveau si le fragment réplique se connecte à un autre fragment primaire ou en cas d'ajout de mappes modèles.
CWOBJ1526I: Replica objectGridName:mapsetName:partitionNumber:mapName entering peer 
mode after X seconds.

Lorsque le fragment réplique synchrone est en mode homologue, le fragment primaire doit répliquer les transactions vers la totalité des fragments réplique synchrones qui sont en mode homologue. Le fragment réplique synchrone demeure au même niveau que les données du fragment primaire. Si, dans la règle de déploiement, il est défini un nombre minimum de fragments réplique ou si minSync est défini dans cette règle, ce nombre de fragments réplique synchrones doit voter pour valider avant que la validation de la transaction puisse s'effectuer dans le fragment primaire.

Evénements de reprise

La finalité de la réplication est de permettre la reprise après des échecs et des événements d'erreur. Si un fragment primaire tombe en panne, un autre fragment réplique prend le relais. Si des erreurs sont détectées sur les fragments réplique, le fragment réplique tente de se rétablir. Le service de catalogue contrôle le positionnement et les transactions sur les nouveaux fragments primaires ou sur les nouveaux fragments réplique.

Les fragments réplique deviennent un fragment primaire

Un fragment réplique devient un fragment primaire pour deux raisons. Le fragment primaire s'est arrêté ou a échoué ou une décision d'équilibre a été prise pour déplacer le fragment précédent vers un nouvel emplacement.

Le service de catalogue sélectionne un nouveau fragment primaire des fragments réplique synchrones existants. Si un déplacement de fragment primaire est nécessaire et qu'il n'existe aucun fragment réplique, un fragment réplique temporaire sera positionné pour effectuer la transition. Le nouveau fragment primaire enregistre tous les fragments réplique existants et accepte les transactions en tant que nouveau fragment primaire. Si les fragments réplique existants comportent le niveau de données adéquat, les données en cours sont conservées lorsque le fragment réplique s'enregistre auprès du nouveau fragment primaire. Les fragments réplique asynchrones scruteront le nouveau fragment primaire.

Figure 1. Exemple de positionnement d'une mappe ObjectGrid définie pour la partition partition0. La règle de déploiement comprend une valeur minSyncReplicas de 1, une valeur maxSyncReplicas de 2 et une valeur maxAsyncReplicas de 1.
La machine A comporte un fragment primaire de partition 0. Les machines B et C comportent des fragments réplique synchrones. La machine D comporte un fragment réplique asynchrone.
Figure 2. Le conteneur pour le fragment primaire échoue.
Le conteneur pour le fragment primaire, qui est exécuté sur la machine A, échoue.
Figure 3. Le fragment de réplique synchrone sur le conteneur ObjectGrid 2 devient un fragment primaire.
Sur la machine B, le fragment réplique synchrone devient le fragment primaire.
Figure 4. La machine B contient le fragment primaire. En fonction de la définition du mode de réparation automatique et de la disponibilité des conteneurs, un nouveau fragment réplique synchrone peut ou peut ne pas être placé sur une machine.
La machine B comporte désormais un fragment primaire, la machine C comporte un fragment réplique synchrone et la machine D comporte un fragment réplique asynchrone.

Reprise des fragments réplique

Un fragment réplique synchrone est contrôlé par le fragment primaire. Toutefois, si un fragment réplique détecte un problème, il peut déclencher un événement de réenregistrement pour corriger l'état des données. La réplique supprime les données en cours et obtient une nouvelle copie du fragment primaire.

Lorsqu'un fragment réplique lance un événement de réenregistrement, il imprime un message de journal.

CWOBJ1524I: Replica listener 
objectGridName:mapSetName:partition must re-register with the primary. 
Reason: Exception listed
Si une transaction cause une erreur sur un fragment réplique pendant le traitement, le fragment réplique est à l'état inconnu. La transaction a correctement eu lieu sur le fragment primaire mais un incident s'est produit sur le fragment réplique. Pour remédier à cette situation, le fragment réplique lance un événement de réenregistrement. Avec une nouvelle copie des données du fragment primaire, le fragment réplique peut se poursuivre. Si le même problème se reproduit, le fragment réplique n'effectue pas le réenregistrement en continu. Voir Evénements d'arrêt anormal pour plus de détails.

Evénements d'arrêt anormal

Un fragment réplique peut arrêter de répliquer les données s'il rencontre des situations d'erreur dans lesquelles il n'a aucun moyen de reprendre son activité.

Trop de tentatives d'enregistrement

Si un fragment réplique déclenche un réenregistrement plusieurs fois sans parvenir à valider les données, il s'arrête. L'arrêt empêche une réplique d'entrer dans une boucle de réenregistrement infinie. Par défaut, un fragment réplique tente de réenregistrer trois fois dans une ligne avant de s'interrompre.

Si une réplique réenregistre trop de fois, elle imprime le message suivant dans le journal.

CWOBJ1537E: objectGridName:mapSetName:partition exceeded the maximum number 
of times to reregister (timesAllowed) without successful transactions.
Si le fragment réplique est incapable d'être restauré en se réenregistrant, un problème pervasif peut exister avec les transactions relatives à ce fragment. Il pourrait en résulter un manque de ressources sur le chemin d'accès aux classes si une erreur survient lors de l'inflation des clés ou des valeurs de la transaction.

Echec lors de l'activation du mode homologue

Si un fragment réplique tente de passer en mode homologue et rencontre une erreur lors du traitement des données en bloc existantes à partir du fragment primaire (données de point de contrôle), le fragment réplique s'arrête. L'arrêt empêche le fragment réplique démarrer avec des données initiales erronées. Etant donné qu'il reçoit les mêmes données du fragment primaire s'il se iréenregistre, le fragment réplique ne fait aucune nouvelle tentative.

Si une réplique ne parvient pas à entrer en mode homologue, elle imprime le message suivant dans le journal :

CWOBJ1527W Replica objectGridName:mapSetName:partition:mapName failed to enter peer mode after numSeconds seconds.
Un message supplémentaire s'affiche dans le journal et explique pourquoi le fragment réplique n'a pu passer en mode homologue.

Reprise après réenregistrement ou échec du mode homologue

Si une réplique ne peut pas se réenregistrer ou entrer en mode homologue, elle est à l'état inactif jusqu'à ce qu'un nouvel événement de positionnement ait lieu. Un nouvel événement de positionnement peut être le démarrage ou l'arrêt d'un nouveau serveur. Vous pouvez également démarrer un événement de positionnement à l'aide de la méthode triggerPlacement sur le bean géré PlacementServiceMBean.