Entendendo a alta disponibilidade e a recuperação de desastre para o Databases for MongoDB
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 MongoDB é um serviço regional que atende aos objetivos de nível de serviço(SLO) definidos com os planos Standard e Enterprise. 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 Databases for MongoDB, consulte Disponibilidade de serviço e infraestrutura por local.
Arquitetura de alta disponibilidade
Databases for MongoDB 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 três membros de dados - um membro primário e dois membros secundários. O conjunto de réplicas de dois membros é mantido atualizado 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 primário não estiver disponível, o conjunto de réplicas elege um secundário para ser o primário e continua a operação normal. O primário antigo se unirá novamente ao conjunto, quando disponível. Os membros primários e secundários sempre estarão em zonas diferentes de um MZR. Se uma falha de zona resultar na falha de um membro, a nova réplica será criada em uma zona sobrevivente.
Recursos de alta disponibilidade
Databases for MongoDB oferece suporte aos seguintes recursos de alta disponibilidade.
| Recursos | Descriçã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 de 3 membros. O padrão é uma implementação padrão de três membros. Um cluster de três membros se recuperará automaticamente de uma única instância ou falha de zona (com perda de dados até o limite de atraso). |
| Replicação assíncrona | Os secundários replicam as operações do primário e aplicam as operações a seus conjuntos de dados de forma assíncrona. Como os conjuntos de dados secundários refletem o conjunto de dados primário, o conjunto de réplicas pode continuar funcionando apesar da falha de um ou mais membros. |
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 MongoDB Restore a seguir. 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 do plano Enterprise, se o banco de dados de produção estiver disponível.
Recursos de recuperação de desastres
Databases for MongoDB 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 para o plano Enterprise e 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. |
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) | 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. 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. |
| 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. |
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.
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.
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 os serviços a seguir 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 de backups do FAQ para obter detalhes específicos sobre os procedimentos de recuperação de 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.
- 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.
- Restauração de momento
- Verifique os procedimentos abordados anteriormente.
- Verifique se o backup desejado está na janela.
Para obter mais informações sobre a propriedade de responsabilidade entre o cliente e o IBM Cloud para usar o Databases for MongoDB, consulte Responsabilidades compartilhadas para o 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 Monitoramento de notificações e status. Além disso, revise regularmente a política de versões para obter as atualizações mais recentes sobre as versões e datas de fim de vida útil.