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.
A continuidade de negócios no 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, especialmente em sua infraestrutura de computação. Na maioria dos casos, o Azure Database Database for PostgreSQL lida com eventos disruptivos que podem ocorrer no ambiente cloud e mantém as suas aplicações e processos de negócio a funcionar. No entanto, alguns eventos não podem ser tratados automaticamente, tais como:
- Um utilizador apaga ou atualiza acidentalmente uma linha numa tabela.
- Um 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 Base de Dados do Azure para PostgreSQL oferece funcionalidades que protegem os dados e mitigam o tempo de inatividade das suas bases de dados críticas durante eventos planeados e não planeados. Criado com base na infraestrutura do Azure que oferece resiliência e disponibilidade robustas, o 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, considere 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 seguinte ilustra as funcionalidades que o Base de Dados do Azure para PostgreSQL oferece.
| Feature | Descrição | Considerações |
|---|---|---|
| Cópias de segurança automáticas | Uma instância de 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 de logs de transações. Pode manter cópias de segurança de 7 dias até 35 dias. Você pode restaurar o servidor de banco de dados para qualquer momento no tempo dentro do período de retenção de backup. O RTO depende do tamanho dos dados a restaurar e do tempo para realizar a recuperação dos logs. Pode durar desde alguns 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 entre zonas | Pode implementar uma instância de servidor flexível Base de Dados do Azure para PostgreSQL com configuração redundante de alta disponibilidade (HA), onde os servidores primário e de espera são implementados em duas zonas de disponibilidade diferentes dentro de uma região. Esta configuração de HA protege as suas bases de dados contra falhas ao nível da zona e também ajuda a reduzir o tempo de inatividade da aplicação durante eventos planeados e não planeados. 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. Na maioria dos casos, espera-se que o RTOs seja inferior a 120 segundos. Espera-se que o RPO seja zero (sem perda de dados). Para 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 | Pode implementar uma instância de servidor flexível Base de Dados do Azure para PostgreSQL com a mesma configuração de alta disponibilidade (HA), onde os servidores primário e de espera estão implantados na mesma zona de disponibilidade numa região. Esta configuração HA protege as suas bases de dados contra falhas ao nível dos nós e também ajuda a reduzir o tempo de inatividade da aplicação durante eventos planeados e não planeados. 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. Na maioria dos casos, espera-se que o RTOs seja inferior a 120 segundos. Espera-se que o RPO seja zero (sem perda de dados). Para obter mais informações, consulte [Conceitos - Alta disponibilidade]/azure/reliability/reliability-postgresql-flexible-server. | 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 de alto nível gerido, altamente durável e fiável. Este armazenamento proporciona redundância de dados com três cópias da réplica armazenadas dentro de uma zona de disponibilidade com capacidades de recuperação automática de dados. Para obter mais informações, consulte Documentação de discos gerenciados. | Dados armazenados em uma zona de disponibilidade. |
| Backup redundante por zonas | Os backups da instância de servidor flexível do Banco de Dados do Azure para PostgreSQL são armazenados automaticamente e de forma segura em armazenamento com redundância de zona dentro de uma região, se a região oferecer suporte a zonas de disponibilidade. Durante uma falha ao nível da zona, onde o seu servidor está provisionado, e se o servidor não estiver configurado com redundância de zona, ainda pode restaurar a base de dados usando o ponto de restauro mais recente numa 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 | As cópias de segurança da instância de servidor flexível do Base de Dados do Azure para PostgreSQL são transferidas para uma região remota. Esta funcionalidade ajuda em cenários de recuperação após desastre, caso a região do servidor principal esteja indisponível. | 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 | 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 ficar atrasadas em relação à primária. 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 | SKU de produção (uso geral/memória otimizada) |
|---|---|---|
| Restauro de Ponto no Tempo a partir de backup | 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 |
| Réplicas de leitura | Não Aplicável | RTO - Minutos* RPO - Normalmente variando de 30 segundos a 5 minutos* |
| Alta Disponibilidade | Não Aplicável | RTO < 120 segundos RPO = 0 |
Eventos de inatividade planeados
A tabela seguinte descreve alguns cenários comuns de manutenção planeada. Estes eventos normalmente causam alguns minutos de inatividade, mas não causam perda de dados.
| Cenário | Processo |
|---|---|
| Dimensionamento de computação (iniciado pelo usuário) | Durante a operação de dimensionamento da computação, o processo permite que os pontos de verificação ativos sejam concluídos, encerra as ligações dos clientes de forma controlada, cancela quaisquer transações não confirmadas, desassocia o armazenamento e, em seguida, encerra. O processo prevê uma nova instância de servidor flexível Base de Dados do Azure para PostgreSQL com o mesmo nome de servidor de base de dados, mas com a configuração de computação escalonada. O processo liga o armazenamento ao novo servidor e inicia a base de dados, que realiza a recuperação se necessário antes de aceitar as ligações do cliente. |
| Dimensionamento do armazenamento (iniciado pelo usuário) | Quando inicia uma operação de aumento da capacidade de armazenamento, o processo permite que os pontos de verificação ativos sejam concluídos, encerra as ligações dos clientes e cancela quaisquer transações não confirmadas. Depois disso, o processo desliga o servidor. O processo escala o armazenamento até ao tamanho desejado e depois liga-o ao novo servidor. O processo realiza a recuperação, se necessário, antes de aceitar as ligações do cliente. Observe que a redução do tamanho do armazenamento não é suportada. |
| Nova implantação de software (iniciada pelo Azure) | O serviço lança automaticamente novas funcionalidades ou correções de bugs como parte da manutenção planeada. Podes agendar quando essas atividades acontecem. Para mais informações, consulte o seu portal. |
| Atualizações de versão secundária (iniciadas pelo Azure) | O Azure Database para PostgreSQL aplica automaticamente patches aos servidores de base de dados para a versão menor determinada pelo Azure. Esta atualização ocorre como parte da manutenção planeada do serviço. O processo reinicia automaticamente o servidor de base de dados com a nova versão menor. Para obter mais informações, consulte a documentação. Também pode consultar o seu portal. |
Quando configura a instância de servidor flexível do Base de Dados do Azure para PostgreSQL com alta disponibilidade, o serviço realiza primeiro as operações de escalabilidade e manutenção no servidor de espera. Para obter mais informações, consulte [Conceitos - Alta disponibilidade]/azure/reliability/reliability-postgresql-flexible-server.
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 base de dados configurado com alta disponibilidade falhar inesperadamente, o serviço ativa a réplica de espera e os clientes podem retomar as suas operações. Se não configurar o servidor com alta disponibilidade (HA), o serviço provisiona automaticamente um novo servidor de base de dados se a tentativa de reinício falhar. Embora não consiga evitar períodos de inatividade não planeados, o Base de Dados do Azure para PostgreSQL ajuda a mitigar o tempo de inatividade ao realizar automaticamente operações de recuperação sem necessidade de intervenção humana.
Embora a equipa de engenharia se esforce continuamente por garantir alta disponibilidade, há momentos em que o Base de Dados do Azure para PostgreSQL sofre uma falha que causa a indisponibilidade das bases de dados e, consequentemente, afeta a sua aplicação. Quando a monitorização do serviço deteta problemas que causam erros generalizados de conectividade, falhas ou problemas de desempenho, o serviço declara automaticamente uma interrupção para o manter informado.
Interrupção do serviço
Se uma instância de servidor flexível do Base de Dados do Azure para PostgreSQL falhar, pode encontrar mais detalhes sobre a interrupção nos seguintes locais:
- Banner do portal Azure: Se a sua subscrição for afetada, as Notificações do portal Azure mostram um alerta de falha para um problema de serviço.
- Ajuda + suporte ou Suporte + resolução de problemas: Quando cria um ticket de suporte a partir de Ajuda + suporte ou Suporte + resolução de problemas, o portal inclui informações sobre quaisquer problemas que afetem os seus recursos. Selecione Exibir detalhes da interrupção para obter mais informações e um resumo do impacto. A nova página de pedidos de suporte inclui também um alerta.
- Saúde do Serviço: A página de Saúde do Serviço no portal Azure contém informações sobre o estado global do centro de dados Azure. Procure por "saúde do serviço" na barra de pesquisa do portal do Azure e depois veja problemas de serviço na categoria Eventos Ativos. Também pode ver a saúde de recursos individuais na página de Saúde de Recursos de qualquer recurso, no menu de Ajuda . A captura de ecrã seguinte da página Service Health mostra informações sobre um problema de serviço ativo no Sudeste Asiático.
- Notificação por email: Se configurar alertas, recebe uma notificação por email quando uma falha de serviço afeta a sua subscrição e recurso. Os emails vêm de "azure-noreply@microsoft.com". O corpo do e-mail começa com "O alerta do registro de atividades ... foi desencadeado por um problema de serviço para a assinatura do Azure...". Para mais informações sobre alertas de estado de funcionamento do serviço, consulte Receber alertas de registo de atividades sobre notificações de serviço do Azure com 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. Por isso, não crie objetos de esquema de utilizador em espaço de tabela temporário, pois a durabilidade destes objetos após reinicios do servidor, failovers do HA e eventos semelhantes não é garantida.
Tempo de inatividade não planejado: cenários de falha e recuperação de serviços
A tabela seguinte descreve cenários comuns de falhas não planeadas 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 base de dados falhar, o Azure tenta reiniciar o servidor da base de dados. Se essa tentativa falhar, o Azure reinicia o servidor de base de dados noutro nó físico. O tempo de recuperação (RTO) depende de vários fatores, incluindo a atividade no momento da falha, como uma transação grande, e o volume de recuperação a realizar durante o processo de arranque do servidor de base de dados. As aplicações que utilizam as bases de dados PostgreSQL precisam de detetar e tentar novamente ligações perdidas e transações falhadas. |
Se for detetada a falha do servidor de base de dados, o servidor passa para o servidor de espera, o que reduz o tempo de inatividade. Para obter mais informações, consulte [página de conceitos de HA]/azure/reliability/reliability-postgresql-flexible-server. Espera-se que o RTO dure entre 60 e 120 segundos, sem perda de dados. |
| Falha de armazenamento | As aplicações não veem qualquer impacto devido a problemas relacionados com o armazenamento, como falhas de disco ou corrupção física de blocos. Como os dados são armazenados em três cópias, o armazenamento remanescente assegura a cópia dos dados. O bloco de dados corrompido é reparado automaticamente e uma nova cópia dos dados é criada automaticamente. | Em caso de erros raros e não recuperáveis, como quando todo o armazenamento está inacessível, a instância do servidor flexível do Base de Dados do Azure para PostgreSQL efetua a comutação para a réplica em espera para reduzir o tempo de inatividade. Para obter mais informações, consulte [página de conceitos de HA]/azure/reliability/reliability-postgresql-flexible-server. |
| Erros lógicos ou de utilizador | Para recuperar de erros do utilizador, como tabelas caídas acidentalmente ou dados atualizados incorretamente, realize uma recuperação pontual no tempo (PITR). Durante a realização da operação de restauro, especifique o ponto de restauro personalizado, que corresponde ao momento imediatamente anterior ao erro ocorrer. Se quiser restaurar apenas um subconjunto de bases de dados ou tabelas específicas em vez de todas as bases de dados do servidor de base de dados, pode restaurar o servidor de base de dados numa nova instância, exportar as tabelas via pg_dump e depois usar pg_restore para restaurar essas tabelas na sua base de dados. |
Estes erros de utilizador não são protegidos pela alta disponibilidade, pois todas as alterações são replicadas para a réplica de espera de forma síncrona. É necessário realizar um restauro pontual para recuperar de erros desse tipo. |
| Falha na zona de disponibilidade | Para recuperar de uma falha ao nível da zona, realize uma restauração pontual usando a cópia de segurança e escolha um ponto de restauro personalizado com o prazo mais recente para restaurar os dados mais recentes. Implemente uma nova instância de servidor flexível do Base de Dados do Azure para PostgreSQL noutra 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. | Uma instância de servidor flexível do Base de Dados do Azure para PostgreSQL faz automaticamente failover para o servidor de espera em 60-120 segundos, sem perda de dados. Para obter mais informações, consulte [página de conceitos de HA]/azure/reliability/reliability-postgresql-flexible-server. |
| Falha na 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. O Azure provisiona e recupera um novo servidor para os ú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 uma região, pode realizar uma operação de recuperação de desastre promovendo a sua réplica de leitura para um servidor autónomo de leitura e escrita. Espera-se que o RPO dure até cinco minutos (perda de dados possível), exceto em 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 utilizar a georrestauração ou a georréplica para recuperar de uma indisponibilidade, certifique-se de que a conectividade ao novo servidor está corretamente configurada para que o funcionamento normal da aplicação possa ser retomado. Siga as instruções em Tarefas pós-restauração.
- Se 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 Aceder aos Registos no Base de Dados do Azure para PostgreSQL.
- Para configurar alertas de telemetria, certifique-se de que as definições atuais das suas regras de alerta 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.
Importante
Podes restaurar servidores apagados. Se eliminares o servidor, segue as orientações em Restaurar um servidor eliminado para recuperar. Utilize o bloqueio de recursos do Azure para ajudar a prevenir a eliminação acidental do seu servidor.