[Gluster-devel] Gluster Sharding and Geo-replication

Aravinda avishwan at redhat.com
Tue Aug 11 11:06:36 UTC 2015


Hi,

We are thinking different approaches to add support in Geo-replication 
for Sharded Gluster Volumes[1]

*Approach 1: Geo-rep: Sync Full file*
    - In Changelog only record main file details in the same brick where 
it is created
    - Record as DATA in Changelog whenever any addition/changes to the 
sharded file
    - Geo-rep rsync will do checksum as a full file from mount and syncs 
as new file
    - Slave side sharding is managed by Slave Volume
*Approach 2: Geo-rep: Sync sharded file separately*
    - Geo-rep rsync will do checksum for sharded files only
    - Geo-rep syncs each sharded files independently as new files
    - [UNKNOWN] Sync internal xattrs(file size and block count) in the 
main sharded file to Slave Volume to maintain the same state as in Master.
    - Sharding translator to allow file creation under .shards dir for 
gsyncd. that is Parent GFID is .shards directory
    - If sharded files are modified during Geo-rep run may end up stale 
data in Slave.
    - Files on Slave Volume may not be readable unless all sharded files 
sync to Slave(Each bricks in Master independently sync files to slave)

First approach looks more clean, but we have to analize the Rsync 
checksum performance on big files(Sharded in backend, accessed as one 
big file from rsync)

Let us know your thoughts. Thanks

Ref:
[1] 
http://www.gluster.org/community/documentation/index.php/Features/sharding-xlator

-- 
regards
Aravinda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150811/8a57ab76/attachment.html>


More information about the Gluster-devel mailing list