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 的檔案來將伺服器 ID 屬性給每台機器，每個伺服器一個，此檔案會駐留在該伺服器的資料目錄中，如設定檔參數 dataDir 所指定。

  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) 個伺服器故障。如果具有 6 個伺服器的 ZooKeeper 叢集，則叢集也可以容忍最多 2 (6/2-1) 個伺服器故障，而不會遺失資料並防止「腦裂」問題。

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

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

單一機器需求

如果 ZooKeeper 必須與其他應用程式競爭存取資源，例如儲存媒體、CPU、網路或記憶體，則其效能將會明顯下降。ZooKeeper 具有強大的耐用性保證，表示它會使用儲存媒體來記錄變更，然後才會允許負責變更的作業完成。您應該知道此依賴性，並在想要確保 ZooKeeper 作業不會因媒體而中斷時特別小心。以下列出一些您可以執行的動作，以將此類效能降低降至最低

配置

需要考慮的事項：ZooKeeper 的優點和限制

管理

維護

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

持續資料目錄清理

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

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

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

在以下範例中，保留最後的計數快照及其對應的記錄檔，並刪除其他快照和記錄檔。 的值通常應大於 3（雖然不是必需的，但在最近的記錄檔損毀的不可能性事件中，這會提供 3 個備份）。這可以作為 cron 工作在 ZooKeeper 伺服器機器上執行，以每日清理記錄檔。

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 伺服器，可確保如果程序異常結束，它將自動重新啟動並快速重新加入叢集。

如果發生 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 服務可以用三種主要方式之一來監控

記錄

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 驗證 的實用頁面。

實驗性選項/功能

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

不安全的選項

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

停用資料目錄自動建立

ZooKeeper 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，即可在直接從類別檔案執行 ZooKeeper 伺服器時啟用初始化驗證，亦即 -Dzookeeper.db.autocreate=false。執行 zkServer-initialize.sh 將會建立所需的初始化檔案。

效能調整選項

ZooKeeper 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 Framework，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

ZooKeeper 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 四個字母的字詞介面仍然可用。

可用指令包括

資料檔案管理

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 叢集介面時，這會非常有用。