kudu-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergejs Andrejevs <S.Andrej...@intrum.com>
Subject RE: Adding a new kudu master
Date Fri, 06 Jul 2018 14:16:05 GMT
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


> 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

View raw message