mongodb shard chunk migrazione 500GB richiede 13 giorni - È lento o normale?


9

Ho un cluster di frammenti di mongodb, la chiave di shard è cancellata. Ha 2 set di repliche di frammenti. Ogni set di repliche ha 2 macchine.

Ho fatto un esperimento aggiungendo altri 2 set di repliche di frammenti e inizia a riequilibrare.

Tuttavia, dopo un po 'scopro che la migrazione dei blocchi è piuttosto lenta. Occorrono 1 ora per spostare 1,4 GB di dati.

Mi fa preoccupare, significa che devo aspettare 13 giorni per completare 500 GB di migrazione dei blocchi!

Sono nuovo su questa roba e non ho la sensazione che sia lento, veloce o normale. Ma comunque, quel numero non mi convince.

Note aggiuntive sull'esperimento: - utilizzo di macchine m3 medium aws - nessun altro processo in esecuzione, solo migrazione del blocco - installazione di sharding mongodb predefinita senza ulteriore configurazione - shardkey utilizza l'hash nell'ID oggetto (_id) - dimensione massima del blocco 64 MB

Risposte:


10

Aggiornamento: aprile 2018

Questa risposta era corretta al momento della domanda, ma da allora le cose sono andate avanti. Dalla versione 3.4 è stato introdotto il parallelismo e il ticket a cui ho fatto riferimento in origine è stato chiuso. Per maggiori informazioni tratterò alcuni dettagli in questa risposta più recente . Lascerò il resto della risposta così com'è perché rimane un buon riferimento per problemi / vincoli generali, nonché valido per chiunque abbia una versione precedente.

Risposta originale

Fornisco una spiegazione completa di ciò che accade con una migrazione di blocchi nel corso M202 Advanced se sei interessato. In termini generali, diciamo solo che le migrazioni non sono molto veloci, anche per i pezzi vuoti, a causa delle pulizie eseguite per assicurarsi che le migrazioni funzionino in un sistema attivo (queste continuano ad accadere anche se non si verifica altro che il bilanciamento).

Inoltre, si verifica una sola migrazione alla volta sull'intero cluster: non esiste parallelismo. Quindi, nonostante il fatto che tu abbia due nodi "completi" e due nodi "vuoti", in qualsiasi momento si sta verificando al massimo una migrazione (tra il frammento con il maggior numero di blocchi e il frammento con il minimo). Quindi, dopo aver aggiunto 2 frammenti non guadagni nulla in termini di velocità di bilanciamento e aumenta solo il numero di blocchi che devono essere spostati.

Per le migrazioni stesse, è probabile che i blocchi abbiano una dimensione di ~ 30 MiB (dipende da come sono stati popolati i dati, ma in genere questa sarà la media con la dimensione massima predefinita del blocco). Puoi candidarti db.collection.getShardDistribution()per alcune di queste informazioni e vedere la mia risposta qui per ottenere ulteriori informazioni sui tuoi blocchi.

Poiché non è in corso alcuna altra attività, affinché avvenga una migrazione, il frammento di destinazione (uno dei nuovi frammenti aggiunti di recente) dovrà leggere ~ 30 MiB di dati dai frammenti di origine (uno dei 2 originali) e aggiornare i server di configurazione su riflettere la nuova posizione del blocco una volta terminata. Lo spostamento di 30 MiB di dati non dovrebbe rappresentare un grosso collo di bottiglia per un sistema normale senza carico.

Se è lento, ci sono una serie di possibili motivi per cui questo è il caso, ma i più comuni per un sistema che non è occupato sono:

  • I / O del disco di origine: se i dati non si trovano nella memoria attiva quando vengono letti, devono essere paginati dal disco
  • Rete: in caso di latenza, limitazione della velocità, perdita di pacchetti ecc., La lettura potrebbe richiedere del tempo
  • I / O su disco di destinazione: i dati e gli indici devono essere scritti su disco, molti indici possono peggiorare le cose, ma di solito questo non è un problema su un sistema leggermente caricato
  • Problemi con le migrazioni che causano interruzioni e migrazioni non riuscite (problemi con i server di configurazione, problemi con le eliminazioni sulle primarie)
  • Ritardo di replica: per le migrazioni ai set di repliche, scrivere preoccupazione w:2o w:majorityviene utilizzato per impostazione predefinita e richiede secondari aggiornati per soddisfarlo.

Se il sistema era occupato, allora la contesa di memoria, la contesa di blocco di solito sarebbe sospetta anche qui.

Per ulteriori informazioni su quanto tempo impiegano le migrazioni, in caso di errore, ecc., Dai un'occhiata alle voci nel tuo config.changelog:

// connect to mongos
use config
db.changelog.find()

Come hai visto, e come dico generalmente alle persone quando faccio formazione / istruzione, se sai che avrai bisogno di 4 frammenti, di solito è meglio iniziare con 4 piuttosto che aumentare. Se lo fai, allora devi essere consapevole che l'aggiunta di un frammento può richiedere molto tempo, e inizialmente è un netto negativo sulle risorse piuttosto che un guadagno (vedi la parte II della mia serie di insidie per una discussione più dettagliata di ciò).

Infine, per tracciare / migliorare / commentare la richiesta di funzionalità per migliorare il parallelismo delle migrazioni di blocchi, controlla SERVER-4355


Grazie, questo spiega il meccanismo di migrazione dei blocchi molto più della documentazione di mongodb.
rendybjunior,

Parteciperò sicuramente al tuo corso. :) Cosa ne pensi della velocità che ho citato prima? È normale o lento? So che questa domanda è relativa in base a molti aspetti. Ma sto chiedendo la tua propria opinione
rendybjunior

Sembra un po 'lento in base alla tua descrizione, ma per essere sicuro dovrei fare un benchmark delle istanze medie. Il tuo tasso attuale potrebbe essere tutto ciò di cui è capace, oppure potresti avere uno dei problemi che ho menzionato nella risposta. Un controllo che puoi provare è una mossa manuale del pezzo: spegni il bilanciatore e essenzialmente fai da te per vedere se ci sono problemi e quale impatto ha una mossa sui sistemi di origine / destinazione. Puoi trovare i dettagli rilevanti su moveChunk qui: docs.mongodb.org/manual/reference/method/sh.moveChunk
Adam C

Solo per aggiungere che la mirgazione dei pezzi ha una bassa priorità su mongoDB e anche sui sistemi ad alte prestazioni possono richiedere del tempo se sono occupati.
Antonios,

@Antonis - non sono sicuro di cosa intendi per priorità, una migrazione del blocco è una lettura dal frammento di origine (uguale a qualsiasi altra lettura) e una scrittura sul frammento di destinazione (con la preoccupazione di scrittura sopra menzionata), non c'è priorità per queste operazioni rispetto ad altri. Saranno lenti su sistemi occupati, ma non a causa di alcuna differenza di priorità intrinseca.
Adam C,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.