Комментарии 5
Вы не первые, кто наступил в историю с общим ЗК на несколько кластеров КХ. И причём, чтобы КХ шли под одними ключами ) Спасибо за информацию, что так делать не надо ))) запомним ещё раз ))))
выдающуюся стойкость ClickHouse к различным вариантам поломок
Я бы не переоценивал это качество ) Коллеги умудрились таки получить фарш из данных )))
С одной стороны это выглядит, как простая ошибка эксплуатации.
Но с другой стороны, надо подумать — можно ли улучшить юзабилити системы, чтобы уменьшить возможности возникновения таких ошибок. Я как раз думаю, что можно улучшить.
Один вариант — проверять доступность хотя бы одной из существующих реплик при создании новой реплики. То есть, что новая реплика сможет скачать хоть какие-то данные с существующих.
Этот вариант не подходит по двум причинам:
- добавление новой реплики при временной недоступности старой — полностью легальный сценарий;
- это не защитит от ошибки, когда реплики всё-таки доступны по сети, но новая реплика добавляется по ошибке.
Второй вариант — сделать новую форму запросов CREATE REPLICA, и сделать так, что CREATE TABLE будет только соглашаться создавать новую таблицу, а не новую реплику существующей таблицы. Но это поломает обратную совместимость. Или сделать форму запроса CREATE TABLE… FIRST REPLICA, которая будет проверять то же самое. Вроде уже лучше. Но непонятно, насколько внесение изменений в язык запросов соотносится с тем, будут ли это широко использовать.
Третий вариант — это выводить логи в клиент при создании таблицы. В логах уже написано — первая ли это реплика или новая реплика, которая будет клонировать существующую. И эти логи можно получить, выставив send_logs_level. Остаётся только включить вывод каких-то вариантов логов на клиент по-умолчанию и рассчитывать на то, что их прочитают.
Четвёртый вариант — при создании новой реплики, возвращать результат CREATE TABLE только после того, как новая реплика синхронизировалась. Этот вариант тоже отменяется, так как синхронизация часто бывает долгой (дни). Делать для этой опции отдельную настройку тоже нецелесообразно, так как её мало кто будет использовать.
Спасибо за статью. Для обучения, одна история неудачи стоит десяти историй "успеха"!
«Семь раз отмерь — один раз отрежь». При проектировании решения продумывайте сценарии, когда что-то может пойти не так (и почему). Стоит допускать любые варианты, включая самые, казалось бы, невероятные.
По-английски это называется "Failure Mode and Effects Analysis", например, вот очень хороший пост на тему.
Предварительно и в процессе внедрения решения, к которому вы хотите прийти в итоге, обсуждайте его с коллегами. Убедитесь, что все явно понимают ключевые моменты и возможные нюансы.
Когда вы готовите какую-либо инфраструктуру для разработки, давайте коллегам её полное и максимально детальное описание, чтобы не случилось казуса.
Обычно такие выводы остаются исключительно на бумаге (в секции "будущие шаги" пост-мортема, прямо как у вас), прямо как новогодние обещания. Полезно быть реалистом на этот счет :)
Для обучения, одна история неудачи стоит десяти историй «успеха»!
Это верно! :)
По-английски это называется «Failure Mode and Effects Analysis», например, вот очень хороший пост на тему.
Спасибо, изучим!
Обычно такие выводы остаются исключительно на бумаге (в секции «будущие шаги» пост-мортема, прямо как у вас), прямо как новогодние обещания. Полезно быть реалистом на этот счет :)
Ну, тут два момента, первый — мы стараемся все-таки избегать вот этих вот бумажных формализмов и если и пишем про «будущие шаги», то стараемся их делать выполнимыми и реальными и второе — лично я реалист, но с верой в лучшее, как минимум стремление к выполнению этого шага уже даёт существенный позитивный рывок ;)
Чтобы использовать один зк на нескольких кластерах безопасно, можно задать разные параметры root в конфигурации zookeeper https://clickhouse.tech/docs/en/operations/server-configuration-parameters/settings/#server-settings_zookeeper
Тогда кластеры даже не будут иметь возможности залезть в одну и ту же "поддиректорию"
Аварии как опыт #1. Как сломать два кластера ClickHouse, не уточнив один нюанс