KUDU常见的错误排查

清欢爱蹦跶

已于 2024-02-27 16:32:45 修改

阅读量1.2k

点赞数 19

分类专栏：大数据 kudu 文章标签：大数据数据库数据库开发分布式 big data hadoop

于 2024-01-10 17:01:35 首次发布

本文链接：https://blog.csdn.net/ClaudineQ/article/details/135465072

版权

大数据同时被 2 个专栏收录

1 篇文章 0 订阅

订阅专栏

kudu

1 篇文章 0 订阅

订阅专栏

请添加图片描述

一、启动报错

1. Already present: FS layout already exists

Kudu启动时，会检查每个已配置的数据目录，期望所有数据目录都被初始化或者都为空。如果某个服务器无法启动且有以下报错：

Check failed: _s.ok() Bad status: Already present: FS layout already exists; not overwriting existing layout: FSManager roots already exist: /data0/kudu/data

此前提条件失败，这可能是因为在第一次启动时，Kudu使用非空数据目录进行了配置，也可能是因为之前的一个健康Kudu进程被重新启动，并且至少一个数据目录被删除或是由于磁盘出现错误而损坏。如果出现后一种情况，请参考更改目录配置步骤。

2. NTP Clock Synchronization

对于主服务器和服务器守护程序，必须使用NTP同步服务器的时钟。此外，最大时钟误差必须低于可配置的阈值。默认值为10秒，但可以使用–max_clock_sync_error_usec设置。

如果未安装NTP，或者时钟被报告为未同步，Kudu将无法启动，并发出以下消息：

F0924 20:24:36.336809 14550 hybrid_clock.cc:191 Couldn’t get the current time: Clock unsynchronized. Status: Service unavailable: Error reading clock. Clock considered unsynchronized.

如果安装并同步了NTP，但最大时钟误差过高，则用户将看到以下消息：

Sep 17, 8:13:09.873 PM FATAL hybrid_clock.cc:196 Couldn’t get the current time: Clock synchronized, but error: 11130000, is past the maximum allowable error: 10000000

或

Sep 17, 8:32:31.135 PM FATAL tablet_server_main.cc:38 Check failed: _s.ok() Bad status: Service unavailable: Cannot initialize clock: Cannot initialize HybridClock. Clock synchronized but error was too high (11711000 us).

2.1安装NTP

安装NTP，使用适合您的操作系统的命令：

操作系统	命令
Debian/Ubuntu	sudo apt-get install ntp
RHEL/CentOS	sudo yum install ntp

如果已安装但未运行NTP，请使用以下命令之一启动它：

操作系统	命令
Debian/Ubuntu	sudo service ntp restart
RHEL/CentOS	sudo /etc/init.d/ntpd restart

2.2 Monitoring NTP Status （监控NTP状态）

安装NTP后，可以通过运行ntptime来监视同步状态。例如:

ntp_gettime() returns code 0 (OK)
  time de24c0cf.8d5da274  Tue, Feb  6 2018 16:03:27.552, (.552210980),
  maximum error 224455 us, estimated error 383 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 1279.543 us, frequency 2.500 ppm, interval 1 s,
  maximum error 224455 us, estimated error 383 us,
  status 0x2001 (PLL,NANO),
  time constant 10, precision 0.001 us, tolerance 500 ppm,

特别注意以下最重要的输出：

maximum error 22455 us：此值远低于Kudu所需的最大误差10秒。
status 0x2001 (PLL,NANO):这表示健康的同步状态。

相比之下，没有正确配置和运行NTP的系统将输出以下内容：

ntp_gettime() returns code 5 (ERROR)
  time de24c240.0c006000  Tue, Feb  6 2018 16:09:36.046, (.046881),
  maximum error 16000000 us, estimated error 16000000 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset 0.000 us, frequency 2.500 ppm, interval 1 s,
  maximum error 16000000 us, estimated error 16000000 us,
  status 0x40 (UNSYNC),
  time constant 10, precision 1.000 us, tolerance 500 ppm,

请注意UNSYNC状态和16秒的最大误差。

如果需要更详细的信息，可以使用ntpq或ntpdc工具转储有关当前作为源的网络时间服务器的进一步信息：

$ ntpq -nc lpeers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-108.59.2.24     130.133.1.10     2 u   13   64    1   71.743    0.373   0.016
+192.96.202.120  129.6.15.28      2 u   12   64    1   72.583   -0.426   0.028
-69.10.161.7     204.26.59.157    3 u   11   64    1   15.741    2.641   0.021
-173.255.206.154 45.56.123.24     3 u   10   64    1   43.502    0.199   0.029
-69.195.159.158  128.138.140.44   2 u    9   64    1   53.885   -0.016   0.013
*216.218.254.202 .CDMA.           1 u    6   64    1    1.475   -0.400   0.012
+129.250.35.250  249.224.99.213   2 u    7   64    1    1.342   -0.640   0.018
 45.76.244.193   216.239.35.4     2 u    6   64    1   17.380   -0.754   0.051
 69.89.207.199   212.215.1.157    2 u    5   64    1   57.796   -3.411   0.059
 171.66.97.126   .GPSs.           1 u    4   64    1    1.024   -0.374   0.018
 66.228.42.59    211.172.242.174  3 u    3   64    1   72.409    0.895   0.964
 91.189.89.198   17.253.34.125    2 u    2   64    1  135.195   -0.329   0.171
 162.210.111.4   216.218.254.202  2 u    1   64    1   28.570    0.693   0.306
 199.102.46.80   .GPS.            1 u    2   64    1   55.652   -0.039   0.019
 91.189.89.199   17.253.34.125    2 u    1   64    1  135.265   -0.413   0.037
$ ntpq -nc opeers
     remote           local      st t when poll reach   delay   offset    disp
==============================================================================
-108.59.2.24     10.17.100.238    2 u   17   64    1   71.743    0.373 187.573
+192.96.202.120  10.17.100.238    2 u   16   64    1   72.583   -0.426 187.594
-69.10.161.7     10.17.100.238    3 u   15   64    1   15.741    2.641 187.569
-173.255.206.154 10.17.100.238    3 u   14   64    1   43.502    0.199 187.580
-69.195.159.158  10.17.100.238    2 u   13   64    1   53.885   -0.016 187.561
*216.218.254.202 10.17.100.238    1 u   10   64    1    1.475   -0.400 187.543
+129.250.35.250  10.17.100.238    2 u   11   64    1    1.342   -0.640 187.588
 45.76.244.193   10.17.100.238    2 u   10   64    1   17.380   -0.754 187.596
 69.89.207.199   10.17.100.238    2 u    9   64    1   57.796   -3.411 187.541
 171.66.97.126   10.17.100.238    1 u    8   64    1    1.024   -0.374 187.578
 66.228.42.59    10.17.100.238    3 u    7   64    1   72.409    0.895 187.589
 91.189.89.198   10.17.100.238    2 u    6   64    1  135.195   -0.329 187.584
 162.210.111.4   10.17.100.238    2 u    5   64    1   28.570    0.693 187.606
 199.102.46.80   10.17.100.238    1 u    4   64    1   55.652   -0.039 187.587
 91.189.89.199   10.17.100.238    2 u    3   64    1  135.265   -0.413 187.621

2.3 NTP Configuration Best Practices（NTP配置最佳实践）

为了提供稳定的时间同步和低误差，请遵循以下最佳NTP配置实践。

配置至少4个NTP时间源。除了在一个或多个时间源不可用时提供冗余外，NTP协议旨在通过使用不同来源来提高其准确性。即使您的组织提供一个或多个本地时间服务器，极力推荐配置其他远程服务器以确保健壮性。
选择在服务器所在地理位置的时间服务器。例如，如果您的服务器位于欧洲，请从欧洲NTP池中选择服务器。如果您的服务器在公共云环境中运行，请查阅云提供商的文档以获得推荐的NTP设置。许多云提供商提供高度准确的时钟同步作为服务。
用iburst选项启动时快速同步。iburst选项指示ntpd在启动时发送一组时间查询,这通常会在机器重新启动时导致更快的时间同步。

NTP服务器列表示例可能如下所示：

# Use my organization's internal NTP servers.
server ntp1.myorg.internal iburst
server ntp2.myorg.internal iburst
# Provide several public pool servers for
# redundancy and robustness.
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst

在配置NTP之后，使用·ntpq·工具验证是否能够连接到配置好的对等网络。如果没有，可能是NTP协议被防火墙或其他网络连接问题阻止了。

2.4 Troubleshooting NTP Stability Problems（NTP稳定性问题）

自Kudu 1.6.0以来，Kudu守护程序能够在短时间内失去NTP同步时继续运行。但是，如果NTP同步丢失数小时，守护程序可能会崩溃。如果守护程序由于NTP同步问题而崩溃，请查看ERROR日志以获取有关信息的转储，这些信息可能有助于诊断问题。

Kudu 1.5.0及早期版本对短暂的NTP中断的容忍度较低。此外，它们包含了一个错误，可能会导致Kudu错误地测量最大误差，导致崩溃。如果您在这些早期版本的Kudu上遇到与时钟同步有关的崩溃，并且系统的NTP配置正确，请考虑升级到Kudu 1.6.0或更高版本。
NTP需要网络连接，可能需要几分钟才能在启动时同步时钟。在某些情况下，不稳定的网络连接可能会使NTP将时钟报告为未同步。这种情况下常见的临时解决方法是使用上述命令之一重新启动NTP。

二、性能问题

可以借助这两个页面进行排查：

Daemon ( 守护进程 )	URL
Tablet Server	http://tablet-server-1.example.com:8050/tracing.html
Master	http://master-1.example.com:8051/tracing.html

注意：最好用Google Chrome ，其他浏览器可能无法正常工作。

内存限制

Kudu有硬内存限制和软内存限制。

硬内存限制：Kudu进程被允许使用的最大内存量，由--memory_limit_hard_bytes控制。
软内存限制：硬内存限制的一个百分比，由memory_limit_soft_percentage控制，默认值为80％，到达了这个内存，就开始拒绝某些写操作了，一般到达60%就开始降速。
如果日志或RPC跟踪包含以下消息，表示Kudu内存压力太大开始拒绝写操作，这可能导致写入超时。

Service unavailable: Soft memory limit exceeded (at 96.35% of capacity)

减轻Kudu内存负荷的几种方法：

尽可能增大--memory_limit_hard_bytes，只要主机内存允许
增加磁盘数或增加维护管理器线程数 --maintenance_manager_num_threads，以增加Kudu从内存到磁盘的刷写速率，一般维护管理器线程：数据目录 = 1：3。
降低Kudu写入速率

1.8版本之前的Kudu，请检查--block_cache_capacity_mb的值（Kudu块缓存的最大大小）。尽管--block_cache_capacity_mb较高可以帮助读写性能，但不能超过内存压力阈值，否则即使写入吞吐量较低，Kudu也会强制刷新。

压力阈值 = --memory_pressure_percentage（默认60%）*--memory_limit_hard_bytes，超过压力阈值就开始写入降速了。

建议将--block_cache_capacity_mb设置为内存压力阈值50％以下，默认情况下，也就是不应超过--memory_limit_hard_bytes的30％。在Kudu 1.8及更高版本中，如果块缓存容量超过内存压力阈值，则服务器将拒绝启动。

块缓存大小 Block Cache Size

Kudu使用LRU缓存来缓存最近读取的数据。对于反复扫描数据子集的工作负载，增加此缓存的大小可以提供显着的性能优势。要增加专用于块缓存的内存量，请增加配置--block_cache_capacity_mb的值。默认值为512MiB。

Kudu提供了一组有用的指标，用于评估块缓存的性能，这些指标可以在8050 Web界面的/metrics菜单找到。以下是一个示例集：
在这里插入图片描述

{
  "name": "block_cache_inserts",
  "value": 64
},
{
  "name": "block_cache_lookups",
  "value": 512
},
{
  "name": "block_cache_evictions",
  "value": 0
},
{
  "name": "block_cache_misses",
  "value": 96
},
{
  "name": "block_cache_misses_caching",
  "value": 64
},
{
  "name": "block_cache_hits",
  "value": 0
},
{
  "name": "block_cache_hits_caching",
  "value": 352
},
{
  "name": "block_cache_usage",
  "value": 6976
}

要评估 tserver 服务器上块缓存的效率，先等服务器已经运行并做了几次请求，这样缓存不是冷启动状态。除非服务器存储的数据非常少或处于闲置状态，否则block_cache_usage应该等于或接近于block_cache_capacity_mb。一旦缓存达到了稳定状态，比较block_cache_lookups与block_cache_misses_caching(Kudu期望从缓存中读取但在缓存中未找到的块数)。

如果很多的块缓存查找（block_cache_lookups）导致了在预期的缓存命中情况下缓存未命中，并且block_cache_evictions指标相对于块缓存插入block_cache_inserts来说是很大，则说明块缓存的大小可能不足以处理负载，则增加块缓存的大小可能会提高性能。但是，块缓存的实用性高度依赖于工作负载，因此有必要测试更大块缓存的好处。

不要将块缓存大小提高到内存压力阈值以上（默认为--memory_limit_hard_bytes的60％）,因为这会导致刷新行为较差，Kudu 1.8及更高版本的服务器在这种错误配置的情况下将拒绝启动。

堆采样 Heap Sampling

对于内存使用的高级调试，发布版本的Kudu默认启用堆采样（Heap Sampling）。这使得Kudu开发人员能够将内存使用与负责的具体代码行和数据结构关联起来。在报告与内存使用或明显的内存泄漏相关的错误时，堆剖面分析可以提供定位问题的定量数据。

如果启用了堆采样，可以通过访问http://tablet-server.example.com:8050/pprof/heap或http://master.example.com:8051/pprof/heap来获取当前采样的堆占用情况。输出是与其相关联的堆使用的带机器可读的堆栈跟踪信息。

与直接在Web浏览器中访问堆剖面页面相比，通常更有用的是使用作为gperftools开源项目的一部分分发的pprof工具。例如，拥有本地构建树的开发人员可以使用以下命令收集采样的堆使用情况并输出SVG图：

thirdparty/installed/uninstrumented/bin/pprof -svg  'http://localhost:8051/pprof/heap' > /tmp/heap.svg

生成的SVG可以在Web浏览器中可视化，或者发送到Kudu社区以帮助解决内存占用问题。

堆样本仅包含有关分配的摘要信息，不包含堆中的任何数据。在公共场合共享堆样本是安全的，不用担心泄露机密或敏感数据。

Slow DNS Lookups and nscd

为了在托管许多副本的节点上实现更好的可扩展性，我们建议您使用nscd（名称服务缓存守护进程）来缓存DNS名称解析和静态名称解析（通过/etc/hosts）。

当DNS查找速度较慢时，您将看到类似以下内容的日志消息

W0926 11:19:01.339553 27231 net_util.cc:129] Time spent resolving address for kudu-tserver.example.com: real 4.647s    user 0.000s     sys 0.000s

nscd（服务缓存守护进程）可以通过为最常见的名称服务请求（如密码、组和主机）提供缓存来缓解名称解析缓慢的问题。

请参阅您的操作系统文档，了解如何安装和启用 nscd。

三、使用Kudu错误

墓碑或STOOPED状态的副本 Tombstoned or STOPPED tablet replicas

用户可能会注意到，在tserver服务器上的一些副本处于停止状态，并无限期地留在服务器上。这些副本是墓碑,墓碑表示，该tserver服务器曾经拥有真正副本。

在分布式存储系统中，为了确保数据的可靠性和一致性，通常会有多个副本分散在不同的节点上。如果某个节点失效或者数据丢失，其他节点上的副本还可以用来恢复数据。这些副本就相当于数据的备份。而“墓碑”在这里可能是用来标记那些已经失效或者丢失的副本，表明它们曾经存在过，但现在不再可用。

例如，如果一个 tablet server 宕机，其副本被重新复制到其他地方，如果该 tablet server 重新加入集群，其副本将变成 tombstones。一个 tombstone 将一直存在，直到它所属的表被删除，或者同一 tablet 的新副本被放置在 tablet server 上。在 tablet server web UI 的 /tablets 页面上可以查看被删除的副本的数量和每个副本的详细信息。

Kudu用于复制的Raft共识算法在某些罕见情况下需要使用Tombstones以确保正确性。它们消耗的资源最少，不保存数据。它们不能被删除。

Corruption: checksum error on CFile block

Kudu 1.8.0之前的版本中，如果磁盘上的数据损坏，用户将在tserver日志中遇到包含“Corruption: checksum error on CFile block”的警告，并且在尝试扫描损坏的CFile块的 tablet 时在客户端侧出现错误。修复此损坏是一个手动过程。

要修复此问题，用户首先可以使用ksck工具对受影响的表或平板运行校验和扫描，以识别所有受影响的tserver。

sudo -u kudu kudu cluster ksck <master_addresses> -checksum_scan -tables=<tables>
sudo -u kudu kudu cluster ksck <master_addresses> -checksum_scan -tablets=<tablets>

如果每个tserver至少有一个副本没有返回损坏错误，则可以通过删除它们并使用远程副本删除工具强制它们从Leader重新复制来修复损坏的副本。

sudo -u kudu kudu remote_replica delete <tserver_address> <tablet_id> "Cfile Corruption"

如果所有副本都损坏，则已发生一些数据丢失。直到完成KUDU-2526为止，如果损坏的副本成为Leader并且现有的follower 副本被替换，这可能会发生。

如果数据丢失，您可以使用不安全的替换tablet工具将损坏的tablet替换为空tablet来修复表。

sudo -u kudu kudu tablet unsafe_replace_tablet <master_addresses> <tablet_id>

从1.8.0版本开始，Kudu将标记受影响的副本为失败，导致它们在其他地方自动重新复制。

清欢爱蹦跶

关注

19
点赞
踩
19

收藏

觉得还不错? 一键收藏
1
评论
KUDU常见的错误排查

kudu常见的问题解决办法
复制链接

扫一扫

专栏目录