Serverproducenter og cloud-udbydere tilbyder forskellige slags lagringsløsninger for at imødekomme dine databasebehov. Når vi køber en ny server eller vælger en cloud-instans til at køre vores database, spørger vi ofte os selv - hvor meget diskplads skal vi allokere? Som vi vil finde ud af, er svaret ikke trivielt, da der er en række aspekter at overveje. Diskplads er noget, der skal tænkes på på forhånd, fordi formindskelse og udvidelse af diskplads kan være en risikabel operation for en disk-baseret database.
I dette blogindlæg skal vi se på, hvordan du indledningsvis skal dimensionere din lagerplads og derefter planlægge kapacitet til at understøtte væksten af din MySQL- eller MariaDB-database.
Hvordan MySQL udnytter diskplads
MySQL gemmer data i filer på harddisken under en specifik mappe, der har systemvariablen "datadir". Indholdet af datadir vil afhænge af MySQL-serverversionen og de indlæste konfigurationsparametre og servervariabler (f.eks. general_log, slow_query_log, binær log).
De faktiske lagrings- og genfindingsoplysninger afhænger af lagringsmotorerne. For MyISAM-motoren gemmes en tabels indekser i .MYI-filen, i databiblioteket sammen med .MYD- og .frm-filerne for tabellen. For InnoDB-motoren gemmes indekserne i tablespacet sammen med tabellen. Hvis innodb_file_per_table indstillingen er indstillet, vil indekserne være i tabellens .ibd-fil sammen med .frm-filen. For hukommelsesmotoren gemmes dataene i hukommelsen (heap), mens strukturen er gemt i .frm-filen på disken. I den kommende MySQL 8.0 fjernes metadatafilerne (.frm, .par, dp.opt) med introduktionen af det nye dataordbogsskema.
Det er vigtigt at bemærke, at hvis du bruger InnoDB shared tablespace til lagring af tabeldata (innodb_file_per_table=OFF ), forventes din MySQL fysiske datastørrelse at vokse kontinuerligt, selv efter du har afkortet eller slettet store rækker af data. Den eneste måde at genvinde den ledige plads i denne konfiguration er at eksportere, slette de nuværende databaser og genimportere dem tilbage via mysqldump. Derfor er det vigtigt at indstille innodb_file_per_table=ON hvis du er bekymret for diskpladsen, så når du trunkerer en tabel, kan pladsen genvindes. Med denne konfiguration vil en enorm DELETE-operation ikke frigøre diskplads, medmindre OPTIMIZE TABLE udføres bagefter.
MySQL gemmer hver database i sin egen mappe under "datadir"-stien. Derudover vil logfiler og andre relaterede MySQL-filer som socket- og PID-filer som standard også blive oprettet under datadir. Af hensyn til ydeevne og pålidelighed anbefales det at gemme MySQL-logfiler på en separat disk eller partition - især MySQL-fejlloggen og binære logfiler.
Estimering af databasestørrelse
Den grundlæggende måde at estimere størrelse på er at finde vækstforholdet mellem to forskellige tidspunkter og derefter gange det med den aktuelle databasestørrelse. Måling af din databasetrafik i myldretiden til dette formål er ikke den bedste praksis og repræsenterer ikke din databasebrug som helhed. Tænk på en batch-operation eller en lagret procedure, der kører ved midnat eller en gang om ugen. Din database kan potentielt vokse betydeligt om morgenen, før den muligvis bliver krympet af en husholdningsoperation ved midnat.
En mulig måde er at bruge vores backups som basiselement for denne måling. Fysisk sikkerhedskopiering som Percona Xtrabackup, MariaDB Backup og snapshot af filsystemet ville give en mere nøjagtig repræsentation af din databasestørrelse sammenlignet med logisk backup, da den indeholder den binære kopi af databasen og indekser. Logisk sikkerhedskopiering som mysqldump gemmer kun SQL-sætninger, der kan udføres for at reproducere de originale databaseobjektdefinitioner og tabeldata. Ikke desto mindre kan du stadig komme ud med et godt vækstforhold ved at sammenligne mysqldump-sikkerhedskopier.
Vi kan bruge følgende formel til at estimere databasestørrelsen:
Hvor,
- B - Aktuel uge fuld backup størrelse,
- B - Forrige uge fuld sikkerhedskopieringsstørrelse,
- Dbdata - Samlet databasedatastørrelse,
- Dbindeks - Samlet databaseindeksstørrelse,
- 52 - Antal uger i et år,
- Y - År.
Den samlede databasestørrelse (data og indekser) i MB kan beregnes ved at bruge følgende udsagn:
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 |
+---------------+Ovenstående ligning kan ændres, hvis du ønsker at bruge de månedlige backups i stedet for. Skift den konstante værdi på 52 til 12 (12 måneder om et år), og du er klar til at gå.
Glem heller ikke at tage højde for innodb_log_file_size x 2, innodb_data_file_path og til Galera Cluster skal du tilføje gcache.size værdi.
Størrelsesvurdering af binære logfiler
Binære logfiler genereres af MySQL-masteren til replikering og punkt-i-tidsgendannelsesformål. Det er et sæt logfiler, der indeholder information om dataændringer foretaget på MySQL-serveren. Størrelsen af de binære logfiler afhænger af antallet af skriveoperationer og det binære logformat - STATEMENT, ROW eller MIXED. Udsagnsbaseret binær log er normalt meget mindre sammenlignet med rækkebaseret binær log, fordi den kun består af skrivesætningerne, mens den rækkebaserede består af modificerede rækkeoplysninger.
Den bedste måde at estimere det maksimale diskforbrug af binære logfiler er at måle den binære logstørrelse for en dag og gange den med expire_logs_days værdi (standard er 0 - ingen automatisk fjernelse). Det er vigtigt at indstille expire_logs_days så du kan vurdere størrelsen korrekt. Som standard er hver binær log begrænset til omkring 1 GB, før MySQL roterer den binære logfil. Vi kan bruge en MySQL-begivenhed til blot at tømme den binære log med henblik på denne estimering.
Først skal du sørge for, at event_scheduler-variablen er aktiveret:
mysql> SET GLOBAL event_scheduler = ON;Derefter, som en privilegeret bruger (med EVENT- og RELOAD-rettigheder), skal du oprette følgende begivenhed:
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;For en skriveintensiv arbejdsbyrde skal du sandsynligvis forkorte intervallet til 30 minutter eller 10 minutter, før den binære log når en maksimal størrelse på 1 GB, og derefter runde outputtet op til en time. Bekræft derefter hændelsens status ved at bruge følgende sætning og se på kolonnen LAST_EXECUTED:
mysql> SELECT * FROM information_schema.events WHERE event_name='flush_binlog'\G
...
LAST_EXECUTED: 2018-04-05 13:44:25
...Så tag et kig på de binære logfiler, vi har nu:
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 |
+---------------+------------+Vi kan derefter beregne gennemsnittet af vores binære logvækst, som er omkring ~562 MB i timen i myldretiden. Multiplicer denne værdi med 24 timer og expire_logs_days værdi:
mysql> SELECT (562 * 24 * @@expire_logs_days);
+---------------------------------+
| (562 * 24 * @@expire_logs_days) |
+---------------------------------+
| 94416 |
+---------------------------------+Vi får 94416 MB, hvilket er omkring ~95 GB diskplads til vores binære logfiler. Slaves relælogs er grundlæggende de samme som masterens binære logfiler, bortset fra at de er gemt på slavesiden. Derfor gælder denne beregning også for slaverelæ-loggene.
Spindle Disk eller Solid State?
Der er to typer I/O-operationer på MySQL-filer:
- Sekventielle I/O-orienterede filer:
- InnoDB system tablespace (ibdata)
- MySQL-logfiler:
- Binære logfiler (binlog.xxxx)
- REDO logfiler (ib_logfile*)
- Generelle logfiler
- Langsomme forespørgselslogfiler
- Fejllog
- Tilfældige I/O-orienterede filer:
- InnoDB fil-pr-table datafil (*.ibd) med innodb_file_per_table=ON (standard).
Overvej at placere tilfældige I/O-orienterede filer i et diskundersystem med høj kapacitet for at få den bedste ydeevne. Dette kan være et flashdrev - enten SSD'er eller NVRAM-kort, eller høj RPM spindeldiske som SAS 15K eller 10K, med hardware RAID-controller og batteri-understøttet enhed. For sekventielle I/O-orienterede filer bør lagring på HDD med batteriunderstøttet skrive-cache være god nok til MySQL. Vær opmærksom på, at ydeevnen forringes, hvis batteriet er dødt.
Vi vil dække dette område (estimering af diskgennemstrømning og filallokering) i et separat indlæg.
Kapacitetsplanlægning og dimensionering
Kapacitetsplanlægning kan hjælpe os med at bygge en produktionsdatabaseserver med tilstrækkelige ressourcer til at overleve daglig drift. Vi skal også sørge for uventede behov, tage højde for fremtidig lager- og diskgennemstrømningsbehov. Kapacitetsplanlægning er derfor vigtig for at sikre, at databasen har plads nok til at trække vejret indtil næste hardwareopdateringscyklus.
Det er bedst at illustrere dette med et eksempel. I betragtning af følgende scenarie:
- Næste hardwarecyklus:3 år
- Nuværende databasestørrelse:2013 MB
- Aktuel fuld backupstørrelse (uge N):1177 MB
- Tidligere fuld sikkerhedskopieringsstørrelse (uge N-1):936 MB
- Deltastørrelse:241 MB pr. uge
- Deltaforhold:stigning på 25,7 % pr. uge
- Uger i alt på 3 år:156 uger
- Estimeret samlet databasestørrelse:((1177 - 936) x 2013 x 156)/936 =80856 MB ~ 81 GB efter 3 år
Hvis du bruger binære logfiler, så opsummer det fra den værdi, vi fik i forrige afsnit:
- 81 + 95 =176 GB lagerplads til database og binære logfiler.
Tilføj mindst 100 % mere plads til drifts- og vedligeholdelsesopgaver (lokal backup, datainddeling, fejllog, operativsystemfiler osv.):
- 176 + 176 =352 GB samlet diskplads.
Baseret på dette skøn kan vi konkludere, at vi ville have brug for mindst 352 GB diskplads til vores database i 3 år. Du kan bruge denne værdi til at retfærdiggøre dit nye hardwarekøb. For eksempel, hvis du vil købe en ny dedikeret server, kan du vælge 6 x 128 SSD RAID 10 med batteristøttet RAID-controller, som vil give dig omkring 384 GB samlet diskplads. Eller, hvis du foretrækker skyen, kan du få 100 GB bloklager med klargjort IOPS til vores 81 GB databasebrug og bruge standard vedvarende bloklager til vores 95 GB binære logfiler og anden operationel brug.
God dimensionering!