Você conhece exatamente a função do backup e do replicaset? De acordo com o artigo publicado pelo MongoDB, a função de backup e replicaset são sintetizadas da seguinte maneira: a replicação é para disponibilidade e os backups são para recuperação de desastres.
Disponibilidade é a medida de tempo que uma aplicação está funcionando e acessível aos usuários finais em sua capacidade total. Se você utiliza o MongoDB como principal banco de dados e não tem um mecanismo de replicação configurado, está sob risco de perder dados críticos em casos de falha de hardware, interrupções de serviço, ataques cibernéticos ou desastres naturais. Sem a replicação, o MongoDB não terá cópias dos dados em outros servidores ou datacenters, e isso significa que se o servidor principal falhar ou se tornar inacessível, a empresa perde os dados armazenados nesse servidor.
Um exemplo de caso real, apesar de menos provável foi um evento que ocorreu recentemente na Europa, em que uma onda de calor prejudicou diretamente as atividades da nuvem oferecidas por empresas como Google e Oracle, isso porque alguns data centers não conseguem lidar com as altas temperaturas, e interfere diretamente na funcionalidade dos bancos. De acordo com Adrenaline (2022)
A Oracle foi forçada a desligar parte de sua infraestrutura como forma de evitar danos permanentes a ela, algo que afetou diretamente sua oferta de serviços. A situação também está afetando o Google, que tem testemunhado uma taxa de erros acima do comum, aumentos de latência e a indisponibilidade de alguns de seus sistemas.Ainda de acordo com Adrenaline (2022) “muitas empresas passaram a pulverizar suas unidades de resfriamento com água como forma de lidar com as grandes temperaturas registradas no continente europeu”.
Outras situações podem ocorrer e interferir na disponibilidade do seu banco, por exemplo, em 2011 a Amazon sofreu uma interrupção na AWS US-Leste, foi amplamente divulgado porque derrubou ou prejudicou vários sites populares que dependiam da AWS para hospedagem.
Então, se uma dessas empresas utilizasse o MongoDB mas sem replicação dos dados para qualquer uma das situações acima, onde poderiam continuar acessando seus dados? E a resposta é que não há meios de acessar. A intenção aqui não é instaurar o medo, mas sim, a prevenção. É como um seguro do carro, a gente paga todo mês, mas torcendo que não precise usar nunca.
Um detalhe superimportante é que os requisitos para o tipo de proteção do seu banco, depende do seu tipo de negócio, e é nesse momento que uma consultoria pode influenciar e contribuir ainda mais para seu negócio.
Como falamos acima de indisponibilidade por decorrência um evento catastrófico, se os replicaset estiverem localizados todo no mesmo datacenter, e este datacenter se tornar instável por alguma razão, nenhum nó ficará disponível, e então, entramos com o replicaset em multi regiões: Com um ReplicaSet implantado em várias regiões geográficas, é possível criar um sistema de bancos de dados distribuído e geograficamente redundante, permitindo que o sistema continue funcionando mesmo se uma ou mais instâncias falharem. Além disso, o ReplicaSet em multi regiões também ajuda a melhorar o desempenho do sistema, pois os usuários podem se conectar à instância do MongoDB mais próxima. Especificamente para estes casos, podemos impulsionar ainda mais o Atlas, que é o serviço de banco de dados gerenciado na nuvem do MongoDB.
Assim, com um replicaset, no momento da indisponibilidade do seu nó primário, os outros nós secundários ficam responsáveis em eleger um novo nó primário. De acordo com Jordan Kobelarz (2015) “O nó primário é o único que recebe operações de escrita e redistribui para os outros nós através de um sistema de heartbeats, que fica responsável por sincronizar os nós em uma determinada frequência”. Enquanto, os nós secundários do replica set são responsáveis por manter cópias do nó primário, esses nós ficam sincronizados entre si.
Bom, o número de replicaset deve sempre ser ímpar, isso para não ocorrer empates no momento da eleição de um novo primário caso o primário fique indisponível. Portanto, no mínimo:
Bom, o número de replicaset deve sempre ser ímpar, isso para não ocorrer empates no momento da eleição de um novo primário caso o primário fique indisponível. Portanto, no mínimo:
a) 1 nó primário, 2 nós secundários;
b) 1 nó primário, 1 secundário, e 1 árbitro.
A pergunta agora é, o que é árbitro? Ele não armazena dados, só tem poder de voto, para assim, não ocorrer empates no momento da eleição. Existem algumas possibilidades de tipos de nós, e é muito importante conhecê-los: i) Nó(s) de propriedade(s) 0: nós com prioridades 0 não podem ser eleitos, mas ainda assim podem votar. ii) Nó(s) escondidos ou Hidden: é um tipo de nó secundário em um conjunto de réplicas que não é elegível para se tornar o nó primário. Ele é usado para fins de balanceamento de carga e não é visível para o aplicativo cliente. Isso permite que os desenvolvedores dimensionem horizontalmente o banco de dados sem afetar a disponibilidade do sistema. iii) Nó(s) atrasado(s) ou delayed nodes: guardam uma cópia do nó primário com atraso, a fim de recuperação de dados em casos de desastres. O delayed nodes tem poder de voto, mas não podem ser eleitos, e tem prioridade zero.
Certo, agora que entendemos o replicaset, podemos nos questionar: Certo, meus dados então estão sendo registrados no nó primário, reproduzidos para os nós secundários, então por que a necessidade do backup?
Os backups permitem que você restaure seus dados no caso de uma falha catastrófica. Além disso, os backups podem ser usados para fins de recuperação em caso de exclusão acidental de dados ou corrupção de dados.
Enquanto a replicação fornece alta disponibilidade e redundância para garantir que seus dados estejam sempre disponíveis, os backups fornecem uma camada adicional de proteção contra a perda de dados. Portanto, ambos são importantes para garantir a integridade e a disponibilidade dos seus dados no MongoDB.
De acordo com o MongoDB (2015)
Na categoria de erro humano, você tem bugs de aplicação, hacking deliberado e exclusão ou corrupção acidental de todos os dados no nó primário. Em todos esses casos, os erros introduzidos no primário se propagarão automaticamente para todos os membros de seu conjunto de réplicas, muitas vezes em segundos! Uma vez que o erro humano é tão garantido quanto a falha do disco, isto por si só é motivo suficiente para ter backups.Resumindo, o backup vai te proteger de eventos que podem vir a acontecer (e até se replicar para os outros nós), ele te permite retornar ao momento antes do desastre acontecer, enquanto o replicaset vai permitir que seu sistema nunca fique indisponível, antes mesmo que você perceba uma situação, o sistema de eleição de replicação vai agir e proteger o banco de dados.
Então, se eu te perguntar agora, seja você um gestor de uma empresa, ou um administrador de banco de dados que trabalhe com mongodb, você sente que seu banco está protegido? Como eu disse, são medidas de precaução, que esperamos nunca precisar usar, mas caso um dia precise, estará 100% assegurado!
REFERÊNCIAS
Adrenaline. “Centros de dados do google e da oracle estão sendo prejudicados por onda de calor na Europa”. Disponível em https://adrenaline.com.br/noticias/v/77260/centros-de-dados-do-google-e-da-oracle-estao-sendo-prejudicados-por-onda-de-calor-na-europa
AWS. Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region. Disponível em < https://aws.amazon.com/pt/message/65648/>.
MongoDB. Backup vs Replication: Why do you need both? Disponível em < https://www.mongodb.com/blog/post/backup-vs-replication-why-do-you-need-both>.