[Gluster-users] Increasing replica count from 2 to 3

Ravishankar N ravishankar at redhat.com
Thu Dec 29 05:40:54 UTC 2016


On 12/29/2016 10:46 AM, Jackie Tung wrote:
> Thanks very much for the advice.
>
> Would you mind elaborating on the "no io" recommendation?  It's 
> somewhat hard for me to guarantee this without a long maintenance window.
>
> What is the consequence of having IO at point of add-brick, and for 
> the heal period afterwards?

Sorry I wasn't clear. Since you're running  16 distribute legs (16x2), a 
lot of self-heals would be running and there is a chance that clients 
might experience slowness due to the self-heals. Other than that it 
should be fine.
Thanks,
Ravi

>
>
>
> On Dec 28, 2016 8:27 PM, "Ravishankar N" <ravishankar at redhat.com 
> <mailto:ravishankar at redhat.com>> wrote:
>
>     On 12/29/2016 07:30 AM, Jackie Tung wrote:
>>     Version is 3.8.7 on Ubuntu xenial.
>>
>>     On Dec 28, 2016 5:56 PM, "Jackie Tung" <jackie at drive.ai
>>     <mailto:jackie at drive.ai>> wrote:
>>
>>         If someone has experience to share in this area, i'd be
>>         grateful.  I have an existing distributed replicated volume,
>>         2x16.
>>
>>         We have a third server ready to go.  Redhat docs say just run
>>         add brick replica 3, then run rebalance.
>>
>>         The rebalance step feels a bit off to me.  Isn't some kind of
>>         heal operation in order rather than rebalance?
>>
>>         No additional usable space will be introduced, only replica
>>         count increase from 2 to 3.
>>
>
>     You don't need to run re-balance for increasing the replica count.
>     Heals should automatically be triggered when you run 'gluster vol
>     add-brick <volname> replica 3 <list of bricks for the 3rd
>     replica>`. It is advisable to do this when there is no I/O
>     happening  on the volume. You can verify that files are getting
>     populated in the newly added bricks post running the command.
>
>     -Ravi
>>
>>
>>         Thanks
>>         Jackie
>>
>>
>>     The information in this email is confidential and may be legally
>>     privileged. It is intended solely for the addressee. Access to
>>     this email by anyone else is unauthorized. If you are not the
>>     intended recipient, any disclosure, copying, distribution or any
>>     action taken or omitted to be taken in reliance on it, is
>>     prohibited and may be unlawful.
>>
>>
>>
>>     _______________________________________________
>>     Gluster-users mailing list
>>     Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
>>     http://www.gluster.org/mailman/listinfo/gluster-users
>>     <http://www.gluster.org/mailman/listinfo/gluster-users>
>
> The information in this email is confidential and may be legally 
> privileged. It is intended solely for the addressee. Access to this 
> email by anyone else is unauthorized. If you are not the intended 
> recipient, any disclosure, copying, distribution or any action taken 
> or omitted to be taken in reliance on it, is prohibited and may be 
> unlawful.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20161229/9b5334fc/attachment.html>


More information about the Gluster-users mailing list