fix more headings

Author: Blargian

docs/guides/best-practices/skipping-indexes.md

@@ -115,15 +115,19 @@ example, the debug log shows that the skip index dropped all but two granules:
 ```
 ## Skip index types {#skip-index-types}
 
+<!-- vale off -->
 ### minmax {#minmax}
+<!-- vale on -->
 
 This lightweight index type requires no parameters.  It stores the minimum and maximum values of the index expression
 for each block (if the expression is a tuple, it separately stores the values for each member of the element
 of the tuple).  This type is ideal for columns that tend to be loosely sorted by value.  This index type is usually the least expensive to apply during query processing.
 
 This type of index only works correctly with a scalar or tuple expression -- the index will never be applied to expressions that return an array or map data type.
 
+<!-- vale off -->
 ### set {#set}
+<!-- vale on -->
 
 This lightweight index type accepts a single parameter of the max_size of the value set per block (0 permits
 an unlimited number of discrete values).  This set contains all values in the block (or is empty if the number of values exceeds the max_size).  This index type works well with columns with low cardinality within each set of granules (essentially, "clumped together") but higher cardinality overall.

docs/guides/sre/configuring-ssl.md

@@ -10,7 +10,7 @@ import SelfManaged from '@site/docs/_snippets/_self_managed_only_automated.md';
 import configuringSsl01 from '@site/static/images/guides/sre/configuring-ssl_01.png';
 import Image from '@theme/IdealImage';
 
-# Configuring SSL-TLS
+# Configuring ssl-tls
 
 <SelfManaged />
 

docs/guides/sre/keeper/index.md

@@ -456,7 +456,7 @@ The following features are available:
 - `create_if_not_exists` - support for `CreateIfNotExists` request, which will try to create a node if it doesn't exist. If it exists, no changes are applied and `ZOK` is returned. Default: `0`
 - `remove_recursive` - support for `RemoveRecursive` request, which removes the node along with its subtree. Default: `0`
 
-### Migration from ZooKeeper {#migration-from-zookeeper}
+### Migration from zookeeper {#migration-from-zookeeper}
 
 Seamless migration from ZooKeeper to ClickHouse Keeper is not possible. You have to stop your ZooKeeper cluster, convert data, and start ClickHouse Keeper. `clickhouse-keeper-converter` tool allows converting ZooKeeper logs and snapshots to ClickHouse Keeper snapshot. It works only with ZooKeeper > 3.4. Steps for migration:
 

docs/guides/sre/user-management/index.md

@@ -201,7 +201,7 @@ This article shows the basics of defining SQL users and roles and applying those
     GRANT ALL ON *.* TO clickhouse_admin WITH GRANT OPTION;
     ```
 
-## ALTER permissions {#alter-permissions}
+## Alter permissions {#alter-permissions}
 
 This article is intended to provide you with a better understanding of how to define permissions, and how permissions work when using `ALTER` statements for privileged users.
 

docs/managing-data/core-concepts/partitions.md

@@ -18,7 +18,7 @@ import Image from '@theme/IdealImage';
 
 Partitions group the [data parts](/parts) of a table in the [MergeTree engine family](/engines/table-engines/mergetree-family) into organized, logical units, which is a way of organizing data that is conceptually meaningful and aligned with specific criteria, such as time ranges, categories, or other key attributes. These logical units make data easier to manage, query, and optimize.
 
-### Partition By {#partition-by}
+### PARTITION BY {#partition-by}
 
 Partitioning can be enabled when a table is initially defined via the [PARTITION BY clause](/engines/table-engines/mergetree-family/custom-partitioning-key). This clause can contain a SQL expression on any columns, the results of which will define which partition a row belongs to.
 

docs/managing-data/deleting-data/overview.md

@@ -16,7 +16,7 @@ There are several ways to delete data in ClickHouse, each with its own advantage
 
 Here is a summary of the different ways to delete data in ClickHouse:
 
-## Lightweight Deletes {#lightweight-deletes}
+## Lightweight deletes {#lightweight-deletes}
 
 Lightweight deletes cause rows to be immediately marked as deleted such that they can be automatically filtered out of all subsequent `SELECT` queries. Subsequent removal of these deleted rows occurs during natural merge cycles and thus incurs less I/O. As a result, it is possible that for an unspecified period, data is not actually deleted from storage and is only marked as deleted. If you need to guarantee that data is deleted, consider the above mutation command.
 
@@ -33,7 +33,7 @@ In general, lightweight deletes should be preferred over mutations if the existe
 
 Read more about [lightweight deletes](/guides/developer/lightweight-delete).
 
-## Delete Mutations {#delete-mutations}
+## Delete mutations {#delete-mutations}
 
 Delete mutations can be issued through a `ALTER TABLE ... DELETE` command e.g. 
 
@@ -46,7 +46,7 @@ These can be executed either synchronously (by default if non-replicated) or asy
 
 Read more about [delete mutations](/sql-reference/statements/alter/delete).
 
-## Truncate Table {#truncate-table}
+## Truncate table {#truncate-table}
 
 If all data in a table needs to be deleted, use the `TRUNCATE TABLE` command shown below. This is a lightweight operation.
 
@@ -56,7 +56,7 @@ TRUNCATE TABLE posts
 
 Read more about [TRUNCATE TABLE](/sql-reference/statements/truncate).
 
-## Drop Partition {#drop-partition}
+## Drop partition {#drop-partition}
 
 If you have specified a custom partitioning key for your data, partitions can be efficiently dropped. Avoid high cardinality partitioning.
 

docs/migrations/bigquery/migrating-to-clickhouse-cloud.md

@@ -66,7 +66,7 @@ Before trying the following examples, we recommend users review the [permissions
 
 Change Data Capture (CDC) is the process by which tables are kept in sync between two databases. This is significantly more complex if updates and deletes are to be handled in near real-time. One approach is to simply schedule a periodic export using BigQuery's [scheduled query functionality](https://cloud.google.com/bigquery/docs/scheduling-queries). Provided you can accept some delay in the data being inserted into ClickHouse, this approach is easy to implement and maintain. An example is given in [this blog post](https://clickhouse.com/blog/clickhouse-bigquery-migrating-data-for-realtime-queries#using-scheduled-queries).
 
-## Designing Schemas {#designing-schemas}
+## Designing schemas {#designing-schemas}
 
 The Stack Overflow dataset contains a number of related tables. We recommend focusing on migrating the primary table first. This may not necessarily be the largest table but rather the one on which you expect to receive the most analytical queries. This will allow you to familiarize yourself with the main ClickHouse concepts. This table may require remodeling as additional tables are added to fully exploit ClickHouse features and obtain optimal performance. We explore this modeling process in our [Data Modeling docs](/data-modeling/schema-design#next-data-modeling-techniques).
 
@@ -499,7 +499,7 @@ MaxViewCount:            66975
 Peak memory usage: 377.26 MiB.
 ```
 
-## Conditionals and Arrays {#conditionals-and-arrays}
+## Conditionals and arrays {#conditionals-and-arrays}
 
 Conditional and array functions make queries significantly simpler. The following query computes the tags (with more than 10000 occurrences) with the largest percentage increase from 2022 to 2023. Note how the following ClickHouse query is succinct thanks to conditionals, array functions, and the ability to reuse aliases in the `HAVING` and `SELECT` clauses.
 

docs/migrations/postgres/overview.md

@@ -23,7 +23,7 @@ When migrating from PostgreSQL to ClickHouse, the right strategy depends on your
 
 Below section describes the two main strategies for migration: **Real-Time CDC** and **Manual Bulk Load + Periodic Updates**.
 
-### Real-Time replication (CDC) {#real-time-replication-cdc}
+### Real-time replication (CDC) {#real-time-replication-cdc}
 
 Change Data Capture (CDC) is the process by which tables are kept in sync between two databases. It is the most efficient approach for most migration from PostgreSQL, but yet more complex as it handles insert, updates and deletes from PostgreSQL to ClickHouse in near real-time. It is ideal for use cases where real-time analytics are important. 
 

docs/native-protocol/columns.md

@@ -5,7 +5,7 @@ title: 'Column types'
 description: 'Column types for the native protocol'
 ---
 
-# Column Types
+# Column types
 
 See [Data Types](/sql-reference/data-types/) for general reference.
 
@@ -77,7 +77,7 @@ Alias of `FixedString(16)`, UUID value represented as binary.
 
 Alias of `Int8` or `Int16`, but each integer is mapped to some `String` value.
 
-## Low Cardinality {#low-cardinality}
+## LowCardinality {#low-cardinality}
 
 `LowCardinality(T)` consists of `Index T, Keys K`,
 where `K` is one of (UInt8, UInt16, UInt32, UInt64) depending on size of `Index`.

docs/native-protocol/hash.md

@@ -7,12 +7,13 @@ description: 'Native protocol hash'
 
 # CityHash
 
-ClickHouse uses **one of previous** versions of [CityHash from Google](https://github.com/google/cityhash).
+ClickHouse uses **one of the previous** versions of [CityHash from Google](https://github.com/google/cityhash).
 
 :::info
 CityHash has changed the algorithm after we have added it into ClickHouse.
 
-CityHash documentation specifically notes that the user should not rely to specific hash values and should not save it anywhere or use it as sharding key.
+CityHash documentation specifically notes that the user should not rely on 
+specific hash values and should not save it anywhere or use it as a sharding key.
 
 But as we exposed this function to the user, we had to fix the version of CityHash (to 1.0.2). And now we guarantee that the behaviour of CityHash functions available in SQL will not change.