Réplicas de leitura no servidor flexível do Banco de Dados do Azure para PostgreSQL

O recurso de réplicas de leitura permite replicar os dados de um servidor flexível do Banco de Dados do Azure para PostgreSQL em uma réplica somente leitura. As réplicas são atualizadas de forma assíncrona usando a tecnologia de replicação física nativa do mecanismo 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 a um servidor flexível comum do Banco de Dados do Azure para PostgreSQL. Para cada réplica de leitura, você paga pela capacidade de computação provisionada em vCores e pelo armazenamento em GB por mês.

Saiba como Criar uma réplica de leitura.

Quando usar uma réplica de leitura

O recurso de réplica de leitura ajuda a melhorar o desempenho e a escala de cargas de trabalho com uso intensivo de leitura. Você pode isolar as cargas de trabalho de leitura para as réplicas, enquanto direciona as cargas de trabalho de gravação para a origem. Você também pode implantar réplicas de leitura em uma região diferente e promovê-las a servidores de leitura e gravação, em caso de necessidade de recuperação de desastres.

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 da primária apresentam menos atraso do que as réplicas geográficas, já que estas geralmente sofrem com a latência causada pela distância geográfica. Para obter mais informações sobre as implicações de desempenho da replicação geográfica, confira 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.

Criar uma réplica

Você pode implantar um servidor primário para Banco de Dados do Azure para PostgreSQL servidor flexível 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 de Azure globais em que Banco de Dados do Azure para PostgreSQL está disponível. Você também pode criar réplicas em algumas regiões Azure em nuvens soberanas. Para obter uma lista de regiões de nuvem soberanas em que você pode criar réplicas, consulte o artigo de replicação geográfica.

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

Uma réplica só é considerada criada com êxito quando duas condições são atendidas: todo o backup do primário é copiado para a réplica e os logs de transação sincronizam com não mais do que um retardo de 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, evite criar réplicas ao migrar de outras fontes para um servidor Banco de Dados do Azure para PostgreSQL flexível ou durante operações de carregamento em massa pesadas. Se você estiver migrando dados ou carregando grandes quantidades de dados, conclua 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 carga 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 max_wal_size parâmetro do servidor. Você pode acompanhar o uso de armazenamento do log de transações por meio da métrica Armazenamento Usado pelo Log de Transações, que fornece informações sobre a quantidade de armazenamento usada pelo log de transações. Monitorando 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.

Saiba como criar uma réplica de leitura.

Gerenciamento de configuração

Ao configurar réplicas de leitura para um servidor Banco de Dados do Azure para PostgreSQL flexível, você precisa entender quais configurações de servidor você pode ajustar, quais configurações a réplica herda do servidor primário e quaisquer limitações relacionadas.

Configurações herdadas

Quando você cria uma réplica de leitura, ela herda configurações de servidor específicas do servidor primário. Você pode alterar essas configurações durante a criação da réplica ou depois de configurar a réplica. No entanto, a réplica de leitura não herda configurações específicas, como o backup geográfico, do servidor primário.

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

• Camada, tamanho de armazenamento: para promover a operação do servidor primário , a camada e o tamanho do armazenamento devem corresponder ao servidor primário. Para a operação de promover para servidor independente e remover da replicação, a camada de serviço e o tamanho do armazenamento podem ser iguais ou superiores aos do servidor primário.
• Nível de desempenho (IOPS): ajustável.
• Criptografia de dados: ajustável, incluindo a mudança de chaves gerenciadas pelo serviço para chaves gerenciadas pelo cliente.

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

• Regras de firewall: você pode adicionar, excluir ou modificar regras.
• Camada, tamanho de armazenamento: para promover a operação do servidor primário , a camada e o tamanho do armazenamento devem corresponder ao servidor primário. Para a operação de promover para servidor independente e remover da replicação, a camada de serviço e o tamanho do armazenamento podem ser iguais ou superiores aos do servidor primário.
• Nível de desempenho (IOPS): ajustável.
• método Authentication: ajustável, as opções incluem a mudança da autenticação PostgreSQL para Microsoft Entra.
• Parâmetros: a maioria dos parâmetros é ajustável. No entanto, os parâmetros que afetam o tamanho da memória compartilhada devem estar alinhados com o servidor primário, especialmente em possíveis cenários de promoção a servidor primário. Para a operação de promoção para servidor independente e remoção da replicação, esses parâmetros devem corresponder aos do servidor primário ou excedê-los.
• Agendamento de manutenção: ajustável.

Recursos sem suporte em réplicas de leitura

Os servidores primários dão suporte a determinadas funcionalidades que você não pode configurar em réplicas de leitura. Essas funcionalidades incluem:

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

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

Criar réplicas de leitura em cascata

Réplicas de leitura em cascata podem ajudar a distribuir cargas de trabalho de leitura, reduzindo a carga no servidor primário. Implantar réplicas de leitura em regiões diferentes (réplicas de leitura entre regiões) pode ajudar a distribuir o tráfego de leitura mais próximo dos usuários em várias regiões geográficas. Você pode adicionar réplicas de leitura em cascata ao servidor Banco de Dados do Azure para PostgreSQL. Esse recurso permite que você crie novas réplicas de leitura a partir de uma réplica de leitura existente, com essa réplica servindo como origem para o nível seguinte.

A réplica de leitura de primeiro nível replica de forma assíncrona os dados do servidor primário. Em seguida, você pode criar uma réplica de leitura de segundo nível usando a réplica de primeiro nível como sua origem, formando uma hierarquia de replicação de duas camadas. Essa arquitetura aumenta a escalabilidade, com suporte a até 30 servidores de réplica de leitura: o servidor primário permite até cinco réplicas de leitura, e cada uma dessas réplicas pode suportar outras cinco réplicas adicionais. Para adicionar uma réplica de leitura em cascata a Banco de Dados do Azure para PostgreSQL servidor flexível, selecione a réplica de leitura existente (criada no servidor primário), vá para a guia Replicação e selecione Criar réplica.

Por exemplo, o servidor primário pode ter até cinco réplicas de leitura (nível 1). Uma delas, digamos read-replica-1, atua como a origem de outra réplica read-replica-2 que se torna parte do (nível 2).

Principais considerações

• Você pode criar até cinco réplicas de leitura por réplica de leitura de origem, com suporte para dois níveis de replicação.
• Há suporte para a operação de alternância entre a réplica de leitura intermediária (origem) e a réplica de leitura em cascata.
• A promoção à operação primária não dá suporte a réplicas de leitura intermediárias com réplicas de leitura em cascata.
• Pontos de extremidade virtuais não são compatíveis com réplicas em cascata.
• Há suporte para réplicas de leitura em cascata em réplicas intermediárias com PostgreSQL versão 14 e superior.

Conectar-se a uma réplica

Quando você cria uma réplica, ela não herda as regras de firewall ou o ponto de extremidade de serviço de rede virtual do servidor primário. Você pode definir essas regras durante a criação da réplica e alterá-las posteriormente.

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.

Você pode usar dois métodos para se conectar à réplica:

• Direto para a réplica: Você pode se conectar à réplica usando o hostname dela e uma conta de usuário válida, da mesma forma que faria em um servidor flexível comum do Banco de Dados do Azure para PostgreSQL. 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.

Para facilitar o processo de conexão, o portal Azure fornece cadeias de conexão prontas para uso. Você pode encontrar essas cadeias de conexão na página Conectar . Elas incluem libpq variáveis e cadeias de conexão personalizadas para consoles bash.

• Por meio de pontos de extremidade virtuais: um método de conexão alternativo usa pontos de extremidade virtuais. Para obter mais informações, consulte pontos de extremidade virtuais. Usando pontos de extremidade virtuais, você pode configurar o ponto de extremidade de somente leitura para sempre apontar para a réplica, independentemente de qual servidor atualmente detém a função de réplica.

Monitorar a replicação

O recurso de réplica de leitura no Banco de Dados do Azure para PostgreSQL se baseia no 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. Esse ajuste ajuda a impedir que as réplicas fiquem fora de sincronia porque evita a exclusão de segmentos WAL no primário antes que as réplicas as recebam. A desvantagem dessa abordagem é o risco de ficar sem espaço no primário se o slot de replicação permanecer inativo por um longo período. Nessas situações, o primário acumula arquivos WAL, causando um aumento gradual do uso de armazenamento. Quando o uso do armazenamento atinge 95% ou se a capacidade disponível for menor que 5 GiB, o servidor alterna 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.

Defina regras de alerta para o 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 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 Armazenamento de log de transações usado indica se o acúmulo de arquivos WAL é o principal motivo para o uso excessivo de armazenamento.

Monitorando métricas

Banco de Dados do Azure para PostgreSQL serviço fornece as seguintes métricas para monitorar a replicação.

Você pode usar métricas avançadas para monitorar e alertar sobre a replicação de leitura.

Habilitar métricas aprimoradas

• A maioria dessas novas métricas estão desabilitadas por padrão. No entanto, há algumas exceções que são habilitadas por padrão. A coluna mais à direita nas tabelas a seguir indica se cada métrica está habilitada por padrão ou não.
• Para habilitar as métricas que não estão habilitadas por padrão, defina o parâmetro metrics.collector_database_activity como ON. Esse parâmetro é dinâmico e não requer uma reinicialização de instância.

Replicação lógica

Replication

Para saber mais, confira o artigo de instruções sobre réplicas 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 só estará disponível 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 de 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.

Estado da replicação

Para monitorar o progresso e o status da operação de replicação e promoção, consulte a coluna Replication no portal 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 Azure Resource Manager, ao invocar a API GetReplica, o estado aparece como ReplicationState no recipiente de propriedades replica.

Estes são os valores possíveis:

Saiba como monitorar a replicação.

Considerações

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

• Operações de energia: você pode aplicar operações de energia, incluindo ações de inicialização e desligamento, aos servidores primário e de réplica. No entanto, para preservar a integridade do sistema, siga 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 iniciar nos servidores-réplica antes de iniciar o servidor primário.
• Se um servidor tiver réplicas de leitura, exclua as réplicas de leitura antes de excluir o servidor primário.
• A atualização de versão principal in-loco para um servidor flexível do Banco de Dados do Azure para PostgreSQL requer a remoção de réplicas de leitura e réplicas de leitura em cascata habilitadas no servidor. Depois que as réplicas forem excluídas, você poderá atualizar o servidor primário 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.
  • Redefinir a senha do administrador: atualmente, não há suporte para redefinir a senha de administrador no servidor de réplica. Além disso, não é possível atualizar a senha de administrador junto com a operação de promover a réplica na mesma solicitação. Se você quiser executar essas ações, primeiro promova o servidor de réplica e atualize a senha no servidor recém-promovido separadamente.

Novas réplicas

Uma réplica de leitura é criada como um novo servidor flexível do Banco de Dados do Azure para PostgreSQL. Não é possível transformar um servidor existente em uma réplica.

Movimentação de recursos

Você pode criar réplicas de leitura em um grupo de recursos diferente do grupo de recursos primário. No entanto, não há suporte para mover réplicas de leitura para outro grupo de recursos após serem criadas. Além disso, não há suporte para mover réplicas para uma assinatura diferente. Não há suporte para 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 um servidor Banco de Dados do Azure para PostgreSQL flexível, verifique se a configuração de crescimento automático de armazenamento nas réplicas corresponde à 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 seu servidor Banco de Dados do Azure para PostgreSQL flexível, tenha em mente a função atual e anterior do servidor em diferentes cenários de promoção. Lembre-se destes pontos-chave:

Promover para servidor primário

• Nenhum backup de réplicas de leitura: o sistema nunca recebe backups de servidores de réplica de leitura, independentemente de sua função anterior.
• Preservação de backups anteriores: se um servidor já foi primário e o sistema fez backups durante esse período, ele preserva esses backups até o período de retenção definido pelo usuário.
• Restrições de operação de restauração: mesmo se houver backups anteriores para um servidor que faz 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 é promovido de volta à função primária.

Para maior clareza, a tabela a seguir ilustra estes pontos:

Promover para servidor independente e remover da replicação

Embora o servidor seja uma réplica de leitura, o sistema não faz backups. No entanto, depois de promovê-lo a um servidor independente, o sistema faz backups para o servidor promovido e o servidor primário. Você pode restaurar backups em ambos os servidores.

Rede

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

Esse requisito não só facilita o processo de sincronização, mas também garante o funcionamento adequado do mecanismo de promoção. As réplicas podem precisar se comunicar na ordem inversa — da réplica para a primária — especialmente durante operações de promoção a primária. Além disso, você deve permitir conexões com a conta de armazenamento do Azure que armazena arquivos de Write-Ahead Logging (WAL) para garantir a durabilidade dos dados e habilitar processos de recuperação eficientes.

Para obter mais informações sobre como configurar o acesso privado (integração à rede virtual) para suas réplicas de leitura e entender as implicações da replicação entre regiões do Azure e redes virtuais no contexto de rede privada, consulte o artigo 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.

Manter a integridade e a funcionalidade do servidor primário é uma prioridade. Nesses casos extremos, o servidor pode descartar o slot de replicação para garantir que o servidor primário permaneça operacional para o 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.

Monitore o uso de armazenamento e o atraso de replicação de perto e execute as ações necessárias para atenuar possíveis problemas antes que eles aumentem.

Parameters

Quando você cria uma réplica de leitura, ela herda os parâmetros do servidor primário. Essa herança garante um ponto de partida consistente e confiável. No entanto, as alterações nos parâmetros 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. Embora esse comportamento forneça opções de flexibilidade e personalização, ele também exige um gerenciamento cuidadoso e manual para manter a consistência entre o primário e sua réplica quando a uniformidade dos parâmetros é necessária.

Os administradores podem alterar parâmetros no servidor de réplica de leitura e definir valores diferentes dos definidos no 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 "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 perfeita e não encontre limitações de memória compartilhadas, sempre defina esses parâmetros específicos como valores equivalentes ou maiores do que aqueles configurados no servidor primário. Antes de reduzir os valores de parâmetro em um servidor de réplica de leitura, verifique se o atraso na replicação é mínimo ou se a réplica está totalmente sincronizada com o servidor primário, para evitar alguns problemas de replicação ou recuperação.

Scale

Você pode aumentar ou reduzir a capacidade de computação (vCores), alterar a camada de serviço de Uso Geral para Otimizado para Memória (ou vice-versa) e aumentar o armazenamento. No entanto, as seguintes ressalvas se aplicam.

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

• Banco de Dados do Azure para PostgreSQL requer que vários parâmetros nas réplicas sejam maior ou igual à 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 deve ser sempre igual ou menor que a computação na réplica menor.

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 réplica menor.

Conteúdo relacionado

• Geo-replicação no ambiente do Banco de Dados do Azure para PostgreSQL.
• Promova réplicas de leitura no Banco de Dados do Azure para PostgreSQL.
• Pontos de extremidade virtuais para réplicas de leitura no Banco de Dados do Azure para PostgreSQL.
• Criar uma réplica de leitura.
• Replication em regiões Azure e redes virtuais com rede privada.