Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

xtrabackup got a crash in prepare stage with default use-memory.

Description

the abort crash error log :

2024-03-31T04:07:26.714067+08:00 0 [Note] [MY-011953] [InnoDB] Page cleaner took 68857ms to flush 0 and evict 0 pages 2024-03-31T04:07:26.790897+08:00 0 [Warning] [MY-012091] [InnoDB] Allocated tablespace ID 218727 for chng_cwgx_2306_hpdi/t_pur_inquiryturns, old maximum was 0 2024-03-30T20:47:33Z UTC - mysqld got signal 11 ; Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware. BuildID[sha1]= Thread pointer: 0x6a2d430 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 = 7ffd23b727f8 thread_stack 0x100000 xtrabackup(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x2766b1e] xtrabackup(print_fatal_signal(int)+0x36b) [0x1449e1b] xtrabackup(handle_fatal_signal+0x95) [0x1449eb5] /usr/lib64/libpthread.so.0(+0x135a0) [0x7f4c52cf55a0] /usr/lib64/libc.so.6(+0x156f6a) [0x7f4c52358f6a] xtrabackup(dict_sdi_create_idx_in_mem(unsigned int, bool, unsigned int, bool)+0x974) [0x19de134] xtrabackup(dd_table_open_on_id(unsigned long, THD*, MDL_ticket**, bool, bool, bool)+0xd80) [0x169e510] xtrabackup() [0x159f4f9] xtrabackup(ib_sdi_get_keys(unsigned int, ib_sdi_vector*, trx_t*)+0x26) [0x15a05e6] xtrabackup(dict_load_tables_from_space_id(unsigned int, THD*, trx_t*)+0x130) [0xec88e0] xtrabackup() [0xecaba5] xtrabackup() [0xecfcaf] xtrabackup(main+0x131b) [0xe76ceb] /usr/lib64/libc.so.6(__libc_start_main+0xe7) [0x7f4c52227c87] xtrabackup(_start+0x2a) [0xead66a] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0): Connection ID (thread ID): 0 Status: NOT_KILLED

if we use make use-memory more larger, we will succeed to prepare.

it’s in our release environment, in the database there are hundreds of thousands of tables.

Environment

None

is duplicated by

Activity

Li Biao April 7, 2024 at 2:16 AM

hi, thanks all. the latest version fixed this issue.

Satya Bodapati April 2, 2024 at 10:31 AM

Thats because cgroup is enforcing the memory limits. If not, OOM Killer will typically enforce the memory limits and kill the processes

Li Biao April 2, 2024 at 8:31 AM

hi, thanks. I have looked pxb 2955. It’s very nice. I will try it.

there is a cgroup in our release env. and I found if we close the cgroup, we won’t get the coredump. So I also suspect that the issue maybe is dupicated of pxb 2955.

but, I’m not clear why xtrabackup is aborted by cgroup. it’s strange.

Aaditya Dubey April 2, 2024 at 7:07 AM

Hi

Please check with the latest PXB and see if it fixes the issue.

Li Biao April 2, 2024 at 3:52 AM

the pxb’s version is 8.0.32

Done

Details

Assignee

Reporter

Needs QA

Yes

Fix versions

Affects versions

Priority

Smart Checklist

Created March 30, 2024 at 11:04 PM
Updated April 8, 2024 at 6:22 AM
Resolved April 8, 2024 at 6:21 AM

Flag notifications