On Mon, May 1, 2017 at 2:55 PM, Pranith Kumar Karampuri <pkarampu@xxxxxxxxxx> wrote:
On Tue, May 2, 2017 at 12:20 AM, Gandalf Corvotempesta <gandalf.corvotempesta@gmail.com > wrote:2017-05-01 20:43 GMT+02:00 Shyam <srangana@xxxxxxxxxx>:
> I do agree that for the duration a brick is replaced its replication count
> is down by 1, is that your concern? In which case I do note that without (a)
> above, availability is at risk during the operation. Which needs other
> strategies/changes to ensure tolerance to errors/faults.
Oh, yes, i've forgot this too.
I don't know Ceph, but Lizard, when moving chunks across the cluster,
does a copy, not a movement
During the whole operation you'll end with some files/chunks
replicated more than the requirement.Replace-brick as a command is implemented with the goal of replacing a disk that went bad. So the availability was already less. In 2013-2014 I proposed that we do it by adding brick to just the replica set and increase its replica-count just for that set once heal is complete we could remove this brick. But at the point I didn't see any benefit to that approach, because availability was already down by 1. But with all of this discussion it seems like a good time to revive this idea. I saw that Shyam suggested the same in the PR he mentioned before.
The ability to increase and decrease the replication count within a replica set would be pretty cool. In addition to replace-brick, workloads that need elasticity to serve reads can benefit from more replicas to provide load balancing. Once the load is back to normal, we can cull the temporary brick.
We might also want to start thinking about spare bricks that can be brought into a volume based on some policy. For example, if the posix health checker determines that underlying storage stack has problems, we can bring a spare brick into the volume to replace the failing brick. More policies can be evolved for triggering the action of bringing in a spare brick to a volume.
-Vijay
-Vijay
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-users
