Thanks for the quick answer, Todd!

> >
> > I need to upgrade (reinstall) prod servers, where 3 Kudu masters are
> > running. What would be the best way to do it from Kudu perspective?
> >

> Will you be changing the hostnames of the servers or just reinstalling the
> OS but otherwise keeping the same configuration?
>
> Have you partitioned the servers with separate OS and data disks? If so,
> you can likely just reinstall the OS without reformatting the data disks.
> When the OS has been reinstalled, simply install Kudu again, use the same
> configuration as before to point at the existing data directories, and
>
The address is going to remain the same.
Hardware remains the same.
The OS and disks will be wiped out.

>

> Why bother removing the master that's down? If you can keep its data

> around, and it will come back with the same hostname, there's no need to

> remove it. You could simply shut down the node and be running with 2/3

> servers up, which would give you the same reliability as using 2/2 without

> the extra steps.
>
Removing the Kudu master from CM results in Kudu configs update. Kudu may 
continue running and operating till the first restart.
On the restart there is reported Kudu masters mismatch and the start fails. 
That was the only purpose.

>

> I can't give any particular advise on how this might interact with Cloudera

> Manager. I think the Cloudera community forum probably is a more

> appropriate spot for that. But, from a Kudu-only perspective, it should be

> fine to have a mixed-OS cluster where one master has been upgraded before

> the others. Just keep the data around when you reinstall.
>
Both perspectives are important. Thanks a lot for lighting up any of them :)
What should more preferable approach:

1.       To backup fs_wal_dir and fs_data_dirs, make upgrade (including wipe 
out the disk), return backed up directories back and continue. Are there any 
dependencies, such as uuid, outside these 2 directories.

2.       To follow the steps similar to "migrating to multi-master" (as posted 
previously) by removing one master, upgrading it and then adding as a new fresh 
master.
?

I haven't tried the 1st option yet (but probably I should try this out too).
Talking about the 2nd option and "add a new master":
I understand, since it is not in the official documentation, it is not 
officially supported yet. As well as not tested [enough].
However, I saw a remark that the steps, listed here 
http://kudu.apache.org/docs/administration.html#migrate_to_multi_master, may 
introduce some issues in case of adding a new master to multi-master cluster. 
Could you highlight the pitfalls? Just to be aware of it.
E.g. May be major concerns be solved/reduced, e.g. by Kudu masters stop for 
some short time to perform the changes? [once again, I understand it is not 
official and there will be some risk anyway. However, I wish to be informed 
about known risks]


Best regards,
Sergejs Andrejevs

Reply via email to