Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
APLICÁVEL A:
Azure Database para PostgreSQL - Servidor Flexível
Este artigo descreve a alta disponibilidade no Banco de Dados do Azure para PostgreSQL - Servidor Flexível, que inclui zonasde 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. Em uma configuração de alta disponibilidade (HA), os dados são confirmados de forma síncrona no servidor primário e no de backup. O modelo é 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 são grupos fisicamente separados de datacenters dentro de cada região do Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.
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. Embora possa haver algum impacto de latência nas gravações e confirmações devido à replicação síncrona, isso não afeta as consultas de leitura. Esse impacto é muito específico para suas cargas de trabalho, o tipo de SKU selecionado e a região.
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 redundante por zona proporciona isolamento físico de toda a pilha entre servidores primários e secundários.
A opção com redundância de zona só está disponível em regiões que têm suporte para zonas de disponibilidade.
Não há suporte para redundante de zona para:
- Camada de computação Burstable .
- Regiões com disponibilidade de zona única.
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 servidor é automaticamente redirecionado para a réplica em espera.
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.
Nota
Os modelos de implantação zoneados e com redundância de zona comportam-se da mesma forma do ponto de vista arquitetónico. Várias discussões nas seções a seguir se aplicam a ambos, salvo indicação em contrário.
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.
Nota
Para garantir que High-Availability (HA) funcione corretamente, deve configurar os parâmetros max_replication_slots e os valores do servidor max_wal_senders. High-Availability requer 4 de cada para lidar com failovers e upgrades sem interrupções. Para uma configuração de HA com 5 réplicas de leitura e 12 slots de replicação lógica, deve-se definir ambos os valores de parâmetro max_replication_slots e max_wal_senders como 21. Isso ocorre porque cada réplica de leitura e slot de replicação lógica requer um de cada um, mais os 4 necessários para que High-Availability funcione corretamente. Para saber mais sobre max_replication_slots e max_wal_senders parâmetros, consulte a documentação.
Monitorizar a saúde 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 a monitorização do estado 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 os status de integridade de HA, consulte o artigo principal Monitorização 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 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 transferência pode levar mais de 120 segundos devido ao processo de recuperação na réplica em espera antes de poder ser ativada.
O servidor em espera normalmente recupera arquivos WAL em 40 MB / s. Para SKUs maiores, essa taxa pode aumentar para até 200 MB/s. Se a sua carga de trabalho exceder este limite, poderá enfrentar um tempo prolongado para que a recuperação seja concluída, quer durante o failover, quer após estabelecer um novo standby.
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 rede virtual (distribuídas por zonas de disponibilidade dentro de uma região) ou escolher o 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.
Acordo de Nível de Serviço (SLA)
O modelo de redundância de zona oferece um SLA de tempo de atividade garantido 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.
Redistribuiçã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 persistidos no armazenamento do servidor secundário, o servidor primário é notificado sobre a conclusão da escrita. Só então é confirmado o Commit da transação da aplicaçã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 saúde
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 mudança de função, mudança de função planeada e mudança de função não planeada. 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 de reserva. |
| Replicando dados | Após a criação do modo de espera, está a par com 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 eliminaçã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 monitorizar 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 secundário.
- A primária recebe um reconhecimento.
- As escritas/confirmações são reconhecidas.
Restauração em um ponto específico no tempo 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
Alternância 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 é feito o failover do serviço para o servidor standby, pelo que, embora a operação de dimensionamento seja realizada no servidor principal, as aplicações enfrentam um curto 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 ser colocado junto com a sua aplicação.
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. A sua aplicação 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 de espera se tenha sincronizado com o primário. | Não |
| 2 | O sistema de monitorização interna inicia o fluxo de trabalho de failover. | Não |
| 3 | As escritas de aplicativos são bloqueadas quando o servidor em espera está próximo ao número de sequência de log principal (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 de espera noutra zona foi estabelecido. | Não |
| 8 | O servidor de espera começa a recuperar logs (do Blob do Azure) que perdeu durante a sua configuração. | 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.
Sugestão
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.
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 falhas não planeadas e interrupções, incluindo cenários possíveis, consulte Mitigação de interrupções não planeadas.
Testes de alternância de falha (alternância de falha forçada)
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 desativa o servidor primário e inicia o fluxo de trabalho de failover, no qual a operação de promoção do servidor de reserva é realizada. Assim que o servidor de espera concluir o processo de restauro até aos ú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. O seu aplicativo pode continuar a escrever no servidor primário enquanto um novo servidor de contingência é configurado em segundo plano, sem impactar 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 | A aplicação enfrenta uma interrupção porque o servidor principal está fora de serviço. | 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 de espera começa a recuperar logs (do Blob do Azure) que perdeu durante a sua configuração. | 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 comutação de ponta a ponta inclui (a) a comutação para o servidor em espera após a falha primária e (b) o estabelecimento de um novo servidor em espera em estado estável. Como seu aplicativo incorre em tempo de inatividade até que o failover para o servidor de reserva seja concluído, por favor, meça o tempo de inatividade do ponto de vista do seu aplicativo/cliente em vez de medir o processo geral de failover de ponta a ponta.
Considerações ao realizar 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 esta distinção, a prática recomendada após um failover do PostgreSQL é executar ANALYZE. 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 redução de zona
Zonal: Para recuperar de uma falha ao nível da zona, 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 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 Servidor Flexível do Azure para PostgreSQL.
Com redundância de zona: o servidor flexível faz failover automaticamente para o servidor em espera dentro de 60 a 120 segundos sem perda de dados.
Configurações sem zonas de disponibilidade
Embora não seja recomendado, é possível configurar o seu servidor flexível sem a alta disponibilidade ativada. 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. Nesta configuração, oferecemos um uptime de 99,9% garantido pelo SLA. 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,99999999999999 por cento (16 noves) de durabilidade de objetos de backup ao longo de um ano.
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 de propósito geral e em camadas otimizadas para memória.
Para obter mais informações sobre as funcionalidades e considerações das réplicas de leitura, consulte Réplicas de leitura.
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 com base nos últimos dados disponíveis que foram copiados para esta região.
Pode também usar réplicas de leitura em regiões diferentes. Em caso de falha de região, pode executar a operação de recuperação de desastres configurando a sua réplica de leitura como um servidor autónomo com capacidade de leitura e escrita. 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.