Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.4.4
-
Ubuntu 18.04
Description
Using following scenario:
- Started 5 nodes of 10.3
- Did Rolling Upgrade to 10.4
- Run following SQLs one of the nodes:
CREATE SEQUENCE Seq1_1 START WITH 1 INCREMENT BY 1; |
CREATE TABLE Observation (Id int(11) NOT NULL, Place varchar(50) NOT NULL, BirdId int(11) NOT NULL,PRIMARY KEY (Id)); |
INSERT INTO Observation (Id, Place, BirdId) VALUES (NEXT VALUE FOR Seq1_1, 'Helsinki', 10); |
INSERT INTO Observation (Id, Place, BirdId) VALUES (NEXT VALUE FOR Seq1_1, 'Espoo', 10); |
INSERT INTO Observation (Id, Place, BirdId) VALUES (NEXT VALUE FOR Seq1_1, 'Kirkkonummi', 10); |
INSERT INTO Observation (Id, Place, BirdId) VALUES (NEXT VALUE FOR Seq1_1, 'Hanko', 10); |
drop sequence Seq1_1; |
CREATE SEQUENCE Seq1_1 START WITH 1 INCREMENT BY 1; |
INSERT INTO Observation (Id, Place, BirdId) VALUES (NEXT VALUE FOR Seq1_1, 'Helsinki', 10); |
The result of last insert:
`ERROR 2013 (HY000): Lost connection to MySQL server during query`
From error log:
mysqld: /home/shako/Galera_Tests/MariaDB/wsrep-lib/src/transaction.cpp:456: int wsrep::transaction::ordered_commit(): Assertion `state() == s_committing' failed. |
190306 13:21:41 [ERROR] mysqld got signal 6 ; |
stdlib/abort.c:81(__GI_abort)[0x7fc418e8c801] |
assert/assert.c:89(__assert_fail_base)[0x7fc418e7c39a] |
/lib/x86_64-linux-gnu/libc.so.6(+0x30412)[0x7fc418e7c412]
|
/home/shako/Galera_Tests/dbs/maria_10.4/bin/mysqld(_ZN5wsrep11transaction14ordered_commitEv+0x72)[0x555c0ff107ea]
|
src/transaction.cpp:457(wsrep::transaction::ordered_commit())[0x555c0f5ae0ee]
|
wsrep/client_state.hpp:409(wsrep::client_state::ordered_commit())[0x555c0f7c53f5]
|
sql/wsrep_trans_observer.h:291(wsrep_ordered_commit(THD*, bool, wsrep_apply_error const&))[0x555c0f7d9705] |
sql/log.cc:7689(MYSQL_BIN_LOG::write_transaction_to_binlog_events(MYSQL_BIN_LOG::group_commit_entry*))[0x555c0f7d8d2e] |
sql/log.cc:7370(MYSQL_BIN_LOG::write_transaction_to_binlog(THD*, binlog_cache_mngr*, Log_event*, bool, bool, bool))[0x555c0f7c8efa] |
sql/log.cc:1785(binlog_flush_cache(THD*, binlog_cache_mngr*, Log_event*, bool, bool, bool))[0x555c0f7c91fc] |
sql/log.cc:1837(binlog_commit_flush_stmt_cache(THD*, bool, binlog_cache_mngr*))[0x555c0f7c9e7e] |
sql/log.cc:2109(binlog_rollback(handlerton*, THD*, bool))[0x555c0f6b5c51] |
sql/handler.cc:1852(ha_rollback_trans(THD*, bool))[0x555c0f4f8521] |
sql/transaction.cc:573(trans_rollback_stmt(THD*))[0x555c0f378801]
|
sql/sql_parse.cc:6396(mysql_execute_command(THD*))[0x555c0f37d71c]
|
sql/sql_parse.cc:8157(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x555c0f37cd92] |
sql/sql_parse.cc:7980(wsrep_mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x555c0f368982] |
sql/sql_parse.cc:1813(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x555c0f367289] |
sql/sql_parse.cc:1357(do_command(THD*))[0x555c0f4dfa4b]
|
sql/sql_connect.cc:1399(do_handle_one_connection(CONNECT*))[0x555c0f4df7af]
|
nptl/pthread_create.c:463(start_thread)[0x7fc419d876db]
|
x86_64/clone.S:97(clone)[0x7fc418f6d88f]
|
With 10.3 cluster there is no such issue -> reusing sequence resulted with duplicated key error as expected.