【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的缓存，提供查询性能