Remove references to Read the docs (deprecated) (#159)

* Remove references to Read the docs (deprecated)

* Fix clickhouse-grafana project links

Author: fviolette

docs/content/cn/index.md

@@ -77,7 +77,7 @@ go get -u github.com/ContentSquare/chproxy
 
 ## 为什么开发了Chproxy
 
-由于各种原因，ClickHouse 的最大执行时间、最大并发语句可能会超过 [max_execution_time](http://clickhouse-docs.readthedocs.io/en/latest/settings/query_complexity.html#max-execution-time) 和[max_concurrent_queries](https://github.com/yandex/ClickHouse/blob/add13f233eb6d30da4c75c4309542047a1dde033/dbms/src/Server/config.xml#L75) 的限制：
+由于各种原因，ClickHouse 的最大执行时间、最大并发语句可能会超过 [max_execution_time](https://clickhouse.com/docs/en/operations/settings/query-complexity/#max-execution-time) 和[max_concurrent_queries](https://clickhouse.com/docs/en/operations/server-configuration-parameters/settings/#max-concurrent-queries) 的限制：
 
 * `max_execution_time`  可能会因为当前实现的缺陷而被超过。
 * `max_concurrent_queries`  只针对每个节点的限制。如果是在集群节点上，是没法限制集群整体的并发查询数量。
@@ -161,7 +161,7 @@ clusters:
 
 ### 通过 HTTPS 进行用户密码认证
 
-假如你需要设置用户名称/密码用于在任何地方访问 `ClickHouse` 集群，可能用于在 [ClickHouse-grafana](https://github.com/ContentSquare/ClickHouse-grafana) 或 [Tabix](https://tabix.io/) 创建图形界面管理。通过不信任的网络传输为加密的密码和数据，是一个坏主意。因此在这种情况下，必须通过 HTTPS 访问集群。
+假如你需要设置用户名称/密码用于在任何地方访问 `ClickHouse` 集群，可能用于在 [ClickHouse-grafana](https://github.com/Altinity/clickhouse-grafana) 或 [Tabix](https://tabix.io/) 创建图形界面管理。通过不信任的网络传输为加密的密码和数据，是一个坏主意。因此在这种情况下，必须通过 HTTPS 访问集群。
 
 以下的 `chproxy` 配置示例演示了 [HTTPS 配置](https://github.com/ContentSquare/chproxy/blob/master/config/examples/https.yml)：
 

docs/content/en/configuration/security.md

@@ -6,7 +6,7 @@ position: 204
 
 `Chproxy` removes all the query params from input requests (except the user's [params](https://github.com/ContentSquare/chproxy/blob/master/config#param_groups_config) and listed [here](https://github.com/ContentSquare/chproxy/blob/master/scope.go#L292))
 before proxying them to `ClickHouse` nodes. This prevents from unsafe overriding
-of various `ClickHouse` [settings](http://clickhouse-docs.readthedocs.io/en/latest/interfaces/http_interface.html).
+of various `ClickHouse` [settings](https://clickhouse.com/docs/en/interfaces/http/).
 
 Be careful when configuring limits, allowed networks, passwords etc.
 By default `chproxy` tries detecting the most obvious configuration errors such as `allowed_networks: ["0.0.0.0/0"]` or sending passwords via unencrypted HTTP.

docs/content/en/faq.md

@@ -15,7 +15,7 @@ position: 103
   A single `chproxy` instance easily proxies 1Gbps of compressed `INSERT` data
   while using less than 20% of a single CPU core in our production setup.
 
-* *Does `chproxy` support [native interface](http://clickhouse-docs.readthedocs.io/en/latest/interfaces/tcp.html) for ClickHouse?*
+* *Does `chproxy` support [native interface](https://clickhouse.com/docs/en/interfaces/tcp/) for ClickHouse?*
 
   No. Because currently all our services work with ClickHouse only via HTTP.
   Support for `native interface` may be added in the future.

docs/content/en/history.md

@@ -6,7 +6,7 @@ position: 401
 
 ## Why it was created
 
-`ClickHouse` may exceed [max_execution_time](http://clickhouse-docs.readthedocs.io/en/latest/settings/query_complexity.html#max-execution-time) and [max_concurrent_queries](https://github.com/yandex/ClickHouse/blob/add13f233eb6d30da4c75c4309542047a1dde033/dbms/src/Server/config.xml#L75) limits due to various reasons:
+`ClickHouse` may exceed [max_execution_time](https://clickhouse.com/docs/en/operations/settings/query-complexity/#max-execution-time) and [max_concurrent_queries](https://clickhouse.com/docs/en/operations/server-configuration-parameters/settings/#max-concurrent-queries) limits due to various reasons:
 - `max_execution_time` may be exceeded due to the current [implementation deficiencies](https://github.com/yandex/ClickHouse/issues/217).
 - `max_concurrent_queries` works only on a per-node basis. There is no way to limit the number of concurrent queries on a cluster if queries are spread across cluster nodes.
 

docs/content/en/use-cases/authorize-users.md

@@ -6,7 +6,7 @@ position: 303
 ---
 
 Suppose you need to access `ClickHouse` cluster from anywhere by username/password.
-This may be used for building graphs from [ClickHouse-grafana](https://github.com/ContentSquare/ClickHouse-grafana) or [Tabix](https://tabix.io/).
+This may be used for building graphs from [ClickHouse-grafana](https://github.com/Altinity/clickhouse-grafana) or [Tabix](https://tabix.io/).
 It is bad idea to transfer unencrypted password and data over untrusted networks.
 So HTTPS must be used for accessing the cluster in such cases.
 The following `chproxy` config may be used for [this use case](https://github.com/ContentSquare/chproxy/blob/master/config/examples/https.yml):

docs/content/en/use-cases/spread-insert.md

@@ -7,7 +7,7 @@ position: 301
 
 Usually `INSERT`s are sent from app servers located in a limited number of subnetworks. `INSERT`s from other subnetworks must be denied.
 
-All the `INSERT`s may be routed to a [distributed table](http://clickhouse-docs.readthedocs.io/en/latest/table_engines/distributed.html) on a single node. But this increases resource usage (CPU and network) on the node comparing to other nodes, since it must parse each row to be inserted and route it to the corresponding node (shard).
+All the `INSERT`s may be routed to a [distributed table](https://clickhouse.com/docs/en/engines/table-engines/special/distributed/) on a single node. But this increases resource usage (CPU and network) on the node comparing to other nodes, since it must parse each row to be inserted and route it to the corresponding node (shard).
 
 It would be better to spread `INSERT`s among available shards and to route them directly to per-shard tables instead of distributed tables. The routing logic may be embedded either directly into applications generating `INSERT`s or may be moved to a proxy. Proxy approach is better since it allows re-configuring `ClickHouse` cluster without modification of application configs and without application downtime. Multiple identical proxies may be started on distinct servers for scalability and availability purposes.
 

docs/content/en/use-cases/spread-select.md

@@ -10,7 +10,7 @@ The load generated by such `SELECT`s on `ClickHouse` cluster may vary depending
 on the number of online customers and on the generated report types. It is obvious
 that the load must be limited in order to prevent cluster overload.
 
-All the `SELECT`s may be routed to a [distributed table](http://clickhouse-docs.readthedocs.io/en/latest/table_engines/distributed.html) on a single node. But this increases resource usage (RAM, CPU and network) on the node comparing to other nodes, since it must do final aggregation, sorting and filtering for the data obtained from cluster nodes (shards).
+All the `SELECT`s may be routed to a [distributed table](https://clickhouse.com/docs/en/engines/table-engines/special/distributed/) on a single node. But this increases resource usage (RAM, CPU and network) on the node comparing to other nodes, since it must do final aggregation, sorting and filtering for the data obtained from cluster nodes (shards).
 
 It would be better to create identical distributed tables on each shard and spread `SELECT`s among all the available shards.
 

scope.go

@@ -293,7 +293,7 @@ func (s *scope) killQuery() error {
 }
 
 // allowedParams contains query args allowed to be proxied.
-// See http://clickhouse-docs.readthedocs.io/en/latest/settings/
+// See https://clickhouse.com/docs/en/operations/settings/
 //
 // All the other params passed via query args are stripped before
 // proxying the request. This is for the sake of security.