Als de MySQL-server onvoldoende schijfruimte heeft, ziet u een van de volgende fouten in uw toepassing (evenals in het MySQL-foutlogboek):
ERROR 3 (HY000) at line 1: Error writing file '/tmp/AY0Wn7vA' (Errcode: 28 - No space left on device)Voor binaire logs ziet de foutmelding er als volgt uit:
[ERROR] [MY-000035] [Server] Disk is full writing './binlog.000019' (OS errno 28 - No space left on device). Waiting for someone to free space... Retry in 60 secs. Message reprinted in 600 secs.Voor relaislog ziet het foutbericht er als volgt uit:
[ERROR] [MY-000035] [Server] Disk is full writing './relay-bin.000007' (OS errno 28 - No space left on device). Waiting for someone to free space... Retry in 60 secs. Message reprinted in 600 secs.Voor een langzame querylog ziet u een foutmelding als volgt:
[ERROR] [MY-011263] [Server] Could not use /var/log/mysql/mysql-slow.log for logging (error 28 - No space left on device). Turning logging off for the server process. To turn it on again: fix the cause, then either restart the query logging by using "SET GLOBAL SLOW_QUERY_LOG=ON" or restart the MySQL server.Voor InnoDB ziet het er zo uit:
[ERROR] [MY-012144] [InnoDB] posix_fallocate(): Failed to preallocate data for file ./#innodb_temp/temp_8.ibt, desired size 16384 bytes. Operating system error number 28. Check that the disk is not full or a disk quota exceeded. Make sure the file system supports this function. Some operating system error numbers are described at http://dev.mysql.com/doc/refman/8.0/en/operating-system-error-codes.html
[Warning] [MY-012638] [InnoDB] Retry attempts for writing partial data failed.
[ERROR] [MY-012639] [InnoDB] Write to file ./#innodb_temp/temp_8.ibt failed at offset 81920, 16384 bytes should have been written, only 0 were written. Operating system error number 28. Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.
[ERROR] [MY-012640] [InnoDB] Error number 28 means 'No space left on device'
[Warning] [MY-012145] [InnoDB] Error while writing 16384 zeroes to ./#Ze rapporteren allemaal hetzelfde foutcodenummer, namelijk 28. Als alternatief kunnen we de foutcode gebruiken om de werkelijke fout te zien met het perror-commando:
$ perror 28
OS error code 28: No space left on deviceHet bovenstaande betekent eenvoudigweg dat de MySQL-server geen schijfruimte meer heeft, en meestal wordt MySQL op dit punt gestopt of vastgelopen. In deze blogpost gaan we kijken naar manieren om dit probleem op te lossen voor MySQL in een op Linux gebaseerde omgeving.
Problemen oplossen
Allereerst moeten we bepalen welke schijfpartitie vol is. MySQL kan worden geconfigureerd om gegevens op een andere schijf of partitie op te slaan. Kijk om te beginnen naar het pad zoals vermeld in de fout. In dit voorbeeld bevindt onze map zich op de standaardlocatie, /var/lib/mysql die zich onder de / partitie bevindt. We kunnen het df-commando gebruiken en het volledige pad naar de datadir specificeren om de partitie te krijgen waarop de gegevens zijn opgeslagen:
$ df -h /var/lib/mysql
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 40G 40G 20K 100% /Het bovenstaande betekent dat we wat ruimte moeten vrijmaken in de rootpartitie.
Tijdelijke tijdelijke oplossingen
De tijdelijke oplossing is om wat schijfruimte vrij te maken zodat MySQL naar de schijf kan schrijven en de bewerking kan hervatten. Dingen die we kunnen doen als we met dit soort problemen worden geconfronteerd, houden verband met:
- Het verwijderen van onnodige bestanden
- Opschonen van de binaire logbestanden
- Oude tafels verwijderen of een hele grote tafel opnieuw opbouwen
Onnodige bestanden verwijderen
Dit is meestal de eerste stap die u moet doen als de MySQL-server niet beschikbaar is of niet reageert, of als u geen binaire logboeken hebt ingeschakeld. Bestanden onder /var/log/ zijn bijvoorbeeld gewoonlijk de eerste plaats om naar onnodige bestanden te zoeken:
$ cd /var/log
$ find . -type f -size +5M -exec du -sh {} +
8.1M ./audit/audit.log.6
8.1M ./audit/audit.log.5
8.1M ./audit/audit.log.4
8.1M ./audit/audit.log.3
8.1M ./audit/audit.log.2
8.1M ./audit/audit.log.1
11M ./audit/audit.log
8.5M ./secure-20190429
8.0M ./wtmpHet bovenstaande voorbeeld laat zien hoe u bestanden kunt ophalen die groter zijn dan 5 MB. We kunnen de geroteerde logbestanden die meestal in {filename}.{number} formaat zijn, veilig verwijderen, bijvoorbeeld van audit.log.1 tot audit.log.6. Hetzelfde kan gezegd worden over alle grote oudere back-ups die op de server zijn opgeslagen. Als u een herstel had uitgevoerd via Percona Xtrabackup of MariaDB Backup, kunnen alle bestanden met het voorvoegsel xtrabackup_ worden verwijderd uit de MySQL-datadir, omdat ze niet langer nodig zijn voor het herstel. Het xtrabackup_logbestand is meestal het grootste bestand omdat het alle transacties bevat die zijn uitgevoerd terwijl het xtrabackup-proces de datadir naar de bestemming kopieert. Het volgende voorbeeld toont alle gerelateerde bestanden in MySQL datadir:
$ ls -lah /var/lib/mysql | grep xtrabackup_
-rw-r-----. 1 mysql root 286 Feb 4 11:30 xtrabackup_binlog_info
-rw-r--r--. 1 mysql root 24 Feb 4 11:31 xtrabackup_binlog_pos_innodb
-rw-r-----. 1 mysql root 83 Feb 4 11:31 xtrabackup_checkpoints
-rw-r-----. 1 mysql root 808 Feb 4 11:30 xtrabackup_info
-rw-r-----. 1 mysql root 179M Feb 4 11:31 xtrabackup_logfile
-rw-r--r--. 1 mysql root 1 Feb 4 11:31 xtrabackup_master_key_id
-rw-r-----. 1 mysql root 248 Feb 4 11:31 xtrabackup_tablespacesDaarom kunnen de genoemde bestanden veilig worden verwijderd. Start de MySQL-service zodra er ten minste 10% meer vrije ruimte is.
Wis de binaire logboeken
Als de MySQL-server nog steeds reageert en binair logboek is ingeschakeld, bijvoorbeeld voor replicatie of herstel op een bepaald tijdstip, kunnen we de oude binaire logboekbestanden opschonen door de PURGE-instructie te gebruiken en de interval. In dit voorbeeld verwijderen we alle binaire logboeken vóór 3 dagen geleden:
mysql> SHOW BINARY LOGS;
mysql> PURGE BINARY LOGS BEFORE DATE(NOW() - INTERVAL 3 DAY);
mysql> SHOW BINARY LOGS;Voor MySQL-replicatie is het veilig om alle logboeken te verwijderen die zijn gerepliceerd en toegepast op slaves. Controleer de waarde van Relay_Master_Log_File op de server:
mysql> SHOW SLAVE STATUS\G
...
Relay_Master_Log_File: binlog.000008
...En verwijder de oudere logbestanden, bijvoorbeeld binlog.000007 en ouder. Het is een goede gewoonte om de MySQL-server opnieuw op te starten om er zeker van te zijn dat deze over voldoende bronnen beschikt. We kunnen de binaire logrotatie ook automatisch laten gebeuren via de variabele expire_logs_days (
Voeg vervolgens de volgende regel toe aan het MySQL-configuratiebestand onder de sectie [mysqld]:
Gebruik in MySQL 8.0 in plaats daarvan binlog_expire_logs_seconds, waarbij de standaardwaarde 2592000 seconden (30 dagen) is. In dit voorbeeld verminderen we het tot slechts 3 dagen (60 seconden x 60 minuten x 24 uur x 3 dagen):
SET PERSIST zorgt ervoor dat de configuratie wordt geladen bij de volgende herstart. De configuratie die door deze opdracht wordt ingesteld, wordt opgeslagen in /var/lib/mysql/mysqld-auto.cnf. Houd er rekening mee dat de bewerking DELETE de schijfruimte niet vrijmaakt, tenzij OPTIMIZE TABLE daarna wordt uitgevoerd. Dus als je veel rijen hebt verwijderd en je wilt de vrije ruimte teruggeven aan het besturingssysteem na een enorme DELETE-bewerking, voer dan de OPTIMALISEERTABEL uit of bouw deze opnieuw op. Bijvoorbeeld:
We kunnen ook forceren om een tabel opnieuw op te bouwen met behulp van de ALTER-instructie:
Merk op dat de bovenstaande DDL-bewerking wordt uitgevoerd via online DDL, wat betekent dat MySQL gelijktijdige DML-bewerkingen toestaat terwijl het opnieuw opbouwen aan de gang is. Een andere manier om een defragmentatie uit te voeren is door mysqldump te gebruiken om de tabel naar een tekstbestand te dumpen, de tabel neer te zetten en deze opnieuw te laden vanuit het dumpbestand. Uiteindelijk kunnen we ook DROP TABLE gebruiken om de ongebruikte tabel te verwijderen of TRUNCATE TABLE om alle rijen in de tabel op te ruimen, waardoor de ruimte terug naar het besturingssysteem wordt teruggestuurd. De permanente oplossing is natuurlijk het toevoegen van meer ruimte aan de corresponderende schijf of partitie, of het toepassen van een kortere bewaarregel om onnodige bestanden op de server te houden. Als u bovenop een schaalbaar bestandsopslagsysteem werkt, zou u de bron moeten kunnen opschalen zonder al te veel gedoe, of met minimale onderbreking en downtime voor de MySQL-service. Bekijk dit blogbericht voor meer informatie over het dimensioneren van uw opslag en het begrijpen van MySQL- en MariaDB-capaciteitsplanning.
Schijfgerelateerde databaseproblemen zijn een van de meest voorkomende problemen bij MySQL-databasebeheerders en ontwikkelaars die met het RDBMS werken - hoewel deze problemen echter vaak voorkomen, zijn er ook veel manieren om ze op te lossen - en ze voorgoed op te lossen. De manieren om een dergelijk probleem aan te pakken zijn misschien niet altijd eenvoudig, maar ze kunnen allemaal worden opgelost met een beetje inspanning en hulp van tools zoals ClusterControl.
Met de proactieve monitoringmogelijkheden van ClusterControl zijn databasegerelateerde problemen uw minste zorg:u krijgt een melding in de vorm van een waarschuwing wanneer de schijfruimte 80% heeft bereikt en een melding in de vorm van een kritieke waarschuwing als uw schijfgebruik bereikt 90% of meer. We hopen dat je met deze blogpost in ieder geval een paar van de problemen met betrekking tot het gebruik van MySQL-schijfruimte hebt opgelost, geniet van je gebruik van ClusterControl en we zien je in de volgende blog.mysql> SET GLOBAL expire_logs_days = 3;expire_logs_days=3mysql> SET GLOBAL binlog_expire_logs_seconds = (60*60*24*3);
mysql> SET PERSIST binlog_expire_logs_seconds = (60*60*24*3);Oude tabellen verwijderen / tabellen opnieuw opbouwen
mysql> DELETE tbl_name WHERE id < 100000; -- remove 100K rows
mysql> OPTIMIZE TABLE tbl_name;mysql> ALTER TABLE tbl_name FORCE;
mysql> ALTER TABLE tbl_name; -- a.k.a "null" rebuildPermanente oplossingen voor problemen met schijfruimte
Samenvatting