сделать sstablesplit на стороне

Поскольку sstable неизменяемы, разделение sstable должно выполняться в автономном режиме, т.е. с отключением узла. Не было бы также возможно разделить копии чрезвычайно больших sstables в автономном режиме/в боковой директории, сохраняя при этом узел в сети, а затем заменять крайние sstables набором разделенных файлов 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:/// для локальных файлов или file:/// для удаленных файлов. Прерывание. Если вы выполняете это из внешнего инструмента, необходимо установить Config.setClientMode(true), чтобы избежать загрузки конфигурации. Фатальная ошибка конфигурации; невозможно начать. Смотрите журнал для трассировки стека.


cassandra cassandra-2.1
person Steffen Winther Sørensen    schedule 04.02.2017    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

Остановить узел -> Удалить большие sstables -> Запустить узел -> Восстановить.

РЕДАКТИРОВАТЬ: Начиная с Cassandra 3.4, вы можете запускать компактную команду для определенных sstables/файлов. В любой более ранней версии вы можете использовать вызов jmx forceUserDefinedCompaction. Вы можете использовать один из них или сделать вызов 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.

person nevsv    schedule 05.02.2017
comment
Причина, по которой мы хотим выполнить сжатие таких больших sstables, заключается в том, что мы ожидаем иметь много надгробий для некоторых данных, находящихся в больших sstables. TS были созданы +30 дней назад, поэтому они давно просрочены gc_grace по умолчанию 10 дней. Только пройдет много времени, прежде чем такие TS будут уплотняться против нескольких лишних нескольких крупных sstables. Наш поставщик приложений говорит, что каждую ночь нужно запускать крупные компаки и не использовать vnodes, поскольку мы полагаемся на второстепенные компаки. Будут ли данные TSed также распространяться на деком или только «живые данные», т.е. может ли decom-rejoin работать аналогично основному compac для отдельного узла? - person Steffen Winther Sørensen; 05.02.2017
comment
Насколько мне известно, и перестроение, и вывод из эксплуатации не имеют ничего общего с уплотнением — они просто передают данные. Пожалуйста, просмотрите мое редактирование ответа. - person nevsv; 05.02.2017
comment
Я имел в виду, что если бы decom не передавал теневые данные TS из большой таблицы, то эффект после decom+rejoin мог бы быть подобен сжатию данных TSed. сжатие одного файла правильно полезно только в том случае, если тот же файл содержит данные с истекшим сроком действия TTL, в противном случае, чтобы освободить место на диске, нам также нужно будет учитывать TS, созданные нашим приложением, из других меньших таблиц. См. thelastpickle.com/blog/2016/07/27. / - person Steffen Winther Sørensen; 05.02.2017
comment
Опять же, насколько я знаю, вывод из эксплуатации БУДЕТ передавать данные TSed, и уплотнение не будет выполняться. - person nevsv; 05.02.2017
comment
Я вижу три варианта с TS в меньших таблицах и старые данные, помещенные в большие таблицы. 1) сделать основные уплотнения (с целью сохранить ваши данные CF в одной [большой] таблице, 2) decom+rejoin (перетасовка большого количества данных wo/vnodes), 3) в автономном режиме и выполнить sstablesplit. 1+2 поддерживает полную избыточность во время операции, 3 - нет, 1 может означать, что нужно продолжать регулярно выполнять крупные уплотнения, иначе мы вскоре закончим аналогичным образом. App Vendor рекомендует не LCS, а STCS+обычный мажорный compac+без vnodes. Мы на STCS+vnodes+не-довольно-делаем-основные-из-за-загрузки... - person Steffen Winther Sørensen; 05.02.2017
comment
Поэтому, если decom выполняет потоковую передачу данных TSed, тогда мы должны стремиться к серьезному сжатию, чтобы освободить место на диске и сохранить избыточность во время работы... - person Steffen Winther Sørensen; 05.02.2017
comment
Одной из проблем, которую решает LCS, является ваш сценарий с большими таблицами, которые никогда не уплотнялись... Поскольку ваши данные могут быть распределены по нескольким sstables, единственный способ вернуть все пространство, используемое старыми/TS-данными, - это выполнить серьезное уплотнение. - person nevsv; 05.02.2017