Geo-replicación y conceptos multi-sitio
La geo-replicación permite que un almacén de Clustron Zaris abarque más de un datacenter. Dos (o más) clústeres independientes — uno por región — cada uno acepta escrituras localmente y se replica con los demás a través de un change feed basado en pull y reanudable. Este es el modelo conceptual; la página de arquitectura cubre cómo está construido, y la guía del desarrollador cubre cómo lo activas y lo operas.
La geo-replicación es nueva en Zaris 2.1.0 y está desactivada de forma predeterminada — un almacén sin configuración de sitio se comporta exactamente como un almacén normal de un solo sitio.
Un sitio es un clúster independiente
Un sitio es un clúster de Zaris completo — su propia pertenencia, mapa de particiones, propiedad y quórum local — identificado por un id de sitio. La geo-replicación acopla los sitios únicamente a través del change feed; deliberadamente no es un clúster estirado.
Mantener los sitios independientes es todo el objetivo de un almacén en memoria: la latencia de la WAN nunca entra en una ruta de escritura local, y una partición de la WAN degrada el retardo de replicación, nunca la disponibilidad local. El coste es la consistencia eventual entre sitios, acotada por ese retardo — hecho observable en lugar de ocultado.
El change feed acopla los sitios
Cada propietario de un segmento ya mantiene un op-log ordenado por revisión de sus mutaciones. El change feed es exactamente esa cola del op-log, servida como un flujo reanudable y limitada a lo que es durable en una réplica. Un par tira (pull) del feed y lo aplica localmente. Como el feed está basado en pull, cada sitio es dueño de su propia posición y de su control de flujo.
- Cursor — la posición durable de un sitio en el feed de un par, un par
(generation, revision). El orden por generación primero mantiene a un consumidor correcto a través de los propios failovers del par. Tras un reinicio o un corte de la WAN, un sitio reanuda desde su cursor en lugar de resincronizar desde cero. - Origen — el sitio que escribió primero un valor. Un feed sirve solo sus propios cambios de origen, de modo que una escritura nunca rebota de vuelta en una topología bidireccional.
Activo-pasivo y activo-activo
- Activo → pasivo — un sitio es el primario activo; el par es un espejo de solo lectura que lo sigue a través del feed y rechaza las escrituras de aplicación (las lecturas y los watches siguen funcionando).
- Activo-activo — cada sitio está activo y lista a todos los demás sitios como pares. Cada sitio acepta escrituras localmente, tira del feed de cada par, y todos los sitios convergen.
Cómo convergen las escrituras concurrentes
Cuando dos sitios escriben la misma clave aproximadamente al mismo tiempo, el resultado es determinista y simétrico — cada sitio calcula el mismo ganador, de modo que todos los sitios acaban idénticos sin que un coordinador arbitre entre ellos.
- Versión de conflicto — un reloj lógico híbrido
(physicalMs, logical)más el id del sitio de origen, estampado una vez en la escritura original. El last-writer-wins los compara en orden: tiempo físico, luego contador lógico, luego id del sitio. - Los escalares usan last-writer-wins: la escritura concurrente perdedora se descarta. Usa contadores donde cada actualización deba sobrevivir.
- Los contadores usan un PN-counter: cada sitio aporta su propio componente y el valor es la suma, de modo que los incrementos concurrentes en sitios distintos nunca se pierden.
- Las colecciones (hash, list, set, sorted-set, stream) son de valor completo last-writer-wins en esta versión — un cambio concurrente reemplaza el valor completo por versión, sin fusión a nivel de campo.
- Las eliminaciones son tombstones versionados decididos por la misma regla; un clear es consciente de la geo-replicación y se replica como tombstones versionados en lugar de descartar solo los datos locales.
Qué permanece local al sitio
La geo-replicación converge datos, no coordinación. CAS, las transacciones,
los locks y leases son locales al sitio — no los uses para la exclusión mutua entre sitios.
El TTL cruza como una expiración absoluta, de modo que un elemento expira en el mismo instante de reloj
de pared en cada sitio (mantén los relojes sincronizados con NTP). Un watch local se dispara solo cuando un cambio
entrante gana su resolución de conflictos.
Modelo de consistencia
La geo-replicación es eventualmente consistente entre sitios: una lectura refleja el estado del sitio local, y los sitios convergen a medida que el feed se propaga. No hay lectura-de-tu-propia-escritura entre sitios ni linealizabilidad — esa es la concesión deliberada a cambio de una disponibilidad regional independiente y de baja latencia.
Relacionado
- Change Data Capture — el change feed sobre el que viaja la replicación.
- Arquitectura de geo-replicación — el diseño completo y el flujo de datos.
- Guía del desarrollador de geo-replicación — configuración, cmdlets y operaciones.