Confiabilidade no Banco de Dados do Azure para PostgreSQL

O Banco de Dados do Azure para PostgreSQL é um serviço de banco de dados totalmente gerenciado projetado para fornecer controle granular e flexibilidade sobre as funções de gerenciamento de banco de dados e as configurações de configuração. O serviço fornece recursos de alta disponibilidade e recuperação de desastre com base em seus requisitos.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar o Banco de Dados do Azure para PostgreSQL resiliente a uma variedade de possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade, interrupções na região e manutenção do serviço. Ele também descreve como você pode usar backups para se recuperar de outros tipos de problemas e realça algumas informações importantes sobre o SLA (contrato de nível de serviço) do Banco de Dados do Azure para PostgreSQL.

Recomendações de implantação de produção

Para saber mais sobre como implantar o Banco de Dados do Azure para PostgreSQL para dar suporte aos requisitos de confiabilidade da solução e como a confiabilidade afeta outros aspectos de sua arquitetura, consulte as práticas recomendadas de arquitetura para o Banco de Dados do Azure para PostgreSQL no Azure Well-Architected Framework.

Visão geral da arquitetura de confiabilidade

Esta seção descreve alguns dos aspectos importantes de como o serviço funciona que são mais relevantes do ponto de vista da confiabilidade. A seção apresenta a arquitetura lógica, que inclui alguns dos recursos e recursos que você implanta e usa. Também discute a arquitetura física, que fornece detalhes sobre como o serviço funciona nos bastidores.

Arquitetura lógica

Ao trabalhar com o Banco de Dados do Azure para PostgreSQL, você implanta um servidor, que representa os recursos de computação e armazenamento necessários para dar suporte ao servidor de banco de dados. Você implanta um ou mais bancos de dados no servidor.

Os servidores podem ser implantados em várias camadas de computação: Burstable, General Purpose e Memory Optimized, cada uma delas otimizada para diferentes tipos de cargas de trabalho. Em algumas regiões do Azure, você pode implantar servidores com a Computação Confidencial do Azure.

Para obter mais informações sobre a arquitetura de serviço geral e os modelos de implantação, consulte o que é o Banco de Dados do Azure para PostgreSQL?.

Arquitetura física

• Separação de computação e armazenamento: O Banco de Dados do Azure para PostgreSQL usa uma arquitetura de separação de armazenamento e computação para dar suporte à alta disponibilidade. O mecanismo de banco de dados é executado em uma máquina virtual do Linux, enquanto os arquivos de dados são armazenados no armazenamento do Azure, que mantém três cópias síncronas com redundância local dos arquivos de banco de dados para garantir a durabilidade dos dados.

• Alta disponibilidade: Opcionalmente, você pode habilitar uma configuração de alta disponibilidade em seu servidor. Quando você habilita a configuração de alta disponibilidade, o serviço provisiona e mantém um servidor em espera quente. As alterações de dados no servidor primário são replicadas de forma síncrona para o servidor em espera para garantir a perda de dados zero durante uma falha do servidor primário.

  A arquitetura separa a camada de computação da camada de armazenamento, permitindo que o serviço lide com diferentes tipos de falhas de forma apropriada. Para maior resiliência, você pode espalhar os servidores entre zonas de disponibilidade.

  

  Um servidor em espera é implantado na mesma configuração de VM que o servidor primário, incluindo vCores, armazenamento e configurações de rede.

  Você pode alternar entre servidores executando um failover. Há dois tipos de failover: failovers forçados, que são usados quando o servidor primário falha e failovers planejados, que são usados durante algumas operações de manutenção e em outros cenários em que você precisa minimizar o tempo de inatividade do aplicativo durante um failover.

  Operações como parar, iniciar e reiniciar são executadas em servidores de banco de dados primários e em espera ao mesmo tempo. Eventos planejados, como computação em escala e armazenamento em escala, ocorrem primeiro em espera e, em seguida, no servidor primário. Atualmente, o servidor não faz failover para essas operações planejadas.

  Para obter mais informações, consulte Alta disponibilidade no Banco de Dados do Azure para PostgreSQL.

• Backups: O Banco de Dados do Azure para PostgreSQL cria automaticamente backups de servidor. Para obter mais informações, consulte Cópia de Segurança e Restauração.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

Seus aplicativos devem lidar com erros transitórios de conectividade que podem ocorrer durante a manutenção, operações de dimensionamento ou interrupções de rede. Siga estas recomendações:

• Quando seu aplicativo encontra falhas transitórias, repita a operação usando a retirada exponencial. Aumente o atraso entre novas tentativas e limite o número de tentativas. Se a operação ainda falhar após o número máximo de tentativas, trate-a como uma falha.
• Sempre que possível, use bibliotecas de cliente (também chamadas de drivers) que lidam automaticamente com novas tentativas.
• Erros transitórios que ocorrem durante operações de gravação exigem uma consideração mais cuidadosa. Considere tornar suas operações de gravação idempotentes, para que possam ser executadas com segurança várias vezes.

Para obter mais informações, consulte Tratamento de erros transitórios de conectividade no Banco de Dados do Azure para PostgreSQL.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

Você pode selecionar seu tipo de suporte de zona de disponibilidade por meio da configuração de alta disponibilidade . Habilitar a alta disponibilidade implanta um servidor em espera ao lado do servidor primário. Esse modelo de alta disponibilidade ajuda a garantir que os dados confirmados nunca sejam perdidos durante falhas. Independentemente de qual modelo de implantação de alta disponibilidade o seu servidor use, os dados são confirmados de forma síncrona no servidor primário e no servidor de espera. Se ocorrer uma interrupção no servidor primário, o servidor fará failover automaticamente para o servidor em espera.

Os arquivos de dados e os logs de gravação antecipada (WALs) são armazenados em discos gerenciados premium dentro de cada zona de disponibilidade, com armazenamento com redundância local (LRS) que automaticamente armazena três cópias dos dados dentro de cada zona.

O Banco de Dados do Azure para PostgreSQL dá suporte a dois tipos de configuração de zona de disponibilidade quando você usa alta disponibilidade:

• Alta disponibilidade com redundância de zona: A redundância de zona fornece o nível mais alto de resiliência de zona implantando um servidor primário em uma zona de disponibilidade e um servidor em espera em uma zona de disponibilidade diferente. O servidor em espera usa computação, armazenamento e configuração de rede semelhantes ao primário. A configuração com redundância de zona fornece isolamento físico de toda a pilha entre servidores primários e em espera.

  Você pode selecionar as zonas de disponibilidade para os servidores primários e em espera ou permitir que a Microsoft as escolha.

  Recomendamos implantações com redundância de zona para servidores de produção.

  

  As operações de gravação podem experimentar um pequeno aumento na latência de confirmação porque o serviço replica dados de forma síncrona para o servidor em espera. O impacto varia de acordo com a carga de trabalho, a SKU selecionada e a região.

• Alta disponibilidade zonal (mesma zona): Os servidores primários e em espera usam a mesma zona de disponibilidade. Se ocorrer uma interrupção no servidor primário, mas a zona ainda estiver íntegra, o servidor fará failover automaticamente para o servidor em espera. Uma implantação zonal oferece alta disponibilidade em uma única zona de disponibilidade. Ele protege você contra falhas em nível de nó e também ajuda a diminuir o tempo de inatividade do aplicativo em situações de inatividade planejada e não planejada. No entanto, ele não protege contra uma interrupção nessa zona.

  

  A alta disponibilidade zonal (mesma zona) só está disponível nas seguintes situações:

  • A região não dá suporte a zonas de disponibilidade. A região funciona efetivamente como uma única zona e, portanto, a única configuração de alta disponibilidade que você pode selecionar é a mesma zona.
  • Se uma região não tiver capacidade suficiente para uma implantação com redundância de zona, o serviço poderá inicialmente colocar ambos os servidores na mesma zona de disponibilidade e migrá-los automaticamente para zonas separadas quando a capacidade estiver disponível. Essa opção está disponível quando você usa o portal do Azure ou a CLI do Azure para implantar um servidor. Para obter mais informações, consulte Configurar opções comercialmente críticas (alta disponibilidade).

  Como os servidores estão na mesma zona, ele pode reduzir a latência de gravação para aplicativos que você implanta na mesma zona.

Se você configurar o servidor sem alta disponibilidade, ele será executado em um único servidor. Se esse servidor ou sua zona ficar inoperante, o servidor não estará disponível. Para obter mais informações, consulte Configurações sem zonas de disponibilidade.

Requisitos

• Suporte à região: O suporte do Banco de Dados do Azure para PostgreSQL para configurações de zona de disponibilidade difere entre as regiões do Azure. Para obter uma lista completa de regiões e os tipos de suporte à zona de disponibilidade e quaisquer considerações específicas para essa região, consulte as regiões do Azure.

• Camada de computação: A tabela a seguir lista o suporte da camada de computação para cada tipo de suporte de zona de disponibilidade:

  Tipo de preço	Zone-redundant	Zonal (mesma zona)
  Com capacidade de intermitência	Sem suporte	Supported
  Uso Geral	Supported	Supported
  Otimizado para Memória	Supported	Supported

• Camada de serviço: A redundância de zona requer camadas de Uso Geral ou Otimizado para Memória.

  Implantações zonais (da mesma zona) têm suporte em todos os tipos de preço.

Considerações

Capacidade da região: Se uma região não tiver capacidade suficiente para uma implantação com redundância de zona, o serviço poderá inicialmente colocar ambos os servidores na mesma zona de disponibilidade e migrá-los automaticamente para zonas separadas quando a capacidade estiver disponível. Essa opção está disponível quando você usa o portal do Azure ou a CLI do Azure para implantar um servidor. Para obter mais informações, consulte Configurar opções comercialmente críticas (alta disponibilidade).

Custo

Quando você habilita a alta disponibilidade, o servidor em espera é criado e cobrado na mesma taxa que o primário. A configuração da zona de disponibilidade não afeta o custo. Não há encargos para replicação de dados dentro ou entre zonas de disponibilidade. Dependendo do volume de armazenamento de backup, você também pode receber uma cobrança pelo armazenamento de backup. Para obter informações detalhadas sobre preços, consulte os preços do Banco de Dados do Azure para PostgreSQL.

Configurar o suporte à zona de disponibilidade

Para configurar o suporte à zona de disponibilidade para um servidor, defina as configurações de alta disponibilidade.

• Criar um servidor com redundância de zona: Para saber como criar um servidor com alta disponibilidade e redundância de zona habilitada, consulte Início Rápido: Criar um Banco de Dados do Azure para PostgreSQL no portal do Azure.

• Altere a configuração da zona de disponibilidade para servidores existentes: Você pode alterar a configuração da zona de disponibilidade para servidores existentes alterando as configurações de alta disponibilidade. Para obter etapas detalhadas, consulte Habilitar alta disponibilidade para servidores existentes.

  Você não pode alterar a zona usada para o servidor primário ou em espera após a criação. Você precisa recriar o servidor.

  Dica

  É uma boa ideia aguardar até que a atividade do servidor seja baixa antes de alterar a configuração de alta disponibilidade.

• Desabilitar alta disponibilidade: Desabilitar a alta disponibilidade remove o servidor em espera, de modo que o servidor não seja resiliente a interrupções em sua zona de disponibilidade. Para obter mais informações, consulte Desabilitar alta disponibilidade.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando os servidores são configurados com alta disponibilidade e suporte de zona de disponibilidade, e todas as zonas de disponibilidade estejam operacionais.

• Operação entre zonas: Os aplicativos cliente PostgreSQL conectam-se ao servidor primário usando o nome do servidor de banco de dados. O Banco de Dados do Azure para PostgreSQL usa uma configuração ativa/passiva em que todas as conexões e consultas de banco de dados são tratadas pelo servidor primário na zona de disponibilidade primária. O servidor em espera não atende ao tráfego do cliente durante operações normais.

• Replicação de dados entre zonas: As alterações nos dados são replicadas de forma síncrona entre os servidores primário e em espera. As transações não são consideradas concluídas até que o servidor primário e em espera confirmem a gravação.

  Gravação de transações acionada pelo aplicativo escreve e confirma o primeiro log no WAL no servidor primário. O servidor primário transmite esses logs para o servidor em espera usando o protocolo de streaming postgres. Quando o armazenamento do servidor de espera guarda os logs, o servidor primário confirma a conclusão do registro. O aplicativo confirma sua transação somente após essa confirmação. Esse processo de confirmação não aguarda que os logs sejam aplicados no servidor em espera.

  Os efeitos da replicação são diferentes dependendo da configuração da zona de disponibilidade que o servidor usa:

  • Com redundância de zona: Como os servidores estão em zonas separadas, essa abordagem garante zero perda de dados durante uma falha de zona. Essa situação também é às vezes chamada de alcançar um RPO (objetivo de ponto de recuperação) de zero para falhas de zona.

    No entanto, a replicação entre zonas pode introduzir uma pequena quantidade de latência extra. O impacto da latência depende do aplicativo e, para a maioria dos aplicativos, ele é insignificante.

  • Zonal: como ambos os servidores estão na mesma zona, nenhum tráfego é replicado entre zonas.

  Observação

  O sistema replica dados de log em tempo real para o servidor em espera. Todos os erros de usuário no servidor primário, como uma queda acidental de uma tabela ou atualizações de dados incorretas, são replicados para o servidor em espera. Portanto, você não pode usar o modo de espera para se recuperar desses tipos de erros e deve executar uma restauração pontual do backup. Para obter mais informações, consulte Cópia de Segurança e Restauração.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando os servidores são configurados com alta disponibilidade e suporte de zona de disponibilidade e ocorre uma interrupção na zona de disponibilidade.

• Detecção e resposta: O Azure verifica periodicamente a integridade dos servidores primários e em espera. Após vários pings, se o monitoramento de integridade detectar que um servidor primário não é acessível, o serviço inicia um failover automático para o servidor em espera. O algoritmo de monitoramento de saúde usa vários pontos de dados para evitar situações de falso positivo.

  No caso de uma falha de zona, o comportamento é diferente dependendo da configuração da zona de disponibilidade que o servidor usa:

  • Com redundância de zona: O Banco de Dados do Azure para PostgreSQL detecta automaticamente falhas em zonas de disponibilidade. Para exibir os possíveis tipos de status de alta disponibilidade, consulte os tipos de status de alta disponibilidade. Quando uma zona falha, o Azure inicia um failover forçado para o servidor em espera sem exigir que você tome medidas.

  • Zonal: Se a zona de disponibilidade que hospeda um servidor zonal ficar indisponível, os servidores primário e em espera não estarão disponíveis. Nesse cenário, o serviço não fornece failover automático. Você é responsável por detectar a interrupção da zona e executar ações de recuperação, como restaurar backups com redundância de zona para um servidor separado em outra zona ou região de disponibilidade.

• Notificação: O monitoramento de status de integridade de alta disponibilidade (HA) no Banco de Dados do Azure para PostgreSQL fornece uma visão geral contínua da integridade e da preparação das instâncias habilitadas para HA. O recurso de monitoramento é criado com base no Azure Resource Health e pode detectar e alertar sobre quaisquer problemas que possam afetar a preparação de failover do banco de dados ou a disponibilidade geral. Avalie métricas essenciais, como o status de conexão, o estado de failover e a integridade da replicação de dados, para possibilitar a solução de problemas de forma proativa e ajudar a manter o tempo de atividade e o desempenho do seu banco de dados.

  Para obter um guia detalhado sobre como configurar e interpretar status de integridade de HA, consulte o monitoramento de status de integridade de alta disponibilidade (HA) para o Banco de Dados do Azure para PostgreSQL.

• Solicitações ativas: Quando uma zona de disponibilidade fica indisponível, qualquer solicitação em andamento para servidores na zona afetada pode ser encerrada. Os aplicativos devem repetir essas solicitações. Se seus clientes lidarem adequadamente com falhas transitórias tentando novamente após um curto período de tempo, eles normalmente evitam um impacto significativo.

• Perda de dados esperada: A quantidade de perda de dados depende da configuração da zona de disponibilidade usada pelo servidor.

  • Com redundância de zona: Espera-se que não haja perda de dados durante o failover de zona devido à replicação síncrona entre o servidor primário e o servidor de espera em diferentes zonas.

  • Zonal: Os dados em servidores na zona afetada não estão disponíveis até que a zona se recupere.

• Tempo de inatividade esperado: A quantidade de tempo de inatividade depende da configuração da zona de disponibilidade usada pelo servidor.

  • Com redundância de zona: O failover normalmente é concluído dentro de 60 a 120 segundos. Se seus clientes lidarem adequadamente com falhas transitórias tentando novamente após um curto período de tempo, eles normalmente evitam um impacto significativo.

  • Zonal: Os servidores em uma zona afetada ficam indisponíveis até que a zona de disponibilidade se recupere.

• Redistribuição: O comportamento de redirecionamento de tráfego depende da configuração da zona de disponibilidade usada pelo servidor.

  • Com redundância de zona: Após o failover, o servidor em espera antigo se torna o novo primário e começa a aceitar novas conexões. O Azure estabelece automaticamente um novo servidor em espera na zona primária original após a recuperação. Para obter detalhes completos, consulte Falha forçada.

  • Zonal: Quando uma zona não está disponível, o servidor não está disponível. Se você tiver um servidor separado pré-criado em outra zona ou região de disponibilidade, será responsável por redirecionar o tráfego para esse servidor.

Recuperação de zona

O comportamento de recuperação de zona depende da configuração da zona de disponibilidade usada pelo servidor.

• Com redundância de zona: Quando a zona de disponibilidade é recuperada, o Banco de Dados do Azure para PostgreSQL recria automaticamente o servidor em espera na zona recuperada e o sincroniza com o primário atual. Depois, a zona recuperada serve como local de espera. O serviço não move automaticamente a função primária de volta para a zona original para evitar interrupções desnecessárias. Você pode iniciar manualmente um failover planejado se quiser retornar o servidor primário para a zona original.

• Zonal: Depois que a integridade da zona for verificada, os servidores na zona estarão disponíveis novamente. Você é responsável por todos os procedimentos de recuperação de zona e sincronização de dados que suas cargas de trabalho exigem.

Testar falhas em zonas

As opções para testar falhas de zona dependem da configuração da zona de disponibilidade usada pela sua instância.

• Com redundância de zona: Você pode testar a resiliência do aplicativo ao failover iniciando um failover forçado. Um failover forçado permite simular um cenário de interrupção não planejado durante a execução da carga de trabalho e observar o tempo de inatividade do aplicativo. É recomendável executar simulações em um ambiente de não produção ou em um momento tranquilo. Para obter mais informações, consulte Iniciar um failover forçado.

• Zonal: Embora não seja possível simular uma interrupção de zona completa, você pode simular que o servidor está indisponível de maneira semelhante ao que acontece durante uma interrupção de zona. Para obter mais informações, consulte Parar a computação de um servidor.

Resiliência a falhas em toda a região

O Banco de Dados do Azure para PostgreSQL dá suporte a réplicas de leitura entre regiões, que você pode usar para manter uma cópia sincronizada do banco de dados em uma região diferente para uma recuperação mais rápida.

Você também pode usar backups com redundância geográfica, em regiões com suporte, para fornecer recuperação entre regiões. No entanto, os backups normalmente envolvem mais tempo de inatividade e perda de dados do que replicação. Para obter mais informações, consulte Cópia de Segurança e Restauração.

Réplicas de leitura entre regiões

Você pode implantar réplicas de leitura para proteger seus bancos de dados contra falhas no nível da região. Cada réplica de leitura é um servidor separado do Banco de Dados do Azure para PostgreSQL. Quando você coloca uma réplica de leitura em uma segunda região do Azure, seu servidor de banco de dados pode garantir resiliência a problemas que afetem toda a região. Você pode implantar até cinco réplicas de leitura, que podem opcionalmente estar em diferentes regiões do Azure. A tecnologia de replicação física do PostgreSQL atualiza as réplicas de leitura de forma assíncrona, e elas podem ficar defasadas em relação ao primário. Réplicas de leitura entre regiões podem, opcionalmente, suportar cargas de trabalho somente leitura para reduzir a latência de aplicativos distribuídos globalmente ou para aliviar o tráfego de leitura do servidor primário. Para obter mais informações sobre recursos e considerações de réplica de leitura, confira Réplicas de leitura.

Os pontos de extremidade virtuais fornecem pontos de extremidade de leitura e gravação e somente leitura e redirecionam automaticamente o tráfego quando uma réplica é promovida, o que ajuda a minimizar o tempo de inatividade durante eventos de failover. É altamente recomendável usar pontos de extremidade virtuais com réplicas de leitura inter-regionais para melhorar a resiliência da aplicação. Para obter mais informações, consulte endpoints virtuais para réplicas de leitura no Banco de Dados do Azure para PostgreSQL.

Se a região primária falhar, você poderá acionar uma promoção para que sua réplica secundária se torne a primária. Há diferentes tipos de failover que você pode acionar dependendo como usar réplicas de leitura. Ao usar réplicas de leitura para fornecer resiliência a falhas regionais, você normalmente usa a abordagem promover para o servidor primário, que atualiza o seu ponto de extremidade virtual. Durante uma interrupção de região, você precisa executar uma promoção forçada, o que pode resultar em alguma perda de dados para quaisquer dados não duplicados. Em cenários planejados em que a região primária está íntegra, você pode optar por executar uma promoção planejada para evitar a perda de dados. Para obter mais informações, consulte Promover réplicas de leitura no Banco de Dados do Azure para PostgreSQL.

Observação

Esta seção resume algumas das informações importantes sobre como as réplicas de leitura podem dar suporte à resiliência a falhas regionais. Você também pode usar réplicas de leitura para melhorar o desempenho e dar suporte a bases de usuários distribuídas geograficamente em grande escala. Para obter mais informações, consulte Réplicas de Leitura.

Requisitos

• Suporte à região: Você pode criar réplicas de leitura entre regiões em qualquer região que dê suporte ao Banco de Dados do Azure para PostgreSQL. Você não está limitado a regiões emparelhadas do Azure.

• Camadas de computação: As camadas de computação com Uso Geral e Otimizado para Memória dão suporte a réplicas de leitura. A camada Intermitível não dá suporte a réplicas de leitura.

Considerações

• Diferenças de configuração: As réplicas de leitura podem não herdar todas as configurações do servidor primário. Planeje definir as configurações necessárias após o failover. O servidor primário e as réplicas devem ser simétricos, o que significa que elas precisam ter as mesmas camadas, tamanhos de armazenamento e valores para algumas configurações. Durante falhas de região, o requisito de servidor simétrico pode ser dispensado para promoções forçadas, mas é uma boa prática ter uma configuração simétrica sempre que possível para evitar problemas inesperados. Para obter mais informações, consulte Gerenciamento de configuração.

• Monitorando o atraso de replicação: O processo de replicação assíncrona requer um atraso de replicação, que pode variar dependendo de vários fatores. Quando o atraso de replicação é muito alto, o servidor pode ter problemas. É importante monitorar o atraso de replicação para que você possa atenuar os problemas antes que eles aumentem. Para obter mais informações, consulte a replicação do Monitor.

• Alta disponibilidade: As réplicas de leitura não podem ter alta disponibilidade ativada e, quando são promovidas, elas também não têm alta disponibilidade. Você é responsável por configurar a alta disponibilidade depois de promover uma réplica.

Para obter considerações adicionais que se aplicam ao processo de promoção, veja Promover réplicas de leitura no Banco de Dados do Azure para PostgreSQL – Considerações.

Custo

As réplicas de leitura incorrem em custos de computação e armazenamento, bem como custos de transferência de dados entre regiões para replicação. Para obter informações detalhadas sobre preços, consulte preços do Banco de Dados do Azure para PostgreSQL e preços de largura de banda.

Configurar o suporte a várias regiões

• Crie uma réplica de leitura: Para saber como criar uma réplica de leitura, consulte Criar uma réplica de leitura. As réplicas podem ser configuradas após a criação do servidor primário, desde que o servidor primário esteja em execução e acessível.

  Para criar um ponto de extremidade virtual, consulte Criar pontos de extremidade virtuais.

• Excluir uma réplica de leitura: Para saber como excluir uma réplica de leitura, consulte Excluir uma réplica de leitura.

Comportamento quando todas as regiões estão saudáveis

Esta seção descreve o que esperar quando o servidor está configurado com uma réplica de leitura em outra região e um ponto de extremidade virtual, e todas as regiões estão operacionais:

• Roteamento de tráfego entre regiões: Em operações normais, o ponto de extremidade virtual direciona o tráfego para o ponto de extremidade de leitura/gravação para o servidor primário na região primária. Se você também usar o ponto de extremidade somente leitura do virtual endpoint, ele direcionará o tráfego para qualquer réplica que você configurar.

• Replicação de dados entre regiões: As réplicas de leitura entre regiões usam replicação assíncrona para minimizar o impacto no desempenho do servidor primário. A quantidade de retardo de replicação depende de vários fatores, incluindo a carga de gravação e a latência entre o servidor primário e as réplicas. O atraso de replicação normalmente é de pelo menos vários minutos, mas pode ser muito mais longo. Para obter mais informações, consulte a replicação do Monitor.

Comportamento durante uma falha de região

Esta seção descreve o que esperar quando seu servidor está configurado com uma réplica de leitura em outra região e um ponto de extremidade virtual, e ocorre uma interrupção na região primária:

• Detecção e resposta: Você é responsável por detectar uma interrupção na região primária e promover manualmente uma réplica de leitura para se tornar o novo servidor primário. Durante uma interrupção de região, você deve executar uma promoção forçada, o que resulta na perda de quaisquer dados não replicados.

  Importante

  Você é responsável por disparar a promoção. O Azure não promove réplicas de leitura automaticamente, mesmo que haja falha em uma região.

  Para obter etapas detalhadas para iniciar uma promoção, consulte Alternar a réplica de leitura para primária.

• Notificação: A Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto, você pode usar Azure Service Health para entender a integridade geral do serviço, incluindo eventuais falhas na região, e pode configurar alertas Service Health para notificar você sobre problemas.

• Solicitações ativas: Todas as conexões ativas com a região primária são descartadas. Os aplicativos precisam tentar novamente fazer conexões com a réplica promovida após a conclusão do processo de promoção.

• Perda de dados esperada: Durante uma interrupção de região, você deve executar uma promoção forçada, o que resulta na perda permanente de quaisquer dados não replicados.

  A quantidade de perda de dados depende do atraso de replicação no momento da interrupção. O atraso de replicação normalmente é de pelo menos vários minutos, mas pode ser muito mais longo. Para obter mais informações, consulte a replicação do Monitor.

• Tempo de inatividade esperado: A promoção forçada normalmente é concluída dentro de 1 a 3 minutos após ser disparada. Os aplicativos também podem precisar se reconectar ao endpoint correto. Os endpoints virtuais são atualizados como parte do processo de promoção forçada. Os aplicativos devem respeitar o tempo de vida (TTL) dos registros DNS do endpoint para garantir que se reconectem rapidamente à réplica correta após a conclusão da promoção.

• Redirecionamento de tráfego: O ponto de extremidade virtual do servidor redireciona automaticamente o tráfego do aplicativo para a nova réplica primária.

  Observação

  Depois que uma réplica de leitura é promovida para ser o servidor primário, ela não tem a configuração de alta disponibilidade habilitada. Você precisa habilitar a configuração de alta disponibilidade manualmente ou adicioná-la aos seus próprios processos de automação.

Recuperação de região

Quando você usa pontos de extremidade virtuais, após a recuperação da região primária, o servidor primário antigo é configurado automaticamente como uma réplica de leitura. Você pode executar outra promoção para retornar as operações primárias para sua região primária preferida.

Teste de falhas na região

Teste regularmente os procedimentos de promoção de réplica de leitura para garantir que seus processos sejam válidos e que os recursos atendam aos seus requisitos de RTO e RPO.

Você pode promover uma réplica de leitura para se tornar o servidor primário a qualquer momento, mesmo quando todas as regiões estiverem funcionando normalmente. Para testes

• Você pode executar testes de promoção forçada. Recomendamos que você execute esses testes em um ambiente de não produção, pois isso pode resultar em perda de dados. O teste de promoção forçada ajuda a simular o comportamento observado durante uma falha de região.
• Para cenários de manutenção planejada ou teste em que você deseja evitar a perda de dados, use uma promoção planejada. Lembre-se de que a promoção planejada segue um processo diferente da promoção durante uma interrupção de região.

Para obter instruções passo a passo, consulte Alternar a réplica de leitura para primária.

Como parte de sua estratégia de recuperação de desastre, execute regularmente exercícios de recuperação completa. Essas análises devem incluir validação de dados, teste de funcionalidade de aplicativo e procedimentos de reversão documentados.

Backup e restauração

O Banco de Dados do Azure para PostgreSQL executa automaticamente backups que fornecem recursos de recuperação pontual e ajudam a protegê-lo contra corrupção acidental e exclusão de dados. Os backups são totalmente gerenciados pela Microsoft, não interrompem a disponibilidade do servidor e incluem backups completos e backups de log de transações.

• Armazenamento de backup: Se o servidor estiver configurado com alta disponibilidade com redundância de zona, os backups serão armazenados no ZRS (armazenamento com redundância de zona). Para servidores configurados sem alta disponibilidade ou com alta disponibilidade zonal (zona única), os backups são armazenados no LRS (armazenamento com redundância local).

  Nas regiões do Azure com pares, você pode configurar o armazenamento de backup GRS (com redundância geográfica) no momento da criação do servidor para replicar backups para a região emparelhada do Azure para proteção adicional contra falhas na região. Os backups são replicados de forma assíncrona.

  O período de retenção de backup padrão é de 7 dias, com a opção de estender a retenção até 35 dias. Você também pode usar o Backup do Azure para armazenamento de longo prazo de backups manuais por até 10 anos. Todos os backups são criptografados.

• Restaurar: A recuperação pontual permite que você restaure seu banco de dados a qualquer momento dentro do período de retenção de backup. O processo de restauração cria um novo servidor de banco de dados com um novo nome de servidor fornecido pelo usuário, do qual você pode usar as-is ou copiar dados.

  Ao restaurar um backup com redundância geográfica, você cria um novo servidor na região emparelhada.

  Essa funcionalidade é útil para recuperar-se de modificações acidentais de dados, erros de aplicativo ou cenários de teste.

Para a maioria das soluções, você não deve depender exclusivamente de backups. Em vez disso, use as outras funcionalidades descritas neste guia para dar suporte aos seus requisitos de resiliência. No entanto, os backups protegem contra alguns riscos que outras abordagens não protegem. Para obter mais informações, consulte O que são redundância, replicação e backup?.

Para obter mais informações, consulte Backup e restauração no Banco de Dados do Azure para PostgreSQL.

Resiliência à manutenção do serviço

O Banco de Dados do Azure para PostgreSQL lida automaticamente com tarefas de manutenção críticas, incluindo a aplicação de patch do hardware subjacente, do sistema operacional e do mecanismo de banco de dados. O serviço inclui atualizações de segurança, atualizações de software e atualizações de versão secundárias como parte da manutenção planejada.

Para garantir que o servidor permaneça disponível durante as janelas de manutenção, siga estas recomendações:

• Habilitar alta disponibilidade: Durante a manutenção, o servidor pode precisar ser reiniciado como parte do processo de atualização. Se você tiver alta disponibilidade habilitada, as operações de manutenção normalmente usam atualizações sem interrupção para minimizar o tempo de inatividade. As atividades de manutenção periódica, como atualizações de versão menor, ocorrem primeiro na réplica em espera. Para reduzir o tempo de inatividade, a instância em espera é promovida como primária para que as cargas de trabalho continuem enquanto as tarefas de manutenção são aplicadas no nó restante. Esse sequenciamento se aplica, quer o servidor use redundância de zona ou alta disponibilidade zonal.

  Para servidores sem alta disponibilidade habilitada, espere um breve tempo de inatividade durante as operações de manutenção. Com alta disponibilidade habilitada, as operações de manutenção normalmente são concluídas com tempo mínimo ou sem tempo de inatividade.

• Configurar janelas de manutenção personalizadas: Você pode configurar o agendamento de manutenção para ser gerenciado pelo sistema ou definir uma janela de manutenção personalizada para minimizar o impacto em suas operações de negócios. Agende a manutenção durante períodos de baixa atividade para minimizar o impacto nos negócios. Para obter mais informações, consulte Agendar manutenção.

• Implementar lógica de repetição: Verifique se seus aplicativos podem lidar com breves interrupções de conectividade que podem ocorrer durante as reinicializações de manutenção. Para tornar seus aplicativos resilientes a esses tipos de problemas, consulte As diretrizes de resiliência a falhas transitórias .

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços de Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

O Banco de Dados do Azure para PostgreSQL fornece SLAs de disponibilidade diferentes com base na configuração do servidor:

• Servidores configurados com alta disponibilidade redundante por zona.
• Servidores configurados com alta disponibilidade zonal (zona única).
• Servidores configurados sem alta disponibilidade.

Conteúdo relacionado

• Confiabilidade do Azure
• Práticas recomendadas de arquitetura para o Banco de Dados do Azure para PostgreSQL
• Visão geral da continuidade dos negócios com o Banco de Dados do Azure para PostgreSQL
• Recuperação de desastre geográfico no Banco de Dados do Azure para PostgreSQL
• Acelerador de Solução de Resiliência do Banco de Dados do Azure para PostgreSQL – scripts do Terraform para implementar muitos dos princípios de resiliência e recuperabilidade descritos neste artigo.