È male avere un disco rigido molto pieno su un server di database ad alto traffico?

Esecuzione di un server Ubuntu con MySQL per un server di database di produzione ad alto traffico. Nient'altro è in esecuzione sulla macchina tranne l'istanza di MySQL.

Archiviamo backup giornalieri del database sul server DB, c'è qualche hit nelle prestazioni o motivo per cui dovremmo mantenere il disco rigido relativamente vuoto? Se il disco viene riempito fino all'86% + con il database e tutti i backup, ciò influisce negativamente sulle prestazioni?

Quindi il server DB in esecuzione con una capacità massima dell'86-90% + funzionerebbe meno bene rispetto al server in esecuzione con solo un disco pieno al 10%?

La dimensione totale del disco sul server è superiore a 1 TB, quindi anche il 10% del disco dovrebbe essere sufficiente per lo scambio di O / S di base e simili.

Prima di tutto NON vuoi mantenere i backup del tuo database sulla stessa unità fisica o gruppo RAID del tuo database. La ragione di ciò è che un errore del disco (se si esegue senza alcuna protezione RAID) o un errore RAID catastrofico (se si utilizza RAID-1 o RAID-5) causerà la perdita del backup del database e del database.

La tua domanda sulle prestazioni del disco si riferisce a quanto è piena un'unità disco dipende da come si accede ai dati sul disco. Per i dischi rotanti ci sono due fattori fisici che influenzano le prestazioni I / O. Loro sono:

• tempo di ricerca: è il tempo impiegato dall'unità disco per spostare la testa del disco dalla posizione della traccia corrente alla traccia che contiene i dati richiesti

• latenza di rotazione - che è il tempo medio impiegato dai dati desiderati per raggiungere la testina di lettura mentre l'unità gira - per un'unità da 15 K RPM questo è 2 ms (millisecondi)

Quanto è piena l'unità può influire sul tempo medio di ricerca che gli I / O del server stanno riscontrando. Ad esempio, se l'unità è piena e si dispone di tabelle di database che si trovano fisicamente sull'unità alle estremità opposte estreme dei piatti del disco, quindi mentre si eseguono I / O accedendo ai dati da ciascuna di queste tabelle si verificheranno gli I / O il tempo di ricerca massimo dell'unità.

Detto questo, tuttavia, se l'unità è piena e l'applicazione accede solo a una piccola parte dei dati memorizzati sull'unità e tutti questi dati si trovano contigui sull'unità, questi I / O saranno minimamente influenzati dal tempo di ricerca .

Sfortunatamente, la risposta a questa domanda è che "il tuo chilometraggio varierà", il che significa che il modo in cui l'applicazione accede ai dati e dove si trovano questi dati determinerà quali saranno le prestazioni di I / O.

Inoltre, come indicato da @gravyface, sarebbe "buona pratica" separare i requisiti di archiviazione del sistema operativo dal database. Ancora una volta, ciò contribuirebbe a ridurre al minimo il movimento della testina sulla superficie del disco poiché avere entrambi sulla stessa unità potrebbe causare una ricerca costante tra il sistema operativo e le aree del database dell'unità poiché sia ​​il sistema operativo che il software del database fanno richieste di I / O.

Ci sono due angoli da considerare qui: prestazioni e robustezza.

Per quanto riguarda le prestazioni, si consiglia generalmente di disporre di mandrini del disco separati (o gruppi RAID / set di unità) per:

1. Elementi del sistema operativo (file binari, registri, home directory, ecc.)
2. Scambia spazio (che può essere combinato con (1) se non prevedi di utilizzare lo scambio)
3. Il DB di produzione
4. I registri delle transazioni del DB di produzione (se utilizzato)
5. Dump / backup del database

Il ragionamento alla base di questo è piuttosto semplice: non si desidera che le prestazioni del DB siano influenzate da "altre cose" che richiedono il disco (ad es. Se la macchina inizia a scambiare pesantemente e la partizione di swap si trova sull'altro lato del disco dai dati DB che si hanno un disco lungo che cerca di fare i conti).

Dal punto di vista della solidità, si desidera lo stesso tipo di guasto, ma per una ragione diversa: come altri hanno sottolineato, non si desidera che un disco guasto elimini sia il proprio DB che i suoi backup (anche se realisticamente si dovrebbero copiare i backup il server comunque in caso di guasto catastrofico).

Volete anche evitare qualsiasi configurazione con una /partizione monolitica che contenga tutto - questo è uno sfortunato, tragico e allarmante errore comune fatto nel mondo Linux che non è condiviso dagli altri sistemi simili a Unix.
Come Gravyface ha menzionato nel suo commento, se in qualche modo riesci a riempire il /tuo sistema quasi sicuramente andrà in crash, e la pulizia / ripristino può richiedere molto tempo e denaro se il sistema ha una singola /partizione piuttosto che una gerarchia ben strutturata di punti di montaggio.

Consiglio di spostare il database e i backup temporanei (vedi sotto) in una partizione diversa rispetto a root (/).

Inoltre, elaborare uno schema di rotazione / conservazione ragionevole per i backup di dump del database compresso (presunto). Non c'è (di solito) alcun motivo per conservare così tante copie dei backup sul disco locale. Non fa nulla per il ripristino di emergenza e quando viene spostato fuori sede, deve essere rimosso dal disco.

Questa è praticamente la procedura operativa standard.

Questo mi ha ricordato un bug su NetApp in cui i file system quasi completi hanno avuto un calo significativo delle prestazioni (come la metà). (è vero che alcuni anni fa).

La risposta, come dicevano tutti, è che dipende, ma vale la pena pensarci su.

Il principale svantaggio dei file system completi è che l'elenco degli inode gratuiti è probabilmente frammentato e ovunque.

Esistono tre tipi di dati che si trovano sul disco rigido per un database.

1. Il tuo file di database effettivo. Questo sarà un grande file preallocato che generalmente cresce in grossi pezzi (ad esempio il 10%).
2. Registri, il registro delle transazioni che viene continuamente scritto, eliminato, scritto su, ecc.
3. File temporanei per query di grandi dimensioni che non possono essere eseguite in memoria.

(1) necessita solo di spazio libero quando alloca più spazio per il tuo set di file. Se il database non sta crescendo, non dovrebbe essere influenzato da un file system con spazio su disco ridotto. Se lo sta allocando, potrebbe richiedere una parte molto grande che non rientra in alcun elenco gratuito che hai immediatamente frammentando il database e causando la ricerca quando è necessario che i dati siano pronti in memoria.

(2) una ingenua impelementazione dei log in cui utilizza il sistema operativo per gestire l'allocazione dello spazio e la sua eliminazione ne risentirà. Supponendo che il tuo database non sia di sola lettura, ci sarà un flusso costante di log, che saranno spesso frammentati su uno spazio su disco rigido ridotto. In definitiva questo danneggerà le tue prestazioni di scrittura.

(3) tempDB, se il DB ne ha bisogno per query scritte scadenti, o non abbastanza RAM, allora hai problemi più grandi dello spazio su disco insufficiente che causano problemi di prestazioni poiché anche le tue prestazioni di lettura potrebbero diventare associate al disco. Si corre anche il rischio di un'interruzione se MySql doveva allocare spazio su disco per tempDB e il disco rigido si esauriva.

Informazioni sui backup ...

1. Ogni azienda in cui ho lavorato mantiene i backup sulla stessa macchina. Quando si tratta di un ripristino (a chi importa dei backup, contano i ripristini). Niente potrà battere la velocità di avere il file db proprio lì sullo stesso disco.
2. Eventualmente ovvio, assicurarsi che i backup non siano solo locali.

In breve, direi che sopravvivrai a condizione che il tuo DB non sia pesante. In tal caso, lo spazio su disco insufficiente è un problema. Ma se fossi in te lavorerei su quanto segue prima piuttosto che dopo.

1. Confermando che ho abbastanza RAM
2. Separazione dei registri e di tutti i dati temporanei dal proprio DB.
3. Separando il sistema operativo, l'installazione di MySql dal resto.

Usa mandrini e controller separati se puoi per 1.

Seguito da mandrini separati

Seguito dalle partizioni separate di un povero.

Di recente ho avuto un problema simile quando ho esaurito tutto lo spazio su disco su uno dei miei server di replica. L'effetto immediato è stato l'arresto anomalo della replica e quindi non ho potuto accedere a MySQL perché non è stato possibile aprire il file mysqld.sock.