do sstablesplit на стороне

Question

Поскольку sstables являются неизменяемыми и sstable split должен выполняться автономно, т.е. с отключением узла. Разве также не было бы возможности разделить копии крайне больших sstables в автономном режиме/в sideline dir, сохраняя при этом узел онлайн, после чего сворачивайте экстремальные sstables с набором разделенных sstable-файлов во время короткого перезапуска узла, чтобы минимизировать время простоя узла ?

Или было бы лучше списание узла, распространение данных по остальной части кластера, а затем вернуться в новом пустом узле

Eg. имея несколько больших sstables, которые не попадают в представление уплотнения в ближайшее время. Я хотел бы разделить такие оффлайн-сообщения в другом каталоге/FS/на другом поле, где бы он ни находился вне области действия от запущенного узла, но при этом сохраняется избыточность обслуживания узла с исходного пути sstable. Только кажется, что sstablesplit хочет найти конфигурацию, или ее можно обмануть, чтобы в противном случае сделать раздвоенный доступ из работающего узла?

Пробовал на копии sstable файла разбить его, но:

на-offlinebox $ sstablesplit --debug -s НЕКОТОРЫХ-VALUE-IN-MB mykeyspc-mycf - * - Данные .db 16: 58: 13.197 [main] ERROR oacconfig.DatabaseDescriptor - Fatal ошибка конфигурации org.apache.cassandra.exceptions.ConfigurationException: Ожидание URI в переменной: [cassandra.config]. Пожалуйста, префикс файла с файлом: /// для локальных файлов или файлов: /// для удаленных файлов. Aborting. Если вы используете из внешнего инструмента, для предотвращения загрузки конфигурации необходимо установить Config.setClientMode (true). на org.apache.cassandra.config.YamlConfigurationLoader.getStorageConfigURL (YamlConfigurationLoader.java:73) ~ [апаша-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] at org.apache.cassandra.config.DatabaseDescriptor.loadConfig (DatabaseDescriptor.java:161) ~ [apache-cassandra -2.1.15.jar: 2.1.15] at org.apache.cassandra.config.DatabaseDescriptor. (DatabaseDescriptor.java:136) ~ [apache-cassandra-2.1.15.jar: 2.1.15] at org .apache.cassandra.tools.StandaloneSplitter.main (StandaloneSplitter.java:56) [apache-cassandra-2.1.15.jar: 2.1.15] Ожидание URI в varia ble: [cassandra.config]. Пожалуйста префикс файла с файлом: /// для локального файлов или файлов: /// для удаленных файлов. Aborting. Если вы используете , выполнив это с помощью внешнего инструмента, ему необходимо установить Config.setClientMode (true), чтобы избежать загрузки конфигурации. Fatal ошибка конфигурации; невозможно начать. См. Журнал для stacktrace.

Answer 1

Если вы можете позволить себе время простоя для узла, просто сделайте это (разделите таблицы). В любом случае, если вы сделаете это разделение на другой машине/другой директории, вам нужно будет выполнить ремонт на узле (из-за «автономного» времени перестроенных таблиц) после перезагрузки sstables.

Вы также можете попробовать сбросить эти файлы данные таблицы из вашего узла и текущего ремонта, то это будет, вероятно, минимальное время простоя для узла:

Стоп узла -> Удалить большой sstables -> Запустить узел -> Ремонт.

EDIT: Начиная с Cassandra 3.4, вы можете запускать компактную команду для определенных sstables/файлов. В любой более ранней версии вы можете использовать вызов 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.