La prima parte della risposta è la buona notizia... che mysqlcheck -o non è più probabile che danneggi il tuo database rispetto all'esecuzione di OPTIMIZE TABLE su ogni tavolo, perché è tutto ciò che fa. È una comoda utility che accede al server, recupera un elenco delle tabelle e le scorre, inviando un OPTIMIZE TABLE interrogare il server per una tabella alla volta, fino al termine.
Ora, alcune brutte notizie. Se hai un danneggiamento latente nei tuoi tablespace, OPTIMIZE TABLE potrebbe incappare in esso, quindi dovresti essere certo di essere preparato per questa possibilità, con backup e un piano di ripristino. Le possibilità che ciò accada sono piuttosto remote, ma lo è un possibile risultato.
Peggiore notizie:quasi sicuramente stanno abbaiando dall'albero sbagliato.
L'esecuzione di Apache e MySQL insieme sulla stessa macchina con traffico significativo, o variazioni significative del traffico, è contro le migliori pratiche ed è una ricetta per i problemi, perché entrambi i servizi tendono ad aumentare il consumo di memoria sotto carico e se il database è il supporto memorizzare i dati del sito Web, quindi un aumento del carico tende a verificarsi su entrambi i servizi contemporaneamente.
Vedi la mia risposta a InnoDB Crash Post Mortem su Database Administrators Stack Exchange e Perché Apache è selvaggio e uccide MySQL in caso di errore del server per una copertura completa di questo problema abbastanza comune, di cui MySQL è la vittima, più di ogni altra cosa.
Nota che non importa se stai usando InnoDB o meno. Le voci di ripristino del database nel registro degli errori di MySQL saranno leggermente diverse, ma il regalo morto è questo:preceduto da nulla di sospetto, il registro degli errori di MySQL dice:
mysqld_safe Number of processes running now: 0
I messaggi che seguono sono spesso interpretati erroneamente come MySQL "crash", ma non è quello che sta succedendo... È stato ucciso. MySQL potrebbe anche rifiutarsi di riavviarsi, finché Apache non si calma o viene riavviato o il server non viene riavviato. Ancora una volta, dal registro degli errori, potresti visualizzare o meno qualcosa di simile a questo:
InnoDB: Initializing buffer pool, size = 4.0G
InnoDB: mmap(4395630592 bytes) failed; errno 12
InnoDB: Completed initialization of buffer pool
InnoDB: Fatal error: cannot allocate memory for the buffer pool
[ERROR] Aborting
[Note] /usr/libexec/mysqld: Shutdown complete
mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
Controllo /var/log/syslog o /var/log/messages (a seconda della distribuzione che esegui) ti mostrerà il vero problema.
$ sudo egrep 'kernel|oom' /var/log/syslog
...oi messaggi... dovrebbero rivelare un numero di voci che iniziano in questo modo:
kernel: pcscd invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
Apache diventa così affamato di memoria che il sistema è a rischio di instabilità generale, quindi "qualcosa" viene sacrificato. È probabile che quel "qualcosa" sia il demone di MySQL Server, mysqld .
kernel: Out of memory: Killed process 3044, UID 27, (mysqld)
MySQL di solito prova a riavviarsi da solo e, per quanto ne sai, anche questo può accadere occasionalmente... ma a meno che le richieste di memoria di Apache non diminuiscano rapidamente, MySQL non sarà autorizzato a richiedere memoria sufficiente dal sistema e lo farà mollare.
L'ottimizzazione dei tavoli ha le sue valide applicazioni... ma, in questo caso, se ho individuato correttamente il tuo problema, sarebbe molto paragonabile a risistemare le sedie a sdraio sulla nave che affonda Titanic. Potrebbe farti risparmiare spazio su disco, ma ti costerà anche dello spazio libero su disco durante l'esecuzione poiché alcuni motori di archiviazione creano una copia completamente nuova della tabella, quindi rinomina la copia ed elimina la vecchia tabella. In ogni caso, è improbabile che abbia un impatto significativo sul consumo di memoria.
