Fejl ved oprettelse af databaseforbindelse i WordPress

Kort svar: Beskeden betyder, at WordPress ikke kan bruge den databaseforbindelse, som wp-config.php beskriver. Kontrollér først om database-servicen er oppe, og om fejlen rammer både frontend og /wp-admin/. Sammenlign derefter DB_NAME, DB_USER, DB_HOST og det aktuelle password med hostingens konfiguration – uden at kopiere værdierne til screenshots eller supportbeskeder. Reparér kun tabeller, hvis en tabelkontrol dokumenterer skade.

Fagligt gennemgået: 28. august 2026

Kontrolgrundlag: WordPress 7.1 og PHP 8.4.23 på isoleret staging samt aktuel produktdokumentation. Databasehost, motor, bruger og rettigheder varierer mellem platforme og skal kontrolleres i det konkrete hostingmiljø.

Fejlen kan komme af forkerte credentials, en database-service der er stoppet, en forkert host/port, manglende brugerrettigheder eller et kapacitetsproblem. En beskadiget tabel er en anden fejltype og skal bevises, før du kører repair.

Før du ændrer noget: Tag database- og filbackup. Gem aldrig wp-config.php i en supportsag, og publicér aldrig DB_PASSWORD, hostnavn eller databasebruger i et screenshot.

Afgræns fejlen

Notér første og seneste tidspunkt samt om en ny request virker. En periodisk fejl efter 30 sekunders ventetid peger ikke nødvendigvis på et forkert password; den kan være kapacitet eller restart.

Klassificér databasefejlen før første ændring

Den konkrete databasebesked er mere værd end WordPress' generelle frontendtekst:

Tag fejlteksten fra et autentificeret kontrolpanel, WP-CLI eller serverlog. Vis ikke databasefejl offentligt for at få flere detaljer; de kan afsløre intern host, brugernavn og filsti.

1. Kontrollér database-servicen og ressourcer

Brug hostingens status/metrics eller bed hosting om at bekræfte:

• at databaseprocessen kører;
• at instansen accepterer forbindelser fra WordPress-miljøet;
• at disk/quota ikke er fuld;
• at max connections eller lignende loft ikke er nået;
• om servicen genstartede på fejlens tidspunkt.

Hvis servicen er nede, skal den bringes stabilt op, før du ændrer wp-config.php. Ellers risikerer du at erstatte korrekte credentials under en driftsfejl.

2. Sammenlign wp-config.php med den aktuelle database

Kontrollér kun disse værdier visuelt eller via sikker konfigurationsstyring:

define( 'DB_NAME', '…' );
define( 'DB_USER', '…' );
define( 'DB_PASSWORD', '…' );
define( 'DB_HOST', '…' );

DB_HOST kan være andet end localhost og kan indeholde port eller socket. Brug værdien fra det aktuelle hostingmiljø. Ved migration er en gammel intern host eller databasebruger almindelig.

Hvis passwordet er roteret, opdateres WordPress og databasebrugeren som én kontrolleret ændring. Gem ikke passwordet i shell history, ticket eller skærmbillede.

Ændr ikke $table_prefix for at “teste forbindelsen”. Prefix afgør hvilke tabeller WordPress læser efter forbindelsen og er ikke et loginparameter.

3. Test forbindelsen med platformens sikre værktøj

Foretræk hostingens database-test eller WP-CLI i det samme runtime-miljø som WordPress. Et eksempel på en read-only kontrol er database-check/forespørgsel efter platformens dokumenterede metode.

Opret ikke en offentligt tilgængelig test-db.php med credentials. Selv en kortlivet testfil kan lække adgangskoder gennem backup, logs, editorhistorik eller en direkte request.

Resultatet skal skelne mellem:

• kan ikke resolve/reach host;
• access denied for user;
• unknown database;
• too many connections;
• forbindelse lykkes, men en senere query fejler.

Hver besked har sin egen løsning. “Access denied” løses ikke med table repair.

4. Kontrollér brugerens rettigheder

Hvis forbindelsen når serveren, men brugeren afvises eller ikke kan læse WordPress-tabeller:

1. verificér, at brugeren er knyttet til den rigtige database;
2. sammenlign nødvendige privileges med en fungerende installation eller hostingens standard;
3. ret bruger-database-tilknytningen, ikke globale serverprivilegier;
4. gentag en read-only forespørgsel;
5. kør derefter WordPress-requesten.

Giv ikke databasebrugeren bredere administrative rettigheder end WordPress kræver for normal drift og opdatering.

5. Reparér kun dokumenteret beskadigede tabeller

Hvis en check rapporterer en bestemt tabel som crashed/corrupt:

1. tag en ny databasebackup og verificér at filen kan læses;
2. notér tabelnavn og checkresultat;
3. brug hostingens eller WP-CLI/databaseværktøjets målrettede repair;
4. kør check igen;
5. test WordPress.

WordPress kan eksponere en repairfunktion via WP_ALLOW_REPAIR, men den skal kun bruges kortvarigt og konstanten skal fjernes straks bagefter, fordi repair-siden ikke kræver normal login på samme måde. Brug hellere en autentificeret platformfunktion, når den findes.

Hvis mange tabeller er beskadiget, skal du stoppe og undersøge disk, databasecrash og backupintegritet. Masse-repair uden årsagsanalyse kan gøre datatabet sværere at afgrænse.

6. Undersøg periodiske forbindelsesfejl

Match fejlens tidspunkt med:

• forbindelsesantal;
• langsomme queries;
• database restart;
• backup/import;
• disk- eller I/O-pres;
• PHP-workers, der holder mange samtidige forbindelser.

Optimer den dokumenterede tunge query eller jobplan. Et større forbindelsesloft uden kontrol kan flytte presset til RAM eller disk.

Kontrolleret testforløb fra WordPress-runtime

Test fra samme miljø som den fejlende WordPress-request. En databaseklient på din egen computer kan have en anden netværksvej og beviser derfor ikke, at PHP-containeren kan forbinde.

1. Gem fejlens tidspunkt, requesttype og den aktuelle konfiguration som maskerede fingerprints – eksempelvis om hosten er localhost, socket eller separat host, ikke selve hemmeligheden.
2. Bekræft service, disk og forbindelsesmetrics uden at skrive til databasen.
3. Kør platformens read-only forbindelsestest eller en simpel SELECT 1 gennem den WordPress-konfigurerede forbindelse.
4. Hvis den lykkes, kontroller at de forventede WordPress-tabeller kan læses, uden at dumpe deres indhold.
5. Gentag den oprindelige frontend-/adminrequest og match den med PHP- og databaselog.
6. Ved periodiske fejl gentages målingen over mindst det tidligere fejlinterval og under den arbejdsgang, der udløste problemet.

En enkelt succes efter en databasegenstart kan være midlertidig. Notér forbindelsesantal, responstid og eventuelle restarts ved hver gentagelse. Hvis fejlene kun optræder under backup eller import, flyt eller reducer det dokumenterede job på staging før du hæver servergrænser.

Efter migration: test alle fire forbindelsesled

Ved flytning mellem miljøer skal host, port/socket, database og bruger-relation passe sammen. Kontrollér dem som fire separate led. Et hyppigt mønster er, at databasen og brugeren blev oprettet korrekt, men brugeren ikke blev knyttet til den nye database, eller at WordPress stadig peger på den gamle interne host.

Sammenlign også web-PHP og CLI. Hvis WP-CLI virker, men websitet ikke gør, kan de køre i forskellige containere, bruge forskellig wp-config.php, DNS eller PHP-konfiguration. “Det virker i terminalen” er derfor et spor, ikke en slutverifikation.

Før/efter og negativ kontrol

Som negativ kontrol må et bevidst forkert login i et lukket testmiljø fortsat blive afvist; du må ikke have løst problemet ved at gøre databaseadgangen global eller anonym. Brug en midlertidig testbruger uden produktionsdata, og fjern den igen. Kør ikke denne kontrol mod live med den aktive WordPress-bruger, da gentagne fejllogins kan udløse lås eller forstyrre drift.

Når problemet ligger i kapacitet

Ved too many connections skal du finde, om forbindelserne kommer fra mange legitime workers, langsomme queries eller kode, som ikke slipper ressourcer. Sammenhold åbne forbindelser, aktive PHP-workers og queryvarighed. Hæv kun loftet, hvis database-RAM og workerdesign kan bære det; ellers bytter du en afvisning ud med swap, langsomhed eller crash.

Ved disk-/I/O-pres skal du først sikre backup og stabil storage. Table repair er ikke kapacitetsstyring. Hvis der har været crash eller fuld disk, kontroller alle berørte tabeller og backupens tidsstempel, før siden åbnes for writes igen.

Verifikation

• En sikker read-only databaseforespørgsel lykkes fra WordPress-runtime.
• Forside, login og en databaseafhængig adminside giver forventet status.
• Tre gentagelser over det tidligere fejlinterval lykkes.
• Database- og PHP-log har ingen ny matchende connection error.
• Hvis repair blev kørt, rapporterer ny check tabellen som OK.

Undgå at teste med en ordre, brugeroprettelse eller anden irreversibel write, før read-only-kontrollerne består.

Rollback

Gendan den præcise wp-config.php-backup ved fejl. Rul passwordrotation tilbage på både database og WordPress som én handling. Gendan tabel fra backup, hvis en repair forværrer resultatet. Fjern WP_ALLOW_REPAIR og eventuelle midlertidige testbrugere/privilegier.

Hvornår skal hosting eller udvikler hjælpe?

Er forbindelsen bevist korrekt, og fejlen alligevel vender tilbage, ligger den i databasetjenesten eller i kapaciteten frem for i konfigurationen. På WordPress hosting hos Hostious kører databasen med dedikerede ressourcer pr. site, og supporten kan læse forbindelses- og fejllog med det samme.

Hosting skal hjælpe ved service, disk, forbindelsesloft, netværk, host/socket og privilegier. Send fejltype og tidspunkt, men maskér DB-navn og bruger. Udvikleren skal hjælpe ved reproducerbar query-/schemafejl. Hostious WordPress-support kan koordinere begge lag.

Sådan dokumenterer du databasefejlen

Dokumentationen skal vise fejlklassen og den efterfølgende fungerende læsetest uden at afsløre forbindelsesdata:

1. Fejlbeskeden på et isoleret testsite.
2. Kontrolpanel med database-service som oppe/nede; alle identifikatorer skjules.
3. wp-config.php med værdier fuldt dækket, kun konstantnavne synlige.
4. Read-only check før/efter eller anonymiseret tabelstatus.

Gem den præcise connection error-klasse og timestamp samt en succesfuld read-only eftertest. Ingen credentials eller fulde interne hostnavne må vises.

Ofte stillede spørgsmål om databasefejlen

Hvorfor siger WordPress pludselig, at databasen ikke kan nås?

Oftest fordi database-servicen er stoppet, serveren er løbet tør for hukommelse, eller adgangskoden i wp-config.php ikke længere passer. Fejlen kan også være midlertidig under høj belastning – tjek derfor først, om den stadig er aktiv.

Kan jeg selv rette fejlen uden teknisk hjælp?

Ofte, ja: kontrollér DB_NAME, DB_USER, DB_PASSWORD og DB_HOST i wp-config.php mod kontrolpanelets oplysninger, og genstart databasen hvis muligt. Rør ikke tabellerne uden backup – og lad reparation være sidste skridt.

Mister jeg data, når databaseforbindelsen fejler?

Normalt ikke. Fejlen betyder, at WordPress ikke kan NÅ databasen – ikke at den er slettet. Data er typisk intakte, når forbindelsen genoprettes; det er derfor, du ikke skal køre reparationer i panik.

Læs også

• Hub: WordPress fejl og fejlfinding
• Kritisk fejl i WordPress
• Hvid skærm i WordPress
• Optimering af WordPress-database