Promover réplicas de leitura no Banco de Dados do Azure para PostgreSQL ─ Servidor Flexível
APLICA-SE A: 
Banco de dados do Azure para PostgreSQL — Servidor Flexível
"Promover" refere-se ao processo em que uma réplica recebe o comando para encerrar o modo de réplica e fazer a transição para operações de leitura e gravação completas.
Importante
A operação de promoção não é automática. Caso ocorra uma falha de servidor primário, o sistema não alternará para a réplica de leitura de forma independente. Sempre será necessária uma ação do usuário para a operação de promoção.
A promoção de réplicas pode ser feita de duas formas distintas:
Promover para servidor primário
Essa ação eleva uma réplica à função do servidor primário. No processo, o servidor primário atual é rebaixado para uma função de réplica, trocando suas funções. Para obter uma promoção bem-sucedida, é necessário ter um ponto de extremidade virtual configurado para o primário atual como ponto de extremidade de gravador e a réplica destinada à promoção como ponto de extremidade de leitor. A promoção só será bem-sucedida se a réplica de destino for incluída na configuração do ponto de extremidade do leitor.
O diagrama ilustra a configuração dos servidores antes da promoção e do estado resultante após a conclusão bem-sucedida da operação de promoção.
Promover para servidor independente e remover da replicação
Quando você escolhe essa opção, a réplica é promovida para se tornar um servidor independente e é removida do processo de replicação. Como resultado, o servidor primário e o promovido funcionaram como dois servidores independentes de leitura e gravação. Observe que, embora os pontos de extremidade virtuais possam ser configurados, eles não são uma necessidade para essa operação. O servidor que acabou de ser promovido não faz mais parte de um ponto de extremidade virtual existente, mesmo que o ponto de extremidade de leitor tenha apontado para ele anteriormente. Portanto, é essencial atualizar a cadeia de conexão do aplicativo para direcionar para a réplica recém-promovida, caso o aplicativo se conecte a ela.
O diagrama mostra como os servidores são configurados antes de serem promovidos e sua configuração depois de se tornarem servidores independentes com êxito.
Importante
A ação Promover para servidor independente e remover da replicação tem compatibilidade com versões anteriores da funcionalidade de promoção anterior.
Importante
Simetria de servidor: para obter uma promoção bem-sucedida usando a operação promover para servidor primário, os servidores primário e de réplica devem ter camadas e tamanhos de armazenamento idênticos. Por exemplo, se o primário tiver 2vCores e a réplica tiver 4vCores, a única opção viável será usar a ação "promover para servidor independente e remover da replicação". Além disso, eles precisam compartilhar os mesmos valores para parâmetros de servidor que alocam memória compartilhada.
Os dois métodos de promoção têm mais opções a serem consideradas:
Planejado: essa opção garante que os dados estão sincronizados antes da promoção. Isso aplica todos os logs pendentes para garantir a consistência dos dados antes de aceitar conexões de cliente.
Forced (forçado): essa opção foi criada para recuperação rápida em cenários como interrupções regionais. Em vez de esperar para sincronizar todos os dados do primário, o servidor fica operacional assim que processa os arquivos WAL necessários para alcançar o estado consistente mais próximo. Se você promover a réplica usando essa opção, o retardo no momento em que você desvincular a réplica do primário indica a quantidade de dados perdida.
Importante
A opção de promoção Forçada foi especificamente projetada para resolver interrupções regionais e, nesses casos, ignora todas as verificações - incluindo o requisito de simetria do servidor - e prossegue com a promoção. Isso ocorre porque prioriza a disponibilidade imediata do servidor para lidar com cenários de desastre. No entanto, o uso da opção Forçada fora dos cenários de região para baixo não será permitido se os requisitos de réplicas de leitura especificadas na documentação, especialmente o requisito de simetria do servidor, não forem atendidos, pois isso poderá levar a problemas como replicação interrompida.
Saiba como promover réplica para primário e promover para servidor independente e remover da replicação.
Gerenciamento de configuração
As réplicas de leitura são tratadas como servidores separados em relação às configurações do painel de controle. Essa abordagem fornece flexibilidade para cenários de escala de leitura. No entanto, ao usar réplicas para fins de recuperação de desastre, os usuários devem garantir que a configuração seja a desejada.
A operação de promoção não carrega configurações e parâmetros específicos. Estas são algumas das mais notáveis:
- PgBouncer: as configurações e o status do pooler de conexões de PgBouncer internos não são replicados durante o processo de promoção. Se o PgBouncer for habilitado no primário, mas não na réplica, ele permanecerá desabilitado na réplica após a promoção. Caso deseje o PgBouncer no servidor recém-promovido, habilite-o antes ou após a ação de promoção.
- Armazenamento de backup com redundância geográfica: as configurações de backup geográfico não são transferidas. Como as réplicas não podem ter o backup geográfico habilitado, o primário promovido (anteriormente a réplica) não o tem após a promoção. O recurso só pode ser ativado na hora de criação do servidor padrão (não em uma réplica).
- Parâmetros do servidor: se os seus valores forem diferentes na réplica primária e de leitura, eles não serão alterados durante a promoção. É fundamental observar que os parâmetros que influenciam o tamanho da memória compartilhada devem ter os mesmos valores nas réplicas e nas primárias. Esse requisito é detalhado na seção Parâmetros do servidor.
- Autenticação do Microsoft Entra: se o primário tiver a autenticação do Microsoft Entra configurada, mas a réplica foi configurada com a autenticação do PostgreSQL, a réplica não mudará automaticamente para a autenticação do Microsoft Entra depois da promoção. Ela manterá a autenticação do PostgreSQL. Os usuários precisam configurar manualmente a autenticação do Microsoft Entra na réplica promovida antes ou depois do processo de promoção.
- HA (alta disponibilidade): caso você exija a HA após a promoção, ela deve ser configurada no servidor primário que acabou de ser promovido, logo após a reversão de função.
Considerações
Estados do servidor durante a promoção
Nos cenários de promoção planejada e forçada, é necessário que os servidores (primário e réplica) estejam em um estado "Disponível". Se o status de um servidor for diferente de "Disponível" (como "Atualizando" ou "Reiniciando"), a promoção normalmente não poderá continuar sem problemas. No entanto, uma exceção é feita no caso de interrupções regionais.
Durante essas interrupções regionais, o método de promoção forçada pode ser implementado independentemente do status atual do servidor primário. Essa abordagem permite uma ação rápida em resposta a possíveis desastres regionais, ignorando verificações normais sobre a disponibilidade do servidor.
Observe que, se o servidor primário anterior falhar além da recuperação durante a promoção de sua réplica, a única opção é excluir o antigo primário e recriar o servidor de réplica.
Visibilidade de diversas réplicas durante a promoção em regiões não emparelhadas
Deve-se fazer uma consideração especial ao lidar com diversas réplicas e se a região primária não tiver uma região emparelhada. Caso uma interrupção regional afete o primário, todas as outra réplicas não serão reconhecidas automaticamente pela réplica recém-promovida. Embora os aplicativos ainda possam ser direcionados para a réplica promovida para a operação contínua, as réplicas não reconhecidas permanecem desconectadas durante a interrupção. Essas outras réplicas serão reassociadas e retomarão suas funções depois que a região primária original for restaurada.
Restauração pontual durante uma promoção
Nos cenários de promoção planejada e forçada, é necessário que os backups automatizados mais recentes estejam disponíveis para garantir que as operações de recuperação pontual obtenham êxito. Nós sabemos de um problema em que a operação de restauração pontual pode obter o seguinte erro após operações de failover e failback. Esse problema está programado para ser resolvido em uma próxima versão. Para garantir operações de recuperação pontual com êxito até o último instante, você pode aguardar a conclusão do backup automatizado após uma operação de promoção.
Error : Point-in-time-restore of server to the period when the siteswap operation for this server was in-progress or when the server was replica is not allowed.
Perguntas frequentes
Posso promover uma réplica caso meu servidor primário tenha a HA (alta disponibilidade) habilitada?
Sim, caso o servidor primário tenha habilitado para HA ou não, você poderá promover sua réplica de leitura. A opção de promover uma réplica de leitura para um servidor primário é independente da configuração de HA do primário.
Se eu tiver um primário habilitado para HA e uma réplica de leitura, e eu promover a réplica, depois voltar para o primário original, o servidor ainda estará em HA?
Não, desabilitamos a HA durante a promoção inicial, pois não damos suporte a réplicas de leitura habilitadas para HA. Promover uma réplica de leitura para um primário significa que o primário original está alterando sua função para uma réplica. Se você estiver alternando de volta, precisará habilitar a HA no servidor primário original.