【Cassandra】日常运维
在之前公司有幸用到了cassandra并且具有一定程度的数据量，所有不免出现许多问题，从而进行解决，在此统一归纳，以便自己回顾，也供大家一起研究学习，实际ip或一些敏感信息已手动脱敏。
目录
1.平台日常检查、监控内容
2.权限管理
3.备份还原
4.集群迁移(全量)
4.1 方案1：使用sstableloader来做集群间数据迁移
4.2 方案2：利用集群节点的增加和移除来平滑切换集群数据
4.3 方案3：全量数据的导入导出
5.遇到的问题
5.1 problem:超大组导致数据热点问题
5.2 problem:Cassandra数据不一致
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的缓存，提供查询性能