应用说明

这是应用程序的逐步说明（请参阅schema附件）：

  • Service1使用来自RabbitMQ的消息

  • Service1对它执行某些操作然后使用列插入数据（处理为false）

  • Service1从cassandra获取ID（数据只是插入）并在具有ID的专用RabbitMQ队列中推送消息

  • Service2使用来自专用RabbitMQ队列的消息，做一些事情然后用列INSERT（实际更新）数据（处理为true）

群集说明

在上一次发布之前，我们有一个3节点集群，复制因子为2.发布的一个步骤是删除所有数据并重新创建密钥空间（项目尚未 生产环境 ） .

出于冗余原因，我们必须添加第二个数据中心 . 这是在发布期间，在DROP键空间和重新创建之间完成的 . Keyspace设置从（DC1：2）到（DC1：2，DC2,2）

时间表

  • 停止应用程序的部分服务（导致写入cassandra的服务）

  • DROP KEYSPACE

  • 添加第二个数据中心

  • 启动所有DC2节点

  • 将复制因子更改为相关键空间的（DC1：2，DC2,2）

  • 在新节点上重建

  • 使用（DC1：2，DC2,2）创建应用程序密钥空间

  • 正在运行迁移

  • 从RabbitMQ开始使用服务

问题

发布后，我们必须运行所谓的“迁移”，将数据从旧数据存储区导入到新数据存储区（cassandra） . 这是部分工作，之后当我们启动服务时，我们注意到已处理的列始终保持“假” . 尽管前面的所有步骤都正常工作 .

那时，我们注意到忘记将一致性级别从QUORUM更改为LOCAL_QUORUM . 我们试图改变它并重新启动，但它没有用 . 我们还试图恢复第3步，删除第2个数据中心，它不起作用 .

最后，唯一有效的方法是DROP表并重新启动服务 .

因为当我们要上线时，将表格投入 生产环境 将不是一个选项，我们决定尝试按照相同的时间表重现问题 .

测试执行

  • 首次测试，再现 生产环境 中的所有相同步骤给出了相同的结果 .

  • 步骤相同但使用了从工作开始的LOCAL_QUORUM的一致性级别 .

  • 重试与QUORUM的一致性级别也有效!!!

  • 此次尝试以一致性级别重试LOCAL_QUORUM失败

  • 对于LOCAL_QUORUM的一致性级别，但是service2已停止工作==>在RabbitMQ中显示的数据使处理列变为true，以及以下内容 .

  • 对于LOCAL_QUORUM的一致性级别但是service2停止工作时延迟更多==>在RabbitMQ中显示的数据使处理列变为真但不是以下的 .

  • 对于LOCAL_QUORUM的一致性级别，一个1 DC从一开始就失败了

  • 对于LOCAL_QUORUM的一致性级别，一个1个DC，1个节点和RF到1在迁移期间工作，但之后我们重新启动服务时没有工作 .

上次测试当前正在运行，当处理列未正确设置为true时，我们停止service2一段时间，然后我们重新启动它，问题得到解决，并且从那时起它就一直在运行 .

现在我们正在更改应用程序，以便我们最后只写一次cassandra . 使用RabbitMQ在服务之间共享数据 . 即使这将删除问题（已处理的列不再存在），我们希望了解此问题的根本原因 .

提前致谢，

cassandra consistency