Det är ont om diskutrymme på Adobe Commerce i molninfrastrukturen

Den här artikeln innehåller lösningar för när du har mycket lite utrymme eller inte har något 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äsning av 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 /data/mysql (eller var MySQL-datalagringen är konfigurerad) är fullt är genom att köra följande kommando i CLI:

df -h

Mindre än 10 % av det lediga minnet på MySQL-disken ä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å tillbaka MySQL på spåret (eller förhindra att det 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

WARNING
Vi rekommenderar starkt att du skapar en säkerhetskopia av databasen innan du utför några ändringar och undviker dem under höga belastningsperioder på platsen. Se Dumpa databasen i utvecklardokumentationen.

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 binära loggningsinställningar 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 inställningarna för MySQL-servern ber du support att kontrollera dem.

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.

recommendation-more-help
8bd06ef0-b3d5-4137-b74e-d7b00485808a