Re: Abusing georeplication for read-only replication?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 4, 2014 at 2:12 AM, Danny Sauer <danny@xxxxxxxxxxxxxx> wrote:
> I've tried using the fuse mount on the read-only systems, which gives predictably atrocious performance over a high - latency link. The NFS client is a little better, but I'd prefer some fall over capability. I was originally thinking about using an inotify-based rsync job, but then I thought that Gluster might be able to do this for me easier. What if I set the ro systems to be geo-replicated peers, and just used their local brick directly as my "read-only" volume? Assuming my application is smart enough to not write to the brick & doesn't care about any metadata, and my volume is a straight replica with no striping, is there any real problem with this that I'm overlooking? That would get rid of the slow network stat(), and just have a minimal delay in replication while remaining fault-tolerant, right?


If you're only interested in a delayed read-only copy of the data,
then yes, geo-replication could work.
You'd have to test to see if you're happy with the setup... Also, your
receiving RO end needs to be big enough to accommodate the amount of
storage you'll be pushing there...
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-users




[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux