Enabling Core Dumps for MySQL Crash Diagnosis

MySQL crashes can be hard to diagnose because the error log often provides insufficient information, especially for subtle failures. To retain more forensic data, the article recommends enabling core dumps.

The experiment reproduces a known bug (#95294) on a MySQL 5.7 instance, showing that the server silently exits and the error log only contains a brief stack trace.

To capture a full memory snapshot, three steps are performed:

Enable system‑wide core dump generation by setting appropriate kernel parameters (e.g., sysctl -w kernel.core_pattern=/tmp/core.%e.%p and ulimit -c unlimited ).

Increase the MySQL process user’s ulimit for core files, ensuring the user (root in the example) can create large core files.

Configure MySQL to allow core dumps by setting core_file=1 (or the relevant MySQL option) in the server configuration.

After restarting MySQL, a deliberate crash produces a core file, which is confirmed in the error log. The core file size is large because it contains the entire memory image.

From MySQL 8.0.14 onward, the innodb_buffer_pool_in_core_file option can be disabled to reduce core dump size by excluding the InnoDB buffer pool.

To analyze the core dump, the article shows using gdb to load the core file and extract stack traces for all threads, providing a detailed view of the crash context.

Conclusion: By enabling OS‑level core dumps, adjusting user limits, and setting the appropriate MySQL option, you can obtain comprehensive crash information that aids developers and the MySQL team in diagnosing complex failures.