kudu手册：中文翻译版 - 7、Apache kudu管理 - 《只能学一点点》

7.1、启动和停止Kudu进程
7.2、kuduWeb界面
7.3、kudu指标
7.4、机架感知
7.5、备份和恢复
- 7.5.1、逻辑备份和恢复
- 7.5.2、整个节点的物理备份
7.6、常见的kudu工作流

本文档适用于Apache Kudu 1.15.0版本。请参考适用于Kudu集群版本的相应版本的文档。

7.1、启动和停止Kudu进程

这些说明只适用于使用操作系统软件包(例如rpm或deb)安装Kudu的情况。

7.2、kuduWeb界面

Kudu平板电脑服务器和主机在内置的web界面上公开有用的操作信息，

7.2.1、Kudu Master Web Interface

Kudu主进程在8051端口上提供web接口。该接口公开了几个包含集群状态信息的页面:

一个平板电脑服务器的列表，它们的主机名，以及它们最后一次心跳的时间。
表列表，包括每个表的模式和平板位置信息。
可以粘贴到Impala Shell中以将现有表添加到Impala的已知数据源列表中的SQL代码。

7.2.2、Kudu tablet服务器Web界面

每个平板电脑服务器在8050端口上提供一个web界面。该接口公开关于服务器上每个平板电脑的信息、当前状态以及关于维护后台操作的调试信息。

7.2.3、常用Web界面页面

Kudu主机和平板电脑服务器都通过它们的web界面公开了一组共同的信息:

对服务器日志的HTTP访问。
一个/rpcz端点，它通过JSON列出当前运行的rpc。
提供关于进程的不同组件的内存使用的概述和详细信息的页面。
关于当前配置标志集的信息。
有关当前运行的线程及其资源消耗的信息。
一个暴露服务器度量的JSON端点。
关于守护进程部署的版本号的信息。

这些接口从每个守护进程的web UI的登录页面链接。

7.3、kudu指标

Kudu守护进程暴露了大量的指标。一些指标与整个服务器进程相关联，而其他指标与特定的平板电脑副本相关联。

7.3.1、列出可用的指标

Kudu服务器的所有可用指标可以通过一个特殊的命令行标志转储:

$ kudu-tserver --dump_metrics_json
$ kudu-master --dump_metrics_json

这将输出一个大型JSON文档。每个度量表示它的名称、标签、描述、单位和类型。因为输出是json格式的，所以可以很容易地解析该信息并将其提供给从Kudu服务器收集指标的其他工具。

7.3.2、通过HTTP收集指标

可以通过访问/ Metrics从服务器进程的HTTP接口收集指标。此页面的输出是JSON，以便通过监视服务进行解析。这个端点在其查询字符串中接受几个GET参数:

/metrics?metrics=,,… -将返回的度量限制为至少包含一个提供的子字符串。子字符串还匹配实体名称，因此可以用于收集特定平板的指标。
/metrics?include_schema=1 -在JSON输出中包含度量模式信息，如单元、描述和标签。为了节省空间，通常会省略这些信息。
/metrics?compact=1 -消除结果JSON中不必要的空白，这会减少从远程主机获取该页面时的带宽。
/metrics?include_raw_histograms=1—包括直方图度量的原始桶和值，允许在不同时间和不同主机之间准确地聚合百分比度量。
/metrics?level=info -根据严重性级别限制返回的度量。级别是有序的，较低的级别包括其上的级别。如果没有指定级别，则使用调试来包括所有度量。有效值为:
- debug-对诊断有帮助但通常在正常操作期间不被监控的指标。
- info -通常有用的指标，运营商总是想要可用，但在正常情况下可能不会被监控。
- warn—通常可以指示可能需要更多调查的操作异常的度量。

例如:

$ 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
            }
        ]
    }
]

所有直方图和计数器都是从服务器启动时间开始测量的，在收集时不会重置。

7.3.3、诊断日志记录

Kudu可以配置为将各种诊断信息转储到本地日志文件中。诊断日志将被写入与其他Kudu日志文件相同的目录中，以类似的命名格式，替换诊断而不是类似INFO的日志级别。在任何未压缩的诊断日志文件达到64MB后，将滚动该日志，并将前一个文件压缩为gzip。

诊断日志中的每一行由以下组件组成:

人类可读的时间戳格式与其他Kudu日志文件相同。
记录的类型。例如，一个度量记录由单词度量组成。
一个机器可读的时间戳，以Unix时代以来的微秒为单位。
记录本身。

目前，诊断记录的唯一类型是服务器指标的定期转储。每个记录都以紧凑的JSON格式编码，服务器试图省略自前一个记录以来没有改变的任何指标。此外，没有增加的计数器将被省略。否则，JSON记录的格式与上述HTTP端点公开的格式相同。

度量转储到诊断日志的频率使用——metrics_log_interval_ms标志配置。缺省情况下，Kudu每60秒记录一次度量值。

7.4、机架感知

从1.9版开始，Kudu支持机架感知特性。Kudu的普通复制方法确保了单个节点故障时集群的可用性。然而，集群很容易受到多个节点相关故障的影响。例如，如果机架顶交换机故障，数据中心同一机架上的所有物理主机可能同时不可用。Kudu的机架感知功能可以防止某些类型的相关故障，比如数据中心的整个机架的故障。如果集群中至少定义了三个不同的位置，那么机架感知可以提高Kudu集群的可用性。

Kudu的机架感知功能的第一个元素是位置分配。当平板电脑服务器或客户端向主服务器注册时，主服务器会给它分配一个位置。位置是一个以/开头的/分隔的字符串，每个/分隔的组件由集合[A- za - z0 -9-.]中的字符组成。例如，/dc-0/rack-09是有效位置，而rack-04和/rack=1不是有效位置。因此位置字符串类似于UNIX文件的绝对路径，其中目录和文件名中的字符被限制为集合[a-zA-Z0-9-.]。目前，Kudu还没有使用位置的层次结构，但将来可能会使用。位置分配是由用户提供的命令完成的，它的路径应该使用——location_mapping_cmd主标志来指定。该命令应该只有一个参数，即tablet服务器或客户机的IP地址或主机名，并返回tablet服务器或客户机的位置。确保所有的Kudu master都使用相同的位置映射命令。

Kudu的机架感知功能的第二个要素是布局策略，这是

不要将平板电脑服务器上的大部分副本放在同一位置。
当在平板服务器上放置新创建的副本和重新复制现有的平板时，主服务器将尝试以符合放置策略的方式放置副本。例如,与五个平板电脑服务器集群,B, C, D和E,与各自的位置/ L0 / L0 / L1 / L1 / L2,遵守政策新3 x位置复制平板电脑可能有它的副本放在,C和E,但a, B和C,因为平板电脑会有2/3位置/ L0副本。另一个例子是，如果药片在药片服务器a、C和E上有副本，然后C出现故障，则必须将替换副本放在D上，以符合放置策略。

在一个Kudu集群中至少定义三个位置是必要的，这样可以通过位置感知特性提高其高可用性。如果在Kudu集群中只定义了两个或一个位置，那么任何平板电脑都会不可避免地将其大部分副本放在一个位置。

在不可能以符合放置策略的方式放置副本的情况下，Kudu将违反该策略并放置副本。例如，使用上一段描述的设置，如果一台平板电脑在平板电脑服务器a、C和E上有副本，然后E出现故障，Kudu会将该平板电脑重新复制到B或D服务器上，这违反了放置策略，而不是无限期地保持平板电脑复制不足。如果可能的话，kudu集群rebalance工具可以重新建立放置策略。如果集群刚刚被配置为使用机架感知特性，并且现有副本需要移动以符合放置策略，那么kudu集群rebalance工具还可以用于在集群上建立放置策略。有关更多信息，请参见在支持机架的集群上运行平板电脑再平衡工具。

Kudu的机架感知功能的第三个也是最后一个元素是利用客户端位置来寻找“附近”的服务器。如前所述，主机在连接到集群时还为客户机分配一个位置。当以CLOSEST_REPLICA模式扫描时，客户端(无论是Java、c++还是Python)使用自己的位置和集群中的平板服务器的位置来选择“附近的”副本。客户端按照以下顺序选择要扫描的副本:

1、在同一台主机上的平板服务器上扫描一个副本(如果有的话)。
2、在同一位置的平板电脑服务器上扫描一个副本(如果有的话)。
3、扫描副本。

例如,使用上述集群设置,如果一个客户在同一主机作为平板电脑服务器扫描平板电脑与平板电脑服务器上的副本,C和E在CLOSEST_REPLICA模式下,它会选择扫描的副本,因为客户端和复制在同一个主机上。如果客户机使用tablet服务器B、C和E上的副本扫描tablet，那么它将选择从B上的副本进行扫描，因为它与客户机位于相同的位置/L0。如果有多个副本满足某个条件，则任意选择一个副本。

7.5、备份和恢复

7.5.1、逻辑备份和恢复

从Kudu 1.10.0开始，Kudu支持通过Apache Spark实现的作业进行全表备份和增量表备份。此外，它还支持通过使用Apache Spark实现的恢复作业从完全备份和增量备份中恢复表。

由于Kudu备份和恢复作业使用Apache Spark，请确保按照Spark文档在您的环境中安装了Apache Spark。另外，请查看Apache Spark文档中的提交应用程序。

7.5.1.1、备份表

如果需要备份一个或多个Kudu表，可以使用KuduBackup Spark作业。第一次为表运行作业时，将运行完全备份。额外的运行将执行增量备份，只包含自初始完全备份以来更改的行。通过将——forceFull标志传递给备份作业，可以在任何时候强制执行一组新的完整备份。

进行备份时使用的通用标志是:

—rootPath:输出备份数据的根路径。接受任何兼容spark的路径。
- rootPath中使用的目录结构请参见备份目录结构。
—kuduMasterAddresses:逗号分隔的Kudu主机地址。默认值:localhost

…: 要备份的表列表。

注意:通过传递——help标志，您可以随时看到完整的Job选项列表。

下面是一个完整的KuduBackup作业执行示例，它将表foo和bar备份到HDFS目录kudu-backups:

spark-submit --class org.apache.kudu.backup.KuduBackup kudu-backup2_2.11-1.14.0.jar \
  --kuduMasterAddresses master1-host,master-2-host,master-3-host \
  --rootPath hdfs:///kudu-backups \
  foo bar

7.5.1.2、从备份中恢复表

如果需要恢复一个或多个Kudu表，可以使用KuduRestore Spark作业。对于每个备份的表，KuduRestore作业将恢复完全备份和每个关联的增量备份，直到恢复全表状态。恢复完整和增量备份的完整系列是可能的，因为备份是通过备份元数据中的from_ms和to_ms字段链接的。默认情况下，恢复作业将创建与备份的表同名的表。如果希望在不影响现有表的情况下侧面加载表，可以传递——tableSuffix向每个恢复的表添加后缀。

恢复时使用的通用标志是:

—rootPath:备份数据的根路径。接受任何兼容spark的路径。
- rootPath中使用的目录结构请参见备份目录结构。
-kuduMasterAddresses: 逗号分隔的Kudu主机地址。默认值:localhost
—createTables:如果设置为true，则恢复进程创建表。如果目标表已经存在，则设置为false。默认值:真的。
—tableSuffix: 如果设置，添加到恢复的表名的后缀。仅当createTables为true时使用。
—timestampMs:UNIX时间戳，以毫秒为单位，定义了在选择恢复候选项时使用的最新时间。默认值:System.currentTimeMillis ()

…: 要恢复的表列表。

注意:通过传递——help标志，您可以随时看到完整的作业选项列表。

下面是一个完整的KuduRestore作业执行示例，它将从HDFS目录kudu-backups中恢复表foo和bar:

spark-submit --class org.apache.kudu.backup.KuduRestore kudu-backup2_2.11-1.14.0.jar \
  --kuduMasterAddresses master1-host,master-2-host,master-3-host \
  --rootPath hdfs:///kudu-backups \
  foo bar

7.5.1.3、备份工具

另外还有一个备份工具jar可以提供一些备份探索和垃圾收集功能。这个jar不直接使用Spark，只需要运行Hadoop类路径即可。
命令:

list:在rootPath中列出备份。
clean:清理rootPath下的旧备份数据。

注意:通过传递——help标志，您可以随时看到完整的命令选项列表。

下面是一个打印命令选项的执行示例:

java -cp $(hadoop classpath):kudu-backup-tools-1.14.0.jar org.apache.kudu.backup.KuduBackupCLI --help

7.5.1.4、备份目录结构

rootPath中的备份目录结构被认为是一个内部细节，在将来的Kudu版本中可能会更改。此外，数据和元数据文件的格式和内容只用于备份和恢复过程，在将来的Kudu版本中可以更改。也就是说，在使用Kudu备份时，了解备份rootPath的结构和它的使用方式可能会很有用。
rootPath下的备份目录结构如下:

/<rootPath>/<tableId>-<tableName>/<backup-id>/
   .kudu-metadata.json
   part-*.<format>

rootPath:用于区分不同的备份组、作业或关注点。
tableId:被备份表的唯一内部ID。
tableName:要备份的表名。
- 注意:表名是URL编码，以防止路径问题。
backup-id:唯一标识/分组单个备份运行的数据的方法。
.kudu-metadata。json:包含所有元数据，以支持重新创建表、按时间链接备份和处理数据格式更改。

最后写入，这样失败的备份将没有元数据文件，在恢复时或备份链接时不会被考虑。

part-*.
: 包含表数据的数据文件。
- 目前每个Kudu分区有一个部分文件。
- 增量备份在末尾包含一个附加的“RowAction”字节列。
- 目前唯一支持的格式/后缀是拼花

7.5.1.5、故障排除

生成一个表列表
要生成要备份的表列表，使用kudu表列表工具和grep可能会很有用。下面的例子将生成my_db开头的所有表的列表:

kudu table list <master_addresses> | grep "^my_db\.*" | tr '\n' ' '

注意:此列表也可以保存为备份过程的一部分，以便在恢复时使用。

spark 调优
通常，Spark作业被设计为只需要最少的调优和配置就可以运行。您可以通过使用Spark的配置选项来调整executor和资源的数量，以提高并行性和性能。

如果您的表非常宽，而您的默认内存分配相当低，则可能会看到作业失败。要解决此问题，请增加Spark执行器内存。保守的经验法则是每50列1 GiB。

如果您的Spark资源大大超出了Kudu集群的规模，那么您可能希望限制在恢复过程中允许运行的并发任务的数量。

在Kudu 1.9和更早的版本上进行备份
如果您的Kudu集群是1.9或更早版本，您仍然可以使用Kudu 1.10中引入的备份工具来备份您的表。但是，由于增量备份特性需要更改服务器端，因此只能进行完全备份。备份表的过程与上面所述相同，但是您需要下载并使用Kudu 1.10+版本中的Kudu -backup jar。在运行备份作业之前，您应该通过设置—tablet_history_max_age_sec=604800来调整服务器的配置。这是Kudu 1.10+中的新默认值，以确保长时间运行的备份任务能够成功且一致地完成。此外，在运行备份时，您需要通过——forceFull来禁用增量备份特性。现在，每次运行作业都会进行一次完整备份。

定期进行完全备份要比增量备份耗费更多的资源和时间。建议尽快升级到Kudu 1.10+。

7.5.2、整个节点的物理备份

Kudu还没有提供内置的物理备份和恢复功能。但是，可以为Kudu节点创建物理备份(无论是平板服务器还是主服务器)，并在以后进行恢复。

在此过程中，需要将待备份的节点离线，否则备份(或恢复)的数据将不一致。
Kudu节点的某些方面(比如主机名)嵌入到磁盘数据中。因此，还不可能将节点的物理备份恢复到另一台机器上。
停止集群中的所有Kudu进程。这可以防止备份节点上的平板电脑在其他不必要的地方重新复制。

1、在创建备份时，需要将需要备份的每个节点上的WAL、元数据和数据目录都拷贝一份。重要的是，这个副本要保留所有文件属性和稀疏性。

2、如果从备份中恢复，则删除现有的WAL、元数据和数据目录，然后通过移动或复制恢复备份。与创建备份一样，重要的是恢复要保留所有文件属性和稀疏性。

3、启动集群中的所有Kudu进程。

7.6、常见的kudu工作流

7.6.1、迁移到多个Kudu masters

为了高可用性和避免单点故障，应该使用多个master创建Kudu集群。许多Kudu集群都是用一个主机创建的，这可能是为了简单，也可能是因为当时的Kudu多主机支持还处于试验阶段。此工作流演示了如何迁移到多主配置。通过简单的修改，它还可以用于从两个主程序迁移到三个主程序。注意主节点的数量必须是奇数。

将新的主节点添加到已经拥有三个或更多主节点的现有配置中是不安全的。不要把它用于那个目的。

偶数个大师并不比少一个大师带来任何好处。对于迁移到三个主服务器，应该始终使用本指南。

下面的所有命令行步骤都应该作为Kudu UNIX用户执行。示例命令假设Kudu Unix用户为Kudu，这很典型。

工作流的前提是至少对Kudu配置管理有基本的熟悉。如果使用特定于供应商的工具，工作流也以熟悉它为前提，由于细节可能不同，应该使用供应商的说明。

从Kudu 1.15.0版本开始，增加了一个新的Kudu master add命令，简化了将一个现有的Kudu集群迁移到多个master的业务流程。

7.6.1.1、为迁移做准备

1、建立一个维护窗口(一个小时应该足够了)。在此期间，Kudu集群将不可用。

2、决定使用多少个master。大师的数量应该是奇数。推荐三到五个节点主配置;他们可以分别容忍一两次失败。

3、对现有的主机执行以下准备步骤:

如果从单个主节点迁移到多个主节点，请确保为单个主节点配置指定——master_addresses，因为需要迁移到多个主节点。可以使用kudu master get_flags命令进行检查。如果没有指定，请提供——master_addresses=:到主服务器的配置，并重新启动单个主服务器。
可选:为master配置DNS别名。别名可以是DNS cname(如果机器在DNS中已经有a记录)，a记录(如果机器仅通过其IP地址知道)，或/etc/hosts.别名应该是master的抽象表示(例如master-1)。

如果没有DNS别名，就不可能在不关闭集群进行维护的情况下从永久性主故障中恢复，因此，强烈建议这样做。

4、如果您有从Impala访问的Kudu表，则必须更新Apache Hive Metastore (HMS)数据库中的主地址。

如果设置了DNS别名，请在impala-shell中运行以下语句，用实际的别名替换master-1和master-2。
```
ALTER TABLE table_name
SET TBLPROPERTIES
('kudu.master_addresses' = 'master-1,master-2');
```
如果您没有设置DNS别名，请参见更新HMS的执行迁移部分中的步骤#7。

5、对每个新主机执行以下准备步骤:

在集群中选择一个未使用的计算机。master生成的负载很少，因此可以与其他数据服务或负载生成进程并置，但不能与来自相同配置的另一个Kudu master配置。
确保机器上安装了Kudu，可以通过系统包(在这种情况下，应该安装Kudu和Kudu -master包)，也可以通过其他方式安装。
选择并记录存放主数据的目录。
选择并记录主机应该为rpc使用的端口。
可选:为master配置DNS别名(例如master-2, master-3等)。

7.6.1.2、执行迁移

从版本1.15.0开始，添加了一个新的kudu master add CLI命令，用于协调向现有kudu集群中的多个master的迁移。

该过程不需要停止整个集群中的所有Kudu进程，但是一旦迁移过程完成，必须重新启动所有Kudu进程来合并新添加的master，这可以在不引起停机的情况下完成，如下步骤所述。

该过程支持一次只添加一个主程序。为了添加多个主机，请对下一个新主机再次执行相同的过程。

1、在新的主主机上(不是在任何现有的主主机上)，运行kudu master add命令添加主主机。在控制台或新的主日志文件中查找任何成功或错误消息。该命令被设计为幂等的，因此在错误消息中提到的问题修复后出现错误时，再次运行相同的命令以取得进展。在过程完成后，不管过程是否成功，新的主程序都将被关闭。下面的示例使用master-1将master-2添加到现有的Kudu集群中。

如果您的Kudu集群是安全的，在执行此命令之前，除了以Kudu UNIX用户身份运行外，还必须以Kudu业务用户身份进行身份验证。

$ sudo -u kudu kudu master add master-1 master-2 --fs_wal_dir=/data/kudu/master/wal \
--fs_data_dirs=/data/kudu/master/data

2、修改现有主服务器的master_addresses配置参数的值，因为新主服务器已经配置了更新的master_addresses。新值必须是以逗号分隔的所有主节点列表。每个条目都是一个形式为:的字符串
主机名
主机先前记录的主机名或别名

端口
master先前记录的RPC端口号

3、逐个重新启动现有的主服务器。

4、启动新的master。

5、修改每个平板服务器的tserver_master_addr配置参数的值。新值必须是一个以逗号分隔的主节点列表，其中每个条目是一个形式为:的字符串

主机名
主机先前记录的主机名或别名

端口
master先前记录的RPC端口号

6、重新启动所有平板电脑服务器以获取新的主配置。

7、如果您有从Impala访问的Kudu表，并且您没有设置DNS别名，那么在为HMS提供存储的底层数据库中手动更新HMS数据库。

下面是你应该在HMS数据库中运行的SQL语句示例:

UPDATE TABLE_PARAMS
SET PARAM_VALUE =
'master-1.example.com,master-2.example.com'
WHERE PARAM_KEY = 'kudu.master_addresses' AND PARAM_VALUE = 'master-1.example.com';

In impala-shell, run:
```
INVALIDATE METADATA;
```
7.6.1.3、验证迁移是否成功
要验证所有主节点是否正常工作，请执行以下完整性检查:
使用浏览器，访问每个主人的web UI。看看/大师页面。所有的master都应该列在那里，其中一个master在LEADER角色中，其他的在FOLLOWER角色中。每个master上的/master的内容应该是相同的。
使用Kudu命令行工具在集群上运行Kudu系统检查(ksck)。有关详细信息，请参见使用ksck检查集群运行状况。

7.6.2、在多主机部署中从死去的Kudu Master中恢复
当主机丢失时，Kudu多主机部署功能正常。然而，重要的是替换死亡的master;否则，第二次故障可能导致可用性损失，具体取决于可用主机的数量。这个工作流描述了如何替换失效的主服务器。

替换没有DNS别名的主机需要在重新启动平板服务器以选择不同主机名的替换主机时出现不可用窗口。有关使用DNS别名部署的更多细节，请参阅多主机迁移工作流。
工作流的前提是至少对Kudu配置管理有基本的熟悉。如果使用特定于供应商的工具，工作流也以熟悉它为前提，由于细节可能不同，应该使用供应商的说明。
下面的所有命令行步骤都应该作为Kudu UNIX用户(通常是Kudu)执行。

7.6.2.1、为恢复做准备

1、如果没有配置DNS别名，则执行以下步骤。

建立一个维护窗口(一个小时应该足够了)。在此期间，Kudu集群将不可用。
关闭集群中所有Kudu平板服务器进程。

2、确保死去的主人真的死了。采取任何必要的步骤来防止意外重启;这对于恢复后的集群来说是非常危险的。

3、在集群中选择新主机所在的未使用的计算机。master生成的负载很少，所以它可以与其他数据服务或负载生成进程并置，但不能与来自相同配置的另一个Kudu master配置。此工作流的其余部分将将此主机称为“替换”主机。

4、请执行以下准备步骤更换主组件:

如果使用相同的死主服务器替换主服务器，则删除主服务器的目录。
确保机器上安装了Kudu，可以通过系统包(在这种情况下，应该安装Kudu和Kudu -master包)，也可以通过其他方式安装。
选择并记录存放主数据的目录。

7.6.2.2、执行恢复

1、使用kudu master Remove命令从主机的Raft配置中删除死主机。在下面的例子中，已经死亡的master-2正在被恢复。

$ sudo -u kudu kudu master remove master-1,master-2 master-2

2、在待更换主机上，使用kudu master add命令将待更换主机添加到集群中。在控制台或替换主日志文件中查找任何成功或错误消息。该命令被设计为幂等的，因此在错误消息中提到的问题修复后出现错误时，再次运行相同的命令以取得进展。在程序完成后，无论程序是否成功，替换主程序都将关闭。在下面的例子中，使用了替换主机master-2。如果没有使用DNS别名，请使用替换主机的主机名。

$ sudo -u kudu kudu master add master-1 master-2 --fs_wal_dir=/data/kudu/master/wal \
--fs_data_dirs=/data/kudu/master/data

3、如果集群设置了DNS别名，请重新配置失效主服务器的DNS别名，使其指向替换主服务器。

4、如果集群没有设置DNS别名，请执行以下步骤:

修改每个活主服务器的master_addresses配置参数的值，删除死主服务器并使用替换主服务器替换它。新值必须是一个以逗号分隔的主节点列表，其中每个条目是一个形式为:的字符串

主机名
主机先前记录的主机名或别名

港口
船长先前记录的RPC端口号

重新启动其余的活动主服务器。

5、启动替换主服务器。

6、如果集群没有设置DNS别名，请按照以下步骤设置平板服务器:

修改每个tablet服务器的tserver_master_addr配置参数的值，删除死主服务器并使用替换主服务器替换它。新值必须是一个以逗号分隔的主节点列表，其中每个条目是一个形式为:的字符串

主机名
主机先前记录的主机名或别名

港口
船长先前记录的RPC端口号

重新启动所有平板电脑服务器。

恭喜你，死去的主人被取代了!要验证所有主节点是否正常工作，请考虑执行以下完整性检查:

使用浏览器，访问每个主人的web UI。看看/大师页面。所有的主节点都应该在那里列出，其中一个主节点在LEADER角色中，其他的在FOLLOWER角色中。每个master上的/master的内容应该是相同的。
使用Kudu命令行工具在集群上运行Kudu系统检查(ksck)。有关详细信息，请参见使用ksck检查集群运行状况。

7.6.3、从多主机部署中删除Kudu主机

如果多主机部署已经过度分配了节点，那么应该采取以下步骤来删除不需要的主机。

在规划新的多主机配置时，请记住主机的数量应该是奇数，并且建议使用3个或5个节点主配置。
如果主机数量低于Raft多数当前所需的主机数量，可能会导致数据丢失。要减轻这种情况，请确保在此过程中没有删除leader master。

7.6.3.1、为移除做准备

1、建立一个维护窗口(一个小时应该足够了)。在此期间，Kudu集群将不可用。

2、通过访问任何主机的web UI的/masters页面来确定多主机部署的UUID和RPC地址。在此过程中不能删除此主程序;删除可能导致严重的数据丢失。

3、停止不需要的Kudu主进程。

7.6.3.2、执行删除

1、执行Raft配置更改。运行kudu master删除工具。一次只能移除一个master。如果需要删除多个master，请多次运行该工具。在下例中，master-2被从一个拥有两个master-1和master-2的Kudu集群中移除。

$ sudo -u kudu kudu master remove master-1,master-2 master-2

2、删除不需要的主服务器上的数据目录和WAL目录。这是一种预防措施，以确保它们不会再次启动并干扰新的多主机部署。

3、修改新的多主机部署的主机的master_addresses配置参数的值。

4、重新启动所有未删除的主机。

5、修改tablet服务器的tserver_master_addr配置参数的值，以删除任何不需要的主服务器。

6、重新启动所有平板电脑服务器。

7.6.3.3、验证迁移是否成功

要验证所有主节点是否正常工作，请执行以下完整性检查:

使用浏览器，访问每个主人的web UI。看看/大师页面。所有的主节点都应该在那里列出，其中一个主节点在LEADER角色中，其他的在FOLLOWER角色中。每个master上的/master的内容应该是相同的。
使用Kudu命令行工具在集群上运行Kudu系统检查(ksck)。有关详细信息，请参见使用ksck检查集群运行状况。

7.6.4、修改master主机名

为了防止更换死主服务器时出现长维护窗口，应该使用DNS别名。如果集群没有设置别名，则可以通过以下步骤更改主机名。

7.6.4.1、准备好更改主机名

1、建立一个维护窗口(一个小时应该足够了)。在此期间，Kudu集群将不可用。

2、通过访问任何master的web UI的/masters页面来注意每个master的UUID和RPC地址。

3、停止整个集群中的所有Kudu进程。

4、设置新的主机名以指向主机，并验证所有服务器和客户端正确解析它们。

7.6.4.2、执行主机名更改

用下面的命令重写每个master的Raft配置，在所有master主机上执行:

$ sudo -u kudu kudu local_replica cmeta rewrite_raft_config --fs_wal_dir=<master_wal_dir> [--fs_data_dirs=<master_data_dir>] 00000000000000000000000000000000 <all_masters>

示例

$ sudo -u kudu kudu local_replica cmeta rewrite_raft_config --fs_wal_dir=/data/kudu/master/wal --fs_data_dirs=/data/kudu/master/data 00000000000000000000000000000000 4aab798a69e94fab8d77069edff28ce0:new-master-name-1:7051 f5624e05f40649b79a757629a69d061e:new-master-name-2:7051 988d8ac6530f426cbe180be5ba52033d:new-master-name-3:7051

1、更改主机的gflag文件，以便master_addresses参数反映新的主机名。
2、将平板服务器的gflag文件中的tserver_master_addrs参数更改为新的主机名。
3、启动masters。
4、要验证所有主节点是否正常工作，请执行以下完整性检查:

使用浏览器，访问每个主人的web UI。看看/大师页面。所有的主节点都应该在那里列出，其中一个主节点在LEADER角色中，其他的在FOLLOWER角色中。每个master上的/master的内容应该是相同的。
运行下面的命令来验证所有主机都已启动并在监听。uuid应该与主机名更改之前相同，并且属于相同的主机:
```
$ sudo -u kudu kudu master list new-master-name-1:7051,new-master-name-2:7051,new-master-name-3:7051
```
5、启动所有平板电脑服务器。
6、使用Kudu命令行工具在集群上运行Kudu系统检查(ksck)。有关详细信息，请参见使用ksck检查集群运行状况。启动后，有些平板可能不可用，因为需要一些时间来初始化所有的平板。

7、如果您有从Impala访问的Kudu表，请在为HMS提供存储的底层数据库中手动更新HMS数据库。

下面是你应该在HMS数据库中运行的SQL语句示例:

UPDATE TABLE_PARAMS
SET PARAM_VALUE =
'new-master-name-1:7051,new-master-name-2:7051,new-master-name-3:7051'
WHERE PARAM_KEY = 'kudu.master_addresses'
AND PARAM_VALUE = 'master-1:7051,master-2:7051,master-3:7051';

In impala-shell, run:
```
INVALIDATE METADATA;
```
通过在一个支持kudu的Impala表上运行一个简单的SELECT查询，验证元数据的更新是否有效。

7.6.5、添加新的平板服务器时的最佳实践

在管理Kudu集群时，一个常见的工作流程是添加额外的平板服务器实例，以努力增加存储容量，减少单个主机上的负载或利用率，增加计算能力等。

默认情况下，任何新添加的平板服务器在添加到集群后都不会立即被使用。相反，只有在创建新的平板电脑或需要复制现有的平板电脑时，才会使用新添加的平板电脑服务器，这可能会导致节点不平衡。建议在将一个新的平板服务器添加到集群之后运行rebalancer CLI工具，如下面的枚举步骤所述。

避免在单个节点上放置多个平板电脑服务器。这样做消除了增加Kudu集群的总体存储容量的意义，并增加了单个节点故障时平板电脑不可用的可能性(如果集群正确配置为使用位置感知特性，则后者的缺点不适用)。

要向现有集群中添加额外的药片服务器，可以采取以下步骤，以确保药片副本在整个集群中均匀分布:

1、确保在添加到集群的新机器上安装了Kudu，并且新实例已经正确地配置为指向预先存在的集群。然后，启动新的平板服务器实例。

2、验证新实例是否成功签入了Kudu Master。验证它们是否已成功签入现有Master实例的一个快速方法是查看Kudu Master web，特别是/tablet-servers部分，并验证新添加的实例是否已注册，是否正在运行。

3、一旦平板电脑服务器成功在线并正常运行，请按照以下步骤运行重新平衡工具，该工具将把现有的平板电脑副本扩展到新添加的平板电脑服务器。

4、在重新平衡器工具完成后，甚至在其执行期间，您可以使用ksck命令行实用工具检查集群的运行状况(有关详细信息，请参阅使用ksck检查集群运行状况)。

7.6.6、使用ksck检查集群运行状况

kudu CLI包含一个名为ksck的工具，可用于收集关于kudu集群状态的信息，包括检查其健康状况。KSCK将发现平板电脑复制不足、无法到达的平板电脑服务器或没有领导者的平板电脑等问题。
ksck应该以Kudu管理员用户的身份从命令行运行，并且需要指定完整的主地址列表:

$ sudo -u kudu kudu cluster ksck master-01.example.com,master-02.example.com,master-03.example.com

要查看ksck可用选项的完整列表，请使用——help标志。如果集群是健康的，ksck将打印关于集群的信息、一条成功消息，并返回零(成功)退出状态。

Master Summary
               UUID               |       Address         | Status
----------------------------------+-----------------------+---------
 a811c07b99394df799e6650e7310f282 | master-01.example.com | HEALTHY
 b579355eeeea446e998606bcb7e87844 | master-02.example.com | HEALTHY
 cfdcc8592711485fad32ec4eea4fbfcd | master-02.example.com | HEALTHY
Tablet Server Summary
               UUID               |        Address         | Status
----------------------------------+------------------------+---------
 a598f75345834133a39c6e51163245db | tserver-01.example.com | HEALTHY
 e05ca6b6573b4e1f9a518157c0c0c637 | tserver-02.example.com | HEALTHY
 e7e53a91fe704296b3a59ad304e7444a | tserver-03.example.com | HEALTHY
Version Summary
 Version |      Servers
---------+-------------------------
  1.7.1  | all 6 server(s) checked
Summary by table
   Name   | RF | Status  | Total Tablets | Healthy | Recovering | Under-replicated | Unavailable
----------+----+---------+---------------+---------+------------+------------------+-------------
 my_table | 3  | HEALTHY | 8             | 8       | 0          | 0                | 0
                | Total Count
----------------+-------------
 Masters        | 3
 Tablet Servers | 3
 Tables         | 1
 Tablets        | 8
 Replicas       | 24
OK

如果集群不健康，例如，如果平板服务器进程停止，ksck将报告问题并返回一个非零退出状态，如下面的ksck输出的简短代码片段所示:

Tablet Server Summary
               UUID               |        Address         |   Status
----------------------------------+------------------------+-------------
 a598f75345834133a39c6e51163245db | tserver-01.example.com | HEALTHY
 e05ca6b6573b4e1f9a518157c0c0c637 | tserver-02.example.com | HEALTHY
 e7e53a91fe704296b3a59ad304e7444a | tserver-03.example.com | UNAVAILABLE
Error from 127.0.0.1:7150: Network error: could not get status from server: Client connection negotiation failed: client connection to 127.0.0.1:7150: connect: Connection refused (error 61) (UNAVAILABLE)
... (full output elided)
==================
Errors:
==================
Network error: error fetching info from tablet servers: failed to gather info for all tablet servers: 1 of 3 had errors
Corruption: table consistency check error: 1 out of 1 table(s) are not healthy
FAILED
Runtime error: ksck discovered errors

为了验证数据完整性，可以设置可选的——checksum_scan标志，它将通过扫描每个平板副本并比较结果来确保集群拥有一致的数据。可以使用——tables或——tablet标志分别将校验和扫描的范围限制到特定的表或片剂。例如，检查my_table表的数据完整性可以使用以下命令:

$ sudo -u kudu kudu cluster ksck --checksum_scan --tables my_table master-01.example.com,master-02.example.com,master-03.example.com

默认情况下，ksck将尝试使用表的快照扫描，因此可以在继续写操作的同时执行校验和扫描。
最后，ksck还支持使用——ksck_format标志的JSON格式输出。JSON输出包含与纯文本输出相同的信息，但是格式可以被其他工具使用。更多信息请参见kudu集群ksck——帮助。

7.6.7、改变目录配置

为了提高读并行度和每个服务器的存储容量，用户可能希望将服务器配置为将数据存储在不同设备的多个目录中。用户可以通过更新——fs_data_dirs gflag配置并重新启动服务器，向现有的主服务器或平板服务器添加或删除数据目录。数据跨数据目录进行条带化，当添加新数据目录时，新数据将跨新老目录进行条带化。

从——fs_data_dirs中删除数据目录可能导致在删除的目录中有数据块的情况下，平板复制失败。使用ksck确保集群可以在转移到另一台服务器之前从目录删除中完全恢复。
在低于1.12的版本中，Kudu要求运行Kudu fs update_dirs工具，然后再用不同的一组数据目录重新启动。这样的版本如果不运行将无法启动。

如果是低于1.12的Kudu版本，一旦服务器启动，用户必须通过以下步骤来更改目录配置:

除非指定了——force标志，否则Kudu将不允许删除被配置为跨片传播数据的目录。如果指定了——force，那么所有配置为使用该目录的片将在启动时失败，并被复制到其他地方。
如果元数据目录与数据目录有重叠(在Kudu 1.7之前是默认的)，或者配置了非默认的元数据目录，则运行Kudu fs update_dirs工具时必须指定——fs_metadata_dir配置。
只有新的平板电脑副本(即全新的平板电脑副本和复制到服务器的高可用性副本)将使用新的目录。服务器上现有的平板副本将不会跨新目录进行重新平衡。
下面的所有命令行步骤都应该作为Kudu UNIX用户(通常是Kudu)执行。

1、使用ksck以确保集群正常运行，并建立一个维护窗口以使平板服务器脱机。

2、使用所需的目录配置标志运行该工具。例如，如果集群设置了——fs_wal_dir=/wals，——fs_metadata_dir=/meta，并且——fs_data_dirs=/data/1，/data/2，/data/3， /data/3将被删除(例如由于磁盘错误)，则执行命令:

$ sudo -u kudu kudu fs update_dirs --force --fs_wal_dir=/wals --fs_metadata_dir=/meta --fs_data_dirs=/data/1,/data/2

3、修改更新后服务器的——fs_data_dirs标志的值。如果使用CM，请确保只更新更新的服务器的配置，而不是整个Kudu服务的配置。
4、一旦完成，就可以启动服务器进程。当使用系统包安装Kudu时，通常使用service:

$ sudo service kudu-tserver start

7.6.8、从磁盘故障中恢复

只有挂载了部分Kudu目录的磁盘出现故障，Kudu节点才能存活。有关不同Kudu目录类型的更多信息，请参见“Kudu目录配置”一节。下面描述不同Apache Kudu版本之间的这种行为。

表1。Kudu硬盘故障行为

Node Type	Kudu Directory Type	Kudu Releases that Crash on Disk Failure
Master	All	All
Tablet Server	Directory containing WALs	All
Tablet Server	Directory containing tablet metadata	All
Tablet Server	Directory containing data blocks only	Pre-1.6.0

当发生磁盘故障但未导致崩溃时，Kudu将停止使用受影响目录，关闭受影响目录上有块的平板，并自动将受影响的平板重新复制到其他平板服务器上。受影响的服务器将保持活动状态，并将消息打印到指示磁盘故障的日志中，例如:

E1205 19:06:24.163748 27115 data_dirs.cc:1011] Directory /data/8/kudu/data marked as failed
E1205 19:06:30.324795 27064 log_block_manager.cc:1822] Not using report from /data/8/kudu/data: IO error: Could not open container 0a6283cab82d4e75848f49772d2638fe: /data/8/kudu/data/0a6283cab82d4e75848f49772d2638fe.metadata: Read-only file system (error 30)
E1205 19:06:33.564638 27220 ts_tablet_manager.cc:946] T 4957808439314e0d97795c1394348d80 P 70f7ee61ead54b1885d819f354eb3405: aborting tablet bootstrap: tablet has data in a failed directory

在此状态下，受影响的节点将避免使用故障磁盘，导致存储容量减少，读并行度降低。管理员可以从——fsdata_dirs gflag中删除失败的目录，以避免看到这些错误。
在低于1.12版本的Kudu中，为了用一组不同的目录启动Kudu，管理员应该安排一个简短的窗口来更新节点的目录配置。否则Kudu将无法启动。_
当磁盘修复、重新挂载并准备供Kudu重用时，请执行以下步骤:

1、确保磁盘的Kudu部分完全为空。

2、停止平板服务器。

3、更新——fs_data_dirs gflag，添加/data/3，如果库度低于1.12，可能使用update_dirs工具:

$ sudo -u kudu kudu fs update_dirs --force --fs_wal_dir=/wals --fs_data_dirs=/data/1,/data/2,/data/3

4、启动平板电脑服务器。
5、运行ksck验证集群运行状况。

sudo -u kudu kudu cluster ksck master-01.example.com

请注意，现有的药片将不会分条到恢复的磁盘，但任何新的药片将分条到恢复的磁盘。

7.6.9、从全磁盘恢复

默认情况下，Kudu在其目录中预留少量空间(按容量的1%计算);如果可用的空闲空间少于预定空间，Kudu会认为磁盘已满。Kudu节点只能允许挂载某些Kudu目录的磁盘空间不足。有关不同Kudu目录类型的更多信息，请参见Kudu目录配置。下表描述了每种目录类型的这种行为。主机服务器和平板服务器之间的行为是统一的。

表2。Kudu全磁盘行为

Kudu Directory Type	Crash on a Full Disk?
Directory containing WALs	Yes
Directory containing tablet metadata	Yes
Directory containing data blocks only	No (see below)

在Kudu 1.7.0之前，Kudu对所有目录进行条带化，避免将数据写入完整目录。如果所有数据目录都满了，Kudu会崩溃。
在1.7.0及以后版本中，新片会被分配一个由——fs_target_data_dirs_per_tablet数据目录组成的磁盘组(默认为3)。如果Kudu没有为一个完整的磁盘组配置足够的数据目录，则会使用所有的数据目录。当数据目录满时，Kudu将停止向其写入新数据，使用该数据目录的每台平板电脑将向其组内的其他数据目录写入新数据。如果一个平板电脑的所有数据目录都满了，Kudu就会崩溃。Kudu会定期检查满数据目录是否仍然满，如果空间可用，会恢复对这些数据目录的写入。

如果Kudu因其数据目录已满而崩溃，则释放完整目录上的空间将允许受影响的守护进程重新启动并恢复写入。请注意，Kudu可以通过跑步来释放一些空间

$ sudo -u kudu kudu fs check --repair

但是，如果剩余空间太少，该命令也可能失败。
还可以为Kudu分配额外的数据目录，以增加可用的存储总量。有关更多信息，请参阅有关更新节点目录配置的文档。请注意，现有的平板不会使用新的数据目录，所以添加一个新的数据目录并不能解决满磁盘的问题。

7.6.10、让一台丢失了大部分复制品的平板电脑重新上线

如果一个平板电脑永久丢失了它的大部分副本，它就不能自动恢复，需要操作员的干预。如果承载大部分副本的平板服务器宕机(即ksck报告为“TS不可用”)，它们应该尽可能恢复。

下面的步骤可能会导致最近对平板电脑的编辑丢失，可能导致永久的数据丢失。如果不可能让大多数人重新上线，请尝试以下步骤。
假设一个平板电脑失去了它的大部分复制品。诊断和修复问题的第一步是使用ksck检查平板电脑的状态:

$ sudo -u kudu kudu cluster ksck --tablets=e822cab6c0584bc0858219d1539a17e6 master-00,master-01,master-02
Connected to the Master
Fetched info from all 5 Tablet Servers
Tablet e822cab6c0584bc0858219d1539a17e6 of table 'my_table' is unavailable: 2 replica(s) not RUNNING
  638a20403e3e4ae3b55d4d07d920e6de (tserver-00:7150): RUNNING
  9a56fa85a38a4edc99c6229cba68aeaa (tserver-01:7150): bad state
    State:       FAILED
    Data state:  TABLET_DATA_READY
    Last status: <failure message>
  c311fef7708a4cf9bb11a3e4cbcaab8c (tserver-02:7150): bad state
    State:       FAILED
    Data state:  TABLET_DATA_READY
    Last status: <failure message>

该输出显示，对于tablet e822cab6c0584bc0858219d1539a17e6, tserver-01和tserver-02上的两个tablet副本失败。剩余的副本不是leader，所以leader副本也失败了。这意味着数据丢失的可能性更高，因为tserver-00上的剩余副本可能已经延迟了。一般来说，为了接受潜在的数据丢失并从剩余的副本中恢复片剂，将片剂副本分为两组:

1、运行正常的副本:ksck报告的处于运行状态的副本
2、不健康的副本

例如，在上面的ksck输出中，tablet服务器tserver-00上的副本是正常的，而tserver-01和tserver-02上的副本是不正常的。在每个具有正常副本的平板服务器上，更改共识配置以删除不正常副本。在3个幸存副本中有1个副本的典型情况下，将只有一个正常副本，因此共识配置将被重写，以只包含正常副本。

$ sudo -u kudu kudu remote_replica unsafe_change_config tserver-00:7150 <tablet-id> <tserver-00-uuid>

where is e822cab6c0584bc0858219d1539a17e6 and is the uuid of tserver-00, 638a20403e3e4ae3b55d4d07d920e6de.

一旦健康的副本的共识配置被强制排除不健康的副本，健康的副本将能够选举一个领导人。平板电脑将可用于写入，尽管它仍将被复制不足。在药片可用后不久，leader master将注意到它复制不足，并将导致药片重新复制，直到恢复适当的复制因子。不正常的副本将被主服务器删除，导致其剩余数据被删除。

7.6.11、重建一个Kudu文件系统布局

如果关键文件丢失，例如WALs或特定于平板电脑的元数据，服务器上的所有Kudu目录都必须删除并重新构建以确保正确性。这样做将破坏本地服务器上每个平板电脑副本的数据副本。Kudu将自动重新复制以这种方式删除的平板副本，前提是复制因子至少为三个，并且所有其他服务器都在线且正常。

这些步骤以平板服务器为例，但是对于Kudu主服务器，步骤是相同的。
如果多个节点需要重新构建它们的FS布局，请等待，直到每个节点上先前托管的所有副本都在其他地方自动完成重新复制，然后再继续。如果不这样做，可能会导致永久的数据丢失。
在继续之前，请确保备份了目录的内容，可以是副本，也可以是其他tablet副本的形式。

1、使用新目录配置重新构建服务器的第一步是清空服务器的所有现有目录。例如，平板服务器配置了——fs_wal_dir=/data/0/kudu-tserver- WAL、——fs_metadata_dir=/data/0/kudu-tserver-meta、——fs_data_dirs=/data/1/kudu-tserver、/data/2/kudu-tserver，则删除WAL目录和数据目录的内容。

# Note: this will delete all of the data from the local tablet server.
$ rm -rf /data/0/kudu-tserver-wal/* /data/0/kudu-tserver-meta/* /data/1/kudu-tserver/* /data/2/kudu-tserver/*

2、如果使用CM，更新重新构建的服务器的配置，使其只包含所需的目录。确保只更新应用更改的服务器的配置，而不是整个Kudu服务的配置。
3、删除目录后，服务器进程可以使用新的目录配置启动。Kudu将在启动时创建相应的子目录。

7.6.12、最小化单个平板服务器临时计划停机期间的集群中断

如果在一个健康的集群中有一台平板电脑服务器暂时宕机，那么所有的平板电脑都将保持可用，客户端也将正常工作，尽管可能会因为领导人选举而出现短暂的延迟。但是，如果停机时间超过——follower_unavailable_sided_failed_sec(默认300)秒，则关闭的平板服务器上的平板副本将被可用平板服务器上的新副本取代。这将在平板电脑重新复制时对集群造成压力，如果停机时间足够长，将显著减少宕机平板电脑服务器上的副本数量，这将需要重新平衡器来修复。

为了解决这个问题，在1.11之后的Kudu版本中，Kudu CLI包含一个工具，可以让平板服务器进入维护模式。虽然在这种状态下,平板电脑服务器的副本不是复制仅由于停机时间,但仍有可能发生重新复制时,服务器在维护患有磁盘故障或者平板电脑服务器上的从动件复制品瀑布太远其领导人复制品。在退出维护时，将对任何剩余复制不足的片触发重新复制。

添加了kudu tserver状态enter_maintenance和kudu tserver状态exit_maintenance工具来协调平板服务器的维护。下面的操作可以从平板电脑服务器上运行，使其进入维护:

$ TS_UUID=$(sudo -u kudu kudu fs dump uuid --fs_wal_dir=<wal_dir> --fs_data_dirs=<data_dirs>)
$ sudo -u kudu kudu tserver state enter_maintenance <master_addresses> "$TS_UUID"

在Kudu leader master的web UI的“tablet Servers”页面和Kudu集群ksck的输出中可以看到平板服务器的维护模式。使用实例退出维护模式。

$ sudo -u kudu kudu tserver state exit_maintenance <master_addresses> "$TS_UUID"

在1.11之前的版本中，必须使用不同的方法来防止不必要的重复复制。在所有平板电脑服务器上增加——follower_unavailable_considered_failed_sec，这样重新复制启动之前的时间比平板电脑服务器的预期停机时间要长，包括平板电脑服务器重新启动和引导其平板电脑副本所需的时间。为此，为每个平板服务器运行以下命令:

$ sudo -u kudu kudu tserver set_flag <tserver_address> follower_unavailable_considered_failed_sec <num_seconds>

其中，是包含停机时间的秒数。停机结束后，将该标志重置为其原始值。

$ sudo -u kudu kudu tserver set_flag <tserver_address> follower_unavailable_considered_failed_sec <original_value>

请确保将——follower_unavailable_considered_failed_sec的值重置为其原始值。
在1.8之前的Kudu版本中，必须在上面的set_flag命令中提供——force标志。

7.6.13、安排无停机时间的滚动重新启动

从Kudu 1.12开始，可以使用工具重新启动集群，而不需要停机。执行“滚动重启”的顺序如下:

1、逐个重新启动主服务器。如果只有一个主机，这可能会对正在进行的工作负载造成短暂干扰。

2、从单个平板服务器开始，使用kudu tserver状态enter_maintenance工具将平板服务器设置为维护模式。

3、使用kudu tserver静默启动工具开始静默平板服务器。这将向Kudu发出信号，要求其停止在指定的平板电脑服务器上托管leader，并将新的扫描请求重定向到其他平板电脑服务器。

4、使用——error_if_not_full_quiesced选项定期运行kudu tserver quiesce start，直到它返回success，这表明所有leader都已经从平板服务器上移走，所有正在进行的扫描都已经完成。

5、重启平板电脑服务器。

6、定期运行ksck，直到报告集群处于健康状态。

7、执行kudu tserver state exit_maintenance命令，退出平板服务器维护模式。这将允许在平板服务器上放置新的平板副本。

8、对集群中的所有平板服务器重复这些步骤。

如果集群中的任何表的复制因子为1，那么一些静止的平板服务器将永远不会完全静止，因为单副本平板不会自然地放弃领导权。如果存在这样的表，请使用kudu集群rebalance工具，通过指定——ignored_tservers、——move_replicas_from_ignored_tservers和——tables选项，将这些表的副本从静止的平板服务器上移走。
如果运行机架感知，可以执行上述步骤，同时在单个机架内重启多个平板服务器。用户应该使用ksck来确保在执行这些步骤时强制执行位置分配策略，并且同时重启的位置不超过一个。集群中至少应该定义三个位置，以便在一个位置内安全重启多个平板电脑服务。

7.6.14、运行平板电脑再平衡工具

kudu CLI包含一个平衡工具，可用于平衡平板服务器之间的平板副本。对于每个表，该工具试图平衡每个平板服务器的副本数量。它还将在不破坏任何表平衡的情况下，尝试在整个集群中平均分配每个平板服务器的副本数量。再平衡工具应该以Kudu管理员用户的身份运行，指定所有主地址:

sudo -u kudu kudu cluster rebalance master-01.example.com,master-02.example.com,master-03.example.com

当运行时，再平衡器将报告集群中初始的片剂副本分布，记录它移动的副本，并在终止时打印该分布的最终摘要:

Per-server replica distribution summary:
       Statistic       |   Value
-----------------------+-----------
 Minimum Replica Count | 0
 Maximum Replica Count | 24
 Average Replica Count | 14.400000
Per-table replica distribution summary:
 Replica Skew |  Value
--------------+----------
 Minimum      | 8
 Maximum      | 8
 Average      | 8.000000
I0613 14:18:49.905897 3002065792 rebalancer.cc:779] tablet e7ee9ade95b342a7a94649b7862b345d: 206a51de1486402bbb214b5ce97a633c -> 3b4d9266ac8c45ff9a5d4d7c3e1cb326 move scheduled
I0613 14:18:49.917578 3002065792 rebalancer.cc:779] tablet 5f03944529f44626a0d6ec8b1edc566e: 6e64c4165b864cbab0e67ccd82091d60 -> ba8c22ab030346b4baa289d6d11d0809 move scheduled
I0613 14:18:49.928683 3002065792 rebalancer.cc:779] tablet 9373fee3bfe74cec9054737371a3b15d: fab382adf72c480984c6cc868fdd5f0e -> 3b4d9266ac8c45ff9a5d4d7c3e1cb326 move scheduled
... (full output elided)
I0613 14:19:01.162802 3002065792 rebalancer.cc:842] tablet f4c046f18b174cc2974c65ac0bf52767: 206a51de1486402bbb214b5ce97a633c -> 3b4d9266ac8c45ff9a5d4d7c3e1cb326 move completed: OK
rebalancing is complete: cluster is balanced (moved 28 replicas)
Per-server replica distribution summary:
       Statistic       |   Value
-----------------------+-----------
 Minimum Replica Count | 14
 Maximum Replica Count | 15
 Average Replica Count | 14.400000
Per-table replica distribution summary:
 Replica Skew |  Value
--------------+----------
 Minimum      | 1
 Maximum      | 1
 Average      | 1.000000

如果除了副本分发摘要之外还需要更多的详细信息，请使用——output_replica_distribution_details标志。如果添加了该标志，该工具还将打印每个表和每个平板服务器副本分布统计信息。
使用——report_only标志可以获得表范围和集群范围的副本分布统计信息的报告，而无需启动任何重新平衡活动。

通过提供——tables标志，还可以将重新平衡器限制在表的一个子集上运行。注意，当在表的子集上运行时，该工具不会试图平衡整个集群。

再平衡的时间长度可以用标志max_run_time_sec来控制。默认情况下，rebalancer会一直运行到集群被平衡为止。要控制用于重新平衡的资源数量，请修改标志——max_moves_per_server。参见kudu集群rebalance——更多帮助。

在任何时候停止再平衡器工具都是安全的。重新启动时，再平衡器将继续对集群进行再平衡。

重新平衡器要求所有注册的平板电脑服务器都启动并运行以继续重新平衡过程。这是为了避免与自动重新复制可能的冲突和竞争，并保持副本放置对于集群的当前配置是最优的。如果平板电脑服务器在重新平衡过程中不可用，重新平衡器将退出。如上所述，解决了平板服务器不可用的问题后，重新启动重新平衡器是安全的。

再平衡工具也可以再平衡运行旧版本的Kudu集群，但有一些限制。更多信息请参考下表。在表中，“RF”代表“复制因子”。

表3。Kudu平衡工具兼容性

Version Range	Rebalances RF = 1 Tables?	Rebalances RF > 1 Tables?
v < 1.4.0	No	No
1.4.0 <= v < 1.7.1	No	Yes
v >= 1.7.1	Yes	Yes

如果重新平衡器在一个集群上运行，而该集群不支持重新平衡复制因子中的一个表，那么它将重新平衡所有其他表和集群，就好像这些单复制表不存在一样。

7.6.15、在支持机架的集群上运行平板电脑再平衡工具

正如机架感知部分所详细介绍的，可以使用kudu集群rebalance工具在集群上建立放置策略。当首次配置机架感知特性或重新复制违反了放置策略时，这可能是必要的。再平衡工具将其工作分为三个阶段:

1、感知机架的再平衡器试图建立布局策略。使用——disable_policy_fixer标志跳过此阶段。

2、重新平衡器尝试按位置平衡负载，在位置之间移动片剂副本，试图在位置之间均匀分布片剂副本。一个位置的负载是用该位置上的副本总数除以该位置上的平板服务器数量来测量的。使用——disable_cross_location_rebalance标志跳过此阶段。

3、再平衡器试图在每个位置内平衡平板电脑副本分布，就像该位置本身是一个集群一样。使用——disable_intra_location_rebalance标志跳过此阶段。

通过使用——report_only标志，也可以检查集群中的所有平板是否符合放置策略，而不尝试任何复制移动。

7.6.16、从集群中退役或永久删除平板服务器

从Kudu 1.12开始，通过提供——ignored_tservers和——move_replicas_from_ignored_tservers参数，可以使用Kudu再平衡器工具来解除tablet服务器。

不要同时关闭多个平板电脑服务器。要从集群中删除多个平板服务器，请对每个平板服务器执行以下说明，确保前一个平板服务器已从集群中删除，并且在关闭下一个平板服务器之前ksck是健康的。

1、通过使用ksck确保集群运行良好。请参阅使用ksck检查集群运行状况。

2、使用kudu tserver状态enter_maintenance工具将平板服务器设置为维护模式。

3、运行kudu cluster rebalance工具，提供——ignored_tservers参数和将要退役的平板服务器的uuid，以及——move_replicas_from_ignored_tservers标志。

4、等待移动完成并等待ksck显示集群处于健康状态。

5、可以使退役的平板电脑服务器离线。

6、要完全将其从集群中删除，以便ksck显示集群完全健康，请重新启动主服务器。对于单个主服务器，这将导致集群停机。对于多主机，按顺序重新启动主机，以避免集群停机。

在不支持上述工具的Kudu版本中，必须遵循不同的步骤来关闭平板服务器:

1、使用ksck确保集群运行良好。请参阅使用ksck检查集群运行状况。

2、如果tablet服务器包含复制因子为1的表的任何副本，那么在关闭tablet服务器之前必须手动将这些副本移出tablet服务器。可以使用kudu tablet change_config move_replica工具。

3、关闭平板电脑服务器。在-follower_unavailable_considered_failed_sec(默认值为5分钟)之后，Kudu将开始重新将平板服务器的副本复制到其他服务器。等待流程完成。可以使用ksck监控进度。

4、一旦所有副本都完成，ksck将继续报告平板服务器不可用。否则，集群在没有平板服务器的情况下也可以正常运行。要完全将其从集群中删除，以便ksck显示集群完全健康，请重新启动主服务器。对于单个主服务器，这将导致集群停机。对于多主机，按顺序重新启动主机，以避免集群停机。

7.6.17、在kudu命令行工具中使用集群名称

使用kudu命令行工具时，可能很难记住与集群通信所需的kudu主RPC地址的精确列表，特别是在管理多个集群时。作为替代方法，命令行工具可以通过名称标识集群。要使用此功能:

1、新建一个目录存放Kudu配置文件。

2、在KUDU_CONFIG环境变量中导出到此目录的路径。

3、在新目录中创建一个名为kudurc的文件。

4、按照以下方式填充kudurc，替换您自己的集群名称和RPC地址:

clusters_info:
  cluster_name1:
    master_addresses: ip1:port1,ip2:port2,ip3:port3
  cluster_name2:
    master_addresses: ip4:port4

5、使用kudu命令行工具时，将kudu主RPC地址列表替换为集群名称，前面加上字符@。
例子

$ sudo -u kudu kudu cluster ksck @cluster_name1

集群名称可以用作任何调用kudu命令行工具时的输入，该命令行工具需要一列kudu主RPC地址。

7、Apache kudu管理

7.1、启动和停止Kudu进程

7.2、kuduWeb界面

7.2.1、Kudu Master Web Interface

7.2.2、Kudu tablet服务器Web界面

7.2.3、常用Web界面页面

7.3、kudu指标

7.3.1、列出可用的指标

7.3.2、通过HTTP收集指标

7.3.3、诊断日志记录

7.4、机架感知

7.5、备份和恢复

7.5.1、逻辑备份和恢复

7.5.1.1、备份表

7.5.1.2、从备份中恢复表

7.5.1.3、备份工具

7.5.1.4、备份目录结构

7.5.1.5、故障排除

7.5.2、整个节点的物理备份

7.6、常见的kudu工作流

7.6.1、迁移到多个Kudu masters

7.6.1.1、为迁移做准备

7.6.1.2、执行迁移

7.6.1.3、验证迁移是否成功

7.6.2、在多主机部署中从死去的Kudu Master中恢复

7.6.2.1、为恢复做准备

7.6.2.2、执行恢复

7.6.3、从多主机部署中删除Kudu主机

7.6.3.1、为移除做准备

7.6.3.2、执行删除

7.6.3.3、验证迁移是否成功

7.6.4、修改master主机名

7.6.4.1、准备好更改主机名

7.6.4.2、执行主机名更改

7.6.5、添加新的平板服务器时的最佳实践

7.6.6、使用ksck检查集群运行状况

7.6.7、改变目录配置

7.6.8、从磁盘故障中恢复

7.6.9、从全磁盘恢复

7.6.10、让一台丢失了大部分复制品的平板电脑重新上线

7.6.11、重建一个Kudu文件系统布局

7.6.12、最小化单个平板服务器临时计划停机期间的集群中断

7.6.13、安排无停机时间的滚动重新启动

7.6.14、运行平板电脑再平衡工具

7.6.15、在支持机架的集群上运行平板电脑再平衡工具

7.6.16、从集群中退役或永久删除平板服务器

7.6.17、在kudu命令行工具中使用集群名称