release notes: some edits
- Some small wording improvements
- Moved 3-4-3 replication to new features since it seems large enough to
not just be an "improvement"
- Added a note that the 3-disks-per-replica change only affects new
replicas
- Stopped documenting the experimental flag which goes back to 3-2-3
replication since we'd like to remove it in the future, and we don't
know of any compelling reasons for someone to change it.
- Moved KUDU-2259 to "fixed issues" since it was seen as a bug
- Added a few explanations of the results of some fixes instead of the
implementations.
Change-Id: I944a302a7fe5c86d0204545157efb92407573e1e
Reviewed-on: http://gerrit.cloudera.org:8080/9703
Reviewed-by: Alexey Serbin <aserbin@cloudera.com>
Reviewed-by: Adar Dembo <adar@cloudera.com>
Tested-by: Grant Henke <granthenke@apache.org>
Reviewed-by: Grant Henke <granthenke@apache.org>
(cherry picked from commit 02d9578406c955d70a59c6676c044dac42e0d9bd)
Reviewed-on: http://gerrit.cloudera.org:8080/9706
diff --git a/docs/release_notes.adoc b/docs/release_notes.adoc
index fc7bf80..f31d026 100644
--- a/docs/release_notes.adoc
+++ b/docs/release_notes.adoc
@@ -36,7 +36,7 @@
the default replica management scheme changed, and running masters and tablet
servers with different replica management schemes is not supported, see
<<rn_1.7.0_incompatible_changes>> for details. However, mixing client and
- server sides of different versions is not a problem, i.e. you can still
+ server sides of different versions is not a problem. You can still
update your clients before your servers or vice versa.
When upgrading to Kudu 1.7, it is required to first shut down all Kudu processes
across the cluster, then upgrade the software on all servers, then restart
@@ -64,6 +64,17 @@
larger than int64 and cases with fractional values in a primary key.
See link:schema_design.html#decimal[Decimal Type] for more details.
+* The strategy Kudu uses for automatically healing tablets which have lost a
+ replica due to server or disk failures has been improved. The new re-replication
+ strategy, or replica management scheme, first adds a replacement tablet replica
+ before evicting the failed one. With the previous replica management scheme,
+ the system first evicts the failed replica and then adds a replacement. The new
+ replica management scheme allows for much faster recovery of tablets in
+ scenarios where one tablet server goes down and then returns back shortly after
+ 5 minutes or so. The new scheme also provides substantially better overall
+ stability on clusters with frequent server failures.
+ (see link:https://issues.apache.org/jira/browse/KUDU-1097[KUDU-1097]).
+
* The `kudu fs update_dirs` tool now supports removing directories. Unless the
`--force` flag is specified, Kudu will not allow the removal of a directory
across which tablets are configured to spread data. If specified, all tablet
@@ -88,8 +99,8 @@
Note that this is still an experimental feature which may be stabilized in
future releases.
-* The tablet server web UI scans dashboard (/scans) has been improved with a
- host of new features, including: showing the most recently completed scans,
+* The tablet server web UI scans dashboard (/scans) has been improved with
+ several new features, including: showing the most recently completed scans,
a pseudo-SQL scan descriptor that concisely shows the selected columns and
applied predicates, and more complete and better documented scan statistics.
@@ -100,14 +111,11 @@
== Optimizations and improvements
* By default, each tablet replica will now stripe data blocks across 3 data
- directories instead of all data directories. This increases the likelihood
- that any given tablet will be unaffected in the event of a single disk failure.
- In performance tests of this feature we saw no meaningful performance hit. You
- can see the details of that test
- link:https://github.com/apache/kudu/commit/60276c54a221d554287c6645df7df542fe6d6443[here].
-
-* The master no longer issues authentication tokens over non-confidential
- connections.
+ directories instead of all data directories. This decreases the likelihood
+ that any given tablet will be affected in the event of a single disk failure.
+ No substantial performance impact is expected due to this feature based on
+ link:https://github.com/apache/kudu/commit/60276c54a221d554287c6645df7df542fe6d6443[performance testing].
+ This change only affects new replicas created after upgrading to Kudu 1.7.
* Kudu servers previously offered the ability to enable a separate metrics log
which stores periodic snapshots of all metrics available on a server. This
@@ -150,18 +158,6 @@
the data. Users can disable this behavior by passing 'leader_only' to the
'kudu.scanLocality' option."
-* The strategy Kudu uses for automatically healing tablets which have lost a
- replica due to server or disk failures has been improved. The new re-replication
- strategy, or replica management scheme, first adds a replacement tablet replica
- before evicting the failed one. With the previous replica management scheme,
- the system first evicts the failed replica and then adds a replacement. The new
- replica management scheme allows for much faster recovery of tablets in
- scenarios where one tablet server goes down and then returns back shortly after
- 5 minutes or so. To switch back to the old scheme, set the
- `--raft_prepare_replacement_before_eviction` run-time flag to `false` for
- *all* tablet servers and masters in Kudu 1.7 cluster.
- (see link:https://issues.apache.org/jira/browse/KUDU-1097[KUDU-1097]).
-
* The number of OS threads used in the steady state and during bursts of
activity (such as in Raft leader elections triggered by a node failure) has
been drastically reduced and should no longer exceed the value of `ulimit -u`.
@@ -181,37 +177,26 @@
This will improve update-heavy workloads which overwrite large (1KiB+) values.
(see link:https://issues.apache.org/jira/browse/KUDU-2253[KUDU-2253]).
-* The Unix process username of the client is now included inside the exported
- security credentials, so that the effective username of clients who import
- credentials and subsequently use unauthenticated (SASL PLAIN) connections
- matches the client who exported the security credentials. For example, this is
- useful to let the Spark executors know which username to use if the Spark
- driver has no authentication token. This is the case when the system is
- configured with `--rpc-encryption=disabled`.
- (see link:https://issues.apache.org/jira/browse/KUDU-2259[KUDU-2259]).
[[rn_1.7.0_fixed_issues]]
== Fixed Issues
-* Fixed scenarios where a tablet server was completely wiped and a new one was
- started with a new UUID using the same host and ports sometimes preventing
- previously hosted tablet replicas from be evicted from the Raft configuration.
+* Fixed a scenario where the on-disk data of a tablet server was completely
+ erased and and a new tablet server was started on the same host. This issue
+ could prevent tablet replicas previously hosted on the server from being
+ evicted and re-replicated.
Tablets now immediately evict replicas that respond with a different server
UUID than expected.
(see link:https://issues.apache.org/jira/browse/KUDU-1613[KUDU-1613]).
* Fixed a rare race condition when connecting to masters during their
startup which might cause a client to get a response without a CA certificate
- and/or authentication token. The leader master now always sends a CA
+ and/or authentication token. This would cause the client to fail to authenticate
+ with other servers in the cluster. The leader master now always sends a CA
certificate and an authentication token (when applicable) to a Kudu client
with a successful ConnectToMaster response.
(see link:https://issues.apache.org/jira/browse/KUDU-1927[KUDU-1927]).
-* Fixed a bug that would, in rare cases, attempt and fail to compact
- already-compacted rowsets. This would previously crash tablet servers running
- in debug mode.
- (see link:https://issues.apache.org/jira/browse/KUDU-2115[KUDU-2115]).
-
* The Kudu Java client now will retry a connection if no master is discovered as a
leader, and the user has a valid authentication token. This avoids failure
in recoverable cases when masters are in the process of the very first leader
@@ -226,12 +211,10 @@
authentication has been added to the Javadoc for the `AsyncKuduClient` class.
(see link:https://issues.apache.org/jira/browse/KUDU-2264[KUDU-2264]).
-* Follower masters are now able to verify authn tokens even if they have never
+* Follower masters are now able to verify authentication tokens even if they have never
been a leader. Prior to this fix, if a follower master had never been a leader,
- it didn’t have CA-signed server certificate and it didn’t have the public part
- of token signing keys. Kudu clients could not authenticate with such follower
- masters using their valid authentication tokens, resorting to Kerberos
- authentication, when possible.
+ clients would be unable to authenticate to that master, resulting in spurious
+ error messages being logged.
(see link:https://issues.apache.org/jira/browse/KUDU-2265[KUDU-2265]).
* Fixed a tablet server crash when a tablet replica is deleted during a scan.
@@ -245,9 +228,9 @@
(see link:https://issues.apache.org/jira/browse/KUDU-2312[KUDU-2312]).
* Previously, the `kudu tablet change_config move_replica` tool required all
- tablet servers to be available when performing a move. This restriction has
- been relaxed: only the tablet server that will receive a replica of the tablet
- being moved and the hosts of the tablet's existing replicas need to be
+ tablet servers in the cluster to be available when performing a move. This
+ restriction has been relaxed: only the tablet server that will receive a replica
+ of the tablet being moved and the hosts of the tablet's existing replicas need to be
available for the move to occur.
(see link:https://issues.apache.org/jira/browse/KUDU-2331[KUDU-2331]).
@@ -257,6 +240,15 @@
timing out operations with errors indicating that there was no leader master.
(see link:https://issues.apache.org/jira/browse/KUDU-2343[KUDU-2343]).
+* The Unix process username of the client is now included inside the exported
+ security credentials, so that the effective username of clients who import
+ credentials and subsequently use unauthenticated (SASL PLAIN) connections
+ matches the client who exported the security credentials. For example, this is
+ useful to let the Spark executors know which username to use if the Spark
+ driver has no authentication token. This change only affects clusters with
+ encryption disabled using `--rpc-encryption=disabled`.
+ (see link:https://issues.apache.org/jira/browse/KUDU-2259[KUDU-2259]).
+
[[rn_1.7.0_wire_compatibility]]
== Wire Protocol compatibility
@@ -283,24 +275,14 @@
* The newly introduced replica management scheme is not compatible with the
old scheme, so it's not possible to run pre-1.7 Kudu masters with
- 1.7 Kudu tablet servers and vice versa, unless setting the run-time flag
- `--raft_prepare_replacement_before_eviction` to `false` for 1.7 masters
- and tablet servers. In essence, tablet servers cannot register with masters
- running with different replica management scheme. This is the server-side
- incompatibility only and it does not affect the client side. In other words,
- Kudu clients of prior versions are compatible with the Kudu server side
- running with either scheme, assuming the same replica management scheme
- is used by all masters and tablet servers in the Kudu cluster.
+ 1.7 Kudu tablet servers or vice versa. This is a server-side
+ incompatibility only and it does not affect client compatibility. In other words,
+ Kudu clients of prior versions are compatible with upgraded Kudu clusters.
+
** Kudu masters of 1.7 version will not register Kudu tablet servers of 1.6
- and prior revisions. To run 1.7 masters with the old scheme, set the
- `--raft_prepare_replacement_before_eviction` to `false`.
+ and prior versions.
** Kudu tablet servers of 1.7 version will not work with Kudu masters of 1.6
- and prior versions. To make the case of such misconfiguration easily
- detectable, Kudu tablet servers of 1.7 version crash when they detect their
- masters running with different replica management scheme. The crashing of
- tablet servers in such scenarios can be disabled by setting their
- `--heartbeat_incompatible_replica_management_is_fatal` run-time flag to
- `false`.
+ and prior versions.
* The format of the previously-optional metrics log has changed to include a
human-readable timestamp on each line. The path of the log file has also
