Brussels / 30 & 31 January 2016


More on gdb for MySQL DBAs

Using gdb to study MySQL internals and as a last resort

This session is about using GNU debugger (gdb) as a tool to study MySQL internals (namely, InnoDB locks and metadata locks) and as a last resort in cases when server hangs or has to be restarted for other reason. It never hurts to try a trick or two before giving up and restarting.

Sometimes MySQL DBAs have to work with stalled/hanged/unresponsive MySQL instance, where their usual SQL-based tricks do not work any more. Sometimes they can not even connect to check what's going on inside server.

In other cases they know what to do and everything still works, but they have to implement changes to read-only server variables. Server restart is often not an option in production, as it means some downtime and may cause negative performance impact.

In these cases one could do something given read and write access to server memory/internals. Here comed gdb, that, alone with careful reading of the source code helps to often resolve the problems described above. During this session I'll show what can be done with gdb when server already is in troubles, and how to use gdb to "see" and understand MySQL internals (like InnoDB locks or metadata locks) better.


Photo of Valerii Kravchuk Valerii Kravchuk