Cos'è la replica a catena?
Quando parliamo di replica, ci riferiamo al processo di creazione di copie ridondanti dei dati al fine di soddisfare i criteri di progettazione sulla disponibilità dei dati. La replica della catena, quindi, si riferisce all'ordinamento lineare dei server MongoDB per formare una catena sincronizzata. La catena contiene un nodo primario, seguito da server secondari disposti in modo lineare. Come suggerisce la catena di parole, il server più vicino al server primario si replica da esso mentre ogni altro server secondario successivo si replica dal server MongoDB secondario precedente. Questa è la principale differenza tra la replica concatenata e la replica normale. La replica concatenata si verifica quando un nodo secondario seleziona la propria destinazione utilizzando il tempo di ping o quando il nodo più vicino è un nodo secondario. Sebbene la replica a catena come appare, riduca il carico sul nodo primario, potrebbe causare un ritardo di replica.
Perché utilizzare la replica a catena?
Le infrastrutture di sistema a volte subiscono guasti imprevedibili che portano alla perdita di un server e quindi alla disponibilità. La replica garantisce che gli errori imprevedibili non influiscano sulla disponibilità. La replica consente inoltre il ripristino da guasti hardware e interruzioni del servizio. Sia la replica concatenata che non concatenata servono a questo scopo di garantire la disponibilità nonostante i guasti del sistema. Avendo stabilito che la replica è importante, potresti chiederti perché usare in particolare la replica a catena. Non vi è alcuna differenza di prestazioni tra la replica concatenata e non concatenata in MongoDb. In entrambi i casi, quando il nodo primario si guasta, i server secondari votano per un nuovo primario funzionante e quindi la scrittura e la lettura dei dati non sono interessate in entrambi i casi. La replica concatenata è tuttavia il tipo di replica predefinito in MongoDb.
Come impostare una replica a catena
Per impostazione predefinita, la replica concatenata è abilitata in MongoDB. Esamineremo quindi il processo di disattivazione della replicazione a catena. Il motivo principale per cui la replica della catena può essere disabilitata è se sta causando un ritardo. Il merito della replicazione a catena è comunque superiore al demerito del lag e quindi nella maggior parte dei casi non è necessario disattivarla. Nel caso in cui la replica a catena non sia attiva per impostazione predefinita, i seguenti comandi ti aiuteranno ad attivarla.
cfg = rs.config()
cfg.settings.chainingAllowed = true
rs.reconfig(cfg)Questo processo è reversibile. Quando è costretto a disattivare la replica a catena, viene seguito religiosamente il seguente processo.
cfg = rs.config()
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)Suggerimenti e trucchi per la replica a catena
Il limite più terribile della replica a catena è il ritardo di replica. Il ritardo di replica si riferisce al ritardo che si verifica tra il momento in cui viene eseguita un'operazione sul primario e quando la stessa operazione viene replicata sul secondario. Sebbene sia naturalmente impossibile, si desidera sempre che la velocità di replicazione sia molto alta in quel ritardo di replicazione sia zero. Per evitare o ridurre al minimo il ritardo di replica vicino allo zero, è un criterio di progettazione prudente utilizzare host primari e secondari con le stesse specifiche in termini di CPU, RAM, IO e specifiche relative alla rete.
Sebbene la replica a catena garantisca la disponibilità dei dati, la replica a catena può essere utilizzata insieme al journaling. Il journaling fornisce la sicurezza dei dati scrivendo in un registro che viene regolarmente scaricato su disco. Quando i due vengono combinati, vengono scritti tre server per richiesta di scrittura, a differenza della sola replica a catena in cui vengono scritti solo due server per richiesta di scrittura.
Un altro consiglio importante è usare w con la replica. Il parametro w controlla il numero di server su cui deve essere scritta una risposta prima di restituire l'esito positivo. Quando il parametro w è impostato, getlasterror controlla l'oplog dei server e attende fino a quando il numero specificato di server "w" non ha applicato l'operazione.
L'utilizzo di uno strumento di monitoraggio come MongoDB Monitoring Service (MMS) o ClusterControl consente di ottenere lo stato dei nodi di replica e visualizzare le modifiche nel tempo. Ad esempio, in MMS, puoi trovare grafici del ritardo di replica dei nodi secondari che mostrano la variazione del tempo di ritardo di replica.
Misurazione delle prestazioni di replica della catena
Ormai sei consapevole che il parametro di prestazione più importante della replica a catena è il tempo di ritardo della replica. Discuteremo quindi come testare il periodo di ritardo di replica. Questo test può essere eseguito tramite lo script della shell MongoDb. Per eseguire un test del ritardo di replica, confrontiamo l'oplog dell'ultimo evento sul nodo primario e l'oplog dell'ultimo evento sul nodo secondario.
Per controllare le informazioni per il nodo primario, eseguiamo il codice seguente.
db.printSlaveReplicationInfo()Il comando precedente fornirà informazioni su tutte le operazioni recenti sul nodo primario. I risultati dovrebbero apparire come di seguito.
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)Dopo aver ottenuto l'oplog per il nodo primario, siamo ora interessati all'oplog per il nodo secondario. Il comando seguente ci aiuterà a ottenere l'oplog.
db.printReplicationInfo()Questo comando fornirà un output con i dettagli sulla dimensione dell'oplog, la lunghezza del registro, l'ora del primo evento dell'oplog, l'ora dell'ultimo evento dell'oplog e l'ora corrente. I risultati vengono visualizzati come di seguito.
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)Dall'oplog del server primario, l'ultima sincronizzazione è avvenuta il mar 05 2013 07:48:19 GMT-0800 (PST). Dall'oplog del server secondario, l'ultima operazione è avvenuta Mar 05 2013 07:48:19 GMT-0800 (PST). Il ritardo di replica era zero e quindi il nostro sistema replicato a catena funziona correttamente. Il ritardo di replica può tuttavia variare a seconda della quantità di modifiche che devono essere replicate.
