[Gluster-users] Reliable Geo-Replication

Tue Jun 23 06:45:48 UTC 2020

Dear Shwetha,

yes, I deleted the previous session including the [reset-sync-time] option.

Actually, the geo-replication is in hybrid crawl and I executed the command

what we discussed yesterday. # setfattr ....

So far, the files are still present on the slave side.

You mentioned that renames and deletes are not going to be considered in 
hybrid crawl,

the command setfattr... is actually not useful, since our 
geo-replication is still in hybrid crawl?

You already asked which issues are we actually faced using geo-replication.

For another volume, here is a snippet of the log-file:

[2020-06-23 06:40:10.280570] E [repce(agent path2brick):121:worker] 
<top>: call failed:
Traceback (most recent call last):
   File "/usr/libexec/glusterfs/python/syncdaemon/repce.py", line 117, 
in worker
     res = getattr(self.obj, rmeth)(*in_data[2:])
   File "/usr/libexec/glusterfs/python/syncdaemon/changelogagent.py", 
line 40, in register
     return Changes.cl_register(cl_brick, cl_dir, cl_log, cl_level, retries)
   File "/usr/libexec/glusterfs/python/syncdaemon/libgfchangelog.py", 
line 46, in cl_register
     cls.raise_changelog_err()
   File "/usr/libexec/glusterfs/python/syncdaemon/libgfchangelog.py", 
line 30, in raise_changelog_err
     raise ChangelogException(errn, os.strerror(errn))
ChangelogException: [Errno 2] No such file or directory
[2020-06-23 06:40:10.281264] E [repce(worker path2brick):213:__call__] 
RepceClient: call failed call=100462:139896734930752:1592894408.19    
method=register error=ChangelogException
[2020-06-23 06:40:10.281446] E [resource(worker 
path2brick):1286:service_loop] GLUSTER: Changelog register failed    
error=[Errno 2] No such file or directory
[2020-06-23 06:40:10.283895] E [repce(agent path2brick):121:worker] 
<top>: call failed:
Traceback (most recent call last):
   File "/usr/libexec/glusterfs/python/syncdaemon/repce.py", line 117, 
in worker
     res = getattr(self.obj, rmeth)(*in_data[2:])
   File "/usr/libexec/glusterfs/python/syncdaemon/changelogagent.py", 
line 40, in register
     return Changes.cl_register(cl_brick, cl_dir, cl_log, cl_level, retries)
   File "/usr/libexec/glusterfs/python/syncdaemon/libgfchangelog.py", 
line 46, in cl_register
     cls.raise_changelog_err()
   File "/usr/libexec/glusterfs/python/syncdaemon/libgfchangelog.py", 
line 30, in raise_changelog_err
     raise ChangelogException(errn, os.strerror(errn))
ChangelogException: [Errno 2] No such file or directory
[2020-06-23 06:40:10.285129] E [repce(worker path2brick):213:__call__] 
RepceClient: call failed call=100465:140153610073920:1592894408.19    
method=register error=ChangelogException

Due to this issue, the geo-replication is going from passive to active 
to faulty to initialise and starts from the beginning, .... (endless 
loop) and no

progress in synchronisation.

Regards,

Felix

On 22/06/2020 13:49, Shwetha Acharya wrote:
> Hi Felix,
>
> Have you deleted the session with reset-sync-time and recreated the 
> session?
>
> If yes, the crawling starts from beginning.
> Which happens in this way:
>
> It begins with hybrid crawl, as data is already in  master before re 
> creating the geo-rep session. If geo-rep session is craeted before 
> creating data on master, hybrid crawl does not occur. *Note*:  renames 
> and deletes will not be synced in hybrid crawl.
>
> Then it gradually changes to history crawl and changelog crawl.
>
> You can wait for sync to complete by setting a checkpoint, need not 
> try # setfattr -n glusterfs.geo-rep.trigger-sync -v "1" <file-path>
> reset-sync-time will take considerable time to finish syncing, as I 
> stated earlier, it is time consuming one.
>
> Modes does not affect # setfattr -n glusterfs.geo-rep.trigger-sync -v 
> "1" <file-path>
>
> Regards,
> Shwetha
>
>
> On Mon, Jun 22, 2020 at 5:01 PM Felix Kölzow <felix.koelzow at gmx.de 
> <mailto:felix.koelzow at gmx.de>> wrote:
>
>     Dear Shwetha,
>
>
>     sorry, one more question, since I try to collect some more
>     information which may helpful for other gluster-users.
>
>     Does the suggested command
>
>     # setfattr -n glusterfs.geo-rep.trigger-sync -v "1" <file-path>
>
>     also work regardless of the current mode, i.e. history, hybrid or
>     changelog crawl?
>
>
>     Regards,
>
>     Felix
>
>     On 22/06/2020 13:11, Shwetha Acharya wrote:
>>     Hi Felix,
>>
>>     File path is the path from mount point. Need not include any
>>     other options.
>>
>>     Regards,|
>>     Shwetha
>>
>>     On Mon, Jun 22, 2020 at 3:15 PM Felix Kölzow
>>     <felix.koelzow at gmx.de <mailto:felix.koelzow at gmx.de>> wrote:
>>
>>         Dear Shwetha,
>>
>>         > One more alternative would be to triggering sync
>>         on indivisual files,
>>         > # setfattr -n glusterfs.geo-rep.trigger-sync -v "1" <file-path>
>>
>>         So, how to do it exactly and what is <file-path>? Is it a
>>         gluster mount
>>         point with certain mount options
>>
>>         or is this the brick path? Furthermore, does it work for
>>         directories?
>>
>>
>>         Regards,
>>
>>         Felix
>>
>>
>>         ________
>>
>>
>>
>>         Community Meeting Calendar:
>>
>>         Schedule -
>>         Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
>>         Bridge: https://bluejeans.com/441850968
>>
>>         Gluster-users mailing list
>>         Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
>>         https://lists.gluster.org/mailman/listinfo/gluster-users
>>
>
> ________
>
>
>
> Community Meeting Calendar:
>
> Schedule -
> Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
> Bridge: https://bluejeans.com/441850968
>
> Gluster-users mailing list
> Gluster-users at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20200623/573651d3/attachment.html>