关于【cassandra】的问题- 第1页

Lis Shimoni

Asked: 2025-01-27 22:32:55 +0800 CST

如何在不影响性能的情况下启用静态数据加密？

5

我希望为我的 Cassandra 集群添加加密，以提高数据安全性。以下是我的设置细节以及我遇到的问题：

集群详情：8 个节点，每个节点都有 TB 级的数据。

尝试：尝试添加加密的 EBS 卷并更改数据路径，但这导致整个集群的性能显著滞后。添加了配置了加密的新节点（用于 SSTable 和节点间加密的 JKS），但这造成了严重中断并使整个集群不稳定。

面临的挑战：迁移到加密 EBS 卷时延迟严重。引入带加密的新节点时集群不稳定。

问题：在 Cassandra 集群中启用加密（静态数据）的推荐方法是什么，以最短的停机时间并且不会严重影响性能？

任何见解或最佳实践都将不胜感激！

Коля Курик

Asked: 2025-01-25 00:17:30 +0800 CST

Cassandra 4.1 中已弃用的配置属性

5

我需要一些建议，我将 Ubuntu 22.04 上拥有 7 个节点的 cassandra 集群从 4.0.5 升级到了 4.1.7，我是这样做的：

停止 Cassandra，步骤：nodetool drip、nodetool stopdaemon
编辑 /etc/apt/sources.list.d/cassandra.sources.list，将 deb http://www.apache.org/dist/cassandra/debian 40x main 替换为 deb https://debian.cassandra.apache.org 41x main
升级：apt-get install --only-upgrade Cassandra
重新启动 systemctl restart Cassandra

我对每个节点都继续执行此操作。之后我收到了警告：

WARN  08:50:08,758 [dynamic_snitch_reset_interval_in_ms, tracetype_query_ttl, request_timeout_in_ms, row_cache_size_in_mb, counter_write_request_timeout_in_ms, column_index_size_in_kb, trickle_fsync_interval_in_kb, cas_contention_timeout_in_ms, key_cache_size_in_mb, range_request_timeout_in_ms, enable_transient_replication, dynamic_snitch_update_interval_in_ms, column_index_cache_size_in_kb, write_request_timeout_in_ms, index_summary_resize_interval_in_minutes, permissions_validity_in_ms, max_hint_window_in_ms, enable_user_defined_functions, enable_sasi_indexes, read_request_timeout_in_ms, enable_drop_compact_storage, enable_legacy_ssl_storage_port, credentials_validity_in_ms, batch_size_warn_threshold_in_kb, index_summary_capacity_in_mb, commitlog_sync_period_in_ms, batchlog_replay_throttle_in_kb, windows_timer_interval, enable_scripted_user_defined_functions, commitlog_segment_size_in_mb, sstable_preemptive_open_interval_in_mb, tracetype_repair_ttl, roles_validity_in_ms, enable_materialized_views, prepared_statements_cache_size_mb, hinted_handoff_throttle_in_kb, compaction_large_partition_warning_threshold_mb, truncate_request_timeout_in_ms, slow_query_log_timeout_in_ms, hints_flush_period_in_ms, counter_cache_size_in_mb, max_hints_file_size_in_mb, compaction_throughput_mb_per_sec, batch_size_fail_threshold_in_kb] parameters have been deprecated. They have new names and/or value format; For more information, please refer to NEWS.txt

正如我在文档https://cassandra.apache.org/doc/4.1/cassandra/configuration/cass_yaml_file.html中看到的那样，我应该在以下内容中注释此参数cassandra.yaml：

dynamic_snitch_reset_interval_in_ms
tracetype_query_ttl
请求超时（单位：毫秒）
row_cache_size_in_mb
counter_write_request_timeout_in_ms
列索引大小（单位：kb）
trickle_fsync_interval_in_kb
cas_contention_timeout_in_ms
key_cache_size_in_mb
范围请求超时（单位：毫秒）
启用瞬时复制
dynamic_snitch_update_interval_in_ms
列索引缓存大小（单位：kb）
写入请求超时（毫秒）
index_summary_resize_interval_in_minutes
权限有效性（单位：毫秒）
max_hint_window_in_ms
启用用户定义函数
启用_sasi_索引
读取请求超时（毫秒）
启用删除压缩存储
启用旧版 SSL 存储端口
凭证有效性（单位：毫秒）
批次大小警告阈值（单位：kb）
index_summary_capacity_in_mb
commitlog_sync_period_in_ms
batchlog_replay_throttle_in_kb
windows_timer_interval
启用脚本用户定义函数
commitlog_segment_size_in_mb
tracetype_repair_ttl
角色有效性（单位：毫秒）
启用物化视图
准备好的语句缓存大小
hinted_handoff_throttle_in_kb
压缩_大型分区_警告_阈值_mb
截断请求超时（毫秒）
slow_query_log_timeout_in_ms
hints_flush_period_in_ms
counter_cache_size_in_mb
max_hints_file_size_in_mb
压缩吞吐量
批次大小_失败阈值_单位：kb

并sstable_preemptive_open_interval_in_mb改为sstable_preemptive_open_interval

对吧？

stratacast1

Asked: 2025-01-18 08:47:44 +0800 CST

使用 Ansible 自动升级，对抗 APT 自动启动 Cassandra 服务

5

我正准备将节点从 3.11.17 升级到 4.1.7。我已经手动成功完成了一些开发节点的升级，但我想使用 Ansible 使此过程更具可重复性。我在 Ubuntu 服务器上运行，因此我必须与 apt 自动启动服务作斗争。想知道在不让 apt 向我抛出默认文件并可能弄乱东西的情况下，进行这些升级的最正统流程是什么。我的想法是：

排空并停止一个节点
我必需的 cassandra.yaml 和 rack 属性文件中的模板
安装 Cassandra 4.1.7
应对 apt 自动启动 cassandra

这是否意味着灾难？我的数据不在来自软件包维护者的配置的默认路径 (/var/lib/cassandra) 中，并且我的一些配置变量在 4.1 中不再存在，所以我预计 Cassandra 会在启动时崩溃，并看到无法识别的变量（我在开发测试中遇到过）。我真正想要的是安装 Cassandra 并在开始之前仔细检查一下，但我没有这种奢侈。在多次测试中，成功安装后立即停止 Cassandra 不起作用，Cassandra 会继续存在。

adinas

Asked: 2024-12-17 17:58:10 +0800 CST

Cassandra 数据库中的墓碑未被删除

6

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

该表的 gc_grace_seconds = 345600

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

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

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

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

谢谢

Коля Курик

Asked: 2024-11-15 23:01:18 +0800 CST

如何在 Cassandra 4.0.5 上升级 Java 版本

6

我想将 Cassandra 集群上的 Java 版本从 8 升级到 11。如何更好地做到这一点？我可以逐个节点升级 Java 版本吗？例如：

停止1个节点
升级 Java
启动1个节点

并对另一个节点重复这些步骤，或者我是否需要在升级后修复节点。现在节点：

Cassandra 4.0.5
Java 8

我会很高兴听取您的建议。

adinas

Asked: 2024-11-03 18:26:05 +0800 CST

5.0 上的架构更改导致 gossip 失败，oacdb.db.TypeSizes.sizeof() 返回“AssertionError: null”

6

我们有一个 2 节点集群（我知道 3 是建议的最小值），它已经运行 Cassandra 3 和 4 多年，没有发生任何事故。

上周我们将两个节点都升级到了 Cassandra 5。

自那时起，节点之间似乎出现了流言蜚语和沟通问题。尤其是在更新架构时（例如创建或删除表时）。

这是在进行架构更改（删除表）之后立即出现的调试日志：

INFO  [Native-Transport-Requests-1] 2024-11-03 09:48:04,021 Keyspace.java:379 - Creating replication strategy r_internal params KeyspaceParams{durable_writes=true, replication=ReplicationParams{class=org.apache.cassandra.locator.SimpleStrategy, replication_factor=2}}
DEBUG [Native-Transport-Requests-1] 2024-11-03 09:48:04,064 MigrationCoordinator.java:430 - Reported schema a47919aa-79b3-362c-b023-d8ac89671885 at endpoint /10.10.2.27:7000
DEBUG [MigrationStage:1] 2024-11-03 09:48:04,070 MigrationCoordinator.java:749 - Pushing schema mutations: [Mutation(keyspace='system_schema', key='72617976656e5f696e7465726e616c', modifications=[
  [system_schema.columns] key=r_internal partition_deletion=deletedAt=-9223372036854775808, localDeletion=9223372036854775807 columns=[[] | []]
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=cdate |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=device_id |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=event_timestamp |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=info |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=input |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=node_id |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=output |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=server |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=unique_flow_process |
  [system_schema.indexes] key=r_internal partition_deletion=deletedAt=-9223372036854775808, localDeletion=9223372036854775807 columns=[[] | []]
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, index_name=p1489_log_node_input_output_unique_flow_process_idx |
  [system_schema.keyspaces] key=r_internal partition_deletion=deletedAt=-9223372036854775808, localDeletion=9223372036854775807 columns=[[] | [durable_writes replication]]
    Row[info=[ts=1730627238890000] ]: EMPTY | [durable_writes=true ts=1730627238890000], [replication=0000000200000005636c6173730000002b6f72672e6170616368652e63617373616e6472612e6c6f6361746f722e53696d706c655374726174656779000000127265706c69636174696f6e5f666163746f720000000132 ts=1730627238890000]
  [system_schema.tables] key=r_internal partition_deletion=deletedAt=-9223372036854775808, localDeletion=9223372036854775807 columns=[[] | []]
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output |
])]
DEBUG [MigrationStage:1] 2024-11-03 09:48:04,071 MigrationCoordinator.java:757 - Pushing schema mutations to /10.10.2.28:7000: [Mutation(keyspace='system_schema', key='72617976656e5f696e7465726e616c', modifications=[
  [system_schema.columns] key=r_internal partition_deletion=deletedAt=-9223372036854775808, localDeletion=9223372036854775807 columns=[[] | []]
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=cdate |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=device_id |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=event_timestamp |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=info |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=input |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=node_id |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=output |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=server |
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, column_name=unique_flow_process |
  [system_schema.indexes] key=r_internal partition_deletion=deletedAt=-9223372036854775808, localDeletion=9223372036854775807 columns=[[] | []]
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output, index_name=p1489_log_node_input_output_unique_flow_process_idx |
  [system_schema.keyspaces] key=r_internal partition_deletion=deletedAt=-9223372036854775808, localDeletion=9223372036854775807 columns=[[] | [durable_writes replication]]
    Row[info=[ts=1730627238890000] ]: EMPTY | [durable_writes=true ts=1730627238890000], [replication=0000000200000005636c6173730000002b6f72672e6170616368652e63617373616e6472612e6c6f6361746f722e53696d706c655374726174656779000000127265706c69636174696f6e5f666163746f720000000132 ts=1730627238890000]
  [system_schema.tables] key=r_internal partition_deletion=deletedAt=-9223372036854775808, localDeletion=9223372036854775807 columns=[[] | []]
    Row[info=[ts=-9223372036854775808] del=deletedAt=1730627238890000, localDeletion=1730627238 ]: table_name=p1489_log_node_input_output |
])]
ERROR [GossipStage:1] 2024-11-03 09:48:04,187 JVMStabilityInspector.java:70 - Exception in thread Thread[GossipStage:1,5,GossipStage]
java.lang.RuntimeException: java.lang.AssertionError
        at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
        at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
        at org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:430)
        at org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.AssertionError: null
        at org.apache.cassandra.db.TypeSizes.sizeof(TypeSizes.java:44)
        at org.apache.cassandra.gms.VersionedValue$VersionedValueSerializer.serializedSize(VersionedValue.java:365)
        at org.apache.cassandra.gms.VersionedValue$VersionedValueSerializer.serializedSize(VersionedValue.java:343)
        at org.apache.cassandra.gms.EndpointStateSerializer.serializedSize(EndpointState.java:344)
        at org.apache.cassandra.gms.EndpointStateSerializer.serializedSize(EndpointState.java:300)
        at org.apache.cassandra.gms.GossipDigestAckSerializer.serializedSize(GossipDigestAck.java:96)
        at org.apache.cassandra.gms.GossipDigestAckSerializer.serializedSize(GossipDigestAck.java:61)
        at org.apache.cassandra.net.Message$Serializer.payloadSize(Message.java:1088)
        at org.apache.cassandra.net.Message.payloadSize(Message.java:1131)
        at org.apache.cassandra.net.Message$Serializer.serializedSize(Message.java:769)
        at org.apache.cassandra.net.Message.serializedSize(Message.java:1111)
        at org.apache.cassandra.net.OutboundConnections.connectionTypeFor(OutboundConnections.java:215)
        at org.apache.cassandra.net.OutboundConnections.connectionFor(OutboundConnections.java:207)
        at org.apache.cassandra.net.OutboundConnections.enqueue(OutboundConnections.java:96)
        at org.apache.cassandra.net.MessagingService.doSend(MessagingService.java:473)
        at org.apache.cassandra.net.OutboundSink.accept(OutboundSink.java:70)
        at org.apache.cassandra.net.MessagingService.send(MessagingService.java:462)
        at org.apache.cassandra.net.MessagingService.send(MessagingService.java:437)
        at org.apache.cassandra.gms.GossipDigestSynVerbHandler.doVerb(GossipDigestSynVerbHandler.java:110)
        at org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
        at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
        ... 7 common frames omitted
DEBUG [GossipStage:1] 2024-11-03 09:48:04,187 HeapUtils.java:133 - Heap dump creation on uncaught exceptions is disabled.
DEBUG [GossipStage:1] 2024-11-03 09:48:04,187 HeapUtils.java:133 - Heap dump creation on uncaught exceptions is disabled.

线程 Thread[GossipStage:1,5,GossipStage] 中的异常Exception不断重复出现。

此时，运行nodetool status显示，每个节点都认为另一个节点已关闭

我通常需要耗尽并重新启动两个节点（我一个接一个地执行此操作），以便它们互相看到并显示它们的模式是同步的。

以下是nodetool gossipinfo的输出（重新启动节点后）

/10.10.2.27
  generation:1730627829
  heartbeat:939
  STATUS:23:NORMAL,-1656170799351181049
  LOAD:898:2.029075780322E12
  SCHEMA:17:a47919aa-79b3-362c-b023-d8ac89671885
  DC:13:dc1
  RACK:15:rack1
  RELEASE_VERSION:6:5.0.2
  INTERNAL_IP:11:10.10.2.27
  RPC_ADDRESS:5:10.10.2.27
  NET_VERSION:2:12
  HOST_ID:3:8be5925c-0436-4bc7-bd4c-0fb5dd8fc9e5
  RPC_READY:35:true
  INTERNAL_ADDRESS_AND_PORT:9:10.10.2.27:7000
  NATIVE_ADDRESS_AND_PORT:4:10.10.2.27:9042
  STATUS_WITH_PORT:22:NORMAL,-1656170799351181049
  SSTABLE_VERSIONS:7:big-nb
  TOKENS:21:<hidden>
/10.10.2.28
  generation:1730628138
  heartbeat:619
  LOAD:586:2.215579324507E12
  SCHEMA:17:a47919aa-79b3-362c-b023-d8ac89671885
  DC:13:dc1
  RACK:15:rack1
  RELEASE_VERSION:6:5.0.2
  NET_VERSION:2:12
  HOST_ID:3:c9e8a4f8-c7b2-4cac-994a-e8de50c9f358
  RPC_READY:35:true
  INTERNAL_ADDRESS_AND_PORT:9:10.10.2.28:7000
  NATIVE_ADDRESS_AND_PORT:4:10.10.2.28:9042
  STATUS_WITH_PORT:22:NORMAL,-2024247660995288657
  SSTABLE_VERSIONS:7:big-nb
  TOKENS:21:<hidden>

这里从第二个节点开始

/10.10.2.27
  generation:1730627829
  heartbeat:906
  LOAD:898:2.029075780322E12
  SCHEMA:17:a47919aa-79b3-362c-b023-d8ac89671885
  DC:13:dc1
  RACK:15:rack1
  RELEASE_VERSION:6:5.0.2
  NET_VERSION:2:12
  HOST_ID:3:8be5925c-0436-4bc7-bd4c-0fb5dd8fc9e5
  RPC_READY:35:true
  INTERNAL_ADDRESS_AND_PORT:9:10.10.2.27:7000
  NATIVE_ADDRESS_AND_PORT:4:10.10.2.27:9042
  STATUS_WITH_PORT:22:NORMAL,-1656170799351181049
  SSTABLE_VERSIONS:7:big-nb
  TOKENS:21:<hidden>
/10.10.2.28
  generation:1730628138
  heartbeat:584
  STATUS:23:NORMAL,-2024247660995288657
  LOAD:524:2.215537773956E12
  SCHEMA:17:a47919aa-79b3-362c-b023-d8ac89671885
  DC:13:dc1
  RACK:15:rack1
  RELEASE_VERSION:6:5.0.2
  INTERNAL_IP:11:10.10.2.28
  RPC_ADDRESS:5:10.10.2.28
  NET_VERSION:2:12
  HOST_ID:3:c9e8a4f8-c7b2-4cac-994a-e8de50c9f358
  RPC_READY:35:true
  INTERNAL_ADDRESS_AND_PORT:9:10.10.2.28:7000
  NATIVE_ADDRESS_AND_PORT:4:10.10.2.28:9042
  STATUS_WITH_PORT:22:NORMAL,-2024247660995288657
  SSTABLE_VERSIONS:7:big-nb
  TOKENS:21:<hidden>

当他们遇到问题时，这是在 10.10.2.28 上运行时nodetool gossinfo显示的内容：

/10.10.2.27
  generation:1730626480
  heartbeat:810
  LOAD:771:2.029304184276E12
  SCHEMA:17:9bcfb867-92ca-3144-92d7-da5fed3359d0
  DC:13:dc1
  RACK:15:rack1
  RELEASE_VERSION:6:5.0.2
  NET_VERSION:2:12
  HOST_ID:3:8be5925c-0436-4bc7-bd4c-0fb5dd8fc9e5
  RPC_READY:35:true
  INTERNAL_ADDRESS_AND_PORT:9:10.10.2.27:7000
  NATIVE_ADDRESS_AND_PORT:4:10.10.2.27:9042
  STATUS_WITH_PORT:22:NORMAL,-1656170799351181049
  SSTABLE_VERSIONS:7:big-nb
  TOKENS:21:<hidden>
/10.10.2.28
  generation:1730625184
  heartbeat:2523
  STATUS:23:NORMAL,-2024247660995288657
  LOAD:2513:2.214202366182E12
  SCHEMA:2243:a47919aa-79b3-362c-b023-d8ac89671885
  DC:13:dc1
  RACK:15:rack1
  RELEASE_VERSION:6:5.0.2
  INTERNAL_IP:11:10.10.2.28
  RPC_ADDRESS:5:10.10.2.28
  NET_VERSION:2:12
  HOST_ID:3:c9e8a4f8-c7b2-4cac-994a-e8de50c9f358
  RPC_READY:35:true
  INTERNAL_ADDRESS_AND_PORT:9:10.10.2.28:7000
  NATIVE_ADDRESS_AND_PORT:4:10.10.2.28:9042
  STATUS_WITH_PORT:22:NORMAL,-2024247660995288657
  SSTABLE_VERSIONS:7:big-nb
  INDEX_STATUS:2198:{"r_internal.p1643_log_node_input_output_unique_flow_process_idx":"BUILD_SUCCEEDED","r_internal.p1720_log_node_input_output_unique_flow_process_idx":"BUILD_SUCCEEDED","r_internal.p1479_log_node_input_output_unique_flow_process_idx":"BUILD_SUCCEEDED"...}
  TOKENS:21:<hidden>

adinas

Asked: 2024-10-28 22:43:50 +0800 CST

我应该将哪个版本的 Java 与 Cassandra 5.x 一起使用

6

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

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

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

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

jakob

Asked: 2024-10-08 20:53:13 +0800 CST

由于提交日志损坏，Cassandra 无法启动

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 ”选项，它似乎会影响处理提交日志时的错误处理。关于此设置的一些问题：

如果可以接受丢失写入 Cassandra 的数据，那么启用此设置是否安全？
启用此设置时是否会忽略所有提交日志损坏，或者 Cassandra 仍然无法启动？请注意，我们的关键要求是 Cassandra 能够在断电后无需人工干预即可启动。
提交日志损坏发生后是否应该执行“nodetool repair”？

Nahush

Asked: 2024-10-01 01:53:03 +0800 CST

哪个 DSE 版本兼容导入 Cassandra 4.x SSTables？

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 兼容性的明确信息。任何与此相关的链接或信息都会有所帮助。谢谢！

Andreas Larfors

Asked: 2024-08-05 18:39:31 +0800 CST

安装 Cassandra：RedHat - 仅提供版本 4.1~alpha1-1

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 4.1 中已弃用的配置属性

使用 Ansible 自动升级，对抗 APT 自动启动 Cassandra 服务

Cassandra 数据库中的墓碑未被删除

如何在 Cassandra 4.0.5 上升级 Java 版本

5.0 上的架构更改导致 gossip 失败，oacdb.db.TypeSizes.sizeof() 返回“AssertionError: null”

我应该将哪个版本的 Java 与 Cassandra 5.x 一起使用

由于提交日志损坏，Cassandra 无法启动

哪个 DSE 版本兼容导入 Cassandra 4.x SSTables？

安装 Cassandra：RedHat - 仅提供版本 4.1~alpha1-1

连接到 PostgreSQL 服务器：致命：主机没有 pg_hba.conf 条目

如何让sqlplus的输出出现在一行中？

选择具有最大日期或最晚日期的日期

如何列出 PostgreSQL 中的所有模式？

列出指定表的所有列

如何在不修改我自己的 tnsnames.ora 的情况下使用 sqlplus 连接到位于另一台主机上的 Oracle 数据库

你如何mysqldump特定的表？

使用 psql 列出数据库权限

如何从 PostgreSQL 中的选择查询中将值插入表中？

如何使用 psql 列出所有数据库和表？

问题[cassandra](dba)