Serverfabrikanten en cloudproviders bieden verschillende soorten opslagoplossingen om aan uw databasebehoeften te voldoen. Wanneer we een nieuwe server kopen of een cloudinstantie kiezen om onze database uit te voeren, vragen we ons vaak af:hoeveel schijfruimte moeten we toewijzen? Zoals we zullen ontdekken, is het antwoord niet triviaal, aangezien er een aantal aspecten zijn waarmee rekening moet worden gehouden. Schijfruimte is iets waar vooraf aan moet worden gedacht, omdat het verkleinen en uitbreiden van schijfruimte een riskante operatie kan zijn voor een op schijf gebaseerde database.
In deze blogpost gaan we onderzoeken hoe u in eerste instantie uw opslagruimte kunt indelen en vervolgens plannen voor capaciteit om de groei van uw MySQL- of MariaDB-database te ondersteunen.
Hoe MySQL schijfruimte gebruikt
MySQL slaat gegevens op in bestanden op de harde schijf onder een specifieke map met de systeemvariabele "datadir". De inhoud van de datadir hangt af van de MySQL-serverversie en de geladen configuratieparameters en servervariabelen (bijv. general_log, slow_query_log, binary log).
De daadwerkelijke opslag- en ophaalinformatie is afhankelijk van de storage-engines. Voor de MyISAM-engine worden de indexen van een tabel opgeslagen in het .MYI-bestand, in de gegevensmap, samen met de .MYD- en .frm-bestanden voor de tabel. Voor de InnoDB-engine worden de indexen samen met de tabel in de tabelruimte opgeslagen. Als innodb_file_per_table optie is ingesteld, bevinden de indexen zich in het .ibd-bestand van de tabel samen met het .frm-bestand. Voor de geheugenengine worden de gegevens opgeslagen in het geheugen (heap) terwijl de structuur wordt opgeslagen in het .frm-bestand op schijf. In de aankomende MySQL 8.0 worden de metadatabestanden (.frm, .par, dp.opt) verwijderd met de introductie van het nieuwe datadictionary-schema.
Het is belangrijk op te merken dat als u InnoDB gedeelde tablespace gebruikt voor het opslaan van tabelgegevens (innodb_file_per_table=OFF ), wordt verwacht dat uw fysieke MySQL-gegevensgrootte continu zal groeien, zelfs nadat u enorme rijen gegevens hebt afgekapt of verwijderd. De enige manier om de vrije ruimte in deze configuratie terug te winnen, is door de huidige databases te exporteren, te verwijderen en opnieuw te importeren via mysqldump. Het is dus belangrijk om innodb_file_per_table=ON in te stellen als u zich zorgen maakt over de schijfruimte, dus bij het inkorten van een tabel, kan de ruimte worden teruggevorderd. Met deze configuratie zal een enorme DELETE-bewerking ook geen schijfruimte vrijmaken, tenzij OPTIMIZE TABLE daarna wordt uitgevoerd.
MySQL slaat elke database op in zijn eigen map onder het pad "datadir". Daarnaast worden logbestanden en andere gerelateerde MySQL-bestanden, zoals socket- en PID-bestanden, standaard ook onder datadir aangemaakt. Om redenen van prestatie en betrouwbaarheid wordt aanbevolen om MySQL-logbestanden op een aparte schijf of partitie op te slaan, met name het MySQL-foutlogboek en binaire logboeken.
Geschatte databasegrootte
De basismanier om de grootte te schatten, is om de groeiverhouding tussen twee verschillende tijdstippen te vinden en die vervolgens te vermenigvuldigen met de huidige databasegrootte. Het meten van uw databaseverkeer tijdens piekuren voor dit doel is niet de beste praktijk en geeft niet uw databasegebruik als geheel weer. Denk aan een batchbewerking of een opgeslagen procedure die om middernacht of een keer per week wordt uitgevoerd. Uw database kan 's ochtends mogelijk aanzienlijk groeien, voordat ze mogelijk om middernacht wordt ingekrompen door een huishoudelijke operatie.
Een mogelijke manier is om onze back-ups als basiselement voor deze meting te gebruiken. Fysieke back-up zoals Percona Xtrabackup, MariaDB Backup en bestandssysteem-snapshot zou een nauwkeurigere weergave van uw databasegrootte opleveren in vergelijking met logische back-up, omdat het de binaire kopie van de database en indexen bevat. Logische back-up zoals mysqldump slaat alleen SQL-instructies op die kunnen worden uitgevoerd om de originele database-objectdefinities en tabelgegevens te reproduceren. Desalniettemin kun je nog steeds een goede groeiratio behalen door mysqldump-back-ups te vergelijken.
We kunnen de volgende formule gebruiken om de databasegrootte te schatten:
Waar,
- B - Huidige week volledige back-upgrootte,
- B - Vorige week volledige back-upgrootte,
- Dbgegevens - Totale grootte van databasegegevens,
- Dbindex - Totale grootte van de database-index,
- 52 - Aantal weken in een jaar,
- J - Jaar.
De totale databasegrootte (gegevens en indexen) in MB kan worden berekend met behulp van de volgende instructies:
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 |
+---------------+De bovenstaande vergelijking kan worden gewijzigd als u in plaats daarvan de maandelijkse back-ups wilt gebruiken. Verander de constante waarde van 52 in 12 (12 maanden in een jaar) en je bent klaar om te gaan.
Vergeet ook niet rekening te houden met innodb_log_file_size x 2, innodb_data_file_path en voor Galera Cluster, voeg gcache.size . toe waarde.
Geschatte grootte van binaire logbestanden
Binaire logboeken worden gegenereerd door de MySQL-master voor replicatie en hersteldoeleinden op een bepaald tijdstip. Het is een set logbestanden die informatie bevatten over gegevenswijzigingen die op de MySQL-server zijn aangebracht. De grootte van de binaire logbestanden hangt af van het aantal schrijfbewerkingen en het binaire logformaat - STATEMENT, ROW of MIXED. Op instructies gebaseerd binair logboek is meestal veel kleiner in vergelijking met op rij gebaseerd binair logboek, omdat het alleen uit de schrijfinstructies bestaat, terwijl het op rij gebaseerde logboek bestaat uit gewijzigde rijinformatie.
De beste manier om het maximale schijfgebruik van binaire logboeken te schatten, is door de binaire logboekgrootte voor een dag te meten en deze te vermenigvuldigen met de expire_logs_days waarde (standaard is 0 - geen automatische verwijdering). Het is belangrijk om expire_logs_days in te stellen zodat u de maat goed kunt inschatten. Standaard is elk binair logbestand beperkt tot ongeveer 1 GB voordat MySQL het binaire logbestand roteert. We kunnen een MySQL-gebeurtenis gebruiken om het binaire logboek eenvoudigweg te wissen voor deze schatting.
Zorg er eerst voor dat de variabele event_scheduler is ingeschakeld:
mysql> SET GLOBAL event_scheduler = ON;Maak vervolgens als bevoorrechte gebruiker (met EVENT- en RELOAD-rechten) de volgende gebeurtenis:
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;Voor een schrijfintensieve werkbelasting moet u waarschijnlijk het interval verkorten tot 30 minuten of 10 minuten voordat het binaire logboek de maximale grootte van 1 GB bereikt, en vervolgens de uitvoer afronden naar een uur. Controleer vervolgens de status van de gebeurtenis met behulp van de volgende verklaring en kijk naar de kolom LAST_EXECUTED:
mysql> SELECT * FROM information_schema.events WHERE event_name='flush_binlog'\G
...
LAST_EXECUTED: 2018-04-05 13:44:25
...Bekijk dan de binaire logs die we nu hebben:
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 |
+---------------+------------+We kunnen dan het gemiddelde van de groei van onze binaire logbestanden berekenen, die rond ~562 MB per uur ligt. tijdens spitsuren. Vermenigvuldig deze waarde met 24 uur en de expire_logs_days waarde:
mysql> SELECT (562 * 24 * @@expire_logs_days);
+---------------------------------+
| (562 * 24 * @@expire_logs_days) |
+---------------------------------+
| 94416 |
+---------------------------------+We krijgen 94416 MB, wat ongeveer ~95 GB is schijfruimte voor onze binaire logboeken. De relaislogboeken van de slave zijn in principe hetzelfde als de binaire logboeken van de master, behalve dat ze aan de slave-zijde worden opgeslagen. Daarom is deze berekening ook van toepassing op de slave-relaislogboeken.
Spilschijf of Solid State?
Er zijn twee soorten I/O-bewerkingen op MySQL-bestanden:
- Sequentiële I/O-georiënteerde bestanden:
- InnoDB-systeemtabelruimte (ibdata)
- MySQL-logbestanden:
- Binaire logboeken (binlog.xxxx)
- REDO-logboeken (ib_logfile*)
- Algemene logboeken
- Langzame zoekopdrachtlogboeken
- Foutenlogboek
- Willekeurige I/O-georiënteerde bestanden:
- InnoDB bestand-per-tabel gegevensbestand (*.ibd) met innodb_file_per_table=ON (standaard).
Overweeg om willekeurige I/O-georiënteerde bestanden in een schijfsubsysteem met hoge doorvoer te plaatsen voor de beste prestaties. Dit kan een flashdrive zijn - ofwel SSD's of NVRAM-kaart, of spindelschijven met een hoog toerental zoals SAS 15K of 10K, met hardware RAID-controller en batterijgevoede eenheid. Voor sequentiële I/O-georiënteerde bestanden zou het opslaan op HDD met schrijfcache met batterijvoeding goed genoeg moeten zijn voor MySQL. Houd er rekening mee dat prestatievermindering waarschijnlijk is als de batterij leeg is.
We zullen dit gebied (het schatten van schijfdoorvoer en bestandstoewijzing) in een aparte post behandelen.
Capaciteitsplanning en dimensionering
Capaciteitsplanning kan ons helpen een productiedatabaseserver te bouwen met voldoende middelen om de dagelijkse operaties te overleven. We moeten ook voorzien in onverwachte behoeften, rekening houden met toekomstige opslag- en schijfdoorvoerbehoeften. Capaciteitsplanning is dus belangrijk om ervoor te zorgen dat de database voldoende ademruimte heeft tot de volgende hardwareverversingscyclus.
U kunt dit het beste illustreren met een voorbeeld. Gezien het volgende scenario:
- Volgende hardwarecyclus:3 jaar
- Huidige databasegrootte:2013 MB
- Huidige volledige back-upgrootte (week N):1177 MB
- Vorige volledige back-upgrootte (week N-1):936 MB
- Deltagrootte:241 MB per week
- Delta-ratio:toename van 25,7% per week
- Totaal weken in 3 jaar:156 weken
- Geschatte totale databasegrootte:((1177 - 936) x 2013 x 156)/936 =80856 MB ~ 81 GB na 3 jaar
Als u binaire logbestanden gebruikt, vat deze dan samen met de waarde die we in de vorige sectie hebben gekregen:
- 81 + 95 =176 GB opslagruimte voor database en binaire logboeken.
Voeg ten minste 100% meer ruimte toe voor operationele en onderhoudstaken (lokale back-up, gegevensstaging, foutenlogboek, besturingssysteembestanden, enz.):
- 176 + 176 =352 GB totale schijfruimte.
Op basis van deze schatting kunnen we concluderen dat we minimaal 352 GB schijfruimte nodig hebben voor onze database voor 3 jaar. U kunt deze waarde gebruiken om uw nieuwe hardware-aankoop te rechtvaardigen. Als u bijvoorbeeld een nieuwe dedicated server wilt kopen, kunt u kiezen voor 6 x 128 SSD RAID 10 met RAID-controller met batterijvoeding, waarmee u ongeveer 384 GB aan totale schijfruimte krijgt. Of, als u de voorkeur geeft aan de cloud, kunt u 100 GB blokopslag krijgen met ingerichte IOPS voor ons databasegebruik van 81 GB en de standaard persistente blokopslag gebruiken voor onze 95 GB binaire logboeken en ander operationeel gebruik.
Veel plezier met dimensioneren!