Ett fel uppstod vid anslutning till databasen i WordPress: vad det betyder

Vad meddelandet säger

För varje sida den levererar öppnar WordPress en anslutning till sin MySQL- eller MariaDB-databas med fyra värden som står i wp-config.php, i webbplatsens rotmapp:

define( 'DB_NAME', 'databasnamn' );
define( 'DB_USER', 'anvandarnamn' );
define( 'DB_PASSWORD', 'losenord' );
define( 'DB_HOST', 'localhost' );

”Ett fel uppstod vid anslutning till databasen” betyder att den anslutningen misslyckades. Fyra orsaker ger det: uppgifter som inte längre stämmer, en databasserver som ligger nere eller inte går att nå, en överbelastad server eller en skadad databas. Avsnitten nedan går igenom dem, från den enklaste att kontrollera till den ovanligaste.

1. Svarar databasservern?

• Webbhotellets statussida: ett avbrott eller underhåll på MySQL-servern meddelas där.
• Andra webbplatser på samma konto: visar de samma fel i samma ögonblick ligger orsaken på serversidan, och åtgärden hos ditt webbhotell.
• phpMyAdmin, från webbhotellets kontrollpanel: öppnar det databasen och visar dess tabeller är servern igång och databasen finns.

Ligger felet hos servern, öppna ett ärende hos webbhotellet och ange när felet började och det exakta meddelandet. Under tiden finns inget att ändra på webbplatsen.

2. Stämmer uppgifterna i wp-config.php?

Det är den vanligaste orsaken efter en flytt av webbplatsen, ett byte av databaslösenordet i kontrollpanelen eller en återställning från säkerhetskopia. Jämför de fyra värdena i wp-config.php med databasavsnittet i webbhotellets kontrollpanel:

• DB_NAME och DB_USER: många webbhotell sätter kontonamnet som prefix (konto_wordpress). Prefixet är en del av namnet.
• DB_PASSWORD: är du osäker, sätt ett nytt lösenord för användaren i kontrollpanelen och kopiera in det i filen.
• DB_HOST: localhost hos många webbhotell, men inte alla. Vissa anger ett servernamn eller en adress, ibland följd av en port (:3306). Det exakta värdet står i kontrollpanelen.
• Användaren behöver rättigheter på databasen: kontrollera i kontrollpanelen att användaren är kopplad till databasen, med alla behörigheter.

Ett lösenord som innehåller ett enkelt citattecken (') bryter PHP-strängen som omger det i wp-config.php. Sätt ett omvänt snedstreck framför det (\'), eller välj ett lösenord utan enkelt citattecken.

Testa uppgifterna utanför WordPress

WordPress visar ett allmänt meddelande. MySQL säger däremot exakt vad som är fel. Två sätt att fråga, med värdena från wp-config.php:

Från kommandoraden, om du har SSH-åtkomst

mysql -h localhost -u anvandarnamn -p databasnamn

Med WP-CLI läser wp db check direkt wp-config.php och kontrollerar tabellerna med de uppgifterna.

Med en tillfällig PHP-fil

Ladda upp den här filen till webbplatsens rotmapp under ett namn som är svårt att gissa, öppna den i webbläsaren och radera den direkt efteråt: den innehåller databasens lösenord.

<?php
mysqli_report(MYSQLI_REPORT_OFF);
$link = @mysqli_connect('localhost', 'anvandarnamn', 'losenord', 'databasnamn');
echo $link ? 'Anslutning OK' : 'Misslyckades: ' . mysqli_connect_error();

Den första raden spelar roll: sedan PHP 8.1 kastar en misslyckad anslutning som standard ett undantag, och sidan skulle förbli tom i stället för att visa MySQL:s meddelande.

3. En skadad databas: reparationsverktyget

När uppgifterna stämmer men tabeller är skadade visar den publika webbplatsen samma anslutningsfel, och adminpanelen ett mer exakt: ”En eller flera databastabeller är otillgängliga. Databasen kan behöva repareras.” WordPress har ett verktyg för detta. Lägg till den här raden i wp-config.php:

define( 'WP_ALLOW_REPAIR', true );

Öppna sedan https://www.din-webbplats.com/wp-admin/maint/repair.php och kör ”Reparera databas”. Ta bort raden så snart reparationen är klar: så länge den finns kan vem som helst nå sidan, utan att logga in.

Exportera databasen före varje reparation (wp db export, eller fliken Exportera i phpMyAdmin). Misslyckas reparationen kan ditt webbhotell återställa databasen från sina säkerhetskopior.

4. Ett fel som kommer och går: belastningen

Ett fel som visar sig vid vissa tider och sedan försvinner av sig självt pekar på en överbelastad server snarare än en felaktig inställning. De vanliga orsakerna:

• En trafiktopp, ofta robotar: upprepade inloggningsförsök mot wp-login.php eller xmlrpc.php, synliga i webbhotellets åtkomstloggar.
• Gränserna för delade webbhotell: samtidiga anslutningar eller processer begränsade per konto. Kontrollpanelerna visar dem oftast i avsnittet om resursförbrukning.
• Ett tungt tillägg: statistik, loggar eller schemalagda uppgifter som skriver till databasen vid varje besök.

Åtgärderna: blockera missbrukande inloggningsförsök, lägg till sidcache, stäng av xmlrpc.php om inget program använder det, och be ditt webbhotell om loggarna för tidpunkten då felet inträffade.