ZooKeeper 管理者ガイド

導入と管理ガイド

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

導入

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

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

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

システム要件

サポートされているプラットフォーム

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

• クライアント は、アプリケーションが ZooKeeper アンサンブルに接続するために使用する Java クライアントライブラリです。
• サーバー は、ZooKeeper アンサンブルノードで実行される Java サーバーです。
• ネイティブクライアント は、Java クライアントと同様の C で実装されたクライアントであり、アプリケーションが ZooKeeper アンサンブルに接続するために使用されます。
• 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 は 1 台のマシンの障害のみを処理できます。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 が奇数であれば、アンサンブルは最大 N/2 台のサーバー障害に耐えることができます（znode データの損失はありません）。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のデータディレクトリには、特定のサービングアンサンブルによって格納されたznodesの永続的なコピーであるファイルが含まれています。これらは、スナップショットファイルとトランザクションログファイルです。znodesに変更が加えられると、これらの変更はトランザクションログに追加されます。ログが大きくなると、znodesの現在の状態のスナップショットがファイルシステムに書き込まれ、今後のトランザクションのために新しいトランザクションログファイルが作成されます。スナップショット作成中は、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接続のポートを指定します。両方とも指定すると混合モードが有効になり、いずれか一方を省略するとそのモードが無効になります。ユーザーがzookeeper.serverCnxnFactory、zookeeper.clientCnxnSocketをNettyとしてプラグインすると、SSL機能が有効になります。

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

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

  注記

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

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

高度な設定

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

• 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）です。正でない値を設定すると、この機能は無効になります。

• 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になります。

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

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

  ハッシュ関数の実装には内部的にCRCを使用しています。これは衝突耐性のあるハッシュ関数ではありませんが、衝突耐性のあるハッシュ関数と比べて効率が高く、衝突の可能性は非常に低いため、本用途の要件を満たしています。

  この機能は下位互換性および上位互換性を備えているため、安全にロールアップグレード、ダウングレード、有効化、無効化を行うことができます。互換性の問題は発生しません。以下に、テスト済みのシナリオを示します。

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

  注記：`/zookeeper`以下のノードは、`/zookeeper/quota`統計ノードの潜在的な不整合のため、現在のダイジェスト計算には含まれていません。この問題が解決された後に含めることができます。

  この機能はデフォルトで有効になっています。"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（Javaシステムプロパティ：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サーバーのリストと一致する必要があります。ポート番号nnnnnが2つあります。最初のフォロワーがリーダーに接続するために使用し、2番目はリーダー選出に使用します。単一マシンで複数のサーバーをテストする場合は、各サーバーに異なるポートを使用できます。

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

  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サーバー間プロトコル）が変更されます。ユーザーはこれを認識せず、新しい設定で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の新機能: ユーザーが使用したいフォーレターワードコマンドのコンマ区切りリスト。有効なフォーレターワードコマンドはこのリストに含める必要があります。そうでない場合、ZooKeeperサーバーはそのコマンドを有効にしません。デフォルトでは、ホワイトリストにはzkServer.shが使用する"srvr"コマンドのみが含まれています。その他のフォーレターワードコマンドはデフォルトで無効になっています。使用しようとすると、「.... is not executed because it is not in the whitelist.」という応答が返されます。stat、ruok、conf、isroコマンドを有効にし、その他のフォーレターワードコマンドを無効にする設定の例を次に示します。

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

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

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です。この機能を有効にする場合は、leader.closeSocketAsyncとlearner.closeSocketAsyncも有効にすることを検討してください。SSL接続のシャットダウン時にソケットの閉じ時間が長くなる可能性があることに関連する問題を回避するためです。

• 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ネゴシエーションで使用されるプロトコルを指定します。デフォルト：使用されているJavaランタイムバージョンに応じてTLSv1.3またはTLSv1.2。

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

• 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プロトコルで証明書失効リスト（CRL）が有効かどうかを指定します。デフォルト：false

• ssl.ocsp および ssl.quorum.ocsp：（Java システムプロパティ：zookeeper.ssl.ocsp および zookeeper.ssl.quorum.ocsp）3.5.5 新機能: クライアントとクォーラムのTLSプロトコルでOCSP（Online Certificate Status Protocol）が有効かどうかを指定します。デフォルト：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）オブザーバーマスターに接続されたオブザーバーを含むクラスタの場合、このフラグをオンにすると、オブザーバーマスターのメモリ圧力を軽減できる可能性があります。クラスタにオブザーバーがいない場合、またはオブザーバーマスターに接続されていない場合、またはオブザーバーがほとんど書き込みを行わない場合は、このフラグを使用しても効果はありません。現在、この変更はフラグによって保護されており、メモリゲインに関する信頼性を高めるのに役立っています。長期的に見ると、このフラグを削除し、その動作をデフォルトのコードパスとして設定したいと考えています。

危険なオプション

次のオプションは役立つ場合がありますが、使用するときは注意してください。それぞれのリスクは、変数の機能の説明とともに説明されています。

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

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

  • このオプションは、Java システムプロパティとしてのみ設定できます。zookeeper プレフィックスはありません。znode に格納できるデータの最大サイズを指定します。単位はバイトです。デフォルトは 0xfffff（1048575）バイト、つまり約 1MB です。
  • このオプションを変更する場合は、問題が発生しないように、すべてのサーバーとクライアントでシステムプロパティを設定する必要があります。
  • クライアント側の 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」です。負の値とゼロの値はサポートされていません。

• 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. SSLはNIOではサポートされていないため、serverCnxnFactoryとしてNettyServerCnxnFactoryを使用する必要があります。以下の設定を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の新機能：4文字コマンドを使用する前に、明示的にホワイトリストに登録する必要があります。詳細は、クラスタ設定セクションで説明されている4lw.commands.whitelistを参照してください。 今後は、4文字コマンドは非推奨となり、代わりにAdminServerを使用してください。

• conf：3.3.0の新機能：サービス設定に関する詳細を出力します。

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

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

• dump：未処理のセッションと一時ノードを一覧表示します。

• envi：サービス環境に関する詳細を出力します。

• ruok：サーバーがエラー状態ではないかテストします。ホワイトリストでruokが有効になっている場合、サーバーは実行中であればimokで応答し、そうでない場合は応答しません。ruokが無効になっている場合、サーバーは「ruok is not executed because it is not in the whitelist.」と応答します。「imok」の応答は、サーバーがクォーラムに参加したことを必ずしも示しているわけではなく、サーバープロセスがアクティブであり、指定されたクライアントポートにバインドされていることを示しているだけです。クォーラムとクライアント接続情報に関する状態の詳細については、「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 | 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ビット符号付きロング値として取得します。可能な値の説明については、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ビット符号付きロング値として表されたトレースマスクを含むリクエストを送信します。この例では、Perlのpack関数を使用して、上記で説明されているすべてのトレースログカテゴリを有効にするトレースマスクを作成し、ビッグエンディアンバイトオーダーで64ビット符号付きロング値に変換します。結果は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/[command name]"にアクセスすることでコマンドが発行されます（例：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文字コマンドインターフェースは引き続き使用できます。

SSL/TLSのAdminServerの設定

• クォーラムTLSにあるkeystore.jksとtruststore.jksを生成します。
• zoo.cfg設定ファイルに次の設定を追加します。

admin.portUnification=true
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

• ログに次のエントリが表示されることを確認します。

2019-08-03 15:44:55,213 [myid:] - INFO  [main:JettyAdminServer@123] - Successfully loaded private key from /data/software/cert/keystore.jks
2019-08-03 15:44:55,213 [myid:] - INFO  [main:JettyAdminServer@124] - Successfully loaded certificate authority from /data/software/cert/truststore.jks

2019-08-03 15:44:55,403 [myid:] - INFO  [main:JettyAdminServer@170] - Started AdminServer on address 0.0.0.0, port 8080 and command URL /commands

使用可能なコマンドには、次のものがあります。

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

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

• connections/cons：サーバーへのクライアント接続に関する情報。クライアント接続の数によっては、この操作は高コストになる可能性がある（つまり、サーバーのパフォーマンスに影響を与える）ことに注意してください。「connections」を返し、接続情報のオブジェクトのリストが含まれます。

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

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

• dump：セッションの期限切れと一時的なものに関する情報。グローバルセッションと一時的なものの数によっては、この操作は高コストになる可能性がある（つまり、サーバーのパフォーマンスに影響を与える）ことに注意してください。「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」：文字列 注：サーバーへの過負荷を防ぐため、このAPIはレート制限されています（デフォルトでは5分間に1回）。

• ruok：ノーオペレーションコマンド。サーバーが実行中かどうかを確認します。レスポンスが返されたとしても、サーバーがクォーラムに参加していることを必ずしも示すわけではなく、管理サーバーがアクティブで、指定されたポートにバインドされていることを示すだけです。新しいフィールドは返されません。

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

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

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

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

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

• observers/obsr：サーバーへのオブザーバー接続に関する情報。リーダーでは常に使用可能で、フォロワーがラーナーマスターとして機能している場合に使用可能です。「synced_observers」（整数）と「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.<zxid> - データツリーのファジースナップショットを保持します。

各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クラスタとインターフェースする多くのアプリケーション/サービスを展開する場合に非常に役立ちます。