ZooKeeper管理员指南
ZooKeeper管理员指南
部署和管理指南
- 部署
- 系统要求
- 支持的平台
- 必备软件
- 群集（多服务器）安装程序
- 单服务器和开发人员设置
- 系统要求
- 管理
- 设计ZooKeeper部署
- 跨机器要求
- 单机要求
- 供应
- 需要考虑的事项：ZooKeeper的优势和局限
- 管理
- 保养
- 正在进行的数据目录清理
- 调试日志清理（log4j）
- 监督
- 监控
- 记录
- 故障排除
- 配置参数
- 最低配置
- 高级配置
- 群集选项
- 加密，身份验证，授权选项
- 实验选项/功能
- 不安全的选择
- 禁用数据目录自动创建
- 启用db存在验证
- 性能调整选项
- 使用Netty框架进行通信
- AdminServer配置
- ZooKeeper命令
- 四字母词
- AdminServer
- 数据文件管理
- 数据目录
- 日志目录
- 文件管理
- 恢复 - TxnLogToolkit
- 要避免的事情
- 最佳实践
- 设计ZooKeeper部署
部署
本节包含有关部署Zookeeper的信息，并涵盖以下主题：
- 系统要求
- 群集（多服务器）安装程序
- 单服务器和开发人员设置
前两节假设您有兴趣在生产环境（如数据中心）中安装ZooKeeper。最后一节介绍了在有限的基础上设置ZooKeeper的情况 - 用于评估，测试或开发 - 但不适用于生产环境。
系统要求
支持的平台
ZooKeeper由多个组件组成。某些组件得到广泛支持，其他组件仅在较小的平台上受支持。
- 客户端是Java客户端库，应用程序使用它连接到ZooKeeper集合。
- Server是在ZooKeeper集合节点上运行的Java服务器。
- Native Client是一个用C实现的客户端，类似于Java客户端，应用程序用它来连接ZooKeeper集合。
- Contrib是指多个可选的附加组件。
以下矩阵描述了为在不同操作系统平台上运行每个组件而提交的支持级别。
支持矩阵
| 操作系统 | 客户 | 服务器 | 原生客户端 | 的Contrib |
|---|---|---|---|---|
| GNU / Linux的 | 开发和生产 | 开发和生产 | 开发和生产 | 开发和生产 |
| 的Solaris | 开发和生产 | 开发和生产 | 不支持 | 不支持 |
| FreeBSD的 | 开发和生产 | 开发和生产 | 不支持 | 不支持 |
| 视窗 | 开发和生产 | 开发和生产 | 不支持 | 不支持 |
| Mac OS X. | 仅限发展 | 仅限发展 | 不支持 | 不支持 |
对于矩阵中未明确提及的任何操作系统，组件可能有效，也可能无效。ZooKeeper社区将修复针对其他平台报告的明显错误，但没有完全支持。
必备软件
ZooKeeper在Java中运行，1.7或更高版本（JDK 7或更高版本，FreeBSD支持需要openjdk7）。它作为ZooKeeper服务器的集合运行 。三个ZooKeeper服务器是整体的最小建议大小，我们还建议它们在不同的机器上运行。在Yahoo！，ZooKeeper通常部署在专用的RHEL盒子上，具有双核处理器，2GB RAM和80GB IDE硬盘。
群集（多服务器）安装程序
对于可靠的ZooKeeper服务，您应该在称为集合的集群中部署ZooKeeper 。只要合奏的大部分都在增加，该服务将可用。因为Zookeeper需要占多数，所以最好使用奇数个机器。例如，使用四台机器，ZooKeeper只能处理单台机器的故障; 如果两台机器出现故障，其余两台机器不会占多数。但是，有了五台机器，ZooKeeper可以处理两台机器的故障。
＃＃＃＃＃＃注意
如 ZooKeeper入门指南中所述 ，容错群集设置至少需要三台服务器，强烈建议您使用奇数个服务器。
通常三台服务器对于生产安装来说已经足够了，但为了在维护期间获得最大可靠性，您可能希望安装五台服务器。使用三台服务器时，如果对其中一台服务器执行维护，则在维护期间，您很容易在其他两台服务器上发生故障。如果你有五个正在运行，你可以拿一个进行维护，并且知道如果其他四个中的一个突然失败你仍然可以。
您的冗余注意事项应包括环境的所有方面。如果您有三台ZooKeeper服务器，但它们的网络电缆都插入同一个网络交换机，那么该交换机的故障将会占用整个集合。
以下是设置将成为集合一部分的服务器的步骤。这些步骤应该在整体中的每个主机上执行：
-
安装Java JDK。您可以为系统使用本机打包系统，也可以从以下位置下载JDK：http：//java.sun.com/javase/downloads/index.jsp
-
设置Java堆大小。这对于避免交换非常重要，这会严重降低ZooKeeper的性能。要确定正确的值，请使用负载测试，并确保远低于导致交换的使用限制。保守一点 - 对于4GB机器，最大堆大小为3GB。
-
安装ZooKeeper服务器包。它可以从http://zookeeper.apache.org/releases.html下载
-
创建配置文件。这个文件可以被称为任何东西。使用以下设置作为起点：
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您可以在“ 配置参数 ”部分中找到这些和其他配置设置的含义。这里有一个词虽然有几个：ZooKeeper整体中的每台机器都应该知道整体中的其他机器。您可以使用server.id = host：port：port形式的一系列行来完成此操作。参数host和port很简单。您可以通过创建名为myid的文件将服务器ID归因于每台计算机，每个服务器对应一个文件 ，该文件位于该服务器的数据目录中，由配置文件参数dataDir指定。
-
myid文件由一行组成，只包含该机器id的文本。所以服务器1的myid将包含文本“1”而没有别的。id在整体中必须是唯一的，其值应介于1到255之间。 重要信息：如果启用TTL节点等扩展功能（见下文），由于内部限制，id必须介于1和254之间。
-
创建初始化标记文件初始化 在同一目录身份识别码。此文件表示需要空数据目录。如果存在，则创建空数据库并删除标记文件。如果不存在，则空数据目录将表示此对等方将没有投票权，并且在与活动领导者通信之前不会填充数据目录。预期用途是仅在创建新集合时创建此文件。
-
如果您的配置文件已设置，则可以启动ZooKeeper服务器：
$ 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.quorum.QuorumPeerMain zoo.cfg
QuorumPeerMain启动ZooKeeper服务器， 还注册了JMX管理bean，允许通过JMX管理控制台进行管理。该ZooKeeper的JMX文件包含有关使用JMX管理ZooKeeper的细节。有关启动服务器实例的示例，请参阅发行版中包含的脚本bin / zkServer.sh。8.通过连接到主机来测试部署：在Java中，您可以运行以下命令来执行简单操作：
$ bin/zkCli.sh -server 127.0.0.1:2181
单服务器和开发人员设置
如果要设置ZooKeeper用于开发目的，您可能需要设置ZooKeeper的单个服务器实例，然后在开发计算机上安装Java或C客户端库和绑定。
设置单个服务器实例的步骤与上述类似，但配置文件更简单。您可以在ZooKeeper入门指南的“ 单服务器模式下安装和运行ZooKeeper”部分找到完整说明。
有关安装客户端库的信息，请参阅ZooKeeper程序员指南的Bindings 部分。
管理
本节包含有关运行和维护ZooKeeper的信息，并涵盖以下主题：
- 设计ZooKeeper部署
- 供应
- 需要考虑的事项：ZooKeeper的优势和局限
- 管理
- 保养
- 监督
- 监控
- 记录
- 故障排除
- 配置参数
- ZooKeeper命令
- 数据文件管理
- 要避免的事情
- 最佳实践
设计ZooKeeper部署
ZooKeeper的可靠性取决于两个基本假设。
- 部署中只有少数服务器会失败。此上下文中的失败意味着机器崩溃或网络中的一些错误将服务器与大多数分区。
- 部署的机器正常运行。正确操作意味着正确执行代码，使时钟正常工作，并使存储和网络组件始终如一地执行。
以下部分包含ZooKeeper管理员的注意事项，以最大化这些假设保持为真的概率。其中一些是跨机器考虑因素，而另一些则是您应该为部署中的每台计算机考虑的事项。
跨机器要求
要使ZooKeeper服务处于活动状态，必须有大多数可以相互通信的非故障机器。要创建可以容忍F计算机故障的部署，您应该依赖部署2xF + 1计算机。因此，由三台机器组成的部署可以处理一个故障，而五台机器的部署可以处理两个故障。请注意，由于三台计算机不是多数，因此部署六台计算机只能处理两次故障。因此，ZooKeeper部署通常由奇数个计算机组成。
为了实现容忍故障的最高概率，您应该尝试使机器故障独立。例如，如果大多数机器共享同一个交换机，则该交换机的故障可能导致相关故障并导致服务中断。共享电源电路，冷却系统等也是如此。
单机要求
如果ZooKeeper必须与其他应用程序竞争访问存储介质，CPU，网络或内存等资源，其性能将受到显着影响。ZooKeeper具有强大的持久性保证，这意味着它允许存储介质记录更改，然后才能完成负责更改的操作。您应该知道这种依赖关系，如果您想确保媒体不会阻止ZooKeeper操作，请务必小心。以下是您可以采取的一些措施，以尽量减少这种退化：
- ZooKeeper的事务日志必须位于专用设备上。（专用分区是不够的。）ZooKeeper按顺序写入日志，而不寻求与其他进程共享您的日志设备可能导致搜索和争用，这反过来可能导致多秒延迟。
- 不要将ZooKeeper置于可能导致交换的情况。为了使ZooKeeper能够以任何时间运行，它根本不允许交换。因此，请确保为ZooKeeper提供的最大堆大小不大于ZooKeeper可用的实际内存量。有关详细信息，请参阅 下面的“ 要避免的事项”。
供应
需要考虑的事项：ZooKeeper的优势和局限
管理
保养
ZooKeeper集群需要很少的长期维护，但您必须了解以下内容：
正在进行的数据目录清理
ZooKeeper 数据目录包含的文件是特定服务集合存储的znode的持久副本。这些是快照和事务日志文件。随着对znode的更改，这些更改将附加到事务日志中。有时，当日志变大时，所有znode的当前状态的快照将写入文件系统，并为将来的事务创建新的事务日志文件。在快照期间，ZooKeeper可以继续将传入事务附加到旧日志文件。因此，可以在快照之前的最后一个事务日志中找到一些比快照更新的事务。
使用默认配置时，ZooKeeper服务器不会删除旧快照和日志文件（请参阅下面的autopurge），这是运营商的责任。每个服务环境都不同，因此管理这些文件的要求可能因安装而不同（例如备份）。
PurgeTxnLog实用程序实现了管理员可以使用的简单保留策略。该API文档包含调用约定（参数等）的详细信息。
在以下示例中，将保留最后的计数快照及其相应的日志，并删除其他日志。值应该通常大于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 -n
版本3.4.0中引入了自动清除快照和相应的事务日志，可以通过以下配置参数autopurge.snapRetainCount和autopurge.purgeInterval启用。有关详细信息，请参阅 下面的高级配置。
调试日志清理（log4j）
请参阅本文档中的登录部分。预计您将使用内置的log4j功能设置滚动文件追加器。发行版tar的conf / log4j.properties中的示例配置文件提供了此示例。
监督
您将需要一个管理每个ZooKeeper服务器进程（JVM）的监督过程。ZK服务器被设计为“快速失败”，这意味着如果发生无法恢复的错误，它将关闭（进程退出）。由于ZooKeeper服务群集非常可靠，这意味着虽然服务器可能会在整个群集中停留，但仍然处于活动状态并提供请求。此外，由于群集是“自我修复”，故障服务器一旦重新启动，将自动重新加入整体，无需任何手动交互。
有一个监控过程，如daemontools或 SMF （监控过程的其他选项也可用，取决于你想要使用哪一个，这只是两个例子）管理你的ZooKeeper服务器确保如果进程异常退出它将自动重新启动并快速重新加入群集。
如果发生OutOfMemoryError **，还建议将ZooKeeper服务器进程配置为终止并转储其堆。这是通过分别在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"
监控
ZooKeeper服务可以通过两种主要方式之一进行监控; 1）命令端口通过使用4个字母的单词和2）JMX。有关您的环境/要求，请参阅相应部分。
记录
ZooKeeper使用SLF4J 版本1.7.5作为其日志记录基础结构。为了向后兼容，它绑定到 LOG4J，但您可以使用 LOGBack 或您选择的任何其他支持的日志框架。
ZooKeeper默认的log4j.properties 文件位于conf目录中。Log4j要求 log4j.properties位于工作目录（运行ZooKeeper的目录）中，或者可以从类路径访问。
有关SLF4J的更多信息，请参阅 其手册。
有关LOG4J的更多信息，请参阅 log4j手册的Log4j默认初始化过程。
故障排除
- 服务器因文件损坏而无法启动：由于ZooKeeper服务器的事务日志中的某些文件损坏，服务器可能无法读取其数据库并且无法启动。您将在加载ZooKeeper数据库时看到一些IOException。在这种情况下，请确保您的整体中的所有其他服务器都已启动并正常工作。在命令端口上使用“stat”命令查看它们是否运行状况良好。在验证了集合的所有其他服务器都已启动后，您可以继续清理损坏服务器的数据库。删除datadir / version-2和datalogdir / version-2 /中的所有文件。重启服务器。
配置参数
ZooKeeper的行为由ZooKeeper配置文件控制。假设磁盘布局相同，则此文件的设计使得构成ZooKeeper服务器的所有服务器都可以使用完全相同的文件。如果服务器使用不同的配置文件，则必须注意确保所有不同配置文件中的服务器列表匹配。
＃＃＃＃＃＃注意
在3.5.0及更高版本中，其中一些参数应放在动态配置文件中。如果将它们放在静态配置文件中，ZooKeeper会自动将它们移动到动态配置文件中。有关更多信息，请参阅动态重新配置。
最低配置
以下是必须在配置文件中定义的最低配置关键字：
-
clientPort：侦听客户端连接的端口; 也就是客户端尝试连接的端口。
-
secureClientPort：使用SSL侦听安全客户端连接的端口。 clientPort指定明文连接的端口，而secureClientPort指定SSL连接的端口。指定两者都启用混合模式，而忽略将禁用该模式。请注意，当用户将zookeeper.serverCnxnFactory，zookeeper.clientCnxnSocket作为Netty插件时，将启用SSL功能。
-
observerMasterPort：侦听观察者连接的端口; 也就是说，观察者尝试连接的端口。如果设置了属性，那么除了处于领导模式时，服务器将在跟随者模式下托管观察者连接，并且在处于观察者模式时相应地尝试连接到任何投票对等体。
-
dataDir：ZooKeeper将存储内存数据库快照的位置，除非另有说明，否则为数据库更新的事务日志。＃＃＃＃＃＃注意
放置事务日志的位置要小心。专用的事务日志设备是始终如一的良好性能的关键。将日志置于繁忙的设备上会对性能产生负面影响。
-
tickTime：单个tick的长度，是ZooKeeper使用的基本时间单位，以毫秒为单位。它用于调节心跳和超时。例如，最小会话超时将是两个滴答。
高级配置
该部分中的配置设置是可选的。您可以使用它们来进一步微调ZooKeeper服务器的行为。有些也可以使用Java系统属性进行设置，通常采用zookeeper.keyword形式。确切的系统属性（如果可用）如下所示。
-
dataLogDir :(无Java系统属性）此选项将指示计算机将事务日志写入dataLogDir而不是dataDir。这允许使用专用日志设备，并有助于避免日志记录和快照之间的竞争。＃＃＃＃＃＃注意
拥有专用的日志设备会对吞吐量和稳定的延迟产生很大影响。强烈建议专用日志设备并将dataLogDir设置为指向该设备上的目录，然后确保将dataDir指向不驻留在该设备上的目录 。
-
globalOutstandingLimit :( Java系统属性：zookeeper.globalOutstandingLimit。）客户端可以比ZooKeeper更快地提交请求，特别是如果有很多客户端。为了防止ZooKeeper因排队请求而耗尽内存，ZooKeeper将限制客户端，以便系统中只有globalOutstandingLimit未完成的请求。默认限制为1,000。
-
preAllocSize :( Java系统属性：zookeeper.preAllocSize）为了避免搜索，ZooKeeper以preAllocSize千字节为单位在事务日志文件中分配空间。默认块大小为64M。更改块大小的一个原因是，如果更频繁地拍摄快照，则减小块大小。（另请参阅snapCount）。
-
snapCount :( Java系统属性：zookeeper.snapCount）ZooKeeper使用快照和事务日志记录其事务（考虑预写日志）。在获取快照之前记录在事务日志中的事务数（并且事务日志已滚动） ）由snapCount决定。为了防止仲裁中的所有计算机同时拍摄快照，每个ZooKeeper服务器将在事务日志中的事务数达到[snapCount / 2 + 1]中的运行时生成的随机值时拍摄快照，snapCount] range。默认snapCount为100,000。
-
txnLogSizeLimitInKb :( Java系统属性：zookeeper.txnLogSizeLimitInKb）还可以使用txnLogSizeLimitInKb更直接地控制Zookeeper事务日志文件。使用事务日志完成同步时，较大的txn日志可能导致较慢的跟随者同步。这是因为leader必须扫描磁盘上的相应日志文件才能找到要从中开始同步的事务。此默认设置关闭此功能，而snapCount是唯一限制事务日志大小的值。启用时，Zookeeper将在达到任一限制时滚动日志。请注意，实际日志大小可以超过序列化事务的大小。另一方面，如果此值设置得太接近（或小于）preAllocSize，它可以导致Zookeeper为每个tranasaction滚动日志。虽然这不是正确性问题，但这可能会导致性能严重下降。为了避免这种情况并最大限度地利用此功能，建议将值设置为N * preAllocSize ，其中N> = 2。
-
maxClientCnxns :(无Java系统属性）限制由IP地址标识的单个客户端可能对ZooKeeper集合的单个成员进行的并发连接数（在套接字级别）。这用于防止某些类别的DoS攻击，包括文件描述符耗尽。默认值为60.将此值设置为0将完全删除并发连接的限制。
-
clientPortAddress： 3.3.0中的新增内容：侦听客户端连接的地址（ipv4，ipv6或hostname）; 也就是客户端尝试连接的地址。这是可选的，默认情况下我们以这样的方式绑定，即接受服务器上任何地址/接口/ nic 的clientPort的任何连接。
-
minSessionTimeout :(无Java系统属性） 3.3.0中的新增内容：服务器允许客户端协商的最小会话超时（以毫秒为单位）。默认为tickTime的 2倍。
-
maxSessionTimeout :(无Java系统属性） 3.3.0中的新增内容：服务器允许客户端协商的最大会话超时（以毫秒为单位）。默认为tickTime的 20倍。
-
fsync.warningthresholdms :( Java系统属性：zookeeper.fsync.warningthresholdms） 3.3.4中的新增内容：只要事务日志（WAL）中的fsync花费的时间超过此值，就会向日志输出警告消息。值以毫秒为单位指定，默认值为1000.此值只能设置为系统属性。
-
maxResponseCacheSize :( Java系统属性：zookeeper.maxResponseCacheSize）设置为正整数时，它确定存储最近读取记录的序列化形式的缓存大小。有助于节省流行znode的序列化成本。度量response_packet_cache_hits 和response_packet_cache_misses可用于将此值调整为给定工作负载。默认情况下，该功能处于打开状态，值为400，设置为0或负整数以关闭此功能。
-
autopurge.snapRetainCount :(无Java系统属性） 3.4.0中的新增内容： 启用后，ZooKeeper自动清除功能分别在dataDir和dataLogDir中保留autopurge.snapRetainCount最新快照和相应的事务日志，并删除其余的日志 。默认为3.最小值为3。
-
autopurge.purgeInterval :(无Java系统属性） 3.4.0中的新增内容：必须触发清除任务的时间间隔（以小时为单位）。设置为正整数（1和更高）以启用自动清除。默认为0。
-
syncEnabled :( Java系统属性：zookeeper.observer.syncEnabled） 3.4.6,3.5.0中的新增内容： 观察者现在默认记录事务并将快照写入磁盘，就像参与者一样。这减少了重启时观察者的恢复时间。设置为“false”以禁用此功能。默认为“true”
-
fastleader.minNotificationInterval :( Java系统属性：zookeeper.fastleader.minNotificationInterval）对领导者选举的两次连续通知检查之间的时间长度的下限。此间隔确定对等方等待检查选举投票集的时间长度以及影响选举可以解决的速度。该间隔遵循从配置的最小值（this）和配置的最大值（fastleader.maxNotificationInterval）进行长时间选举的退避策略。
-
fastleader.maxNotificationInterval :( Java系统属性：zookeeper.fastleader.maxNotificationInterval）对领导者选举的两次连续通知检查之间的时间长度的上限。此间隔确定对等方等待检查选举投票集的时间长度以及影响选举可以解决的速度。该间隔遵循配置的最小值（fastleader.minNotificationInterval）的退避策略和长期选举的配置的最大值（this）。
群集选项
本节中的选项旨在与服务器集合一起使用 - 即，在部署服务器群集时。
-
electionAlg :(没有Java系统属性）要使用的选举实现。值“1”对应于未经认证的基于UDP的快速领导者选举版本，“2”对应于经认证的基于UDP的快速领导者选举版本，“3”对应于基于TCP的快速领导者选举版本选举。目前，算法3是默认值。＃＃＃＃＃＃注意
领导者选举1和2的实施现已 弃用。我们打算在下一个版本中删除它们，此时只有FastLeaderElection可用。
-
initLimit :(无Java系统属性）允许关注者连接并同步到领导者的时间量（以tick为单位）（请参阅tickTime）。如果ZooKeeper管理的数据量很大，则根据需要增加此值。
-
leaderServes :( Java系统属性：zookeeper。领导者服务）领导者接受客户端连接。默认值为“是”。领导者协调更新。为了获得更高的更新吞吐量，只需稍微花费读取吞吐量，就可以将领导者配置为不接受客户端并专注于协调。此选项的默认值为yes，这表示领导者将接受客户端连接。＃＃＃＃＃＃注意
如果集合中有三个以上的ZooKeeper服务器，强烈建议启用领导者选择。
-
server.x = [hostname]：nnnnn [：nnnnn]等 :(没有Java系统属性）服务器构成ZooKeeper集合。当服务器启动时，它通过在数据目录中查找文件myid来确定它是哪个服务器。该文件包含了服务器数量，在ASCII，它应该与 X在server.x在此设置的左侧。组成客户端使用的ZooKeeper服务器的服务器列表必须与每个ZooKeeper服务器所具有的ZooKeeper服务器列表相匹配。有两个端口号nnnnn。第一批追随者用来连接领导者，第二个追随者用于领导者选举。如果要在一台计算机上测试多个服务器，则可以为每个服务器使用不同的端口。
-
syncLimit :(无Java系统属性）允许关注者与ZooKeeper同步的时间量（以tick为单位）（请参阅tickTime）。如果粉丝落后于领导者，他们就会被淘汰。
-
group.x = nnnnn [：nnnnn] :(无Java系统属性）启用分层仲裁构造。“x”是组标识符，“=”符号后面的数字对应于服务器标识符。赋值的左侧是以冒号分隔的服务器标识符列表。请注意，组必须是不相交的，并且所有组的并集必须是ZooKeeper集合。你会在这里找到一个例子
-
weight.x = nnnnn :(无Java系统属性）与“group”一起使用时，它在形成仲裁时为服务器分配权重。这样的值对应于投票时服务器的权重。ZooKeeper的一些部分需要投票，例如领导者选举和原子广播协议。默认情况下，服务器的权重为1.如果配置定义组而不是权重，则将为所有服务器分配值1。你会在这里找到一个例子
-
cnxTimeout：（Java系统属性：饲养员cnxTimeout）设置为打开领导人选举通知连接超时值。仅在使用electionAlg 3时适用。######注意
默认值为5秒。
-
standaloneEnabled :(无Java系统属性） 3.5.0中的新功能： 当设置为false时，可以在复制模式下启动单个服务器，单个参与者可以使用观察者运行，并且群集可以重新配置为一个节点，并且从一个节点。对于向后兼容性，默认值为true。可以使用QuorumPeerConfig的setStandaloneEnabled方法或通过将“standaloneEnabled = false”或“standaloneEnabled = true”添加到服务器的配置文件来设置它。
-
reconfigEnabled :(无Java系统属性） 3.5.3中的新增功能： 它控制动态重新配置功能的启用或禁用 。启用此功能后，用户可以通过ZooKeeper客户端API或ZooKeeper命令行工具执行重新配置操作，前提是用户有权执行此类操作。禁用此功能后，任何用户（包括超级用户）都无法执行重新配置。任何重新配置的尝试都将返回错误。 “reconfigEnabled”选项可以设置为 “reconfigEnabled = false”或 “reconfigEnabled = true” 到服务器的配置文件，或使用QuorumPeerConfig的setReconfigEnabled方法。默认值为false。如果存在，则该值应该在整个集合中的每个服务器上保持一致。在某些服务器上将值设置为true而在其他服务器上将其设置为false将导致不一致的行为，具体取决于哪个服务器被选为leader。如果领导者的设置为 “reconfigEnabled = true”，则整体将启用重新配置功能。如果领导者的设置为 “reconfigEnabled = false”，则整体将禁用重新配置功能。因此，建议在整体中的服务器之间具有“reconfigEnabled”的一致值。
-
4lw.commands.whitelist :( Java系统属性：zookeeper.4lw.commands.whitelist） 3.5.3中的新功能： 用户想要使用的逗号分隔的四字母单词命令列表。必须在此列表中放入有效的Four Letter Words命令，否则ZooKeeper服务器将不启用该命令。默认情况下，白名单仅包含zkServer.sh使用的“srvr”命令。默认情况下，禁用其余的四个字母单词命令。以下是启用stat，ruok，conf和isro命令的配置示例，同时禁用其余的Four Letter Words命令：
4lw.commands.whitelist=stat, ruok, conf, isro
如果您确实需要默认启用所有四个字母单词命令，则可以使用星号选项，这样您就不必在列表中逐个包含每个命令。例如，这将启用所有四个字母单词命令：
4lw.commands.whitelist=*
- tcpKeepAlive :( Java系统属性：zookeeper.tcpKeepAlive） 3.5.4中的新增内容： 将此设置为true会在仲裁成员用于执行选举的套接字上设置TCP keepAlive标志。这将允许仲裁成员之间的连接在存在可能以其他方式破坏它们的网络基础结构时保持运行。对于长时间运行或空闲连接，某些NAT和防火墙可能会终止或丢失状态。启用此选项依赖于操作系统级别设置才能正常工作，请查看操作系统有关TCP keepalive的选项以获取更多信息。默认为 false。
加密，身份验证，授权选项
本节中的选项允许控制服务执行的加密/身份验证/授权。
-
DigestAuthenticationProvider.superDigest :( Java系统属性：zookeeper.DigestAuthenticationProvider.superDigest）默认情况下，此功能被禁用 3.2中的新功能： 使ZooKeeper集合管理员能够以“超级”用户身份访问znode层次结构。特别是对于经过身份验证的用户，不会进行ACL检查。org.apache.zookeeper.server.auth.DigestAuthenticationProvider可用于生成superDigest，使用一个参数“super：”调用它。在启动整体的每个服务器时，提供生成的“super：”作为系统属性值。当对ZooKeeper服务器（来自ZooKeeper客户端）进行身份验证时，传递“digest”的方案和“super：”的authdata。请注意，摘要auth以明文形式将authdata传递给服务器，仅在localhost（不是通过网络）或通过加密连接使用此身份验证方法是明智的。
-
X509AuthenticationProvider.superUser :( Java系统属性：zookeeper.X509AuthenticationProvider.superUser）支持SSL的方法，使ZooKeeper集合管理员能够以“超级”用户身份访问znode层次结构。当此参数设置为X500主体名称时，只有具有该主体的经过身份验证的客户端才能绕过ACL检查并拥有所有znode的完全权限。
-
zookeeper.superUser :( Java系统属性：zookeeper.superUser）与zookeeper.X509AuthenticationProvider.superUser类似， 但对于基于SASL的登录是通用的。它存储可以作为“超级”用户访问znode层次结构的用户的名称。
-
ssl.keyStore.location和ssl.keyStore.password :( Java系统属性：zookeeper.ssl.keyStore.location和zookeeper.ssl.keyStore.password）指定包含要用于SSL连接的本地凭据的JKS的文件路径，以及解锁文件的密码。
-
ssl.trustStore.location和ssl.trustStore.password :( Java系统属性：zookeeper.ssl.trustStore.location和zookeeper.ssl.trustStore.password）指定包含要用于SSL连接的远程凭据的JKS的文件路径，以及解锁文件的密码。
-
ssl.authProvider :( Java系统属性：zookeeper.ssl.authProvider）指定org.apache.zookeeper.auth.X509AuthenticationProvider的子类， 以用于安全客户端身份验证。这在不使用JKS的证书密钥基础结构中很有用。可能需要扩展javax.net.ssl.X509KeyManager和javax.net.ssl.X509TrustManager 以从SSL堆栈获取所需的行为。要将ZooKeeper服务器配置为使用自定义提供程序进行身份验证，请为自定义AuthenticationProvider选择方案名称，并设置属性zookeeper.authProvider。[scheme]到自定义实现的完全限定类名。这会将提供程序加载到ProviderRegistry中。然后设置此属性zookeeper.ssl.authProvider = [scheme]，该提供程序将用于安全身份验证。
实验选项/功能
目前被认为是实验性的新功能。
- 只读模式服务器：（Java系统属性：readonlymode.enabled） 3.4.0中的新增内容： 将此值设置为true将启用只读模式服务器支持（默认情况下禁用）。即使服务器可能与仲裁分区，ROM也允许请求ROM支持的客户端会话连接到服务器。在此模式下，ROM客户端仍然可以从ZK服务读取值，但无法写入值并查看其他客户端的更改。有关详细信息，请参阅ZOOKEEPER-784。
不安全的选择
以下选项可能很有用，但在使用它们时要小心。解释每个的风险以及变量的作用的解释。
-
forceSync :( Java系统属性：zookeeper.forceSync）要求在完成更新处理之前将更新同步到事务日志的介质。如果此选项设置为no，则ZooKeeper不需要将更新同步到媒体。
-
jute.maxbuffer : :（Java system property：jute.maxbuffer）此选项只能设置为Java系统属性。它上面没有zookeeper前缀。它指定可以存储在znode中的数据的最大大小。默认值为0xfffff，或者仅为1M。如果更改此选项，则必须在所有服务器和客户端上设置系统属性，否则将出现问题。这真是一个健全检查。ZooKeeper旨在存储大小为千字节的数据。
-
skipACL :( Java系统属性：zookeeper.skipACL）跳过ACL检查。这样可以提高吞吐量，但可以向所有人开放对数据树的完全访问权限。
-
quorumListenOnAllIPs：当设置为true时，ZooKeeper服务器将在所有可用IP地址上侦听来自其对等方的连接，而不仅是在配置文件的服务器列表中配置的地址。它会影响处理ZAB协议和快速领导者选举协议的连接。默认值为false。
禁用数据目录自动创建
3.5中的新功能： ZooKeeper服务器的默认行为是，如果该目录尚不存在，则在启动时自动创建数据目录（在配置文件中指定）。在某些情况下，这可能是不方便的甚至是危险的。假设对正在运行的服务器进行配置更改，其中dataDir参数被意外更改。当ZooKeeper服务器重新启动时，它将创建这个不存在的目录并开始服务 - 使用空的znode命名空间。这种情况可能导致有效的“裂脑”情况（即新的无效目录和原始有效数据存储中的数据）。因此，可以选择关闭此自动创建行为。通常，对于生产环境，这应该是完成的，但不幸的是，此时无法更改默认的遗留行为，因此必须根据具体情况进行此操作。这留给了用户和ZooKeeper发行版的打包者。
运行zkServer.sh时，可以通过将环境变量ZOO_DATADIR_AUTOCREATE_DISABLE设置为1 来禁用autocreate 。直接从类文件运行ZooKeeper服务器时，可以通过在java命令行上设置zookeeper.datadir.autocreate = false来完成，即-Dzookeeper.datadir .autocreate = FALSE
禁用此功能，并且ZooKeeper服务器确定所需的目录不存在时，它将生成错误并拒绝启动。
提供了一个新脚本zkServer-initialize.sh来支持此新功能。如果禁用autocreate，则用户必须首先安装ZooKeeper，然后创建数据目录（可能还有txnlog目录），然后启动服务器。否则如前一段所述，服务器将无法启动。运行zkServer-initialize.sh将创建所需的目录，并可选择设置myid文件（可选的命令行参数）。即使未使用自动创建功能本身，也可以使用此脚本，并且可能对用户有用，因为此过程（设置，包括创建myid文件）一直是用户的问题。请注意，此脚本仅确保数据目录存在，它不会创建配置文件，而是需要配置文件才能执行。
启用db存在验证
3.6.0中的新增功能：未找到数据树时，启动时ZooKeeper服务器的默认行为是将zxid设置为零，并将仲裁作为投票成员加入。如果某个事件（例如流氓'rm -rf'）在服务器关闭时删除了数据目录，这可能会很危险，因为此服务器可能有助于选择缺少事务的领导者。启用数据库存在验证将在未找到数据树时更改启动时的行为：服务器将集合作为非投票参与者加入，直到它能够与领导者同步并获取集合数据的最新版本。要指示空数据树是预期的（集合创建），用户应将文件'initialize'放在与'myid'相同的目录中。启动时服务器将检测并删除此文件。
通过 在java命令行上设置zookeeper.db.autocreate = false，即-Dzookeeper.db.autocreate = false， 可以直接从类文件运行ZooKeeper服务器时启用初始化验证 。运行zkServer-initialize.sh 将创建所需的初始化文件。
性能调整选项
3.5.0中的新功能：重新设计了几个子系统以提高读取吞吐量。这包括NIO通信子系统和请求处理管道（提交处理器）的多线程。NIO是默认的客户端/服务器通信子系统。它的线程模型包括1个接受线程，1-N选择器线程和0-M套接字I / O工作线程。在请求处理流水线中，系统可以配置为一次处理多个读取请求，同时保持相同的一致性保证（同一会话后读写）。提交处理器线程模型包括1个主线程和0-N工作线程。
默认值旨在最大化专用ZooKeeper机器上的读取吞吐量。两个子系统都需要有足够的线程来实现峰值读取吞吐量。
-
zookeeper.nio.numSelectorThreads :(仅限Java系统属性：zookeeper.nio.numSelectorThreads） 3.5.0中的新增内容： NIO选择器线程数。至少需要1个选择器线程。建议为大量客户端连接使用多个选择器。默认值为sqrt（cpu核心数/ 2）。
-
zookeeper.nio.numWorkerThreads :(仅限Java系统属性：zookeeper.nio.numWorkerThreads） 3.5.0中新增： NIO工作线程数。如果配置了0个工作线程，则选择器线程直接执行套接字I / O. 默认值是cpu核心数的2倍。
-
zookeeper.commitProcessor.numWorkerThreads :(仅限Java系统属性：zookeeper.commitProcessor.numWorkerThreads） 3.5.0中新增： 提交处理器工作线程数。如果配置了0个工作线程，主线程将直接处理请求。默认值是cpu核心数。
-
znode.container.checkIntervalMs :(仅限Java系统属性） 3.6.0中的新增内容：候选容器和ttl节点的每次检查的时间间隔（以毫秒为单位）。默认值为“60000”。
-
znode.container.maxPerMinute :(仅限Java系统属性） 3.6.0中的新增内容：每分钟可删除的最大容器和ttl节点数。这可以防止在容器删除期间放牧。默认值为“10000”。
使用Netty框架进行通信
Netty 是一个基于NIO的客户端/服务器通信框架，它简化了（通过NIO直接使用）许多Java应用程序的网络级通信的复杂性。此外，Netty框架内置了对加密（SSL）和身份验证（证书）的支持。这些是可选功能，可以单独打开或关闭。
在3.5+版本中，ZooKeeper服务器可以通过将环境变量zookeeper.serverCnxnFactory设置 为org.apache.zookeeper.server.NettyServerCnxnFactory来使用Netty而不是NIO（默认选项）; 对于客户端，将zookeeper.clientCnxnSocket设置 为org.apache.zookeeper.ClientCnxnSocketNetty。
TBD - netty的调整选项 - 目前没有netty特定的，但我们应该添加一些。Esp围绕netty创建的读者工作线程数量的最大界限。
TBD - 如何管理加密
TBD - 如何管理证书
AdminServer配置
3.5.0中的新增功能：以下选项用于配置AdminServer。
-
admin.enableServer :( Java系统属性：zookeeper.admin.enableServer）设置为“false”以禁用AdminServer。默认情况下，AdminServer已启用。
-
admin.serverAddress :( Java系统属性：zookeeper.admin.serverAddress）嵌入式Jetty服务器侦听的地址。默认为0.0.0.0。
-
admin.serverPort :( Java系统属性：zookeeper.admin.serverPort）嵌入式Jetty服务器侦听的端口。默认为8080。
-
admin.idleTimeout :( Java系统属性：zookeeper.admin.idleTimeout）设置连接在发送或接收数据之前可以等待的最长空闲时间（以毫秒为单位）。默认为30000毫秒。
-
admin.commandURL :( Java系统属性：zookeeper.admin.commandURL）用于列出和发出与根URL相关的命令的URL。默认为“/ commands”。
ZooKeeper命令
四字母词
ZooKeeper响应一小组命令。每个命令由四个字母组成。您可以通过telnet或nc在客户端端口向ZooKeeper发出命令。
三个更有趣的命令：“stat”给出了关于服务器和连接客户端的一些一般信息，而“srvr”和“cons”分别给出了服务器和连接的扩展细节。
3.5.3中的新功能： 使用前需要明确列出四个字母单词。有关详细信息，请参阅群集配置部分中 描述的4lw.commands.whitelist。继续前进，不推荐使用Four Letter Words，请改用 AdminServer。
-
conf： 3.3.0中的新功能：打印有关服务配置的详细信息。
-
缺点： 3.3.0中的新功能：列出连接到此服务器的所有客户端的完整连接/会话详细信息。包括有关接收/发送的数据包数量，会话ID，操作延迟，上次执行的操作等信息...
-
crst： 3.3.0中的新功能：重置所有连接的连接/会话统计信息。
-
dump：列出未完成的会话和临时节点。这只适用于领导者。
-
envi：打印有关服务环境的详细信息
-
ruok：测试服务器是否在非错误状态下运行。如果正在运行，服务器将使用imok响应。否则它根本不会响应。“imok”的响应不一定表示服务器已加入仲裁，只是服务器进程处于活动状态并绑定到指定的客户端端口。有关状态wrt仲裁和客户端连接信息的详细信息，请使用“stat”。
-
srst：重置服务器统计信息。
-
srvr： 3.3.0中的新功能：列出服务器的完整详细信息。
-
stat：列出服务器和连接客户端的简要详细信息。
-
wchs： 3.3.0中的新功能：列出服务器手表的简要信息。
-
wchc： 3.3.0中的新功能：按会话列出服务器监视的详细信息。这将输出与相关监视（路径）的会话（连接）列表。请注意，根据手表的数量，此操作可能很昂贵（即影响服务器性能），请谨慎使用。
-
dirs： 3.5.1中的新增功能： 显示快照和日志文件的总大小（以字节为单位）
-
wchp： 3.3.0中的新功能：按路径列出服务器监视的详细信息。这将输出一个包含相关会话的路径列表（znodes）。请注意，根据手表的数量，此操作可能很昂贵（即影响服务器性能），请谨慎使用。
-
mntr： 3.4.0中的新增内容：输出可用于监视群集运行状况的变量列表。
$ echo mntr | 数控本地主机2185 zk_version 3.4.0 zk_avg_latency 0.7561 - 是考虑到小数点后四位zk_max_latency 0 zk_min_latency 0 zk_packets_received 70个zk_packets_sent 69个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平台上可用
输出与java属性格式兼容，内容可能随时间而变化（添加了新的键）。您的脚本应该预期更改。注意：某些键是特定于平台的，而某些键仅由Leader导出。输出包含多行，格式如下：
key \t value
-
isro： 3.4.0中的新增功能：测试服务器是否以只读模式运行。如果处于只读模式，服务器将以“ro”响应，如果不处于只读模式，则响应“rw”。
-
gtmk：以十进制格式获取当前跟踪掩码为64位有符号长整型值。有关
stmk可能值的说明，请参阅。 -
stmk：设置当前的跟踪掩码。跟踪掩码是64位，其中每个位启用或禁用服务器上特定类别的跟踪日志记录。必须将Log4J配置为
TRACE首先启用 级别才能查看跟踪日志记录消息。跟踪掩码的位对应于以下跟踪日志记录类别。跟踪掩码位值 0b0000000000 未使用，留作将来使用。 0b0000000010 记录客户端请求，不包括ping请求。 0b0000000100 未使用，留作将来使用。 0b0000001000 记录客户端ping请求。 0b0000010000 记录从作为当前领导者的仲裁对等方接收的数据包，不包括ping请求。 0b0000100000 记录客户端会话的添加，删除和验证。 0b0001000000 将监视事件的传递记录到客户端会话。 0b0010000000 记录从作为当前领导者的仲裁对等方接收的数据包。 0b0100000000 未使用，留作将来使用。 0b1000000000 未使用，留作将来使用。 64位值中的所有剩余位未使用，并保留供将来使用。通过计算记录值的按位OR来指定多个跟踪日志记录类别。默认跟踪掩码为0b0100110010。因此，默认情况下，跟踪日志记录包括客户端请求，从领导者和会话接收的数据包。要设置不同的跟踪掩码，请发送包含
stmk四个字母单词的请求， 后跟跟踪掩码，表示为64位有符号长整型值。此示例使用Perlpack函数构造跟踪掩码，该掩码启用上述所有跟踪日志记录类别，并将其转换为具有big-endian字节顺序的64位带符号long值。结果将附加到stmknetcat并使用netcat发送到服务器。服务器以十进制格式响应新的跟踪掩码。$ perl -e“print'stmk'，pack（'q>'，0b0011111010）”| nc localhost 2181 250
这是ruok 命令的一个例子：
$ echo ruok | nc 127.0.0.1 5111
imok
AdminServer
3.5.0中的新增功能： AdminServer是一个嵌入式Jetty服务器，它为四个字母的单词命令提供HTTP接口。默认情况下，服务器在端口8080上启动，并通过转到URL“/ commands / [command name]”发出命令，例如http：// localhost：8080 / commands / stat。命令响应以JSON形式返回。与原始协议不同，命令不限于四个字母的名称，命令可以有多个名称; 例如，“stmk”也可以称为“set_trace_mask”。要查看所有可用命令的列表，请将浏览器指向URL /命令（例如，http：// localhost：8080 / commands）。有关 如何更改端口和URL的信息，请参阅AdminServer配置选项。
AdminServer默认启用，但可以通过以下任一方式禁用：
- 将zookeeper.admin.enableServer系统属性设置为false。
- 从类路径中删除Jetty。（如果要覆盖ZooKeeper的jetty依赖项，此选项很有用。）
请注意，如果禁用AdminServer，则TCP四字母字界面仍可用。
数据文件管理
ZooKeeper将其数据存储在数据目录中，将其事务日志存储在事务日志目录中。默认情况下，这两个目录是相同的。服务器可以（并且应该）配置为将事务日志文件存储在与数据文件不同的目录中。当事务日志驻留在专用日志设备上时，吞吐量增加和延迟减少。
数据目录
该目录中有两个或三个文件：
- myid - 包含人类可读ASCII文本中的单个整数，表示服务器ID。
- initialize - presence表示预计缺少数据树。创建数据树后清理。
- 快照。 - 保存数据树的模糊快照。
每个ZooKeeper服务器都有一个唯一的id。此id用于两个位置：myid文件和配置文件。该身份识别码的文件标识对应于给定数据目录的服务器。配置文件列出了由其服务器标识标识的每个服务器的联系信息。当ZooKeeper服务器实例启动时，它从myid文件读取其id ，然后使用该id从配置文件中读取，查找它应该监听的端口。
存储在数据目录中的快照文件是模糊快照，因为在ZooKeeper服务器拍摄快照期间，数据树正在进行更新。快照文件名的后缀是zxid，ZooKeeper事务id，是快照开始时的最后一个提交事务。因此，快照包括在快照处理期间发生的数据树更新的子集。然后，快照可能与实际存在的任何数据树不对应，因此我们将其称为模糊快照。尽管如此，ZooKeeper仍然可以使用此快照进行恢复，因为它利用了其更新的幂等特性。通过针对模糊快照重放事务日志，ZooKeeper在日志结束时获取系统的状态。
日志目录
日志目录包含ZooKeeper事务日志。在进行任何更新之前，ZooKeeper确保将表示更新的事务写入非易失性存储。当写入当前日志文件的事务数达到（可变）阈值时，将启动新的日志文件。使用影响快照频率的相同参数计算阈值（请参阅上面的snapCount）。日志文件的后缀是写入该日志的第一个zxid。
文件管理
快照和日志文件的格式在独立ZooKeeper服务器和复制的ZooKeeper服务器的不同配置之间不会更改。因此，您可以将这些文件从正在运行的复制ZooKeeper服务器提取到具有独立ZooKeeper服务器的开发计算机，以便进行故障排除。
使用较旧的日志和快照文件，您可以查看ZooKeeper服务器的先前状态，甚至还原该状态。LogFormatter类允许管理员查看日志中的事务。
ZooKeeper服务器创建快照和日志文件，但从不删除它们。数据和日志文件的保留策略在ZooKeeper服务器之外实现。服务器本身只需要最新的完整模糊快照，其后面的所有日志文件以及它之前的最后一个日志文件。后一个要求必须包括在此快照启动后发生但当时进入现有日志文件的更新。这是可能的，因为在ZooKeeper中，日志的快照和滚动有些独立。有关设置保留策略和维护ZooKeeper存储的详细信息，请参阅本文档中的 维护部分。
＃＃＃＃＃＃注意
存储在这些文件中的数据未加密。在ZooKeeper中存储敏感数据的情况下，需要采取必要的措施来防止未经授权的访问。这些措施在ZooKeeper外部（例如，控制对文件的访问），并取决于部署它的各个设置。
#### Recovery - 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日志文件。它重新计算CRC值并复制计算值，如果它与原始txn条目不匹配。默认情况下，该工具以交互方式工作：它会在遇到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值。 Abort将中止整个操作并退出。（在这种情况下，“。fixed”将不会被删除并保持半完成状态：仅包含已处理的条目，或仅包含在第一个条目中中止操作时的标题。）
$ 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可以避免的一些常见问题：
-
不一致的服务器列表：客户端使用的ZooKeeper服务器列表必须与每个ZooKeeper服务器所拥有的ZooKeeper服务器列表相匹配。如果客户端列表是真实列表的子集，那么事情就可以了，但如果客户端有一个位于不同ZooKeeper集群中的ZooKeeper服务器列表，事情就会变得很奇怪。此外，每个Zookeeper服务器配置文件中的服务器列表应该彼此一致。
-
事务日志的错误放置：ZooKeeper中性能最关键的部分是事务日志。ZooKeeper在返回响应之前将事务同步到媒体。专用的事务日志设备是始终如一的良好性能的关键。将日志置于繁忙的设备上会对性能产生负面影响。如果您只有一个存储设备，请将跟踪文件放在NFS上并增加snapshotCount; 它并没有消除这个问题，但它应该减轻它。
-
不正确的Java堆大小：您应该特别注意正确设置Java最大堆大小。特别是，您不应该创建ZooKeeper交换到磁盘的情况。该磁盘是ZooKeeper的死亡。一切都是有序的，所以如果处理一个请求交换磁盘，所有其他排队的请求可能会做同样的事情。磁盘。不要交换。保守估计：如果你有4G的RAM，不要将Java最大堆大小设置为6G甚至4G。例如，您更有可能将3G堆用于4G计算机，因为操作系统和缓存也需要内存。估计系统所需堆大小的最佳且唯一建议的做法是运行负载测试，然后确保远低于导致系统交换的使用限制。
-
可公开访问的部署：ZooKeeper集合有望在可信计算环境中运行。因此，建议在防火墙后部署ZooKeeper。
最佳实践
为获得最佳结果，请注意以下良好的Zookeeper实践列表：
对于多租户安装看到部分 细节的ZooKeeper“chroot环境”的支持，部署很多应用程序/服务的接口，以单一的ZooKeeper集群时，这是非常有用的。
转载来源：https://github.com/apache/zookeeper/blob/master/zookeeper-docs/src/main/resources/markdown/zookeeperAdmin.md