anchor.diff:  `kudu`.
   
   ==== Prepare for the recovery
  +
  +. If the deployment was configured without DNS aliases perform the following steps:
  +* Establish a maintenance window (one hour should be sufficient). During this time the Kudu cluster
  +  will be unavailable.
  +* Shut down all Kudu tablet server processes in the cluster.
   
   . Ensure that the dead master is well and truly dead. Take whatever steps needed to prevent it from
     accidentally restarting; this can be quite dangerous for the cluster post-recovery.
  
positive.code: 
  Due to https://issues.apache.org/jira/browse/KUDU-1620[KUDU-1620], it is not possible to perform
  this workflow without also restarting the live masters. As such, the workflow requires a
  maintenance window, albeit a brief one as masters generally restart quickly.
  
  WARNING: Kudu does not yet support Raft configuration changes for masters. As such, it is only
  possible to replace a master if the deployment was created with DNS aliases. See the
  <<migrate_to_multi_master,multi-master migration workflow>> for more details.
  
  WARNING: The workflow presupposes at least basic familiarity with Kudu configuration management. If
  using Cloudera Manager (CM), the workflow also presupposes familiarity with it.
  
negative.code: * Choose and record the port the master should use for RPCs.
  * Optional: configure a DNS alias for the master (e.g. `master-2`, `master-3`, etc).
  
  [[perform-the-migration]]
  ==== Perform the migration
  
  . Stop all the Kudu processes in the entire cluster.
  