6

我有一个 Cassandra 集群（3 个节点，所有节点都部署到 AWS），我正在尝试迁移到 DataStax 集群。现在是时候停止自己管理这些节点了。

我有多个生产者和消费者整天读/写数据到我的 Cassandra 集群。我没有将应用程序/服务/代理放在我的 Cassandra 集群前面的选项，然后只是干净地翻转开关，以便所有读/写都去/来自我的 Cassandra，转到 DataStax。因此，没有一种干净的方法可以一次迁移一个表。我还试图为数据的所有生产者/消费者实现零（或接近零）停机时间。一个硬性要求：迁移不能是有损的。没有丢失的数据！

我认为这里最好的策略是一个四步过程：

  1. 不知何故，将 DataStax 配置为我的 Cassandra 集群的副本，有效地创建到 DataStax 的流复制
  2. 一旦 DataStax 完全“赶上”我的 Cassandra 中的其他节点，让生产者继续写入我当前的 Cassandra 集群，但将消费者/读者切换到 DataStax（也就是说，重新配置它们以连接到 DataStax，然后重新启动它们）。不是零停机时间，但我可能可以接受简单的重启。（同样，零停机解决方案是非常受欢迎的。）
  3. 将生产者切换到 DataStax。同样，停机时间几乎为零，因为这涉及重新配置生产者以指向 DataStax，然后需要重新启动以获取新配置。零停机解决方案将是首选。
  4. 一旦来自“旧” Cassandra 集群的复制流量减少到零，我们现在就没有我的非 DataStax 节点需要写入 DataStax 的“新”信息了。用火杀死那些节点。

这个解决方案是我能想到的最微创、最接近零停机时间的解决方案，但假设有以下几点：

  • 也许不可能将 DataStax 视为可以复制到的额外节点（是/否？）
  • 也许 Cassandra 和/或 DataStax 有一些我不知道的神奇特性/功能，它们可以比这个解决方案更好地处理迁移；或者也许有可以更好地处理这个问题的第 3 方（理想情况下是开源的）工具
  • 我不知道如何监控从“旧”Cassandra 节点到 DataStax 的复制“流量”。在我可以安全地关闭+杀死旧节点之前需要知道如何做到这一点（同样，不能丢失数据）。

我想我想知道这个策略是否：（1）可行/可行，以及（2）最优；如果 Cassandra/DataStax 生态系统中有任何功能/工具，我可以利用这些功能/工具来使其变得更好（更快且零停机时间）。

4

2 回答 2

4

您概述的四个步骤绝对是一个可行的选择。还有进行简单的滚动二进制安装的途径： https ://docs.datastax.com/en/latest-upgrade/upgrade/datastax_enterprise/upgrdCstarToDSE.html

我将在您上面提供的步骤的背景下发言。如果您对滚动二进制安装感到好奇，我们当然也可以聊聊。

注意文档链接特定于 Cassandra 3.0 (DataStax 5.0) - 确保文档版本与您的 Cassandra 版本匹配。

如果当前主要 Cassandra 版本 == DataStax 中的当前主要 Cassandra 版本，您应该能够将“DataStax”节点添加为当前 Cassandra 环境所属的同一集群中的新 DC：http://docs.datastax。 com/en/cassandra/3.0/cassandra/operations/opsAddDCToCluster.html - 这会将现有数据从现有 Cassandra DC 引入 DataStax DC。

如果您的 Cassandra 版本不匹配（当前的 Cassandra 比 DataStax Cassandra 旧/新），那么您可能需要通过https://academy.datastax.com/slack联系 DataStax，因为该过程将更具体地针对您的环境并且可以变化很大。

如文档中所述，您需要运行

ALTER KEYSPACE "your-keyspace" WITH REPLICATION =
{'class’: 'NetworkTopologyStrategy', 'OldCassandraDC':3, 'DataStaxDC':3};

（显然将 DC 名称和复制因子更改为您的规格）

这将确保来自生产者的新数据将复制到新的 DataStax 节点。

然后，您可以nodetool rebuild -- name_of_existing_data_center从 DataStax 节点运行以从现有 Cassandra 节点流式传输数据。根据有多少数据，它可能会有些耗时，但它是最简单、最省心的方法。

然后，您需要在停用旧的 Cassandra DC 之前一一更新生产者/消费者中的联系点。

根据我的经验提供一些建议：

  • 在启动这些节点之前，请确保您的 DataStax 节点在 cassandra.yaml 中使用GosspingPropertyFileSnitch 。
  • 运行时nodetool rebuild，使用屏幕执行此操作，以便您可以看到它何时完成（或错误），否则，您将不得不通过使用nodetool netstats和检查流活动来监控进度。
  • 启动并运行 OpsCenter 以监控重建期间 DataStax 集群中发生的情况。您可以密切关注流式吞吐量、待处理的压缩和其他 Cassandra 特定指标。
  • 当需要停用旧 DC 时，请确保遵循以下步骤： http ://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsDecomissionDC.html

希望有帮助！

于 2017-01-31T10:26:03.010 回答
2

我想你的意思是 Datastax Managed 产品，他们为你运行 cassandra。如果您只是说“在您自己的 AWS 实例上运行 DSE”，您可以就地进行二进制升级。

您提出的问题最好向 Datastax 提出——如果您要付钱给他们，您也可以向他们提出问题（这就是客户所做的）。

您的 4 步方法大多非常合乎逻辑，但可能过于复杂。大多数 cassandra 驱动程序将自动发现新主机，并自动驱逐旧的/离开的主机，因此一旦集群中拥有所有新的 Datastax 托管节点（假设它们允许），您可以运行修复以保证一致性，然后停用您的现有节点 - 您的应用程序将继续工作（Cassandra 不是很棒吗？）。您需要更新您的应用配置以在您的应用配置/端点中拥有新的 Datastax 托管节点，但这不需要提前完成。

这里需要注意的一个问题是所涉及的延迟 - 从您的环境到 Datastax Managed 可能会引入延迟。在这种情况下，您有一个中间步骤，您可以考虑将 Datastax 托管节点添加为 cassandra 中的不同“数据中心”，扩展复制因子，并使用LOCAL_一致性级别来控制哪个 DC 获取查询（然后您可以移动您的生产者/消费者单独）。

于 2017-02-01T00:13:08.473 回答