Réplicas de leitura no Banco 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á prestes a ser desativado. É altamente recomendável atualizar para o Banco de Dados do Azure para PostgreSQL – Servidor Flexível. Para obter mais informações sobre a migração para o Banco de Dados do Azure para PostgreSQL – Servidor Flexível, veja O que está acontecendo com o Banco de Dados do Azure para PostgreSQL Servidor único?.

O recurso de réplica de leitura permite replicar dados de um servidor de Banco de Dados do Azure para 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 a partir do servidor primário para até cinco réplicas.

As réplicas são novos servidores que você gerencia de modo similar ao Banco de Dados do Azure para PostgreSQL normal. 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 é ter cargas de trabalho analíticas e de BI usando 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

O recurso destina-se a cenários em que o atraso é aceitável e a descarregamento de consultas. Não é destinado a cenários de replicação síncrona em que os dados de réplica devem estar atualizados. Haverá um atraso mensurável entre o primário e a réplica. Isso pode ser em minutos ou até mesmo em horas, dependendo da carga de trabalho e da latência entre o primário e a réplica. 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 atraso de replicação pode continuar a aumentar e nunca alcançar o primário. Isso também pode aumentar o uso de armazenamento no primário, pois os arquivos WAL não são excluídos até que sejam recebidos na réplica. Se essa situação persistir, excluir e recriar a réplica de leitura após a conclusão das cargas de trabalho com uso intensivo de gravação é a opção de 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 seu aplicativo, monitore o atraso na réplica para um ciclo de carga de trabalho completo do aplicativo em 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.

Observação

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

Replicação entre regiões

Você pode criar uma réplica de leitura em uma região diferente do seu servidor primário. A replicação entre regiões pode ser útil para cenários como o planejamento de recuperação de desastres ou para trazer dados mais próximos dos seus usuários.

Observação

Os servidores de camada básica oferecem suporte apenas à replicação de mesma região.

Você pode ter um servidor primário em qualquer região do Banco 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 figura abaixo mostra quais regiões de réplica estão disponíveis dependendo da sua região primária.

Regiões de réplica de leitura

Regiões de réplica universal

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

Leste da Austrália, Sudeste da Austrália, Sul do Brasil, Canadá Central, Leste do Canadá, EUA Central, Leste da Ásia, Leste dos EUA, Leste dos EUA 2, Leste do Japão, Oeste do Japão, Coreia Central, Sul da Coreia, Centro-Norte dos EUA, Norte da Europa, Centro-Sul dos EUA, Sudeste da Ásia, Sul do Reino Unido, Oeste do Reino Unido, Oeste da Europa, 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, você pode encontrar essa informação no artigo Regiões emparelhadas do Azure.

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

Limitações a serem consideradas:

  • Pares unidirecionais: Algumas regiões do Azure são emparelhadas em uma direção apenas. Essas regiões incluem Oeste da Índia e Sul do Brasil. Isso significa que um servidor primário no Oeste da Índia pode criar uma réplica no Sul da Índia. Entretanto, um servidor primário no Sul da Índia não pode criar uma réplica no Oeste da Índia. Isso ocorre porque a região secundária do Oeste da Índia é o Sul da Índia, mas a região secundária do Sul da Índia não é o Oeste da Índia.

Criar uma réplica

Quando você inicia o fluxo de trabalho de criação de réplica, um servidor do Banco de Dados do Azure para PostgreSQL é criado. O novo servidor é preenchido com os dados que estavam no servidor primário. A hora de criação depende da quantidade de dados no primário e do tempo decorrido desde o último backup completo semanal. O tempo pode variar de alguns minutos a várias horas.

Cada réplica é habilitada para armazenamento de aumento automático. O recurso de aumento automático permite que a réplica acompanhe os dados replicados e evita uma interrupção na replicação causada por erros de falta de armazenamento.

O recurso de réplica de leitura usa a replicação física do PostgreSQL, e não a replicação lógica. A replicação de streaming usando slots de replicação é o modo de operação padrão. Quando necessário, o envio de logs é usado para recuperar o atraso.

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

Se o servidor PostgreSQL de origem estiver criptografado com chaves gerenciadas pelo cliente, consulte a documentação para obter considerações adicionais.

Conectar-se a uma réplica

Quando você cria uma réplica, ela não herda as regras de firewall nem o ponto de extremidade de serviço de rede virtual do servidor primário. Essas regras precisam ser configuradas independentemente da réplica.

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

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

Monitorar 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 Atraso máximo entre réplicas e Atraso da réplica. 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 Atraso máximo entre réplicas mostra o atraso em bytes entre o primário e a réplica com o 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 o primário 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 Atraso da réplica mostra o tempo decorrido desde a última transação reproduzida. Se não houver nenhuma transação ocorrendo no servidor primário, a métrica refletirá esse tempo decorrido. Essa métrica é aplicável e está disponível somente para servidores de réplica. O Atraso da réplica é calculado a partir da exibição de pg_stat_wal_receiver:

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

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

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

Interromper a replicação/promover a réplica

Você pode interromper a replicação entre um primário e uma réplica a qualquer momento. A ação de interrupção faz com que a réplica reinicie e promove a réplica como um servidor independente e autônomo para leitura e gravação. Os dados no servidor autônomo são os dados que estavam disponíveis no servidor de réplica no momento em que a replicação foi interrompida. Todas as atualizações subsequentes no primário não são propagadas para a réplica. No entanto, o servidor de réplica pode ter logs acumulados 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.

Observação

No momento 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 junto com a promoção da operação de réplica na mesma solicitação. Se você quiser fazer isso, primeiro deverá 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 o atraso da replicação para garantir que a réplica tenha todos os dados de que você precisa.
  • Como a réplica de leitura precisa aplicar todos os logs pendentes antes que possa se tornar um servidor autônomo, o RTO pode ser maior para cargas de trabalho pesadas de gravação quando a replicação de interrupção acontece, pois pode haver um atraso significativo na réplica. 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 a servidor primário, não poderá estabelecer a replicação de volta para o servidor primário antigo. Se você quiser voltar para a região primária antiga, poderá estabelecer um novo servidor de réplica com um novo nome (ou) excluir o primário antigo e criar uma réplica usando o antigo nome primário.
  • Se você tiver várias réplicas de leitura e promover uma delas a servidor primário, os outros servidores de réplica ainda estarão conectados ao antigo primário. Pode ser necessário recriar réplicas a partir do novo servidor promovido.

Quando você interrompe a replicação, a réplica perde todos os links para o seu primário 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, não ocorre o failover automático 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 de réplica. Em casos típicos com carga de trabalho de gravação nominal, espera-se um atraso da réplica de alguns segundos a alguns minutos. No entanto, nos casos em que o primário executa uma carga de trabalho muito pesada e com uso intensivo de gravação e a réplica não está alcançando com rapidez suficiente, o atraso pode ser muito maior. Você pode acompanhar o atraso de replicação de cada réplica usando a métrica Atraso da réplica. Essa métrica mostra o tempo decorrido desde a última transação reproduzida na réplica. Recomendamos que você identifique o atraso médio, observando o atraso da réplica ao longo de um período de tempo. Você pode definir um alerta sobre o atraso da réplica, de modo que, se ficar fora de sua faixa esperada, você seja notificado a agir.

Dica

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

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

  1. Pare a replicação para a réplica
    Essa etapa é necessária para fazer com que o servidor de réplica se torne um servidor autônomo e seja capaz de aceitar gravações. Como parte desse processo, o servidor de réplica será reiniciado e desconectado do primário. Depois que você inicia a interrupção da replicação, o processo de back-end normalmente leva alguns minutos para aplicar os logs residuais que ainda não foram aplicados e abrir o banco de dados como um servidor de leitura e gravação. Consulte a seção Parar replicação deste artigo para entender as implicações dessa ação.

  2. Direcione seu aplicativo para a réplica (antiga)
    Cada servidor tem uma cadeia de conexão única. Atualize a cadeia de conexão do aplicativo para direcionar para a réplica (antiga) em vez do primário.

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

Recuperação de desastre

Quando há um grande evento de desastre, como falhas regionais ou no nível de zona de disponibilidade, você pode executar a operação de recuperação de desastre promovendo a réplica de leitura. No portal de interface do usuário, navegue até o servidor de réplica de leitura. Em seguida, selecione a guia de replicação e interrompa a réplica para promovê-la a servidor independente. Como alternativa, você pode usar a CLI do Azure para interromper 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 WAL (Log de gravação antecipada) do Postgres para obter informações. Esses dois recursos precisam de diferentes níveis de registro em log 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 certo de registro em 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:

  • Desativada - Coloca o mínimo de informações 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 Desativada. Esse é 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ógica - Mais detalhada do que Réplica. 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 servidor de Banco de Dados do Azure para PostgreSQL. Um servidor existente não pode se tornar uma réplica. Você não pode 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 que o primário. Depois que uma réplica é criada, várias configurações podem ser alteradas, incluindo o período de retenção do armazenamento e do backup.

Regras de firewall, regras de rede virtual e 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.

Scaling

Dimensionar vCores ou entre Uso geral e Otimizado para memória:

  • 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 permitido de conexões para cada servidor é corrigido para a SKU de computação, já que as conexões ocupam memória. Você pode saber mais sobre o mapeamento entre Máximo de conexões e SKUs de computação.
  • Escalar verticalmente: primeiro escale verticalmente a computação de uma réplica e, em seguida, escale verticalmente o primário. Essa ordem impedirá que erros violem o requisito max_connections.
  • Reduzir verticalmente: primeiro reduza verticalmente a computação do primário e, em seguida, reduza verticalmente a réplica. Se você tentar dimensionar a réplica abaixo do primário, ocorrerá um erro, pois isso viola o requisito max_connections.

Armazenamento em escala:

  • Todas as réplicas têm o aumento automático de armazenamento habilitado para evitar problemas de replicação em uma réplica de armazenamento completo. Essa configuração não pode ser desabilitada.
  • Você também pode escalar verticalmente o armazenamento manualmente, como faria em qualquer outro servidor

Camada básica

Os servidores de camada básica oferecem suporte apenas à replicação de mesma região.

max_prepared_transactions

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

Réplicas paradas

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 se tornará um servidor autônomo que aceita leituras e gravações. O servidor autônomo não pode se tornar uma réplica novamente.

Servidores primário e autônomo 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 alteração.

Próximas etapas