Binlog bug
General
Escalation
General
Escalation
Description
Environment
None
Attachments
1
Smart Checklist
Activity
Show:

George Lorch January 21, 2020 at 8:40 PM
Not enough information to reproduce and upstream bug is now restricted.

Lalit Choudhary September 17, 2019 at 12:36 PM
Hi Kabilesh,
Thank for the report.
This bug is already identified/reported in MySQL upstream.
https://bugs.mysql.com/bug.php?id=86256
The issue still exists in new version of Percoan server as well as in upstream mysql server.
Validated as described with testcase given in mysql#86256
Incomplete
Details
Details
Assignee
Unassigned
UnassignedReporter

Labels
Upstream Bug URL
Priority
Smart Checklist
Open Smart Checklist
Smart Checklist

Open Smart Checklist
Created September 17, 2019 at 7:15 AM
Updated March 6, 2024 at 11:51 AM
Resolved January 21, 2020 at 8:40 PM
hi,
Am running a percona server 5.7.21-21 on debian 9 machine, recently am facing issue issue with my MTS replication, wherein the server getting crashed with the below error.
Logs:
2019-09-05T18:43:21.083183Z 379476 [ERROR] /usr/sbin/mysqld: Binary logging not possible. Message: An error occurred during flush stage of the commit. 'binlog_error_action' is set to 'ABORT_SERVER'. Hence aborting the server.
18:43:21 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.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/
key_buffer_size=33554432
read_buffer_size=524288
max_used_connections=5209
max_threads=15001
thread_count=2287
connection_count=2277
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 11764774 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7fcfb00631d0
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 = 7fcd46f3ae78 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2c)[0x563f13fa394c]
/usr/sbin/mysqld(handle_fatal_signal+0x489)[0x563f138b7f09]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0)[0x7fe8ae7c70e0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7fe8ac42afff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fe8ac42c42a]
/usr/sbin/mysqld(+0xcacf71)[0x563f13f2af71]
/usr/sbin/mysqld(+0xcb41f2)[0x563f13f321f2]
/usr/sbin/mysqld(_ZN13MYSQL_BIN_LOG14ordered_commitEP3THDbb+0x11d)[0x563f13f3bebd]
/usr/sbin/mysqld(_ZN13MYSQL_BIN_LOG6commitEP3THDb+0x838)[0x563f13f3daf8]
/usr/sbin/mysqld(_Z15ha_commit_transP3THDbb+0x2d3)[0x563f1391c9a3]
/usr/sbin/mysqld(_Z12trans_commitP3THD+0x39)[0x563f13e20d99]
/usr/sbin/mysqld(_ZN13Xid_log_event9do_commitEP3THD+0x19)[0x563f13f08c69]
/usr/sbin/mysqld(_ZN19Xid_apply_log_event21do_apply_event_workerEP12Slave_worker+0x10e)[0x563f13f08dde]
/usr/sbin/mysqld(_Z27slave_worker_exec_job_groupP12Slave_workerP14Relay_log_info+0x23a)[0x563f13f75aba]
/usr/sbin/mysqld(handle_slave_worker+0x35b)[0x563f13f5752b]
/usr/sbin/mysqld(pfs_spawn_thread+0x1b4)[0x563f13fbdce4]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x74a4)[0x7fe8ae7bd4a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fe8ac4e0d0f]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): Connection ID (thread ID): 379476
Status: NOT_KILLED
You may download the Percona Server operations manual by visiting
http://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.