Skip to main content

Обзор

В ClickHouse «ограничения» для настроек — это ограничения и правила, которые можно назначать настройкам. Эти ограничения помогают поддерживать стабильность, безопасность и предсказуемое поведение вашей базы данных.

Определение ограничений

Ограничения для настроек можно задать в разделе profiles файла конфигурации user.xml. Они запрещают пользователям изменять некоторые настройки с помощью оператора SET. Ограничения задаются следующим образом:
Если пользователь пытается нарушить ограничения, генерируется исключение, а значение настройки остается неизменным.

Типы ограничений

В ClickHouse поддерживается несколько типов ограничений:
  • min
  • max
  • disallowed
  • readonly (с псевдонимом const)
  • changeable_in_readonly
Ограничения min и max задают верхнюю и нижнюю границы для числовой настройки и могут использоваться совместно. Ограничение disallowed используется, чтобы указать конкретное значение или набор значений, которые не допускаются для определенной настройки. Ограничение readonly или const указывает, что пользователь вообще не может изменять соответствующую настройку. Тип ограничения changeable_in_readonly позволяет пользователям изменять настройку в пределах диапазона min/max, даже если для настройки readonly установлено значение 1; в противном случае в режиме readonly=1 изменять настройки нельзя.
changeable_in_readonly поддерживается, только если включен параметр settings_constraints_replace_previous:

Не делайте readonly изменяемым в режиме только для чтения

Не включайте readonly в список changeable_in_readonly ни в одном профиле, в том числе в профилях, которые никому не назначены: любой сеанс может выбрать профиль по имени.
Не помечайте сам параметр readonly как changeable_in_readonly. Иначе сеанс, начавшийся со значением readonly = 1, сможет выполнить SET readonly = 0 и вновь получить возможность выполнять запросы на запись, которые и так разрешены его текущими привилегиями, если только то же ограничение не запрещает значение 0. Это касается каждого определённого вами профиля, а не только назначенных:
  • SET profile не проверяется по правам доступа, поэтому любой сеанс может выбрать любой профиль по имени. Профиль остаётся доступным, даже если он никому не назначен, однако вносимые им изменения всё равно проверяются на соответствие ограничениям, уже действующим в этом сеансе.
  • По HTTP запросы GET принудительно переводятся в readonly = 2 только тогда, когда эффективное значение в противном случае было бы равно 0. Поэтому профиль, который задаёт readonly = 1, но при этом разрешает изменять readonly в режиме только для чтения, сводит эту защиту на нет, поскольку запрос GET может переключить значение на 0 и выполнить запись.

Несколько профилей ограничений

Если для пользователя активно несколько профилей, ограничения объединяются. Процесс объединения зависит от settings_constraints_replace_previous:
  • true (рекомендуется): ограничения для одной и той же настройки при объединении заменяются, поэтому используется последнее ограничение, а все предыдущие игнорируются. Это относится и к полям, не заданным в новом ограничении.
  • false (по умолчанию): ограничения для одной и той же настройки объединяются так, что каждый незаданный тип ограничения берётся из предыдущего профиля, а каждый заданный тип ограничения заменяется значением из нового профиля.

Режим только для чтения

Режим только для чтения включается настройкой readonly, которую не следует путать с типом ограничения (CONSTRAINT) readonly. При readonly = 1 настройку, изменение которой иначе было бы отклонено, всё же можно изменить, если это допускает ограничение changeable_in_readonly. О том, что означают значения этой настройки, см. справочник по настройкам; о том, какие классы запросов разрешает каждое значение и как его устанавливает HTTP interface, см. разрешения для запросов.

Пример

Пусть файл users.xml содержит следующие строки:
Для всех следующих запросов будет сгенерировано исключение:
Профиль default обрабатывается особым образом: все ограничения, заданные для профиля default, становятся ограничениями по умолчанию, поэтому они применяются ко всем пользователям, пока для них явно не заданы другие.

Ограничения на настройки MergeTree

Для настроек MergeTree можно задавать ограничения. Эти ограничения применяются при создании таблицы с движком MergeTree или при изменении её настроек хранения. При указании имени настройки MergeTree в разделе <constraints> к нему необходимо добавлять префикс merge_tree_.

Пример

Вы можете запретить создание новых таблиц с явно заданной storage_policy
Последнее изменение 26 сентября 2026 г.