Adar Dembo has posted comments on this change.
Change subject: docs: workflow for master migration
Patch Set 1:
Line 202: For true high availability and to avoid a single point of failure,
Kudu clusters should be created
> remove "true"
Line 236: recovering from permanent master failures greatly, and is highly
recommended. The alias should be
> how? are you linking this to somewhere else, or are you adding this info on
To clarify, is your question "how does it simplify recovering from permanent
master failures"? Or "how do I configure a DNS cname or /etc/hosts alias"?
To the first question: originally I had an explanation embedded in this
section, but I found it to be too complex and distracting from the rest of the
workflow, so I removed it. The actual explanation can be found in the "handling
permanent failure in masters" design doc, but I don't think it makes sense to
link to a design doc from product documentation.
To the second question: configuring DNS is out of scope of this document
because we expect administrators to know how to do that already, or to find
someone in their organization who does.
Line 244: * Identify and record the directory where the master's data will live.
> this is confusing, the user can "choose" these now since it's running new d
I wanted "record" in there to make it clear that the choice being made needs to
be remembered for later on.
After that, "choose" and "identify" seem synonymous enough to me, and I think
it's good to evoke symmetry with respect to the previous step (where we
identified and recorded the data directory of the existing master).
Line 282: ** `port` is the master's previously recorded RPC port number
> it would be good to have examples for an actual correct command, maybe some
I've added an example for each command.
Line 314: are working properly, consider performing the following sanity checks:
> how does this validate that the new masters are working properly? if the us
Obviously there are a lot of ways that this workflow could be botched. But, if
the user at least rewrote the Raft configuration on the existing master such
that it includes multiple entries, a scan will fail if there aren't healthy
masters behind those entries (because the client will look for a leader master
and won't find one, since the one working master can't get a majority of votes).
What would you propose as a better means of post-migration validation?
To view, visit http://gerrit.cloudera.org:8080/4300
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-Owner: Adar Dembo <a...@cloudera.com>
Gerrit-Reviewer: Adar Dembo <a...@cloudera.com>
Gerrit-Reviewer: Anonymous Coward #149
Gerrit-Reviewer: David Ribeiro Alves <dral...@apache.org>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Todd Lipcon <t...@apache.org>