Entendendo a alta disponibilidade e a recuperação de desastre para o Databases for PostgreSQL
Alta disponibilidadeA capacidade de um serviço ou carga de trabalho de resistir a falhas e continuar fornecendo capacidade de processamento de acordo com algum nível de serviço predefinido. Para serviços, a disponibilidade é definida no Contrato de Nível de Serviço. A disponibilidade inclui eventos planejados e não planejados, como manutenção, falhas e desastres. (HA) é a capacidade de um serviço permanecer operacional e acessível na presença de falhas inesperadas. A recuperação de desastresA capacidade de um serviço ou carga de trabalho de se recuperar de incidentes raros e importantes e de falhas em larga escala, como a interrupção do serviço. Isso inclui um desastre físico que afeta toda uma região, a corrupção de um banco de dados ou a perda de um serviço que contribui para uma carga de trabalho. O impacto excede a capacidade do projeto de alta disponibilidade para lidar com ele. é o processo de recuperação da instância de serviço para um estado de funcionamento.
Databases for PostgreSQL é um serviço regional que atende aos objetivos de nível de serviço(SLO) definidos com o plano padrão. Para obter mais informações, consulte Contrato de nível de serviço(SLA). Para obter mais informações sobre as regiões e os data centers disponíveis em IBM Cloud para site.data.keyword.databases-for-postgresql, consulte Disponibilidade de serviço e infraestrutura por local.
Arquitetura de alta disponibilidade
Databases for PostgreSQL oferece recursos de replicação, failover e alta disponibilidade para proteger seus bancos de dados e dados contra manutenção de infraestrutura, upgrades e algumas falhas. As implementações contêm um cluster com dois membros de dados - líder e réplica. A réplica é mantida atualizada usando a replicação assíncrona. Um mecanismo de consenso distribuído é usado para manter o estado do cluster e lidar com failovers. Se o líder se tornar inacessível, o cluster iniciará um failover, e a réplica será promovida a líder, e uma nova réplica se juntará novamente ao cluster como uma réplica. O líder e a réplica sempre estarão em zonas diferentes de um MZR. Se a réplica falhar, uma nova réplica será criada. Se uma falha de zona resultar na falha de um membro, a nova réplica será criada em uma zona sobrevivente.
Você pode ampliar ainda mais a alta disponibilidade adicionando membros do PostgreSQL ao cluster para obter maior redundância na região ou provisionando réplicas somente leitura para failover entre regiões ou descarregamento de leitura.
Consulte a documentação do site PostgreSQL sobre técnicas de replicação para entender as restrições e as compensações associadas à estratégia de replicação assíncrona implantada por padrão.
Em cenários em que um banco de dados se torna criticamente insalubre, como uma falha de servidor no líder, o Databases for PostgreSQL tenta um failover. Esse recurso de failover automático é limitado a 16 MB de defasagem de dados do líder para a réplica (algumas linhas de dados uma vez, representando mais PostgreSQL sobrecarga de dados) e não é executado se o limite de defasagem for excedido. Se a possibilidade de perda de 16 MB de dados for intolerável para o aplicativo, consulte a replicação síncrona.
As cargas de trabalho que acessam o cluster de forma programática devem seguir a lógica de repetição de disponibilidade do cliente para manter a disponibilidade.
Às vezes, o serviço realizará failovers controlados durante a operação normal. Esses failovers são eventos sem perda de dados, mas resultam em redefinições das conexões ativas. Há um período de até 15 segundos no qual as reconexões podem falhar. Às vezes, podem ocorrer failovers não planejados devido a eventos imprevistos no ambiente operacional. Isso pode levar até 45 segundos, mas geralmente leva menos de 30. A manutenção do serviço, por exemplo, aciona um failover controlado.
Recursos de alta disponibilidade
Databases for PostgreSQL oferece suporte aos seguintes recursos de alta disponibilidade:
| Recursos | Descrição | Consideração |
|---|---|---|
| Failover automático | Padrão em todos os clusters e resiliente contra falhas na zona ou em um único membro | |
| Contagem de membros | Mínimo - 2 membros. O padrão é uma implementação padrão de dois membros. Um cluster de dois membros se recuperará automaticamente de uma falha em uma única instância ou zona (com perda de dados até o limite de atraso). Durante a sincronização de dados para uma nova réplica, o cluster é exposto a uma segunda falha que causa perda de dados. Um membro de três membros, veja a adição de membros PostgreSQL, é resistente à falha de dois membros durante o mesmo período de falha | Três membros necessários para a replicação síncrona |
| Replicação síncrona | Melhora o RPO ao adicionar a sincronização remota de membros ao caminho de gravação de dados. Consulte Replicação síncrona abaixo. | Impacto no desempenho e custo. |
| Réplica somente leitura | As réplicas somente de leitura podem fornecer acesso local em regiões remotas, melhorando a disponibilidade para possíveis problemas de latência de rede ou conectividade. | Todas as solicitações de gravação devem ser direcionadas exclusivamente para o cluster de leitura e gravação associado à réplica de leitura |
Replicação síncrona Databases for PostgreSQL
Por padrão, a replicação do fluxo é assíncrona. Se o líder falhar, algumas transações que foram confirmadas podem não ter sido sincronizadas com a réplica, causando perda de dados. Cloud Databases garante que a perda de dados seja mantida
em um mínimo substancial de perda de dados; no entanto, a replicação síncrona oferece a capacidade de confirmar que todas as alterações feitas por uma transação foram sincronizadas com uma réplica. Isso garante a consistência em um cluster.
Essa consistência vem da confirmação de que as gravações são gravadas em um secundário antes de retornar ao cliente conectado com success. Para obter variáveis relacionadas à replicação síncrona, consulte synchronous_commit na página Alterando a configuração.
A replicação síncrona traz disponibilidade de réplica para o caminho de gravação primário. Se não houver uma réplica para reconhecer uma gravação, ela ficará suspensa até que uma réplica esteja disponível. Isso requer que pelo menos três membros funcionem de forma confiável, uma vez que a replicação síncrona não é suportada em implementações de dois membros. Você deve escalar horizontalmente para pelo menos três membros antes de ativar a replicação síncrona. Consulte adicionar membros do PostgreSQL.
Embora improvável, é possível que mais de uma réplica fique indisponível simultaneamente. Se isso acontecer, o banco de dados primário não será capaz de concluir qualquer gravação até que uma réplica se torne on-line novamente, bloqueando efetivamente todo o tráfego de gravação em seu banco de dados. Quando você decidir usar a replicação síncrona, pondere os custos e benefícios relativos da maior durabilidade dos dados em relação aos possíveis problemas de disponibilidade.
A configuração da replicação síncrona pode aumentar significativamente a latência de gravação e reduzir a taxa de transferência geral. Para obter o melhor desempenho, recomenda-se usar a replicação síncrona somente em bancos de dados ou cargas de trabalho específicos que exijam o mais alto grau de durabilidade dos dados.
Arquitetura de recuperação de desastres
A estratégia geral para a recuperação de desastres é criar um novo banco de dados, como o banco de dados Restore abaixo. O conteúdo do novo banco de dados pode ser um backup do banco de dados de origem criado antes do desastre.
Um novo banco de dados pode ser criado usando o recurso point-in-time se o banco de dados de produção estiver disponível.
Recursos de recuperação de desastres
Databases for PostgreSQL oferece suporte aos seguintes recursos de recuperação de desastres:
| Recursos | Descrição | Consideração |
|---|---|---|
| Restauração de backup | Crie um banco de dados a partir de um backup criado anteriormente; consulte Gerenciamento de backups em Cloud Databases. | Novas cadeias de conexão para o banco de dados restaurado devem ser referenciadas em toda a carga de trabalho. |
| Restauração de momento | Crie um banco de dados a partir da produção em tempo real usando a recuperação point-in-time | Isso só é possível se o banco de dados ativo estiver disponível e o RPO (desastre) estiver dentro da janela suportada. Não é útil se o cluster de produção não estiver disponível. Novas cadeias de conexão para o banco de dados restaurado devem ser referenciadas em toda a carga de trabalho. |
| Promover a réplica de leitura | Crie réplicas somente leitura ao planejar um desastre na mesma região ou em uma região remota. Promova a réplica somente leitura para se recuperar de um desastre. | A réplica de leitura criada anteriormente deve estar disponível. Novas cadeias de conexão para o banco de dados restaurado devem ser referenciadas em toda a carga de trabalho. |
Planejando a Recuperação de Desastre
As etapas de recuperação de desastres devem ser praticadas regularmente. Ao criar seu plano, considere os cenários de falha e as resoluções a seguir.
| Falha | Resolução |
|---|---|
| Falha de hardware (ponto único) | IBM fornece um banco de dados que é resiliente a um único ponto de falha de hardware em uma zona - não é necessária nenhuma configuração. |
| falha da zona | Failover automático (#postgresql-high-availability). Os membros do banco de dados são distribuídos entre as zonas. A configuração de três membros fornecerá resiliência adicional a falhas em várias zonas.
A replicação síncrona reduzirá o RPO em detrimento do desempenho. |
| Distorção de dados | Restauração de backup. Use o banco de dados restaurado na produção ou para dados de origem para corrigir a corrupção no banco de dados restaurado.
Restauração pontual. Use o banco de dados restaurado na produção ou para dados de origem para corrigir a corrupção no banco de dados restaurado. |
| Falha regional | Restauração de backup. Use o banco de dados restaurado na produção.
Promover a leitura da réplica. Promover uma réplica somente leitura para um banco de dados de leitura/gravação. Use o banco de dados restaurado na produção |
Alta disponibilidade de nível do aplicativo
Os aplicativos que se comunicam sobre redes e serviços de nuvem estão sujeitos a falhas de conexão temporárias. Você deseja projetar os seus aplicativos para tentar novamente as conexões quando os erros são causados por uma perda temporária em conectividade com a sua implementação ou com a IBM Cloud.
Como o Databases for PostgreSQL é um serviço gerenciado, as atualizações regulares e a manutenção do banco de dados ocorrem como parte das operações normais. Isso pode, ocasionalmente, causar intervalos curtos quando seu banco de dados fica indisponível. Também pode fazer com que o banco de dados acione um failover, uma nova tentativa e uma reconexão normais. Leva pouco tempo para o banco de dados determinar qual membro é uma réplica e qual é o líder, portanto, também é possível ver uma pequena interrupção de conexão. Os failovers geralmente levam menos de 30 segundos.
Os seus aplicativos devem ser projetados para manipular interrupções temporárias para o banco de dados, implementar a manipulação de erros para comandos de banco de dados com falha e implementar a lógica de nova tentativa para se recuperar de uma interrupção temporária.
Vários minutos de indisponibilidade de banco de dados ou de interrupção de conexão não são esperados. Abra um caso de suporte com detalhes se você tiver períodos de mais de um minuto sem conectividade, para que possamos investigar.
limites de conexão
O Databases for PostgreSQL configura o número máximo de conexões para o seu banco de dados PostgreSQL para 115. São reservadas 15 conexões para que o superusuário mantenha o estado e a integridade do seu banco de dados, sendo que 100 conexões estão disponíveis para você e seus aplicativos. Após atingir o limite de conexão, qualquer tentativa de iniciar uma nova conexão resulta em um erro. Para evitar sobrecarregar sua implementação com conexões, use o pooling de conexões ou dimensione sua implementação e aumente o limite de conexões. Consulte a página Gerenciando conexões PostgreSQL para obter mais informações.
Suas responsabilidades com HA e DR
As informações a seguir podem ajudá-lo a criar e praticar continuamente seu plano de HA e DR.
Ao restaurar um banco de dados a partir de backups ou usando a restauração point-in-time, um novo banco de dados é criado com novas cadeias de conexão. As cargas de trabalho e os processos existentes devem ser ajustados para consumir as novas cadeias de conexão. A promoção de uma réplica de leitura para um cluster terá um impacto semelhante, embora as partes existentes somente de leitura da carga de trabalho não sejam afetadas.
Um banco de dados recuperado também pode precisar das mesmas dependências criadas pelo cliente do banco de dados do desastre - certifique-se de que esse e outros serviços existam na região recuperada:
- IBM® Key Protect for IBM Cloud®
Lembre-se de que a exclusão de um banco de dados também exclui seus backups associados. No entanto, os bancos de dados excluídos podem ser recuperados dentro de um prazo limitado. Consulte a documentação para obter detalhes específicos sobre os procedimentos de recuperação do banco de dados.
Não é possível copiar backups do site IBM Cloud, portanto, considere usar as ferramentas específicas do banco de dados para backups adicionais. Pode ser necessário para recuperar a exclusão maliciosa de um banco de dados, seguida de uma exclusão de recuperação de um banco de dados. O gerenciamento cuidadoso do acesso do IAM aos bancos de dados pode ajudar a reduzir a exposição a esse problema.
A lista de verificação a seguir, associada a cada recurso, pode ajudá-lo a criar e praticar seu plano.
- Restauração de backup
- Verifique se os backups estão disponíveis na frequência desejada para atender aos requisitos de RPO. O gerenciamento dos backups do site Cloud Databases documenta a frequência dos backups. Considere um script usando o site IBM Cloud® Code Engine- Trabalhando com o produtor de eventos do timer periódico(cron) para criar backups adicionais sob demanda para melhorar o RPO se a criticidade e o tamanho do banco de dados permitirem. Entretanto, considerando os recursos do PostgreSQL's PITR, avalie cuidadosamente a necessidade de backups adicionais.
- Existem algumas restrições nas regiões de restauração do banco de dados - verifique se suas metas de restauração podem ser alcançadas lendo gerenciar backups em Cloud Databases.
- Verifique se o período de retenção dos backups atende aos seus requisitos.
- Programe restaurações de teste regularmente para verificar se os tempos reais de restauração atendem ao RTO definido. Lembre-se de que o tamanho do banco de dados afeta significativamente o tempo de restauração. Considere estratégias para minimizar o tempo de restauração, como dividir grandes bancos de dados em unidades menores e mais gerenciáveis e eliminar dados não utilizados.
- Verifique o serviço Key Protect.
- Restauração de momento
- Verifique os procedimentos abordados anteriormente.
- Verifique se o backup desejado está na janela.
- Promover a réplica de leitura
- Verifique se existe uma réplica de leitura na região de recuperação.
- Pratique o processo de promoção - crie uma réplica de leitura temporária na região desejada. A réplica temporária pode ser promovida para leitura/gravação e alguns testes podem ser realizados com pouco impacto na produção.
Para saber mais sobre a propriedade de responsabilidade entre o cliente e o IBM Cloud para usar o Databases for PostgreSQL, consulte Responsabilidades compartilhadas para Cloud Databases.
Mantenha-se informado: IBM notificações
As atualizações que afetam as cargas de trabalho dos clientes são comunicadas por meio de notificações no site IBM Cloud. Para se manter informado sobre manutenção planejada, anúncios e notas de versão relacionadas a esse serviço, consulte a página de status e notificações de monitoramento. Além disso, revise regularmente a página da política de versões para obter as atualizações mais recentes sobre as versões e datas do fim da vida útil.