тачке и storage_policy?
как решали проблему что после того как КХ намувит, надо shadow почистить / посинкать как то?
а откуда вы получили "не пустой shadow" ? FREEZE делали? и не убрали за собой?
Да. Оставляем прям на тачках в качестве горячего "снапшота", если это корректно так назвать.
Ну freeze это хардлинки Вы знаете что такое хардлинки?
Да конечно. Допустим у меня есть ssd первым приоритетом и hdd вторым, есть некоторый move_factor. Вот я делаю freeze. Вот кликхаус стаскал с ssd на hdd какие то парты. Предложения как поступить дальше? Я думал над тем чтобы искать в parts_log мувы и перефриживать их прицельно.
При move У вас хардлинк inode и аккокация физического места сохраняется Вам сначала надо shadow чистить А какой смысл вообще старые парты держать кроме как для бекапа? И какой смысл в бекапе на том же диске?
Все так, вы совершенно правы, сохраняется. В этом то и вопрос, как бы их актуализировать чтоб из shadow на ssd пропало и в shadow на hdd появилось. И так же хардлинком. И наиболее оптимальным способом. И желательно максимально своевременно, потому что КХ не учитывает наличие такого хардлинка, что вобщем то и логично. А вот мне надо какой то такой механизм ( В этом то и проблема. Смысл такого бэкапа, я б назвал его снапшотом, в том что данных много, и таскать куда то на холодное хранение дорого. Реплик три штуки на шард, снапшотятся все реплики. Потеря одной означает что ещё на 2-х останется такой снапшот.
Вы не ответили на вопрос зачем вам хардлинки Какую проблему вы решаете? Если горячее резервирование то вы решаете ее не правильно
У меня нет проблемы горячего резервирования, у меня 3 реплики на шард, две справляются в случае отказа одной, я проверял. Хардлинки мне для бэкапов, и я их делаю локально. Какую проблему решаю озвучил в первом сообщении, давайте перешлю )
@BloodJazMan , вот она проблема, переслал )
Хардлинк это не бекап Бекап это копия данных которая хранится хотя бы на другом диске А лучше на другой машине
У меня 3 реплики, по отношению к одной две другие это как раз другой диск и другая машина. Вы понимаете что такое хардлинк? Это то что позволяет мне пару петов сэкономить на резервном копировании. Очень дорого таскать такой объем данных куда то ещё на холодное хранение. Поэтому поставил вопрос сразу так как поставил, но мы не ищем ответ а спорим о понятиях )
Это не проблема Это попытка ликвидации последствий неправильного решения Хардлинки для бекапов нужны только для консистентности перед upload на remote storage
у вас какая-та очень необычная задачка. Даже интересно стало. Обычно бекапы делают против гибели дисков и машин. Против этих рисков отлично спасает replicated. Заодно и пиковые нагрузки сглаживает. И не надо одномоментно качать пентабайты. А вы какой риск преодолеваете? Враги хакнут и заинсертят что-то такое что испортит аналитику? Или вы сами в измененном сознании запустите alter table delete where 1? Или что?
как раз в любом осуждении backup vs raid1 говорится, что raid не предотвратит ошибочного удаления данных
Да, именно так. Реплики для ошибок железа, бэкапы для ошибок людей. По классике )
Обсуждают сегодня