Upgrade Notes for Kudu 1.10 / CDH 6.3
When upgrading Kudu, it is recommended to first shut down all Kudu processes across the cluster, then upgrade the software on all servers, then restart the Kudu processes on all servers in the cluster.
- To improve security, world-readable Kerberos keytab files are no longer accepted by default. Set ‑‑allow_world_readable_credentials=true to override this behavior.
Wire Protocol compatibility
Kudu 1.10.0 is wire-compatible with previous versions of Kudu:
Kudu 1.10 clients may connect to servers running Kudu 1.0 or later. If the client uses features that are not available on the target server, an error will be returned.
Rolling upgrade between Kudu 1.9 and Kudu 1.10 servers is believed to be possible though has not been sufficiently tested. Users are encouraged to shut down all nodes in the cluster, upgrade the software, and then restart the daemons on the new version.
Kudu 1.0 clients may connect to servers running Kudu 1.10 with the exception of the below-mentioned restrictions regarding secure clusters.
The authentication features introduced in Kudu 1.3 place the following limitations on wire compatibility between Kudu 1.10 and versions earlier than 1.3:
If a Kudu 1.10 cluster is configured with authentication or encryption set to "required", clients older than Kudu 1.3 will be unable to connect.
If a Kudu 1.10 cluster is configured with authentication and encryption set to "optional" or "disabled", older clients will still be able to connect.
Client Library Compatibility
The Kudu 1.10 Java client library is API- and ABI-compatible with Kudu 1.9. Applications written against Kudu 1.9 will compile and run against the Kudu 1.10 client library and vice-versa.
The Kudu 1.10 C++ client is API- and ABI-forward-compatible with Kudu 1.9. Applications written and compiled against the Kudu 1.9 client library will run without modification against the Kudu 1.10 client library. Applications written and compiled against the Kudu 1.9 client library will run without modification against the Kudu 1.10 client library.
The Kudu 1.10 Python client is API-compatible with Kudu 1.9. Applications written against Kudu 1.9 will continue to run against the Kudu 1.10 client and vice-versa.
Upon upgrading to CDH 6.2 / Kudu 1.9 or higher, if rack locations are assigned, you should run the kudu cluster rebalance tool to ensure your existing tables are in compliance with the rack awareness placement policy.
Table History Retention Time
The default tablet history retention time has been raised from 15 minutes to 7 days to better support touchless incremental backups.
Integration with the Hive Metastore
Kudu has an optional feature which allows it to integrate its own catalog with the Hive Metastore (HMS). Before enabling the HMS integration on an existing cluster, upgrade any tables that may exist in Kudu's or in the HMS's catalog. See Upgrading Existing Tables.