Confiabilidade no Azure Database para PostgreSQL

Azure Database for PostgreSQL é um serviço de base de dados totalmente gerido, concebido para lhe dar controlo granular e flexibilidade sobre funções de gestão de bases de dados e definições de configuração. O serviço oferece elevada disponibilidade e capacidades de recuperação de desastres de acordo com as 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 para PostgreSQL resiliente a uma variedade de potenciais falhas e problemas, incluindo falhas transitórias, falhas 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 algumas informações chave sobre o acordo de nível de serviço (SLA) da Azure Database for PostgreSQL.

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

Para saber como implementar o Azure Database 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 Azure Database for 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 Azure Database para PostgreSQL, implementa um servidor que representa os recursos de computação e armazenamento necessários para dar suporte ao seu servidor de bases de dados. Implementas uma ou mais bases de dados no servidor.

Os servidores podem ser implementados em múltiplos níveis de computação: Burstable, General Purpose e Memory Optimized, cada um 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 O que é Azure Database for 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, enquanto os ficheiros de dados são armazenados no armazenamento Azure, que 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: Podes, opcionalmente, ativar uma configuração de alta disponibilidade no teu servidor. Quando ativas a configuração de alta disponibilidade, o serviço fornece e mantém um servidor de espera quente. As alterações de dados no servidor principal são replicadas de forma síncrona para o servidor de reserva para garantir perda zero de dados durante uma falha do servidor principal.

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

  

  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.

  Operações como parar, iniciar e reiniciar são realizadas nos servidores de bases de dados principal e de reserva em simultâneo. Os eventos planejados, como computação em escala e armazenamento em escala, acontecem primeiro no modo de espera e, em seguida, no servidor primário. 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 Azure Database for 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.

Pode selecionar o seu tipo de zona de disponibilidade através da configuração de alta disponibilidade . Ativar alta disponibilidade implementa um servidor de contingência ao lado do seu servidor principal. Este modelo de alta disponibilidade ajuda a garantir que os dados comprometidos nunca se percam durante falhas. Independentemente do modelo de implementação de alta disponibilidade que o seu servidor utilize, os dados são sincronizados para ambos, o servidor principal e o de espera. Se ocorrer uma interrupção no servidor principal, este passa automaticamente para o servidor de espera.

Os ficheiros de dados e os registos de escrita antecipada (WALs) são armazenados em discos geridos premium dentro de cada zona de disponibilidade, com armazenamento localmente redundante (LRS) que armazena automaticamente três cópias de dados em 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 uma configuração de computação, armazenamento e rede semelhante à primária. 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.

  

  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-te contra falhas ao nível do nó e também ajuda a reduzir o tempo de inatividade da aplicação durante eventos planeados e não planeados. No entanto, não protege contra uma falha nessa zona.

  

  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, pelo que 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 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 Críticas para o Negócio (Alta Disponibilidade).

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

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

• Apoio regional: O suporte do Azure Database for PostgreSQL para configurações de zonas de disponibilidade difere entre regiões Azure. Para uma lista completa de regiões, os tipos de suporte para zonas de disponibilidade e quaisquer considerações específicas para essa 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:

  Escalão de preço	Redundância zonal	Zonal (mesma zona)
  Elástico	Não suportado	Suportado
  Fins Gerais	Suportado	Suportado
  Otimizado para Memória	Suportado	Suportado

• Nível de serviço: A redundância de zonas requer os níveis de Propósito Geral ou Otimizado para Memória.

  Implementações zonais (na mesma zona) são suportadas em todos os níveis de preço.

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 Críticas para o Negócio (Alta Disponibilidade).

Custo

Quando ativas a alta disponibilidade, o servidor de espera é criado e faturado à mesma taxa que o primário. 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 Azure Database for PostgreSQL.

Configurar o suporte à zona de disponibilidade

Para configurar o suporte a zonas de disponibilidade para um servidor, configura 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 uma Base de Dados Azure para PostgreSQL no portal Azure.

• Altere a configuração da zona de disponibilidade para servidores existentes: Pode alterar 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 depois de terem sido criados. Precisas de recriar o servidor.

  Sugestão

  É uma boa ideia esperar que a atividade do servidor seja baixa antes de mudar 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 os servidores estão configurados com alta disponibilidade e suporte a 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. O Azure Database para PostgreSQL utiliza uma configuração ativa/passiva onde todas as ligações e consultas à base de dados são tratadas pelo servidor principal na zona de disponibilidade primária. O servidor de espera não serve o tráfego do cliente durante as operações normais.

• Replicação de dados entre zonas: As alterações aos dados são replicadas de forma síncrona entre os servidores primário e 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.

  Gravação acionada por transação de aplicativo e confirma o primeiro log para a 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 em espera persiste os logs, o servidor primário reconhece a conclusão do processo de 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, e para a maioria das aplicações é 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. Portanto, 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 os servidores estão configurados com alta disponibilidade e suporte a 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.

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

  • Redundante por zona: O Azure Database for PostgreSQL deteta automaticamente falhas nas zonas de disponibilidade. Para ver os possíveis tipos de estado de alta disponibilidade, veja Tipos de estado de alta disponibilidade. 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 (HA) no Azure Database for PostgreSQL fornece uma visão geral contínua da saúde e prontidão das instâncias habilitadas por HA. 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 dos 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 status de integridade de HA, consulte Monitoramento de status de integridade de alta disponibilidade (HA) para o Banco de Dados do Azure para PostgreSQL.

• 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 pré-criou 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 Azure Database for 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. O serviço não move automaticamente a função principal de volta para a zona original para evitar perturbações desnecessárias. 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 a execução de simulações num ambiente não produtivo ou em momentos calmos. Para mais informações, consulte Iniciar um failover forçado.

• Zonal: Embora não possas simular uma interrupção total de zona, podes simular que o teu servidor está indisponível de forma semelhante ao que acontece durante uma interrupção de 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 Azure Database for PostgreSQL.

Se a tua região principal falhar, podes desencadear uma promoção para que a tua réplica secundária se torne a principal. Existem diferentes tipos de failover que podes ativar 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 Azure Database for PostgreSQL.

Observação

Esta secção resume algumas das informações importantes sobre como as réplicas Read podem suportar a resiliência 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 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 vários fatores. Quando o atraso de replicação é muito 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 considerações adicionais relacionadas com o processo de promoção, consulte Promover réplicas de leitura no Azure Database for PostgreSQL - Considerações.

Custo

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

Configurar suporte a várias regiões

• Crie uma réplica de leitura: Para aprender a criar uma réplica de leitura, veja Criar uma réplica de leitura. As réplicas podem ser configuradas após a criação do servidor principal, desde que o servidor principal esteja a funcionar e acessível.

  Para criar um endpoint virtual, veja Criar endpoints virtuais.

• Apagar uma réplica lida: Para aprender a eliminar uma réplica lida, veja Eliminar uma réplica lida.

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, então ele direciona o tráfego para a réplica que tenhas configurado.

• 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 lag de replicação depende de vários 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 muito 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: Todas as ligações ativas à região primária são cortadas. As aplicações precisam de tentar fazer novamente ligações à réplica promovida após o processo de promoção ser concluído.

• 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 muito 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 réplicas para garantir que os seus procedimentos são válidos e que as capacidades cumprem os requisitos do seu RTO e 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 de produção, pois 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. Esteja ciente de que a promoção planeada segue um processo diferente da promoção durante uma interrupção regional.

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 Azure Database para PostgreSQL realiza automaticamente backups que proporcionam capacidades de recuperação pontual e ajudam a protegê-lo contra corrupção acidental e eliminação de dados. Os backups são totalmente geridos pela Microsoft, não interrompem a disponibilidade do servidor e incluem tanto backups completos como backups dos registos de transações.

• Armazenamento de backup: Se o servidor estiver configurado com alta disponibilidade redundante por zona, as cópias de segurança são armazenadas em armazenamento redundante por zona (ZRS). Para servidores configurados sem alta disponibilidade, ou com alta disponibilidade zonal (de zona única), os backups são armazenados em armazenamento localmente redundante (LRS).

  Nas regiões emparelhadas do Azure, pode configurar armazenamento de backup geo-redundante (GRS) na altura da criação do servidor para replicar backups na região emparelhada do Azure, para proteção adicional contra indisponibilidade de região. As cópias de segurança são replicadas de forma assíncrona.

  O período padrão de retenção de backup é de 7 dias, com a opção de prolongar 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 de servidor fornecido pelo utilizador, do qual pode depois usar as-is ou copiar dados.

  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 Azure Database for PostgreSQL gere automaticamente tarefas críticas de manutenção, incluindo a correção do hardware subjacente, sistema operativo e 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 ser reiniciado como parte do processo de atualização. Se tiver a alta disponibilidade ativada, 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 modo de espera é promovido a principal para que as cargas de trabalho possam continuar enquanto as tarefas de manutenção são aplicadas no nó restante. 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.

• Implementar lógica de retentativa: Assegure que as suas aplicações conseguem lidar com breves interrupções de conectividade que possam ocorrer durante os reinícios de 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.

O Azure Database for PostgreSQL fornece diferentes SLAs de disponibilidade consoante a 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

• Fiabilidade do Azure
• Melhores práticas de arquitetura para Azure Database for PostgreSQL
• Visão geral da continuidade de negócios com o Banco de Dados do Azure para PostgreSQL
• Recuperação de desastres geográficos no Azure Database for PostgreSQL
• Azure Database for PostgreSQL Resiliency Solution Accelerator - scripts Terraform para implementar muitos dos princípios de resiliência e recuperação descritos neste artigo.