Esta página foi traduzida pela API Cloud Translation.

Arquiteturas para alta disponibilidade de clusters do PostgreSQL no Compute Engine

Last reviewed 2024-12-03 UTC

Este documento descreve várias arquiteturas que oferecem alta disponibilidade (HA) para implementações do PostgreSQL no Google Cloud. A HA é a medida da capacidade de recuperação do sistema em resposta a falhas da infraestrutura subjacente. Neste documento, a HA refere-se à disponibilidade de clusters do PostgreSQL numa única região da nuvem ou entre várias regiões, consoante a arquitetura de HA.

Este documento destina-se a administradores de bases de dados, arquitetos de nuvem e engenheiros de DevOps que querem saber como aumentar a fiabilidade da camada de dados do PostgreSQL melhorando o tempo de atividade geral do sistema. Este documento aborda conceitos relevantes para a execução do PostgreSQL no Compute Engine. O documento não aborda a utilização de bases de dados geridas, como o Cloud SQL para PostgreSQL e o AlloyDB para PostgreSQL.

Se um sistema ou uma aplicação exigir um estado persistente para processar pedidos ou transações, a camada de persistência de dados (o nível de dados) tem de estar disponível para processar com êxito os pedidos de consultas ou mutações de dados. O tempo de inatividade na camada de dados impede que o sistema ou a aplicação execute as tarefas necessárias.

Consoante os objetivos ao nível do serviço (SLOs) do seu sistema, pode precisar de uma arquitetura que ofereça um nível de disponibilidade mais elevado. Existem várias formas de alcançar a HA, mas, em geral, aprovisiona uma infraestrutura redundante que pode tornar rapidamente acessível à sua aplicação.

Este documento aborda os seguintes tópicos:

Definição dos termos relacionados com os conceitos da base de dados de HA.
Opções para topologias PostgreSQL de HA.
Informações contextuais para consideração de cada opção de arquitetura.

Terminologia

Os seguintes termos e conceitos são padrão da indústria e são úteis para compreender fins que vão além do âmbito deste documento.

replicação: O processo através do qual as transações de escrita (INSERT, UPDATE ou DELETE) e as alterações ao esquema (linguagem de definição de dados (DDL)) são captadas, registadas e, em seguida, aplicadas em série a todos os nós de réplica da base de dados a jusante na arquitetura.
nó principal: O nó que fornece uma leitura com o estado mais atualizado dos dados persistentes. Todas as escritas na base de dados têm de ser direcionadas para um nó principal.
nó de réplica (secundário): Uma cópia online do nó da base de dados principal. As alterações são replicadas de forma síncrona ou assíncrona para os nós de réplica a partir do nó principal. Pode ler a partir de nós de réplica, tendo em atenção que os dados podem sofrer um ligeiro atraso devido ao intervalo de tempo da replicação.
intervalo de tempo da replicação: Uma medição, no número de sequência do registo (LSN), no ID da transação ou na hora. O intervalo de tempo da replicação expressa a diferença entre o momento em que as operações de alteração são aplicadas à réplica e o momento em que são aplicadas ao nó principal.
arquivagem contínua: Uma cópia de segurança incremental em que a base de dados guarda continuamente transações sequenciais num ficheiro.
Registo de escrita antecipada (WAL): Um registo de escrita antecipada (WAL) é um ficheiro de registo que regista as alterações aos ficheiros de dados antes de as alterações serem efetivamente feitas aos ficheiros. Em caso de falha do servidor, o WAL é uma forma padrão de ajudar a garantir a integridade dos dados e a durabilidade das suas gravações.
Registo WAL: Um registo de uma transação que foi aplicada à base de dados. Um registo WAL é formatado e armazenado como uma série de registos que descrevem alterações ao nível da página do ficheiro de dados.
Número de sequência do registo (LSN): As transações criam registos WAL que são anexados ao ficheiro WAL. A posição onde ocorre a inserção é denominada número de sequência do registo (LSN). É um número inteiro de 64 bits, representado como dois números hexadecimais separados por uma barra (XXXXXXXX/YYZZZZZZ). O "Z" representa a posição de desvio no ficheiro WAL.
ficheiros de segmentos: Ficheiros que contêm o maior número possível de registos WAL, consoante o tamanho do ficheiro que configurar. Os ficheiros de segmentos têm nomes de ficheiros que aumentam monotonicamente e um tamanho de ficheiro predefinido de 16 MB.
replicação síncrona: Uma forma de replicação em que o servidor principal aguarda que a réplica confirme que os dados foram escritos no registo de transações da réplica antes de confirmar uma confirmação ao cliente. Quando executa a replicação de streaming, pode usar a opção synchronous_commit do PostgreSQL, que ajuda a garantir a consistência entre o servidor principal e a réplica.
replicação assíncrona: Uma forma de replicação em que o servidor principal não aguarda que a réplica confirme que a transação foi recebida com êxito antes de confirmar uma confirmação ao cliente. A replicação assíncrona tem uma latência inferior em comparação com a replicação síncrona. No entanto, se o nó principal falhar e as respetivas transações comprometidas não forem transferidas para a réplica, existe a possibilidade de perda de dados. A replicação assíncrona é o modo de replicação predefinido no PostgreSQL, quer use o envio de registos baseado em ficheiros ou a replicação de streaming.
Envio de registos com base em ficheiros: Um método de replicação no PostgreSQL que transfere os ficheiros de segmento WAL do servidor de base de dados principal para a réplica. O serviço principal funciona no modo de arquivo contínuo, enquanto cada serviço de espera funciona no modo de recuperação contínua para ler os ficheiros WAL. Este tipo de replicação é assíncrono.
replicação de streaming: Um método de replicação em que a réplica se liga ao principal e recebe continuamente uma sequência contínua de alterações. Uma vez que as atualizações chegam através de um fluxo, este método mantém a réplica mais atualizada em relação à base de dados principal quando comparado com a replicação de envio de registos. Embora a replicação seja assíncrona por predefinição, pode configurar a replicação síncrona em alternativa.
replicação de streaming física: Um método de replicação que transporta as alterações para a réplica. Este método usa os registos WAL que contêm as alterações físicas aos dados sob a forma de endereços de blocos de disco e alterações byte a byte.
replicação de streaming lógica: Um método de replicação que capta as alterações com base na respetiva identidade de replicação (chave primária), o que permite um maior controlo sobre a forma como os dados são replicados em comparação com a replicação física. Devido a restrições na replicação lógica do PostgreSQL, a replicação de streaming lógico requer uma configuração especial para uma configuração de HA. Este guia aborda a replicação física padrão e não aborda a replicação lógica.
tempo de atividade: A percentagem de tempo em que um recurso está a funcionar e é capaz de fornecer uma resposta a um pedido.
deteção de falhas: O processo de identificação de que ocorreu uma falha de infraestrutura.
ativação pós-falha: O processo de promoção da infraestrutura de reserva ou em espera (neste caso, o nó de réplica) para se tornar a infraestrutura principal. Durante a comutação por falha, o nó de réplica torna-se o nó principal.
comutação: O processo de execução de uma comutação por falha manual num sistema de produção. Uma comutação testa se o sistema está a funcionar bem ou retira o nó principal atual do cluster para manutenção.
objetivo de tempo de recuperação (OTR): A duração decorrida em tempo real para a conclusão do processo de comutação por falha da camada de dados. O RTO depende do tempo aceitável do ponto de vista empresarial.
objetivo de ponto de recuperação (OPR): A quantidade de perda de dados (em tempo real decorrido) que o nível de dados vai suportar como resultado da comutação por falha. O RPO depende da quantidade de perda de dados que é aceitável do ponto de vista empresarial.
alternativo: O processo de reposição do nó principal anterior após a condição que causou uma comutação por falha ser corrigida.
autorreparação: A capacidade de um sistema resolver problemas sem ações externas por parte de um operador humano.
partição de rede: Uma condição em que dois nós numa arquitetura, por exemplo, os nós principal e de réplica, não conseguem comunicar entre si através da rede.
cérebro dividido: Uma condição que ocorre quando dois nós acreditam simultaneamente que são o nó principal.
grupo de nós: Um conjunto de recursos de computação que fornecem um serviço. Neste documento, esse serviço é a camada de persistência de dados.
nó de testemunha ou quórum: Um recurso de computação separado que ajuda um grupo de nós a determinar o que fazer quando ocorre uma condição de divisão de cérebro.
eleição primária ou de líder: O processo através do qual um grupo de nós com reconhecimento de pares, incluindo nós de testemunho, determina qual deve ser o nó principal.

Quando deve considerar uma arquitetura de HA

As arquiteturas de HA oferecem maior proteção contra o tempo de inatividade da camada de dados quando comparadas com configurações de base de dados de nó único. Para selecionar a melhor opção para o seu exemplo de utilização empresarial, tem de compreender a sua tolerância a tempo de inatividade e as respetivas compensações das várias arquiteturas.

Use uma arquitetura de AD quando quiser oferecer um tempo de atividade da camada de dados aumentado para cumprir os requisitos de fiabilidade das suas cargas de trabalho e serviços. Se o seu ambiente tolerar alguma indisponibilidade, uma arquitetura de HA pode introduzir custos e complexidade desnecessários. Por exemplo, os ambientes de desenvolvimento ou de teste raramente precisam de uma disponibilidade de nível elevado da base de dados.

Considere os seus requisitos de HA

Seguem-se várias perguntas para ajudar a decidir que opção de HA do PostgreSQL é melhor para a sua empresa:

Que nível de disponibilidade espera alcançar? Precisa de uma opção que permita que o seu serviço continue a funcionar durante apenas uma zona ou uma falha regional completa? Algumas opções de HA estão limitadas a uma região, enquanto outras podem ser multirregionais.
Que serviços ou clientes dependem do seu nível de dados e qual é o custo para a sua empresa se houver tempo de inatividade no nível de persistência de dados? Se um serviço se destinar apenas a clientes internos que requerem uma utilização ocasional do sistema, é provável que tenha requisitos de disponibilidade mais baixos do que um serviço virado para o cliente final que serve os clientes continuamente.
Qual é o seu orçamento operacional? O custo é uma consideração importante: para fornecer HA, é provável que os custos de infraestrutura e armazenamento aumentem.
Quão automatizado tem de ser o processo e com que rapidez tem de fazer a comutação por falha? (Qual é o seu RTO?) As opções de HA variam consoante a rapidez com que o sistema pode fazer failover e ficar disponível para os clientes.
Pode perder dados como resultado da comutação por falha? (Qual é o seu RPO?) Devido à natureza distribuída das topologias de HA, existe uma relação de compromisso entre a latência de confirmação e o risco de perda de dados devido a uma falha.

Como funciona a HA

Esta secção descreve a replicação de streaming e streaming síncrono que estão na base das arquiteturas de HA do PostgreSQL.

Replicação de streaming

A replicação de streaming é uma abordagem de replicação na qual a réplica se liga à base de dados principal e recebe continuamente um fluxo de registos WAL. Em comparação com a replicação de envio de registos, a replicação de streaming permite que a réplica se mantenha mais atualizada com a principal. O PostgreSQL oferece replicação de streaming incorporada a partir da versão 9. Muitas soluções de HA do PostgreSQL usam a replicação de streaming incorporada para fornecer o mecanismo para que vários nós de réplica do PostgreSQL sejam mantidos sincronizados com o nó principal. Várias destas opções são abordadas na secção Arquiteturas de HA do PostgreSQL mais adiante neste documento.

Cada nó de réplica requer recursos de computação e armazenamento dedicados. A infraestrutura do nó de réplica é independente da principal. Pode usar nós de réplica como hot standbys para publicar consultas de clientes só de leitura. Esta abordagem permite o equilíbrio de carga de consultas de leitura apenas na base de dados principal e numa ou mais réplicas.

Por predefinição, a replicação de streaming é assíncrona. O servidor principal não aguarda uma confirmação de uma réplica antes de confirmar uma confirmação de transação ao cliente. Se um servidor principal sofrer uma falha depois de confirmar a transação, mas antes de uma réplica receber a transação, a replicação assíncrona pode resultar numa perda de dados. Se a réplica for promovida para se tornar uma nova principal, essa transação não está presente.

Replicação de streaming síncrona

Pode configurar a replicação de streaming como síncrona escolhendo uma ou mais réplicas para serem uma réplica de reserva síncrona. Se configurar a sua arquitetura para a replicação síncrona, o servidor principal não confirma a confirmação de uma transação até que a réplica reconheça a persistência da transação. A replicação de streaming síncrona oferece maior durabilidade em troca de uma latência de transação mais elevada.

A opção de configuração synchronous_commit também permite configurar os seguintes níveis de durabilidade de réplicas progressivas para a transação:

local: as réplicas em espera síncronas não estão envolvidas na confirmação da confirmação. O nó principal confirma as confirmações de transações depois de os registos WAL serem escritos e descarregados para o respetivo disco local. Os commits de transações no servidor principal não envolvem réplicas em espera. As transações podem ser perdidas se ocorrer alguma falha no dispositivo principal.
on [predefinição]: as réplicas em espera síncronas escrevem as transações comprometidas no respetivo WAL antes de enviarem a confirmação à principal. A utilização da configuração on garante que a transação só pode ser perdida se a réplica principal e todas as réplicas em espera síncronas sofrerem falhas de armazenamento simultâneas. Uma vez que as réplicas só enviam uma confirmação depois de escreverem registos WAL, os clientes que consultam a réplica não veem alterações até que os registos WAL respetivos sejam aplicados à base de dados da réplica.
remote_write: as réplicas de standby síncronas confirmam a receção do registo WAL ao nível do SO, mas não garantem que o registo WAL foi escrito no disco. Uma vez que remote_write não garante que a WAL foi escrita, a transação pode ser perdida se ocorrer uma falha no registo principal e secundário antes de os registos serem escritos. remote_write tem uma durabilidade inferior à opção on.
remote_apply: as réplicas em espera síncronas confirmam a receção da transação e a aplicação bem-sucedida à base de dados antes de confirmarem a confirmação da transação ao cliente. A utilização da configuração remote_apply garante que a transação é mantida na réplica e que os resultados da consulta do cliente incluem imediatamente os efeitos da transação. remote_apply oferece maior durabilidade e consistência em comparação com on e remote_write.

A opção de configuração synchronous_commit funciona com a opção de configuração synchronous_standby_names que especifica a lista de servidores em espera que participam no processo de replicação síncrona. Se não forem especificados nomes de espera síncronos, as confirmações de transações não aguardam a replicação.

Arquiteturas de HA do PostgreSQL

Ao nível mais básico, a HA da camada de dados consiste no seguinte:

Um mecanismo para identificar se ocorre uma falha no nó principal.
Um processo para realizar uma comutação por falha em que o nó da réplica é promovido a nó principal.
Um processo para alterar o encaminhamento de consultas de modo que os pedidos da aplicação cheguem ao novo nó principal.
Opcionalmente, um método para reverter para a arquitetura original através de nós primários e de réplica pré-failover nas respetivas capacidades originais.

As secções seguintes oferecem uma vista geral das seguintes arquiteturas de HA:

O modelo Patroni
Extensão e serviço pg_auto_failover
MIGs com estado e disco persistente regional

Estas soluções de HA minimizam o tempo de inatividade se houver uma interrupção da infraestrutura ou zonal. Quando escolher entre estas opções, equilibre a latência de confirmação e a durabilidade de acordo com as necessidades da sua empresa.

Um aspeto crítico de uma arquitetura de HA é o tempo e o esforço manual necessários para preparar um novo ambiente de espera para uma comutação por falha ou uma alternativa subsequente. Caso contrário, o sistema só pode suportar uma falha e o serviço não tem proteção contra uma violação do SLA. Recomendamos que selecione uma arquitetura de HA que possa realizar comutações por falha manuais ou comutações com a infraestrutura de produção.

HA using the Patroni template

O Patroni é um modelo de software de código aberto (licenciado pela MIT) maduro e com manutenção ativa que lhe oferece as ferramentas para configurar, implementar e operar uma arquitetura de alta disponibilidade do PostgreSQL. O Patroni fornece um estado de cluster partilhado e uma configuração de arquitetura que é mantida numa loja de configuração distribuída (DCS). As opções para implementar um DCS incluem: etcd, Consul, Apache ZooKeeper ou Kubernetes. O diagrama seguinte mostra os principais componentes de um cluster do Patroni.

Um cluster do Patroni tem interação entre os nós do PostgreSQL, o DCS e os agentes do Patroni.

Figura 1. Diagrama dos principais componentes de um cluster do Patroni.

Na figura 1, os balanceadores de carga estão à frente dos nós do PostgreSQL, e os agentes DCS e Patroni operam nos nós do PostgreSQL.

O Patroni executa um processo de agente em cada nó do PostgreSQL. O processo do agente gere o processo do PostgreSQL e a configuração do nó de dados. O agente Patroni coordena-se com outros nós através do DCS. O processo do agente Patroni também expõe uma API REST que pode consultar para determinar o estado de funcionamento do serviço PostgreSQL e a configuração de cada nó.

Para afirmar a respetiva função de membro do cluster, o nó principal atualiza regularmente a chave principal no DCS. A chave principal inclui um tempo de vida (TTL). Se o TTL expirar sem uma atualização, a chave principal é removida do DCS e a eleição de líder começa a selecionar um novo principal do conjunto de candidatos.

O diagrama seguinte mostra um cluster em bom estado de funcionamento no qual o nó A atualiza com êxito o bloqueio do líder.

Um líder de cluster saudável atualiza o bloqueio de líder enquanto os candidatos a líder observam.

Figura 2. Diagrama de um cluster saudável.

A Figura 2 mostra um cluster saudável: o nó B e o nó C observam enquanto o nó A atualiza com êxito a chave principal.

Deteção de falhas

O agente Patroni comunica continuamente o respetivo estado atualizando a respetiva chave no DCS. Ao mesmo tempo, o agente valida o estado de funcionamento do PostgreSQL. Se o agente detetar um problema, isola o nó desligando-se ou rebaixa o nó para uma réplica. Conforme mostrado no diagrama seguinte, se o nó danificado for o principal, a respetiva chave principal no DCS expira e ocorre uma nova eleição de líder.

Um cluster danificado elege um novo líder após a expiração da chave do líder existente.

Figura 3. Diagrama de um cluster danificado.

A Figura 3 mostra um cluster danificado: um nó principal inativo não atualizou recentemente a respetiva chave principal no DCS e as réplicas não principais são notificadas de que a chave principal expirou.

Em anfitriões Linux, o Patroni também executa um monitor de temporizador ao nível do SO em nós principais. Este watchdog escuta mensagens de keep-alive do processo do agente Patroni. Se o processo deixar de responder e o sinal de manutenção não for enviado, o watchdog reinicia o anfitrião. O watchdog ajuda a evitar uma condição de split brain em que o nó do PostgreSQL continua a funcionar como o principal, mas a chave principal no DCS expirou devido a uma falha do agente, e foi eleito um principal (líder) diferente.

Processo de comutação por falha

Se o bloqueio do líder expirar no DCS, os nós de réplica candidatos iniciam uma eleição de líder. Quando uma réplica deteta um bloqueio de líder em falta, verifica a respetiva posição de replicação em comparação com as outras réplicas. Cada réplica usa a API REST para obter as posições do registo WAL dos outros nós de réplica, conforme mostrado no diagrama seguinte.

Durante o processo de comutação por falha do Patroni, as réplicas verificam a respetiva posição no registo WAL.

Figura 4. Diagrama do processo de comutação por falha do Patroni.

A Figura 4 mostra as consultas de posição do registo WAL e os respetivos resultados dos nós de réplica ativos. O nó A não está disponível e os nós B e C em bom estado devolvem a mesma posição WAL uns aos outros.

O nó mais atualizado (ou os nós, se estiverem na mesma posição) tenta adquirir simultaneamente o bloqueio de líder no DCS. No entanto, apenas um nó pode criar a chave principal no DCS. O primeiro nó a criar com êxito a chave principal é o vencedor da corrida de líderes, conforme mostrado no diagrama seguinte. Em alternativa, pode designar candidatos de alternativa preferenciais definindo a etiqueta failover_priority nos ficheiros de configuração.

Um nó cria uma chave principal no DCS e torna-se o novo nó principal.

Figura 5. Diagrama da corrida de líderes.

A Figura 5 mostra uma corrida de líder: dois candidatos a líder tentam obter o bloqueio de líder, mas apenas um dos dois nós, o nó C, define com êxito a chave de líder e ganha a corrida.

Após ganhar a eleição de líder, a réplica promove-se a si própria para ser a nova primária. A partir do momento em que a réplica se promove a si própria, o novo nó principal atualiza a chave principal no DCS para manter o bloqueio principal, e os outros nós funcionam como réplicas.

O Patroni também fornece a patronictlferramenta de controlo que lhe permite executar comutações para testar o processo de comutação por falha nodal. Esta ferramenta ajuda os operadores a testarem as respetivas configurações de HA em produção.

Encaminhamento de consultas

O processo do agente Patroni executado em cada nó expõe pontos finais da API REST que revelam a função do nó atual: principal ou réplica.

Ponto final REST	Código de retorno HTTP se for principal	Código de retorno HTTP se for uma réplica
`/primary`	`200`	`503`
`/replica`	`503`	`200`

Uma vez que as verificações de saúde relevantes alteram as respetivas respostas se um nó específico alterar a respetiva função, uma verificação de saúde do equilibrador de carga pode usar estes pontos finais para informar o encaminhamento de tráfego do nó principal e de réplica. O projeto Patroni fornece configurações de modelos para um balanceador de carga, como o HAProxy. O balanceador de carga de encaminhamento interno pode usar estas mesmas verificações de funcionamento para oferecer capacidades semelhantes.

Processo alternativo

Se houver uma falha no nó, o cluster fica num estado degradado. O processo de alternativa do Patroni ajuda a restaurar um cluster de HA para um estado saudável após uma comutação por falha. O processo de alternativa gere o regresso do cluster ao seu estado original inicializando automaticamente o nó afetado como uma réplica do cluster.

Por exemplo, um nó pode ser reiniciado devido a uma falha no sistema operativo ou na infraestrutura subjacente. Se o nó for o principal e demorar mais tempo do que o TTL da chave principal a reiniciar, é acionada uma eleição de líder, e é selecionado e promovido um novo nó principal. Quando o processo primário do Patroni obsoleto é iniciado, este deteta que não tem o bloqueio do líder, rebaixa-se automaticamente para uma réplica e junta-se ao cluster nessa capacidade.

Se ocorrer uma falha de nó irrecuperável, como uma falha zonal improvável, tem de iniciar um novo nó. Um operador de base de dados pode iniciar manualmente um novo nó ou pode usar um grupo de instâncias gerido (MIG) regional com estado com uma contagem mínima de nós para automatizar o processo. Depois de o novo nó ser criado, o Patroni deteta que o novo nó faz parte de um cluster existente e inicializa automaticamente o nó como uma réplica.

HA com a extensão e o serviço pg_auto_failover

pg_auto_failover é uma extensão do PostgreSQL de código aberto (licença do PostgreSQL) em desenvolvimento ativo. O pg_auto_failover configura uma arquitetura de HA ao expandir as capacidades existentes do PostgreSQL. O pg_auto_failover não tem dependências além do PostgreSQL.

Para usar a extensão pg_auto_failover com uma arquitetura de HA, precisa de, pelo menos, três nós, cada um a executar o PostgreSQL com a extensão ativada. Qualquer um dos nós pode falhar sem afetar o tempo de atividade do grupo de bases de dados. Uma coleção de nós geridos pelo pg_auto_failover é denominada formação. O diagrama seguinte mostra uma arquitetura pg_auto_failover.

Uma arquitetura pg_auto_failover contém uma formação de nós.

Figura 6. Diagrama de uma arquitetura pg_auto_failover.

A Figura 6 mostra uma arquitetura pg_auto_failover que consiste em dois componentes principais: o serviço de monitorização e o agente Keeper. O Keeper e o Monitor estão contidos na extensão pg_auto_failover.

Serviço de monitorização

O serviço de monitorização pg_auto_failover é implementado como uma extensão do PostgreSQL; quando o serviço cria um nó de monitorização, inicia uma instância do PostgreSQL com a extensão pg_auto_failover ativada. O Monitor mantém o estado global para a formação, obtém o estado de verificação de integridade dos nós de dados PostgreSQL membros e orquestra o grupo através das regras estabelecidas por uma máquina de estados finitos (MEF). De acordo com as regras da FSM para transições de estado, o Monitor comunica instruções aos nós do grupo para ações como promover, rebaixar e alterações de configuração.

Agente do Keeper

Em cada nó de dados do pg_auto_failover, a extensão inicia um processo de agente do Keeper. Este processo do Keeper observa e gere o serviço PostgreSQL. O Keeper envia atualizações de estado para o nó Monitor e recebe e executa ações que o Monitor envia em resposta.

Por predefinição, o pg_auto_failover configura todos os nós de dados secundários do grupo como réplicas síncronas. O número de réplicas síncronas necessárias para uma confirmação baseia-se na configuração number_sync_standby que define no monitor.