regards
Aravinda
On 03/09/2016 06:22 PM, Shyam wrote:
On 03/09/2016 12:45 AM, Aravinda wrote:
regards
Aravinda
On 03/08/2016 11:34 PM, Atin Mukherjee wrote:
On 03/07/2016 05:13 PM, Kotresh Hiremath Ravishankar wrote:
Added gluster-users.
Thanks and Regards,
Kotresh H R
----- Original Message -----
From: "Kotresh Hiremath Ravishankar" <khiremat@xxxxxxxxxx>
To: "Gluster Devel" <gluster-devel@xxxxxxxxxxx>
Sent: Monday, March 7, 2016 3:03:08 PM
Subject: Using geo-replication as backup solution
using gluster volume snapshot!
Hi All,
Here is the idea, we can use geo-replication as backup solution
using gluster
volume
snapshots on slave side. One of the drawbacks of geo-replication is
that it's
a
continuous asynchronous replication and would not help in getting
the last
week's or
yesterday's data. So if we use gluster snapshots at the slave end,
we can use
the
snapshots to get the last week's or yesterday's data making it a
candidate
for a
backup solution. The limitation is that the snapshots at the slave
end can't
be
restored as it will break the running geo-replication. It could be
mounted
and
we have access to data when the snapshots are taken. It's just a
naive idea.
Any suggestions and use cases are worth discussing:)
When you mention that gluster snapshot can be taken at the slave end
how
does it guarantee that the data is available till yesterday or next
week
considering the asynchronous nature of the replication strategy? (I've
very limited knowledge on geo replication, so I may sound stupid!)
Check my response in the same thread. Geo-rep now has a scheduler
script, which can be used to run Geo-replication whenever required.
It does the following to make sure everything is synced to Slave.
1. Stop Geo-replication if Started
2. Start Geo-replication
3. Set Checkpoint
4. Check the Status and see Checkpoint is Complete.(LOOP)
5. If checkpoint complete, Stop Geo-replication
Will this stop at the moment checkpoint is complete, or is there a
chance that geo-rep would continue with the next change log, but be
interrupted by this script.
Checkpoint here is just a stop notification for Scheduler script.
Geo-rep may sync some files which are created/modified after the
checkpoint time. But it makes sure that everything created/modified
before checkpoint are in sync.
IOW, we are polling for the checkpoint, which when we detect has
happened, may not mean geo-rep has not processed (or started
processing) the next changelog, would this understanding be right?
It may process next changelogs.
I state/ask this, as we may want to geo-rep upto a checkpoint, which
is a point of snapshot on the master, and not geo-rep beyond this point.
Geo-rep can't provide point of snapshot since data changes are not
recorded in changelogs. File may have modified after it recorded data in
Changelog.
I guess I need to understand checkpoints better, if my understanding
is incorrect.
Checkpoint is kind of indicator that shows all the files
created/modified before the checkpoint time are synced.
Thanks and Regards,
Kotresh H R
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
