Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo descreve a alta disponibilidade no Banco de Dados do Azure para PostgreSQL, que inclui zonas de disponibilidade e recuperação entre regiões e continuidade dos negócios. Para obter uma visão geral mais detalhada da confiabilidade no Azure, consulte a confiabilidade do Azure.
O Banco de Dados do Azure para PostgreSQL dá suporte à 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 durante falhas. Em uma configuração de alta disponibilidade (HA), os dados são confirmados de forma síncrona com os servidores primários e em espera. O modelo foi projetado para que o banco de dados não se torne um ponto único de falha em sua arquitetura de 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 são grupos fisicamente separados de datacenters em cada região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.
O Banco de Dados do Azure para PostgreSQL dá suporte a 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 fornece o nível mais alto de disponibilidade, mas você precisa configurar a redundância de aplicativo entre 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. 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 é 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 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 de gravação antecipada, também conhecidos como WAL) são armazenados em 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.
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 redundância de zona para:
Camada de computação com capacidade de intermitência
Regiões com disponibilidade de zona única
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. caso ocorra alguma interrupção no servidor primário, o sistema fará uma transferência automática para a réplica em espera.
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.
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.
Configurar resiliência zonal no portal
Você pode configurar a HA (alta disponibilidade) de duas maneiras: HA com redundância de zona, que coloca o servidor em espera em uma zona de disponibilidade diferente para resiliência máxima ou HA da mesma zona, que implanta o servidor em espera na mesma zona que o servidor primário para minimizar a latência.
Para simplificar a configuração e garantir a resiliência zonal, o portal fornece uma opção de Resiliência Zonal com dois botões de opção: Habilitado e Desabilitado. Selecionar Habilitado tenta criar o servidor em espera em uma zona de disponibilidade diferente (modo de alta disponibilidade com redundância de zona). Se a região não der suporte à HA com redundância de zona, você poderá marcar a caixa de seleção de fallback (realçada na imagem a seguir) para habilitar a HA da mesma zona.
Quando você seleciona a caixa de seleção de contingência, o sistema cria o servidor em espera na mesma zona. Se a capacidade zonal mais tarde ficar disponível, o Azure notificará você para que você possa optar por migrar para uma configuração de HA com redundância de zona usando PITR ou réplicas de leitura. Se você não selecionar a caixa de seleção e a capacidade zonal não estiver disponível, a habilitação de HA falhará. Esse design impõe a HA com redundância de zona como padrão, fornecendo um fallback controlado para HA da mesma zona, garantindo que as cargas de trabalho eventualmente alcancem resiliência de zona completa sem intervenção manual.
Recursos de alta disponibilidade
Uma réplica em espera é implantada na mesma configuração de VM - incluindo vCores, armazenamento e configurações de rede - 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.
Em modelos zonais e com redundância de zona, o servidor de banco de dados primário executa periodicamente backups automáticos. Ao mesmo tempo, a réplica em espera arquiva continuamente os logs de transação no armazenamento de backup. 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.
Você pode reiniciar o servidor para pegar as alterações de parâmetro do servidor estático.
As atividades de manutenção periódica, como atualizações de versão secundária, ocorrem primeiro em espera. Para reduzir o tempo de inatividade, a instância em espera é promovida como primária para que as cargas de trabalho continuem enquanto as tarefas de manutenção são aplicadas no nó restante.
Observação
Para garantir que a alta disponibilidade funcione corretamente, configure os valores dos parâmetros do servidor max_replication_slots e max_wal_senders. A alta disponibilidade requer quatro unidades de cada para lidar com failovers e atualizações sem interrupção. Para uma configuração de alta disponibilidade com cinco réplicas de leitura e 12 slots de replicação lógica, defina tanto o valor do parâmetro max_replication_slots quanto o max_wal_senders como 21. Essa configuração é necessária porque cada réplica de leitura e cada slot de replicação lógica exigem um de cada recurso, além dos quatro recursos necessários para garantir que a alta disponibilidade funcione corretamente. Para obter mais informações sobre max_replication_slots e max_wal_senders parâmetros, consulte a documentação.
Monitorar a saúde de alta disponibilidade
O monitoramento de status de integridade de alta disponibilidade (HA) no Banco de Dados do Azure para PostgreSQL fornece uma visão geral contínua da integridade e da preparação das instâncias habilitadas para HA. Esse recurso de monitoramento aplica a estrutura RHC (Resource Health Check) do Azure para detectar e alertar sobre quaisquer problemas que possam afetar a preparação de failover do banco de dados ou a disponibilidade geral. Ao avaliar as principais métricas, como status da conexão, estado de failover e integridade da replicação de dados, o monitoramento de status de integridade de HA permite a solução de problemas proativa e ajuda a manter o tempo de atividade e o desempenho do banco de dados.
Utilize o monitoramento do status de integridade de HA para:
- Obtenha insights em tempo real sobre a integridade de 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 de HA, para que você possa tomar medidas imediatas para resolver possíveis interrupções.
- Otimize a preparação para failover identificando e resolvendo problemas antes que eles afetem as operações de banco de dados.
Para obter um guia detalhado sobre como configurar e interpretar o status de integridade de HA, confira Monitoramento de status de integridade de alta disponibilidade (HA) para o Banco de Dados do Azure para PostgreSQL.
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 de gravação e confirmação elevadas.
Você não pode usar a réplica em espera 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, pois a réplica em espera precisa se recuperar antes de ser promovida.
O servidor em espera normalmente recupera arquivos WAL a 40 MB/s. Para versões maiores, essa taxa pode aumentar para até 200 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 estado em espera.
Reiniciar o servidor de banco de dados primário também reinicia a réplica em espera.
Você não pode configurar um espera extra.
Você não pode agendar tarefas de gerenciamento iniciadas pelo cliente durante a janela de manutenção gerenciada.
Eventos planejados, como computação em escala e armazenamento em escala, ocorrem primeiro em espera e, em seguida, no servidor primário. Atualmente, o servidor não passou por failover para essas operações planejadas.
Se você configurar a decodificação lógica ou a replicação lógica em um servidor flexível habilitado para HA:
- No PostgreSQL 16 e versões anteriores, os slots de replicação lógica não são preservados no servidor em espera após um failover por padrão.
- Para garantir que a replicação lógica continue funcionando após o failover, você precisa habilitar a
pg_failover_slotsextensão e definir configurações de suporte, comohot_standby_feedback = on. - A partir do PostgreSQL 17, há suporte para sincronização de slot nativamente. Se você habilitar as configurações corretas do PostgreSQL (
sync_replication_slots,hot_standby_feedback), os slots de replicação lógica serão preservados automaticamente após o failover e nenhuma extensão será necessária. - Para obter as etapas de instalação e os pré-requisitos, consulte a documentação da extensão PG_Failover_Slots.
Não há suporte para a configuração de zonas de disponibilidade entre acesso privado (rede virtual) e público com pontos de extremidade privados. Você deve configurar zonas de disponibilidade em uma rede virtual (abrangidas por zonas de disponibilidade dentro de uma região) ou acesso público por meio de endpoints privados.
Você só pode configurar zonas de disponibilidade em uma única região. Não é possível configurar zonas de disponibilidade entre regiões.
contrato de nível de serviço
O modelo Zonal oferece tempo de atividade para a SLA por aproximadamente 99.95%.
O modelo de redundância de zona oferece um tempo de atividade de aproximadamente 99,99% para um SLA.
Criar um Banco de Dados do Azure para PostgreSQL com a zona de disponibilidade habilitada
Para saber como criar um Banco de Dados do Azure para PostgreSQL para alta disponibilidade com zonas de disponibilidade, consulte Início Rápido: Criar um Banco de Dados do Azure para PostgreSQL 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 e fluxo de trabalho de alta disponibilidade
Conclusão da transação
Uma transação de aplicativo dispara uma gravação e confirma que primeiro faz logon no WAL no servidor primário. O servidor primário transmite esses logs para o servidor em espera usando o protocolo de streaming postgres. Quando o armazenamento do servidor de espera guarda os logs, o servidor primário confirma a conclusão do registro. O aplicativo confirma sua transação somente após essa confirmação. Essa viagem de ida e volta extra adiciona latência ao seu aplicativo. A porcentagem 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 permanece no modo de recuperação até ser promovido.
Verificação de saúde
O monitoramento de integridade do servidor flexível verifica periodicamente a integridade do servidor primário e de reserva. Após vários pings, se o monitoramento de integridade detectar que um servidor primário não é acessível, o serviço inicia um failover automático para o servidor em espera. O algoritmo de monitoramento de saúde usa 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. Em ambos os modos, uma vez que a replicação é interrompida, o servidor de espera executa a recuperação antes de ser promovido a primário e é aberto para operações de 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 e seu aplicativo conseguirá manter a conectividade.
Status de alta disponibilidade
O sistema monitora continuamente a integridade de servidores primários e em espera. Ele toma as ações apropriadas para corrigir problemas, incluindo executar 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. |
| Replicando dados | Depois que o servidor em espera é criado, ele é atualizado com o primário. |
| Íntegro | A replicação está em estado estável e íntegro. |
| Failover em progresso | 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 em um momento posterior. Se você habilitar ou desabilitar a alta disponibilidade durante o estágio pós-criação, faça isso quando a atividade no servidor primário estiver baixa.
Operações de estado estável
Os aplicativos cliente PostgreSQL conectam-se ao servidor primário usando o nome do servidor DB. O servidor primário atende diretamente às leituras do aplicativo. Ao mesmo tempo, o aplicativo recebe a confirmação dos commits e realiza a gravação somente depois de os dados de log serem 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.
- As gravações e confirmações são reconhecidas.
Restauração pontual de servidores de alta disponibilidade
Para servidores flexíveis configurados com alta disponibilidade, o sistema replica os dados de log em tempo real para o servidor em espera. Todos os erros de 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. Portanto, você não pode usar o modo de espera para se recuperar desses erros lógicos. Para se recuperar desses erros, você deve executar uma restauração em um ponto no tempo a partir do backup. Usando a funcionalidade de restauração pontual de um servidor flexível, você pode restaurar até o momento antes do erro ocorrer. 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 vários casos de uso:
Use o servidor restaurado para produção e, opcionalmente, habilite a 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 ao failover
Recuperação planejada
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 você configura a alta disponibilidade, essas operações se aplicam primeiro à réplica em espera enquanto os aplicativos continuam a acessar o servidor primário. Depois que o processo atualiza a réplica em espera, ela drena as conexões do servidor primário e dispara um failover que ativa a réplica em espera como o servidor primário com o mesmo nome do servidor de banco de dados. Os aplicativos cliente se reconectam com o mesmo nome do servidor de banco de dados para o novo servidor primário e podem retomar suas operações. O processo estabelece um novo servidor em espera na mesma zona que o primário antigo.
Para outras operações iniciadas pelo usuário, como escalonamento de computação ou escalonamento de armazenamento, o processo aplica as alterações primeiro no modo de espera e, em seguida, no primário. Atualmente, o serviço não faz failover para a instância em espera. Portanto, enquanto a operação de escalonamento é executada no servidor primário, os aplicativos sofrem um curto período de inatividade.
Você também pode usar esse recurso para fazer o failover para o servidor em espera com tempo de inatividade reduzido. Por exemplo, o servidor primário pode estar em uma zona de disponibilidade diferente do aplicativo após um failover não planejado. É recomendável trazer o servidor primário de volta à zona anterior para colocar com seu aplicativo.
Quando você executa esse recurso, o processo primeiro prepara o servidor em espera para garantir que ele se atualize com transações recentes, permitindo que o aplicativo continue executando leituras e gravações. O processo promove o servidor em espera e corta as conexões com o primário. O seu aplicativo pode continuar a gravar no servidor primário enquanto o processo estabelece um novo servidor em espera em segundo plano. A tabela a seguir descreve as etapas envolvidas com o failover planejado:
| Passo | Descrição | É esperado um tempo de inatividade do aplicativo? |
|---|---|---|
| 1 | Aguarde até que o servidor em espera alcance 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 número de sequência de log (LSN) primário. | Yes |
| 4 | O servidor em espera é promovido a servidor independente. | Yes |
| 5 | O registro DNS é atualizado com o novo endereço IP do servidor em espera. | Yes |
| 6 | O aplicativo se reconecta e retoma as operações de 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 recuperação panejada foi 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 ocorre em segundo plano sem afetar as gravações e as confirmações do aplicativo.
Dica
Com o servidor flexível, opcionalmente, você pode agendar atividades de manutenção iniciadas pelo Azure escolhendo uma janela de 60 minutos em um dia de sua preferência, quando espera-se que as atividades nos bancos de dados sejam baixas. Tarefas de manutenção do Azure, como patch ou atualizações de versão secundária, ocorrem durante essa janela. Se você não escolher uma janela personalizada, o sistema alocará uma janela de uma hora entre 23h e 7h locais para o 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.
Failover não planejado
Tempos de inatividade não planejados podem ocorrer como resultado de interrupções imprevistas, como falhas de hardware subjacentes, problemas de rede e bugs de software. Se o servidor de banco de dados configurado com alta disponibilidade falhar inesperadamente, o processo ativará a réplica em espera e os clientes poderão retomar suas operações. Se você não configurar alta disponibilidade (HA) e a tentativa de reinicialização falhar, o processo provisionará automaticamente um novo servidor de banco de dados. 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 operações de recuperação sem a necessidade de 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.
Teste de contingência (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.
A tabela a seguir descreve as etapas durante o failover forçado:
| Passo | Descrição | É esperado um tempo de inatividade do aplicativo? |
|---|---|---|
| 1 | O servidor primário é interrompido logo após receber a solicitação de failover. | Yes |
| 2 | O aplicativo encontra tempo de inatividade à medida que o servidor primário está ocioso. | Yes |
| 3 | O sistema de monitoramento interno detecta a falha e inicia um failover para o servidor em espera. | Yes |
| 4 | O servidor em espera entra no modo de recuperação antes de ser totalmente promovido a um servidor independente. | Yes |
| 5 | O processo de failover aguarda a conclusão da recuperação em espera. | Yes |
| 6 | Depois que o servidor estiver em operação, o processo atualizará os registros DNS com o mesmo nome de host, mas usará o endereço IP do modo de espera. | Yes |
| 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 foi concluído. | Não |
O tempo de inatividade do aplicativo começa após a etapa 1 e continua até que a etapa 6 seja concluída. As outras etapas são executadas 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. À medida que o seu aplicativo incorre em tempo de inatividade até que o failover para a instância em espera seja concluído, meça o tempo de inatividade sob a perspectiva do aplicativo/cliente em vez do processo de failover completo de ponta a ponta.
Considerações ao executar failovers forçados
O tempo geral de operação de ponta a ponta pode ser maior do que o tempo de inatividade real experimentado pelo aplicativo.
Importante
Sempre observe o tempo de inatividade da perspectiva do aplicativo!
Não execute failovers consecutivos e imediatos. Aguarde pelo menos 15 a 20 minutos entre mudanças de servidor para que o novo servidor em espera possa ser totalmente configurado.
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, manter o desempenho ideal do banco de dados envolve entender as funções distintas de pg_statistic e as tabelas pg_stat_* . A pg_statistic tabela armazena estatísticas do 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 estatísticas de atividade, como o número de varreduras, tuplas lidas e atualizações, são redefinidas quando ocorre o failover. Um exemplo dessa tabela é pg_stat_user_tables, que controla a atividade de tabelas definidas pelo usuário. Essa redefinição reflete com precisão o estado operacional do novo servidor 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, execute ANALYZE após um failover do PostgreSQL. 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 redução de atividade na zona
Zonal: para se recuperar de uma falha no nível da zona, você pode usar o backup para executar uma restauração em um ponto no tempo. 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 dentro de 60 a 120 segundos, sem 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 fornece armazenamento com redundância local com três cópias de dados, backup com redundância de zona (em regiões em que há suporte) e resiliência interna do servidor para reiniciar automaticamente um servidor com falha e realocar o servidor para outro nó físico. Essa configuração oferece um SLA de disponibilidade de 99,9%. Durante eventos de failover planejados ou não planejados, se o servidor falhar, 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 a seguir mostra a transição entre a VM e a falha de armazenamento.
Recuperação de desastre entre regiões e continuidade dos negócios
Se ocorrer um desastre abrangendo toda uma região, o Azure poderá fornecer proteção contra desastres regionais ou de grandes proporções geográficas, utilizando outra região para a recuperação de desastres. Para obter mais informações sobre a arquitetura de recuperação de desastre do Azure, consulte Arquitetura de recuperação de desastre de Azure para Azure.
O servidor flexível fornece recursos que protegem dados e reduzem o tempo de inatividade para seus bancos de dados críticos 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, cumprem os requisitos de tempo de recuperação e reduzem a exposição à perda de dados. Ao arquitetar seus aplicativos, considere a tolerância ao tempo de inatividade - o RTO (objetivo de tempo de recuperação) e a exposição à perda de dados - 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 oferecem a capacidade de restaurar o servidor em uma região diferente se ocorrer um desastre. Ela também fornece pelo menos 99,99999999999999% de durabilidade (16 noves) de objetos de backups em um determinado ano.
Você só pode configurar o backup com redundância geográfica ao criar o servidor. Quando você configura o servidor com backup com redundância geográfica, os dados de backup e os logs de transação 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
Você pode implantar réplicas de leitura entre regiões 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 o primário. As camadas de computação com otimização de memória e de uso geral dão suporte a réplicas de leitura.
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 você configurar seu servidor com backup com redundância geográfica, poderá realizar uma 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. Se ocorrer uma falha na região, você pode realizar a operação de recuperação de desastre promovendo a sua réplica de leitura para que ela se torne um servidor autônomo de leitura e gravação. Espera-se que o RPO seja de até 5 minutos (perda de dados possível), exceto no caso de uma falha regional grave, quando o RPO pode se aproximar do atraso de replicação existente 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.