Bug 830497 - [FEAT] geo-replication failover/failback
[FEAT] geo-replication failover/failback
Status: CLOSED NEXTRELEASE
Product: GlusterFS
Classification: Community
Component: geo-replication (Show other bugs)
mainline
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Csaba Henk
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-10 04:21 EDT by Csaba Henk
Modified: 2013-03-19 03:03 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Feature: If geo-replication master goes defunct, applications running on it should be possible to migrate over ("failover") to slave. When master comes back, in case of a data loss (either local data corruption or getting to a stale state due to not being updated in the outage window) it should be possible to migrate (approximate) slave state and applications back to master ("failback"). Reason: Because customers need it oh so bad. Result (if any): It works, but not automated. A skilled administrator is needed to stage and supervise the fo/fb process, and occasionally, make decisions about best approach.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-19 03:03:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Csaba Henk 2012-06-10 04:21:02 EDT
Description of problem:

If M has a geo-rep replica S, and M becomes inaccessible/unreliable/corrupt,
it should be possible to restore it to an operational state from S in a controlled way (failback), while, at the same time, downtime should be minimized by migrating applications over to S (failover).
Comment 1 Amar Tumballi 2013-03-15 06:51:43 EDT
I guess this feature is already present in codebase. Can you please add 'Doc Text' to this bug and close it?
Comment 2 Csaba Henk 2013-03-19 03:03:41 EDT
Feature is implemented by http://review.gluster.com/3541.

Feature also relies on checkpointing, cf. 
https://bugzilla.redhat.com/show_bug.cgi?id=826512

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