Confiabilidade no Azure Database para PostgreSQL

O Base de Dados do Azure para PostgreSQL é um serviço de base de dados totalmente gerido que lhe oferece controlo granular e flexibilidade sobre as funções de gestão da base de dados e definições de configuração. O serviço oferece capacidades de alta disponibilidade e recuperação de desastres com base nas suas necessidades.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer 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 Azure Database Database for PostgreSQL resiliente a vários potenciais cortes e problemas, incluindo falhas transitórias, interrupções em zonas de disponibilidade, interrupções regionais e manutenção de serviços. Descreve também como pode usar backups para recuperar de outros tipos de problemas e destaca informações essenciais sobre o acordo de nível de serviço (SLA) do Base de Dados do Azure para PostgreSQL.

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

Para aprender como implementar Base de Dados do Azure para PostgreSQL para suportar os requisitos de fiabilidade da sua solução e como a fiabilidade afeta outros aspetos da sua arquitetura, consulte as melhores práticas de arquitetura para Base de Dados do Azure para PostgreSQL no Azure Well-Architected Framework.

Visão geral da arquitetura de confiabilidade

Esta secção descreve alguns dos aspetos importantes do funcionamento do serviço que são mais relevantes do ponto de vista da fiabilidade. A secção apresenta a arquitetura lógica, que inclui alguns dos recursos e funcionalidades que implementa e utiliza. Também discute a arquitetura física, detalhando como o serviço funciona nos bastidores.

Arquitetura lógica

Quando trabalha com o Base de Dados do Azure para PostgreSQL, implementa um servidor, que representa os recursos de computação e armazenamento necessários para suportar as bases de dados que implementa no servidor.

Pode implementar servidores em múltiplos níveis de computação: Burstable, General Purpose e Memory Optimized. Cada nível está otimizado para diferentes tipos de cargas de trabalho. Em algumas regiões Azure, pode implementar servidores com Azure Confidential Computing.

Para mais informações sobre a arquitetura geral de serviços e os modelos de implementação, consulte a visão geral do Base de Dados do Azure para PostgreSQL.

Arquitetura física

  • Separação de computação e armazenamento: O Azure Database para PostgreSQL utiliza uma arquitetura de separação de computação e armazenamento para suportar alta disponibilidade. O motor de base de dados corre numa máquina virtual Linux (VM), enquanto o Armazenamento do Azure guarda os ficheiros de dados e mantém três cópias locais redundantes e síncronas dos ficheiros da base de dados para garantir a durabilidade dos dados.

  • Alta disponibilidade: Pode ativar uma configuração de alta disponibilidade no seu servidor. Quando ativas a configuração de alta disponibilidade, o serviço fornece e mantém um servidor de espera quente. O servidor primário replica de forma síncrona as alterações aos dados para o servidor de reserva, para garantir zero perda de dados em caso de falha do servidor primário.

    A arquitetura separa a camada de computação da camada de armazenamento, para que o serviço possa lidar adequadamente com diferentes tipos de falhas. Para maior resiliência, pode espalhar os servidores por zonas de disponibilidade.

    Diagrama mostrando a arquitetura de alta disponibilidade, com servidor primário e servidor de espera.

    Um servidor de espera é implementado na mesma configuração de VM que o servidor principal, incluindo vCores, armazenamento e definições de rede.

    Pode alternar entre servidores realizando um failover. Existem dois tipos de failover: failovers forçados, que são usados quando o servidor principal falha, e failovers planeados, que são usados durante algumas operações de manutenção e noutros cenários onde é necessário minimizar o tempo de inatividade da aplicação durante um failover.

    Quando realiza operações como parar, iniciar e reiniciar, elas ocorrem simultaneamente nos servidores de base de dados primários e de espera. Eventos planeados, como escalonamento de computação e escalabilidade de armazenamento, acontecem primeiro no standby e depois no servidor principal. Atualmente, o servidor não faz failover para estas operações planeadas.

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

  • Cópias de Segurança: O Azure Database para PostgreSQL cria automaticamente backups do servidor. Para 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 em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.

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

As suas aplicações devem lidar com erros transitórios de conectividade que podem ocorrer durante manutenção, operações de escalabilidade ou interrupções de rede. Siga estas recomendações:

  • Quando a sua aplicação encontrar falhas transitórias, tente novamente a operação usando o backoff exponencial. Aumentar o atraso entre as tentativas e limitar o número de tentativas. Se a operação ainda falhar após o máximo de tentativas, trate-a como falha.

  • Sempre que possível, utilize bibliotecas de cliente (também chamadas de drivers) que façam automaticamente repetições.

  • Erros transitórios que ocorrem durante operações de escrita exigem uma consideração mais cuidadosa. Considere tornar as suas operações de escrita idempotentes, para que possam ser executadas em segurança várias vezes.

Para mais informações, consulte Gestão de erros de conectividade transitória na Base de Dados do Azure para PostgreSQL.

Resiliência a falhas na zona de disponibilidade

Zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

Selecione o seu tipo de suporte de zona de disponibilidade através da configuração de alta disponibilidade. Quando ativa a alta disponibilidade, o serviço implementa um servidor de espera ao lado do seu servidor principal. Este modelo de alta disponibilidade ajuda a garantir que os dados comprometidos nunca se percam durante falhas. Seja qual for o modelo de implementação de alta disponibilidade utilizado pelo seu servidor, este grava os dados de forma síncrona tanto no servidor primário como no servidor em espera. Se ocorrer uma interrupção no servidor principal, este passa automaticamente para o servidor de espera.

Cada zona de disponibilidade armazena ficheiros de dados e registos de escrita antecipada (WALs) em discos geridos premium com armazenamento localmente redundante (LRS) que armazena automaticamente três cópias de dados dentro de cada zona.

O Azure Database para PostgreSQL suporta dois tipos de configuração de zonas de disponibilidade quando utiliza alta disponibilidade:

  • Alta disponibilidade redundante de zonas: A redundância de zonas proporciona o mais elevado nível de resiliência de zona ao implementar um servidor primário numa zona de disponibilidade e um servidor de espera numa zona de disponibilidade diferente. O servidor de espera utiliza computação, armazenamento e configuração de rede semelhante à do servidor principal. Uma configuração redundante por zona proporciona isolamento físico de toda a pilha entre servidores primários e secundários.

    Pode selecionar as zonas de disponibilidade dos servidores primário e de espera ou deixar a Microsoft escolhê-las.

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

    Diagrama de uma configuração com redundância entre zonas do Base de Dados do Azure para PostgreSQL.

    As operações de escrita podem sofrer um pequeno aumento na latência de commit porque o serviço replica os dados de forma síncrona para o servidor em standby. O impacto varia consoante a carga de trabalho, o SKU selecionado e a região.

  • Alta disponibilidade zonal (na mesma zona): Os servidores primário e de espera usam a mesma zona de disponibilidade. Se ocorrer uma interrupção no servidor principal, mas a zona ainda estiver saudável, o servidor passa automaticamente para o servidor de espera. Uma implantação zonal dá-lhe alta disponibilidade dentro de uma única zona de disponibilidade. Protege-o contra falhas ao nível do nó e também ajuda a reduzir o tempo de inatividade da aplicação durante períodos de inatividade planeados e não planeados. No entanto, não protege contra uma falha nessa zona.

    Diagrama que mostra uma configuração zonal do Base de Dados do Azure para PostgreSQL.

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

    • A região não suporta zonas de disponibilidade. A região funciona efetivamente como uma única zona, por isso a única configuração de alta disponibilidade que pode selecionar é a da mesma zona.
    • Se uma região não tiver capacidade suficiente para uma implementação redundante de zona, o serviço pode inicialmente colocar ambos os servidores na mesma zona de disponibilidade e depois migrá-los automaticamente para zonas separadas quando a capacidade ficar disponível. Esta opção está disponível quando utiliza o portal Azure ou a CLI Azure para implementar um servidor. Para mais informações, consulte Configurar as opções de Business Critical (alta disponibilidade).

    Colocar os servidores na mesma zona pode reduzir a latência de escrita das aplicações que implementas na mesma zona.

    Quando os servidores estão na mesma zona, a latência de escrita para aplicações que implementas na mesma zona pode ser reduzida.

Se configurares o teu servidor sem alta disponibilidade, então ele corre num único servidor. Se esse servidor ou a sua zona cair, o seu servidor fica indisponível. Para mais informações, consulte Configurações sem zonas de disponibilidade.

Requisitos

  • Suporte de região: O Base de Dados do Azure para PostgreSQL suporta configurações de zonas de disponibilidade de forma diferente entre regiões do Azure. Para uma lista completa de regiões, os tipos de suporte a zonas de disponibilidade e quaisquer considerações específicas para cada região, consulte regiões Azure.

  • Nível de computação: A tabela seguinte lista o suporte em camadas de computação para cada tipo de suporte a zonas de disponibilidade:

    Camada de computação Zona redundante Zonal (mesma zona)
    Elástico Não suportado Não suportado
    Fins Gerais Suportado Suportado
    Otimizado para Memória Suportado Suportado

  • Nível de serviço: Ambos os tipos de alta disponibilidade requerem camadas de Uso Geral ou Otimização para Memória.

Considerações

Capacidade da região: Se uma região não tiver capacidade suficiente para uma implementação redundante de zona, o serviço pode inicialmente colocar ambos os servidores na mesma zona de disponibilidade e migrá-los automaticamente para zonas separadas quando a capacidade ficar disponível. Esta opção está disponível quando utiliza o portal Azure ou a CLI Azure para implementar um servidor. Para mais informações, consulte Configurar opções de Business Critical (alta disponibilidade).

Custo

Quando ativas a alta disponibilidade, cria-se um servidor de espera e é faturado à mesma taxa que o servidor principal. A configuração da zona de disponibilidade não afeta o custo. Não existem custos pela replicação de dados dentro ou entre zonas de disponibilidade. Dependendo do volume de armazenamento de backup, você também pode ser cobrado pelo armazenamento de backup. Para obter informações detalhadas sobre preços, consulte preços do Base de Dados do Azure para PostgreSQL.

Configurar o suporte à zona de disponibilidade

Para configurar o suporte de zonas de disponibilidade para um servidor, configure as definições de alta disponibilidade.

  • Crie um servidor redundante por zonas: Para aprender a criar um servidor com alta disponibilidade e redundância de zonas ativadas, consulte Quickstart: Criar um servidor Base de Dados do Azure para PostgreSQL.

  • Altere a configuração da zona de disponibilidade para servidores existentes: Altere a configuração da zona de disponibilidade para servidores existentes alterando as definições de alta disponibilidade. Para passos detalhados, consulte Ativar alta disponibilidade para servidores existentes.

    Não podes mudar a zona usada nem para o servidor principal nem para o servidor de espera. Tens de criar o servidor novamente.

    Sugestão

    Recomendamos que espere até que a atividade do servidor seja baixa antes de alterar a configuração de alta disponibilidade.

  • Desativar a alta disponibilidade: Desativar a alta disponibilidade remove o servidor de espera, por isso o seu servidor não é resistente a falhas na zona de disponibilidade. Para mais informações, consulte Desativar alta disponibilidade.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar quando configura servidores com alta disponibilidade e suporte de zonas de disponibilidade, e todas as zonas de disponibilidade estão operacionais.

  • Operação entre zonas: As aplicações cliente PostgreSQL ligam-se ao servidor principal usando o nome do servidor de base de dados. Base de Dados do Azure para PostgreSQL utiliza uma configuração ativo-passiva onde o servidor principal na zona de disponibilidade principal gere todas as ligações e consultas à base de dados. O servidor de espera não serve o tráfego do cliente durante as operações normais.

  • Replicação de dados entre zonas: O servidor principal replica sincronizadamente as alterações ao servidor de espera. As transações não são consideradas concluídas até que tanto o servidor primário como o de reserva reconheçam a escrita.

    Quando uma aplicação escreve e faz commit de dados, o PostgreSQL regista primeiro a alteração no WAL no servidor principal. O servidor principal transmite estes registos para o servidor de espera utilizando o protocolo de streaming PostgreSQL. Depois de o servidor de espera armazenar permanentemente o WAL, o servidor principal confirma a escrita. O aplicativo confirma sua transação somente após esse reconhecimento. Esse processo de confirmação não espera que os logs sejam aplicados ao servidor em espera.

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

    • Redundante de zona: Como os servidores estão em zonas separadas, esta abordagem garante perda zero de dados durante uma falha de zona. Esta situação é também por vezes chamada de alcançar um objetivo de ponto de recuperação (RPO) zero para falhas de zona.

      No entanto, a replicação entre zonas pode introduzir uma pequena quantidade extra de latência. O impacto da latência depende da aplicação. Para a maioria das aplicações, a latência extra é negligenciável.

    • Zonal: Como ambos os servidores estão na mesma zona, não há tráfego replicado entre zonas.

    Observação

    O sistema replica os dados de registo em tempo real para o servidor de espera. Quaisquer erros do utilizador no servidor principal, como uma queda acidental de uma tabela ou atualizações de dados incorretas, são replicados para o servidor de espera. Não pode usar o standby para recuperar destes tipos de erros, e tem de fazer uma restauração pontual a partir do backup. Para mais informações, consulte Cópia de segurança e restauração.

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando configura servidores com alta disponibilidade e suporte por zonas de disponibilidade, e há uma falha na zona de disponibilidade.

  • Deteção e resposta: O Azure verifica periodicamente a saúde tanto do servidor principal como do servidor de espera. Após vários pings, se o monitoramento de integridade detetar que um servidor primário não está acessível, o serviço iniciará um failover automático para o servidor em espera. O algoritmo de monitoramento de saúde usa múltiplos pontos de dados para evitar situações de falso positivo.

    Se uma zona de disponibilidade falhar, o comportamento é diferente dependendo da configuração da zona de disponibilidade que o seu servidor utiliza:

    • Redundante por zona: O Base de Dados do Azure para PostgreSQL deteta automaticamente falhas nas zonas de disponibilidade. Para visualizar os possíveis tipos de estado de alta disponibilidade, consulte monitorização do estado de saúde de Alta Disponibilidade (HA). Quando uma zona falha, o Azure inicia um failover forçado para o servidor de espera sem que seja necessário agir.

    • Zonal: Se a zona de disponibilidade que aloja um servidor zonal ficar indisponível, tanto o servidor primário como o de reserva ficam indisponíveis. Neste cenário, o serviço não fornece failover automático. És responsável por detetar a interrupção da zona e realizar ações de recuperação, como restaurar backups redundantes de zona para um servidor separado noutra zona de disponibilidade ou região.

  • Notificação: A monitorização do estado de saúde de alta disponibilidade no Base de Dados do Azure para PostgreSQL fornece uma visão geral contínua da saúde e prontidão das instâncias habilitadas para alta disponibilidade. A funcionalidade de monitorização é construída sobre o Azure Resource Health e pode detetar e alertar sobre quaisquer problemas que possam afetar a prontidão para failover ou a disponibilidade geral da sua base de dados. Avalie métricas-chave como o estado da ligação, o estado do failover e a saúde da replicação de dados para permitir uma resolução proativa de problemas e ajudar a manter o tempo de funcionamento e o desempenho da sua base de dados.

    Para obter um guia detalhado sobre como configurar e interpretar os estados de saúde da Alta Disponibilidade (HA), consulte Monitorização do estado de saúde da Alta Disponibilidade (HA).

  • Pedidos ativos: Quando uma zona de disponibilidade se torna indisponível, quaisquer pedidos em curso para servidores na zona afetada podem ser terminados. As aplicações devem repetir estes pedidos. 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 que o seu servidor utiliza.

    • Redundância de zona: Não se espera perda de dados durante o failover de zona graças à replicação síncrona entre os servidores primário e secundário em diferentes zonas.

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

  • Tempo de inatividade previsto: A quantidade de tempo de inatividade depende da configuração da zona de disponibilidade que o seu servidor utiliza.

    • Redundante de zona: O failover normalmente termina em 60-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 numa zona afetada ficam indisponíveis até que a zona de disponibilidade recupere.

  • Redistribuição: O comportamento de redirecionamento do tráfego depende da configuração da zona de disponibilidade que o seu servidor utiliza.

    • Zona redundante: Após o failover, o antigo servidor de espera torna-se o novo primário e começa a aceitar novas conexões. O Azure estabelece automaticamente um novo servidor de espera na zona primária original após a sua recuperação. Para detalhes completos, consulte Failover forçado.

    • Zonal: Quando uma zona está indisponível, o seu servidor está indisponível. Se tiver um servidor separado que criou previamente noutra zona de disponibilidade ou região, é responsável por redirecionar o tráfego para esse servidor.

Recuperação de zona

O comportamento de recuperação da zona depende da configuração de zonas de disponibilidade que o seu servidor utiliza.

  • Redundante de zona: Quando a zona de disponibilidade recupera, o Base de Dados do Azure para PostgreSQL reconstrói automaticamente o servidor de redundância na zona recuperada e sincroniza-o com o servidor principal atual. A zona recuperada serve então como local de reserva. Para evitar interrupções desnecessárias, o serviço não move automaticamente a função primária de volta para a zona original. Pode iniciar manualmente um failover planeado se desejar devolver o servidor primário à zona original.

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

Teste de falhas de zona

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

  • Redundância de zona: Pode testar a resiliência da sua aplicação ao falhar por iniciar uma falha forçada. Um failover forçado permite-lhe simular um cenário de falha não planeada enquanto executa a sua carga de trabalho e observar o tempo de inatividade da aplicação. Recomendamos que execute simulações num ambiente não produtivo ou num período calmo. Para mais informações, consulte Iniciar um failover forçado.

  • Zonal: Embora não possas simular uma interrupção total em zona, podes simular que o teu servidor está indisponível de uma forma semelhante a uma interrupção em zona. Para mais informações, veja Parar o cálculo de um servidor.

Resiliência a falhas em toda a região

O Azure Database para PostgreSQL suporta réplicas de leitura entre regiões, que pode usar para manter uma cópia sincronizada da sua base de dados numa região diferente para uma recuperação mais rápida.

Também pode usar backups geo-redundantes, em regiões suportadas, para fornecer recuperação entre diferentes regiões. No entanto, os backups normalmente envolvem mais tempo de inatividade e perda de dados do que a replicação. Para mais informações, consulte Cópia de segurança e restauração.

Réplicas de leitura entre regiões

Pode implementar réplicas de leitura para proteger as suas bases de dados contra falhas a nível regional. Cada réplica de leitura é uma base de dados Azure separada para o servidor PostgreSQL. Quando coloca uma réplica de leitura numa segunda região Azure, o seu servidor de base de dados pode proporcionar resiliência a um problema regional. Podes implementar até cinco réplicas de leitura, que podem opcionalmente estar em diferentes regiões do Azure. A tecnologia física de replicação do PostgreSQL atualiza as réplicas de leitura de forma assíncrona, e estas podem estar atrás da primária. As réplicas de leitura entre regiões podem, opcionalmente, servir cargas de trabalho apenas de leitura para reduzir a latência em aplicações distribuídas globalmente ou para descarregar o tráfego de leitura do servidor principal. Para obter mais informações sobre as funcionalidades e considerações das réplicas de leitura, consulte Réplicas de leitura.

Os endpoints virtuais oferecem endpoints de leitura/escrita e de leitura apenas, redirecionando automaticamente o tráfego quando uma réplica é promovida, o que ajuda a minimizar o tempo de inatividade durante eventos de failover. Recomendamos fortemente o uso de endpoints virtuais com réplicas de leitura entre regiões para melhorar a resiliência da aplicação. Para informações adicionais, consulte Endpoints virtuais para réplicas de leitura no Base de Dados do Azure para PostgreSQL.

Diagrama que mostra um servidor primário numa região e uma réplica de leitura numa segunda região.

Se a tua região principal falhar, podes desencadear uma promoção para que a tua réplica secundária se torne a principal. Diferentes tipos de failover podem ser apropriados dependendo de como usas as réplicas de leitura. Quando se usam réplicas de leitura para fornecer resiliência a falhas de região, normalmente se utiliza a abordagem de promoção para servidor principal que atualiza o endpoint virtual. Durante uma falha de região, é necessário realizar uma promoção forçada, o que pode resultar em alguma perda de quaisquer dados não replicados. Em cenários planeados em que a região principal está saudável, pode optar por realizar uma promoção planeada para evitar a perda de dados. Para mais informações, consulte Ativar réplicas de leitura no Base de Dados do Azure para PostgreSQL.

Diagrama mostrando uma réplica lida numa segunda região do Azure que foi promovida para a réplica principal.

Observação

Esta secção resume algumas informações importantes sobre como as réplicas Read podem apoiar a resiliência face a falhas regionais. Também pode usar réplicas de leitura para melhorar o desempenho e suportar bases de utilizadores em larga escala e distribuídas geograficamente. Para mais informações, consulte Ler réplicas.

Requisitos

  • Apoio regional: Pode criar réplicas de leitura entre regiões em qualquer região que suporte Azure Database para PostgreSQL. Não estás limitado a regiões emparelhadas com Azure.

  • Níveis de computação: Os níveis de computação de Propósito Geral e Otimizado para Memória suportam réplicas de leitura. O nível Burstable não suporta réplicas de leitura.

Considerações

  • Diferenças de configuração: As réplicas de leitura podem não herdar todas as definições de configuração do servidor principal. Planeia configurar as definições necessárias após o failover. O teu servidor principal e as réplicas devem ser simétricos, o que significa que precisam de ter os mesmos níveis, tamanhos de armazenamento e valores para algumas definiçõ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 mais informações, consulte Gestão de Configuração.

  • Monitorização do atraso de replicação: O processo de replicação assíncrona requer um atraso de replicação, que pode variar consoante muitos fatores. Quando o atraso de replicação é elevado, o seu servidor pode ter problemas. É importante monitorizar o atraso de replicação para poder mitigar os problemas antes que se agravem. Para mais informações, veja Replicação do monitor.

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

Para outros fatores a considerar sobre o processo de promoção, consulte Considerações.

Custo

As réplicas de leitura acarretam custos de computação e armazenamento, além de custos de transferência de dados entre regiões para replicação. Para informações detalhadas sobre preços, consulte preços do Base de Dados do Azure para PostgreSQL e preçário de largura de banda.

Configurar suporte multirregional

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

Esta secção descreve o que esperar quando o seu servidor está configurado com uma réplica de leitura noutra região e um endpoint virtual, e todas as regiões estão operacionais:

  • Encaminhamento do tráfego entre regiões: Em operações normais, o seu endpoint virtual direciona o tráfego para o endpoint de leitura-escrita para o servidor principal na região principal. Se também usares o endpoint de leitura do endpoint virtual, este encaminha o tráfego para a réplica que configurares.

  • Replicação de dados entre regiões: As réplicas de leitura entre regiões utilizam replicação assíncrona para minimizar o impacto no desempenho do servidor principal. A quantidade de atraso de replicação depende de muitos fatores, incluindo a carga de escrita e a latência entre o servidor principal e as réplicas. O atraso de replicação é tipicamente de pelo menos vários minutos, mas pode ser mais longo. Para mais informações, veja Replicação do monitor.

Comportamento durante uma interrupção regional

Esta secção descreve o que esperar quando o seu servidor está configurado com uma réplica de leitura noutra região e um endpoint virtual, e há uma falha na região principal:

  • Deteção e resposta: És responsável por detetar uma falha na região principal e promover manualmente uma réplica de leitura para se tornar o novo servidor principal. Durante uma interrupção regional, deve realizar uma promoção forçada, o que resulta na perda de quaisquer dados não replicados.

    Importante

    És responsável por desencadear a promoção. O Azure não promove automaticamente as réplicas de leitura, mesmo que haja uma falha de região.

    Para etapas detalhadas sobre como iniciar uma promoção, consulte Alternar réplica de leitura para principal.

  • Notificação: A Microsoft não notifica automaticamente quando uma região está fora de serviço. No entanto, pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas de região, e pode configurar alertas de Saúde do Serviço para o informar sobre problemas.

  • Pedidos ativos: O processo de promoção elimina todas as ligações ativas à região principal. Depois de concluído o processo de promoção, as aplicações têm de voltar a tentar estabelecer ligações à réplica promovida.

  • Perda de dados esperada: Durante uma interrupção regional, deve realizar 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 é tipicamente de pelo menos vários minutos, mas pode ser mais longo. Para mais informações, veja Replicação do monitor.

  • Tempo de inatividade previsto: A promoção forçada normalmente termina entre 1 a 3 minutos após ser ativada. As aplicações também podem precisar de se reconectar ao endpoint correto. Os endpoints virtuais são atualizados como parte do processo de promoção obrigatória. As aplicações devem respeitar o time-to-live (TTL) dos registos DNS do endpoint para garantir que rapidamente se reconectam à réplica correta após a conclusão da promoção.

  • Redirecionamento de tráfego: O endpoint virtual do servidor redireciona automaticamente o tráfego da aplicação para a nova réplica primária.

    Observação

    Depois de uma réplica de leitura ser promovida a servidor principal, não tem a configuração de alta disponibilidade ativada. Precisa de ativar manualmente a configuração de alta disponibilidade, ou adicioná-la aos seus próprios processos de automação.

Recuperação da região

Quando usas endpoints virtuais, depois de a região primária recuperar, o servidor primário antigo é automaticamente configurado como uma réplica de leitura. Pode fazer outra promoção para devolver as operações primárias à sua região principal preferida.

Teste para falhas regionais

Teste regularmente os procedimentos de promoção de read-replica para garantir que os seus processos são válidos e que as capacidades cumprem os requisitos do seu objetivo de tempo de recuperação (RTO) e objetivo do ponto de recuperação (RPO).

Pode promover uma réplica de leitura para se tornar o servidor principal a qualquer momento, mesmo que todas as regiões estejam funcionais. Para testes:

  • Pode realizar testes de promoção forçada. Recomendamos que realize estes testes num ambiente não produtivo porque pode resultar em perda de dados. Os testes de promoção forçada ajudam a simular o comportamento que se observa durante uma interrupção regional.
  • Para manutenção planeada, ou cenários de teste onde pretende evitar a perda de dados, use antes uma promoção planeada. No entanto, a promoção planeada segue um processo diferente da promoção durante uma interrupção regional, pelo que pode não refletir o comportamento durante uma interrupção regional real.

Para obter instruções passo a passo, consulte Alterar réplica de leitura para principal.

Como parte da sua estratégia de recuperação de desastres, realize regularmente exercícios completos de recuperação. Estes exercícios devem incluir validação de dados, testes de funcionalidade da aplicação e procedimentos de rollback documentados.

Backup e restauração

O Base de Dados do Azure para PostgreSQL faz backup automático dos seus dados. Estes backups proporcionam capacidades de recuperação pontual e ajudam a protegê-lo contra corrupção acidental e eliminação de dados. A Microsoft gere integralmente os backups. Não interrompem a disponibilidade do servidor e incluem tanto backups completos como backups de registos de transações.

  • Armazenamento de backup: Se implantar o servidor numa região com zonas de disponibilidade, o serviço armazena backups em armazenamento redundante por zona (ZRS), independentemente da configuração de alta disponibilidade do servidor. Para servidores instalados em regiões sem zonas de disponibilidade, o serviço armazena backups em armazenamento localmente redundante (LRS).

    Nas regiões Azure com pares, podes configurar armazenamento de backup geo-redundante na altura da criação do servidor para replicar backups para a região emparelhada do Azure, para proteção extra contra falhas de região. O serviço replica backups de forma assíncrona.

    O período padrão de retenção de backup é de sete dias, mas pode estender a retenção até 35 dias. Também pode usar o Azure Backup para armazenamento a longo prazo de backups manuais até 10 anos. Todas as cópias de segurança estão encriptadas.

  • Restaurar: A recuperação no momento permite restaurar a sua base de dados a qualquer momento dentro do período de retenção de backup. O processo de restauro cria um novo servidor de base de dados com um novo nome fornecido pelo utilizador. Podes usar o novo servidor as-is ou copiar dados dele.

    Quando restauras um backup geo-redundante, crias um novo servidor na região emparelhada.

    Esta capacidade é útil para recuperar de modificações acidentais de dados, erros de aplicação ou cenários de teste.

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

Para mais informações, consulte Backup e restauro na Base de Dados Azure para PostgreSQL.

Resiliência à manutenção de serviços

O Base de Dados do Azure para PostgreSQL gere automaticamente tarefas críticas de manutenção, incluindo a correção do hardware subjacente, do sistema operativo e do motor de base de dados. O serviço inclui atualizações de segurança, atualizações de software e pequenas atualizações de versões como parte da manutenção planeada.

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

  • Permitir alta disponibilidade: Durante a manutenção, o servidor pode precisar de reiniciar como parte do processo de atualização. Se ativar a alta disponibilidade, as operações de manutenção normalmente utilizam atualizações contínuas para minimizar o tempo de inatividade. Atividades periódicas de manutenção, como pequenas atualizações de versão, acontecem primeiro na réplica de espera. Para reduzir o tempo de inatividade, o standby é promovido a primário para que as cargas de trabalho possam continuar no nó promovido enquanto as tarefas de manutenção são aplicadas ao outro nó. Esta sequência aplica-se quer o seu servidor utilize redundância por zona ou alta disponibilidade zonal.

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

  • Configure janelas de manutenção personalizadas: Pode configurar o calendário de manutenção para ser gerido pelo sistema ou definir uma janela de manutenção personalizada para minimizar o impacto nas operações do seu negócio. Programe a manutenção durante períodos de baixa atividade para minimizar o impacto no negócio. Para mais informações, consulte Manutenção Programada.

  • Implemente lógica de repetição: Certifique-se de que as suas aplicações conseguem lidar com breves interrupções de conectividade que possam ocorrer durante reinícios para manutenção. Para tornar as suas aplicações resilientes a este tipo de problemas, consulte a orientação Resiliência a falhas transitórias .

Contrato de nível de serviço

O contrato de nível de serviço (SLA) para serviços do 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 Acordos de Nível de Serviço (SLAs) para serviços online.

Base de Dados do Azure para PostgreSQL fornece diferentes SLAs de disponibilidade, dependendo da configuração do servidor:

  • Servidores configurados com alta disponibilidade redundante por zona oferecem um SLA de disponibilidade de 99,99%.
  • Servidores configurados com alta disponibilidade zonal oferecem um Acordo de Nível de Serviço (SLA) de tempo de atividade de 99.95%.
  • Servidores configurados sem alta disponibilidade oferecem um SLA de tempo de atividade de 99,9%.

Conteúdo relacionado

  • Last updated on