Server Settings Outside Source

asynchronous_metric_log {#asynchronous_metric_log}

Enabled by default on ClickHouse Cloud deployments.

If the setting is not enabled by default on your environment, depending on how ClickHouse was installed, you can follow the instruction below to enable or disable it.

Enabling

To manually turn on asynchronous metric logs history collection system.asynchronous_metric_log, create /etc/clickhouse-server/config.d/asynchronous_metric_log.xml with the following content:

<clickhouse>
     <asynchronous_metric_log>
        <database>system</database>
        <table>asynchronous_metric_log</table>
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
        <collect_interval_milliseconds>1000</collect_interval_milliseconds>
        <max_size_rows>1048576</max_size_rows>
        <reserved_size_rows>8192</reserved_size_rows>
        <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
        <flush_on_crash>false</flush_on_crash>
    </asynchronous_metric_log>
</clickhouse>

Disabling

To disable asynchronous_metric_log setting, you should create the following file /etc/clickhouse-server/config.d/disable_asynchronous_metric_log.xml with the following content:

<clickhouse><asynchronous_metric_log remove="1" /></clickhouse>

auth_use_forwarded_address {#auth_use_forwarded_address}

Use originating address for authentication for clients connected through proxy.

:::note This setting should be used with extra caution since forwarded addresses can be easily spoofed - servers accepting such authentication should not be accessed directly but rather exclusively through a trusted proxy. :::

backups {#backups}

Settings for backups, used when executing the BACKUP and RESTORE statements.

The following settings can be configured by sub-tags:

This setting is configured by default as:

<backups>
    ....
</backups>

background_schedule_pool_log {#background_schedule_pool_log}

Contains information about all background tasks that are executed via various background pools.

<background_schedule_pool_log>
    <database>system</database>
    <table>background_schedule_pool_log</table>
    <partition_by>toYYYYMM(event_date)</partition_by>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
    <max_size_rows>1048576</max_size_rows>
    <reserved_size_rows>8192</reserved_size_rows>
    <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
    <flush_on_crash>false</flush_on_crash>
    <!-- Only tasks longer than duration_threshold_milliseconds will be logged. Zero means log everything -->
    <duration_threshold_milliseconds>0</duration_threshold_milliseconds>
</background_schedule_pool_log>

bcrypt_workfactor {#bcrypt_workfactor}

Work factor for the bcrypt_password authentication type which uses the Bcrypt algorithm. The work factor defines the amount of computations and time needed to compute the hash and verify the password.

<bcrypt_workfactor>12</bcrypt_workfactor>

:::warning For applications with high-frequency authentication, consider alternative authentication methods due to bcrypt's computational overhead at higher work factors. :::

table_engines_require_grant {#table_engines_require_grant}

If set to true, users require a grant to create a table with a specific engine e.g. GRANT TABLE ENGINE ON TinyLog to user.

:::note By default, for backward compatibility creating table with a specific table engine ignores grant, however you can change this behaviour by setting this to true. :::

builtin_dictionaries_reload_interval {#builtin_dictionaries_reload_interval}

The interval in seconds before reloading built-in dictionaries.

ClickHouse reloads built-in dictionaries every x seconds. This makes it possible to edit dictionaries "on the fly" without restarting the server.

Example

<builtin_dictionaries_reload_interval>3600</builtin_dictionaries_reload_interval>

compression {#compression}

Data compression settings for MergeTree-engine tables.

:::note We recommend not changing this if you have just started using ClickHouse. :::

Configuration template:

<compression>
    <case>
      <min_part_size>...</min_part_size>
      <min_part_size_ratio>...</min_part_size_ratio>
      <method>...</method>
      <level>...</level>
    </case>
    ...
</compression>

<case> fields:

• min_part_size – The minimum size of a data part.
• min_part_size_ratio – The ratio of the data part size to the table size.
• method – Compression method. Acceptable values: lz4, lz4hc, zstd,deflate_qpl.
• level – Compression level. See Codecs.

:::note You can configure multiple <case> sections. :::

Actions when conditions are met:

• If a data part matches a condition set, ClickHouse uses the specified compression method.
• If a data part matches multiple condition sets, ClickHouse uses the first matched condition set.

:::note If no conditions are met for a data part, ClickHouse uses the lz4 compression. :::

Example

<compression incl="clickhouse_compression">
    <case>
        <min_part_size>10000000000</min_part_size>
        <min_part_size_ratio>0.01</min_part_size_ratio>
        <method>zstd</method>
        <level>1</level>
    </case>
</compression>

encryption {#encryption}

Configures a command to obtain a key to be used by encryption codecs. Key (or keys) should be written in environment variables or set in the configuration file.

Keys can be hex or string with a length equal to 16 bytes.

Example

Loading from config:

<encryption_codecs>
    <aes_128_gcm_siv>
        <key>1234567812345678</key>
    </aes_128_gcm_siv>
</encryption_codecs>

:::note Storing keys in the configuration file is not recommended. It isn't secure. You can move the keys into a separate config file on a secure disk and put a symlink to that config file to config.d/ folder. :::

Loading from config, when the key is in hex:

<encryption_codecs>
    <aes_128_gcm_siv>
        <key_hex>00112233445566778899aabbccddeeff</key_hex>
    </aes_128_gcm_siv>
</encryption_codecs>

Loading key from the environment variable:

<encryption_codecs>
    <aes_128_gcm_siv>
        <key_hex from_env="ENVVAR"></key_hex>
    </aes_128_gcm_siv>
</encryption_codecs>

Here current_key_id sets the current key for encryption, and all specified keys can be used for decryption.

Each of these methods can be applied for multiple keys:

<encryption_codecs>
    <aes_128_gcm_siv>
        <key_hex id="0">00112233445566778899aabbccddeeff</key_hex>
        <key_hex id="1" from_env="ENVVAR"></key_hex>
        <current_key_id>1</current_key_id>
    </aes_128_gcm_siv>
</encryption_codecs>

Here current_key_id shows current key for encryption.

Also, users can add nonce that must be 12 bytes long (by default encryption and decryption processes use nonce that consists of zero bytes):

<encryption_codecs>
    <aes_128_gcm_siv>
        <nonce>012345678910</nonce>
    </aes_128_gcm_siv>
</encryption_codecs>

Or it can be set in hex:

<encryption_codecs>
    <aes_128_gcm_siv>
        <nonce_hex>abcdefabcdef</nonce_hex>
    </aes_128_gcm_siv>
</encryption_codecs>

:::note Everything mentioned above can be applied for aes_256_gcm_siv (but the key must be 32 bytes long). :::

error_log {#error_log}

It is disabled by default.

Enabling

To manually turn on error history collection system.error_log, create /etc/clickhouse-server/config.d/error_log.xml with the following content:

<clickhouse>
    <error_log>
        <database>system</database>
        <table>error_log</table>
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
        <collect_interval_milliseconds>1000</collect_interval_milliseconds>
        <max_size_rows>1048576</max_size_rows>
        <reserved_size_rows>8192</reserved_size_rows>
        <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
        <flush_on_crash>false</flush_on_crash>
    </error_log>
</clickhouse>

Disabling

To disable error_log setting, you should create the following file /etc/clickhouse-server/config.d/disable_error_log.xml with the following content:

<clickhouse>
    <error_log remove="1" />
</clickhouse>

custom_settings_prefixes {#custom_settings_prefixes}

List of prefixes used for custom settings. Multiple prefixes should be separated by commas.

Example

<custom_settings_prefixes>SQL_</custom_settings_prefixes>

See Also

• Custom settings

core_dump {#core_dump}

Configures soft limit for core dump file size.

:::note Hard limit is configured via system tools :::

Example

<core_dump>
     <size_limit>1073741824</size_limit>
</core_dump>

default_profile {#default_profile}

Default settings profile. Settings profiles are located in the file specified in the setting user_config.

Example

<default_profile>default</default_profile>

dictionaries_config {#dictionaries_config}

The path to the config file for dictionaries.

Path:

• Specify the absolute path or the path relative to the server config file.
• The path can contain wildcards * and ?.

See also:

• "Dictionaries".

Example

<dictionaries_config>*_dictionary.xml</dictionaries_config>

user_defined_executable_functions_config {#user_defined_executable_functions_config}

The path to the config file for executable user defined functions.

Path:

• Specify the absolute path or the path relative to the server config file.
• The path can contain wildcards * and ?.

See also:

• "Executable User Defined Functions.".

Example

<user_defined_executable_functions_config>*_function.xml</user_defined_executable_functions_config>

graphite {#graphite}

Sending data to Graphite.

Settings:

• host – The Graphite server.
• port – The port on the Graphite server.
• interval – The interval for sending, in seconds.
• timeout – The timeout for sending data, in seconds.
• root_path – Prefix for keys.
• metrics – Sending data from the system.metrics table.
• events – Sending deltas data accumulated for the time period from the system.events table.
• events_cumulative – Sending cumulative data from the system.events table.
• asynchronous_metrics – Sending data from the system.asynchronous_metrics table.

You can configure multiple <graphite> clauses. For instance, you can use this for sending different data at different intervals.

Example

<graphite>
    <host>localhost</host>
    <port>42000</port>
    <timeout>0.1</timeout>
    <interval>60</interval>
    <root_path>one_min</root_path>
    <metrics>true</metrics>
    <events>true</events>
    <events_cumulative>false</events_cumulative>
    <asynchronous_metrics>true</asynchronous_metrics>
</graphite>

graphite_rollup {#graphite_rollup}

Settings for thinning data for Graphite.

For more details, see GraphiteMergeTree.

Example

<graphite_rollup_example>
    <default>
        <function>max</function>
        <retention>
            <age>0</age>
            <precision>60</precision>
        </retention>
        <retention>
            <age>3600</age>
            <precision>300</precision>
        </retention>
        <retention>
            <age>86400</age>
            <precision>3600</precision>
        </retention>
    </default>
</graphite_rollup_example>

http_handlers {#http_handlers}

Allows using custom HTTP handlers. To add a new http handler simply add a new <rule>. Rules are checked from top to bottom as defined, and the first match will run the handler.

The following settings can be configured by sub-tags:

handler contains the following settings, which can be configured by sub-tags:

Along with a list of rules, you can specify <defaults/> which specifies to enable all the default handlers.

Example:

<http_handlers>
    <rule>
        <url>/</url>
        <methods>POST,GET</methods>
        <headers><pragma>no-cache</pragma></headers>
        <handler>
            <type>dynamic_query_handler</type>
            <query_param_name>query</query_param_name>
        </handler>
    </rule>

    <rule>
        <url>/predefined_query</url>
        <methods>POST,GET</methods>
        <handler>
            <type>predefined_query_handler</type>
            <query>SELECT * FROM system.settings</query>
        </handler>
    </rule>

    <rule>
        <handler>
            <type>static</type>
            <status>200</status>
            <content_type>text/plain; charset=UTF-8</content_type>
            <response_content>config://http_server_default_response</response_content>
        </handler>
    </rule>
</http_handlers>

http_server_default_response {#http_server_default_response}

The page that is shown by default when you access the ClickHouse HTTP(s) server. The default value is "Ok." (with a line feed at the end)

Example

Opens https://tabix.io/ when accessing http://localhost: http_port.

<http_server_default_response>
  <![CDATA[<html ng-app="SMI2"><head><base href="http://ui.tabix.io/"></head><body><div ui-view="" class="content-ui"></div><script src="http://loader.tabix.io/master.js"></script></body></html>]]>
</http_server_default_response>

http_options_response {#http_options_response}

Used to add headers to the response in an OPTIONS HTTP request. The OPTIONS method is used when making CORS preflight requests.

For more information, see OPTIONS.

Example:

<http_options_response>
     <header>
            <name>Access-Control-Allow-Origin</name>
            <value>*</value>
     </header>
     <header>
          <name>Access-Control-Allow-Headers</name>
          <value>origin, x-requested-with, x-clickhouse-format, x-clickhouse-user, x-clickhouse-key, Authorization</value>
     </header>
     <header>
          <name>Access-Control-Allow-Methods</name>
          <value>POST, GET, OPTIONS</value>
     </header>
     <header>
          <name>Access-Control-Max-Age</name>
          <value>86400</value>
     </header>
</http_options_response>

hsts_max_age {#hsts_max_age}

Expired time for HSTS in seconds.

:::note A value of 0 means ClickHouse disables HSTS. If you set a positive number, the HSTS will be enabled and the max-age is the number you set. :::

Example

<hsts_max_age>600000</hsts_max_age>

interserver_listen_host {#interserver_listen_host}

Restriction on hosts that can exchange data between ClickHouse servers. If Keeper is used, the same restriction will be applied to the communication between different Keeper instances.

:::note By default, the value is equal to the listen_host setting. :::

Example

<interserver_listen_host>::ffff:a00:1</interserver_listen_host>
<interserver_listen_host>10.0.0.1</interserver_listen_host>

Type:

Default:

interserver_http_credentials {#interserver_http_credentials}

A username and a password used to connect to other servers during replication. Additionally, the server authenticates other replicas using these credentials. interserver_http_credentials must therefore be the same for all replicas in a cluster.

:::note

• By default, if interserver_http_credentials section is omitted, authentication is not used during replication.
• interserver_http_credentials settings do not relate to a ClickHouse client credentials configuration.
• These credentials are common for replication via HTTP and HTTPS. :::

The following settings can be configured by sub-tags:

• user — Username.
• password — Password.
• allow_empty — If true, then other replicas are allowed to connect without authentication even if credentials are set. If false, then connections without authentication are refused. Default: false.
• old — Contains old user and password used during credential rotation. Several old sections can be specified.

Credentials Rotation

ClickHouse supports dynamic interserver credentials rotation without stopping all replicas at the same time to update their configuration. Credentials can be changed in several steps.

To enable authentication, set interserver_http_credentials.allow_empty to true and add credentials. This allows connections with authentication and without it.

<interserver_http_credentials>
    <user>admin</user>
    <password>111</password>
    <allow_empty>true</allow_empty>
</interserver_http_credentials>

After configuring all replicas set allow_empty to false or remove this setting. It makes authentication with new credentials mandatory.

To change existing credentials, move the username and the password to interserver_http_credentials.old section and update user and password with new values. At this point the server uses new credentials to connect to other replicas and accepts connections with either new or old credentials.

<interserver_http_credentials>
    <user>admin</user>
    <password>222</password>
    <old>
        <user>admin</user>
        <password>111</password>
    </old>
    <old>
        <user>temp</user>
        <password>000</password>
    </old>
</interserver_http_credentials>

When new credentials are applied to all replicas, old credentials may be removed.

ldap_servers {#ldap_servers}

List LDAP servers with their connection parameters here to:

• use them as authenticators for dedicated local users, who have an 'ldap' authentication mechanism specified instead of 'password'
• use them as remote user directories.

The following settings can be configured by sub-tags:

Setting user_dn_detection can be configured with sub-tags:

Example:

<my_ldap_server>
    <host>localhost</host>
    <port>636</port>
    <bind_dn>uid={user_name},ou=users,dc=example,dc=com</bind_dn>
    <verification_cooldown>300</verification_cooldown>
    <enable_tls>yes</enable_tls>
    <tls_minimum_protocol_version>tls1.2</tls_minimum_protocol_version>
    <tls_require_cert>demand</tls_require_cert>
    <tls_cert_file>/path/to/tls_cert_file</tls_cert_file>
    <tls_key_file>/path/to/tls_key_file</tls_key_file>
    <tls_ca_cert_file>/path/to/tls_ca_cert_file</tls_ca_cert_file>
    <tls_ca_cert_dir>/path/to/tls_ca_cert_dir</tls_ca_cert_dir>
    <tls_cipher_suite>ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:AES256-GCM-SHA384</tls_cipher_suite>
</my_ldap_server>

Example (typical Active Directory with configured user DN detection for further role mapping):

<my_ad_server>
    <host>localhost</host>
    <port>389</port>
    <bind_dn>EXAMPLE\{user_name}</bind_dn>
    <user_dn_detection>
        <base_dn>CN=Users,DC=example,DC=com</base_dn>
        <search_filter>(&amp;(objectClass=user)(sAMAccountName={user_name}))</search_filter>
    </user_dn_detection>
    <enable_tls>no</enable_tls>
</my_ad_server>

listen_host {#listen_host}

Restriction on hosts that requests can come from. If you want the server to answer all of them, specify ::.

Examples:

<listen_host>::1</listen_host>
<listen_host>127.0.0.1</listen_host>

logger {#logger}

The location and format of log messages.

Keys:

Log format specifiers

File names in log and errorLog paths support below format specifiers for the resulting file name (the directory part does not support them).

Column "Example" shows the output at 2023-07-06 18:32:07.

Example

<logger>
    <level>trace</level>
    <log>/var/log/clickhouse-server/clickhouse-server-%F-%T.log</log>
    <errorlog>/var/log/clickhouse-server/clickhouse-server-%F-%T.err.log</errorlog>
    <size>1000M</size>
    <count>10</count>
    <stream_compress>true</stream_compress>
</logger>

To print log messages only in the console:

<logger>
    <level>information</level>
    <console>true</console>
</logger>

Per-level Overrides

The log level of individual log names can be overridden. For example, to mute all messages of loggers "Backup" and "RBAC".

<logger>
    <levels>
        <logger>
            <name>Backup</name>
            <level>none</level>
        </logger>
        <logger>
            <name>RBAC</name>
            <level>none</level>
        </logger>
    </levels>
</logger>

syslog

To write log messages additionally to syslog:

<logger>
    <use_syslog>1</use_syslog>
    <syslog>
        <address>syslog.remote:10514</address>
        <hostname>myhost.local</hostname>
        <facility>LOG_LOCAL6</facility>
        <format>syslog</format>
    </syslog>
</logger>

Keys for <syslog>:

Log formats

You can specify the log format that will be outputted in the console log. Currently, only JSON is supported.

Example

Here is an example of an output JSON log:

{
  "date_time_utc": "2024-11-06T09:06:09Z",
  "date_time": "1650918987.180175",
  "thread_name": "#1",
  "thread_id": "254545",
  "level": "Trace",
  "query_id": "",
  "logger_name": "BaseDaemon",
  "message": "Received signal 2",
  "source_file": "../base/daemon/BaseDaemon.cpp; virtual void SignalListener::run()",
  "source_line": "192"
}

To enable JSON logging support, use the following snippet:

<logger>
    <formatting>
        <type>json</type>
        <!-- Can be configured on a per-channel basis (log, errorlog, console, syslog), or globally for all channels (then just omit it). -->
        <!-- <channel></channel> -->
        <names>
            <date_time>date_time</date_time>
            <thread_name>thread_name</thread_name>
            <thread_id>thread_id</thread_id>
            <level>level</level>
            <query_id>query_id</query_id>
            <logger_name>logger_name</logger_name>
            <message>message</message>
            <source_file>source_file</source_file>
            <source_line>source_line</source_line>
        </names>
    </formatting>
</logger>

Renaming keys for JSON logs

Key names can be modified by changing tag values inside the <names> tag. For example, to change DATE_TIME to MY_DATE_TIME, you can use <date_time>MY_DATE_TIME</date_time>.

Omitting keys for JSON logs

Log properties can be omitted by commenting out the property. For example, if you do not want your log to print query_id, you can comment out the <query_id> tag.

send_crash_reports {#send_crash_reports}

Settings for sending of crash reports to the ClickHouse core developers team.

Enabling it, especially in pre-production environments, is highly appreciated.

Keys:

Recommended usage

<send_crash_reports>
    <enabled>true</enabled>
</send_crash_reports>

ssh_server {#ssh_server}

The public part of the host key will be written to the known_hosts file on the SSH client side on the first connect.

Host Key Configurations are inactive by default. Uncomment the host key configurations, and provide the path to the respective ssh key to active them:

Example:

<ssh_server>
    <host_rsa_key>path_to_the_ssh_key</host_rsa_key>
    <host_ecdsa_key>path_to_the_ssh_key</host_ecdsa_key>
    <host_ed25519_key>path_to_the_ssh_key</host_ed25519_key>
</ssh_server>

tcp_ssh_port {#tcp_ssh_port}

Port for the SSH server which allows the user to connect and execute queries in an interactive fashion using the embedded client over the PTY.

Example:

<tcp_ssh_port>9022</tcp_ssh_port>

storage_configuration {#storage_configuration}

Allows for multi-disk configuration of storage.

Storage configuration follows the structure:

<storage_configuration>
    <disks>
        <!-- configuration -->
    </disks>
    <policies>
        <!-- configuration -->
    </policies>
</storage_configuration>

Configuration of disks {#configuration-of-disks}

Configuration of disks follows the structure given below:

<storage_configuration>
    <disks>
        <disk_name_1>
            <path>/mnt/fast_ssd/clickhouse/</path>
        </disk_name_1>
        <disk_name_2>
            <path>/mnt/hdd1/clickhouse/</path>
            <keep_free_space_bytes>10485760</keep_free_space_bytes>
        </disk_name_2>
        <disk_name_3>
            <path>/mnt/hdd2/clickhouse/</path>
            <keep_free_space_bytes>10485760</keep_free_space_bytes>
        </disk_name_3>
        ...
    </disks>
</storage_configuration>

The sub-tags above define the following settings for disks:

:::note The order of the disks does not matter. :::

Configuration of policies {#configuration-of-policies}

The sub-tags above define the following settings for policies:

For the volume_priority:

• If all volumes have this parameter, they are prioritized in the specified order.
• If only some volumes have it, volumes that do not have it have the lowest priority. Those that do have it are prioritized according to the tag value, the priority of the rest is determined by the order of description in the configuration file relative to each other.
• If no volumes are given this parameter, their order is determined by the order of the description in the configuration file.
• The priority of volumes may not be identical.

macros {#macros}

Parameter substitutions for replicated tables.

Can be omitted if replicated tables are not used.

For more information, see the section Creating replicated tables.

Example

<macros incl="macros" optional="true" />

replica_group_name {#replica_group_name}

Replica group name for database Replicated.

The cluster created by Replicated database will consist of replicas in the same group. DDL queries will only wait for the replicas in the same group.

Empty by default.

Example

<replica_group_name>backups</replica_group_name>

max_session_timeout {#max_session_timeout}

Maximum session timeout, in seconds.

Example:

<max_session_timeout>3600</max_session_timeout>

merge_tree {#merge_tree}

Fine-tuning for tables in the MergeTree.

For more information, see the MergeTreeSettings.h header file.

Example

<merge_tree>
    <max_suspicious_broken_parts>5</max_suspicious_broken_parts>
</merge_tree>

metric_log {#metric_log}

It is disabled by default.

Enabling

To manually turn on metrics history collection system.metric_log, create /etc/clickhouse-server/config.d/metric_log.xml with the following content:

<clickhouse>
    <metric_log>
        <database>system</database>
        <table>metric_log</table>
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
        <collect_interval_milliseconds>1000</collect_interval_milliseconds>
        <max_size_rows>1048576</max_size_rows>
        <reserved_size_rows>8192</reserved_size_rows>
        <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
        <flush_on_crash>false</flush_on_crash>
    </metric_log>
</clickhouse>

Disabling

To disable metric_log setting, you should create the following file /etc/clickhouse-server/config.d/disable_metric_log.xml with the following content:

<clickhouse>
    <metric_log remove="1" />
</clickhouse>

replicated_merge_tree {#replicated_merge_tree}

Fine-tuning for tables in the ReplicatedMergeTree. This setting has a higher priority.

For more information, see the MergeTreeSettings.h header file.

Example

<replicated_merge_tree>
    <max_suspicious_broken_parts>5</max_suspicious_broken_parts>
</replicated_merge_tree>

opentelemetry_span_log {#opentelemetry_span_log}

Settings for the opentelemetry_span_log system table.

Example:

<opentelemetry_span_log>
    <engine>
        engine MergeTree
        partition by toYYYYMM(finish_date)
        order by (finish_date, finish_time_us, trace_id)
    </engine>
    <database>system</database>
    <table>opentelemetry_span_log</table>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
    <max_size_rows>1048576</max_size_rows>
    <reserved_size_rows>8192</reserved_size_rows>
    <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
    <flush_on_crash>false</flush_on_crash>
</opentelemetry_span_log>

openSSL {#openSSL}

SSL client/server configuration.

Support for SSL is provided by the libpoco library. The available configuration options are explained in SSLManager.h. Default values can be found in SSLManager.cpp.

Keys for server/client settings:

Example of settings:

<openSSL>
    <server>
        <!-- openssl req -subj "/CN=localhost" -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout /etc/clickhouse-server/server.key -out /etc/clickhouse-server/server.crt -->
        <certificateFile>/etc/clickhouse-server/server.crt</certificateFile>
        <privateKeyFile>/etc/clickhouse-server/server.key</privateKeyFile>
        <!-- openssl dhparam -out /etc/clickhouse-server/dhparam.pem 4096 -->
        <dhParamsFile>/etc/clickhouse-server/dhparam.pem</dhParamsFile>
        <verificationMode>none</verificationMode>
        <loadDefaultCAFile>true</loadDefaultCAFile>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
    </server>
    <client>
        <loadDefaultCAFile>true</loadDefaultCAFile>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
        <!-- Use for self-signed: <verificationMode>none</verificationMode> -->
        <invalidCertificateHandler>
            <!-- Use for self-signed: <name>AcceptCertificateHandler</name> -->
            <name>RejectCertificateHandler</name>
        </invalidCertificateHandler>
    </client>
</openSSL>

part_log {#part_log}

Logging events that are associated with MergeTree. For instance, adding or merging data. You can use the log to simulate merge algorithms and compare their characteristics. You can visualize the merge process.

Queries are logged in the system.part_log table, not in a separate file. You can configure the name of this table in the table parameter (see below).

Example

<part_log>
    <database>system</database>
    <table>part_log</table>
    <partition_by>toMonday(event_date)</partition_by>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
    <max_size_rows>1048576</max_size_rows>
    <reserved_size_rows>8192</reserved_size_rows>
    <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
    <flush_on_crash>false</flush_on_crash>
</part_log>

processors_profile_log {#processors_profile_log}

Settings for the processors_profile_log system table.

The default settings are:

<processors_profile_log>
    <database>system</database>
    <table>processors_profile_log</table>
    <partition_by>toYYYYMM(event_date)</partition_by>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
    <max_size_rows>1048576</max_size_rows>
    <reserved_size_rows>8192</reserved_size_rows>
    <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
    <flush_on_crash>false</flush_on_crash>
</processors_profile_log>

prometheus {#prometheus}

Exposing metrics data for scraping from Prometheus.

Settings:

• endpoint – HTTP endpoint for scraping metrics by prometheus server. Start from '/'.
• port – Port for endpoint.
• metrics – Expose metrics from the system.metrics table.
• events – Expose metrics from the system.events table.
• asynchronous_metrics – Expose current metrics values from the system.asynchronous_metrics table.
• errors - Expose the number of errors by error codes occurred since the last server restart. This information could be obtained from the system.errors as well.

Example

<clickhouse>
    <listen_host>0.0.0.0</listen_host>
    <http_port>8123</http_port>
    <tcp_port>9000</tcp_port>
    <!-- highlight-start -->
    <prometheus>
        <endpoint>/metrics</endpoint>
        <port>9363</port>
        <metrics>true</metrics>
        <events>true</events>
        <asynchronous_metrics>true</asynchronous_metrics>
        <errors>true</errors>
    </prometheus>
    <!-- highlight-end -->
</clickhouse>

Check (replace 127.0.0.1 with the IP addr or hostname of your ClickHouse server):

curl 127.0.0.1:9363/metrics

query_log {#query_log}

Setting for logging queries received with the log_queries=1 setting.

Queries are logged in the system.query_log table, not in a separate file. You can change the name of the table in the table parameter (see below).

If the table does not exist, ClickHouse will create it. If the structure of the query log changed when the ClickHouse server was updated, the table with the old structure is renamed, and a new table is created automatically.

Example

<query_log>
    <database>system</database>
    <table>query_log</table>
    <engine>Engine = MergeTree PARTITION BY event_date ORDER BY event_time TTL event_date + INTERVAL 30 day</engine>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
    <max_size_rows>1048576</max_size_rows>
    <reserved_size_rows>8192</reserved_size_rows>
    <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
    <flush_on_crash>false</flush_on_crash>
</query_log>

query_metric_log {#query_metric_log}

It is disabled by default.

Enabling

To manually turn on metrics history collection system.query_metric_log, create /etc/clickhouse-server/config.d/query_metric_log.xml with the following content:

<clickhouse>
    <query_metric_log>
        <database>system</database>
        <table>query_metric_log</table>
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
        <collect_interval_milliseconds>1000</collect_interval_milliseconds>
        <max_size_rows>1048576</max_size_rows>
        <reserved_size_rows>8192</reserved_size_rows>
        <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
        <flush_on_crash>false</flush_on_crash>
    </query_metric_log>
</clickhouse>

Disabling

To disable query_metric_log setting, you should create the following file /etc/clickhouse-server/config.d/disable_query_metric_log.xml with the following content:

<clickhouse>
    <query_metric_log remove="1" />
</clickhouse>

query_cache {#query_cache}

Query cache configuration.

The following settings are available:

:::note

• Changed settings take effect immediately.
• Data for the query cache is allocated in DRAM. If memory is scarce, make sure to set a small value for max_size_in_bytes or disable the query cache altogether. :::

Example

<query_cache>
    <max_size_in_bytes>1073741824</max_size_in_bytes>
    <max_entries>1024</max_entries>
    <max_entry_size_in_bytes>1048576</max_entry_size_in_bytes>
    <max_entry_size_in_rows>30000000</max_entry_size_in_rows>
</query_cache>

query_thread_log {#query_thread_log}

Setting for logging threads of queries received with the log_query_threads=1 setting.

Queries are logged in the system.query_thread_log table, not in a separate file. You can change the name of the table in the table parameter (see below).

If the table does not exist, ClickHouse will create it. If the structure of the query thread log changed when the ClickHouse server was updated, the table with the old structure is renamed, and a new table is created automatically.

Example

<query_thread_log>
    <database>system</database>
    <table>query_thread_log</table>
    <partition_by>toMonday(event_date)</partition_by>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
    <max_size_rows>1048576</max_size_rows>
    <reserved_size_rows>8192</reserved_size_rows>
    <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
    <flush_on_crash>false</flush_on_crash>
</query_thread_log>

query_views_log {#query_views_log}

Setting for logging views (live, materialized etc) dependant of queries received with the log_query_views=1 setting.

Queries are logged in the system.query_views_log table, not in a separate file. You can change the name of the table in the table parameter (see below).

If the table does not exist, ClickHouse will create it. If the structure of the query views log changed when the ClickHouse server was updated, the table with the old structure is renamed, and a new table is created automatically.

Example

<query_views_log>
    <database>system</database>
    <table>query_views_log</table>
    <partition_by>toYYYYMM(event_date)</partition_by>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
    <max_size_rows>1048576</max_size_rows>
    <reserved_size_rows>8192</reserved_size_rows>
    <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
    <flush_on_crash>false</flush_on_crash>
</query_views_log>

text_log {#text_log}

Settings for the text_log system table for logging text messages.

Additionally:

Example

<clickhouse>
    <text_log>
        <level>notice</level>
        <database>system</database>
        <table>text_log</table>
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
        <max_size_rows>1048576</max_size_rows>
        <reserved_size_rows>8192</reserved_size_rows>
        <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
        <flush_on_crash>false</flush_on_crash>
        <!-- <partition_by>event_date</partition_by> -->
        <engine>Engine = MergeTree PARTITION BY event_date ORDER BY event_time TTL event_date + INTERVAL 30 day</engine>
    </text_log>
</clickhouse>

trace_log {#trace_log}

Settings for the trace_log system table operation.

The default server configuration file config.xml contains the following settings section:

<trace_log>
    <database>system</database>
    <table>trace_log</table>
    <partition_by>toYYYYMM(event_date)</partition_by>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
    <max_size_rows>1048576</max_size_rows>
    <reserved_size_rows>8192</reserved_size_rows>
    <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
    <flush_on_crash>false</flush_on_crash>
    <symbolize>false</symbolize>
</trace_log>

asynchronous_insert_log {#asynchronous_insert_log}

Settings for the asynchronous_insert_log system table for logging async inserts.

Example

<clickhouse>
    <asynchronous_insert_log>
        <database>system</database>
        <table>asynchronous_insert_log</table>
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
        <partition_by>toYYYYMM(event_date)</partition_by>
        <max_size_rows>1048576</max_size_rows>
        <reserved_size_rows>8192</reserved_size_rows>
        <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
        <flush_on_crash>false</flush_on_crash>
        <!-- <engine>Engine = MergeTree PARTITION BY event_date ORDER BY event_time TTL event_date + INTERVAL 30 day</engine> -->
    </asynchronous_insert_log>
</clickhouse>

crash_log {#crash_log}

Settings for the crash_log system table operation.

The following settings can be configured by sub-tags:

The default server configuration file config.xml contains the following settings section:

<crash_log>
    <database>system</database>
    <table>crash_log</table>
    <partition_by>toYYYYMM(event_date)</partition_by>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
    <max_size_rows>1024</max_size_rows>
    <reserved_size_rows>1024</reserved_size_rows>
    <buffer_size_rows_flush_threshold>512</buffer_size_rows_flush_threshold>
    <flush_on_crash>false</flush_on_crash>
</crash_log>

custom_cached_disks_base_directory {#custom_cached_disks_base_directory}

This setting specifies the cache path for custom (created from SQL) cached disks. custom_cached_disks_base_directory has higher priority for custom disks over filesystem_caches_path (found in filesystem_caches_path.xml), which is used if the former one is absent. The filesystem cache setting path must lie inside that directory, otherwise an exception will be thrown preventing the disk from being created.

:::note This will not affect disks created on an older version for which the server was upgraded. In this case, an exception will not be thrown, to allow the server to successfully start. :::

Example:

<custom_cached_disks_base_directory>/var/lib/clickhouse/caches/</custom_cached_disks_base_directory>

backup_log {#backup_log}

Settings for the backup_log system table for logging BACKUP and RESTORE operations.

Example

<clickhouse>
    <backup_log>
        <database>system</database>
        <table>backup_log</table>
        <flush_interval_milliseconds>1000</flush_interval_milliseconds>
        <partition_by>toYYYYMM(event_date)</partition_by>
        <max_size_rows>1048576</max_size_rows>
        <reserved_size_rows>8192</reserved_size_rows>
        <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
        <flush_on_crash>false</flush_on_crash>
        <!-- <engine>Engine = MergeTree PARTITION BY event_date ORDER BY event_time TTL event_date + INTERVAL 30 day</engine> -->
    </backup_log>
</clickhouse>

blob_storage_log {#blob_storage_log}

Settings for the blob_storage_log system table.

Example:

<blob_storage_log>
    <database>system</database
    <table>blob_storage_log</table
    <partition_by>toYYYYMM(event_date)</partition_by>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds
    <ttl>event_date + INTERVAL 30 DAY</ttl>
</blob_storage_log>

query_masking_rules {#query_masking_rules}

Regexp-based rules, which will be applied to queries as well as all log messages before storing them in server logs, system.query_log, system.text_log, system.processes tables, and in logs sent to the client. That allows preventing sensitive data leakage from SQL queries such as names, emails, personal identifiers or credit card numbers to logs.

Example

<query_masking_rules>
    <rule>
        <name>hide SSN</name>
        <regexp>(^|\D)\d{3}-\d{2}-\d{4}($|\D)</regexp>
        <replace>000-00-0000</replace>
    </rule>
</query_masking_rules>

Config fields:

The masking rules are applied to the whole query (to prevent leaks of sensitive data from malformed / non-parseable queries).

The system.events table has counter QueryMaskingRulesMatch which has an overall number of query masking rules matches.

For distributed queries each server has to be configured separately, otherwise, subqueries passed to other nodes will be stored without masking.

remote_servers {#remote_servers}

Configuration of clusters used by the Distributed table engine and by the cluster table function.

Example

<remote_servers incl="clickhouse_remote_servers" />

For the value of the incl attribute, see the section "Configuration files".

See Also

• skip_unavailable_shards
• Cluster Discovery
• Replicated database engine

remote_url_allow_hosts {#remote_url_allow_hosts}

List of hosts which are allowed to be used in URL-related storage engines and table functions.

When adding a host with the \<host\> xml tag:

• it should be specified exactly as in the URL, as the name is checked before DNS resolution. For example: <host>clickhouse.com</host>
• if the port is explicitly specified in the URL, then host:port is checked as a whole. For example: <host>clickhouse.com:80</host>
• if the host is specified without a port, then any port of the host is allowed. For example: if <host>clickhouse.com</host> is specified then clickhouse.com:20 (FTP), clickhouse.com:80 (HTTP), clickhouse.com:443 (HTTPS) etc are allowed.
• if the host is specified as an IP address, then it is checked as specified in the URL. For example: [2a02:6b8:a::a].
• if there are redirects and support for redirects is enabled, then every redirect (the location field) is checked.

For example:

<remote_url_allow_hosts>
    <host>clickhouse.com</host>
</remote_url_allow_hosts>

timezone {#timezone}

The server's time zone.

Specified as an IANA identifier for the UTC timezone or geographic location (for example, Africa/Abidjan).

The time zone is necessary for conversions between String and DateTime formats when DateTime fields are output to text format (printed on the screen or in a file), and when getting DateTime from a string. Besides, the time zone is used in functions that work with the time and date if they didn't receive the time zone in the input parameters.

Example

<timezone>Asia/Istanbul</timezone>

See also

• session_timezone

tcp_port {#tcp_port}

Port for communicating with clients over the TCP protocol.

Example

<tcp_port>9000</tcp_port>

tcp_port_secure {#tcp_port_secure}

TCP port for secure communication with clients. Use it with OpenSSL settings.

Default value

<tcp_port_secure>9440</tcp_port_secure>

mysql_port {#mysql_port}

Port for communicating with clients over MySQL protocol.

:::note

• Positive integers specify the port number to listen to
• Empty values are used to disable communication with clients over MySQL protocol. :::

Example

<mysql_port>9004</mysql_port>

postgresql_port {#postgresql_port}

Port for communicating with clients over PostgreSQL protocol.

:::note

• Positive integers specify the port number to listen to
• Empty values are used to disable communication with clients over PostgreSQL protocol. :::

Example

<postgresql_port>9005</postgresql_port>

url_scheme_mappers {#url_scheme_mappers}

Configuration for translating shortened or symbolic URL prefixes into full URLs.

Example:

<url_scheme_mappers>
    <s3>
        <to>https://{bucket}.s3.amazonaws.com</to>
    </s3>
    <gs>
        <to>https://storage.googleapis.com/{bucket}</to>
    </gs>
    <oss>
        <to>https://{bucket}.oss.aliyuncs.com</to>
    </oss>
</url_scheme_mappers>

user_defined_path {#user_defined_path}

The directory with user defined files. Used for SQL user defined functions SQL User Defined Functions.

Example

<user_defined_path>/var/lib/clickhouse/user_defined/</user_defined_path>

users_config {#users_config}

Path to the file that contains:

• User configurations.
• Access rights.
• Settings profiles.
• Quota settings.

Example

<users_config>users.xml</users_config>

access_control_improvements {#access_control_improvements}

Settings for optional improvements in the access control system.

Example:

<access_control_improvements>
    <throw_on_unmatched_row_policies>true</throw_on_unmatched_row_policies>
    <users_without_row_policies_can_read_rows>true</users_without_row_policies_can_read_rows>
    <on_cluster_queries_require_cluster_grant>true</on_cluster_queries_require_cluster_grant>
    <select_from_system_db_requires_grant>true</select_from_system_db_requires_grant>
    <select_from_information_schema_requires_grant>true</select_from_information_schema_requires_grant>
    <settings_constraints_replace_previous>true</settings_constraints_replace_previous>
    <table_engines_require_grant>false</table_engines_require_grant>
    <role_cache_expiration_time_seconds>600</role_cache_expiration_time_seconds>
</access_control_improvements>

s3queue_log {#s3queue_log}

Settings for the s3queue_log system table.

The default settings are:

<s3queue_log>
    <database>system</database>
    <table>s3queue_log</table>
    <partition_by>toYYYYMM(event_date)</partition_by>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</s3queue_log>

dead_letter_queue {#dead_letter_queue}

Setting for the 'dead_letter_queue' system table.

The default settings are:

<dead_letter_queue>
    <database>system</database>
    <table>dead_letter</table>
    <partition_by>toYYYYMM(event_date)</partition_by>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</dead_letter_queue>

zookeeper {#zookeeper}

Contains settings that allow ClickHouse to interact with a ZooKeeper cluster. ClickHouse uses ZooKeeper for storing metadata of replicas when using replicated tables. If replicated tables are not used, this section of parameters can be omitted.

The following settings can be configured by sub-tags:

There is also the zookeeper_load_balancing setting (optional) which lets you select the algorithm for ZooKeeper node selection:

Example configuration

<zookeeper>
    <node>
        <host>example1</host>
        <port>2181</port>
    </node>
    <node>
        <host>example2</host>
        <port>2181</port>
    </node>
    <session_timeout_ms>30000</session_timeout_ms>
    <operation_timeout_ms>10000</operation_timeout_ms>
    <!-- Optional. Chroot suffix. Should exist. -->
    <root>/path/to/zookeeper/node</root>
    <!-- Optional. Zookeeper digest ACL string. -->
    <identity>user:password</identity>
    <!--<zookeeper_load_balancing>random / in_order / nearest_hostname / hostname_levenshtein_distance / first_or_random / round_robin</zookeeper_load_balancing>-->
    <zookeeper_load_balancing>random</zookeeper_load_balancing>
    <!-- Optional. Enable 64-bit transaction IDs. -->
    <use_xid_64>false</use_xid_64>
    <!-- Optional. Enable OpenTelemetry tracing context propagation (requires use_xid_64). -->
    <pass_opentelemetry_tracing_context>false</pass_opentelemetry_tracing_context>
</zookeeper>

See Also

• Replication
• ZooKeeper Programmer's Guide
• Optional secured communication between ClickHouse and Zookeeper

use_minimalistic_part_header_in_zookeeper {#use_minimalistic_part_header_in_zookeeper}

Storage method for data part headers in ZooKeeper. This setting only applies to the MergeTree family. It can be specified:

Globally in the merge_tree section of the config.xml file

ClickHouse uses the setting for all the tables on the server. You can change the setting at any time. Existing tables change their behaviour when the setting changes.

For each table

When creating a table, specify the corresponding engine setting. The behaviour of an existing table with this setting does not change, even if the global setting changes.

Possible values

• 0 — Functionality is turned off.
• 1 — Functionality is turned on.

If use_minimalistic_part_header_in_zookeeper = 1, then replicated tables store the headers of the data parts compactly using a single znode. If the table contains many columns, this storage method significantly reduces the volume of the data stored in Zookeeper.

:::note After applying use_minimalistic_part_header_in_zookeeper = 1, you can't downgrade the ClickHouse server to a version that does not support this setting. Be careful when upgrading ClickHouse on servers in a cluster. Don't upgrade all the servers at once. It is safer to test new versions of ClickHouse in a test environment, or on just a few servers of a cluster.

Data part headers already stored with this setting can't be restored to their previous (non-compact) representation. :::

distributed_ddl {#distributed_ddl}

Manage executing distributed ddl queries (CREATE, DROP, ALTER, RENAME) on cluster. Works only if ZooKeeper is enabled.

The configurable settings within <distributed_ddl> include:

Example

<distributed_ddl>
    <!-- Path in ZooKeeper to queue with DDL queries -->
    <path>/clickhouse/task_queue/ddl</path>

    <!-- Settings from this profile will be used to execute DDL queries -->
    <profile>default</profile>

    <!-- Controls how much ON CLUSTER queries can be run simultaneously. -->
    <pool_size>1</pool_size>

    <!--
         Cleanup settings (active tasks will not be removed)
    -->

    <!-- Controls task TTL (default 1 week) -->
    <task_max_lifetime>604800</task_max_lifetime>

    <!-- Controls how often cleanup should be performed (in seconds) -->
    <cleanup_delay_period>60</cleanup_delay_period>

    <!-- Controls how many tasks could be in the queue -->
    <max_tasks_in_queue>1000</max_tasks_in_queue>
</distributed_ddl>

access_control_path {#access_control_path}

Path to a folder where a ClickHouse server stores user and role configurations created by SQL commands.

See also

• Access Control and Account Management

allow_plaintext_password {#allow_plaintext_password}

Sets whether plaintext-password types (insecure) are allowed or not.

<allow_plaintext_password>1</allow_plaintext_password>

allow_no_password {#allow_no_password}

Sets whether an insecure password type of no_password is allowed or not.

<allow_no_password>1</allow_no_password>

allow_implicit_no_password {#allow_implicit_no_password}

Forbids creating a user with no password unless 'IDENTIFIED WITH no_password' is explicitly specified.

<allow_implicit_no_password>1</allow_implicit_no_password>

default_session_timeout {#default_session_timeout}

Default session timeout, in seconds.

<default_session_timeout>60</default_session_timeout>

default_password_type {#default_password_type}

Sets the password type to be automatically set for in queries like CREATE USER u IDENTIFIED BY 'p'.

Accepted values are:

• plaintext_password
• sha256_password
• double_sha1_password
• bcrypt_password

<default_password_type>sha256_password</default_password_type>

user_directories {#user_directories}

Section of the configuration file that contains settings:

• Path to configuration file with predefined users.
• Path to folder where users created by SQL commands are stored.
• ZooKeeper node path where users created by SQL commands are stored and replicated.

If this section is specified, the path from users_config and access_control_path won't be used.

The user_directories section can contain any number of items, the order of the items means their precedence (the higher the item the higher the precedence).

Examples

<user_directories>
    <users_xml>
        <path>/etc/clickhouse-server/users.xml</path>
    </users_xml>
    <local_directory>
        <path>/var/lib/clickhouse/access/</path>
    </local_directory>
</user_directories>

Users, roles, row policies, quotas, and profiles can be also stored in ZooKeeper:

<user_directories>
    <users_xml>
        <path>/etc/clickhouse-server/users.xml</path>
    </users_xml>
    <replicated>
        <zookeeper_path>/clickhouse/access/</zookeeper_path>
    </replicated>
</user_directories>

You can also define sections memory — means storing information only in memory, without writing to disk, and ldap — means storing information on an LDAP server.

To add an LDAP server as a remote user directory of users that are not defined locally, define a single ldap section with the following settings:

Example

<ldap>
    <server>my_ldap_server</server>
        <roles>
            <my_local_role1 />
            <my_local_role2 />
        </roles>
</ldap>

top_level_domains_list {#top_level_domains_list}

Defines a list of custom top level domains to add where each entry is, of the format <name>/path/to/file</name>.

For example:

<top_level_domains_lists>
    <public_suffix_list>/path/to/public_suffix_list.dat</public_suffix_list>
</top_level_domains_lists>

See also:

• function cutToFirstSignificantSubdomainCustom and variations thereof, which accepts a custom TLD list name, returning the part of the domain that includes top-level subdomains up to the first significant subdomain.

proxy {#proxy}

Define proxy servers for HTTP and HTTPS requests, currently supported by S3 storage, S3 table functions, and URL functions.

There are three ways to define proxy servers:

• environment variables
• proxy lists
• remote proxy resolvers.

Bypassing proxy servers for specific hosts is also supported with the use of no_proxy.

Environment variables

The http_proxy and https_proxy environment variables allow you to specify a proxy server for a given protocol. If you have it set on your system, it should work seamlessly.

This is the simplest approach if a given protocol has only one proxy server and that proxy server doesn't change.

Proxy lists

This approach allows you to specify one or more proxy servers for a protocol. If more than one proxy server is defined, ClickHouse uses the different proxies on a round-robin basis, balancing the load across the servers. This is the simplest approach if there is more than one proxy server for a protocol and the list of proxy servers doesn't change.

Configuration template

<proxy>
    <http>
        <uri>http://proxy1</uri>
        <uri>http://proxy2:3128</uri>
    </http>
    <https>
        <uri>http://proxy1:3128</uri>
    </https>
</proxy>

Select a parent field in the tabs below to view their children:

Remote proxy resolvers

It's possible that the proxy servers change dynamically. In that case, you can define the endpoint of a resolver. ClickHouse sends an empty GET request to that endpoint, the remote resolver should return the proxy host. ClickHouse will use it to form the proxy URI using the following template: \{proxy_scheme\}://\{proxy_host\}:{proxy_port}

Configuration template

<proxy>
    <http>
        <resolver>
            <endpoint>http://resolver:8080/hostname</endpoint>
            <proxy_scheme>http</proxy_scheme>
            <proxy_port>80</proxy_port>
            <proxy_cache_time>10</proxy_cache_time>
        </resolver>
    </http>

    <https>
        <resolver>
            <endpoint>http://resolver:8080/hostname</endpoint>
            <proxy_scheme>http</proxy_scheme>
            <proxy_port>3128</proxy_port>
            <proxy_cache_time>10</proxy_cache_time>
        </resolver>
    </https>

</proxy>

Select a parent field in the tabs below to view their children:

:::note You can have multiple <resolver> elements, but only the first <resolver> for a given protocol is used. Any other <resolver> elements for that protocol are ignored. That means load balancing (if needed) should be implemented by the remote resolver. :::

Precedence

Proxy settings are determined in the following order:

ClickHouse will check the highest priority resolver type for the request protocol. If it is not defined, it will check the next highest priority resolver type, until it reaches the environment resolver. This also allows a mix of resolver types can be used.

disable_tunneling_for_https_requests_over_http_proxy {#disable_tunneling_for_https_requests_over_http_proxy}

By default, tunneling (i.e, HTTP CONNECT) is used to make HTTPS requests over HTTP proxy. This setting can be used to disable it.

no_proxy

By default, all requests will go through the proxy. In order to disable it for specific hosts, the no_proxy variable must be set. It can be set inside the <proxy> clause for list and remote resolvers and as an environment variable for environment resolver. It supports IP addresses, domains, subdomains and '*' wildcard for full bypass. Leading dots are stripped just like curl does.

Example

The below configuration bypasses proxy requests to clickhouse.cloud and all of its subdomains (e.g, auth.clickhouse.cloud). The same applies to GitLab, even though it has a leading dot. Both gitlab.com and about.gitlab.com would bypass the proxy.

<proxy>
    <no_proxy>clickhouse.cloud,.gitlab.com</no_proxy>
    <http>
        <uri>http://proxy1</uri>
        <uri>http://proxy2:3128</uri>
    </http>
    <https>
        <uri>http://proxy1:3128</uri>
    </https>
</proxy>

workload_path {#workload_path}

The directory used as a storage for all CREATE WORKLOAD and CREATE RESOURCE queries. By default /workload/ folder under server working directory is used.

Example

<workload_path>/var/lib/clickhouse/workload/</workload_path>

See Also

• Workload Hierarchy
• workload_zookeeper_path

workload_zookeeper_path {#workload_zookeeper_path}

The path to a ZooKeeper node, which is used as a storage for all CREATE WORKLOAD and CREATE RESOURCE queries. For consistency all SQL definitions are stored as a value of this single znode. By default ZooKeeper is not used and definitions are stored on disk.

Example

<workload_zookeeper_path>/clickhouse/workload/definitions.sql</workload_zookeeper_path>

See Also

• Workload Hierarchy
• workload_path

zookeeper_log {#zookeeper_log}

Settings for the zookeeper_log system table.

The following settings can be configured by sub-tags:

Example

<clickhouse>
    <zookeeper_log>
        <database>system</database>
        <table>zookeeper_log</table>
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
        <ttl>event_date + INTERVAL 1 WEEK DELETE</ttl>
    </zookeeper_log>
</clickhouse>