Red Hat Bugzilla – Bug 1044645
Dist-geo-rep : checkpoint doesn't reach even though all the files have been synced through hybrid crawl.
Last modified: 2015-11-25 03:52:15 EST
Description of problem: geo-rep status checkpoint doesn't reach even though all the files have been synced through hybrid crawl.
Version-Release number of selected component (if applicable):glusterfs-188.8.131.52geo-1
How reproducible: didn't try to reproduce, but seems like consistently reproducible.
Steps to Reproduce:
1.create and start a geo-rep relationship between master and slave.
3.create some data on master.
4.set the checkpoint.
6. wait for the geo-rep to sync data.
7. check geo-rep status whether checkpoint has reached or not.
Actual results: checkpoint doesn't reach at all.
Expected results: checkpoint should reach when all the files are synced.
And this happens only with hybrid crawl.
During start of hybrid crawl, crawler stores masters xtime in memory. After completion of crawl and sync, it will update the same xtime for slave.
If files created after crawler started, then checkpoint time will be more than the last saved xtime in memory, so even after completion it shows checkpoint is not reached.
This is expected behavior, if we update the latest xtime instead of xtime stored in memory, their are chances of data loss.
was I/O done on the mount after checkpoint was set? If yes, then isn't this the expected behaviour?
Verified with build: glusterfs-3.7.1-7.el6rhs.x86_64
Tried both the below scenarios:
a. Have the files before creation of geo-rep session so as to use HYBRID CRAWL
b. Change the change_detector to xsync to use HYBRID CRAWL
In both the above cases, the last sync is not update. In the first case, Last sync is N/A and in the second case, last sync shows when the last changelog was synced.
Eventually in Hybrid Crawl, the checkpoint completed Remains always as NO even when the files are synced to slave. Moving this bug to Assigned state.
Closing this bug since RHGS 2.1 release reached EOL. Required bugs are cloned to RHGS 3.1. Please re-open this issue if found again.