MySQL crashing when running a restore of sql file

I was running a restore of a sql file and it has now crashed the server 2 times.

Not sure what is going on.
Database is running ok after crash.

terminate called after throwing an instance of ‘std::bad_alloc’
what(): std::bad_alloc
12:48:34 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.

Build ID: da020587ab88e14d14c735ba39a113fac35d3888
Server Version: 8.0.21-12 Percona Server (GPL), Release 12, Revision 7ddfdfe

Thread pointer: 0x7f4a5402b700
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong…
stack_bottom = 7f4a5c05ec70 thread_stack 0x46000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d) [0x20b1ead]
/usr/sbin/mysqld(handle_fatal_signal+0x3c3) [0x1226ff3]
/lib64/ [0x7f4b3b3b4630]
/lib64/ [0x7f4b39433387]
/lib64/ [0x7f4b39434a78]
/lib64/ [0x7f4b39d43a95]
/lib64/ [0x7f4b39d41a06]
/lib64/ [0x7f4b39d41a33]
/lib64/ [0x7f4b39d41c53]
/lib64/ new(unsigned long)+0x7d) [0x7f4b39d421ed]
/usr/sbin/mysqld(void std::vector<unsigned long, std::allocator >::_M_realloc_insert<unsigned long const&>(__gnu_cxx::__normal_iterator<unsigned long*, std::vector<unsigned long, std::allocator > >, unsigned long const&)+0x5b) [0xf57dab]
/usr/sbin/mysqld(Rpl_transaction_write_set_ctx::add_write_set(unsigned long)+0x35) [0x100a3f5]
/usr/sbin/mysqld(add_pke(TABLE*, THD*, unsigned char*)+0x12d3) [0x100cf73]
/usr/sbin/mysqld(binlog_log_row(TABLE*, unsigned char const*, unsigned char const*, bool ()(THD, TABLE*, bool, unsigned char const*, unsigned char const*))+0x21d) [0xe1b64d]
/usr/sbin/mysqld(handler::ha_write_row(unsigned char*)+0x16b) [0xe1bb1b]
/usr/sbin/mysqld(write_record(THD*, TABLE*, COPY_INFO*, COPY_INFO*)+0x615) [0x10a8885]
/usr/sbin/mysqld(Sql_cmd_insert_values::execute_inner(THD*)+0xa99) [0x10a9b59]
/usr/sbin/mysqld(Sql_cmd_dml::execute(THD*)+0x5c9) [0x113b229]
/usr/sbin/mysqld(mysql_execute_command(THD*, bool)+0x3ce8) [0x10db6b8]
/usr/sbin/mysqld(mysql_parse(THD*, Parser_state*, bool)+0x444) [0x10dd9a4]
/usr/sbin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0x20cd) [0x10dff3d]
/usr/sbin/mysqld(do_command(THD*)+0x204) [0x10e0be4]
/usr/sbin/mysqld() [0x1217cf0]
/usr/sbin/mysqld() [0x25b94d4]
/lib64/ [0x7f4b3b3acea5]
/lib64/ [0x7f4b394fbb0d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f4a5462c568): INSERT INTO search_resource_rdf_type VALUES (30501594,11),(30501596,11),(30501599,11),(30501600,11),(30501602,11),(30501604,11),(30501606,11),(30501607,11),(30501608,11),(30501609,11),(30501610,11),(30501611,11),(30501616,11),(30501619,11),(30501620,11),(30501623,11),(30501624,11),(30501625,11),(30501634,11),(30501635,11),(30501636,11),(30501639,11),(30501641,11),(30501642,11),(30501645,11),(30501646,11),(30501648,11),(30501649,11),(30501650,11),(30501655,11),(30501658,11),(30501661,11),(30501662,11),(30501664,11),(30501667,11),(30501670,11),(30501672,11),(30501673,11),(30501675,11),(30501676,11),(30501678,11),(30501680,11),(30501688,11),(30501689,11),(30501690,11),(30501694,11),(30501695,11),(30501696,11),(30501698,11),(30501699,11),(30501702,11),(30501705,11),(30501708,11),(30501709,11),(30501710,11),(30501712,11),(30501713,11),(30501718,11),(30501721,11),(30501723,11),(30501725,11),(30501728,11),(30501730,11),(30501731,11),(30501732,11),(30501734,11),(30501741,11),(30501742,11),(30501745,11),(30501748,11
Connection ID (thread ID): 381

Not sure if this is memory related? Will ask sysadmin to increase memory from 3.8 gb to 8.8GB

Hi ipcmlr,

As per the last “INSERT” statement, table “search_resource_rdf_type” seems to be corrupted.
I suggest you consider taking a fresh backup and restoring again.

You are also on an old version (8.0.21). Hundreds (if not thousands) of bugs have been fixed since then. I strongly suggest you consider upgrading to a newer version to rule out any possible bug.

Last; do note that MySQL 8 does not allow downgrades so you should do some testing before upgrading. And whenever taking a backup and restoring into a new instance you the source version should be same or lower than the target version


I did drop the database each time and then tried to restore it from the sql file.
Are you saying that the sql file itself is corrupt?

Yes, this is memory related. Look at dmesg as well.

additional memory on server fixed the issue.