kudu表无法正常访问的一种情况

1 概述

　　本文整理了一种kudu表不能正常访问的情况，以及如何确认本情况与应对方法。本文的解决方法参考了文献1¹。

2 问题描述与解决

2.1 问题描述

　　当我们使用kudu java api或者其它的方式（HUE）访问kudu表时，不能正常的访问时。举个例子，当使用kudu java api访问kudu表时，输出如下的日志内容。
　　使用kudu-client-1.5.0.jar可能会输出如下内容：

2020-01-18 19:18:35 INFO AsyncKuduClient.invalidateTabletCache:1432 Removing server 50864b767cb542098bd25299f43dccb8 from this tablet's cache f5de27bb309e48d7ad95c031c37bec7a
2020-01-18 19:18:35 ERROR Connection.exceptionCaught:418 [peer 50864b767cb542098bd25299f43dccb8] unexpected exception from downstream on [id: 0x07e116d0]
java.net.ConnectException: Connection refused: no further information: node-2/192.168.3.131:7050

　　使用kudu-client-1.11.1.jar可能会输出如下内容：

2020-01-18 19:16:47 INFO AsyncKuduClient.invalidateTabletCache:2157 Invalidating location 50864b767cb542098bd25299f43dccb8(node-2:7050) for tablet f5de27bb309e48d7ad95c031c37bec7a: java.net.ConnectException: Connection refused: no further information: node-2/192.168.3.131:7050

2.2 问题原因

　　kudu中，表由tablet组成。对于3副本的情况，如果有2个副本所在的tablet Server不可获取(TS unavailable)，且其中一个不可获取的副本为leader。那么会本tablet不能正常的访问。
　　原因（个人理解）：依据Raft²³一致性算法，当成员个数N=3时，需要达到N/2 + 1 = 2的大多数票，候选人可以成为Leader。对于上述tablet副本情况之间的选举。3个副本中剩下的一个正常的副本，没法成为leader（因为另外两个副本所在的tablet server不可用，正常的副本没法获得2个投票）。则无法实现一致性（Consensus），则该副本对应的tablet不能正常的对外提供读写访问。

2.3 问题的诊断

　　显然，需要查看kudu表的tablet的副本状态，可以使用kudu提供的命令行工具ksck⁴⁵

ksck使用的例子：`kudu cluster ksck node-1:7051,node-2:7051,node-3:7051 -tables=impala::qianyi2.cat`

　　输出的内容如下。

[root@node-1]# kudu cluster ksck node-1:7051,node-2:7051,node-3:7051 -tables=impala::qianyi2.cat
...
Tablet f5de27bb309e48d7ad95c031c37bec7a of table 'impala::qianyi2.cat' is unavailable: 2 replica(s) not RUNNING
  30df8cd3a6064d02a502118575138b76 (node-4:7050): RUNNING
  50864b767cb542098bd25299f43dccb8 (node-2:7050): TS unavailable [LEADER]
  60469325c50d4c388f93048c0c909a66 (node-1:7050): TS unavailable

Table impala::qianyi2.cat has 1 unavailable tablet(s)

Table Summary
        Name         |   Status    | Total Tablets | Healthy | Under-replicated | Unavailable
---------------------+-------------+---------------+---------+------------------+-------------
 impala::qianyi2.cat | UNAVAILABLE | 1             | 0       | 0                | 1
==================
Errors:
==================
error fetching info from tablet servers: Network error: Not all Tablet Servers are reachable
table consistency check error: Corruption: 1 out of 1 table(s) are bad

　　通过ksck的输出内容，在本表中，uuid=f5de27bb309e48d7ad95c031c37bec7a的Tablet，有2个副本所在的tablet server(node-2:7050与node-1:7050)不可用。

2.4 问题的解决

　　如何处理这种情况呢？优先考虑恢复tablet server。先查询下有没有节点tablet server服务已经关闭了，有的话，再先启动tablet server服务。然后重新ksck一下，查看tablet副本的可用情况情况。
　　如果tablet server无法恢复，可以考虑下面的方法。下面的方法可能会导致对该tablet最近的修改数据丢失，不应该优先使用本方法。具体内容可以参考文献⁶。
　　下面对参考文献中的内容摘录如下。

On each tablet server with a healthy replica, alter the consensus configuration to remove unhealthy replicas. In the typical case of 1 out of 3 surviving replicas, there will be only one healthy replica, so the consensus configuration will be rewritten to include only the healthy replica.
Once the healthy replicas' consensus configurations have been forced to exclude the unhealthy replicas, the healthy replicas will be able to elect a leader. The tablet will become available for writes, though it will still be under-replicated. Shortly after the tablet becomes available, the leader master will notice that it is under-replicated, and will cause the tablet to re-replicate until the proper replication factor is restored. The unhealthy replicas will be tombstoned by the master, causing their remaining data to be deleted.⁶

　　翻译：在每个具有正常副本的tablet服务器上，更改一致性配置以删除不正常副本。在三分之一幸存副本的典型情况下，只有一个健康副本，因此将重写一致配置以仅包含健康副本。
　　一旦健康副本的一致配置中，强制排除不健康副本，健康副本将能够选择一个leader。虽然它的副本个数不足3个，这个tablet仍将可以进行写操作。在tablet可用后不久，leader master将注意到它的副本数小于3，并将导致tablet重新复制，直到恢复正确的副本因子个数的副本。不正常的副本将被主副本进行逻辑删除，从而删除其剩余的数据。

　　上述操作，能够选择出一个leader的原因（个人理解）：对健康副本新的一致性配置中，成员个数为N=1（排除了两个不健康的副本），则获取N/2 + 1 = 1的票数为大多数票数，健康副本投票给自己，获得1 票，即可以成为leader。即能正常的选举出leader，实现了一致性，则该表的该tablet能够被正常的访问。
　　使用到的kudu提供的命令行工具： kudu remote_replica unsafe_change_config⁷。

kudu remote_replica unsafe_change_config <tserver_address> <tablet_id> <peer uuids>… 

　　在本例中，健康的tserver_address=node-4:7050，tablet_id=f5de27bb309e48d7ad95c031c37bec7a，健康的tserver的uuid，即peer uuids＝30df8cd3a6064d02a502118575138b76。则应该执行的命令如下。

sudo -u kudu kudu remote_replica unsafe_change_config node-4:7050 f5de27bb309e48d7ad95c031c37bec7a 30df8cd3a6064d02a502118575138b76

3 其它

3.1 批处理问题

​
　　如果，有多张表，不能访问，可以使用程序解析ksck输出的内容，批量处理生成修改一致性配置的命令，然后批量修改该命令。

3.2 tablet server关闭时，tablet的移动。

　　本部分，是对本文内容的一个补充。

Tablet replicas are not tied to a UUID.Kudu doesn't do tablet re-balancing at runtime, so new tablet server will get tablets the next time a node dies or if you create new tables.⁸
​ 当一个tablet server被关闭超过一定的时间（默认5分钟），位于tablet server上的tablet会被移动到其它的tablet server⁹。如果一个tablet server被关闭了很长时间，再启动起来，位于本tablet server上的tablet数目可能很少。其它tablet server上的tablet数据相对较多些，显得不均衡。

3.3 其它补充

　　文章中个人理解的部分，单独标出。观点不合理的地方，欢迎各位同行指教。

4 参考文献

---

1. https://www.cnblogs.com/barne... (【原创】大数据基础之Kudu（2）移除dead tsever - 匠人先生 - 博客园) ↩
2. https://raft.github.io/ (Raft Consensus Algorithm) ↩
3. https://www.jianshu.com/p/4c8... (Consensus Algorithm——Raft 协议 - 简书) ↩
4. https://kudu.apache.org/relea... ↩
5. https://docs.cloudera.com/run... ↩
6. https://kudu.apache.org/docs/... ↩
7. https://kudu.apache.org/relea... ↩
8. https://mail-archives.apache.... (Re: How to reuse tablet server UUID, or removing old one) ↩
9. https://docs.cloudera.com/run... (Decommissioning or permanently removing a tablet server from a cluster) ↩