The Ultimate Guide to High Availability with MariaDB
This is a read-only copy of the MariaDB Knowledgebase generated on 2024-11-21. For the latest, interactive version please visit https://mariadb.com/kb/.

Come ottenere uno stack trace completo di mysqld (il server MariaDB)

Contents

  1. Compilare MariaDB per il debug
  2. Aggiornare il file my.cnf
  3. Rimpiazzare temporaneamente il mysqld standard con la versione di debug
  4. Ripristinare la versione originale di mysqld
  5. Usare il file core
  6. Se non si ottiene un file core quando mysqld va in crash
  7. Eseguire una copia della directory del database
  8. Segnalare il bug

Se si verifica un errore critico di mysqld (core dump), per default scriverà uno stack trace nel file 'nomehost'.err nella directory dei database. Tuttavia vi sono casi in cui questo non è sufficiente per individuare il problema.

Le seguenti istruzioni spiegano come ottenere uno stack trace completo su Unix.

Per capire dov'è il problema, uno sviluppatore di MariaDB necessita di una o più fra le seguenti informazioni:

  • Uno stack trace completo (che si può ottenere solo usando un binario compilato per il debug)
  • Un file core (immagine del programma crashato)
  • Un mysqld compilato per il debug.

Ecco come creare tutto questo:

  1. Si scarichi un file tar.gz dei sorgenti (like mariadb-5.2.9.tar.gz).
  2. Lo si compili per il debug
  3. Si aggiorni il file my.cnf per ottenere un core e uno stack trace.
  4. Si installi il mysqld di debug al posto di quello regolare.
  5. Si esegua la versione di debug fino a quando non avviene un nuovo crash.
  6. Si ripristini la vecchia versione di mysqld.

Compilare MariaDB per il debug

Segue un esempio di come compilare MariaDB per il debug nella propria home directory con MariaDB 5.2.9:

cd ~
mkdir mariadb
cd mariadb
tar xvf mariadb-5.2.9.tar.gz
ln -s mariadb-5.2.9 current
cd current
./BUILD/compile-pentium64-debug-max

L'ultimo comando produce una versione di debug di sql/mysqld. Se si ha un sistema che non sia Intel/AMD a 64 bit con Linux, si può utilizzare un diverso file BUILD/...-debug-max. Se il comando fallisce, si provi in questo modo:

./BUILD/autorun.sh
./configure --with-debug=full -with-extra-charsets=complex \
--with-plugin-aria --with-aria-tmp-tables --without-plugin-innodb_plugin \
--with-plugins=max \
--with-mysqld-ldflags=-all-static  --with-client-ldflags=-all-static 
make

Aggiornare il file my.cnf

Si aggiungano le righe seguenti al file ~/.my.cnf:

[mysqld]
--stack-trace
--core-file
[mysqld-safe]
--core-file-size=unlimited

Si può lasciare anche per il futuro, non creano problemi.

Nota: Se si sta utilizzando safe_mysqld ed eseguendo mysqld come root, su alcuni sistemi non verrà creato alcun file core. La soluzione è eseguire mysqld con un altro utente.

Rimpiazzare temporaneamente il mysqld standard con la versione di debug

Ecco come farlo su Open SuSE. Sulle altre distribuzioni di Linux, mysqld potrebbe trovarsi in altre directory.

mysqladmin shutdown
cd /usr/local/mysql/libexec
mv mysqld mysqld-orig
cp ~/mariadb/current/sql/mysqld mysqld-debug
ln -s mysqld-debug mysqld

I comandi sopra riportati rimpiazzano mysqld con la versione di debug, e lo fanno in un modo che rende semplicissimo il ritorno alla versione originale.

A questo punto, si avvi di nuovo mysqld con un comando come:

/etc/rc.d/mysql start

Ripristinare la versione originale di mysqld

E' possibile ripristinare il binario originale di mysqld in questo modo:

cd /usr/local/mysql/libexec
rm mysqld
ln -s mysqld-orig mysqld

Si noti che il binario di debug non viene cancellato: viene rimosso soltanto il sym-link, che immediatamente viene sostituito con uno che punti al binario originale. In questo modo, il binario di debug potrà essere riutilizzato in futuro.

Usare il file core

Se la versione di debug di mysqld va in crash, si dovrebbe avere:

  • Uno stack trace più preciso nel file 'nomehost'.err, che si trova nella directory dei dati.
  • Un file core o core.##, sempre nella directory dei dati.

Per esaminare lo stack trace e altre informazioni nel debugger gdb:

cd ~/mariadb/current
cp directory-del-db/core* core
gdb ~/mariadb/current/sql/mysqld core
backtrace full

Se non si ottiene un file core quando mysqld va in crash

Su alcuni sistemi, le dimensioni del file core hanno un limite. Per conoscere il limite e incrementarlo:

ulimit -c
ulimit -c unlimited

Dopodichè, si riavvii mysqld.

Su alcuni sistemi Linux i file core sono disabilitati dal kernel. Per controllare:

sysctl -a | grep k.*core
sysctl -a | grep dumpable

Si verifichi che fs.suid_dumpable=2. Per impostarlo:

/sbin/sysctl -w fs.suid_dumpable=2

Si veda anche http://www.cyberciti.biz/tips/linux-core-dumps.html#comments

Eseguire una copia della directory del database

Se non si vuole eseguire il debug binario sul database di produzione, è possibile copiare il database in un altro percorso e utilizzare la nuova versione. In questo caso si può evitare di installare MariaDB come spiegato sopra, ed eseguire mysqld direttamente dalla directory dei sorgenti.

In questo modo si potrà sapere senza rischi quale istruzione ha mandato in crash il server.

Si avii mysqld con l'opzione --datadir=/copia-della-directory

Segnalare il bug

Infine si segnali il problema nel database dei bug di MariaDB, includendo lo stack trace.

Per errori molto complicati o critici, si può inviare a Monty Program Ab la versione di debug di mysqld, il file core e informazioni su come essere ricontattati nel file .tar o .zip. Loro analizzeranno il tutto e tenteranno di risolvere il problema.

Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.