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
Este artigo descreve a alta disponibilidade no Banco de Dados do Azure para PostgreSQL - Servidor Flexível, que inclui zonas de disponibilidade, recuperação entre regiões e continuidade de negócios. Para obter uma visão geral mais detalhada da confiabilidade no Azure, consulte Confiabilidade do Azure.
O Banco de Dados do Azure para PostgreSQL - 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 (zona redundante). Esse modelo de alta disponibilidade foi projetado para garantir que os dados comprometidos nunca sejam perdidos em caso de falhas. O modelo também é projetado para que o banco de dados não se torne um único ponto de falha em sua arquitetura de software. Para obter mais informações sobre alta disponibilidade e suporte à zona de disponibilidade, consulte Suporte à zona de disponibilidade.
Suporte à zona de disponibilidade
As zonas de disponibilidade do Azure são pelo menos três grupos fisicamente separados de datacenters em cada região do Azure. Os datacenters dentro de cada zona são equipados com infraestrutura independente de energia, resfriamento e rede. No caso de uma falha de zona local, as zonas de disponibilidade são projetadas de modo que, se uma zona for afetada, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas 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 é alcançada com redundância e isolamento lógico dos serviços do Azure. Para obter informações mais detalhadas sobre zonas de disponibilidade no Azure, consulte Regiões e zonas de disponibilidade.
Os serviços habilitados para zonas de disponibilidade do Azure são projetados para fornecer o nível certo de confiabilidade e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ser redundantes de zona, com replicação automática entre zonas, ou zonais, com instâncias fixadas a uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre arquitetura zonal versus arquitetura com redundância de zona, consulte Recomendações para usar zonas e regiões de disponibilidade.
O Banco de Dados do Azure para PostgreSQL - Servidor Flexível dá suporte a modelos zonais e com redundância de zona para configurações de alta disponibilidade. Ambas as configurações de alta disponibilidade permitem a capacidade de failover automático com perda de dados zero durante eventos planejados e não planejados.
Zona redundante. A alta disponibilidade redundante de zona implanta uma réplica em espera em uma zona diferente com capacidade de failover automático. A redundância de zona fornece o mais alto nível de disponibilidade, mas exige que você configure a redundância de aplicativos entre zonas. Por esse motivo, escolha redundância de zona quando quiser 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 para servidores primários e em espera. O servidor de réplica em espera é provisionado na zona de disponibilidade escolhida na mesma região com uma configuração de computação, armazenamento e rede semelhante à do servidor primário. Os arquivos de dados e os arquivos de log de transações (write-ahead logs, também conhecido como WAL) são armazenados em armazenamento localmente redundante (LRS) dentro de cada zona de disponibilidade, armazenando automaticamente três cópias de dados. Uma 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 quiser atingir o mais alto nível de disponibilidade em uma única zona de disponibilidade, mas com a menor latência de rede. Você pode escolher a região e a zona de disponibilidade para implantar o servidor 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 - que o servidor primário. Uma configuração zonal protege seus bancos de dados contra falhas no nível do 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 failover do servidor é automaticamente transferido para a réplica em espera.
Nota
Os modelos de implantação com redundância zonal e de zona se comportam arquitetonicamente da mesma forma. Várias discussões nas seções a seguir se aplicam a ambos, salvo indicação em contrário.
Pré-requisitos
Redundância de zona:
A opção de redundância de zona só está disponível em regiões que suportam zonas de disponibilidade.
A redundância de zona não é suportada para:
- Banco de Dados do Azure para PostgreSQL – SKU de servidor único.
- Camada de computação Burstable .
- 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 onde você pode implantar o Servidor Flexível.
Recursos de alta disponibilidade
Uma réplica em espera é implantada na mesma configuração de VM - incluindo vCores, armazenamento, configurações de rede - que o servidor primário.
Você pode adicionar suporte à zona de disponibilidade para um servidor de banco de dados existente.
Você pode remover a réplica em espera desativando a alta disponibilidade.
Você pode escolher zonas de disponibilidade para seus servidores de banco de dados primários e em espera para disponibilidade com redundância de zona.
Operações como parar, iniciar e reiniciar são realizadas nos servidores de bases de dados principal e de reserva em simultâneo.
Em modelos zonais e com redundância de zona, os backups automáticos são realizados 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 a partir da réplica em espera. Se a região oferecer 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 oferecem suporte a zonas de disponibilidade, os dados de backup são armazenados no LRS (armazenamento redundante local).
Os clientes sempre se conectam ao nome do host final do servidor de banco de dados primário.
Quaisquer alterações nos parâmetros do servidor também são aplicadas à réplica em espera.
Capacidade de reiniciar o servidor para retomar quaisquer alterações aos parâmetros estáticos do servidor.
As atividades de manutenção periódicas, como atualizações secundárias de versão, acontecem primeiro no modo de espera e, para reduzir o tempo de inatividade, o modo 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.
Monitorar a integridade da alta disponibilidade
O monitoramento do status de integridade de Alta Disponibilidade (HA) no Banco de Dados do Azure para PostgreSQL - Servidor Flexível fornece uma visão geral contínua da integridade e da prontidão das instâncias habilitadas para HA. Esse recurso de monitoramento aproveita a estrutura RHC (Verificação de Integridade de Recursos) do Azure para detetar e alertar sobre quaisquer problemas que possam afetar a prontidão para failover ou a disponibilidade geral do banco de dados. Ao avaliar as principais métricas, como status da conexão, estado de failover e integridade da replicação de dados, o monitoramento do status de integridade do HA permite a solução de problemas proativa e ajuda a manter o tempo de atividade e o desempenho do banco de dados.
Os clientes podem usar o monitoramento do status de integridade da HA para:
- Obtenha informações em tempo real sobre a integridade das réplicas primárias e em espera, com indicadores de status que revelam possíveis problemas, como desempenho degradado ou bloqueio de rede.
- Configure alertas para notificações oportunas sobre quaisquer alterações no status do HA, garantindo uma ação imediata para lidar com possíveis interrupções.
- Otimize a prontidão para failover identificando e resolvendo problemas antes que eles afetem as operações do banco de dados.
Para obter um guia detalhado sobre como configurar e interpretar status de integridade de HA, consulte o artigo principal Monitoramento de status de integridade de alta disponibilidade (HA) para o Banco de Dados do Azure para PostgreSQL - Servidor flexível.
Limitações de alta disponibilidade
Devido à replicação síncrona para o servidor em espera, especialmente com uma configuração com redundância de zona, os aplicativos podem experimentar latência elevada de gravação e confirmação.
A réplica de reserva não pode ser utilizada para consultas de leitura.
Dependendo da carga de trabalho e da atividade no servidor primário, o processo de failover pode levar mais de 120 segundos devido à recuperação envolvida na réplica em espera antes de poder ser promovido.
O servidor em espera normalmente recupera arquivos WAL em 40 MB / s. Se sua 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 modo de espera.
A configuração para zonas de disponibilidade induz alguma latência para gravações e confirmações, enquanto não produz nenhum impacto na leitura de consultas. O impacto no desempenho varia consoante a sua carga de trabalho. Em geral, o impacto nas escritas e consolidações pode ser de 20 a 30%.
A reinicialização do 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 modo de espera extra.
A configuração de tarefas de gerenciamento iniciadas pelo cliente não pode ser agendada durante a janela de manutenção gerenciada.
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 essas operações planejadas.
Se a decodificação lógica ou a replicação lógica estiver configurada com um Servidor Flexível configurado para 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 dos dados após um failover, é recomendável usar a extensão PG Failover Slots. 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 acesso privado (VNET) e público com pontos de extremidade privados. Você deve configurar zonas de disponibilidade dentro de uma VNET (abrangendo zonas de disponibilidade dentro de uma região) ou acesso público com pontos de extremidade privados.
As zonas de disponibilidade são configuradas apenas dentro de uma única região. As zonas de disponibilidade não podem ser configuradas entre regiões.
SLA
O modelo Zonal oferece SLA de tempo de atividade de 99,95%.
O modelo de redundância de zona oferece SLA de tempo de atividade de 99,99%.
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 Guia de 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 zonal e com redundância de zona, consulte Gerenciar alta disponibilidade no servidor flexível.
Componentes de alta disponibilidade e fluxo de trabalho
Conclusão da transação
As gravações e confirmações acionadas por transações de aplicativos são primeiro registradas na WAL no servidor primário. Estes são então transmitidos para o servidor em espera usando o protocolo de streaming Postgres. Quando os logs são mantidos no armazenamento do servidor em espera, o servidor primário é reconhecido para conclusão de gravação. Só então o aplicativo é confirmado o commit de sua transação. Essa viagem adicional de ida e volta adiciona mais latência ao seu aplicativo. A percentagem de impacto depende da aplicação. Esse processo de confirmação não espera que os logs sejam aplicados ao servidor em espera. O servidor em espera está permanentemente no modo de recuperação até ser promovido.
Verificação de estado de funcionamento
O monitoramento flexível da integridade do servidor verifica periodicamente a integridade primária e a integridade em 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 integridade é baseado em vários pontos de dados para evitar situações de falso positivo.
Modos de failover
O servidor flexível suporta dois modos de failover, failover planejado e failover não planejado. Em ambos os modos, depois que a replicação é cortada, o servidor em espera executa a recuperação antes de ser promovido como primário e abre para leitura/gravação. Com 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, para que seu aplicativo possa manter a conectividade.
Estado de alta disponibilidade
A integridade dos servidores primários e em espera é monitorada continuamente e ações apropriadas são tomadas para corrigir problemas, incluindo o disparo de um failover para o servidor em espera. A tabela abaixo lista os possíveis status de alta disponibilidade:
| Estado | Descrição |
|---|---|
| Inicializando | No processo de criação de um novo servidor em espera. |
| Replicando dados | Depois que o modo de espera é criado, ele está alcançando o principal. |
| Saudável | A replicação está em estado estacionário e saudável. |
| Falha | O servidor de banco de dados está em processo de failover para o modo de espera. |
| Removendo o modo de espera | No processo de exclusão do servidor em espera. |
| Não ativado | A alta disponibilidade não está ativada. |
Nota
Você pode habilitar a alta disponibilidade durante a criação do servidor ou posteriormente também. Se você estiver habilitando ou desabilitando a alta disponibilidade durante o estágio pós-criação, é recomendável operar quando a atividade do servidor primário estiver baixa.
Operações no estado estacionário
Os aplicativos cliente PostgreSQL são conectados ao servidor primário usando o nome do servidor de banco de dados. As leituras de aplicativos são servidas diretamente do servidor primário. Ao mesmo tempo, confirmações e 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 essa viagem extra de ida e volta, os aplicativos podem esperar 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.
- A primária recebe um reconhecimento.
- As gravações/confirmações são reconhecidas.
Restauração point-in-time 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. Quaisquer erros do usuário no servidor primário, como uma queda acidental de uma tabela ou atualizações de dados incorretas, são replicados para a réplica em espera. Então, você não pode usar o modo de espera para se recuperar de tais erros lógicos. Para se recuperar de tais erros, você tem que executar uma restauração point-in-time a partir do backup. Usando o recurso de restauração point-in-time de um servidor flexível, você pode restaurar para o tempo anterior à ocorrência do erro. Um novo servidor de banco de dados é restaurado como um servidor flexível de zona única com um novo nome de 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 a alta disponibilidade com réplica em espera na mesma zona ou em outra zona na mesma região.
Se quiser restaurar um objeto, exporte-o do servidor de banco de dados restaurado e importe-o para o servidor de banco de dados de produção.
Se desejar clonar o servidor de banco de dados para fins de teste e desenvolvimento ou restaurar para quaisquer outros fins, você poderá executar a restauração point-in-time.
Para saber como fazer uma restauração point-in-time de um servidor flexível, consulte Restauração point-in-time de um servidor flexível.
Suporte a failover
Ativação pós-falha planeada
Os eventos de tempo de inatividade planejados incluem atualizações periódicas de software agendadas do Azure e atualizações de versões secundárias. Você também pode usar um failover planejado para retornar o servidor primário a 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 é atualizada, as conexões do servidor primário são drenadas e um failover é acionado, o que ativa a réplica em espera para ser a principal com o mesmo nome de servidor de banco de dados. Os aplicativos cliente precisam se reconectar com o mesmo nome de servidor de banco de dados ao novo servidor primário e podem retomar suas operações. Um novo servidor em espera é estabelecido na mesma zona que o antigo primário.
Para outras operações iniciadas pelo usuário, como computação em escala ou armazenamento em escala, as alterações são aplicadas primeiro no modo de espera, seguido pelo principal. Atualmente, não é feita a ativação pós-falha do serviço para o servidor de reserva, pelo que, embora a operação de dimensionamento seja realizada no servidor principal, as aplicações deparam-se com um breve período de inatividade.
Você também pode usar esse recurso para fazer failover para o servidor em espera com tempo de inatividade reduzido. Por exemplo, seu primário pode estar em uma zona de disponibilidade diferente do aplicativo, após um failover não planejado. Você deseja trazer o servidor primário de volta para a zona anterior para colocalizar com seu aplicativo.
Ao executar esse recurso, o servidor em espera é preparado primeiro para garantir que esteja atualizado com as transações recentes, permitindo que o aplicativo continue executando leituras/gravações. O modo de espera é então 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 com o failover planejado:
| Passo | Descrição | Tempo de inatividade do aplicativo esperado? |
|---|---|---|
| 1 | Aguarde que o servidor em espera tenha sido apanhado com o primário. | Não |
| 2 | O sistema de monitoramento interno inicia o fluxo de trabalho de failover. | Não |
| 3 | As gravações de aplicativos são bloqueadas quando o servidor em espera está próximo ao número de sequência de log primário (LSN). | Sim |
| 4 | O servidor em espera é promovido a servidor independente. | Sim |
| 5 | O registro DNS é atualizado com o endereço IP do novo 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 está concluído. | Não |
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 acontece em segundo plano sem afetar as gravações e confirmações do aplicativo.
Gorjeta
Com o servidor flexível, você pode, opcionalmente, agendar atividades de manutenção iniciadas pelo Azure escolhendo uma janela de 60 minutos em um dia de sua preferência em que se espera que as atividades nos bancos de dados sejam baixas. Tarefas de manutenção do Azure, como patches ou atualizações de versões secundárias, aconteceriam durante essa janela. Se você não escolher uma janela personalizada, uma janela de 1 hora alocada pelo sistema entre 23h e 7h no horário local será selecionada para o seu servidor. Essas atividades de manutenção iniciadas pelo Azure também são executadas na réplica em espera para 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.
Ativação pós-falha não planeada
Tempos de inatividade não planejados podem ocorrer como resultado de interrupções imprevistas, como falha de hardware subjacente, problemas de rede e bugs de software. Se o servidor de banco de dados configurado com alta disponibilidade cair inesperadamente, a réplica em espera será ativada e os clientes poderão retomar suas 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 executando automaticamente as operações de recuperação sem a necessidade de intervenção humana.
Para obter informações sobre failovers não planejados e tempo de inatividade, incluindo cenários possíveis, consulte Reduçã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 interrupção não planejada enquanto executa sua 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 deixar de responder.
Um failover forçado derruba o servidor primário e inicia o fluxo de trabalho de failover no qual a operação de promoção em espera é executada. Assim que o modo de 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 primário enquanto um novo servidor em espera é estabelecido em segundo plano, o que não afeta o tempo de atividade.
A seguir estão as etapas durante o failover forçado:
| Passo | Descrição | Tempo de inatividade do aplicativo esperado? |
|---|---|---|
| 1 | O servidor primário é interrompido logo após receber a solicitação de failover. | Sim |
| 2 | O aplicativo encontra tempo de inatividade quando o servidor primário está inativo. | Sim |
| 3 | O sistema de monitoramento interno deteta 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 como um servidor independente. | Sim |
| 5 | O processo de failover aguarda a conclusão da recuperação em espera. | Sim |
| 6 | Quando o servidor estiver ativo, o registro DNS será atualizado com o mesmo nome de host, mas usando o endereço IP do modo de 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. | Não |
| 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 está concluído. | Não |
Espera-se que o tempo de inatividade do aplicativo comece após a etapa #1 e persista até que a etapa #6 seja concluída. O restante das etapas acontece em segundo plano sem afetar as gravações e confirmações do aplicativo.
Importante
O processo de failover de ponta a ponta inclui (a) failover para o servidor em espera após a falha principal e (b) estabelecimento de um novo servidor em espera em um estado estacionário. Como seu aplicativo incorre em tempo de inatividade até que o failover para o modo de espera seja concluído, meça o tempo de inatividade da perspetiva do seu aplicativo/cliente em vez do processo geral de failover de ponta a ponta.
Considerações ao executar failovers forçados
O tempo geral de operação de ponta a ponta pode ser visto como maior do que o tempo de inatividade real experimentado pelo aplicativo.
Importante
Observe sempre o tempo de inatividade do ponto de vista da aplicação!
Não execute failovers imediatos e consecutivos. Aguarde pelo menos 15 a 20 minutos entre failovers, permitindo que o novo servidor em espera seja totalmente estabelecido.
É recomendável executar um failover forçado durante um período de baixa atividade para reduzir o tempo de inatividade.
Práticas recomendadas para estatísticas do PostgreSQL após 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 pg_statistic tabela abriga estatísticas do otimizador, que são cruciais para o planejador de consultas. Essas estatísticas incluem distribuições de dados dentro de tabelas e permanecem intactas após um failover, garantindo que o planejador de consultas possa continuar a otimizar a execução de consultas de forma eficaz com base em informações precisas e históricas de distribuição de dados.
Por outro lado, as pg_stat_* tabelas, que registram estatísticas de atividade, como o número de varreduras, tuplas lidas e atualizações, são redefinidas após o failover. Um exemplo de tal tabela é pg_stat_user_tables, que rastreia a atividade para 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 históricas de atividade que poderiam informar o processo de vácuo automático e outras eficiências operacionais.
Dada essa distinção, a prática recomendada após um failover do PostgreSQL é executar ANALYZEo . Esta ação atualiza as pg_stat_* tabelas, 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 ótimo em sua nova função. Essa etapa proativa preenche a lacuna entre a preservação das estatísticas essenciais do otimizador e a atualização das métricas de atividade para alinhá-las com o estado atual do banco de dados.
Experiência de zone-down
Zonal: Para se recuperar de uma falha no nível da zona, você pode executar a restauração point-in-time 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 restaurar depende do backup anterior e do volume de logs de transações a serem recuperados.
Para obter mais informações sobre restauração point-in-time, consulte Backup e restauração no Banco de Dados do Azure para Servidor Flexível PostgreSQL.
Redundante de zona: o servidor flexível é automaticamente transferido para o servidor em espera dentro de 60-120 segundos com perda de dados zero.
Configurações sem zonas de disponibilidade
Embora não seja recomendado, você pode configurar seu servidor flexível sem alta disponibilidade habilitada. Para servidores flexíveis configurados sem alta disponibilidade, o serviço fornece armazenamento redundante local com três cópias de dados, backup com redundância de zona (em regiões onde é suportado) e resiliência de servidor integrada para reiniciar automaticamente um servidor com falha e realocar o servidor para outro nó físico. O SLA de uptime de 99,9% é oferecido nesta configuração. Durante eventos de failover 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 Linux de computação é provisionada.
- O armazenamento com 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 VM e falha de armazenamento.
Recuperação de desastres entre regiões e continuidade de negócios
No caso de um desastre em toda a região, o Azure pode fornecer proteção contra desastres regionais ou de grande porte geográfico com recuperação de desastres usando outra região. Para obter mais informações sobre a arquitetura de recuperação de desastres do Azure, consulte Arquitetura de recuperação de desastres do Azure para Azure.
O servidor flexível fornece recursos que protegem os dados e reduzem o tempo de inatividade de seus bancos de dados de missão crítica durante eventos de tempo de inatividade planejados e não planejados. 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, atendem aos 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 - o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e a exposição à perda de dados - o RPO (Recovery Point Objetive, objetivo de ponto de recuperação). Por exemplo, seu banco de dados crítico para os negócios requer um tempo de atividade mais rigoroso do que um banco de dados de teste.
Recuperação de desastres em geografia de várias regiões
Backup e restauração com redundância geográfica
O backup e a restauração com redundância geográfica oferecem a capacidade de restaurar o servidor em uma região diferente em caso de desastre. Ele também fornece pelo menos 99,999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
O backup com redundância geográfica pode ser configurado somente no momento da criação do servidor. Quando o servidor é configurado com 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 backup e restauração com redundância geográfica, consulte 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 de forma assíncrona usando a tecnologia de replicação física do PostgreSQL e podem atrasar a principal. As réplicas de leitura são suportadas em camadas de computação otimizadas para fins gerais e memória.
Para obter mais informações sobre recursos e considerações de réplica de leitura, consulte Ler réplicas.
Deteção, notificação e gerenciamento de interrupções
Se o servidor estiver configurado com 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 esta região.
Você também pode usar réplicas de leitura entre regiões. Em caso de falha de região, você pode executar a operação de recuperação de desastres promovendo sua réplica de leitura para ser um servidor autônomo que pode ser gravado em leitura. 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 atraso de replicação no momento da falha.
Para obter mais informações sobre a redução e recuperação de tempo de inatividade não planejado após um desastre regional, consulte Mitigação de tempo de inatividade não planejado.