Владимир, поделитесь пожалуйста опытом - были ли другие пробелмы кроме озвученной у вас при таком обновлении-прыжке?
У нас кластер на 19.16 и вопрос обновления стоит уже критически. Хочется прийти к 20.8-lts, но сразу через такое кол-во версий прыгать страшно, а роллить по мажору и каждый перепроверять - много чело-часов надо и вообще времени. Чейнджлог весь прочитали, критов обратно несовместимых не заметили вроде бы.
У нас кластер в 3 шарда, в шарде по 2 ноды, куча replicated/distributed но пишем напрямую в Replicated.

И 2 вопроса к аудитории(гуглил, ответов что-то не нашел):
1. Роллинг апдейт: есть ли принципиально не совместимые версии между 19.16 и 20.8 которые никак не будут работать в одном кластере? Можно ли писать в новую/старую ноду когда кластер не полностью обновлен?
2. есть ли какая-то политика отката ноды? Т.е. в случае чего можно ли кластер откатить на старую версию? Например, если не было записи в ноду с новой версией.

У нас все прошло гладко относительно. Делали сначала на тесте естественно.
Установили флажки

 <joined_subquery_requires_alias>0</joined_subquery_requires_alias>
 <any_join_distinct_right_table_keys>1</any_join_distinct_right_table_keys>

На проде во избежании проблем при обновлении отключили писателей на время обновления
Обновляли все ноды одновременно. Заняло минут 10 простоя, для нас не критично
2 дня полет нормальный, но страшно было тоже

Ок, спасибо за инфу. Желаю вам дальнейшего полета без проблем!) Но если вдруг что-то появится, дайте знать пожалуйста, буду безмерно благодарен.

Договорились

Огромное спасибо
Получилось
Логика секции ARRAY JOIN сходу трудно усваиваемая
Надо попрактиковаться

Всем привет. А кто то юзает redash ?

В словарях есть ограничение на длину строкого атрибута?
тип словаря hashed, источник odbc (postgres)

получаю в качестве значения только часть строки

что надежней работает для сброса старых партов в другой сторедж

* policy + move_factor (как часто он тригерится?)
* TTL TO VOLUME

?

есть проблема с >1024 символов в odbc

похоже в моем случае проблема с odbc

первый скрин isql
второй из psql

План очень сильно зависит от размера кластера.
Можно апгрейдится напрямую с 19.16 в 20.8
апргейдить репликами, т.е. distributed запросы могут давать неверный результат. Инсерты лучше остановить пока не проапгрейжены все ноды.

Мой план: У меня 2 дц, реплики в разных.
выключить инсерты везде.
отключить селекты в дц1
проапгрейдить все шарды в дц1
включить селекты дц1
отключить селекты в дц2
проапгрейдить все шарды в дц2

даунгрейд возможен, если вы не делали alter table (мутации). теперь все alter table, даже add column работают через мутации.

Я тещу 20.8 с октября, на 2х стейджах + LT
Мне нужно изменить 4 параметра чтобы софт мог работать с 20.8 типа
<any_join_distinct_right_table_keys>1</any_join_distinct_right_table_keys>
    <joined_subquery_requires_alias>0</joined_subquery_requires_alias>
и еще какие-то

я 4 раза уже протестил апгрейд/даунгрейд, все ОК, но у меня выключена адаптивная гранулярность и поэтому автоматически не работают компактные парты и все такое, компактные парты созданные в 20.8 естественно не приатачатся в 19.16

не бекпортили кажется

в 20.8.5 не было еще проблемы

Проапдейтились до 20.8.12.2-lts
Ошибка ушла

а какая была 20.8 ?

https://github.com/ClickHouse/ClickHouse/compare/v20.8.11.17-lts...v20.8.12.2-lts
тут есть...  15 января...

Спасибо большое за ответ! Про ALTER'ы и мутации очень полезно.
У нас distributed по факту используются не совсем так как они задуманы. У нас 3 шарда, Distributed смотрит в Replicated. Данные пишутся в Replicated напрямую, шардирование идет по проекту, данные между проектами не пересекаются никак(т.е. нет запроса который тянет данные с разных шардов).

EDIT: Но запрос может прийти на шард 1 а все данные для него на шарде 2

А что скажете на счет такого плана:
1. переносим запись/чтение на одно зеркало в каждом шарде(группа old)
2. обновляем оставшиеся зеркала(группа new)
3. Пробуем читать из new
4. Если все ОК то останавливаем запись(или переносим на группу new)
5. Апдейт группы old

Если не ок то откат/ресетап зеркал группы new.