Apache > ZooKeeper
 
 

ZooKeeper 管理員指南

部署與管理指南

部署

此區段包含有關部署 Zookeeper 的資訊，並涵蓋下列主題

前兩個區段假設您有興趣在生產環境（例如資料中心）中安裝 ZooKeeper。最後一個區段涵蓋您在有限的基礎上設定 ZooKeeper 的情況 - 評估、測試或開發 - 但不在生產環境中。

系統需求

支援的平台

ZooKeeper 包含多個元件。有些元件廣泛受到支援，而其他元件僅在較小的平台組上受到支援。

下表說明在不同作業系統平台上執行各個元件時所承諾的支援層級。

支援矩陣
作業系統 用戶端 伺服器 原生用戶端 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 伺服器的叢集方式執行。三個 ZooKeeper 伺服器是叢集建議的最小規模，我們也建議它們執行於不同的機器上。在 Yahoo! 中，ZooKeeper 通常部署於專用的 RHEL 機器上，配備雙核心處理器、2GB RAM 和 80GB IDE 硬碟。

叢集式（多伺服器）設定

對於可靠的 ZooKeeper 服務，您應該將 ZooKeeper 部署於稱為叢集的群集中。只要叢集中的大多數伺服器都運作，服務就會可用。由於 Zookeeper 需要大多數，最好使用奇數台機器。例如，使用四台機器時，ZooKeeper 只能處理一台機器的故障；如果兩台機器故障，剩餘的兩台機器不構成大多數。然而，使用五台機器時，ZooKeeper 可以處理兩台機器的故障。

注意

正如 ZooKeeper 入門指南 中所述，容錯叢集設定至少需要三台伺服器，強烈建議您使用奇數台伺服器。

通常三台伺服器對於生產安裝來說已經綽綽有餘，但為了在維護期間達到最大的可靠性，您可能希望安裝五台伺服器。使用三台伺服器時，如果您對其中一台伺服器執行維護，您會在維護期間面臨另一台伺服器故障的風險。如果您執行五台伺服器，您可以關閉一台伺服器進行維護，並知道如果其他四台伺服器之一突然故障，您仍然沒問題。

您的備援考量應包含環境的所有面向。如果您有三個 ZooKeeper 伺服器，但它們的網路纜線都插入同一個網路交換器，那麼該交換器的故障將會導致您的整個叢集停擺。

以下是如何設定將成為叢集一部分的伺服器的步驟。這些步驟應在叢集中的每一個主機上執行

  1. 安裝 Java JDK。您可以使用系統的原生封裝系統，或從以下位置下載 JDK：http://java.sun.com/javase/downloads/index.jsp

  2. 設定 Java 堆積大小。這對於避免換頁非常重要，換頁會嚴重降低 ZooKeeper 的效能。若要確定正確的值，請使用負載測試，並確保您遠低於會導致換頁的用量限制。保守一點 - 對於 4GB 的機器，使用 3GB 的最大堆積大小。

  3. 安裝 ZooKeeper 伺服器套件。它可以從以下位置下載：https://zookeeper.dev.org.tw/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 伺服器實例 指定多個位址 (當叢集中可以並行使用多個實體網路介面時，這可以提高可用性)。您可以透過建立一個名為 myid 的檔案，一個檔案對應一部伺服器，並將其儲存在該伺服器的資料目錄中，如設定檔參數 dataDir 所指定，來將伺服器 ID 歸因於每部機器。

  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 的可靠性建立在兩個基本假設上。

  1. 部署中只有少數伺服器會發生故障。在此情況下，「故障」表示機器崩潰，或網路中某些錯誤將伺服器與大多數伺服器隔離。
  2. 已部署的機器正常運作。正常運作表示正確執行程式碼、時鐘正常運作，以及儲存和網路元件持續執行。

下列部分包含 ZooKeeper 管理員應考量的因素，以最大化這些假設為真的機率。其中一些是跨機器考量，而其他則是您應考量部署中每部機器的因素。

跨機器需求

若要讓 ZooKeeper 服務保持作用中，必須有大多數未發生故障的機器可以彼此通訊。對於具有 N 個伺服器的 ZooKeeper 群組，如果 N 為奇數，則群組可以容忍多達 N/2 個伺服器故障，而不會遺失任何 znode 資料；如果 N 為偶數，則群組可以容忍多達 N/2-1 個伺服器故障。

例如，如果我們有一個具有 3 個伺服器的 ZooKeeper 群組，則群組可以容忍多達 1 (3/2) 個伺服器故障。如果我們有一個具有 5 個伺服器的 ZooKeeper 群組，則群組可以容忍多達 2 (5/2) 個伺服器故障。如果 ZooKeeper 群組具有 6 個伺服器，則群組也可以容忍多達 2 (6/2-1) 個伺服器故障，而不會遺失資料並防止「腦裂」問題。

ZooKeeper 群組通常具有奇數個伺服器。這是因為對於偶數個伺服器，容錯容量與伺服器少一個的群組相同（5 節點群組和 6 節點群組都為 2 個故障），但群組必須為另一個伺服器維護額外的連線和資料傳輸。

若要達成容忍故障的最高機率，您應嘗試讓機器故障保持獨立。例如，如果大多數機器共用同一個交換器，則該交換器故障可能會導致相關故障並中斷服務。共用電源電路、冷卻系統等也是如此。

單一機器需求

如果 ZooKeeper 必須與其他應用程式競爭存取資源（例如儲存媒體、CPU、網路或記憶體），其效能將會明顯下降。ZooKeeper 有強大的耐用性保證，這表示它會在負責變更的作業完成之前，使用儲存媒體來記錄變更。因此，您應該注意這個依賴關係，如果您想要確保 ZooKeeper 作業不會被您的媒體延誤，請特別小心。以下是一些您可以執行的動作，以將這種劣化降到最低

提供

需要考量的事項：ZooKeeper 的優點與限制

管理

維護

ZooKeeper 集群只需要很少的長期維護，但您必須注意以下事項

持續的資料目錄清理

ZooKeeper 資料目錄 包含檔案，這些檔案是特定服務組儲存的 znode 的持續性副本。這些是快照和交易記錄檔案。當對 znode 進行變更時，這些變更會附加到交易記錄。偶爾，當記錄變大時，所有 znode 的目前狀態快照會寫入檔案系統，並為未來的交易建立新的交易記錄檔案。在快照期間，ZooKeeper 可能會持續將輸入的交易附加到舊的記錄檔案。因此，某些比快照新的交易可能會出現在快照之前的最後一個交易記錄中。

使用預設組態時，ZooKeeper 伺服器不會移除舊的快照和記錄檔案（請參閱下方的自動清除），這是操作員的責任。每個服務環境都不同，因此管理這些檔案的要求可能會因安裝而異（例如備份）。

PurgeTxnLog 程式實作一個簡單的保留原則，管理員可以使用它。API 文件 包含有關呼叫慣例（引數等）的詳細資料。

在以下範例中，保留最後計數的快照及其對應的記錄，並刪除其他快照。 的值通常應該大於 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 等監督程序 (還有其他監督程序選項可供使用，您可以選擇您想使用的選項，這只是兩個範例) 來管理您的 ZooKeeper 伺服器，可確保如果程序異常退出，它會自動重新啟動並快速重新加入叢集。

也建議將 ZooKeeper 伺服器程序組態為在發生 OutOfMemoryError** 時終止並傾印其堆積。這可透過在 Linux 和 Windows 分別使用下列參數啟動 JVM 來達成。隨 ZooKeeper 附帶的 zkServer.sh 和 zkServer.cmd 腳本會設定這些選項。

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

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

監控

ZooKeeper 服務可以用三種主要方式之一來監控

記錄

ZooKeeper 使用 SLF4J 版本 1.7 作為其記錄基礎架構。預設情況下，ZooKeeper 會隨附 LOGBack 作為記錄後端，但您可以使用您選擇的任何其他支援的記錄架構。

ZooKeeper 預設的 logback.xml 檔案位於 conf 目錄中。Logback 要求 logback.xml 位於工作目錄 (執行 ZooKeeper 的目錄) 中或可從類別路徑存取。

如需進一步了解 SLF4J，請參閱 其手冊。

如需進一步了解 Logback，請參閱 Logback 網站。

疑難排解

設定參數

ZooKeeper 的行為由 ZooKeeper 組態檔所管理。此檔案的設計方式，讓組成 ZooKeeper 伺服器的所有伺服器都能使用完全相同的檔案，假設磁碟配置相同。如果伺服器使用不同的組態檔，則必須小心確保所有不同組態檔中的伺服器清單相符。

注意

在 3.5.0 及更新版本中，其中一些參數應放置在動態組態檔中。如果將它們放置在靜態組態檔中，ZooKeeper 會自動將它們移至動態組態檔。請參閱 動態重新組態 以取得更多資訊。

最低設定

以下是組態檔中必須定義的最低組態關鍵字

進階設定

本節中的組態設定為選用。您可以使用它們進一步微調 ZooKeeper 伺服器的行為。有些也可以使用 Java 系統屬性設定，通常為 zookeeper.keyword 格式。當有可用時，確切的系統屬性會註明在下方。

此功能具有向後和向前相容性。以下是不同的情境。

  1. 由伺服器內部觸發的快照 a. 在使用新程式碼載入舊快照時，嘗試讀取不存在的 lastProcessedZxid 值時，將會擲出 EOFException，並會捕捉到例外狀況。將使用快照檔名稱設定 lastProcessedZxid。

    b. 在使用舊程式碼載入新快照時，反序列化摘要值後將會順利完成，快照檔結尾的 lastProcessedZxid 將會被忽略。將使用快照檔名稱設定 lastProcessedZxid。

    1. 領導者和追隨者之間的同步 lastProcessedZxid 在新舊程式碼中都不會由領導者序列化，也不會由追隨者反序列化。它將設定為透過 QuorumPacket 從領導者傳送的 lastProcessedZxid。

  2. 透過管理員伺服器 API 觸發的快照 此功能標記需要啟用才能讓快照命令運作。

叢集選項

此區段中的選項設計為與伺服器組合作使用，亦即在部署伺服器叢集時使用。

如果你真的需要預設啟用所有四個字母的指令，你可以使用星號選項，這樣就不必在清單中逐一包含每個指令。例如，這將啟用所有四個字母的指令

4lw.commands.whitelist=*

加密、驗證、授權選項

本節中的選項允許控制服務執行的加密/驗證/授權。

除了此頁面外，您還可以在 程式設計人員指南 中找到有關用戶端側組態的實用資訊。ZooKeeper Wiki 也有關於 ZooKeeper SSL 支援 和 ZooKeeper 的 SASL 驗證 的實用頁面。

實驗選項/功能

目前被視為實驗性質的新功能。

不安全的選項

下列選項可能很有用，但請在使用時小心。每個選項的風險會連同變數功能的說明一起說明。

停用資料目錄自動建立

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 檔案）在過去對使用者來說一直是個問題。請注意，此腳本僅確保資料目錄存在，它不會建立設定檔，而是需要設定檔才能執行。

啟用資料庫存在驗證

ZooKeeper 3.6.0 新增功能：啟動時找不到資料樹時，ZooKeeper 伺服器的預設行為是將 zxid 設為零，並以投票成員的身分加入法定人數。如果某些事件（例如惡意「rm -rf」）在伺服器停機時移除資料目錄，這可能會很危險，因為此伺服器可能會協助選出遺失交易記錄的領導者。啟用資料庫存在驗證會變更啟動時找不到資料樹的行為：伺服器會以非投票參與者的身分加入整體，直到它能夠與領導者同步並取得整體資料的最新版本。若要指出預期資料樹為空（建立整體），使用者應將檔案「initialize」置於與「myid」相同的目錄中。伺服器會在啟動時偵測並刪除此檔案。

在 java 命令列上設定 zookeeper.db.autocreate=false，例如 -Dzookeeper.db.autocreate=false，即可在直接從類別檔案執行 ZooKeeper 伺服器時啟用初始化驗證。執行 zkServer-initialize.sh 會建立所需的初始化檔案。

效能調整選項

3.5.0 新功能：已重新設計多個子系統以提升讀取吞吐量。這包括 NIO 通訊子系統和要求處理管線 (提交處理器) 的多執行緒。NIO 是預設的用戶端/伺服器通訊子系統。其執行緒模型包含 1 個接收器執行緒、1-N 個選擇器執行緒和 0-M 個 socket I/O 工作執行緒。在要求處理管線中，系統可設定為一次處理多個讀取要求，同時維持相同的相容性保證 (相同階段的寫入後讀取)。提交處理器執行緒模型包含 1 個主執行緒和 0-N 個工作執行緒。

預設值旨在最大化專用 ZooKeeper 電腦上的讀取吞吐量。兩個子系統都需要有足夠的執行緒才能達到最高讀取吞吐量。

偵錯可觀察性設定

3.6.0 中的新增功能：引入了以下選項，以簡化 zookeeper 的偵錯。

AdminServer 設定

3.9.0 中的新增功能：以下選項用於設定 AdminServer。

3.7.1 新增：下列選項用於設定 AdminServer。

3.6.0 新增：下列選項用於設定 AdminServer。

3.5.0 新增：下列選項用於設定 AdminServer。

指標提供者

3.6.0 新增：下列選項用於設定指標。

預設情況下，ZooKeeper 伺服器會使用 AdminServer 和 Four Letter Words 介面公開有用的指標。

從 3.6.0 開始，您可以設定不同的指標提供者，將指標匯出到您偏好的系統。

從 3.6.0 開始，ZooKeeper 二進位套件會與 Prometheus.io 整合。

使用 Netty 架構進行通訊

Netty 是一個基於 NIO 的客戶端/伺服器通訊架構，它簡化了許多 Java 應用程式在網路層級通訊中直接使用 NIO 的複雜性。此外，Netty 架構內建支援加密 (SSL) 和驗證 (憑證)。這些是選用功能，可以個別開啟或關閉。

在 3.5 以上的版本中，ZooKeeper 伺服器可以透過將環境變數 zookeeper.serverCnxnFactory 設定為 org.apache.zookeeper.server.NettyServerCnxnFactory 來使用 Netty 取代 NIO（預設選項）；對於客戶端，將 zookeeper.clientCnxnSocket 設定為 org.apache.zookeeper.ClientCnxnSocketNetty。

法定人數 TLS

3.5.5 新增

基於 Netty 架構，ZooKeeper 叢集可以在其通訊頻道中設定使用 TLS 加密。本節說明如何在法定人數通訊中設定加密。

請注意，法定人數 TLS 封裝了保護領導者選舉和法定人數通訊協定的安全性。

  1. 建立 SSL 金鑰庫 JKS 來儲存本機憑證

應為每個 ZK 執行個體建立一個金鑰庫。

在此範例中，我們產生一個自簽憑證，並將其與私密金鑰一起儲存在 keystore.jks 中。這適用於測試目的，但您可能需要官方憑證來在生產環境中簽署您的金鑰。

請注意，別名 (-alias) 和識別名稱 (-dname) 必須與其關聯的機器主機名稱相符，否則主機名稱驗證將無法運作。

keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password
  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. 您需要使用 NettyServerCnxnFactory 作為 serverCnxnFactory，因為 NIO 不支援 SSL。將下列組態設定新增至您的 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 指令

四個字母的單字

ZooKeeper 回應一組簡短的指令。每個指令由四個字母組成。您透過 telnet 或 nc 在用戶端埠向 ZooKeeper 發出指令。

三個較有趣的指令：「stat」提供一些關於伺服器和已連線用戶端的資訊，而「srvr」和「cons」分別提供伺服器和連線的詳細資料。

3.5.3 新增：四個字母的字詞在使用前需要明確列入白名單。請參閱 叢集組態區段 中所述的 4lw.commands.whitelist 以取得詳細資料。未來，四個字母的字詞將會被棄用，請改用 AdminServer。

輸出與 java 屬性格式相容，且內容可能會隨著時間而變更（新增新金鑰）。您的腳本應預期會有變更。注意：有些金鑰是特定於平臺的，而有些金鑰僅由 Leader 匯出。輸出包含多行，格式如下

key \t value

以下是 ruok 指令的範例

$ echo ruok | nc 127.0.0.1 5111
    imok

AdminServer

3.5.0 新增： AdminServer 是嵌入式 Jetty 伺服器，提供 HTTP 介面至四個字母字詞指令。預設情況下，伺服器會在埠 8080 上啟動，並透過前往 URL "/commands/[command name]"，例如 https://127.0.0.1:8080/commands/stat 來發出指令。指令回應會以 JSON 回傳。與原始協定不同，指令不限於四個字母名稱，且指令可以有多個名稱；例如，「stmk」也可以稱為「set_trace_mask」。若要檢視所有可用指令的清單，請將瀏覽器指向 URL /commands（例如 https://127.0.0.1:8080/commands）。請參閱 AdminServer 組態選項，了解如何變更埠和 URL。

預設情況下會啟用 AdminServer，但可以透過下列方式停用

請注意，如果 AdminServer 已停用，則 TCP 四個字母字詞介面仍可用。

為 AdminServer 組態 SSL/TLS
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

可用指令包括

資料檔案管理

ZooKeeper 將其資料儲存在資料目錄中，並將其交易記錄儲存在交易記錄目錄中。預設情況下，這兩個目錄是相同的。伺服器可以（而且應該）設定為將交易記錄檔案儲存在與資料檔案不同的目錄中。當交易記錄存在於專用記錄裝置上時，會增加吞吐量並減少延遲。

資料目錄

此目錄中有兩個或三個檔案

每個 ZooKeeper 伺服器都有唯一的 ID。此 ID 用於兩個地方：myid 檔案和設定檔。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「chroot」支援的 區段，這在部署許多與單一 ZooKeeper 群集介接的應用程式/服務時非常有用。