Bug 1044645 - Dist-geo-rep : checkpoint doesn't reach even though all the files have been synced through hybrid crawl.
Dist-geo-rep : checkpoint doesn't reach even though all the files have been s...
Status: CLOSED EOL
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: geo-replication (Show other bugs)
2.1
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Aravinda VK
Rahul Hinduja
checkpoint
: ZStream
Depends On: 1064309
Blocks: 1202842 1223636 1247536 1279306 1285196
  Show dependency treegraph
 
Reported: 2013-12-18 13:25 EST by Vijaykumar Koppad
Modified: 2015-11-25 03:52 EST (History)
7 users (show)

See Also:
Fixed In Version: glusterfs-3.7.0-2.el6rhs
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1247536 1285196 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vijaykumar Koppad 2013-12-18 13:25:43 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-3.4.0.51geo-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. 
2.stop geo-rep 
3.create some data on master.
4.set the checkpoint.
5.start geo-rep 
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. 


Additional info:
Comment 1 Vijaykumar Koppad 2013-12-18 13:29:53 EST
And this happens only with hybrid crawl.
Comment 3 Vijaykumar Koppad 2013-12-19 04:07:21 EST
Consistently reproducible.
Comment 4 Aravinda VK 2013-12-20 03:05:42 EST
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.
Comment 5 Venky Shankar 2013-12-20 03:41:07 EST
Vijaykumar,

was I/O done on the mount after checkpoint was set? If yes, then isn't this the expected behaviour?
Comment 9 Rahul Hinduja 2015-07-07 06:58:30 EDT
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.
Comment 15 Aravinda VK 2015-11-25 03:51:07 EST
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.
Comment 16 Aravinda VK 2015-11-25 03:52:15 EST
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.

Note You need to log in before you can comment on or make changes to this bug.