Merge branch 'master' into xiang/migration

_index.md

@@ -49,7 +49,7 @@ TiDB 可以部署在本地和云平台上，支持公有云、私有云和混合
 
 - [使用 Ansible 部署](/v3.0/how-to/deploy/orchestrated/ansible.md)：如果用于生产环境，须使用 Ansible 部署 TiDB 集群。
 - [使用 Ansible 离线部署](/v3.0/how-to/deploy/orchestrated/offline-ansible.md)：如果部署环境无法访问网络，可使用 Ansible 进行离线部署。
-- [使用 Docker Compose 部署](/v3.0/how-to/get-started/local-cluster/install-from-docker-compose.md)：如果你只是想测试 TiDB、体验 TiDB 的特性，或者用于开发环境，可以使用 Docker Compose 在本地快速部署 TiDB 集群。该部署方式不适用于生产环境。
+- [使用 Docker Compose 部署](/v3.0/how-to/get-started/deploy-tidb-from-docker-compose.md)：如果你只是想测试 TiDB、体验 TiDB 的特性，或者用于开发环境，可以使用 Docker Compose 在本地快速部署 TiDB 集群。该部署方式不适用于生产环境。
 - [使用 Docker 部署](/v3.0/how-to/deploy/orchestrated/docker.md)：你可以使用 Docker 部署 TiDB 集群，但该部署方式不适用于生产环境。
 
 ## 项目源码

dev/TOC.md

@@ -38,10 +38,6 @@
       - [跨数据中心部署方案](/dev/how-to/deploy/geographic-redundancy/overview.md)
       - [配置集群拓扑](/dev/how-to/deploy/geographic-redundancy/location-awareness.md)
     - [使用 Ansible 部署 DM 集群](/dev/how-to/deploy/data-migration-with-ansible.md)
-    + 部署使用 TiDB Binlog
-      - [部署 TiDB Binlog 集群](/dev/how-to/deploy/tidb-binlog.md)
-      - [Binlog Slave Client 用户文档](/dev/reference/tools/tidb-binlog/binlog-slave-client.md)
-      - [Reparo 使用文档](/dev/reference/tools/tidb-binlog/reparo.md)
   + 配置
     - [时区](/dev/how-to/configure/time-zone.md)
     - [内存控制](/dev/how-to/configure/memory-control.md)
@@ -53,7 +49,6 @@
   + 监控
     - [概述](/dev/how-to/monitor/overview.md)
     - [监控 TiDB 集群](/dev/how-to/monitor/monitor-a-cluster.md)
-    - [监控 TiDB Binlog 集群](/dev/how-to/monitor/tidb-binlog.md)
   + 迁移
     - [概述](/dev/how-to/migrate/overview.md)
     - [从 MySQL 迁移](/dev/how-to/migrate/from-mysql.md)
@@ -63,13 +58,11 @@
     - [Ansible 常见运维操作](/dev/how-to/maintain/ansible-operations.md)
     + [备份与恢复](/dev/how-to/maintain/backup-and-restore.md)
     - [定位慢查询](/dev/how-to/maintain/identify-slow-queries.md)
-    - [TiDB Binlog 集群运维](/dev/how-to/maintain/tidb-binlog.md)
   + 扩容缩容
     - [使用 Ansible 扩容缩容](/dev/how-to/scale/with-ansible.md)
   + 升级
     - [升级至 TiDB 3.0](/dev/how-to/upgrade/from-previous-version.md)
     - [使用 Ansible 滚动升级](/dev/how-to/upgrade/rolling-updates-with-ansible.md)
-    - [升级 TiDB Binlog Cluster 版本](/dev/how-to/upgrade/tidb-binlog.md)
     - [升级 Data Migration](/dev/reference/tools/data-migration/dm-upgrade.md)
   + 故障诊断
     - [集群配置诊断](/dev/how-to/troubleshoot/cluster-setup.md)
@@ -129,7 +122,9 @@
     - [工具下载](/dev/reference/tools/download.md)
   + 最佳实践
     - [HAProxy 最佳实践](/dev/reference/best-practices/haproxy.md)
-    - [Java 使用 TiDB 的最佳实践](/dev/reference/best-practices/using-tidb-in-java.md)
+    - [Java 应用开发最佳实践](/dev/reference/best-practices/java-app.md)
+    - [高并发写入场景最佳实践](/dev/reference/best-practices/high-concurrency.md)
+    - [Grafana 监控最佳实践](/dev/reference/best-practices/grafana-monitor.md)
   + [与 MySQL 兼容性对比](/dev/reference/mysql-compatibility.md)
   + SQL
     + SQL 语言结构
@@ -258,10 +253,10 @@
       - [`SHOW [FULL] PROCESSSLIST`](/dev/reference/sql/statements/show-processlist.md)
       - [`SHOW SCHEMAS`](/dev/reference/sql/statements/show-schemas.md)
       - [`SHOW [FULL] TABLES`](/dev/reference/sql/statements/show-tables.md)
+      - [`SHOW TABLE REGIONS`](/dev/reference/sql/statements/show-table-regions.md)
       - [`SHOW TABLE STATUS`](/dev/reference/sql/statements/show-table-status.md)
       - [`SHOW [GLOBAL|SESSION] VARIABLES`](/dev/reference/sql/statements/show-variables.md)
       - [`SHOW WARNINGS`](/dev/reference/sql/statements/show-warnings.md)
-      - [`SHOW TABLE REGIONS`](/dev/reference/sql/statements/show-table-regions.md)
       - [`SPLIT REGION`](/dev/reference/sql/statements/split-region.md)
       - [`START TRANSACTION`](/dev/reference/sql/statements/start-transaction.md)
       - [`TRACE`](/dev/reference/sql/statements/trace.md)
@@ -317,13 +312,23 @@
     - [统计信息概述](/dev/reference/performance/statistics.md)
     - [Optimizer Hints](/dev/reference/performance/optimizer-hints.md)
     - [使用 SQL 语句检查 TiDB 集群状态](/dev/reference/performance/check-cluster-status-using-sql-statements.md)
+    - [Statement Summary Table](/dev/reference/performance/statement-summary.md)
     - [TiKV 调优](/dev/reference/performance/tune-tikv.md)
     - [TiDB 最佳实践](https://pingcap.com/blog-cn/tidb-best-practice/)
   + [TiSpark 使用指南](/dev/reference/tispark.md)
-  + [TiDB Binlog 简介](/dev/reference/tidb-binlog-overview.md)
+  + TiDB Binlog
+    - [概述](/dev/reference/tools/tidb-binlog/overview.md)
+    - [部署使用](/dev/reference/tools/tidb-binlog/deploy.md)
+    - [运维管理](/dev/reference/tools/tidb-binlog/maintain.md)
+    - [版本升级](/dev/reference/tools/tidb-binlog/upgrade.md)
+    - [监控告警](/dev/reference/tools/tidb-binlog/monitor.md)
+    - [增量恢复](/dev/reference/tools/tidb-binlog/reparo.md)
+    - [Kafka 自定义开发](/dev/reference/tools/tidb-binlog/binlog-slave-client.md)
+    - [FAQ](/dev/reference/tools/tidb-binlog/faq.md)
 + TiDB in Kubernetes
   - [TiDB Operator 简介](/dev/tidb-in-kubernetes/tidb-operator-overview.md)
   + 快速上手
+    - [kind](/dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-kind.md)
     - [DinD](/dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-dind.md)
     - [GKE](/dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-gke.md)
     - [Minikube](/dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-minikube.md)
@@ -345,6 +350,7 @@
     - [恢复 Kubernetes 上的 TiDB 集群数据](/dev/tidb-in-kubernetes/maintain/lightning.md)
     - [收集日志](/dev/tidb-in-kubernetes/maintain/log-collecting.md)
     - [集群故障自动转移](/dev/tidb-in-kubernetes/maintain/auto-failover.md)
+    - [TiDB Binlog](/dev/tidb-in-kubernetes/maintain/tidb-binlog.md)
   - [扩缩容](/dev/tidb-in-kubernetes/scale-in-kubernetes.md)
   + 升级
     - [TiDB 集群](/dev/tidb-in-kubernetes/upgrade/tidb-cluster.md)
@@ -354,6 +360,7 @@
       - [集群配置](/dev/tidb-in-kubernetes/reference/configuration/tidb-cluster.md)
       - [备份配置](/dev/tidb-in-kubernetes/reference/configuration/backup.md)
       - [PV 配置](/dev/tidb-in-kubernetes/reference/configuration/storage-class.md)
+      - [TiDB Drainer](/dev/tidb-in-kubernetes/reference/configuration/tidb-drainer.md)
     + 工具
       - [tkctl](/dev/tidb-in-kubernetes/reference/tools/tkctl.md)
       - [相关工具使用](/dev/tidb-in-kubernetes/reference/tools/in-kubernetes.md)
@@ -373,6 +380,7 @@
 + [TiDB 路线图](/dev/roadmap.md)
 + [版本发布历史](/dev/releases/rn.md)
   + v3.0
+    - [3.0.5](/dev/releases/3.0.5.md)
     - [3.0.4](/dev/releases/3.0.4.md)
     - [3.0.3](/dev/releases/3.0.3.md)
     - [3.0.2](/dev/releases/3.0.2.md)

dev/faq/data-migration.md

@@ -20,9 +20,29 @@ category: FAQ
 
 当前版本 DM 发生该类型错误时，需要先使用 `stop-task` 停止任务后再使用 `start-task` 重启任务。后续 DM 会完善对此错误类型的自动重试机制。
 
-## 同步任务中断并包含 `get binlog error ERROR 1236 (HY000)`, `binlog checksum mismatch, data may be corrupted` 等 binlog 获取或解析失败错误
+## relay 处理单元报错 `event from * in * diff from passed-in event *` 或同步任务中断并包含 `get binlog error ERROR 1236 (HY000)`、`binlog checksum mismatch, data may be corrupted` 等 binlog 获取或解析失败错误
 
-在 DM 进行增量同步过程中，如果遇到了上游超过 4G 的 binlog 文件，并且 DM 在处理这个 binlog 过程中出现了同步中断（包括正常的 pause/stop 任务，异常的原因导致的中断时）, 就可能出现这个错误。原因是 DM 需要保存同步的 binlog position 信息，但是 MySQL binlog position 官方定义使用 uint32 存储，所以超过 4G 部分的 binlog position 的 offset 值会溢出，就会存储的是一个错误的 binlog position，在重启 task 或者 dm-worker 后，需要使用该 binlog position 重新解析 binlog/relay log，进而出现上面的错误。遇到这种情况需要手动进行恢复，恢复方法：
+在 DM 进行 relay log 拉取与增量同步过程中，如果遇到了上游超过 4GB 的 binlog 文件，就可能出现这两个错误。
 
-- 首先判断出错发生在 relay log 写入还是 binlog replication/syncer unit 同步（通过日志出错信息中的 component 信息即可判断），如果错误发生在 relay log 模块，binlog replication/syncer unit 保存的断点都是正确的情况，可以先停止任务，停止 DM-worker，手动调节 relay meta 的 binlog-position 到 4，重启 DM-worker 重新拉取 relay log ，relay log 写入正常后启动任务会自动从断点继续同步。
-- 如果 relay log 写入正常，已经写到了下一个文件，错误发生在 binlog replication/syncer unit 读取当前超过 4G relay log 文件的一个不合法的 binlog position，这时候可以停止任务，手动调节该任务的 binlog position 信息到该 relay log 的一个合法的 binlog position，比如 4，注意需要同时调整 global checkpoint 和每个 table checkpoint 的 binlog position。设置任务的 safe-mode 为 true ，保证可重入执行，在这之后就可以重新启动同步任务，观察同步状态，只要同步过这个大于 4G 的文件即可。
+原因是 DM 在写 relay log 时需要依据 binlog position 及文件大小对 event 进行验证，且需要保存同步的 binlog position 信息作为 checkpoint。但是 MySQL binlog position 官方定义使用 uint32 存储，所以超过 4G 部分的 binlog position 的 offset 值会溢出，进而出现上面的错误。
+
+对于 relay 处理单元，可通过以下步骤手动恢复：
+
+1. 在上游确认出错时对应的 binlog 文件的大小超出了 4GB。
+2. 停止 DM-worker。
+3. 将上游对应的 binlog 文件复制到 relay log 目录作为 relay log 文件。
+4. 更新 relay log 目录内对应的 `relay.meta` 文件以从下一个 binlog 开始拉取。
+
+    例如：报错时有 `binlog-name = "mysql-bin.004451"` 与`binlog-pos = 2453`，则将其分别更新为 `binlog-name = "mysql-bin.004452"` 与`binlog-pos = 4`。
+5. 重启 DM-worker。
+
+对于 binlog replication 处理单元，可通过以下步骤手动恢复：
+
+1. 在上游确认出错时对应的 binlog 文件的大小超出了 4GB。
+2. 通过 `stop-task` 停止同步任务。
+3. 将下游 `dm_meta` 数据库中 global checkpoint 与每个 table 的 checkpoint 中的 `binlog_name` 更新为出错的 binlog 文件，将 `binlog_pos` 更新为已同步过的一个合法的 position 值，比如 4。
+
+    例如：出错任务名为 `dm_test`，对应的 `source-id` 为 `replica-1`，出错时对应的 binlog 文件为 `mysql-bin|000001.004451`，则执行 `UPDATE dm_test_syncer_checkpoint SET binlog_name='mysql-bin|000001.004451', binlog_pos = 4 WHERE id='replica-1';`。
+4. 在同步任务配置中为 `syncers` 部分设置 `safe-mode: true` 以保证可重入执行。
+5. 通过 `start-task` 启动同步任务。
+6. 通过 `query-status` 观察同步任务状态，当原造成出错的 relay log 文件同步完成后，即可还原 `safe-mode` 为原始值并重启同步任务。

dev/faq/tidb.md

@@ -528,7 +528,7 @@ TiDB 在执行 SQL 时，预估出来每个 operator 处理了超过 10000 条
 
 #### 3.3.10 在 TiDB 中如何控制或改变 SQL 提交的执行优先级？
 
-TiDB 支持改变 [per-session](/dev/reference/configuration/tidb-server/tidb-specific-variables.md#tidb_force_priority)、[全局](/dev/reference/configuration/tidb-server/server-command-option.md#force-priority)或单个语句的优先级。优先级包括：
+TiDB 支持改变 [per-session](/dev/reference/configuration/tidb-server/tidb-specific-variables.md#tidb_force_priority)、[全局](/dev/reference/configuration/tidb-server/configuration-file.md#force-priority)或单个语句的优先级。优先级包括：
 
 - HIGH_PRIORITY：该语句为高优先级语句，TiDB 在执行阶段会优先处理这条语句
 - LOW_PRIORITY：该语句为低优先级语句，TiDB 在执行阶段会降低这条语句的优先级
@@ -562,16 +562,26 @@ TiDB 支持改变 [per-session](/dev/reference/configuration/tidb-server/tidb-sp
 
 #### 3.3.13 触发 Information schema is changed 错误的原因？
 
-TiDB 在执行 SQL 语句时，会使用当时的 `schema` 来处理该 SQL 语句，而且 TiDB 支持在线异步变更 DDL。那么，在执行 DML 的时候可能有 DDL 语句也在执行，而你需要确保每个 SQL 语句在同一个 `schema` 上执行。所以当执行 DML 时，遇到正在执行中的 DDL 操作就可能会报 `Information schema is changed` 的错误。为了避免太多的 DML 语句报错，已做了一些优化。现在会报此错的可能原因如下：
+TiDB 在执行 SQL 语句时，会使用当时的 `schema` 来处理该 SQL 语句，而且 TiDB 支持在线异步变更 DDL。那么，在执行 DML 的时候可能有 DDL 语句也在执行，而你需要确保每个 SQL 语句在同一个 `schema` 上执行。所以当执行 DML 时，遇到正在执行中的 DDL 操作就可能会报 `Information schema is changed` 的错误。为了避免太多的 DML 语句报错，已做了一些优化。
+
+现在会报此错的可能原因如下（后两个报错原因与表无关）：
 
 - 执行的 DML 语句中涉及的表和集群中正在执行的 DDL 的表有相同的，那么这个 DML 语句就会报此错。
-- 与表无关的报错原因：
-    - 这个 DML 执行时间很久，而这段时间内执行了很多 DDL 语句（新版本 `lock table` 也可），导致中间 `schema` 版本变更超过 1024
-    - 接受 DML 请求的 TiDB 长时间不能加载到 `schema information` (与 PD 或者 TiKV 网络问题等都会导致此问题)，而这段时间内执行了很多 DDL 语句（也包括 `lock table` 语句），导致中间 `schema` 版本变更超过 100（目前我们没有按 `schema` 版本去获取信息）。
+- 这个 DML 执行时间很久，而这段时间内执行了很多 DDL 语句，导致中间 `schema` 版本变更次数超过 1024 （此为默认值，可以通过 `tidb_max_delta_schema_count` 变量修改）。
+- 接受 DML 请求的 TiDB 长时间不能加载到 `schema information`（TiDB 与 PD 或 TiKV 之间的网络连接故障等会导致此问题），而这段时间内执行了很多 DDL 语句，导致中间 `schema` 版本变更次数超过 100。
 
 > **注意：**
 >
-> `create table` 操作会有 1 个 `schema` 版本变更，与每个 DDL 操作对应变更的 `schema state` 个数一致。例如，`add column` 操作会有 4 个版本信息。
+> + 目前 TiDB 未缓存所有的 `schema` 版本信息。
+> + 对于每个 DDL 操作，`schema` 版本变更的数量与对应 `schema state` 变更的次数一致。
+> + 不同的 DDL 操作版本变更次数不一样。例如，`create table` 操作会有 1 次 `schema` 版本变更；`add column` 操作有 4 次 `schema` 版本变更。
+
+#### 3.3.14 触发 Information schema is out of date 错误的原因？
+
+当执行 DML 时，TiDB 超过一个 DDL lease 时间（默认 45s）没能加载到最新的 schema 就可能会报 `Information schema is out of date` 的错误。遇到此错的可能原因如下：
+
+- 执行此 DML 的 TiDB 被 kill 后准备退出，且此 DML 对应的事务执行时间超过一个 DDL lease，在事务提交时会报这个错误。
+- TiDB 在执行此 DML 时，有一段时间内连不上 PD 或者 TiKV，导致 TiDB 超过一个 DDL lease 时间没有 load schema，或者导致 TiDB 断开与 PD 之间带 keep alive 设置的连接。
 
 ### 3.4 TiKV 管理
 
@@ -830,7 +840,6 @@ TiDB 读流量可以通过增加 TiDB server 进行扩展，总读容量无限
 
 - 单个事务包含的 SQL 语句不超过 5000 条（默认）
 - 单条 KV entry 不超过 6MB
-- KV entry 的总条数不超过 30w
 - KV entry 的总大小不超过 100MB
 
 在 Google 的 Cloud Spanner 上面，也有类似的[限制](https://cloud.google.com/spanner/docs/limits)。