Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
5.5.25-galera
-
None
-
None
Description
Any basic scenario which involves concurrent modification of table structure or contents on two nodes, renders the 'victim' connection (the one where the transaction is rolled back) non-functional.
The problem was introduced with revno 3352 (works okay on revno 3351, breaks on 3352).
Please see the following example:
|
|
# Execute on the 1st node |
|
|
drop table if exists t1; |
create table t1 (i int primary key) engine=InnoDB; |
insert into t1 values (1),(2); |
begin; |
update t1 set i=i+2; |
|
|
# Execute on the 2nd node |
|
|
begin; |
update t1 set i=i+4; |
commit; |
|
|
# Execute on the 1st node |
|
|
commit; |
|
|
# ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction |
|
|
# This ^^ deadlock is expected. The following aren't: |
|
|
show status;
|
# ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction |
|
|
select 1; |
# ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction |
|
|
rollback; |
# ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction |
|
|
commit; |
# ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction |
etc. I haven't found a cure except for closing the client session and opening a new one.
My server command line:
mysqld --no-defaults --datadir=data2 --wsrep_provider=galera-23.2.1-src/libgalera_smm.so --wsrep_sst_method=rsync --core --binlog-format=row --default-storage-engine=InnoDB --innodb_autoinc_lock_mode=2 --innodb_locks_unsafe_for_binlog=1 --innodb_flush_log_at_trx_commit=0 --log-error=log.err --basedir=maria-5.5-galera/ --port=8307 --loose-lc-messages-dir=maria-5.5-galera/sql/share --socket=/tmp/galera-2.sock --tmpdir=maria-5.5-galera/data2/tmp --general-log=1 --wsrep_cluster_address=gcomm://127.0.0.1:4567?gmcast.listen_addr=tcp://127.0.0.1:4566 --core
|
Attachments
Issue Links
- blocks
-
-
- Closed
-