Compartilhar via

Réplicas de leitura no Banco 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 do PostgreSQL. A replicação de streaming usando slots de replicação é o modo de operação padrão. Quando necessário, o envio de logs baseado em arquivo é usado para recuperar o atraso. Você pode replicar a partir do servidor primário para até cinco réplicas.

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

Saiba como criar e gerenciar réplicas.

Quando usar uma réplica de leitura

O recurso de réplica de leitura ajuda a melhorar o desempenho e o dimensionamento de cargas de trabalho com uso intenso de leitura. As cargas de trabalho de leitura podem ser isoladas para as réplicas, enquanto as cargas de trabalho de gravação podem ser direcionadas para o primário. As réplicas de leitura também podem ser implantadas em uma região diferente e podem ser promovidas a servidor de leitura-gravação em caso de recuperação de desastre.

Um cenário comum é as cargas de trabalho analíticas e de BI usarem a réplica de leitura como a fonte de dados para relatório.

Como réplicas são somente leitura, elas não reduzem diretamente os encargos de capacidade de gravação no primário.

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. Elas são otimizadas para fornecer atualizações quase em tempo real do primário para a maioria das cargas de trabalho, tornando-as 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 exigem precisão de dados atualizada. Embora os dados na réplica eventualmente se tornem consistentes com o primário, pode haver um atraso, que normalmente varia de alguns segundos a minutos e, em alguns cenários de carga de trabalho pesada ou de alta latência, isso pode se estender para horas. Normalmente, as réplicas de leitura na mesma região que o primário sofrem menos retardos do que as réplicas geográficas, pois geralmente lidam com a latência induzida pela 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 acabarão se tornando consistentes com os dados no primário. Use este recurso para cargas de trabalho que podem acomodar esse atraso.

Observação

Para a maioria das cargas de trabalho, as réplicas de leitura oferecem atualizações quase em tempo real a partir do primário. No entanto, com cargas de trabalho primárias persistentes, pesadas e com uso intensivo de gravação, o retardo de replicação poderia continuar a crescer e apenas alcançar as primárias. Isso também pode aumentar o uso do armazenamento no primário, pois os arquivos WAL são excluídos apenas depois de recebidos na réplica. Se tal situação persistir, ao excluir e recriar a réplica de leitura após a conclusão das cargas de trabalho com uso intensivo de gravação, é possível trazer a réplica de volta a um bom estado em relação ao atraso. As réplicas de leitura assíncronas não são adequadas para cargas de trabalho de gravação pesadas. Ao avaliar réplicas de leitura para o aplicativo, monitore o retardo na réplica de um ciclo de carga de trabalho completo do aplicativo dentro e fora dos horários de pico para avaliar o possível retardo 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 servidor flexível do Banco de Dados do Azure para PostgreSQL pode ser implantado em qualquer região que dê suporte ao serviço. Você pode criar réplicas do servidor primário na mesma região ou em diferentes regiões globais do Azure em que o servidor flexível do Banco de Dados do Azure para 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 em que 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 do 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 independe do tamanho dos dados. As réplicas geográficas são criadas usando o backup de base da instância primária, que é transmitida pela rede. Portanto, o tempo de criação pode variar de minutos a várias horas, dependendo do tamanho da primária.

A réplica só é considerada criada com sucesso 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ção devem ser sincronizados com um atraso de no máximo 1 GB.

Evite fazer réplicas durante períodos de alta carga transacional para obter uma operação de criação bem-sucedida. Por exemplo, é melhor evitar a criação de réplicas durante as migrações de outras fontes para o servidor flexível do Banco de Dados do Azure para PostgreSQL ou durante operações de carregamento em massa excessivas. Se você estiver migrando dados ou carregando grandes volumes de dados no momento, é melhor concluir essa tarefa primeiro. Após essa conclusão, você pode começar a configurar as réplicas. Depois que a operação de migração ou 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 do valor definido no parâmetro de servidor max_wal_size para sua instância. Você pode acompanhar o volume de armazenamento do log de transações usando a métrica Armazenamento de Log de Transações Usado, que fornece insights 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 nas camadas de computação de servidor para Uso Geral e otimizado para memória. Não há suporte para a camada de computação do servidor Com capacidade de intermitência.

Importante

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

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

Gerenciamento 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 de servidor específicas do servidor primário. Essas configurações podem ser alteradas durante ou após a configuração a criação da réplica. No entanto, configurações específicas, como o backup geográfico, não serão replicadas para a réplica de leitura.

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

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

Configurações após a criação

  • Regras de firewall: podem ser adicionadas, excluídas ou modificadas.
  • Camada, tamanho de armazenamento: para a operação "promover para servidor primário", deve ser a mesma que a do primário. Para a operação "promover para servidor independente e remover da replicação", podem ser a mesma ou maior que a do primário.
  • Nível de desempenho (IOPS): ajustável.
  • Método de autenticação: ajustável, as opções incluem comutar da autenticação do 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 ao do primário, especialmente em possíveis cenários de "promover para 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.
  • Agendamento de manutenção: ajustável.

Recursos sem suporte em réplicas de leitura

Determinadas funcionalidades são restritas a servidores primários e não podem ser configuradas em réplicas de leitura. Estão incluídos:

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

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

Conectar-se a uma réplica

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

A réplica herda a conta do 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.

Existem dois métodos para se conectar à réplica:

  • Direto à 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 regular. Para um servidor chamado myreplica com o nome de usuário administrador myadmin, você pode se conectar à réplica usando o psql:
psql -h myreplica.postgres.database.azure.com -U myadmin postgres

No prompt, insira a senha da conta de usuário.

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

  • Por meio de pontos de extremidade virtuais: há um método de conexão alternativo usando pontos de extremidade virtuais, conforme detalhado na seção Pontos de extremidade virtuais. Ao usar pontos de extremidade virtuais,é possível configurar o ponto de extremidade somente leitura para apontar consistentemente para a réplica, independente de qual servidor detém a função de réplica atualmente.

Monitorar a replicação

O recurso de réplica de leitura no servidor flexível do Banco de Dados do Azure para 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 a exclusão de segmentos WAL no primário antes de serem enviados para as réplicas. A desvantagem da abordagem é o risco de falta de espaço no primário, caso o slot de replicação permaneça inativo por um período de tempo estendido. Nessas 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 é alternado automaticamente para o modo somente leitura para evitar erros associados a situações de disco cheio.
Portanto, monitorar o atraso da replicação e o status dos slots de replicação é essencial para as réplicas de leitura.

É recomendável definir regras de alerta para os armazenamentos usados ou para as porcentagem de armazenamento e para atrasos de replicação, quando esses excedem determinados limites, a fim de agir proativamente, aumentar o tamanho do armazenamento e excluir réplicas de leitura atrasadas. Por exemplo, você pode definir um alerta se o percentual de armazenamento exceder 80% de uso e se o atraso da réplica for maior que 5 minutos. A métrica de Armazenamento de log de transações usado mostra se o acúmulo de arquivos WAL é o principal motivo do uso excessivo de armazenamento.

O servidor flexível do Banco de Dados do Azure para PostgreSQL fornece duas métricas para monitorar a replicação. As duas métricas são Retardo Máximo de Replicação Física e Retardo da Réplica de Leitura. Para saber como exibir essas métricas, consulte a seção Monitorar uma réplica do artigo de instruções sobre réplica de leitura.

A métrica Retardo Máximo de Replicação Física mostra o retardo em bytes entre o primário e a réplica com o maior retardo. 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 ao primário. As informações de retardo também estão presentes quando a réplica está em processo de recuperação com o primário, durante a criação da réplica ou quando a replicação fica inativa.

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

Definir um alerta para informar quando o retardo de réplica atingir um valor que não é 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.

Observação

Se um servidor primário ou a réplica de leitura forem reiniciados, o tempo que leva para reiniciar e recuperar o atraso é refletido na métrica de Atraso da réplica.

Estado da replicação

Para monitorar o progresso e o estado da operação de replicação e promoção, consulte a coluna de 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 insights sobre a condição atual das réplicas de leitura e seus links para o primário. Para usuários que dependem da API do Azure Resource Manager, ao invocar a API de GetReplica, o estado aparece como ReplicationState no recipiente de propriedades replica.

Estes são os valores possíveis:

Estado da replicação Descrição Ordem de promoção Ordem de criação de réplica de leitura
Reconfigurando Aguardando o início do link primário da réplica. Ele poderá permanecer mais tempo se a réplica ou sua região não estiver disponível, por exemplo, devido a um desastre. 1 N/D
Provisionamento A réplica de leitura está sendo provisionada e a replicação entre os dois servidores ainda não foi iniciada. Você não poderá se conectar à réplica de leitura até a conclusão do provisionamento. N/D 1
Atualização A configuração do servidor está sendo preparado após uma ação disparada, como promoção ou criação de réplica de leitura. 2 2
Fazendo catchup Os arquivos WAL estão sendo aplicados na réplica. A duração dessa fase durante a promoção depende da opção de sincronização de dados escolhida, se foi a planejada ou forçada. 3 3
Ativo Estado íntegro, indicando que a réplica de leitura foi conectada ao primário com êxito. Se os servidores forem interrompidos, mas já foram conectados com êxito, o status permanecerá como ativo. 4 4
Desfeito Estado não íntegro, indicando que a operação de promoção pode ter falhado ou a réplica não consegue se conectar ao primário por algum motivo. Remova e recrie a réplica para resolver isso." N/D N/D

Saiba como monitorar a replicação.

Considerações

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

  • Operações de energia: as operações de energia, incluindo ações de início e parada, podem ser aplicadas nos servidores primários e de réplica. No entanto, para preservar a integridade do sistema, uma sequência específica deve ser seguida. 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 iniciar nos servidores-réplica antes de iniciar o servidor primário.
  • Se o servidor tiver réplicas de leitura, primeiro as réplicas de leitura deverão ser excluídas antes de excluir o servidor primário.
  • A atualização de versão principal in-loco no servidor flexível do Banco de Dados do Azure para 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. Depois que a atualização for concluída, 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 o SSD Premium v2 para armazenamento, não há suporte para a criação de réplicas de leitura.
  • Redefinição de senha do administrador: Atualmente não há suporte para a redefinição da senha de administrador no servidor de réplica. Além disso, também não há suporte para atualizar a senha de administrador e a operação de promoção de réplica na mesma solicitação. Se desejar fazer isso, primeiro deverá promover o servidor de réplica e depois 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 se tornar uma réplica. Não é possível criar uma réplica de outra réplica de leitura, ou seja, não há suporte para replicação em cascata.

Movimento de recurso

Os usuários podem criar réplicas de leitura em um grupo de recursos diferente do primário. No entanto, não há suporte para a movimentação de réplicas de leitura para outro grupo de recursos após a criação delas. 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.

Aumento 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 aumento automático de armazenamento permite que o armazenamento do banco de dados aumente automaticamente e evite ficar sem espaço, o que pode levar a interrupções de banco de dados. Veja como gerenciar as configurações de crescimento automático do armazenamento de forma eficaz:

  • O crescimento automático do armazenamento pode ser ativado 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 escala de armazenamento.
  • Para habilitar o crescimento automático de armazenamento no primário, primeiro você deverá habilitá-lo nas réplicas. Essa ordem de operações é crucial para manter a integridade da replicação.
  • Por outro lado, se você quiser 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.

Fazer backup e restaurar

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. Alguns aspectos importantes a lembrar:

Promover para servidor primário

  1. Nenhum backup é obtido de réplicas de leitura: os backups nunca são obtidos 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 teve backups feitos durante esse período, esses backups serão preservados. Eles serão mantidos pelo 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 serão restritas. Você só pode iniciar uma operação de restauração quando o servidor for promovido de volta à função primária.

Para ficar mais claro, confira uma tabela ilustrando estes pontos:

Função de servidor Backup realizado Restauração permitida
Primário Sim Yes
Réplica de leitura Não Não
Réplica de leitura promovida à primária Sim Yes

Promover para servidor independente e remover da replicação

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

Rede

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

Importante

A comunicação bidirecional entre o servidor primário e as réplicas de leitura é crucial para a configuração do servidor flexível 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 da 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 quando as réplicas precisarem se comunicar em ordem inversa, da réplica à primária, especialmente durante a promoção para operações primárias. Além disso, as conexões com a conta de armazenamento do Azure que armazena arquivos WAL (log write-ahead) devem ser autorizadas para manter a durabilidade dos dados e habilitar processos de recuperação eficientes.

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

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

Em casos raros, o alto retardo causado por slots de replicação pode levar a um aumento no uso de armazenamento no servidor primário devido ao acúmulo de arquivos WAL. Se o uso de armazenamento atingir 95% ou a capacidade disponível ficar abaixo de 5 GiB, o servidor alterna automaticamente para o modo somente leitura para evitar erros de disco cheio.

Como manter a integridade e a funcionalidade do servidor primário é uma prioridade, nesses casos de borda, o slot de replicação pode ser removido para garantir que o servidor primário permaneça operacional para tráfego de leitura e gravação. Assim, a replicação alterna para o modo de envio de logs baseado em arquivo, o que pode resultar em um retardo de replicação maior.

É fundamental monitorar de perto o uso de armazenamento e o retardo de replicação e tomar as ações necessárias para atenuar possíveis problemas antes que eles sejam escalonados.

Parâmetros do Servidor

Quando uma réplica de leitura é criada, ela herda os parâmetros de servidor a partir do servidor primário. Isso serve para garantir um ponto de partida consistente e confiável. No entanto, as alterações nos parâmetros de 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 a melhora de desempenho em operações com uso intensivo de leitura, sem modificar os parâmetros do servidor primário. Isso fornece opções de flexibilidade e personalização, mas também exige um gerenciamento cuidadoso e manual para manter a consistência entre o primário e sua réplica quando for necessária a uniformidade dos parâmetros do servidor.

Os administradores podem alterar os parâmetros de servidor no servidor de réplica de leitura e definir valores diferentes daqueles presentes no servidor principal. A única exceção são os parâmetros que podem afetar a recuperação da réplica, mencionados também na seção "Escala" 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 se depare com limitações de memória compartilhadas, esses parâmetros específicos sempre devem ser definidos como valores equivalentes ou maiores do que aqueles configurados no servidor primário.

Escala

Você está livre para escalar e reduzir verticalmente a computação (vCores), alterar a camada de serviço de Uso Geral para otimizado para memória (ou vice-versa) e para escalar verticalmente o armazenamento, mas as seguintes limitações se aplicam.

Para colocação em escala de computação:

  • O servidor flexível do Banco de Dados do Azure para PostgreSQL requer que vários parâmetros em 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.

  • Escalar verticalmente: primeiro escale verticalmente a computação de uma réplica e, em seguida, escale verticalmente o primário.

  • Reduzir verticalmente: primeiro reduza verticalmente a computação do primário e, em seguida, reduza verticalmente a réplica.

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

Para colocação em escala de armazenamento:

  • Escalar verticalmente: primeiro escale verticalmente o armazenamento de uma réplica e, em seguida, escale verticalmente o primário.

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

Conteúdo relacionado