<div dir="ltr">Thanks. I'm planning to keep the hostname and ip the same. Essentially, I want to overwrite the /boot and / partitions. The document in step 3 seems to describe the general method of replacing the node which would work even if the gluster configuration and the brick on the node is not recoverable. In my case, I'm reasonably sure that both of those are unaffected. Hence, I was interested in knowing if just restoring the gluster configuration from <span style="font-size:12.8000001907349px"> /var/lib/glusterd and /etc/glusterfs on the newly installed OS would work. If this is more dangerous, I can follow steps in the doc you linked. From a cursory examination, the steps in that document seem more complicated. </span></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 30, 2015 at 6:49 AM, Bipin Kunal <span dir="ltr"><<a href="mailto:bkunal@redhat.com" target="_blank">bkunal@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Prasun,<br>
<br>
This email alias is for upstream glusterfs users not for Red Hat Gluster(downstream glusterfs).<br>
So will not be able to help on Red Hat Gluster Storage much in the public forum. You will need to open a ticket with Red Hat support.<br>
<br>
But as a help here is what you need to do :<br>
1) Try to stabilize your current 3.0 installation first.<br>
2) If you want to have one of your node newly installed, I will say you to re-install RHS the same which was installed earlier<br>
and then add this node back into the cluster. I will recommend you to use same Hostname and IP as earlier.<br>
3) You can follow the chapter 8.6.2( Replacing a host machine with the same Hostname" from the document:<br>
<a href="https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3/html/Administration_Guide/sect-Replacing_Hosts.html#Replacing_a_Host_Machine_with_the_Same_Hostname" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3/html/Administration_Guide/sect-Replacing_Hosts.html#Replacing_a_Host_Machine_with_the_Same_Hostname</a><br>
4) Please go through the document before using it. If possible you can try on your test cluster first in order to get confidence and minimize mistake.<br>
5) As you are using distribute-replicate topology you can get your data back from replica brick by executing self heal.<br>
6) If you want to upgrade to 3.1, you can upgrade now.<br>
<span class="im HOEnZb"><br>
Thanks,<br>
Bipin Kunal<br>
<br>
----- Original Message -----<br>
</span><span class="im HOEnZb">From: Prasun Gera <<a href="mailto:prasun.gera@gmail.com">prasun.gera@gmail.com</a>><br>
To: <a href="mailto:gluster-users@gluster.org">gluster-users@gluster.org</a><br>
Sent: Thu, 30 Jul 2015 05:17:46 -0400 (EDT)<br>
Subject: Re: [Gluster-users] Reinstall OS while keeping bricks intact<br>
<br>
</span><span class="im HOEnZb">Also, if there is a cleaner way of doing this by removing and adding the<br>
node again through gluster commands that would be preferable.<br>
<br>
</span><div class="HOEnZb"><div class="h5">On Thu, Jul 30, 2015 at 1:58 AM, Prasun Gera <<a href="mailto:prasun.gera@gmail.com">prasun.gera@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
> One of my nodes in an RHS 3.0 3x2 dist+replicated pool is down and not<br>
> likely to recover. The machine doesn't have IPMI and I have limited access.<br>
> Standard steps to recover it didn't work, and at this point the easiest<br>
> option seems to get help in reinstalling the OS. I believe that the brick<br>
> and other config files are intact. From RHS documentation on upgrading from<br>
> an ISO, this is what I got:<br>
><br>
> 1. Backup (/var/lib/glusterd, /etc/swift, /etc/samba, /etc/ctdb,<br>
> /etc/glusterfs. /var/lib/samba, /var/lib/ctdb) . Backup entire /etc for<br>
> selective restoration.<br>
><br>
> 2. Stop the volume and all services everywhere. Install the OS on the<br>
> affected node without touching the brick. Stop glusterd on this node too.<br>
><br>
> 3. Backup /var/lib/glusterd from the newly installed OS.<br>
><br>
> 4. Copy back /var/lib/glusterd and /etc/glusterfs from step 1. to the<br>
> newly installed OS.<br>
><br>
> 5. Copy back the latest hooks scripts (from step 3) to<br>
> /var/lib/glusterd/hooks. This is probably not required since the steps were<br>
> written for an upgrade whereas my version is the same. Right ?<br>
><br>
> 6. glusterd --xlator-option *.upgrade=yes -N. Is this needed in my case ?<br>
> It's not an upgrade.<br>
><br>
> 7. Restart services and volume.<br>
><br>
> Do these steps sound all right ? Should I also restore /etc/nagios ? Or<br>
> would nagios have to be reconfigured for the entire cluster ?<br>
><br>
><br>
> The reason for this failure was a botched kernel upgrade and a combination<br>
> of some other factors which i'm not sure yet. And I wasn't able to generate<br>
> working initramfs using dracut in recovery. Interestingly, I noticed the<br>
> following line in the new RHS 3.1 documentation. "If dracut packages are<br>
> previously installed, then exclude the dracut packages while updating to<br>
> Red Hat Gluster Storage 3.1 during offline ISO update using the following<br>
> command:<br>
> # yum update -x dracut -x dracut-kernel" . Is there some sort of a known<br>
> issue ?<br>
><br>
<br>
</div></div></blockquote></div><br></div>