在之前公司有幸用到了cassandra並且具有一定程度的數據量，所有不免出現許多問題，從而進行解決，在此統一歸納，以便自己回顧，也供大家一起研究學習，實際ip或一些敏感信息已手動脫敏。
目錄
4.1 方案1：使用sstableloader來做集羣間數據遷移
5.3 problem:Cassandra需要定期和手動執行repair等運維操作，否則可能出現髒數據
5.4 problem:Cassandra無法獲取一張表的總記錄數
5.5 problem: cassandra集羣產生長時間的GC
1.平臺日常檢查、監控內容
[root@cache01 ~]#nodetool -h 192.168.0.10 status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 192.168.0.10 18.28 GB 256 ? e33aedac-4385-499c-8c64-37ac3c7c9796 rack1
UN 192.168.0.11 13.16 GB 256 ? 460b90fb-148a-4a00-8e66-06d079f0a2b1 rack1
UN 192.168.0.12 19.13 GB 256 ? bf5611c7-34b4-4f32-a0ad-21878cda13b2 rack1
UN 192.168.0.13 15.19 GB 256 ? 9a507206-82a1-426e-8f99-32b5d40c00d9 rack1
Note: Non-system keyspaces don't have the same replication settings, effective ownership information is meaningless
通過cql進行一些測試命令
[root@cache01 ~]# cqlsh 192.168.0.10 9042 -u ecache -p ecache
Connected to ecache at 192.168.0.10:9042.
[cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native protocol v3]
Use HELP for help.
ecache@cqlsh> DESC KEYSPACES ;
ecache@cqlsh> USE ecache ;
ecache@cqlsh:ecache> SELECT * FROM
ecache@cqlsh:ecache> SELECT * FROM account LIMIT 1;
2.權限管理
cassandra的權限都可以通過查自帶system_auth.users和permission(要開啓權限管理)查出相應用戶對於鍵空間或者表的權限
權限管理設置:（該設置可以針對當臺節點）
authenticator: PasswordAuthenticator(需要用戶密碼)
authorizer: CassandraAuthorizer（AllowAllAuthorizer 是允許用戶進行任何操作）
創建用戶的時候可自帶超級管理員
CREATE USER fk WITH PASSWORD 'fk' SUPERUSER;
ALTER USER fk WITH PASSWORD 'fk' NOSUPERUSER;
讓某個用戶對某張表有某些權限(當然需要超級用戶來操作)
GRANT ALL(權限可選 ) PERMISSIONS ON KEYSPACE fky(可選表空間 可選表 )TO fk(用戶名) ;
設置完後就可以查找系統表 看看權限是否生效
3.備份還原
不介紹主動nodetool創建snapshot，就說自動備份
cassandra有個參數 :auto_snapshot: true
它能夠在我們truncate table /drop colunm family/drop keyspace 執行這些對數據有毀壞性操作的時候，自動生成snapshot快照
這些快照存放在datafile設置目錄下的table-uuid 文件夾下的snapshot裏
若要還原數據只需
刪除commitlog->拷貝snapshot下的數據文佳到table-uuid文件夾下->重啓節點
4.集羣遷移(全量)
介紹3種方案，方案各有優缺點，耗時或者是對應用的影響，根據自己的業務進行選擇)
4.1 方案1：使用sstableloader來做集羣間數據遷移
步驟描述：
1. 目標集羣創建相同的keyspace和table
2. 停止源集羣的客戶端寫入
3. 源集羣各個節點執行nodetool flush，把所有數據寫入sstable中
4. 源集羣各個節點執行sstableloader，把數據遷移到目標集羣中
5. 各節點逐一執行nodetool compact操作
優點：
1. 數據遷移速度快
缺點：
1. 全程需要停止集羣服務，對應用的影響較大
2. 缺少新舊集羣數據校驗過程
4.2 方案2：利用集羣節點的增加和移除來平滑切換集羣數據
步驟描述：
1. 把新節點逐一加入舊集羣，組成一個大集羣，完全加入後，需要短暫重啓客戶端的讀寫服務，把客戶端的配置信息指向新加入的8個節點
2. 從大集羣中刪除逐舊節點
3. 新節點逐一執行nodetool repair
優點：
1. 只需短暫重啓客戶端的讀寫服務程序即可，對應用的影響較小
缺點：
1. 耗時較長
2. 缺少新舊集羣數據校驗過程
4.3 方案3：全量數據的導入導出
步驟描述：
1. 舊集羣全量導出數據到文件
2. 新集羣全量導入數據
3. 新集羣全量導出數據到文件，然後進行文件比對，即可確定兩個集羣的數據一致性問題
優點：
1. 包含了新舊集羣的數據校驗過程
缺點：
1. 耗時較長
5.遇到的問題
5.1 problem:超大組導致數據熱點問題
現象描述：靜態分組算法有點問題，導致每張表的某個partition的數據量佔了總數據量的50%以上的數據。Cassandra在創建表的時候，是以 partition_id 作爲 partition_key，這樣同一個 partition_id 的數據，在入庫時計算出來的 hash 值是一樣的，所以也是寫入Cassandra的同一個node中，這樣就會導致嚴重的數據熱點。
解決：創建表的時候，以 partition_id 和 bucket_id 組合作爲 partition_key，其中，bucket_id是由表中某個字段根據一定算法生成的僞隨機數。
5.2 problem:Cassandra數據不一致
現象描述：先前研發中心是採用MapReduce接口往Cassandra集羣寫入檔案數據，而MapReduce接口默認的Cassandra寫入一致性是ONE，所以當Cassandra所有14張表同時錄入數據時，會出現Cassandra集羣過載情況，而MapReduce又沒有失敗後休眠重試的機制，所以整個錄入過程當Cassandra過載時會出現髒數據，客戶端從Cassandra多次全量導出數據就會出現不一致，出現嚴重的數據不一致問題。
解決：修改MapReduce接口的寫入一致性爲QUORUM或者ALL，並且在失敗後捕獲異常並休眠重試，其中休眠的目的是變相的降低負載，避免髒數據的出現，從而解決數據不一致的問題。
5.3 problem:Cassandra需要定期和手動執行repair等運維操作，否則可能出現髒數據
現象描述：當用戶刪除數據時，碰巧保存該數據的副本的那個節點down掉，並且一直到gc_grace_seconds（默認是10天，可以配置）這個時間過後才修復並再次加入集羣中，如果沒有執行 repair 操作，就可能出現髒數據。
解決：需要定期和手動執行 repair 等運維操作。
5.4 problem:Cassandra無法獲取一張表的總記錄數
現象描述：
解決：這個是Cassandra的一個特點，Cassandra開發者不認爲是一個問題，故無法解決
5.5 problem: cassandra集羣產生長時間的GC
現象描述:Cassandra進行大量導出操作,由於沒有用flash卡，並且只有一塊磁盤 性能會比預計有較大的偏差，也造成了較大的GC 情況，導致了Cassandra的異常。
解決: 設備添加flash卡 && 修改配置，file_cache_size_in_mb從512M增加到2048M，增大讀取sstable的緩存，提供查詢性能