Géo-réplication et concepts multi-sites
La géo-réplication permet à un store Clustron Zaris de s'étendre sur plus d'un datacenter. Deux (ou plusieurs) clusters indépendants — un par région — acceptent chacun les écritures localement et se répliquent mutuellement via un change feed reprenable et basé sur le pull. Voici le modèle conceptuel ; la page d'architecture couvre la façon dont il est construit, et le guide du développeur couvre la façon de l'activer et de l'exploiter.
La géo-réplication est nouvelle dans Zaris 2.1.0 et désactivée par défaut — un store sans configuration de site se comporte exactement comme un store mono-site normal.
Un site est un cluster indépendant
Un site est un cluster Zaris complet — avec sa propre appartenance, carte de partitions, propriété et quorum local — identifié par un identifiant de site. La géo-réplication couple les sites uniquement via le change feed ; ce n'est délibérément pas un cluster étiré.
Garder les sites indépendants est tout l'intérêt d'un store en mémoire : la latence du WAN n'entre jamais dans un chemin d'écriture local, et une partition WAN dégrade la latence de réplication, jamais la disponibilité locale. Le coût est une cohérence à terme entre les sites, bornée par cette latence — rendue observable plutôt que masquée.
Le change feed couple les sites
Chaque propriétaire de segment conserve déjà un op-log ordonné par révision de ses mutations. Le change feed est exactement cette queue d'op-log, servie comme un flux reprenable et bornée à ce qui est durable sur un réplica. Un pair tire (pull) le feed et l'applique localement. Parce que le feed est basé sur le pull, chaque site possède sa propre position et son propre contrôle de flux.
- Curseur — la position durable d'un site dans le feed d'un pair, une paire
(generation, revision). L'ordonnancement generation-first maintient un consommateur correct à travers les propres basculements du pair. Après un redémarrage ou une coupure WAN, un site reprend à partir de son curseur au lieu de se resynchroniser depuis zéro. - Origine — le site qui a écrit une valeur en premier. Un feed ne sert que les changements de sa propre origine, de sorte qu'une écriture ne revient jamais en écho dans une topologie bidirectionnelle.
Active-passive et active-active
- Active → passive — un site est le primaire actif ; le pair est un miroir en lecture seule qui le suit via le feed et refuse les écritures applicatives (les lectures et les surveillances continuent de fonctionner).
- Active-active — chaque site est actif et liste tous les autres sites comme pairs. Chaque site accepte les écritures localement, tire le feed de chaque pair, et tous les sites convergent.
Comment les écritures concurrentes convergent
Lorsque deux sites écrivent la même clé à peu près au même moment, le résultat est déterministe et symétrique — chaque site calcule le même gagnant, de sorte que tous les sites finissent identiques sans qu'un coordinateur arbitre entre eux.
- Version de conflit — une horloge logique hybride
(physicalMs, logical)plus l'identifiant du site d'origine, estampillée une seule fois sur l'écriture originale. Le last-writer-wins les compare dans l'ordre : temps physique, puis compteur logique, puis identifiant de site. - Les scalaires utilisent le last-writer-wins : l'écriture concurrente perdante est écartée. Utilisez des compteurs lorsque chaque mise à jour doit survivre.
- Les compteurs utilisent un PN-counter : chaque site apporte sa propre composante et la valeur est la somme, de sorte que les incréments concurrents sur différents sites ne sont jamais perdus.
- Les collections (hash, list, set, sorted-set, stream) sont en last-writer-wins par valeur entière dans cette version — un changement concurrent remplace la valeur entière par version, sans fusion au niveau des champs.
- Les suppressions sont des tombstones versionnés décidés par la même règle ; un clear est géo-conscient et se réplique sous forme de tombstones versionnés plutôt que de supprimer uniquement les données locales.
Ce qui reste local au site
La géo-réplication fait converger les données, pas la coordination. CAS, les transactions,
les verrous et baux sont locaux au site — ne les utilisez pas pour une exclusion mutuelle inter-sites.
Le TTL traverse comme une expiration absolue, de sorte qu'un élément expire au même instant d'horloge
murale sur chaque site (gardez les horloges synchronisées avec NTP). Une surveillance locale ne se déclenche que lorsqu'un
changement entrant remporte sa résolution de conflit.
Modèle de cohérence
La géo-réplication est cohérente à terme entre les sites : une lecture reflète l'état du site local, et les sites convergent à mesure que le feed se propage. Il n'y a pas de read-your-write ni de linéarisabilité inter-sites — c'est le compromis délibéré en faveur d'une disponibilité régionale indépendante et à faible latence.
Voir aussi
- Change Data Capture — le change feed sur lequel repose la réplication.
- Architecture de la géo-réplication — la conception complète et le flux de données.
- Guide du développeur sur la géo-réplication — configuration, cmdlets et exploitation.