Alta disponibilidade (Confiabilidade) no Banco de Dados do Azure para PostgreSQL – Servidor Flexível
APLICA-SE A:
Banco de Dados do Azure para PostgreSQL – Servidor Flexível
Esse artigo descreve a alta disponibilidade no Banco de Dados do Azure para PostgreSQL – Servidor Flexível, que inclui zonas de disponibilidade e continuidade dos negócios e recuperação entre regiões. Para obter uma visão geral mais detalhada da confiabilidade no Azure, confira Confiabilidade do Azure.
Banco de Dados do Azure para PostgreSQL - o Servidor Flexível oferece suporte de alta disponibilidade provisionando réplicas primárias e em espera fisicamente separadas dentro da mesma zona de disponibilidade (zonal) ou entre zonas de disponibilidade (com redundância de zona). Esse modelo de alta disponibilidade foi projetado para garantir que os dados confirmados nunca sejam perdidos no caso de falhas. O modelo também é projetado para que o banco de dados não se torne um ponto único de falha na arquitetura do seu software. Para obter mais informações sobre o suporte à zona de disponibilidade e à alta disponibilidade, consulte Suporte à zona de disponibilidade.
Suporte à zona de disponibilidade
As zonas de disponibilidade do Azure são pelo menos três grupos de datacenters separados fisicamente em cada região do Azure. Os datacenters dentro de cada zona são equipados com energia, resfriamento e infraestrutura de rede independentes. Em caso de falha de uma zona local, as zonas de disponibilidade foram projetadas de modo que, se uma zona é afetada, os serviços regionais, a capacidade e a alta disponibilidade têm suporte nas duas zonas restantes.
As falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. A tolerância a falhas é obtida devido à redundância e ao isolamento lógico dos serviços do Azure. Para obter informações detalhadas sobre as zonas de disponibilidade no Azure, confira Regiões e zonas de disponibilidade.
Os serviços habilitados para zonas de disponibilidade do Azure foram projetados para fornecer o nível ideal de resiliência e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ter redundância de zona, com replicação automática entre zonas, ou podem ser zonais, com instâncias fixadas em uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre a arquitetura zonal versus com redundância de zona, confira Recomendações para usar zonas e regiões de disponibilidade.
O Banco de Dados do Azure para PostgreSQL – Servidor Flexível dá suporte aos modelos zonais e com redundância de zona para configurações de alta disponibilidade. Ambas as configurações de alta disponibilidade habilita a funcionalidade de failover automático sem perda de dados durante eventos planejados ou não planejados.
Redundância de zona. A alta disponibilidade com redundância de zona implanta uma réplica em espera em uma zona diferente com a funcionalidade de failover automático. A redundância de zona oferece o nível mais alto de disponibilidade, mas exige que você configure a redundância do aplicativo entre as zonas. Por esse motivo, escolha a redundância de zona quando você quiser a proteção contra falhas no nível da zona de disponibilidade e quando a latência nas zonas de disponibilidade for aceitável.
Você pode escolher a região e as zonas de disponibilidade dos servidores em espera e primários. O servidor de réplica em espera é provisionado na zona de disponibilidade escolhida na mesma região com uma computação, armazenamento e configuração de rede parecidos com o servidor primário. Arquivos de dados e arquivos de log de transações (logs write-ahead também conhecido como WAL) são armazenados no LRS (armazenamento com redundância local) em cada zona de disponibilidade, armazenando automaticamente três cópias de dados. A configuração com redundância de zona fornece isolamento físico de toda a pilha entre servidores primários e em espera.
Zonal. Escolha uma implantação zonal quando você quiser obter o nível mais alto de disponibilidade em uma só zona de disponibilidade, mas com a latência de rede mais baixa. Você pode escolher a região e a zona de disponibilidade para implantar ambos os servidores de banco de dados primário. Um servidor de réplica em espera é automaticamente provisionado e gerenciado na mesma zona de disponibilidade com computação, armazenamento e configuração de rede semelhantes ao servidor primário. A configuração zonal protege seus bancos de dados contra falhas no nível de nó e também ajuda a reduzir o tempo de inatividade do aplicativo durante eventos de tempo de inatividade planejados e não planejados. Os dados do servidor primário são replicados para a réplica em espera no modo síncrono. No caso de qualquer interrupção no servidor primário, o servidor passará por failover automaticamente na réplica em espera.
Observação
Os dois modelos de implantação zonal e com redundância de zona se comportam arquitetonicamente da mesma forma. Várias discussões nas seções a seguir aplicam-se a ambas, a menos que seja indicado de outra forma.
Pré-requisitos
Redundância de Zona:
A opção de redundância de zona está disponível em regiões com suporte para zonas de disponibilidade.
Não há suporte para redundância de zona para:
- Banco de Dados do Azure para PostgreSQL – SKU de Servidor Único.
- Camada de computação com capacidade de intermitência.
- Regiões com disponibilidade de zona única.
Zonal:
- A opção de implantação zonal está disponível em todas as regiões do Azure em que é possível implantar o Servidor Flexível.
Recursos de alta disponibilidade
A réplica em espera é implantada na mesma configuração de VM, incluindo configurações de rede, vCores e armazenamento como o servidor primário.
Você pode adicionar suporte de zona de disponibilidade a um servidor de banco de dados existente.
Você pode de remover a réplica em espera desabilitando a alta disponibilidade.
Você pode escolher as zonas de disponibilidade para seus servidores de banco de dados primários e em espera para disponibilidade de redundância de zona.
Operações como parar, iniciar e reiniciar são executadas em servidores de banco de dados primários e em espera ao mesmo tempo.
Nos modelos zonal e com redundância de zona, os backups automáticos são executados periodicamente a partir do servidor de banco de dados primário. Ao mesmo tempo, os logs de transações são arquivados continuamente no armazenamento de backup da réplica em espera. Se a região der suporte a zonas de disponibilidade, os dados de backup serão armazenados no ZRS (armazenamento com redundância de zona). Em regiões que não dão suporte a zonas de disponibilidade, os dados de backup são armazenados no LRS (armazenamento com redundância local).
Os clientes sempre se conectam ao nome do host final do servidor de banco de dados primário.
Todas as alterações nos parâmetros do servidor também são aplicadas à réplica em espera.
Capacidade de reiniciar o servidor para selecionar qualquer alteração de parâmetro de servidor estático.
As atividades de manutenção periódica, como atualizações de versão secundárias, ocorrem em espera primeiro e, para reduzir o tempo de inatividade, o estado de espera é promovido a primário para que as cargas de trabalho possam continuar, enquanto as tarefas de manutenção são aplicadas no nó restante.
Limitações de alta disponibilidade
Devido à replicação síncrona para o servidor em espera, especialmente com configuração com redundância de zona, os aplicativos podem ter latência elevada de gravação e confirmação.
A réplica em espera não pode ser usada para consultas de leitura.
Dependendo da carga de trabalho e da atividade no servidor primário, o processo de failover pode demorar mais de 120 segundos devido à recuperação envolvida na réplica em espera para que possa ser promovido.
O servidor em espera normalmente recupera arquivos WAL a 40 MB/s. Se a carga de trabalho exceder esse limite, você poderá encontrar um tempo estendido para que a recuperação seja concluída durante o failover ou depois de estabelecer um novo em espera.
A configuração de zonas de disponibilidade induz alguma latência a gravações e confirmações, enquanto não produz nenhum impacto na leitura de consultas. O impacto no desempenho varia dependendo da carga de trabalho. Como diretriz geral, o impacto de gravações e de confirmação pode ter cerca de 20% a 30% de impacto.
Reiniciar o servidor de banco de dados primário também reinicia a réplica em espera.
Não há suporte para a configuração de um servidor em espera adicional.
A configuração de tarefas de gerenciamento iniciadas pelo cliente não pode ser agendada durante a janela de manutenção gerenciada.
Eventos planejados, como dimensionamento de computação e de armazenamento, ocorrem no servidor em espera primeiro e, em seguida, no servidor primário. Atualmente, o servidor não passou por failover para essas operações planejadas.
Se a decodificação lógica ou a replicação lógica estiver configurada com um servidor flexível configurado com disponibilidade, no caso de um failover para o servidor em espera, os slots de replicação lógica não serão copiados para o servidor em espera. Para manter os slots de replicação lógica e garantir a consistência de dados após um failover, é recomendável usar a extensão de Slots de Failover PG. Para obter mais informações sobre como habilitar essa extensão, consulte a documentação.
Não há suporte para a configuração de zonas de disponibilidade entre a VNET (privada) e o acesso público com pontos de extremidade privados. Você pode configurar as zonas de disponibilidade em uma VNET (distribuída entre zonas de disponibilidade de uma região) ou acesso público com pontos de extremidade privados.
As zonas de disponibilidade são configuradas somente em uma única região. As zonas de disponibilidade não podem ser configuradas entre regiões.
SLA
O modelo zonal oferece SLA de 99,95% de tempo de atividade.
O modelo de redundância de zona oferece SLA de 99,99% de tempo de atividade.
Criar um Banco de Dados do Azure para PostgreSQL – Servidor Flexível com zona de disponibilidade habilitada
Para saber como criar um Banco de Dados do Azure para PostgreSQL – Servidor Flexível para alta disponibilidade com zonas de disponibilidade, consulte Início Rápido: criar um Banco de Dados do Azure para PostgreSQL – Servidor Flexível no portal do Azure.
Reimplantação e migração da zona de disponibilidade
Para saber como habilitar ou desabilitar a configuração de alta disponibilidade em seu servidor flexível em modelos de implantação com redundância de zona e zonal, confira Gerenciar alta disponibilidade no Servidor Flexível.
Componentes e workflow de alta disponibilidade
Conclusão da transação
As gravações e as confirmações disparadas pela transação de aplicativo são registrados primeiro no WAL no servidor primário. Em seguida, elas são transmitidas para o servidor em espera usando o protocolo de streaming do Postgres. Depois que os logs são persistidos no armazenamento do servidor em espera, o servidor primário é confirmado para conclusão da gravação. Somente em seguida, o aplicativo é confirmado a confirmação de sua transação. Essa viagem de ida e volta adicional acrescenta mais latência ao aplicativo. O percentual de impacto depende do aplicativo. Esse processo de confirmação não aguarda que os logs sejam aplicados no servidor em espera. O servidor em espera está permanentemente no modo de recuperação até ser promovido.
Verificação de integridade
O servidor flexível tem um monitoramento de integridade periodicamente verificando a integridade do servidor primário e em espera. Após vários pings, se o monitoramento de integridade detectar que um servidor primário não é acessível, o serviço iniciará um failover automático para o servidor em espera. O algoritmo do monitoramento de integridade é baseado em vários pontos de dados para evitar situações de falso positivo.
Modos de failover
O servidor flexível dá suporte a dois modos de failover, Recuperação panejada e Recuperação não planejada. Nos dois modos, depois que a replicação é danificada, o servidor em espera executa a recuperação antes de ser promovido como primário e abre para leitura/gravação. Com as entradas DNS automáticas atualizadas com o novo ponto de extremidade do servidor primário, os aplicativos podem se conectar ao servidor usando o mesmo ponto de extremidade. Um novo servidor em espera é estabelecido em segundo plano e seu aplicativo conseguirá manter a conectividade.
Status da alta disponibilidade
A integridade dos servidores primários e em espera é monitorada continuamente e as ações apropriadas são executadas para resolver problemas, incluindo disparar um failover para o servidor em espera. A tabela a seguir lista os possíveis status de alta disponibilidade:
| Status | Descrição |
|---|---|
| Inicializando | No processo de criação de um servidor em espera. |
| Replicar dados | Depois que o servidor em espera é criado, ele é atualizado com o primário. |
| Healthy | A replicação está em estado estável e íntegro. |
| Fazer failover | O servidor de banco de dados está em processo de failover para o modo de espera. |
| Remover o servidor de espera | No processo de exclusão do servidor em espera. |
| Não habilitado | A alta disponibilidade não está habilitada. |
Observação
Você pode habilitar a alta disponibilidade durante a criação do servidor ou posteriormente. Se você estiver habilitando ou desabilitando a alta disponibilidade durante a fase de pós-criação, recomendamos executar a operação quando a atividade do servidor primário estiver baixa.
Operações de estado fixo
Os aplicativos cliente do PostgreSQL estão conectados ao servidor primário usando o nome do servidor do BD. As leituras do aplicativo são atendidas diretamente no servidor primário. As confirmações e as gravações são confirmadas no aplicativo somente depois que os dados de log são persistidos no servidor primário e na réplica em espera. Devido a esse requisito adicional de ida e volta, os aplicativos podem esperar uma latência elevada para gravações e confirmações. Você pode monitorar a integridade da alta disponibilidade no portal.
- Os clientes se conectam ao servidor flexível e executam operações de gravação.
- As alterações são replicadas para o site em espera.
- O primário recebe uma confirmação.
- Gravações/commits são confirmados.
Restauração pontual de servidores de alta disponibilidade
Para servidores flexíveis configurados com alta disponibilidade, os dados de log são replicados em tempo real para o servidor em espera. Os erros do usuário no servidor primário, como uma remoção acidental de uma tabela ou atualizações de dados incorretas, também são reproduzidos na réplica em espera. Portanto, não é possível usar em espera para se recuperar desses erros lógicos. Para se recuperar desses erros, você precisará executar a restauração pontual de backups. Você poderá restaurar para o momento anterior ao erro usando o recurso de restauração pontual do servidor flexível. Um novo servidor de banco de dados é restaurado como um servidor flexível de zona única com um nome do servidor fornecido pelo usuário para bancos de dados configurados com alta disponibilidade. Você pode usar o servidor restaurado para alguns casos de uso:
Você pode usar o servidor restaurado para produção e, opcionalmente, habilitar alta disponibilidade com réplica em espera na mesma zona ou em outra zona na mesma região.
Se você quiser restaurar um objeto, exporte-o do servidor de banco de dados restaurado e importe-o no servidor de banco de dados de produção.
Se você quiser clonar seu servidor de banco de dados para fins de teste e desenvolvimento ou restaurar para quaisquer outras finalidades, poderá executar restaurações pontuais.
Para saber como fazer uma restauração pontual de um servidor flexível, consulte Restauração pontual de um servidor flexível.
Suporte a Failover
Failover planejado
Os eventos de tempo de inatividade planejado incluem atualizações de versão secundária e atualizações de software periódicas agendadas do Azure. Você também pode usar uma recuperação panejada para retornar o servidor primário para uma zona de disponibilidade preferencial. Quando configuradas em alta disponibilidade, essas operações são aplicadas primeiro à réplica em espera, enquanto os aplicativos continuam a acessar o servidor primário. Depois que a réplica em espera for atualizada, as conexões do servidor primário serão esvaziadas e um failover será disparado, o que ativa a réplica em espera para ser a primária, com o mesmo nome do servidor de banco de dados. Os aplicativos clientes precisam se reconectar com o mesmo nome do servidor de banco de dados ao novo servidor primário e poderão retomar suas operações. Um novo servidor em espera será estabelecido na mesma zona que o primário antigo.
Para outras operações iniciadas pelo usuário, como computação de escala ou armazenamento de escala, as alterações são aplicadas primeiro no servidor de espera, seguido pelo primário. Atualmente, o serviço não faz failover para o servidor em espera e, portanto, enquanto a operação de escala é executada no servidor primário, os aplicativos terão um tempo de inatividade curto.
Você também pode usar esse recurso para fazer o failover para o servidor em espera com tempo de inatividade reduzido. Por exemplo, o primário pode estar em uma zona de disponibilidade diferente do aplicativo, após uma recuperação não planejada do que o aplicativo. Você deseja trazer o servidor primário de volta à zona anterior para colocar com seu aplicativo.
Ao executar esse recurso, o servidor em espera é preparado primeiro para garantir que ele esteja sincronizado com transações recentes, permitindo que o aplicativo continue a executar leituras/gravações. Em seguida, o servidor em espera é promovido, e as conexões com o primário são cortadas. Seu aplicativo pode continuar a gravar no primário enquanto um novo servidor em espera é estabelecido em segundo plano. A seguir estão as etapas envolvidas na recuperação planejada:
| Step | Descrição | Tempo de inatividade esperado do aplicativo? |
|---|---|---|
| 1 | Aguarde até que o servidor em espera tenha alcançado o primário. | Não |
| 2 | O sistema de monitoramento interno inicia o fluxo de trabalho de failover. | Não |
| 3 | As gravações do aplicativo são bloqueadas quando o servidor em espera está próximo ao LSN (número de sequência de log) primário. | Sim |
| 4 | O servidor em espera é promovido a servidor independente. | Sim |
| 5 | O registro DNS é atualizado com o novo endereço IP do servidor em espera. | Sim |
| 6 | Aplicativo para reconectar e retomar sua leitura/gravação com o novo primário. | Não |
| 7 | Um novo servidor em espera em outra zona é estabelecido. | Não |
| 8 | O servidor em espera começa a recuperar logs (do Blob do Azure) que ele perdeu durante seu estabelecimento. | Não |
| 9 | Um estado estável entre o servidor primário e o servidor em espera é estabelecido. | Não |
| 10 | O processo de failover planejado foi concluído. | No |
O tempo de inatividade do aplicativo começa na etapa #3 e pode retomar a operação após a etapa #5. O restante das etapas ocorre em segundo plano sem afetar as gravações e as confirmações do aplicativo.
Dica
Com o servidor flexível, você tem a opção de agendar atividades de manutenção iniciadas pelo Azure escolhendo uma janela de 60 minutos em um dia de sua preferência em que as atividades nos bancos de dados devem estar baixas. As tarefas de manutenção do Azure, como aplicação de patch ou atualizações de versão secundária, ocorrerão durante essa janela. Se você não escolher uma janela personalizada, uma janela de 1 hora alocada pelo sistema entre 23h e 7h do horário local é selecionada para o servidor. Essas atividades de manutenção iniciadas pelo Azure também são executadas na réplica em espera para os servidores flexíveis configurados com zonas de disponibilidade.
Para obter uma lista de possíveis eventos de tempo de inatividade planejados, consulte Eventos de tempo de inatividade planejados.
Failover não planejado
Os tempos de inatividade não planejados podem ocorrer como resultado de interrupções imprevisíveis, como falha de hardware subjacente, problemas de rede e bugs de software. Se o servidor de banco de dados configurado com alta disponibilidade falhar inesperadamente, a réplica em espera será ativada e os clientes poderão retomar as operações. Se não estiver configurado com alta disponibilidade (HA), se a tentativa de reinicialização falhar, um novo servidor de banco de dados será provisionado automaticamente. Embora um tempo de inatividade não planejado não possa ser evitado, o servidor flexível ajuda a reduzir o tempo de inatividade realizando automaticamente operações de recuperação sem exigir intervenção humana.
Para obter informações sobre recuperações não planejadas e tempo de inatividade, incluindo possíveis cenários, consulte Mitigação de tempo de inatividade não planejado.
Testes de failover (failover forçado)
Com um failover forçado, você pode simular um cenário de inatividade não planejada durante a execução da carga de trabalho de produção e observar o tempo de inatividade do aplicativo. Você também pode usar um failover forçado quando o servidor primário não responder.
Um failover forçado torna o servidor primário inativo e inicia o fluxo de trabalho de failover no qual a operação de promoção do servidor em espera é executada. Depois que o servidor em espera concluir o processo de recuperação até os últimos dados confirmados, ele será promovido a servidor primário. Os registros DNS são atualizados e seu aplicativo pode se conectar ao servidor primário promovido. Seu aplicativo pode continuar a gravar no servidor primário enquanto um novo servidor em espera é estabelecido em segundo plano, o que não afeta o tempo de atividade.
As etapas a seguir ocorrem durante o failover forçado:
| Step | Descrição | Tempo de inatividade esperado do aplicativo? |
|---|---|---|
| 1 | O servidor primário é interrompido logo após receber a solicitação de failover. | Sim |
| 2 | O aplicativo encontra tempo de inatividade à medida que o servidor primário está ocioso. | Sim |
| 3 | O sistema de monitoramento interno detecta a falha e inicia um failover para o servidor em espera. | Sim |
| 4 | O servidor em espera entra no modo de recuperação antes de ser totalmente promovido a um servidor independente. | Sim |
| 5 | O processo de failover aguarda a conclusão da recuperação em espera. | Sim |
| 6 | Quando o servidor está atualizado, o registro DNS é atualizado com o mesmo nome de host, mas usando o endereço IP do servidor em espera. | Sim |
| 7 | O aplicativo pode se reconectar ao novo servidor primário e retomar a operação. | Não |
| 8 | Um servidor em espera na zona preferencial é estabelecido. | Não |
| 9 | O servidor em espera começa a recuperar logs (do Blob do Azure) que ele perdeu durante seu estabelecimento. | No |
| 10 | Um estado estável entre o servidor primário e o servidor em espera é estabelecido. | Não |
| 11 | O processo de failover forçado foi concluído. | No |
Espera-se que o tempo de inatividade do aplicativo se inicie após a etapa #1 e persista até que a etapa #6 seja concluída. O restante das etapas ocorre em segundo plano sem afetar as gravações e confirmações do aplicativo.
Importante
O processo de failover de ponta a ponta inclui (a) fazer failover para o servidor em espera após a falha do primário e (b) estabelecer um novo servidor em espera em um estado estável. Como seu aplicativo incorre em tempo de inatividade até que o failover para o servidor em espera seja concluído, faça a medida do tempo de inatividade a partir da perspectiva do aplicativo/cliente em vez do processo geral de failover de ponta a ponta.
Considerações ao executar failovers forçados
O tempo de operação geral de ponta a ponta pode ser maior do que o tempo de inatividade real apresentado pelo aplicativo.
Importante
Sempre observe o tempo de inatividade pela perspectiva do aplicativo!
Não execute failovers consecutivos e imediatos. Aguarde pelo menos de 15 a 20 minutos entre os failovers, permitindo que o novo servidor em espera seja totalmente estabelecido.
É recomendável que você execute um failover forçado durante um período de baixa atividade para reduzir o tempo de inatividade.
Melhores prática para estatísticas do PostgreSQL após o failover
Após um failover do PostgreSQL, o principal mecanismo para manter o desempenho ideal do banco de dados envolve a compreensão das funções distintas das tabelas pg_statistic e pg_stat_*. A tabela pg_statistic abriga estatísticas de otimizador, que são cruciais para o planejador de consultas. Essas estatísticas incluem a distribuições de dados dentro das tabelas e permanecem intactas após um failover, garantindo que o planejador de consultas possa continuar a otimizar a execução da consulta efetivamente com base em informações precisas e históricas de distribuição de dados.
Por outro lado, as tabelas pg_stat_*, que registram as estatísticas de atividade, como o número de verificações, tuplas lidas e atualizações, são redefinidas após o failover. Um exemplo dessa tabela é pg_stat_user_tables, que controla a atividade de tabelas definidas pelo usuário. Essa redefinição foi projetada para refletir com precisão o estado operacional do novo primário, mas também significa a perda de métricas de atividade histórica que poderiam informar o processo de vácuo automático e outras eficiências operacionais.
Dada essa distinção, a melhor prática após um failover do PostgreSQL é executar ANALYZE. Essa ação atualiza as tabelas pg_stat_*, como pg_stat_user_tables, com novas estatísticas de atividade, ajudando o processo de vácuo automático e garantindo que o desempenho do banco de dados permaneça ideal em sua nova função. Essa etapa proativa faz a ponte entre a preservação das estatísticas essenciais do otimizador e a atualização das métricas de atividade para se alinhar ao estado atual do banco de dados.
Experiência de zona inoperante
Zonal: Para se recuperar de uma falha no nível da zona, você pode executar a restauração pontual usando o backup. Você pode escolher um ponto de restauração personalizado com a hora mais recente para restaurar os dados mais recentes. Um novo servidor flexível é implantado em outra zona não afetada. O tempo necessário para a restauração depende do backup anterior e do volume de logs de transações a serem recuperados.
Para obter mais informações sobre a restauração pontual, consulte Backup e restauração no Banco de Dados do Azure para PostgreSQL – Servidor Flexível.
Com redundância de zona: O servidor flexível faz failover automaticamente para o servidor em espera em 60 a 120s com nenhuma perda de dados.
Configurações sem zonas de disponibilidade
Embora não seja recomendável, você pode configurar seu servidor flexível sem a alta disponibilidade habilitada. Para servidores flexíveis configurados sem alta disponibilidade, o serviço oferece armazenamento com redundância local com três cópias de dados, backup com redundância de zona (em regiões onde há suporte), além de resiliência de servidor interna para reiniciar automaticamente um servidor com falha e realocar o servidor para outro nó físico. O SLA de 99,9% de tempo de atividade é oferecido nessa configuração. Durante eventos de recuperação planejados ou não planejados, se o servidor ficar inativo, o serviço manterá a disponibilidade dos servidores usando o seguinte procedimento automatizado:
- Uma nova VM de computação do Linux será provisionada.
- O armazenamento com os arquivos de dados é mapeado para a nova máquina virtual.
- O mecanismo de banco de dados PostgreSQL é colocado online na nova máquina virtual.
A imagem abaixo mostra a transição entre a falha da VM e de armazenamento.
Recuperação de desastre entre regiões e continuidade dos negócios
No caso de um desastre em toda a região, o Azure fornece proteção contra desastres geográficos grandes ou regionais com recuperação de desastre usando outra região. Para obter mais informações sobre a arquitetura de recuperação de desastre do Azure, confira Arquitetura de recuperação de desastre do Azure para Azure.
O servidor flexível fornece recursos que protegem dados e reduzem o tempo de inatividade para seus bancos de dado de missão crítica durante eventos de tempo de inatividade planejado e não planejado. Criado com base na infraestrutura do Azure que oferece resiliência e disponibilidade robustas, o servidor flexível oferece recursos de continuidade de negócios que fornecem proteção contra falhas, cumprem os requisitos de tempo de recuperação e reduzem a exposição à perda de dados. Ao arquitetar seus aplicativos, você deve considerar a tolerância ao tempo de inatividade, que é o RTO (objetivo de tempo de recuperação) e a exposição à perda de dados, que é o RPO (objetivo de ponto de recuperação). Por exemplo, um banco de dados comercialmente crítico requer requisitos de tempo de atividade mais rígidos que um banco de dados de teste.
Recuperação de desastre na geografia de várias regiões
Restauração e backup com redundância geográfica
O backup e a restauração com redundância geográfica fornece a capacidade de restaurar o servidor em uma região diferente em caso de desastre. Ela também fornece pelo menos 99,99999999999999% de durabilidade (16 noves) de objetos de backups em um determinado ano.
O backup com redundância geográfica só pode ser configurado no momento da criação do servidor. Quando o servidor é configurado com o backup com redundância geográfica, os dados de backup e os logs de transações são copiados para a região emparelhada de forma assíncrona por meio da replicação de armazenamento.
Para obter mais informações sobre o backup e a restauração com redundância geográfica, confira backup e restauração com redundância geográfica.
Réplicas de leitura
Réplicas de leitura entre regiões podem ser implantadas para proteger seus bancos de dados contra falhas no nível da região. As réplicas de leitura são atualizadas assincronamente usando a tecnologia de replicação física do PostgreSQL e podem atrasar o primário. Há suporte para réplicas de leitura nas camadas de computação de uso geral e otimizado para memória.
Para obter mais informações sobre recursos e considerações de réplica de leitura, confira Réplicas de leitura.
Detecção, notificação e gerenciamento de interrupção
Se o servidor estiver configurado com o backup com redundância geográfica, você poderá executar a restauração geográfica na região emparelhada. Um novo servidor é provisionado e recuperado para os últimos dados disponíveis que foram copiados para essa região.
Você também pode usar réplicas de leitura entre regiões. Em caso de falha na região, você pode executar a operação de recuperação de desastre promovendo sua réplica de leitura para ser um servidor autônomo de leitura gravável. Espera-se que o RPO seja de até 5 minutos (perda de dados possível), exceto no caso de falha regional grave quando o RPO pode estar próximo do retardo de replicação no momento da falha.
Para obter mais informações sobre a mitigação de tempo de inatividade não planejado e recuperação após o desastre regional, confira Mitigação de tempo de inatividade não planejado.