【问题标题】:Inconsistent Cassandra system.peers stateCassandra system.peers 状态不一致
【发布时间】:2019-06-13 23:10:24
【问题描述】:

我们在 Kubernetes 上运行 6 个节点的 Cassandra (3.11.2) 集群。最近注意到system.peers表中的数据不一致。但是,system.local 中的数据似乎还可以。 nodetool describecluster 也没有报告任何问题。

您将在下面找到 system.peers 和 system.local 查询的匿名结果。我通过一次将端口转发到单个节点来执行它们(我希望这允许跳过负载平衡策略并直接访问节点)

system.peers 表的状态是否有害?或者可能是预期的?

SELECT peer, schema_version FROM system.peers

node 0
peer | schema_version
IP1 | schema2
IP2 | schema1
IP3 | schema1
IP4 | null
IP5 | schema1
IP6 | schema1
IP7 | schema1

node 1
peer | schema_version
IP8 | null
IP9 | schema1
IP3 | schema1
IP5 | schema1
IP6 | schema1
IP7 | schema1

node 2
peer | schema_version
IP11 | null
IP2 | schema1
IP9 | schema1
IP3 | schema1
IP4 | schema3
IP10 | null
IP5 | schema1
IP6 | schema1

node 3
peer | schema_version
IP12 | schema3
IP2 | schema1
IP9 | schema1
IP13 | null
IP3 | schema1
IP5 | schema1
IP7 | schema1

node 4
peer | schema_version
IP2 | schema1
IP9 | schema1
IP3 | schema1
IP6 | schema1
IP7 | schema1

node 5
peer | schema_version
IP8 | schema3
IP2 | schema1
IP9 | schema1
IP5 | schema1
IP6 | schema1
IP7 | schema1

SELECT key, broadcast_address, schema_version FROM system.local

node 0
key | broadcast_address | schema_version
local | IP9 | schema1

node 1
key | broadcast_address | schema_version
local | IP2 | schema1

node 2
key | broadcast_address | schema_version
local | IP7 | schema1

node 3
key | broadcast_address | schema_version
local | IP6 | schema1

node 4
key | broadcast_address | schema_version
local | IP5 | schema1

node 5
key | broadcast_address | schema_version
local | IP3 | schema1

nodetool describecluster

Cluster Information:
  Name: CLUSTER_NAME
  Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
  DynamicEndPointSnitch: enabled
  Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
  Schema versions:
    e718e690-d474-376e-8020-ed0eba5b6797: [IP5, IP9, IP3, IP2, IP6, IP7]

【问题讨论】:

    标签: cassandra


    【解决方案1】:

    这是出乎意料的,但已知会发生,例如:CASSANDRA-7122CASSANDRA-7531

    这可能会导致不同客户端驱动程序出现问题(例如,请参阅 JAVA-852JAVA-2280),尽管大多数客户端库会忽略此类损坏的对等记录并在发生时记录警告。

    既然提到了 Kubernetes,你会不会经常更换节点?我想知道 C* 中是否存在无法正确删除旧对等条目的潜在错误。过去曾报告过已通过COULD NOT REPRODUCE 关闭的问题。

    如果您可以相当容易地重现此问题,那么如果您可以create a JIRA ticket 描述问题以及如何重现它,将对社区非常有帮助。否则,如果您没有时间,如果您可以描述您的 kubernetes 设置(即您是否使用社区运营商或其他东西?)并解释您可能正在做的一些可能有助于此的操作(即更换节点) 有时间我可以研究一下。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2018-01-20
      • 1970-01-01
      • 1970-01-01
      • 2015-11-05
      • 2012-08-24
      • 1970-01-01
      • 2017-10-13
      • 2018-10-06
      相关资源
      最近更新 更多