MySQL crashing when running a restore of sql file

MySQL & MariaDB Percona Distribution for MySQL
1

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.

Errors:
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/libpthread.so.0(+0xf630) [0x7f4b3b3b4630]
/lib64/libc.so.6(gsignal+0x37) [0x7f4b39433387]
/lib64/libc.so.6(abort+0x148) [0x7f4b39434a78]
/lib64/libstdc++.so.6(__gnu_cxx::__verbose_terminate_handler()+0x165) [0x7f4b39d43a95]
/lib64/libstdc++.so.6(+0x5ea06) [0x7f4b39d41a06]
/lib64/libstdc++.so.6(+0x5ea33) [0x7f4b39d41a33]
/lib64/libstdc++.so.6(+0x5ec53) [0x7f4b39d41c53]
/lib64/libstdc++.so.6(operator 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/libpthread.so.0(+0x7ea5) [0x7f4b3b3acea5]
/lib64/libc.so.6(clone+0x6d) [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
Status: NOT_KILLED

2

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

3

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

Regards

4

Hi,
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?

5

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

6

additional memory on server fixed the issue.