Alta disponibilidade no Banco de Dados do Azure para PostgreSQL – Servidor Único

  • Artigo

APLICA-SE A: Banco de Dados do Azure para PostgreSQL - Servidor Único

Importante

O Banco de Dados do Azure para PostgreSQL - Servidor Único está no caminho da desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único PostgreSQL?.

O serviço Banco de Dados do Azure para PostgreSQL – Servidor Único fornece um alto nível de disponibilidade garantido com o SLA (Service Level Agreement, contrato de nível de serviço) com suporte financeiro para tempo de atividade. O Banco de Dados do Azure para PostgreSQL fornece alta disponibilidade durante eventos planejados, como operação de computação em escala iniciada pelo usuário, e também quando ocorrem eventos não planejados, como falhas subjacentes de hardware, software ou rede. O Banco de Dados do Azure para PostgreSQL pode se recuperar rapidamente das circunstâncias mais críticas, garantindo praticamente nenhum tempo de inatividade do aplicativo ao usar esse serviço.

O Banco de Dados do Azure para PostgreSQL é adequado para executar bancos de dados de missão crítica que exigem alto tempo de atividade. Criado com base na arquitetura do Azure, o serviço tem recursos inerentes de alta disponibilidade, redundância e resiliência para reduzir o tempo de inatividade do banco de dados de interrupções planejadas e não planejadas, sem exigir que você configure componentes adicionais.

Componentes no Banco de Dados do Azure para PostgreSQL – Servidor Único

Componente Descrição
Servidor de Banco de Dados PostgreSQL O Banco de Dados do Azure para PostgreSQL fornece segurança, isolamento, salvaguardas de recursos e capacidade de reinicialização rápida para servidores de banco de dados. Esses recursos facilitam operações como dimensionamento e operação de recuperação do servidor de banco de dados após uma interrupção que aconteça em segundos.
As modificações de dados no servidor de banco de dados normalmente ocorrem no contexto de uma transação de banco de dados. Todas as alterações de banco de dados são registradas de forma síncrona na forma de logs write-ahead (WAL) no Armazenamento do Azure – que é anexado ao servidor de banco de dados. Durante o processo de ponto de verificação do banco de dados, as páginas de dados da memória do servidor de banco de dados também são liberadas para o armazenamento.
Armazenamento remoto Todos os arquivos de dados físicos e WAL do PostgreSQL são armazenados no Armazenamento do Azure, que é projetado para armazenar três cópias de dados em uma região para garantir redundância, disponibilidade e confiabilidade de dados. A camada de armazenamento também é independente do servidor de banco de dados. Ele pode ser desanexado de um servidor de banco de dados com falha e reanexado a um novo servidor de banco de dados em poucos segundos. Além disso, o Armazenamento do Azure monitoriza continuamente quaisquer falhas de armazenamento. Se uma corrupção de bloco for detetada, ela será corrigida automaticamente instanciando uma nova cópia de armazenamento.
Gateway O Gateway atua como um proxy de banco de dados, roteia todas as conexões de cliente para o servidor de banco de dados.

Redução do tempo de inatividade planejado

O Banco de Dados do Azure para PostgreSQL foi projetado para fornecer alta disponibilidade durante as operações de tempo de inatividade planejadas.

Captura de tela do Elastic Scaling no Azure PostgreSQL.

  1. Aumente e diminua a escala dos servidores de banco de dados PostgreSQL em segundos.
  2. O gateway que atua como um proxy para rotear o cliente se conecta ao servidor de banco de dados adequado.
  3. O aumento do armazenamento pode ser realizado sem qualquer tempo de inatividade. O armazenamento remoto permite desanexar/reconectar rapidamente após o failover. Aqui estão alguns cenários de manutenção planejada:
Cenário Descrição
Dimensionamento de computação para cima/para baixo Quando o usuário executa a operação de expansão/redução de escala de computação, um novo servidor de banco de dados é provisionado usando a configuração de computação dimensionada. No servidor de banco de dados antigo, 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 e, em seguida, são encerradas. O armazenamento é então desanexado do servidor de banco de dados antigo e anexado ao novo servidor de banco de dados. Quando o aplicativo cliente tenta novamente a conexão ou tenta fazer uma nova conexão, o Gateway direciona a solicitação de conexão para o novo servidor de banco de dados.
Ampliação do armazenamento A expansão do armazenamento é uma operação online e não interrompe o servidor de banco de dados.
Nova implantação de software (Azure) A implementação de novos recursos ou correções de bugs acontecem automaticamente como parte da manutenção planejada do serviço. Para obter mais informações, consulte a documentação e também verifique seu portal.
Atualizações de versões secundárias 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. Isso incorreria em um curto tempo de inatividade em termos de segundos, e o servidor de banco de dados seria reiniciado automaticamente com a nova versão secundária. Para obter mais informações, consulte a documentação e também verifique seu portal.

Mitigação de tempos de inatividade não planeados

O tempo de inatividade não planejado pode ocorrer como resultado de falhas imprevistas, incluindo falha de hardware subjacente, problemas de rede e bugs de software. Se o servidor de bases de dados ficar indisponível inesperadamente, um novo servidor de bases de dados será disponibilizado automaticamente em poucos segundos. O armazenamento remoto é automaticamente anexado ao novo servidor de bases de dados. O motor PostgreSQL executa a operação de recuperação com ficheiros WAL e de base de dados e abre o servidor de bases de dados para permitir a ligação dos clientes. As transações não confirmadas são perdidas e precisam ser repetidas pelo aplicativo. Embora um tempo de inatividade não planejado não possa ser evitado, o Banco de Dados do Azure para PostgreSQL reduz o tempo de inatividade executando automaticamente operações de recuperação no servidor de banco de dados e nas camadas de armazenamento sem exigir intervenção humana.

Captura de ecrã de Alta Disponibilidade no Azure PostgreSQL.

  1. Servidores Azure PostgreSQL com capacidades de escalonamento rápido.
  2. Gateway que atua como um proxy para rotear conexões de cliente para o servidor de banco de dados adequado.
  3. Armazenamento do Azure com três cópias para confiabilidade, disponibilidade e redundância.
  4. O armazenamento remoto também permite a desanexação/reconexão rápida após o failover do servidor.

Tempo de inatividade não planejado: cenários de falha e recuperação de serviço

Aqui estão alguns cenários de falha e como o Banco de Dados do Azure para PostgreSQL se recupera automaticamente:

Cenário Recuperação automática
Falha do servidor de banco de dados Se o servidor de banco de dados estiver inativo devido a alguma falha de hardware subjacente, as conexões ativas serão descartadas e todas as transações de bordo serão anuladas. Um novo servidor de banco de dados é implantado automaticamente e o armazenamento remoto de dados é anexado ao novo servidor de banco de dados. Após a conclusão da recuperação do banco de dados, os clientes podem se conectar ao novo servidor de banco de dados por meio do Gateway.

O tempo de recuperação (RTO) depende de vários fatores, incluindo a atividade no momento da falha, como uma grande transação e a quantidade de recuperação a ser executada 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. Quando o aplicativo é iniciado, o Gateway redireciona de forma transparente a conexão para o servidor de banco de dados recém-criado.
Falha de armazenamento Os aplicativos não veem nenhum impacto para quaisquer 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. As corrupções de bloco são corrigidas automaticamente. Se uma cópia dos dados for perdida, uma nova cópia dos dados será criada automaticamente.
Falha de computação Falhas de computação são eventos raros. No caso de falha de computação, um novo contêiner de computação é provisionado e o armazenamento com arquivos de dados é mapeado para ele, o mecanismo de banco de dados PostgreSQL é colocado online no novo contêiner e o serviço de gateway garante failover transparente sem qualquer necessidade de alterações no aplicativo. Observe também que a camada de computação incorporou a resiliência da zona de disponibilidade e uma nova computação é girada em zona de disponibilidade diferente no caso de falha de computação AZ.

Aqui estão alguns cenários de falha que exigem ação do usuário para recuperar:

Cenário Plano de recuperação
Falha de região O fracasso de uma região é um evento raro. No entanto, se precisar de proteção contra uma falha de região, você pode configurar uma ou mais réplicas de leitura em outras regiões para recuperação de desastres (DR). (Consulte este artigo sobre como criar e gerenciar réplicas de leitura para obter detalhes). No caso de uma falha no nível da região, você pode promover manualmente a réplica de leitura configurada na outra região para ser seu servidor de banco de dados de produção.
Falha na zona de disponibilidade A falha de uma zona de disponibilidade também é um evento raro. No entanto, se precisar de proteção contra uma falha na zona de disponibilidade, você pode configurar uma ou mais réplicas de leitura ou considerar o uso de nossa oferta de servidor flexível, que fornece alta disponibilidade com redundância de zona.
Erros lógicos/do utilizador A recuperação de erros do usuário, como tabelas descartadas acidentalmente ou dados atualizados incorretamente, envolve a execução de uma recuperação point-in-time (PITR), restaurando e recuperando os dados até o momento imediatamente anterior ao erro ter ocorrido.

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.

Resumo

O Banco de Dados do Azure para PostgreSQL fornece capacidade de reinicialização rápida de servidores de banco de dados, armazenamento redundante e roteamento eficiente do Gateway. Para obter proteção de dados adicional, você pode configurar backups para serem replicados geograficamente e também implantar uma ou mais réplicas de leitura em outras regiões. Com recursos inerentes de alta disponibilidade, o Banco de Dados do Azure para PostgreSQL protege seus bancos de dados contra interrupções mais comuns e oferece um SLA de 99,99% de tempo de atividade líder do setor. Todos esses recursos de disponibilidade e confiabilidade permitem que o Azure seja a plataforma ideal para executar seus aplicativos de missão crítica.

Próximos passos