管理 Kudu

原文链接 : http://kudu.apache.org/docs/administration.html

译文链接 : http://cwiki.apachecn.org/pages/viewpage.action?pageId=10813623

贡献者 : 小瑶 ApacheCN Apache中文网

Apache Kudu Administration ( 管理 Apache Kudu )

注意

Kudu 与Cloudera Manager 相比在独立安装中更容易管理。 有关使用 Kudu 与 Cloudera Manager 的更多详细信息，请参阅 Cloudera Kudu 文档 。

启动和停止 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必须是字符串 00000000000000000000000000000000all_masters空格分隔的 master 的列表，新的和现在的。列表中的每个条目必须是 <uuid>：<hostname>：<port> 格式的字符串 UUID master 以前记录的 UUIDhostname 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>hostnamemaster 以前记录的 hostname 和别名portmaster 以前记录的 RPC 端口号

10. 启动所有的 tablet servers

恭喜，集群已经迁移到多个 masters 了！要验证所有 master 是否正常工作，请考虑执行以下健康性检查：

• 使用浏览器访问每个 master 的 Web UI 。看看 /master page 。所有的 master 都应该被列在那里，一个主人在 LEADER 角色，其他的在 FOLLOWER 角色。每个 master 的 master 的内容应该是一样的。
• 使用 kudu 命令行工具在集群上运行 Kudu 系统检查（ ksck ）。有关详细信息，请参阅 使用 ksck 检查群集运行状况。

在多 Master 部署中从死亡的 Kudu Master 恢复

Kudu multi-master 部署功能通常在主机丢失的情况下。但是，重要的是更换死主;否则第二次故障可能会导致可用性的丢失，具体取决于可用 master 的数量。此工作流程描述如何更换 dead master 。

由于 KUDU-1620 ，无需重新启动现场主机即可执行此工作流程。因此，工作流需要一个维护窗口，尽管主要通常是快速重启。

注意

Kudu 还不支持主人的 Raft 配置更改。因此，如果部署是使用 DNS 别名创建的，则只能替换主服务器。有关详细信息，请参阅 multi-master 移动工作流程。

注意

该工作流程至少基本上熟悉 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 或别名portreference 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 检查群集运行状况。

使用 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 副本。