Cassandra 数据从 1.2 迁移到 3.0.2答案

【问题标题】：Cassandra data Migration from 1.2 to 3.0.2Cassandra 数据从 1.2 迁移到 3.0.2
【发布时间】：2019-07-03 17:43:58
【问题描述】：

我知道以前有人问过类似的问题，但我认为我的用例非常具体，我找不到任何答案。

在生产中，我们在 6 节点集群中使用 Cassandra 1.2 和 ByteOrderPartitioner，Priam 作为种子管理工具。我们最近升级了所有依赖项，并尝试使用 Murmur Partitioner 迁移到 Cassandra 3.0.2，为了向后兼容，我们需要在新集群上启用 thrift。此外，我们还想从 Priam 迁移。我能够设置新集群，但在数据迁移过程中遇到了很多问题。我尝试了 3 件事：

1) 使用复制命令：行数很大时会失败

2) SSTable2Json : Cassandra 3.0.2 已停止支持 SSTable2Json

3) SSTableloader：我认为失败是因为源和目标的 cassandra 版本不同

java.lang.RuntimeException：无法检索端点范围：在 org.apache.cassandra.tools.BulkLoader$ExternalClient.init(BulkLoader.java:233) 在 org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:119) 在 org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:67) 原因：InvalidRequestException（为什么：未配置的表 schema_columnfamilies）在 org.apache.cassandra.thrift.Cassandra$execute_cql3_query_result.read(Cassandra.java:37849) 在 org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78) 在 org.apache.cassandra.thrift.Cassandra$Client.recv_execute_cql3_query(Cassandra.java:1562) 在 org.apache.cassandra.thrift.Cassandra$Client.execute_cql3_query(Cassandra.java:1547) 在 org.apache.cassandra.tools.BulkLoader$ExternalClient.init(BulkLoader.java:225) ... 2 更多

现在我有点卡住了，对此的任何帮助将不胜感激。如果您需要更多详细信息，请告诉我。

【问题讨论】：

标签： cassandra migration etl data-migration cassandra-3.0

【解决方案1】：

不，您不能将您的 sstable从 1.2 直接升级到 3.0.2，因为不同版本的 sstable 会有所不同。这个link 描述了升级 cassandra 版本的步骤。但它也对您没有帮助，因为您正在更改分区器类型。

截至目前，cassandra 尚不支持更改分区器类型现在(Link)。

我更喜欢的解决方案之一是，

创建一个 cassandra 3.0.2 版本的独立实用程序，以从您的源 cassandra 读取所有数据并写入 sstable 在CQLSSTableWriter 的帮助下，使用 Murmur Partitioner 的分区类型（诀窍是，你正在写 3.0.2版本的sstable，所以这个sstable很容易被您的新集群识别）。然后在你的目标集群中使用 SSTableLoader

但我不确定为什么您仍然需要向后兼容，在创建 CQLSSTableWritter 时，您可以使用关键字指定列族架构 “具有紧凑的存储空间”。但是我没有尝试使用“WITH COMPACT STORAGE”的 CQLSSTableWritter，但没有尝试过“WITH COMPACT STORAGE”，它也适用于您的情况。

【讨论】：

谢谢 Jaya，我仍在探索两个选项：1）使用 CQLSSTableWriter 2）在新集群中创建模式，编写将数据从一个集群直接复制到另一个集群的 java 代码。由于数据不是很大（大约 100GB），我更倾向于第二种选择，因为我已经熟悉在 cassandra 中写入数据的代码。对此有任何想法。
在我看来，与第一个选项相比，第二个选项会花费更多时间。另外一个预防步骤是使写入过程具有重试逻辑。因为如果任何写入因任何异常而失败，那么您需要从第一个开始写入过程。
第二个选项的另一点是，我不确定 cassandra 是否会处理所有 100GB 的数据而不会失败。由于在拉伸镜头中写入 100 GB，可能会带来任何麻烦。从 cassandra 文档来看，它必须处理所有 100GB 数据而不会失败。尚未尝试，但几乎您正在对 cassandra 进行压力测试。但是如果你选择第一个选项，你就不会落入任何陷阱。如果可能的话，一旦完成就取回结果，这可能对我将来有帮助。
感谢 Jaya 提出您的顾虑。当然我会分享结果和一些示例代码。支持第二个选项的原因之一是我们的遗留代码。我们为键和列使用了很多带注释的复合序列化器。如果我使用 CQLSSTableWriter，我将不得不手动将列名序列化为 CQL 的 blob，这又是额外的工作。我正在考虑的方法是明智地执行 CF 以避免过载，实现重试逻辑并保持突变批次小。在去 prod 之前我做了很多测试，如果它仍然失败，我将不得不去选项 1

【解决方案2】：

好吧，如果您尝试直接从 1.2 迁移到 3.0.2，那您真的是在自找麻烦。

迁移路径应该是

最新的次要版本或 1.2
2.0 最新的次要版本
2.1 最新次要
3.0.2

对于版本之间的每次跳转，请阅读https://github.com/apache/cassandra/blob/trunk/NEWS.txt 文件以了解您是否需要特殊操作（升级 sstable，...）

【讨论】：

谢谢@doanduyhai 但这不起作用，好像我只是升级当前版本，我仍然必须使用ByteOrderPartitioner
一旦您选择了一个分区器 (ByteOrderPartitioner)，您就必须永远保留它。更改分区器的唯一方法是创建一个新集群并使用 Spark 将所有数据复制到这个新集群
抱歉不清楚，但在我的问题中，我已经提到我已经创建了一个带有新分区器的新集群，现在唯一未决的事情就是复制数据