Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Duplicate
-
None
-
None
Description
Today, Kudu will refuse to start up when its FS layout isn't as expected. Before 1.6.0, users could not add data directories; before 1.7.0, users could not remove data directories; today, to do either of the above, users must use the `update_dirs` tool before starting up.
Prior to this, the preferred way to start up a Kudu node with a different FS layout was to rmrf the entirety of the node's FS layout and start a new node with a new UUID at the same location. While Kudu is designed to be resilient to such removal of data (automatically replicating the removed tablets to other nodes), this has lead to problems, as, e.g., wiping multiple nodes without waiting ample time in between wipes could lead to data loss.
While the `update_dirs` tool removes the need for rmrf altogether, that may not stop unknowing users from wiping their nodes clean upon failure to startup (e.g. if a user adds a data dir through some cluster management software like Cloudera Manager (which doesn't run `update_dirs`), and receives an error upon starting up). Now that we have a solution to safe removal and addition of data directories with known constraints to its usage, it's not unthinkable that we extend Kudu itself to start up with a different FS layout subject to the same constraints.