2018年1月27日 星期六

[Cassandra] 監控與維運

介紹C*監控與維運常用command與用法




監控

nodetool 為bin下的一個指令 ,可以檢視叢集活動
  • nodetool help –檢視指令集
  • nodetool describecluster –列出名稱.Snitch.分割器.檢視schema是否不一致.不一致就必須重啟該節點
  • nodetool -h 192.168.0.42 info –檢視特定節點狀況
  • nodetool tpstats –回傳執行緒池的健康狀況,顯示某階段操作數量為何以及目前處於活動中待處理已完成等狀態,下半部顯示節點丟棄訊息數量,當節點接收請求高於負荷,訊息開始被丟棄, 若drop多數不為零, 代表C*負載過高
  • nodetool tablestats hotel–檢視特定kepspace and table統計值
  • nodetool status –確認節點狀況
  • nodetool info –確認節點detail狀況, EX: Heap memory,key cache......
  • nodetool proxyhistograms –查看延遲, 可在多台節點下執行, 找出效率差的節點
  • nodetool ring –知道主機範圍印記與狀態, 知道叢集還中所有節點IP位置, load顯示節點儲存資料量

檢查從集結點是否健康

  • nodetool status 確認所有節點都處於上線狀況以及負載是否平衡
  • nodetool tpstats 檢視丟棄數量, 若丟棄數量持續上升代表負載過高需要水平擴展增加節點或垂直擴展增加硬體
  • 若1.2.發生問題, 可以檢查log中是否有error或warn, 如outofmemory
  • 確保每個節點cassandra.yaml與.env設定, 如heap在8GB左右
  • 檢查keyspace策略

基礎維運

  • nodetool flush –將資料沖洗成檔案系統內的SSTable
  • nodetool cleanup –清除不屬於該節點的資料, 當複製策略變更降低了複製因子, 必須將多於資料清除, 當有節點新增時, 每個舊節點必須執行
  • nodetool repair [--full] [keyspace] –當節點失效,只要改變snitch or 複製因子
  • nodetool scrub [keyspace] –當repair發生validation failed in xxx.xxx.xxx.xxx,可試著對損壞的keyspace執行 ,從sstable移除損壞資料, 使用完搭配repair
  • nodetool clearsnapshot –清除快照,系統預設自動快照為開啟,當發生truncate or drop table or drop keyspace系統會執行快照,若已將快照保存在其他地方,就可以執行此指令將其刪除,若要將其關閉,必須在cassandra.yaml裡面auto_snapshot=False 
  • nodetool snapshot [-t rename] [keyspace] –建立快照, 將table >> data建立一份snapshot, 可將此資料備份去其他地方進行保存, 當需要恢復特定版本的snapshot時, 可將備份資料夾中的sstable直接copy到正式資料夾的table資料夾中, 先將此table truncate,然後執行nodetool refresh, 但若拓譜或印記或複製因子已經改變過, 就必須透過sstableloader工具, snapshot指令可以參考https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsSnapShot.html 
 
如果發生以下錯誤 : 
Failed to dispatch hints file
 nodetool truncatehints –將損壞的hints刪除, 可再進行一次repair 

Repair

  • 離鋒時刻排程去修復
  • 策略如下(3選1)
    1. 1-3 天一次repair, 1-3 weeks一次full repair ,每個節點
    2. 每5天一次full repair ,每個節點
    3. 最小要求 : 每7天一次full repair ,每個節點
    • 當節點失效時間小於max_hint_window_in_ms(1080000 ms = 3 hours) 重啟後可以還原
    • 當節點失效時間小於gc_grace_seconds(864000 sec=10 day), 重啟節點後要再執行repair
    • 當節點失效時間大於gc_grace_seconds, 則必須更換節點, 以免墓碑資料重生

資料中心增加節點

  • 所有C*必須同版本, 若無, 先全部升級後再進行增加
  • 沿用其他節點設定檔
  • 設定種子節點, 若是新節點加入叢集, 不會設定為seed
  • 如果有多機架, 每個機架有相同數量節點較好
  • 如果使用單一印記模式, 可添加一倍節點數量,讓每個節點負責的印記範圍少一半
  • cassandra.yaml auto_bootstrap(default=True) 新節點開啟後就立即生效, 接收其他蝶演串流資料
  • 啟用後使用nodetool status
  • 每個舊節點必須執行cleanup, 清除不受就節點管理的資料 

拍攝快照

  • 使用nodetool snapshot命令為每個節點建立快照, 要獲取全渠快照請使用ssh(如pssh)運行nodetool snapshot指令
  • 快照會將內存忠的寫入操作(memtables) 刷新到磁盤, 然後為每個keyspace創建一個SSTable文件的映射, 節點上必須有足夠的磁盤空間來容納數據文件的快照, 一個快照需要很少的空間, 但快照不能刪除舊的過時數據, 因此可能導致隨著時間推移而增長的很快速, 也可以在進行快照後將快照移至其他位置   
  •  Cassandra只能在表system_schema存在時恢復數據, 建議也被分system_schema

恢復數據

  • 確保要恢復的數據表模式存在，Cassandra只能從存在的表模式中恢復鏡像裡的數據。如果表模式不存在，則必需首先創建它。
  • 如果可行，務必truncate table。使用TRUNCATE TABLE <table name>將表中數據截斷。我們現在做的都是全量備份，如果因為意外的刪除數據造成tombstone的時間發生混亂，截斷表可以確保不會有本應被刪除的數據被恢復的情況發生
  • 關閉所有節點 nodetool stop
  • 將生成的鏡像文件，<table name>-<uuid>/<snapshot name>/*目錄下的所有數據拷貝到目標Cassandra的
  • <data directory>/<keyspace>/<table name>-<uuid>/目錄中。（注意：是將鏡像目錄的數據拷貝到目錄keyspace的表目錄裡）
  • 每一個節點都必須copy快照, 回到SSTable(或n個複製因子就copy n台?) 可以使用cp snapshots/truncated-1539182023411-dolphin_conversation_result/* .
  • 啟動Cassandra並執行nodetool refresh命令恢復鏡像內的數據  
  • 若拓譜或印記或複製因子已經改變過, 就必須透過sstableloader工具
移除節點 
如果不立即更換失效節點或只想降低從集結點的規模, 你可以選擇移除(Removing).除役(Decommission)或刺殺(Assassinating)節點, 除役 > 移除 > 刺殺
  • 除役 : 如果節點仍上線中,  執行nodetool decommission指令, 將該節點印記範圍分配給其他節點, 並且將資料以串流形式傳送出去, 除役並不會將資料移除, 若決定將節點從新加入叢集並且負責不同印記範圍, 必須先手動移除資料 
  • 移除 : 若節點已經下線, 可使用nodetool removennode, 讓cassandra從新計算印記範圍, 並以串流方式將資料傳送到新的節點上
  • 刺殺 : 若移除失敗, nodetool assassinate作為最後手段
移除節點時, 要更新其餘節點cassandra.yaml設定檔的seeds, 同時確保有足夠的seeds數量, 同一資料中心至少兩個

移除節點可以參考趙岩的博客文章, 參考在如下...
僅適應使用了vnodes的cassandra集群，怎麼判斷是否用了vnodes呢？主要看你的cassandra.yaml配置文件中，是否配置了initial_token，如果沒有配置，就是使用了vnodes。使用了vnodes，刪除了節點之後它會自己均衡數據，不要你手動處理。
根據官方文檔的提示，操作步驟如下：
第一步：先每個機器都修復下每個keyspace 
nodetool repair -h ip_address_of_node keyspace_name 
第二步：如果你要刪除的機器是UP狀態的機器，沒有宕機
你可以在要刪除的機器上執行nodetool decommission .就直接結束了，否則繼續：
第三步：如果你的機器是宕機的。
你要先用在一個活著的機器上執行nodetool status命令，獲取宕機節點的id 
$ nodetool status
Datacenter: DC1 
=============== 
Status=Up/Down 
|/ State=Normal/Leaving/Joining/Moving 
— Address Load Tokens Owns (effective) Host ID Rack 
UN 192.168.2.101 112.82 KB 256 31.7% 420129fc-0d84-42b0-be41-ef7dd3a8ad06 RAC1 
DN 192.168.2.103 91.11 KB 256 33.9% d0844a21-3698-4883-ab66-9e2fd5150edd RAC1 
UN 192.168.2.102 124.42 KB 256 32.6% 8d5ed9f4-7764-4dbd-bad8- 43fddce94b7c RAC1
第四步:在活的節點上執行刪除操作
nodetool removenode d0844a21-3698-4883-ab66-9e2fd5150edd 
它會自己均衡數據，這裡就直接結束了，否則繼續。
第五步:再次使用nodetool status查看節點是否刪除成功
$ nodetool status
Datacenter: DC1 
=============== 
Status=Up/Down 
|/ State=Normal/Leaving/Joining/Moving 
— Address Load Tokens Owns (effective) Host ID Rack 
UN 192.168.2.101 112.82 KB 256 37.7% 420129fc-0d84-42b0-be41-ef7dd3a8ad06 RAC1 
UN 192.168.2.102 124.42 KB 256 38.3% 8d5ed9f4-7764-4dbd-bad8-43fddce94b7c RAC1

Decommission後再重啟此節點會發生錯誤, 要去%CASSANDRA_HOME%/data目錄下, 清空裡面的所有數據後再啟用一次, 資料就會重新串流, 最後要與加入節點一樣cleanup其他節點


更換節點

若無法修復的節點, 最可能的辦法就是更換節點, 移除再新增的作法會產生大量的資料串流, 資料先從舊節點移除再流到新節點, 比較好的做法是新增一個節點, 取代既有節點的印記範圍,  做法是編輯新節點的cassandra-env.sh 添加下列選項
JVM_OPTS="$JVM_OPTS -Dcassandra.replace_address=<address>"

  • 此選項可以在新節點啟用後移除或直接bin/cassandra -Dcassandra.replace_address=<address>來啟動
  • 若更換點為種子節點, 先將一個非種子升為種子, 並更新其餘節點cassandra.yaml設定檔內的種子列表 
  • 若採用GossipingPropertyFileSnitch or ProprtyFileSnitch等, 會透過設定檔紀錄叢集拓撲資訊的設定, 必須將新節點的位置添加到每個機器的配置檔中然後滾動重啟從集中的節點, 建議等待72小時再移除舊機器的位址, 避免gossiper混淆 

認證

  • authenticator  : 修改cassandra.yaml >> authenticator : AllowAllAuthenticator 改成 PasswordAuthenticator >> restart node
  • 使用預設帳密登入 : bin/cqlsh -u cassandra -p cassandra
  • 變更密碼 : alter user cassandra with password '123456789';
  • 新增用戶 : create user charles with  password 'cccccccc' if not exist;
  • 查看用戶 : list users;
  • 切換用戶 : login charles 'cccccccc'
  •  搭配CassandraAuthorizer : 修改cassandra.yaml >> authorizer >> AllowAllAuthorizer 改成 CassandraAuthorizer >> restart node
  • 此時charles只能看有哪些keyspace與table, 並不能讀取table
  • 新增腳色 : create role mykeyspace_role;
  • 對應腳色到keyspace : grant all on keyspace mykeyspace to mykeyspace_role;
  • 用戶對應腳色 : grant mykeyspace_role to charles;
system_auth預設是Strategy並且複製因子為1, 並沒有散布在叢集中, 可以重新設定 

 Ref:
於
標籤：

沒有留言:

張貼留言

訂閱： 張貼留言 (Atom)