Cassandra - Pillar 应用迁移同步问题

Question

在 Cassandra 的同一数据中心中的不同节点之间遇到同步问题。使用 NetworkTopology 将密钥空间设置为 3 的复制因子，并且在 DC 中有 3 个节点。有效地确保每个节点都有数据的副本。节点工具状态运行时，显示DC中的三个节点都拥有100%的数据。

然而，该键空间中的 applied_migrations 列族不同步。这很奇怪，因为键空间中只有一个列族受到影响。所有其他列族在三个节点之间完全复制。测试是通过计算键空间中每个列族的行数来完成的。

keyspace_name | durable_writes | strategy_class                                       | strategy_options
--------------+----------------+------------------------------------------------------+----------------------------
core_service  |           True | org.apache.cassandra.locator.NetworkTopologyStrategy |          {"DC_DATA_1":"3"}


keyspace: core_service

Datacenter: DC_DATA_1
=====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address                      Load       Tokens  Owns (effective)  Host ID                               Rack
UN  host_ip_address_1_DC_DATA_1  3.75 MB    256     100.0%            3851106b                              RAC1
UN  host_ip_address_2_DC_DATA_1  3.72 MB    256     100.0%            d1201142                              RAC1
UN  host_ip_address_3_DC_DATA_1  3.72 MB    256     100.0%            81625495                              RAC1
Datacenter: DC_OPSCENTER_1
==========================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address                           Load       Tokens  Owns (effective)  Host ID                               Rack
UN  host_ip_address_4_DC_OPSCENTER_1  631.31 MB  256     0.0%              39e4f8af                              RAC1

查询：select count(*) from core_service.applied_migrations；

host_ip_address_1_DC_DATA_1 core_service applied_migrations

 count
-------
     1

(1 rows)
host_ip_address_2_DC_DATA_1 core_service applied_migrations

 count
-------
     2

(1 rows)
host_ip_address_3_DC_DATA_1 core_service applied_migrations

 count
-------
     2

(1 rows)
host_ip_address_4_DC_OPSCENTER_1 core_service applied_migrations

 count
-------
     2

(1 rows)

收到类似错误，如下面的问题所述。因为所有数据行都不可用，所以迁移脚本会失败，因为它正在尝试创建现有表： https://github.com/comeara/pillar/issues/25

Answer 1

我需要强一致性

如果您想确保您的读取是一致的，您需要使用正确的一致性级别。

对于 RF3，您有以下选择：

1. 写入 CL ALL 并使用 CL One 或更高版本读取
2. 写入 CL Quorum 并读取 CL Quorum。这是Magro 推荐的内容，他打开了您链接到的问题。这也是最常见的，因为您可以松开一个节点，但仍然可以读写。
3. 写入 CL 1 但读取 CL ALL。

Cassandra 做了什么来提高一致性

Cassandra 的反熵机制是：

Repair 将确保您的节点保持一致。它为您提供了一个一致性基线，因此它应该作为维护操作的一部分运行。 至少比 gc_grace_seconds 更频繁地运行修复，以避免僵尸墓碑再次出现。 DataStax OpsCenter 具有自动执行此任务的修复服务。

你可以手动运行：

nodetool修复 在一个节点中或

nodetool修复-pr 在您的每个节点中。 -pr 选项将确保您只修复节点的主要范围。

读取修复以概率方式发生（可在表 def 中配置）。当你读取一行时，c* 会注意到是否有一些副本没有最新的数据并修复它。

提示在某个节点无法进行写入时由其他节点收集。

操作 c* 模式

我注意到 Pillar 的全部意义在于“将 Cassandra 模式作为代码自动管理”。这是一个危险的概念——尤其是如果 Pillar 是一个分布式应用程序（我不知道是不是这样）。因为它可能会导致架构冲突，从而使集群处于古怪状态。

假设 Pillar 不是一个分布式/多线程系统，您可以通过在架构修改后 Java 驱动程序中架构更改前后使用checkSchemaAgreement() 来确保不会破坏架构。

长期

Cassandra 架构将更加健壮并能够处理分布式更新。观看（并投票）CASSANDRA-9424