query_cache
- 変更した設定はすぐに反映されます。
- クエリキャッシュ用のデータは DRAM に割り当てられます。メモリが逼迫している場合は、
max_size_in_bytesに小さな値を設定するか、クエリキャッシュを完全に無効にしてください。
query_log
table パラメータで変更できます (以下を参照) 。
以下の設定はサブタグで設定できます。
さらに、次のサーバーレベル設定は、すべてのシステムログテーブルに対するデフォルトのフラッシュポリシーを制御します。
enable_user_query_log パラメータ (デフォルトで有効) は、system.user_query_log を作成します。これにより、各ユーザーはテーブル自体へのアクセスを必要とせずに、設定されたクエリログテーブル内の自身のレコードを確認できます。これはクエリログがローカルに保存されている場合にのみ機能します。engine が別のサーバーに委譲する場合 (たとえば Distributed) は、system.user_query_log が ClickHouse プロトコルのサーバー境界をまたいでユーザーごとのアクセスチェックを強制できず、そのようなバックエンドからの読み取りを拒否するため、enable_user_query_log を無効にしてください。
テーブルが存在しない場合、ClickHouse が作成します。ClickHouse サーバー の更新時にクエリログの構造が変更された場合は、古い構造のテーブルはリネームされ、新しいテーブルが自動的に作成されます。
例
query_masking_rules
system.query_log、system.text_log、system.processes テーブル、およびクライアントに送信されるログに反映されます。これにより、
名前、メールアドレス、個人識別子、クレジットカード番号などの機密データが SQL クエリからログに漏えいするのを防止できます。
例
クエリマスキングルールは、クエリ全体に適用されます (不正な形式のクエリや parse できないクエリから機密データが漏えいするのを防ぐためです) 。
system.events テーブルには QueryMaskingRulesMatch というカウンターがあり、クエリマスキングルールに一致した回数の総数を表します。
分散クエリでは、各サーバーを個別に設定する必要があります。そうしないと、他の
ノードに渡されるサブクエリがマスキングされないまま保存されます。
query_metric_log
system.query_metric_log を手動で有効にするには、以下の内容で /etc/clickhouse-server/config.d/query_metric_log.xml を作成します。
query_metric_log 設定を無効にするには、以下の内容で /etc/clickhouse-server/config.d/disable_query_metric_log.xml ファイルを作成します。
さらに、次のサーバーレベル設定は、すべてのシステムログテーブルに対するデフォルトのフラッシュポリシーを制御します。
query_thread_log
table パラメータで変更できます (下記参照) 。
以下の設定はサブタグで設定できます。
さらに、次のサーバーレベル設定は、すべてのシステムログテーブルに対するデフォルトのフラッシュポリシーを制御します。
テーブルが存在しない場合は、ClickHouse が作成します。ClickHouse サーバー の更新時に query thread log の構造が変更された場合は、古い構造のテーブルはリネームされ、新しいテーブルが自動的に自動的に作成されます。
例
query_views_log
table パラメータで変更できます (以下を参照) 。
以下の設定はサブタグで設定できます。
さらに、次のサーバーレベル設定は、すべてのシステムログテーブルに対するデフォルトのフラッシュポリシーを制御します。
テーブルが存在しない場合、ClickHouse が作成します。ClickHouse サーバー の更新時に query views log の構造が変更された場合は、古い構造を持つテーブルはリネームされ、新しいテーブルが自動的に作成されます。
例