Is it definitely a drop-in replacement? (db format is the same, etc.?)
The main csync2 page didn't give me confidence in 2.0, since it has RC next
to it, and I didn't see a changelog. In one of the original messages on
this list about 2.0, you even mention something about inotify and support
for other databases, which also worried me that things were very
different... though the current PDF and man page don't seem very different.
On Tue, Jul 8, 2014 at 6:06 AM, Lars Ellenberg <lars.ellenb...@linbit.com>
wrote:
> On Tue, Jul 08, 2014 at 04:31:46AM -0400, dlo wrote:
> > I've had csync2 (1.34) working fine for a few years now... it took a bit
> of
> > work to figure out its quirks, but it's been really great and reliable.
> > (Thank you, Lars et al!)
>
> Please try 2.0, if you can.
>
> > On one of my machines (rs1), I'm running out of space on the partition
> > containing the synced folder, so I changed the configuration to use
> > prefixes, so that the other server (rs2) continues with its normal path,
> > and the space-limited server is using a new disk. The prefix is the only
> > thing I changed from the previously working configuration.
> >
> > ...
> > > include %FSROOT%/;
> > > ...
> > > prefix FSROOT
> > > {
> > > on rs1: /mnt/cbsvol3/files;
> > > on rs2: /home/myuser/folder/files;
> > > }
> >
> >
> > Not knowing how to update the database to reflect the new path, I
> manually
> > changed the filename values in the file table in sqlite on both servers.
> I
> > was nervous about this, but it seems to have worked ok. For example:
> > INSERT INTO file
> >
> VALUES('/home/myuser/folder/files/trg','v1%3Amode=16872%3Auid=12036132%3Agid=19232%3Atype=dir');
> > became
> > INSERT INTO file
> >
> VALUES('%25FSROOT%25/trg','v1%3Amode=16872%3Auid=12036132%3Agid=19232%3Atype=dir');
> >
> > Good news: When I run a full sync (csync2 -rx), it works absolutely fine.
> >
> > Bad news: However, if I run a sync of a specific file, which is necessary
> > for my use case (with lsyncd, though at this point I'm testing it
> > manually), it appears to mark the file as dirty, but does not actually
> > sync. Using verbose mode seems to indicate that it is not even
> attempting
> > to connect to its peer:
> >
> > rs1% /usr/sbin/csync2 -C test -xvv test3
> > > My hostname is rs1.
> > > Database-File: /var/lib/csync2/rs1_test.db
> > > Config-File: /etc/csync2_test.cfg
> > > Prefix 'FSROOT' is set to '/mnt/cbsvol3/files'.
> > > Match (+): %FSROOT% on %FSROOT%/test3
> > > Running check for /mnt/cbsvol3/files/test3 ...
> > > SQL: SELECT filename from file where filename =
> '/mnt/cbsvol3/files/test3'
> > > ORDER BY filename
> > > SQL Query finished.
> > > Don't check at all: /mnt/cbsvol3/files/test3
> > > Running check for %FSROOT%/test3 ...
> > > SQL: SELECT filename from file where filename = '%25FSROOT%25/test3'
> > > ORDER BY filename
> > > SQL Query finished.
> > > Match (+): %FSROOT% on %FSROOT%/test3
> > > Checking %FSROOT%/test3.
> > > SQL: SELECT checktxt FROM file WHERE filename = '%25FSROOT%25/test3'
> > > SQL Query finished.
> > > SQL: SELECT peername FROM dirty GROUP BY peername ORDER BY random()
> > > SQL Query finished.
> > > SQL: SELECT filename, myname, force FROM dirty WHERE peername = 'rs2'
> > > ORDER by filename ASC
> > > SQL Query finished.
> > > SQL: SELECT command, logfile FROM action GROUP BY command, logfile
> > > SQL Query finished.
> > > Finished with 0 errors.
> >
> >
> > Likewise, if I run with -T on all, the results seem accurate; however,
> if I
> > run -T on the one changed file, it does actually connect to the peer, but
> > doesn't seem to get a sig on the file, and ultimately returns nothing.
> I'm
> > a bit confused about whether maybe the remote host is querying using the
> > local host's prefix path? (and if so, what to do to fix it?):
> >
> > > rs1% /usr/sbin/csync2 -C test -Tvvv test3
> > > My hostname is rs1.
> > > Database-File: /var/lib/csync2/rs1_test.db
> > > Config-File: /etc/csync2_test.cfg
> > > Prefix 'FSROOT' is set to '/mnt/cbsvol3/files'.
> > > Match (+): %FSROOT% on %FSROOT%/test3
> > > Running in-sync check for rs1 <-> rs2.
> > > Connecting to host rs2 (SSL) ...
> > > Local> SSL\n
> > > Peer> OK (activating_ssl).\n
> > > SQL: SELECT certdata FROM x509_cert WHERE peername = 'rs2'
> > > SQL Query finished.
> > > Peer x509 certificate is: [...]
> > > Local> CONFIG test\n
> > > Peer> OK (cmd_finished).\n
> > > Local> HELLO rs1\n
> > > Peer> OK (cmd_finished).\n
> > > Local> LIST rs2 /mnt/cbsvol3/files/test3
> > > Local>
> sF9HeaK6kuFzNfkPgTjL6wcY9akx2_pjjAg1.VOqYHG9AgLjzEG1zfttMlt9WLrp
> > > Local> \n
> > > SQL: SELECT checktxt, filename FROM file WHERE filename = '
> > > /mnt/cbsvol3/files/test3' ORDER BY filename
> > > SQL Query finished.
> > > Peer> OK (cmd_finished).\n
> > > End of query results: OK (cmd_finished).
> > > Local> BYE\n
> > > Peer> OK (cu_later).\n
> > > SQL: SELECT command, logfile FROM action GROUP BY command, logfile
> > > SQL Query finished.
> > > Finished with 0 errors.
> >
> >
> > After many hours, I'm at a loss... do you have any additional ideas for
> me
> > to try? This isn't a bug, is it?
>
> > _______________________________________________
> > Csync2 mailing list
> > Csync2@lists.linbit.com
> > http://lists.linbit.com/mailman/listinfo/csync2
>
>
> --
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
>
> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
> _______________________________________________
> Csync2 mailing list
> Csync2@lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/csync2
>
_______________________________________________
Csync2 mailing list
Csync2@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/csync2
