Share via

Réplicas de leitura na Base de Dados do Azure para PostgreSQL – Servidor Flexível

  • Artigo

APLICA-SE A: Banco de Dados do Azure para PostgreSQL - Servidor Flexível

O recurso de réplica de leitura permite replicar dados de uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL para uma réplica somente leitura. As réplicas são atualizadas de forma assíncrona com a tecnologia de replicação física nativa do mecanismo PostgreSQL. A replicação de transmissão em fluxo com blocos de replicação é o modo de operação predefinido. Quando necessário, o envio de logs baseado em arquivo é usado para recuperar o atraso. Você pode replicar do servidor primário para até cinco réplicas.

As réplicas são novos servidores que você gerencia de forma semelhante às instâncias de servidor flexíveis regulares do Banco de Dados do Azure para PostgreSQL. Para cada réplica de leitura, você é cobrado pela computação provisionada em vCores e armazenamento em GB/mês.

Saiba como criar e gerenciar réplicas.

Quando utilizar uma réplica de leitura

A funcionalidade de réplica de leitura ajuda a melhorar o desempenho e o dimensionamento de cargas de trabalho de leitura intensiva. As cargas de trabalho de leitura podem ser isoladas das réplicas e as cargas de trabalho de escrita podem ser encaminhadas para o servidor principal. As réplicas de leitura também podem ser implantadas em uma região diferente e podem ser promovidas para um servidor de leitura-gravação se a recuperação de desastres for necessária.

Um cenário típico é fazer com que cargas de trabalho analíticas e de BI usem a réplica de leitura como fonte de dados para relatórios.

Como as réplicas são só de leitura, não reduzem diretamente as cargas de capacidade de escrita no servidor principal.

Considerações

As réplicas de leitura são projetadas principalmente para cenários em que o descarregamento de consultas é benéfico e um pequeno atraso é gerenciável. Eles são otimizados para fornecer atualizações quase em tempo real do principal para a maioria das cargas de trabalho, tornando-os uma excelente solução para cenários de leitura pesada. No entanto, é importante observar que eles não se destinam a cenários de replicação síncrona que exijam precisão de dados atualizada. Embora os dados na réplica eventualmente se tornem consistentes com o principal, pode haver um atraso, que normalmente varia de alguns segundos a minutos, e em alguns cenários de carga de trabalho pesada ou alta latência, esse atraso pode se estender por horas. Normalmente, as réplicas de leitura na mesma região que a primária têm menos atraso do que as réplicas geográficas, já que estas últimas geralmente lidam com latência induzida por distância geográfica. Para obter mais informações sobre as implicações de desempenho da replicação geográfica, consulte o artigo Replicação geográfica. Os dados na réplica podem tornar-se consistentes com os dados no cluster principal. Utilize esta funcionalidade para cargas de trabalho que podem acomodar este atraso.

Nota

Para a maioria das cargas de trabalho, as réplicas de leitura oferecem atualizações quase em tempo real a partir do servidor primário. No entanto, com cargas de trabalho primárias persistentes e pesadas de gravação, o atraso de replicação pode continuar a crescer e só conseguir alcançar o principal. Isso também pode aumentar o uso de armazenamento no primário, já que os arquivos WAL só são excluídos uma vez recebidos na réplica. Se essa situação persistir, excluindo e recriando a réplica de leitura depois que as cargas de trabalho de gravação intensiva forem concluídas, você poderá trazer a réplica de volta a um bom estado para atraso. As réplicas de leitura assíncronas não são adequadas para cargas de trabalho tão pesadas em termos de escrita. Ao avaliar réplicas de leitura para seu aplicativo, monitore o atraso na réplica para um ciclo completo de carga de trabalho do aplicativo através de seus horários de pico e fora de pico para avaliar o possível atraso e o RTO/RPO esperado em vários pontos do ciclo de carga de trabalho.

Criar uma réplica

Um servidor primário para o Banco de Dados do Azure para servidor flexível PostgreSQL pode ser implantado em qualquer região que ofereça suporte ao serviço. Você pode criar réplicas do servidor primário dentro da mesma região ou em diferentes regiões globais do Azure onde o Banco de Dados do Azure para servidor flexível PostgreSQL está disponível. A capacidade de criar réplicas agora se estende a algumas regiões especiais do Azure. Consulte o artigo Replicação geográfica para obter uma lista de regiões especiais onde você pode criar réplicas.

Quando você inicia o fluxo de trabalho de criação de réplica, uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL em branco é criada. O novo servidor é preenchido com os dados no servidor primário. Para a criação de réplicas na mesma região, uma abordagem de instantâneo é usada. Portanto, o tempo de criação é independente do tamanho dos dados. As réplicas geográficas são criadas usando o backup base da instância primária, que é então transmitida pela rede; Portanto, o tempo de criação pode variar de minutos a várias horas, dependendo do tamanho primário.

A réplica só é considerada criada com êxito quando duas condições são atendidas: todo o backup da instância primária deve ser copiado para a réplica e os logs de transações devem ser sincronizados com um atraso não superior a 1 GB.

Para obter uma operação de criação bem-sucedida, evite fazer réplicas durante períodos de alta carga transacional. Por exemplo, você deve evitar criar réplicas ao migrar de outras fontes para o Banco de Dados do Azure para o servidor flexível PostgreSQL ou durante operações de carga pesada em massa. Se você estiver migrando dados ou carregando grandes quantidades de dados agora, é melhor concluir essa tarefa primeiro. Depois de concluí-lo, você pode começar a configurar as réplicas. Quando a migração ou a operação de carregamento em massa for concluída, verifique se o tamanho do log de transações retornou ao seu tamanho normal. Normalmente, o tamanho do log de transações deve estar próximo ao valor definido no parâmetro max_wal_size server para sua instância. Você pode acompanhar o espaço ocupado pelo armazenamento do log de transações usando a métrica Transaction Log Storage Used , que fornece informações sobre a quantidade de armazenamento usada pelo log de transações. Ao monitorar essa métrica, você pode garantir que o tamanho do log de transações esteja dentro do intervalo esperado e que o processo de criação da réplica possa ser iniciado.

Importante

Atualmente, há suporte para réplicas de leitura para as camadas de computação de servidor de uso geral e otimização de memória. A camada de computação do servidor Burstable não é suportada.

Importante

Ao executar operações de criação, exclusão e promoção de réplicas, o servidor primário entrará em um estado de atualização. Durante esse período, as operações de gerenciamento de servidor, como modificar parâmetros do servidor, alterar opções de alta disponibilidade ou adicionar ou remover firewalls, ficarão indisponíveis. É importante observar que o estado de atualização afeta apenas as operações de gerenciamento do servidor e não afeta as operações do plano de dados. Isso significa que seu servidor de banco de dados permanecerá totalmente funcional e capaz de aceitar conexões, bem como servir tráfego de leitura e gravação.

Saiba como criar uma réplica de leitura no portal do Azure.

Gestão de configuração

Ao configurar réplicas de leitura para o servidor flexível do Banco de Dados do Azure para PostgreSQL, é essencial entender as configurações de servidor que podem ser ajustadas, as herdadas do primário e quaisquer limitações relacionadas.

Configurações herdadas

Quando uma réplica de leitura é criada, ela herda configurações específicas do servidor primário. Essas configurações podem ser alteradas durante a criação da réplica ou depois que ela for configurada. No entanto, configurações específicas, como backup geográfico, não serão replicadas para a réplica de leitura.

Configurações durante a criação da réplica

  • Nível, tamanho do armazenamento: para a operação "promover para o servidor primário", ela deve ser a mesma que a principal. Para a operação "promover para servidor independente e remover da replicação", ela pode ser igual ou superior à principal.
  • Camada de desempenho (IOPS): ajustável.
  • Criptografia de dados: ajustável, inclui a mudança de chaves gerenciadas por serviço para chaves gerenciadas pelo cliente.

Pós-criação de configurações

  • Regras de firewall: podem ser adicionadas, excluídas ou modificadas.
  • Nível, tamanho do armazenamento: para a operação "promover para o servidor primário", ela deve ser a mesma que a principal. Para a operação "promover para servidor independente e remover da replicação", ela pode ser igual ou superior à principal.
  • Camada de desempenho (IOPS): ajustável.
  • Método de autenticação: ajustável, as opções incluem mudar da autenticação PostgreSQL para o Microsoft Entra.
  • Parâmetros do servidor: A maioria é ajustável. No entanto, aqueles que afetam o tamanho da memória compartilhada devem se alinhar com o principal, especialmente para possíveis cenários de "promover para o servidor primário". Para a operação "promover para servidor independente e remover da replicação", esses parâmetros devem ser os mesmos ou exceder os do primário.
  • Cronograma de manutenção: Ajustável.

Recursos sem suporte em réplicas de leitura

Certas funcionalidades são restritas aos servidores primários e não podem ser configuradas em réplicas de leitura. Estes são, entre outros:

  • Backups, incluindo backups geográficos.
  • Elevada disponibilidade (HA)

Se sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL de origem estiver criptografada com chaves gerenciadas pelo cliente, consulte a documentação para obter outras considerações.

Ligar a uma réplica

Quando você cria uma réplica, ela herda as regras de firewall ou o ponto de extremidade do serviço de rede virtual do servidor primário. Essas regras podem ser alteradas durante a criação da réplica e em qualquer momento posterior.

A réplica herda a conta de administrador do servidor primário. Todas as contas de usuário no servidor primário são replicadas para as réplicas de leitura. Você só pode se conectar a uma réplica de leitura usando as contas de usuário disponíveis no servidor primário.

Há dois métodos para se conectar à réplica:

  • Direto para a instância de réplica: você pode se conectar à réplica usando seu nome de host e uma conta de usuário válida, como faria em uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL. Para um servidor chamado myreplica com o nome de usuário admin myadmin, você pode se conectar à réplica usando psql:
psql -h myreplica.postgres.database.azure.com -U myadmin postgres

Quando lhe for pedido, introduza a palavra-passe para a conta de utilizador.

Além disso, para facilitar o processo de conexão, o portal do Azure fornece cadeias de conexão prontas para uso. Estes podem ser encontrados na página Conectar . Eles abrangem variáveis libpq e cadeias de conexão adaptadas para consoles bash.

  • Via Pontos de extremidade virtuais: Há um método de conexão alternativo usando pontos de extremidade virtuais, conforme detalhado no artigo Pontos de extremidade virtuais. Usando pontos de extremidade virtuais, você pode configurar o ponto de extremidade somente leitura para apontar consistentemente para a réplica, independentemente de qual servidor atualmente detém a função de réplica.

Monitorizar a replicação

O recurso de réplica de leitura no Banco de Dados do Azure para servidor flexível PostgreSQL depende do mecanismo de slots de replicação. A principal vantagem dos slots de replicação é que eles ajustam automaticamente o número de logs de transações (segmentos WAL) exigidos por todos os servidores de réplica. Isso ajuda a evitar que as réplicas fiquem fora de sincronia, pois evita excluir segmentos WAL no primário antes de serem enviados para as réplicas. A desvantagem da abordagem é o risco de ficar sem espaço no primário caso o slot de replicação permaneça inativo por um longo tempo. Em tais situações, o primário acumula arquivos WAL causando crescimento incremental do uso de armazenamento. Quando o uso do armazenamento atinge 95% ou se a capacidade disponível é inferior a 5 GiB, o servidor é automaticamente alternado para o modo somente leitura para evitar erros associados a situações de disco cheio.
Portanto, monitorar o atraso de replicação e o status dos slots de replicação é crucial para réplicas de leitura.

Recomendamos definir regras de alerta para armazenamento usado ou porcentagem de armazenamento e para atrasos de replicação, quando excederem determinados limites, para que você possa agir proativamente, aumentar o tamanho do armazenamento e excluir réplicas de leitura com atraso. Por exemplo, você pode definir um alerta se a porcentagem de armazenamento exceder 80% de uso e se o atraso da réplica for superior a 5 minutos. A métrica Transaction Log Storage Used mostra se o acúmulo de arquivos WAL é o principal motivo do uso excessivo de armazenamento.

O Banco de Dados do Azure para servidor flexível PostgreSQL fornece duas métricas para monitorar a replicação. As duas métricas são Max Physical Replication Lag e Read Replica Lag. Para saber como exibir essas métricas, consulte a seção Monitorar uma réplica do artigo de instruções da réplica de leitura.

A métrica Max Physical Replication Lag mostra o atraso em bytes entre a réplica primária e a réplica com maior atraso. Essa métrica é aplicável e está disponível somente no servidor primário e estará disponível somente se pelo menos uma das réplicas de leitura estiver conectada à principal. As informações de atraso também estão presentes quando a réplica está em processo de recuperação do principal, durante a criação da réplica ou quando a replicação se torna inativa.

A métrica Read Replica Lag mostra o tempo desde a última transação repetida. Por exemplo, se nenhuma transação estiver ocorrendo no servidor primário e a última transação tiver sido repetida há 5 segundos, o atraso da réplica de leitura mostrará um atraso de 5 segundos. Essa métrica é aplicável e está disponível apenas em réplicas.

Defina um alerta para informá-lo quando o atraso da réplica atingir um valor que não seja aceitável para sua carga de trabalho.

Para obter mais informações, consulte o servidor primário diretamente para obter o atraso de replicação em todas as réplicas.

Nota

Se um servidor primário ou uma réplica de leitura for reiniciado, o tempo necessário para reiniciar e recuperar o atraso será refletido na métrica Atraso da réplica.

Estado de replicação

Para monitorar o progresso e o status da replicação e promover a operação, consulte a coluna Estado da replicação no portal do Azure. Esta coluna está localizada na página de replicação e exibe vários estados que fornecem informações sobre a condição atual das réplicas lidas e seu link para a primária. Para usuários que dependem da API do Azure Resource Manager, ao invocar a GetReplica API, o estado aparece como ReplicationState no pacote de replica propriedades.

Aqui estão os valores possíveis:

Estado de replicação Descrição Promova a encomenda Ler a ordem de criação da réplica
Reconfiguração Aguardando o início do link principal da réplica. Pode permanecer mais tempo se a réplica ou sua região não estiver disponível, por exemplo, devido a um desastre. 1 N/A
Provisionamento A réplica de leitura está sendo provisionada e a replicação entre os dois servidores ainda não foi iniciada. Até que o provisionamento seja concluído, você não poderá se conectar à réplica de leitura. N/A 1
Atualização A configuração do servidor está em preparação após uma ação acionada, como promoção ou criação de réplica de leitura. 2 2
Recuperação Os arquivos WAL estão sendo aplicados na réplica. A duração desta fase durante a promoção depende da opção de sincronização de dados escolhida - planeada ou forçada. 3 3
Ativo Estado íntegro, indicando que a réplica de leitura foi conectada com êxito à primária. Se os servidores forem interrompidos, mas tiverem sido conectados com êxito anteriormente, o status permanecerá como ativo. 4 4
Quebrado Estado não íntegro, indicando que a operação de promoção pode ter falhado ou que a réplica não consegue se conectar ao primário por algum motivo. Solte a réplica e recrie a réplica para resolver isso." N/A N/A

Saiba como monitorar a replicação.

Considerações

Esta seção resume as considerações sobre o recurso de réplica de leitura. Aplicam-se as seguintes considerações.

  • Operações de energia: as operações de energia, incluindo ações de início e parada, podem ser aplicadas aos servidores primário e de réplica. No entanto, para preservar a integridade do sistema, deve ser seguida uma sequência específica. Antes de interromper as réplicas de leitura, verifique se o servidor primário foi interrompido primeiro. Ao iniciar as operações, inicie a ação de inicialização nos servidores de réplica antes de iniciar o servidor primário.
  • Se o servidor tiver réplicas de leitura, as réplicas de leitura deverão ser excluídas primeiro antes de excluir o servidor primário.
  • A atualização da versão principal in-loco no Banco de Dados do Azure para o servidor flexível PostgreSQL requer a remoção de todas as réplicas de leitura atualmente habilitadas no servidor. Depois que as réplicas forem excluídas, o servidor primário poderá ser atualizado para a versão principal desejada. Após a conclusão da atualização, você poderá recriar as réplicas para retomar o processo de replicação.
  • SSD Premium v2: A partir da versão atual, se o servidor primário usar SSD Premium v2 para armazenamento, a criação de réplicas de leitura não será suportada.
  • Redefinição da senha de administrador: no momento, não há suporte para a redefinição da senha de administrador no servidor de réplica. Além disso, a atualização da senha de administrador juntamente com a promoção da operação de réplica na mesma solicitação também não é suportada. Se desejar fazer isso, você deve primeiro promover o servidor de réplica e, em seguida, atualizar a senha no servidor recém-promovido separadamente.

Novas réplicas

Uma réplica de leitura é criada como uma nova instância de servidor flexível do Banco de Dados do Azure para PostgreSQL. Um servidor existente não pode ser transformado em uma réplica. Não é possível criar uma réplica de outra réplica de leitura, ou seja, a replicação em cascata não é suportada.

Movimentação de recursos

Os usuários podem criar réplicas de leitura em um grupo de recursos diferente do principal. No entanto, não há suporte para mover réplicas de leitura para outro grupo de recursos após sua criação. Além disso, não há suporte para mover réplicas para uma assinatura diferente e mover o primário que tem réplicas de leitura para outro grupo de recursos ou assinatura.

Crescimento automático do armazenamento

Ao configurar réplicas de leitura para uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL, é essencial garantir que a configuração de crescimento automático de armazenamento nas réplicas corresponda à do servidor primário. O recurso de crescimento automático de armazenamento permite que o armazenamento do banco de dados aumente automaticamente para evitar a falta de espaço, o que pode levar a interrupções do banco de dados. Veja como gerenciar as configurações de crescimento automático de armazenamento de forma eficaz:

  • Você pode ter o crescimento automático de armazenamento habilitado em qualquer réplica, independentemente da configuração do servidor primário.
  • Se o crescimento automático de armazenamento estiver habilitado no servidor primário, ele também deverá ser habilitado nas réplicas para garantir a consistência nos comportamentos de dimensionamento de armazenamento.
  • Para habilitar o crescimento automático do armazenamento no principal, você deve primeiro habilitá-lo nas réplicas. Essa ordem de operações é crucial para manter a integridade da replicação.
  • Por outro lado, se você deseja desabilitar o crescimento automático do armazenamento, comece desabilitando-o no servidor primário antes das réplicas para evitar complicações de replicação.

Backup e restauração

Ao gerenciar backups e restaurações para sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL, é essencial ter em mente a função atual e anterior do servidor em diferentes cenários de promoção. Aqui estão os pontos-chave a serem lembrados:

Promover para servidor primário

  1. Nenhum backup é feito de réplicas de leitura: os backups nunca são feitos de servidores de réplica de leitura, independentemente de sua função anterior.

  2. Preservação de backups anteriores: se um servidor já foi primário e fez backups durante esse período, esses backups serão preservados. Eles serão mantidos até o período de retenção definido pelo usuário.

  3. Restrições de operação de restauração: mesmo que existam backups anteriores para um servidor que fez a transição para uma réplica de leitura, as operações de restauração são restritas. Você só pode iniciar uma operação de restauração quando o servidor tiver sido promovido de volta à função principal.

Para maior clareza, aqui está uma tabela que ilustra esses pontos:

Função de servidor Backup feito Restauração permitida
Primário Sim Sim
Ler réplica No Não
Réplica de leitura promovida a principal Sim Sim

Promover para servidor independente e remover da replicação

Embora o servidor seja uma réplica de leitura, nenhum backup é feito. No entanto, uma vez promovido a um servidor independente, tanto o servidor promovido quanto o servidor primário têm backups feitos, e restaurações são permitidas em ambos.

Rede

As réplicas de leitura dão suporte a todas as opções de rede suportadas pelo Banco de Dados do Azure para o Servidor Flexível PostgreSQL.

Importante

A comunicação bidirecional entre o servidor primário e as réplicas de leitura é crucial para a configuração flexível do servidor do Banco de Dados do Azure para PostgreSQL. Deve haver uma provisão para enviar e receber tráfego na porta de destino 5432 na sub-rede de rede virtual do Azure.

O requisito acima não só facilita o processo de sincronização, mas também garante o funcionamento adequado do mecanismo de promoção, onde as réplicas podem precisar se comunicar em ordem inversa - da réplica para a primária - especialmente durante as operações de promoção para primárias. Além disso, as conexões com a conta de armazenamento do Azure que armazena arquivos WAL (Write-Ahead Logging) devem ter permissão para manter a durabilidade dos dados e permitir processos de recuperação eficientes.

Para obter mais informações sobre como configurar o acesso privado (integração de rede virtual) para suas réplicas de leitura e entender as implicações para a replicação entre regiões do Azure e redes virtuais dentro de um contexto de rede privada, consulte a página Replicação em regiões do Azure e redes virtuais com rede privada.

Mitigação de problemas de slot de replicação

Em casos raros, o alto atraso causado pelos slots de replicação pode levar ao aumento do uso de armazenamento no servidor primário devido aos arquivos WAL acumulados. Se o uso do armazenamento atingir 95% ou a capacidade disponível cair abaixo de 5 GiB, o servidor alternará automaticamente para o modo somente leitura para evitar erros de disco cheio.

Como a manutenção da integridade e da funcionalidade do servidor primário é uma prioridade, nesses casos de borda, o slot de replicação pode ser descartado para garantir que o servidor primário permaneça operacional para o tráfego de leitura e gravação. Assim, a replicação muda para o modo de envio de logs baseado em arquivos, o que pode resultar em um maior atraso na replicação.

É essencial monitorar de perto o uso do armazenamento e o atraso da replicação e tomar as medidas necessárias para mitigar possíveis problemas antes que eles aumentem.

Parâmetros do servidor

Quando uma réplica de leitura é criada, ela herda os parâmetros do servidor primário. Trata-se de assegurar um ponto de partida coerente e fiável. No entanto, quaisquer alterações nos parâmetros do servidor no servidor primário feitas após a criação da réplica de leitura não são replicadas automaticamente. Esse comportamento oferece a vantagem do ajuste individual da réplica de leitura, como melhorar seu desempenho para operações com uso intensivo de leitura sem modificar os parâmetros do servidor primário. Embora isso forneça flexibilidade e opções de personalização, também requer um gerenciamento cuidadoso e manual para manter a consistência entre o primário e sua réplica quando a uniformidade dos parâmetros do servidor é necessária.

Os administradores podem alterar os parâmetros do servidor no servidor de réplica de leitura e definir valores diferentes dos do servidor primário. A única exceção são os parâmetros que podem afetar a recuperação da réplica, mencionados também na seção "Dimensionamento" abaixo: max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes. Para garantir que a recuperação da réplica de leitura seja contínua e não encontre limitações de memória compartilhada, esses parâmetros específicos devem sempre ser definidos para valores equivalentes ou maiores do que os configurados no servidor primário.

Escala

Você é livre para aumentar e diminuir a escala de computação (vCores), alterando a camada de serviço de Uso Geral para Memória Otimizada (ou vice-versa) e dimensionando o armazenamento, mas as seguintes advertências se aplicam.

Para dimensionamento de computação:

  • O servidor flexível do Banco de Dados do Azure para PostgreSQL requer que vários parâmetros nas réplicas sejam maiores ou iguais à configuração no primário para garantir que a réplica não fique sem memória compartilhada durante a recuperação. Os parâmetros afetados são: max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes.

  • Escalonamento: primeiro aumente a escala da computação de uma réplica e, em seguida, aumente a escala principal.

  • Redução da escala: primeiro reduza a computação do primário e, em seguida, diminua a réplica.

  • A computação na réplica primária deve ser sempre igual ou menor do que a computação na réplica menor.

Para dimensionamento de armazenamento:

  • Escalonamento: primeiro aumente a escala do armazenamento de uma réplica e, em seguida, aumente a escala principal.

  • O tamanho do armazenamento no primário deve ser sempre igual ou menor do que o tamanho do armazenamento na réplica menor.

Conteúdos relacionados