[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