[KUDU-3206] Document the procedure of upgrading tablet server's hardware (including hard drives)

• Type: Task
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Component/s: CLI, documentation, tserver
• Labels: maintainability supportability
• Assignee: Unassigned
• Reporter: Alexey Serbin
• Created: 26/Oct/20 19:09
• Updated: 26/Oct/20 19:10

Description

In the fields we saw several cases when people try to update servers in their Kudu clusters to support denser storage per node. Two major points specific to such cases:

• The contents is wiped out since the disk drives are among hardware components to be replaced
• The upgraded node is getting back to the cluster under the same IP address and using the same DNS name, so it's natural to to have the tablet server to run under the same UUID.

The procedure is to use the functionality provided by kudu fs format CLI utility which can take UUID and the set of data directories as input:

Usage: ./bin/kudu fs format [-fs_data_dirs=<dirs>] [-fs_metadata_dir=<dir>] 
        [-fs_wal_dir=<dir>] [-uuid=<uuid>]

Format a new Kudu filesystem

    -fs_data_dirs (Comma-separated list of directories with data blocks. If
      this is not specified, fs_wal_dir will be used as the sole data block
      directory.) type: string default: ""

    -fs_metadata_dir (Directory with metadata. If this is not specified, for
      compatibility with Kudu 1.6 and below, Kudu will check the first entry of
      fs_data_dirs for metadata and use it as the metadata directory if any
      exists. If none exists, fs_wal_dir will be used as the metadata
      directory.) type: string default: ""

    -fs_wal_dir (Directory with write-ahead logs. If this is not specified, the
      program will not start. May be the same as fs_data_dirs) type: string
      default: ""

    -uuid (The uuid to use in the filesystem. If not provided, one is
      generated) type: string default: ""