主页 / dba / 问题

问题[cassandra](dba)

Martin Hope
adinas
Asked: 2024-12-17 17:58:10 +0800 CST
  • 6

我认为 Cassandra 4.1.7 表中的墓碑不会被删除。

该表的 gc_grace_seconds = 345600

即使在运行之后nodetool garbagecollect（删除后远晚于 4 天），如果我运行，nodetool tablestats我会得到以下结果：

在此处输入图片描述

执行垃圾收集后，磁盘大小也不会减少。

我不确定我过去是否跑过nodetool compact（我想这意味着我需要继续使用它？）

附带问题，如何让 tablestats 返回更新的信息（而不是从 2024-12-12 开始）

谢谢

cassandra
Martin Hope
adinas
Asked: 2024-10-28 22:43:50 +0800 CST
  • 6

我已经在我的 Linux 机器（Ubutnu）上安装了 Cassandra。

我安装了 OpenJDK 11，然后安装了 JDK 17 并将其设置为默认值并重新启动了 Cassandra。

Java 精选

我可以看到 /var/log/cassandra/system.log 中正在使用新版本 Cassandra 日志

一切正常，但我不清楚使用 17 是否被视为“实验性的”或是否比 11 更可取？

cassandra
Martin Hope
jakob
Asked: 2024-10-08 20:53:13 +0800 CST
  • 6

我们在这样的环境中操作 Cassandra，其中运行 Cassandra 的主机偶尔会在未正确关闭的情况下断电。我们可以接受丢失数据，但我们的问题是，在极少数情况下，Cassadra在非正常关闭后无法启动。然后由于提交日志损坏而导致启动失败：

ERROR [main] 2024-05-02 12:39:13,834 JVMStabilityInspector.java:196 - Exiting due to error while processing commit log during initialization.
org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException: Mutation checksum failure at 2378 in Next section at 2016 in CommitLog-7-1714580480939.log
        at org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:387)
        at org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:244)
        at org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:147)
        at org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:191)
        at org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:223)
        at org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:204)
        at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:353)
        at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:744)
        at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)

我们发现了“ cassandra.commitlog.ignorereplayerrors ”选项，它似乎会影响处理提交日志时的错误处理。关于此设置的一些问题：

  1. 如果可以接受丢失写入 Cassandra 的数据，那么启用此设置是否安全？
  2. 启用此设置时是否会忽略所有提交日志损坏，或者 Cassandra 仍然无法启动？请注意，我们的关键要求是 Cassandra 能够在断电后无需人工干预即可启动。
  3. 提交日志损坏发生后是否应该执行“nodetool repair”？
cassandra
Martin Hope
Nahush
Asked: 2024-10-01 01:53:03 +0800 CST
  • 6

是否有任何 DSE 6.x 版本支持 C* 4.x sstable 格式 (-nb-)？我想使用 sstableloader 将数据从 apache C* 4.x 加载到 DSE 6.x。将 C* 4.x sstables 导入 DSE 6.x 的最佳推荐升级路径（兼容）是什么？

  • DSE 6.x - 协议 DSE_V2 - （sstable 格式-bb-）
  • C* 4.x - 协议 v5 - （sstable 格式-nb-）

使用 Apache Cassandra 4.x sstableloader -> 即使按照文档application.conf添加( v4) ，客户端仍无法协商协议。无论提供何种兼容驱动程序，错误仍然相同：EXTRA_CLASSPATH

com.datastax.driver.core.exceptions.UnsupportedProtocolVersionException: \
  [/10.x.x.x:9042] Host does not support protocol version V6 but V5.

使用 DSE 6.8.x sstableloader -> 从 4.x 导入-nb-sstables 完成且无错误，但 DSE 集群的 /data 路径中没有文件并SELECT * from TABLE返回 0 行。使用nodetool refresh和nodetool import似乎没有帮助。

Datastax 文档中没有关于 C* 4.x 与 DSE 兼容性的明确信息。任何与此相关的链接或信息都会有所帮助。谢谢！

cassandra
Martin Hope
Andreas Larfors
Asked: 2024-08-05 18:39:31 +0800 CST
  • 5

看起来 Cassandra 41x 的 rpm 存储库的一些配置已更改，这意味着只有版本 4.1~alpha1-1 可用。我们正在使用 Ansible 部署包含 Cassandra 的堆栈。我们的部署中已修复 Cassandra 版本 4.1.5。部署在几周前还可以运行，但今天我休假回来后就无法运行了，错误消息：

No package cassandra-4.1.5-* available.

检查存储库https://apache.jfrog.io/ui/native/cassandra-rpm/41x/我可以看到列出了版本 4.1.5，但是执行 yum search / yum list 时未返回该版本：

$ yum list cassandra --showduplicates
Available Packages
cassandra.noarch 4.1~alpha1-1 cassandra
cassandra.src 4.1~alpha1-1 cassandra

2024-08-03（三天前）在目录https://apache.jfrog.io/ui/native/cassandra-rpm/41x/repodata中修改了一系列文件- 这可能是导致这种行为的变化吗？

我们现在无法安装除 alpha 版本之外的任何版本的 Cassandra 4.1.x。

$ cat /etc/yum.repos.d/cassandra.repo
[cassandra]
baseurl = https://redhat.cassandra.apache.org/41x/
enabled = 1
gpgcheck = 1
gpgkey = https://downloads.apache.org/cassandra/KEYS
name = apache cassandra repository
repo_gpgcheck = 1

附注：最新的 Cassandra 安装文档引用了 42x，但这在远程存储库中不存在：https://cassandra.apache.org/doc/latest/cassandra/installing/installing.html

cassandra
Martin Hope
Soheil Rahsaz
Asked: 2024-08-01 21:12:07 +0800 CST
  • 5

概括

我创建了一个有 3 个节点的场景，其中 1 个节点与其他节点不同步，当我连接到该节点时，我发现它正在检索不应该检索的数据，因为它正在从另一个节点读取数据（我相信我使用驱动程序连接到的节点是协调器节点）。

我不知道我错过了什么以及为什么Cassandra要这样做？

步骤：

  1. 使用 docker 和 cassandra 版本 4.1.5 创建一个具有默认设置且无身份验证的 3 个节点的集群，并使用CASSANDRA_ENDPOINT_SNITCH=GossipingPropertyFileSnitch
docker run --name cass1 -d -p 19001:9042 --network=casscluster -e CASSANDRA_CLUSTER_NAME=chat -e CASSANDRA_DC=dc1 -e CASSANDRA_RACK=rack1 -e CASSANDRA_ENDPOINT_SNITCH=GossipingPropertyFileSnitch -e CASSANDRA_SEEDS="cass1,cass2" -e CASSANDRA_LISTEN_ADDRESS="cass1" -e CASSANDRA_BROADCAST_ADDRESS="cass1" cassandra:4.1.5
docker run --name cass2 -d -p 19002:9042 --network=casscluster -e CASSANDRA_CLUSTER_NAME=chat -e CASSANDRA_DC=dc1 -e CASSANDRA_RACK=rack1 -e CASSANDRA_ENDPOINT_SNITCH=GossipingPropertyFileSnitch -e CASSANDRA_SEEDS="cass1,cass2" -e CASSANDRA_LISTEN_ADDRESS="cass2" -e CASSANDRA_BROADCAST_ADDRESS="cass2" cassandra:4.1.5
docker run --name cass3 -d -p 19003:9042 --network=casscluster -e CASSANDRA_CLUSTER_NAME=chat -e CASSANDRA_DC=dc1 -e CASSANDRA_RACK=rack1 -e CASSANDRA_ENDPOINT_SNITCH=GossipingPropertyFileSnitch -e CASSANDRA_SEEDS="cass1,cass2" -e CASSANDRA_LISTEN_ADDRESS="cass3" -e CASSANDRA_BROADCAST_ADDRESS="cass3" cassandra:4.1.5
  1. 在每个节点中，禁用来自 yml 的提示切换并重新启动节点（检查每个节点以nodetool statushandoff确保hinted_hand_off已禁用）
nodetool statushandoff
Hinted handoff is not running
  1. 创建复制因子为 3 的键空间。
create keyspace testak WITH REPLICATION = {
    'class' : 'NetworkTopologyStrategy',
    'dc1' : 3
    };
  1. 创建表并禁用speculative_retry（这样如果查询花费的时间太长它就不会从其他节点读取）
create table testak.mooz
(
    userid int,
    chatid int,
    name   text,
    primary key (userid, chatid)
);
alter table testak.mooz with speculative_retry = 'none';
  1. 停止节点 3
  2. 插入节点 1
insert into testak.mooz (userid, chatid) values (1, 1);
insert into testak.mooz (userid, chatid) values (2, 1);
insert into testak.mooz (userid, chatid) values (3, 1);
insert into testak.mooz (userid, chatid) values (4, 1);
insert into testak.mooz (userid, chatid) values (5, 1);
insert into testak.mooz (userid, chatid) values (6, 1);
insert into testak.mooz (userid, chatid) values (7, 1);
insert into testak.mooz (userid, chatid) values (8, 1);
insert into testak.mooz (userid, chatid) values (9, 1);
insert into testak.mooz (userid, chatid) values (10, 1);
  1. 启动节点3
  2. 使用外部 cqlsh 连接到节点 3 docker run --name cqlsh --rm -it --network=casscluster nuvo/docker-cqlsh cqlsh cass3 9042 --cqlversion=3.4.6
  3. 设置一致性一 CONSISTENCY ONE
  4. 追踪 TRACING ON
  5. 选择 1 行 select * from testak.mooz where userid = 1 and chatid = 1;

因为复制因子是 3 并且我有 3 个节点，所以我期望所有节点都认为它们拥有所有数据并且不需要从另一个节点查询数据，但是通过多次发出查询，我发现有时请求会转到其他节点并实际检索到不应该检索的数据，因为节点 3 存在不一致并且没有真实的记录数据。

在此处输入图片描述 这是一个屏幕截图，显示它正在从另一个节点检索数据。

注意：大多数时候（~90%）它不会从另一个节点读取数据。

更新

后来我使用设置了日志记录级别nodetool setlogginglevel org.apache.cassandra ALL并查看了debug.log，这是当 cassandra 决定从另一个节点读取数据时的日志：

TRACE [Native-Transport-Requests-1] 2024-07-18 08:47:01,109 CoordinatorWarnings.java:49 - CoordinatorTrackWarnings.init()
TRACE [Native-Transport-Requests-1] 2024-07-18 08:47:01,110 Dispatcher.java:164 - Received: QUERY select * from testak.mooz where userid = 1 and chatid = 1; [pageSize = 100] at consistency ONE, v=4/v4
TRACE [Native-Transport-Requests-1] 2024-07-18 08:47:01,110 QueryProcessor.java:251 - Process SelectStatement[aggregationSpecFactory=<null>,bindVariables=[],isReversed=false,limit=<null>,..(truncated long log line)
TRACE [Native-Transport-Requests-1] 2024-07-18 08:47:01,111 ReadCallback.java:90 - Blockfor is 1; setting up requests to org.apache.cassandra.locator.ReplicaPlan$SharedForTokenRead@74da23a8
TRACE [Native-Transport-Requests-1] 2024-07-18 08:47:01,111 MessagingService.java:401 - cass3/172.20.0.4:7000 sending READ_REQ to 2781@/172.20.0.3:7000
TRACE [Native-Transport-Requests-1] 2024-07-18 08:47:01,111 AbstractReadExecutor.java:226 - Decided not to speculate as 9223372036854775807 > 5000000
TRACE [Native-Transport-Requests-1] 2024-07-18 08:47:01,122 CoordinatorWarnings.java:80 - CoordinatorTrackWarnings.done() with state {}
TRACE [Native-Transport-Requests-1] 2024-07-18 08:47:01,122 CoordinatorWarnings.java:61 - CoordinatorTrackWarnings.reset()
TRACE [Native-Transport-Requests-1] 2024-07-18 08:47:01,122 Dispatcher.java:214 - Responding: ROWS [userid(testak, mooz), org.apache.cassandra.db.marshal.Int32Type][chatid(testak, mooz), org.apache.cassandra.db.marshal.Int32Type][name(testak, mooz), org.apache.cassandra.db.marshal.UTF8Type]
 | 1 | 1 | null
---, v=4/v4

但是，当从节点本身读取数据时，sending READ_REQ我看到的不是带有 的行，而是这一行：

TRACE [Native-Transport-Requests-1] 2024-07-18 08:47:49,248 EndpointMessagingVersions.java:67 - Assuming current protocol version for cass3/172.20.0.4:7000
TRACE [Native-Transport-Requests-1] 2024-07-18 08:47:49,248 AbstractReadExecutor.java:158 - reading data locally

更新2

在cass3上运行nodetool getendpoints testak mooz 1：

172.20.0.3
172.20.0.4
172.20.0.2

nodetool status testak：

Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load        Tokens  Owns (effective)  Host ID                               Rack
UN  172.20.0.3  227.48 KiB  16      100.0%            2a4a84a4-1894-488a-8661-680cf818384b  rack1
UN  172.20.0.4  232.56 KiB  16      100.0%            9ed9d3f6-13e0-424f-bf52-1bd359d8a26e  rack1
UN  172.20.0.2  281.54 KiB  16      100.0%            68de8980-ab63-4745-85b1-6b98636ea9af  rack1

nodetool describecluster：

Cluster Information:
        Name: chat
        Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
        DynamicEndPointSnitch: enabled
        Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
        Schema versions:
                629e0d12-c942-3eeb-bce3-5616a291ae90: [172.20.0.4, 172.20.0.2, 172.20.0.3]

Stats for all nodes:
        Live: 3
        Joining: 0
        Moving: 0
        Leaving: 0
        Unreachable: 0

Data Centers:
        dc1 #Nodes: 3 #Down: 0

Database versions:
        4.1.5: [172.20.0.4:7000, 172.20.0.2:7000, 172.20.0.3:7000]

Keyspaces:
        system_auth -> Replication class: SimpleStrategy {replication_factor=1}
        testak -> Replication class: NetworkTopologyStrategy {dc1=3}
        system_distributed -> Replication class: SimpleStrategy {replication_factor=3}
        system_traces -> Replication class: SimpleStrategy {replication_factor=2}
        system_schema -> Replication class: LocalStrategy {}
        system -> Replication class: LocalStrategy {}
cassandra
Martin Hope
Sai
Asked: 2024-07-13 03:47:31 +0800 CST
  • 5

我们在 GKE 上运行了一个 Cassandra 集群，该集群具有 32 个 CPU 节点池和 SSD 磁盘。当前集群大小接近 1 PB，每个节点平均使用 10 TB 分配的 SSD 磁盘上的 5 TB。该集群包含 200 个节点，每个节点有 10 TB 磁盘，总共分配了 2 PB 大小。

这个集群规模，维护成本是比较大的，那么如何才能低成本的实现这么大的集群容灾呢？

我正在考虑的一个选项是在不同区域创建一个新的数据中心，副本数为 1（RF1）。虽然不建议这样做，但它至少会将集群大小减少三倍。

任何建议将不胜感激。

cassandra