MySQL diskutrymme börjar ta slut på Adobe Commerce i molninfrastrukturen
Den här artikeln innehåller lösningar för när du har mycket lite utrymme eller inget utrymme för MySQL på Adobe Commerce i molninfrastruktur. Symtomen kan omfatta avbrott i webbplatser, kunder som inte kan lägga till produkter i kundvagnen, som inte kan ansluta till databasen, få fjärråtkomst till databasen och som inte kan ansluta SSH till noden. Symtomen är också Galera, miljösynkronisering, PHP, databas och distributionsfel som listas nedan. Klicka på Lösning om du vill gå direkt till lösningsavsnittet.
Berörda produkter och versioner
Adobe Commerce om molninfrastruktur 2.3.0-2.3.6-p1, 2.4.0-2.4.2
Problem
Databasen blir för stor. Symtomen kan vara att databasanslutningen bryts, databasöverföringsfel och många andra problem.
Fel som kan uppstå:
Galera:
- SQLSTATE[08S01]: Kommunikationslänksfel: 1047 WSREP har inte förberetts för programanvändning än Importfel:
- SQLSTATE[HY000]: Allmänt fel: 1180 Fel 5 "Indata-/utdatafel" uppstod
- SQLSTATE[08S01]: Kommunikationslänksfel: 1047 WSREP har inte förberetts för programanvändning än
Fel vid miljösynkronisering:
- SQLSTATE: Allmänt fel: 1180 Fel 5 "Indata-/utdatafel" uppstod under COMMIT
PHP-fel:
- php: SUB::__construct(): MySQL-servern har försvunnit.
- php-fel: SUB::__construct(): Fel vid läsning av gratulationspaket. PID=NNNN.
- FEL 2013 (HY000): Anslutningen till MySQL-servern bröts vid 'Läser ursprungligt kommunikationspaket', systemfel: 0 "Internt fel/kontroll (inte systemfel)".
Databasfel:
- Fel_kod: 1114
- InnoDB: Fel (slut på diskutrymme) vid skrivning av ordnod till FTS-tilläggsindextabell.
- SQLSTATE[HY000]: Allmänt fel: 2006 MySQL-servern har försvunnit
- [ERROR] Slav SQL: Felet "Tabellen
<table\_name>är full" i frågan. - Enheten mysql.service har försatts i ett felaktigt tillstånd.
- fel: Det går inte att ansluta till den lokala MySQL-servern via socketen /var/run/mysqld/mysqld.sock (111 Anslutning nekad)
- 1205 Tidsgränsen för låsning har överskridits. Försök starta om transaktionen. Frågan var: INSERT INTO `cron_schedule` (`job_code`, `status`, `created_at`, `edul_at`) VÄRDEN (?, ?,
YYYY-02-07 HH:MM:SS,YYYY-MM-DD HH:MM:SS)
Distributionsfel:
- E: Kommandot '['sudo', '-u',
<environment name>, 'bash', '-c', '/etc/platform/<environment name>/post_deploy.sh']' returnerade en avslutningsstatus som inte är noll 255 - E: Kommandot '['ssh'', u
<node IP address>, 'sudo /usr/bin/sv -w 30 launch site-<environment name>g-nginx']' returnerade inte-noll - Uppgraderar schema… SQLSTATE[HY000]: Allmänt fel: 114 Tabellen
<table\_name>är full - SQLSTATE[HY000]: Allmänt fel: 3 Fel vid skrivning av fil ./
<environment name>/# - W:
<filename>(Felkod: 28 "Inget utrymme återstår på enheten") Indexeringsfel (tillsammans med tillfälliga Ibd-filer som inte har sparats in i /tmp): - Katalogregelindexeraren genererar ett undantag. De temporära tabellerna rensas inte i efterbearbetningen och fyller sedan i disken på den aktuella MySQL-huvudnoden
Steg som ska återskapas:
Ett sätt att kontrollera om datalagringen /data/mysql (eller där MySQL är konfigurerad) är full är att köra följande kommando i CLI:
df -h
Mindre än 10 % av det lediga minnet på disken MySQL är en primär indikator på ett driftstopp.
Orsak
Monteringen /data/mysql kan bli full på grund av en rad problem, som att det inte finns tillräckligt med noder, tillgängligt lagringsutrymme och felaktiga frågor som genererar tillfälliga tabeller.
Lösning
Det finns ett omedelbart steg som du kan ta för att få MySQL tillbaka på spår (eller förhindra att den fastnar): frigör utrymme genom att tömma stora tabeller.
Men en långsiktig lösning skulle allokera mer utrymme och följa Bästa praxis för databaser, inklusive aktivering av funktionen Arkiv för beställning/faktura/leverans.
Här följer information om både snabba och långsiktiga lösningar.
Kontrollera och frigöra noder
Se till att det finns tillräckligt med tillgängliga noder. Kör följande kommando för att göra detta:
df -i
Utdata skulle se ut ungefär så här:
Filesystem Inodes Used Free Use% Mounted on
/dev/nvme2n1 655360 1695 653665 1% /data/mysql
Kontrollera att Använd % är <70 %. Inoder är korrelerade med filer. Om du tar bort filer från partitionen kommer du att frigöra noder.
Kontrollera och frigör lagringsutrymme
Kontrollera tillgängligt lagringsutrymme. Kör för detta:
df -k
Resultatet skulle se ut ungefär så här:
Size Used Avail Use% Mounted on·
50G 49G 95M 100% /data/mysql
Om Använd % är >70 % måste du vidta åtgärder för att frigöra/lägga till utrymme.
Sök efter stora ibtmp1 filer
Kontrollera om det finns stora ibtmp1-filer på /data/mysql i varje nod: det här är tabellutrymmet för temporära tabeller. Om det finns felaktiga frågor som genererar tillfälliga tabeller finns de i filen ibtmp1. Den här filen tas bara bort när databasen startas om. Om det tar upp allt tillgängligt utrymme måste databasen startas om. Om det finns felaktiga frågor återskapas den igen.
Töm stora tabeller
Kontrollera om det finns stora tabeller och tänk på om någon av dem kan tömmas. Gör detta på den primära (käll-) noden.
Tabeller med rapporter kan till exempel oftast tömmas. Mer information om hur du söker efter stora tabeller finns i artikeln Sök efter stora MySQL tabeller .
Om det inte finns några stora rapporttabeller bör du överväga att tömma _index-tabeller, bara för att returnera Adobe Commerce-programmet på rätt spår. index_price tabeller skulle vara de bästa kandidaterna. Exempel: catalog_category_product_index_storeX tabeller, där X kan ha värden från "1" till det maximala antalet arkiv. Tänk på att du måste indexera om för att återställa data i dessa tabeller, och om det gäller stora kataloger kan omindexeringen ta lång tid.
När du har tömt dem väntar du på att wsrep-synkroniseringen ska slutföras. Nu kan du skapa säkerhetskopior och utföra fler viktiga steg för att lägga till mer utrymme, som att allokera/köpa mer utrymme och aktivera funktionen Arkiv för beställning/faktura/leverans.
Kontrollera inställningar för binär loggning
Kontrollera de binära loggningsinställningarna för MySQL-servern: log_bin och log_bin_index. Om inställningarna är aktiverade kan loggfilerna bli enorma. Skapa en supportbiljett som begär att stora binära loggfiler ska rensas. Begär också att du kontrollerar att binär loggning konfigureras korrekt så att loggarna rensas regelbundet och inte tar för mycket utrymme.
Om du inte har tillgång till serverinställningarna för MySQL ber du support att kontrollera det.
Allokera/köp mer utrymme
Allokera mer diskutrymme för MySQL om du inte har använt något. Mer information om hur du kontrollerar om det finns ledigt diskutrymme finns i artikeln Kontrollera begränsning av diskutrymme.
- För Starter-planen, alla miljöer och Pro-planintegreringsmiljöer kan du allokera diskutrymmet om du inte använder något. Mer information finns i Allokera mer utrymme för MySQL.
- För Pro-planmiljöer för mellanlagrings- och produktionsmiljöer kontaktar du support för att tilldela mer diskutrymme om du inte har använt något.
Om du har nått din utrymmesgräns och fortfarande har problem med lite utrymme kan du överväga att köpa mer diskutrymme. Kontakta Adobe Account Team för mer information.
Relaterad läsning
Metodtips för att ändra databastabeller i Commerce Implementeringspellbook