管理 Kudu · Kudu 1.4.0 中文文檔

# 管理 Kudu 原文鏈接 : [http://kudu.apache.org/docs/administration.html](http://kudu.apache.org/docs/administration.html) 譯文鏈接 : [http://cwiki.apachecn.org/pages/viewpage.action?pageId=10813623](http://cwiki.apachecn.org/pages/viewpage.action?pageId=10813623) 貢獻者 : [小瑤](/display/~chenyao) [ApacheCN](/display/~apachecn) [Apache中文網](/display/~apachechina) ## Apache Kudu Administration ( 管理 Apache Kudu ) 注意 **Kudu** 與**[Cloudera Manager](http://www.cloudera.com/content/www/en-us/products/cloudera-manager.html)** 相比在獨立安裝中更容易管理。有關使用 **Kudu** 與 **Cloudera Manager** 的更多詳細信息，請參閱 [**Cloudera Kudu** 文檔](http://www.cloudera.com/documentation/kudu/latest/topics/kudu_installation.html) 。 ## 啟動和停止 Kudu 進程重要僅當使用操作系統軟件包（例如 **rpm** 或 **deb** ）安裝 **Kudu** 時，這些說明才是相關的。 1. 使用以下命令啟動 **Kudu** 服務： ``` $ sudo service kudu-master start $ sudo service kudu-tserver start ``` 2. 要停止 **Kudu** 服務，請使用以下命令： ``` $ sudo service kudu-master stop $ sudo service kudu-tserver stop ``` ## Kudu Web 界面 **Kudu?tablet servers**?和 **masters** 在內置的 **Web** 界面上顯示有用的操作信息， ### Kudu Master Web Interface **Kudu** 主進程在 **8051** 端口上為其 **Web** 界面提供服務。該界面暴露了幾個頁面，其中包含有關群集狀態的信息： * **tablet servers** 列表，其 **host names** 和上次心跳時間。 * 表格列表，包括每個表的 **schema?**和 **tablet location information** 信息。 * 您可以將其粘貼到 **Impala** **Shell** 中以將現有表添加到 Impala 的已知數據源列表中的 **SQL** 代碼。 ### Kudu Tablets Server Web 界面每個**tablet server** 都提供端口 **8050** 上的 **Web** 界面。該界面顯示有關服務器上托管的每個**tablet** 的信息，其當前狀態以及有關維護后臺操作的調試信息。 ### 常見的 Web 界面頁面 **Kudu masters** 和 **tablet servers** 通過其 **Web** 界面暴露了一組通用的信息： * HTTP 訪問服務器日志。 * 一個 **/rpcz** 端點，通過 **JSON** 列出當前運行的 **RPC** 。 * 頁面提供了有關進程不同組件的內存使用情況的概述和詳細信息。 * 關于當前配置標志的信息。 * 關于當前正在運行的線程及其資源消耗的信息。 * 一個 **JSON** 端點顯示有關服務器的指標。 * 有關守護程序部署版本號的信息。這些界面是從每個守護進程的 **Web UI** 的 **landing page** 鏈接的。 ## Kudu Metrics ( 指標 ) **Kudu** 守護進程公開了大量的指標。一些指標與整個服務器進程相關聯，而其他指標與特定 **tablet** 副本相關聯。 ### 列出可用的指標 **Kudu** 服務器的全套可用度量值可以通過特殊的命令行標志進行轉儲： ``` $ kudu-tserver --dump_metrics_json $ kudu-master --dump_metrics_json ``` 這將輸出一個大的 **JSON** 文檔。每個指標都表示其名稱，標簽，描述，單位和類型。由于輸出是 **JSON** 格式的，所以可以輕松地將這些信息進行解析，并將其饋送到從 **Kudu** 服務器收集指標的其他工具中。 ### 通過HTTP收集指標可以通過訪問/指標通過其 **HTTP** 接口從服務器進程收集度量。此頁面的輸出是 **JSON** ，可以通過監視服務輕松解析。此端點在其查詢字符串中接受幾個 **GET** 參數： * **/metrics?metrics=<substring1>,<substring2>,…** -?將返回的指標限制為至少包含一個提供的子字符串的指標。子串也匹配實體名稱，因此可用于收集特定 **tablet** 的指標。 * **/metrics?include_schema=1** - ?包括 JSON 輸出中的度量架構信息，如單位，描述和標簽。通常這些信息可以節省空間。 * **/metrics?compact=1** -?從結果 JSON 中消除不必要的空格，從遠程主機獲取此頁面時可以減少帶寬。 * **/metrics?include_raw_histograms=1** -?包括直方圖指標的原始存儲桶和值，可實現隨時間和跨主機的百分位數度量的準確聚合。例如： ``` $ curl -s 'http://example-ts:8050/metrics?include_schema=1&metrics=connections_accepted' ``` ``` [ { "type": "server", "id": "kudu.tabletserver", "attributes": {}, "metrics": [ { "name": "rpc_connections_accepted", "label": "RPC Connections Accepted", "type": "counter", "unit": "connections", "description": "Number of incoming TCP connections made to the RPC server", "value": 92 } ] } ] ``` ``` $ curl -s 'http://example-ts:8050/metrics?metrics=log_append_latency' ``` ``` [ { "type": "tablet", "id": "c0ebf9fef1b847e2a83c7bd35c2056b1", "attributes": { "table_name": "lineitem", "partition": "hash buckets: (55), range: [(<start>), (<end>))", "table_id": "" }, "metrics": [ { "name": "log_append_latency", "total_count": 7498, "min": 4, "mean": 69.3649, "percentile_75": 29, "percentile_95": 38, "percentile_99": 45, "percentile_99_9": 95, "percentile_99_99": 167, "max": 367244, "total_sum": 520098 } ] } ] ``` 注意所有直方圖和計數器都是從服務器開始時間開始測量的，收集后不會重置。 ### 收集指標到日志 **Kudu** 可以配置為使用 **--metrics_log_interval_ms** 標志將其所有度量值定期轉儲到本地日志文件。將此標志設置為將度量值寫入日志文件的時間間隔。度量日志將與其他 **Kudu** 日志文件一樣寫入與其相同的目錄，具有相同的命名格式。任何指標日志文件達到 **64MB** 未壓縮后，日志將被滾動，上一個文件將被 **gzip** 壓縮。生成的日志文件有三個空格分隔的字段。第一個字段是單詞指標。第二個字段是自 **Unix** 紀元以來的微秒的當前時間戳。第三個是使用緊湊的 **JSON** 編碼在服務器上的所有指標的當前值。編碼與通過上述 **HTTP** 獲取的指標相同。注意雖然度量記錄自動滾動并壓縮以前的日志文件，但它不會刪除舊的日志文件。由于度量記錄可以使用大量的磁盤空間，因此請考慮設置系統實用程序來監視日志目錄中的空間并歸檔或刪除舊段。 ## 常見的 Kudu 工作流程 ### 遷移到多個 Kudu Master 為了獲得高可用性并避免出現單點故障，**Kudu** 集群應該由多個主人創建。許多 **Kudu** 集群是由一個單一的主人創建的，無論是簡單的還是由于 **Kudu** 多主人的支持在當時仍然是實驗性的。此工作流演示如何遷移到多主配置。注意將工作流添加到現有的多主配置中是不安全的。不要為此目的使用它。注意該工作流程至少基本上熟悉 **Kudu** 配置管理。如果使用 **Cloudera Manager（CM）** ，工作流程也預先假定它是熟悉的。注意以下所有命令行步驟都應該像 **Kudu** **UNIX** 用戶一般執行。 #### 準備遷移 1. 建立維護窗口（一小時應該足夠）。在此期間，**Kudu** 集群將不可用。 2. 決定使用多少 **masters** 。 **masters** 的數量應該是奇數。建議使用三或五個節點主配置;他們可以容忍一兩個故障。 3. 對現有 **master** 執行以下準備步驟： * 識別和記錄主數據所在的目錄。如果使用 **Kudu** 系統軟件包，則默認值為 **/var/lib/kudu/master** ，但可以通過 **fs_wal_dir** 和 **fs_data_dirs** 配置參數進行自定義。請注意，如果您將 **fs_data_dirs** 設置為除 **fs_wal_dir** 值之外的某些目錄，則應將其明確包含在其中還包含 fs_wal_dir 的每個命令中。 * 識別和記錄 **master** 正在為 **RPC** 使用的端口。默認端口值為 **7051** ，但可能使用 **rpc_bind_addresses** 配置參數進行了自定義。 * 識別 **master** 的 **UUID** 。可以使用以下命令獲取它： ``` $ kudu fs dump uuid --fs_wal_dir=<master_data_dir> 2>/dev/null ``` **master_data_dir** 現有 master 以前記錄的數據目錄 **例子** ``` $ kudu fs dump uuid --fs_wal_dir=/var/lib/kudu/master 2>/dev/null 4aab798a69e94fab8d77069edff28ce0 ``` * 可選：配置 **master** 的 **DNS** 別名。別名可能是 **DNS cname** （如果機器已經在 **DNS** 中有 **A** 記錄）， **A** 記錄（如果機器僅由其 **IP** 地址知道）或 **/etc/hosts** 中的別名。別名應該是 **master** 的抽象表示（例如，**master - 1**）。注意沒有 **DNS** 別名，不可能從永久性主機故障中恢復，因此強烈建議。 4. 為每個新的主設備執行以下準備步驟： * * 在集群中選擇一個未使用的機器。主機生成的負載很小，因此它可以與其他數據服務或負載生成過程共同配置，盡管與其他 **Kudu** 主機不同，配置相同。 * 確保 **Kudu** 通過系統包裝（在這種情況下應安裝 **kudu** 和 **kudu-master** 包裝）或通過其他方式安裝在機器上。 * 選擇并記錄主數據將存在的目錄。 * 選擇并記錄主機應用于 **RPC** 的端口。 * 可選：配置主服務器的 **DNS** 別名（例如，**master-2** ， **master-3** 等）。 #### 執行遷移 1. 停止整個集群中的所有 **Kudu** 進程。 2. 格式化每個新 **master ?**上的數據目錄，并記錄生成的 **UUID** 。使用以下命令序列： ``` $ kudu fs format --fs_wal_dir=<master_data_dir> $ kudu fs dump uuid --fs_wal_dir=<master_data_dir> 2>/dev/null ``` **master_data_dir** 新 master 以前錄制的數據目錄。 **示例** ``` $ kudu fs format --fs_wal_dir=/var/lib/kudu/master $ kudu fs dump uuid --fs_wal_dir=/var/lib/kudu/master 2>/dev/null f5624e05f40649b79a757629a69d061e ``` 3. 如果使用 **CM** ，現在添加新的 **Kudu master roles** ，但不要啟動它們。 * 如果使用 **DNS** 別名，請使用該主機的別名覆蓋每個角色（包括現有主角色）的 **“Master Address”** 參數的空值。 * 如果使用非默認 **RPC** 端口值，請添加端口號（以冒號分隔）。 4. 使用以下命令重寫 **master** 的 **Raft** 配置，在現有主機上執行： ``` $ kudu local_replica cmeta rewrite_raft_config --fs_wal_dir=<master_data_dir> <tablet_id> <all_masters> ``` **master_data_dir** 現有 master 以前記錄的數據目錄 **tablet_id**必須是字符串 00000000000000000000000000000000**all_masters**空格分隔的 master 的列表，新的和現在的。列表中的每個條目必須是 <uuid>：<hostname>：<port> 格式的字符串? ?**UUID** ? ?master 以前記錄的 UUID **hostname** ? ?master 以前記錄的 hostname 或別名 **port** ? ?master 以前記錄的 RPC 的端口號 **示例** ``` $ kudu local_replica cmeta rewrite_raft_config --fs_wal_dir=/var/lib/kudu/master 00000000000000000000000000000000 4aab798a69e94fab8d77069edff28ce0:master-1:7051 f5624e05f40649b79a757629a69d061e:master-2:7051 988d8ac6530f426cbe180be5ba52033d:master-3:7051 ``` 5. 修改現有 **master** 和新 **masters** 的 **master_addresses** 配置參數的值。新值必須是所有主節點的逗號分隔列表。每個條目是 **<hostname>：<port>** 形式的字符串 **hostname** ? ?master 以前記錄的 hostname 和別名 **port** ? ?master 以前記錄的 RPC 端口號 6. 啟動現有的 **master** 7. 使用以下命令將 **master** 數據復制到每個新 **master** ，在每臺新 **master** 上執行： ``` $ kudu local_replica copy_from_remote --fs_wal_dir=<master_data_dir> <tablet_id> <existing_master> ``` **master_data_dir** 新 master 以前記錄的數據目錄 **tablet_id** 必須是字符串 00000000000000000000000000000000 **existing_master** 現有 master 的 RPC 地址必須是 <hostname>：<port> 形式的字符串 **hostname** 現有 master?以前記錄的 hostname 或別名 **port** 現有 master 以前記錄的 RPC 端口號 **示例** ``` $ kudu local_replica copy_from_remote --fs_wal_dir=/var/lib/kudu/master 00000000000000000000000000000000 master-1:7051 ``` 8. 啟動所有的新的 **master** 注意如果使用 **CM** ，請跳過下一步。 9. 修改每個 **tablet** **server** 的 **tserver_master_addrs** 配置參數的值。新值必須是以逗號分隔的主文件列表，其中每個條目是 **<hostname>** 形式的字符串：**<port>**? **hostname** master 以前記錄的 hostname 和別名 **port** master 以前記錄的 RPC 端口號 10. 啟動所有的 **tablet servers** 恭喜，集群已經遷移到多個 **masters** 了！要驗證所有 **master** 是否正常工作，請考慮執行以下健康性檢查： * 使用瀏覽器訪問每個 **master** 的 **Web UI** 。看看 **/master page** 。所有的 **master** 都應該被列在那里，一個主人在 **LEADER** 角色，其他的在 **FOLLOWER** 角色。每個 **master** 的 **master** 的內容應該是一樣的。 * 使用 **kudu** 命令行工具在集群上運行 **Kudu** 系統檢查（ **ksck** ）。有關詳細信息，請參閱 [使用 **ksck** 檢查群集運行狀況](/pages/viewpage.action?pageId=10813623)。 ### 在多 Master 部署中從死亡的 Kudu Master 恢復 **Kudu ?multi-master** 部署功能通常在主機丟失的情況下。但是，重要的是更換死主;否則第二次故障可能會導致可用性的丟失，具體取決于可用 **master** 的數量。此工作流程描述如何更換 **dead master** 。由于 [KUDU-1620](https://issues.apache.org/jira/browse/KUDU-1620) ，無需重新啟動現場主機即可執行此工作流程。因此，工作流需要一個維護窗口，盡管主要通常是快速重啟。注意 **Kudu** 還不支持主人的 **Raft** 配置更改。因此，如果部署是使用 **DNS** 別名創建的，則只能替換主服務器。有關詳細信息，請參閱[ **multi-master**? 移動工作流程](/pages/viewpage.action?pageId=10813623)。注意該工作流程至少基本上熟悉 **Kudu** 配置管理。如果使用 **Cloudera Manager （CM）** ，工作流程也預先假定它是熟悉的。注意以下所有命令行步驟都應該像 **Kudu** **UNIX** 用戶一般執行。 #### 為恢復做準備 1. 確保 **dead master** 機器正常并且真正死亡。采取一切必要步驟，防止意外重啟;這對于集群后恢復來說可能是相當危險的。 2. 選擇剩下的仍然活著的 **master** 之一作為恢復的基礎。這個工作流程的其余部分將把這個主機稱為 “**reference**” 主機。 3. 選擇 **new master** 所在的群集中未使用的機器。**master** 生成的負載很小，因此它可以與其他數據服務或負載生成過程共同配置，盡管與其他 **Kudu** 主機不同，配置相同。這個工作流程的其余部分將把這個主機稱為 “**replacement**” 主機。 4. 為?**replacement master** 執行以下準備步驟： * 確保 **Kudu** 通過系統包裝（在這種情況下應安裝 **kudu** 和 **kudu-master** 包裝）或通過其他方式安裝在機器上。 * 選擇并記錄 **master** 數據將存在的目錄。 5. 為每個現在活著的 **master** 執行以下步驟： * 識別和記錄主數據所在的目錄。如果使用 **Kudu** 系統軟件包，則默認值為 **/var/lib/kudu/master** ，但可以通過 **fs_wal_dir** 和 **fs_data_dirs** 配置參數進行自定義。請注意，如果您將 **fs_data_dirs** 設置為除 **fs_wal_dir** 值之外的某些目錄，則應將其明確包含在其中還包含 **fs_wal_dir** 的每個命令中。 * 識別和記錄 **master** 的 **UUID** 。可以使用以下命令獲取它： ``` $ kudu fs dump uuid --fs_wal_dir=<master_data_dir> 2>/dev/null ``` **master_data_dir** 活著 master 以前記錄的數據目錄 **示例** ``` $ kudu fs dump uuid --fs_wal_dir=/var/lib/kudu/master 2>/dev/null 80a82c4b8a9f4c819bab744927ad765c ``` 6. 對?**reference master** 執行以下準備步驟： * 識別和記錄主數據所在的目錄。如果使用 **Kudu** 系統軟件包，則默認值為 **/var/lib/kudu/master** ，但可以通過 **fs_wal_dir** 和 **fs_data_dirs** 配置參數進行自定義。請注意，如果您將 **fs_data_dirs** 設置為除 **fs_wal_dir** 值之外的某些目錄，則應將其明確包含在其中還包含 fs_wal_dir 的每個命令中。 * 使用以下命令識別并記錄集群中每個 **master** 的 **UUID** ： ``` $ kudu local_replica cmeta print_replica_uuids --fs_wal_dir=<master_data_dir> <tablet_id> 2>/dev/null ``` **master_data_dir** reference master 以前記錄的數據目錄 **tablet_id** 必須是字符串 00000000000000000000000000000000 **示例** ``` $ kudu local_replica cmeta print_replica_uuids --fs_wal_dir=/var/lib/kudu/master 00000000000000000000000000000000 2>/dev/null 80a82c4b8a9f4c819bab744927ad765c 2a73eeee5d47413981d9a1c637cce170 1c3f3094256347528d02ec107466aef3 ``` 7. 使用以前記錄的兩個 **UUID** 列表（一個用于所有 **live master** ，一個用于所有 **master** ），確定并記錄（通過消除處理） **dead master** 的 **UUID** 。 #### 執行恢復 1. 使用以前記錄的 **dead master** 主機的 **UUID** 格式化 **replacement master** ?上的數據目錄。使用以下命令序列： ``` $ kudu fs format --fs_wal_dir=<master_data_dir> --uuid=<uuid> ``` **master_data_dir** replacement master 以前記錄的數據目錄 **uuid** dead master 以前記錄的 UUID **例子** ``` $ kudu fs format --fs_wal_dir=/var/lib/kudu/master --uuid=80a82c4b8a9f4c819bab744927ad765c ``` 2. 使用以下命令將 **master** 數據復制到 **replacement master** ： ``` $ kudu local_replica copy_from_remote --fs_wal_dir=<master_data_dir> <tablet_id> <reference_master> ``` **master_data_dir** replacement master 以前記錄的數據目錄 **tablet_id** 必須是字符串 00000000000000000000000000000000 **reference_master** reference_master 的 RPC 地址必須是 <hostname>：<port> 形式的字符串 **hostname** reference master 以前記錄的 hostname 或別名 **port** reference master 之前記錄的 RPC 的端口號 **示例** ``` $ kudu local_replica copy_from_remote --fs_wal_dir=/var/lib/kudu/master 00000000000000000000000000000000 master-2:7051 ``` 3. 如果使用 **CM** ，請立即添加替換的 **Kudu master role**?，但不要啟動它。 * 使用?**replacement master**?的別名覆蓋**?new role**?的 **“?Master Address”** 參數的空值。 * 如果使用非默認 **RPC** 端口值，請添加端口號（以冒號分隔）。 4. 重新配置 **dead master** 的 **DNS** 別名以指向 **replacement master** 。 5. 啟動**?replacement master** 。 6. 重新啟動現有的 **live master** 。這導致短暫的可用性中斷，但是只有 masters 回來才能持續。恭喜，**dead master** 已經被替換了！要驗證所有 **master** 是否正常工作，請考慮執行以下健康性檢查： * 使用瀏覽器訪問每個 **master** 的 **Web UI** 。看看?**/master page** 。所有的主人都應該被列在那里，一個 **master** 在 **LEADER** 角色，其他的在 **FOLLOWER** 角色。每個 **master** 的 **master** 的內容應該是一樣的。 * 使用 **kudu** 命令行工具在集群上運行 **Kudu** 系統檢查（ **ksck** ）。有關詳細信息，請參閱 [使用 ksck 檢查群集運行狀況](/pages/viewpage.action?pageId=10813623)。 ### 使用 ksck 檢查集群運行狀況 **kudu CLI** 包括一個名為 **ksck** 的工具，可用于檢查群集運行狀況和數據完整性。 **ksck** 會發現問題，如副本不足的 **tablet** ，無法連接的 **tablet server** 或沒有 **leader** 的 **tablet** 。應從命令行運行 **ksck** ，并要求指定 master ?address 的完整列表： ``` $ kudu cluster ksck master-01.example.com,master-02.example.com,master-03.example.com ``` 要查看 **ksck** 可用選項的完整列表，請使用 **--help** 標志。如果集群是健康的， **ksck** 將打印成功消息，并返回零（成功）退出狀態。 ``` Connected to the Master Fetched info from all 1 Tablet Servers Table IntegrationTestBigLinkedList is HEALTHY (1 tablet(s) checked) The metadata for 1 table(s) is HEALTHY OK ``` 如果集群不健康，例如，如果 **tablet server** 進程已停止，則 **ksck** 將報告問題并返回非零退出狀態： ``` Connected to the Master WARNING: Unable to connect to Tablet Server 8a0b66a756014def82760a09946d1fce (tserver-01.example.com:7050): Network error: could not send Ping RPC to server: Client connection negotiation failed: client connection to 192.168.0.2:7050: connect: Connection refused (error 61) WARNING: Fetched info from 0 Tablet Servers, 1 weren't reachable Tablet ce3c2d27010d4253949a989b9d9bf43c of table 'IntegrationTestBigLinkedList' is unavailable: 1 replica(s) not RUNNING 8a0b66a756014def82760a09946d1fce (tserver-01.example.com:7050): TS unavailable [LEADER] Table IntegrationTestBigLinkedList has 1 unavailable tablet(s) WARNING: 1 out of 1 table(s) are not in a healthy state ================== Errors: ================== error fetching info from tablet servers: Network error: Not all Tablet Servers are reachable table consistency check error: Corruption: 1 table(s) are bad FAILED Runtime error: ksck discovered errors ``` 為了驗證數據完整性，可以設置可選的 **--checksum_scan** 標志，通過掃描每個 **tablet** 副本并比較結果，可以確保集群具有一致的數據。 **?--tables** 或 **--tablets** 標志可用于將校驗和掃描的范圍分別限制在特定的表格或 **tablet** 上。例如，可以使用以下命令對 **IntegrationTestBigLinkedList** 表上的數據完整性進行檢查： ``` $ kudu cluster ksck --checksum_scan --tables IntegrationTestBigLinkedList master-01.example.com,master-02.example.com,master-03.example.com ``` ### 從磁盤故障恢復 **Kudu tablet servers** 無法恢復磁盤故障。當包含數據目錄或預寫日志（ **WAL** ）的磁盤死機時，必須重建整個 **tablet server**。在 **tablet server** 發生故障后， **Kudu** 會在其他服務器上自動重新復制 **tablet** ，但需要手動干預才能將失敗的 **tablet server** 還原到運行狀態。在磁盤故障后恢復 **tablet servers** 的第一步是更換發生故障的磁盤，或從數據目錄 **and/or ?WAL** 配置中刪除出現故障的磁盤。接下來，必須刪除數據目錄和 **WAL** 目錄的內容。例如，如果 **tablet servers** 配置了**--fs_wal_dir = /data/0/kudu-tserver-wal** 和 **--fs_data_dirs = /data/1/kudu-tserver/data/2/kudu-tserver** ，則以下命令將刪除數據目錄和 **WAL** 目錄內容： ``` $ rm -rf /data/0/kudu-tserver-wal/* /data/1/kudu-tserver/* /data/2/kudu-tserver/* ``` 在 **WAL** 和數據目錄被清空之后，可以啟動 **tablet servers** 進程。當使用系統包安裝 **Kudu** 時，通常使用服務： ``` $ sudo service kudu-tserver start ``` 一旦 **tablet servers** 再次運行，就會根據需要在其上創建新的 **tablet** 副本。