aurora 2.10.1 crashed and reboot with 'mysqld got signal 6'

0

aurora 2.10.1 crashed every night, makes a failover and rebooted after a few seconds.

terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 4294967295) >= this->size() (which is 0)
00:02:12 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=189
max_threads=3000
thread_count=33
connection_count=33
connection_count=28
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 13123173 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
aurora backtrace compare flag : 1
Writing a core file
2022-02-01T00:02:42.648128Z 0 [Warning] The syntax '--secure-auth' is deprecated and will be removed in a future release
2022-02-01T00:02:42.648345Z 0 [Warning] 'NO_AUTO_CREATE_USER' sql mode was not set.
2022-02-01T00:02:42.649173Z 0 [Note] /rdsdbbin/oscar/bin/mysqld (mysqld 5.7.12) starting as process 12965 ...
2022-02-01T00:02:42.662116Z 0 [Warning] InnoDB: Setting innodb_checksums to OFF is DEPRECATED. This option may be removed in future releases. You should set innodb_checksum_algorithm=NONE instead.
2022-02-01T00:02:42.662195Z 0 [Note] InnoDB: Started in read only mode
2022-02-01T00:02:42.662212Z 0 [Note] InnoDB: PUNCH HOLE support available
2022-02-01T00:02:42.662216Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-02-01T00:02:42.662219Z 0 [Note] InnoDB: Uses event mutexes
2022-02-01T00:02:42.662222Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2022-02-01T00:02:42.662225Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-02-01 00:02:42 0x400039a33160[IB_LOG_LEVEL_INFO]:Initializing buffer pool, size = 43.0G (srv0start.cc:4406)
2022-02-01T00:02:42.662286Z 0 [Note] InnoDB: == Add SYNC_FAST DDL...
2022-02-01T00:02:42.663027Z 0 [Note] InnoDB: Number of pools: 1
2022-02-01T00:02:42.663127Z 0 [Note] InnoDB: Not using CPU crc32 instructions
2022-02-01T00:02:42.663132Z 0 [Note] InnoDB: Disabling background log and ibuf IO write threads.
2022-02-01T00:02:42.663936Z 0 [Note] InnoDB: Initializing buffer pool, total size = 42.9512G, instances = 8, chunk size = 5.3689G
asked 2 years ago799 views
1 Answer
0

Hi there, I'm sorry that your Aurora cluster crashed.

From the logs you posted, your cluster hit Community MySQL Bug #24585978, which was fixed in Aurora MySQL release 2.10.2.

See the 2.10.2 release notes:

Integration of MySQL Community Edition bug fixes

Fixed an issue in InnoDB where an error in code related to table statistics raised an assertion in the dict0stats.cc source file. (Bug #24585978)

We recommend that you patch your cluster up to 2.10.2 or higher to avoid future crashes.

AWS
answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions