Réplicas de leitura na Base de Dados do Azure para PostgreSQL – Servidor Único

  • Artigo

APLICA-SE A: Banco de Dados do Azure para PostgreSQL - Servidor Único

Importante

O Banco de Dados do Azure para PostgreSQL - Servidor Único está no caminho da desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único PostgreSQL?.

O recurso de réplica de leitura permite replicar dados de um Banco de Dados do Azure para um servidor PostgreSQL para um servidor somente leitura. As réplicas são atualizadas de forma assíncrona com a tecnologia de replicação física nativa do mecanismo PostgreSQL. Você pode replicar do servidor primário para até cinco réplicas.

As réplicas são novos servidores que gere, à semelhança dos servidores da Base de Dados do Azure para PostgreSQL normais. 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 ser um servidor de leitura/gravação no caso de uma recuperação de desastre.

Um cenário comum é fazer com que as cargas de trabalho analíticas e de BI utilizem a réplica de leitura como a origem de dados de 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

O recurso destina-se a cenários em que o atraso é aceitável e destina-se a descarregar consultas. Ele não se destina a cenários de replicação síncrona em que se espera que os dados da réplica estejam atualizados. Ocorrerá um atraso significativo entre o cluster principal e a réplica. Isso pode ser em minutos ou até horas, dependendo da carga de trabalho e da latência entre o primário e a réplica. 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 principal. No entanto, com cargas de trabalho primárias persistentes, pesadas e de escrita intensiva, o atraso da replicação pode continuar a crescer e pode nunca ficar a par do servidor principal. Além disso, pode também aumentar a utilização do armazenamento no servidor principal, uma vez que os ficheiros WAL não são eliminados até serem recebidos na réplica. Se esta situação persistir, a opção será eliminar e recriar a réplica de leitura após a conclusão das cargas de trabalho de escrita intensiva, para que o atraso da réplica volte ao normal. 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 acessar o possível atraso e o RTO/RPO esperado em vários pontos do ciclo de carga de trabalho.

Nota

Os backups automáticos são realizados para servidores de réplica configurados com configuração de armazenamento de até 4 TB.

Replicação entre regiões

Pode criar uma réplica de leitura numa região diferente do servidor principal. A replicação entre regiões pode ser útil em cenários como o planeamento de recuperação após desastre ou para que os dados fiquem mais próximos dos utilizadores.

Nota

Os servidores de camada básica suportam apenas a replicação da mesma região.

Pode ter um servidor principal em qualquer região da Base de Dados do Azure para PostgreSQL. Um servidor primário pode ter uma réplica em sua região emparelhada ou nas regiões de réplica universal. A imagem abaixo mostra quais regiões de réplica estão disponíveis, dependendo da sua região principal.

Ler regiões de réplica

Regiões de réplica universal

Você sempre pode criar uma réplica de leitura em qualquer uma das seguintes regiões, independentemente de onde o servidor primário esteja localizado. Estas são as regiões de réplica universal:

Austrália Leste, Austrália Sudeste, Brasil Sul, Canadá Central, Canadá Leste, Centro dos EUA, Leste Asiático, Leste dos EUA, Leste dos EUA 2, Leste do Japão, Oeste do Japão, Coreia Central, Coreia do Sul, Centro-Norte dos EUA, Norte da Europa, Centro-Sul dos EUA, Sudeste Asiático, Sul do Reino Unido, Oeste do Reino Unido, Europa Ocidental, Oeste dos EUA, Oeste dos EUA 2, Centro-Oeste dos EUA.

Regiões emparelhadas

Além das regiões de réplica universal, você pode criar uma réplica de leitura na região emparelhada do Azure do seu servidor primário. Se não souber o par da sua região, pode saber mais no artigo Regiões Emparelhadas do Azure.

Se você estiver usando réplicas entre regiões para planejamento de recuperação de desastres, recomendamos que você crie a réplica na região emparelhada em vez de uma das outras regiões. As regiões emparelhadas evitam atualizações simultâneas e priorizam o isolamento físico e a residência de dados.

Há limitações a considerar:

  • Pares unidirecionais: algumas regiões do Azure são emparelhadas em apenas uma direção. Estas regiões incluem a Índia Ocidental, o Sul do Brasil. Isso significa que um servidor primário na Índia Ocidental pode criar uma réplica no Sul da Índia. No entanto, um servidor primário no sul da Índia não pode criar uma réplica na Índia Ocidental. Isso ocorre porque a região secundária da Índia Ocidental é o Sul da Índia, mas a região secundária do Sul da Índia não é a Índia Ocidental.

Criar uma réplica

Quando inicia o fluxo de trabalho de criação da réplica, é criado um servidor da Base de Dados do Azure para PostgreSQL em branco. O novo servidor é preenchido com os dados que estavam no servidor principal. O tempo de criação depende da quantidade de dados no cluster principal e o tempo decorrido desde a última cópia de segurança completa semanal. O tempo pode variar entre alguns minutos e várias horas.

Todas as réplicas estão habilitadas para crescimento automático de armazenamento. O recurso de crescimento automático permite que a réplica acompanhe os dados replicados para ela e evite uma interrupção na replicação causada por erros de falta de armazenamento.

A funcionalidade de réplica de leitura utiliza a replicação física do PostgreSQL e não a replicação lógica. 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 registos é utilizado para atualização.

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

Se o servidor PostgreSQL de origem estiver encriptado com chaves geridas pelo cliente, veja a documentação para obter considerações adicionais.

Ligar a uma réplica

Quando você cria uma réplica, ela não herda as regras de firewall ou o ponto de extremidade do serviço VNet do servidor primário. Estas regras devem ser configuradas de forma independente na réplica.

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. Só pode ligar-se a uma réplica de leitura com as contas de utilizador que estão disponíveis no servidor principal.

Você pode se conectar à réplica usando seu nome de host e uma conta de usuário válida, como faria em um Banco de Dados do Azure normal para servidor PostgreSQL. Para um servidor chamado minha réplica 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@myreplica -d postgres

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

Monitorizar a replicação

O Banco de Dados do Azure para PostgreSQL fornece duas métricas para monitorar a replicação. As duas métricas são Max Lag Across Replicas e 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 Lag Across Replicas 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 ao primário e a principal estiver no modo de replicação de streaming. As informações de atraso não mostram detalhes quando a réplica está no processo de alcançar o primário usando os logs arquivados do primário em um modo de replicação de envio de arquivos.

A métrica Replica Lag mostra o tempo desde a última transação repetida. Se não houver transações ocorrendo no servidor primário, a métrica refletirá esse intervalo de tempo. Essa métrica é aplicável e está disponível apenas para servidores de réplica. O atraso da réplica é calculado a partir da pg_stat_wal_receiver exibição:

SELECT EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp());

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 informações adicionais, consulte o servidor primário diretamente para obter o atraso de replicação em bytes 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.

Interromper a replicação / Promover réplica

Pode parar a replicação entre uma principal e uma réplica em qualquer altura. A ação stop faz com que a réplica seja reiniciada e promove que ela seja um servidor independente e autônomo que pode ser gravado. Os dados no servidor autónomo são os dados disponíveis no servidor de réplica no momento em que a replicação é interrompida. Quaisquer atualizações subsequentes no primário não são propagadas para a réplica. No entanto, o servidor de réplica pode ter acumulado logs que ainda não foram aplicados. Como parte do processo de reinicialização, a réplica aplica todos os logs pendentes antes de aceitar conexões de cliente.

Nota

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 operação de réplica de promoção 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.

Considerações

  • Antes de interromper a replicação em uma réplica de leitura, verifique se há atraso na replicação para garantir que a réplica tenha todos os dados necessários.
  • Como a réplica de leitura precisa aplicar todos os logs pendentes antes de se tornar um servidor autônomo, o RTO pode ser maior para cargas de trabalho pesadas de gravação quando a interrupção da replicação acontece, pois pode haver um atraso significativo na réplica. Por favor, preste atenção a isso ao planejar a promoção de uma réplica.
  • O servidor de réplica promovido não pode ser transformado em uma réplica novamente.
  • Se você promover uma réplica para ser o servidor primário, não poderá estabelecer a replicação de volta para o servidor primário antigo. Se quiser voltar à antiga região primária, poderá estabelecer um novo servidor de réplica com um novo nome (ou) eliminar o servidor principal antigo e criar uma réplica com o nome desse servidor antigo.
  • Se tiver várias réplicas de leitura e se promover uma delas para ser o servidor principal, os outros servidores de réplicas permanecerão ligados ao servidor principal antigo. Pode ter de recriar réplicas a partir do novo servidor promovido.

Quando você interrompe a replicação, a réplica perde todos os links para sua réplica primária anterior e outras réplicas.

Saiba como interromper a replicação para uma réplica.

Failover para réplica

No caso de uma falha do servidor primário, o failover não é feito automaticamente para a réplica de leitura.

Como a replicação é assíncrona, pode haver um atraso considerável entre o primário e a réplica. A quantidade de atraso é influenciada por vários fatores, como o tipo de carga de trabalho em execução no servidor primário e a latência entre o servidor primário e o servidor de réplica. Em casos típicos com carga de trabalho de gravação nominal, o atraso da réplica é esperado entre alguns segundos a alguns minutos. No entanto, nos casos em que o primário executa uma carga de trabalho de gravação muito pesada e a réplica não está alcançando rápido o suficiente, o atraso pode ser muito maior. Você pode controlar o atraso de replicação para cada réplica usando a métrica Replica Lag. Essa métrica mostra o tempo desde a última transação repetida na réplica. Recomendamos que você identifique o atraso médio observando o atraso da réplica durante um período de tempo. Você pode definir um alerta sobre o atraso da réplica, para que, se ele sair do intervalo esperado, você seja notificado para tomar medidas.

Gorjeta

Se você fizer failover para a réplica, o atraso no momento em que você desvincular a réplica do primário indicará a quantidade de dados perdidos.

Depois de decidir que deseja fazer failover para uma réplica,

  1. Interromper a replicação para a réplica
    Esta etapa é necessária para fazer com que o servidor de réplica se torne um servidor autônomo e possa aceitar gravações. Como parte desse processo, o servidor de réplica será reiniciado e desvinculado do principal. Depois de iniciar a replicação de parada, o processo de back-end normalmente leva alguns minutos para aplicar quaisquer logs residuais que ainda não foram aplicados e para abrir o banco de dados como um servidor de leitura gravável. Consulte a seção Parar replicação deste artigo para entender as implicações dessa ação.

  2. Aponte seu aplicativo para a réplica (anterior)
    Cada servidor tem uma cadeia de conexão exclusiva. Atualize a cadeia de conexão do aplicativo para apontar para a réplica (anterior) em vez da principal.

Quando o aplicativo estiver processando leituras e gravações com êxito, você terá concluído o failover. A quantidade de tempo de inatividade que seu aplicativo enfrenta dependerá de quando você detetar um problema e concluir as etapas 1 e 2 acima.

Recuperação após desastre

Quando há um evento de desastre importante, como falhas regionais ou no nível da zona de disponibilidade, você pode executar a operação de recuperação de desastres promovendo sua réplica de leitura. No portal da interface do usuário, você pode navegar até o servidor de réplica de leitura. Em seguida, selecione a guia de replicação e você pode parar a réplica para promovê-la a ser um servidor independente. Como alternativa, você pode usar a CLI do Azure para parar e promover o servidor de réplica.

Considerações

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

Pré-requisitos

As réplicas de leitura e a decodificação lógica dependem do log de gravação antecipada (WAL) do Postgres para obter informações. Esses dois recursos precisam de níveis diferentes de registro do Postgres. A decodificação lógica precisa de um nível mais alto de registro em log do que as réplicas de leitura.

Para configurar o nível correto de log, use o parâmetro de suporte de replicação do Azure. O suporte à replicação do Azure tem três opções de configuração:

  • Off - Coloca o mínimo de informação no WAL. Essa configuração não está disponível na maioria dos servidores do Banco de Dados do Azure para PostgreSQL.
  • Réplica - Mais detalhada do que Off. Este é o nível mínimo de registro em log necessário para que as réplicas de leitura funcionem. Essa configuração é o padrão na maioria dos servidores.
  • Lógico - Mais detalhado que Replica. Este é o nível mínimo de registro em log para que a decodificação lógica funcione. As réplicas de leitura também funcionam nessa configuração.

Novas réplicas

Uma réplica de leitura é criada como um novo Banco de Dados do Azure para o servidor 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.

Configuração da réplica

Uma réplica é criada usando as mesmas configurações de computação e armazenamento da principal. Depois que uma réplica é criada, várias configurações podem ser alteradas, incluindo o período de retenção de armazenamento e backup.

As regras de firewall, as regras de rede virtual e as configurações de parâmetros não são herdadas do servidor primário para a réplica quando a réplica é criada ou posteriormente.

Dimensionamento

Dimensionamento de vCores ou entre uso geral e memória otimizada:

  • O PostgreSQL requer que a max_connections configuração em um servidor secundário seja maior ou igual à configuração no primário, caso contrário, o secundário não será iniciado.
  • No Banco de Dados do Azure para PostgreSQL, o máximo de conexões permitidas para cada servidor é fixado ao sku de computação, uma vez que as conexões ocupam memória. Você pode aprender mais sobre o mapeamento entre max_connections e compute skus.
  • Escalonamento: primeiro aumente a escala da computação de uma réplica e, em seguida, aumente a escala principal. Esta ordem evitará que erros violem o max_connections requisito.
  • Redução da escala: primeiro reduza a computação do primário e, em seguida, diminua a réplica. Se você tentar dimensionar a réplica abaixo da principal, haverá um erro, pois isso viola o max_connections requisito.

Armazenamento de escala:

  • Todas as réplicas têm o crescimento automático do armazenamento habilitado para evitar problemas de replicação de uma réplica com armazenamento completo. Esta definição não pode ser desativada.
  • Você também pode dimensionar manualmente o armazenamento, como faria em qualquer outro servidor

Escalão básico

Os servidores de camada básica suportam apenas a replicação da mesma região.

max_prepared_transactions

O PostgreSQL exige que o max_prepared_transactions valor do parâmetro na réplica de leitura seja maior ou igual ao valor primário, caso contrário, a réplica não será iniciada. Se você quiser alterar max_prepared_transactions na principal, primeiro altere-a nas réplicas.

Réplicas interrompidas

Se você interromper a replicação entre um servidor primário e uma réplica de leitura, a réplica será reiniciada para aplicar a alteração. A réplica interrompida torna-se um servidor autônomo que aceita leituras e gravações. O servidor autônomo não pode ser transformado em uma réplica novamente.

Servidores primários e autônomos excluídos

Quando um servidor primário é excluído, todas as suas réplicas de leitura se tornam servidores autônomos. As réplicas são reiniciadas para refletir essa mudança.

Próximos passos