Cassandra 最佳实践系列(4) - 管理篇之一

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
云原生多模数据库 Lindorm,多引擎 多规格 0-4节点
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: Cassandra之系统管理命令介绍之第一部分

基本集群运维操作

集群信息获取

cassandra项目官方没有给我们提供一个中控的地方让我们获取集群的相关信息,但是由于cassandra是对等的,且集群种节点通过gossip可以拿到集群的整个视图,所以如果想要获取得到集群的整个视图信息也是可以通过单节点的nodetool工具获取得到我们将获取的信息做一下分类:

1.nodetool describecluster

显示集群的基本信息,包括:集群的名字(cassandra.yaml里面配置的)、Snitch类型、是否开启dynamicendpointsnitch、集群partitioner、schmema version,因为我们是通过gossip进行信息同步,可能会存在某些节点一时间与另外节点schema version不一致,可以通过这个命令判断。

eg:

Cluster Information:
    Name: Test Cluster
    Snitch: org.apache.cassandra.locator.SimpleSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
    Schema versions:
        ea63e099-37c5-3d7b-9ace-32f4c833653d: [127.0.0.1]

2../nodetool describering keyspace

打印出给定的keyspace以及与其相关的token ring信息,此处我的token_number设置为2,方便展示信息,如果我们希望想要知道某个keyspace与其相关的token信息,可以通过这个命令获取。

eg:

Schema Version:ea63e099-37c5-3d7b-9ace-32f4c833653d
TokenRange:
    TokenRange(start_token:-7410294471124200252, end_token:2438009623152110684, endpoints:[127.0.0.1], rpc_endpoints:[127.0.0.1], endpoint_details:[EndpointDetails(host:127.0.0.1, datacenter:datacenter1, rack:rack1)])
    TokenRange(start_token:2438009623152110684, end_token:-7410294471124200252, endpoints:[127.0.0.1], rpc_endpoints:[127.0.0.1], endpoint_details:[EndpointDetails(host:127.0.0.1, datacenter:datacenter1, rack:rack1)])

3.nodetool gossipinfo

显示集群的gossip信息,下面显示的是一个三节点的集群中,各个节点相关的gossip信息输出:

/192.168.0.250
  generation:1578559963
  heartbeat:289
  STATUS:18:NORMAL,-1000610182680759021
  LOAD:273:111238.0
  SCHEMA:20:ea63e099-37c5-3d7b-9ace-32f4c833653d
  DC:6:datacenter1
  RACK:8:rack1
  RELEASE_VERSION:4:3.11.4
  RPC_ADDRESS:3:127.0.0.1
  NET_VERSION:1:11
  HOST_ID:2:012ed1eb-0dac-4562-9812-415a7b58e6d6
  RPC_READY:32:true
  TOKENS:17:<hidden>
/192.168.0.245
  generation:1578560055
  heartbeat:196
  STATUS:58:NORMAL,-112189776392027338
  LOAD:153:115665.0
  SCHEMA:20:ea63e099-37c5-3d7b-9ace-32f4c833653d
  DC:6:datacenter1
  RACK:8:rack1
  RELEASE_VERSION:4:3.11.4
  RPC_ADDRESS:3:127.0.0.1
  NET_VERSION:1:11
  HOST_ID:2:0dbd4aca-7dd4-4833-b3db-c7d9dda0aef9
  RPC_READY:68:true
  TOKENS:57:<hidden>
/192.168.0.246
  generation:1578559991
  heartbeat:260
  STATUS:56:NORMAL,-1045048566066926798
  LOAD:213:91038.0
  SCHEMA:18:ea63e099-37c5-3d7b-9ace-32f4c833653d
  DC:6:datacenter1
  RACK:8:rack1
  RELEASE_VERSION:4:3.11.4
  RPC_ADDRESS:3:127.0.0.1
  NET_VERSION:1:11
  HOST_ID:2:3ca695aa-edd2-435c-b9ee-89e143648351
  RPC_READY:66:true
  TOKENS:55:<hidden>

上述信息表示了集群种三个节点对应的相关gossip信息,就第一个节点解释下相关的信息意义:

  • 第一行的ip 192.168.0.250表示的是对应节点进行gossip交互ip信息;
  • generation 表示的每个节点的相关的generation信息,节点的generation是交互信息的一部分,最初是当前时间的秒数(从1970年UTC时间开始到现在);
  • heartbeat 表示在当前这个generation下面执行了多少次gossip交互,默认的情况下,每隔1s会主动进行一次gossip交互任务,这里看来是经过289秒;
  • 余下都是集群的状态相关的信息:在Cassandra里面都是applicationstate里的VersionedValue,可以参考下面这个图:

​ 我们可以看到的是接下来的模块都是string0:number0:string1,其中string0 的格式就是STATUS、LOAD、SCHEMA等等这些需要的状态字符串,number0是这些状态每个一次变更就加1的version版本号,我们主要介绍是string1的具体意义;但是不是说string0 和number0 不重要。

  • STATUS:表示的是对应的ip节点的状态,有9种状态(3.11.4版本代码),BOOT、BOOT_REPLACE、NORMAL、shutdown、removing、removed、LEAVING、LEFT、MOVING;
  • LOAD: 表示对应节点的节点的磁盘存储容量,单位是byte;
  • SCHEMA: 对应节点上面schema keyspace下面的所有table 按照顺序计算出来的一个md5值转换为的一个UUID;
  • DC: 对应节从属的datacenter;
  • RACK:对应节点从属的rack;
  • RELEASE_VERSION:节点机器的release 软件包的版本号;
  • RPC_ADDRESS: RPC的地址
  • NET_VERSION:这里主要是我们的网络版本号,如果是force使用3.0 的协议版本就是10,否则是11;
  • HOST_ID:节点的hostid,基于对应节点的ip等计算
  • RPC_READY: 如果9042的端口或者9142(ssl)的rpc端口已经准备初始化完成,可以接收响应就是true;
  • TOKENS:本来是对应节点负责的tokens,但是在这里显示的时候是hindden表示。

gossip1

4.nodetool ring

展示集群的token ring环信息,由于我这里的vnode用了默认的256,所以只列部分数据:

Datacenter: datacenter1
==========
Address        Rack        Status State   Load            Owns                Token
                                                                              9171192753316195244
192.168.0.245  rack1       Up     Normal  266.49 KiB      64.99%              -9183757132875531958
192.168.0.250  rack1       Up     Normal  242.16 KiB      70.75%              -9159199665119898622
192.168.0.250  rack1       Up     Normal  242.16 KiB      70.75%              -9135911702874518408
192.168.0.250  rack1       Up     Normal  242.16 KiB      70.75%              -9120077450536389482
192.168.0.246  rack1       Up     Normal  238.16 KiB      64.26%              -9106101311114100850
192.168.0.246  rack1       Up     Normal  238.16 KiB      64.26%              -9069141338515824351
  • Datacenter : 对应的datacenter的名字,这里使用的是默认的;
  • Address、Rack:表示的是对应节点以及从属的rack信息;
  • Status 、State :对应的节点的状态:Up、Down;Normal、leaving等等;
  • Load:集群的对应节点的load信息,参考上面的gossip info的输出信息;
  • Owns:这个ip负责的tokens的范围占整个数据范围的占比多少
  • Token:对应负责的token是哪些
目录
相关文章
|
6月前
|
SQL 分布式计算 关系型数据库
阿里云E-MapReduce Trino专属集群外连引擎及权限控制踩坑实践
本文以云厂商售后技术支持的角度,从客户的需求出发,对于阿里云EMR-Trino集群的选型,外连多引擎的场景、Ldap以及Kerberos鉴权等问题进行了简要的实践和记录,模拟客户已有的业务场景,满足客户需求的同时对过程中的问题点进行解决、记录和分析,包括但不限于Mysql、ODPS、Hive connector的配置,Hive、Delta及Hudi等不同表格式读取的兼容,aws s3、阿里云 oss协议访问异常的解决等。
|
16天前
|
运维 监控 安全
ClickHouse安全与管理:从基础到高级
【10月更文挑战第26天】在大数据时代,数据的安全性和系统的稳定性是企业成功的关键因素之一。作为一款高性能的列式数据库,ClickHouse 不仅在数据处理方面表现出色,同时也提供了多种安全和管理功能,以确保数据的安全性和系统的可靠性。本文将从我个人的角度出发,探讨如何加强 ClickHouse 的安全性以及如何进行日常运维管理。
39 2
|
5月前
|
监控 NoSQL 数据建模
使用Apache Cassandra进行分布式数据库管理的技术实践
【6月更文挑战第5天】本文探讨了使用Apache Cassandra进行分布式数据库管理的技术实践。Cassandra是一款高性能、可扩展的NoSQL数据库,适合大规模、高并发场景。文章介绍了其高可扩展性、高性能、高可用性和灵活数据模型等核心特性,并详细阐述了环境准备、安装配置、数据建模与查询以及性能优化与监控的步骤。通过本文,读者可掌握Cassandra的运用,适应不断增长的数据需求。
|
5月前
|
存储 NoSQL 数据管理
MongoDB关系处理:优化数据管理、提升性能的最佳实践
MongoDB关系处理:优化数据管理、提升性能的最佳实践
|
存储 监控 NoSQL
Cassandra应用场景
Cassandra应用场景
|
存储 缓存 Prometheus
统一观测丨使用 Prometheus 监控 Cassandra 数据库最佳实践
统一观测丨使用 Prometheus 监控 Cassandra 数据库最佳实践
|
SQL 存储 关系型数据库
分布式 PostgreSQL 集群(Citus)官方示例 - 多租户应用程序实战
分布式 PostgreSQL 集群(Citus)官方示例 - 多租户应用程序实战
506 0
分布式 PostgreSQL 集群(Citus)官方示例 - 多租户应用程序实战
|
存储 NoSQL Java
|
存储 运维 监控
大数据数据存储的搜索引擎Elasticsearch的集群运维的集群扩展
Elasticsearch是一个可扩展的搜索引擎,可以在同一个集群中部署多个Elasticsearch节点,以提高性能和可用性。
79 0
|
SQL 存储 消息中间件
一面数据: Hadoop 迁移云上架构设计与实践
Hadoop 技术栈,一直是企业自建大数据平台的首选。随着企业数据量的指数级增长,云计算时代的到来,企业对存储的弹性、运维及 TCO 都提出了更高要求。曾经自建 Hadoop 大数据平台的企业正逐步将大数据平台迁移至云上。
780 1
一面数据: Hadoop 迁移云上架构设计与实践