From getting backtraces, SQL statements executed by threads at the moment of crash to changing some of the read only server variables on the fly... Sometimes gdb is your last resort, and few tricks from experts may help.
I'd like to show and discuss typical use cases of gdb for a production MySQL DBA. Some of them were already discussed in blog posts like the following:
http://www.percona.com/blog/2012/09/09/obtain-last-executed-statement-from-optimized-core-dump/ http://www.percona.com/blog/2013/11/11/how-to-extract-all-running-queries-including-the-last-executed-statement-from-a-core-file/ http://mysqlbugs.blogspot.com.au/2012/09/how-to-obtain-all-executing-queries.html http://dom.as/2009/02/15/poor-mans-contention-profiling/ http://dom.as/2010/01/02/read-ahead/ http://dom.as/2009/07/30/evil-replication-management/ http://www.percona.com/blog/2010/03/23/too-many-connections-no-problem/ http://dom.as/2009/12/29/when-bad-things-happen/
and some are even well known as a separate tools, like pt-pmp. But quick review, real life use cases demonstration and discussion may help attendees to know the limitations, outcomes and benefits of attaching gdb to a (hopefully) live MySQL server as a last resort of solving some problems or getting additional useful information for further troubleshooting before restarting it.
Speakers: Valerii Kravchuk