Ler réplicas no Banco de Dados do Azure para servidor flexível PostgreSQL

A funcionalidade de read replica permite replicar dados de um servidor flexível do Base de Dados do Azure para PostgreSQL para uma réplica de apenas leitura. As réplicas são atualizadas de forma assíncrona utilizando a tecnologia nativa de replicação física do motor PostgreSQL. A replicação em modo de transmissão contínua com slots de replicação é o modo de operação predefinido. Quando necessário, a transferência de logs com base em arquivos é utilizada para sincronizar. Você pode replicar do servidor primário para até cinco réplicas.

As réplicas são novos servidores que geres de forma semelhante ao servidor flexível normal do Base de Dados do Azure para PostgreSQL. Por cada réplica de leitura, pagas pelo processamento provisionado em vCores e pelo armazenamento em GB por mês.

Saiba como criar uma réplica de leitura.

Quando utilizar uma réplica de leitura

A funcionalidade de réplica de leitura ajuda a melhorar o desempenho e a escala das cargas de trabalho intensivas em leitura. Podes isolar cargas de leitura para as réplicas, enquanto direcionas as cargas de escrita para o primário. Também pode implementar réplicas de leitura numa região diferente e promovê-las para um servidor de leitura e escrita, caso seja necessária recuperação após desastre.

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. Estão otimizados para fornecer atualizações quase em tempo real a partir do principal para a maioria das cargas de trabalho, tornando-os uma excelente solução para cenários que exigem muita leitura. 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 geo-réplicas, pois estas últimas frequentemente 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 eventualmente tornam-se consistentes com os dados no primário. Utilize esta funcionalidade para cargas de trabalho que podem acomodar este atraso.

Criar uma réplica

Pode implementar um servidor primário do Servidor flexível do Base de Dados do Azure para PostgreSQL em qualquer região que suporte o serviço. Pode criar réplicas do servidor principal dentro da mesma região ou em diferentes regiões globais do Azure onde o Base de Dados do Azure para PostgreSQL esteja disponível. Também podes criar réplicas em algumas regiões do Azure em nuvens soberanas. Para ver uma lista de regiões de nuvem soberana onde pode criar réplicas, consulte o artigo Geo-replicação.

Quando inicia o fluxo de trabalho de criação de réplica, o processo cria um servidor flexível do Base de Dados do Azure para PostgreSQL em branco. O novo servidor é preenchido com os dados no servidor primário. Para a criação de réplicas na mesma região, o processo recorre a uma abordagem de snapshot. Portanto, o tempo de criação é independente do tamanho dos dados. As geo-réplicas são criadas utilizando o backup base do primário, que é depois transmitido pela rede. Portanto, o tempo de criação pode variar entre minutos e várias horas, dependendo do tamanho principal.

Uma réplica só é considerada criada com sucesso quando são cumpridas duas condições: toda a cópia de segurança do primário é copiada para a réplica, e os registos de transações sincronizam-se com no máximo 1 GB de atraso.

Para obter uma operação de criação bem-sucedida, evite fazer réplicas durante períodos de alta carga transacional. Por exemplo, evite criar réplicas ao migrar de outras fontes para um servidor flexível do Base de Dados do Azure para PostgreSQL ou durante operações de carregamento massivo. Se estiver a migrar dados ou a carregar grandes quantidades de dados, termine esta tarefa primeiro. Depois de concluí-lo, você pode começar a configurar as réplicas. Quando a operação de migração ou carregamento em massa terminar, verifique se o tamanho do log de transação voltou ao seu tamanho normal. Normalmente, o tamanho do registo de transações deve estar próximo do valor definido no max_wal_size parâmetro para o seu servidor. Pode acompanhar o espaço de armazenamento utilizado pelo registo de transações utilizando a métrica Armazenamento Utilizado do Registo de Transações, que permite obter informações sobre a quantidade de armazenamento utilizada pelo registo de transações. Ao monitorizar esta métrica, pode garantir que o tamanho do registo de transações está dentro do intervalo esperado e que o processo de criação da réplica pode começar.

Saiba como Criar uma réplica de leitura.

Gerenciamento de configuração

Quando configuras réplicas de leitura para um servidor flexível do Base de Dados do Azure para PostgreSQL, precisas de perceber que configurações de servidor podes ajustar, quais as configurações que a réplica herda do servidor principal e quaisquer limitações relacionadas.

Configurações herdadas

Quando crias uma réplica de leitura, ela herda configurações específicas do servidor principal. Podes alterar estas configurações durante a criação da réplica ou depois de a configurares. No entanto, a réplica de leitura não herda definições específicas, como o geo-backup, do servidor principal.

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

• Nível, tamanho do armazenamento: Para a operação de promoção para servidor principal , o nível e o tamanho do armazenamento devem corresponder ao servidor principal. Na operação promover para servidor independente e remover da replicação, o escalão e o tamanho do armazenamento podem ser iguais ou superiores aos do servidor primário.
• Camada de desempenho (IOPS): ajustável.
• Encriptação de dados: Ajustável, incluindo a transição de chaves geridas pelo serviço para chaves geridas pelo cliente.

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

• Regras de firewall: Pode adicionar, eliminar ou modificar regras.
• Nível, tamanho do armazenamento: Para a operação de promoção para servidor principal , o nível e o tamanho do armazenamento devem corresponder ao servidor principal. Para a operação de promoção para servidor independente e remoção da replicação, o nível e o tamanho do armazenamento podem ser iguais ou superiores aos do servidor principal.
• Camada de desempenho (IOPS): ajustável.
• : 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 que afetam o tamanho da memória partilhada devem estar alinhados com o servidor principal, especialmente em potenciais cenários de promoção a servidor principal. Para promover para servidor independente e remover da operação de replicação , estes parâmetros devem igualar ou exceder os do servidor principal.
• Cronograma de manutenção: Ajustável.

Funcionalidades sem suporte nas réplicas de leitura

Os servidores principais suportam determinadas funcionalidades que não é possível configurar nas réplicas de leitura. Estas funcionalidades incluem:

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

Se o seu servidor flexível do Base de Dados do Azure para PostgreSQL estiver encriptado com chaves geridas pelo cliente, consulte a documentação para outras considerações.

Criar réplicas de leitura em cascata

As réplicas de leitura em cascata podem ajudar a distribuir cargas de trabalho de leitura, reduzindo a carga no servidor primário. A implantação de réplicas de leitura em diferentes regiões (réplicas de leitura entre regiões) pode ajudar a distribuir o tráfego de leitura mais perto dos usuários em várias geografias. Pode adicionar réplicas de leitura em cascata ao servidor Base de Dados do Azure para PostgreSQL. Esta funcionalidade permite-lhe criar novas réplicas de leitura a partir de uma réplica de leitura existente, servindo esta de 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. Pode então criar uma réplica de leitura de segundo nível usando a réplica de primeiro nível como fonte, formando uma hierarquia de replicação de dois níveis. Esta arquitetura aumenta a escalabilidade, suportando até 30 servidores réplicas de leitura, sendo que o servidor principal permite até cinco réplicas de leitura, e cada uma dessas réplicas suporta cinco réplicas adicionais. Para adicionar uma réplica de leitura em cascata ao servidor flexível Base de Dados do Azure para PostgreSQL, selecione a réplica de leitura existente (criada a partir do servidor principal), vá ao separador Replicação e selecione Criar réplica.

Por exemplo, o seu servidor principal pode ter até cinco réplicas de leitura (nível 1). Um destes, por exemplo read-replica-1, atua como fonte para outra réplica read-replica-2 que se torna parte de (nível 2).

Principais considerações

• Pode criar até cinco réplicas de leitura por réplica de leitura de origem, com suporte para dois níveis de replicação.
• A operação de comutação suporta a réplica de leitura intermédia (fonte) e a réplica de leitura em cascata.
• A operação de promover a primário não suporta réplicas de leitura intermédias que tenham réplicas de leitura em cascata.
• Os endpoints virtuais não são suportados para réplicas em cascata.
• As réplicas de leitura em cascata são suportadas em réplicas intermediárias com o PostgreSQL versão 14 e superior.

Ligar a uma réplica

Quando crias uma réplica, ela não herda as regras do firewall ou o endpoint do serviço de rede virtual do servidor principal. Podes definir estas regras durante a criação de réplicas e alterá-las mais tarde.

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.

Pode usar dois métodos para ligar à réplica:

• Direto para a réplica: Pode ligar-se à réplica usando o seu nome de host e uma conta de utilizador válida, tal como faria num servidor flexível normal do Base 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.

Para facilitar o processo de ligação, o portal Azure disponibiliza strings de ligação prontos a usar. Pode encontrar estas cadeias de ligação na página Conectar . Incluem tanto libpq variáveis como cadeias de ligação adaptadas para consolas bash.

• Através de pontos de extremidade virtuais: Um método alternativo de conexão utiliza pontos de extremidade virtuais. Para mais informações, consulte Endpoints virtuais. Ao usar endpoints virtuais, pode configurar o endpoint só de leitura para apontar sempre para a réplica, independentemente de qual servidor detém atualmente a função de réplica.

Monitorizar a replicação

A funcionalidade de réplica de leitura no Base de Dados do Azure para PostgreSQL baseia-se 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. Este ajuste ajuda a evitar que as réplicas fiquem fora de sincronização, pois evita eliminar segmentos WAL no primário antes de as réplicas os receberem. A desvantagem desta abordagem é o risco de ficar sem espaço no primário se o slot de replicação permanecer inativo durante um período prolongado. Nessas situações, o primário acumula ficheiros WAL, causando um crescimento incremental do uso de armazenamento. Quando o uso de armazenamento atinge 95% ou se a capacidade disponível for inferior a 5 GiB, o servidor muda automaticamente para modo de leitura sozinha 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.

Defina regras de alerta para armazenamento usado ou percentagem de armazenamento, e para atrasos de replicação, quando ultrapassam certos limiares, para que possa agir proativamente, aumentar o tamanho do armazenamento e eliminar 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-lhe se a acumulação de ficheiros WAL é a principal razão para o uso excessivo de armazenamento.

Métricas de monitoramento

O serviço Base de Dados do Azure para PostgreSQL fornece as seguintes métricas para monitorizar a replicação.

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

Habilitando métricas aprimoradas

• A maioria dessas novas métricas é desativada por padrão. No entanto, existem algumas exceções, que são ativadas 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 ativar as métricas que não estão ativadas por defeito, defina o parâmetro metrics.collector_database_activity para ON. Esse parâmetro é dinâmico e não requer uma reinicialização da instância.

Replicação lógica

Replication

Para saber mais, consulte o artigo de instruções da réplica.

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. Esta métrica é aplicável e está disponível apenas no servidor principal, estando disponível apenas se pelo menos uma das réplicas de leitura estiver ligada ao primário. As informações de atraso também estão presentes quando a réplica está em processo de sincronização com o primário, 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 não estiverem a ocorrer transações no seu servidor principal e se a última transação tiver sido reproduzida há 5 segundos, o atraso da réplica de leitura mostra 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 a latência da réplica atingir um valor que não seja aceitável para a 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 de replicação

Para monitorizar o progresso e o estado da replicação e promover a operação, consulte a coluna Estado de replicação no portal 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 utilizadores que dependem da API Azure Resource Manager, ao invocar a API GetReplica, o estado aparece como ReplicationState no saco de propriedades replica.

Aqui estã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. Aplicam-se as seguintes considerações.

• Operações de energia: Pode aplicar operações de energia, incluindo ações de início e paragem , tanto ao servidor principal como ao 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 de inicialização nos servidores de réplica antes de iniciar o servidor primário.
• Se um servidor tiver réplicas de leitura, elimine primeiro as réplicas de leitura antes de eliminar o servidor principal.
• Atualização local da versão principal de um servidor flexível do Base de Dados do Azure para PostgreSQL requer a remoção de todas as réplicas de leitura e réplicas de leitura em cascata configuradas no servidor. Depois de as réplicas serem apagadas, podes atualizar o servidor principal 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.
  • Redefinir a palavra-passe de administrador: Redefinir a palavra-passe de administrador no servidor réplica não é atualmente suportado. Além disso, a atualização da palavra-passe de administrador juntamente com a operação de promoção da réplica no mesmo pedido não é suportada. Se quiseres realizar estas ações, primeiro promove o servidor réplica e depois atualiza a palavra-passe no servidor recém-promovido separadamente.

Novas réplicas

Cria uma réplica de leitura na forma de um novo servidor flexível do Base de Dados do Azure para PostgreSQL. Não é possível transformar um servidor existente em uma réplica.

Movimentação de recursos

Podes criar réplicas de leitura num grupo de recursos diferente do principal. No entanto, não é suportada a mudança de réplicas de leitura para outro grupo de recursos após a sua criação. Além disso, não é suportado mover réplicas para uma subscrição diferente. Mover o primário que leu réplicas para outro grupo de recursos ou subscrição não é suportado.

Aumento automático do armazenamento

Ao configurar réplicas de leitura para um servidor flexível do Base de Dados do Azure para PostgreSQL, certifique-se de que a definição de crescimento automático do armazenamento nas réplicas corresponde à 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 recuperação

Quando gerir backups e restaurações para o seu servidor flexível Base de Dados do Azure para PostgreSQL, tenha em mente o papel atual e anterior do servidor em diferentes cenários de promoção. Lembre-se destes pontos-chave:

Promover para servidor primário

• Sem cópias de segurança de réplicas de leitura: O sistema nunca efetua cópias de segurança a partir de servidores de réplica de leitura, independentemente do seu papel anterior.
• Preservação de backups passados: Se um servidor foi uma vez primário e o sistema fez backups durante esse período, preserva esses backups até ao período de retenção definido pelo utilizador.
• Restrições de operação de restauro: Mesmo que existam backups anteriores para um servidor que transita para uma réplica de leitura, as operações de restauro são restritas. Só pode iniciar uma operação de restauro quando o servidor for promovido de volta à função principal.

Para maior clareza, a tabela seguinte 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 efetua cópias de segurança. No entanto, uma vez promovido para servidor independente, o sistema aceita backups tanto para o servidor promovido como para o servidor principal. Podes restaurar backups em ambos os servidores.

Rede

As réplicas de leitura suportam todas as opções de rede que o servidor flexível Base de Dados do Azure para PostgreSQL suporta.

Este requisito não só facilita o processo de sincronização, como também assegura o funcionamento adequado do mecanismo de promoção. As réplicas podem precisar de comunicar no sentido inverso — da réplica para a primária — especialmente durante as operações de promoção a primária. Além disso, deve permitir ligações à conta de armazenamento Azure que armazena arquivos de Write-Ahead Logging (WAL) para manter a durabilidade dos dados e permitir processos de recuperação eficientes.

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

Mitigação de problemas de espaços 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.

Manter a saúde e funcionalidade do servidor principal é uma prioridade. Nestes casos extremos, o servidor pode eliminar o slot de replicação para garantir que o servidor principal se mantém operacional para tráfego de leitura e escrita. 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.

Monitorize atentamente o uso de armazenamento e o atraso de replicação e tome as medidas necessárias para mitigar potenciais problemas antes que se agravem.

Parameters

Quando crias uma réplica de leitura, ela herda os parâmetros do servidor principal. Esta herança assegura um ponto de partida consistente e fiável. No entanto, quaisquer alterações aos parâmetros no servidor principal que faças após criares a 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 este comportamento proporcione flexibilidade e opções de personalização, também exige uma gestão cuidadosa e manual para manter a consistência entre o primário e a sua réplica quando é necessária uniformidade dos parâmetros.

Os administradores podem alterar parâmetros no servidor réplica de leitura e definir valores diferentes dos do 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 "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 fluida e que não encontre limitações de memória partilhada, defina sempre estes parâmetros para valores equivalentes ou superiores aos configurados no servidor principal. Antes de reduzir os valores dos parâmetros num servidor réplica de leitura, certifique-se de que o atraso de replicação é mínimo ou que a réplica está completamente sincronizada com o servidor principal, para evitar potenciais problemas de replicação ou recuperação.

Scale

Pode aumentar e diminuir a capacidade de computação (vCores), alterar o escalão de serviço de Fins Gerais para Otimizado para Memória (ou vice-versa) e aumentar a capacidade de armazenamento. No entanto, aplicam-se as seguintes ressalvas.

Para o dimensionamento de computação:

• serviço Base de Dados do Azure para PostgreSQL exige 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 partilhada 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.

• Escalamento: primeiro aumente os recursos de computação de uma réplica e, em seguida, aumente os recursos do primário.

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

• O cálculo no primário deve ser sempre igual ou menor do que o cálculo na réplica mais pequena.

Para dimensionamento de armazenamento:

• Ampliar: Primeiro aumente o armazenamento de uma réplica e, em seguida, amplie o primário.

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

Conteúdo relacionado

• Geo-replicação na Base de Dados Azure para PostgreSQL.
• Promover réplicas de leitura em Base de Dados do Azure para PostgreSQL.
• Endpoints virtuais para réplicas de leitura em Base de Dados do Azure para PostgreSQL.
• Crie uma réplica de leitura.
• Replicação entre regiões do Azure e nas redes virtuais com redes privadas.