Per riparare il database WordPress bisogna prima creare un backup e identificare le tabelle realmente danneggiate. WordPress offre la costante WP_ALLOW_REPAIR, mentre phpMyAdmin e gli strumenti MySQL possono eseguire controlli più mirati.
Questa guida approfondisce riparare database WordPress con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.
Che cosa significa
La funzione di riparazione non risolve credenziali errate, server database non raggiungibile, query lente o spazio disco esaurito. È utile quando MySQL segnala tabelle corrotte o che richiedono repair.
La pagina di riparazione WordPress non richiede login quando è abilitata, quindi la costante deve essere rimossa immediatamente dopo l’intervento.
Come riconoscere il problema
- MySQL segnala table is marked as crashed.
- WordPress mostra errori su tabelle specifiche.
- Una tabella non può essere aperta.
- phpMyAdmin propone repair table.
- Il problema è iniziato dopo arresto o spazio esaurito.
Cause più frequenti
1. Tabella MyISAM danneggiata
Arresti improvvisi possono richiedere repair. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
2. Spazio o inode esauriti
Il database non riesce a scrivere file temporanei o indici. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
3. Crash o riavvio
Una operazione è stata interrotta in fase critica. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
4. Plugin con tabelle proprie
La corruzione può riguardare dati non core. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
5. Problema hardware o filesystem
Errori ricorrenti richiedono analisi del server. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
6. Confusione con lentezza
Una query lenta non implica che la tabella sia corrotta. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
Diagnosi passo per passo
- Crea backup database. Conserva dump e backup hosting prima di repair. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Leggi l’errore completo. Annota nome tabella e motore. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla spazio. Verifica quota e inode dell’account. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Esegui check. Usa phpMyAdmin o comandi supportati per la tabella. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Verifica il motore. InnoDB e MyISAM richiedono approcci differenti. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla log MySQL applicativo. Cerca ricorrenza e orario. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Distingui connessione e corruzione. Credenziali o host errati non si risolvono con repair. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
Metodo sicuro di diagnosi
Prima di applicare modifiche, registra lo stato iniziale: URL o servizio coinvolto, messaggio completo, data e ora, rete o client, ultima operazione eseguita e risultato da un secondo strumento. Questo consente di distinguere una causa locale da una configurazione condivisa e rende possibile il rollback.
Cambia un solo elemento alla volta. Dopo ogni intervento ripeti esattamente lo stesso test, controlla i log dello stesso intervallo temporale e annota il risultato. Modificare contemporaneamente DNS, cache, PHP, plugin e firewall rende impossibile stabilire quale correzione abbia avuto effetto.
Controllo incrociato
Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin e WP-CLI; per DNS interroga nameserver autoritativo e resolver pubblico; per la posta confronta header, Webmail e Track Delivery. Cache e proxy possono mostrare stati differenti per alcuni minuti.
Quando il problema sembra risolto, ripeti il test con una seconda rete o un secondo account e verifica che le protezioni restino attive. Una soluzione che disabilita globalmente TLS, WAF, autenticazione o controlli di sicurezza non è considerata definitiva.
Procedura di risoluzione
- Abilita WP_ALLOW_REPAIR temporaneamente. Aggiungi la costante in wp-config.php soltanto per il tempo necessario. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Esegui Repair Database. Usa la pagina prevista e registra il risultato. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Rimuovi subito la costante. La pagina non deve restare pubblicamente accessibile. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Ripara una tabella da phpMyAdmin. Solo quando il motore e l’errore lo consentono. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Ripristina da backup. Se la riparazione fallisce o i dati risultano incoerenti. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi la causa. Libera spazio, aggiorna plugin e verifica il server. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Controlla il sito. Testa frontend, wp-admin, ordini e contenuti. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
Verifica della stabilità dopo l’intervento
Non fermarti al primo test riuscito. Ripeti l’operazione dopo aver aperto una nuova sessione, svuotato soltanto la cache pertinente e atteso l’eventuale scadenza del TTL o del rate limit. Controlla inoltre che una seconda pagina, un secondo utente o un secondo destinatario non presentino ancora il problema.
Conserva per almeno il tempo necessario il backup e la configurazione precedente. Se l’anomalia ricompare, confronta orario, log e processo pianificato: una ricorrenza regolare può dipendere da cron, rinnovi, rotazioni, cache rigenerate o servizi esterni.
Controlli finali
- Tutte le tabelle si aprono.
- WP_ALLOW_REPAIR è rimosso.
- Il sito non registra nuovi errori.
- Backup disponibile.
- La causa originaria è stata corretta.
Prevenzione
- Backup regolari.
- Monitora spazio.
- Evita interruzioni durante import.
- Aggiorna plugin.
- Controlla errori MySQL.
Errori da evitare
- Non lasciare WP_ALLOW_REPAIR attivo.
- Non eseguire repair ripetuti senza causa.
- Non ottimizzare durante traffico critico.
- Non sovrascrivere dati recenti senza verifica.
- Non condividere dump contenenti dati personali.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi o richiede log e configurazioni non disponibili nel pannello. Indica:
- tabella e motore
- errore completo
- orario
- spazio disponibile
- backup presente
Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.
Fonti tecniche ufficiali
Verifica prolungata dopo la correzione
Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione dopo una nuova sessione, da una seconda rete o con un secondo utente quando applicabile. Per DNS e posta considera anche TTL, code e cache dei resolver; per HTTP e WordPress controlla una pagina dinamica, una funzione amministrativa e il relativo registro degli errori.
Conserva temporaneamente il backup, i valori precedenti e gli estratti dei log. Se l’anomalia ricompare, confronta l’orario con cron, backup, aggiornamenti, rinnovi SSL, rotazioni DNS, code email e servizi esterni. Una ricorrenza regolare è spesso più significativa del messaggio mostrato durante il singolo evento.
Prima di chiudere l’intervento verifica inoltre che le misure di sicurezza siano ancora operative: HTTPS valido, autenticazione richiesta, WAF attivo, permessi non eccessivi e nessun endpoint di debug o manutenzione lasciato pubblico. La soluzione deve correggere la causa senza ridurre stabilmente le protezioni del servizio.
Domande frequenti su riparare database WordPress
WP_ALLOW_REPAIR richiede il login?
No, per questo deve essere rimosso appena terminata la riparazione.
Repair risolve una password database errata?
No. Corregge tabelle, non credenziali o host.
Devo ottimizzare insieme alla riparazione?
Soltanto se necessario e dopo backup; sono operazioni differenti.
Tutte le tabelle supportano REPAIR TABLE?
No, dipende dal motore e dal tipo di problema.
Quando è meglio ripristinare un backup?
Quando la riparazione fallisce o l’integrità dei dati non è affidabile.