Serverhersteller und Cloud-Anbieter bieten verschiedene Arten von Speicherlösungen an, um Ihren Datenbankanforderungen gerecht zu werden. Wenn wir einen neuen Server kaufen oder eine Cloud-Instanz zum Ausführen unserer Datenbank auswählen, fragen wir uns oft:Wie viel Speicherplatz sollten wir zuweisen? Wie wir sehen werden, ist die Antwort nicht trivial, da es eine Reihe von Aspekten zu berücksichtigen gilt. Über den Speicherplatz muss im Voraus nachgedacht werden, da das Verkleinern und Erweitern des Speicherplatzes für eine plattenbasierte Datenbank ein riskanter Vorgang sein kann.
In diesem Blogpost werden wir untersuchen, wie Sie Ihren Speicherplatz zunächst dimensionieren und dann die Kapazität planen, um das Wachstum Ihrer MySQL- oder MariaDB-Datenbank zu unterstützen.
Wie MySQL Speicherplatz nutzt
MySQL speichert Daten in Dateien auf der Festplatte unter einem bestimmten Verzeichnis, das die Systemvariable "datadir" hat. Der Inhalt des datadir hängt von der MySQL-Serverversion und den geladenen Konfigurationsparametern und Servervariablen ab (z. B. general_log, slow_query_log, binary log).
Die tatsächlichen Speicher- und Abrufinformationen hängen von den Speicher-Engines ab. Für die MyISAM-Engine werden die Indizes einer Tabelle in der .MYI-Datei im Datenverzeichnis zusammen mit den .MYD- und .frm-Dateien für die Tabelle gespeichert. Für die InnoDB-Engine werden die Indizes zusammen mit der Tabelle im Tablespace gespeichert. Wenn innodb_file_per_table Wenn die Option gesetzt ist, befinden sich die Indizes zusammen mit der .frm-Datei in der .ibd-Datei der Tabelle. Für die Speichermaschine werden die Daten im Arbeitsspeicher (Heap) gespeichert, während die Struktur in der .frm-Datei auf der Festplatte gespeichert wird. Im kommenden MySQL 8.0 werden die Metadatendateien (.frm, .par, dp.opt) mit der Einführung des neuen Data-Dictionary-Schemas entfernt.
Es ist wichtig zu beachten, dass, wenn Sie den gemeinsam genutzten InnoDB-Tablespace zum Speichern von Tabellendaten verwenden (innodb_file_per_table=OFF ), wird Ihre physische MySQL-Datengröße voraussichtlich kontinuierlich wachsen, selbst nachdem Sie große Datenzeilen gekürzt oder gelöscht haben. Die einzige Möglichkeit, den freien Speicherplatz in dieser Konfiguration zurückzugewinnen, besteht darin, die aktuellen Datenbanken zu exportieren, zu löschen und sie über mysqldump erneut zu importieren. Daher ist es wichtig, innodb_file_per_table=ON zu setzen Wenn Sie sich Sorgen um den Speicherplatz machen, kann der Speicherplatz beim Abschneiden einer Tabelle zurückgewonnen werden. Außerdem wird bei dieser Konfiguration eine große DELETE-Operation den Speicherplatz nicht freigeben, es sei denn, OPTIMIZE TABLE wird danach ausgeführt.
MySQL speichert jede Datenbank in einem eigenen Verzeichnis unter dem Pfad „datadir“. Darüber hinaus werden Protokolldateien und andere zugehörige MySQL-Dateien wie Socket- und PID-Dateien standardmäßig auch unter datadir erstellt. Aus Gründen der Leistung und Zuverlässigkeit wird empfohlen, MySQL-Protokolldateien auf einer separaten Festplatte oder Partition zu speichern - insbesondere das MySQL-Fehlerprotokoll und die Binärprotokolle.
Schätzung der Datenbankgröße
Die grundlegende Methode zum Schätzen der Größe besteht darin, das Wachstumsverhältnis zwischen zwei verschiedenen Zeitpunkten zu ermitteln und dieses dann mit der aktuellen Datenbankgröße zu multiplizieren. Das Messen Ihres Datenbankverkehrs zu Spitzenzeiten zu diesem Zweck ist nicht die bewährte Methode und stellt nicht Ihre Datenbanknutzung als Ganzes dar. Denken Sie an einen Stapelvorgang oder eine gespeicherte Prozedur, die um Mitternacht oder einmal pro Woche ausgeführt wird. Ihre Datenbank könnte morgens möglicherweise erheblich wachsen, bevor sie möglicherweise um Mitternacht durch eine Reinigungsoperation geschrumpft wird.
Eine Möglichkeit besteht darin, unsere Backups als Basiselement für diese Messung zu verwenden. Physische Backups wie Percona Xtrabackup, MariaDB Backup und Dateisystem-Snapshots würden im Vergleich zu logischen Backups eine genauere Darstellung Ihrer Datenbankgröße erzeugen, da sie die binäre Kopie der Datenbank und der Indizes enthalten. Logische Sicherungen wie mysqldump speichern nur SQL-Anweisungen, die ausgeführt werden können, um die ursprünglichen Datenbankobjektdefinitionen und Tabellendaten zu reproduzieren. Trotzdem können Sie durch den Vergleich von mysqldump-Backups immer noch eine gute Wachstumsrate erzielen.
Wir können die folgende Formel verwenden, um die Datenbankgröße abzuschätzen:
Wo,
- B - Gesamtsicherungsgröße der aktuellen Woche,
- B - Gesamtsicherungsgröße der Vorwoche,
- DbDaten - Gesamtgröße der Datenbankdaten,
- Dbindex - Gesamtgröße des Datenbankindex,
- 52 - Anzahl der Wochen in einem Jahr,
- Ja - Jahr.
Die Gesamtgröße der Datenbank (Daten und Indizes) in MB kann mit den folgenden Anweisungen berechnet werden:
mysql> SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) "DB Size in MB" FROM information_schema.tables;
+---------------+
| DB Size in MB |
+---------------+
| 2013.41 |
+---------------+Die obige Gleichung kann geändert werden, wenn Sie stattdessen die monatlichen Sicherungen verwenden möchten. Ändern Sie den konstanten Wert von 52 auf 12 (12 Monate in einem Jahr) und Sie können loslegen.
Vergessen Sie auch nicht, innodb_log_file_size zu berücksichtigen x 2, innodb_data_file_path und für Galera-Cluster fügen Sie gcache.size hinzu Wert.
Schätzung der Größe von Binärprotokollen
Binäre Protokolle werden vom MySQL-Master für Replikations- und Point-in-Time-Wiederherstellungszwecke generiert. Es handelt sich um eine Reihe von Protokolldateien, die Informationen über Datenänderungen enthalten, die auf dem MySQL-Server vorgenommen wurden. Die Größe der Binärlogs hängt von der Anzahl der Schreibvorgänge und dem Format des Binärlogs ab – STATEMENT, ROW oder MIXED. Anweisungsbasierte Binärlogs sind normalerweise viel kleiner als zeilenbasierte Binärlogs, da sie nur aus den Schreibanweisungen bestehen, während die zeilenbasierten aus modifizierten Zeileninformationen bestehen.
Die beste Möglichkeit, die maximale Festplattennutzung von Binärlogs abzuschätzen, besteht darin, die Binärloggröße für einen Tag zu messen und sie mit den expire_logs_days zu multiplizieren Wert (Standard ist 0 - keine automatische Entfernung). Es ist wichtig, expire_logs_days festzulegen damit Sie die Größe richtig einschätzen können. Standardmäßig ist jedes Binärlog auf etwa 1 GB begrenzt, bevor MySQL die Binärlogdatei rotiert. Wir können ein MySQL-Ereignis verwenden, um das Binärlog für diese Schätzung einfach zu leeren.
Stellen Sie zunächst sicher, dass die Variable event_scheduler aktiviert ist:
mysql> SET GLOBAL event_scheduler = ON;Erstellen Sie dann als privilegierter Benutzer (mit EVENT- und RELOAD-Berechtigungen) das folgende Ereignis:
mysql> USE mysql;
mysql> CREATE EVENT flush_binlog
ON SCHEDULE EVERY 1 HOUR STARTS CURRENT_TIMESTAMP ENDS CURRENT_TIMESTAMP + INTERVAL 2 HOUR
COMMENT 'Flush binlogs per hour for the next 2 hours'
DO FLUSH BINARY LOGS;Bei einer schreibintensiven Arbeitslast müssen Sie das Intervall wahrscheinlich auf 30 Minuten oder 10 Minuten verkürzen, bevor das Binärprotokoll die maximale Größe von 1 GB erreicht, und die Ausgabe dann auf eine Stunde aufrunden. Überprüfen Sie dann den Status des Ereignisses, indem Sie die folgende Anweisung verwenden, und sehen Sie sich die Spalte LAST_EXECUTED an:
mysql> SELECT * FROM information_schema.events WHERE event_name='flush_binlog'\G
...
LAST_EXECUTED: 2018-04-05 13:44:25
...Dann werfen Sie einen Blick auf die Binärlogs, die wir jetzt haben:
mysql> SHOW BINARY LOGS;
+---------------+------------+
| Log_name | File_size |
+---------------+------------+
| binlog.000001 | 146 |
| binlog.000002 | 1073742058 |
| binlog.000003 | 1073742302 |
| binlog.000004 | 1070551371 |
| binlog.000005 | 1070254293 |
| binlog.000006 | 562350055 | <- hour #1
| binlog.000007 | 561754360 | <- hour #2
| binlog.000008 | 434015678 |
+---------------+------------+Wir können dann das durchschnittliche Wachstum unserer Binärprotokolle berechnen, das bei etwa ~562 MB pro Stunde liegt während der Stoßzeiten. Multiplizieren Sie diesen Wert mit 24 Stunden und den expire_logs_days Wert:
mysql> SELECT (562 * 24 * @@expire_logs_days);
+---------------------------------+
| (562 * 24 * @@expire_logs_days) |
+---------------------------------+
| 94416 |
+---------------------------------+Wir erhalten 94416 MB, was ungefähr ~95 GB entspricht Speicherplatz für unsere Binärlogs. Die Relaisprotokolle des Slaves sind im Grunde die gleichen wie die Binärprotokolle des Masters, außer dass sie auf der Slave-Seite gespeichert werden. Daher gilt diese Berechnung auch für die Slave-Relay-Logs.
Spindelscheibe oder Festkörper?
Es gibt zwei Arten von E/A-Operationen für MySQL-Dateien:
- Sequentielle E/A-orientierte Dateien:
- InnoDB-System-Tablespace (ibdata)
- MySQL-Protokolldateien:
- Binärprotokolle (binlog.xxxx)
- REDO-Protokolle (ib_logfile*)
- Allgemeine Protokolle
- Protokolle für langsame Abfragen
- Fehlerprotokoll
- Random I/O-orientierte Dateien:
- InnoDB-Datei-pro-Tabelle-Datendatei (*.ibd) mit innodb_file_per_table=ON (Standard).
Erwägen Sie, zufällige E/A-orientierte Dateien in einem Plattensubsystem mit hohem Durchsatz zu platzieren, um die beste Leistung zu erzielen. Dies könnte ein Flash-Laufwerk sein – entweder SSDs oder NVRAM-Karte oder Spindelfestplatten mit hoher Drehzahl wie SAS 15K oder 10K, mit Hardware-RAID-Controller und batteriegepufferter Einheit. Für sequentielle E/A-orientierte Dateien sollte das Speichern auf HDD mit batteriegestütztem Schreib-Cache für MySQL gut genug sein. Beachten Sie, dass es wahrscheinlich zu Leistungseinbußen kommt, wenn der Akku leer ist.
Wir werden diesen Bereich (Schätzung des Festplattendurchsatzes und der Dateizuweisung) in einem separaten Beitrag behandeln.
Kapazitätsplanung und Dimensionierung
Die Kapazitätsplanung kann uns dabei helfen, einen Produktionsdatenbankserver mit genügend Ressourcen aufzubauen, um den täglichen Betrieb zu überstehen. Wir müssen auch für unerwartete Anforderungen sorgen und zukünftige Speicher- und Plattendurchsatzanforderungen berücksichtigen. Daher ist die Kapazitätsplanung wichtig, um sicherzustellen, dass die Datenbank bis zum nächsten Hardware-Aktualisierungszyklus genügend Luft zum Atmen hat.
Verdeutlichen Sie sich das am besten an einem Beispiel. Unter Berücksichtigung des folgenden Szenarios:
- Nächster Hardwarezyklus:3 Jahre
- Aktuelle Datenbankgröße:2013 MB
- Aktuelle Größe der vollständigen Sicherung (Woche N):1177 MB
- Größe der vorherigen vollständigen Sicherung (Woche N-1):936 MB
- Deltagröße:241 MB pro Woche
- Delta-Verhältnis:Steigerung um 25,7 % pro Woche
- Gesamtwochen in 3 Jahren:156 Wochen
- Schätzung der Gesamtgröße der Datenbank:((1177 - 936) x 2013 x 156)/936 =80856 MB ~ 81 GB nach 3 Jahren
Wenn Sie Binärlogs verwenden, fassen Sie es aus dem Wert zusammen, den wir im vorherigen Abschnitt erhalten haben:
- 81 + 95 =176 GB Speicherplatz für Datenbank- und Binärprotokolle.
Fügen Sie mindestens 100 % mehr Platz für Betriebs- und Wartungsaufgaben hinzu (lokale Sicherung, Datenbereitstellung, Fehlerprotokoll, Betriebssystemdateien usw.):
- 176 + 176 =352 GB Gesamtspeicherplatz.
Basierend auf dieser Schätzung können wir schlussfolgern, dass wir für unsere Datenbank mindestens 352 GB Speicherplatz für 3 Jahre benötigen würden. Sie können diesen Wert verwenden, um Ihren neuen Hardwarekauf zu rechtfertigen. Wenn Sie beispielsweise einen neuen dedizierten Server kaufen möchten, können Sie sich für 6 x 128 SSD RAID 10 mit batteriegepuffertem RAID-Controller entscheiden, wodurch Sie rund 384 GB Gesamtspeicherplatz erhalten. Oder, wenn Sie die Cloud bevorzugen, können Sie 100 GB Blockspeicher mit bereitgestellten IOPS für unsere 81 GB-Datenbanknutzung erhalten und den standardmäßigen dauerhaften Blockspeicher für unsere 95 GB-Binärprotokolle und andere betriebliche Zwecke verwenden.
Viel Spaß beim Dimensionieren!
