Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Synchronisation du décalage entre groupes de consommateurs
MSK Replicator peut synchroniser les décalages des groupes de consommateurs entre un cluster source et un cluster cible, ce qui permet aux consommateurs de changer de cluster et de reprendre le traitement sans sauter d'enregistrements. Cette rubrique décrit le fonctionnement de la synchronisation offset dans les configurations unidirectionnelles (anciennes) et bidirectionnelles (améliorées) et met en évidence les pièges courants.
Comment fonctionne la synchronisation offset
Dans le cadre de la réplication des données, MSK Replicator consomme les messages du cluster source et les transmet au cluster cible. Cela peut entraîner des messages présentant des décalages différents sur vos clusters source et cible. Si vous avez activé la synchronisation des décalages des groupes de consommateurs lors de la création du réplicateur, MSK Replicator traduit automatiquement les décalages lors de la copie des métadonnées afin qu'après avoir basculé vers le cluster cible, vos clients puissent reprendre le traitement là où ils s'étaient arrêtés.
MSK Replicator est optimisé pour les utilisateurs du cluster source qui lisent à partir d'une position plus proche de la pointe du flux (fin de la partition thématique). Si vos groupes de consommateurs sont en retard sur le cluster source, il se peut que ces groupes de consommateurs soient plus en retard sur le cluster cible que sur le cluster source, ce qui signifie que les consommateurs retraiteront davantage de messages dupliqués après le basculement. Pour réduire ce décalage, vos clients du cluster source doivent rattraper leur retard et commencer à consommer dès le début du flux. Au fur et à mesure que vos clients rattrapent leur retard, MSK Replicator réduira automatiquement le décalage.
La synchronisation offset est un pipeline en trois étapes :
Mappage des décalages : lorsque les enregistrements sont répliqués de la source à la cible, le réplicateur enregistre des mappages périodiques entre les décalages source et les décalages cibles correspondants. Étant donné que les décalages source et cible divergent (points de départ différents, compactage, etc.), ces mappages sont essentiels.
Traduction des décalages : le réplicateur lit périodiquement les décalages validés pour chaque groupe de consommateurs répliqué sur le cluster source. Il utilise ensuite les mappages de décalage enregistrés pour traduire ces décalages sources en décalages cibles équivalents.
Validation des décalages : les offsets traduits sont attribués au
__consumer_offsetssujet du cluster cible, de sorte que lorsqu'un consommateur se connecte à la cible et rejoint le même groupe, celui-ci reprend approximativement à la bonne position.
Comportements clés :
La traduction de l'offset est approximative et non exacte. Le réplicateur échantillonne les mappages de décalage à intervalles réguliers, de sorte que le décalage traduit peut être légèrement inférieur à la véritable position équivalente. Cela est intentionnel : cela se traduit par une erreur de at-least-once livraison, ce qui signifie que les consommateurs peuvent relire un petit nombre de messages après le basculement.
Les compensations ne sont attribuées à un groupe de consommateurs sur la cible que si aucun consommateur ne consomme activement dans ce groupe sur la cible. Cela empêche le réplicateur d'interférer avec les consommateurs qui s'exécutent déjà sur le cluster cible.
Les groupes de consommateurs doivent correspondre au filtre de groupe de consommateurs configuré (modèles d'inclusion/exclusion) pour être synchronisés.
Réplication unidirectionnelle avec synchronisation offset traditionnelle
Il s'agit du mode par défaut pour un réplicateur unidirectionnel standard (Cluster A → Cluster B).
Dénomination des rubriques : l'ancienne synchronisation offset prend en charge la réplication de noms de rubrique à la fois préfixés et identiques.
Direction — Les compensations des groupes de consommateurs ne sont synchronisées avec le cluster cible que lorsque les producteurs sont actifs sur la source et les consommateurs sont inactifs sur le cluster cible.
Failover — Les consommateurs peuvent être dirigés vers le cluster cible et repartiront de la position offset traduite.
Aucune prise en charge rétroactive : l'ancienne synchronisation des décalages ne traduit pas les décalages de la cible vers la source. Si vous redirigez les consommateurs vers la destination et que vous souhaitez ensuite les rediriger vers la source, il n'y a pas de traduction offset automatique pour le voyage aller-retour. Si le retour en arrière est une exigence, utilisez une configuration bidirectionnelle avec une synchronisation améliorée des décalages.
Configuration bidirectionnelle avec synchronisation améliorée du décalage
Une configuration bidirectionnelle nécessite l'exécution de deux réplicateurs dans des directions opposées (réplicateur A→B et réplicateur B→A). Chaque réplicateur effectue toujours une réplication unidirectionnelle des données et une synchronisation des décalages : il réplique les données de leur source vers leur cible et synchronise les décalages des groupes de consommateurs dans le même sens. Grâce à la synchronisation offset améliorée, chaque réplicateur est en mesure de continuer à synchroniser les groupes de consommateurs même lorsque les producteurs et les consommateurs sont actifs sur des clusters différents.
Caractéristiques principales :
Dénomination des rubriques : la synchronisation améliorée nécessite une réplication identique des noms de rubriques sur les deux réplicateurs.
Deux réplicateurs, chacun unidirectionnel : chaque réplicateur réplique les données et synchronise les décalages dans une seule direction. Le comportement bidirectionnel provient du fait que la paire travaille ensemble.
Lit les mappages des deux réplicateurs : lors de la traduction des décalages, les réplicateurs travaillent ensemble pour déterminer la traduction la plus précise disponible.
Basculement et retour en arrière : les consommateurs peuvent être déplacés d'un cluster à l'autre et reprendre leur activité à peu près à la bonne position.
Quand activer la synchronisation bidirectionnelle des décalages :
Migration avec fonction de restauration : lorsque vous migrez d'un cluster vers un autre, vous souhaitez pouvoir revenir au cluster d'origine en cas de problème.
Architectures active-active : lorsque les deux clusters effectuent activement des opérations de lecture et d'écriture et que les consommateurs doivent pouvoir passer d'un cluster à l'autre.
Reprise après sinistre : lorsque vous devez vous assurer que les clients peuvent reprendre le traitement à partir du bon décalage sur l'un ou l'autre des clusters après un incident de basculement ou de retour en arrière.
Surveillance de la synchronisation des décalages
Surveillez les CloudWatch métriques Amazon suivantes pour vérifier que la synchronisation des décalages fonctionne correctement :
ConsumerGroupCount— Vérifiez que le nombre attendu de groupes de consommateurs est synchronisé sur les deux réplicateurs.ConsumerGroupOffsetSyncFailure— Doit être égal à 0 sur les deux réplicateurs. Si cette valeur est supérieure à 0, vérifiez que les groupes de consommateurs sont actifs, vérifiez les autorisations de lecture et de description et assurez-vous que les rubriques existent sur le cluster cible.OffsetLag (MSK Cluster)etOffsetLag (Non-MSK Cluster)— Comparez le décalage entre les consommateurs au niveau des partitions sur les deux clusters pour vérifier que les décalages sont synchronisés.
Pièges courants
-
Les consommateurs peuvent relire un petit nombre de messages après un basculement
La traduction de l'offset est approximative. Le décalage traduit est volontairement prudent : il peut être légèrement inférieur à la position équivalente réelle. Cela signifie que les consommateurs retraitent généralement un petit nombre d'enregistrements après avoir changé de cluster. Les applications doivent être conçues pour gérer le double traitement (idempuissance).
-
Les offsets ne sont pas synchronisés avec les groupes qui consomment activement sur la cible
Si un groupe de consommateurs est déjà actif sur le cluster cible, le réplicateur ne remplacera pas ses décalages. Il s'agit d'un mécanisme de sécurité. Toutefois, cela signifie que si les consommateurs commencent à utiliser la cible avant que le réplicateur n'ait eu l'occasion de synchroniser les décalages, ils partiront de la politique de réinitialisation des décalages par défaut de la cible (généralement
latestouearliest), et non de la position traduite. -
La synchronisation offset a un décalage inhérent
La traduction offset dépend de deux processus asynchrones : la réplication des données et la synchronisation des offset. Il y a toujours un certain délai entre le moment où le consommateur valide une compensation sur la source et le moment où l'offset traduit apparaît sur la cible. En cas de basculement, ce délai peut amener les consommateurs à relire plus de messages que prévu si le consommateur source était actif très récemment.
-
Les groupes de consommateurs doivent être inclus dans le filtre de réplication
Seuls les groupes de consommateurs qui correspondent au modèle d'inclusion configuré (et qui ne correspondent pas au modèle d'exclusion) verront leurs offsets synchronisés. Si les décalages d'un groupe de consommateurs n'apparaissent pas sur la cible, vérifiez qu'ils sont inclus dans la configuration de réplication du groupe de consommateurs.
-
Les réplicateurs unidirectionnels ne prennent pas en charge le retour en arrière
Avec l'ancienne synchronisation des décalages (unidirectionnelle), les décalages sont uniquement traduits de la source vers la cible. Si vous déplacez les consommateurs vers la cible et que vous devez ensuite les rediriger vers la source, vous devrez déterminer manuellement les compensations correctes ou accepter un nouveau traitement. Si le retour en arrière est une exigence, utilisez une configuration bidirectionnelle avec une synchronisation améliorée des décalages.
-
La suppression et la recréation de sujets peuvent invalider les mappages de décalage
Si un sujet est supprimé et recréé sur l'un des clusters, les mappages de décalage deviennent obsolètes car le nouveau sujet part du décalage 0. Avec l'ancienne synchronisation de l'offset, cela peut entraîner des traductions de décalage incorrectes. La synchronisation offset améliorée détecte la recréation des sujets et réinitialise automatiquement les mappages.
