Entendendo a alta disponibilidade e a recuperação de desastre para o Databases for Redis
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 de lidar com ele. é o processo de recuperação da instância de serviço para um estado de funcionamento.
Databases for Redis é 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 sobre as regiões e os data centers disponíveis em IBM Cloud para Databases for Redis, consulte Disponibilidade de serviço e infraestrutura por local.
Arquitetura de alta disponibilidade
Databases for Redis 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 em uma configuração primária e réplica. A réplica é mantida atualizada usando a replicação assíncrona. A alta disponibilidade é monitorada e gerenciada com três sentinelas Redis
Por padrão, a persistência de dados está ativada em todas as implementações e os dados são gravados no disco. O site Databases for Redis usa uma combinação de snapshots de RDB e AOF(Append Only File) para persistir os dados no disco. O intervalo para Databases for Redis gravar no disco (fsync) é definido como uma vez a cada segundo para equilibrar a durabilidade e o desempenho.
É possível desativar a persistência de dados, o que é útil para configurar o Redis como um cache.
Recursos de alta disponibilidade
Databases for Redis 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 é um cluster padrão de dois membros em uma configuração primária e de réplica. 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). | Três nós Sentinel para monitorar a integridade do cluster e coordenar failovers. |
| Replicação assíncrona | Permite a replicação do primário para a réplica sem bloquear o caminho de gravação, garantindo alta disponibilidade com baixa latência. Consulte Replicação assíncrona abaixo. | Pode resultar em perda de dados durante o failover devido ao atraso na replicação (RPO > 0). Não é adequado quando é necessária uma durabilidade rigorosa dos dados. |
Replicação assíncrona para Databases for Redis
Por padrão, o site Databases for Redis usa replicação assíncrona, em que o nó primário não espera que a réplica confirme as gravações. Isso garante baixa latência e alta taxa de transferência, tornando o site Databases for Redis ideal para cargas de trabalho sensíveis ao cache e ao desempenho. No entanto, no caso de uma falha primária, o atraso na replicação pode levar à perda de dados, pois a réplica pode não ter recebido as gravações mais recentes.
Databases for Redis a replicação é projetada para alta disponibilidade, não para durabilidade estrita. Um failover é acionado automaticamente se o primário se tornar inacessível, promovendo a réplica a líder. Como a replicação é assíncrona, algumas gravações confirmadas podem ser perdidas durante esse processo. Esse atraso de replicação define o objetivo de ponto de recuperação (RPO) das implementações do Databases for Redis.
Para reduzir o risco de perda de dados, o site Databases for Redis oferece suporte a mecanismos de persistência como snapshots de RDB e AOF(Append Only File), que gravam dados no disco independentemente do processo de replicação. Eles devem ser configurados cuidadosamente com base nos requisitos de carga de trabalho.
A replicação assíncrona em Databases for Redis garante um desempenho rápido, mas não elimina a possibilidade de perda de dados durante eventos de failover. É recomendado para cargas de trabalho em que a velocidade e a disponibilidade superam a consistência estrita 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.
Recursos de recuperação de desastres
Databases for Redis 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. |
Planejando a Recuperação de Desastre
As etapas de recuperação de desastres devem ser praticadas regularmente. Ao criar seu plano, considere os seguintes cenários de falha e resoluções.
| Falha | Resolução |
|---|---|
| Falha de hardware (ponto único) | (Exemplo) O site 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 do cliente. |
| falha da zona | Failover automático. Os membros do banco de dados são distribuídos entre as zonas. |
| 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. |
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 Redis é 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.
Seus aplicativos devem ser projetados para lidar com interrupções temporárias no banco de dados, implementar o tratamento 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 interruption.Use IOREDIS, NODEREDIS ou qualquer outro pacote de sua escolha para garantir a continuidade do seu application.For. Para obter mais informações, consulte a postagem do blog sobre detecção e tratamento de erros com Redis.
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
Databases for Redis define um máximo de 10.000 conexões simultâneas por implementação. Esse limite garante a estabilidade do desempenho e o gerenciamento de recursos em seu ambiente Redis. No entanto, nem todas as 10.000 conexões estão disponíveis para os clientes - uma parte é reservada internamente para operações que mantêm o estado e a integridade da implantação. Após atingir o limite de conexão, qualquer tentativa de iniciar uma nova conexão resulta em um erro. Para obter mais informações, consulte Gerenciamento de conexões Redis.
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.
Um banco de dados recuperado também pode precisar das mesmas dependências criadas pelo cliente do banco de dados do desastre. Assegurar que esses e outros serviços existam na região recuperada:
- IBM® Key Protect for IBM Cloud®
- Hyper Protect Crypto Services
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. Para obter mais informações, consulte Perguntas frequentes sobre backups.
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.
- Há 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 os tempos de restauração, como a divisão de grandes bancos de dados em unidades menores e mais gerenciáveis e a eliminação de dados não utilizados.
- Verifique o serviço Key Protect.
Para saber mais sobre a propriedade de responsabilidade entre o cliente e o IBM Cloud para usar o Databases for Redis, 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.