A propos de la réplication coordonnée

En mode coordonné, le processus Replicat fonctionne comme suit :

La différence entre le mode classique et le mode coordonné est que le processus Replicat est multithread en mode coordonné. Dans une instance Replicat unique, plusieurs threads lisent la trace indépendamment et appliquent les transactions en parallèle. Chaque thread gère le filtrage, le mapping, la conversion, la construction SQL et la gestion des erreurs pour la charge globale qui lui est affectée. Un thread de coordinateur coordonne les transactions entre les threads pour prendre en compte les dépendances entre les threads.

Les transactions source peuvent être réparties entre les traitements CR de sorte que l'intégrité de la transaction source totale ne soit pas maintenue. La partie de la transaction traitée par un processus CR est effectuée dans l'ordre validé, mais la totalité de la transaction dans tous les processus CR ne l'est pas.

Le processus Replicat coordonné permet le partitionnement défini par l'utilisateur de la charge globale afin d'appliquer simultanément des transactions à volume élevé. En outre, il coordonne automatiquement l'exécution des transactions nécessitant une coordination, telles que les instructions LDD, et les mises à jour de clé primaire avec le partitionnement THREADRANGE. Une telle transaction est exécutée comme une transaction dans la cible avec une synchronisation complète : elle attend que toutes les transactions précédentes soient appliquées en premier, et toutes les transactions après cette transaction barrière doivent attendre que cette transaction barrière soit appliquée.

Un seul fichier de paramètres est requis pour une réplication coordonnée, quel que soit le nombre de threads. Vous utilisez l'option THREAD ou THREADRANGE dans l'instruction MAP pour indiquer les threads qui traitent les transactions pour ces objets, et vous indiquez le nombre maximal de threads lorsque vous créez le groupe de réplication.

Cette figure illustre l'architecture du processus Replicat coordonné.

Description de l'image coordinatedreplicat.jpg

Comme indiqué dans cette figure, le processus Replicat coordonné comprend les deux processus suivants :

A propos des transactions de barrière

Les transactions de barrière sont gérées automatiquement dans une configuration Replicat coordonnée. Les transactions de barrière sont des transactions qui nécessitent une coordination entre les threads. Exemples : instructions LDD, transactions qui incluent des mises à jour de clés primaires et certaines actions EVENTACTIONS.

Vous pouvez éventuellement forcer le traitement d'autres transactions comme une transaction barrière à l'aide de la commande "COORDINATED keyword in a MAP statement. One use case for this would be force a SQLEXEC" pour qu'elle soit exécutée de manière similaire à une exécution série. Cela peut s'avérer utile si les résultats peuvent devenir ambigus, sauf si l'état de la cible est cohérent dans toutes les transactions.

Remarque : le processus Replicat coordonné n'effectue pas de calculs de dépendance pour les transactions sans barrière lorsqu'une table mappée est partitionnée sur la base de THREADRANGE. Elle s'appuie sur les colonnes THREADRANGE indiquées pour calculer une valeur de hachage. Il partitionne les données entrantes en fonction de la valeur de hachage et envoie tous les enregistrements correspondant à cette valeur de hachage au même thread.

Mode de traitement des transactions de barrière

Tous les threads convergent et attendent au début d'une transaction barrière. La transaction de barrière est suspendue jusqu'à ce que les autres threads atteignent leur position de départ. Si des threads traitaient déjà une partie de la transaction de barrière, ces threads effectuent une annulation. Les transactions groupées, telles que celles contrôlées par les paramètres BATCHSQL ou GROUPTRANSOPS, sont également annulées, puis réappliquées jusqu'à ce qu'elles atteignent le début de la transaction barrière.

Tous les threads convergent et attendent au début de la transaction suivante après la transaction barrière. Les deux points de synchronisation, avant et après la transaction barrière, garantissent que les opérations de métadonnées et les actions EVENTACTIONS se déroulent dans l'ordre approprié pour les opérations de données.

Une fois les threads synchronisés au début de la transaction de barrière, la transaction de barrière est traitée en série par le thread qui a l'ID de thread le plus bas parmi tous les threads spécifiés dans les instructions MAP, puis le traitement parallèle entre les threads est repris. Vous pouvez forcer le traitement des transactions de barrière via un thread spécifique, qui est toujours le thread 0, en spécifiant le paramètre USEDEDICATEDCOORDINATIONTHREAD dans le fichier de paramètres de réplication.