Re: [Mysqlfs-general] mysqlfs patch

[Andrew R. <ros...@gm...>]

On 22/08/07, Stef Bon <st...@bo...> wrote:
> On Wednesday 22 August 2007 04:58:02 Michal Ludvig wrote:
> > Andrew Rose wrote:
> > > On 21/08/07, Michal Ludvig <mi...@lo...> wrote:
>
> >
> > I still wonder what scenario leads to the duplicate keys and subsequent
> > replication failure. Do you write to the same mysqlfs on both hosts?
> > Even if you create a file on "db1" and another file on "db2" they should
> > have assigned different inode numbers. Perhaps if you write to a single
> > file on both DBs it the INSERT on line 558 of query.c may fail. Hmm...
> > Try changing it to REPLACE, ie "REPLACE INTO data_blocks ...". But I'm
> > afraid you may end up with a data corruption if blindly replacing blocks
> > like this. But your original solution that simply didn't do the write on
> > detected conflict wasn't much more corruption proof either. In both
> > cases you'd lose a write that you expected to go through.
> >
> > I personally wouldn't run it in master-master setup, it's a bit
> > complicated to synchronize them, not a simple "one-liner" solution.
> >
> > Michal
> >
> >
> I would like to reply to you. I 'm not a programmer, but as far as I can see
> multithreading is also important. I wanted to use mysqlfs as a backup, but failed beacuse of the
> lack of multithreading.

Correct me if I'm wrong but I was under the impression FUSE handled
the threading.  All that mysqlfs needs to do is maintain the mysql
connections (the pool) and keep them thread safe.  The locking (inode
and data_blocks) as far as I can picture it should be done on the
database level.

Does anyone have any information on how FUSE handles inode creation?
The problem with multi-master inode clashing as far as I can see it is
when two servers (or more) create a file and pick the same inode (for
a file that they regard as local) that the clash occurs.

Andrew