ZooKeeperManagement 员指南

部署和 Management 指南

Deployment

本节包含有关部署 Zookeeper 的信息，并涵盖以下主题：

前两个部分假设您对在生产环境(例如数据中心)中安装 ZooKeeper 感兴趣。最后一部分介绍了在有限的基础上设置 ZooKeeper(用于评估，测试或开发)但在生产环境中没有设置的情况。

System Requirements

Supported Platforms

ZooKeeper 由多个组件组成。一些组件得到广泛支持，而其他组件仅在较小的一组平台上受支持。

以下矩阵描述了为在不同的 os 平台上运行每个组件而承诺的支持级别。

Support Matrix
Operating System Client Server Native Client Contrib
GNU/Linux 开发生产 开发生产 开发生产 开发生产
Solaris 开发生产 开发生产 Not Supported Not Supported
FreeBSD 开发生产 开发生产 Not Supported Not Supported
Windows 开发生产 开发生产 Not Supported Not Supported
Mac OS X Development Only Development Only Not Supported Not Supported

对于矩阵中未明确提及的任何 os，组件可能会起作用，也可能不会起作用。 ZooKeeper 社区将修复在其他平台上报告的明显错误，但没有完全支持。

Required Software

ZooKeeper 运行于 Java 1.7 或更高版本(JDK 7 或更高版本，对 FreeBSD 的支持需要 openjdk7)。它作为 ZooKeeper 服务器的“整体”运行。建议三个最小的 ZooKeeper 服务器是一个整体的最小大小，我们也建议它们在单独的计算机上运行。在 Yahoo!上，ZooKeeper 通常部署在专用的 RHEL 盒上，该盒具有双核处理器，2GB RAM 和 80GB IDE 硬盘。

群集(多服务器)设置

为了获得可靠的 ZooKeeper 服务，您应该在称为* ensemble *的群集中部署 ZooKeeper。只要大多数合奏正常运行，就可以使用该服务。因为 Zookeeper 占多数，所以最好使用奇数台计算机。例如，对于四台机器，ZooKeeper 只能处理单台机器的故障；如果两台计算机发生故障，则其余两台计算机不占多数。但是，使用五台计算机，ZooKeeper 可以处理两台计算机的故障。

Note

Note

如ZooKeeper 入门指南中所述，容错群集设置至少需要三台服务器，并且强烈建议您使用奇数个服务器。

通常，对于生产安装而言，三台服务器绰绰有余，但是为了在维护期间获得最大的可靠性，您可能希望安装五台服务器。对于三台服务器，如果对其中一台服务器执行维护，则在该维护过程中容易遭受其他两台服务器之一故障的影响。如果其中有五台正在运行，则可以将其中一台停机进行维护，并知道如果其他四台之一突然出现故障，您仍然可以。

您的冗余注意事项应包括环境的所有方面。如果您有三台 ZooKeeper 服务器，但它们的网络电缆均插入同一网络交换机，则该交换机的故障将使整个系统瘫痪。

以下是设置将成为整体一部分的服务器的步骤。这些步骤应在集合中的每个主机上执行：

tickTime=2000
dataDir=/var/lib/zookeeper/
clientPort=2181
initLimit=5
syncLimit=2
server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888

您可以在Configuration Parameters部分中找到这些以及其他配置设置的含义。这里只说几句：作为 ZooKeeper 合奏一部分的每台机器都应该知道该合奏中的每台其他机器。您可以通过一系列形式为 server.id = host：port：port 的行来完成此操作。参数 host 和 port 很简单。通过为服务器创建一个名为* myid *的文件，将服务器 ID 分配给每台计算机，该文件位于配置文件参数 dataDir 指定的该服务器数据目录中。

$ java -cp zookeeper.jar:lib/*:conf org.apache.zookeeper.server.quorum.QuorumPeerMain zoo.conf

QuorumPeerMain 启动了 ZooKeeper 服务器，还注册了JMXManagementbean，该 Managementbean 允许通过 JMXManagement 控制台进行 Management。 ZooKeeper JMX 文档包含有关使用 JMXManagementZooKeeper 的详细信息。有关启动服务器实例的示例，请参阅发行版中包含的脚本* bin/zkServer.sh *。

通过连接到主机来测试部署：在 Java 中，您可以运行以下命令来执行简单的操作：

$ bin/zkCli.sh -server 127.0.0.1:2181

单服务器和开发人员设置

如果要出于开发目的设置 ZooKeeper，则可能要设置 ZooKeeper 的单个服务器实例，然后在开发计算机上安装 Java 或 CClient 端库和绑定。

设置单个服务器实例的步骤与上述步骤相似，只是配置文件更简单。您可以在ZooKeeper 入门指南的在单服务器模式下安装和运行 ZooKeeper部分中找到完整的说明。

有关安装 Client 端库的信息，请参阅ZooKeeper 程序员指南的Bindings部分。

Administration

本节包含有关运行和维护 ZooKeeper 的信息，并涵盖以下主题：

设计 ZooKeeper 部署

ZooKeeper 的可靠性基于两个基本假设。

以下各节包含 ZooKeeperManagement 员要考虑的因素，以最大程度地使这些假设成立。其中一些是跨计算机的考虑因素，而另一些则是部署中每台计算机应考虑的事项。

跨机器要求

为了使 ZooKeeper 服务处于活动状态，必须有大多数可以相互通信的非故障机器。要创建可以容忍 F 机故障的部署，您应该指望部署 2xF 1 机。因此，由三台计算机组成的部署可以处理一个故障，而由五台计算机组成的部署可以处理两个故障。请注意，部署六台计算机只能处理两个故障，因为三台计算机不是多数。因此，ZooKeeper 部署通常由奇数台计算机组成。

为了最大程度地容忍故障，您应该尝试使机器故障独立。例如，如果大多数计算机共享同一交换机，则该交换机的故障可能导致相关的故障并导致服务中断。共享电源电路，冷却系统等也是如此。

单机要求

如果 ZooKeeper 必须与其他应用程序竞争以访问诸如存储介质，CPU，网络或内存之类的资源，则其性能将显着下降。 ZooKeeper 具有很强的耐用性保证，这意味着在允许负责更改的操作完成之前，它使用存储介质记录更改。然后，您应该意识到这种依赖性，如果要确保媒体不阻止 ZooKeeper 的操作，请格外小心。您可以采取以下措施来最大程度地减少这种退化：

Provisioning

要考虑的事项：ZooKeeper 的优势和局限性

Administering

Maintenance

ZooKeeper 集群几乎不需要长期维护，但是您必须注意以下几点：

正在进行的数据目录清除

ZooKeeper Data Directory包含文件，这些文件是特定服务集合存储的 znode 的永久副本。这些是快照和事务日志文件。在对 znode 进行更改时，这些更改将附加到事务日志中。有时，当日志变大时，会将所有 znodes 当前状态的快照写入文件系统，并为将来的事务创建新的事务日志文件。在快照过程中，ZooKeeper 可能会 continue 将传入的事务追加到旧的日志文件中。因此，一些比快照新的事务可能会在快照之前的最后一个事务日志中找到。

当使用默认配置(请参阅下面的自动清除)时，ZooKeeper 服务器 不会删除旧快照和日志文件 ，这是操作员的责任。每个服务环境都不同，因此安装之间(例如备份)的 Management 这些文件的要求可能会有所不同。

PurgeTxnLogUtil 实现了 Management 员可以使用的简单保留策略。 API docs包含有关调用约定(参数等)的详细信息。

在以下示例中，将保留最后一个计数快照及其对应的日志，并删除其他快照。的值通常应大于 3(尽管不是必需的，但在最近的日志损坏的情况下，这可以提供 3 次备份)。这可以作为 ZooKeeper 服务器计算机上的 cron 作业运行，以每天清理日志。

java -cp zookeeper.jar:lib/slf4j-api-1.7.5.jar:lib/slf4j-log4j12-1.7.5.jar:lib/log4j-1.2.17.jar:conf org.apache.zookeeper.server.PurgeTxnLog <dataDir> <snapDir> -n <count>

自动清除快照和相应的事务日志是在 3.4.0 版中引入的，可以通过以下配置参数 autopurge.snapRetainCount 和 autopurge.purgeInterval 来启用。有关更多信息，请参见下面的Advanced Configuration。

调试日志清除(log4j)

请参阅本文档中关于logging的部分。期望您将使用内置的 log4j 功能来设置滚动文件追加程序。发行版 tar 的 conf/log4j.properties 中的 samples 配置文件提供了一个示例。

Supervision

您将需要一个 Management 流程来 Management 您的每个 ZooKeeper 服务器流程(JVM)。 ZK 服务器被设计为“快速失败”，这意味着如果发生无法恢复的错误，它将关闭(进程退出)。由于 ZooKeeper 服务群集高度可靠，因此这意味着虽然服务器可能宕机，但群集仍处于活动状态并正在处理请求。此外，由于群集是“自我修复”的，因此一旦失败的服务器重新启动，将自动重新加入整体，而无需任何手动交互。

拥有daemontools或SMF之类的监督流程(也可以使用其他监督程序选项，这取决于您要使用哪个，这只是两个示例)，对 ZooKeeper 服务器进行 Management 可以确保该过程确实退出时将自动重启并迅速重新加入集群。

还建议将 ZooKeeper 服务器进程配置为在发生 OutOfMemoryError *时终止并转储其堆。这是通过分别在 Linux 和 Windows 上使用以下参数启动 JVM 来实现的。 ZooKeeper 附带的 zkServer.sh 和 zkServer.cmd *脚本设置了这些选项。

-XX:+HeapDumpOnOutOfMemoryError -XX:OnOutOfMemoryError='kill -9 %p'

"-XX:+HeapDumpOnOutOfMemoryError" "-XX:OnOutOfMemoryError=cmd /c taskkill /pid %%%%p /t /f"

Monitoring

ZooKeeper 服务可以通过以下两种主要方式之一进行监视： 1)通过使用4 个字母词的命令端口和 2)JMX。请参阅适合您的环境/要求的部分。

Logging

ZooKeeper 使用 SLF4J 版本 1.7.5 作为其日志记录基础结构。为了向后兼容，它绑定到 LOG4J ，但是您可以使用 LOGBack 或您选择的任何其他受支持的日志记录框架。

ZooKeeper 的默认* log4j.properties 文件位于 conf 目录中。 Log4j 要求 log4j.properties *可以在工作目录(运行 ZooKeeper 的目录)中，也可以从 Classpath 访问。

有关 SLF4J 的更多信息，请参见its manual。

有关 LOG4J 的更多信息，请参见 log4j 手册的Log4j 默认初始化过程。

Troubleshooting

Configuration Parameters

ZooKeeper 的行为由 ZooKeeper 配置文件控制。设计此文件的目的是，假设磁盘布局相同，组成 ZooKeeper 服务器的所有服务器都可以使用完全相同的文件。如果服务器使用不同的配置文件，则必须注意确保所有不同配置文件中的服务器列表匹配。

Note

Note

在 3.5.0 及更高版本中，其中一些参数应放置在动态配置文件中。如果将它们放置在静态配置文件中，则 ZooKeeper 会自动将它们移到动态配置文件中。有关更多信息，请参见Dynamic Reconfiguration。

Minimum Configuration

以下是必须在配置文件中定义的最低配置关键字：

Note

Note

请注意将事务日志放在何处。专用的事务日志设备是保持良好性能的关键。将日志放在繁忙的设备上会对性能产生不利影响。

Advanced Configuration

本节中的配置设置是可选的。您可以使用它们进一步调整 ZooKeeper 服务器的行为。也可以使用 Java 系统属性(通常为* zookeeper.keyword *形式)进行设置。可用时，确切的系统属性在下面列出。

Note

Note

拥有专用的日志设备对吞吐量和稳定的延迟有很大的影响。强烈建议您专门使用一个日志设备并设置 dataLogDir 指向该设备上的目录，然后确保将 dataDir 指向该设备上不存在的目录。

Cluster Options

本节中的选项设计用于与一组服务器一起使用，即在部署服务器群集时。

Note

Note

现在**不推荐使用领导人选举 1 和 2 的实现。我们打算在下一个版本中删除它们，届时只有 FastLeaderElection 将可用。

Note

Note

当您在一个集合中具有三个以上的 ZooKeeper 服务器时，强烈建议打开领导者选择。

Note

Note

默认值为 5 秒。

4lw.commands.whitelist=stat, ruok, conf, isro

如果您确实需要默认情况下启用所有四个字母单词命令，则可以使用星号选项，这样您就不必在列表中一个接一个地添加每个命令。例如，这将启用所有四个字母词命令：

4lw.commands.whitelist=*

加密，身份验证，授权选项

本节中的选项允许控制服务执行的加密/认证/授权。

在此页面旁边，您还可以在Programmers Guide中找到有关 Client 端配置的有用信息。 ZooKeeper Wiki 还具有关于ZooKeeper SSL 支持和ZooKeeper 的 SASL 身份验证的有用页面。

Experimental Options/Features

当前被认为是实验性的新功能。

Unsafe Options

以下选项可能有用，但是在使用它们时要小心。解释每个变量的风险以及变量作用的解释。

禁用数据目录自动创建

3.5 中的新增功能： ZooKeeper 服务器的默认行为是在启动时自动创建数据目录(在配置文件中指定)，如果该目录尚不存在。在某些情况下，这可能会带来不便，甚至是危险。以正在运行的服务器的配置更改为例，其中 dataDir 参数被意外更改。当 ZooKeeper 服务器重新启动时，它将创建一个不存在的目录并开始提供服务-带有一个空的 znode 命名空间。这种情况可能导致有效的“裂脑”情况(即新无效目录和原始有效数据存储区中的数据)。因此，最好选择一个选项来关闭此自动创建行为。通常，对于生产环境，应该这样做，但是不幸的是，此时默认的旧行为无法更改，因此必须视具体情况进行更改。这留给用户和 ZooKeeper 发行版的打包者。

当运行 zkServer.sh 时，可以通过将环境变量 ZOO_DATADIR_AUTOCREATE_DISABLE 设置为 1 来禁用自动创建。当直接从类文件运行 ZooKeeper 服务器时，可以通过设置 **zookeeper.datadir.autocreate = false 来实现.在 Java 命令行上，即 -Dzookeeper.datadir.autocreate = false **

当禁用此功能，并且 ZooKeeper 服务器确定所需的目录不存在时，它将生成错误并拒绝启动。

提供了一个新脚本 zkServer-initialize.sh 以支持此新功能。如果禁用了自动创建，则用户必须首先安装 ZooKeeper，然后创建数据目录(可能还有 txnlog 目录)，然后启动服务器。否则，如前一段所述，服务器将无法启动。运行 zkServer-initialize.sh 将创建所需的目录，并可选地设置 myid 文件(可选的命令行参数)。即使不使用自动创建功能本身，也可以使用此脚本，并且该脚本可能已被用户使用，因为过去(用户设置(包括创建 myid 文件))已经成为问题。请注意，此脚本确保数据目录仅存在，它不会创建配置文件，而是需要一个配置文件才能执行。

性能调整选项

3.5.0 中的新增功能： 已对多个子系统进行了改进，以提高读取吞吐量。这包括 NIO 通信子系统和请求处理管道(Commit Processor)的多线程。 NIO 是默认的 Client 端/服务器通信子系统。它的线程模型包括 1 个接收器线程，1-N 个 selectors 线程和 0-M 个套接字 I/O 工作线程。在请求处理管道中，系统可以配置为一次处理多个读取请求，同时保持相同的一致性保证(相同的会话写入后读取)。提交处理器线程模型包括 1 个主线程和 0-N 个工作线程。

默认值旨在最大化专用 ZooKeeper 机器上的读取吞吐量。这两个子系统都需要有足够数量的线程才能达到峰值读取吞吐量。

AdminServer configuration

3.5.0 中的新增功能： 以下选项用于配置AdminServer。

使用 Netty 框架进行通信

Netty是基于 NIO 的 Client 端/服务器通信框架，它简化了 Java 应用程序的网络级通信的许多复杂性(通过直接使用的 NIO)。此外，Netty 框架内置了对加密(SSL)和身份验证(证书)的支持。这些是可选功能，可以单独打开或关闭。

在版本 3.5 中，通过将环境变量 zookeeper.serverCnxnFactory 设置为 org.apache.zookeeper.server.NettyServerCnxnFactory ，ZooKeeper 服务器可以使用 Netty 代替 NIO(默认选项)；对于 Client 端，请将 zookeeper.clientCnxnSocket 设置为 org.apache.zookeeper.ClientCnxnSocketNetty 。

Quorum TLS

基于 Netty Framework，可以将 ZooKeeper 集成设置为在其通信通道中使用 TLS 加密。本节介绍如何在仲裁通信中设置加密。

请注意，Quorum TLS 封装了确保领导者选举和法定通信协议的安全。

应该为每个 ZK 实例创建一个密钥库。

在此示例中，我们生成一个自签名证书，并将其与私钥一起存储在keystore.jks中。这适合于测试目的，但是您可能需要正式证书才能在生产环境中对密钥进行签名。

请注意，别名(-alias)和专有名称(-dname)必须与关联计算机的主机名匹配，否则主机名验证将不起作用。

keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password

仅对自签名证书才需要执行此步骤.

keytool -exportcert -alias $(hostname -f) -keystore keystore.jks -file $(hostname -f).cer -rfc

同一信任库(存储所有接受的证书)应在集合的参与者之间共享。您需要使用不同的别名将多个证书存储在同一信任库中。别名的名称无关紧要。

keytool -importcert -alias [host1..3] -file [host1..3].cer -keystore truststore.jks -storepass password

sslQuorum=true serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory ssl.quorum.keyStore.location=/path/to/keystore.jks ssl.quorum.keyStore.password=password ssl.quorum.trustStore.location=/path/to/truststore.jks ssl.quorum.trustStore.password=password

INFO [main:QuorumPeer@1789] - Using TLS encrypted quorum communication INFO [main:QuorumPeer@1797] - Port unification disabled ... INFO [QuorumPeerListener:QuorumCnxManager$Listener@877] - Creating TLS-only quorum server socket

升级现有的非 TLS 群集而无停机时间

这是通过利用端口统一功能在不停机的情况下将已经运行的 ZooKeeper 集成升级到 TLS 所需的步骤。

sslQuorum=false portUnification=true serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory ssl.quorum.keyStore.location=/path/to/keystore.jks ssl.quorum.keyStore.password=password ssl.quorum.trustStore.location=/path/to/truststore.jks ssl.quorum.trustStore.password=password

请注意，尚未启用 TLS，但我们打开了端口统一。

INFO [main:QuorumPeer@1791] - Using insecure (non-TLS) quorum communication INFO [main:QuorumPeer@1797] - Port unification enabled ... INFO [QuorumPeerListener:QuorumCnxManager$Listener@874] - Creating TLS-enabled quorum server socket

在每个节点重新启动后，还应该仔细检查仲裁是否再次恢复正常。

sslQuorum=true portUnification=true

sslQuorum=true portUnification=false

ZooKeeper Commands

四个字母词

ZooKeeper 响应少量命令。每个命令由四个字母组成。您可以在 Client 端端口通过 telnet 或 nc 向 ZooKeeper 发出命令。

三个更有趣的命令：“ stat”提供有关服务器和连接的 Client 端的一些常规信息，而“ srvr”和“ cons”分别提供有关服务器和连接的扩展详细信息。

3.5.3 中的新增功能： 使用前，必须将四个字母词明确列出为白色。有关详细信息，请参阅集群配置部分中描述的 4lw.commands.whitelist 。展望 Future，不建议使用四个字母词，请改用AdminServer。

$ echo mntr | NClocalhost2185 zk_version 3.4.0 zk_avg_latency 0 zk_max_latency 0 zk_min_latency 0 zk_packets_received 70 zk_packets_sent 69 个 zk_num_alive_connections 1 个 zk_outstanding_requests 0 zk_server_state 前导 zk_znode_count 4 zk_watch_count 0 zk_ephemerals_count 0 zk_approximate_data_size 27 个 zk_followers 4 - 仅由组长 zk_synced_followers 4 露出 - 仅由组长 zk_pending_syncs 0 暴露 - 仅由领导者公开 zk_open_file_descriptor_count 23-仅在 Unix 平台上可用 zk_max_file_descriptor_count 1024-仅在 Unix 平台上可用 zk_last_proposal_size 23 zk_min_proposal_size 23 zk_max_proposal_size 64

输出与 Java 属性格式兼容，并且内容可能会随时间变化(添加了新键)。您的脚本应该会有变化。注意：一些密钥是特定于平台的，而某些密钥仅由 Leader 导出。输出包含具有以下格式的多行：

key \t value
跟踪掩码位值
0b0000000000 未使用，保留以备将来使用。
0b0000000010 记录 Client 端请求，但不包括 ping 请求。
0b0000000100 未使用，保留以备将来使用。
0b0000001000 记录 Client 端 ping 请求。
0b0000010000 记录从作为当前领导者的仲裁对等方收到的数据包，但不包括 ping 请求。
0b0000100000 记录 Client 端会话的添加，删除和验证。
0b0001000000 记录监视事件到 Client 端会话的传递。
0b0010000000 记录从作为当前领导者的仲裁对等方收到的 ping 数据包。
0b0100000000 未使用，保留以备将来使用。
0b1000000000 未使用，保留以备将来使用。

64 位值中的所有其余位均未使用，并保留以供将来使用。通过计算记录值的按位或，可以指定多个跟踪日志记录类别。默认跟踪掩码为 0b0100110010.因此，默认情况下，跟踪日志记录包括 Client 端请求，从领导者接收的数据包和会话。要设置其他跟踪掩码，请发送一个请求，该请求包含stmk个四个字母的单词，后跟跟踪掩码，表示为一个 64 位带符号的 long 值。本示例使用 Perl pack函数构造一个跟踪掩码，该掩码启用上述所有跟踪日志记录类别，并将其转换为具有 big-endian 字节 Sequences 的 64 位有符号 long 值。结果将附加到stmk并使用 netcat 发送到服务器。服务器以十进制格式响应新的跟踪掩码。

$ perl -e“打印'stmk'，pack('q>'，0b0011111010)” | nclocalhost2181 250

这是 ruok 命令的示例：

$ echo ruok | nc 127.0.0.1 5111
    imok

The AdminServer

3.5.0 中的新增功能： AdminServer 是嵌入式 Jetty 服务器，为四个字母单词命令提供 HTTP 接口。默认情况下，服务器在端口 8080 上启动，并通过转到 URL“/commands/[command name]”发出命令，例如 http：// localhost：8080/commands/stat。命令响应作为 JSON 返回。与原始协议不同，命令不限于四个字母的名称，命令可以具有多个名称。例如，“ stmk”也可以称为“ set_trace_mask”。要查看所有可用命令的列表，请将浏览器指向 URL/commands(例如，http：// localhost：8080/commands)。有关如何更改端口和 URL 的信息，请参见AdminServer 配置选项。

AdminServer 默认情况下处于启用状态，但可以通过以下任一方式禁用：

请注意，如果 AdminServer 被禁用，则 TCP 四字母词接口仍然可用。

数据文件 Management

ZooKeeper 将其数据存储在数据目录中，并将其事务日志存储在事务日志目录中。默认情况下，这两个目录相同。可以(并且应该)将服务器配置为将事务日志文件存储在与数据文件不同的目录中。当事务日志驻留在专用日志设备上时，吞吐量增加而延迟减少。

数据目录

此目录中包含两个或三个文件：

每个 ZooKeeper 服务器都有一个唯一的 ID。该 id 在两个地方使用：* myid *文件和配置文件。 * myid 文件标识与给定数据目录相对应的服务器。配置文件列出了由服务器 ID 标识的每个服务器的联系信息。当 ZooKeeper 服务器实例启动时，它会从 myid *文件中读取其 ID，然后使用该 ID 从配置文件中读取并查找其应侦听的端口。

从某种意义上说，存储在数据目录中的* snapshot *文件是模糊快照，即在 ZooKeeper 服务器拍摄快照的过程中，数据树正在更新。 * snapshot 文件名的后缀是快照开始时最后提交的事务的 zxid *(ZooKeeper 事务 ID)。因此，快照包括在快照进行过程中发生的数据树更新的子集。因此，快照可能与实际存在的任何数据树都不对应，因此，我们将其称为模糊快照。尽管如此，ZooKeeper 仍可以使用此快照进行恢复，因为它利用了其更新的幂等性质。通过针对模糊快照重播事务日志，ZooKeeper 可以在日志末尾获取系统状态。

日志目录

日志目录包含 ZooKeeper 事务日志。在进行任何更新之前，ZooKeeper 确保将代表该更新的事务写入非易失性存储。当写入当前日志文件的事务数达到(可变)阈值时，将启动一个新的日志文件。使用影响快照频率的相同参数计算阈值(请参见上面的 snapCount)。日志文件的后缀是写入该日志的第一个 zxid。

File Management

在独立的 ZooKeeper 服务器和复制的 ZooKeeper 服务器的不同配置之间，快照和日志文件的格式不会更改。因此，您可以将这些文件从运行中的复制的 ZooKeeper 服务器拉到带有独立 ZooKeeper 服务器的开发计算机上，以进行故障排除。

使用较旧的日志和快照文件，您可以查看 ZooKeeper 服务器的先前状态，甚至可以恢复该状态。 LogFormatter 类允许 Management 员查看日志中的事务。

ZooKeeper 服务器创建快照和日志文件，但从不删除它们。数据和日志文件的保留策略是在 ZooKeeper 服务器外部实现的。服务器本身仅需要最新的完整模糊快照，其后的所有日志文件以及其前的最后一个日志文件。后一个要求是必需的，以包括在启动此快照之后发生的更新，但该更新当时已存在于现有的日志文件中。之所以可能这样做，是因为在 ZooKeeper 中，快照的快照和日志的翻转在某种程度上是独立进行的。有关设置保留策略和维护 ZooKeeper 存储的更多详细信息，请参阅本文档的maintenance部分。

Note

Note

这些文件中存储的数据未加密。在 ZooKeeper 中存储敏感数据的情况下，需要采取必要的措施来防止未经授权的访问。此类措施在 ZooKeeper 外部(例如，控制对文件的访问)，并且取决于部署该文件的各个设置。

恢复-TxnLogToolkit

TxnLogToolkit 是 ZooKeeper 附带的命令行工具，能够恢复带有损坏 CRC 的事务日志条目。

在不使用任何命令行参数或不使用-h,--help参数的情况下运行它，它将输出以下帮助页面：

$ bin/zkTxnLogToolkit.sh
usage: TxnLogToolkit [-dhrv] txn_log_file_name
-d,--dump      Dump mode. Dump all entries of the log file. (this is the default)
-h,--help      Print help message
-r,--recover   Recovery mode. Re-calculate CRC for broken entries.
-v,--verbose   Be verbose in recovery mode: print all entries, not just fixed ones.
-y,--yes       Non-interactive mode: repair all CRC errors without asking

默认行为是安全的：将给定事务日志文件的条目转储到屏幕上：(与使用-d,--dump参数相同)

$ bin/zkTxnLogToolkit.sh log.100000001
ZooKeeper Transactional Log File with dbid 0 txnlog format version 2
4/5/18 2:15:58 PM CEST session 0x16295bafcc40000 cxid 0x0 zxid 0x100000001 createSession 30000
CRC ERROR - 4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null
4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null
4/5/18 2:16:12 PM CEST session 0x26295bafcc90000 cxid 0x0 zxid 0x100000003 createSession 30000
4/5/18 2:17:34 PM CEST session 0x26295bafcc90000 cxid 0x0 zxid 0x200000001 closeSession null
4/5/18 2:17:34 PM CEST session 0x16295bd23720000 cxid 0x0 zxid 0x200000002 createSession 30000
4/5/18 2:18:02 PM CEST session 0x16295bd23720000 cxid 0x2 zxid 0x200000003 create '/andor,#626262,v{s{31,s{'world,'anyone}}},F,1
EOF reached after 6 txns.

上面的事务日志文件的第二个条目中有一个 CRC 错误。在 转储 模式下，该工具包仅将此信息打印到屏幕上，而无需触摸原始文件。在“恢复”模式(-r,--recover标志)下，原始文件仍然保持不变，所有事务将被复制到后缀为“ .fixed”的新 txn 日志文件中。如果它与原始 txn 条目不匹配，它将重新计算 CRC 值并复制计算出的值。默认情况下，该工具以交互方式工作：遇到 CRC 错误时，它会要求进行确认。

$ bin/zkTxnLogToolkit.sh -r log.100000001
ZooKeeper Transactional Log File with dbid 0 txnlog format version 2
CRC ERROR - 4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null
Would you like to fix it (Yes/No/Abort) ?

回答“是”表示新计算的 CRC 值将输出到新文件。 否 表示将复制原始的 CRC 值。 中止 将中止整个操作并退出。 (在这种情况下，“.fixed”将不会被删除，并处于半完成状态：仅包含已经处理过的条目，或者如果操作在第一个条目中止，则仅包含 Headers.)

$ bin/zkTxnLogToolkit.sh -r log.100000001
ZooKeeper Transactional Log File with dbid 0 txnlog format version 2
CRC ERROR - 4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null
Would you like to fix it (Yes/No/Abort) ? y
EOF reached after 6 txns.
Recovery file log.100000001.fixed has been written with 1 fixed CRC error(s)

恢复的默认行为是保持沉默：仅将带有 CRC 错误的条目打印到屏幕上。可以使用-v,--verbose参数打开详细模式以查看所有记录。可以使用-y,--yes参数关闭交互模式。在这种情况下，所有 CRC 错误都将在新的事务文件中修复。

应避免的事情

通过正确配置 ZooKeeper，可以避免以下一些常见问题：

Best Practices

为了获得最佳效果，请注意以下 Zookeeper 良好做法列表：

对于多租户安装，请参见section详细介绍 ZooKeeper 的“ chroot”支持，这在将许多与单个 ZooKeeper 群集接口的应用程序/服务部署时非常有用。

首页