Pular para conteúdo

Cargas com Estado e Armazenamento

Aplicações sem estado são naturalmente fáceis de distribuir entre regiões. Aplicações com estado exigem que a localização do dado seja tratada como parte da arquitetura — um volume que existe em uma região não está automaticamente disponível nas outras.

Cargas sem estado distribuídas entre regiões, bancos replicados e volumes que não cruzam a fronteira regional

A computação pode ser distribuída. O dado exige uma estratégia de disponibilidade compatível com essa distribuição.

Mobilidade de computação ≠ localização do dado

Esta é a distinção central de qualquer arquitetura multi-região:

Cargas sem estado Cargas com estado
Onde executam Qualquer zona com capacidade Onde o dado está
Como se recuperam Nova réplica em outro nó Promoção de réplica com dado consistente
O que o agendador precisa saber Recursos e spread Topologia do volume
Custo de errar Um pod reiniciado Perda ou divergência de dados

O Kubernetes usa a informação de topologia do armazenamento para impedir que uma carga inicie em uma região onde seu volume não existe. Isso é proteção, não limitação: um banco que sobe sem o seu dado é pior do que um banco que não sobe.

Replicação é responsabilidade da tecnologia de dados

Para que uma aplicação sobreviva à perda completa de uma região, a replicação precisa ser feita pela própria aplicação ou pela tecnologia de armazenamento — cada região mantém o seu armazenamento, e quem entende o dado controla a replicação.

Tecnologias que operamos nesse modelo:

  • bancos relacionais replicados — MySQL e PostgreSQL;
  • bancos distribuídos com escrita local em várias regiões — CockroachDB;
  • plataformas de fila e streaming — Kafka;
  • busca e análise — Elasticsearch / OpenSearch, ClickHouse;
  • plataformas de armazenamento com replicação regional.

Replicação contínua, não transferência de emergência

O erro clássico é assumir que, se a região cair, os dados serão copiados para a outra. Mover volumes grandes pela WAN depois que a região já falhou não é um plano de continuidade. A replicação precisa estar correndo antes do incidente.

Alta disponibilidade de cargas com estado

Quando a aplicação precisa sobreviver à perda de uma região, o arranjo mínimo é um primário em uma região e uma réplica na outra, com armazenamento próprio em cada lado — por exemplo, PostgreSQL em br-sp-1 replicando para br-sp-2, ou um primário na InteSys replicando para uma nuvem pública.

Dependendo da tecnologia, replicação e eleição de líder ficam a cargo da aplicação, do próprio motor de banco ou da plataforma de armazenamento. O que não muda são os requisitos que a arquitetura precisa atender:

  • quórum com número ímpar de votantes;
  • eleição de líder determinística;
  • fencing do primário antigo antes de qualquer promoção;
  • prevenção de split-brain em partição de rede;
  • monitoramento de lag — uma réplica que ficou para trás em silêncio não é uma réplica.

O detalhamento por tecnologia — modos de replicação, RPO de cada arranjo, sequência de failover — está na seção de Administração de Banco de Dados.

Backup continua sendo obrigatório

Replicação entre regiões cobre falha de infraestrutura. Não cobre DROP TABLE, deploy com erro, corrupção lógica ou ransomware — esses são replicados fielmente para todas as réplicas, em segundos.

Por isso, mesmo em arquitetura multi-região, o cluster carrega backup com restauração testada e recuperação a ponto no tempo, armazenado fora dos nós que ele protege.

Soberania de dados

Uma topologia entre br-sp-1 e br-sp-2 mantém dado primário, réplicas, logs e backups no Brasil, sob jurisdição brasileira e sem transferência internacional de dados pessoais.

Quando a arquitetura inclui uma região fora do país, isso passa a ser uma decisão de conformidade — documentada no desenho da solução, com escopo limitado ao que realmente precisa sair, e nunca um padrão da plataforma.

Páginas Relacionadas