Elasticsearch:Replicate data across clusters with CCR

Architecture de base

CCR repose sur une architecture actif-passif. Le cluster leader gère toutes les opérations d'écriture, tandis que le cluster follower réplique les données en mode lecture seule.

• leader cluster : cluster source qui accepte toutes les opérations d'écriture.

• follower cluster : cluster de destination en lecture seule qui réplique les données depuis le cluster leader.

Processus de réplication des données

CCR réplique les données en deux phases :

Phase d'initialisation

Le cluster follower demande l'initialisation au cluster leader, qui transfère tous les fichiers de segments Lucene vers l'index du follower, de manière similaire à une restauration à partir d'un snapshot.

Phase de synchronisation incrémentielle

Par défaut, les shards de l'index follower extraient les dernières opérations du cluster leader chaque seconde :

1. Déterminer le point de départ de l'extraction : le cluster follower conserve un remote_checkpoint local qui suit la dernière opération appliquée à l'index local, correspondant au global_checkpoint dans le Translog du leader.

2. Lire le Translog du leader : le leader utilise le from_seq_no fourni par le follower pour localiser la position de départ dans le Translog, lit toutes les opérations suivantes (indexation, mise à jour, suppression) et les renvoie.

3. Rejouer les opérations sur le follower : le follower rejoue les opérations dans l'ordre et met à jour son remote_checkpoint. En cas d'échec du rejeu (par exemple, en raison d'un conflit de version), la synchronisation est suspendue et une erreur est journalisée.

4. Interrogation continue : le follower interroge régulièrement le leader pour détecter les nouvelles opérations à intervalles fixes, ce qui permet d'atteindre une latence inférieure à la seconde.

Rôle du Translog dans CCR

Le Translog (journal des transactions) constitue la source de données pour la synchronisation incrémentielle de CCR et remplit les fonctions suivantes :

• Prévenir la perte de données : il enregistre toutes les opérations d'écriture afin de permettre une récupération par rejeu après un crash de nœud.

• Garantir la cohérence des réplicas : les écritures sont d'abord enregistrées dans le Translog, puis dans le shard replica. Une opération n'est considérée comme réussie qu'après accusé de réception par les shards primary et replica.

• Prendre en charge la synchronisation incrémentielle CCR : CCR lit les journaux d'opérations via l'API interne du Translog pour récupérer toutes les modifications intervenues après un numéro de séquence donné, permettant ainsi une réplication en quasi temps réel.

Chaque shard dispose de son propre répertoire Translog situé sous indices/{index_uuid}/{shard_id}/translog/. Les fichiers Translog (.tlog) utilisent un format binaire avec un mécanisme de génération. Un nouveau fichier de génération est créé à chaque vidage (flush) ou lorsque le fichier atteint 512 Mo (valeur par défaut).