Pular para conteúdo

CockroachDB Multi-Região

Toda arquitetura de MySQL ou PostgreSQL entre regiões esbarra no mesmo limite: existe um primário. As leituras se distribuem, o cache ajuda, a réplica local resolve o SELECT — mas a escrita continua tendo que viajar até uma única região.

Quando o requisito é escrever localmente em mais de uma região, ao mesmo tempo, a resposta não é adaptar um banco de primário único com replicação bidirecional — é usar um banco projetado para isso. O CockroachDB fala o protocolo PostgreSQL, o que permite reaproveitar drivers, ferramentas e boa parte do SQL existente, e distribui os dados em ranges replicados por consenso, sem primário e sem failover manual.

Como funciona

Os dados são divididos em ranges, e cada range é replicado (três cópias, por padrão) em nós diferentes. Cada escrita precisa da confirmação da maioria das réplicas — o quórum. Não há promoção, não há split-brain: se um nó ou um domínio inteiro cai, a maioria restante continua aceitando escrita.

Ranges replicados em três domínios de falha — br-sp-1, br-sp-2 e um terceiro — com leaseholder por range e consenso Raft entre as réplicas

Cada range tem três réplicas em domínios de falha distintos; a escrita é confirmada por dois dos três.

Duas regiões não formam quórum

Com apenas dois domínios de falha, a perda de um deles deixa metade das réplicas — e metade não é maioria. Uma topologia que sobrevive à queda de uma região inteira precisa de três domínios de falha: br-sp-1, br-sp-2 e um terceiro, que pode ser outra região ou um conjunto de nós dedicado a formar quórum. Esse é o requisito que define o custo real do projeto, e tratamos disso logo no dimensionamento.

Survival goals: quanto o cluster precisa sobreviver

Comparação entre survive zone, que tolera a perda de um nó ou rack, e survive region, que tolera a perda de uma região inteira ao custo de escrita entre regiões

A meta de sobrevivência é uma configuração do banco de dados, não um redesenho do cluster — e pode mudar conforme o sistema amadurece.

SURVIVE ZONE FAILURE SURVIVE REGION FAILURE
Tolera Perda de nó, rack ou zona Perda de uma região inteira
Distribuição das réplicas Pode concentrar em uma região Espalhada por três domínios
Latência de escrita Menor, quórum local Paga o round trip entre regiões
Domínios necessários Um com múltiplas zonas Três
Indicado para Maioria das aplicações Sistemas que não podem parar com a queda de um datacenter

Entre br-sp-1 e br-sp-2 a distância é métrica de milissegundos, então SURVIVE REGION FAILURE custa muito menos aqui do que em uma topologia intercontinental — é justamente o que torna a configuração viável no Brasil.

Localidade de tabelas: onde cada dado vive

Tabelas REGIONAL BY ROW, REGIONAL BY TABLE e GLOBAL, com o efeito de cada uma na latência de leitura e escrita

A localidade é definida por tabela — e, no caso de REGIONAL BY ROW, linha a linha.

  • REGIONAL BY ROW — cada linha tem uma região de origem. O cliente brasileiro grava em São Paulo, o cliente de outra região grava lá, na mesma tabela, com a mesma consulta SQL. É o recurso que resolve o caso multi-tenant sem sharding manual na aplicação.
  • REGIONAL BY TABLE — a tabela inteira tem uma região de origem. Escrita rápida nessa região, leitura de qualquer lugar.
  • GLOBAL — leitura rápida em todas as regiões, escrita mais cara. Ideal para tabelas de referência: catálogos, tarifas, configurações.
  • Follower reads — leitura levemente defasada atendida pela réplica local, sem cruzar a WAN. Excelente para relatórios e telas de consulta.

Quando faz sentido — e quando não faz

Cenário Recomendação
SaaS multi-tenant com clientes em regiões diferentes CockroachDB, REGIONAL BY ROW
Escrita ativa em duas regiões, sem eleger primário CockroachDB
Indisponibilidade regional é inaceitável, mesmo por minutos CockroachDB, SURVIVE REGION FAILURE
Aplicação de leitura pesada, escrita concentrada PostgreSQL Multi-Região — mais simples e mais barato
Muitas extensões PostgreSQL, procedures e SQL específico PostgreSQL — a compatibilidade é do protocolo, não de todo o ecossistema
Carga analítica, agregações sobre bilhões de linhas ClickHouse
Banco pequeno e uma única região Alta Disponibilidade PostgreSQL

Compatível não é idêntico

O CockroachDB fala o protocolo PostgreSQL e cobre a maior parte do SQL de aplicação, mas não é um PostgreSQL: extensões, stored procedures, gatilhos e alguns comportamentos transacionais diferem. Toda migração começa com um inventário de compatibilidade e um teste com a carga real, antes de qualquer decisão.

Operação na InteSys

  • Distribuição entre br-sp-1, br-sp-2 e um terceiro domínio de falha, com localities declaradas de forma que o banco saiba onde cada nó está e posicione as réplicas corretamente.
  • Em Kubernetes ou em máquinas virtuais — o cluster é homogêneo, todos os nós rodam o mesmo papel, o que torna a operação previsível em qualquer uma das duas formas.
  • Upgrades e manutenção sem downtime, nó a nó, com o quórum sempre preservado.
  • Backup para armazenamento de objetos, com restauração testada — o quórum protege contra falha de infraestrutura, não contra erro humano.
  • Observabilidade — latência por região, distribuição de ranges, hot ranges, saúde do quórum e contenção de transações.
  • Migração assistida a partir do PostgreSQL, com inventário de compatibilidade, carga de teste e plano de cutover.

Soberania de dados

Em um banco distribuído, "onde o dado está" é configuração, não consequência — e é isso que permite conciliar escrita multi-região com residência de dados no Brasil.

  • Três domínios de falha dentro do Brasil — quando a soberania é requisito, o terceiro domínio também é nacional. O cluster sobrevive à perda de uma região inteira sem que nenhuma réplica saia do país.
  • REGIONAL BY ROW fixa o dado na região de origem — a linha do cliente brasileiro é gravada e mantida no Brasil, mesmo em um cluster que atende outras regiões. É o mecanismo que permite operar fora do país sem misturar residência de dados.
  • Domínio de falha em outro país é decisão explícita — melhora a sobrevivência e cria transferência internacional de dados; a base legal entra no desenho da solução, não depois.
  • Backup e snapshot com destino escolhido — backup para armazenamento de objetos no Brasil por padrão e, em Kubernetes, snapshot de volume criptografado que pode ficar no país ou ser replicado para outro, a pedido. Veja Alta Disponibilidade PostgreSQL.
  • LGPD — na topologia padrão, integralmente brasileira, não há transferência internacional a documentar.

Como a InteSys implanta

  1. Avaliação do requisito — confirmar que o caso realmente exige escrita multi-região; muitas vezes uma réplica de leitura resolve por uma fração do custo.
  2. Inventário de compatibilidade — mapeamento do SQL, extensões e comportamentos transacionais em uso.
  3. Desenho da topologia — regiões, terceiro domínio de falha, número de nós e survival goal.
  4. Localidade dos dados — definição de quais tabelas são REGIONAL BY ROW, REGIONAL BY TABLE ou GLOBAL.
  5. Provisionamento — cluster em Kubernetes ou VMs, com localities e anti-affinity corretas.
  6. Teste de falha — derrubamos um domínio inteiro em ambiente controlado e medimos o impacto real na aplicação.
  7. Migração — carga inicial, sincronização e cutover com janela curta.
  8. Observabilidade e runbook — painéis, alertas e procedimento documentado.

O caminho mais barato costuma vir antes

Escrita multi-região resolve um problema real, mas não é o primeiro passo de todo projeto. Se a sua carga é dominada por leitura, comece por PostgreSQL Multi-Região. Se a indisponibilidade regional é o risco central, o CockroachDB é a resposta direta. Fale com nossa equipe para avaliar qual dos dois atende ao seu caso.

Próximos Passos