That’s actually problem – I can’t be sure in both patches. Both requires intensive production testing. That’s why we made our own – we know how it supposed to work (more or less), and actually is shorter But I believe we will consider it again and again.

I don’t believe that my patch does have a problem with innobackup. It preserves the order of binlog and innodb commits, although it doesn’t preserve the order of innodb prepare and binlog. This isn’t a problem for crash recovery, since mysql scans the binlog and commits any pending prepares in the same order as commits in the binlog file. Any prepare that doesn’t have a corresponding commit in the binlog file is rolled back.

Innobase has been annoyingly silent on whether innobackup cares about prepare/binlog ordering, but it seems unlikely. It would seem like a bug to me if innobackup treated prepares differently than mysql does itself during crash recovery.

Yes, I saw your patch. We reviewed it but we actually can’t say if it is better or worse than our solution. As I understand your patch has the same danger for innobackup as our.

Why not fix concurrent commit for real? I submitted a patch with a real fix for this back in August 2008. You can see it at http://bugs.mysql.com/file.php?id=10008 and read about it at http://blogs.sun.com/dlutz/entry/toward_a_more_scalable_mysql

thanks for the nice article. I have question for you, thats not related to this post. I am making an album script that I want it to have a feature where users can set different order of their photos and subalbums per album. Should I do it with two tables:
album(id,name,path,col2,col3,col4,col5) and albumorder(id,photoorder,albumorder) or one table album(id,name,photoorder,albumorder,col2,col3,col4,col5)?

Because I don’t see how this could ever cause slave desynchronization, even theoretically. As far as I understand it *only* affect innodb hot backup.

The possibility here is theoretical. We had done some stress test running many transactions which should break replication if they are replied in the wrong order… and things just work fine.

It is just we’re not quite sure it will work in 100% cases.