<div dir="ltr">Hi Strahil,<div><br></div><div>We have 4 main servers, and I wanted to run gluster on all of them, with everything working even if 3/4 are down, so I set up a replica 4 with quorum at 1. It&#39;s been working well for several years now, and I can lose 3 out of 4 servers to outages and remain up.</div><div><br></div><div>Amar, so to clarify, right now I set up the volume using &quot;gluster v create $GLUSTER_VOL replica 4 server1:brick1 server2:brick2 server3:brick3 server4:brick4&quot;.</div><div>In order to turn it into a replica 4 but distributed across 4 old bricks and 4 new bricks (say server1:brick5 server2:brick6 server3:brick7 server4:brick8), what exact commands do I need to issue? </div><div><br></div><div>The docs are a bit confusing for this case IMO:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">volume add-brick &lt;VOLNAME&gt; [&lt;stripe|replica&gt; &lt;COUNT&gt; [arbiter &lt;COUNT&gt;]] &lt;NEW-BRICK&gt; ... [force] - add brick to volume &lt;VOLNAME&gt;</blockquote><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Do I need to specify a stripe? Do I need to repeat the replica param and keep it at 4? I.e.:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">gluster v add-brick $GLUSTER_VOL replicate 4 server1:brick5<br>gluster v add-brick $GLUSTER_VOL replicate 4 server2:brick6<br>

gluster v add-brick $GLUSTER_VOL replicate 4 server3:brick7<br>gluster v add-brick $GLUSTER_VOL replicate 4 server4:brick8<br>gluster v rebalance $GLUSTER_VOL fix-layout start</blockquote><div dir="ltr"><br></div><div>My reservations about going with this new approach also include the fact that right now I can back up and restore just the brick data itself as each brick contains the full copy of the data, and it&#39;s a loooot faster to access the brick data during backups (probably an order of magnitude due to unresolved list issues). If I go distributed replicated, my current backup strategy will need to shift to backing up the gluster volume itself (not sure what kind of additional load that would put on the servers), or maybe backing up one brick from each replica would work too, though it&#39;s unclear if I&#39;d be able to restore by just copying the data from such backups back into one restore location to recreate the full set of data (would that work?).</div><div><br></div><div>Thanks again for your answers.</div><div dir="ltr"><br></div><div dir="ltr">Sincerely,<br>Artem<br><br>--<br>Founder, <a href="http://www.androidpolice.com" target="_blank">Android Police</a>, <a href="http://www.apkmirror.com/" style="font-size:12.8px" target="_blank">APK Mirror</a><span style="font-size:12.8px">, Illogical Robot LLC</span></div><div dir="ltr"><a href="http://beerpla.net/" target="_blank">beerpla.net</a> | <a href="http://twitter.com/ArtemR" target="_blank">@ArtemR<br></a><br></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 17, 2020 at 3:29 PM Strahil Nikolov &lt;<a href="mailto:hunter86_bg@yahoo.com">hunter86_bg@yahoo.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On February 18, 2020 1:16:19 AM GMT+02:00, Artem Russakovskii &lt;<a href="mailto:archon810@gmail.com" target="_blank">archon810@gmail.com</a>&gt; wrote:<br>
&gt;Hi all,<br>
&gt;<br>
&gt;We currently have an 8TB 4-brick replicated volume on our 4 servers,<br>
&gt;and<br>
&gt;are at 80% capacity. The max disk size on our host is 10TB. I&#39;m<br>
&gt;starting to<br>
&gt;think about what happens closer to 100% and see 2 options.<br>
&gt;<br>
&gt;Either we go with another new 4-brick replicated volume and start<br>
&gt;dealing<br>
&gt;with symlinks in our webapp to make sure it knows which volumes the<br>
&gt;data is<br>
&gt;on, which is a bit of a pain (but not too much) on the sysops side of<br>
&gt;things. Right now the whole volume mount is symlinked to a single<br>
&gt;location<br>
&gt;in the webapps (an uploads/ directory) and life is good. After such a<br>
&gt;split, I&#39;d have to split uploads into yeardir symlinks, make sure<br>
&gt;future<br>
&gt;yeardir symlinks are created ahead of time and point to the right<br>
&gt;volume,<br>
&gt;etc).<br>
&gt;<br>
&gt;The other direction would be converting the replicated volume to a<br>
&gt;distributed replicated one<br>
&gt;<a href="https://docs.gluster.org/en/latest/Administrator%20Guide/Setting%20Up%20Volumes/#creating-distributed-replicated-volumes" rel="noreferrer" target="_blank">https://docs.gluster.org/en/latest/Administrator%20Guide/Setting%20Up%20Volumes/#creating-distributed-replicated-volumes</a>,<br>
&gt;but I&#39;m a bit scared to do it with production data (even after testing,<br>
&gt;of<br>
&gt;course), and having never dealt with a distributed replicated volume.<br>
&gt;<br>
&gt;1. Is it possible to convert our existing volume on the fly by adding 4<br>
&gt;   bricks but keeping the replica count at 4?<br>
&gt;2. What happens if bricks 5-8 which contain the replicated volume #2 go<br>
&gt;down for whatever reason or can&#39;t meet their quorum, but the replicated<br>
&gt;   volume #1 is still up? Does the whole main combined volume become<br>
&gt;unavailable or only a portion of it which has data residing on<br>
&gt;replicated<br>
&gt;   volume #2?<br>
&gt;   3. Any other gotchas?<br>
&gt;<br>
&gt;Thank you very much in advance.<br>
&gt;<br>
&gt;Sincerely,<br>
&gt;Artem<br>
&gt;<br>
&gt;--<br>
&gt;Founder, Android Police &lt;<a href="http://www.androidpolice.com" rel="noreferrer" target="_blank">http://www.androidpolice.com</a>&gt;, APK Mirror<br>
&gt;&lt;<a href="http://www.apkmirror.com/" rel="noreferrer" target="_blank">http://www.apkmirror.com/</a>&gt;, Illogical Robot LLC<br>
&gt;<a href="http://beerpla.net" rel="noreferrer" target="_blank">beerpla.net</a> | @ArtemR<br>
&gt;&lt;<a href="http://twitter.com/ArtemR" rel="noreferrer" target="_blank">http://twitter.com/ArtemR</a>&gt;<br>
<br>
Distributed replicated sounds more reasonable.<br>
<br>
Out of curiocity, why did you decide to have an even number of bricks in the replica - it can still suffer from split-brain?<br>
<br>
1.  It should be OK, but I have never done it. Test on some VMs before proceeding.<br>
Rebalance might take some time, so keep that in mind.<br>
<br>
2.All files on replica 5-8 will be unavailable untill yoiu recover that set of bricks.<br>
<br>
Best Regards,<br>
Strahil Nikolov<br>
<br>
</blockquote></div>