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 é comandada para encerrar seu modo de réplica e fazer a transição para operações completas de leitura-gravação.
Importante
Promover a operação não é automático. No caso de uma falha do servidor primário, o sistema não alternará para a réplica de leitura independentemente. Uma ação do usuário é sempre necessária para a operação de promoção.
A promoção de réplicas pode ser feita de duas maneiras 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 uma promoção bem-sucedida, é necessário ter um ponto de extremidade virtual configurado para o ponto de extremidade primário atual como o ponto de extremidade do gravador e a réplica destinada à promoção como o ponto de extremidade do leitor. A promoção só será bem-sucedida se a réplica de destino estiver incluída na configuração do ponto de extremidade do leitor.
O diagrama ilustra a configuração dos servidores antes da promoção e o estado resultante após a operação de promoção ser concluída com êxito.
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 servidor promovido funcionam como dois servidores de leitura-gravação independentes. Deve-se notar que, embora os pontos de extremidade virtuais possam ser configurados, eles não são uma necessidade para essa operação. O servidor recém-promovido não faz mais parte de nenhum ponto de extremidade virtual existente, mesmo que o ponto de extremidade do leitor estivesse apontando anteriormente para ele. Assim, é essencial atualizar a cadeia de conexão do seu aplicativo para direcionar para a réplica recém-promovida se o aplicativo deve se conectar 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 é compatível com versões anteriores da funcionalidade de promoção.
Importante
Simetria do servidor: para uma promoção bem-sucedida usando a operação de promoção para servidor primário, os servidores primário e de réplica devem ter níveis 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 é 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.
Para ambos os métodos de promoção, há mais opções a considerar:
Planejado: essa opção garante que os dados sejam sincronizados antes da promoção. Ele aplica todos os logs pendentes para garantir a consistência dos dados antes de aceitar conexões de cliente.
Forçado: esta opção foi projetada 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 torna-se operacional uma vez 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 atraso no momento em que você desvincular a réplica do primário indicará a quantidade de dados perdidos.
Importante
A opção Promoção forçada foi projetada especificamente para lidar com 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 ele prioriza a disponibilidade imediata do servidor para lidar com cenários de desastre. No entanto, o uso da opção Forçado fora dos cenários de inatividade de região não é permitido se os requisitos para réplicas de leitura especificados na documentação, especialmente o requisito de simetria do servidor, não forem atendidos, pois isso pode levar a problemas como replicação interrompida.
Saiba como promover a réplica para o servidor principal e promover para o servidor independente e remover da replicação.
Gestão de configuração
As réplicas de leitura são tratadas como servidores separados em termos de configurações do plano 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 desastres, os usuários devem garantir que a configuração seja a desejada.
A operação de promoção não transporta configurações e parâmetros específicos. Aqui estão alguns dos notáveis:
- PgBouncer: As configurações e o status do pool de conexões PgBouncer integrado não são replicados durante o processo de promoção. Se o PgBouncer foi ativado na réplica principal, mas não na réplica, ele permanecerá desativado na réplica após a promoção. Se você quiser PgBouncer no servidor recém-promovido, você deve ativá-lo antes ou depois da 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 no momento da criação do servidor padrão (não uma réplica).
- Parâmetros do servidor: Se seus valores diferirem na réplica primária e lida, eles não serão alterados durante a promoção. É essencial observar que os parâmetros que influenciam o tamanho da memória compartilhada devem ter os mesmos valores na primária e nas réplicas. Este 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 tiver sido configurada com autenticação PostgreSQL, após a promoção, a réplica não mudará automaticamente para a autenticação do Microsoft Entra. Ele mantém a autenticação 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.
- Alta disponibilidade (HA): Se você precisar de HA após a promoção, ela deverá ser configurada no servidor primário recém-promovido, após a inversã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ários e de réplica) estejam em um estado "Disponível". Se o status de um servidor for algo diferente de "Disponível" (como "Atualizando" ou "Reiniciando"), a promoção normalmente não pode prosseguir sem problemas. No entanto, é feita uma exceção 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 as verificações normais de 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 será excluir o primário anterior e recriar o servidor de réplica.
Visibilidade de várias réplicas durante a promoção em regiões não emparelhadas
Ao lidar com várias réplicas e se a região primária não tiver uma região emparelhada, uma consideração especial deve ser considerada. No caso de uma interrupção regional que afete a réplica primária, quaisquer outras réplicas não serão automaticamente reconhecidas pela réplica recém-promovida. Embora os aplicativos ainda possam ser direcionados para a réplica promovida para operação contínua, as réplicas não reconhecidas permanecem desconectadas durante a interrupção. Essas réplicas extras só serão reassociadas e retomadas suas funções quando a região primária original for restaurada.
Restauração point-in-time durante a 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 PITR sejam bem-sucedidas. Estamos cientes de um problema em que a operação PITR pode encontrar 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 PITR bem-sucedidas até o momento mais recente, 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 mais frequentes
Posso promover uma réplica se meu servidor primário tiver alta disponibilidade (HA) habilitada?
Sim, quer o servidor primário esteja habilitado para HA ou não, você pode promover sua réplica de leitura. A capacidade de promover uma réplica de leitura para um servidor primário é independente da configuração 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, em seguida, voltar para o primário original, o servidor ainda estará em HA?
Não, desativamos o HA durante a promoção inicial, pois não suportamos réplicas de leitura habilitadas para HA. Promover uma réplica de leitura para uma réplica primária significa que a primária original está mudando sua função para uma réplica. Se você estiver alternando de volta, precisará habilitar a HA no servidor primário original.