O que é replicação em cadeia?
Quando falamos de replicação, estamos nos referindo ao processo de fazer cópias redundantes de dados para atender aos critérios de design sobre disponibilidade de dados. A replicação em cadeia, portanto, refere-se à ordenação linear dos servidores MongoDB para formar uma cadeia sincronizada. A cadeia contém um nó primário, sucedido por servidores secundários dispostos linearmente. Como a palavra chain sugere, o servidor mais próximo do servidor primário replica a partir dele, enquanto todos os outros servidores secundários sucessivos replicam do servidor MongoDB secundário anterior. Esta é a principal diferença entre a replicação encadeada e a replicação normal. A replicação encadeada ocorre quando um nó secundário seleciona seu destino usando o tempo de ping ou quando o nó mais próximo é um secundário. Embora a replicação em cadeia, como aparece, reduza a carga no nó primário, pode causar atraso na replicação.
Por que usar a replicação em cadeia?
As infraestruturas do sistema às vezes sofrem falhas imprevisíveis que levam à perda de um servidor e, portanto, afetam a disponibilidade. A replicação garante que falhas imprevisíveis não afetem a disponibilidade. A replicação permite ainda a recuperação de falhas de hardware e interrupção do serviço. A replicação encadeada e não encadeada atende a esse propósito de garantir a disponibilidade apesar das falhas do sistema. Tendo estabelecido que a replicação é importante, você pode perguntar por que usar a replicação em cadeia em particular. Não há diferença de desempenho entre replicação encadeada e não encadeada no MongoDb. Em ambos os casos, quando o nó primário falha, os servidores secundários votam em um novo primário atuante e, portanto, a gravação e a leitura de dados não são afetadas em ambos os casos. No entanto, a replicação encadeada é o tipo de replicação padrão no MongoDb.
Como configurar uma réplica de cadeia
Por padrão, a replicação encadeada é habilitada no MongoDB. Vamos, portanto, elaborar o processo de desativação da replicação da cadeia. A principal razão pela qual a replicação em cadeia pode ser desabilitada é se ela estiver causando atraso. O mérito da replicação da cadeia é, no entanto, superior ao demérito do atraso e, portanto, na maioria dos casos, desativá-lo é desnecessário. Caso a replicação em cadeia não esteja ativa por padrão, os comandos a seguir o ajudarão a ativar.
cfg = rs.config()
cfg.settings.chainingAllowed = true
rs.reconfig(cfg)Este processo é reversível. Quando forçado a desativar a replicação em cadeia, o seguinte processo é seguido religiosamente.
cfg = rs.config()
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)Dicas e truques para replicação em cadeia
As limitações mais terríveis da replicação em cadeia é o atraso na replicação. O atraso de replicação refere-se ao atraso que ocorre entre o momento em que uma operação é feita no primário e quando a mesma operação é replicada no secundário. Embora seja naturalmente impossível, é sempre desejável que a velocidade de replicação seja muito alta nesse atraso de replicação seja zero. Para evitar ou minimizar o atraso de replicação para ser próximo de zero, é um critério de projeto prudente usar hosts primários e secundários com as mesmas especificações em termos de CPU, RAM, E/S e especificações relacionadas à rede.
Embora a replicação em cadeia garanta a disponibilidade de dados, a replicação em cadeia pode ser usada junto com o registro no diário. O registro no diário fornece segurança de dados gravando em um log que é liberado regularmente no disco. Quando os dois são combinados, três servidores são gravados por solicitação de gravação, diferentemente da replicação em cadeia, onde apenas dois servidores são gravados por solicitação de gravação.
Outra dica importante é usar w com replicação. O parâmetro w controla o número de servidores nos quais uma resposta deve ser gravada antes de retornar com sucesso. Quando o parâmetro w é definido, o getlasterror verifica o oplog dos servidores e aguarda até que o número determinado de servidores 'w' tenha a operação aplicada.
O uso de uma ferramenta de monitoramento como MongoDB Monitoring Service (MMS) ou ClusterControl permite obter o status de seus nós de réplica e visualizar as alterações ao longo do tempo. Por exemplo, no MMS, você pode encontrar gráficos de atraso de réplica dos nós secundários mostrando a variação no tempo de atraso de replicação.
Medindo o desempenho da replicação da cadeia
Até agora você está ciente de que o parâmetro de desempenho mais importante da replicação em cadeia é o tempo de atraso da replicação. Portanto, discutiremos como testar o período de atraso de replicação. Este teste pode ser feito através do shell script MongoDb. Para fazer um teste de atraso de replicação, comparamos o oplog do último evento no nó primário e o oplog do último evento no nó secundário.
Para verificar as informações do nó primário, executamos o código a seguir.
db.printSlaveReplicationInfo()O comando acima fornecerá informações sobre todas as operações recentes no nó primário. Os resultados devem aparecer conforme abaixo.
rs-ds046297:PRIMARY db.printSlaveReplicationInfo()
source: ds046297-a1.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)
source: ds046297-a2.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)Tendo obtido o oplog para o primário, agora estamos interessados no oplog para o nó secundário. O comando a seguir nos ajudará a obter o oplog.
db.printReplicationInfo()Este comando fornecerá uma saída com detalhes sobre o tamanho do oplog, comprimento do log, tempo para o primeiro evento do oplog, tempo para o último evento do oplog e a hora atual. Os resultados aparecem como abaixo.
rs-ds046297:PRIMARY db.printReplicationInfo()
configured oplog size: 1024MB
log length start to end: 5589 secs (1.55hrs)
oplog first event time: Tue Mar 05 2013 06:15:19 GMT-0800 (PST)
oplog last event time: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
now: Tue Mar 05 2013 09:53:07 GMT-0800 (PST)A partir do oplog do servidor primário, a última sincronização ocorreu em 05 de março de 2013 07:48:19 GMT-0800 (PST). A partir do oplog do servidor secundário, a última operação ocorreu em 05 de março de 2013 07:48:19 GMT-0800 (PST). O atraso de replicação foi zero e, portanto, nosso sistema replicado em cadeia está em operação correta. No entanto, o intervalo de tempo de replicação pode variar dependendo da quantidade de alterações que precisam ser replicadas.
