Avaluació inicial sense contrasenyes Pressupost abans d’intervenir Un especialista responsable de principi a fi

Base Dades I Dades Wordpress

La reparació de la base de dades de WordPress acaba, però l’error torna

Descobreix per què reapareixen errors de base de dades després de reparar revisant disc, caigudes MySQL, motors, consultes i emmagatzematge.

Una ordre de reparació pot reconstruir índexs o marcar una taula com a utilitzable sense corregir l’esdeveniment que l’ha malmesa. Si l’error torna, investiga pressió de disc, aturades brusques de MySQL, fallades d’emmagatzematge, un mètode incompatible o codi que torna a espatllar les dades.

Deixa de tractar cada recaiguda com un cas aïllat. Conserva una cronologia i protegeix les dades actuals abans d’una altra reparació.

Compara cada recaiguda

Registra taula, codi MySQL, hora, funció i sortida de reparació per a cada incident. Determina si sempre falla la mateixa taula o índex o si el dany es desplaça.

Cronologia:
primer error
mètode i resultat de reparació
reinici o esdeveniment de disc
primera activitat d'escriptura
hora de la recaiguda
motor de la taula

Oculta valors de consultes i dades de clients.

Confirma que les còpies siguin utilitzables

Fes un bolcat actual quan sigui possible i conserva una còpia coneguda anterior. Llegeix els errors del bolcat: «completat» no garanteix que s’hagin exportat totes les taules.

Prova la restauració en una base o servidor aïllat. Confirma els recomptes i l’accés des de l’aplicació.

No desis totes les còpies al mateix disc problemàtic ni sobreescriguis l’última de vàlida.

Revisa disc i sistema de fitxers

Comprova espai, inodes, sistema de fitxers de dades i logs de MySQL i alertes de l’allotjament. Un volum ple pot interrompre escriptures i fer caure taules.

En un VPS, revisa els errors del kernel i l’emmagatzematge amb un administrador autoritzat. En allotjament gestionat, demana proves al proveïdor.

Alliberar espai pot aturar la fallada immediata, però no demostra que el disc estigui sa.

Examina l’historial d’aturades de MySQL

Busca aturades no netes, recuperació, processos finalitzats per manca de memòria i reinicis forçats al voltant de cada recaiguda. MySQL s’ha d’aturar correctament abans del manteniment.

No reiniciïs repetidament com a diagnòstic. Conserva abans la memòria, els processos i el registre.

Si còpies o importacions coincideixen amb els pics, reprograma-les i acota-les.

Utilitza una reparació adequada al motor

Les eines de MyISAM no resolen corrupció InnoDB. wp-admin/maint/repair.php executa comprovacions, però no repara maquinari ni totes les fallades InnoDB.

SHOW TABLE STATUS LIKE 'wp_example';
CHECK TABLE wp_example;

Indica taules concretes i comença amb un compte autoritzat de només lectura. Escala els errors InnoDB al proveïdor o administrador.

Investiga escriptures recurrents

Un connector pot repetir migracions d’esquema, escriure dades excessives o aturar-se a mig procés. Relaciona el propietari i les modificacions de la taula amb cron i actualitzacions.

Desactiva la migració programada responsable en staging i reprodueix-la. Actualitza o substitueix codi abandonat.

No eliminis la taula fins a confirmar que les dades són reconstruïbles i el proveïdor en documenta la creació.

Comprova memòria i capacitat

Les aturades per OOM, connexions exhaurides i bloquejos llargs poden provocar una caiguda brusca. Revisa RAM, swap, buffers MySQL i càrregues concurrents.

Ajusta segons mesures, no copiant configuracions genèriques. Reservar buffers per sobre de la RAM física empitjora les caigudes.

Evita que les tasques web i de còpia consumeixin tots els recursos que necessita MySQL.

Observa després de reparar

Després de recuperar, registra la mida, files, uptime MySQL, disc lliure i última aturada neta. Executa escriptures controlades a la funció afectada i revisa el registre després de cada cicle.

No programis CHECK TABLE agressiu i continu sobre taules grans; pot crear la seva pròpia càrrega. Segueix les indicacions del motor i alerta per la signatura original, llindar de disc i reinici no net.

Restaura, repara i vigila

Corregeix l’emmagatzematge, la capacitat o l’aplicació abans de la reparació o restauració final. Utilitza un manteniment que impedeixi escriptures perilloses durant la recuperació.

Verifica la funció, els registres recents i les escriptures noves durant diversos cicles.

El manteniment recurrent ha de provar restauracions i alertar per disc, OOM i aturades brusques. L’èxit significa que la causa perjudicial ha desaparegut, no que es pugui prémer de nou el botó de reparar.

ABANS D’ENVIAR LA SOL·LICITUD

Preguntes freqüents.

Demaneu contrasenyes al formulari?+

No. El formulari públic no demana mai accessos. Les dades segures es demanen només després d’aprovar l’abast i el pressupost.

Qui revisa la incidència?+

La sol·licitud arriba a Jordi Ensenyat, fundador de Code Barcelona i especialista en WordPress amb més de 15 anys d’experiència.

Es canvia res abans del pressupost?+

No. Primer es revisen els símptomes visibles i es defineix l’abast. La intervenció comença després de l’aprovació i amb una via de recuperació preparada.

Treballeu amb webs en anglès i fora d’Espanya?+

Sí. WP Repair atén incidències de WordPress i WooCommerce en català, castellà i anglès mitjançant un servei remot.

Avaluar la meva incidència