问题标签 [cassandra-2.1]

我想在我的服务器中使用 cassandra，并且服务器有五个磁盘，我可以跨磁盘分区数据吗？换句话说，如何使用分区键将数据存储在这个磁盘中？我读到 cassandra 可以在多个服务器中分区，如何为多个磁盘做同样的事情？TNX

我正在研究[cqlsh 5.0.1 | 卡桑德拉 2.1.1 | CQL 规范 3.2.0 | 本机协议 v3] 最近 5 个月在 centOS 7 服务器上。

不幸的是服务器下车了。之后，我试图重新启动 cassandra。

但是得到了错误

我打算将 Java 对象用作自定义类型并将其存储在 Cassandra 中。我从类中取出 2 个数据成员并将它们设为主键，并将其余数据成员保留在自定义类型中。 data members of my class: name, date_of_birth, occupation, last_visit, family_members, total_income primary key: name, date_of_birth cassandra custom type members: occupation, last_visit, family_members, total_income 与根据 Cassandra 数据类型存储单个数据成员相比，自定义数据类型在写入或读取时是否具有任何性能优势。

我们使用 java datastax cassandra 驱动程序2.1.2。我们使用的 Cassandra 版本是2.0.9.

我们有我们构建的语句，QueryBuilder并且我们正在将一致性级别设置为TWO显式的语句。

我们得到这样的异常：

I know that calling all() on ResultSet makes it load all articles for organization in memory and work with it and creates load on cassandra. This will be removed as noted in comments. This can cause read timeout but I am still puzzled why in exception message there is ALL.

Question is why exception is telling that consistency level ALL is used when we set it to TWO for original statement. Is all() internally doing something with query and using CL ALL by default?

我试图了解 Cassandra 中的Leveled Compaction Strategy是如何工作的，以保证 90% 的所有读取都将从单个 sstable 中得到满足。

来自 DataStax 文档：

新的 sstables 被添加到第一层 L0，并立即与 L1 中的 sstables 压缩。当 L1 填满时，额外的 sstables 会提升到 L2。在 L1 中生成的后续 sstable 将与它们重叠的 L2 中的 sstable 进行压缩。

我们有带有分级压缩策略的 Cassandra 1.1.1 服务器。

系统工作，以便有读取和删除操作。每半年我们都会删除大约一半的数据，同时有新数据进来。有时磁盘使用率会上升到 75%，而我们知道实际数据占用大约 40-50% 的其他空间被墓碑占用。为了避免磁盘溢出，我们通过将所有 SSTable 降到 0 级来强制压缩表。为此，我们删除 .json 清单文件并重新启动 Cassandra 节点。（gc_grace 选项没有帮助，因为压缩仅在填充级别后开始）

从 Cassandra 2.0 开始，清单文件被移动到 sstable 文件本身：https ://issues.apache.org/jira/browse/CASSANDRA-4872

我们正在考虑迁移到 Cassandra 2.x，但我们担心我们将不再有强制分级压缩的可能性。

我的问题是：我们如何才能使我们的表具有磁盘空间限制，例如 150GB？（当超过限制时，它会自动触发压缩）。问题主要是关于 Cassandra 2.x。同时也欢迎 Cassandra 1.1.1 的任何替代解决方案。

我希望使用布隆过滤器和 hyperloglog 等结构进行概率计数和设置成员资格。

是否支持使用此类数据结构并在服务器端通过用户定义的函数或类似方法对它们执行原子操作？或者我有什么方法可以添加具有此类功能的扩展？

（我可以通过另一个系统获取数据并批量更新以减少争用，但如果所有这些都可以在数据库服务器中处理，那就简单多了。）

我正在使用 Cassandra 2.1 并且有一个大致如下所示的模型：

如您所见，我在ticket_id. 这个索引工作正常。events包含大约 1 亿行，而其中只有 500 万行有大约 50,000 个不同的票证。因此，一张票 - 平均 - 有 100 个事件。

查询二级索引无需提供分区键，这在我们的情况下很方便。由于该bucket列有时很难事先确定（即您应该知道事件的日期，bucket即当前日期）。

当一张票的所有事件都应该移动到另一张票时，我该如何解决这个问题？即以下查询将不起作用：

这是否意味着二级索引不能在UPDATE查询中使用？

我应该使用什么模型来支持这些更改？

我有一个 4 节点集群，每个盒子上有 16 核 CPU 和 100 GB RAM（每个机架上有 2 个节点）。

截至目前，所有系统都使用 Cassandra (v2.1.4) 的默认 JVM 设置运行。使用此设置，每个节点使用 13GB RAM 和 30% CPU。这是一个写入繁重的集群，偶尔会删除或更新。

我是否需要调整 Cassandra 的 JVM 设置以利用更多内存？为了进行适当的设置，我应该查看哪些内容？

每个人

几天前，我将我们的 6 节点 EC2 集群从 cassandra 2.1.4 升级到了 2.1.5。

从那时起，我的所有节点的 cpu 使用率都“爆炸式增长”——它们大部分时间都处于 100% cpu，并且它们的平均负载在 100-300 之间（！！！）。

这不是在升级后立即开始的。几个小时后，其中一个节点开始，慢慢地，越来越多的节点开始表现出相同的行为。它似乎与我们最大的列族的压缩相关，并且在压缩完成后（开始后约 24 小时），节点似乎恢复正常。才2天左右，所以我希望它不会再次发生，但我仍在监控。

这是我的问题

1. 这是错误还是预期行为？

如果这是预期的行为 -

1. 这个问题的解释是什么？
2. 它是否记录在我错过的某个地方？
3. 我应该以不同的方式进行升级吗？每 24 小时左右一次可能有 1 或 2 个节点？最佳做法是什么？

如果它是一个错误 -

1. 它是已知的吗？
2. 我应该在哪里报告这个？我应该添加什么数据？
3. 降级到 2.1.4 会起作用吗？

对此的任何反馈都会很棒

谢谢

阿米尔

更新：

这是有问题的表的结构。

创建表 tbl1 (

) 紧凑的存储空间

日志没有透露太多（至少对我来说）。这是日志外观的片段

信息 [WRITE-/10.0.1.142] 2015-05-23 05:43:42,577 YamlConfigurationLoader.java:92 - 从文件加载设置：/etc/cassandra/cassandra.yaml

信息 [WRITE-/10.0.1.142] 2015-05-23 05:43:42,580 YamlConfigurationLoader.java:135 - 节点配置：[authenticator=AllowAllAuthenticator; 授权人=允许所有授权人；自动快照=真；batch_size_warn_threshold_in_kb=5；batchlog_replay_throttle_in_kb=1024；广播_rpc_address=10.0.2.145; cas_contention_timeout_in_ms=1000；client_encryption_options=; cluster_name=Gryphonet21 集群；column_index_size_in_kb=64；commit_failure_policy=停止；commitlog_directory=/data/cassandra/commitlog; commitlog_segment_size_in_mb=32；commitlog_sync=定期；commitlog_sync_period_in_ms=10000；compaction_throughput_mb_per_sec=16；并发计数器写入=32；并发读取=32；并发写入=32；counter_cache_save_period=7200; counter_cache_size_in_mb=null；counter_write_request_timeout_in_ms=5000；交叉节点超时=假；data_file_directories=[/data/cassandra/data]; disk_failure_policy=停止；dynamic_snitch_badness_threshold=0.1；dynamic_snitch_reset_interval_in_ms=600000；dynamic_snitch_update_interval_in_ms=100；endpoint_snitch=GossipingPropertyFileSnitch; 提示切换启用=真；提示_handoff_throttle_in_kb=1024；增量备份=假；index_summary_capacity_in_mb=null；index_summary_resize_interval_in_minutes=60；inter_dc_tcp_nodelay=false；节点间压缩=全部；key_cache_save_period=14400; key_cache_size_in_mb=null；max_hint_window_in_ms=10800000；max_hints_delivery_threads=2；memtable_allocation_type=heap_buffers; native_transport_port=9042; num_tokens=16; 分区器=随机分区器；permissions_validity_in_ms=2000; range_request_timeout_in_ms=10000；read_request_timeout_in_ms=5000；request_scheduler=org.apache.cassandra.scheduler。无调度器；request_timeout_in_ms=10000；row_cache_save_period=0；row_cache_size_in_mb=0；rpc_address=0.0.0.0；rpc_keepalive=true；rpc_port=9160；rpc_server_type=同步；saved_caches_directory=/data/cassandra/saved_caches；seed_provider=[{class_name=org.apache.cassandra.locator.SimpleSeedProvider，参数=[{seeds=10.0.1.141,10.0.2.145,10.0.3.149}]}]；server_encryption_options=; snapshot_before_compaction=false；ssl_storage_port=7001；sstable_preemptive_open_interval_in_mb=50；start_native_transport=真；start_rpc=真；存储端口=7000；thrift_framed_transport_size_in_mb=15；tombstone_failure_threshold=100000；tombstone_warn_threshold=1000；涓流_fsync=假；涓流_fsync_interval_in_kb=10240；truncate_request_timeout_in_ms=60000; write_request_timeout_in_ms=2000] row_cache_size_in_mb=0；rpc_address=0.0.0.0；rpc_keepalive=true；rpc_port=9160；rpc_server_type=同步；saved_caches_directory=/data/cassandra/saved_caches；seed_provider=[{class_name=org.apache.cassandra.locator.SimpleSeedProvider，参数=[{seeds=10.0.1.141,10.0.2.145,10.0.3.149}]}]；server_encryption_options=; snapshot_before_compaction=false；ssl_storage_port=7001；sstable_preemptive_open_interval_in_mb=50；start_native_transport=真；start_rpc=真；存储端口=7000；thrift_framed_transport_size_in_mb=15；tombstone_failure_threshold=100000；tombstone_warn_threshold=1000；涓流_fsync=假；涓流_fsync_interval_in_kb=10240；truncate_request_timeout_in_ms=60000; write_request_timeout_in_ms=2000] row_cache_size_in_mb=0；rpc_address=0.0.0.0；rpc_keepalive=true；rpc_port=9160；rpc_server_type=同步；saved_caches_directory=/data/cassandra/saved_caches；seed_provider=[{class_name=org.apache.cassandra.locator.SimpleSeedProvider，参数=[{seeds=10.0.1.141,10.0.2.145,10.0.3.149}]}]；server_encryption_options=; snapshot_before_compaction=false；ssl_storage_port=7001；sstable_preemptive_open_interval_in_mb=50；start_native_transport=真；start_rpc=真；存储端口=7000；thrift_framed_transport_size_in_mb=15；tombstone_failure_threshold=100000；tombstone_warn_threshold=1000；涓流_fsync=假；涓流_fsync_interval_in_kb=10240；truncate_request_timeout_in_ms=60000; write_request_timeout_in_ms=2000] seed_provider=[{class_name=org.apache.cassandra.locator.SimpleSeedProvider，参数=[{seeds=10.0.1.141,10.0.2.145,10.0.3.149}]}]；server_encryption_options=; snapshot_before_compaction=false；ssl_storage_port=7001；sstable_preemptive_open_interval_in_mb=50；start_native_transport=真；start_rpc=真；存储端口=7000；thrift_framed_transport_size_in_mb=15；tombstone_failure_threshold=100000；tombstone_warn_threshold=1000；涓流_fsync=假；涓流_fsync_interval_in_kb=10240；truncate_request_timeout_in_ms=60000; write_request_timeout_in_ms=2000] seed_provider=[{class_name=org.apache.cassandra.locator.SimpleSeedProvider，参数=[{seeds=10.0.1.141,10.0.2.145,10.0.3.149}]}]；server_encryption_options=; snapshot_before_compaction=false；ssl_storage_port=7001；sstable_preemptive_open_interval_in_mb=50；start_native_transport=真；start_rpc=真；存储端口=7000；thrift_framed_transport_size_in_mb=15；tombstone_failure_threshold=100000；tombstone_warn_threshold=1000；涓流_fsync=假；涓流_fsync_interval_in_kb=10240；truncate_request_timeout_in_ms=60000; write_request_timeout_in_ms=2000] 存储端口=7000；thrift_framed_transport_size_in_mb=15；tombstone_failure_threshold=100000；tombstone_warn_threshold=1000；涓流_fsync=假；涓流_fsync_interval_in_kb=10240；truncate_request_timeout_in_ms=60000; write_request_timeout_in_ms=2000] 存储端口=7000；thrift_framed_transport_size_in_mb=15；tombstone_failure_threshold=100000；tombstone_warn_threshold=1000；涓流_fsync=假；涓流_fsync_interval_in_kb=10240；truncate_request_timeout_in_ms=60000; write_request_timeout_in_ms=2000]

信息 [HANDSHAKE-/10.0.1.142] 2015-05-23 05:43:42,591 OutboundTcpConnection.java:494 - 无法与 /10.0.1.142 握手版本

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,713 MessagingService.java:887 - 在过去 5000 毫秒内丢弃了 135 条 MUTATION 消息

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,713 StatusLogger.java:51 - 池名称活动挂起完成阻塞所有时间阻塞

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,714 StatusLogger.java:66 - CounterMutationStage 0 0 0 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,714 StatusLogger.java:66 - ReadStage 5 1 5702809 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,715 StatusLogger.java:66 - RequestResponseStage 0 45 29528010 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,715 StatusLogger.java:66 - ReadRepairStage 0 0 997 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,715 StatusLogger.java:66 - MutationStage 0 31 43404309 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,716 StatusLogger.java:66 - GossipStage 0 0 569931 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,716 StatusLogger.java:66 - AntiEntropyStage 0 0 0 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,716 StatusLogger.java:66 - CacheCleanupExecutor 0 0 0 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,717 StatusLogger.java:66 - MigrationStage 0 0 9 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,829 StatusLogger.java:66 - ValidationExecutor 0 0 0 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,830 StatusLogger.java:66 - 采样器 0 0 0 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,830 StatusLogger.java:66 - MiscStage 0 0 0 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,831 StatusLogger.java:66 - CommitLogArchiver 0 0 0 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,831 StatusLogger.java:66 - MemtableFlushWriter 1 1 1756 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,831 StatusLogger.java:66 - PendingRangeCalculator 0 0 11 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,832 StatusLogger.java:66 - MemtableReclaimMemory 0 0 1756 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,832 StatusLogger.java:66 - MemtablePostFlush 1 2 3819 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,832 StatusLogger.java:66 - CompactionExecutor 2 32 742 0 0

信息 [ScheduledTasks:1] 2015-05-23 05:43:42,833 StatusLogger.java:66 - InternalResponseStage 0 0 0 0 0

信息 [HANDSHAKE-/10.0.1.142] 2015-05-23 05:43:45,086 OutboundTcpConnection.java:485 - 与 /10.0.1.142 的握手版本

更新：

问题仍然存在。我认为在每个节点上的一次压缩完成后，节点会恢复正常，但事实并非如此。几个小时后，CPU 跳到 100%，平均负载在 100-300 之间。

我正在降级回 2.1.4。

更新：

使用 phact 的 dumpThreads 脚本来获取堆栈跟踪。此外，尝试使用 jvmtop，但它似乎只是挂起。

输出太大，无法在此处粘贴，但您可以在http://downloads.gryphonet.com/cassandra/找到它。

用户名：cassandra 密码：cassandra