Georreplicação no Base de Dados do Azure para PostgreSQL flexible server

Pode criar uma réplica de leitura na mesma região do servidor principal ou numa região geográfica diferente. A geo-replicação é útil para cenários como planeamento de recuperação de desastres ou aproximar dados dos seus utilizadores.

Você pode ter um servidor primário em qualquer região de serviço de servidor flexível do Banco de Dados do Azure para PostgreSQL. Um servidor primário também pode ter réplicas em qualquer região global do Azure que suporte o Base de Dados do Azure para PostgreSQL para servidores flexíveis. Além disso, o serviço suporta regiões na nuvem soberana Azure Government e na nuvem soberana Microsoft Azure operada pela 21Vianet.

Regiões emparelhadas para fins de recuperação de desastres

Pode criar réplicas em qualquer região suportada, mas obtém benefícios notáveis ao escolher réplicas em regiões Azure emparelhadas, especialmente quando arquitetar para fins de recuperação de desastres:

  • Sequência de Recuperação de Região: Numa interrupção geográfica, a recuperação de uma região de cada conjunto emparelhado é prioritária. Esta prioridade garante que as aplicações entre regiões emparelhadas tenham sempre uma região acelerada para recuperação.

  • Atualização Sequencial: As atualizações das regiões emparelhadas são escalonadas cronologicamente, o que minimiza o risco de indisponibilidade devido a problemas relacionados com a atualização.

  • Residência de Dados: Com algumas exceções, as regiões de um conjunto emparelhado residem dentro da mesma geografia, pelo que cumprem os requisitos de residência de dados.

  • Desempenho: Embora as regiões emparelhadas normalmente ofereçam baixa latência de rede, o que melhora a acessibilidade dos dados e a experiência do utilizador, nem sempre são as regiões com a latência absolutamente mais baixa. Se o objetivo principal for fornecer dados mais próximos dos utilizadores em vez de priorizar a recuperação de desastres, avalie todas as regiões disponíveis quanto à latência. Em alguns casos, uma região não emparelhada pode apresentar a menor latência. Para obter uma compreensão abrangente, você pode fazer referência aos números de latência de ida e volta do Azure para fazer uma escolha informada.

Para uma compreensão mais profunda das vantagens das regiões emparelhadas, consulte a documentação do Azure sobre replicação entre regiões.

Falhas regionais e recuperação

Os recursos do Azure em várias regiões são projetados para serem altamente confiáveis. No entanto, em circunstâncias raras, toda uma região pode tornar-se inacessível devido a razões que vão desde falhas de rede a cenários graves, como catástrofes naturais. As capacidades do Azure permitem-lhe criar aplicações distribuídas por várias regiões, garantindo que uma falha numa região não afete outras.

Preparar-se para desastres regionais

Estar preparado para possíveis desastres regionais é fundamental para garantir a operação ininterrupta de seus aplicativos e serviços. Se está a considerar um plano de contingência robusto para o seu servidor flexível Base de Dados do Azure para PostgreSQL, considere estes passos e considerações essenciais:

  1. Crie uma réplica de leitura com replicação geográfica: Configure uma réplica de leitura numa região diferente da sua instância primária. Esta configuração assegura continuidade caso a região principal sofra uma falha.
  2. Garantir simetria do servidor: A ação mais recomendada para lidar com falhas regionais é promover para servidor principal, mas isso implica um requisito de simetria do servidor . Este requisito significa que tanto o servidor primário como o réplica devem ter configurações idênticas de definições específicas. As vantagens de usar esta ação incluem:
    • Não há necessidade de modificar cadeias de conexão de aplicação se você usar pontos de extremidade virtuais.
    • Ele fornece um processo de recuperação contínuo em que, uma vez que a região afetada está on-line novamente, o servidor primário original retoma automaticamente sua função, mas em uma nova função de réplica.
  3. Configurar pontos de extremidade virtuais: os pontos de extremidade virtuais permitem uma transição suave do seu aplicativo para outra região se houver uma interrupção. Eles eliminam a necessidade de quaisquer alterações nas cadeias de conexão do seu aplicativo.
  4. Configurar a réplica de leitura: nem todas as configurações do servidor primário são replicadas para a réplica de leitura. Certifique-se de que configura corretamente todas as configurações e funcionalidades necessárias (por exemplo, PgBouncer) na sua réplica de leitura. Para obter mais informações, consulte a seção Gerenciamento de configuração .
  5. Prepare-se para alta disponibilidade (HA): Se a sua configuração exigir alta disponibilidade, esta não está automaticamente ativada numa réplica promovida. Esteja pronto para ativá-lo depois da promoção. Considere automatizar esta etapa para minimizar o tempo de inatividade.
  6. Testes regulares: simule regularmente cenários de desastres regionais para validar limites, destinos e configurações existentes. Certifique-se de que seu aplicativo responda conforme o esperado durante esses cenários de teste.
  7. Siga as orientações gerais do Azure: o Azure fornece orientações abrangentes sobre fiabilidade e preparação para desastres. Consulte estes recursos e integre as melhores práticas no seu plano de preparação.

Ser proativo e preparar-se antecipadamente para desastres regionais garante a resiliência e fiabilidade das suas aplicações e dados.

Quando interrupções afetam seu SLA

Se ocorrer uma interrupção prolongada num servidor flexível do Base de Dados do Azure para PostgreSQL numa região específica que ameace o acordo de nível de serviço (SLA) da sua aplicação, esteja ciente de que ambas as ações discutidas na secção seguinte não são orientadas pelo serviço. Ambas as ações requerem intervenção do utilizador. Automatize todo o processo tanto quanto possível e tenha monitorização robusta implementada. Para obter mais informações sobre quais informações são fornecidas durante uma interrupção, consulte a página Interrupção do serviço. Apenas uma promoção forçada é possível em um cenário de região para baixo, o que significa que a quantidade de perda de dados é aproximadamente igual ao atraso atual entre a réplica e a principal. Por isso, é crucial monitorar o atraso. Considere as seguintes opções:

Promover para servidor primário

Esta opção não requer atualizar as strings de ligação na sua aplicação, desde que configure endpoints virtuais. Uma vez ativado, o endpoint do escritor aponta para o novo primário numa região diferente e a coluna de estado de replicação no portal Azure mostra "Reconfigurar". Assim que a região afetada é restaurada, o antigo servidor principal retoma automaticamente, mas agora numa função de réplica.

Promover para servidor independente e remover da replicação

Em alguns casos, esta opção pode ser a única viável. Depois de promover o servidor, atualize as cadeias de ligação da sua aplicação. Uma vez restaurada a região original, a primária antiga pode ficar ativa novamente. Certifique-se de removê-lo para evitar incorrer em custos desnecessários. Se desejar manter a topologia anterior, recrie a réplica de leitura.

Conteúdo relacionado

  • Last updated on