On 10 December 2013 08:09, Joe Julian <joe@xxxxxxxxxxxxxxxx> wrote: > Replicas are defined in the order bricks are listed in the volume create > command. So > gluster volume create myvol replica 2 server1:/data/brick1 > server2:/data/brick1 server3:/data/brick1 server4:/data/brick1 > will replicate between server1 and server2 and replicate between server3 and > server4. > > Bricks added to a replica 2 volume after it's been created will require > pairs of bricks, > > The best way to "force" replication to happen on another server is to just > define it that way. Yup, that's understood. The problem is when (for argument's sake) : * We've defined 4 hosts with 10 disks each * Each individual disk is a brick * Replication is defined correctly when creating the volume initially * I'm on holidays, my employer buys a single node, configures it brick-per-disk, and the IT junior adds it to the cluster All good up until that final point, and then I've got that fifth node at the end replicating to itself. Node goes down some months later, chaos ensues. Not a GlusterFS/technology problem, but a problem with what frequently happens at a human level. As a sysadmin, these are also things I need to work around, even if it means deviating from best practices. :) -Dan _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users