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 que o servidor primário ou em uma região geográfica diferente. A replicação geográfica pode ser útil para cenários como o planejamento de recuperação de desastres ou para trazer dados mais próximos dos seus 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 dê suporte ao servidor flexível do Banco de Dados do Azure para PostgreSQL. Além disso, damos suporte a regiões especiais do Azure Governamental e do Microsoft Azure operadas pela 21Vianet.
Regiões emparelhadas para fins de recuperação de desastre
Embora seja possível criar réplicas em qualquer região com suporte, há benefícios importantes em escolher réplicas em regiões emparelhadas, especialmente quando se está projetando para fins de recuperação de desastre:
Sequência de recuperação de região: em uma interrupção de toda a geografia, prioriza-se a recuperação de uma região de cada conjunto emparelhado, garantindo que os aplicativos entre regiões emparelhadas sempre tenham uma região agilizada para recuperação.
Atualização sequencial: as atualizações de regiões emparelhadas são escalonadas cronologicamente, minimizando o risco de tempo de inatividade por 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 eventos significativos sofrerem interrupções simultâneas.
Residência de dados: com algumas exceções, as regiões em um conjunto emparelhado residem na 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 de dados e a experiência do usuário, nem sempre elas são as regiões com a menor latência total. Se o objetivo principal é fornecer dados mais próximos aos usuários em vez de priorizar a recuperação de desastre, avaliar todas as regiões disponíveis para latência é essencial. Em alguns casos, uma região não emparelhada pode apresentar a menor latência. Para obter uma reconhecimento maior, você pode referenciar os números de latência de viagem ida e volta do Azure para fazer uma escolha esclarecida.
Para obter uma reconhecimento mais detalhado das vantagens das regiões emparelhadas, consulte a documentação do Azure sobre replicação entre regiões.
Falhas regionais e recuperação
As instalações do Azure em diversas regiões foram criadas para serem altamente confiáveis. No entanto, em circunstâncias raras, uma região inteira pode se tornar inacessível por motivos que vão desde falhas de rede até cenários graves, como desastres 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 atinja outras.
Preparação 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: é fundamental ter uma réplica de leitura configurada em uma região separada do primário. Isso garante continuidade, caso a região primária enfrente uma interrupção.
- Garantir a simetria de servidor: a ação "promover para servidor primário" é a mais recomendada para lidar com as interrupções regionais, mas ela exige um requisito de simetria do servidor. Isso significa que os servidores primários e de réplica devem ter configurações idênticas de certas configurações. Estas são algumas vantagens de usar essa ação:
- Não é necessário modificar cadeias de conexão de aplicativo se você usar pontos de extremidade virtuais.
- Isso fornece um processo de recuperação contínuo em que, depois que a região afetada estiver online novamente, o servidor primário original retomará 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 aplicativo para outra região, caso ocorra uma interrupção. Isso elimina a necessidade de fazer alterações nas cadeias de conexão do 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.
- Preparar para HA (alta disponibilidade): se sua configuração exigir alta disponibilidade, ela não será habilitada automaticamente em uma réplica promovida. Prepare-se para ativar isso após a promoção. É aconselhável automatizar essa etapa para minimizar o tempo de inatividade.
- Testes regulares: simule regularmente cenários de desastre regional para validar limites, destinos e configurações existentes. Verifique se o aplicativo responde conforme o esperado durante esses cenários de teste.
- Siga as diretrizes gerais do Azure: o Azure fornece diretrizes amplas sobre a confiabilidade e preparação para desastres. Consultar esses recursos e integrar as melhores práticas ao seu plano de preparação é altamente benéfico.
Ser proativo e estar preparado para desastres regionais garante a resiliência e a confiabilidade de seus aplicativos e dados.
Quando as interrupções afetam o 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 ameaça o SLA (contrato de nível de serviço) do aplicativo, lembre-se de que ambas as ações discutidas abaixo não são controladas pelo serviço. A intervenção do usuário é necessária nos dois casos. É uma melhor prática automatizar todo o processo o máximo possível e ter em vigor um monitoramento robusto. Para obter mais informações sobre quais informações são fornecidas durante uma interrupção, confira a página Interrupção do serviço. Em um cenário de região inoperante é possível aplicar somente uma promoção forçada, o que significa que a quantidade de perda de dados é aproximadamente igual ao retardo atual entre a réplica e o primário. Portanto, é crucial monitorar o retardo. 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. Depois de ativado, o ponto de extremidade de gravador será renomeado para o novo primário em uma região diferente e a coluna de estado de replicação no portal do Azure exibirá "Reconfigurando". Depois que a região afetada for restaurada, o servidor primário antigo será retomado automaticamente, mas dessa vez em uma função de réplica.
Promover para servidor independente e remover da replicação
Nesse caso, essa é a única opção viável. Depois de promover o servidor, você precisará atualizar as cadeias de conexão do aplicativo. Assim que a região original for restaurada, o primário antigo poderá ficar ativa novamente. Não deixe de removê-la para evitar a geração de custos desnecessários. Se desejar manter a topologia anterior, recrie a réplica de leitura.