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
