Olá, Khabrovites! Nós decodificamos para você uma parte do tutorial MongoDB de Evgeny Aristov, um desenvolvedor de 20 anos e autor do curso online "Bancos de Dados Não Relacionais" . O material, assim como o próprio curso, será útil para especialistas que se deparam com o NoSQL, que desejam aprender como otimizar seus bancos de dados e trabalhar com eles.
Por que replicar?
- Alta disponibilidade. Um backup é bom, mas leva tempo para ser implantado.
- Escala horizontal. No caso de o servidor ficar sem núcleos físicos e memória.
- É melhor fazer um backup de uma réplica e não de um mestre.
- Carregue a distribuição geográfica.
No MongoDB, não existem muitos tipos de replicação prontos para uso: o mais relevante no momento é o Replicaset e o segundo é o mestre-escravo, que está limitado à versão 3.6 e não será discutido em detalhes neste artigo.
# 1. Escrevendo e lendo do servidor principal
Temos um driver de aplicativo cliente que lê e grava no nó primário. Além disso, de acordo com o protocolo de replicação, as informações gravadas no nó primário são enviadas para os nós secundários.
# 2. Lendo de uma deixa
Uma alternativa para ler e escrever do Primário é quando o driver pode ler informações do Secundário. Neste caso, as configurações podem ser diferentes, por exemplo, "é preferível ler as informações do Secundário e depois do Primário" ou "ler as informações do nó mais próximo no mapa da rede", etc. Essas opções de configuração são usadas com mais frequência do que a primeira opção de replicação, onde tudo passa pelo Primário.
3 maneiras de tornar uma réplica legível:
- Especificamos
db.slaveOk() - Especifique os parâmetros necessários na string de conexão do driver
- Especifique tudo e escreva com mais precisão na própria consulta, por exemplo, leia do Secundário na região Sul:
db.collection.find({}).readPref( “secondary”, [ { “region”: “South”} ] )
Problemas de leitura de réplica
- Como a gravação é assíncrona, ela já pode ser feita no Primário, mas não pode chegar ao Secundário, então os dados antigos do Secundário serão lidos.
- , , .
, . MongoDB , , , . - , () — «».
A) Os nós "ouvem" uns aos outros, essa conexão é chamada de pulsação. Ou seja, cada nó é constantemente verificado por outros para o assunto "vivo / não vivo", a fim de tomar alguma ação se algo acontecer.
B) Um nó secundário é alterado para Árbitro. Esta é uma aplicação muito leve, roda como Mongo, praticamente não consome recursos e é responsável por determinar qual nó na hora de votar para reconhecer o principal. E esta geralmente é a configuração recomendada.
As principais características desta configuração
- Replicação assíncrona
- O árbitro é livre de dados e, portanto, muito leve
- Primário pode se tornar Secundário e vice-versa. O Árbitro não pode se tornar Primário ou Secundário
- O número máximo de respostas é 50 e apenas 7 delas podem votar
- Arbiter Primary Secondary, , .. , Arbiter .
Se você estiver interessado em aprender mais sobre os recursos de clustering do MongoDB, pode assistir a uma gravação de toda a lição de demonstração aqui . Na lição, Evgeny Aristov demonstra as diferenças entre Replicaset e Master-slave, explica o processo de quorum, dimensionamento, fragmentação e a seleção correta da chave para fragmentação.
Explorar os recursos do MongoDB faz parte do curso online de bancos de dados não relacionais. O curso é destinado a desenvolvedores, administradores e outros profissionais que conhecem o NoSQL. Na sala de aula, os alunos dominam na prática as ferramentas mais relevantes da atualidade: Cassandra, MongoDB, Redis, ClickHouse, Tarantool, Kafka, Neo4j, RabbitMQ.
O início já é dia 30 de setembro, mas já no primeiro mês você pode entrar no grupo. Estude o programa, siga em frenteteste de entrada e junte-se!