Os principais objetivos de uma configuração multi-datacenter (ou multi-DC) - independentemente de o ecossistema de banco de dados ser SQL (PostgreSQL, MySQL) ou NoSQL (MongoDB, Cassandra) para citar apenas alguns - são baixa latência para usuários finais, Alta Disponibilidade e Recuperação de Desastres. No coração de tal ambiente está a capacidade de replicar dados, de forma a garantir sua durabilidade (como uma nota lateral, os parâmetros de configuração de durabilidade do Cassandra são semelhantes aos usados pelo PostgreSQL). Os vários requisitos de replicação serão discutidos abaixo, no entanto, os casos extremos serão deixados para os curiosos para futuras pesquisas.
A replicação usando o envio de log assíncrono está disponível no PostgreSQL há muito tempo, e a replicação síncrona introduzida na versão 9.1 abriu um novo conjunto de opções para desenvolvedores de ferramentas de gerenciamento do PostgreSQL.
Coisas a considerar
Uma maneira de entender a complexidade de uma implementação multi-DC do PostgreSQL é aprender com as soluções implementadas para outros sistemas de banco de dados, tendo em mente que o PostgreSQL insiste em ser compatível com ACID.
Uma configuração multi-DC inclui, na maioria dos casos, pelo menos um datacenter na nuvem. Embora os provedores de nuvem assumam o ônus de gerenciar a replicação do banco de dados em nome de seus clientes, eles geralmente não correspondem aos recursos disponíveis em ferramentas de gerenciamento especializadas. Por exemplo, com muitas empresas adotando soluções de nuvem híbrida e/ou multinuvem, além de sua infraestrutura local existente, uma ferramenta multi-DC deve ser capaz de lidar com esse ambiente misto.
Além disso, para minimizar o tempo de inatividade durante um failover, o sistema de gerenciamento do PostgreSQL deve ser capaz de solicitar (através de uma chamada de API) uma atualização de DNS, para que as solicitações do banco de dados sejam roteadas para o novo cluster mestre.
As redes que abrangem grandes áreas geográficas são conexões de alta latência e todas as soluções devem comprometer:esqueça a replicação síncrona e use um primário com muitas réplicas de leitura. Consulte os estudos do AWS MongoDB e do Cluster da Multiplenines/Galera para obter uma análise detalhada dos efeitos da rede na replicação. Em uma nota relacionada, uma ferramenta bacana para testar a latência entre locais é o Wonder Network Ping Statistics.
Embora a natureza de alta latência da WAN não possa ser alterada, a experiência do usuário pode ser melhorada drasticamente, garantindo que as leituras sejam fornecidas a partir de uma réplica de leitura próxima ao local do usuário, porém com algumas ressalvas. Ao mover as réplicas para longe do primário, as gravações são atrasadas e, portanto, devemos acabar com a replicação síncrona. A solução também deve ser capaz de contornar outros problemas, como consistência de leitura após gravação e leituras secundárias obsoletas devido à perda de conexão.
Para minimizar o RTO, os dados precisam ser replicados para um armazenamento durável que também seja capaz de fornecer alta taxa de transferência de leitura e, de acordo com a Citus Data, uma opção que atende a esses requisitos é o AWS S3.
A própria noção de datacenter múltiplo implica que o sistema de gerenciamento de banco de dados deve ser capaz de apresentar ao DBA uma visão global de todos os datacenters e os vários clusters PostgreSQL dentro deles, gerenciar várias versões do PostgreSQL e configurar a replicação entre eles.
Ao replicar gravações em data centers regionais, o atraso de propagação deve ser monitorado. Se o atraso exceder um limite, um alarme deve ser acionado indicando que a réplica contém dados obsoletos. O mesmo princípio se aplica à replicação multimestre assíncrona.
Em uma configuração síncrona, alta latência ou interrupções de rede podem levar a atrasos no atendimento de solicitações de clientes enquanto aguardam a conclusão da confirmação, enquanto em configurações assíncronas há riscos de cérebro dividido ou desempenho degradado por um longo período de tempo. Split-brain e atrasos em commits síncronos são inevitáveis mesmo com soluções de replicação bem estabelecidas, conforme explicado no artigo Geo-Distributed Database Clusters with Galera.
Outra consideração é o suporte do fornecedor — até o momento, a AWS não oferece suporte a réplicas entre regiões do PostgreSQL.
Os sistemas de gerenciamento inteligente devem monitorar a latência da rede entre os data centers e recomendar ou ajustar as alterações, por exemplo. a replicação síncrona funciona perfeitamente entre as zonas de disponibilidade da AWS em que os data centers são conectados usando redes de fibra. Dessa forma, uma solução pode atingir zero perda de dados e também pode implementar a replicação mestre-mestre junto com o balanceamento de carga. Observe que o AWS Aurora PostgreSQL não oferece atualmente uma opção de replicação mestre-mestre.
Decida o nível de replicação:cluster, banco de dados, tabela. Os critérios de decisão devem incluir custos de largura de banda.
Implemente a replicação em cascata para contornar as interrupções de rede que podem impedir que as réplicas recebam atualizações do mestre devido à distância geográfica.
Soluções
Levando em consideração todos os requisitos, identifique os produtos mais adequados para o trabalho. No entanto, uma nota de cautela:cada solução vem com suas próprias advertências que devem ser tratadas seguindo as recomendações na documentação do produto. Veja, por exemplo, o requisito de monitoramento de BDR.
A documentação oficial do PostgreSQL contém uma lista de aplicativos de código aberto não comerciais, e uma lista expandida incluindo soluções comerciais de código fechado pode ser encontrada na página wiki Replication, Clustering, and Connection Pooling. Algumas dessas ferramentas foram analisadas com mais detalhes no artigo Top PG Clustering HA Solutions for PostgreSQL.
Não existe uma solução pronta para uso, mas alguns produtos podem fornecer a maioria dos recursos, especialmente ao trabalhar com o fornecedor.
Aqui está uma lista não exaustiva:
- Citus Data fornece sua própria compilação PostgreSQL, aprimorada com recursos corporativos impressionantes e integração profunda com a AWS.
- EnterpriseDB oferece um grande conjunto de serviços que podem ser combinados para atender à maioria dos requisitos. A maioria das informações está na documentação do produto.
- O Postgres-BDR é uma poderosa ferramenta de replicação projetada especificamente para clusters distribuídos geograficamente, mas não se integra a nenhum provedor de nuvem.
- O ClusterControl vem com um impressionante conjunto de recursos para gerenciar o PostgreSQL. Ele também tem integração limitada na nuvem.
- O ElephantSQL funciona em muitos provedores de nuvem. No entanto, não há opção para uma configuração local.
- O Crunchy PostgreSQL para Kubernetes é um produto independente de nuvem criado no PostgreSQL upstream.
Conclusão
Como vimos, quando se trata de escolher uma solução de vários datacenters PostgreSQL, não existe uma solução única para todos. Muitas vezes, o compromisso é uma obrigação. No entanto, uma boa compreensão dos requisitos e implicações pode ajudar muito a tomar uma decisão informada.
Em comparação com dados estáticos (somente leitura), uma solução para bancos de dados precisa considerar a replicação de atualizações (gravações). A literatura que descreve as soluções de replicação SQL e NoSQL insiste em usar uma única fonte de verdade para gravações com muitas réplicas, a fim de evitar problemas como split-brain e consistência de leitura após gravação.
Por fim, a interoperabilidade é um requisito fundamental, considerando que as configurações multi-DC podem abranger data centers localizados no local e vários provedores de nuvem.
