Descrição geral da continuidade do negócio com a Base de Dados do Azure para PostgreSQL – Servidor Flexível
APLICA-SE A: 
Banco de Dados do Azure para PostgreSQL - Servidor Flexível
A continuidade de negócios no servidor flexível do Banco de Dados do Azure para PostgreSQL refere-se aos mecanismos, políticas e procedimentos que permitem que sua empresa continue operando em face de interrupções, particularmente em sua infraestrutura de computação. Na maioria dos casos, o servidor flexível do Banco de Dados do Azure para PostgreSQL lida com eventos disruptivos que podem acontecer no ambiente de nuvem e mantém seus aplicativos e processos de negócios em execução. No entanto, existem alguns eventos que não podem ser tratados automaticamente, tais como:
- O usuário exclui ou atualiza acidentalmente uma linha em uma tabela.
- O terramoto provoca uma falha de energia e desativa temporariamente uma zona de disponibilidade ou uma região.
- Aplicação de patches de banco de dados necessária para corrigir um bug ou problema de segurança.
O servidor flexível do Banco de Dados do Azure para PostgreSQL fornece recursos que protegem os dados e reduzem o tempo de inatividade para 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 do Banco de Dados do Azure para PostgreSQL tem recursos de continuidade de negócios que fornecem outra 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.
A tabela abaixo ilustra os recursos que o Banco de Dados do Azure para servidor flexível PostgreSQL oferece.
| Funcionalidade | Descrição | Considerações |
|---|---|---|
| Cópias de segurança automáticas | O servidor flexível do Banco de Dados do Azure para PostgreSQL executa automaticamente backups diários de seus arquivos de banco de dados e faz backup contínuo dos logs de transações. As cópias de segurança podem ser mantidas entre 7 dias e 35 dias. Você pode restaurar o servidor de banco de dados para qualquer point-in-time dentro do período de retenção de backup. O RTO depende do tamanho dos dados a serem restaurados + do tempo necessário para executar a recuperação do log. Pode ser de poucos minutos até 12 horas. Para obter mais detalhes, consulte Conceitos - Backup e restauração. | Os dados de backup permanecem na região. |
| Alta disponibilidade redundante de zona | O servidor flexível do Banco de Dados do Azure para PostgreSQL pode ser implantado com configuração de alta disponibilidade (HA) redundante de zona, onde os servidores primários e em espera são implantados em duas zonas de disponibilidade diferentes dentro de uma região. Essa configuração HA protege seus bancos de dados contra falhas no nível da zona 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. Na maioria dos casos, espera-se que o RTO seja inferior a 120s. Espera-se que o RPO seja zero (sem perda de dados). Para obter mais informações, consulte Conceitos - Alta disponibilidade. | Suportado em camadas de computação otimizadas para fins gerais e memória. Disponível apenas em regiões onde várias zonas estão disponíveis. |
| Alta disponibilidade na mesma zona | O servidor flexível do Banco de Dados do Azure para PostgreSQL pode ser implantado com a mesma configuração de alta disponibilidade (HA) de zona em que os servidores primários e em espera são implantados na mesma zona de disponibilidade em uma região. Essa configuração HA 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. Na maioria dos casos, espera-se que o RTO seja inferior a 120s. Espera-se que o RPO seja zero (sem perda de dados). Para obter mais informações, consulte Conceitos - Alta disponibilidade. | Suportado em camadas de computação otimizadas para fins gerais e memória. |
| Discos gerenciados premium | Os ficheiros das bases de dados são armazenados num armazenamento gerido premium e altamente durável e fiável. Este armazenamento fornece redundância de dados com três cópias de réplicas armazenadas numa zona de disponibilidade com capacidades de recuperação de dados automática. Para obter mais informações, consulte Documentação de discos gerenciados. | Dados armazenados em uma zona de disponibilidade. |
| Backup redundante de zona | Os backups flexíveis do Servidor do Banco de Dados do Azure para PostgreSQL são armazenados de forma automática e segura em um armazenamento redundante de zona dentro de uma região, se a região oferecer suporte a zonas de disponibilidade. Durante uma falha no nível da zona em que o servidor é provisionado e se o servidor não estiver configurado com redundância de zona, você ainda poderá restaurar o banco de dados usando o ponto de restauração mais recente em uma zona diferente. Para obter mais informações, consulte Conceitos - Backup e restauração. | Aplicável apenas em regiões onde estão disponíveis várias zonas. |
| Backup com redundância geográfica | Os backups flexíveis do Servidor do Banco de Dados do Azure para PostgreSQL são copiados para uma região remota. Isso ajuda na situação de recuperação de desastres caso a região do servidor primário esteja inativa. | Este recurso está atualmente ativado em regiões selecionadas. É necessário um RTO mais longo e um RPO mais alto, dependendo do tamanho dos dados a serem restaurados e da quantidade de recuperação a ser executada. |
| Ler réplica | 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. Para obter mais informações, consulte Conceitos - Ler réplicas. | Suportado em camadas de computação otimizadas para fins gerais e memória. |
A tabela a seguir compara RTO e RPO em um cenário de carga de trabalho típica:
| Capacidade | Burstable | Fins Gerais | Com otimização de memória |
|---|---|---|---|
| Restauro para um Ponto Anterior no Tempo a partir de cópia de segurança | Qualquer ponto de restauração dentro do período de retenção RTO - Varia RPO < 5 minutos |
Qualquer ponto de restauração dentro do período de retenção RTO - Varia RPO < 5 minutos |
Qualquer ponto de restauração dentro do período de retenção RTO - Varia RPO < 5 minutos |
| Restauração geográfica a partir de backups replicados geograficamente | RTO - Varia RPO < 1 h |
RTO - Varia RPO < 1 h |
RTO - Varia RPO < 1 h |
| Réplicas de leitura | RTO - Atas* RPO < 5 min* |
RTO - Atas* RPO < 5 min* |
RTO - Atas* RPO < 5 min* |
* RTO e RPO podem ser muito maiores em alguns casos, dependendo de vários fatores, incluindo latência entre sites, a quantidade de dados a serem transmitidos e, principalmente, a carga de trabalho de gravação do banco de dados primário.
Eventos de inatividade planeados
Abaixo estão alguns cenários de manutenção planejada. Esses eventos normalmente incorrem em até alguns minutos de tempo de inatividade e sem perda de dados.
| Cenário | Processo |
|---|---|
| Dimensionamento de computação (iniciado pelo usuário) | Durante a operação de dimensionamento de computação, os pontos de verificação ativos podem ser concluídos, as conexões do cliente são drenadas, todas as transações não confirmadas são canceladas, o armazenamento é desanexado e, em seguida, é desligado. Uma nova instância de servidor flexível do Banco de Dados do Azure para PostgreSQL com o mesmo nome de servidor de banco de dados é provisionada com a configuração de computação dimensionada. O armazenamento é então anexado ao novo servidor e o banco de dados é iniciado, o que executa a recuperação, se necessário, antes de aceitar conexões de cliente. |
| Dimensionamento do armazenamento (iniciado pelo usuário) | Quando uma operação de armazenamento de expansão é iniciada, os pontos de verificação ativos podem ser concluídos, as conexões do cliente são drenadas e todas as transações não confirmadas são canceladas. Depois disso, o servidor é desligado. O armazenamento é dimensionado para o tamanho desejado e, em seguida, anexado ao novo servidor. Uma recuperação é executada, se necessário, antes de aceitar conexões de cliente. Observe que a redução do tamanho do armazenamento não é suportada. |
| Nova implantação de software (iniciada pelo Azure) | A implementação de novos recursos ou correções de bugs acontecem automaticamente como parte da manutenção planejada do serviço, e você pode agendar quando essas atividades acontecerão. Para mais informações, consulte o seu portal. |
| Atualizações de versão secundária (iniciadas pelo Azure) | O Banco de Dados do Azure para PostgreSQL aplica patches automaticamente aos servidores de banco de dados para a versão secundária determinada pelo Azure. Isso acontece como parte da manutenção planejada do serviço. O servidor de banco de dados é reiniciado automaticamente com a nova versão secundária. Para obter mais informações, consulte a documentação. Também pode consultar o seu portal. |
Quando a instância de servidor flexível do Banco de Dados do Azure para PostgreSQL é configurada com alta disponibilidade, o serviço executa primeiro as operações de dimensionamento e manutenção no servidor em espera. Para obter mais informações, consulte Conceitos - Alta disponibilidade.
Mitigação de tempos de inatividade não planeados
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 do Banco de Dados do Azure para PostgreSQL ajuda a reduzir o tempo de inatividade executando automaticamente operações de recuperação sem exigir intervenção humana.
Embora nos esforcemos continuamente para fornecer alta disponibilidade, há momentos em que o servidor flexível do Banco de Dados do Azure para PostgreSQL incorre em interrupções, causando indisponibilidade dos bancos de dados e, portanto, afetando seu aplicativo. Quando nosso monitoramento de serviço deteta problemas que causam erros generalizados de conectividade, falhas ou problemas de desempenho, o serviço declara automaticamente uma interrupção para mantê-lo informado.
Falha do Serviço
No caso de interrupção do servidor flexível do Banco de Dados do Azure para PostgreSQL, você pode ver mais detalhes relacionados à interrupção nos seguintes locais:
- Banner do portal do Azure: se sua assinatura for identificada como afetada, haverá um alerta de interrupção de um Problema de Serviço em suas Notificações do portal do Azure.
- Ajuda + suporte ou Suporte + solução de problemas: quando você cria tíquete de suporte a partir de Ajuda + suporte ou Suporte + solução de problemas, haverá informações sobre quaisquer problemas que afetem seus recursos. Selecione Exibir detalhes da interrupção para obter mais informações e um resumo do impacto. Também haverá um alerta na página Nova solicitação de suporte.
- Ajuda do Serviço: A página Estado de Funcionamento do Serviço no portal do Azure contém informações sobre o estado do centro de dados do Azure a nível global. Pesquise "estado de funcionamento do serviço" na barra de pesquisa no portal do Azure e, em seguida, veja Problemas de serviço na categoria Eventos ativos. Você também pode exibir a integridade de recursos individuais na página Integridade do recurso de qualquer recurso no menu Ajuda. Segue-se uma captura de ecrã de exemplo da página Estado de Funcionamento do Serviço, com informações sobre um problema de serviço ativo no Sudeste Asiático.
- Notificação por e-mail: se você configurou alertas, uma notificação por e-mail chegará quando uma interrupção de serviço afetar sua assinatura e recurso. Os e-mails chegam de "azure-noreply@microsoft.com". O corpo do e-mail começa com "O alerta do registro de atividades ... foi desencadeada por um problema de serviço para a subscrição do Azure...". Para obter mais informações sobre alertas de integridade do serviço, consulte Receber alertas de log de atividades em notificações de serviço do Azure usando o portal do Azure.
Importante
Como o nome indica, espaços de tabela temporários no PostgreSQL são usados para objetos temporários, bem como outras operações internas de banco de dados, como classificação. Portanto, não recomendamos a criação de objetos de esquema de usuário em espaço de tabela temporário, pois não garantimos a durabilidade desses objetos após reinicializações do servidor, failovers de HA, etc.
Tempo de inatividade não planejado: cenários de falha e recuperação de serviços
Abaixo estão alguns cenários de falha não planejada e o processo de recuperação.
| Cenário | Processo de recuperação [Servidores configurados sem HA redundante de zona] |
Processo de recuperação [Servidores configurados com HA redundante de zona] |
|---|---|---|
| Falha do servidor de banco de dados | Se o servidor de banco de dados estiver inativo, o Azure tentará reiniciar o servidor de banco de dados. Se isso falhar, o servidor de banco de dados será reiniciado em outro nó físico. O tempo de recuperação (RTO) depende de vários fatores, incluindo a atividade no momento da falha, como uma grande transação, e o volume de recuperação a ser executado durante o processo de inicialização do servidor de banco de dados. Os aplicativos que usam os bancos de dados PostgreSQL precisam ser criados de forma a detetar e repetir conexões descartadas e transações com falha. |
Se a falha do servidor de banco de dados for detetada, o servidor será submetido a failover para o servidor em espera, reduzindo assim o tempo de inatividade. Para obter mais informações, consulte a página de conceitos de HA. Espera-se que o RTO seja de 60 a 120 anos, com zero perda de dados. |
| Falha de armazenamento | Os aplicativos não veem nenhum impacto para problemas relacionados ao armazenamento, como uma falha de disco ou uma corrupção de bloco físico. Como os dados são armazenados em três cópias, a cópia dos dados é servida pelo armazenamento sobrevivente. O bloco de dados corrompido é reparado automaticamente e uma nova cópia dos dados é criada automaticamente. | Para erros raros e não recuperáveis, como que todo o armazenamento esteja inacessível, a instância flexível do servidor do Banco de Dados do Azure para PostgreSQL é submetida a failover para a réplica em espera para reduzir o tempo de inatividade. Para obter mais informações, consulte a página de conceitos de HA. |
| Erros lógicos/do utilizador | Para se recuperar de erros do usuário, como tabelas descartadas acidentalmente ou dados atualizados incorretamente, você precisa executar uma recuperação point-in-time (PITR). Ao executar a operação de restauração, especifique o ponto de restauração personalizado, que é o tempo certo antes do erro ocorrer. Se desejar restaurar apenas um subconjunto de bancos de dados ou tabelas específicas em vez de todos os bancos de dados no servidor de banco de dados, você poderá restaurar o servidor de banco de dados em uma nova instância, exportar a(s) tabela(s) via pg_dump e, em seguida, usar pg_restore para restaurar essas tabelas em seu banco de dados. |
Esses erros do usuário não são protegidos com alta disponibilidade, pois todas as alterações são replicadas para a réplica em espera de forma síncrona. Você tem que executar a restauração point-in-time para se recuperar de tais erros. |
| Falha na zona de disponibilidade | Para se recuperar de uma falha no nível da zona, você pode executar a restauração point-in-time usando o backup e escolhendo um ponto de restauração personalizado com o tempo mais recente para restaurar os dados mais recentes. Uma nova instância de servidor flexível do Banco de Dados do Azure para PostgreSQL é implantada 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. | O servidor flexível do Banco de Dados do Azure para PostgreSQL é automaticamente transferido para o servidor em espera dentro de 60-120s com perda de dados zero. Para obter mais informações, consulte a página de conceitos de HA. |
| Falha de região | 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 será 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. |
O mesmo processo. |
Configure seu banco de dados após a recuperação de falha regional
- Se você estiver usando a restauração geográfica ou a réplica geográfica para se recuperar de uma interrupção, verifique se a conectividade com o novo servidor está configurada corretamente para que a função normal do aplicativo possa ser retomada. Você pode seguir as tarefas pós-restauração.
- Se você configurou anteriormente uma configuração de diagnóstico no servidor original, certifique-se de fazer o mesmo no servidor de destino, se necessário, conforme explicado em Configurar e acessar logs no Banco de Dados do Azure para PostgreSQL - Servidor flexível.
- Configurar alertas de telemetria, você precisa certificar-se de que suas configurações de regra de alerta existentes estão atualizadas para mapear para o novo servidor. Para obter mais informações sobre regras de alerta, consulte Usar o portal do Azure para configurar alertas em métricas para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível.
Importante
Os servidores excluídos podem ser restaurados. Se você excluir o servidor, poderá seguir nossas orientações Restaurar um banco de dados do Azure descartado - Banco de Dados do Azure para PostgreSQL - Servidor flexível para recuperar. Utilize o bloqueio de recursos do Azure para ajudar a prevenir a eliminação acidental do seu servidor.
Próximos passos
- Saiba mais sobre modelos de implantação de alta disponibilidade
- Saiba mais sobre backup e recuperação