Upgrading directly from Kudu 1.5.0 is supported and no special upgrade steps are required. A rolling upgrade may work, however it has not been tested. 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.
Support for Spark 1 (kudu-spark_2.10) has been removed in Kudu 1.6.0 and now only Spark 2 is supported. Spark 1 support was deprecated in Kudu 1.5.0.
Support for Java 7 has been deprecated since Kudu 1.5.0 and may be removed in the next major release.
Tablet servers' tolerance of disk failures is now enabled by default and has
been extended to handle data directory failures at runtime. In the event of
a disk failure at runtime, any tablets with data on a failed disk will be
shut down and restarted on another tablet server. There is a configurable
tradeoff between a newly added tablet’s tolerance to disk failures and its
ability to parallelize reads via the experimental
--fs_target_data_dirs_per_tablet flag. Tablets that are spread across fewer
disks are less likely to be affected by a disk failure, at the cost of
reduced parallelism. By default, tablets are striped across all available
disks. Note that the first configured data directory and the WAL directory
cannot currently tolerate disk failures. This will be further improved in
future Kudu releases.
Kudu servers can now adopt new data directories via the new
kudu fs update_dirs tool. The new directory will be used by new tablet
replicas only. Note that removing directories is not yet supported
Kudu servers have two new flags to control webui TLS/HTTPS
These flags allow the advertised TLS ciphers and TLS protocol versions to be
configured. Additionally, the webserver now excludes insecure legacy ciphers
Kudu servers can now tolerate short interruptions in NTP clock synchronization. NTP synchronization is still required when any Kudu daemon starts up. If NTP synchronization is not available, diagnostic information is now logged to help pinpoint the issue (see KUDU-1578).
Tablet server startup time has been improved significantly on servers containing large numbers of blocks.
The log block manager now performs disk data deletion in batches. This optimization can significantly reduce the time taken to delete data on a tablet.
The usage of sensitive data redaction flag has been slightly changed. By
--redact=log flag, redaction will be disabled in the web UI but
retained for server logs. Alternatively,
--redact=none can be used to
disable redaction completely.
The Spark DataSource integration now can take advantage of scan locality for better scan performance, the scan will take place at the closest replica instead of going to the leader.
Various optimizations were made to reduce the 99th percentile latency of writes on the tablet server. This can also improve throughput on certain write workloads, particularly on larger clusters.
Kudu may now be configured to ignore system-wide auth_to_local mappings
configured in /etc/krb5.conf by setting the configuration flag
The performance of the compaction scheduler has been improved. In previous versions, certain types of time series workloads were found to cause compaction scheduling to take tens of seconds. These workloads now schedule compactions an order of magnitude more efficiently.
The compaction scheduler has been improved to avoid running a compaction when the benefit of that compaction is extremely small.
Tablet servers now consider the health of all replicas of a tablet before deciding to evict one. This can improve stability of the Kudu cluster after experiencing multiple simultaneous daemon failures (see KUDU-2048).
Several performance improvements have been made to the Kudu master, particularly in concurrency of clients opening tables. This should improve performance in highly concurrent workloads.
The on-disk size metric for a tablet now includes all data and metadata. Previously, it excluded WAL segments and consensus metadata (see KUDU-1755).
Added verbose mode for the 'kudu cluster ksck' command to enable output of detailed information on the cluster’s metadata, even when no errors are detected.
HybridTime timestamp propagation now works in the Java client when using scan tokens (see KUDU-1411).
Fixed an error message commonly found in tablet server logs indicating that operations were being read "from the future" (see KUDU-1078).
Tombstoned tablets no longer report metrics (see KUDU-2044).
Fixed a bug in the C++ client which could cause tablets to be erroneously pruned, or skipped, during certain scans, resulting in fewer results than expected being returned from queries. The bug only affected tables whose range partition columns are a proper prefix of the primary key (see KUDU-2173).
Published Kudu Java artifacts are now fully compatible with JRE 7 and JRE 8. There was previously a bug in the release process which made them compatible only with JRE 8 (see KUDU-2188).
Fixed a typo in the list of default TLS ciphers used by Kudu servers. As a result, two additional cipher suites are now available:
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
Kudu 1.6.0 is wire-compatible with previous versions of Kudu:
Kudu 1.6 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.5 and Kudu 1.6 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.6 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.6 and versions earlier than 1.3:
If a Kudu 1.6 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.6 cluster is configured with authentication and encryption set to "optional" or "disabled", older clients will still be able to connect.
The Kudu 1.6 Java client library is API- and ABI-compatible with Kudu 1.5. Applications written against Kudu 1.5 will compile and run against the Kudu 1.6 client library and vice-versa.
The Kudu 1.6 C++ client is API- and ABI-forward-compatible with Kudu 1.5. Applications written and compiled against the Kudu 1.5 client library will run without modification against the Kudu 1.6 client library. Applications written and compiled against the Kudu 1.6 client library will run without modification against the Kudu 1.5 client library.
The Kudu 1.6 Python client is API-compatible with Kudu 1.5. Applications written against Kudu 1.5 will continue to run against the Kudu 1.6 client and vice-versa.
Please refer to the Known Issues and Limitations section of the documentation.
Kudu 1.6 includes contributions from 14 people, including one first-time contributor, Hector Camarena.
Thanks for helping to make Kudu even better!