Replicação geográfica no Banco de Dados do Azure para PostgreSQL - Servidor flexível
APLICA-SE A: 
Banco de Dados do Azure para PostgreSQL - Servidor Flexível
Uma réplica de leitura pode ser criada na mesma região do servidor primário ou em uma região geográfica diferente. A replicação geográfica pode ser útil para cenários como planejamento de recuperação de desastres ou aproximar os dados dos usuários.
Você pode ter um servidor primário em qualquer regiã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 ofereça suporte ao Banco de Dados do Azure para servidor flexível PostgreSQL. Além disso, suportamos regiões especiais Azure Government e Microsoft Azure operadas pela 21Vianet. As regiões especiais agora apoiadas são:
Regiões do Azure Government:
- US Gov - Arizona
- US Gov - Texas
- US Gov - Virginia
Microsoft Azure operado por 21Vianet regiões:
- Norte da China 3
- Leste da China 3
- Norte da China 2
- China Leste 2
Regiões emparelhadas para fins de recuperação de desastres
Embora a criação de réplicas em qualquer região com suporte seja possível, há benefícios notáveis na escolha de réplicas em regiões emparelhadas, especialmente ao arquitetar para fins de recuperação de desastres:
Sequência de recuperação de região: em uma interrupção em toda a geografia, a recuperação de uma região de cada conjunto emparelhado é priorizada, garantindo que os aplicativos em regiões emparelhadas sempre tenham uma região acelerada para recuperação.
Atualização sequencial: as atualizações das regiões emparelhadas são escalonadas cronologicamente, minimizando o risco de tempo de inatividade devido a problemas relacionados à atualização.
Isolamento físico: Uma distância mínima de 300 milhas é mantida entre data centers em regiões emparelhadas, reduzindo o risco de interrupções simultâneas de eventos significativos.
Residência de dados: Com algumas exceções, as regiões em um conjunto emparelhado residem dentro da mesma geografia, atendendo aos requisitos de residência de dados.
Desempenho: Embora as regiões emparelhadas normalmente ofereçam baixa latência de rede, melhorando a acessibilidade dos dados e a experiência do usuário, elas nem sempre são as regiões com a menor latência absoluta. Se o objetivo principal é servir os dados mais perto dos usuários em vez de priorizar a recuperação de desastres, é crucial avaliar 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. Os recursos do Azure permitem a criação de aplicativos distribuídos em várias regiões, garantindo que uma falha em uma região não afete outras.
Prepare-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 você estiver considerando um plano de contingência robusto para sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL, aqui estão as principais etapas e considerações:
- Estabeleça uma réplica de leitura replicada geograficamente: é essencial ter uma réplica de leitura configurada em uma região separada da principal. Isso garante a continuidade caso a região principal enfrente uma interrupção.
- Garantir a simetria do servidor: a ação "promover para o servidor principal" é a mais recomendada para lidar com interrupções regionais, mas vem com um requisito de simetria do servidor. Isso significa que os servidores primário e de réplica devem ter configurações idênticas de configurações específicas. As vantagens de usar esta ação incluem:
- Não há necessidade de modificar cadeias de conexão de aplicativo 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.
- 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.
- Configurar a réplica de leitura: nem todas as configurações do servidor primário são replicadas para a réplica de leitura. É crucial garantir que todas as configurações e recursos necessários (por exemplo, PgBouncer) sejam configurados adequadamente em sua réplica de leitura. Para obter mais informações, consulte a seção Gerenciamento de configuração .
- Prepare-se para alta disponibilidade (HA): se sua configuração exigir alta disponibilidade, ela não será ativada automaticamente em uma réplica promovida. Esteja pronto para ativá-lo após a promoção. Considere automatizar esta etapa para minimizar o tempo de inatividade.
- 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.
- Siga as orientações gerais do Azure: o Azure fornece orientações abrangentes sobre fiabilidade e preparação para desastres. É altamente benéfico consultar estes recursos e integrar as melhores práticas no seu plano de preparação.
Ser proativo e preparar-se com antecedência para desastres regionais garantem a resiliência e a confiabilidade de seus aplicativos e dados.
Quando interrupções afetam seu SLA
No caso de uma interrupção prolongada com o servidor flexível do Banco de Dados do Azure para PostgreSQL em uma região específica que ameace o contrato de nível de serviço (SLA) do seu aplicativo, esteja ciente de que ambas as ações discutidas abaixo não são orientadas por serviço. A intervenção do usuário é necessária para ambos. É uma prática recomendada automatizar todo o processo tanto quanto possível e ter um monitoramento robusto. 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 etapas:
Promover para servidor primário
Essa opção não exigirá a atualização das cadeias de conexão em seu aplicativo, desde que os pontos de extremidade virtuais estejam configurados. Uma vez ativado, o ponto de extremidade do gravador reapontará para o novo primário em uma região diferente e a coluna de estado de replicação no portal do Azure exibirá "Reconfiguração". Depois que a região afetada for restaurada, o antigo servidor primário será retomado automaticamente, mas agora em uma função de réplica.
Promover para servidor independente e remover da replicação
Nesse caso, esta é a única opção viável. Depois de promover o servidor, você precisará atualizar as cadeias de conexão do aplicativo. 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.