From: Andrew R. <ros...@gm...> - 2007-08-21 14:05:02
|
On 21/08/07, Michal Ludvig <mi...@lo...> wrote: > Hi Andrew, > > > I've recently created a patch for mysqlfs. The idea of the patch is > > to check for the existence of an entry by key in the data_blocks table > > before attempting to write (query_write_one_block). The reason? to > > stop mysqlfs killing MySQL replication when attempting to insert an > > data_block with the same inode/seq as one that already exists. > > Interesting. What version of MySQL are you running on both master and > slave? Replication should never break when you attempt to insert a > record with a primary key that already exists. In fact *any* user action > or query should never break MySQL replication. If it does in your case > and if it's reproducible I'd consider it a MySQL server bug worth filing > a bugreport. > I am currently running a chained master->master setup. It is a common MySQL replication problem with master->master setups, and crops up when the PK's are not auto incrementing. > > Now I'm not that familiar with the mysqlfs code, and was hoping > > someone with more knowledge than myself could let me know if I've gone > > in the right direction. > > > > http://dev.iris.ac/~ody/mysqlfs-x86_64/mysqlfs-0.4.0-rc1.patch > > Problem is that your query_inode_key_exists() and the subsequent insert > are two independent transactions. I.e. even if your check returns false > the inode can appear in another thread before the first thread decides > to run the INSERT. You'd have to make it atomic to be safe, which in > case of MYISAM tables means locking the whole table and therefore > resulting to a worse performance. I figured there would be a problem with threading. Have you thought about maybe providing some shared memory locking functionality? ;) Many thanks for the help. For now I think I'll keep my fingers crossed and hope that what I have done has lowered the odds enough that I will rarely, if ever, see a problem, considering there is minimal writes going on to my mounted filesystems anyway. cheers Andrew |