2012-07-17 9 views
6

Sto usando MongoDB da un po 'di tempo e ho visto che fsync aspetta che i dati vengano scaricati sul disco. Ok, quindi ho pensato che fosse la soluzione per la sicurezza dei dati.Per che cosa è il fsync di MongoDB?

Ha funzionato bene con tempi lunghi, più lunghi rispetto a quelli di SQL. Poi ho visto che posso mettere il syncdelay a 0, quindi la velocità è tornata, ma ho pensato a come sarebbe in futuro con molte richieste simultanee. Così ho rimosso l'opzione fsync dagli aggiornamenti e inserimenti e rimosso l'opzione di configurazione syncdelay.

Per verificare se i dati sono stati scritti, ho controllato rapidamente Rockmongo dopo aver effettuato un aggiornamento ei dati erano effettivamente lì, super veloci!

Quindi, in realtà, che cosa è fsync per se fa le scritture lente e senza di essa le scritture avvengono, e veloce comunque?

risposta

5

Per Mongo documentazione:

L'uso primario di fsync è quello di irrigare e bloccare il database per i backup.

anche

I blocchi operazione fsync tutte le altre operazioni di scrittura per un po 'si corre.

Il blocco sembra essere il motivo.

4

fsync è tecnicamente un comando di amministrazione che forza il flusso di tutti i dati su disco. Non dovresti usarlo nel tuo codice, normalmente non almeno. È usato per bloccare il database per i backup e così via.

La sicurezza dei dati in MongoDB deriva dalla replica/sharding/journaling, non dal forzare le scritture. Questo tipo di sconfigge lo scopo della cosa.

Il driver Java avvolge questo concetto di 'scrittura e sincronizzazione' nella classe WriteConcern, che non mi è mai piaciuta molto. Non dovresti decidere quale parte dei tuoi dati è più o meno importante, ma piuttosto fidarti dello strumento per fare il suo lavoro.

Inoltre, se si imposta syncdelay su zero, assicurarsi di disattivare l'inserimento nel journal. Vedi this.

+0

La mia più grande preoccupazione era che Mongo memorizzava i dati sulla memoria e poi sul disco dopo il syncdelay, e se l'utente riceve un msg di successo ma l'hardware ha fallito prima di quella sincronizzazione, sostanzialmente, un grosso errore. Ho ragione? o c'è una soluzione a questo? – Hadrian

+0

Ancora, replica.MongoDB è un archivio dati distribuito, non un RDBMS. Una singola istanza di MongoDB è essenzialmente _useless_, perché non si può fare affidamento sul fatto che sia durevole da solo. Una volta che hai due istanze, non devi preoccuparti dell'errore hardware. – kprobst

+0

Una singola istanza con l'inserimento nel journal va bene per la durata, in particolare con il problema di scrittura di Journaling. – MrKurt

0

Come le altre risposte hanno detto, il comando fsync impone un flush e viene normalmente utilizzato prima di bloccare i file di dati per un'istantanea point-in-time.

C'è un "fsync" write concern option su getLastError che attenderà il ritorno in tutti i dati in sospeso è stato svuotato su disco. Normalmente non lo useresti, ma l'opzione "j" (che ritorna non appena è avvenuto il journal) è molto più veloce da restituire e garantisce comunque scritture durature. È possibile passare tramite un comando di aggiornamento/inserimento come opzione sicura nel driver di scelta per consentire l'esecuzione automatica del comando getLastError.