我最近在cassandra做了一些不同设计的性能测试.我目前正在使用cassandra作为写密集型项目.但是,我将使用select语句添加读取密集部分来导出数据.
我正在用下表做时间序列;
CREATE TABLE events (
date text,
n int, // it could be 1,2,3
id timeuuid,
PRIMARY KEY ((date, n), id)
);
我有date|n分区键.为了提高读取性能,我试图从宽行的概念中获益.在文件中,声明;
如果分区键相同,则将它们插入到同一物理节点,并加宽分区键的行.
因此,我用n在获得该陈述热点的情况下,均匀分布行这里 ;
但是,在多节点集群中,当我插入以下内容时;
'2013-07-30'|1, some-timeuuid
'2013-07-30'|1, another-timeuuid
我看到他们不在同一个物理节点上.
我得到节点信息;
nodetool getendpoint keyspace columnfamily some-timeuuid
因此,不知何故,我希望它们在同一行中以提高读取性能,但在获得20亿列时不会太宽.(这是列的大小限制)
那么,任何想法在这里发生了什么？
经常nodetool repair在我的Cassandra节点上运行会使它们瘫痪吗？
该行星卡桑德拉常见问题说明(强调)说
反熵节点修复-对于数据未频繁地读取,或更新已向下延长的期间内,节点修复过程(也被称为反熵修复)在一个节点上的数据,确保上的所有数据副本是一致的.作为常规集群维护操作的一部分,应定期运行节点修复(使用nodetool实用程序).
这是我见过的nodetool repair经常运行的唯一参考.如果它便宜,经常运行它不会是一个问题,但它有多贵？它是否相当于对节点上每条记录的一致性检查读取？还是比这更聪明？文档提到了Merkle树的使用,但这并没有让我知道操作的成本有多高.
如果你有500 GB数据的节点上,并在该节点与其他节点实际上是一致的(修为无操作),多少数据并从磁盘(读取所有500 GB读修复将采取一对夫妇小时)？关于通过LAN发送多少数据(通过LAN发送所有500 GB可能需要一个小时左右).
我想从我的Cassandra集群中删除一个节点,并且正在关注这两个相关问题(此处和此处)以及Cassandra文档.但我仍然不确定确切的过程.
我的第一个问题是:以下方法从Cassandra集群中删除节点是否正确？
decommission 我想删除的节点.removetoken 我刚刚退役的节点.如果上述过程是正确的,那么如何判断退役过程是否完成以便我可以继续进行第二步？或者在步骤1之后立即执行第2步是否安全？
此外,Cassandra文件说:
您可以将具有nodetool decommission的节点从群集中移出到活动节点,或者nodetool removetoken(到任何其他计算机)以删除死亡节点.这会将旧节点负责的范围分配给其他节点,并在那里复制适当的数据.如果使用退役,则数据将从退役节点流式传输.如果使用removetoken,则数据将从剩余的副本流中传输.
从要退役的节点中不会自动删除任何数据,因此如果要将节点重新置于环上不同令牌的服务中,则应手动删除该节点.
这是否意味着退役节点是死节点？此外,由于没有从被退役的节点中自动删除数据,如何确定何时从退役节点中删除数据是安全的(即,如何知道数据流何时完成？)
在文档中,它说SizeTieredCompactionStrategy(STCS)是默认的压缩策略.
如何获得群集的实际压缩策略？
我希望停用 cassandra 节点，因为该节点需要操作系统升级。
我登录到该节点。执行退役命令，几分钟后我在控制台上收到此异常
nodetool decommission
error: Stream failed
-- StackTrace --
org.apache.cassandra.streaming.StreamException: Stream failed
at org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85)
at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
at com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
at com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
at com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202)
at org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:208)
at org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:184)
at org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:412)
at org.apache.cassandra.streaming.StreamSession.onError(StreamSession.java:507)
at org.apache.cassandra.streaming.StreamSession.start(StreamSession.java:229)
at org.apache.cassandra.streaming.StreamCoordinator$StreamSessionConnector.run(StreamCoordinator.java:208)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
我不确定那个异常是什么意思，我打算通过nodetool netstats和nodetool status来验证退役是否成功，其输出在下面。在两个地方都说LEAVING，我如何确认它是否完整。
nodetool netstats
Mode: LEAVING
Not sending any streams.
Read Repair Statistics:
Attempted: 1
Mismatch (Blocking): 0
Mismatch (Background): 0
Pool Name Active Pending Completed
Commands n/a …cassandra datastax-enterprise nodetool datastax cassandra-2.1
我们最近在我们的一个Cassandra节点(其复制因子为3的5个Cassandra 2.2集群)中出现磁盘故障.在该节点上执行完整修复大约需要一周或更长时间.每个节点包含3/5的数据,并且在所有节点上执行nodetool修复修复了3/5的令牌范围.现在它已被修复,它很可能会更快地修复,因为它进行了增量修复.我想知道使用nodetool repair -pr在所有节点上执行定期修复是否是一个好主意(我们在2.2,我认为增量修复在2.2中是默认的).
我认为这是一个好主意,因为如果定期执行它将需要更少的时间来修复,因为它只需要修复未修复的SStables.我们也可能有过这样的情况:节点可能已经关闭了超过提示的切换窗口,我们可能没有做任何事情.
我们向数据中心添加了一个新节点,然后nodetool cleanup根据cassandra中的现有集群添加新节点运行.但是在清理完成后,我们注意到我们丢失了一些数据.
可能是什么原因？
我们还需要修复Cassandra中的"SYSTEM"键空间和"OPSCENTER"键空间,以及我们创建的键空间吗？
我在 Linux Ubuntu 机器上设置了 DataStax Enterprise 4.6.6。OpsCenter 和 DevCenter 工作正常。我可以毫无问题地写入数据库等。
然而，许多演示和命令行工具返回以下错误：
无法确定 DSE_ENV
发生这种情况的一个例子是：
节点工具状态
我找到了一个名为的文件DSE_ENV.sh，它似乎设置了一些环境变量，例如DSE_HOME. 但是当我echo $DSE_HOME例如未设置变量时。我不知道这个文件是否永远不会被调用，或者是什么导致了这个问题。
我发现这篇文章专门针对dse未启动的服务，而我的情况并非如此：https :
//support.datastax.com/hc/en-us/articles/204226189-DSE-fails-to-start-有错误-DSE-ENV-无法确定
然而，我尝试运行它提到的权限命令，但没有运气。
我在Docker上运行Cassandra时获得了研发任务.我正在研究XUbuntu 14.04.2 64位(安装在Windows7 32位操作系统的VirtualBOX上).
我在Ubuntu和Pokle cassandra教程中遵循Docker中给出的步骤,当我尝试使用nodetool检查特定节点的状态时,我得到了一个ConnectException.
以下是我所做的步骤列表.
asela@teamlk:~$ docker run -d --name cass1 poklet/cassandra start
7b2ddfb60adf1c270a425c4440fe263e1fe56f5dc1c3205372bee3b8626e0624
asela@teamlk:~$ docker run -d --name cass2 poklet/cassandra start $(/data/cassandra/scripts/ipof.sh cass1)
4f98a194214e603242279226bb94cee20774058e84b6d0171a8d14d648e19016
asela@teamlk:~$ docker run -d --name cass3 poklet/cassandra start $(/data/cassandra/scripts/ipof.sh cass1)
394f9ce918121c0b79ed8282ba95c8f1badd4e3536d4ad3f24c4c21651e50b3c
asela@teamlk:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
394f9ce91812 poklet/cassandra:latest "start 172.17.0.1" 6 seconds ago Up 3 seconds 22/tcp, 7000-7001/tcp, 7199/tcp, 8012/tcp, 9042/tcp, 9160/tcp, 61621/tcp cass3
4f98a194214e poklet/cassandra:latest "start 172.17.0.1" …