【问题标题】:do sstablesplit on the side在旁边做 sstablesplit
【发布时间】:2017-06-21 21:53:19
【问题描述】:

由于 sstable 是不可变的,并且 sstable 拆分必须离线执行,即。随着节点关闭。是否也可以离线/在副线目录中拆分超大 sstable 的副本,同时保持节点在线,然后在节点短暂重启期间将极端 sstable 与一组拆分的 sstable 文件交换,以最大程度地减少节点停机时间?

或者最好停用一个节点,将数据分散到集群的其余部分,然后作为新的空节点重新加入

例如。有一些大型 sstables 不会很快进入压缩视图。我想将这样的离线说拆分到另一个目录/FS/另一个盒子上,就在运行节点超出范围的地方,同时仍然让节点为原始 sstable 路径提供冗余服务。只是似乎 sstablesplit 想要找到配置,还是可以被欺骗以其他方式从正在运行的节点进行拆分外展?

尝试使用 sstable 文件的副本来拆分它,但是:

on-a-offlinebox$ sstablesplit --debug -s SOME-VALUE-IN-MB mykeyspc-mycf-*-Data.db 16:58:13.197 [main] 错误 o.a.c.config.DatabaseDescriptor - 致命 配置错误 org.apache.cassandra.exceptions.ConfigurationException:期望 URI 在变量中:[cassandra.config]。请在文件前加上 file:/// 用于本地文件或 file:/// 用于远程文件。中止。如果你 正在从外部工具执行此操作,它需要设置 Config.setClientMode(true) 避免加载配置。 在 org.apache.cassandra.config.YamlConfigurationLoader.getStorageConfigURL(YamlConfigurationLoader.java:73) ~[apache-cassandra-2.1.15.jar:2.1.15] 在 org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:84) ~[apache-cassandra-2.1.15.jar:2.1.15] 在 org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:161) ~[apache-cassandra-2.1.15.jar:2.1.15] 在 org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:136) ~[apache-cassandra-2.1.15.jar:2.1.15] 在 org.apache.cassandra.tools.StandaloneSplitter.main(StandaloneSplitter.java:56) [apache-cassandra-2.1.15.jar:2.1.15] 期望 URI 在变量中: [cassandra.config]。请在文件前加上 file:/// 为本地 files 或 file:/// 用于远程文件。中止。如果你是 从外部工具执行此操作,它需要设置 Config.setClientMode(true) 避免加载配置。致命的 配置错误;无法启动。查看堆栈跟踪日志。

【问题讨论】:

    标签: cassandra cassandra-2.1


    【解决方案1】:

    如果您可以负担节点的停机时间,就这样做(拆分表)。无论如何,如果您要在另一台机器/另一个目录上进行此拆分,您将需要在重新加载 sstables 后在节点上运行修复(由于重建表的“离线”时间)。

    您也可以尝试从节点中删除此表数据文件并运行修复,这可能会使节点的停机时间最短:

    停止节点->删除大sstables->启动节点->修复。

    编辑:从 Cassandra 3.4 开始,您可以在特定的 sstables/文件上运行 compact 命令。在任何早期版本上,您都可以使用 forceUserDefinedCompaction jmx 调用。您可以使用其中一种,也可以自己进行 jmx 调用:

    http://wiki.cyclopsgroup.org/jmxterm/manual.html

    https://github.com/hancockks/cassandra-compact-cf

    https://gist.github.com/jeromatron/e238e5795b3e79866b83

    使用 jmxterm 的示例代码:

    sudo java -jar jmxterm-1.0-alpha-4-uber.jar -l localhost:7199
    
    bean org.apache.cassandra.db:type=CompactionManager
    run forceUserDefinedCompaction YourKeySpaceName_YourFileName.db
    

    另外,如果“大桌子”问题一直出现,请考虑转移到 LCS。

    【讨论】:

    • 我们想要对如此大的 sstable 进行压缩的原因是我们希望在大型 sstable 中为相当多的数据有许多墓碑。 TS 是在 +30 天前创建的,因此它们在默认 10 天时早就过期了 gc_grace。只有在这样的 TS 与少数几个大型 sstable 压缩之前,还需要很长时间。我们的应用供应商说每天晚上运行主要的压缩包,不要像我们依赖次要压缩包那样使用 vnode。 TSed 数据是否也会在 decom 上传播或仅在“实时数据”上传播,即。 decom-rejoin 能否像单个节点的主要压缩包一样工作?
    • AFAIK,重建和退役都与压缩无关——它们只是流式传输数据。请查看我对答案的编辑。
    • 我的意思是,如果 decom 没有从大表中流式传输 TS shadowed 数据,那么 decom+rejoin 后的效果可能类似于压缩掉 TSed 数据。只有当同一个文件包含 TTL 过期数据时,单个文件压缩才正确有用,否则为了回收磁盘空间,我们还需要考虑我们的应用程序从其他较小的表生成的 TS。见thelastpickle.com/blog/2016/07/27/…
    • 再一次,AFAIK,退役将流式传输 TSed 数据,并且不会执行压缩。
    • 我在较小的表中看到三个带有 TS 的选项,并将旧数据推送到大表中。 1)进行主要的压缩(旨在将您的 CF 数据保存在一个 [大] 表中,2)decom+rejoin(大量数据混洗 wo/vnodes),3)离线并进行 sstablesplit。 1+2 在操作过程中保持完全冗余,3 不,1 可能意味着定期进行重大压缩,否则我们很快就结束了。 App Vendor 不推荐 LCS,但 STCS+regulary major compac+no vnodes。我们在 STCS+vnodes+not-happy-doing-majors-due-to-load...
    猜你喜欢
    • 2015-02-12
    • 1970-01-01
    • 2013-11-06
    • 1970-01-01
    • 2015-11-13
    • 2018-05-09
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多