ZooKeeper 管理者ガイド

導入と管理ガイド

• 導入
  • システム要件
    • サポート対象プラットフォーム
    • 必要なソフトウェア
  • クラスタ化（マルチサーバー）設定
  • シングルサーバーと開発者向け設定
• 管理
  • ZooKeeper 配置の設計
    • 複数マシン間の要件
    • 単一マシン要件
  • プロビジョニング
  • 考慮事項：ZooKeeperの長所と短所
  • 管理
  • メンテナンス
    • データディレクトリの継続的なクリーンアップ
    • デバッグログのクリーンアップ（logback）
  • スーパービジョン
  • モニタリング
  • ロギング
  • トラブルシューティング
  • 設定パラメータ
    • 最小構成
    • 高度な構成
    • クラスタオプション
    • 暗号化、認証、認可オプション
    • 実験的オプション/機能
    • 安全でないオプション
    • データディレクトリの自動作成の無効化
    • db存在検証の有効化
    • パフォーマンスチューニングオプション
    • AdminServer 設定
  • Netty フレームワークを使用した通信
    • クォーラム TLS
    • 既存の非TLSクラスタのダウンタイムなしでのアップグレード
  • ZooKeeperコマンド
    • 4文字の単語
    • AdminServer
  • データファイル管理
    • データディレクトリ
    • ログディレクトリ
    • ファイル管理
    • リカバリ - TxnLogToolkit
  • 避けるべきこと
  • ベストプラクティス

導入

このセクションには、Zookeeper の導入に関する情報が含まれており、次のトピックについて説明しています。

• システム要件
• クラスタ化（マルチサーバー）設定
• シングルサーバーと開発者向け設定

最初の2つのセクションでは、データセンターなどの本番環境に ZooKeeper をインストールすることに関心があると仮定しています。最後のセクションでは、評価、テスト、開発など、限定的な目的で ZooKeeper を設定する場合（本番環境ではありません）について説明します。

システム要件

サポート対象プラットフォーム

ZooKeeper は複数のコンポーネントで構成されています。一部のコンポーネントは広くサポートされていますが、他のコンポーネントはより少ないプラットフォームでのみサポートされています。

• クライアントは、アプリケーションが ZooKeeper アンサンブルに接続するために使用する Java クライアントライブラリです。
• サーバーは、ZooKeeper アンサンブルノードで実行される Java サーバーです。
• ネイティブクライアントは、Java クライアントと同様に、アプリケーションが ZooKeeper アンサンブルに接続するために使用される C で実装されたクライアントです。
• Contrib は、複数のオプションのアドオンコンポーネントを指します。

次のマトリックスは、さまざまなオペレーティングシステムプラットフォームで各コンポーネントを実行するためのコミットされたサポートレベルを示しています。

サポートマトリックス

オペレーティングシステム	クライアント	サーバー	ネイティブクライアント	Contrib
GNU/Linux	開発と本番	開発と本番	開発と本番	開発と本番
Solaris	開発と本番	開発と本番	サポートされていません	サポートされていません
FreeBSD	開発と本番	開発と本番	サポートされていません	サポートされていません
Windows	開発と本番	開発と本番	サポートされていません	サポートされていません
Mac OS X	開発のみ	開発のみ	サポートされていません	サポートされていません

マトリックスで明示的にサポート対象として言及されていないオペレーティングシステムについては、コンポーネントが動作する場合と動作しない場合があります。ZooKeeper コミュニティは、他のプラットフォームで報告された明らかなバグを修正しますが、完全なサポートはありません。

必要なソフトウェア

ZooKeeper は Java バージョン 1.8 以上（JDK 8 LTS、JDK 11 LTS、JDK 12 - Java 9 と 10 はサポートされていません）で実行されます。ZooKeeper サーバーの *アンサンブル* として実行されます。アンサンブルの推奨最小サイズは 3 つの ZooKeeper サーバーであり、別々のマシンで実行することをお勧めします。Yahoo! では、ZooKeeper は通常、デュアルコアプロセッサ、2GB の RAM、80GB の IDE ハードドライブを搭載した専用の RHEL ボックスに配置されています。

クラスタ化（マルチサーバー）設定

信頼性の高い ZooKeeper サービスを実現するには、*アンサンブル* と呼ばれるクラスタに ZooKeeper を配置する必要があります。アンサンブルの大部分が稼働している限り、サービスは利用可能です。Zookeeper は過半数が必要なため、奇数のマシンを使用するのが最適です。たとえば、4 台のマシンでは、ZooKeeper は単一のマシンの障害しか処理できません。2 台のマシンに障害が発生した場合、残りの 2 台のマシンは過半数を構成しません。しかし、5 台のマシンでは、ZooKeeper は 2 台のマシンの障害を処理できます。

注記

ZooKeeper はじめにガイドで説明されているように、フォールトトレラントなクラスタ設定には最低 3 つのサーバーが必要であり、奇数のサーバーを使用することを強くお勧めします。

通常、3 つのサーバーは本番インストールには十分すぎるほどですが、メンテナンス中の最大限の信頼性のために、5 つのサーバーをインストールすることをお勧めします。3 つのサーバーの場合、1 つのサーバーでメンテナンスを実行すると、そのメンテナンス中に他の 2 つのサーバーのいずれかに障害が発生する可能性があります。5 つ実行している場合、1 つをメンテナンスのために停止しても、他の 4 つのいずれかに突然障害が発生しても問題ありません。

冗長性の考慮事項には、環境のすべての側面を含める必要があります。3 つの ZooKeeper サーバーがあるが、それらのネットワークケーブルがすべて同じネットワークスイッチに接続されている場合、そのスイッチの障害によってアンサンブル全体が停止します。

以下は、アンサンブルの一部となるサーバーを設定する手順です。これらの手順は、アンサンブル内のすべてのホストで実行する必要があります。

1. Java JDK をインストールします。システムのネイティブパッケージシステムを使用するか、JDK をここからダウンロードできます。http://java.sun.com/javase/downloads/index.jsp

2. Java ヒープサイズを設定します。これは、スワップを回避するために非常に重要であり、スワップは ZooKeeper のパフォーマンスを大幅に低下させます。正しい値を決定するには、ロードテストを使用し、スワップが発生する使用量制限を十分に下回っていることを確認してください。保守的に行い、4GB のマシンでは最大ヒープサイズを 3GB にします。

3. ZooKeeper サーバーパッケージをインストールします。ここからダウンロードできます。https://zookeeper.dokyumento.jp/releases.html

4. 設定ファイルを作成します。このファイルには任意の名前を付けることができます。次の設定を起点として使用します。

   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は簡単で、各サーバーに対して、まずクォーラムポートを指定し、次にZooKeeperリーダー選出専用のポートを指定する必要があります）。ZooKeeper 3.6.0 以降では、各 ZooKeeper サーバーインスタンスに複数のアドレスを指定することもできます（これにより、クラスタ内で複数の物理ネットワークインターフェースを並行して使用できる場合、可用性を高めることができます）。サーバーIDは、設定ファイルパラメータdataDirで指定された各サーバーのデータディレクトリにある、myidという名前のファイルを作成することで、各マシンに割り当てます。

5. myidファイルは、そのマシンのIDのテキストのみを含む単一行で構成されます。そのため、サーバー1のmyidには「1」というテキストのみが含まれ、他のものは含まれません。IDはアンサンブル内で一意である必要があり、1から255の間の値にする必要があります。**重要：**TTLノードなどの拡張機能を有効にする場合（下記参照）、内部的な制限のため、IDは1から254の間である必要があります。

6. myidと同じディレクトリに初期化マーカーファイルinitializeを作成します。このファイルは、空のデータディレクトリが期待されていることを示します。存在する場合、空のデータベースが作成され、マーカーファイルは削除されます。存在しない場合、空のデータディレクトリは、このピアが投票権を持たず、アクティブなリーダーと通信するまでデータディレクトリにデータを入力しないことを意味します。これは、新しいアンサンブルを起動する場合にのみこのファイルを作成することを目的としています。

7. 設定ファイルが設定されている場合、ZooKeeperサーバーを起動できます。

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

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 プログラマーガイドのバインディングセクションを参照してください。

管理

このセクションには、ZooKeeper の実行とメンテナンスに関する情報が含まれており、次のトピックについて説明しています。

• ZooKeeper 配置の設計
• プロビジョニング
• 考慮事項：ZooKeeperの長所と短所
• 管理
• メンテナンス
• スーパービジョン
• モニタリング
• ロギング
• トラブルシューティング
• 設定パラメータ
• ZooKeeperコマンド
• データファイル管理
• 避けるべきこと
• ベストプラクティス

ZooKeeper 配置の設計

ZooKeeper の信頼性は、2 つの基本的な仮定に基づいています。

1. 配置内のサーバーの少数派だけが失敗します。このコンテキストでの *障害* とは、マシンのクラッシュ、またはサーバーを大部分から分離するネットワークのエラーを意味します。
2. 配置されたマシンは正常に動作します。正常に動作するとは、コードを正しく実行し、正常に動作する時計を持ち、一貫して動作するストレージとネットワークコンポーネントを持つことを意味します。

以下のセクションには、これらの仮定が確実に成り立つ確率を最大化するための ZooKeeper 管理者向けの考慮事項が含まれています。これらのいくつかは複数マシン間の考慮事項であり、他のものは、配置内のすべてのマシンについて考慮する必要があるものです。

複数マシン間の要件

ZooKeeper サービスをアクティブにするには、互いに通信できる非故障マシンの過半数が必要です。N 台のサーバーを持つ ZooKeeper アンサンブルの場合、N が奇数の場合は、アンサンブルは znode データを失うことなく最大 N/2 台のサーバー障害に耐えることができます。N が偶数の場合は、アンサンブルは最大 N/2-1 台のサーバー障害に耐えることができます。

例えば、3台のサーバーからなるZooKeeperアンサンブルの場合、最大1台（3/2）のサーバー障害に耐えることができます。5台のサーバーからなるZooKeeperアンサンブルの場合、最大2台（5/2）のサーバー障害に耐えることができます。6台のサーバーからなるZooKeeperアンサンブルの場合も、データ損失を防ぎ、「ブレイン・スプリット」の問題を回避しながら、最大2台（6/2-1）のサーバー障害に耐えることができます。

ZooKeeperアンサンブルは通常、奇数のサーバーで構成されます。これは、偶数のサーバーでは、障害耐性の容量がサーバー数が1つ少ないアンサンブル（5ノードアンサンブルと6ノードアンサンブルの両方で2回の障害）と同じになるのに対し、アンサンブルは1台のサーバー分の追加の接続とデータ転送を維持する必要があるためです。

障害耐性の確率を最大限に高めるには、マシンの障害を独立させるようにする必要があります。例えば、ほとんどのマシンが同じスイッチを共有している場合、そのスイッチの障害により相関のある障害が発生し、サービスが停止する可能性があります。これは、共有電源回路、冷却システムなどにも当てはまります。

単一マシン要件

ZooKeeperがストレージメディア、CPU、ネットワーク、メモリなどのリソースへのアクセスに関して他のアプリケーションと競合する場合、そのパフォーマンスは著しく低下します。ZooKeeperは強力な耐久性保証を持っており、変更を担当する操作が完了する前に、変更内容をストレージメディアにログとして記録します。この依存関係を認識し、ZooKeeper操作がメディアによって遅延されないようにするために十分な注意を払う必要があります。この種の性能低下を最小限に抑えるためにできることをいくつか紹介します。

• ZooKeeperのトランザクションログは、専用のデバイス上に配置する必要があります。（専用のパーティションでは不十分です。）ZooKeeperは、シークなしでログを順番に書き込みます。他のプロセスとログデバイスを共有すると、シークと競合が発生し、数秒間の遅延が発生する可能性があります。
• ZooKeeperをスワップが発生する可能性のある状況に置いてはいけません。ZooKeeperをある程度のタイムリーに機能させるためには、スワップを許可することはできません。したがって、ZooKeeperに与えられる最大ヒープサイズが、ZooKeeperが使用できる実メモリの量よりも大きくならないようにしてください。詳細については、下記の避けるべきことを参照してください。

プロビジョニング

考慮事項：ZooKeeperの長所と短所

管理

メンテナンス

ZooKeeperクラスタには、長期的なメンテナンスはほとんど必要ありませんが、以下の点に注意する必要があります。

データディレクトリの継続的なクリーンアップ

ZooKeeperのデータディレクトリには、特定のサービングアンサンブルによって保存されたznodeの永続的なコピーであるファイルが含まれています。これらは、スナップショットファイルとトランザクションログファイルです。znodeに変更が加えられると、これらの変更はトランザクションログに追加されます。ログが大きくなると、znodeの現在の状態のスナップショットがファイルシステムに書き込まれ、将来のトランザクションのために新しいトランザクションログファイルが作成されます。スナップショット作成中は、ZooKeeperは古いログファイルに受信したトランザクションを追加し続ける場合があります。したがって、スナップショットよりも新しいトランザクションの一部は、スナップショットの前にある最後のトランザクションログに見つかる場合があります。

ZooKeeperサーバーは、デフォルト設定（下記の自動パージを参照）を使用している場合、古いスナップショットとログファイルを削除しません。これはオペレーターの責任です。サービング環境はそれぞれ異なるため、これらのファイルを管理するための要件はインストールごとに異なる場合があります（バックアップなど）。

PurgeTxnLogユーティリティは、管理者が使用できる単純な保持ポリシーを実装しています。 APIドキュメントには、呼び出し規約（引数など）の詳細が記載されています。

次の例では、最後のcount個のスナップショットとその対応するログが保持され、それ以外は削除されます。の値は、通常3より大きくする必要があります（必須ではありませんが、これは、最近のログが破損した場合に備えて3つのバックアップを提供します）。これは、ZooKeeperサーバーマシンでcronジョブとして実行して、ログを毎日クリーンアップできます。

java -cp zookeeper.jar:lib/slf4j-api-1.7.30.jar:lib/logback-classic-1.2.10.jar:lib/logback-core-1.2.10.jar:conf org.apache.zookeeper.server.PurgeTxnLog <dataDir> <snapDir> -n <count>

スナップショットと対応するトランザクションログの自動パージは、バージョン3.4.0で導入され、構成パラメータautopurge.snapRetainCountとautopurge.purgeIntervalを使用して有効にできます。詳細については、下記の高度な設定を参照してください。

デバッグログのクリーンアップ（logback）

このドキュメントのログに関するセクションを参照してください。組み込みのlogback機能を使用してローリングファイルアペンダーを設定することが期待されています。リリース版tarのconf/logback.xmlにあるサンプル設定ファイルに、その例を示します。

スーパービジョン

各ZooKeeperサーバープロセス（JVM）を管理するスーパーバイザプロセスを用意する必要があります。ZKサーバーは「フェールファースト」になるように設計されており、回復できないエラーが発生した場合にシャットダウン（プロセス終了）します。ZooKeeperサービングクラスタは非常に信頼性が高いため、サーバーがダウンしても、クラスタ全体はアクティブな状態を維持し、要求を処理します。さらに、クラスタは「自己修復」されるため、障害が発生したサーバーは、再起動すると、手動で操作することなく、自動的にアンサンブルに再参加します。

daemontoolsまたはSMFなどのスーパーバイザプロセスを使用すると（他のスーパーバイザプロセスのオプションも使用できます。どれを使用するかはユーザー次第です。これらは単なる2つの例です）、プロセスが異常終了した場合でも、自動的に再起動され、すぐにクラスタに再参加します。

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サービスは、主に3つの方法で監視できます。

• 4文字の単語を使用してコマンドポート経由で
• JMXを使用して
• zkServer.sh statusコマンドを使用して

ロギング

ZooKeeperは、ログ記録インフラストラクチャとしてSLF4Jバージョン1.7を使用します。デフォルトでは、ZooKeeperにはログ記録バックエンドとしてLOGBackが付属していますが、他のサポートされているログ記録フレームワークを使用することもできます。

ZooKeeperのデフォルトのlogback.xmlファイルは、confディレクトリにあります。Logbackでは、logback.xmlが作業ディレクトリ（ZooKeeperを実行するディレクトリ）にあるか、クラスパスからアクセスできる必要があります。

SLF4Jの詳細については、マニュアルを参照してください。

Logbackの詳細については、Logbackウェブサイトを参照してください。

トラブルシューティング

• ファイルの破損が原因でサーバーが起動しない：サーバーはデータベースを読み取ることができず、ZooKeeperサーバーのトランザクションログのファイルの破損が原因で起動に失敗することがあります。ZooKeeperデータベースのロード時に、いくつかのIOExceptionが表示されます。このような場合は、アンサンブル内の他のすべてのサーバーが稼働していることを確認してください。「stat」コマンドをコマンドポートで使用して、それらが正常に動作しているかどうかを確認します。アンサンブルの他のすべてのサーバーが稼働していることを確認したら、破損したサーバーのデータベースをクリーンアップできます。datadir/version-2とdatalogdir/version-2/内のすべてのファイルを削除します。サーバーを再起動します。

設定パラメータ

ZooKeeperの動作は、ZooKeeperの設定ファイルによって制御されます。このファイルは、ディスクレイアウトが同じであれば、ZooKeeperサーバーを構成するすべてのサーバーでまったく同じファイルを使用できるように設計されています。サーバーが異なる設定ファイルを使用する場合は、すべての異なる設定ファイル内のサーバーのリストが一致するように注意する必要があります。

注記

3.5.0以降では、これらのパラメータの一部を動的設定ファイルに配置する必要があります。静的設定ファイルに配置されている場合、ZooKeeperはそれらを自動的に動的設定ファイルに移動します。詳細については、動的再構成を参照してください。

最小構成

設定ファイルに定義する必要がある最小限の設定キーワードを以下に示します。

• clientPort：クライアント接続をリッスンするポート。つまり、クライアントが接続しようとするポートです。

• secureClientPort：SSLを使用してセキュアなクライアント接続をリッスンするポート。clientPortはプレーンテキスト接続のポートを指定し、secureClientPortはSSL接続のポートを指定します。両方指定すると混合モードが有効になり、どちらかを省略するとそのモードが無効になります。SSL機能は、ユーザーがzookeeper.serverCnxnFactory、zookeeper.clientCnxnSocketをNettyとしてプラグインした場合に有効になります。

• observerMasterPort：オブザーバー接続をリッスンするポート。つまり、オブザーバーが接続しようとするポートです。プロパティが設定されている場合、サーバーはリーダーモードの場合だけでなく、フォロワーモードの場合にもオブザーバー接続をホストし、オブザーバーモードの場合には任意の投票ピアへの接続を試みます。

• dataDir：ZooKeeperがインメモリデータベースのスナップショットと、特に指定しない限り、データベースへの更新のトランザクションログを保存する場所です。

  注記

  トランザクションログの配置場所には注意してください。専用のトランザクションログデバイスは、一貫した良好なパフォーマンスの鍵となります。ログをビジーなデバイスに配置すると、パフォーマンスに悪影響を与えます。

• tickTime：ZooKeeperで使用される基本的な時間単位である単一ティックの長さ（ミリ秒単位）。ハートビートとタイムアウトを調整するために使用されます。例えば、最小セッションタイムアウトは2ティックになります。

高度な構成

このセクションの設定はオプションです。これらを使用して、ZooKeeperサーバーの動作をさらに微調整できます。一部は、Javaシステムプロパティ（一般的にzookeeper.keywordという形式）を使用して設定することもできます。利用可能な場合は、正確なシステムプロパティを以下に示します。

• dataLogDir：（Javaシステムプロパティなし）このオプションは、マシンがトランザクションログをdataDirではなくdataLogDirに書き込むように指示します。これにより、専用のログデバイスを使用でき、ログとスナップショット間の競合を回避できます。

  注記

  専用のログデバイスを使用すると、スループットと安定したレイテンシに大きな影響を与えます。ログデバイスを専用にすること、およびdataLogDirをそのデバイス上のディレクトリを指すように設定し、dataDirをそのデバイス上にないディレクトリを指すようにすることを強くお勧めします。

• globalOutstandingLimit：（Javaシステムプロパティ：zookeeper.globalOutstandingLimit）クライアントは、ZooKeeperが処理できる速度よりも速く要求を送信できます。特に、クライアントが多い場合です。キューに入れられた要求のためにZooKeeperがメモリ不足にならないようにするため、ZooKeeperはクライアントを調整して、アンサンブル全体でglobalOutstandingLimitを超える未処理の要求がないようにします（均等に分割されます）。デフォルトの制限は1,000で、例えば、3つのメンバーがいる場合、それぞれ1000 / 2 = 500の個々の制限があります。

• preAllocSize：（Javaシステムプロパティ：zookeeper.preAllocSize）シークを回避するために、ZooKeeperはpreAllocSizeキロバイトのブロックでトランザクションログファイルにスペースを割り当てます。デフォルトのブロックサイズは64Mです。ブロックサイズを変更する理由の1つは、スナップショットがより頻繁に取得される場合にブロックサイズを小さくすることです。（また、snapCountとsnapSizeLimitInKbも参照してください）。

• snapCount：（Javaシステムプロパティ：zookeeper.snapCount）ZooKeeperは、スナップショットとトランザクションログ（ライトアヘッドログと考えてください）を使用してトランザクションを記録します。スナップショットが取得され（そしてトランザクションログがロールオーバーされる）、トランザクションログに記録されるトランザクションの数は、snapCountによって決定されます。クォーラム内のすべてのマシンが同時にスナップショットを取得することを防ぐために、各ZooKeeperサーバーは、トランザクションログ内のトランザクション数が[snapCount/2+1, snapCount]範囲のランタイム生成のランダムな値に達したときにスナップショットを取得します。デフォルトのsnapCountは100,000です。

• commitLogCount *：（Javaシステムプロパティ：zookeeper.commitLogCount）Zookeeperは、フォロワーがそれほど遅れていない場合に、フォロワーとの高速な同期のために、最後にコミットされた要求のインメモリリストを保持します。スナップショットが大きい（>100,000）場合、これにより同期のパフォーマンスが向上します。デフォルト値は500であり、推奨される最小値です。

• snapSizeLimitInKb：（Javaシステムプロパティ: **zookeeper.snapSizeLimitInKb**）ZooKeeperは、スナップショットとトランザクションログ（ライトアヘッドログと考える）を使用してトランザクションを記録します。スナップショットを作成する（そしてトランザクションログをロールする）前に、トランザクションログに記録されたトランザクションの合計バイト数は、snapSizeによって決定されます。クォーラム内のすべてのマシンが同時にスナップショットを作成することを防ぐために、各ZooKeeperサーバーは、トランザクションログ内のトランザクションセットのバイトサイズが[snapSize/2+1, snapSize]の範囲内のランタイムで生成されたランダム値に達すると、スナップショットを作成します。各ファイルシステムには最小の標準ファイルサイズがあり、この機能が正しく機能するためには、選択された数値がその値よりも大きくなければなりません。デフォルトのsnapSizeLimitInKbは4,194,304（4GB）です。0以下の値は、この機能を無効にします。

• txnLogSizeLimitInKb：（Javaシステムプロパティ: **zookeeper.txnLogSizeLimitInKb**）ZooKeeperトランザクションログファイルは、txnLogSizeLimitInKbを使用してより直接的に制御することもできます。トランザクションログを使用して同期が行われる場合、より大きなトランザクションログは、フォロワーの同期を遅らせる可能性があります。これは、リーダーがディスク上の適切なログファイル全体をスキャンして、同期を開始するトランザクションを見つける必要があるためです。この機能はデフォルトでオフになっており、snapCountとsnapSizeLimitInKbのみがトランザクションログサイズを制限します。有効にすると、ZooKeeperは、いずれかの制限に達するとログをロールします。実際のログサイズは、シリアル化されたトランザクションのサイズだけ、この値を超える可能性があることに注意してください。一方、この値が**preAllocSize**に非常に近い（またはそれより小さい）場合、ZooKeeperはトランザクションごとにログをロールする可能性があります。これは正確性の問題ではありませんが、パフォーマンスが著しく低下する可能性があります。これを回避し、この機能を最大限に活用するには、値をN * **preAllocSize**（N >= 2）に設定することをお勧めします。

• maxCnxns：（Javaシステムプロパティ: **zookeeper.maxCnxns**）ZooKeeperサーバー（各サーバーのクライアントポートごと）に対して行うことができる同時接続の総数を制限します。これは、特定の種類のDoS攻撃を防ぐために使用されます。デフォルトは0であり、0に設定すると、同時接続の総数に関する制限が完全に削除されます。serverCnxnFactoryとsecureServerCnxnFactoryの接続数のカウントは別々に行われるため、ピアは、適切なタイプであれば最大2*maxCnxnsまでホストできます。

• maxClientCnxns：（Javaシステムプロパティなし）単一のクライアント（IPアドレスで識別）がZooKeeperアンサンブルの単一メンバーに対して行うことができる同時接続数（ソケットレベル）を制限します。これは、ファイル記述子の枯渇を含む特定の種類のDoS攻撃を防ぐために使用されます。デフォルトは60です。これを0に設定すると、同時接続の制限が完全に削除されます。

• clientPortAddress：**3.3.0の新機能:** クライアント接続をリッスンするアドレス（IPv4、IPv6、またはホスト名）。つまり、クライアントが接続を試みるアドレスです。これはオプションです。デフォルトでは、サーバー上の任意のアドレス/インターフェース/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または負の整数に設定すると、機能をオフにします。

• maxGetChildrenResponseCacheSize：（Javaシステムプロパティ: **zookeeper.maxGetChildrenResponseCacheSize**）**3.6.0の新機能:** **maxResponseCacheSize**に似ていますが、子取得リクエストに適用されます。メトリック**response_packet_get_children_cache_hits**と**response_packet_get_children_cache_misses**を使用して、この値を特定のワークロードに合わせて調整できます。この機能は、値400でデフォルトでオンになっています。0または負の整数に設定すると、機能をオフにします。

• autopurge.snapRetainCount：（Javaシステムプロパティなし）**3.4.0の新機能:** 有効にすると、ZooKeeperの自動パージ機能は、最新の**autopurge.snapRetainCount**個のスナップショットと対応するトランザクションログをそれぞれ**dataDir**と**dataLogDir**に保持し、残りを削除します。デフォルトは3です。最小値は3です。

• autopurge.purgeInterval：（Javaシステムプロパティなし）**3.4.0の新機能:** パージタスクをトリガーする必要がある時間間隔（時間単位）。自動パージを有効にするには、正の整数（1以上）に設定します。デフォルトは0です。

• syncEnabled：（Javaシステムプロパティ: **zookeeper.observer.syncEnabled**）**3.4.6、3.5.0の新機能:** オブザーバーは、参加者と同様に、トランザクションのログ記録とディスクへのスナップショットの書き込みをデフォルトで実行するようになりました。これにより、再起動時のオブザーバーの復旧時間が短縮されます。この機能を無効にするには、「false」に設定します。デフォルトは「true」です。

• extendedTypesEnabled：（Javaシステムプロパティのみ: **zookeeper.extendedTypesEnabled**）**3.5.4、3.6.0の新機能:** TTLノードの作成など、拡張機能を有効にするにはtrueに設定します。デフォルトでは無効になっています。重要：有効にした場合、内部的な制限によりサーバーIDは255未満でなければなりません。

• emulate353TTLNodes：（Javaシステムプロパティのみ: **zookeeper.emulate353TTLNodes**）**3.5.4、3.6.0の新機能:** [ZOOKEEPER-2901] (https://issues.apache.org/jira/browse/ZOOKEEPER-2901) により、バージョン3.5.3で作成されたTTLノードは3.5.4/3.6.0ではサポートされていません。ただし、zookeeper.emulate353TTLNodesシステムプロパティを介して回避策が提供されています。ZooKeeper 3.5.3でTTLノードを使用しており、互換性を維持する必要がある場合は、**zookeeper.extendedTypesEnabled**に加えて**zookeeper.emulate353TTLNodes**をtrueに設定します。注：バグのため、サーバーIDは127以下でなければなりません。さらに、最大サポートTTL値は1099511627775であり、3.5.3で許可されていた値（1152921504606846975）よりも小さいです。

• watchManagerName：（Javaシステムプロパティのみ: **zookeeper.watchManagerName**）**3.6.0の新機能:** ZOOKEEPER-1179に追加。新しいウォッチャーマネージャーWatchManagerOptimizedが追加され、ウォッチャー使用量の多いケースにおけるメモリオーバーヘッドが最適化されます。この設定は、使用するウォッチャーマネージャーを定義するために使用されます。現在、WatchManagerとWatchManagerOptimizedのみをサポートしています。

• watcherCleanThreadsNum：（Javaシステムプロパティのみ: **zookeeper.watcherCleanThreadsNum**）**3.6.0の新機能:** ZOOKEEPER-1179に追加。新しいウォッチャーマネージャーWatchManagerOptimizedは、非アクティブなウォッチャーを遅延的にクリーンアップします。この設定は、WatcherCleanerで使用されるスレッド数を決定するために使用されます。スレッドが多いほど、通常はクリーンアップのスループットが大きくなります。デフォルト値は2であり、セッションの頻繁な開閉を行う場合でも十分です。

• watcherCleanThreshold：（Javaシステムプロパティのみ: **zookeeper.watcherCleanThreshold**）**3.6.0の新機能:** ZOOKEEPER-1179に追加。新しいウォッチャーマネージャーWatchManagerOptimizedは、非アクティブなウォッチャーを遅延的にクリーンアップします。クリーンアッププロセスは比較的負荷が高いため、バッチ処理によってコストを削減し、パフォーマンスを向上させることができます。この設定は、バッチサイズを決定するために使用されます。デフォルトは1000であり、メモリまたはクリーンアップ速度の問題がない限り変更する必要はありません。

• watcherCleanIntervalInSeconds：（Javaシステムプロパティのみ: **zookeeper.watcherCleanIntervalInSeconds**）**3.6.0の新機能:** ZOOKEEPER-1179に追加。新しいウォッチャーマネージャーWatchManagerOptimizedは、非アクティブなウォッチャーを遅延的にクリーンアップします。クリーンアッププロセスは比較的負荷が高いため、バッチ処理によってコストを削減し、パフォーマンスを向上させることができます。watcherCleanThresholdに加えて、この設定は、非アクティブなウォッチャーがwatcherCleanThresholdよりも多くなくても、一定時間後に非アクティブなウォッチャーをクリーンアップするために使用されます。これにより、非アクティブなウォッチャーを長期間残しておくことを防ぎます。デフォルト設定は10分であり、通常は変更する必要はありません。

• maxInProcessingDeadWatchers：（Javaシステムプロパティのみ: **zookeeper.maxInProcessingDeadWatchers**）**3.6.0の新機能:** ZOOKEEPER-1179に追加。これは、WatcherCleanerでどれだけ多くのバックログを持つことができるかを制御するために使用されます。この数に達すると、WatcherCleanerへの非アクティブなウォッチャーの追加が遅くなり、結果としてウォッチャーの追加とクローズが遅くなります。これにより、OOMの問題を回避できます。デフォルトでは制限はありません。watcherCleanThreshold * 1000などの値に設定できます。

• bitHashCacheSize：（Javaシステムプロパティのみ: **zookeeper.bitHashCacheSize**）**3.6.0の新機能:** ZOOKEEPER-1179に追加。これは、BitHashSet実装におけるHashSetキャッシュサイズを決定するために使用される設定です。HashSetを使用しないと、要素を取得するのにO(N)の時間が必要になります（NはelementBitsのビット数です）。ただし、メモリをあまり消費しないようにサイズを小さくする必要があるため、メモリと時間計算量のトレードオフがあります。デフォルト値は10であり、比較的妥当なキャッシュサイズです。

• fastleader.minNotificationInterval：（Javaシステムプロパティ: **zookeeper.fastleader.minNotificationInterval**）リーダー選出時の2つの連続する通知チェック間の時間の下限。この間隔は、ピアが選出投票のセットをチェックする待ち時間を決定し、選出が解決される速度に影響します。長い選出の場合、この間隔は設定された最小値（これ）と設定された最大値（fastleader.maxNotificationInterval）からのバックオフ戦略に従います。

• fastleader.maxNotificationInterval：（Javaシステムプロパティ: **zookeeper.fastleader.maxNotificationInterval**）リーダー選出時の2つの連続する通知チェック間の時間の上限。この間隔は、ピアが選出投票のセットをチェックする待ち時間を決定し、選出が解決される速度に影響します。長い選出の場合、この間隔は設定された最小値（fastleader.minNotificationInterval）と設定された最大値（これ）からのバックオフ戦略に従います。

• connectionMaxTokens：（Javaシステムプロパティ：zookeeper.connection_throttle_tokens）3.6.0の新機能：これは、オプションで確率的ドロップを備えたトークンベースのレート制限メカニズムである、サーバー側の接続スロットリングを調整するためのパラメータの1つです。このパラメータは、トークンバケット内の最大トークン数を定義します。0に設定すると、スロットリングは無効になります。デフォルトは0です。

• connectionTokenFillTime：（Javaシステムプロパティ：zookeeper.connection_throttle_fill_time）3.6.0の新機能：これは、オプションで確率的ドロップを備えたトークンベースのレート制限メカニズムである、サーバー側の接続スロットリングを調整するためのパラメータの1つです。このパラメータは、connectionTokenFillCountトークンでトークンバケットが再充填される間隔をミリ秒単位で定義します。デフォルトは1です。

• connectionTokenFillCount：（Javaシステムプロパティ：zookeeper.connection_throttle_fill_count）3.6.0の新機能：これは、オプションで確率的ドロップを備えたトークンベースのレート制限メカニズムである、サーバー側の接続スロットリングを調整するためのパラメータの1つです。このパラメータは、connectionTokenFillTimeミリ秒ごとにトークンバケットに追加するトークン数を定義します。デフォルトは1です。

• connectionFreezeTime：（Javaシステムプロパティ：zookeeper.connection_throttle_freeze_time）3.6.0の新機能：これは、オプションで確率的ドロップを備えたトークンベースのレート制限メカニズムである、サーバー側の接続スロットリングを調整するためのパラメータの1つです。このパラメータは、ドロップ確率が調整される間隔をミリ秒単位で定義します。-1に設定すると、確率的ドロップは無効になります。デフォルトは-1です。

• connectionDropIncrease：（Javaシステムプロパティ：zookeeper.connection_throttle_drop_increase）3.6.0の新機能：これは、オプションで確率的ドロップを備えたトークンベースのレート制限メカニズムである、サーバー側の接続スロットリングを調整するためのパラメータの1つです。このパラメータは、ドロップ確率の増加量を定義します。スロットラーはconnectionFreezeTimeミリ秒ごとにチェックし、トークンバケットが空の場合、ドロップ確率はconnectionDropIncreaseだけ増加します。デフォルトは0.02です。

• connectionDropDecrease：（Javaシステムプロパティ：zookeeper.connection_throttle_drop_decrease）3.6.0の新機能：これは、オプションで確率的ドロップを備えたトークンベースのレート制限メカニズムである、サーバー側の接続スロットリングを調整するためのパラメータの1つです。このパラメータは、ドロップ確率の減少量を定義します。スロットラーはconnectionFreezeTimeミリ秒ごとにチェックし、トークンバケットのトークン数が閾値を超えている場合、ドロップ確率はconnectionDropDecreaseだけ減少します。閾値はconnectionMaxTokens * connectionDecreaseRatioです。デフォルトは0.002です。

• connectionDecreaseRatio：（Javaシステムプロパティ：zookeeper.connection_throttle_decrease_ratio）3.6.0の新機能：これは、オプションで確率的ドロップを備えたトークンベースのレート制限メカニズムである、サーバー側の接続スロットリングを調整するためのパラメータの1つです。このパラメータは、ドロップ確率を減少させるための閾値を定義します。デフォルトは0です。

• zookeeper.connection_throttle_weight_enabled：（Javaシステムプロパティのみ）3.6.0の新機能：スロットリング時に接続の重みを考慮するかどうか。connectionMaxTokensが0より大きい場合、つまり接続スロットルが有効になっている場合にのみ有効です。デフォルトはfalseです。

• zookeeper.connection_throttle_global_session_weight：（Javaシステムプロパティのみ）3.6.0の新機能：グローバルセッションの重み。接続スロットラーを通過するためにグローバルセッションリクエストに必要なトークン数です。ローカルセッションの重み以上の正の整数でなければなりません。デフォルトは3です。

• zookeeper.connection_throttle_local_session_weight：（Javaシステムプロパティのみ）3.6.0の新機能：ローカルセッションの重み。接続スロットラーを通過するためにローカルセッションリクエストに必要なトークン数です。グローバルセッションまたはセッション更新の重み以下の正の整数でなければなりません。デフォルトは1です。

• zookeeper.connection_throttle_renew_session_weight：（Javaシステムプロパティのみ）3.6.0の新機能：セッション更新の重み。スロットラーを通過するために再接続リクエストに必要なトークン数でもあります。ローカルセッションの重み以上の正の整数でなければなりません。デフォルトは2です。

• clientPortListenBacklog：（Javaシステムプロパティなし）3.4.14、3.5.5、3.6.0の新機能：ZooKeeperサーバーソケットのソケットバックログの長さ。これは、ZooKeeperサーバーによって処理されるためにサーバー側でキューイングされるリクエストの数を制御します。この長さを超える接続はネットワークタイムアウト（30秒）を受け取り、ZooKeeperセッションの期限切れ問題が発生する可能性があります。デフォルトでは、この値は設定されていません（-1）。Linuxでは、バックログは50になります。この値は正の数でなければなりません。

• serverCnxnFactory：（Javaシステムプロパティ：zookeeper.serverCnxnFactory）ServerCnxnFactoryの実装を指定します。TLSベースのサーバー通信を使用するには、NettyServerCnxnFactoryに設定する必要があります。デフォルトはNIOServerCnxnFactoryです。

• flushDelay：（Javaシステムプロパティ：zookeeper.flushDelay）コミットログのフラッシュを遅らせる時間（ミリ秒単位）。maxBatchSizeで定義された制限には影響しません。デフォルトでは無効（値0）。書き込みレートの高いアンサンブルでは、10〜20ミリ秒の値でスループットが向上する可能性があります。

• maxWriteQueuePollTime：（Javaシステムプロパティ：zookeeper.maxWriteQueuePollTime）flushDelayが有効になっている場合、これは新しいリクエストがキューイングされていないときにフラッシュするまで待機する時間（ミリ秒単位）を決定します。デフォルトではflushDelay/3に設定されます（暗黙的に無効）。

• maxBatchSize：（Javaシステムプロパティ：zookeeper.maxBatchSize）コミットログのフラッシュがトリガーされる前にサーバーで許可されるトランザクション数。flushDelayで定義された制限には影響しません。デフォルトは1000です。

• enforceQuota：（Javaシステムプロパティ：zookeeper.enforceQuota）3.7.0の新機能：クォータチェックを強制します。有効になっており、クライアントがznodeの下で合計バイト数または子ノード数のハードクォータを超えた場合、サーバーはリクエストを拒否し、クライアントにQuotaExceededExceptionを強制的に返します。デフォルト値はfalseです。詳細については、クォータ機能をご覧ください。

• requestThrottleLimit：（Javaシステムプロパティ：zookeeper.request_throttle_max_requests）3.6.0の新機能：RequestThrottlerがストールを開始する前に許可される未処理リクエストの総数。0に設定すると、スロットリングは無効になります。デフォルトは0です。

• requestThrottleStallTime：（Javaシステムプロパティ：zookeeper.request_throttle_stall_time）3.6.0の新機能：スレッドがリクエストの処理を再開できるようになるまで通知されるのを待機できる最大時間（ミリ秒単位）。デフォルトは100です。

• requestThrottleDropStale：（Javaシステムプロパティ：request_throttle_drop_stale）3.6.0の新機能：有効にすると、スロットラーはリクエストパイプラインに発行するのではなく、古いリクエストをドロップします。古いリクエストとは、現在閉じられている接続によって送信されたリクエスト、またはセッションタイムアウトよりもリクエストレイテンシが高いリクエストです。デフォルトはtrueです。

• requestStaleLatencyCheck：（Javaシステムプロパティ：zookeeper.request_stale_latency_check）3.6.0の新機能：有効にすると、リクエストレイテンシが関連付けられたセッションタイムアウトよりも高い場合、リクエストは古いと見なされます。デフォルトでは無効です。

• requestStaleConnectionCheck：（Javaシステムプロパティ：zookeeper.request_stale_connection_check）3.6.0の新機能：有効にすると、リクエストの接続が閉じられている場合、リクエストは古いと見なされます。デフォルトで有効になっています。

• zookeeper.request_throttler.shutdownTimeout：（Javaシステムプロパティのみ）3.6.0の新機能：RequestThrottlerが強制的にシャットダウンする前に、シャットダウン中にリクエストキューの枯渇を待つ時間（ミリ秒単位）。デフォルトは10000です。

• advancedFlowControlEnabled：（Javaシステムプロパティ：zookeeper.netty.advancedFlowControl.enabled）ZooKeeperパイプラインの状態に基づいてNettyで正確なフロー制御を使用し、直接バッファOOMを回避します。NettyのAUTO_READを無効にします。

• enableEagerACLCheck：（Javaシステムプロパティのみ：zookeeper.enableEagerACLCheck）"true"に設定すると、クォーラムにリクエストを送信する前に、各ローカルサーバーでの書き込みリクエストに対して早期ACLチェックが有効になります。デフォルトは"false"です。

• maxConcurrentSnapSyncs：（Javaシステムプロパティ：zookeeper.leader.maxConcurrentSnapSyncs）リーダーまたはフォロワーが同時に処理できるスナップ同期の数。デフォルトは10です。

• maxConcurrentDiffSyncs：（Javaシステムプロパティ：zookeeper.leader.maxConcurrentDiffSyncs）リーダーまたはフォロワーが同時に処理できる差分同期の最大数。デフォルトは100です。

• digest.enabled：（Javaシステムプロパティのみ：zookeeper.digest.enabled）3.6.0の新機能：ディスクからのデータベースの読み込み、リーダーへの追いつき、リーダーの追従時にZooKeeper内部のデータの不整合を検出するためのダイジェスト機能が追加されました。これは、adHash論文で言及されているDataTreeに対して増分ハッシュチェックを実行しています。

  https://cseweb.ucsd.edu/~daniele/papers/IncHash.pdf
  

  アイデアはシンプルで、DataTreeのハッシュ値はデータセットの変更に基づいて増分的に更新されます。リーダーがトランザクションを準備するとき、発生した変更に基づいてツリーのハッシュを事前に計算します。

  current_hash = current_hash + hash(new node data) - hash(old node data)
  

  新しいノードを作成する場合、hash(古いノードデータ)は0になり、ノードを削除する操作の場合は、hash(新しいノードデータ)は0になります。

  このハッシュは、データツリーにトランザクションを適用した後の期待されるハッシュ値を表すために各トランザクションに関連付けられ、元の提案とともにフォロワーに送信されます。学習者は、データツリーにトランザクションを適用した後、実際のハッシュ値とトランザクション内のハッシュ値を比較し、同じでない場合は不一致を報告します。

  これらのダイジェスト値は、ディスク上の各トランザクションとスナップショットにも保持されるため、サーバーが再起動してディスクからデータを読み込むと、ハッシュの不一致を比較して確認し、ディスク上のデータ損失問題の検出に役立ちます。

  実際のハッシュ関数として、内部的にCRCを使用しています。これは衝突のないハッシュ関数ではありませんが、衝突のないハッシュと比較して効率が高く、衝突の可能性は非常にまれであり、ここのニーズをすでに満たしています。

  この機能は下位互換性と上位互換性があるため、互換性の問題なく、安全にロールアップグレード、ダウングレード、有効化、および後で無効化できます。カバーしてテストされたシナリオを以下に示します。

  1. フォロワーが古いコードで実行されている間にリーダーが新しいコードで実行されている場合、ダイジェストは各トランザクションの最後に追加され、フォロワーはヘッダーとトランザクションデータのみを読み取り、トランザクション内のダイジェスト値は無視されます。フォロワーが次のトランザクションを読み取り、処理することに影響しません。
  2. フォロワーが新しいコードで実行されている間にリーダーが古いコードで実行されている場合、ダイジェストはトランザクションとともに送信されません。フォロワーがダイジェストを読み取ろうとすると、EOFがスローされ、これはキャッチされ、ダイジェスト値がnullに設定されて正常に処理されます。
  3. 新しいコードで古いスナップショットを読み込むと、存在しないダイジェスト値を読み込もうとするとIOExceptionがスローされ、例外がキャッチされ、ダイジェストがnullに設定されます。これは、ロールアップグレード中に発生することが予想されます。
  4. 古いコードで新しいスナップショットを読み込むと、データツリーの逆シリアル化後に正常に終了します。スナップショットファイルの末尾にあるダイジェスト値は無視されます。
  5. フラグの変更によるローリング再起動のシナリオは、上記の1番目と2番目のシナリオに似ています。リーダーが有効になっているがフォロワーが無効になっている場合、ダイジェスト値は無視され、フォロワーは実行時にダイジェストを比較しません。リーダーが無効になっているがフォロワーが有効になっている場合、フォロワーはEOF例外を受け取りますが、これは正常に処理されます。

  注：現在のダイジェスト計算では、/zookeeper/quota statノードの潜在的な不整合のため、/zookeeperの下のノードは除外されています。この問題が修正された後に含めることができます。

  この機能はデフォルトで有効になっています。「false」に設定して無効にすることができます。

• snapshot.compression.method：（Javaシステムプロパティ：zookeeper.snapshot.compression.method）3.6.0の新機能: このプロパティは、ZooKeeperがスナップショットをディスクに保存する前に圧縮するかどうかを制御します（ZOOKEEPER-3179参照）。可能な値は次のとおりです。

  • ""：無効（スナップショット圧縮なし）。これがデフォルトの動作です。
  • "gz"：gzip圧縮を参照してください。
  • "snappy"：Snappy圧縮を参照してください。

• snapshot.trust.empty：（Javaシステムプロパティ：zookeeper.snapshot.trust.empty）3.5.6の新機能: このプロパティは、ZooKeeperが欠落しているスナップショットファイルを回復不能な致命的な状態として扱うかどうかを制御します。ZooKeeperサーバーがスナップショットファイルなしで回復できるようにするには、trueに設定します。これは、ZooKeeperにトランザクションログファイルのみが存在し、スナップショットファイルが存在しない古いバージョンのZooKeeper（3.4.x、3.5.3以前）からのアップグレード時にのみ設定する必要があります。アップグレード時に値を設定する場合は、アップグレード後に値をfalseに戻し、ZooKeeperプロセスを再起動して、ZooKeeperが回復プロセス中に通常のデータ整合性チェックを継続できるようにすることをお勧めします。デフォルト値はfalseです。

• audit.enable：（Javaシステムプロパティ：zookeeper.audit.enable）3.6.0の新機能: デフォルトでは、監査ログは無効になっています。「true」に設定して有効にします。デフォルト値は「false」です。ZooKeeper監査ログの詳細については、こちらを参照してください。

• audit.impl.class：（Javaシステムプロパティ：zookeeper.audit.impl.class）3.6.0の新機能: 監査ロガーを実装するクラス。デフォルトでは、Logbackベースの監査ロガーorg.apache.zookeeper.audit.Slf4jAuditLoggerが使用されます。ZooKeeper監査ログの詳細については、こちらを参照してください。

• largeRequestMaxBytes：（Javaシステムプロパティ：zookeeper.largeRequestMaxBytes）3.6.0の新機能: すべての進行中の大規模リクエストの最大バイト数。着信する大規模リクエストによって制限を超えると、接続が閉じられます。デフォルトは100 * 1024 * 1024です。

• largeRequestThreshold：（Javaシステムプロパティ：zookeeper.largeRequestThreshold）3.6.0の新機能: リクエストが大規模リクエストと見なされるサイズしきい値。-1の場合、すべてのリクエストは小さいと見なされ、大規模リクエストのスロットリングが事実上オフになります。デフォルトは-1です。

• outstandingHandshake.limit（Javaシステムプロパティのみ：zookeeper.netty.server.outstandingHandshake.limit）ZooKeeperで許容される進行中のTLSハンドシェイク接続の最大数。この制限を超える接続は、ハンドシェイクを開始する前に拒否されます。この設定は、最大TLS同時実行数を制限しませんが、進行中のTLSハンドシェイクが多すぎる場合のTLSハンドシェイクタイムアウトによる群集効果を回避するのに役立ちます。群集効果を回避するには、250などにするのが適切です。

• netty.server.earlyDropSecureConnectionHandshakes（Javaシステムプロパティ：zookeeper.netty.server.earlyDropSecureConnectionHandshakes）ZooKeeperサーバーが完全に起動していない場合、TLSハンドシェイクを実行する前にTCP接続を切断します。これは、再起動後に多くの同時TLSハンドシェイクでサーバーがフラッディングされるのを防ぐのに役立ちます。このフラグを有効にすると、サーバーが完全に起動していない場合、「ruok」コマンドに応答しなくなることに注意してください。

  接続を切断する動作はZooKeeper 3.7で導入され、無効にすることはできませんでした。3.7.1および3.8.0以降、この機能はデフォルトで無効になっています。

• throttledOpWaitTime（Javaシステムプロパティ：zookeeper.throttled_op_wait_time）RequestThrottlerキューで、リクエストがスロットルされるとマークされる時間。スロットルされたリクエストは、属するサーバーのパイプラインに送られる以外は処理されず、すべてのリクエストの順序を維持します。FinalProcessorは、これらの未消化のリクエストに対してエラー応答（新しいエラーコード：ZTHROTTLEDOP）を発行します。クライアントがそれらをすぐに再試行しないようにすることを意図しています。0に設定すると、リクエストはスロットルされません。デフォルトは0です。

• learner.closeSocketAsync（Javaシステムプロパティ：zookeeper.learner.closeSocketAsync）（Javaシステムプロパティ：learner.closeSocketAsync）（下位互換性のために追加）3.7.0の新機能: 有効にすると、ラーナーはクォーラムソケットを非同期的に閉じます。これは、ソケットのクローズに時間がかかり、シャットダウンプロセスがブロックされ、新しいリーダーの選出が遅延し、クォーラムが使用できなくなる可能性のあるTLS接続に役立ちます。ソケットを非同期的に閉じることで、長いソケットクローズ時間にもかかわらずシャットダウンプロセスがブロックされるのを回避し、ソケットのクローズ中に新しいリーダーの選出を開始できます。デフォルトはfalseです。

• leader.closeSocketAsync（Javaシステムプロパティ：zookeeper.leader.closeSocketAsync）（Javaシステムプロパティ：leader.closeSocketAsync）（下位互換性のために追加）3.7.0の新機能: 有効にすると、リーダーはクォーラムソケットを非同期的に閉じます。これは、ソケットのクローズに時間がかかる可能性のあるTLS接続に役立ちます。失敗したSyncLimitCheckのためにping（）でフォロワーの切断が開始された場合、長いソケットクローズ時間が他のフォロワーへのpingの送信をブロックします。pingを受信しないと、他のフォロワーはセッション情報をリーダーに送信せず、セッションが期限切れになります。このフラグをtrueに設定すると、pingが定期的に送信されます。デフォルトはfalseです。

• learner.asyncSending（Javaシステムプロパティ：zookeeper.learner.asyncSending）（Javaシステムプロパティ：learner.asyncSending）（下位互換性のために追加）3.7.0の新機能: Learnerでの送受信パケットは、クリティカルセクションで同期的に実行されていました。時期尚早のネットワークの問題により、フォロワーがハングする可能性があります（ZOOKEEPER-3575およびZOOKEEPER-4074を参照）。新しい設計では、Learnerでのパケット送信を別のスレッドに移動し、パケットを非同期的に送信します。新しい設計は、このパラメーター（learner.asyncSending）で有効になります。デフォルトはfalseです。

• forward_learner_requests_to_commit_processor_disabled（Javaシステムプロパティ：zookeeper.forward_learner_requests_to_commit_processor_disabled）このプロパティが設定されている場合、ラーナーからのリクエストはCommitProcessorキューにエンキューされません。これにより、リーダーのリソースとGC時間を節約できます。

  デフォルト値はfalseです。

• serializeLastProcessedZxid.enabled（Javeシステムプロパティ：zookeeper.serializeLastProcessedZxid.enabled）3.9.0の新機能: 有効にすると、ZooKeeperはスナップショット時にlastProcessedZxidをシリアル化し、復元時にデシリアライズします。デフォルトはtrueです。管理サーバーコマンドを介してスナップショットと復元を実行するには、有効にする必要があります。スナップショットファイル名からlastProcessedZxidを抽出することはできないためです。

この機能は下位互換性と上位互換性があります。さまざまなシナリオを以下に示します。

1. サーバーによって内部的にトリガーされるスナップショット a. 新しいコードで古いスナップショットを読み込む場合、存在しないlastProcessedZxid値を読み込もうとするとEOFExceptionがスローされ、例外がキャッチされます。lastProcessedZxidはスナップショットファイル名を使用して設定されます。

   b. 古いコードで新しいスナップショットを読み込む場合、ダイジェスト値のデシリアライズ後に正常に終了し、スナップショットファイルの最後のlastProcessedZxidは無視されます。lastProcessedZxidはスナップショットファイル名を使用して設定されます。

   1. リーダーとフォロワー間の同期 新しいコードと古いコードの両方で、lastProcessedZxidはリーダーによってシリアル化されず、フォロワーによってデシリアライズされません。QuorumPacketを介してリーダーから送信されたlastProcessedZxidに設定されます。

2. 管理サーバーAPIによってトリガーされるスナップショット スナップショットコマンドを機能させるには、機能フラグを有効にする必要があります。

クラスタオプション

このセクションのオプションは、サーバーのアンサンブル（つまり、サーバーのクラスタを展開する場合）で使用するために設計されています。

• electionAlg：（Javaシステムプロパティなし）使用する選挙実装。値「1」は、高速リーダー選出の認証されていないUDPベースのバージョンに対応し、「2」は、高速リーダー選出の認証されたUDPベースのバージョンに対応し、「3」は、TCPベースの高速リーダー選出のバージョンに対応します。アルゴリズム3は3.2.0でデフォルトになり、それ以前のバージョン（3.0.0と3.1.0）でもアルゴリズム1と2を使用していました。

  注記

  リーダー選出のアルゴリズム1と2の実装は、3.4.0で非推奨になりました。3.6.0以降はFastLeaderElectionのみが利用可能であるため、アップグレードする場合は、すべてのサーバーをシャットダウンし、electionAlg=3で再起動する必要があります（または、設定ファイルからその行を削除します）。>

• maxTimeToWaitForEpoch：（Javaシステムプロパティ：zookeeper.leader.maxTimeToWaitForEpoch）3.6.0の新機能: リーダーをアクティブ化するときに、投票者からエポックを待つ最大時間。リーダーが投票者の1つからLOOKING通知を受信し、maxTimeToWaitForEpoch内で過半数からエポックパケットを受信していない場合、LOOKINGに戻ってリーダーを再選出します。これは、クォーラムまたはサーバーの利用不可時間を短縮するために調整できます。initLimit * tickTimeよりもはるかに小さく設定できます。クロスデータセンター環境では、2秒などにすることができます。

• initLimit：（Javaシステムプロパティなし）ティック数（tickTimeを参照）で、フォロワーがリーダーに接続して同期できるようにする時間。ZooKeeperによって管理されるデータの量が多い場合は、必要に応じてこの値を増やします。

• connectToLearnerMasterLimit：（Javaシステムプロパティ：zookeeper.connectToLearnerMasterLimit）ティック数（tickTimeを参照）で、リーダー選出後にフォロワーがリーダーに接続できるようにする時間。initLimitの値がデフォルトです。initLimitが高い場合に使用し、ラーナーマスターへの接続でタイムアウトが長くなるのを防ぎます。

• leaderServes：（Javaシステムプロパティ：zookeeper.leaderServes）リーダーはクライアント接続を受け入れます。デフォルト値は「yes」です。リーダーマシンは更新を調整します。わずかな読み取りスループットの犠牲で更新スループットを高めるために、リーダーはクライアントを受け入れず、調整に集中するように設定できます。このオプションのデフォルトはyesであり、リーダーはクライアント接続を受け入れることを意味します。

  注記

  アンサンブルに3つ以上のZooKeeperサーバーがある場合は、リーダーの選択を有効にすることを強くお勧めします。

• server.x=[hostname]:nnnnn[:nnnnn] etc：（Javaシステムプロパティなし）ZooKeeperアンサンブルを構成するサーバー。サーバーが起動すると、データディレクトリ内のファイルmyidを調べて、どのサーバーであるかを判別します。そのファイルには、ASCII形式のサーバー番号が含まれており、この設定の左側のserver.xのxと一致する必要があります。クライアントが使用するZooKeeperサーバーのリストは、各ZooKeeperサーバーが持つZooKeeperサーバーのリストと一致する必要があります。2つのポート番号nnnnnがあります。最初のフォロワーはリーダーへの接続に使用され、2番目はリーダー選出に使用されます。単一のマシンで複数のサーバーをテストする場合は、各サーバーに異なるポートを使用できます。

  ZooKeeper 3.6.0以降、各ZooKeeperサーバーに複数のアドレスを指定できるようになりました（ZOOKEEPER-3188を参照）。この機能を有効にするには、multiAddress.enabled設定プロパティをtrueに設定する必要があります。これにより、可用性が向上し、ZooKeeperにネットワークレベルの回復力が追加されます。サーバーに複数の物理ネットワークインターフェースを使用する場合、ZooKeeperはすべてのインターフェースにバインドでき、ネットワークエラーが発生した場合に動作中のインターフェースにランタイムで切り替えることができます。複数のアドレスは、パイプ文字（'|'）を使用してconfigに指定できます。複数のアドレスを使用した有効な構成は次のようになります。

  server.1=zoo1-net1:2888:3888|zoo1-net2:2889:3889
  server.2=zoo2-net1:2888:3888|zoo2-net2:2889:3889
  server.3=zoo3-net1:2888:3888|zoo3-net2:2889:3889
  

  注記

  この機能を有効にすると、クォーラムプロトコル（ZooKeeperサーバー間プロトコル）が変更されます。ユーザーはこれに気付かず、新しいconfigでZooKeeperクラスタを起動すると、すべて正常に動作します。ただし、古いZooKeeperクラスタがmultiAddress機能（および新しいクォーラムプロトコル）をサポートしていない場合、ローリングアップグレード中にこの機能を有効にして複数のアドレスを指定することはできません。この機能が必要で、3.6.0より古いZooKeeperクラスタからのローリングアップグレードも実行する必要がある場合は、まずMultiAddress機能を有効にせずにローリングアップグレードを実行し、後でmultiAddress.enabledがtrueに設定され、複数のアドレスが提供されている新しい構成で別のローリング再起動を行う必要があります。

• syncLimit：（Javaシステムプロパティなし）フォロワーがZooKeeperと同期するために許容される時間（tickTimeを参照）。ティック単位で指定します。フォロワーがリーダーに遅れすぎると、削除されます。

• group.x=nnnnn[:nnnnn]：（Javaシステムプロパティなし）階層的なクォーラム構築を有効にします。"x"はグループ識別子であり、"="記号の後の数値はサーバー識別子に対応します。代入の左辺は、コロンで区切られたサーバー識別子のリストです。グループは互いに素であり、すべてのグループの和集合がZooKeeperアンサンブルであることに注意してください。例はこちらを参照してください。

• weight.x=nnnnn：（Javaシステムプロパティなし）"group"と共に使用され、クォーラムを形成する際のサーバーに重みを割り当てます。この値は、投票時のサーバーの重みに対応します。リーダー選出やアトミックブロードキャストプロトコルなど、投票を必要とするZooKeeperのいくつかの部分があります。デフォルトでは、サーバーの重みは1です。設定でグループが定義されているが重みが定義されていない場合、すべてのサーバーに1の値が割り当てられます。例はこちらを参照してください。

• cnxTimeout：（Javaシステムプロパティ：zookeeper.cnxTimeout）リーダー選出通知の接続を開くためのタイムアウト値を設定します。electionAlg 3を使用している場合にのみ適用されます。

  注記

  デフォルト値は5秒です。

• quorumCnxnTimeoutMs：（Javaシステムプロパティ：zookeeper.quorumCnxnTimeoutMs）リーダー選出通知の接続の読み取りタイムアウト値を設定します。electionAlg 3を使用している場合にのみ適用されます。

  注記

  デフォルト値は-1で、この場合はsyncLimit * tickTimeがタイムアウトとして使用されます。

• standaloneEnabled：（Javaシステムプロパティなし）3.5.0の新機能：falseに設定すると、単一サーバーをレプリケートモードで起動でき、単独の参加者はオブザーバーと共に実行でき、クラスタは1ノードに再構成され、1ノードから拡張できます。下位互換性のために、デフォルトは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に設定すると、リーダーとして選出されたサーバーによって動作が不整合になります。リーダーの設定が"reconfigEnabled=true"の場合、エンティティは再構成機能が有効になります。リーダーの設定が"reconfigEnabled=false"の場合、エンティティは再構成機能が無効になります。したがって、エンティティ内のサーバー間で"reconfigEnabled"の値を一致させることをお勧めします。

• 4lw.commands.whitelist：（Javaシステムプロパティ：zookeeper.4lw.commands.whitelist）3.5.3の新機能：ユーザーが使用したいカンマ区切りの4文字コマンドのリストです。有効な4文字コマンドは、このリストに含める必要があります。そうでない場合、ZooKeeperサーバーはコマンドを有効にしません。デフォルトでは、ホワイトリストにはzkServer.shが使用する"srvr"コマンドのみが含まれています。残りの4文字コマンドはデフォルトで無効になっています。これらを使用しようとすると、「....はホワイトリストにないため実行されません。」という応答が得られます。stat、ruok、conf、isroコマンドを有効にし、残りの4文字コマンドを無効にする設定の例を以下に示します。

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

すべての4文字コマンドをデフォルトで有効にする必要がある場合は、アスタリスクオプションを使用すると、リストにすべてのコマンドを1つずつ含める必要がありません。たとえば、これによりすべての4文字コマンドが有効になります。

4lw.commands.whitelist=*

• tcpKeepAlive：（Javaシステムプロパティ：zookeeper.tcpKeepAlive）3.5.4の新機能：これをtrueに設定すると、クォーラムメンバーが選挙の実行に使用しているソケットのTCP keepAliveフラグが設定されます。これにより、それ以外の場合は切断する可能性のあるネットワークインフラストラクチャがある場合でも、クォーラムメンバー間の接続を維持できます。一部のNATとファイアウォールは、長時間実行されるアイドル接続の状態を終了または失う可能性があります。このオプションを有効にするには、正しく動作するためにOSレベルの設定に依存します。詳細については、オペレーティングシステムのTCP keepaliveに関するオプションを確認してください。デフォルトはfalseです。

• clientTcpKeepAlive：（Javaシステムプロパティ：zookeeper.clientTcpKeepAlive）3.6.1の新機能：これをtrueに設定すると、クライアントソケットのTCP keepAliveフラグが設定されます。破損したネットワークインフラストラクチャでは、クローズ中のクライアントから送信されるFINパケットが失われる可能性があります。これらの決してクローズされないクライアントソケットは、OSリソースリークを引き起こします。このオプションを有効にすると、アイドルチェックによってこれらのゾンビソケットが終了します。このオプションを有効にするには、正しく動作するためにOSレベルの設定に依存します。詳細については、オペレーティングシステムのTCP keepaliveに関するオプションを確認してください。デフォルトはfalseです。tcpKeepAliveとの違いに注意してください。これはクライアントソケットに適用されますが、tcpKeepAliveはクォーラムメンバーが使用するソケット用です。現在、このオプションはデフォルトのNIOServerCnxnFactoryを使用する場合にのみ使用できます。

• electionPortBindRetry：（Javaシステムプロパティのみ：zookeeper.electionPortBindRetry）Zookeeperサーバーがリーダー選出ポートのバインドに失敗した場合の最大再試行回数を設定するプロパティです。ZOOKEEPER-3320で説明されているDNSの問題など、一時的なエラーと回復可能なエラー、またはポートが既に使用中など、再試行できないエラーがあります。一時的なエラーの場合、このプロパティはZookeeperサーバーの可用性を向上させ、自己回復を支援できます。デフォルト値は3です。特にKubernetesなどのコンテナ環境では、DNS名の解決に関連する問題を克服するために、この値を増やすか、0（無限再試行）に設定する必要があります。

• observer.reconnectDelayMs：（Javaシステムプロパティ：zookeeper.observer.reconnectDelayMs）オブザーバーがリーダーとの接続を失うと、リーダーとの再接続を試みる前に指定された値だけ待機します。これにより、オブザーバーフリート全体が一度にリーダー選出を実行してリーダーに再接続しようとするのを防ぎます。デフォルトは0ミリ秒です。

• observer.election.DelayMs：（Javaシステムプロパティ：zookeeper.observer.election.DelayMs）切断時にオブザーバーのリーダー選出への参加を遅らせ、このプロセス中に投票ピアへの予期せぬ追加負荷を防ぎます。デフォルトは200ミリ秒です。

• localSessionsEnabledとlocalSessionsUpgradingEnabled：3.5の新機能：オプションの値はtrueまたはfalseです。デフォルト値はfalseです。localSessionsEnabled=trueに設定することで、ローカルセッション機能を有効にできます。localSessionsUpgradingEnabledを有効にすると、必要に応じてローカルセッションをグローバルセッションに自動的にアップグレードできます（例：一時ノードの作成）。これは、localSessionsEnabledが有効になっている場合にのみ重要です。

暗号化、認証、認可オプション

このセクションのオプションを使用すると、サービスによって実行される暗号化/認証/承認を制御できます。

このページ以外にも、プログラマーガイドでクライアント側の設定に関する有用な情報を見つけることができます。ZooKeeper Wikiには、ZooKeeper SSLサポートとZooKeeperのSASL認証に関する有用なページもあります。

• DigestAuthenticationProvider.enabled：（Javaシステムプロパティ：zookeeper.DigestAuthenticationProvider.enabled）3.7の新機能：digest認証プロバイダーが有効かどうかを決定します。下位互換性のためにデフォルト値はtrueですが、使用しない場合はこのプロバイダーを無効にすることをお勧めします。監査ログに誤解を招く可能性のあるエントリが表示される可能性があるためです（ZOOKEEPER-3979を参照）。

• DigestAuthenticationProvider.superDigest：（Javaシステムプロパティ：zookeeper.DigestAuthenticationProvider.superDigest）デフォルトではこの機能は無効です。3.2の新機能：ZooKeeperアンサンブル管理者が「スーパー」ユーザーとしてznode階層にアクセスできるようにします。具体的には、スーパーとして認証されたユーザーに対してはACLチェックは行われません。org.apache.zookeeper.server.auth.DigestAuthenticationProviderを使用してsuperDigestを生成できます。パラメーター「super」を1つ指定して呼び出します。". 生成された"super:"を各サーバーの起動時のシステムプロパティ値として指定します。ZooKeeperサーバー（ZooKeeperクライアントから）に認証する際には、「digest」のスキームと「super:」のauthdataを渡します。digest認証はauthdataをプレーンテキストでサーバーに渡すため、この認証メソッドはlocalhost（ネットワーク上ではない）または暗号化された接続でのみ使用する方が賢明です。

• DigestAuthenticationProvider.digestAlg：（Javaシステムプロパティ：zookeeper.DigestAuthenticationProvider.digestAlg）3.7.0の新機能：ACLダイジェストアルゴリズムを設定します。デフォルト値はSHA1ですが、セキュリティ上の問題から将来廃止される予定です。このプロパティをすべてのサーバーで同じ値に設定します。

  • 他のアルゴリズムをサポートするにはどうすればよいですか？

    • $JAVA_HOME/jre/lib/security/java.securityにあるjava.security設定ファイルを修正して、security.provider.<n>=<provider class name>を指定します。

      For example:
      set zookeeper.DigestAuthenticationProvider.digestAlg=RipeMD160
      security.provider.3=org.bouncycastle.jce.provider.BouncyCastleProvider
      

    • jarファイルを$JAVA_HOME/jre/lib/ext/にコピーします。

      For example:
      copy bcprov-jdk18on-1.60.jar to $JAVA_HOME/jre/lib/ext/
      

  • ダイジェストアルゴリズムを移行するにはどうすればよいですか？

    • 1. 新しいアルゴリズムに移行する際にsuperDigestを再生成します。
    • 1. 古いアルゴリズムのダイジェスト認証が既に設定されているznodeに対してSetAclを実行します。

• X509AuthenticationProvider.superUser：（Javaシステムプロパティ：zookeeper.X509AuthenticationProvider.superUser）SSLを基盤とした方法で、ZooKeeperアンサンブル管理者が「スーパー」ユーザーとしてznode階層にアクセスできるようにします。このパラメーターがX500プリンシパル名に設定されている場合、そのプリンシパルを持つ認証済みのクライアントのみがACLチェックをバイパスし、すべてのznodeへの完全な権限を持つことができます。

• zookeeper.superUser：（Javaシステムプロパティ：zookeeper.superUser）zookeeper.X509AuthenticationProvider.superUserと同様ですが、SASLベースのログインに対して汎用的です。「スーパー」ユーザーとしてznode階層にアクセスできるユーザーの名前を格納します。zookeeper.superUser.[suffix]表記を使用して、複数のSASLスーパーユーザーを指定できます（例：zookeeper.superUser.1=...）。

• ssl.authProvider：（Javaシステムプロパティ：zookeeper.ssl.authProvider）安全なクライアント認証に使用するorg.apache.zookeeper.auth.X509AuthenticationProviderのサブクラスを指定します。これは、JKSを使用しない証明書キーインフラストラクチャで役立ちます。SSLスタックから必要な動作を得るには、javax.net.ssl.X509KeyManagerとjavax.net.ssl.X509TrustManagerを拡張する必要がある場合があります。ZooKeeperサーバーが認証にカスタムプロバイダーを使用するように設定するには、カスタムAuthenticationProviderのスキーム名を選択し、プロパティzookeeper.authProvider.[scheme]をカスタム実装の完全修飾クラス名に設定します。これにより、プロバイダーがProviderRegistryにロードされます。次に、このプロパティzookeeper.ssl.authProvider=[scheme]を設定すると、そのプロバイダーが安全な認証に使用されます。

• zookeeper.ensembleAuthName：（Javaシステムプロパティのみ：zookeeper.ensembleAuthName）3.6.0の新機能：コンマ区切りの有効なアンサンブル名/エイリアスのリストを指定します。「ensemble」スキームの資格情報として、接続しようとするアンサンブル名をクライアントが提供できます。EnsembleAuthenticationProviderは、接続要求を受け取るアンサンブルの、名前/エイリアスのリストに対して資格情報をチェックします。資格情報がリストにない場合、接続要求は拒否されます。これにより、クライアントが誤って間違ったアンサンブルに接続するのを防ぎます。

• sessionRequireClientSASLAuth：（Javaシステムプロパティ：zookeeper.sessionRequireClientSASLAuth）3.6.0の新機能：trueに設定すると、ZooKeeperサーバーはSASLでサーバーと認証済みのクライアントからの接続と要求のみを受け入れます。SASL認証が設定されていないクライアント、またはSASLが設定されているが認証に失敗したクライアント（無効な資格情報など）は、サーバーとのセッションを確立できません。そのような場合、型付きエラーコード（-124）が配信され、JavaおよびCクライアントはその後、再接続を試行せずにサーバーとのセッションを閉じます。

  この設定は、enforce.auth.enabled=trueとenforce.auth.scheme=saslの省略形です。

  デフォルトでは、この機能は無効になっています。有効化したいユーザーは、sessionRequireClientSASLAuthをtrueに設定することで有効化できます。

  この機能は、以下の機能を無効にします。zookeeper.allowSaslFailedClientsつまり、サーバーがSASL認証に失敗したクライアントのログインを許可するように設定されている場合でも、この機能が有効になっていると、クライアントはサーバーとのセッションを確立できません。

• enforce.auth.enabled：（Javaシステムプロパティ：zookeeper.enforce.auth.enabled）3.7.0の新機能：trueに設定すると、ZooKeeperサーバーは、設定された認証スキームを介してサーバーと認証済みのクライアントからの接続と要求のみを受け入れます。認証スキームは、プロパティenforce.auth.schemesを使用して設定できます。サーバーで設定されていない認証スキーム、または設定されているが認証に失敗した（無効な資格情報など）クライアントは、サーバーとのセッションを確立できません。そのような場合、型付きエラーコード（-124）が配信され、JavaおよびCクライアントはその後、再接続を試行せずにサーバーとのセッションを閉じます。

  デフォルトでは、この機能は無効になっています。有効化したいユーザーは、enforce.auth.enabledをtrueに設定することで有効化できます。

  enforce.auth.enabled=trueかつenforce.auth.schemes=saslの場合、zookeeper.allowSaslFailedClientsの設定は無効になります。つまり、サーバーがSASL認証に失敗したクライアントのログインを許可するように設定されている場合でも、この機能がsaslを認証スキームとして有効になっていると、クライアントはサーバーとのセッションを確立できません。

• enforce.auth.schemes：（Javaシステムプロパティ：zookeeper.enforce.auth.schemes）3.7.0の新機能：コンマ区切りの認証スキームのリストです。クライアントは、ZooKeeper操作を行う前に、少なくとも1つの認証スキームで認証されている必要があります。このプロパティは、enforce.auth.enabledがtrueの場合にのみ使用されます。

• sslQuorum：（Javaシステムプロパティ：zookeeper.sslQuorum）3.5.5の新機能：暗号化されたクォーラム通信を有効にします。デフォルトはfalseです。この機能を有効にする場合は、SSL接続のシャットダウン時の潜在的に長いソケットクローズ時間に関連する問題を回避するために、leader.closeSocketAsyncとlearner.closeSocketAsyncも有効にすることを検討してください。

• ssl.keyStore.locationとssl.keyStore.passwordとssl.quorum.keyStore.locationとssl.quorum.keyStore.password：（Javaシステムプロパティ：zookeeper.ssl.keyStore.locationとzookeeper.ssl.keyStore.passwordとzookeeper.ssl.quorum.keyStore.locationとzookeeper.ssl.quorum.keyStore.password）3.5.5の新機能：クライアントとクォーラムのTLS接続に使用されるローカル資格情報を含むJavaキーストアへのファイルパスと、ファイルをロック解除するためのパスワードを指定します。

• ssl.keyStore.passwordPathとssl.quorum.keyStore.passwordPath：（Javaシステムプロパティ：zookeeper.ssl.keyStore.passwordPathとzookeeper.ssl.quorum.keyStore.passwordPath）3.8.0の新機能：キーストアパスワードを含むファイルパスを指定します。ファイルからのパスワードの読み込みは、明示的なパスワードプロパティよりも優先されます。

• ssl.keyStore.typeとssl.quorum.keyStore.type：（Javaシステムプロパティ：zookeeper.ssl.keyStore.typeとzookeeper.ssl.quorum.keyStore.type）3.5.5の新機能：クライアントとクォーラムのキーストアのファイル形式を指定します。値：JKS、PEM、PKCS12、またはnull（ファイル名で検出）。デフォルト：null。3.5.10、3.6.3、3.7.0の新機能：BCFKS形式が追加されました。

• ssl.trustStore.locationとssl.trustStore.passwordとssl.quorum.trustStore.locationとssl.quorum.trustStore.password：（Javaシステムプロパティ：zookeeper.ssl.trustStore.locationとzookeeper.ssl.trustStore.passwordとzookeeper.ssl.quorum.trustStore.locationとzookeeper.ssl.quorum.trustStore.password）3.5.5の新機能：クライアントとクォーラムのTLS接続に使用されるリモート資格情報を含むJavaトラストストアへのファイルパスと、ファイルをロック解除するためのパスワードを指定します。

• ssl.trustStore.passwordPathとssl.quorum.trustStore.passwordPath：（Javaシステムプロパティ：zookeeper.ssl.trustStore.passwordPathとzookeeper.ssl.quorum.trustStore.passwordPath）3.8.0の新機能：トラストストアパスワードを含むファイルパスを指定します。ファイルからのパスワードの読み込みは、明示的なパスワードプロパティよりも優先されます。

• ssl.trustStore.typeとssl.quorum.trustStore.type：（Javaシステムプロパティ：zookeeper.ssl.trustStore.typeとzookeeper.ssl.quorum.trustStore.type）3.5.5の新機能：クライアントとクォーラムのTrustStoreのファイル形式を指定します。値：JKS、PEM、PKCS12、またはnull（ファイル名で検出）。デフォルト：null。3.5.10、3.6.3、3.7.0の新機能：BCFKS形式が追加されました。

• ssl.protocolとssl.quorum.protocol：（Javaシステムプロパティ：zookeeper.ssl.protocolとzookeeper.ssl.quorum.protocol）3.5.5の新機能：クライアントとクォーラムのTLSネゴシエーションで使用されるプロトコルを指定します。デフォルト：TLSv1.2

• ssl.enabledProtocolsとssl.quorum.enabledProtocols：（Javaシステムプロパティ：zookeeper.ssl.enabledProtocolsとzookeeper.ssl.quorum.enabledProtocols）3.5.5の新機能：クライアントとクォーラムのTLSネゴシエーションで有効なプロトコルを指定します。デフォルト：protocolプロパティの値

• ssl.ciphersuitesとssl.quorum.ciphersuites：（Javaシステムプロパティ：zookeeper.ssl.ciphersuitesとzookeeper.ssl.quorum.ciphersuites）3.5.5の新機能：クライアントとクォーラムのTLSネゴシエーションで使用される有効な暗号スイートを指定します。デフォルト：有効な暗号スイートは、使用されているJavaランタイムバージョンによって異なります。

• ssl.context.supplier.classとssl.quorum.context.supplier.class：（Javaシステムプロパティ：zookeeper.ssl.context.supplier.classとzookeeper.ssl.quorum.context.supplier.class）3.5.5の新機能：クライアントとクォーラムのSSL通信でSSLコンテキストの作成に使用されるクラスを指定します。これにより、カスタムSSLコンテキストを使用し、次のシナリオを実装できます。

  1. PKCS11などを使用して読み込まれたハードウェアキーストアを使用します。
  2. ソフトウェアキーストアにアクセスできませんが、コンテナーから既に構築されたSSLContextを取得できます。デフォルト：null

• ssl.hostnameVerificationとssl.quorum.hostnameVerification：（Javaシステムプロパティ：zookeeper.ssl.hostnameVerificationとzookeeper.ssl.quorum.hostnameVerification）3.5.5の新機能：クライアントとクォーラムのTLSネゴシエーションプロセスでホスト名検証が有効かどうかを指定します。無効にするのは、テスト目的でのみ推奨されます。デフォルト：true

• ssl.crlとssl.quorum.crl：（Javaシステムプロパティ：zookeeper.ssl.crlとzookeeper.ssl.quorum.crl）3.5.5の新機能：クライアントとクォーラムのTLSプロトコルで証明書失効リストが有効かどうかを指定します。デフォルト：false

• ssl.ocspとssl.quorum.ocsp：（Javaシステムプロパティ：zookeeper.ssl.ocspとzookeeper.ssl.quorum.ocsp）3.5.5の新機能：クライアントとクォーラムのTLSプロトコルでオンライン証明書ステータスプロトコルが有効かどうかを指定します。デフォルト：false

• ssl.clientAuthとssl.quorum.clientAuth：（Javaシステムプロパティ：zookeeper.ssl.clientAuthとzookeeper.ssl.quorum.clientAuth）3.5.5に追加されましたが、3.5.7までは機能していませんでした：クライアントからのssl接続を認証するためのオプションを指定します。有効な値は次のとおりです。

  • 「none」：サーバーはクライアント認証を要求しません。
  • 「want」：サーバーはクライアント認証を「要求」します。
  • 「need」：サーバーはクライアント認証を「必要」とします。

  デフォルト：「need」

• ssl.handshakeDetectionTimeoutMillisとssl.quorum.handshakeDetectionTimeoutMillis：（Javaシステムプロパティ：zookeeper.ssl.handshakeDetectionTimeoutMillisとzookeeper.ssl.quorum.handshakeDetectionTimeoutMillis）3.5.5の新機能：未定義

• ssl.sslProvider：（Javaシステムプロパティ：zookeeper.ssl.sslProvider）3.9.0の新機能：TLSが有効になっている場合、クライアントサーバー間の通信でSSLプロバイダーを選択できます。バージョン3.9.0のZooKeeperには、サポートされているプラットフォームでOpenSSLなどのネイティブSSLライブラリを使用できるNetty-tcnativeネイティブライブラリが追加されました。Netty-tcnativeドキュメントで利用可能なオプションを参照してください。デフォルト値は「JDK」です。

• sslQuorumReloadCertFiles：（Javaシステムプロパティなし）3.5.5、3.6.0の新機能：ZKプロセスを再起動しなくても、ファイルシステム上の証明書が変更された場合に、クォーラムSSL keyStoreとtrustStoreの再読み込みを許可します。デフォルト：false

• client.certReload：（Javaシステムプロパティ：zookeeper.client.certReload）3.7.2、3.8.1、3.9.0の新機能：ZKプロセスを再起動しなくても、ファイルシステム上の証明書が変更された場合に、クライアントSSL keyStoreとtrustStoreの再読み込みを許可します。デフォルト：false

• client.portUnification：（Javaシステムプロパティ：zookeeper.client.portUnification）クライアントポートがSSL接続を受け入れる必要があることを指定します（セキュアなクライアントポートと同じ構成を使用）。デフォルト：false

• authProvider：（Javaシステムプロパティ：zookeeper.authProvider）ZooKeeperに複数の認証プロバイダークラスを指定できます。通常、このパラメーターを使用して、SASL認証プロバイダーを指定します。例：authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider

• kerberos.removeHostFromPrincipal（Javaシステムプロパティ：zookeeper.kerberos.removeHostFromPrincipal）認証中にクライアントプリンシパル名からホストを削除するようにZooKeeperに指示できます。（例：zk/myhost@EXAMPLE.COMクライアントプリンシパルは、ZooKeeperでzk@EXAMPLE.COMとして認証されます）デフォルト：false

• kerberos.removeRealmFromPrincipal（Javaシステムプロパティ：zookeeper.kerberos.removeRealmFromPrincipal）認証中にクライアントプリンシパル名からレルムを削除するようにZooKeeperに指示できます。（例：zk/myhost@EXAMPLE.COMクライアントプリンシパルは、ZooKeeperでzk/myhostとして認証されます）デフォルト：false

• kerberos.canonicalizeHostNames（Javaシステムプロパティ：zookeeper.kerberos.canonicalizeHostNames）3.7.0の新機能：server.x行から抽出されたサーバーホスト名を正規化するようにZooKeeperに指示します。これにより、構成ファイル内のサーバーを参照するためにCNAMEレコードを使用しながら、クォーラムメンバー間のSASL Kerberos認証を有効にできます。本質的には、クライアントのzookeeper.sasl.client.canonicalize.hostnameプロパティと同様のクォーラム相当です。下位互換性のために、デフォルト値はfalseです。

• multiAddress.enabled：（Javaシステムプロパティ：zookeeper.multiAddress.enabled）3.6.0の新機能：ZooKeeper 3.6.0以降、各ZooKeeperサーバーインスタンスに複数のアドレスを指定することもできます（これは、複数の物理ネットワークインターフェースをクラスターで並列に使用できる場合、可用性を高めることができます）。このパラメーターをtrueに設定すると、この機能が有効になります。古いZooKeeperクラスターのバージョンが3.6.0より前の場合は、ローリングアップグレード中にこの機能を有効にできません。デフォルト値はfalseです。

• multiAddress.reachabilityCheckTimeoutMs：（Javaシステムプロパティ：zookeeper.multiAddress.reachabilityCheckTimeoutMs）3.6.0の新機能：ZooKeeper 3.6.0以降、各ZooKeeperサーバーインスタンスに複数のアドレスを指定することもできます（これは、複数の物理ネットワークインターフェースをクラスターで並列に使用できる場合、可用性を高めることができます）。ZooKeeperは、到達可能なアドレスを見つけるために、ICMP ECHO要求を実行するか、宛先ホストのポート7（Echo）でTCP接続を確立しようとします。これは、構成に複数のアドレスを提供する場合のみ発生します。このプロパティでは、到達可能性チェックのタイムアウトをミリ秒単位で設定できます。チェックは異なるアドレスに対して並列に行われるため、ここで設定したタイムアウトは、すべてのアドレスの到達可能性のチェックにかかる最大時間です。デフォルト値は1000です。

  このパラメータは、multiAddress.enabled=true を設定して MultiAddress 機能を有効にしない限り、効果はありません。

• fips-mode：（Java システムプロパティ: **zookeeper.fips-mode**） **3.8.2の新機能:** ZooKeeperでFIPS互換モードを有効にします。有効にすると、ホスト名検証に使用されるカスタムトラストマネージャー（ZKTrustManager）が無効になり、FIPS要件に準拠します。その結果、クォーラムプロトコルではホスト名検証は利用できませんが、クライアントサーバー間の通信では引き続き設定できます。デフォルト: **true** (3.9.0以降)、**false** (3.8.x)

実験的オプション/機能

現在実験段階と見なされている新機能。

• Read Only Mode Server：（Java システムプロパティ: **readonlymode.enabled**） **3.4.0の新機能:** この値をtrueに設定すると、Read Only Modeサーバーのサポートが有効になります（デフォルトでは無効）。ROMにより、サーバーがクォーラムからパーティション化されている場合でも、ROMサポートを要求したクライアントセッションがサーバーに接続できます。このモードでは、ROMクライアントはZKサービスから値を読み取ることができますが、値を書き込んだり、他のクライアントからの変更を確認することはできません。詳細については、ZOOKEEPER-784を参照してください。

• zookeeper.follower.skipLearnerRequestToNextProcessor：（Java システムプロパティ: **zookeeper.follower.skipLearnerRequestToNextProcessor**） クラスタにObserverMasterに接続されたオブザーバーがある場合、このフラグをオンにすると、Observer Masterのメモリ圧力を軽減できる場合があります。クラスタにオブザーバーがない場合、またはObserverMasterに接続されていない場合、あるいはオブザーバーの書き込みが少ない場合は、このフラグを使用しても効果はありません。現在、この変更はフラグによって制御されており、メモリ増加に関する信頼性を高めるのに役立っています。長期的に見ると、このフラグを削除し、その動作をデフォルトのコードパスとして設定したいと考えています。

安全でないオプション

次のオプションは便利ですが、使用する際には注意が必要です。各オプションのリスクは、変数の説明とともに説明されています。

• forceSync：（Java システムプロパティ: **zookeeper.forceSync**） 更新処理を完了する前に、トランザクションログのメディアに更新を同期する必要があります。このオプションをnoに設定すると、ZooKeeperはメディアへの更新の同期を要求しなくなります。

• jute.maxbuffer：（Java システムプロパティ: **jute.maxbuffer**）

  • このオプションは、Javaシステムプロパティとしてのみ設定できます。zookeeperプレフィックスはありません。これは、znodeに保存できるデータの最大サイズを指定します。単位はバイトです。デフォルトは0xfffff（1048575）バイト、つまり1M未満です。
  • このオプションを変更する場合は、問題が発生するのを防ぐため、すべてのサーバーとクライアントでシステムプロパティを設定する必要があります。
  • クライアント側のjute.maxbufferがサーバー側よりも大きい場合、クライアントがサーバー側のjute.maxbufferを超えるデータの書き込みを試みると、サーバー側で**java.io.IOException: Len error**が発生します。
  • クライアント側のjute.maxbufferがサーバー側よりも小さい場合、クライアントがクライアント側のjute.maxbufferを超えるデータの読み込みを試みると、クライアント側で**java.io.IOException: Unreasonable length**または**Packet len is out of range!**が発生します。
  • これは、実際にはサニティチェックです。ZooKeeperは、キロバイトサイズのデータを保存するように設計されています。本番環境では、このプロパティをデフォルト値を超えるように増やすことは、次の理由により推奨されません。
  • 大きなサイズのznodeは、不必要なレイテンシスパイクを引き起こし、スループットを低下させます。
  • 大きなサイズのznodeは、リーダーとフォロワー間の同期時間を予測不可能で非収束（タイムアウトする場合もあります）にし、クォーラムを不安定にします。

• jute.maxbuffer.extrasize：（Java システムプロパティ: **zookeeper.jute.maxbuffer.extrasize**） **3.5.7の新機能:** クライアント要求を処理する際、ZooKeeperサーバーはトランザクションとして永続化する前に、追加情報を要求に追加します。以前は、この追加情報のサイズは1024バイトに固定されていました。多くのシナリオ、特にjute.maxbufferの値が1MBを超え、要求の種類がマルチであるシナリオでは、この固定サイズは不十分でした。すべてのシナリオを処理するために、追加情報のサイズは1024バイトからjute.maxbufferサイズと同じサイズに増加し、jute.maxbuffer.extrasizeを介して設定可能になりました。一般的に、デフォルト値が最適な値であるため、このプロパティを設定する必要はありません。

• skipACL：（Java システムプロパティ: **zookeeper.skipACL**）ACLチェックをスキップします。これによりスループットが向上しますが、データツリーへの完全なアクセス権が全員に開かれます。

• quorumListenOnAllIPs：trueに設定すると、ZooKeeperサーバーは、構成ファイルのサーバーリストに設定されているアドレスだけでなく、使用可能なすべてのIPアドレスからのピアからの接続をリッスンします。これは、ZABプロトコルと高速リーダー選出プロトコルを処理する接続に影響します。デフォルト値は**false**です。

• multiAddress.reachabilityCheckEnabled：（Java システムプロパティ: **zookeeper.multiAddress.reachabilityCheckEnabled**） **3.6.0の新機能:** ZooKeeper 3.6.0以降、各ZooKeeperサーバーインスタンスに複数のアドレスを指定することもできます（クラスタ内で複数の物理ネットワークインターフェースを並列で使用できる場合、可用性を高めることができます）。ZooKeeperは、到達可能なアドレスを見つけるために、ICMP ECHO要求を実行するか、宛先ホストのポート7（Echo）でTCP接続を確立しようとします。これは、構成に複数のアドレスを指定した場合にのみ発生します。大きな（例：11以上）アンサンブルメンバークラスタをテストのために単一マシンで起動しようとすると、ICMPレート制限（例：macOS）に遭遇した場合、到達可能性チェックが失敗する可能性があります。

  デフォルト値は**true**です。このパラメータを 'false' に設定することで、到達可能性チェックを無効にできます。到達可能性チェックを無効にすると、ネットワークの問題発生時にクラスタが正しく再構成できなくなるため、テスト時のみ無効にすることをお勧めします。

  このパラメータは、multiAddress.enabled=true を設定して MultiAddress 機能を有効にしない限り、効果はありません。

データディレクトリの自動作成の無効化

**3.5の新機能:** ZooKeeperサーバーのデフォルトの動作は、起動時に、指定されたデータディレクトリ（構成ファイルで指定）が存在しない場合に自動的に作成することです。これは、場合によっては不便で危険なこともあります。実行中のサーバーに対して構成変更が行われ、dataDirパラメータが誤って変更された場合を考えてみましょう。ZooKeeperサーバーが再起動されると、この存在しないディレクトリが作成され、空のznode名前空間でサービスが開始されます。このシナリオでは、事実上の「スプリットブレイン」状態（つまり、新しい無効なディレクトリと元の有効なデータストアの両方にデータが存在する状態）が発生する可能性があります。そのため、この自動作成動作をオフにするオプションがあると便利です。一般的に、本番環境ではこれを行う必要がありますが、残念ながら、デフォルトのレガシー動作は現時点では変更できないため、ケースバイケースで実行する必要があります。これは、ユーザーとZooKeeperディストリビューションのパッケージャーに委ねられています。

zkServer.shを実行する際、環境変数ZOO_DATADIR_AUTOCREATE_DISABLEを1に設定することで、自動作成を無効にできます。クラスファイルからZooKeeperサーバーを直接実行する場合は、Javaコマンドラインでzookeeper.datadir.autocreate=falseを設定することで実現できます。つまり、-Dzookeeper.datadir.autocreate=falseです。

この機能が無効になっている場合、ZooKeeperサーバーは必要なディレクトリが存在しないと判断し、エラーを生成して起動を拒否します。

この新機能をサポートするために、新しいスクリプトzkServer-initialize.shが提供されています。自動作成が無効になっている場合は、最初にZooKeeperをインストールし、データディレクトリ（および必要に応じてtxnlogディレクトリ）を作成してから、サーバーを起動する必要があります。そうでない場合、前の段落で述べたように、サーバーは起動しません。zkServer-initialize.shを実行すると、必要なディレクトリが作成され、オプションでmyidファイルが設定されます（オプションのコマンドラインパラメータ）。このスクリプトは、自動作成機能自体が使用されていない場合でも使用でき、ユーザーにとって役立つでしょう（設定、myidファイルの作成を含む）は、過去にユーザーにとって問題となっていました。このスクリプトはデータディレクトリが存在することを確認するだけであり、構成ファイルを作成するのではなく、実行するために構成ファイルが利用可能である必要があります。

db存在検証の有効化

**3.6.0の新機能:** データツリーが見つからない場合のZooKeeperサーバーの起動時のデフォルト動作は、zxidをゼロに設定し、投票メンバーとしてクォーラムに参加することです。サーバーがダウンしている間に何らかのイベント（例：不正な 'rm -rf'）によってデータディレクトリが削除された場合、このサーバーはトランザクションが欠落しているリーダーの選出に役立つ可能性があるため、これは危険な場合があります。DBの存在検証を有効にすると、データツリーが見つからない場合の起動時の動作が変更されます。サーバーは、リーダーと同期してアンサンブルデータの最新バージョンを取得できるようになるまで、非投票参加者としてアンサンブルに参加します。空のデータツリーが期待されている（アンサンブルの作成）ことを示すには、'myid'と同じディレクトリに'initialize'ファイルを作成する必要があります。このファイルは、サーバーによって起動時に検出され、削除されます。

クラスファイルからZooKeeperサーバーを直接実行する場合は、Javaコマンドラインでzookeeper.db.autocreate=falseを設定することで、初期化検証を有効にできます。つまり、-Dzookeeper.db.autocreate=falseです。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コア数です。

• zookeeper.commitProcessor.maxReadBatchSize：（Javaシステムプロパティのみ: **zookeeper.commitProcessor.maxReadBatchSize**）コミットの処理に切り替える前に、queuedRequestsから処理する読み取りの最大数。値が<0（デフォルト）の場合、ローカル書き込みと保留中のコミットがあるたびに切り替えます。読み取りのバッチサイズが大きいと、コミット処理が遅延し、古いデータが提供される原因となります。読み取りが固定サイズのバッチで到着することがわかっている場合、このプロパティの値とバッチサイズを一致させることで、キューのパフォーマンスをスムーズにすることができます。読み取りは並列処理されるため、このプロパティをzookeeper.commitProcessor.numWorkerThread（デフォルトはCPUコア数）と同じかそれ以下の値に設定することをお勧めします。

• zookeeper.commitProcessor.maxCommitBatchSize：（Javaシステムプロパティのみ: **zookeeper.commitProcessor.maxCommitBatchSize**）読み込み処理を開始する前に処理するコミットの最大数。この数に達するまで、可能な限り多くのリモート/ローカルコミットを処理しようとします。コミットのバッチサイズを大きくすると、より多くのコミットを処理する間に読み込みが遅延します。コミットのバッチサイズを小さくすると、読み込みが優先されます。このプロパティを設定するのは、アンサンブルが高コミットレートのワークロードを提供している場合にのみ推奨されます。書き込みが一定数のバッチで到着することがわかっている場合、このプロパティの値とバッチサイズを一致させることで、キューのパフォーマンスを向上させることができます。一般的なアプローチとしては、この値をアンサンブルサイズに等しく設定します。これにより、各バッチの処理ごとに、現在のサーバーは確率的にその直接クライアントの1つに関連する書き込みを処理します。デフォルトは"1"です。負の数とゼロはサポートされていません。

• znode.container.checkIntervalMs：（Javaシステムプロパティのみ）**3.6.0の新機能:**候補コンテナノードとTTLノードをチェックする時間間隔（ミリ秒単位）。デフォルトは"60000"です。

• znode.container.maxPerMinute：（Javaシステムプロパティのみ）**3.6.0の新機能:**1分間に削除できるコンテナノードとTTLノードの最大数。これにより、コンテナ削除中のハーディングを防ぎます。デフォルトは"10000"です。

• znode.container.maxNeverUsedIntervalMs：（Javaシステムプロパティのみ）**3.6.0の新機能:**子ノードを持たないコンテナが保持される最大時間間隔（ミリ秒単位）。クライアントがコンテナを作成し、必要な作業を行い、その後子ノードを作成するのに十分な長さである必要があります。デフォルトは"0"で、子ノードを持たないコンテナは決して削除されないことを示します。

デバッグオブザーバビリティ設定

**3.6.0の新機能:**ZooKeeperのデバッグを容易にするために、以下のオプションが導入されました。

• zookeeper.messageTracker.BufferSize：（Javaシステムプロパティのみ）**MessageTracker**に格納されるメッセージの最大数を制御します。値は正の整数である必要があります。デフォルト値は10です。**MessageTracker**は**3.6.0**で導入され、サーバー（フォロワーまたはオブザーバー）とリーダー間の最後のメッセージセットを記録します（サーバーがリーダーとの接続を切断した場合）。これらのメッセージセットはZooKeeperのログファイルにダンプされ、切断時のサーバーの状態を再構築するのに役立ち、デバッグの目的にも役立ちます。

• zookeeper.messageTracker.Enabled：（Javaシステムプロパティのみ）"true"に設定すると、**MessageTracker**がメッセージの追跡と記録を有効にします。デフォルト値は"false"です。

AdminServer 設定

**3.9.0の新機能:**以下のオプションは、AdminServerの設定に使用されます。

• admin.rateLimiterIntervalInMS：（Javaシステムプロパティ: **zookeeper.admin.rateLimiterIntervalInMS**）サーバーを保護するためのレート制限管理コマンドの時間間隔。デフォルトは5分です。

• admin.snapshot.enabled：（Javaシステムプロパティ: **zookeeper.admin.snapshot.enabled**）スナップショットコマンドを有効にするためのフラグ。デフォルトはtrueです。

• admin.restore.enabled：（Javaシステムプロパティ: **zookeeper.admin.restore.enabled**）リストアコマンドを有効にするためのフラグ。デフォルトはtrueです。

• admin.needClientAuth：（Javaシステムプロパティ: **zookeeper.admin.needClientAuth**）クライアント認証が必要かどうかを制御するフラグ。x509認証を使用するにはtrueが必要です。デフォルトはfalseです。

**3.7.1の新機能:**以下のオプションは、AdminServerの設定に使用されます。

• admin.forceHttps：（Javaシステムプロパティ: **zookeeper.admin.forceHttps**）AdminServerにSSLの使用を強制し、HTTPSトラフィックのみを許可します。デフォルトでは無効です。**admin.portUnification**の設定を上書きします。

**3.6.0の新機能:**以下のオプションは、AdminServerの設定に使用されます。

• admin.portUnification：（Javaシステムプロパティ: **zookeeper.admin.portUnification**）管理ポートでHTTPとHTTPSの両方のトラフィックを受け入れるように有効にします。デフォルトでは無効です。

**3.5.0の新機能:**以下のオプションは、AdminServerの設定に使用されます。

• admin.enableServer：（Javaシステムプロパティ: **zookeeper.admin.enableServer**）AdminServerを無効にするには"false"に設定します。デフォルトでは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"です。

メトリクスプロバイダー

**3.6.0の新機能:**以下のオプションは、メトリクスの設定に使用されます。

デフォルトでは、ZooKeeperサーバーはAdminServerとフォーレターワードインターフェースを使用して、有用なメトリクスを公開します。

3.6.0以降、お好みのシステムにメトリクスをエクスポートする別のメトリクスプロバイダーを設定できます。

3.6.0以降、ZooKeeperバイナリパッケージにはPrometheus.ioとの統合が含まれています。

• metricsProvider.className：Prometheus.ioエクスポーターを有効にするには"org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider"に設定します。

• metricsProvider.httpHost：**3.8.0の新機能:**Prometheus.ioエクスポーターはJettyサーバーを起動し、このアドレスをリスンします。デフォルトは"0.0.0.0"です。

• metricsProvider.httpPort：Prometheus.ioエクスポーターはJettyサーバーを起動し、このポートにバインドします。デフォルトは7000です。Prometheusエンドポイントはhttp://hostname:httPort/metricsになります。

• metricsProvider.exportJvmInfo：このプロパティが**true**に設定されている場合、Prometheus.ioはJVMに関する有用なメトリクスをエクスポートします。デフォルトはtrueです。

• metricsProvider.numWorkerThreads：**3.7.1の新機能:**Prometheusサマリーメトリクスのレポート作成のためのワーカースレッドの数。デフォルト値は1です。数が1未満の場合、メインスレッドが使用されます。

• metricsProvider.maxQueueSize：**3.7.1の新機能:**Prometheusサマリーメトリクスのレポート作成タスクの最大キューサイズ。デフォルト値は1000000です。

• metricsProvider.workerShutdownTimeoutMs：**3.7.1の新機能:**Prometheusワーカースレッドのシャットダウンのタイムアウト（ミリ秒単位）。デフォルト値は1000ミリ秒です。

Netty フレームワークを使用した通信

NettyはNIOベースのクライアント/サーバー通信フレームワークであり、Javaアプリケーションのネットワークレベルの通信の複雑さの多くを簡素化します（NIOを直接使用する場合と比較して）。さらに、Nettyフレームワークには、暗号化（SSL）と認証（証明書）の組み込みサポートがあります。これらはオプション機能であり、個別にオンオフを切り替えることができます。

3.5以降のバージョンでは、環境変数**zookeeper.serverCnxnFactory**を**org.apache.zookeeper.server.NettyServerCnxnFactory**に設定することで、ZooKeeperサーバーはNIO（デフォルトオプション）の代わりにNettyを使用できます。クライアントの場合は、**zookeeper.clientCnxnSocket**を**org.apache.zookeeper.ClientCnxnSocketNetty**に設定します。

クォーラム TLS

3.5.5の新機能

Nettyフレームワークに基づいて、ZooKeeperアンサンブルは通信チャネルでTLS暗号化を使用するように設定できます。このセクションでは、クォーラム通信で暗号化を設定する方法について説明します。

クォーラムTLSは、リーダー選出とクォーラム通信プロトコルの両方のセキュリティをカプセル化することに注意してください。

1. ローカル資格情報を格納するためのSSLキーストアJKSを作成する

各ZKインスタンスごとに1つのキーストアを作成する必要があります。

この例では、自己署名証明書を生成し、秘密キーと共にkeystore.jksに格納します。これはテスト目的には適していますが、本番環境ではキーに署名する正式な証明書が必要になる可能性があります。

エイリアス（-alias）と識別名（-dname）は、関連付けられているマシンのホスト名と一致する必要があることに注意してください。そうでない場合、ホスト名検証は機能しません。

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

1. キーストアから署名済みの公開キー（証明書）を抽出する

この手順は、自己署名証明書の場合にのみ必要になる可能性があります。

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

1. すべてのZooKeeperインスタンスの証明書を含むSSLトラストストアJKSを作成する

同じトラストストア（すべての承認済み証明書を格納）は、アンサンブルの参加者間で共有する必要があります。複数の証明書を同じトラストストアに格納するには、異なるエイリアスを使用する必要があります。エイリアスの名前は重要ではありません。

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

1. NIOではSSLがサポートされていないため、NettyServerCnxnFactoryをserverCnxnFactoryとして使用する必要があります。以下の設定をzoo.cfg設定ファイルに追加します。

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

1. ログで、アンサンブルがTLSで実行されていることを確認します。

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クラスタのダウンタイムなしでのアップグレード

3.5.5の新機能

ポート統合機能を利用して、既に実行されているZooKeeperアンサンブルをダウンタイムなしでTLSにアップグレードするために必要な手順を次に示します。

1. 前のセクションで説明されているように、すべてのZK参加者に対して必要なキーストアとトラストストアを作成します。

2. 以下の設定を追加し、最初のノードを再起動します。

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はまだ有効になっていませんが、ポート統合を有効にします。

1. 残りのノードで手順2を繰り返します。ログに以下のエントリが表示されることを確認します。

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

各ノードの再起動後、クォーラムが再び正常になることを二重に確認する必要があります。

1. 各ノードでクォーラムTLSを有効にし、ローリング再起動を実行します。

sslQuorum=true
portUnification=true

1. アンサンブル全体がTLSで実行されていることを確認したら、ポート統合を無効にして、別のローリング再起動を実行できます。

sslQuorum=true
portUnification=false

ZooKeeperコマンド

4文字の単語

ZooKeeperは、少数のコマンドに応答します。各コマンドは4文字で構成されます。クライアントポートでtelnetまたはncを介してZooKeeperにコマンドを発行します。

より興味深い3つのコマンド：「stat」はサーバーと接続されたクライアントに関する一般的な情報を提供し、「srvr」と「cons」はそれぞれサーバーと接続に関する詳細な情報を提供します。

**3.5.3の新機能:**フォーレターワードを使用する前に、明示的にホワイトリストに登録する必要があります。詳細については、クラスター設定セクションで説明されている4lw.commands.whitelistを参照してください。今後、フォーレターワードは非推奨となり、代わりにAdminServerを使用してください。

• conf：**3.3.0の新機能:**提供されている設定に関する詳細情報を表示します。

• cons：**3.3.0の新機能:**このサーバーに接続されているすべてのクライアントの完全な接続/セッションの詳細をリストします。受信/送信されたパケットの数、セッションID、操作の待ち時間、最後に実行された操作などの情報が含まれます。

• crst：**3.3.0の新機能:**すべての接続の接続/セッション統計をリセットします。

• dump：保留中のセッションと一時ノードをリストします。

• envi：提供されている環境に関する詳細情報を表示します。

• ruok：サーバーがエラー状態ではないかどうかをテストします。ホワイトリストがruokを有効にしている場合、サーバーは実行されている場合はimokで応答し、それ以外の場合はまったく応答しません。ruokが無効になっている場合、サーバーは「ruokはホワイトリストにないため実行されません。」と応答します。「imok」の応答は、サーバーがクォーラムに参加したことを必ずしも示しているわけではなく、サーバープロセスがアクティブであり、指定されたクライアントポートにバインドされていることを示しているだけです。クォーラムとクライアント接続情報に関する状態の詳細については、「stat」を使用してください。

• srst：サーバー統計をリセットします。

• srvr：**3.3.0の新機能:**サーバーの完全な詳細をリストします。

• stat：サーバーと接続されたクライアントの簡単な詳細をリストします。

• wchs：**3.3.0の新機能:**サーバーのウォッチに関する簡単な情報をリストします。

• wchc：**3.3.0の新機能:**セッション別にサーバーのウォッチに関する詳細情報をリストします。これは、関連付けられたウォッチ（パス）を持つセッション（接続）のリストを出力します。ウォッチの数によっては、この操作はコストがかかる可能性がある（つまり、サーバーのパフォーマンスに影響を与える）ため、注意して使用してください。

• dirs : 3.5.1の新機能: スナップショットファイルとログファイルの合計サイズをバイト単位で表示します。

• wchp : 3.3.0の新機能: サーバーのウォッチに関する詳細情報をパス別に一覧表示します。パス（znode）と関連付けられたセッションの一覧を出力します。ウォッチの数によっては、この操作は負荷が高く（つまり、サーバーのパフォーマンスに影響を与える可能性があります）、注意して使用してください。

• mntr : 3.4.0の新機能: クラスタの健全性を監視するために使用できる変数のリストを出力します。

  $ echo mntr | nc localhost 2185 zk_version 3.4.0 zk_avg_latency 0.7561 - 小数点以下4桁 zk_max_latency 0 zk_min_latency 0 zk_packets_received 70 zk_packets_sent 69 zk_outstanding_requests 0 zk_server_state leader 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プロパティ形式と互換性があり、内容は時間の経過とともに変更される可能性があります（新しいキーが追加される場合があります）。スクリプトでは変更を想定する必要があります。注意：一部のキーはプラットフォーム固有であり、一部のキーはリーダーのみがエクスポートします。出力は次の形式の複数行を含みます。

key \t value

• isro : 3.4.0の新機能: サーバーが読み取り専用モードで実行されているかどうかをテストします。サーバーは、読み取り専用モードの場合は "ro"、読み取り専用モードでない場合は "rw" を返します。

• hash : 3.6.0の新機能: zxidに関連付けられたツリーダイジェストの最新の履歴を返します。

• gtmk : 現在のトレースマスクを10進形式の64ビット符号付きlong値として取得します。可能な値の説明については、stmkを参照してください。

• stmk : 現在のトレースマスクを設定します。トレースマスクは64ビットで、各ビットはサーバー上の特定のカテゴリのトレースログを有効または無効にします。トレースログメッセージを表示するには、まずLogbackでTRACEレベルを有効にする必要があります。トレースマスクのビットは、次のトレースログカテゴリに対応します。

  トレースマスクビット値
  0b0000000000	未使用、将来の使用のために予約されています。
  0b0000000010	ping要求を除くクライアント要求をログに記録します。
  0b0000000100	未使用、将来の使用のために予約されています。
  0b0000001000	クライアントのping要求をログに記録します。
  0b0000010000	ping要求を除く、現在のリーダーであるクォーラムピアから受信したパケットをログに記録します。
  0b0000100000	クライアントセッションの追加、削除、および検証をログに記録します。
  0b0001000000	クライアントセッションへのウォッチイベントの配信をログに記録します。
  0b0010000000	現在のリーダーであるクォーラムピアから受信したpingパケットをログに記録します。
  0b0100000000	未使用、将来の使用のために予約されています。
  0b1000000000	未使用、将来の使用のために予約されています。

  64ビット値の残りのビットはすべて未使用であり、将来の使用のために予約されています。複数のトレースログカテゴリは、文書化された値のビットごとのORを計算することで指定されます。デフォルトのトレースマスクは0b0100110010です。したがって、デフォルトでは、トレースログにはクライアント要求、リーダーから受信したパケット、セッションが含まれます。異なるトレースマスクを設定するには、stmkの4文字の単語と、64ビット符号付きlong値として表されたトレースマスクを含む要求を送信します。この例では、Perlのpack関数を使用して、上記のすべてのトレースログカテゴリを有効にするトレースマスクを作成し、ビッグエンディアンバイトオーダーで64ビット符号付きlong値に変換します。結果はstmkに追加され、netcatを使用してサーバーに送信されます。サーバーは、新しいトレースマスクを10進形式で返します。

  $ 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は、4文字の単語コマンドにHTTPインターフェースを提供する組み込みJettyサーバーです。デフォルトでは、サーバーはポート8080で起動され、URL "/commands/[コマンド名]"にアクセスすることでコマンドが発行されます（例：http://localhost:8080/commands/stat）。コマンド応答はJSONとして返されます。元のプロトコルとは異なり、コマンドは4文字の名前に制限されず、コマンドは複数名を持つことができます。たとえば、「stmk」は「set_trace_mask」とも呼ばれます。使用可能なすべてのコマンドの一覧を表示するには、ブラウザをURL /commandsにポイントします（例：http://localhost:8080/commands）。ポートとURLの変更方法については、AdminServer構成オプションを参照してください。

AdminServerはデフォルトで有効になっていますが、次のいずれかの方法で無効にすることができます。

• zookeeper.admin.enableServerシステムプロパティをfalseに設定します。
• クラスパスからJettyを削除します。（このオプションは、ZooKeeperのJetty依存関係をオーバーライドする場合に役立ちます。）

AdminServerが無効になっている場合でも、TCPの4文字の単語インターフェースは引き続き使用できます。

使用可能なコマンドには以下が含まれます。

• connection_stat_reset/crst: すべてのクライアント接続統計をリセットします。新しいフィールドは返されません。

• configuration/conf/config : サービング構成に関する基本的な詳細（例：クライアントポート、データディレクトリへの絶対パス）を出力します。

• connections/cons : サーバーへのクライアント接続に関する情報。クライアント接続の数によっては、この操作は負荷が高くなる可能性があります（つまり、サーバーのパフォーマンスに影響を与える可能性があります）。"connections"、接続情報のオブジェクトのリストを返します。

• hash: 履歴ダイジェストリスト内のトランザクションダイジェスト。128トランザクションごとに1つが記録されます。"digests"、トランザクションダイジェストオブジェクトのリストを返します。

• dirs : ログファイルディレクトリとスナップショットディレクトリのサイズをバイト単位で表示します。"datadir_size"と"logdir_size"を返します。

• dump : セッションの期限切れとephemeralに関する情報。グローバルセッションとephemeralの数によっては、この操作は負荷が高くなる可能性があります（つまり、サーバーのパフォーマンスに影響を与える可能性があります）。"expiry_time_to_session_ids"と"session_id_to_ephemeral_paths"をマップとして返します。

• environment/env/envi : 定義されているすべての環境変数。それぞれを独自のフィールドとして返します。

• get_trace_mask/gtmk : 現在のトレースマスク。set_trace_maskの読み取り専用バージョン。詳細については、4文字のコマンドstmkの説明を参照してください。"tracemask"を返します。

• initial_configuration/icfg : ピアを起動するために使用された構成ファイルのテキストを出力します。"initial_configuration"を返します。

• is_read_only/isro : このサーバーが読み取り専用モードかどうかを示す真偽値。 "read_only"を返します。

• last_snapshot/lsnp : ZooKeeperサーバーがディスクへの保存を完了した最後のスナップショットの情報。サーバーの起動と最初のスナップショットの保存完了の間の初期期間中に呼び出された場合、このコマンドはサーバーの起動時に読み込まれたスナップショットの情報を返します。"zxid"と"timestamp"を返し、後者は秒単位の時間単位を使用します。

• leader/lead : アンサンブルがクォーラムモードで構成されている場合、ピアの現在のリーダーの状態と現在のリーダーの場所を出力します。"is_leader"、"leader_id"、および"leader_ip"を返します。

• monitor/mntr : 監視に役立つさまざまな情報を大量に出力します。パフォーマンス統計、内部キューに関する情報、データツリーのサマリー（その他）が含まれます。それぞれを独自のフィールドとして返します。

• observer_connection_stat_reset/orst : すべてのオブザーバー接続統計をリセットします。observersの仲間コマンド。新しいフィールドは返されません。

• restore/rest : 現在のサーバー上のスナップショット入力ストリームからデータベースを復元します。応答ペイロードに次のデータが含まれます。"last_zxid": String 注：このAPIは、サーバーの過負荷を防ぐために（デフォルトで5分ごとに1回）レート制限されています。

• ruok : 何もしないコマンド。サーバーが実行中かどうかをチェックします。応答は必ずしもサーバーがクォーラムに参加していることを示すものではなく、管理サーバーがアクティブであり、指定されたポートにバインドされていることを示すだけです。新しいフィールドは返されません。

• set_trace_mask/stmk : トレースマスクを設定します（そのため、パラメーターが必要です）。get_trace_maskの書き込みバージョン。詳細については、4文字のコマンドstmkの説明を参照してください。"tracemask"を返します。

• server_stats/srvr : サーバー情報。サーバーの状態の概要を示す複数のフィールドを返します。

• snapshot/snap : datadirに現在のサーバーのスナップショットを作成し、データをストリーミング出力します。オプションのクエリパラメーター："streaming": Boolean（パラメーターが存在しない場合、trueがデフォルト） HTTPヘッダーを介して次を返します："last_zxid": String "snapshot_size": String 注：このAPIは、サーバーの過負荷を防ぐために（デフォルトで5分ごとに1回）レート制限されています。

• stats/stat : server_statsと同じですが、"connections"フィールドも返します（詳細についてはconnectionsを参照）。クライアント接続の数によっては、この操作は負荷が高くなる可能性があります（つまり、サーバーのパフォーマンスに影響を与える可能性があります）。

• stat_reset/srst : サーバー統計をリセットします。これは、server_statsとstatsによって返される情報のサブセットです。新しいフィールドは返されません。

• observers/obsr : サーバーへのオブザーバー接続に関する情報。リーダーでは常に使用可能で、フォロワーがラーナーマスターとして機能している場合はフォロワーでも使用可能です。"synced_observers"（int）と"observers"（オブザーバーごとのプロパティのリスト）を返します。

• system_properties/sysp : 定義されているすべてのシステムプロパティ。それぞれを独自のフィールドとして返します。

• voting_view : アンサンブル内の現在の投票メンバーを提供します。"current_config"をマップとして返します。

• watches/wchc : セッション別に集計されたウォッチ情報。ウォッチの数によっては、この操作は負荷が高くなる可能性があります（つまり、サーバーのパフォーマンスに影響を与える可能性があります）。"session_id_to_watched_paths"をマップとして返します。

• watches_by_path/wchp : パス別に集計されたウォッチ情報。ウォッチの数によっては、この操作は負荷が高くなる可能性があります（つまり、サーバーのパフォーマンスに影響を与える可能性があります）。"path_to_session_ids"をマップとして返します。

• watch_summary/wchs : 要約されたウォッチ情報。"num_total_watches"、"num_paths"、および"num_connections"を返します。

• zabstate : ピアが実行しているZabプロトコルの現在のフェーズと、それが投票メンバーかどうか。ピアは、ELECTION、DISCOVERY、SYNCHRONIZATION、BROADCASTのいずれかのフェーズになる可能性があります。"voting"と"zabstate"のフィールドを返します。

データファイル管理

ZooKeeperはデータをデータディレクトリに、トランザクションログをトランザクションログディレクトリに保存します。デフォルトでは、これら2つのディレクトリは同じです。サーバは、データファイルとは別のディレクトリにトランザクションログファイルを保存するように設定できます（そして、そうするべきです）。トランザクションログが専用のログデバイスに存在する場合、スループットは向上し、レイテンシは低下します。

データディレクトリ

このディレクトリには、2つまたは3つのファイルが含まれています。

• myid - サーバIDを表す、人間が読み取れるASCIIテキストで記述された単一の整数が含まれています。
• initialize - データツリーが存在しないことを示します。データツリーが作成されると削除されます。
• snapshot. - データツリーのファジィスナップショットを保持します。

各ZooKeeperサーバには、一意のIDがあります。このIDは、myidファイルと設定ファイルの2つの場所で使用されます。myidファイルは、特定のデータディレクトリに対応するサーバを識別します。設定ファイルには、サーバIDで識別される各サーバの連絡先情報がリストされています。ZooKeeperサーバインスタンスが起動すると、myidファイルからIDを読み取り、そのIDを使用して設定ファイルから読み取り、リスンするポートを調べます。

データディレクトリに保存されているsnapshotファイルは、ZooKeeperサーバがスナップショットを作成している間にデータツリーへの更新が行われているため、ファジィスナップショットです。snapshotファイル名のサフィックスは、スナップショット開始時の最後のコミットされたトランザクションのZooKeeperトランザクションIDであるzxidです。したがって、スナップショットには、スナップショット処理中に発生したデータツリーへの更新の一部が含まれています。そのため、スナップショットは実際に存在したデータツリーと一致しない可能性があり、このためファジィスナップショットと呼びます。それでも、ZooKeeperは更新のべき等性を利用するため、このスナップショットを使用して復旧できます。ファジィスナップショットに対してトランザクションログを再生することにより、ZooKeeperはログの末尾のシステムの状態を取得します。

ログディレクトリ

ログディレクトリには、ZooKeeperトランザクションログが含まれています。更新が行われる前に、ZooKeeperは、更新を表すトランザクションが不揮発性ストレージに書き込まれることを確認します。現在のログファイルに書き込まれたトランザクション数が（可変の）しきい値に達すると、新しいログファイルが開始されます。しきい値は、スナップショットの頻度にも影響するパラメータ（上記のsnapCountとsnapSizeLimitInKbを参照）を使用して計算されます。ログファイルのサフィックスは、そのログに最初に書き込まれたzxidです。

ファイル管理

スナップショットファイルとログファイルの形式は、スタンドアロンZooKeeperサーバとレプリケートされたZooKeeperサーバの異なる構成間で変化しません。したがって、これらのファイルを稼働中のレプリケートされたZooKeeperサーバから、スタンドアロンZooKeeperサーバのある開発マシンにプルして、トラブルシューティングを行うことができます。

古いログファイルとスナップショットファイルを使用すると、ZooKeeperサーバの以前の状態を確認し、その状態を復元することもできます。

ZooKeeperサーバはスナップショットファイルとログファイルを作成しますが、削除することはありません。データファイルとログファイルの保持ポリシーは、ZooKeeperサーバの外部で実装されます。サーバ自体に必要なのは、最新の完全なファジィスナップショット、それに続くすべてのログファイル、およびその前の最後のログファイルだけです。後者の要件は、このスナップショットが開始された後に発生したが、その時点で既存のログファイルに書き込まれた更新を含めるために必要です。これは、スナップショットとログのロールオーバーがZooKeeperで多少独立して進むため可能です。ZooKeeperストレージの保持ポリシーとメンテナンスの設定の詳細については、このドキュメントのメンテナンスセクションを参照してください。

注記

これらのファイルに保存されているデータは暗号化されていません。ZooKeeperに機密データを保存する場合は、不正アクセスを防ぐための必要な対策を講じる必要があります。そのような対策はZooKeeperの外部（例：ファイルへのアクセスの制御）であり、それが展開されている個々の設定によって異なります。

リカバリ - TxnLogToolkit

詳細はこちらをご覧ください。

避けるべきこと

ZooKeeperを正しく設定することで回避できる一般的な問題をいくつか紹介します。

• サーバリストの不一致：クライアントで使用されるZooKeeperサーバのリストは、各ZooKeeperサーバが持つZooKeeperサーバのリストと一致する必要があります。クライアントリストが実際のリストのサブセットである場合は問題なく動作しますが、クライアントが異なるZooKeeperクラスタにあるZooKeeperサーバのリストを持つ場合、非常に奇妙な動作になります。また、各ZooKeeperサーバの設定ファイル内のサーバリストは互いに一致する必要があります。

• トランザクションログの配置が不適切：ZooKeeperで最もパフォーマンスが重要なのはトランザクションログです。ZooKeeperは、応答を返す前にトランザクションをメディアに同期します。専用のトランザクションログデバイスは、一貫した良好なパフォーマンスの鍵となります。ログをビジーなデバイスに配置すると、パフォーマンスに悪影響を及ぼします。ストレージデバイスが1つしかない場合は、snapCountを増やしてスナップショットファイルが生成される頻度を減らします。これにより問題は解消されませんが、トランザクションログにより多くのリソースを使用できるようになります。

• Javaヒープサイズが不適切：Javaの最大ヒープサイズを正しく設定することに特に注意する必要があります。特に、ZooKeeperがディスクにスワップするような状況を作成しないでください。ディスクはZooKeeperにとって致命的です。すべてが順序付けられているため、1つのリクエストの処理でディスクがスワップされると、キューに入れられた他のすべてのリクエストも同様になる可能性が高いです。ディスクを使用しないでください。推定値は控えめにしてください。4GBのRAMがある場合、Javaの最大ヒープサイズを6GBまたは4GBに設定しないでください。たとえば、オペレーティングシステムとキャッシュにもメモリが必要なため、4GBのマシンでは3GBのヒープを使用する可能性が高くなります。システムに必要なヒープサイズを推定するための最善の方法、そして唯一推奨される方法は、負荷テストを実行し、システムがスワップを引き起こす使用制限を十分に下回っていることを確認することです。

• 公開アクセス可能な展開：ZooKeeperアンサンブルは、信頼できるコンピューティング環境で動作することが期待されています。したがって、ファイアウォールの背後にZooKeeperを展開することをお勧めします。

ベストプラクティス

最適な結果を得るには、次のZooKeeperのベストプラクティスに注意してください。

マルチテナントインストールについては、ZooKeeperの「chroot」サポートについて詳しく説明しているセクションを参照してください。これは、単一のZooKeeperクラスタにインターフェースする多くのアプリケーション/サービスを展開する場合に非常に役立ちます。