[MDEV-9386] Commit failed due to failure of an earlier commit on which this one depends Created: 2016-01-09  Updated: 2022-09-08

Status: Open
Project: MariaDB Server
Component/s: Replication
Affects Version/s: 10.0.23, 10.1
Fix Version/s: 10.1

Type: Bug Priority: Major
Reporter: Alex Assignee: Andrei Elkin
Resolution: Unresolved Votes: 1
Labels: parallelslave


 Description   

Hello,
I am using parallel replication and the table on slave initially was myisam.
inserts are either ignored (and if duplicate key found, I am simply ignoring error 1062 in config) or inserted.
I switched to innodb to check the speed improvements and got the error in subject (error num reported 1964)
Then switched again to myisam.

Recently the app logic been changed and we are using INSERT + ON DUPLICATE KEY UPDATE
so no duplicate ignores any longer and it should work fine.
However, switching to innodb resulted in same error again and now switched back to myisam.

Another thing - alter to myisam for a table 30gb with 2 indexes took about 15 minutes, and to innodb (from myisam) around 2 hours. But I guess that's by design.

All other myisam tables that have simple insert without primary key working fine as innodb, without any errors.

masters have insert delayed which is seen on slave, but I guess slave converts this to simple insert in order to keep same order but maybe this can help as well

Thanks,
Alex

 Comments   
Comment by Elena Stepanova [ 2016-01-11 ]

ShivaS,

Please attach your cnf file(s) or, if you already did it in previous reports, point at the one(s) that are applicable to this issue.

Can you describe the flow which causes the duplicate keys in the first place? Are they coming from different masters, or does the slave receive direct updates (inserts) which produce the keys which can be later duplicated by the replication events?

Comment by Alex [ 2016-01-12 ]

Hi Elena,
I've uploaded file MDEV-9386.zip to your private FTP having all the relevant info inside.

The master has blackhole tables (previously it was myisam and we've filtered everything in redis to avoid duplicates). So right now every single query enters master and its binary logs.
Then slave simply ignores duplicates if needed (based on keys). We only needed to know something exists without making it duplicate, that's the whole logic behind it.

Recently we've switched our app queries to become insert + on duplicate key update, because we still wanted a certain field being updated on slave.

So in both situations whenever I tried working with innodb and parallel replication I got the error I've mentioned earlier. Single slave thread works fine with innodb.

Thanks!

Comment by Alex [ 2016-01-30 ]

I checked the behavior with 10.1 and having same problem

Generated at Thu Feb 08 07:34:17 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.