Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.4.6
-
None
Description
The following conflict happens on MariaDB 10.4.6 (schema details removed/anonymized:
2019-07-30 0:33:47 42 [Note] WSREP: MDL BF-BF conflict
|
schema: db
|
request: (42 seqno 2086357067 wsrep (toi, exec, committed) cmd 0 102 DROP TRIGGER IF EXISTS aud_tr_t)
|
granted: (37 seqno 2086357068 wsrep (high priority, exec, executing) cmd 0 161 INSERT INTO t ... SELECT ... FROM t1, t2 WHERE ... ON DUPLICATE KEY
|
UPDATE c1 = VALUES(...)
|
2019-07-30 0:33:47 42 [ERROR] Aborting
|
 |
2019-07-30 0:34:07 0 [Warning] WSREP: 0x55859a56dea8 down context(s) not set
|
2019-07-30 0:34:07 0 [Warning] WSREP: Failed to send state UUID: -107 (Transport endpoint is not connected)
|
On node1 we see in the processlist (eventually threads were killed):
...
|
1320412 jobs ...:7678 db Killed 3959 wsrep replaying trx DELETE FROM audit_change WHERE id = 459275 0.000
|
1324781 jobs ...l:18998 db Killed 3959 wsrep replaying trx INSERT INTO t ... SELECT ... FROM t1, t2 WHERE ... ON DUPLICATE KEY UPDATE c1 = VALUES(...) 0.000
|
1324822 jobs ...:19118 db Killed 3959 Commit_implicit DROP TRIGGER IF EXISTS aud_tr_t 0.000
|
...
|
Trigger works with that audit_change table.
On node2 we see:
...
|
27 system user NULL Sleep 4004 wsrep applier committed NULL 0.000
|
28 system user NULL Sleep 4004 After apply log event NULL 0.000
|
29 system user edoc_live_md Sleep 4004 Commit_implicit DROP TRIGGER IF EXISTS aud_tr_t 0.000
|
30 system user NULL Sleep 4004 wsrep applier committed NULL 0.000
|
31 system user NULL Sleep 4004 wsrep applier committed NULL 0.000
|
32 system user NULL Sleep 4004 After apply log event NULL 0.000
|
35 system user NULL Sleep 4004 wsrep applier committed NULL 0.000
|
33 system user NULL Sleep 4004 wsrep applier committed NULL 0.000
|
36 system user NULL Sleep 4004 committing NULL 0.000
|
37 system user NULL Sleep 4004 wsrep applier committed NULL 0.000
|
38 system user NULL Sleep 4004 wsrep applier committed NULL 0.000
|
39 system user NULL Sleep 4004 wsrep applier committed NULL 0.000
|
40 system user NULL Sleep 4004 wsrep applier committed NULL 0.000
|
41 system user NULL Sleep 4004 wsrep applier committed NULL 0.000
|
42 system user NULL Sleep 4004 wsrep applier committed NULL 0.000
|
43 system user NULL Sleep 4004 wsrep applier committed NULL 0.000
|
44 system user NULL Sleep 4004 After apply log event NULL 0.000
|
45 system user NULL Sleep 4004 wsrep applier committed NULL 0.000
|
46 system user NULL Sleep 4004 wsrep applier committed NULL 0.000
|
47 system user NULL Sleep 4004 Opening tables INSERT INTO t ... SELECT ... FROM t1, t2 WHERE ... ON DUPLICATE KEY UPDATE c1 = VALUES(...) 0.000
|
49 system user NULL Sleep 4004 wsrep applier committed NULL 0.000
|
...
|
We have:
wsrep_slave_threads = 64
|
wsrep_retry_autocommit = 50
|
wsrep_provider_options = "gcache.size=10G; gmcast.segment=2; evs.send_window=256; evs.user_send_window=64;gcs.fc_limit=512;gcs.fc_factor=0.9;evs.keepalive_period=PT3S; evs.suspect_timeout=PT15S; evs.inactive_timeout=PT30S; evs.install_timeout=PT30S; evs.inactive_check_period=PT5S; evs.join_retrans_period=PT2S"
|
I'd expect metadata locks to be set on applier node and prevent attempt to execute DROP TRIGGER in parallel, further fail and retries etc. IMHO it is a bug.