MongoDB
 sql >> Database >  >> NoSQL >> MongoDB

Una guida per sviluppatori ai set di repliche MongoDB

MongoDB spesso implica l'utilizzo di un ampio set di dati, inclusi array incorporati e oggetti array. Pertanto, è sempre importante assicurarsi che la velocità di elaborazione del database sia il più veloce possibile per migliorare le operazioni di lettura e scrittura. Inoltre, per evitare anomalie dei dati che possono verificarsi a causa dell'incoerenza dei dati, è necessario assicurarsi che i dati siano in maggiore disponibilità nel caso in cui si desideri ottenere un ripristino da un guasto hardware o da alcune interruzioni del servizio. MongoDB fornisce alcuni 2 concetti a tale scopo:ReplicaSet e Sharding.

Replica in MongoDB

Replica master-slave

Questa è una delle tecniche più antiche utilizzate per garantire che i dati siano sempre disponibili per gli utenti anche in caso di guasto di un sistema. Tuttavia, la replica Master-Slave è deprecata nelle ultime versioni di MongoDB a partire dalla 3.2 ed è stata quindi sostituita con i set di repliche.

Per effettuare questa configurazione, si avviano 2 istanze mongod considerando che una è in modalità master e l'altra è in modalità slave.

Per avviare un'istanza in modalità master, esegui:

mongod --master --port portNumber

Le opzioni --master indicano a mongod di creare una raccolta local.oplog.$main con la quale un elenco di operazioni viene accodato agli slave da applicare nella replica dei dati.

Per avviare un'istanza mongod in modalità slave, esegui:

mongod --slave --source <masterhostname><:<port>>

Qui è necessario specificare il nome host e la porta dell'istanza master nell'argomento --source. Questa è una panoramica riepilogativa dell'utilizzo della replica master slave e poiché è deprecata, il nostro interesse sarà sui set di repliche.

Set di repliche

Questo è un gruppo di processi MongoDB noti come istanze mongod che sostanzialmente ospitano lo stesso set di dati. È caratterizzato da un nodo primario e diversi nodi secondari per il rilevamento dei dati. Il nodo primario riceve tutte le operazioni di scrittura e registra tutte le altre modifiche al proprio set di dati nel proprio registro delle operazioni. I nodi secondari, all'altra estremità, replicano il registro delle operazioni del primario e applicano le operazioni al loro set di dati in modo che i loro set di dati riflettano il set di dati del primario. In parole semplici, possiamo dire di avere la macchina A come nodo primario e la macchina B e C come nodi secondari. La macchina A riceve un'operazione di scrittura e apporta modifiche ai suoi dati, quindi crea un elenco delle modifiche apportate. Le macchine B e C copieranno quindi le operazioni dall'elenco fornito, in questo caso l'oplog, e le eseguiranno in modo che i dati risultanti siano gli stessi della macchina A.

Come accennato in precedenza, è sempre importante garantire un'elevata disponibilità dei dati, soprattutto nell'ambiente di produzione. La replica viene in aiuto fornendo la ridondanza dei dati in diverse istanze di Mongod. In caso di perdita di dati, poiché le copie degli stessi dati sono archiviate su database diversi in più posizioni, è facile recuperarli in quello esistente.

Con molte istanze in esecuzione, le operazioni di lettura e scrittura dai client vengono inviate a server diversi e quindi la velocità di elaborazione aumenta. La struttura di base del processo di replica è mostrata di seguito.

A volte il principale potrebbe non essere disponibile, ad esempio a causa della disconnessione di Internet o dell'interruzione del servizio. In questo caso, il set di repliche nominerà un nodo secondario come nodo primario. Per quanto le richieste di lettura vengano fondamentalmente inviate al primario, in alcune occasioni le richieste di lettura possono essere inviate ai secondari, ma fai attenzione poiché i dati restituiti potrebbero non riflettere ciò che è nel primario o piuttosto i dati potrebbero non essere aggiornati.

Arbitri

In caso di elezione di una primaria, avrai bisogno di un'istanza mongod aggiuntiva al set di repliche per aggiungere un voto nel processo elettorale. Questa istanza è denominata arbitro e le sue caratteristiche salienti sono:

  1. Non ha una copia del set di dati, quindi non richiede hardware potente come i nodi portanti dati..
  2. Non può essere promosso a primario.
  3. Hanno sempre 1 voto elettorale in modo da consentire al set di repliche di avere un numero dispari di membri votanti senza il sovraccarico di un membro aggiuntivo che replica i dati. Il suo ruolo cruciale è, quindi, selezionare un nodo primario quando non è disponibile.
  4. Rimane invariato.

Contrariamente all'arbitro, altri set di repliche possono essere convertiti in primari da secondari e viceversa.

Replica asincrona

Il processo di replica avviene in due forme di sincronizzazione dei dati. Innanzitutto, i membri del set vengono popolati con dati completi nella sincronizzazione iniziale. La replica successiva ha luogo per applicare le modifiche avanzate all'intero set di dati.

Nella sincronizzazione iniziale, i dati vengono copiati da un membro del set di repliche in un altro. Al termine del processo, il membro passa al nodo secondario.

Failover automatico di MongoDB

Può verificarsi un'interruzione del servizio come la disconnessione della rete che deriva dall'interruzione della comunicazione tra il primario e i secondari. Se la disconnessione dura più di 10 secondi o non riesce completamente, il set di repliche rimanente voterà affinché un membro diventi il ​​nuovo primario. Il nodo secondario che ottiene la maggioranza dei voti diventa il nuovo primario.

Nella versione 3.0 di MongoDB, un set di repliche può avere fino a 50 membri con 7 membri votanti.

Membri dell'insieme di repliche con priorità zero

Questi sono membri secondari che non possono né transitare per essere nodi primari né possono attivare un'elezione. I ruoli cruciali nel set di dati sono:mantenere le copie del set di dati, eleggere un nodo primario ed eseguire operazioni di lettura. Agiscono come un backup in cui un nuovo membro potrebbe non riuscire ad aggiungere immediatamente. Memorizzerà così i dati aggiornati e potrà sostituire immediatamente un membro non disponibile.

Membri del set di repliche nascoste MongoDB

Questi sono membri senza alcuna connessione alle applicazioni client. Vengono utilizzati per carichi di lavoro con requisiti di utilizzo diversi da altri membri secondari. Ricevono solo il traffico di replica di base durante la sincronizzazione iniziale.

Membri del set di repliche ritardate MongoDB

Questi copiano i dati dal file oplog del nodo primario entro una durata specificata. Riflettono sempre lo stato ritardato o una forma precedente dell'insieme. Sono quindi importanti per rilevare gli errori e forniscono un suggerimento su come recuperare da tali errori, ad esempio se è presente un database che è stato eliminato. Quando si sceglie l'importo del ritardo, questo dovrebbe essere preso in considerazione:

  1. La durata dovrebbe essere inferiore alla capacità del registro delle operazioni, che per i motori di archiviazione WiredTiger, MMAPv1 e In-Memory è di 50 GB. In caso contrario, il membro ritardato non potrà replicare correttamente le operazioni.
  2. La durata del ritardo dovrebbe essere uguale o leggermente superiore alla durata prevista della finestra di manutenzione.

Configurazione

Questo è un membro a priorità zero, è nascosto quindi non visibile alle candidature e infine può partecipare al processo elettorale. Pertanto, per configurare una priorità, supponiamo che tu abbia 10 membri nel tuo set di repliche, puoi selezionare un membro nella posizione n come membro[n] e impostarne le proprietà come:

{
    “_id”: <num>, 
    “Host”: <hostname: port>,
    “Priority”: 0,
    “slaveDelay”: <seconds>,
    “Hidden”: true
}

Oppure utilizzando la shell mongo collegata al primario puoi eseguire questi comandi per impostare il primo membro del set di repliche come ritardato:

cfg = rs.conf()
cfg.members[0].priority = 0
cfg.members[0].hidden = true
cfg.members[0].slaveDelay = 3600
rs.reconfig(cfg)

Dopo aver impostato queste configurazioni, il secondario ritardato non può diventare un primario e quindi nascosto alle applicazioni. Il Membro sarà ritardato di 1 ora (3600 secondi) dalle operazioni di oplog.

Multiplenines Diventa un DBA MongoDB - Portare MongoDB in produzioneScopri cosa devi sapere per distribuire, monitorare, gestire e ridimensionare MongoDBScarica gratuitamente

Come avviare un set di repliche

In questa guida vedremo passo dopo passo come configurare una replica impostata in MongoDB.

  1. Diciamo che hai 3 mongodb che vuoi replicare e che sono configurati come segue:
    1. Mongod1.conf in esecuzione sulla porta 27017
    2. Mongod2.conf in esecuzione sulla porta 27018
    3. Mongod3.conf in esecuzione sulla porta 27019

    Assicurati di aggiungere il nome del set di repliche che non cambierà in ogni file. Puoi farlo aggiungendo o modificando il valore dell'opzione replSet con un nome a tua scelta.

  2. Possiamo avviare la prima istanza eseguendo

    sudo mongod --config /etc/mongo/mongod1.conf

    Questo è se non hai un'istanza in esecuzione mongod. Quindi fai lo stesso per le altre istanze. Per verificare la presenza di istanze in esecuzione nella tua macchina esegui

    ps -ax | grep mongo

    Otterrai una lista come questa:

    4328 ttys000    0:06.15 mongod
4950 ttys001    0:00.00 grep mongo
    Ciò significa che la prima istanza in MongoDB per impostazione predefinita viene eseguita sulla porta 27017, quindi l'abbiamo come prima nell'elenco. Se hai avviato gli altri, verranno anche delineati nell'elenco con i relativi URL di percorso. Per connetterti a un'istanza nella mongo shell, esegui questo comando:
    mongo  --port port_number i.e mongo  --port 27017.
    Tuttavia nel nostro caso dobbiamo connetterci con un nome di set di repliche, quindi dobbiamo aggiungere il nome al comando:
    mongod --replSet replicaSetName --dbpath /usr/local/var/mongo/mongod --port 27017
    In questo caso il nostro replicaSetName =“testrep”

  3. Verifichiamo se esiste un set di repliche abilitato eseguendo rs.status()

    Se ottieni un risultato del tipo:

    {
    "ok" : 0,
    "errmsg" : "not running with --replSet",
    "code" : 76,
    "codeName" : "NoReplicationEnabled"
}

    Quindi significa che non esiste un set di repliche abilitato. Altrimenti se ottieni il risultato come

    {
    "operationTime" : Timestamp(0, 0),
    "ok" : 0,
    "errmsg" : "no replset config has been received",
    "code" : 94,
    "codeName" : "NotYetInitialized",
    "$clusterTime" : {
        "clusterTime" : Timestamp(0, 0),
        "signature" : {
            "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
            "keyId" : NumberLong(0)
        }
    }
}

    quindi significa che la replica non è ancora stata avviata.

  4. Il metodo rs.initiate() ci aiuterà ad avviare un nuovo set di repliche e l'istanza all'interno della quale viene avviato diventa il nostro nodo primario. Quindi possiamo avviarne uno nella nostra istanza eseguendo il metodo di avvio. rs.initiate().

  5. Controllare di nuovo lo stato del set di repliche eseguendo rs.status().members. Ora dovresti vedere qualcosa come

    "members" : [
        {
            "_id" : 0,
            "name" : "localhost:27018",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 577,
            "optime" : {
                "ts" : Timestamp(1535301271, 1),
                "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2018-08-26T16:34:31Z"),
            "syncingTo" : "",
            "syncSourceHost" : "",
            "syncSourceId" : -1,
            "infoMessage" : "could not find member to sync from",
            "electionTime" : Timestamp(1535301265, 1),
            "electionDate" : ISODate("2018-08-26T16:34:25Z"),
            "configVersion" : 1,
            "self" : true,
            "lastHeartbeatMessage" : ""
        }
    ]

    Bene, buono per andare. Il nostro interesse sarà l'opzione membri, come possiamo vedere è n array con 1 membro in esso. Selezionando l'opzione stateStr del primo membro in questo caso è impostata su Primaria, il che significa che fungerà da nostro nodo primario.

  6. Aggiungi un nuovo membro al set di repliche utilizzando il suo nome host. Per verificare il nome host dell'istanza connessa che desideri aggiungere esegui

    db.serverStatus().host

    Otterrai qualcosa come

    ervername.local:27019

    Quindi da PRIMARY puoi aggiungere un altro membro eseguendo questo comando nella mongo shell:

    rs.add("servername.local:27019");

  7. Esegui il comando di stato

    rs.status().members

    Per verificare se le modifiche sono state apportate.

    Ora dovresti avere qualcosa simile a questo:

    [
    {
        "_id" : 0,
        "name" : "localhost:27018",
        "health" : 1,
        "state" : 1,
        "stateStr" : "PRIMARY",
        "uptime" : 11479,
        "optime" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
        "syncingTo" : "",
        "syncSourceHost" : "",
        "syncSourceId" : -1,
        "infoMessage" : "",
        "electionTime" : Timestamp(1535301265, 1),
        "electionDate" : ISODate("2018-08-26T16:34:25Z"),
        "configVersion" : 2,
        "self" : true,
        "lastHeartbeatMessage" : ""
    },
    {
        "_id" : 1,
        "name" : "127.0.0.1:27019",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "uptime" : 15,
        "optime" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDurable" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
        "optimeDurableDate" : ISODate("2018-08-26T19:36:23Z"),
        "lastHeartbeat" : ISODate("2018-08-26T19:36:26.302Z"),
        "lastHeartbeatRecv" : ISODate("2018-08-26T19:36:27.936Z"),
        "pingMs" : NumberLong(0),
        "lastHeartbeatMessage" : "",
        "syncingTo" : "localhost:27018",
        "syncSourceHost" : "localhost:27018",
        "syncSourceId" : 0,
        "infoMessage" : "",
        "configVersion" : 2
    }
]

    Ora abbiamo 2 membri, uno è un nodo PRIMARIO e l'altro è un nodo SECONDARIO. Puoi aggiungere più membri ma non superare 50. Ora creiamo un database nell'istanza sulla porta 27018 come primario.

    Se disconnettiamo il primario, si verificherà un failover e poiché abbiamo solo 1 primario, verrà automaticamente trasferito in un secondario. Ora se ci colleghiamo a quello sulla porta 27019 dovresti ottenere gli stessi database e raccolte con i loro documenti.

    Ora, se il nodo primario disconnesso viene ricollegato, verrà aggiunto come secondario poiché copia le operazioni dall'oplog del primario esistente.

Preoccupazione per la scrittura della replica MongoDB

Se MongoDB restituisce un problema di scrittura su journal riuscito, i dati verranno archiviati sul disco e diventano quindi disponibili dopo il riavvio di mongod. Tuttavia, per le operazioni di scrittura, i dati sono durevoli solo dopo essere stati replicati e impegnati nel journal a favore della maggioranza dei membri votanti del set di repliche.

Alcuni dati potrebbero essere troppo grandi per essere aggiornati o inseriti, quindi potrebbe richiedere più tempo del previsto per la replica dei dati in altri membri. Per questo motivo è consigliabile modificare le configurazioni di writeConcern per tener conto della durata entro la quale deve essere eseguita un'operazione. Le configurazioni di writeConcern predefinite impongono che il set di repliche richieda il riconoscimento solo dal membro primario. Un problema di scrittura predefinito conferma le operazioni di scrittura solo per il primario, ma può essere sovrascritto per controllare le operazioni di scrittura su alcuni membri del set di repliche specificando il problema di scrittura per un'operazione di scrittura specifica. Ad esempio:

db.books.insert({name: “James”,place: “Beijing”},{writeConcern: {w: 3, wtimeout: 3600}})

L'opzione di scrittura in questo caso impone che l'operazione restituisca una risposta solo dopo che è stata diffusa al primario e ad almeno 2 secondari o se scade dopo 3,6 secondi.

Configurazione del problema di scrittura per MongoDB

L'opzione MongoDB getLastErrorDefaults fornisce i parametri per modificare le impostazioni predefinite relative alla scrittura nella configurazione del set di repliche. Ciò implica che l'operazione deve essere completata nella maggior parte dei membri votanti prima di restituire il risultato.

cfg = rs.conf()
cfg.settings = {},
cfg.settings.getLastErrorDefaults = {w: “majority”, wtimeout: 3600}
rs.reconfig(cfg)

Il valore di timeout impedirà il blocco delle operazioni di scrittura, vale a dire, se si suppone che ci siano 5 membri per riconoscere il problema di scrittura ma sfortunatamente ci sono 4 o meno membri nel set di repliche, l'operazione si bloccherà finché tutti i membri non saranno disponibili. Aggiungendo la soglia di timeout, il blocco dell'operazione verrà annullato dopo questa durata.

Blocco delle repliche

Il blocco di un'operazione, in particolare quando tutti i membri sono stati replicati, assicura che non verrà più perso tempo in attesa che un altro membro del set di repliche sia disponibile per restituire una risposta. L'opzione del comando getLastError di MongoDB determina come viene eseguito l'aggiornamento della replica utilizzando l'attributo "w" opzionale.

Ad esempio, questa query

db.runCommand({getLastError: 1, w: N, “wtimeout”: 5000});

richiede che il blocco si verifichi fino a quando N numero di membri non avrà replicato l'ultima operazione di scrittura. Se N è disponibile o è minore di 2, verrà restituita la query. Altrimenti se il valore di N è uguale a 2, il master equivalente al primario risponderà solo dopo che 1 dei suoi slave è stato replicato all'ultima operazione.

Il timeout il parametro è fondamentalmente quello di impostare il tempo in millisecondi dopo il quale il comando getLastError scadrà e restituirà un errore prima che l'ultima opzione sia stata replicata.

Per quanto il blocco sia in qualche modo vantaggioso, a volte ha un limite. Rallenta notevolmente le operazioni di lettura soprattutto se si imposta il valore "w" su un valore troppo grande. Ti consiglio di impostare il valore "w" su 2 o 3 per una maggiore sicurezza ed efficienza.

Leggi la preferenza in MongoDB

Questo è fondamentalmente il percorso adiacente con cui vengono eseguite le operazioni di lettura del client sul set di repliche. L'impostazione predefinita di MongoDB configura le operazioni di lettura sul primario perché è quella con l'ultima versione del documento che stai recuperando. Come accennato in precedenza, il vantaggio supremo per sfruttare il set di repliche è migliorare le prestazioni del nostro sistema di database. Pertanto, è consigliabile distribuire le operazioni di lettura a molti membri secondari per ridurre la latenza per le applicazioni che non richiedono necessariamente dati aggiornati. Tuttavia, ci sono ragioni più cruciali per cui dovresti usare anche la primaria come preferenza di base:

  1. Mantenimento della disponibilità dei dati durante il failover.
  2. Per le applicazioni distribuite geograficamente, il primario fornirà letture locali per i client nello stesso data center.
  3. Non influenzare le applicazioni front-end, in particolare quelle che eseguono operazioni di sistema.

Mongo.setReadPref() Metodo

Questo metodo serve fondamentalmente a definire come il client instraderà tutte le query ai membri del set di repliche. Richiede 2 argomenti, modalità e tagSet.

L'argomento mode specifica la preferenza di lettura che può essere primary, primaryPreferred, secondary, secondaryPreferred o più vicino.

La modalità tagSet specifica la preferenza di lettura personalizzata. Puoi anche specificarli come una matrice di oggetti. Un esempio di configurazione sarà:

db.getMongo().setReadPref('primaryPreferred',
                          [ { "dc": "east", "use": "production" },
                            { "dc": "east", "use": "reporting" },
                            { "dc": "east" },
                            {}
                          ] )

Quello che succede qui è che, se il client tenta di accedere al primo tag e la richiesta non va a buon fine, verrà optato per la seconda preferenza di lettura.

Leggi le modalità di preferenza

  • Primario:definisce che tutte le operazioni di lettura lette da un determinato set di repliche sono primarie ed è la modalità di lettura preferita predefinita.
  • PrimaryPreferred:se solo il primario non è disponibile, le operazioni di lettura possono essere eseguite dai secondari.
  • Secondario:tutte le operazioni di lettura vengono eseguite dai membri secondari del set di repliche.
  • SecondaryPreferred:se solo non c'è un secondario disponibile, le operazioni di lettura possono essere fatte dal primario.
  • Più vicino:il membro con la latenza di rete minima viene selezionato per l'operazione di lettura indipendentemente dal tipo.

Set di tag e loro configurazione

Queste sono opzioni che ti consentono di modellare il modo in cui desideri che appaiano le tue preferenze di scrittura e lettura. Sono archiviati all'interno dell'oggetto di configurazione del set di repliche. Se esegui rs.conf().members, otterrai questo oggetto restituito:

[
    {
        "_id" : 0,
        "host" : "localhost:27018",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    },
    {
        "_id" : 1,
        "host" : "127.0.0.1:27019",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    }
]

Come puoi vedere, ogni membro ha un attributo tag.

La principale differenza tra Read Preferences e Write Concern è che il primo considera il valore di un tag quando seleziona un membro da cui leggere mentre il secondo no.

Supponiamo che un set di tag per un'operazione di lettura sia impostato su:

{ "disk": "ssd", "use": "reporting" }

Un membro nel set di repliche deve soddisfare questi tag affinché l'operazione di lettura possa essere eseguita. Quindi per dire, una configurazione come questa

{ "disk": "ssd", "use": "reporting", "rack": "a" }

soddisferà la query mentre questa

{ "disk": "ssd", "use": "production", "rack": "k" }

non soddisferà la query.

Aggiunta di tag a una replica di set

Per il membro selezionato in un set di repliche, puoi aggiungere set di tag utilizzando il metodo rs.conf() in MongoDB.

Supponiamo che tu abbia selezionato un membro nella posizione 1 del tuo array di set di repliche, puoi aggiungere set di tag come segue.

conf = rs.conf()
conf.members[0].tags = { "dc": "NYK", "use": "production"  }
conf.members[1].tags = { "dc": "LON", "use": "reporting"  }
conf.members[2].tags = { "use": "production"  }
rs.reconfig(conf)

Modelli di distribuzione per il set di repliche MongoDB

  1. Set di repliche distribuite geograficamente - Migliora la ridondanza dei dati oltre a proteggere i dati da guasti come la perdita di alimentazione. Le istanze in esecuzione si trovano in più posizioni.
  2. Set di repliche a tre membri:l'architettura standard di base per un set di repliche.
  3. Set di repliche a quattro o più membri:consente una più ampia ridondanza dei dati e supporta anche una distribuzione più ampia delle operazioni di lettura nel set di repliche.

Tecniche di ottimizzazione della distribuzione dei set di repliche MongoDB

Un set di repliche ideale richiederà un'architettura ben strutturata con almeno 3 membri per un sistema di produzione. Queste strategie di distribuzione ti aiuteranno a abilitare un ottimo set di repliche.

  1. Utilizza membri ritardati e nascosti per supportare funzioni dedicate come reportistica e backup.
  2. Rendi sempre dispari il numero dei membri schierati. Come abbiamo discusso sopra, per eleggere una primaria sarà richiesto un numero dispari di membri. Quindi assicurati di avere un numero dispari e, in caso contrario, puoi sempre aggiungere un arbitro.
  3. Per le distribuzioni di lettura pesante, dovrai bilanciare il carico. Ti verrà quindi richiesto di distribuire le letture al secondario per migliorare le prestazioni di lettura. Inoltre, quando i dati crescono con il tempo, puoi aggiungere più membri e distribuirli, ma tieni presente che devi configurarli in modo tale che il design fondamentale sia quello di eleggere il primario.
  4. Considera sempre la tolleranza agli errori. Questo sta sostanzialmente determinando quanti membri possono non essere disponibili in un dato momento e quanti rimarranno per sostenere il processo elettorale di una primaria. Se non disponi di una primaria, sfortunatamente il set di repliche non accetterà alcuna operazione di scrittura.
  5. Aggiungi nuovi membri al set di repliche esistente prima che sorga la domanda.
  6. Utilizzare i set di tag dei set di repliche per garantire che tutte le operazioni vengano replicate in data center specifici. Puoi anche utilizzare questi tag nel routing per le operazioni di lettura per macchine di distribuzione specifiche.
  7. Distribuisci la maggior parte dei tuoi membri in un'unica posizione per evitare la battuta d'arresto che deriverà dal partizionamento di rete. Il partizionamento di rete può essere il risultato di comunicazioni disconnesse tra i data center, ostacolando di conseguenza il processo di replica e il processo di elezione di un primario.
  8. Per motivi di sicurezza, distribuisci geograficamente i tuoi membri oltre a nasconderne alcuni. Puoi impostare a zero la priorità di almeno 2 o 3 membri per evitare di renderli primari.
  9. Utilizza il journaling per proteggere la perdita di dati che potrebbe comportare qualcosa come un'interruzione di corrente. Ciò garantisce che i dati vengano scritti su disco in caso di arresto improvviso.

Il registro delle operazioni (Oplog)

L'oplog conserva un registro delle operazioni master che devono essere applicate agli slave. È memorizzato in un database chiamato local nella raccolta oplog.$main. Viene creato quando si avvia per la prima volta un membro del set di repliche. Sul limite superiore, l'oplog è limitato a una dimensione di 50 GB per tutti i motori di archiviazione. La dimensione dell'oplog può essere modificata da un'impostazione predefinita. Se questa dimensione viene raggiunta ad esempio in 24 ore di funzionamento, i secondari non potranno copiarlo comodamente durante questa durata e potrebbero finire per non copiare affatto. Puoi cambiare la dimensione dell'oplog usando l'opzione replSetResizeOplog cioè

db.database({replSetResizeOplog:1, size: 16384})

Se vuoi ridurre le dimensioni di questo oplog, alcuni dati verranno rimossi. L'impatto principale di ciò nel set di repliche è che i membri sincronizzati con questo nodo diventano obsoleti. Pertanto, dovrai risincronizzare questi membri.

Modelli di carico di lavoro che richiederebbero una dimensione di Oplog grande

  1. Aggiorna a più documenti contemporaneamente. Le operazioni di aggiornamento multiple devono essere convertite in una singola operazione per migliorare i risultati tra i nodi. Questa operazione utilizzerà un vasto spazio dello spazio oplog.
  2. Numero significativo di aggiornamenti sul posto. Ciò accade generalmente quando si aggiornano i dati di documenti non necessariamente aumentando le dimensioni di questo documento. Il database registrerà un gran numero di operazioni sull'oplog aumentandone le dimensioni.
  3. Le eliminazioni equivalgono alla stessa quantità di dati degli inserimenti. Ciò accade quando si tenta di eliminare una quantità di dati (quasi) uguale alla quantità di dati inseriti. Questa operazione tenderà ad aumentare le dimensioni dell'oplog.

Conclusione

La replica è un aspetto importante dei database che gli sviluppatori devono comprendere. Garantisce una maggiore disponibilità dei dati. Il tuo server MongoDB potrebbe non funzionare, ad esempio, a causa di un'interruzione di corrente, ma vorresti comunque che i tuoi client accedano ai suoi dati. Se hai replicato i dati in un altro server, i tuoi client potranno continuare ad accedere ai dati da esso se il server primario si guasta. Inoltre, c'è un maggiore bilanciamento del carico in modo che invece di tutti gli utenti che accedono a un singolo server, abbiamo visto i compromessi nel servire il traffico dalle repliche secondarie.