Saltar a contenido

CockroachDB Multi-Región

Toda arquitectura de MySQL o PostgreSQL entre regiones choca con el mismo límite: existe un primario. Las lecturas se distribuyen, la caché ayuda, la réplica local resuelve el SELECT — pero la escritura sigue teniendo que viajar hasta una única región.

Cuando el requisito es escribir localmente en más de una región, al mismo tiempo, la respuesta no es adaptar una base de primario único con replicación bidireccional — es usar una base diseñada para eso. CockroachDB habla el protocolo PostgreSQL, lo que permite reaprovechar drivers, herramientas y buena parte del SQL existente, y distribuye los datos en ranges replicados por consenso, sin primario y sin failover manual.

Cómo funciona

Los datos se dividen en ranges, y cada range se replica (tres copias, por defecto) en nodos diferentes. Cada escritura necesita la confirmación de la mayoría de las réplicas — el quórum. No hay promoción ni split-brain: si un nodo o un dominio entero cae, la mayoría restante sigue aceptando escritura.

Ranges replicados en tres dominios de fallo — br-sp-1, br-sp-2 y un tercero — con leaseholder por range y consenso Raft entre las réplicas

Cada range tiene tres réplicas en dominios de fallo distintos; la escritura se confirma por dos de las tres.

Dos regiones no forman quórum

Con solo dos dominios de fallo, la pérdida de uno deja la mitad de las réplicas — y la mitad no es mayoría. Una topología que sobrevive a la caída de una región entera necesita tres dominios de fallo: br-sp-1, br-sp-2 y un tercero, que puede ser otra región o un conjunto de nodos dedicado a formar quórum. Ese es el requisito que define el coste real del proyecto, y lo tratamos ya en el dimensionamiento.

Survival goals: cuánto debe sobrevivir el clúster

Comparación entre survive zone, que tolera la pérdida de un nodo o rack, y survive region, que tolera la pérdida de una región entera al coste de escritura entre regiones

La meta de supervivencia es una configuración de la base de datos, no un rediseño del clúster — y puede cambiar a medida que el sistema madura.

SURVIVE ZONE FAILURE SURVIVE REGION FAILURE
Tolera Pérdida de nodo, rack o zona Pérdida de una región entera
Distribución de las réplicas Puede concentrarse en una región Repartida por tres dominios
Latencia de escritura Menor, quórum local Paga el round trip entre regiones
Dominios necesarios Uno con múltiples zonas Tres
Recomendado para La mayoría de las aplicaciones Sistemas que no pueden parar con la caída de un centro de datos

Entre br-sp-1 y br-sp-2 la distancia se mide en milisegundos, así que SURVIVE REGION FAILURE cuesta mucho menos aquí que en una topología intercontinental — es justamente lo que hace viable la configuración en Brasil.

Localidad de tablas: dónde vive cada dato

Tablas REGIONAL BY ROW, REGIONAL BY TABLE y GLOBAL, con el efecto de cada una en la latencia de lectura y escritura

La localidad se define por tabla — y, en el caso de REGIONAL BY ROW, fila a fila.

  • REGIONAL BY ROW — cada fila tiene una región de origen. El cliente brasileño escribe en São Paulo, el cliente de otra región escribe allí, en la misma tabla, con la misma consulta SQL. Es el recurso que resuelve el caso multi-tenant sin sharding manual en la aplicación.
  • REGIONAL BY TABLE — la tabla entera tiene una región de origen. Escritura rápida en esa región, lectura desde cualquier lugar.
  • GLOBAL — lectura rápida en todas las regiones, escritura más costosa. Ideal para tablas de referencia: catálogos, tarifas, configuraciones.
  • Follower reads — lectura ligeramente desfasada atendida por la réplica local, sin cruzar la WAN. Excelente para informes y pantallas de consulta.

Cuándo tiene sentido — y cuándo no

Escenario Recomendación
SaaS multi-tenant con clientes en regiones diferentes CockroachDB, REGIONAL BY ROW
Escritura activa en dos regiones, sin elegir primario CockroachDB
La indisponibilidad regional es inaceptable, aunque sea de minutos CockroachDB, SURVIVE REGION FAILURE
Aplicación de lectura pesada, escritura concentrada PostgreSQL Multi-Región — más simple y más barato
Muchas extensiones PostgreSQL, procedures y SQL específico PostgreSQL — la compatibilidad es del protocolo, no de todo el ecosistema
Carga analítica, agregaciones sobre miles de millones de filas ClickHouse
Base pequeña y una única región Alta Disponibilidad PostgreSQL

Compatible no es idéntico

CockroachDB habla el protocolo PostgreSQL y cubre la mayor parte del SQL de aplicación, pero no es un PostgreSQL: extensiones, stored procedures, triggers y algunos comportamientos transaccionales difieren. Toda migración empieza con un inventario de compatibilidad y una prueba con la carga real, antes de cualquier decisión.

Operación en InteSys

  • Distribución entre br-sp-1, br-sp-2 y un tercer dominio de fallo, con localities declaradas de forma que la base sepa dónde está cada nodo y posicione las réplicas correctamente.
  • En Kubernetes o en máquinas virtuales — el clúster es homogéneo, todos los nodos ejecutan el mismo papel, lo que hace la operación previsible en cualquiera de las dos formas.
  • Upgrades y mantenimiento sin downtime, nodo a nodo, con el quórum siempre preservado.
  • Backup hacia almacenamiento de objetos, con restauración probada — el quórum protege contra fallos de infraestructura, no contra el error humano.
  • Observabilidad — latencia por región, distribución de ranges, hot ranges, salud del quórum y contención de transacciones.
  • Migración asistida desde PostgreSQL, con inventario de compatibilidad, carga de prueba y plan de cutover.

Soberanía de datos

En una base distribuida, "dónde está el dato" es una configuración, no una consecuencia — y eso es lo que permite conciliar escritura multi-región con residencia de datos en Brasil.

  • Tres dominios de fallo dentro de Brasil — cuando la soberanía es requisito, el tercer dominio también es brasileño. El clúster sobrevive a la pérdida de una región entera sin que ninguna réplica salga del país.
  • REGIONAL BY ROW fija el dato en su región de origen — la fila del cliente brasileño se escribe y se mantiene en Brasil, incluso en un clúster que atiende otras regiones. Es el mecanismo que permite operar fuera del país sin mezclar residencia de datos.
  • Un dominio de fallo en otro país es una decisión explícita — mejora la supervivencia y crea transferencia internacional de datos; la base legal entra en el diseño de la solución, no después.
  • Backup y snapshot con destino elegido — backup a almacenamiento de objetos en Brasil por defecto y, en Kubernetes, snapshot de volumen cifrado que puede quedarse en el país o replicarse a otro, a pedido. Vea Alta Disponibilidad PostgreSQL.
  • LGPD — en la topología estándar, íntegramente brasileña, no hay transferencia internacional que documentar.

Cómo lo implementa InteSys

  1. Evaluación del requisito — confirmar que el caso realmente exige escritura multi-región; muchas veces una réplica de lectura lo resuelve por una fracción del coste.
  2. Inventario de compatibilidad — mapeo del SQL, las extensiones y los comportamientos transaccionales en uso.
  3. Diseño de la topología — regiones, tercer dominio de fallo, número de nodos y survival goal.
  4. Localidad de los datos — definición de qué tablas son REGIONAL BY ROW, REGIONAL BY TABLE o GLOBAL.
  5. Aprovisionamiento — clúster en Kubernetes o VMs, con localities y anti-affinity correctas.
  6. Prueba de fallo — tumbamos un dominio entero en un entorno controlado y medimos el impacto real en la aplicación.
  7. Migración — carga inicial, sincronización y cutover con ventana corta.
  8. Observabilidad y runbook — paneles, alertas y procedimiento documentado.

El camino más barato suele venir antes

La escritura multi-región resuelve un problema real, pero no es el primer paso de todo proyecto. Si su carga está dominada por la lectura, empiece por PostgreSQL Multi-Región. Si la indisponibilidad regional es el riesgo central, CockroachDB es la respuesta directa. Hable con nuestro equipo para evaluar cuál de los dos atiende su caso.

Próximos Pasos