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

你可能感兴趣的:(【Cassandra】日常运维)