# 管理 Kudu
原文链接 : [http://kudu.apache.org/docs/administration.html](http://kudu.apache.org/docs/administration.html)
译文链接 : [http://cwiki.apachecn.org/pages/viewpage.action?pageId=10813623](http://cwiki.apachecn.org/pages/viewpage.action?pageId=10813623)
贡献者 : [小瑶](/display/~chenyao) [ApacheCN](/display/~apachecn) [Apache中文网](/display/~apachechina)
## Apache Kudu Administration ( 管理 Apache Kudu )
注意
**Kudu** 与**[Cloudera Manager](http://www.cloudera.com/content/www/en-us/products/cloudera-manager.html)** 相比在独立安装中更容易管理。 有关使用 **Kudu** 与 **Cloudera Manager** 的更多详细信息，请参阅 [**Cloudera Kudu** 文档](http://www.cloudera.com/documentation/kudu/latest/topics/kudu_installation.html) 。
## 启动和停止 Kudu 进程
重要
仅当使用操作系统软件包（例如 **rpm** 或 **deb** ）安装 **Kudu** 时，这些说明才是相关的。
1. 使用以下命令启动 **Kudu** 服务：
```
$ sudo service kudu-master start
$ sudo service kudu-tserver start
```
2. 要停止 **Kudu** 服务，请使用以下命令：
```
$ sudo service kudu-master stop
$ sudo service kudu-tserver stop
```
## Kudu Web 界面
**Kudu tablet servers** 和 **masters** 在内置的 **Web** 界面上显示有用的操作信息，
### Kudu Master Web Interface
**Kudu** 主进程在 **8051** 端口上为其 **Web** 界面提供服务。该界面暴露了几个页面，其中包含有关群集状态的信息：
* **tablet servers** 列表，其 **host names** 和上次心跳时间。
* 表格列表，包括每个表的 **schema **和 **tablet location information** 信息。
* 您可以将其粘贴到 **Impala** **Shell** 中以将现有表添加到 Impala 的已知数据源列表中的 **SQL** 代码。
### Kudu Tablets Server Web 界面
每个**tablet server** 都提供端口 **8050** 上的 **Web** 界面。该界面显示有关服务器上托管的每个**tablet** 的信息，其当前状态以及有关维护后台操作的调试信息。
### 常见的 Web 界面页面
**Kudu masters** 和 **tablet servers** 通过其 **Web** 界面暴露了一组通用的信息：
* HTTP 访问服务器日志。
* 一个 **/rpcz** 端点，通过 **JSON** 列出当前运行的 **RPC** 。
* 页面提供了有关进程不同组件的内存使用情况的概述和详细信息。
* 关于当前配置标志的信息。
* 关于当前正在运行的线程及其资源消耗的信息。
* 一个 **JSON** 端点显示有关服务器的指标。
* 有关守护程序部署版本号的信息。
这些界面是从每个守护进程的 **Web UI** 的 **landing page** 链接的。
## Kudu Metrics ( 指标 )
**Kudu** 守护进程公开了大量的指标。一些指标与整个服务器进程相关联，而其他指标与特定 **tablet** 副本相关联。
### 列出可用的指标
**Kudu** 服务器的全套可用度量值可以通过特殊的命令行标志进行转储：
```
$ kudu-tserver --dump_metrics_json
$ kudu-master --dump_metrics_json
```
这将输出一个大的 **JSON** 文档。每个指标都表示其名称，标签，描述，单位和类型。由于输出是 **JSON** 格式的，所以可以轻松地将这些信息进行解析，并将其馈送到从 **Kudu** 服务器收集指标的其他工具中。
### 通过HTTP收集指标
可以通过访问/指标通过其 **HTTP** 接口从服务器进程收集度量。此页面的输出是 **JSON** ，可以通过监视服务轻松解析。此端点在其查询字符串中接受几个 **GET** 参数：
* **/metrics?metrics=<substring1>,<substring2>,…** - 将返回的指标限制为至少包含一个提供的子字符串的指标。子串也匹配实体名称，因此可用于收集特定 **tablet** 的指标。
* **/metrics?include_schema=1** - 包括 JSON 输出中的度量架构信息，如单位，描述和标签。通常这些信息可以节省空间。
* **/metrics?compact=1** - 从结果 JSON 中消除不必要的空格，从远程主机获取此页面时可以减少带宽。
* **/metrics?include_raw_histograms=1** - 包括直方图指标的原始存储桶和值，可实现随时间和跨主机的百分位数度量的准确聚合。
例如：
```
$ curl -s 'http://example-ts:8050/metrics?include_schema=1&metrics=connections_accepted'
```
```
[
{
"type": "server",
"id": "kudu.tabletserver",
"attributes": {},
"metrics": [
{
"name": "rpc_connections_accepted",
"label": "RPC Connections Accepted",
"type": "counter",
"unit": "connections",
"description": "Number of incoming TCP connections made to the RPC server",
"value": 92
}
]
}
]
```
```
$ curl -s 'http://example-ts:8050/metrics?metrics=log_append_latency'
```
```
[
{
"type": "tablet",
"id": "c0ebf9fef1b847e2a83c7bd35c2056b1",
"attributes": {
"table_name": "lineitem",
"partition": "hash buckets: (55), range: [(<start>), (<end>))",
"table_id": ""
},
"metrics": [
{
"name": "log_append_latency",
"total_count": 7498,
"min": 4,
"mean": 69.3649,
"percentile_75": 29,
"percentile_95": 38,
"percentile_99": 45,
"percentile_99_9": 95,
"percentile_99_99": 167,
"max": 367244,
"total_sum": 520098
}
]
}
]
```
注意
所有直方图和计数器都是从服务器开始时间开始测量的，收集后不会重置。
### 收集指标到日志
**Kudu** 可以配置为使用 **--metrics_log_interval_ms** 标志将其所有度量值定期转储到本地日志文件。将此标志设置为将度量值写入日志文件的时间间隔。
度量日志将与其他 **Kudu** 日志文件一样写入与其相同的目录，具有相同的命名格式。任何指标日志文件达到 **64MB** 未压缩后，日志将被滚动，上一个文件将被 **gzip** 压缩。
生成的日志文件有三个空格分隔的字段。第一个字段是单词指标。第二个字段是自 **Unix** 纪元以来的微秒的当前时间戳。第三个是使用紧凑的 **JSON** 编码在服务器上的所有指标的当前值。编码与通过上述 **HTTP** 获取的指标相同。
注意
虽然度量记录自动滚动并压缩以前的日志文件，但它不会删除旧的日志文件。由于度量记录可以使用大量的磁盘空间，因此请考虑设置系统实用程序来监视日志目录中的空间并归档或删除旧段。
## 常见的 Kudu 工作流程
### 迁移到多个 Kudu Master
为了获得高可用性并避免出现单点故障，**Kudu** 集群应该由多个主人创建。许多 **Kudu** 集群是由一个单一的主人创建的，无论是简单的还是由于 **Kudu** 多主人的支持在当时仍然是实验性的。此工作流演示如何迁移到多主配置。
注意
将工作流添加到现有的多主配置中是不安全的。不要为此目的使用它。
注意
该工作流程至少基本上熟悉 **Kudu** 配置管理。如果使用 **Cloudera Manager（CM）** ，工作流程也预先假定它是熟悉的。
注意
以下所有命令行步骤都应该像 **Kudu** **UNIX** 用户一般执行。
#### 准备迁移
1. 建立维护窗口（一小时应该足够）。在此期间，**Kudu** 集群将不可用。
2. 决定使用多少 **masters** 。 **masters** 的数量应该是奇数。建议使用三或五个节点主配置;他们可以容忍一两个故障。
3. 对现有 **master** 执行以下准备步骤：
* 识别和记录主数据所在的目录。如果使用 **Kudu** 系统软件包，则默认值为 **/var/lib/kudu/master** ，但可以通过 **fs_wal_dir** 和 **fs_data_dirs** 配置参数进行自定义。请注意，如果您将 **fs_data_dirs** 设置为除 **fs_wal_dir** 值之外的某些目录，则应将其明确包含在其中还包含 fs_wal_dir 的每个命令中。
* 识别和记录 **master** 正在为 **RPC** 使用的端口。默认端口值为 **7051** ，但可能使用 **rpc_bind_addresses** 配置参数进行了自定义。
* 识别 **master** 的 **UUID** 。可以使用以下命令获取它：
```
$ kudu fs dump uuid --fs_wal_dir=<master_data_dir> 2>/dev/null
```
**master_data_dir**
现有 master 以前记录的数据目录
**例子**
```
$ kudu fs dump uuid --fs_wal_dir=/var/lib/kudu/master 2>/dev/null
4aab798a69e94fab8d77069edff28ce0
```
* 可选：配置 **master** 的 **DNS** 别名。别名可能是 **DNS cname** （如果机器已经在 **DNS** 中有 **A** 记录）， **A** 记录（如果机器仅由其 **IP** 地址知道）或 **/etc/hosts** 中的别名。别名应该是 **master** 的抽象表示（例如，**master - 1**）。
注意
没有 **DNS** 别名，不可能从永久性主机故障中恢复，因此强烈建议。
4. 为每个新的主设备执行以下准备步骤：
* * 在集群中选择一个未使用的机器。主机生成的负载很小，因此它可以与其他数据服务或负载生成过程共同配置，尽管与其他 **Kudu** 主机不同，配置相同。
* 确保 **Kudu** 通过系统包装（在这种情况下应安装 **kudu** 和 **kudu-master** 包装）或通过其他方式安装在机器上。
* 选择并记录主数据将存在的目录。
* 选择并记录主机应用于 **RPC** 的端口。
* 可选：配置主服务器的 **DNS** 别名（例如，**master-2** ， **master-3** 等）。
#### 执行迁移
1. 停止整个集群中的所有 **Kudu** 进程。
2. 格式化每个新 **master **上的数据目录，并记录生成的 **UUID** 。使用以下命令序列：
```
$ kudu fs format --fs_wal_dir=<master_data_dir>
$ kudu fs dump uuid --fs_wal_dir=<master_data_dir> 2>/dev/null
```
**master_data_dir**
新 master 以前录制的数据目录。
**示例**
```
$ kudu fs format --fs_wal_dir=/var/lib/kudu/master
$ kudu fs dump uuid --fs_wal_dir=/var/lib/kudu/master 2>/dev/null
f5624e05f40649b79a757629a69d061e
```
3. 如果使用 **CM** ，现在添加新的 **Kudu master roles** ，但不要启动它们。
* 如果使用 **DNS** 别名，请使用该主机的别名覆盖每个角色（包括现有主角色）的 **“Master Address”** 参数的空值。
* 如果使用非默认 **RPC** 端口值，请添加端口号（以冒号分隔）。
4. 使用以下命令重写 **master** 的 **Raft** 配置，在现有主机上执行：
```
$ kudu local_replica cmeta rewrite_raft_config --fs_wal_dir=<master_data_dir> <tablet_id> <all_masters>
```
**master_data_dir**
现有 master 以前记录的数据目录
**tablet_id**必须是字符串 00000000000000000000000000000000**all_masters**空格分隔的 master 的列表，新的和现在的。列表中的每个条目必须是 <uuid>：<hostname>：<port> 格式的字符串 **UUID**
master 以前记录的 UUID
**hostname**
master 以前记录的 hostname 或 别名
**port**
master 以前记录的 RPC 的端口号
**示例**
```
$ kudu local_replica cmeta rewrite_raft_config --fs_wal_dir=/var/lib/kudu/master 00000000000000000000000000000000 4aab798a69e94fab8d77069edff28ce0:master-1:7051 f5624e05f40649b79a757629a69d061e:master-2:7051 988d8ac6530f426cbe180be5ba52033d:master-3:7051
```
5. 修改现有 **master** 和新 **masters** 的 **master_addresses** 配置参数的值。新值必须是所有主节点的逗号分隔列表。每个条目是 **<hostname>：<port>** 形式的字符串
**hostname**
master 以前记录的 hostname 和 别名
**port**
master 以前记录的 RPC 端口号
6. 启动现有的 **master**
7. 使用以下命令将 **master** 数据复制到每个新 **master** ，在每台新 **master** 上执行：
```
$ kudu local_replica copy_from_remote --fs_wal_dir=<master_data_dir> <tablet_id> <existing_master>
```
**master_data_dir**
新 master 以前记录的数据目录
**tablet_id**
必须是字符串 00000000000000000000000000000000
**existing_master**
现有 master 的 RPC 地址必须是 <hostname>：<port> 形式的字符串
**hostname**
现有 master 以前记录的 hostname 或别名
**port**
现有 master 以前记录的 RPC 端口号
**示例**
```
$ kudu local_replica copy_from_remote --fs_wal_dir=/var/lib/kudu/master 00000000000000000000000000000000 master-1:7051
```
8. 启动所有的新的 **master**
注意
如果使用 **CM** ，请跳过下一步。
9. 修改每个 **tablet** **server** 的 **tserver_master_addrs** 配置参数的值。新值必须是以逗号分隔的主文件列表，其中每个条目是 **<hostname>** 形式的字符串 ：**<port>**
**hostname**
master 以前记录的 hostname 和别名
**port**
master 以前记录的 RPC 端口号
10. 启动所有的 **tablet servers**
恭喜，集群已经迁移到多个 **masters** 了！要验证所有 **master** 是否正常工作，请考虑执行以下健康性检查：
* 使用浏览器访问每个 **master** 的 **Web UI** 。看看 **/master page** 。所有的 **master** 都应该被列在那里，一个主人在 **LEADER** 角色，其他的在 **FOLLOWER** 角色。每个 **master** 的 **master** 的内容应该是一样的。
* 使用 **kudu** 命令行工具在集群上运行 **Kudu** 系统检查（ **ksck** ）。有关详细信息，请参阅 [使用 **ksck** 检查群集运行状况](/pages/viewpage.action?pageId=10813623)。
### 在多 Master 部署中从死亡的 Kudu Master 恢复
**Kudu multi-master** 部署功能通常在主机丢失的情况下。但是，重要的是更换死主;否则第二次故障可能会导致可用性的丢失，具体取决于可用 **master** 的数量。此工作流程描述如何更换 **dead master** 。
由于 [KUDU-1620](https://issues.apache.org/jira/browse/KUDU-1620) ，无需重新启动现场主机即可执行此工作流程。因此，工作流需要一个维护窗口，尽管主要通常是快速重启。
注意
**Kudu** 还不支持主人的 **Raft** 配置更改。因此，如果部署是使用 **DNS** 别名创建的，则只能替换主服务器。有关详细信息，请参阅[ **multi-master** 移动工作流程](/pages/viewpage.action?pageId=10813623)。
注意
该工作流程至少基本上熟悉 **Kudu** 配置管理。如果使用 **Cloudera Manager （CM）** ，工作流程也预先假定它是熟悉的。
注意
以下所有命令行步骤都应该像 **Kudu** **UNIX** 用户一般执行。
#### 为恢复做准备
1. 确保 **dead master** 机器正常并且真正死亡。采取一切必要步骤，防止意外重启;这对于集群后恢复来说可能是相当危险的。
2. 选择剩下的仍然活着的 **master** 之一作为恢复的基础。这个工作流程的其余部分将把这个主机称为 “**reference**” 主机。
3. 选择 **new master** 所在的群集中未使用的机器。**master** 生成的负载很小，因此它可以与其他数据服务或负载生成过程共同配置，尽管与其他 **Kudu** 主机不同，配置相同。这个工作流程的其余部分将把这个主机称为 “**replacement**” 主机。
4. 为 **replacement master** 执行以下准备步骤：
* 确保 **Kudu** 通过系统包装（在这种情况下应安装 **kudu** 和 **kudu-master** 包装）或通过其他方式安装在机器上。
* 选择并记录 **master** 数据将存在的目录。
5. 为每个现在活着的 **master** 执行以下步骤：
* 识别和记录主数据所在的目录。如果使用 **Kudu** 系统软件包，则默认值为 **/var/lib/kudu/master** ，但可以通过 **fs_wal_dir** 和 **fs_data_dirs** 配置参数进行自定义。请注意，如果您将 **fs_data_dirs** 设置为除 **fs_wal_dir** 值之外的某些目录，则应将其明确包含在其中还包含 **fs_wal_dir** 的每个命令中。
* 识别和记录 **master** 的 **UUID** 。可以使用以下命令获取它：
```
$ kudu fs dump uuid --fs_wal_dir=<master_data_dir> 2>/dev/null
```
**master_data_dir**
活着 master 以前记录的数据目录
**示例**
```
$ kudu fs dump uuid --fs_wal_dir=/var/lib/kudu/master 2>/dev/null
80a82c4b8a9f4c819bab744927ad765c
```
6. 对 **reference master** 执行以下准备步骤：
* 识别和记录主数据所在的目录。如果使用 **Kudu** 系统软件包，则默认值为 **/var/lib/kudu/master** ，但可以通过 **fs_wal_dir** 和 **fs_data_dirs** 配置参数进行自定义。请注意，如果您将 **fs_data_dirs** 设置为除 **fs_wal_dir** 值之外的某些目录，则应将其明确包含在其中还包含 fs_wal_dir 的每个命令中。
* 使用以下命令识别并记录集群中每个 **master** 的 **UUID** ：
```
$ kudu local_replica cmeta print_replica_uuids --fs_wal_dir=<master_data_dir> <tablet_id> 2>/dev/null
```
**master_data_dir**
reference master 以前记录的数据目录
**tablet_id**
必须是字符串 00000000000000000000000000000000
**示例**
```
$ kudu local_replica cmeta print_replica_uuids --fs_wal_dir=/var/lib/kudu/master 00000000000000000000000000000000 2>/dev/null
80a82c4b8a9f4c819bab744927ad765c 2a73eeee5d47413981d9a1c637cce170 1c3f3094256347528d02ec107466aef3
```
7. 使用以前记录的两个 **UUID** 列表（一个用于所有 **live master** ，一个用于所有 **master** ），确定并记录（通过消除处理） **dead master** 的 **UUID** 。
#### 执行恢复
1. 使用以前记录的 **dead master** 主机的 **UUID** 格式化 **replacement master** 上的数据目录。使用以下命令序列：
```
$ kudu fs format --fs_wal_dir=<master_data_dir> --uuid=<uuid>
```
**master_data_dir**
replacement master 以前记录的数据目录
**uuid**
dead master 以前记录的 UUID
**例子**
```
$ kudu fs format --fs_wal_dir=/var/lib/kudu/master --uuid=80a82c4b8a9f4c819bab744927ad765c
```
2. 使用以下命令将 **master** 数据复制到 **replacement master** ：
```
$ kudu local_replica copy_from_remote --fs_wal_dir=<master_data_dir> <tablet_id> <reference_master>
```
**master_data_dir**
replacement master 以前记录的数据目录
**tablet_id**
必须是字符串 00000000000000000000000000000000
**reference_master**
reference_master 的 RPC 地址必须是 <hostname>：<port> 形式的字符串
**hostname**
reference master 以前记录的 hostname 或别名
**port**
reference master 之前记录的 RPC 的端口号
**示例**
```
$ kudu local_replica copy_from_remote --fs_wal_dir=/var/lib/kudu/master 00000000000000000000000000000000 master-2:7051
```
3. 如果使用 **CM** ，请立即添加替换的 **Kudu master role** ，但不要启动它。
* 使用 **replacement master** 的别名覆盖** new role** 的 **“ Master Address”** 参数的空值。
* 如果使用非默认 **RPC** 端口值，请添加端口号（以冒号分隔）。
4. 重新配置 **dead master** 的 **DNS** 别名以指向 **replacement master** 。
5. 启动** replacement master** 。
6. 重新启动现有的 **live master** 。这导致短暂的可用性中断，但是只有 masters 回来才能持续。
恭喜，**dead master** 已经被替换了！要验证所有 **master** 是否正常工作，请考虑执行以下健康性检查：
* 使用浏览器访问每个 **master** 的 **Web UI** 。看看 **/master page** 。所有的主人都应该被列在那里，一个 **master** 在 **LEADER** 角色，其他的在 **FOLLOWER** 角色。每个 **master** 的 **master** 的内容应该是一样的。
* 使用 **kudu** 命令行工具在集群上运行 **Kudu** 系统检查（ **ksck** ）。有关详细信息，请参阅 [使用 ksck 检查群集运行状况](/pages/viewpage.action?pageId=10813623)。
### 使用 ksck 检查集群运行状况
**kudu CLI** 包括一个名为 **ksck** 的工具，可用于检查群集运行状况和数据完整性。 **ksck** 会发现问题，如副本不足的 **tablet** ，无法连接的 **tablet server** 或没有 **leader** 的 **tablet** 。
应从命令行运行 **ksck** ，并要求指定 master address 的完整列表：
```
$ kudu cluster ksck master-01.example.com,master-02.example.com,master-03.example.com
```
要查看 **ksck** 可用选项的完整列表，请使用 **--help** 标志。如果集群是健康的， **ksck** 将打印成功消息，并返回零（成功）退出状态。
```
Connected to the Master
Fetched info from all 1 Tablet Servers
Table IntegrationTestBigLinkedList is HEALTHY (1 tablet(s) checked)
The metadata for 1 table(s) is HEALTHY
OK
```
如果集群不健康，例如，如果 **tablet server** 进程已停止，则 **ksck** 将报告问题并返回非零退出状态：
```
Connected to the Master
WARNING: Unable to connect to Tablet Server 8a0b66a756014def82760a09946d1fce
(tserver-01.example.com:7050): Network error: could not send Ping RPC to server: Client connection negotiation failed: client connection to 192.168.0.2:7050: connect: Connection refused (error 61)
WARNING: Fetched info from 0 Tablet Servers, 1 weren't reachable
Tablet ce3c2d27010d4253949a989b9d9bf43c of table 'IntegrationTestBigLinkedList'
is unavailable: 1 replica(s) not RUNNING
8a0b66a756014def82760a09946d1fce (tserver-01.example.com:7050): TS unavailable [LEADER]
Table IntegrationTestBigLinkedList has 1 unavailable tablet(s)
WARNING: 1 out of 1 table(s) are not in a healthy state
==================
Errors:
==================
error fetching info from tablet servers: Network error: Not all Tablet Servers are reachable
table consistency check error: Corruption: 1 table(s) are bad
FAILED
Runtime error: ksck discovered errors
```
为了验证数据完整性，可以设置可选的 **--checksum_scan** 标志，通过扫描每个 **tablet** 副本并比较结果，可以确保集群具有一致的数据。 ** --tables** 或 **--tablets** 标志可用于将校验和扫描的范围分别限制在特定的表格或 **tablet** 上。例如，可以使用以下命令对 **IntegrationTestBigLinkedList** 表上的数据完整性进行检查：
```
$ kudu cluster ksck --checksum_scan --tables IntegrationTestBigLinkedList master-01.example.com,master-02.example.com,master-03.example.com
```
### 从磁盘故障恢复
**Kudu tablet servers** 无法恢复磁盘故障。当包含数据目录或预写日志（ **WAL** ）的磁盘死机时，必须重建整个 **tablet server**。在 **tablet server** 发生故障后， **Kudu** 会在其他服务器上自动重新复制 **tablet** ，但需要手动干预才能将失败的 **tablet server** 还原到运行状态。
在磁盘故障后恢复 **tablet servers** 的第一步是更换发生故障的磁盘，或从数据目录 **and/or WAL** 配置中删除出现故障的磁盘。接下来，必须删除数据目录和 **WAL** 目录的内容。例如，如果 **tablet servers** 配置了**--fs_wal_dir = /data/0/kudu-tserver-wal** 和 **--fs_data_dirs = /data/1/kudu-tserver/data/2/kudu-tserver** ，则以下命令将删除数据目录和 **WAL** 目录内容：
```
$ rm -rf /data/0/kudu-tserver-wal/* /data/1/kudu-tserver/* /data/2/kudu-tserver/*
```
在 **WAL** 和数据目录被清空之后，可以启动 **tablet servers** 进程。当使用系统包安装 **Kudu** 时，通常使用服务：
```
$ sudo service kudu-tserver start
```
一旦 **tablet servers** 再次运行，就会根据需要在其上创建新的 **tablet** 副本。
