Saltar al contenido principal
Geo-replicación · Novedad en 2.1.0

Geo-replicación activo-activo entre centros de datos

Ejecuta clústeres Zaris independientes en dos o más regiones y replica entre ellos mediante un feed de cambios reanudable y basado en pull. Cada sitio acepta escrituras localmente y sirve lecturas dentro de su región — y sigue funcionando por su cuenta si el enlace entre ellos llega a caerse.

Cómo funciona

Dos clústeres, un espacio de claves que converge

Esto no es un clúster extendido. Cada región es un clúster Zaris completo y autocoordinado que posee sus propios datos. Un feed de cambios duradero lleva las escrituras al otro lado, en ambos sentidos.

REGIÓN A · OESTEclúster Zaris independienteCluster An1n2n3particionado · RF ≥ 2▲ acepta escrituras localesop-log → feed de cambiosordenado por revisión · limitado por watermarkcursor ⟲(gen, rev) · duraderoREGIÓN B · ESTEclúster Zaris independienteCluster Bn1n2n3particionado · RF ≥ 2▲ acepta escrituras localesop-log → feed de cambiosordenado por revisión · limitado por watermarkcursor ⟲(gen, rev) · duraderofeed de cambios →← feed de cambiosEnlace WANpull · reanudableRESOLUCIÓN DE CONFLICTOS — determinista y simétricaEscalares → HLC last-writer-winsfísico · lógico · id de sitioContadores → PN-counterincrementos concurrentes preservadosEliminaciones → tombstones con versiónmás borrado con reconocimiento geográficoOBSERVABILIDADcontadores site.* — en ambas direccionesaplicados · omitidos · conflictos · bytes · tasas en vivoRPO = antigüedad de la operación sin aplicar más antigua≈ 0 cuando está al día · segundos de backlog cuando va por detrás
Por qué es diferente

Alcance global sin un coordinador en el medio

Baja latencia local en todas partes, disponibilidad independiente por sitio y un espacio de claves que converge por sí solo — con la observabilidad para demostrarlo.

Activo-activo, no conmutación por error

Cada sitio sirve lecturas y acepta escrituras localmente — sin región primaria, sin paso de promoción. Los usuarios acceden al centro de datos más cercano y obtienen latencia dentro de la región tanto en la ruta de lectura como en la de escritura.

Independiente por diseño

Cada sitio es su propio clúster autocoordinado, no uno extendido. Una pérdida total del enlace entre sitios no deja a nadie fuera de servicio: ambos lados siguen sirviendo y se reconcilian automáticamente cuando el enlace vuelve.

Converge de forma determinista

Las escrituras concurrentes se resuelven con last-writer-wins de reloj lógico híbrido, y los contadores usan un PN-counter para que todos los incrementos concurrentes de distintas regiones se conserven — cada región llega al mismo valor sin que un coordinador arbitre en el medio.

Reanudable desde un cursor duradero

La replicación es un feed de cambios basado en pull con un cursor duradero por sitio. Tras una caída o un reinicio, cada sitio se reanuda exactamente donde se detuvo — sin resincronización completa, sin ventana perdida.

Observable de extremo a extremo

Contadores site.* automáticos en ambas direcciones — aplicados, omitidos, conflictos, bytes y tasas en vivo — además de un RPO informado como la antigüedad de la operación sin aplicar más antigua: ≈0 cuando está al día, segundos de backlog reales cuando va por detrás.

Aditivo y desactivado por defecto

Un almacén sin configuración geográfica se comporta exactamente como antes. Activa la replicación por almacén y gestiónala en vivo desde la consola web o PowerShell — sin rediseño, sin nuevas piezas móviles que operar.

Míralo en vivo

Un mapa de replicación que de verdad puedes leer

  • Topología animadaLa consola web dibuja la imagen en vivo — sitios activos frente a pasivos, carriles unidireccionales frente a bidireccionales y recuentos de elementos por sitio — para que veas la forma de tu despliegue de un vistazo.
  • Banner de estado y aviso en el panelCada carril informa de si está en buen estado, retrasándose o detenido, mostrado como un banner y un aviso en el panel — sin tener que rastrear registros para saber cómo vas.
  • Un RPO en el que puedes confiarEl lag de replicación se informa como la antigüedad de la operación sin aplicar más antigua: cercano a cero cuando está al día, y subiendo a segundos de backlog reales en cuanto un sitio se queda atrás.
  • Gestión en vivoConfigura, cambia, suspende y reanuda la replicación desde la consola o los cmdlets de PowerShell. Un borrado con reconocimiento geográfico se replica a los pares mediante tombstones con versión.
● en buen estadoSitio Aactivo1.24M elementosSitio Bactivo1.24M elementosbidireccionalRPO ≈ 0.2santigüedad de la operación sin aplicar más antigua
Lo que puedes construir

Pon los datos donde están tus usuarios

Multirregión

Sirve a los usuarios cerca de ellos

Coloca un clúster en cada región donde viven tus usuarios. Cada uno responde localmente, así que un cliente en Fráncfort y un cliente en Virginia ven lecturas y escrituras a velocidad de caché — sobre los mismos datos.

Resiliencia

Recuperación ante desastres y conmutación por error regional

Pierde una región entera y las demás siguen sirviendo el mismo espacio de claves. Cuando la región vuelve, se reanuda desde su cursor y se pone al día por su cuenta.

Cumplimiento

Localidad y soberanía de los datos

Mantén una copia en vivo de los datos residente en cada jurisdicción mientras siguen convergiendo a una única vista consistente, de modo que las aplicaciones dentro de la región nunca crucen una frontera para leer o escribir.

Operaciones

Mantenimiento regional sin tiempo de inactividad

Drena, parchea o actualiza una región entera según tu calendario. El tráfico permanece en los pares, y la región se reincorpora y resincroniza cuando la vuelves a poner en marcha.

Pásate a multirregión en tus propios términos

La geo-replicación es aditiva y está desactivada de forma predeterminada — añádela a los almacenes que la necesiten y gestiónala en vivo. Validada en un despliegue en la nube de dos regiones sobre emparejamiento de red privada.