Prepare for the migration

Before migrating to a multiple Kudu masters set up, you need to perform many migration planning steps, such as deciding the number of masters, and choosing the nodes where to add the new Kudu masters.

Decide how many masters to use.
The number of masters should be odd because an even number of masters does not provide any benefit over having one fewer masters. Three or five node master configurations are recommended as they can tolerate the failure of one or two masters respectively.
Establish a maintenance window.
One hour should be sufficient maintenance window time. During this time the Kudu cluster will be unavailable.
Optional: Configure a DNS alias for the master.
The alias can be:
- a CNAME record: if the machine already has an A record in DNS
- and A record: if the machine is only known by its IP address
important
Without DNS aliases, it is not possible to recover from permanent master failures without restarting the masters and tablet servers in the cluster to pick up the replacement master node with a different hostname. It is highly recommended that you use DNS aliases.
Perform the following preparatory steps for each new master that you are planning to add:
1. Choose a node in the cluster where there is no running Kudu master yet and which has enough spare CPU and memory capacity to host a new Kudu master.
  The master generates very little load so it can be collocated with other data services or load-generating processes, though not with another Kudu master from the same configuration.
2. Choose and record the directories where the new master’s data and WAL will be located.
3. Choose and record the port the master should use for RPCs.
4. Optional: Configure a DNS alias for the master.