3.4 Tabella posts crashed

[Davide DB]

Salve ragazzi,

 

Ho il forum morto e il problema risiede nella tabella posts che ha crashato e marcata per essere riparata.

 

 

Stavo per procedere da phpMyAdmin quando ho letto che Invision consiglia di far riparare il db al provider perchè questi sono sintomi di problemi sul server.

 

Tra l'altro, visto che ho un backup di tre gg fa, prima di procedere volevo fare ulteriore backup ma...

 

Da cPanel la funzione di backup mi torna un file vuoto

Da phpMyAdmin se esposto il database mi ritorna un file sql che sembra corretto.

 

Che faccio? provvedo io?

 

La tabella posts contiene la ciccia del forum...

[Daniel]

quanto pesa la tabella posts?

hai 2 possibilità, o fai fare al provider (che provider hai?) o ripari tu.. se hai un accesso SSH vai + tranquillo.

EDIT : comunque si, possono essere dati da cambi di versioni di mySQL sullo shared (ho letto che usi hostingplaza).. ultimamente dovrebbero avere reinstallarato i server.

[Davide DB]

Scusa rispondo solo ora dopo tutti i casini dei giorni scorsi.

La tabella non è enorme, circa 8MB per 2000 righe.

Da quello che capisco, sto facendo training on the job, di suo non dovrebbe mai sputtanarsi. Se accade dipende da casini del server: file system, riavvii ecc... 

Capace sia dipeso pure dalla versione di MySQL ma la cosa stana è che è accaduto 4 gg dopo la migrazione. Boh.

Cmq ora tutto a posto.

 

PS

La cosa brutta che ho notato è che se si cerca di fare backup di tutto prima di riparare la cosa non funziona. le export falliscono saltando la tabella incriminata. Io avevo un backup vecchio di due gg e ho dovuto incrociare le dita. 

[Enzo]

Ti consiglio di utilizzare Mysql dumper per fare i backup e restore dei database, credimi è una bomba.

[Daniel]

Ti consiglio di utilizzare Mysql dumper per fare i backup e restore dei database, credimi è una bomba.

 

Confermo, è un buon tool sopratutto per chi utilizza un webhosting senza possibilità di usare il tool di ssh mysqldump

Scusa rispondo solo ora dopo tutti i casini dei giorni scorsi.

La tabella non è enorme, circa 8MB per 2000 righe.

Da quello che capisco, sto facendo training on the job, di suo non dovrebbe mai sputtanarsi. Se accade dipende da casini del server: file system, riavvii ecc... 

Capace sia dipeso pure dalla versione di MySQL ma la cosa stana è che è accaduto 4 gg dopo la migrazione. Boh.

Cmq ora tutto a posto.

 

PS

La cosa brutta che ho notato è che se si cerca di fare backup di tutto prima di riparare la cosa non funziona. le export falliscono saltando la tabella incriminata. Io avevo un backup vecchio di due gg e ho dovuto incrociare le dita. 

non preocuparti, da quello che ho visto ora usi HP.

si, solitamente si corrompono le tabelle quando si modifica la versione del mysql a livello "globale" quindi nel tuo caso parliamo di hostingplaza.. o c'e una brusca interruzione del servizio data da un riavvio errato.

confermo comunque. su cPanel non ho mai avuto l'occasione di provare ma con il tool ufficiale da riga di comando, mysqldump fa la stessa cosa che hai descritto, e visto che il tool di cpanel si basa proprio su mysqldump per i backup/restore immagino che ti abbia ridato un file solo con l'header simile a  questo

-- MySQL dump 10.16  Distrib 10.1.9-MariaDB, for debian-linux-gnu (x86_64)---- Host: localhost    Database: invisionita-- -------------------------------------------------------- Server version	10.1.9-MariaDB-1~wheezy-log/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;/*!40101 SET NAMES utf8 */;/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;/*!40103 SET TIME_ZONE='+00:00' */;/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;