Ist es schlecht, eine sehr volle Festplatte auf einem Datenbankserver mit hohem Datenverkehr zu haben?

Ausführen eines Ubuntu-Servers mit MySQL für einen Datenbankserver mit hohem Datenverkehr. Auf dem Rechner läuft nichts anderes als die MySQL-Instanz.

Wir speichern tägliche Datenbank-Backups auf dem DB-Server. Gibt es Performance-Einbußen oder Gründe, warum wir die Festplatte relativ leer halten sollten? Wenn die Festplatte zu mehr als 86% mit der Datenbank und allen Sicherungen gefüllt ist, beeinträchtigt dies die Leistung überhaupt?

Würde der DB-Server mit 86-90% + voller Kapazität in irgendeiner Weise weniger gut abschneiden als der Server mit nur 10% voller Festplatte?

Die Gesamtgröße des Datenträgers auf dem Server beträgt mehr als 1 TB, sodass selbst 10% des Datenträgers für das einfache Austauschen von Betriebssystemen und dergleichen ausreichen sollten.

Zunächst möchten Sie Ihre Datenbanksicherungen NICHT auf demselben physischen Laufwerk oder derselben RAID-Gruppe wie Ihre Datenbank aufbewahren. Der Grund dafür ist, dass ein Festplattenfehler (wenn Sie ohne RAID-Schutz arbeiten) oder ein schwerwiegender RAID-Fehler (wenn Sie RAID-1 oder RAID-5 verwenden) dazu führt, dass Sie Ihre Datenbank und Ihre Datenbanksicherungen verlieren.

Ihre Frage zur Festplattenleistung hängt davon ab, wie auf die Daten auf der Festplatte zugegriffen wird. Bei sich drehenden Festplatten gibt es zwei physikalische Faktoren, die die E / A-Leistung beeinflussen. Sie sind:

• Suchzeit - Dies ist die Zeit, die das Laufwerk benötigt, um den Plattenkopf von seiner aktuellen Spurposition zu der Spur zu bewegen, die die angeforderten Daten enthält

• Rotationslatenz - das ist die durchschnittliche Zeit, die die gewünschten Daten benötigen, um den Lesekopf zu erreichen, während sich das Laufwerk dreht. Bei einem Laufwerk mit 15.000 U / min sind dies 2 ms (Millisekunden).

Wie voll Ihr Laufwerk ist, kann sich auf die durchschnittliche Suchzeit für die E / A Ihres Servers auswirken. Wenn Ihr Laufwerk beispielsweise voll ist und Sie Datenbanktabellen haben, die sich physisch auf dem Laufwerk am äußersten gegenüberliegenden Ende der Platten befinden, greifen diese E / As beim Ausführen von E / As auf Daten aus jeder dieser Tabellen zu die maximale Suchzeit des Laufwerks.

Wenn Ihr Laufwerk jedoch voll ist und Ihre Anwendung nur auf einen kleinen Teil der auf dem Laufwerk gespeicherten Daten zugreift und sich alle diese Daten zusammenhängend auf dem Laufwerk befinden, werden diese E / A-Vorgänge durch die Suchzeit nur minimal beeinträchtigt .

Unglücklicherweise lautet die Antwort auf diese Frage "Ihr Kilometerstand wird variieren", was bedeutet, dass die Art und Weise, wie Ihre Anwendung auf die Daten zugreift und wo sich diese Daten befinden, die E / A-Leistung bestimmt.

Wie von @gravyface erwähnt, ist es auch eine bewährte Methode, die Speicheranforderungen Ihres Betriebssystems von Ihrer Datenbank zu trennen. Dies würde wiederum dazu beitragen, die Kopfbewegung auf der Plattenoberfläche so gering wie möglich zu halten, da beide auf demselben Laufwerk ständig nach dem Betriebssystem und den Datenbankbereichen des Laufwerks suchen könnten, wenn sowohl das Betriebssystem als auch die Datenbanksoftware E / A-Anforderungen stellen.

Hierbei sind zwei Aspekte zu berücksichtigen: Leistung und Robustheit.

In Bezug auf die Leistung wird im Allgemeinen empfohlen, separate Plattenspindeln (oder RAID-Gruppen / Laufwerksätze) für Folgendes zu verwenden:

1. Das Betriebssystem (Binärdateien, Protokolle, Home-Verzeichnisse usw.)
2. Swap Space (kann mit (1) kombiniert werden, wenn Sie nicht damit rechnen, Swap zu verwenden)
3. Die Produktions-DB
4. Die Transaktionsprotokolle der Produktionsdatenbank (falls verwendet)
5. Datenbank-Dumps / Backups

Der Grund dafür ist ziemlich einfach: Sie möchten nicht, dass die DB-Leistung durch "andere Dinge" beeinträchtigt wird, die den Datenträger beanspruchen (z. B. wenn der Computer stark ausgelagert wird und sich die Auslagerungspartition auf der anderen Seite des Datenträgers von den von Ihnen angegebenen DB-Daten befindet) habe lange festplattenbemühungen).

Unter dem Gesichtspunkt der Robustheit möchten Sie die gleiche Art der Aufteilung, jedoch aus einem anderen Grund: Wie andere betont haben, möchten Sie nicht, dass eine ausgefallene Festplatte sowohl Ihre Datenbank als auch ihre Sicherungen entfernt (obwohl Sie die Sicherungen realistischerweise abschreiben sollten) der Server trotzdem im Falle eines katastrophalen Ausfalls).

Sie möchten auch jegliche Konfiguration mit einer monolithischen /Partition vermeiden , die alles enthält - dies ist ein unglücklicher, tragischer und alarmierend häufiger Fehler, der in der Linux-Welt gemacht wird und von den anderen Unix-ähnlichen Systemen nicht geteilt wird.
Wie Gravyface in seinem Kommentar erwähnt hat, stürzt /Ihr System mit ziemlicher Sicherheit ab , wenn Sie es irgendwie schaffen, es zu füllen , und die Bereinigung / Wiederherstellung kann zeitaufwändig und kostspielig sein, wenn das System über eine einzelne /Partition und keine gut strukturierte Hierarchie von Einhängepunkten verfügt.

Ich würde empfehlen, die Datenbank und temporäre (siehe unten) Sicherungen auf eine andere Partition als root (/) zu verschieben.

Überlegen Sie sich auch ein sinnvolles Rotations- / Aufbewahrungsschema für Ihre (angenommenen) komprimierten Datenbank-Dump-Backups. Es gibt (normalerweise) keinen Grund, so viele Kopien der Backups auf der lokalen Festplatte zu speichern. Tut nichts für die Notfallwiederherstellung und sollte beim Verschieben von der Festplatte entfernt werden.

Das ist so ziemlich die Standardarbeitsweise.

Dies erinnerte mich an einen Fehler in NetApp, bei dem die Leistung von Dateisystemen, die fast voll sind, erheblich abnahm (etwa die Hälfte). (Zugegeben, das war vor ein paar Jahren).

Die Antwort, wie alle sagten, hängt davon ab, aber es lohnt sich, darüber nachzudenken.

Der Hauptnachteil von vollständigen Dateisystemen ist die Liste der freien Inodes, die wahrscheinlich fragmentiert sind und überall zu finden sind.

Es gibt drei Arten von Daten, die sich für eine Datenbank auf der Festplatte befinden.

1. Ihre eigentliche Datenbankdatei. Hierbei handelt es sich um eine große vorab zugewiesene Datei, die im Allgemeinen in großen Blöcken (z. B. 10%) wächst.
2. Protokolle, Ihr Transaktionsprotokoll, das fortlaufend geschrieben, gelöscht, geschrieben usw. wird.
3. Temporäre Dateien für große Abfragen, die nicht im Speicher ausgeführt werden können.

(1) benötigt nur freien Speicherplatz, wenn mehr Speicherplatz für Ihren Dateisatz zugewiesen wird. Wenn Ihre Datenbank nicht wächst, sollte sie nicht von einem Dateisystem mit geringem Speicherplatz betroffen sein. Wenn es jedoch zugeteilt wird, könnte es nach einem sehr großen Block fragen, der nicht in eine freie Liste passt, die Sie sofort fragmentiert haben, und das Suchen veranlassen, wenn Daten in den Speicher geladen werden müssen.

(2) Eine naive Übernahme von Protokollen, bei der das Betriebssystem zum Verwalten der Speicherplatzzuweisung und zum Löschen verwendet wird, leidet darunter. Vorausgesetzt, Ihre Datenbank ist nicht schreibgeschützt, es gibt einen konstanten Strom von Protokollen, sie werden häufig auf einem niedrigen Festplattenspeicher fragmentiert. Letztendlich wird dies Ihre Schreibleistung beeinträchtigen.

(3) tempDB: Wenn die Datenbank es für fehlerhafte, geschriebene Abfragen benötigt oder nicht genügend RAM, dann haben Sie größere Probleme als nur geringen Speicherplatz, was zu Leistungsproblemen führt, da selbst Ihre Leseleistung dann an die Festplatte gebunden werden könnte. Sie laufen auch Gefahr, einen Ausfall zu erleiden, wenn MySql Speicherplatz für tempDB reservieren muss und die Festplatte leer ist.

Informationen zu Sicherungen ...

1. Jedes Unternehmen, in dem ich gearbeitet habe, speichert Backups auf demselben Computer. Wenn es um eine Wiederherstellung geht (wer sich um Backups kümmert, zählt nur die Wiederherstellung). Nichts wird die Geschwindigkeit übertreffen, mit der die db-Datei genau dort auf derselben Festplatte gespeichert ist.
2. Stellen Sie hoffentlich sicher, dass die Sicherungen nicht nur lokal sind.

Kurz gesagt, ich würde sagen, Sie werden überleben, vorausgesetzt, Ihre Datenbank ist nicht schwer zu schreiben. Wenn dies der Fall ist, ist ein geringer Speicherplatz ein Problem. Aber wenn ich du wäre, würde ich eher früher als später an den folgenden arbeiten.

1. Bestätigung, dass ich genug RAM habe
2. Trennen von Protokollen und allen vorübergehenden Daten aus Ihrer Datenbank.
3. Trennen Sie Ihr Betriebssystem und Ihre MySql-Installation vom Rest.

Verwenden Sie separate Spindeln und Steuerungen, wenn Sie für 1 können.

Gefolgt von separaten Spindeln

Gefolgt von den getrennten Partitionen eines armen Mannes.

Ich hatte kürzlich ein ähnliches Problem, als ich den gesamten Speicherplatz auf einem meiner Replikationsserver beanspruchte. Der unmittelbare Effekt war, dass die Replikation abstürzte und ich mich nicht bei MySQL anmelden konnte, da die Datei mysqld.sock nicht geöffnet werden konnte.