The Ultimate Guide to High Availability with MariaDB

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

Stai visualizzando una vecchia versione di questo article. Visualizza la versione più recente.

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. Using the core file
  6. What to do if you don't get a core file when mysqld crashes
  7. Running a copy of the database directory
  8. Reporting the problem

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.

Using the core file

If the debug version of mysqld crashes, you should now have:

  • A more precise stack trace in the 'hostname'.err file in the data directory.
  • A core or core.## file in your data directory.

To examine the stack trace and other information in the gdb debugger you can do:

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

What to do if you don't get a core file when mysqld crashes

On some systems there is a limit of the size of the core file. You can check and increase the limit with:

ulimit -c
ulimit -c unlimited

The above are shell limits and you should do this before you start mysqld again.

On some Linux systems the core files are disabled in the kernel. You can check this with:

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

Ensure that fs.suid_dumpable=2. You can set it with:

/sbin/sysctl -w fs.suid_dumpable=2

See also http://www.cyberciti.biz/tips/linux-core-dumps.html#comments

Running a copy of the database directory

If you are concerned with running the debug binary on your production database you can also copy the database to another location and use the new debug-enabled version with this. In this case you can skip the above instructions of installing MariaDB and instead run mysqld directly from the source directory.

This is useful when you know which statement crashed the server.

Just start mysqld with the option --datadir=/copy-of-original-data-directory

Reporting the problem

Report the problem, including the stack information in the MariaDB bugs database.

For very difficult or critical errors, you should consider sending the debug version of mysqld and the core file and some information of how to contact you in a .tar or .zip file to the MariaDB developers at Monty Program Ab so they can analyze it and try to create a fix.

Commenti

Sto caricando i commenti......
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.