From 863c552c92a9d424b08b3f474ab112ae14e93264 Mon Sep 17 00:00:00 2001 From: Lilian Lee Date: Mon, 13 May 2019 17:29:33 +0800 Subject: [PATCH] *: test renaming deploy/configure/secure/monitor files (#1322) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * sql: update tidb slow log operation * update log * update log * modify the translation: requirements vs recommendations * improve the translation * dm: add description for task overview monitor * dm: add description for instances' monitor * Update tools/dm/monitor.md Co-Authored-By: csuzhangxc * Update tools/dm/monitor.md Co-Authored-By: csuzhangxc * Update tools/dm/monitor.md Co-Authored-By: csuzhangxc * Update tools/dm/monitor.md Co-Authored-By: csuzhangxc * Update tools/dm/monitor.md Co-Authored-By: csuzhangxc * Update tools/dm/monitor.md Co-Authored-By: csuzhangxc * Update tools/dm/monitor.md Co-Authored-By: csuzhangxc * Update tools/dm/monitor.md Co-Authored-By: csuzhangxc * Update tools/dm/monitor.md Co-Authored-By: csuzhangxc * dm: address comments * Update tools/dm/monitor.md Co-Authored-By: csuzhangxc * Update tools/dm/monitor.md Co-Authored-By: csuzhangxc * Update tools/dm/monitor.md Co-Authored-By: csuzhangxc * v2.1/tools, v2.1/tools: update TiDB-Binlog (#1245) v2.1/tools: update TiDB-Binlog * fix incorrect IP address parsing and other inline code formatting * *: move overview and features (#1253) Via: https://github.com/pingcap/docs/pull/1045 * TOC: update the quickstart link (#1255) * sql: remove redundant content in privilege && user, tiny clean up * Apply suggestions from code review Co-Authored-By: dcalvin * Apply suggestions from code review Co-Authored-By: dcalvin * Update tools/dm/monitor.md Co-Authored-By: csuzhangxc * dm: address comments * add digest declare * update eg * add stats eg * update eg * address comment and add more field * TOC: covert docs-cn to DITA TOC (#1242) * TOC: covert docs-cn to DITA TOC * TOC: update wording * TOC: refine wording * toc: update description and a link * toc: update wording * toc: update a file name * toc: remove the K8s link * toc: fix a link about incremental replication * toc: update a blog post link to Chinese version * toc: fix a link and update wording * toc: update key features and overview * toc: update About TiDB * add declare for v2.1.8 * address comment * change the link of back-restore in tidb-binlog document * address comment * *: remove doc redundant space * sql/slow_query: add pt-digest-query version * tools: update a lightning download link * address comment * sql, TOC: update doc title (#1262) * benchmark: update the Note format * op-guide: update the Note format * benchmark, op-guide: Update the Note format (#1273) benchmark, op-guide: update the Note format * *: update the Note format * address comment * *: update the Note format * benchmark, v2.1/benchmark: remove an invalid link (#1275) * benchmark: remove an invalid link * v2.1/benchmark: remove an invalid link * update condition (#1265) * Update sql/slow-query.md Co-Authored-By: crazycs520 * Update sql/slow-query.md Co-Authored-By: crazycs520 * sql: update the USE command explanation in util document (#1269) * docs-cn #1112 Update the USE command explanation in util document * Update sql/util.md LGTM Co-Authored-By: ericsyh * Update v1.0/sql/util.md LGTM Co-Authored-By: ericsyh * Update v2.0/sql/util.md LGTM Co-Authored-By: ericsyh * Update v2.1/sql/util.md LGTM Co-Authored-By: ericsyh * update the loader pprof-addr default port (#1256) * tools: clarify meaning of "N/A" (#1267) * releases: correct the TiDB-Ansible version (#1280) * sql: fix some format mistakes (#1277) * Sql: fix some format mistakes * Update sql/slow-query.md Co-Authored-By: IzabelWang <37297881+IzabelWang@users.noreply.github.com> * Update sql/slow-query.md Co-Authored-By: IzabelWang <37297881+IzabelWang@users.noreply.github.com> * Update sql/slow-query.md Co-Authored-By: IzabelWang <37297881+IzabelWang@users.noreply.github.com> * Update op-guide/tidb-config-file.md Co-Authored-By: IzabelWang <37297881+IzabelWang@users.noreply.github.com> * Update sql/slow-query.md Co-Authored-By: IzabelWang <37297881+IzabelWang@users.noreply.github.com> * Remove unnecessary space * Update slow-query.md * Update slow-query.md * sql: update generated columns docs * address comment and add issue link * *: rename how-to get started (#1281) * *: rename how-to get started Related PR: https://github.com/pingcap/docs/pull/1046 * *: fix aliases link path * sql: update content structure and wording (#1259) * TOC: update a doc title (#1285) * tools/lightning: fix a broken link (#1287) * explain for update statement (#1284) * tools, toc: reorganize TiDB Binlog documents (#1264) * reorg the binlog documents * update TOC format * change the pd to file in overview * update the ansible-deployment link * rename the previous version of tidb-binlog to tidb-binlog-local * Make the explaination of pausing and paused more clear * change the order in TOC * uncomment some necessary configs in kafka version * add more explaination of paused and offline in overview * fix the typo * Add the Topic config in Kafka driver * update the gc intro in deployment * remove unnecessary step in deployment * remove the compression in deploy document * remove sql in the file dainer * update the download link in deployment * Time and size limits delete * abandon enable-tolerant config * move the reparo document into binlog folder * update the rapero download link * update drainer_pd to drainer_file * trouble-shooting: update the issue report link (#1289) * trouble-shooting: update the issue report link * Update trouble-shooting.md Co-Authored-By: CaitinChen <34535727+CaitinChen@users.noreply.github.com> * Update trouble-shooting.md Co-Authored-By: CaitinChen <34535727+CaitinChen@users.noreply.github.com> * Update trouble-shooting.md Co-Authored-By: CaitinChen <34535727+CaitinChen@users.noreply.github.com> * tools/binlog: optimize the TiDB-Binlog documents (#1291) * fix some problems with suggestions from Lilian and Calvin * tools/binlog: fix and update format (#1292) * tools/binlog: fix and update format * tools/binlog: update wording * tools/binlog: update a link * Update tools/binlog/upgrade.md Co-Authored-By: lilin90 * tools: update syncer batch size (#1288) * tools/dm: fix the error in valus from ansible command (#1293) * sql: fix punctuation and format * circle.yml: [WIP] comment publish pdf cmd * TOC, releases: add 2.1.9 release notes (#1298) * TOC, releases: add 2.1.9 release notes PTAL * Update 2.1.9.md * releases: fix format * tools: update loader status addr (#1299) * Add charset check in Syncer precheck (#1300) * Add charset check in Syncer precheck * Update tools/syncer.md Co-Authored-By: ericsyh * circle.yml: remove IP address (#1301) * *: change "登陆" to “登录” (#1302) * sql: fix format (#1303) * sql: update a comma (#1305) * sql: replace "jeffrey" with "test" (#1309) * op-guide/monitor: update the PD API DOC link (#1311) * Update the link * Update the PD API DOC link * tools: fix the format error in Syncer (#1306) * Fix the format error in Syncer * Update tools/syncer.md Co-Authored-By: ericsyh * update a link (#1313) * op-guide: add a guide about upgrading to 3.0 (#1258) * Add rolling update TiDB 3.0 guide. * Add rolling update TiDB 3.0 guide. * Apply suggestions from code review Co-Authored-By: superlzs0476 <43946384+superlzs0476@users.noreply.github.com> * Apply suggestions from code review * Apply suggestions from code review Co-Authored-By: liubo * op-guide: update a note format * op-guide: update wording * op-guide: update format * circle.yml: add a new IP for qiniu (#1315) * sql: fix typo (#1286) * media, tools: update TiDB-Lightning architecture Via: https://github.com/pingcap/docs/pull/1128 * Delete useless instruction (#1308) * TOC, releases: add TiDB 3.0.0 RC1 release notes (#1316) * TOC, releases: add TiDB 3.0.0 RC1 release notes PTAL * Fix format * add new updates * Update TOC.md * Update rn.md * op-guide, toc: fix upgrade wording and update TOC (#1318) * op-guide, tools: fix a link and remove duplicated file (#1319) * *: update version limit for DM/Syncer (#1312) * toc, support: reorganize TOC and update a link (#1320) * toc, support: reorganize TOC and update a link Related PR: https://github.com/pingcap/docs-cn/pull/1279 * toc: udpate description * toc: update wording * *: rename how-to deploy/configure/secure/monitor --- FAQ.md | 10 +- TOC.md | 215 +++++------ benchmark/sysbench-v2.md | 5 +- benchmark/sysbench-v4.md | 10 +- benchmark/sysbench.md | 4 +- benchmark/tpch-v2.md | 4 +- benchmark/tpch.md | 4 +- circle.yml | 3 +- .../how-to/configure/memory-control.md | 3 +- {sql => dev/how-to/configure}/time-zone.md | 7 +- .../deploy/data-migration-with-ansible.md | 45 ++- .../location-awareness.md | 5 +- .../deploy/geographic-redundancy/overview.md | 19 +- .../how-to/deploy/hardware-recommendations.md | 17 +- .../how-to/deploy/orchestrated/ansible.md | 68 ++-- .../how-to/deploy/orchestrated/docker.md | 7 +- .../deploy/orchestrated/offline-ansible.md | 25 +- .../how-to/deploy/tispark.md | 16 +- .../how-to/get-started/explore-sql.md | 9 +- .../install-from-docker-compose.md | 13 +- .../get-started/read-historical-data.md | 23 +- .../how-to/monitor/monitor-a-cluster.md | 9 +- .../how-to/monitor/overview.md | 7 +- .../secure/enable-tls-between-components.md | 23 +- .../how-to/secure/enable-tls-clients.md | 17 +- .../generate-self-signed-certificates.md | 3 +- media/tidb-lightning-architecture.png | Bin 0 -> 29918 bytes media/tidb-lightning.svg | 82 ----- op-guide/ansible-deployment-rolling-update.md | 8 +- op-guide/ansible-deployment-scale.md | 3 +- op-guide/backup-restore.md | 4 +- op-guide/configuration.md | 6 +- op-guide/gc.md | 12 +- op-guide/horizontal-scale.md | 4 +- op-guide/migration-overview.md | 4 +- op-guide/migration.md | 23 +- op-guide/pd-configuration.md | 48 +-- op-guide/tidb-config-file.md | 87 ++--- op-guide/tidb-v2.0-upgrade-guide.md | 4 +- op-guide/tidb-v2.1-upgrade-guide.md | 4 +- op-guide/tidb-v3.0-upgrade-guide.md | 134 +++++++ releases/2.1.9.md | 68 ++++ releases/205.md | 2 +- releases/3.0.0-beta.1.md | 4 +- releases/3.0.0-rc.1.md | 141 +++++++ releases/rn.md | 6 +- sql/aggregate-group-by-functions.md | 2 +- sql/character-set-support.md | 12 +- sql/date-and-time-types.md | 8 +- sql/ddl.md | 4 +- sql/dml.md | 2 +- sql/error.md | 2 +- sql/generated-columns.md | 33 +- sql/literal-value-null-values.md | 4 +- sql/literal-values.md | 4 +- sql/mysql-compatibility.md | 4 +- sql/optimizer-hints.md | 4 +- sql/privilege.md | 344 +++++++----------- sql/slow-query.md | 232 +++++++++--- sql/statistics.md | 6 +- sql/system-database.md | 18 +- sql/tidb-server.md | 6 +- sql/tidb-specific.md | 6 +- sql/transaction-isolation.md | 6 +- sql/transaction.md | 5 +- sql/understanding-the-query-execution-plan.md | 2 + sql/user-account-management.md | 102 +++++- sql/util.md | 3 +- support.md | 2 +- tispark/tispark-quick-start-guide_v1.x.md | 4 +- tispark/tispark-user-guide_v1.x.md | 6 +- tools/{ => binlog}/binlog-slave-client.md | 16 +- .../deploy.md} | 303 +++------------ .../monitor.md} | 102 ++---- tools/binlog/operation.md | 131 +++++++ tools/binlog/overview.md | 60 +++ tools/{ => binlog}/reparo.md | 18 +- tools/{ => binlog}/tidb-binlog-kafka.md | 54 +-- .../tidb-binlog-local.md} | 40 +- tools/binlog/upgrade.md | 42 +++ tools/dm/cluster-operations.md | 18 +- tools/dm/data-synchronization-features.md | 24 +- tools/dm/dm-upgrade.md | 6 +- tools/dm/dm-worker-intro.md | 4 +- tools/dm/manage-task.md | 4 +- .../manually-handling-sharding-ddl-locks.md | 6 +- tools/dm/monitor.md | 68 +++- tools/dm/overview.md | 6 + tools/dm/practice.md | 10 +- tools/dm/relay-log.md | 4 +- tools/dm/shard-merge-scenario.md | 4 +- tools/dm/shard-merge.md | 4 +- tools/dm/simple-synchronization-scenario.md | 4 +- tools/dm/skip-replace-sqls.md | 3 +- tools/dm/troubleshooting.md | 4 +- tools/lightning/checkpoints.md | 4 +- tools/lightning/deployment.md | 8 +- tools/lightning/filter.md | 4 +- tools/lightning/overview-architecture.md | 2 +- tools/loader.md | 10 +- tools/syncer.md | 18 +- tools/tikv-control.md | 24 +- trouble-shooting.md | 8 +- v1.0/FAQ.md | 8 +- v1.0/benchmark/sysbench.md | 4 +- v1.0/op-guide/ansible-deployment.md | 12 +- v1.0/op-guide/backup-restore.md | 4 +- v1.0/op-guide/monitor.md | 2 +- v1.0/sql/dml.md | 2 +- v1.0/sql/privilege.md | 8 +- v1.0/sql/user-account-management.md | 2 +- v1.0/sql/util.md | 2 +- v2.0/FAQ.md | 8 +- v2.0/op-guide/monitor.md | 2 +- v2.0/sql/dml.md | 2 +- v2.0/sql/privilege.md | 8 +- v2.0/sql/user-account-management.md | 2 +- v2.0/sql/util.md | 2 +- v2.1/FAQ.md | 10 +- v2.1/benchmark/sysbench-v2.md | 5 +- v2.1/benchmark/sysbench.md | 4 +- v2.1/benchmark/tpch-v2.md | 4 +- v2.1/benchmark/tpch.md | 4 +- .../ansible-deployment-rolling-update.md | 8 +- v2.1/op-guide/ansible-deployment-scale.md | 3 +- v2.1/op-guide/ansible-deployment.md | 29 +- v2.1/op-guide/backup-restore.md | 4 +- v2.1/op-guide/configuration.md | 6 +- v2.1/op-guide/cross-dc-deployment.md | 4 +- v2.1/op-guide/docker-compose.md | 4 +- v2.1/op-guide/docker-deployment.md | 4 +- v2.1/op-guide/gc.md | 4 +- v2.1/op-guide/history-read.md | 12 +- v2.1/op-guide/horizontal-scale.md | 4 +- v2.1/op-guide/migration-overview.md | 4 +- v2.1/op-guide/migration.md | 23 +- v2.1/op-guide/monitor.md | 2 +- v2.1/op-guide/recommendation.md | 6 +- v2.1/op-guide/tidb-config-file.md | 5 +- v2.1/op-guide/tidb-v2.0-upgrade-guide.md | 4 +- v2.1/op-guide/tidb-v2.1-upgrade-guide.md | 4 +- v2.1/releases/205.md | 2 +- v2.1/sql/aggregate-group-by-functions.md | 2 +- v2.1/sql/character-set-support.md | 12 +- v2.1/sql/date-and-time-types.md | 4 +- v2.1/sql/ddl.md | 4 +- v2.1/sql/dml.md | 2 +- v2.1/sql/encrypted-connections.md | 4 +- v2.1/sql/literal-value-null-values.md | 4 +- v2.1/sql/privilege.md | 12 +- v2.1/sql/tidb-specific.md | 9 +- v2.1/sql/time-zone.md | 4 +- .../understanding-the-query-execution-plan.md | 16 +- v2.1/sql/user-account-management.md | 2 +- v2.1/sql/util.md | 2 +- v2.1/tispark/tispark-user-guide.md | 6 +- v2.1/tools/lightning/checkpoints.md | 4 +- v2.1/tools/lightning/deployment.md | 4 +- v2.1/tools/lightning/overview-architecture.md | 2 +- v2.1/tools/tidb-binlog-cluster.md | 8 +- v2.1/tools/tidb-binlog-kafka.md | 8 +- v2.1/tools/tikv-control.md | 24 +- 162 files changed, 2076 insertions(+), 1333 deletions(-) rename sql/tidb-memory-control.md => dev/how-to/configure/memory-control.md (97%) rename {sql => dev/how-to/configure}/time-zone.md (86%) rename tools/dm/deployment.md => dev/how-to/deploy/data-migration-with-ansible.md (95%) rename {op-guide => dev/how-to/deploy/geographic-redundancy}/location-awareness.md (92%) rename op-guide/cross-dc-deployment.md => dev/how-to/deploy/geographic-redundancy/overview.md (85%) rename op-guide/recommendation.md => dev/how-to/deploy/hardware-recommendations.md (89%) rename op-guide/ansible-deployment.md => dev/how-to/deploy/orchestrated/ansible.md (89%) rename op-guide/docker-deployment.md => dev/how-to/deploy/orchestrated/docker.md (96%) rename op-guide/offline-ansible-deployment.md => dev/how-to/deploy/orchestrated/offline-ansible.md (77%) rename tispark/tispark-quick-start-guide.md => dev/how-to/deploy/tispark.md (88%) rename try-tidb.md => dev/how-to/get-started/explore-sql.md (94%) rename op-guide/docker-compose.md => dev/how-to/get-started/local-cluster/install-from-docker-compose.md (92%) rename op-guide/history-read.md => dev/how-to/get-started/read-historical-data.md (84%) rename op-guide/monitor.md => dev/how-to/monitor/monitor-a-cluster.md (97%) rename op-guide/monitor-overview.md => dev/how-to/monitor/overview.md (83%) rename op-guide/security.md => dev/how-to/secure/enable-tls-between-components.md (83%) rename sql/encrypted-connections.md => dev/how-to/secure/enable-tls-clients.md (92%) rename {op-guide => dev/how-to/secure}/generate-self-signed-certificates.md (97%) create mode 100644 media/tidb-lightning-architecture.png delete mode 100644 media/tidb-lightning.svg create mode 100644 op-guide/tidb-v3.0-upgrade-guide.md create mode 100644 releases/2.1.9.md create mode 100644 releases/3.0.0-rc.1.md rename tools/{ => binlog}/binlog-slave-client.md (84%) rename tools/{tidb-binlog-cluster.md => binlog/deploy.md} (52%) rename tools/{tidb-binlog-monitor.md => binlog/monitor.md} (57%) create mode 100644 tools/binlog/operation.md create mode 100644 tools/binlog/overview.md rename tools/{ => binlog}/reparo.md (75%) rename tools/{ => binlog}/tidb-binlog-kafka.md (90%) rename tools/{tidb-binlog.md => binlog/tidb-binlog-local.md} (89%) create mode 100644 tools/binlog/upgrade.md diff --git a/FAQ.md b/FAQ.md index 88ca7e20511b..bcfd41cfbb7c 100755 --- a/FAQ.md +++ b/FAQ.md @@ -118,7 +118,7 @@ TiDB 的 sql_mode 与 MySQL 的 sql_mode 设置方法有一些差别，TiDB 不 #### 1.1.24 TiDB 支持哪些认证协议，过程是怎样的？ -这一层跟 MySQL 一样，走的 SASL 认证协议，用于用户登陆认证，对密码的处理流程。 +这一层跟 MySQL 一样，走的 SASL 认证协议，用于用户登录认证，对密码的处理流程。 客户端连接 TiDB 的时候，走的是 challenge-response（挑战-应答）的认证模式，过程如下： @@ -349,9 +349,9 @@ Binary 不是我们建议的安装方式，对升级支持也不友好，建议 | 滚动升级除 PD 外模块 | ansible-playbook rolling\_update.yml --skip-tags=pd | | 滚动升级监控组件 | ansible-playbook rolling\_update\_monitor.yml | -#### 3.1.2 TiDB 如何登陆？ +#### 3.1.2 TiDB 如何登录？ -和 MySQL 登陆方式一样，可以按照下面例子进行登陆。 +和 MySQL 登录方式一样，可以按照下面例子进行登录。 `mysql -h 127.0.0.1 -uroot -P4000` @@ -697,9 +697,9 @@ loader 的 -t 参数可以根据 TiKV 的实例个数以及负载进行评估调 TiDB 支持绝大多数 MySQL 语法，一般不需要修改代码。 -#### 4.1.4 不小心把 MySQL 的 user 表导入到 TiDB 了，或者忘记密码，无法登陆，如何处理？ +#### 4.1.4 不小心把 MySQL 的 user 表导入到 TiDB 了，或者忘记密码，无法登录，如何处理？ -重启 TiDB 服务，配置文件中增加 `-skip-grant-table=true` 参数，无密码登陆集群后，可以根据情况重建用户，或者重建 mysql.user 表，具体表结构搜索官网。 +重启 TiDB 服务，配置文件中增加 `-skip-grant-table=true` 参数，无密码登录集群后，可以根据情况重建用户，或者重建 mysql.user 表，具体表结构搜索官网。 #### 4.1.5 在 Loader 运行的过程中，TiDB 可以对外提供服务吗？ 该操作进行逻辑插入，TiDB 仍可对外提供服务，但不要执行相关 DDL 操作。 diff --git a/TOC.md b/TOC.md index 1db144a5fcaf..02597660a840 100644 --- a/TOC.md +++ b/TOC.md @@ -1,4 +1,4 @@ -# TiDB 中文技术文档 +# TiDB 中文用户文档 ## 目录 @@ -11,36 +11,31 @@ + 操作指南 + 快速上手 + 创建本地集群 - - [使用 Docker Compose](op-guide/docker-compose.md) - - [SQL 基本操作](try-tidb.md) - - [读取历史数据](op-guide/history-read.md) - - 部署 - - [软硬件环境需求](op-guide/recommendation.md) + - [使用 Docker Compose](dev/how-to/get-started/local-cluster/install-from-docker-compose.md) + - [SQL 基本操作](dev/how-to/get-started/explore-sql.md) + - [读取历史数据](dev/how-to/get-started/read-historical-data.md) + + 部署 + - [软硬件环境需求](dev/how-to/deploy/hardware-recommendations.md) + 集群部署方式 - - [使用 Ansible 部署（推荐）](op-guide/ansible-deployment.md) - - [使用 Ansible 离线部署](op-guide/offline-ansible-deployment.md) - - [使用 Docker 部署](op-guide/docker-deployment.md) + - [使用 Ansible 部署（推荐）](dev/how-to/deploy/orchestrated/ansible.md) + - [使用 Ansible 离线部署](dev/how-to/deploy/orchestrated/offline-ansible.md) + - [使用 Docker 部署](dev/how-to/deploy/orchestrated/docker.md) + 跨地域冗余 - - [跨数据中心部署方案](op-guide/cross-dc-deployment.md) - - [配置集群拓扑](op-guide/location-awareness.md) - - [TiSpark 快速上手](tispark/tispark-quick-start-guide.md) - - [使用 Ansible 部署 DM 集群](tools/dm/deployment.md) + - [跨数据中心部署方案](dev/how-to/deploy/geographic-redundancy/overview.md) + - [配置集群拓扑](dev/how-to/deploy/geographic-redundancy/location-awareness.md) + - [TiSpark 快速上手](dev/how-to/deploy/tispark.md) + - [使用 Ansible 部署 DM 集群](dev/how-to/deploy/data-migration-with-ansible.md) + + 配置 + - [时区](dev/how-to/configure/time-zone.md) + - [内存控制](dev/how-to/configure/memory-control.md) + 安全 - - [与 MySQL 的安全特性差异](sql/security-compatibility.md) - - [TiDB 数据库权限管理](sql/privilege.md) - - [TiDB 用户账户管理](sql/user-account-management.md) + 安全传输层协议 (TLS) - - [为 MySQL 客户端启用 TLS](sql/encrypted-connections.md) - - [为 TiDB 组件启用 TLS](op-guide/security.md) - - [生成自签名证书](op-guide/generate-self-signed-certificates.md) + - [为 MySQL 客户端开启 TLS](dev/how-to/secure/enable-tls-clients.md) + - [为 TiDB 组件间开启 TLS](dev/how-to/secure/enable-tls-between-components.md) + - [生成自签名证书](dev/how-to/secure/generate-self-signed-certificates.md) + 监控 - - [概述](op-guide/monitor-overview.md) - - [监控 TiDB 集群](op-guide/monitor.md) - + 重要监控指标详解 - - [Overview](op-guide/dashboard-overview-info.md) - - [TiDB](op-guide/tidb-dashboard-info.md) - - [PD](op-guide/dashboard-pd-info.md) - - [TiKV](op-guide/dashboard-tikv-info.md) + - [概述](dev/how-to/monitor/overview.md) + - [监控 TiDB 集群](dev/how-to/monitor/monitor-a-cluster.md) + 迁移 - [概述](op-guide/migration-overview.md) + 从 MySQL 迁移 @@ -52,36 +47,30 @@ + 备份与恢复 - [全量备份](op-guide/backup-restore.md) - [增量备份](tools/tidb-binlog-cluster.md) - + 扩容缩容 - - [集群扩容缩容方案](op-guide/horizontal-scale.md) - - [使用 Ansible 扩容缩容](op-guide/ansible-deployment-scale.md) - [定位慢查询](sql/slow-query.md) - + 升级 - - [升级至 TiDB 2.1](op-guide/tidb-v2.1-upgrade-guide.md) - - [升级 Data Migration](tools/dm/dm-upgrade.md) - - [使用 Ansible 滚动升级](op-guide/ansible-deployment-rolling-update.md) - - 故障诊断 - - [错误码](sql/error.md) + + 扩容缩容 + - [使用 Ansible 扩容缩容](op-guide/ansible-deployment-scale.md) + - [集群扩容缩容方案](op-guide/horizontal-scale.md) + + 升级 + - [升级至 TiDB 3.0](op-guide/tidb-v3.0-upgrade-guide.md) + - [升级至 TiDB 2.1](op-guide/tidb-v2.1-upgrade-guide.md) + - [使用 Ansible 滚动升级](op-guide/ansible-deployment-rolling-update.md) + - [升级 Data Migration](tools/dm/dm-upgrade.md) + + 故障诊断 - [集群配置诊断](trouble-shooting.md) - [Data Migration 故障诊断](tools/dm/troubleshooting.md) - [TiDB-Lightning 故障诊断](tools/lightning/errors.md) - - [支持渠道](support.md) - - [反馈问题](report-issue.md) - + [贡献](contribute.md) - - [贡献代码](contribute.md#成为-tidb-的贡献者) - - [改进文档](contribute.md#改进文档) -+ 参考资源 ++ 参考手册 + + [与 MySQL 兼容性对比](sql/mysql-compatibility.md) + SQL - - [支持的连接器和 API](sql/connection-and-APIs.md) - - [与 MySQL 兼容性对比](sql/mysql-compatibility.md) - + SQL 语句 - - [数据定义语句 (DDL)](sql/ddl.md) - - [数据操作语句 (DML)](sql/dml.md) - - [事务语句](sql/transaction.md) - - [数据库管理语句](sql/admin.md) - - [Prepared SQL 语句语法](sql/prepare.md) - - [实用工具语句](sql/util.md) - - [TiDB SQL 语法图](https://pingcap.github.io/sqlgram/) + - [TiDB SQL 语法图](https://pingcap.github.io/sqlgram/) + + SQL 语言结构 + - [字面值](sql/literal-values.md) + - [Schema 对象名](sql/schema-object-names.md) + - [关键字和保留字](sql/keywords-and-reserved-words.md) + - [用户自定义变量](sql/user-defined-variables.md) + - [表达式语法](sql/expression-syntax.md) + - [注释语法](sql/comment-syntax.md) + 数据类型 - [数值类型](sql/datatype.md#数值类型) - [日期和时间类型](sql/datatype.md#日期时间类型) @@ -90,7 +79,6 @@ - [枚举类型](sql/datatype.md#枚举类型) - [集合类型](sql/datatype.md#集合类型) - [数据类型默认值](sql/datatype.md#数据类型的默认值) - - [约束](sql/constraints.md) + 函数与操作符 - [函数与操作符概述](sql/functions-and-operators-reference.md) - [表达式求值的类型转换](sql/type-conversion-in-expression-evaluation.md) @@ -107,48 +95,60 @@ - [GROUP BY 聚合函数](sql/aggregate-group-by-functions.md) - [其它函数](sql/miscellaneous-functions.md) - [精度数学](sql/precision-math.md) - + SQL 语言结构 - - [字面值](sql/literal-values.md) - - [Schema 对象名](sql/schema-object-names.md) - - [关键字和保留字](sql/keywords-and-reserved-words.md) - - [用户自定义变量](sql/user-defined-variables.md) - - [表达式语法](sql/expression-syntax.md) - - [注释语法](sql/comment-syntax.md) + + SQL 语句 + - [数据定义语句 (DDL)](sql/ddl.md) + - [数据操作语句 (DML)](sql/dml.md) + - [事务语句](sql/transaction.md) + - [数据库管理语句](sql/admin.md) + - [Prepared SQL 语句语法](sql/prepare.md) + - [实用工具语句](sql/util.md) + - [约束](sql/constraints.md) - [生成列](sql/generated-columns.md) - + 事务 - - [事务模型](sql/transaction-model.md) - - [隔离级别](sql/transaction-isolation.md) - + 性能 - - [SQL 优化流程](sql/sql-optimizer-overview.md) - - [基于代价的优化](sql/understanding-the-query-execution-plan.md) - - [统计信息概述](sql/statistics.md) - - [Optimizer Hints](sql/optimizer-hints.md) - - [TiKV 调优](op-guide/tune-tikv.md) - - [TiDB 最佳实践](https://pingcap.com/blog-cn/tidb-best-practice/) - - [TiDB 系统数据库](sql/system-database.md) - - [Information Schema](sql/information-schema.md) - - [TiSpark 使用指南](tispark/tispark-user-guide.md) + - [字符集](sql/character-set-support.md) + 配置 + tidb-server - [MySQL 系统变量](sql/variable.md) - [TiDB 特定系统变量](sql/tidb-specific.md) - - [时区](sql/time-zone.md) - - [字符集](sql/character-set-support.md) - - [内存控制](sql/tidb-memory-control.md) - - [垃圾回收 (GC)](op-guide/gc.md) - [配置参数](op-guide/configuration.md) + pd-server - [配置参数](op-guide/pd-configuration.md) + tikv-server - [配置参数](op-guide/tikv-configuration.md) + + 监控指标 + - [Overview 面板](op-guide/dashboard-overview-info.md) + - [TiDB 面板](op-guide/tidb-dashboard-info.md) + - [PD 面板](op-guide/dashboard-pd-info.md) + - [TiKV 面板](op-guide/dashboard-tikv-info.md) + + 安全 + - [与 MySQL 的安全特性差异](sql/security-compatibility.md) + - [TiDB 数据库权限管理](sql/privilege.md) + - [TiDB 用户账户管理](sql/user-account-management.md) + + 事务 + - [事务模型](sql/transaction-model.md) + - [隔离级别](sql/transaction-isolation.md) + + 系统数据库 + - [`mysql`](sql/system-database.md) + - [`information_schema`](sql/information-schema.md) + - [错误码](sql/error.md) + - [支持的连接器和 API](sql/connection-and-APIs.md) + - [垃圾回收 (GC)](op-guide/gc.md) + + 性能调优 + - [SQL 优化流程](sql/sql-optimizer-overview.md) + - [理解 TiDB 执行计划](sql/understanding-the-query-execution-plan.md) + - [统计信息概述](sql/statistics.md) + - [Optimizer Hints](sql/optimizer-hints.md) + - [TiKV 调优](op-guide/tune-tikv.md) + - [TiDB 最佳实践](https://pingcap.com/blog-cn/tidb-best-practice/) + + [TiSpark 使用指南](tispark/tispark-user-guide.md) + 生态工具 - [Mydumper](tools/mydumper.md) - [Loader](tools/loader.md) - [Syncer](tools/syncer.md) + Data Migration - - [概述](tools/dm/overview.md) - - [使用限制](tools/dm/overview.md#使用限制) - + [部署使用](tools/dm/practice.md) + + [概述](tools/dm/overview.md) + - [DM 架构](tools/dm/overview.md#dm-架构) + - [同步功能介绍](tools/dm/overview.md#同步功能介绍) + - [使用限制](tools/dm/overview.md#使用限制) + 核心特性 - [Table Routing](tools/dm/data-synchronization-features.md#table-routing) - [Black & White Lists](tools/dm/data-synchronization-features.md#black-white-table-lists) @@ -162,6 +162,7 @@ + 使用场景 - [简单的从库同步场景](tools/dm/simple-synchronization-scenario.md) - [分库分表合并场景](tools/dm/shard-merge-scenario.md) + + [部署使用](tools/dm/practice.md) + 配置 - [概述](tools/dm/dm-configuration-file-overview.md) - [任务配置](tools/dm/task-configuration-file-intro.md) @@ -175,57 +176,35 @@ - [表库过滤](tools/lightning/filter.md) - [CSV 支持](tools/lightning/csv.md) - [监控告警](tools/lightning/monitor.md) - - [TiDB-Binlog](tools/tidb-binlog-cluster.md) + + TiDB-Binlog + - [概述](tools/binlog/overview.md) + - [部署使用](tools/binlog/deploy.md) + - [监控告警](tools/binlog/monitor.md) + - [运维管理](tools/binlog/operation.md) + - [版本升级](tools/binlog/upgrade.md) - [PD Control](tools/pd-control.md) - [PD Recover](tools/pd-recover.md) - [TiKV Control](https://github.com/tikv/tikv/blob/master/docs/tools/tikv-control.md) - [TiDB Controller](tools/tidb-controller.md) - [工具下载](tools/download.md) - - [TiDB 路线图](ROADMAP.md) - + 用户案例 - - [北京银行](http://t.cn/RnY8fGn) - - [海航](http://t.cn/REXx0Qe) - - [美团点评](http://t.cn/EAFCqhl) - - [今日头条](http://t.cn/RnLfEMf) - - [转转](http://t.cn/R1MAXEq) - - [Mobike](http://t.cn/RT8FbP6) - - [小米科技](http://t.cn/Ey2xCDK) - - [爱奇艺](http://t.cn/EvErsc1) - - [易果生鲜](http://t.cn/RTYVhzH) - - [同程旅游（一）](http://t.cn/RmXeNKR) - - [同程旅游（二）](http://t.cn/EAmsF08) - - [去哪儿](http://t.cn/RTKnsL7) - - [火星文化](http://t.cn/EAuvfcs) - - [G7](http://t.cn/RQVePoX) - - [一面数据](http://t.cn/RT9r5di) - - [凤凰网](http://t.cn/RHRQfNT) - - [猿辅导](http://t.cn/RTKnKSX) - - [Mobikok](http://t.cn/Rm1F6lg) - - [二维火](http://t.cn/R8bXM2f) - - [客如云](http://t.cn/R1wSEJH) - - [Ping++](http://t.cn/RE5xYKn) - - [乐视云](http://t.cn/Rnv3IVs) - - [零氪科技](http://t.cn/REj7tSv) - - [威锐达测控](http://t.cn/R3CrviR) - - [盖娅互娱](http://t.cn/RT9r7hx) - - [游族网络](http://t.cn/R8k4AWB) - - [西山居](http://t.cn/RBP12zj) - - [FUNYOURS JAPAN](http://t.cn/Rnoab5D) - - [丰巢科技](http://t.cn/EAuvLIv) - - [特来电](http://t.cn/RrHzUGW) - - [万达网络](http://t.cn/RTKm6ds) - - [360金融](http://t.cn/RTKnTev) - - [中国电信翼支付](http://t.cn/R3Wd9p3) - - [某电信运营商](http://t.cn/RTYWADg) + 常见问题 (FAQ) - [TiDB FAQ](FAQ.md) - [TiDB-Lightning FAQ](tools/lightning/faq.md) - [升级 FAQ](op-guide/upgrade-faq.md) ++ 技术支持 + - [支持渠道](support.md) + - [反馈问题](report-issue.md) ++ [贡献](contribute.md) + - [贡献代码](contribute.md#成为-tidb-的贡献者) + - [改进文档](contribute.md#改进文档) +- [TiDB 路线图](ROADMAP.md) + [版本发布历史](releases/rn.md) + v3.0 - - [3.0.0 Beta.1](releases/3.0.0-beta.1.md) - - [3.0 Beta](releases/3.0beta.md) + - [3.0.0-rc.1](releases/3.0.0-rc.1.md) + - [3.0.0-beta.1](releases/3.0.0-beta.1.md) + - [3.0.0-beta](releases/3.0beta.md) + v2.1 + - [2.1.9](releases/2.1.9.md) - [2.1.8](releases/2.1.8.md) - [2.1.7](releases/2.1.7.md) - [2.1.6](releases/2.1.6.md) diff --git a/benchmark/sysbench-v2.md b/benchmark/sysbench-v2.md index fc188ef4267a..4ca39cc70da0 100644 --- a/benchmark/sysbench-v2.md +++ b/benchmark/sysbench-v2.md @@ -26,10 +26,7 @@ IDC 机器 | OS | Linux (CentOS 7.3.1611) | | CPU | 40 vCPUs, Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz | | RAM | 128GB | -| DISK | Optane 500GB SSD * 1 | - -Sysbench 测试脚本： -https://github.com/pingcap/tidb-bench/tree/master/sysbench +| DISK | Optane 500GB SSD * 1 | ## 测试方案 diff --git a/benchmark/sysbench-v4.md b/benchmark/sysbench-v4.md index 448f9bcf6414..42ef685afd8f 100644 --- a/benchmark/sysbench-v4.md +++ b/benchmark/sysbench-v4.md @@ -90,7 +90,9 @@ block-cache-size = "6GB" ## 测试过程 -> **注意**：此次测试并没有使用如 HAproxy 等负载均衡工具。在 TiDB 单一节点上进行 Sysbench 测试，并把结果相加。负载均衡工具和不同版本参数也会影响性能表现。 +> **注意：** +> +> 此次测试并没有使用如 HAproxy 等负载均衡工具。在 TiDB 单一节点上进行 Sysbench 测试，并把结果相加。负载均衡工具和不同版本参数也会影响性能表现。 ### Sysbench 配置 @@ -134,10 +136,12 @@ create database sbtest; 假设用户使用的 [Sysbench](https://github.com/akopytov/sysbench/tree/1.0.14) 版本。我们可以通过以下两种方式来修改。 -1. 直接下载为 TiDB 修改好的 [oltp_common.lua](https://raw.githubusercontent.com/pingcap/tidb-bench/master/sysbench-patch/oltp_common.lua) 文件，覆盖 `/usr/share/sysbench/oltp_common.lua` 文件。 +1. 直接下载为 TiDB 修改好的 [oltp_common.lua](https://raw.githubusercontent.com/pingcap/tidb-bench/master/sysbench/sysbench-patch/oltp_common.lua) 文件，覆盖 `/usr/share/sysbench/oltp_common.lua` 文件。 2. 将 `/usr/share/sysbench/oltp_common.lua` 的第 [235](https://github.com/akopytov/sysbench/blob/1.0.14/src/lua/oltp_common.lua#L235) 行到第 [240](https://github.com/akopytov/sysbench/blob/1.0.14/src/lua/oltp_common.lua#L240) 行移动到第 198 行以后。 -> **注意**：此操作为可选操作，仅节约了数据导入时间。 +> **注意：** +> +> 此操作为可选操作，仅节约了数据导入时间。 命令行输入以下命令，开始导入数据，config 文件为上一步中配置的文件： diff --git a/benchmark/sysbench.md b/benchmark/sysbench.md index 8c6017c8a0d3..44c4fdfd2d9c 100644 --- a/benchmark/sysbench.md +++ b/benchmark/sysbench.md @@ -10,7 +10,9 @@ draft: true 测试 TiDB 在 OLTP 场景下的性能以及水平扩展能力。 -> **注意**: 不同的测试环境可能使测试结果发生改变。 +> **注意：** +> +> 不同的测试环境可能使测试结果发生改变。 ## 测试版本、时间、地点 diff --git a/benchmark/tpch-v2.md b/benchmark/tpch-v2.md index de31f746af7d..aac0be586270 100644 --- a/benchmark/tpch-v2.md +++ b/benchmark/tpch-v2.md @@ -9,7 +9,9 @@ category: benchmark 测试 TiDB 在 OLAP 场景下 2.0 和 2.1 版本的性能对比。 -> **注意**：不同的测试环境可能使测试结果发生改变。 +> **注意：** +> +> 不同的测试环境可能使测试结果发生改变。 ## 测试环境 diff --git a/benchmark/tpch.md b/benchmark/tpch.md index 1d8f1ba9031b..7e45daaeaeaa 100644 --- a/benchmark/tpch.md +++ b/benchmark/tpch.md @@ -9,7 +9,9 @@ category: benchmark 测试 TiDB 在 OLAP 场景下 1.0 和 2.0 版本的性能对比。 -> **注意**：不同的测试环境可能使测试结果发生改变。 +> **注意：** +> +> 不同的测试环境可能使测试结果发生改变。 ## 测试环境 diff --git a/circle.yml b/circle.yml index cdd7f0cf1bae..e302d293e5b8 100644 --- a/circle.yml +++ b/circle.yml @@ -24,10 +24,11 @@ jobs: name: "Generate PDF" command: scripts/generate_pdf.sh + # echo "222.222.95.49 uc.qbox.me": adds a new host - deploy: name: "Publish PDF" command: | - sudo bash -c 'echo "119.188.128.5 uc.qbox.me" >> /etc/hosts'; + sudo bash -c 'echo "222.222.95.49 uc.qbox.me" >> /etc/hosts'; if [ "${CIRCLE_BRANCH}" == "master" ]; then python3 scripts/upload.py output.pdf tidb-manual-cn.pdf; fi diff --git a/sql/tidb-memory-control.md b/dev/how-to/configure/memory-control.md similarity index 97% rename from sql/tidb-memory-control.md rename to dev/how-to/configure/memory-control.md index df8724f650ee..23428593cc7e 100644 --- a/sql/tidb-memory-control.md +++ b/dev/how-to/configure/memory-control.md @@ -1,6 +1,7 @@ --- title: TiDB 内存控制文档 -category: user guide +category: how-to +aliases: ['/docs-cn/sql/tidb-memory-control/'] --- # TiDB 内存控制文档 diff --git a/sql/time-zone.md b/dev/how-to/configure/time-zone.md similarity index 86% rename from sql/time-zone.md rename to dev/how-to/configure/time-zone.md index 358dd981cdf8..ac0a554a2ba9 100644 --- a/sql/time-zone.md +++ b/dev/how-to/configure/time-zone.md @@ -1,6 +1,7 @@ --- title: 时区支持 -category: user guide +category: how-to +aliases: ['/docs-cn/sql/time-zone/'] --- # 时区支持 @@ -37,7 +38,9 @@ mysql> SELECT @@global.time_zone, @@session.time_zone; `NOW()` 和 `CURTIME()` 的返回值都受到时区设置的影响。 -注意，只有 Timestamp 数据类型的值是受时区影响的。可以理解为， Timestamp 数据类型的实际表示使用的是 (字面值 + 时区信息)。其它时间和日期类型，比如 Datetime/Date/Time 是不包含时区信息的，所以也不受到时区变化的影响。 +> **注意：** +> +> 只有 Timestamp 数据类型的值是受时区影响的。可以理解为， Timestamp 数据类型的实际表示使用的是 (字面值 + 时区信息)。其它时间和日期类型，比如 Datetime/Date/Time 是不包含时区信息的，所以也不受到时区变化的影响。 ```sql mysql> create table t (ts timestamp, dt datetime); diff --git a/tools/dm/deployment.md b/dev/how-to/deploy/data-migration-with-ansible.md similarity index 95% rename from tools/dm/deployment.md rename to dev/how-to/deploy/data-migration-with-ansible.md index 8191ca9d1cd3..be48aa0386a1 100644 --- a/tools/dm/deployment.md +++ b/dev/how-to/deploy/data-migration-with-ansible.md @@ -1,6 +1,7 @@ --- title: 使用 DM-Ansible 部署 DM 集群 -category: tools +category: how-to +aliases: ['/docs-cn/tools/dm/deployment/'] --- # 使用 DM-Ansible 部署 DM 集群 @@ -25,7 +26,9 @@ DM-Ansible 是 PingCAP 基于 [Ansible](https://docs.ansible.com/ansible/latest/ ## 第 1 步：在中控机上安装依赖包 -> **注意**：请确保使用 `root` 账户登陆中控机。 +> **注意：** +> +> 请确保使用 `root` 账户登录中控机。 根据中控机的操作系统版本，运行相应命令如下： @@ -44,7 +47,9 @@ DM-Ansible 是 PingCAP 基于 [Ansible](https://docs.ansible.com/ansible/latest/ ## 第 2 步：在中控机上创建 `tidb` 用户，并生成 SSH 密钥 -> **注意**：请确保使用 `root` 账户登陆中控机。 +> **注意：** +> +> 请确保使用 `root` 账户登录中控机。 1. 创建 `tidb` 用户。 @@ -67,7 +72,7 @@ DM-Ansible 是 PingCAP 基于 [Ansible](https://docs.ansible.com/ansible/latest/ 4. 生成 SSH 密钥。 - 执行以下 `su` 命令，将登陆用户从 `root` 切换至 `tidb`。 + 执行以下 `su` 命令，将登录用户从 `root` 切换至 `tidb`。 ``` # su - tidb @@ -102,7 +107,9 @@ DM-Ansible 是 PingCAP 基于 [Ansible](https://docs.ansible.com/ansible/latest/ ## 第 3 步：下载 DM-Ansible 至中控机 -> **注意**：请确保使用 `tidb` 账户登陆中控机。 +> **注意：** +> +> 请确保使用 `tidb` 账户登录中控机。 1. 打开 `/home/tidb` 目录。 2. 执行以下命令下载 DM-Ansible。 @@ -115,8 +122,9 @@ DM-Ansible 是 PingCAP 基于 [Ansible](https://docs.ansible.com/ansible/latest/ ## 第 4 步：安装 DM-Ansible 及其依赖至中控机 -> **注意**： -> - 请确保使用 `tidb` 账户登陆中控机。 +> **注意：** +> +> - 请确保使用 `tidb` 账户登录中控机。 > - 您需要使用 `pip` 方式下载安装 Ansible 及其依赖，否则可能会遇到兼容性问题。 DM-Ansible 当前与 Ansible 2.5 或更高版本兼容。 1. 在中控机上安装 DM-Ansible 及其依赖包： @@ -139,7 +147,9 @@ DM-Ansible 是 PingCAP 基于 [Ansible](https://docs.ansible.com/ansible/latest/ ## 第 5 步：在中控机上配置 SSH 互信和 sudo 规则 -> **注意**：请确保使用 `tidb` 账户登陆至中控机。 +> **注意：** +> +> 请确保使用 `tidb` 账户登录至中控机。 1. 将您部署的目标机器的 IP 地址加至 `hosts.ini` 文件中的 `[servers]` 部分。 @@ -165,7 +175,9 @@ DM-Ansible 是 PingCAP 基于 [Ansible](https://docs.ansible.com/ansible/latest/ ## 第 6 步：下载 DM 及监控组件安装包至中控机 ->**注意**：请确保中控机接入互联网。 +> **注意：** +> +> 请确保中控机接入互联网。 在中控机上，运行如下命令： @@ -175,7 +187,9 @@ ansible-playbook local_prepare.yml ## 第 7 步：编辑 `inventory.ini` 配置文件 -> **注意**：请确保使用 `tidb` 账户登陆中控机。 +> **注意：** +> +> 请确保使用 `tidb` 账户登录中控机。 打开并编辑 `/home/tidb/dm-ansible/inventory.ini` 文件如下，以管控 DM 集群。 @@ -342,8 +356,9 @@ dm-worker1 ansible_host=172.16.10.72 source_id="mysql-replica-01" server_id=101 dm-worker2 ansible_host=172.16.10.73 source_id="mysql-replica-02" server_id=102 relay_binlog_name="binlog.000002" mysql_host=172.16.10.82 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 ``` -> **注意**： - 如未设定 `relay_binlog_name`，DM-worker 将从上游 MySQL 或 MariaDB 现有最早时间点的 binlog 文件开始拉取 binlog。拉取到数据同步任务需要的最新 binlog 可能需要很长时间。 +> **注意：** +> +> 如未设定 `relay_binlog_name`，DM-worker 将从上游 MySQL 或 MariaDB 现有最早时间点的 binlog 文件开始拉取 binlog。拉取到数据同步任务需要的最新 binlog 可能需要很长时间。 ### 开启 relay log GTID 同步模式 @@ -384,9 +399,11 @@ dm-worker2 ansible_host=172.16.10.73 source_id="mysql-replica-02" server_id=102 ```ini ansible_user = tidb ``` - > **注意**：请勿将 `ansible_user` 设为 `root`，因为 `tidb-ansible` 限制服务需以普通用户运行。 + > **注意：** + > + > 请勿将 `ansible_user` 设为 `root`，因为 `tidb-ansible` 限制服务需以普通用户运行。 - 运行以下命令。如果所有服务都返回 `root`，则 SSH 互信配置成功。 + 运行以下命令。如果所有服务都返回 `tidb`，则 SSH 互信配置成功。 ```bash ansible -i inventory.ini all -m shell -a 'whoami' diff --git a/op-guide/location-awareness.md b/dev/how-to/deploy/geographic-redundancy/location-awareness.md similarity index 92% rename from op-guide/location-awareness.md rename to dev/how-to/deploy/geographic-redundancy/location-awareness.md index 111d75f64ea8..a01979bf4785 100644 --- a/op-guide/location-awareness.md +++ b/dev/how-to/deploy/geographic-redundancy/location-awareness.md @@ -1,6 +1,7 @@ --- title: 集群拓扑信息配置 -category: deployment +category: how-to +aliases: ['/docs-cn/op-guide/location-awareness/'] --- # 集群拓扑信息配置 @@ -9,7 +10,7 @@ category: deployment PD 能够根据 TiKV 集群的拓扑结构进行调度，使得 TiKV 的容灾能力最大化。 -阅读本章前，请先确保阅读 [Ansible 部署方案](../op-guide/ansible-deployment.md) 和 [Docker 部署方案](../op-guide/docker-deployment.md)。 +阅读本章前，请先确保阅读 [Ansible 部署方案](/dev/how-to/deploy/orchestrated/ansible.md) 和 [Docker 部署方案](/dev/how-to/deploy/orchestrated/docker.md)。 ## TiKV 上报拓扑信息 diff --git a/op-guide/cross-dc-deployment.md b/dev/how-to/deploy/geographic-redundancy/overview.md similarity index 85% rename from op-guide/cross-dc-deployment.md rename to dev/how-to/deploy/geographic-redundancy/overview.md index 8cef95037bad..89ee4fda5c62 100644 --- a/op-guide/cross-dc-deployment.md +++ b/dev/how-to/deploy/geographic-redundancy/overview.md @@ -1,6 +1,7 @@ --- title: 跨数据中心部署方案 -category: deployment +category: how-to +aliases: ['/docs-cn/op-guide/cross-dc-deployment/'] --- # 跨数据中心部署方案 @@ -11,13 +12,13 @@ category: deployment TiDB, TiKV, PD 分别分布在 3 个不同的中心，这是最常规，可用性最高的方案。 -![三中心部署](../media/deploy-3dc.png) +![三中心部署](/media/deploy-3dc.png) ### 优点 所有数据的副本分布在三个数据中心，任何一个数据中心失效后，另外两个数据中心会自动发起 leader election，并在合理长的时间内（通常情况 20s 以内）恢复服务，并且不会产生数据丢失。 -![三中心部署容灾](../media/deploy-3dc-dr.png) +![三中心部署容灾](/media/deploy-3dc-dr.png) ### 缺点 @@ -31,13 +32,13 @@ TiDB, TiKV, PD 分别分布在 3 个不同的中心，这是最常规，可用 如果不需要每个数据中心同时对外提供服务，可以将业务流量全部派发到一个数据中心，并通过调度策略把 Region leader 和 PD leader 都迁移到同一个数据中心（我们在上文所述的测试中也做了这个优化）。这样一来，不管是从 PD 获取 TSO 还是读取 Region 都不受数据中心间网络的影响。当该数据中心失效后，PD leader 和 Region leader 会自动在其它数据中心选出，只需要把业务流量转移至其他存活的数据中心即可。 -![三中心部署读性能优化](../media/deploy-3dc-optimize.png) +![三中心部署读性能优化](/media/deploy-3dc-optimize.png) ## 两地三中心部署方案 两地三中心的方案与三数据中心类似，算是三机房方案根据业务特点进行的优化，区别是其中有两个数据中心距离很近（通常在同一个城市），网络延迟相对很小。这种场景下，我们可以把业务流量同时派发到同城的两个数据中心，同时控制 Region leader 和 PD leader 也分布在同城的两个数据中心。 -![两地三中心部署方案](../media/deploy-2city3dc.png) +![两地三中心部署方案](/media/deploy-2city3dc.png) 与三数据中心方案相比，两地三中心有以下优势： @@ -51,15 +52,17 @@ TiDB, TiKV, PD 分别分布在 3 个不同的中心，这是最常规，可用 两数据中心 + binlog 同步类似于传统的 MySQL 中 master/slave 方案。两个数据中心分别部署一套完整的 TiDB 集群，我们称之为主集群和从集群。正常情况下所有的请求都在主集群，写入的数据通过 binlog 异步同步至从集群并写入。 -![binlog 同步部署方案](../media/deploy-binlog.png) +![binlog 同步部署方案](/media/deploy-binlog.png) 当主集群整个数据中心失效后，业务可以切换至从集群，与 MySQL 类似，这种情况下会有一些数据缺失。对比 MySQL，这个方案的优势是数据中心内的 HA -- 少部分节点故障时，通过重新选举 leader 自动恢复服务，不需要人工干预。 -![两中心 binlog 相互备份方案](../media/deploy-backup.png) +![两中心 binlog 相互备份方案](/media/deploy-backup.png) 另外部分用户采用这种方式做双数据中心多活，两个数据中心各有一个集群，将业务分为两个库，每个库服务一部分数据，每个数据中心的业务只会访问一个库，两个集群之间通过 binlog 将本数据中心业务所涉及的库中的数据变更同步到对端机房，形成环状备份。 -注意：在两数据中心 + binlog 同步部署方案中，数据中心之间只有 binlog 异步复制。在数据中心间的延迟较高的情况下，从集群落后主集群的数据量会增大。当主集群故障后（DR），会造成数据丢失，丢失的数据量受网络延迟等因素影响。 +> **注意：** +> +> 在两数据中心 + binlog 同步部署方案中，数据中心之间只有 binlog 异步复制。在数据中心间的延迟较高的情况下，从集群落后主集群的数据量会增大。当主集群故障后（DR），会造成数据丢失，丢失的数据量受网络延迟等因素影响。 ## 高可用和容灾分析 diff --git a/op-guide/recommendation.md b/dev/how-to/deploy/hardware-recommendations.md similarity index 89% rename from op-guide/recommendation.md rename to dev/how-to/deploy/hardware-recommendations.md index 138dc8669af7..d96f27faf2f8 100644 --- a/op-guide/recommendation.md +++ b/dev/how-to/deploy/hardware-recommendations.md @@ -1,9 +1,10 @@ --- -title: TiDB 软件和硬件环境要求 -category: deployment +title: TiDB 软件和硬件环境建议配置 +category: how-to +aliases: ['/docs-cn/op-guide/recommendation/'] --- -# TiDB 软件和硬件环境要求 +# TiDB 软件和硬件环境建议配置 ## 概述 @@ -18,13 +19,13 @@ TiDB 作为一款开源分布式 NewSQL 数据库，可以很好的部署和运 | Oracle Enterprise Linux | 7.3 及以上 | | Ubuntu LTS | 16.04 及以上 | -> **注**： +> **注意：** > > - TiDB 只支持 Red Hat 兼容内核 (RHCK) 的 Oracle Enterprise Linux，不支持 Oracle Enterprise Linux 提供的 Unbreakable Enterprise Kernel。 > - TiDB 在 CentOS 7.3 的环境下进行过大量的测试，同时社区也有很多该操作系统部署的最佳实践，因此，建议使用 CentOS 7.3 以上的 Linux 操作系统来部署 TiDB。 > - 以上 Linux 操作系统可运行在物理服务器以及 VMware、KVM、XEN 主流虚拟化环境上。 -## 服务器要求 +## 服务器建议配置 TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器平台。对于开发，测试，及生产环境的服务器硬件配置有以下要求和建议： @@ -36,7 +37,7 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器 | PD | 4核+ | 8 GB+ | SAS, 200 GB+ | 千兆网卡 | 1（可与 TiDB 同机器） | | TiKV | 8核+ | 32 GB+ | SSD, 200 GB+ | 千兆网卡 | 3 | -> **注**： +> **注意：** > > - 验证测试环境中的 TiDB 和 PD 可以部署在同一台服务器上。 > - 如进行性能相关的测试，避免采用低性能存储和网络硬件配置，防止对测试结果的正确性产生干扰。 @@ -52,7 +53,7 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器 | TiKV | 16核+ | 32 GB+ | SSD | 万兆网卡（2块最佳） | 3 | | 监控 | 8核+ | 16 GB+ | SAS | 千兆网卡 | 1 | -> **注**： +> **注意：** > > - 生产环境中的 TiDB 和 PD 可以部署和运行在同服务器上，如对性能和可靠性有更高的要求，应尽可能分开部署。 > - 生产环境强烈推荐使用更高的配置。 @@ -81,4 +82,4 @@ TiDB 作为开源分布式 NewSQL 数据库，其正常运行需要网络环境 ## 客户端 Web 浏览器要求 -TiDB 提供了基于 Prometheus 和 Grafana 技术平台作为 TiDB 分布式数据库集群的可视化监控数据展现方案。建议用户采用高版本的微软 IE，Google Chrome，Mozilla Firefox 访问 Grafana 监控入口。 +TiDB 提供了基于 [Grafana](https://grafana.com/) 的技术平台，对数据库集群的各项指标进行可视化展现。采用支持 Javascript 的微软 IE、Google Chrome、Mozilla Firefox 的较新版本即可访问监控入口。 diff --git a/op-guide/ansible-deployment.md b/dev/how-to/deploy/orchestrated/ansible.md similarity index 89% rename from op-guide/ansible-deployment.md rename to dev/how-to/deploy/orchestrated/ansible.md index 55cedffcfe04..2c77462d099b 100644 --- a/op-guide/ansible-deployment.md +++ b/dev/how-to/deploy/orchestrated/ansible.md @@ -1,6 +1,7 @@ --- title: TiDB-Ansible 部署方案 -category: deployment +category: how-to +aliases: ['/docs-cn/op-guide/ansible-deployment/'] --- # TiDB-Ansible 部署方案 @@ -13,28 +14,32 @@ Ansible 是一款自动化运维工具，[TiDB-Ansible](https://github.com/pingc - 初始化操作系统参数 - 部署 TiDB 集群（包括 PD、TiDB、TiKV 等组件和监控组件） -- [启动集群](../op-guide/ansible-operation.md#启动集群) -- [关闭集群](../op-guide/ansible-operation.md#关闭集群) -- [变更组件配置](../op-guide/ansible-deployment-rolling-update.md#变更组件配置) -- [集群扩容缩容](../op-guide/ansible-deployment-scale.md) -- [升级组件版本](../op-guide/ansible-deployment-rolling-update.md#升级组件版本) -- [集群开启 binlog](../tools/tidb-binlog-cluster.md) -- [清除集群数据](../op-guide/ansible-operation.md#清除集群数据) -- [销毁集群](../op-guide/ansible-operation.md#销毁集群) - -> **注**：对于生产环境，须使用 TiDB-Ansible 部署 TiDB 集群。如果只是用于测试 TiDB 或体验 TiDB 的特性，建议[使用 Docker Compose 在单机上快速部署 TiDB 集群](../op-guide/docker-compose.md)。 +- [启动集群](/op-guide/ansible-operation.md#启动集群) +- [关闭集群](/op-guide/ansible-operation.md#关闭集群) +- [变更组件配置](/op-guide/ansible-deployment-rolling-update.md#变更组件配置) +- [集群扩容缩容](/op-guide/ansible-deployment-scale.md) +- [升级组件版本](/op-guide/ansible-deployment-rolling-update.md#升级组件版本) +- [集群开启 binlog](/tools/tidb-binlog-cluster.md) +- [清除集群数据](/op-guide/ansible-operation.md#清除集群数据) +- [销毁集群](/op-guide/ansible-operation.md#销毁集群) + +> **注意：** +> +> 对于生产环境，须使用 TiDB-Ansible 部署 TiDB 集群。如果只是用于测试 TiDB 或体验 TiDB 的特性，建议[使用 Docker Compose 在单机上快速部署 TiDB 集群](/dev/how-to/get-started/local-cluster/install-from-docker-compose.md)。 ## 准备机器 -1. 部署目标机器若干 +1. 部署目标机器若干 - - 建议 4 台及以上，TiKV 至少 3 实例，且与 TiDB、PD 模块不位于同一主机，详见[部署建议](../op-guide/recommendation.md)。 + - 建议 4 台及以上，TiKV 至少 3 实例，且与 TiDB、PD 模块不位于同一主机，详见[部署建议](/dev/how-to/deploy/hardware-recommendations.md)。 - 推荐安装 CentOS 7.3 及以上版本 Linux 操作系统，x86_64 架构 (amd64)。 - 机器之间内网互通。 - > **注：使用 Ansible 方式部署时，TiKV 及 PD 节点数据目录所在磁盘请使用 SSD 磁盘，否则无法通过检测。** 如果仅验证功能，建议使用 [Docker Compose 部署方案](../op-guide/docker-compose.md)单机进行测试。 + > **注意：** + > + > 使用 Ansible 方式部署时，TiKV 及 PD 节点数据目录所在磁盘请使用 SSD 磁盘，否则无法通过检测。** 如果仅验证功能，建议使用 [Docker Compose 部署方案](/dev/how-to/get-started/local-cluster/install-from-docker-compose.md)单机进行测试。 -2. 部署中控机一台: +2. 部署中控机一台: - 中控机可以是部署目标机器中的某一台。 - 推荐安装 CentOS 7.3 及以上版本 Linux 操作系统（默认包含 Python 2.7）。 @@ -126,7 +131,9 @@ The key's randomart image is: 使用以下命令从 Github [TiDB-Ansible 项目](https://github.com/pingcap/tidb-ansible)上下载 TiDB-Ansible [相应版本](https://github.com/pingcap/tidb-ansible/tags)，默认的文件夹名称为 `tidb-ansible`。 -> **注意**：部署和升级 TiDB 集群需使用对应的 tidb-ansible 版本，通过改 `inventory.ini` 文件中的版本来混用可能会产生一些错误。 +> **注意：** +> +> 部署和升级 TiDB 集群需使用对应的 tidb-ansible 版本，通过改 `inventory.ini` 文件中的版本来混用可能会产生一些错误。 - 下载指定 tag 的 tidb-ansible： @@ -140,7 +147,9 @@ The key's randomart image is: $ git clone https://github.com/pingcap/tidb-ansible.git ``` -> **注**：请务必按文档操作，将 `tidb-ansible` 下载到 `/home/tidb` 目录下，权限为 `tidb` 用户，不要下载到 `/root` 下，否则会遇到权限问题。 +> **注意：** +> +> 请务必按文档操作，将 `tidb-ansible` 下载到 `/home/tidb` 目录下，权限为 `tidb` 用户，不要下载到 `/root` 下，否则会遇到权限问题。 ## 在中控机器上安装 Ansible 及其依赖 @@ -308,8 +317,9 @@ UUID=c51eb23b-195c-4061-92a9-3fad812cc12f /data1 ext4 defaults,nodelalloc,noatim 以 `tidb` 用户登录中控机，`inventory.ini` 文件路径为 `/home/tidb/tidb-ansible/inventory.ini`。 -> **注：** 请使用内网 IP 来部署集群，如果部署目标机器 SSH 端口非默认 22 端口，需添加 `ansible_port` 变量，如： -> `TiDB1 ansible_host=172.16.10.1 ansible_port=5555` +> **注意：** +> +> 请使用内网 IP 来部署集群，如果部署目标机器 SSH 端口非默认 22 端口，需添加 `ansible_port` 变量，如 `TiDB1 ansible_host=172.16.10.1 ansible_port=5555`。 标准 TiDB 集群需要 6 台机器: @@ -317,7 +327,7 @@ UUID=c51eb23b-195c-4061-92a9-3fad812cc12f /data1 ext4 defaults,nodelalloc,noatim - 3 个 PD 节点 - 3 个 TiKV 节点，第一台 TiDB 机器同时用作监控机 -默认情况下，单台机器上只需部署一个 TiKV 实例。如果你的 TiKV 部署机器 CPU 及内存配置是[部署建议](../op-guide/recommendation.md)的两倍或以上，并且拥有两块 SSD 硬盘或单块容量超 2T 的 SSD 硬盘，可以考虑部署两实例，但不建议部署两个以上实例。 +默认情况下，单台机器上只需部署一个 TiKV 实例。如果你的 TiKV 部署机器 CPU 及内存配置是[部署建议](/dev/how-to/deploy/hardware-recommendations.md)的两倍或以上，并且拥有两块 SSD 硬盘或单块容量超 2T 的 SSD 硬盘，可以考虑部署两实例，但不建议部署两个以上实例。 ### 单机单 TiKV 实例集群拓扑 @@ -391,7 +401,7 @@ TiKV2-2 ansible_host=172.16.10.5 deploy_dir=/data2/deploy tikv_port=20172 labels TiKV3-1 ansible_host=172.16.10.6 deploy_dir=/data1/deploy tikv_port=20171 labels="host=tikv3" TiKV3-2 ansible_host=172.16.10.6 deploy_dir=/data2/deploy tikv_port=20172 labels="host=tikv3" -# 使用 master 分支的 tidb-ansible 部署集群，并且 group_vars/all.yml 中的 tikv_metric_method 设置为 pull，多实例场景时需要额外配置 status 端口，示例如下： +# 部署 3.0 版本的 TiDB 集群时，多实例场景需要额外配置 status 端口，示例如下： # TiKV1-1 ansible_host=172.16.10.4 deploy_dir=/data1/deploy tikv_port=20171 tikv_status_port=20181 labels="host=tikv1" # TiKV1-2 ansible_host=172.16.10.4 deploy_dir=/data2/deploy tikv_port=20172 tikv_status_port=20182 labels="host=tikv1" # TiKV2-1 ansible_host=172.16.10.5 deploy_dir=/data1/deploy tikv_port=20171 tikv_status_port=20181 labels="host=tikv2" @@ -462,15 +472,17 @@ TiKV1-1 ansible_host=172.16.10.4 deploy_dir=/data1/deploy #### 其他变量调整 -> **注：** 以下控制变量开启请使用首字母大写 `True`，关闭请使用首字母大写 `False`。 +> **注意：** +> +> 以下控制变量开启请使用首字母大写 `True`，关闭请使用首字母大写 `False`。 | 变量 | 含义 | | --------------- | ---------------------------------------------------------- | | cluster_name | 集群名称，可调整 | | tidb_version | TiDB 版本，TiDB-Ansible 各分支默认已配置 | | process_supervision | 进程监管方式，默认为 systemd，可选 supervise | -| timezone | 新安装 TiDB 集群第一次启动 bootstrap（初始化）时，将 TiDB 全局默认时区设置为该值。TiDB 使用的时区后续可通过 `time_zone` 全局变量和 session 变量来修改，参考[时区支持](../sql/time-zone.md)。 默认为 `Asia/Shanghai`，可选值参考[ timzone 列表](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)。 | -| enable_firewalld | 开启防火墙，默认不开启，如需开启，请将[部署建议-网络要求](recommendation.md#网络要求) 中的端口加入白名单 | +| timezone | 新安装 TiDB 集群第一次启动 bootstrap（初始化）时，将 TiDB 全局默认时区设置为该值。TiDB 使用的时区后续可通过 `time_zone` 全局变量和 session 变量来修改，参考[时区支持](../sql/time-zone.md)。 默认为 `Asia/Shanghai`，可选值参考 [timzone 列表](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)。 | +| enable_firewalld | 开启防火墙，默认不开启，如需开启，请将[部署建议-网络要求](/dev/how-to/deploy/hardware-recommendations.md#网络要求) 中的端口加入白名单 | | enable_ntpd | 检测部署目标机器 NTP 服务，默认为 True，请勿关闭 | | set_hostname | 根据 IP 修改部署目标机器主机名，默认为 False | | enable_binlog | 是否部署 pump 并开启 binlog，默认为 False，依赖 Kafka 集群，参见 `zookeeper_addrs` 变量 | @@ -527,7 +539,9 @@ TiKV1-1 ansible_host=172.16.10.4 deploy_dir=/data1/deploy ansible-playbook deploy.yml ``` - >**注**：Grafana Dashboard 上的 Report 按钮可用来生成 PDF 文件，此功能依赖 `fontconfig` 包和英文字体。如需使用该功能，登录 **grafana_servers** 机器，用以下命令安装： + > **注意：** + > + > Grafana Dashboard 上的 Report 按钮可用来生成 PDF 文件，此功能依赖 `fontconfig` 包和英文字体。如需使用该功能，登录 **grafana_servers** 机器，用以下命令安装： > > ``` > $ sudo yum install fontconfig open-sans-fonts @@ -617,7 +631,9 @@ synchronised to NTP server (85.199.214.101) at stratum 2 polling server every 1024 s ``` -> **注：** Ubuntu 系统需安装 ntpstat 软件包。 +> **注意：** +> +> Ubuntu 系统需安装 ntpstat 软件包。 以下情况表示 NTP 服务未正常同步： diff --git a/op-guide/docker-deployment.md b/dev/how-to/deploy/orchestrated/docker.md similarity index 96% rename from op-guide/docker-deployment.md rename to dev/how-to/deploy/orchestrated/docker.md index 86a429f3d7cf..a80fc147a945 100644 --- a/op-guide/docker-deployment.md +++ b/dev/how-to/deploy/orchestrated/docker.md @@ -1,13 +1,16 @@ --- title: TiDB Docker 部署方案 -category: deployment +category: how-to +aliases: ['/docs-cn/op-guide/docker-deployment/'] --- # TiDB Docker 部署方案 本文介绍如何使用 Docker 部署一个多节点的 TiDB 集群。 -> **注**：对于生产环境，不要使用 Docker 进行部署，而应[使用 Ansible 部署 TiDB 集群](../op-guide/ansible-deployment.md)。 +> **注意：** +> +> 对于生产环境，不要使用 Docker 进行部署，而应[使用 Ansible 部署 TiDB 集群](/dev/how-to/deploy/orchestrated/ansible.md)。 ## 环境准备 diff --git a/op-guide/offline-ansible-deployment.md b/dev/how-to/deploy/orchestrated/offline-ansible.md similarity index 77% rename from op-guide/offline-ansible-deployment.md rename to dev/how-to/deploy/orchestrated/offline-ansible.md index df834504d7ca..1f79b3c87bed 100644 --- a/op-guide/offline-ansible-deployment.md +++ b/dev/how-to/deploy/orchestrated/offline-ansible.md @@ -1,6 +1,7 @@ --- title: 离线 TiDB-Ansible 部署方案 -category: deployment +category: how-to +aliases: ['/docs-cn/op-guide/offline-ansible-deployment/'] --- # 离线 TiDB-Ansible 部署方案 @@ -14,7 +15,7 @@ category: deployment 2. 部署目标机器若干及部署中控机一台 - - 系统要求及配置参考[准备机器](../op-guide/ansible-deployment.md#准备机器)。 + - 系统要求及配置参考[准备机器](/dev/how-to/deploy/orchestrated/ansible.md#准备机器)。 - 可以无法访问外网。 ## 在中控机上安装系统依赖包 @@ -39,7 +40,7 @@ category: deployment ## 在中控机上创建 tidb 用户，并生成 ssh key -参考[在中控机上创建 tidb 用户，并生成 ssh key](../op-guide/ansible-deployment.md#在中控机上创建-tidb-用户-并生成-ssh-key) 即可。 +参考[在中控机上创建 tidb 用户，并生成 ssh key](/dev/how-to/deploy/orchestrated/ansible.md#在中控机上创建-tidb-用户-并生成-ssh-key) 即可。 ## 在中控机器上离线安装 Ansible 及其依赖 @@ -91,7 +92,9 @@ category: deployment 使用以下命令从 Github [TiDB-Ansible 项目](https://github.com/pingcap/tidb-ansible)上下载 TiDB-Ansible 相应版本，默认的文件夹名称为 `tidb-ansible`。 - > **注意**：部署和升级 TiDB 集群需使用对应的 tidb-ansible 版本，通过改 `inventory.ini` 文件中的版本来混用可能会产生一些错误。 + > **注意：** + > + > 部署和升级 TiDB 集群需使用对应的 tidb-ansible 版本，通过改 `inventory.ini` 文件中的版本来混用可能会产生一些错误。 - 下载指定 tag 的 tidb-ansible： @@ -116,25 +119,25 @@ category: deployment ## 在中控机上配置部署机器 ssh 互信及 sudo 规则 -参考[在中控机上配置部署机器 ssh 互信及 sudo 规则](../op-guide/ansible-deployment.md#在中控机上配置部署机器-ssh-互信及-sudo-规则)即可。 +参考[在中控机上配置部署机器 ssh 互信及 sudo 规则](/dev/how-to/deploy/orchestrated/ansible.md#在中控机上配置部署机器-ssh-互信及-sudo-规则)即可。 ## 在部署目标机器上安装 NTP 服务 -> 如果你的部署目标机器时间、时区设置一致，已开启 NTP 服务且在正常同步时间，此步骤可忽略，可参考[如何检测 NTP 服务是否正常](../op-guide/ansible-deployment.md#如何检测-ntp-服务是否正常)。 +> 如果你的部署目标机器时间、时区设置一致，已开启 NTP 服务且在正常同步时间，此步骤可忽略，可参考[如何检测 NTP 服务是否正常](/dev/how-to/deploy/orchestrated/ansible.md#如何检测-ntp-服务是否正常)。 参考[在部署目标机器上安装 NTP 服务](../op-guide/ansible-deployment.md#在部署目标机器上安装-ntp-服务)即可。 ## 在部署目标机器上配置 CPUfreq 调节器模式 -参考[在部署目标机器上配置 CPUfreq 调节器模式](../op-guide/ansible-deployment.md#在部署目标机器上配置-cpufreq-调节器模式)即可。 +参考[在部署目标机器上配置 CPUfreq 调节器模式](/dev/how-to/deploy/orchestrated/ansible.md#在部署目标机器上配置-cpufreq-调节器模式)即可。 ## 在部署目标机器上添加数据盘 ext4 文件系统挂载参数 -参考[在部署目标机器上添加数据盘 ext4 文件系统挂载参数](../op-guide/ansible-deployment.md#在部署目标机器上添加数据盘-ext4-文件系统挂载参数)即可。 +参考[在部署目标机器上添加数据盘 ext4 文件系统挂载参数](/dev/how-to/deploy/orchestrated/ansible.md#在部署目标机器上添加数据盘-ext4-文件系统挂载参数)即可。 ## 分配机器资源，编辑 inventory.ini 文件 -参考[分配机器资源，编辑 inventory.ini 文件](../op-guide/ansible-deployment.md#分配机器资源-编辑-inventory-ini-文件)即可。 +参考[分配机器资源，编辑 inventory.ini 文件](/dev/how-to/deploy/orchestrated/ansible.md#分配机器资源-编辑-inventory-ini-文件)即可。 ## 部署任务 @@ -149,8 +152,8 @@ category: deployment $ ./install_grafana_font_rpms.sh ``` -3. 参考[部署任务](../op-guide/ansible-deployment.md#部署任务)即可。 +3. 参考[部署任务](/dev/how-to/deploy/orchestrated/ansible.md#部署任务)即可。 ## 测试集群 -参考[测试集群](../op-guide/ansible-deployment.md#测试集群)即可。 +参考[测试集群](/dev/how-to/deploy/orchestrated/ansible.md#测试集群)即可。 diff --git a/tispark/tispark-quick-start-guide.md b/dev/how-to/deploy/tispark.md similarity index 88% rename from tispark/tispark-quick-start-guide.md rename to dev/how-to/deploy/tispark.md index b8479b55e490..11a5303e9918 100644 --- a/tispark/tispark-quick-start-guide.md +++ b/dev/how-to/deploy/tispark.md @@ -1,22 +1,18 @@ --- title: TiSpark 快速入门指南 -category: tispark +category: how-to +aliases: ['/docs-cn/tispark/tispark-quick-start-guide/'] --- # TiSpark 快速入门指南 -为了让大家快速体验 [TiSpark](../tispark/tispark-user-guide.md)，通过 TiDB-Ansible 安装的 TiDB 集群中默认已集成 Spark、TiSpark jar 包及 TiSpark sample data。 +为了让大家快速体验 [TiSpark](/tispark/tispark-user-guide.md)，通过 TiDB-Ansible 安装的 TiDB 集群中默认已集成 Spark、TiSpark jar 包及 TiSpark sample data。 ## 部署信息 -- Spark 默认部署在 TiDB 实例部署目录下 spark 目录中 -- TiSpark jar 包默认部署在 Spark 部署目录 jars 文件夹下： - - spark/jars/tispark-SNAPSHOT-jar-with-dependencies.jar - -- TiSpark sample data 及导入脚本默认部署在 TiDB-Ansible 目录下： - - tidb-ansible/resources/bin/tispark-sample-data +- Spark 默认部署在 TiDB 实例部署目录下 spark 目录中 +- TiSpark jar 包默认部署在 Spark 部署目录 jars 文件夹下：`spark/jars/tispark-SNAPSHOT-jar-with-dependencies.jar` +- TiSpark sample data 及导入脚本默认部署在 TiDB-Ansible 目录下：`tidb-ansible/resources/bin/tispark-sample-data` ## 环境准备 diff --git a/try-tidb.md b/dev/how-to/get-started/explore-sql.md similarity index 94% rename from try-tidb.md rename to dev/how-to/get-started/explore-sql.md index eb2ff4f80282..94379314c2bc 100644 --- a/try-tidb.md +++ b/dev/how-to/get-started/explore-sql.md @@ -1,11 +1,12 @@ --- -title: TiDB 基本操作 -category: user guide +title: TiDB 中的基本 SQL 操作 +category: how-to +aliases: ['/docs-cn/try-tidb/'] --- -# TiDB 基本操作 +# TiDB 中的基本 SQL 操作 -成功部署 TiDB 集群之后，便可以在 TiDB 中执行 SQL 语句了。因为 TiDB 兼容 MySQL，你可以使用 MySQL 客户端连接 TiDB，并且[大多数情况下](sql/mysql-compatibility.md)可以直接执行 MySQL 语句。 +成功部署 TiDB 集群之后，便可以在 TiDB 中执行 SQL 语句了。因为 TiDB 兼容 MySQL，你可以使用 MySQL 客户端连接 TiDB，并且[大多数情况下](/sql/mysql-compatibility.md)可以直接执行 MySQL 语句。 本文介绍 CRUD 操作等基本的 SQL 语句。完整的 SQL 语句列表，参见 [TiDB SQL 语法详解](https://pingcap.github.io/sqlgram/)。 diff --git a/op-guide/docker-compose.md b/dev/how-to/get-started/local-cluster/install-from-docker-compose.md similarity index 92% rename from op-guide/docker-compose.md rename to dev/how-to/get-started/local-cluster/install-from-docker-compose.md index 901f063cb8ac..7c564d30ab00 100644 --- a/op-guide/docker-compose.md +++ b/dev/how-to/get-started/local-cluster/install-from-docker-compose.md @@ -1,13 +1,16 @@ --- -title: 使用 Docker Compose 快速构建集群 -category: deployment +title: 使用 Docker Compose 快速构建 TiDB 集群 +category: how-to +aliases: ['/docs-cn/op-guide/docker-compose/'] --- -# 使用 Docker Compose 快速构建集群 +# 使用 Docker Compose 快速构建 TiDB 集群 本文档介绍如何在单机上通过 Docker Compose 快速一键部署一套 TiDB 测试集群。[Docker Compose](https://docs.docker.com/compose/overview) 可以通过一个 YAML 文件定义多个容器的应用服务，然后一键启动或停止。 -> **注**：对于生产环境，不要使用 Docker Compose 进行部署，而应[使用 Ansible 部署 TiDB 集群](../op-guide/ansible-deployment.md)。 +> **注意：** +> +> 对于生产环境，不要使用 Docker Compose 进行部署，而应[使用 Ansible 部署 TiDB 集群](/op-guide/ansible-deployment.md)。 ## 准备环境 @@ -158,4 +161,4 @@ docker-compose exec tispark-master /opt/spark/bin/pyspark docker-compose exec tispark-master /opt/spark/bin/sparkR ``` -更多关于 TiSpark 的信息，参见 [TiSpark 的详细文档](../tispark/tispark-quick-start-guide.md)。 +更多关于 TiSpark 的信息，参见 [TiSpark 的详细文档](/tispark/tispark-quick-start-guide.md)。 diff --git a/op-guide/history-read.md b/dev/how-to/get-started/read-historical-data.md similarity index 84% rename from op-guide/history-read.md rename to dev/how-to/get-started/read-historical-data.md index 4ce53baa8d0c..78ec0fe8f936 100644 --- a/op-guide/history-read.md +++ b/dev/how-to/get-started/read-historical-data.md @@ -1,11 +1,12 @@ --- -title: TiDB 历史数据回溯 -category: advanced +title: 读取历史数据 +category: how-to +aliases: ['/docs-cn/op-guide/history-read/'] --- -# TiDB 历史数据回溯 +# 读取历史数据 -本文档用于描述 TiDB 如何读取历史版本数据，包括具体的操作流程以及历史数据的保存策略。 +本文档介绍 TiDB 如何读取历史版本数据，包括具体的操作流程以及历史数据的保存策略。 ## 功能说明 @@ -19,7 +20,9 @@ TiDB 实现了通过标准 SQL 接口读取历史数据功能，无需特殊的 “2016-10-08 16:45:26.999”，一般来说可以只写到秒，比如”2016-10-08 16:45:26”。 当这个变量被设置时，TiDB 会用这个时间戳建立 Snapshot（没有开销，只是创建数据结构），随后所有的 Select 操作都会在这个 Snapshot 上读取数据。 -> **注意**：TiDB 的事务是通过 PD 进行全局授时，所以存储的数据版本也是以 PD 所授时间戳作为版本号。在生成 Snapshot 时，是以 tidb_snapshot 变量的值作为版本号，如果 TiDB Server 所在机器和 PD Server 所在机器的本地时间相差较大，需要以 PD 的时间为准。 +> **注意：** +> +> TiDB 的事务是通过 PD 进行全局授时，所以存储的数据版本也是以 PD 所授时间戳作为版本号。在生成 Snapshot 时，是以 tidb_snapshot 变量的值作为版本号，如果 TiDB Server 所在机器和 PD Server 所在机器的本地时间相差较大，需要以 PD 的时间为准。 当读取历史版本操作结束后，可以结束当前 Session 或者是通过 Set 语句将 tidb_snapshot 变量的值设为 ""，即可读取最新版本的数据。 @@ -27,7 +30,7 @@ TiDB 实现了通过标准 SQL 接口读取历史数据功能，无需特殊的 TiDB 使用 MVCC 管理版本，当更新/删除数据时，不会做真正的数据删除，只会添加一个新版本数据，所以可以保留历史数据。历史数据不会全部保留，超过一定时间的历史数据会被彻底删除，以减小空间占用以及避免历史版本过多引入的性能开销。 -TiDB 使用周期性运行的 GC（Garbage Collection，垃圾回收）来进行清理，关于 GC 的详细介绍参见 [TiDB 垃圾回收 (GC)](../op-guide/gc.md)。 +TiDB 使用周期性运行的 GC（Garbage Collection，垃圾回收）来进行清理，关于 GC 的详细介绍参见 [TiDB 垃圾回收 (GC)](/op-guide/gc.md)。 这里需要重点关注的是 `tikv_gc_life_time` 和 `tikv_gc_safe_point` 这条。`tikv_gc_life_time` 用于配置历史版本保留时间，可以手动修改；`tikv_gc_safe_point` 记录了当前的 safePoint，用户可以安全地使用大于 safePoint 的时间戳创建 snapshot 读取历史版本。safePoint 在每次 GC 开始运行时自动更新。 @@ -97,8 +100,8 @@ TiDB 使用周期性运行的 GC（Garbage Collection，垃圾回收）来进行 Query OK, 0 rows affected (0.00 sec) ``` - > **注意**： - > + > **注意：** + > > - 这里的时间设置的是 update 语句之前的那个时间。 > - 在 `tidb_snapshot` 前须使用 `@@` 而非 `@`，因为 `@@` 表示系统变量，`@` 表示用户变量。 @@ -135,4 +138,6 @@ TiDB 使用周期性运行的 GC（Garbage Collection，垃圾回收）来进行 3 rows in set (0.00 sec) ``` - > **注意**：在 `tidb_snapshot` 前须使用 `@@` 而非 `@`，因为 `@@` 表示系统变量，`@` 表示用户变量。 \ No newline at end of file + > **注意：** + > + > 在 `tidb_snapshot` 前须使用 `@@` 而非 `@`，因为 `@@` 表示系统变量，`@` 表示用户变量。 \ No newline at end of file diff --git a/op-guide/monitor.md b/dev/how-to/monitor/monitor-a-cluster.md similarity index 97% rename from op-guide/monitor.md rename to dev/how-to/monitor/monitor-a-cluster.md index 29ecc07d918f..58917b4bad40 100644 --- a/op-guide/monitor.md +++ b/dev/how-to/monitor/monitor-a-cluster.md @@ -1,6 +1,7 @@ --- title: TiDB 集群监控 -category: monitoring +category: how-to +aliases: ['/docs-cn/op-guide/monitor/'] --- # TiDB 集群监控 @@ -36,7 +37,7 @@ curl http://127.0.0.1:10080/status PD API 地址：`http://${host}:${port}/pd/api/v1/${api_name}`。 -其中 port 默认为 2379，各类 api_name 详细信息参见 [PD API Doc](https://cdn.rawgit.com/pingcap/docs/master/op-guide/pd-api-v1.html)。 +其中 port 默认为 2379，各类 api_name 详细信息参见 [PD API Doc](https://download.pingcap.com/pd-api-v1.html)。 通过这个接口可以获取当前所有 TiKV 的状态以及负载均衡信息。其中最重要也是最常用的接口获取 TiKV 集群所有节点状态的接口，下面以一个单个 TiKV 构成的集群为例，说明一些用户需要了解的信息： @@ -121,11 +122,11 @@ curl http://127.0.0.1:2379/pd/api/v1/stores #### TiDB/PD/TiKV 配置 -+ TiDB ++ TiDB 设置 \-\-metrics-addr 和 \-\-metrics-interval 两个参数，其中 metrics-addr 设为 Push Gateway 的地址，metrics-interval 为 push 的频率，单位为秒，默认值为 15 -+ PD ++ PD 修改 toml 配置文件，填写 Push Gateway 的地址和推送频率 diff --git a/op-guide/monitor-overview.md b/dev/how-to/monitor/overview.md similarity index 83% rename from op-guide/monitor-overview.md rename to dev/how-to/monitor/overview.md index f719103662bf..338fa5d97862 100644 --- a/op-guide/monitor-overview.md +++ b/dev/how-to/monitor/overview.md @@ -1,6 +1,7 @@ --- title: TiDB 监控框架概述 -category: monitoring +category: how-to +aliases: ['/docs-cn/op-guide/monitor-overview/'] --- # TiDB 监控框架概述 @@ -11,8 +12,8 @@ Prometheus 是一个拥有多维度数据模型，灵活的查询语句的时序 Prometheus 提供了多个组件供用户使用。目前，我们使用 Prometheus Server，来收集和存储时间序列数据。Client 代码库，在程序中定制需要的 Metric 。Push GateWay 来接收 Client Push 上来的数据，统一供 Prometheus 主服务器抓取。以及 AlertManager 来实现报警机制。其结构如下图： -![Prometheus in TiDB](../media/prometheus-in-tidb.png) +![Prometheus in TiDB](/media/prometheus-in-tidb.png) Grafana 是一个开源的 metric 分析及可视化系统。我们使用 Grafana 来展示 TiDB 的各项性能指标 。如下图所示: -![Grafana Screeshot](../media/grafana-screenshot.png) \ No newline at end of file +![Grafana Screeshot](/media/grafana-screenshot.png) \ No newline at end of file diff --git a/op-guide/security.md b/dev/how-to/secure/enable-tls-between-components.md similarity index 83% rename from op-guide/security.md rename to dev/how-to/secure/enable-tls-between-components.md index a46dfd421567..568d1d3c0efb 100644 --- a/op-guide/security.md +++ b/dev/how-to/secure/enable-tls-between-components.md @@ -1,9 +1,10 @@ --- -title: 开启 TLS 验证和数据加密存储 -category: deployment +title: 为 TiDB 组件间开启 TLS 和数据加密存储 +category: how-to +aliases: ['/docs-cn/op-guide/security/'] --- -# 开启 TLS 验证和数据加密存储 +# 为 TiDB 组件间开启 TLS 和数据加密存储 本文档介绍 TiDB 集群如何开启 TLS 验证和数据加密存储。 @@ -24,7 +25,7 @@ MySQL Client 与 TiDB 之间使用一套证书，TiDB 集群组件之间使用 有多种工具可以生成自签名证书，如 `openssl`，`easy-rsa `，`cfssl`。 - 这里提供一个使用 `cfssl` 生成证书的示例：[生成自签名证书](../op-guide/generate-self-signed-certificates.md)。 + 这里提供一个使用 `cfssl` 生成证书的示例：[生成自签名证书](/dev/how-to/secure/generate-self-signed-certificates.md)。 2. 配置证书。 @@ -70,7 +71,9 @@ MySQL Client 与 TiDB 之间使用一套证书，TiDB 集群组件之间使用 此时 TiDB 集群各个组件间已开启双向验证。 -> **注意**：若 TiDB 集群各个组件间已开启 TLS，在使用 tikv-ctl 或 pd-ctl 工具连接集群时，需要指定 client 证书，示例： +> **注意：** +> +> 若 TiDB 集群各个组件间已开启 TLS，在使用 tikv-ctl 或 pd-ctl 工具连接集群时，需要指定 client 证书，示例： ```bash ./pd-ctl -u https://127.0.0.1:2379 --cacert /path/to/ca.pem --cert /path/to/client.pem --key /path/to/client-key.pem @@ -80,7 +83,7 @@ MySQL Client 与 TiDB 之间使用一套证书，TiDB 集群组件之间使用 ### MySQL 与 TiDB 间开启 TLS -请参考 [使用加密连接](../sql/encrypted-connections.md)。 +请参考 [使用加密连接](/dev/how-to/secure/enable-tls-clients.md)。 ## 开启数据加密存储 @@ -96,7 +99,9 @@ MySQL Client 与 TiDB 之间使用一套证书，TiDB 集群组件之间使用 ./tikv-ctl random-hex --len 256 > cipher-file-256 ``` - > **注意**：TiKV 只接受 hex 格式的 token 文件，文件的长度必须是 2^n，并且小于等于 1024。 + > **注意：** + > + > TiKV 只接受 hex 格式的 token 文件，文件的长度必须是 2^n，并且小于等于 1024。 2. 配置 TiKV。 @@ -106,7 +111,9 @@ MySQL Client 与 TiDB 之间使用一套证书，TiDB 集群组件之间使用 cipher-file = "/path/to/cipher-file-256" ``` -> **注意**：若使用 [Lightning](../tools/lightning/overview-architecture.md) 向集群导入数据，如果目标集群开启了加密功能，Lightning 生成的 sst 文件也必须是加密的格式。 +> **注意：** +> +> 若使用 [Lightning](/tools/lightning/overview-architecture.md) 向集群导入数据，如果目标集群开启了加密功能，Lightning 生成的 sst 文件也必须是加密的格式。 ### 使用限制 diff --git a/sql/encrypted-connections.md b/dev/how-to/secure/enable-tls-clients.md similarity index 92% rename from sql/encrypted-connections.md rename to dev/how-to/secure/enable-tls-clients.md index 63824b0c2f1b..5e847c6f4741 100644 --- a/sql/encrypted-connections.md +++ b/dev/how-to/secure/enable-tls-clients.md @@ -1,6 +1,7 @@ --- title: 使用加密连接 -category: user guide +category: how-to +aliases: ['/docs-cn/sql/encrypted-connections/'] --- # 使用加密连接 @@ -26,9 +27,9 @@ TiDB 的加密连接支持默认是关闭的，必须在 TiDB 服务端通过配 在启动 TiDB 时，至少需要在配置文件中同时指定 `ssl-cert` 和 `ssl-key` 参数，才能使 TiDB 服务端接受加密连接。还可以指定 `ssl-ca` 参数进行客户端身份验证（请参见[配置启用身份验证](#配置启用身份验证)章节）。 -- [`ssl-cert`](../sql/server-command-option.md#ssl-cert)：指定 SSL 证书文件路径 -- [`ssl-key`](../sql/server-command-option.md#ssl-key)：指定证书文件对应的私钥 -- [`ssl-ca`](../sql/server-command-option.md#ssl-ca)：可选，指定受信任的 CA 证书文件路径 +- [`ssl-cert`](/sql/server-command-option.md#ssl-cert)：指定 SSL 证书文件路径 +- [`ssl-key`](/sql/server-command-option.md#ssl-key)：指定证书文件对应的私钥 +- [`ssl-ca`](/sql/server-command-option.md#ssl-ca)：可选，指定受信任的 CA 证书文件路径 参数指定的文件都为 PEM 格式。另外目前 TiDB 尚不支持加载有密码保护的私钥，因此必须提供一个没有密码的私钥文件。若提供的证书或私钥无效，则 TiDB 服务端将照常启动，但并不支持客户端加密连接到 TiDB 服务端。 @@ -82,7 +83,9 @@ MySQL 5.7 及以上版本自带的客户端默认尝试使用安全连接，若 - 若要使 TiDB 服务端验证 MySQL 客户端身份，TiDB 服务端需配置 `ssl-cert`、`ssl-key`、`ssl-ca` 参数，客户端需至少指定 `--ssl-cert`、`--ssl-key` 参数。必须确保服务端配置的证书和客户端配置的证书都是由服务端配置指定的 `ssl-ca` 签发的。 - 若要进行双向身份验证，请同时满足上述要求。 -注：目前 TiDB 尚不支持强制验证客户端身份，即服务端对客户端的身份验证是可选的。若客户端在 TLS 握手时未出示自己的身份证书，也能正常建立 TLS 连接。 +> **注意：** +> +> 目前 TiDB 尚不支持强制验证客户端身份，即服务端对客户端的身份验证是可选的。若客户端在 TLS 握手时未出示自己的身份证书，也能正常建立 TLS 连接。 ## 检查当前连接是否是加密连接 @@ -90,7 +93,7 @@ MySQL 5.7 及以上版本自带的客户端默认尝试使用安全连接，若 以下是一个安全连接中执行该语句的结果。由于客户端支持的 TLS 版本号和加密协议会有所不同，执行结果相应地也会有所变化。 -``` +```sql mysql> SHOW STATUS LIKE "%Ssl%"; ...... | Ssl_verify_mode | 5 | @@ -101,7 +104,7 @@ mysql> SHOW STATUS LIKE "%Ssl%"; 除此以外，对于 MySQL 自带客户端，还可以使用 `STATUS` 或 `\s` 语句查看连接情况： -``` +```sql mysql> \s ... SSL: Cipher in use is ECDHE-RSA-AES128-GCM-SHA256 diff --git a/op-guide/generate-self-signed-certificates.md b/dev/how-to/secure/generate-self-signed-certificates.md similarity index 97% rename from op-guide/generate-self-signed-certificates.md rename to dev/how-to/secure/generate-self-signed-certificates.md index 04ddced0c5ab..323e54f33370 100644 --- a/op-guide/generate-self-signed-certificates.md +++ b/dev/how-to/secure/generate-self-signed-certificates.md @@ -1,6 +1,7 @@ --- title: 生成自签名证书 -category: deployment +category: how-to +aliases: ['/docs-cn/op-guide/generate-self-signed-certificates/'] --- # 生成自签名证书 diff --git a/media/tidb-lightning-architecture.png b/media/tidb-lightning-architecture.png new file mode 100644 index 0000000000000000000000000000000000000000..bc88e8957f7b076390b641d51fa40d2bc5e3bd90 GIT binary patch literal 29918 zcmag_Wk8hA8$XOv3(5`BODZk3bVzp#g5;ufNvCuQEG6CD9kO(HH%KEA($Zam&-(rS z&v~A6UYxTpX779En$OH!HP_Bu8>aeB4jYpU6A1|kTR~o04G9SijD&>p@C+4E<9mJm zgoK2Oq^hJL^Y`yxF)^{Ot}Z`6zs{Y%olk#n{&sdw{6&!cJ?TVz*ty00{rwF;`HKm$ zM^|=V`H72ojpB0sj8|H5`nk3x2LA2CMPE;DJc~d6)^!|Z*OmX zeSLIvl!k`p+qZAo+1Zhikp>0^(P^EisHmN_(f0QCxVX4ENp9FLUc7$&nw;Y0+kP>cz7VErad`1nV+9`a&mI@%PKA|_V)H>;N*ry*IZp)4Gj%ROY-pY^0Kqi zB_t$-hK70smr^ih zY;3%`y2{Vb|H>|q&APs%F0sFvM@1HH8(dy-Uzil{1JVp_H^8#sA*Es zypvb8TwJ&Ao|`AY&q4!X?H)|L*=>?i|KMT=H8V3a@bjCPm?$eN8~vWC>F6jaDfwf( z;OMH+H8V?5j$h8epmy=p%KCj&dxxfmL`O|j`ov^Wg}<(zcFX!*@$kBrpMkQnGP{^q zOo+|ppSExNzst+Z1r*-K!TUD8msmSTt0)WeODHyXMyVKBHkOCk2F3+tSM%^PuI^MM z4i1GEH)nOue$x{3c7c~$boSX@%h76e@#@-V_YYC!9ijCN7U5rYtli9P zLn^0s;j;(tG%dx&Ia8yZHV@$MEG&FOOJcfv0;}LUZf<2`o4L8Uk#V*m5f)D2sg$pX zIrvzIS`$Cod6sW&+dFI7#>OqJ7uS{qf6EW3YxxRq49#hspB>2ZFDv))xA7?|E}z&Q zzTLV-LZU)ake1MJUp~y#lTX(n8)Vt`@n9UKihIe;ZENn@@G;zYw8UCybmDVJ=5MSY z9M-m}@Uih17DS$$`ay(X@PfN0cHw>>HCY}VvE|f0EIyriiw4be1J+Fyt{?V&gi-$% z8ME+E;6zT8$2Bi*ueT}fe_Dv#>}O6gv-x;m z*EBCnDCIM=z%{k0|Jm+#HKO7&m(V$}TKZ?fz|Z?K zGG7$PTfL#-Bnd#|7Y~^>chR`PZ_}$K{4C*$BTzGB)|d#LL$EQxPRiJ z!Qqmm_jpF@U5cwwbN}0WZhYnV*n%`7SSt`Od2}<(UX0uz?Q*2%FjJRoEoxANE!mnO z^%Upk+efF4AAfGIf1aFONvekJKXm@QJ$b?pC^T}n*AJuO1j@t`3XFgJ00jKwan}=h5 zK9K5GR$_Vmg}Tl+4;Ke^e=rOL(IBDaZj*K9Q51*0VVMfe>tttiwMz~cWWH-i5G26( z_mA>@e1A&^Rwpd!Aywi16UF$AmCnBb1V|9^ynTI{k^HaElf7v^C^i(2U?46diYL*uO>;N5o_XR+lc=t7|jU+pZ=CXjTz>*FP$m{0vow2K1uMlozZT{QRvUGQI?krkrf{aKDCHrCXX<*K=fWPTqlYf7D6S7LE1mT%`|M zeqrh;5OJCLlLTvufEuI^YF1b~Ynuf~fa?1z>XSV30W;3Jk>*q02~0Q=ktVVGH#ptb zJlx$LN{0{rppq0TGd|tK{`b6a#7g?-1HEd1azTj{8OoE7-I;2lvK0HK3gUiUg*@gTq-)zF7n9#G5pV_NOmJR2DNlFd^bGxJv<$ z$+3NFk*Wu`Pw!%$|0o~7H|QYwnY4{=h#b&21a^P5mbLoA*v9i*I%Pd=6gt6KR)G{~ zgB&0|3{EIpTlQQo_-Y-ysZ7=o{}f?MD~P}BLfVCb78cLS7%t6CY-N9@Lix7T$mtDF zO7p3=i$PlK}%=~;Lze^JqRZD=l7&AtQ0TRO7cF4yO9g!)r$ROh^467H_Q-VuR)=`C$Rn26x{ zkN&rg)l;q=H5uUr;Um^^%Z}woAI^-~s)VEUdaxp4vxPuwx$|`O>WWmLZq4Tg9-IdP z1?|;xnQ*~Si&k+Nt-Ds)kyY-TIM|n`DMp;V zp8y6bY79K(MClHl(h{d8>ylr%x)x@F_dj$#uQl#w2?RXiiPg_$;ZPEoEsZ5Bep zIXORNxrhbjAOokBS<2%}Ll`DmIxT52pAm55?a=yz@{Kl7uH<`$l(+Btbl*Mx>O0H_ zJc1%*e)z-GdQhe-_`%MzTQgS;?<1u$Qa**H`GX9*RiU>*_jC#c-)@%e2fg(R(B$HJ zE}tW;fdmuK+yW09quvo-vsj83q%@wB${$!F!QxsPO^S;?lvs@b&fbVF$zj7>9#(XSco)h)Bm4hZ{xdZM(f|DwfJ|(Q zim+NkYCmNL{NYAoV3PRwlRoX<3;DPoFA2y29nK#sb|G~eu0IfF?+@Lh@oceAzpt;? z%r~Lt5bJ(AVz3@?zWSqRp6BttnuABI{>_d~9+PFjyRAHC!;PbXfNY<%>FV`-2Ko>X zH!Bi=3wKz7l0+&eQh;lW(ZM+=CPu=)NEJ+sUU#(izWQWhw54OZu*u5?{_bRM)Lp%1 zJ`p*#YcnyHEPLa{SpH=TPV@pXr%#4Py;|!jnO!|ULO?ici>n&tM%@S6ZYA02v4O9* zvn*wkisvd7@;7CBd)nqC!3W`WL|XG&tI*^8jwhX$01zo13Fv$ay@J!08EEP89az)7 zjaIu&hX>oTNIzJ_0&?UXrL7x%r4+F8pF5Rm|d;F3Rc_84# z2FORvX%2u=D$XAj^IbmN?fjBss+J~34DHmMy*=_@pA4bztZv%Qi=GO6z8gZ_ODX0F zY%^Y!Yro<$VS;j$W4xSLmsEP7A@iUVvVTtr5xR?$sT(_ffy)%-oaTYgHCNo`Tb?`3ph6%1q;U=yS_8jA@@3yX<`g}9ub(%R1=P;h^3HZ9kcXRHS zOkx>(Z;T?;2$&rCe9DP62D5U}wqSP18>4Bt{ zutIPJV2yp@=KD7D>>~GDCBR@NklLx3xBcEELpD~WfI65KBs66 zE3g9U4_`BmwjRDV-AWDhh(r>_2EeQB%VfhDcD5UZAVl!do^7zpC|1HmZ-~c*8?eA$Jk6op!QFf2rk@GWy72VMlO{tZnHp*|iUhP;+KJK)<%-Ad8tv#tC?z!;w zsSti-Y~Xhr3OTAgD0Hbv^W}B_%IBMnPsCT%4F3k^XiZNLV#Nf%R;M3Sf=H{YkdXo4 zcB;h^V~I*s_=*vu8E5gw_J!K+hs6Z+rcw>L77y8uF)!;+vZ$1Ul78>LZqx2cK%ecM zE>FSNXPq%VA{#dxvA-z`L%aNtm?#WxvQNJ4D-aAN*(wZHwdDW+>%*en>`RiDfVqfS zLkZNq@DsrK!$(Fj*2x#Pa6>3}e{3CI$U4Ay{@py6wf|hJy?ct&$Vf3-EjuS;t_Ji~ z!$0K_t$NztZ+mg=X|VA)Vaz}}Ea^ItIPH7M}^@Rp-#OdInNpBDYF?yYsEVigk&C<+g1aDVWJ?6`G~hT!FAwC zkN$62kav}Lvcdf%vYxZ;ram7Io{L_%2}5JQNBtvlS^Ny=E z2yUnWQF1*s;JQv@Ok_=&m%RR4>*mX;Z0bcpNypboVuDqQqR-@qCP~$WLgPn+@*aYQ zm4^#Eby7x4KMWMc9ZSU3^Z8)Qr{DNC9Q~P3Nzw1XWMYo9Zk~NqoVYmi;hzjW=FNCD zIGE4r%$;{LQZ0+W_ka6*G5H@eSCP4O+^Pf%mPKnRw{fx zG{6c|xmn8Wgc@(~M@OFX`6Ya~eCx29?iql!Y__f9Hai$zN!F_vg6_&Bh|_cz36&~aY%IiQyA7p9QzHV{BX@g!$w z6if=`paLtUuc$L-Z$Y8voN}J~Ceg?qUxH?O8N{+3;9r7&T0q^ed3f$p^^|1FZ;xQ! zfpN-81=+J_9iyEi@n4tHZ6uI;2grvtwY6v;-)!~xP2x07{){9s-k4jO+WJ%~bCW29 zNAPLMe9^X_-Tq=1P6h9lUM;oB>2im1cu;JghbweAjqp}}VA{X*eACCUrgc|iRLkA& zL-0YLpNEsLu&1jwaZOZD^6qK#ezDKX>~G)V$dAl%sEHPoG*Yc5F)$Pqd#@ z8#j&yON9*T$91T_;8pwUMh$I~T=1d(Z`Vd_?f5;Yh#mC*v4Ib5Kl^{|=Kr62`~SZ; zZ)}K-4V#UiBt7Gs$B*RSNBw6=*S|7nzH5kx6Z53_qZ-|~atyGwT-qs5BLAC$AqnKP z?YVT|H`V8gdC0ACOR<&Jt{2Q)wTGs5dKNrUW z5r`L~0lzy%i<%(aE@5@?y>)st+9=5&C;czFIn|v6#oKA&{7M?;86@HC`l?(*(4%zU6s^uumS}z=j@<#+AQK!eDqFN_b?(Jx5zyI0_ruA zP&odxY{%sR9k^LJR}!c#Z=192oxf@HNU#XX znRNwhz}H)grLle%nSnn&)B1KT+l9i8wUP9D`R%e=^4xd5?|hCqqJ=L3a^|9r$u~=i zAHw6GC=&Zo0m0sYVGU8HwFtP}IT*!hU81K)_(wDITEn_A{Rw5WnaAf4n5k#kO9C&7 zaS}<~b6Rj~RC-`M4us?dP|KD)y6aeheU8aV+-m|X6j;R2fHh)#9#u7mhZey|ESC`M_O%==Vu{0cov#O9Q{z45R z5ed>t`+mqRpwli8GW^=ky^z3V4+oGGAyTn4fA*flHm43s+Z$SHtcVCPdyT&Ql+PKi z@0WPRZg>I4MAtu0jUqqaDv}VDKmai*4S!W-OH~36n>YQrK#KNITs`{z&)H7s14$ML6f zwd})81yh>glH#l_I`|UobUDh`!QW`B9Auf=igw{Ex?m{~3W|>w!l>(eJK?d#4N18S z15F#`6gzg@KK)5y9433TuPwqCiE>Ln!QcJ}8cK1a5sm_Nj=s`G77#jGyM&>Wx`uEY zmpCnpy{wQTb!gJnk5;IH;{N^`I#H=|Xnek2tEbyq{CZwz`bSUa^+8;JwD3>ObT{65 zN8?9|_l{f@t8l3Nma+3le`CzAia#Bl_ZRo)o2%wcm|X#})l_8=F(xL_`NX({><1Zi z^GJjA__*^?!!v{$RiE~cOn9k^Cw;#3dxkKgrnKw&t1Vn2o}33Mgza^;-){Uaw;U^e zC36yj2=65{Jgq-!a#C8R-{ju>BcL+nJyu~=MRC~s^Ut9?JA%<-5|$uIc>DvC)+|Ch znV)mXzxYR*vm@D!ed+VBfsRdMXeRbW?#X`;M!C{GlEf{dXb2aCNu-$CsTvpd4F};W z0+e9+`;ZRR$SlNLa2d2+h#B5w@{ZE;KT>MuQ1G2)@c83m<-nE(AK5}q4YoSd{m2P)jn@JjwUKu66Y8J<3Z4;wvX=>&@? z|516n#OdUX7lIfe7hK$yA>ts!5TUhPw{?$R*X~l?`wgc_hsZ?#e(kK59VO3Sd{!DH zz;r&QvBW;-_z#q9UGi%Nczso}Eoc2@vM^{w0OucY!0XSl`bbI*I8po&uXHgIAhN9W z|4r9ITDe({X!MVdH_IteD!h6**HjoXG>QM;$Wt+b&HJN=#iS+9BfrJt4`yP z{sSDCjVWWMw(#ZY|Im#O+s}SN0C%-rxG^ zzusGizrrG4&jt__1AQn5E6t=yr{8zs)Anoqg!}&a-bc&dyBPW>Fv?c@T@G=33vB-}+y=s-XK6vsl&4}Qz}ei? z0^dKCd8u)^toL+xBy6bPGdFQ?_LNxNi-G{ALns?tJIi75P|Y9TU(*LT$Mu?><=)H3 zr}s&yMa@gtAwHg?_3H+iZU$Z+>q$o{qPq75)@wwpf4WkPkTsCN_~?Mr&t0K%MMf(k zZ}ZMO!z<3C73WYQFoJ8;)$p!4-z}*Ar2IQ%pXPA3j552GcweY`CyV7r?i-oCZ?Scm znC~fwkM8g<`3)tCTRd88@2#wq6+YB)z!T;pHHcj6&9$x0Z~D-IxGE%P3@|<+z^ra@ z%xZmD#^$Z+BDlE@3(r8_Q6PNDT3Sx(ObuWb zM_9(cB4!+S3aL3L|8)L;rO9FKY}j%pqfB~1|xnrF&+iHLiMg)`ms z@xu}fY0^Ba#k7?9sgO=ff=2FTGL@px$vjHO(7kLS?*$|7BMiVFq$)v)f8?U!skxLv z|7;=bd{K7h3XtYK)C_C;>%cV~IJMgns#bFsE7AscV1Iw{!oWGc1Q~*a5ROj?ySL3L z8x&_YO-h4F6t8~R4@nK1KpJ!Q^IP^R+{kB=uinpG*SdWg9<}h>VgqTbL-}4=vm(5U zKPK6Xa~{{zuZ_J>i>6)6fe&VWfa;(a6vMRaoSy6{@B+Q z9|u@G{A{)fiaURYJFyTZ71P3e-Tn9|O}xCE`tV+T;Xzo=>D_-^pNf&*Og?Olmv3`e zcn_=DCBcx)s`)!2!Szw|fvk5jUUoRZLCux)omv{ztoac2Fy)ehbQqMMc7bK2WP3Bb zOj<7hKuj@B3%k~^i1{}$`%c-d1j~E&3zWT~SX!KrR>jZ`Y+vTYwR%;iObaM(){tW; zmg07oW#!>&{OcCHd0Oe=@l;9f_cBuE*OqzY-ntTnb8lY!3zTI;yd-{8p?Ii@QPgy| zY7)IL;jJXmty$cmY*omm!7~h$-II}C50NUjDiLlz+t=*_d;GiyK;`D4Nd7x>Kl94^ zh1GPi0i3Hf#umzE22P%@o+Rc?VtQsZ_F$J+m$IJIdwb-Lp~$P?6|SL8`-)mNfnfcCy?NH1r?bXZt0fR1jPuio!|rm>i^$*Pi$uwOj3{4A*iJ zK_;L;oFZGK{EU7pwpH0+8$%w6X!X!O#)k4LrWhMeCEs=Z-c^y&-mkv>WJX`$;u;P) z4bp%)34O#fl{`B_NO=z5G^Tu-Ca0@K3DQ){C;PTfax_1ws|J}Gi1xy8rON$T@U~^n zdo$%5R-3qax;7i013{p?fQvdTPk=8jesnRtq@1k>L$g*lL1D+p)<2*+^*xo#n5Yp& zo>d+r7bSD-=Lw9tf zFJypeXPY8|gB_bOMtOAnZt!uN1CxsV0694F#oElG_Avv8?MMc&Ksx`o&#mz;3KdJv z6_5U@T{y>Uo#$@?fqK(n}VyAW#p=`|dByX(Bi-^3PR_3$o;y z`0pB|l-Gpp_{&NyluRWwrIo&P4rZ>1EcWXTKn6!GwcY9Dqse`fo-u^iFdQb({%>aD zGKe)+Ep|6q@m*y$#kR-1Q3r>^C~L?f$94$tSlzMxU&dORN|xc_9!uy}saEYzqmNna zf%})*N%69}vT*)Gfvai{R_eX*CE;m4V#|(pt>iQ}wlk@9)SkVMa!}kO+eXP>od6`p&#W4_zV)n?l@ftYYn7>Lh+ZT36o*x)!-{Vnt|l!n>a8MFtadI&4I(_ZhY$>t-={XqaiudTRi>vmIk7P3b;Dw7UkyR zrhDpZicQ!C2POAl(e?BY!VOu7?=4P43R8Jj(}G`1bxFP941=HAKo$o9A3?H|AVkS+Mr%m2un{n6Q(T6`Qa_tFo4Wgr=c ztk1xUI%*X|!JP~w-Q%YC%oIRNlzA8^c^g#_!-{7_>^{z(Qk*C4m%;vCY}+Wgf5dhv za7vZXjP)SKtB1shk%oXuOKCYB7zKlX3c=IQWBQ49qt06=*LIY)gEM_SwAh>&yAdx9 zSh^Hka@Lcrq^y460}`tIJ&2ean1Ah0h*0#T7milH&VLzhC`8{_8dKY5O0&WJt-U{C zL)O2A(}VePusohT=_>V2RVHw$4;ZRP#0{xg2fTR;%~|F2vCd9m)EqOvGB$9gEdN0RHe9|o$lyv7o; z1?OLEx+?#ZU(nkCyxB75i=#itC3>G}qQu+Z=h)u4_#Wl5(Xm|ViTn^fAY82@HQHDT z|2XMyZ1_b_Vx~`$=v^fojt+7i{p$#^0o@fcJLJc9wr(|m1|^BP69iSQ^15Bn4?MBx6Hr|izD<5GW%w0an+kQu`0*M{V!r`~hDv3-Q2*YAHf`>J-Y~W7 zj_<6;q@$92-0Q}y!WTxL(t_58Ll^zi=g%CS@3n*L7%`g}640zXzMEJF!5pjME*wrY zT2!CDz=}{xH86cbxD0hAn7I6CqaPUr!4o-ZnpI8xg-AmoD1aUXa@;`-yk&JV*%=mBqAVQAIz!NHGnm<>&-`g%XZlW`=^#=_l z4#oi>`dYdVfHh%~W6h*ug6we&Z}eBqgj`sEgCgImhm7KZc}}ym2}|5S;9&pEjP&=- zocuxP#<|GNM%JT(_Ds^wjqSP~_@|SdZ!hN7D4V-gou7e!jr@Td3e+BmE~_hoEB#)h z=SZsvM)-`j3KQN%r+k95>3@uA4~~k09TSON#^Z<*ArTbC8+Q$wg;Rp@s$u4MlkIjs zpHwlnM+;H9265gxFMKo`JA3>Z0h$bo-mTgdW5UYPPW3Y!D^6DVm7=P3lz}a~yNzCe05JhD5>5f?pxT?K(BH~_r}JK(7Ekpebvt^ zV>4%SsNwSzQ$;%4azXw6G>oh`0~%CTqen@4p&*3U-1jiaMY19!gqcZ~^fvY;Nx&Gp zUeHO{a>;y|A@tm>?U6LhD^)??bUkOL5;MB=qQsvS)h|*!ox}(+G}^DK-eF0n2j8z- z+pYGvLH()UJ)kA9{&JG^;Z3<>c`^#OOCC8&lEPw%i zFLr&rULVO4jd~kV&}$#$py^TL#8TO+P){?>sL&rbUKGxf^i$?JwvEku#kY*Fsl%~B zOR~Xpl3jYI`fbk=Ar;*PeaRG9Ku-wWo9ufGwD6NNN1X2B+nCXgH{5aC%P!^x(_`t= zH(v6PI}eD*j?Yf}8pP^~PjpYQ#w6g^@bf2Lq>ySQAopo#?(GzzIhr-4L&#iDh~|I{5|3w{^vd9^!hAbQj4B2Uw`v#{X;$g@5Q=^Iu@dr8D^*Sx;%X_(I)=
s0`$Pw;n?tXK0r;NqWYV(WfM^YZezU$1`4=Er$89$kO_K$YRze}l&hD>ICy!4 z3X2_*6xV6O*CSyC-!AFyygkP@yW~tO+-Q`=g>#sK1KMI9Eq(mvlc$VdWPcw`MU$cq zYvsr#FiM0i+nodwKuhY=+gS##e9Jw0eio$H(~=t;CBvwyB<_xxGlpOp%Z6ora)jTF zE?;#8(1Slzxn3VIk57`;d%4=dm@BW}gR>s9UaGTvl+~kLQ?;z_sKQaw`cV6$j!VzO zIKfLTb%r?p<7*eM5V2|lQtO6L^KMB$Y+qMbc5LAZ)p1ka4kprUUnD?FC#A^D#HH6v z-(!LJs%p1187AWV*lX)M?`J7Gba12hv7Cc_Cv@JU+2z-pSRZr9TV-dZSmkTVFEC%T zp))>I%O#~XhC8S3MOnd*U7;vYcrVKIs%PMwzH5;zj#ou5} z&+8n{*5MJobqKDe{_$bFqso3Vg}+W-|EJmq8v>b3P@4S_Z?|OUTnkSrdAj@nCZ88! zsVangK}R8J$_)u<&{=o!bO|gOXL-zW)ZTdohF1CwgggW5$W*b;ke$3eWIJ~`AOU_< zj8xSycytpjt0oAjd2Hr1C|~eSpx6f)+T^Zz#}r*2si|?38GaBZ2ij}Z-(x2lpVcju z#P^bzpaGBYocXblzp@^ZUwLbVVzjN4v&j578ooud@+AgK1m(dSq#|pl_|l&r{%w@T z7-4?@mfba%YQ*r%^{z6Tz>lAUWn=g=4hB(yS(xQEWardg=?q{wm-o<&wM~z zvQw(Bb6j&89`^oCRHIg<(E3pA1Qm22!q_~}ihmd~=!Ll@0Mr_fe~eN2T9j?7qA;RP z)RK?>K8Zu6=3(SAg!Bn}7QMikEcOIvL^5)(kZW@AB{uE3qR?di4XLZ!&Mkd-Qcb_& z_W0qenwU>>*;njjm?vhlLZEq&>BelILV?VJuL20ok*#w`vTz2^J-?01i?Fp_DykN{ zopwsqGB#R)ED+Qh8SFHKa`5G_{t~;o3d=k#a^QOxgnupU6bDd6K8pk8KdjL#Z~txM z9mKs5DeoCy7-P^TeKoMxi_Urj&k@e8_Sj_J&Jze~?nmV7AbKzXL|QIxm)-phXNDI; zZJ>*??eAo3;(FQbs$P~axV}*&ae@pV!;F=)XX`5eWzpOwg7UV_xQfV6sbxf+tCL~N zWW9N!viJ4FI*Ar$CRr90^P`fHBDJ>O{g@N>6(m1U{|&%7c9&iu2Y z&uuP!kdIkQJ}|pO-|qE(-?vWEUS=;4lXbJ_^+{yJMb>kuKW69&G(|lvT_|$m)2n2@ zi^%24k&2FS`=f|-^%U(N_UDtXDi1@K$2+UtEwq#suihh4a%hl%az6V+!$#r%^~b#i zSJ4imXdo^i|5aE(Z2UpF|DF){2JP?q_NtMH5QnBwE3x*GV8l$3fq;Hz1Plrok=OUX zK8U-6{~8RDnW+M{>@FeD(>I6;N5QBnDE9wI1BxNyAT)#{E5aA*V;*G(0+U-K80(0UD7s&TMwn>7dvB2(LUw+$0r(;$P z|4sl+NHTv`i!xaGoU?)l4u16d+bW+7^m%{CAP>7WZsUANA*q&B%lZ2{C6d2zmIQg1Ml$rCM^E^MOCC3KipPx~L&@+q% zCJFTfp#BglTnW73xif^GY%)?Z$VxU-CtPp>-gN942@mfA>Yn_d6NzPf`X$`~)<1o2 z2EZKOaEETwVPEj`nyfonN)X&YY>fyJApysqsB<8v9zeGVGP6HOTP^V<5Y&laUYF!) zz&o`6Zy9#8BG`ivD1!O_B=!G(L7b2yF#n$-gj4YW0s=$`k{(9sr0xKqnRdBu?erW{Rc_`Q`_7)TFn`eB9g6ayh0LW{pLVJ9 zE8<2+2O2|(prHHl6R0K|EMsU5>bLbh+s^#{cG@cD#hBC30#hL9y^j3Sl0dF*nl~kD zs$)-ZSv&Lkr3ickRsr_+iDg|B_#-JCaT-JGLgQ}k zR?#r>>f}5+EafZ$nQ2?lkJ^8LdkHKX=VqM6ok@=kSPmnyRp$6Xj33M$z~5`;=x(zd zr(hO>@((nb=L`U!Af8#^*@8)y^k0@i)?UNiiOJG$E+<~uewTmqf8M=V`l9pfW7R-{ zJpZ0#(Zwsaj*|o3!?tLpE**K!fx(95@J|A_5@yP#h^UX`;Ut^=mE51KkV$N^IJ+9E zqnj90?gXkz1ZhA72A9mcsfllgPWnS6mWgqi zfwP>Nu6Ly_G7<1=$zcg_**#p64!_BS^N<;cYKnQDF%>(c@<)USWkfP%fbhMO;l7eZ zBIv2PU^Lc$TR;pv`mJU?2-shL{xZzFmwg@Gc~w#;ALxPSMCb@uR8D-9$2dXjck+Nw z!+fD6E1>p`YaWZ%Urc`5nw{0Ei6IKRTF>&*9eg4kPD{+v-I)5%Yd(z%sQyI zMj|){!voA-2{q+%+xplG^uN%XW!}%~_tUc=%a{-@b+#x2`x_R#BM|a%2N~!ic zZ`QH}KE(mD6_|j6^9Cb&P>l*WT@%FAIY3l?!QHnu6kia~!5kTiy;RZ|ZpXB^4ynpQvvcBe(!Q)+U8I+9E6^HEAst|gf+i#oF zgORwxFk3K*Dz)gr*QSNm)Ot|)DBwrUbbS|3W1CH1&&lapM2}=OW~&Z8xaM4TRCFv{*r>;5kMTy*+sah!TF)sAK_ET1q+|y@j)HowBt6PjnLGfW*(H9q$421W}9GG^9J$69!M zP;z@bR#q@9WVU)i*nqWY{UNYFiH(R#2CY>NdA|?-iaO%WVj*xP%{?bJ@;lxi`RPIi z)=K4p(D{QTVa{WvNPfB4j#|zFMMS{1Dvg2z2n&CtkfI<^_4c7sjZqkKh`wKnT=;LD zJ&35~+=S+hpG4n`WzSh%h37@<)@)&$?o1m_)f!v+7SE(PLXj3x3+q2WP}@-R zN$ZeRcUdvwVxdbJOzgP`%IPkJ!_os(!zeLsp3kYe?M>wdqKCsO7hE$|?tm@eO}3a{ z2MYn5LwjS08G;p;^oAweF3yq8^K;T+2T{Krk`zTyOgupzzf{L-;%x4I(VG3&385F~ zJ#7AEW4%2FJ+Gc5pE@@h)kj5G+Zv$jzt(w8X_Id|ypcORjYXS%kDjB;aT5Ubw{Xg( zWerA~U3H~KHQU^8ag~5WhBp~EGGJ@{*DlzlAElvfg15J4_x6NjNFG9g7o<+_5Yhko z!XD1J?P>DmtBGDUM_h(WZ7{S+9!|vx`GaA%krolD@sTkwZWD(sc?$p`{zcaL?bm#= zvl}9bbo#}(4|w#U4~`3mLhk2`y6vkYOt;!#vN3yvuW2a~UKA1l6~P*Y-ERwU@6q9K zkd-!GO2%s8lw{5Xp~FT~J~FLkA224eu-r214xj06WTcM3~=<=}Bi-9kPP z@K%hEG7!YAK(`hVlG<&Trd@#X^OcWj9kBXQE0+Q5ZysRo&gNS?lqLG9Q*n(A%swT z_^SNQ;hj6uII*4NQ*@)^hN4aj+%Q|~xUW0Fr%Ah+E#X|_g!1jlf^~GWhe}#C2YbG% z*%ARK&FeGyM22vX3enCfo4xdyF(s^#(qc0Ydb;@~SfUJbvtJ@MBSFYu#=9sqTv*ms z#0Q!M3+RqKBG7+#o>jdH%{d#A^58*oR0|*&HZhXB8b`1bPp$&*ivdUA?$i-S^w%&p zE}B!B@^}KS$^)jc#mGNLsC(b@Z?Q~x?1y>|FK&#Gum!`!-BYF6G-eG`dS*;7Dvw_A z&_%(%mJasxN=h_YQEh9S5Wm~$e&rNylO6nE*(Le6^$h0v{KH4+iJet5>eXX!HPrpe z{`}!s*u>{CL=L~Mo?Ug&)W>fIXmT!k;vBtc>HsYSTb>~8_w&DkmaHxQz?n)ghhRC$ zO(>B7^LrP)SilBP3k4V*N1B@xa!MB>?K=_U7+otU|?wP?@+ z6)m)DyA^++2iE(Ey&@7g{T0nn;tKD~(ZX#wq~X)=F6A-Y!1@gT@Vje5XiB#6qeK`? zKtGz@Vb-tLEqvc=;dq`vzYYn@umjouQxG-&=#(Vmd62ineKjtbRo6R#+2Lwj|7|!@ zt{Hqis1RzAVfk5}FBl(a`!QOV=EDh%3CsG@6Jucfe0`hwnWE)05C_jzR$*h#cldjVcn_5E z_8}K}i#N+BB|L!;jI@JJQE(F%+Yxek9Eb7WYoYl|orXzQd0i zjP!dgf?btD)tF~L4QW}Qmo?_2hAKqd`me5iundiC$&+Ob6I^whzz4&aB8(H7gZ><;;mBSMvDs?z%HMB zLXE+>`O>{$rrtkj%%JEHMX+y9dII;_{&! z+^?X<)$7}9ujs*31zq-H`L`3Kp z6tMeSXwzsOP{KQl>h_8TJh0!XLWqzE%ca=9S!R17$_y!;1gP$J-a8m(jOTPPzZ7>J z6<(G@m6W-WQC4eypDG$)vyAt<>a3arFDf@unilV@+Aur>RxR&*!>qSO1~!Hp8ZP{l z^7+j-2mCVZp3ID(0F*w4hEDnukHm5n?GAm!j1|kxns- z>mVP*Qq?mNU>PEXP_t_Bo%{XBA#kr!RqvUcBK&m5tynD(mii1FO!5K+BM-Xg6jn6O znR{Ls8)}$SYpnx;&KZ6AQ0vpt9eXK9(;=2UB9A67qhe2wAC{tXsnqwZ{Oyx{h$coN zbddsIPmkvVMU?bnUTi2MSPAl7SmAb}4KvK>3*&KTBKg~-!5+6Y`kAi>%z)Zgn6-io z4SExfBbk_}Bc*Y*v1XH&kl3QsdUqR6bdJ;)&`*=a#gV)O+ZEUyR#*%KJmOSUxT6=v zAGhNC!U>WSj;YDZc>y*R{3*`I%586CJlqBXfmK5|_y;wNy3-L&6Z#4-!QlnMqWKC$ z;3j@!IBr~TFj>08)>||H4W!}Cre%3PN+!xl9S%xZKfvS8to<&|ASu`%R894)p5bY7 z^{!t!cFVCXxH*I}D90E;?H!^ta^ez1MMfDC`&*6Ljh!JLiZ&eX*rq(D@GLzP{?we& z(bO!G|2&yQ*?Y=Hsf|8O#AE8V&YUvpEgNULjgwBi*9-=wJ>{`cRawiYqE95I=AOY% zn>PG zye|gb<6NLIv|(w$Mfn5~7$x^tTEvcYo5IF6;{)Lb9BUt8t6ddz=+ymd zbq@i%uetK3leK$;20zEqfu78LLr0V1xKEJJ*D1#n(gxlVWvyTK)CjY_dO|WfyNx&v zB%N%|xnX-FnUi6P69?4}S=kTbrH!(ef5YWcwiy7_bQ1?n>BRLfCe4dn9)l+qPkwNFGF$D55 zZBO)j``b1tvM36nA%mkUVx7L1&5NVvX^%%H3^i=)yhrt^<6)s@A=g1qIoHe-c8Oa4 zT1S6V`AIb=65Lzyz{2IpF3vPhNjwaatYjgbGc6(wdPR$MiK9z~5)mj^$}hGEfyCqC z`>!a#hvNt@;bV?+{@GRjS@Rd*oo(^nJ;{}6ouxaW_KS-V>^a&G*Ua9oaxS)6@jEg$ zW9nC55;8IU-ed5=cx%+5ujiq-Pu;!sAuZqFy=$TdZ_~OiylW$q`Y+of=T&cAY*_>6 z0$-J!bQ(0`0!IaCUL|(Hk+^pO#yfOxXfPRv-kx*aNe<7rU9=0TtGSX)FF2tb_RiJE zw~!{Zs0vRm%)ctD{iJQ+le(YGppr;t-rUzCkoSL8_7zZZG~KpHunZc=Ai+H_gG(Uj z;1XO0m*5&Kc#tr7kYEWe!EJB}t_e%FyR)ts*Gs#B+{Yj<_m zIlI-=-T<>3)Ro3{MmMvD)`<4`(EzRN_h%1DfKh>Hm#Zsqs&cr?f!`fv^L$|ghmqdR zQA_L7b=K=K(Z#1>c0adC5dtFwn}djOVasg>S;NR@WnDedo9{`c%4AVI4c#5o@89zb zc_nbLvTE{xnCp}yRj625^TNU15Znv5z6~x#ooeu0{v?%#%`_OV7Xoq*BH)x(kHq;C zBnPceTv5aN-cu(Er2K_jDteHqVasbyKhxnW*!bn}%y!y+Cmz_g}~dN-5EvZGTOtO0Y4b`=0TkNpKQH95!-)!1?Cf|inCm9c<1Axrq8;K|iw*=u zz?OVid#gVlL3zEhc->0Q#;Evu6&&;c=J$@rZ}xtiQ&RP}*N52`^Cs4Rfq@pJ5hKglP>K3NsSsG! znu)65?S44ggwg0E^jnN@OBxUUFhu}bbbdy~@BIpnl)V~qa3C!820X3a&<)v{D5NYp zz?+}|FM}t#Nq{y5_w#n%e~3-)zLj>NoT(a_qmGIRx%XM`1Z7;#3rh2h$8TuTm2tPB zz>iHp*P*+?9&2q9>)tXn0kGFEY+2j@fJ+io;6NwDjj7d#lb_bK;S8G9-KUnl{58Y| z`WWZ=f&bE+68Oq=A86=S1Xy5QZ!oLG>|4Wb#RMT{ni5+f?7WOg+r7f@& zzN|E_ak=Itp@R*;m8ypR=--e81*snqnj|;=VXi>|d|`7GguXc#;79mv;gsgV(31K; zLYD>X-+~kyqH@prcgN;jr=z4Q#vP!?GD-ceiCuOcqAuC;-HcY2dLF1KZP?Tuxk^4Fschew@`)uax=6;fIhu3p(2OAuH33u3{9L>kfIs1w0wp^i`PZSZAm`|AI*2##BqXs$qZJ#Qq&v@A&nYUc1=`h;c}X*x1iUI%;@&BH zHUBsV8YG&?n`-fPB;Z~pKx-24Mfvm_ZEKpqnPOV3D+-F)Z;+Nx(YgK8`IW!gt6Ef+ zv8FvWGJ^{Am(Gi&dtdin`yEAg)E6Cw+eM~Ym;}I3S2wTTcD3)He>$-(>cH(m!Dujj zWZsw;QuQsP5{GV}9K30699;DJXaJOaPC}n=4K-e5xk0^D&KNq2TkSjIPfgc4%kJwZ zk3<8qF|lwqv>(fI>aX(G(xuXMGK{`^3@kCXd!tl?*i53BdroQ`Knz^$@b)_zRdP93 zm?AuhKkHoFWWh*~Y+d=f&G!)%y;W#AwFI-C)I|^otsh+{X9f4oxoo@q(qma3ZnuIq z_s2w%xjBT0HTF?hP$2_@4z@m88tKcwj`1~Z{VCFlC!lu3=02n6;7;HY)a2_q1ej?V z&hK0BHGE|$wgHUFAR76IF1}eDroK|=fsLRv`0JVcucRaI6c`lS9s`D}s2CT{eRpF9 z&W2lz>GTtz06{bnrN5UoKtCE{h5tIdQ$-WRZuSlT4H!X0a{tZwCqdMP5dYWIE_b;O z5w6|_`AYkD4E{aD0!#YY|LM^Gz3~5*^Eaxb4U*FzL54Jg0tj|LdFpDjc(gS6^a*pr?Qvr~^AHzR z-WG5cL`8XGzj>9Iy#A=qIJT>)wenHh?|5!1UoLkh$lIsR zq$xMJ_jXw$r@Sn;=_k$xDRf#86tDNARdvj}uZPe}J9~JYlGboIf0b$6Tn~MfDKW&Y zkTshih?dJfaFJlJOF|}z@oTGyR5H=7Y`x4<@QH2#CuPBj6k&-ws=c1zbhH{S$gH56 zuM%%0JOR$3?3=RatT$@+=X*Dh#*lJ%yRh89n??ueT|nL zXxS$5&c-xUQ0mGTFQ5PXv#pQ+Y9?QeeH7V~Lx>|2eWSnni#C;DFCJM=2G#ogNUqDC zZA~(txUg3!=mmvhR1EE)^eQ;<5U+RnOX~FmTP*Eh9O`{9Hbd|Em=n?8nx%u1q`@$l zuXVlH(M(%2O+56SP({OHD&X_|l9OO@8m5{o@yQEMHT}|7knT>{;z_ISRfl~xRHifR z0^JXK^{6z_Au8p{J9}6#%9Noqp3QH?Ge+&4A|(eraGIX@K{38lih~LLg_z5OCf1m5 z$qi;qvmmASO|^!)B21qtMjPdc;wQX0fDTg=hS`fyv3LEqy|rry9clz9B_W_9d`XI9WZl^sGrgM;Z3sLl6dbiAh!!bd?}O4~i*7jj&(vM}+{O2|5? zcJXx?uE{iry~sXYp<;SXa^>519@@v~^I+MXmsNfD!t?NLfpAk?#CWD^>rkss^Np~Q zN56tY_cEol952o)aY@CmKmll&`{CX(9b-Xn)umLS%tJ8mu2z0A!tl)jA-KIuDeSkVP}H- zzf|9Dub0+biZC%v?w!f(o+a0yCs(;#D(Md2rq;B0r!@mA6GVJhLB5na<@%d}Xzd*g zP%$bsmuCw|2|m#G(<_%4m*byWmqg#bKq3K0?wu*@d|0A4HFnJoVMI>E$-(i{JXfMo zV2KQ($}Fi%o~zyL>G7mLlo%t=`dp|J=YmAeJ<|HcQOq*yd6u|8MStEbhVD#x5guG}T-pPTS6+Zh{0mdfB1};QUAK!k z)wb=tclM{OWOlWd@)E)04PmyB61e0O*TG=|Mzkq%nW(mfJt zI|v&dQ*fGQy~cFiceo%9EQocL;PyktlgsW`df?7QjrnB-;okd#E9K*Q8?L|h_Y@#r z_i>i$`fHs^2~`g#n?{!nzHi^}cq1aGB_(fW`-x~*57jHNI-vTO4OotTI^m}PYr$kA z%w}!ac3jPjYSap#n0^K|t@&d@7avBVNrPEY0+k!>QP`uWmj|E=C_Pj)4;AToL}M^w zJJsn}jG=Monj+Lf0=@)%B-|)|AEg+O##yqYJd|}e(ZkEo$XvEmiLughF=;083XRlY z|99|cXUm)4I>@y*gV z%$y4|$U>0qFPWbQ;`K){FF)45wh0YP%4f-_lHqsJ!bhu;-+GjrU@DX;%nlI)e~qCd z9#RYb#V$czEwIwUApHYcd;5h%4zD`!SYwoF_Wi)!s zkN6$Mw0+HZPsWvW^lAFxit57*?@$OBJHcmUgy35>GeHhbKFHc6D!yMn1V}c#W-|ca zWm}z_!y=<+Oe!}PhktktoIQBK!2UZx&bxcM0Y3s|yKff3m4*iEs!@_wS%Oazj)pAw z+_6uAZhB~BQs*pc^!&y$rZQ!Aa=bkswAwnmG!Q!uAhf|!c<{2 zUZ{MEplCkg@i*DFGKn?08cSLn7?HaU7h)6MX_2lK(GIcl;*Dr^gK8ct8yHK*v_efh~PyUThqU!o&E5<0TZTOI`E%Y%NgyX$B_yqmreqDh*4&26L6J7aDcP(C0 z{xG{aeIhL5NePttas3bsTr3DgNxaF^po!sgY#17{e>G@{)ALrw8*))fw?cJyaxpIB zHioV((=CAOPw?~0dyGTE$!O3IsHh@rf0*q$ilpL0VF1;V6UGN0<#0k`4pfQj_ml7h zg#-|fOBOxe<)n&oxO>?$zio+WvOm9O5%Ga&f05g!z*!Hs<j;NClrQ9s~@x4dV#-aWlo=q0mxPjE#TQZ9TjCVAPaGy8X#Un9Ew@o$$e7 zg9nbn($B47JoNoc>aj6jV-q@&ns@?`J{lnS1LA7Z>-P|nf8PWTTxQYQn)!nq{ymm; zpVC;oUPTdPrksjFY)s=_zcRnselyvF_7*{o1wc3YnE@?$7P@jULlroJGbQ5H6AfWB ziib0M48y7QnQ?)9t&|zyZyemEO>c#ppLeE&z@XRnj*70@qOXnoDs4ONJ4gX>ohdtX zPzv(Lf}y)NLSIDjh=J`wf_cGJE4{B$kaq6EU`5(UiC8*FDmr4e{b=xmE<6#)Wh`=?-QlgV8g`|?m8qTkR1~C<3Qd? z*%L(?C7$z+u+WiF5SsrAd#`0ADx>sl0{XY7RFO^^K@tE*m1m=qBSY_QK>FN)>DZ!P z%Q!9Zly67ihpabH>I}mHiRu=|x~fT=D-T_gxXh1na#(@BSqRzB*xvVC-& zL|n=vcy0Yk-)qTweUi6`Vj+TxZA+rapXw)(_-=xzkSv2>YjXpVp;$l%f3y_{g6gfz zf|%Kc1RYHI0vM%3+lFME<_sHb#@W~(qcHm{8HoGMX+sKz%fZhaLb6Vn7l!Gr>xK^s zU0?tP0qS}?0=-O3ql|a;nr%mWI<)C~0$&jDSJf`d)_$gj*6_va=WC$66?IA-k%Yf2G3T%ERFF%onbeIqp_rPCAW z))8eazW)@2w$fo=!C}XMvSeW7ChfEuPd+A~^vs!YAda!HD=K+C=(^`Gs z5X-aQnN`;}9}F}ltBPV4HFF2c1)AaRKQ(z{KrD7eVek5+(^V{Jq4=!mz*=O%SGw&F z{Z&O34`*P%({Rr~*qpJ+Y)yrGYE`wvX%Cz}s94VJ=EX58=-^mg zu)i}m@p(&D79Hi)Y>q`IGWvcllhzJ>Q^)XDFvmGMB>>m#Int0(ai!|_> z?zzLU2NG=y1G{T5bzj6uV>=ND6WAq>0%$t4U$O&$dU&eKvm&YPGp;;NRsjvDoz4`fxI4O=O=IPySLl8r@B8c{vNtw zctl9U2xWfb@ZIY3%g#YPPkV9NzMme{z`#j#B#b7_P}!(Jw2H575DrQ2K(g2DBoa*q zAD$K2fv(%nLI>)w>CnLo>`=r7pMV7Pf&U3?U0sYB6`T81)5+S|0}1B8NTKlJ>Dlv? zdIm7VbECWaaFbdeY%H#Wy3g(?`bA7Q4?A}GBlhDs^tjEr2#<_%!n>K24r%z|f*R`a z3tI0%=Uwr&3t~>Ez5EAvb;-XDMG`b3ZHmDNGAFaDg4=f%L@h@=Z|{&$qCGU$eqGTD z0AkY-q+ZmW6)SRVL(6`q0nf|RzpWXx>Gsr42q30+flw^tm1M@hO~wK~0|cURA||-v zaO%G~nEzz_vwduIIh4l~YlqV&v(U7X{Hik^Mex&T^~o-d6*d9Uy)1uL7~>0>_s5mi zgif6uI|Ci6?^l(#r^9~gxHIky-v9XN>XdZl;FzZF^O{#UbU|hNj2^6V0mR8Kq8#$x z9T)HiwosIw>%kR%tLs7&0$T5Xo$HAKtg`IoeS58t4MTyny^X^Vi{oqG)oIdp`zMbV z;Oa1=$1Mi%J$(c{!ALL=*DYylAX1-VV?DtzCSe*y*D6lnW>7-wdZbTD0$|l{0H}T0 z<39eSWCv}FOZLSm+j~>rV>Mg?F~CS3(2n()EAdvrHi(uQ1EKWRY~pPKnu3oN^6VJI zM|$#ko~pRW4!Nmz7K|yr;(ixFoG|(aD;hWwm;w}uuuINY7mRr0NJ&Qt7AkUUXSMEf zsI8G(Cc!b8>PXW(kt zNp`KPaSZRxVaN;WQA!eZ2CS2x2ad- z<<2YE&STd;C30=~C=4C|Aeo4drp28nEb2Hw@q=vigG z8-ZZR$;LpCs*!LIo@J6@rU=QckLi>ttq*CW17Pk4F$?{h$15K~`{HdbH4@k(jc&;` zsL)n4dsn*oyVNt7H=596|>iL0DOTW93CZNGxF5j;c#CF9V<)ftdZ? zDfIY7fDk(lv2?dvfU9Bh7#2_TAs|;Hz=>S-h%Y!kiBun5T@6g^4$ouo`EgXFbSTf06Bqg^ zY<9~}o*k1i3&v)ZRc-JShf5yAYP$*OEPwF3<)OSlLkX8049$4{_Eu}|^z#XH1Y%kJ zfizS)hx0r9DVSKmB5O?-J{CkksvVcl^0tvNCkpsN{-q>soDI`wU}Gi>@@q3Lbvp#5 z7v!o7NPPVHO0yG7L0gAacjQ1n;u7UaM0Z<$E|84W=`#KSbL3<;P-H**r;V71VbWod z?lgy}&ckO_xh#Yc;=&bcq=+v6P^2N}%tA7-J^FoD*Q0K(e0=nCMbo!mkKb)*4&QE! zivirg*X0q`-?g|;cP;eHY_p1BFu32IsZs4nhr$R7;Y<$9TbG0wYi{eYz=+<9H2$?7 zK&qiu+n`6%EVUL!94pDu#j0yH4pD(gvx)|(%a_IjclWruPrE;VL0m8X#96Rje?-@1 zqE-6?m%FV^Zppy^$RxpN2mvu{k-w+tMKbf8eyb74itA+-cn<$1|$WWU4+TuYUh?s2d^#Q09qiC`*9tkj#CTENNB# z@3>hCrOCOD@$JG(_a(e?*=DtAk=5V9NVNaUQwm2E;jV= z4%52dQg^VQT`uWYS?Dj73$PuLC0R|z>a+~vN&&0_YSEAomLMS-i)3|Ue0EibgV1v< zgjdTXj+~9=@hS4c7sq$gkJleX5^&rBg_m+DaAy9y45CdD?Bx_geL81?YMwge4$sq? z`f+p~H-s%MZkwk(tC6f$bY2u2G zrY?IaK#wmu_1s=d_qF;*6-jzy(S@vWWUxmvYV6de+=`;vAa<&&p@BQITIn%yi5El1 zO58{39)YEcwe&KBpgZ>{TETA2nWNfk2Z`)jtkXD=JCpII40`pgf2^r8@25_X$Jx%f zg3j~MG!>Tt#$UbUmz+Fu{1yYZ{#0M~gT(V7377V!32Dz&a6D73eB5KCm{us zWKQ&zk}h9wt-BkzjcnNoQKmP9S8?l!UonGLd1Y35guSvi?5 zFkYAVX8&As0HeE-6-D8z`fhWaMXIi#u&f{jB^OiUS5AjpZhg(g2VHk~ddX!ax)>mx z(aX=FAX2sw3QAnsyUQYbMFF`D?z>mobTv}UflQu<3XSbDUxT<^G}P{Oa;4D+c>BLu zyH0;>E+-F-UlL0rrRge?7r(t-r zBwajpSQD`D;A52~ao#W_wNF>pU9Yv}d^lLI6YVQfJ;DjTHrS-4v<**jNvrzy&#v}2 z+F;kSvn&{{O}oq{y6|Z2zwjFAFH|EG{u`+O;xz*L{%Ze=fCwb~PiX%Oh|AdjHRFGl ztsYG6CqY3n9EU9RQw+yckpBhzf7!9kDP0EYSIo2%z4wvuL;z)O&t4A4laQ3tUzsmZ zll9v1HBL2BW<`;%?4l}(6|&fw(_}@*v(hLl47)8(` zkDCx3fW}?%!B;%W_IuVNx<0-J{M`vJW8*j;-E-`U4fIAg1P>PvC^cCEt-r{2Yxts& zbB4|{|7WyS!n;$3`VTlDl291-#6VV{xjFCJzQHK{tP_HArMXx%KTo_Cq<2JXYfPg9 z#g9<_&BZ#ztvh#qng+b`B5;iG`b>-chsh zB(8qi7mwD(sRZk83io$q2>L^KOjd=p32;|q?x@f)x%{h=2e~R;0ttekEErZ|ZDO$# zG!kp_MZ;leXL(4>NVgsp_yPvwKGUKq&a2Sj}ULe+T>D#BCD*mb99~v{n&Oec`kF85p zC2CKv&7mqSyAR@haQw?Vdlw&MK#z&Z__F1Tc>=$pT^i(!t0f??1D#IkrifuVPiC$o z@N^=EKby0g7;a1s^pZ3rt58W2NE87v8zDR&;20oib3lqTVr!?f!;0fL0L|EB3L5jL z4f1m?>PT#L>GVho8}TWX!~5p<;_`I9i^mg&PD{UHTYIjfDl!jj$G=b%`cWIT1zJO` z772Y_y~^ypT|h!_hd!)I)+yKtvPX<6;}R@fY3|2Uo@oHqjgHBGF3^y@jSBx^xg~8j zQ$Y8r;bEX+`eSOlz0y`0$6R|yn)+J)iEdw#e1_`s8=PLxDD*cM7cId``Ex(+lo{!; zi{c#@dm@((003?y25&CiqhjHb6N#`Kk<$?%W$%iEuP@q*AIJczjrYHsJsfEih_2ax zIFNzE!#?@se*M~hUefZIoCBAn|KuMm$yIPqE*wtPtW9S}pl{D>>4J= zmD;#Y&3To`dM#)t+95~YZT$A=D<)unoWEX#bDX{012?U(hWebmePdHp?y`93WAL>9 z;Jzg${v1B?5}EJdiz#%QApX3Orq&iirK(No~CZI<86+4`2upZarh znK^6jUlEioq+g@e-m4N=buKRQ5eS>)OhuT8o8#TZT61T4+cuYjhzVwP{+NXhlnA>C z$2!k6oQxuli!Db3E*@`$-Ga}(3BNDu4_tIu8$K?x`S@O+tml(&JfRc)I8hA3%)nsF zD|YQ%YS9i80dSYeJS1b1KhZ55bJX=P6R2t&^lb+D_;-FgwYM#jK0~$iegRmd8J3Kc zL>t`mlO0zrb};HplFhKVi~H@7C8T$e5`VVUgZGhf6>Q{t;SglUek*11T*D zGNJ8UOUvyr`zMM6ZGRY#X#j6pv&i~2!QNx3j}C~Lf4*%u-Xo2mrcEM*cLkHxNh%XK zpBMDGmsM30cbkJ?wrYE#4Z>NaMEvS~KrSVmVF3HOoCl0!q|@gsNNOsa{tKC1NS%94 zaHncg%fbaza(;o&OVl_I`X|l7|ks`N=G5 zKXh;c^6h$>F9_kiwEQAaNGTJ0n*|El0~|R%O#Ay+jEr;#Mu}hm2yYtuy|+|anijP` z)~XvRO26jIY~d&iK%?-*1wQsBdA-VzBF$vvcJCJsX>gtd`YsTh*Qy1;>^^5l5KG>> z3EvDJCo}(YF;CR=t)}INn0;RIUebruRTV5g!1WYYp0)B3T zvBCWLx;8%RsFpjgeai2W^M_5jy0r0j?_pbC_&Pe+ya0~3yPiIFB1aMRaV31OXi^r6 z%JEun`;A&3n7jaCDl0!~P(jZsoeW$iPTy~N>WcIS-eazvZPhD*hU&gR_? zeV*U%Gq>{k02()E{(gDo4ccY8mP=mP9e(%O`vqEJyjk+`B$q zTkhEMbU^i(=Jyi7#Pn;bSrbL?_D5D^()ETSEnCm%X%#uSGE2370}al)^7Zg(Z=d6GD4b}sEUj#0$9 zj$$x7`X-}kRQ<;#QH1U{K*Nh}t$k`iwV|h1Z_AY=4!fp8r~rPqEADL&LAc5=V&HsI z)yyX@6--lh5r`C=J0-HXQZ-=N(^XJCmppqY-92C8FOe_~Q2ss0_NlC>Y~IDyYAB!c zsi<7)wu|wzD5#Bz4`Y%Bp6T-%RC1=NmQ?%J*>dG~{}<=e&s0B8F9xr^8=(LS+X6Rm zAqUZ;xDI!9xibtECOMDi7RQlIx8qfOW0!|R;}r7;zorZd7q{)VZN1$sXWO*rQgHJP z&kJS!IGVvVcx!+g8*<=RhWUQZFD)_U|95x2zb;DuI70ou|NW=q)PJ~7{bvfN4;czT zb0PYJpp7R1a^1gaC(2XStuW3k|2pJ??+VsbbbZagX ztT!MD&wp{9Y4ETPk^RsFeQ;spD6Y!X1T}fPn`n6wXF@sDrp)6`dyBVSfo7x{e6RiF zfBY<(!;Fz!jW%lRK8ue2S9hqQl5s8cz>-_RI-wfPqY89 zfUY`*Y2=W2ZrwYTtYR#=)P*C47Pkij5Lg+me%`N@Pf0@&Wm9K(#kizx-nsvpWQBD= ztH390pR2xAg+ALR=3V9W44k+(<;I3#X=<7v#G^W^{EY5X>i(OX7TsUqoCy{~l|OFh zq-Z;y6{#LZmc1!=f+7k{<<2K0o(X}ak~DE<6h`@frY0=6hE6mEeZ}#g{kLCF!H2-H zo)}U=fp+qJIl(LEpiFwqE9YlG>c7;;|6d6Q)_-$U`?t&5f0O>@V2ALsqgR1pAKqhs z&r(EpLHcja!Z)jZ&Qv_!@n+D8HKf$TfwsqY=8aXkV78`U&wu2-nTm2U;=`SFtclUd z1@>4+=?U0%H++n|t91Gg6QAt2?6e4HvYCB2;<~%VF%y2+;h(*~XbZ?A2n*i~iLz2r zq0izp`vdtZhc1k*it>Q@j_maL_x0{mqUNhI7C+|{N`v|Y?NhFR+Nljia0Az13l|FsmVTC1+7&ZA9xFHu z>kCya^X`oR#k4!DAg9bnf@3Q707%m#`J0TRMK+ncCc3o5t-VjZzs~`VZ)kp7s%fno zA5AY){(9s7{QP229|t7N;gTjG+LYKkVQD+HF zCU43igQd?8c|EX3fGRE1P$_YzS}-&Q!0Kt%+w>Gfk0;PE^Fd>>YE~=k=&sGS$=FWd zmli?ycmI)~wW+#f3A;|-V>u?m8uV;zo7*^P#2o!Kfu}H!9L>B{K|vVX$^#R9fRFgN z%1EtiyU|EB#BjaCDxG(_+QpY=>DmPOF!3x|TIxu!BFlW=F! z1l{-JOTw>`jVGSUI$1Pu2bk(>Hs#qc_Ma70w&5E-K_f-LA^rZbaEK5b&2*aW!XRmHW_~riDFpj>l@r>g#A$v8^OK!}F2X4U0)iw`0Q!fn+SvgcO#QVp64Yy+YE^{$D~Lc{)8ie=5tqDAao^ z{tZ%~n|3l{5#rMD0l>2Yo}lYSisxFvGOFP*6)z@PgMT+^F1)0+mxg?SP5oI6Np!i9 zeQzd&!_~bZD}gEZe9nnH#{byV=sby!!n-Os*LDyM#Ls?EDyM&K=rna@2(2Su4S~T1 zC#CbzYcQ-wNroaNG!YAFmQ?4UmK7(QPg1^8Np%@9^v=XnM0r|l`#K77v_{9dBX@Px zpKk`waH9=V-=2@#o`W66FS46yE|(>}Nw3_^gleA!OGjI_4a-ZO2qvzq$4v&&e+5w6 zy|!s{nN24VWt+LQXvQ+{XJU&B6HH+T=^fMf=ÉgW`??Tgdsf0)I6AN7&PO1+U|ASsfZl#*l_#5nMO0GCXl!~g&Q literal 0 HcmV?d00001 diff --git a/media/tidb-lightning.svg b/media/tidb-lightning.svg deleted file mode 100644 index 9669ef158c0a..000000000000 --- a/media/tidb-lightning.svg +++ /dev/null @@ -1,82 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - 
 - 数据源 - - - tidb-lightning - - tikv-importer - - tikv-server - - tidb-server - - tidb-server - - pd-server - - pd-server - - pd-server - - tikv-server - - tikv-server - - - - - KV对 - - - SQL - Dump - - TiDB-Lightning 工具包 - TiDB 集群 - TiKV 集群 - PD 集群 - - - - 排好 - 序的 - KV对 - - - - - - - DDL、
 - 数据分析 - - - - - 元数据 - - - - diff --git a/op-guide/ansible-deployment-rolling-update.md b/op-guide/ansible-deployment-rolling-update.md index 4bdca69f2782..4a103736590c 100644 --- a/op-guide/ansible-deployment-rolling-update.md +++ b/op-guide/ansible-deployment-rolling-update.md @@ -7,7 +7,9 @@ category: deployment 滚动升级 TiDB 集群时，会串行关闭服务，更新服务 binary 和配置文件，再启动服务。在前端配置负载均衡的情况下，滚动升级期间不影响业务运行（最小环境 ：pd * 3、tidb * 2、tikv * 3）。 -> **注**：如果 TiDB 集群开启了 binlog，部署了 Pump 和 Drainer 服务，升级 TiDB 服务时会升级 Pump，请先停止 Drainer 服务再执行滚动升级操作。 +> **注意：** +> +> 如果 TiDB 集群开启了 binlog，部署了 Pump 和 Drainer 服务，升级 TiDB 服务时会升级 Pump，请先停止 Drainer 服务再执行滚动升级操作。 ## 升级组件版本 @@ -21,7 +23,9 @@ category: deployment tidb_version = v2.0.7 ``` - > **注**：如果使用 master 分支的 tidb-ansible，`tidb_version = latest` 保持不变即可，latest 版本的 TiDB 安装包会每日更新。 + > **注意：** + > + > 如果使用 master 分支的 tidb-ansible，`tidb_version = latest` 保持不变即可，latest 版本的 TiDB 安装包会每日更新。 2. 删除原有的 downloads 目录 `/home/tidb/tidb-ansible/downloads/` diff --git a/op-guide/ansible-deployment-scale.md b/op-guide/ansible-deployment-scale.md index 1cf075c72299..9d46ae6fe191 100644 --- a/op-guide/ansible-deployment-scale.md +++ b/op-guide/ansible-deployment-scale.md @@ -87,7 +87,8 @@ TiDB 集群可以在不影响线上服务的情况下进行扩容和缩容。以 ansible-playbook bootstrap.yml -l 172.16.10.101,172.16.10.102 ``` - > **注**： + > **注意：** + > > 如果 `inventory.ini` 中为节点配置了别名，如 `node101 ansible_host=172.16.10.101`，执行 ansible-playbook 时 -l 请指定别名，以下步骤类似。例如：`ansible-playbook bootstrap.yml -l node101,node102` 3. 部署新增节点： diff --git a/op-guide/backup-restore.md b/op-guide/backup-restore.md index 7f3f91ae96ad..20f5baf7ff01 100644 --- a/op-guide/backup-restore.md +++ b/op-guide/backup-restore.md @@ -40,7 +40,9 @@ cd tidb-enterprise-tools-latest-linux-amd64 可使用 [`mydumper`](../tools/mydumper.md) 从 TiDB 导出数据进行备份，然后用 [`loader`](../tools/loader.md) 将其导入到 TiDB 里面进行恢复。 -> **注意**：必须使用企业版工具集包的 `mydumper`，不要使用你的操作系统的包管理工具提供的 `mydumper`。`mydumper` 的上游版本并不能对 TiDB 进行正确处理 ([#155](https://github.com/maxbube/mydumper/pull/155))。由于使用 `mysqldump` 进行数据备份和恢复都要耗费许多时间，这里也并不推荐。 +> **注意：** +> +> 必须使用企业版工具集包的 `mydumper`，不要使用你的操作系统的包管理工具提供的 `mydumper`。`mydumper` 的上游版本并不能对 TiDB 进行正确处理 ([#155](https://github.com/maxbube/mydumper/pull/155))。由于使用 `mysqldump` 进行数据备份和恢复都要耗费许多时间，这里也并不推荐。 ### `mydumper`/`loader` 全量备份恢复最佳实践 diff --git a/op-guide/configuration.md b/op-guide/configuration.md index e0f688a1f3c6..3abdb6ee32f9 100644 --- a/op-guide/configuration.md +++ b/op-guide/configuration.md @@ -129,4 +129,8 @@ TiDB 通过命令行参数或环境变量配置。默认的 TiDB 端口为 4000 + PROXY Protocol 请求头读取超时时间。 + 默认：5 -+ 单位为秒。注意：请不要配置成0，除非特殊情况，一般使用默认值即可。 ++ 单位：秒。 + +> **注意：** +> +> 请不要配置成 0，除非特殊情况，一般使用默认值即可。 diff --git a/op-guide/gc.md b/op-guide/gc.md index cc13f9ed812c..c73024cb26e5 100644 --- a/op-guide/gc.md +++ b/op-guide/gc.md @@ -46,11 +46,13 @@ update mysql.tidb set VARIABLE_VALUE = '24h' where VARIABLE_NAME = 'tikv_gc_life 时长字符串的形式是数字后接时间单位的序列，如 `24h`、`2h30m`、`2.5h`。可以使用的时间单位包括 "h"、"m"、"s"。 -需要注意的是，在数据更新频繁的场景下如果将 `tikv_gc_life_time` 设置得比较大（如数天甚至数月），可能会有一些潜在的问题： - -* 随着版本的不断增多，数据占用的磁盘空间会随之增加。 -* 大量的历史版本会在一定程度上导致查询变慢，主要影响范围查询（如 `select count(*) from t`）。 -* 如果在运行中突然将 `tikv_gc_life_time` 配置调小，可能会导致短时间内大量历史数据被删除，造成 I/O 负担。 +> **注意：** +> +> 在数据更新频繁的场景下如果将 `tikv_gc_life_time` 设置得比较大（如数天甚至数月），可能会有一些潜在的问题： +> +> * 随着版本的不断增多，数据占用的磁盘空间会随之增加。 +> * 大量的历史版本会在一定程度上导致查询变慢，主要影响范围查询（如 `select count(*) from t`）。 +> * 如果在运行中突然将 `tikv_gc_life_time` 配置调小，可能会导致短时间内大量历史数据被删除，造成 I/O 负担。 `tikv_gc_concurrency` 是运行 GC 的并发数。默认该选项为 1，即单线程运行，逐个向每个涉及的 Region 发起请求并等待响应。可以增加该数值以改善性能，最大不能超过 128。 diff --git a/op-guide/horizontal-scale.md b/op-guide/horizontal-scale.md index 93ff949a4ed2..d1cb522f6a10 100644 --- a/op-guide/horizontal-scale.md +++ b/op-guide/horizontal-scale.md @@ -9,7 +9,9 @@ category: deployment TiDB 集群可以在不影响线上服务的情况下动态进行扩容和缩容。 -> **注**：如果使用 Ansible 部署 TiDB 集群，请参考[使用 Ansible 扩容缩容](../op-guide/ansible-deployment-scale.md)。 +> **注意：** +> +> 如果使用 Ansible 部署 TiDB 集群，请参考[使用 Ansible 扩容缩容](../op-guide/ansible-deployment-scale.md)。 下面分别介绍如何增加或者删除 PD，TiKV 以及 TiDB 的节点。 diff --git a/op-guide/migration-overview.md b/op-guide/migration-overview.md index b13db7ade2c6..9703744fe361 100644 --- a/op-guide/migration-overview.md +++ b/op-guide/migration-overview.md @@ -39,7 +39,9 @@ category: advanced 详细操作参见 [MySQL 数据到 TiDB 的增量同步](/op-guide/migration.md#使用-syncer-增量导入数据)。 -> **注意**：在将 MySQL binlog 数据增量同步至 TiDB 前，需要[在 MySQL 中开启 binlog 功能](http://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html)，并且 binlog 必须[使用 `ROW` 格式](https://dev.mysql.com/doc/refman/5.7/en/binary-log-formats.html)。 +> **注意：** +> +> 在将 MySQL binlog 数据增量同步至 TiDB 前，需要[在 MySQL 中开启 binlog 功能](http://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html)，并且 binlog 必须[使用 `ROW` 格式](https://dev.mysql.com/doc/refman/5.7/en/binary-log-formats.html)。 ### 非 MySQL 数据源的数据迁移 diff --git a/op-guide/migration.md b/op-guide/migration.md index 83d0a37f68d0..db4fa3570ada 100644 --- a/op-guide/migration.md +++ b/op-guide/migration.md @@ -11,7 +11,9 @@ category: advanced 你可以使用 `mydumper` 从 MySQL 导出数据，然后用 `loader` 将其导入到 TiDB 里面。 -> **注意**：虽然 TiDB 也支持使用 MySQL 官方的 `mysqldump` 工具来进行数据的迁移工作，但相比于 `mydumper`/`loader`，性能会慢很多，大量数据的迁移会花费很多时间，这里我们并不推荐。 +> **注意：** +> +> 虽然 TiDB 也支持使用 MySQL 官方的 `mysqldump` 工具来进行数据的迁移工作，但相比于 `mydumper`/`loader`，性能会慢很多，大量数据的迁移会花费很多时间，这里我们并不推荐。 ### `mydumper`/`loader` 全量导入数据最佳实践 @@ -46,13 +48,19 @@ category: advanced `--skip-tz-utc` 添加这个参数忽略掉 MySQL 与导数据的机器之间时区设置不一致的情况，禁止自动转换。 -> 注意：在阿里云等一些需要 `super privilege` 的云上面，`mydumper` 需要加上 `--no-locks` 参数，否则会提示没有权限操作。 +> **注意：** +> +> 在阿里云等一些需要 `super privilege` 的云上面，`mydumper` 需要加上 `--no-locks` 参数，否则会提示没有权限操作。 ### 向 TiDB 导入数据 -> 注意：目前 TiDB 支持 UTF8mb4 [字符编码](../sql/character-set-support.md)，假设 mydumper 导出数据为 latin1 字符编码，请使用 `iconv -f latin1 -t utf-8 $file -o /data/imdbload/$basename` 命令转换，$file 为已有文件，$basename 为转换后文件。 +> **注意：** +> +> 目前 TiDB 支持 UTF8mb4 [字符编码](../sql/character-set-support.md)，假设 mydumper 导出数据为 latin1 字符编码，请使用 `iconv -f latin1 -t utf-8 $file -o /data/imdbload/$basename` 命令转换，$file 为已有文件，$basename 为转换后文件。 -> 注意：如果 mydumper 使用 -m 参数，会导出不带表结构的数据，这时 loader 无法导入数据。 +> **注意：** +> +> 如果 mydumper 使用 -m 参数，会导出不带表结构的数据，这时 loader 无法导入数据。 我们使用 `loader` 将之前导出的数据导入到 TiDB。Loader 的下载和具体的使用方法见 [Loader 使用文档](../tools/loader.md) @@ -141,9 +149,10 @@ binlog-pos = 930143241 binlog-gtid = "2bfabd22-fff7-11e6-97f7-f02fa73bcb01:1-23,61ccbb5d-c82d-11e6-ac2e-487b6bd31bf7:1-4" ``` -+ 注意：`syncer.meta` 只需要第一次使用的时候配置，后续 `syncer` 同步新的 binlog 之后会自动将其更新到最新的 position。 - -+ 注意： 如果使用 binlog position 同步则只需要配置 binlog-name binlog-pos; 使用 gtid 同步则需要设置 gtid，且启动 syncer 时带有 `--enable-gtid` +> **注意：** +> +> - `syncer.meta` 只需要第一次使用的时候配置，后续 `syncer` 同步新的 binlog 之后会自动将其更新到最新的 position。 +> - 如果使用 binlog position 同步则只需要配置 binlog-name binlog-pos; 使用 gtid 同步则需要设置 gtid，且启动 syncer 时带有 `--enable-gtid`。 ### 启动 `syncer` diff --git a/op-guide/pd-configuration.md b/op-guide/pd-configuration.md index 3d013146495f..18aafc470fe3 100644 --- a/op-guide/pd-configuration.md +++ b/op-guide/pd-configuration.md @@ -9,76 +9,76 @@ PD 可以通过命令行参数或环境变量配置。 ## `--advertise-client-urls` -+ 对外客户端访问 URL 列表 -+ 默认：${client-urls} ++ 对外客户端访问 URL 列表。 ++ 默认：`${client-urls}` + 在某些情况下，譬如 docker，或者 NAT 网络环境，客户端并不能通过 PD 自己监听的 client URLs 来访问到 PD，这时候，你就可以设置 advertise urls 来让客户端访问 -+ 例如，docker 内部 IP 地址为 172.17.0.1，而宿主机的 IP 地址为 192.168.100.113 并且设置了端口映射 -p 2379:2379，那么可以设置为 \-\-advertise-client-urls="http://192.168.100.113:2379"，客户端可以通过 http://192.168.100.113:2379 来找到这个服务 ++ 例如，docker 内部 IP 地址为 172.17.0.1，而宿主机的 IP 地址为 192.168.100.113 并且设置了端口映射 `-p 2379:2379`，那么可以设置为 `--advertise-client-urls="http://192.168.100.113:2379"`，客户端可以通过 `http://192.168.100.113:2379` 来找到这个服务。 ## `--advertise-peer-urls` + 对外其他 PD 节点访问 URL 列表。 -+ 默认：${peer-urls} ++ 默认：`${peer-urls}` + 在某些情况下，譬如 docker，或者 NAT 网络环境，其他节点并不能通过 PD 自己监听的 peer URLs 来访问到 PD，这时候，你就可以设置 advertise urls 来让其他节点访问 -+ 例如，docker 内部 IP 地址为 172.17.0.1，而宿主机的 IP 地址为 192.168.100.113 并且设置了端口映射 -p 2380:2380，那么可以设置为 \-\-advertise-peer-urls="http://192.168.100.113:2380"，其他 PD 节点可以通过 http://192.168.100.113:2380 来找到这个服务 ++ 例如，docker 内部 IP 地址为 172.17.0.1，而宿主机的 IP 地址为 192.168.100.113 并且设置了端口映射 `-p 2380:2380`，那么可以设置为 `--advertise-peer-urls="http://192.168.100.113:2380"`，其他 PD 节点可以通过 `http://192.168.100.113:2380` 来找到这个服务。 ## `--client-urls` -+ 处理客户端请求监听 URL 列表 -+ 默认："http://127.0.0.1:2379" -+ 如果部署一个集群，\-\-client-urls 必须指定当前主机的 IP 地址，例如 "http://192.168.100.113:2379"，如果是运行在 docker 则需要指定为 "http://0.0.0.0:2379" ++ 处理客户端请求监听 URL 列表。 ++ 默认：`http://127.0.0.1:2379` ++ 如果部署一个集群，\-\-client-urls 必须指定当前主机的 IP 地址，例如 `http://192.168.100.113:2379"`，如果是运行在 docker 则需要指定为 `http://0.0.0.0:2379`。 ## `--peer-urls` + 处理其他 PD 节点请求监听 URL 列表。 -+ default: "http://127.0.0.1:2380" -+ 如果部署一个集群，\-\-peer-urls 必须指定当前主机的 IP 地址，例如 "http://192.168.100.113:2380"，如果是运行在 docker 则需要指定为 "http://0.0.0.0:2380" ++ default: `http://127.0.0.1:2380` ++ 如果部署一个集群，\-\-peer-urls 必须指定当前主机的 IP 地址，例如 `http://192.168.100.113:2380`，如果是运行在 docker 则需要指定为 `http://0.0.0.0:2380`。 ## `--config` -+ 配置文件 ++ 配置文件。 + 默认："" -+ 如果你指定了配置文件，PD 会首先读取配置文件的配置。然后如果对应的配置在命令行参数里面也存在，PD 就会使用命令行参数的配置来覆盖配置文件里面的 ++ 如果你指定了配置文件，PD 会首先读取配置文件的配置。然后如果对应的配置在命令行参数里面也存在，PD 就会使用命令行参数的配置来覆盖配置文件里面的。 ## `--data-dir` -+ PD 存储数据路径 -+ 默认："default.${name}" ++ PD 存储数据路径。 ++ 默认：`default.${name}` ## `--initial-cluster` + 初始化 PD 集群配置。 + 默认："{name}=http://{advertise-peer-url}" -+ 例如，如果 name 是 "pd", 并且 `advertise-peer-urls` 是 "http://192.168.100.113:2380", 那么 `initial-cluster` 就是 pd=http://192.168.100.113:2380 ++ 例如，如果 name 是 "pd", 并且 `advertise-peer-urls` 是 `http://192.168.100.113:2380`, 那么 `initial-cluster` 就是 `pd=http://192.168.100.113:2380`。 + 如果你需要启动三台 PD，那么 `initial-cluster` 可能就是 - `pd1=http://192.168.100.113:2380, pd2=http://192.168.100.114:2380, pd3=192.168.100.115:2380` + `pd1=http://192.168.100.113:2380, pd2=http://192.168.100.114:2380, pd3=192.168.100.115:2380`。 ## `--join` -+ 动态加入 PD 集群 ++ 动态加入 PD 集群。 + 默认："" -+ 如果你想动态将一台 PD 加入集群，你可以使用 `--join="${advertise-client-urls}"`， `advertise-client-url` 是当前集群里面任意 PD 的 `advertise-client-url`，你也可以使用多个 PD 的，需要用逗号分隔 ++ 如果你想动态将一台 PD 加入集群，你可以使用 `--join="${advertise-client-urls}"`， `advertise-client-url` 是当前集群里面任意 PD 的 `advertise-client-url`，你也可以使用多个 PD 的，需要用逗号分隔。 ## `-L` -+ Log 级别 ++ Log 级别。 + 默认："info" -+ 我们能选择 debug, info, warn, error 或者 fatal ++ 我们能选择 debug, info, warn, error 或者 fatal。 ## `--log-file` -+ Log 文件 ++ Log 文件。 + 默认："" -+ 如果没设置这个参数，log 会默认输出到 "stderr"，如果设置了，log 就会输出到对应的文件里面，在每天凌晨，log 会自动轮转使用一个新的文件，并且将以前的文件改名备份 ++ 如果没设置这个参数，log 会默认输出到 "stderr"，如果设置了，log 就会输出到对应的文件里面，在每天凌晨，log 会自动轮转使用一个新的文件，并且将以前的文件改名备份。 ## `--log-rotate` -+ 是否开启日志切割 ++ 是否开启日志切割。 + 默认：true + 当值为 true 时,按照 PD 配置文件中 `[log.file]` 信息执行。 ## `--name` -+ 当前 PD 的名字 ++ 当前 PD 的名字。 + 默认："pd" + 如果你需要启动多个 PD，一定要给 PD 使用不同的名字 diff --git a/op-guide/tidb-config-file.md b/op-guide/tidb-config-file.md index bcc2bc6b1c87..53702d6d8a94 100644 --- a/op-guide/tidb-config-file.md +++ b/op-guide/tidb-config-file.md @@ -12,26 +12,29 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ ### `split-table` + 为每个 table 建立单独的 Region。 -+ 默认: true ++ 默认：true + 如果需要创建大量的表，我们建议把这个参数设置为 false。 ### `oom-action` + 指定 TiDB 发生 out-of-memory 错误时的操作。 -+ 默认: "log" ++ 默认："log" + 现在合法的选项是 ["log", "cancel"]，如果为 "log"，仅仅是打印日志，不作实质处理。如果为 "cancel"，我们会取消执行这个操作，并且输出日志。 ### `enable-streaming` + 开启 coprocessor 的 streaming 获取数据模式。 -+ 默认: false ++ 默认：false ### `lower-case-table-names` + 这个选项可以设置 TiDB 的系统变量 `lower_case_table_names` 的值。 -+ 默认: 2 ++ 默认：2 + 具体可以查看 MySQL 关于这个变量的[描述](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_lower_case_table_names) -+ 注意：目前 TiDB 只支持将该选项的值设为 2，即按照大小写来保存表名，按照小写来比较（不区分大小写）。 + +> **注意：** +> +> 目前 TiDB 只支持将该选项的值设为 2，即按照大小写来保存表名，按照小写来比较（不区分大小写）。 ### `compatible-kill-query` @@ -47,36 +50,36 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ ### `format` + 指定日志输出的格式，可选项为 [json, text, console]。 -+ 默认: "text" ++ 默认："text" ### `disable-timestamp` + 是否禁止在日志中输出时间戳。 -+ 默认: false ++ 默认：false + 如果设置为 true，那么日志里面将不会输出时间戳。 ### `slow-query-file` + 慢查询日志的文件名。 -+ 默认: "" ++ 默认："tidb-slow.log"，注：由于 TiDB V2.1.8 更新了慢日志格式，所以将慢日志单独输出到了慢日志文件。V2.1.8 之前的版本，该变量的默认值是 ""。 + 设置后，慢查询日志会单独输出到该文件。 ### `slow-threshold` + 输出慢日志的耗时阈值。 -+ 默认: 300ms ++ 默认：300ms + 当查询大于这个值，就会当做是一个慢查询，输出到慢查询日志。 ### `expensive-threshold` + 输出 `expensive` 操作的行数阈值。 -+ 默认: 10000 -+ 当查询的行数(包括中间结果，基于统计信息)大于这个值，我们就会当成是一个 `expensive` 的操作，输出一个前缀带有 `[EXPENSIVE_QUERY]` 的日志。 ++ 默认：10000 ++ 当查询的行数（包括中间结果，基于统计信息）大于这个值，我们就会当成是一个 `expensive` 的操作，输出一个前缀带有 `[EXPENSIVE_QUERY]` 的日志。 ### `query-log-max-len` + 最长的 SQL 输出长度。 -+ 默认: 2048 ++ 默认：2048 + 当语句的长度大于 `query-log-max-len`，将会被截断输出。 ### log.file @@ -84,31 +87,31 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ #### `filename` + 一般日志文件名字。 -+ 默认: "" ++ 默认："" + 如果设置，会输出一般日志到这个文件。 #### `max-size` + 日志文件的大小限制。 -+ 默认: 300MB ++ 默认：300MB + 最大设置上限为 4GB。 #### `max-days` + 日志最大保留的天数。 -+ 默认: 0 ++ 默认：0 + 默认是不清理的，如果设置了，在 `max-days` 之后 TiDB 会清理过期的日志文件。 #### `max-backups` + 保留的日志的最大数量。 -+ 默认: 0 ++ 默认：0 + 默认全部保存，如果设置为 7，会最多保留 7 个老的日志文件。 #### `log-rotate` + 是否每日创建一个新的日志文件。 -+ 默认: true ++ 默认：true + 如果设置为 true，每天会新建新的日志文件，如果设置为 false，那么只会输出到一个日志文件。 ## security @@ -117,22 +120,22 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ ### `ssl-ca` -+ PEM 格式的受信任 CA 的证书文件路径 -+ 默认: "" ++ PEM 格式的受信任 CA 的证书文件路径。 ++ 默认："" + 当同时设置了该选项和 `--ssl-cert`、`--ssl-key` 选项时，TiDB 将在客户端出示证书的情况下根据该选项指定的受信任的 CA 列表验证客户端证书。若验证失败，则连接会被终止。 + 即使设置了该选项，若客户端没有出示证书，则安全连接仍然继续，不会进行客户端证书验证。 ### `ssl-cert` -+ PEM 格式的 SSL 证书文件路径 -+ 默认: "" ++ PEM 格式的 SSL 证书文件路径。 ++ 默认："" + 当同时设置了该选项和 `--ssl-key` 选项时，TiDB 将接受（但不强制）客户端使用 TLS 安全地连接到 TiDB。 + 若指定的证书或私钥无效，则 TiDB 会照常启动，但无法接受安全连接。 ### `ssl-key` -+ PEM 格式的 SSL 证书密钥文件路径，即 `--ssl-cert` 所指定的证书的私钥 -+ 默认: "" ++ PEM 格式的 SSL 证书密钥文件路径，即 `--ssl-cert` 所指定的证书的私钥。 ++ 默认："" + 目前 TiDB 不支持加载由密码保护的私钥。 ## performance @@ -142,36 +145,36 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ ### `max-procs` + TiDB 的 CPU 使用数量。 -+ 默认: 0 -+ 默认为 0 表示使用机器上所有的 CPU，也可以设置成 n， 那么 TiDB 会使用 n 个 CPU 数量。 ++ 默认：0 ++ 默认为 0 表示使用机器上所有的 CPU，也可以设置成 n，那么 TiDB 会使用 n 个 CPU 数量。 ### `stmt-count-limit` + TiDB 一个事务允许的最大语句条数限制。 -+ 默认: 5000 ++ 默认：5000 + 在一个事务中，超过 `stmt-count-limit` 条语句后还没有 rollback 或者 commit，TiDB 将会返回 `statement count 5001 exceeds the transaction limitation, autocommit = false` 错误。 ### `tcp-keep-alive` -+ TiDB 在 TCP 层开启 keepalive -+ 默认: false ++ TiDB 在 TCP 层开启 keepalive。 ++ 默认：false ### `retry-limit` + TiDB 在提交事务的时候遇到 key 冲突或者其他错误时进行的重试次数。 -+ 默认: 10 ++ 默认：10 + 如果 TiDB 超过 `retry-limit` 次重试还是没有成功，将会返回错误。 ### `cross-join` -+ 默认: true ++ 默认：true + 在做 join 的时候，两边表没有任何条件（where 字段），默认可以执行这样的语句。但是设置为 false，则如有这样的 join 语句出现，server 会拒绝执行 ### `stats-lease` -+ TiDB 重载统计信息, 更新表行数, 检查是否需要自动 analyze 以及加载列的统计信息的时间间隔 -+ 默认: 3s - - 每隔 `stats-lease` 时间， TiDB 会检查统计信息是否有更新，如果有会将其更新到内存中 ++ TiDB 重载统计信息，更新表行数，检查是否需要自动 analyze 以及加载列的统计信息的时间间隔。 ++ 默认：3s + - 每隔 `stats-lease` 时间，TiDB 会检查统计信息是否有更新，如果有会将其更新到内存中 - 每隔 `5 * stats-lease` 时间，TiDB 会将 DML 产生的总行数以及修改的行数变化持久化下来 - 每隔 `stats-lease` 时间，TiDB 会检查是否有表或者索引需要自动 analyze - 每隔 `stats-lease` 时间，TiDB 会检查是否有列的统计信息需要被加载到内存中 @@ -179,12 +182,12 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ ### `run-auto-analyze` + TiDB 是否做自动的 Analyze。 -+ 默认: true ++ 默认：true ### `feedback-probability` -+ TiDB 对查询收集统计信息反馈的概率 -+ 默认: 0.0 ++ TiDB 对查询收集统计信息反馈的概率。 ++ 默认：0.0 + 对于每一个查询，TiDB 会以 `feedback-probability` 的概率收集查询的反馈，用于更新统计信息。 ## prepared-plan-cache @@ -194,24 +197,24 @@ prepare 语句的 Plan cache 设置。 ### `enabled` + 开启 prepare 语句的 plan cache。 -+ 默认: false ++ 默认：false ### `capacity` + 缓存语句的数量。 -+ 默认: 100 ++ 默认：100 ## tikv-client ### `grpc-connection-count` + 跟每个 TiKV 之间建立的最大连接数。 -+ 默认: 16 ++ 默认：16 ### `commit-timeout` + 执行事务提交时，最大的超时时间。 -+ 默认: 41s ++ 默认：41s + 这个值必须是大于两倍 Raft 选举的超时时间。 ## txn-local-latches @@ -221,9 +224,9 @@ prepare 语句的 Plan cache 设置。 ### `enable` + 开启 -+ 默认: false ++ 默认：false ### `capacity` -+ Hash 对应的 slot 数, 会自动向上调整为 2 的指数倍。每个 slot 占 32 Bytes 内存。当写入数据的范围比较广时（如导数据），设置过小会导致变慢，性能下降。 ++ Hash 对应的 slot 数，会自动向上调整为 2 的指数倍。每个 slot 占 32 Bytes 内存。当写入数据的范围比较广时（如导数据），设置过小会导致变慢，性能下降。 + 默认：1024000 diff --git a/op-guide/tidb-v2.0-upgrade-guide.md b/op-guide/tidb-v2.0-upgrade-guide.md index f718c9f4971b..c629acf65267 100644 --- a/op-guide/tidb-v2.0-upgrade-guide.md +++ b/op-guide/tidb-v2.0-upgrade-guide.md @@ -28,7 +28,9 @@ Name: jmespath Version: 0.9.0 ``` -> **注意**：请务必按以上文档安装 Ansible 及其依赖。确认 Jinja2 版本是否正确，否则启动 Grafana 时会报错。确认 jmespath 版本是否正确，否则滚动升级 TiKV 时会报错。 +> **注意：** +> +> 请务必按以上文档安装 Ansible 及其依赖。确认 Jinja2 版本是否正确，否则启动 Grafana 时会报错。确认 jmespath 版本是否正确，否则滚动升级 TiKV 时会报错。 ## 在中控机器上下载 TiDB-Ansible diff --git a/op-guide/tidb-v2.1-upgrade-guide.md b/op-guide/tidb-v2.1-upgrade-guide.md index a6d757270776..6030c1d37052 100644 --- a/op-guide/tidb-v2.1-upgrade-guide.md +++ b/op-guide/tidb-v2.1-upgrade-guide.md @@ -36,7 +36,9 @@ Name: jmespath Version: 0.9.3 ``` -> **注意**：请务必按以上文档安装 Ansible 及其依赖。确认 Jinja2 版本是否正确，否则启动 Grafana 时会报错。确认 jmespath 版本是否正确，否则滚动升级 TiKV 时会报错。 +> **注意：** +> +> 请务必按以上文档安装 Ansible 及其依赖。确认 Jinja2 版本是否正确，否则启动 Grafana 时会报错。确认 jmespath 版本是否正确，否则滚动升级 TiKV 时会报错。 ## 在中控机器上下载 TiDB-Ansible diff --git a/op-guide/tidb-v3.0-upgrade-guide.md b/op-guide/tidb-v3.0-upgrade-guide.md new file mode 100644 index 000000000000..2167704b8f2b --- /dev/null +++ b/op-guide/tidb-v3.0-upgrade-guide.md @@ -0,0 +1,134 @@ +--- +title: TiDB 3.0 升级操作指南 +category: upgrade +--- + +# TiDB 3.0 升级操作指南 + +本文档适用于从 TiDB 2.0 版本（v2.0.1 及之后版本）或 TiDB 2.1 RC 版本升级到 TiDB 3.0 版本。TiDB 3.0 版本兼容 [Kafka 版本的 TiDB-Binlog](/tools/binlog/tidb-binlog-kafka.md) 以及[集群模式的 TiDB-Binlog](/tools/binlog/overview.md)。 + +## 升级兼容性说明 + +- 不支持在升级后回退至 2.1.x 或更旧版本 +- 从 2.0.6 之前的版本升级到 3.0 之前，需要确认集群中是否存在正在运行中的 DDL 操作，特别是耗时的 `Add Index` 操作，等 DDL 操作完成后再执行升级操作 +- 2.1 及之后版本启用了并行 DDL，早于 2.0.1 版本的集群，无法滚动升级到 3.0，可以选择下面两种方案： + - 停机升级，直接从早于 2.0.1 的 TiDB 版本升级到 3.0 + - 先滚动升级到 2.0.1 或者之后的 2.0.x 版本，再滚动升级到 3.0 版本 + +> **注意：** +> +> 在升级的过程中不要执行 DDL 请求，否则可能会出现行为未定义的问题。 + +## 在中控机器上安装 Ansible 及其依赖 + +TiDB-Ansible release-3.0 版本依赖 2.5.14 Ansible 版本（`ansible=2.5.14`），另依赖 Python 模块：`jinja2>=2.9.6` 和 `jmespath>=0.9.0`。为方便管理依赖，新版本使用 `pip` 安装 Ansible 及其依赖，可参照[在中控机器上安装 Ansible 及其依赖](../op-guide/ansible-deployment.md#在中控机器上安装-ansible-及其依赖) 进行安装。离线环境参照[在中控机器上离线安装 Ansible 及其依赖](../op-guide/offline-ansible-deployment.md#在中控机器上离线安装-ansible-及其依赖)。 + +安装完成后，可通过以下命令查看版本： + +``` +$ ansible --version +ansible 2.5.14 +$ pip show jinja2 +Name: Jinja2 +Version: 2.10 +$ pip show jmespath +Name: jmespath +Version: 0.9.0 +``` + +> **注意：** +> +> 请务必按以上文档安装 Ansible 及其依赖。确认 Jinja2 版本是否正确，否则启动 Grafana 时会报错。确认 jmespath 版本是否正确，否则滚动升级 TiKV 时会报错。 + +## 在中控机器上下载 TiDB-Ansible + +以 `tidb` 用户登录中控机并进入 `/home/tidb` 目录，备份 TiDB 2.0 版本或 TiDB 2.1 版本的 tidb-ansible 文件夹： + +``` +$ mv tidb-ansible tidb-ansible-bak +``` + +下载 TiDB 3.0 版本对应 tag 的 tidb-ansible [**下载 TiDB-Ansible**](/op-guide/ansible-deployment.md#在中控机器上下载-tidb-ansible)，默认的文件夹名称为 `tidb-ansible`。 + +``` +$ git clone -b $tag https://github.com/pingcap/tidb-ansible.git +``` + +## 编辑 inventory.ini 文件和配置文件 + +以 `tidb` 用户登录中控机并进入 `/home/tidb/tidb-ansible` 目录。 + +### 编辑 `inventory.ini` 文件 + +编辑 `inventory.ini` 文件，IP 信息参照备份文件 `/home/tidb/tidb-ansible-bak/inventory.ini`。 + +以下变量配置，需要重点确认，变量含义可参考 [inventory.ini 变量调整](../op-guide/ansible-deployment.md#其他变量调整)。 + +1. 请确认 `ansible_user` 配置的是普通用户。为统一权限管理，不再支持使用 root 用户远程安装。默认配置中使用 `tidb` 用户作为 SSH 远程用户及程序运行用户。 + + ``` + ## Connection + # ssh via normal user + ansible_user = tidb + ``` + + 可参考[如何配置 ssh 互信及 sudo 规则](../op-guide/ansible-deployment.md#在中控机上配置部署机器-ssh-互信及-sudo-规则)自动配置主机间互信。 + +2. `process_supervision` 变量请与之前版本保持一致，默认推荐使用 `systemd`。 + + ``` + # process supervision, [systemd, supervise] + process_supervision = systemd + ``` + + 如需变更，可参考 [如何调整进程监管方式从 supervise 到 systemd](../op-guide/ansible-deployment.md#如何调整进程监管方式从-supervise-到-systemd)，先使用备份 `/home/tidb/tidb-ansible-bak/` 分支变更进程监管方式再升级。 + +### 编辑 TiDB 集群组件配置文件 + +如之前自定义过 TiDB 集群组件配置文件，请参照备份文件修改 `/home/tidb/tidb-ansible/conf` 下对应配置文件。 + +TiKV 配置中 `end-point-concurrency` 变更为 `high-concurrency`、`normal-concurrency` 和 `low-concurrency` 三个参数： + +``` +readpool: + coprocessor: + # Notice: if CPU_NUM > 8, default thread pool size for coprocessors + # will be set to CPU_NUM * 0.8. + # high-concurrency: 8 + # normal-concurrency: 8 + # low-concurrency: 8 +``` + +单机多 TiKV 实例情况下，需要修改这三个参数，推荐设置：`实例数 * 参数值 = CPU 核数 * 0.8`。 + +## 下载 TiDB 3.0 binary 到中控机 + +确认 `tidb-ansible/inventory.ini` 文件中 `tidb_version = v3.0.0`，然后执行以下命令下载 TiDB 3.0 binary 到中控机。 + +``` +$ ansible-playbook local_prepare.yml +``` + +## 滚动升级 TiDB 集群组件 + +> **注意：** +> +> 为优化 TiDB 集群组件的运维管理，TiDB 3.0 版本对 `systemd` 模式下的 `PD service` 名称进行了调整。与之前版本相比，滚动升级 TiDB 3.0 版本集群组件的操作略有不同，注意升级前后 `process_supervision` 参数配置须保持一致。 + +如果 `process_supervision` 变量使用默认的 `systemd` 参数，则通过 `excessive_rolling_update.yml` 滚动升级 TiDB 集群。 + +``` +$ ansible-playbook excessive_rolling_update.yml +``` + +如果 `process_supervision` 变量使用 `supervise` 参数，则通过 `rolling_update.yml` 滚动升级 TiDB 集群。 + +``` +$ ansible-playbook rolling_update.yml +``` + +## 滚动升级 TiDB 监控组件 + +``` +$ ansible-playbook rolling_update_monitor.yml +``` diff --git a/releases/2.1.9.md b/releases/2.1.9.md new file mode 100644 index 000000000000..2afc56c9c84d --- /dev/null +++ b/releases/2.1.9.md @@ -0,0 +1,68 @@ +--- +title: TiDB 2.1.9 Release Notes +category: Releases +--- + +# TiDB 2.1.9 Release Notes + +发版日期：2019 年 5 月 6 日 + +TiDB 版本：2.1.9 + +TiDB-Ansible 版本：2.1.9 + +## TiDB + +- 修复 `MAKETIME` 函数在 unsigned 类型溢出时的兼容性 [#10089](https://github.com/pingcap/tidb/pull/10089) +- 修复常量折叠在某些情况下导致的栈溢出 [#10189](https://github.com/pingcap/tidb/pull/10189) +- 修复 Update 在某些有别名的情况下权限检查的问题 [#10157](https://github.com/pingcap/tidb/pull/10157) [#10326](https://github.com/pingcap/tidb/pull/10326) +- 追踪以及控制 DistSQL 中的内存使用 [#10197](https://github.com/pingcap/tidb/pull/10197) +- 支持指定 collation 为 utf8mb4_0900_ai_ci [#10201](https://github.com/pingcap/tidb/pull/10201) +- 修复主键为 Unsigned 类型的时候，MAX 函数结果错误的问题 [#10209](https://github.com/pingcap/tidb/pull/10209) +- 修复在非 Strict SQL Mode 下可以插入 NULL 值到 NOT NULL 列的问题 [#10254](https://github.com/pingcap/tidb/pull/10254) +- 修复 COUNT 函数在 DISTINCT 有多列的情况下结果错误的问题 [#10270](https://github.com/pingcap/tidb/pull/10270) +- 修复 LOAD DATA 解析不规则的 CSV 文件时候 Panic 的问题 [#10269](https://github.com/pingcap/tidb/pull/10269) +- 忽略 Index Lookup Join 中内外 join key 类型不一致的时候出现的 overflow 错误 [#10244](https://github.com/pingcap/tidb/pull/10244) +- 修复某些情况下错误判定语句为 point-get 的问题 [#10299](https://github.com/pingcap/tidb/pull/10299) +- 修复某些情况下时间类型未转换时区导致的结果错误问题 [#10345](https://github.com/pingcap/tidb/pull/10345) +- 修复 TiDB 字符集在某些情况下大小写比较不一致的问题 [#10354](https://github.com/pingcap/tidb/pull/10354) +- 支持控制算子返回的行数 [#9166](https://github.com/pingcap/tidb/issues/9166) + - Selection & Projection [#10110](https://github.com/pingcap/tidb/pull/10110) + - StreamAgg & HashAgg [#10133](https://github.com/pingcap/tidb/pull/10133) + - TableReader & IndexReader & IndexLookup [#10169](https://github.com/pingcap/tidb/pull/10169) +- 慢日志改进 + - 增加 SQL Digest 用于区分同类 SQL [#10093](https://github.com/pingcap/tidb/pull/10093) + - 增加慢语句使用的统计信息的版本信息 [#10220](https://github.com/pingcap/tidb/pull/10220) + - 输出语句内存使用量 [#10246](https://github.com/pingcap/tidb/pull/10246) + - 调整 Coprocessor 相关信息的输出格式，让其能被 pt-query-digest 解析 [#10300](https://github.com/pingcap/tidb/pull/10300) + - 修复慢语句中带有 `#` 字符的问题 [#10275](https://github.com/pingcap/tidb/pull/10275) + - 增加一些信息的列到慢查询的内存表 [#10317](https://github.com/pingcap/tidb/pull/10317) + - 将事务提交时间算入慢语句执行时间 [#10310](https://github.com/pingcap/tidb/pull/10310) + - 修复某些时间格式无法被 pt-query-digest 解析的问题 [#10323](https://github.com/pingcap/tidb/pull/10323) +## PD + +- 支持 GetOperator 服务 [#1514](https://github.com/pingcap/pd/pull/1514) + +## TiKV + +- 修复在 transfer leader 时非预期的 quorum 变化 [#4604](https://github.com/tikv/tikv/pull/4604) + +## Tools + +- TiDB Binlog + - 修复 unsigned int 类型的主键列的 binlog 数据为负数，造成同步出错中断的问题 [#574](https://github.com/pingcap/tidb-binlog/pull/574) + - 删除下游是 `pb` 时的压缩选项，修改下游名字 `pb` 成 `file` [#597](https://github.com/pingcap/tidb-binlog/pull/575) + - 修复 2.1.7 引入的 Reparo 生成错误 update 语句的 bug [#576](https://github.com/pingcap/tidb-binlog/pull/576) +- TiDB Lightning + - 修复 parser 解析 bit 类型的 column 数据错误的 bug [#164](https://github.com/pingcap/tidb-lightning/pull/164) + - 使用 row id 或者列的默认值填充 dump 文件中缺少的 column 数据 [#174](https://github.com/pingcap/tidb-lightning/pull/174) + - Importer 修复部分 SST 导入失败依然返回导入成功的 bug [#4566](https://github.com/tikv/tikv/pull/4566) + - Importer 支持 upload SST 到 TiKV 限速 [#4607](https://github.com/tikv/tikv/pull/4607) + - 修改 Importer RocksDB SST 压缩方法为 `lz4`，减少 CPU 消耗 [#4624](https://github.com/tikv/tikv/pull/4624) +- sync-diff-inspector + - 支持 checkpoint [#227](https://github.com/pingcap/tidb-tools/pull/227) + +## TiDB-Ansible + +- 更新 tidb-ansible 中的文档链接，兼容重构之后的文档 [#740](https://github.com/pingcap/tidb-ansible/pull/740)，[#741](https://github.com/pingcap/tidb-ansible/pull/741) +- 移除 `inventory.ini` 中的 `enable_slow_query_log` 参数，默认即将 slow log 输出到单独的日志文件中 [#742](https://github.com/pingcap/tidb-ansible/pull/742) diff --git a/releases/205.md b/releases/205.md index ab57e8e02212..588bed594a4d 100644 --- a/releases/205.md +++ b/releases/205.md @@ -22,7 +22,7 @@ category: Releases - 支持注释中存在多个星号的情况 [#6858](https://github.com/pingcap/tidb/pull/6858) - Bug Fixes - 修复 `KILL QUERY` 语句权限检查问题 [#7003](https://github.com/pingcap/tidb/pull/7003) - - 修复用户数量超过 1024 时可能造成无法登陆的问题 [#6986](https://github.com/pingcap/tidb/pull/6986) + - 修复用户数量超过 1024 时可能造成无法登录的问题 [#6986](https://github.com/pingcap/tidb/pull/6986) - 修复一个写入无符号类型 `float`/`double` 数据的问题 [#6940](https://github.com/pingcap/tidb/pull/6940) - 修复 `COM_FIELD_LIST` 命令的兼容性，解决部分 MariaDB 客户端遇到 Panic 的问题 [#6929](https://github.com/pingcap/tidb/pull/6929) - 修复 `CREATE TABLE IF NOT EXISTS LIKE` 行为 [#6928](https://github.com/pingcap/tidb/pull/6928) diff --git a/releases/3.0.0-beta.1.md b/releases/3.0.0-beta.1.md index f02537adeb8e..96a971c6b60d 100644 --- a/releases/3.0.0-beta.1.md +++ b/releases/3.0.0-beta.1.md @@ -9,11 +9,11 @@ category: Releases TiDB 版本：3.0.0-beta.1 -TiDB-Ansible 版本：3.0.0-beta +TiDB-Ansible 版本：3.0.0-beta.1 ## Overview -2019 年 03 月 26 日，TiDB 发布 3.0.0 Beta.1 版，对应的 TiDB-Ansible 版本为 3.0.0 Beta。相比 3.0.0 Beta 版本，该版本对系统稳定性、易用性、功能、优化器、统计信息以及执行引擎做了很多改进。 +2019 年 03 月 26 日，TiDB 发布 3.0.0 Beta.1 版，对应的 TiDB-Ansible 版本为 3.0.0 Beta.1。相比 3.0.0 Beta 版本，该版本对系统稳定性、易用性、功能、优化器、统计信息以及执行引擎做了很多改进。 ## TiDB diff --git a/releases/3.0.0-rc.1.md b/releases/3.0.0-rc.1.md new file mode 100644 index 000000000000..96aea2e59dfe --- /dev/null +++ b/releases/3.0.0-rc.1.md @@ -0,0 +1,141 @@ +--- +title: TiDB 3.0.0-rc.1 Release Notes +category: Releases +--- + +# TiDB 3.0.0-rc.1 Release Notes + +发版日期：2019 年 5 月 10 日 + +TiDB 版本：3.0.0-rc.1 + +TiDB-Ansible 版本：3.0.0-rc.1 + +## Overview + +2019 年 5 月 10 日，TiDB 发布 3.0.0-rc.1 版，对应的 TiDB-Ansible 版本为 3.0.0-rc.1。相比 3.0.0-beta.1 版本，该版本对系统稳定性、易用性、功能、优化器、统计信息以及执行引擎做了很多改进。 + +## TiDB + ++ SQL 优化器 + - 利用列之间的顺序相关性提升代价估算准确度，并提供启发式参数 `tidb_opt_correlation_exp_factor` 用于控制在相关性无法被直接用于估算的场景下对索引扫描的偏好程度。[#9839](https://github.com/pingcap/tidb/pull/9839) + - 当过滤条件中包含相关列时，在抽取复合索引的访问条件时尽可能多地匹配索引的前缀列。[#10053](https://github.com/pingcap/tidb/pull/10053) + - 用动态规划决定连接的执行顺序，当参与连接的表数量不多于 `tidb_opt_join_reorder_threshold` 时启用。[#8816](https://github.com/pingcap/tidb/pull/8816) + - 在构造 Index Join 的的内表中，以复合索引作为访问条件时，尽可能多地匹配索引的前缀列。[#8471](https://github.com/pingcap/tidb/pull/8471) + - 提升对单列索引上值为 NULL 的行数估算准确度。[#9474](https://github.com/pingcap/tidb/pull/9474) + - 在逻辑优化阶段消除聚合函数时特殊处理 `GROUP_CONCAT` ，防止产生错误的执行结果。[#9967](https://github.com/pingcap/tidb/pull/9967) + - 当过滤条件为常量时，正确地将它下推到连接算子的子节点上。[#9848](https://github.com/pingcap/tidb/pull/9848) + - 在逻辑优化阶段列剪裁时特殊处理一些函数，例如 `RAND()` ，防止产生和 MySQL 不兼容的执行结果。[#10064](https://github.com/pingcap/tidb/pull/10064) + - 支持 `FAST ANALYZE`，通过`tidb_enable_fast_analyze` 变量控制。该特性通过用对 Region 进行采样取代扫描整个 region 的方式加速统计信息收集。[#10258](https://github.com/pingcap/tidb/pull/10258) + - 支持 `SQL PLAN MANAGEMENT`。该特性通过对 SQL 进行执行计划绑定，以确保执行稳定性。该特性目前处于测试阶段，仅支持对 SELECT 语句使用绑定的执行计划，不建议在生产场景中直接使用。[#10284](https://github.com/pingcap/tidb/pull/10284) + ++ 执行引擎 + - 支持对 `TableReader`、`IndexReader` 和 `IndexLookupReader` 算子进行内存追踪控制。[#10003](https://github.com/pingcap/tidb/pull/10003) + - 在慢日志中展示更多 COPROCESSOR 端执行任务相关细节。如 COPROCESSOR 任务数，平均/最长/90% 执行/等待时间，执行/等待时间最长的 TiKV 地址等。[#10165](https://github.com/pingcap/tidb/pull/10165) + - 支持 PREPARE 不含占位符的 DDL 语句。[#10144](https://github.com/pingcap/tidb/pull/10144) + ++ Server + - TiDB 启动时，只允许 DDL owner 执行 bootstrap [#10029](https://github.com/pingcap/tidb/pull/10029) + - 新增 `tidb_skip_isolation_level_check` 变量控制检查隔离级别设置为 SERIALIZABLE 时不报错 [#10065](https://github.com/pingcap/tidb/pull/10065) + - 在慢日志中，将隐式提交的时间与 SQL 执行时间融合在一起 [#10294](https://github.com/pingcap/tidb/pull/10294) + + RBAC 权限管理 + - 支持 `SHOW GRANT` [#10016](https://github.com/pingcap/tidb/pull/10016) + - 支持 `SET DEFAULT ROLE` [#9949](https://github.com/pingcap/tidb/pull/9949) + - 支持 `GRANT ROLE` [#9721](https://github.com/pingcap/tidb/pull/9721) + - 修正了插件退出时导致 TiDB 退出的问题 [#9889](https://github.com/pingcap/tidb/pull/9889) + - 修正只读语句被错误地放到事务历史中的问题 [#9723](https://github.com/pingcap/tidb/pull/9723) + - kill 语句可以更快的结束 SQL 的执行，并快速释放资源 [#9844](https://github.com/pingcap/tidb/pull/9844) + - 增加启动选项 `config-check` 来检查配置文件的合法性 [#9855](https://github.com/pingcap/tidb/pull/9855) + - 修正非严格模式下对于写入 NULL 字段的合法性检查 [#10161](https://github.com/pingcap/tidb/pull/10161) + ++ DDL + - 为 CREATE TABLE 添加了 pre_split_regions 选项，该选项可以在建表时预先分配 Table Region，避免建表后大量写入造成的写热点 [#10138](https://github.com/pingcap/tidb/pull/10138) + - 优化了部分 DDL 语句的执行性能 [#10170](https://github.com/pingcap/tidb/pull/10170) + - FULLTEXT KEY 新增不支持全文索引的 warning [#9821](https://github.com/pingcap/tidb/pull/9821) + - 修正了旧版本 TiDB 中，UTF8 和 UTF8MB4 编码的兼容性问题 [#9820](https://github.com/pingcap/tidb/pull/9820) + - 修正了一个表的 shard_row_id_bits 的潜在 BUG [#9868](https://github.com/pingcap/tidb/pull/9868) + - 修正了 ALTER TABLE Charset 后，Column Charset 不会跟随变化的 BUG [#9790](https://github.com/pingcap/tidb/pull/9790) + - 修正了使用 BINARY/BIT 作为 Column Default Value 时，SHOW COLUMN 可能出错的 BUG [#9897](https://github.com/pingcap/tidb/pull/9897) + - 修正了 SHOW FULL COLUMNS 语句中，CHARSET / COLLATION 显示的兼容性问题 [#10007](https://github.com/pingcap/tidb/pull/10007) + - 现在 SHOW COLLATIONS 语句只会列出 TiDB 所实际支持的 COLLATIONS [#10186](https://github.com/pingcap/tidb/pull/10186) + +## PD + ++ 升级 ETCD 版本 [#1452](https://github.com/pingcap/pd/pull/1452) + - 统一 etcd 的日志格式与 pd server 一致 + - 修复 prevote 可能无法选出 Leader 的问题 + - 快速 drop 掉会失败的 propose 和 read 请求，减少阻塞后面的请求时间 + - 修复 Lease 的死锁问题 +- 修复 store 读热点的 keys 统计不正确问题 [#1487](https://github.com/pingcap/pd/pull/1487) +- 支持从单一 PD 节点强制重建 PD 集群 [#1485](https://github.com/pingcap/pd/pull/1485) +- 修复 Scatter Region 产生无效 Operator Step 的问题 [#1482](https://github.com/pingcap/pd/pull/1482) +- 修复 Region Merge Operator 超时时间过短的问题 [#1495](https://github.com/pingcap/pd/pull/1495) +- 热点调度使用高优先级 [#1492](https://github.com/pingcap/pd/pull/1492) +- 添加 PD server 端处理 TSO 请求的耗时 Metrics [#1502](https://github.com/pingcap/pd/pull/1502) +- 添加相对应的 Store ID 和 Address 到 store 相关的 Metrics [#1506](https://github.com/pingcap/pd/pull/1506) +- 支持 GetOperator 服务 [#1477](https://github.com/pingcap/pd/pull/1477) +- 修复 Heartbeat stream 下发送 error 找不到 store 的问题 [#1521](https://github.com/pingcap/pd/pull/1521) + +## TiKV + ++ Engine + - 修复读流量统计不准确问题 [#4436](https://github.com/tikv/tikv/pull/4436) + - 修复 prefix extractor panic 的问题 [#4503](https://github.com/tikv/tikv/pull/4503) + - 优化内存管理，减少 `Iterator Key Bound Option` 的内存分配和拷贝 [#4537](https://github.com/tikv/tikv/pull/4537) + - 修复 Merge Region 时未考虑 Learner log gap 造成的 panic 问题 [#4559](https://github.com/tikv/tikv/pull/4559) + - 支持不同的 `column families` 共享 `block cache` [#4612](https://github.com/tikv/tikv/pull/4612) ++ Server + - 减少 `batch commands` 的上下文切换开销 [#4473](https://github.com/tikv/tikv/pull/4473) + - 检查 seek iterator status 的合法性 [#4470](https://github.com/tikv/tikv/pull/4470) ++ RaftStore + - 可配置化 `properties index distance` [#4517](https://github.com/tikv/tikv/pull/4517) ++ Coprocessor + - 新增 batch index scan executor [#4419](https://github.com/tikv/tikv/pull/4419) + - 新增向量化 evaluation 框架 [#4322](https://github.com/tikv/tikv/pull/4322) + - 新增 batch 执行器统计框架 [#4433](https://github.com/tikv/tikv/pull/4433) + - 构建 RPN expression 时检查 max column 以防止 evaluation 阶段 column offset 越界的问题 [#4481](https://github.com/tikv/tikv/pull/4481) + - 实现 `BatchLimitExecutor` [#4469](https://github.com/tikv/tikv/pull/4469) + - ReadPool 使用 `tokio-threadpool` 替换原本的 `futures-cpupool`，减少 context switch [#4486](https://github.com/tikv/tikv/pull/4486) + - 新增 batch 聚合框架 [#4533](https://github.com/tikv/tikv/pull/4533) + - 新增 `BatchSelectionExecutor` [#4562](https://github.com/tikv/tikv/pull/4562) + - 实现 batch aggression function `AVG` [#4570](https://github.com/tikv/tikv/pull/4570) + - 实现 RPN function `LogicalAnd` [#4575](https://github.com/tikv/tikv/pull/4575) ++ Misc + - 支持选用 tcmalloc 为内存分配器 [#4370](https://github.com/tikv/tikv/pull/4370) + +## Tools + ++ TiDB-Binlog + - 修复 unsigned int 类型的主键列的 binlog 数据为负数，造成同步出错中断的问题 [#573](https://github.com/pingcap/tidb-binlog/pull/573) + - 删除下游是 pb 时的压缩选项，修改下游名字 pb 成 file [#559](https://github.com/pingcap/tidb-binlog/pull/559) + - Pump 新增 storage.sync-log 配置项，支持 Pump 本地存储异步刷盘 [#509](https://github.com/pingcap/tidb-binlog/pull/509) + - Pump 和 Drainer 之间通讯支持流量压缩 [#495](https://github.com/pingcap/tidb-binlog/pull/495) + - Drainer 新增 syncer.sql-mode 配置项，支持使用不同 sql-mode 解析 DDL query [#511](https://github.com/pingcap/tidb-binlog/pull/511) + - Drainer 新增 syncer.ignore-table 配置项，支持过滤不需要同步的表 [#520](https://github.com/pingcap/tidb-binlog/pull/520) ++ Lightning + - 使用 row id 或者列的默认值填充 dump 文件中缺少的 column 数据 [#170](https://github.com/pingcap/tidb-lightning/pull/170) + - Importer 修复部分 SST 导入失败依然返回导入成功的 bug [#4566](https://github.com/tikv/tikv/pull/4566) + - Importer 支持 upload SST 到 TiKV 限速 [#4412](https://github.com/tikv/tikv/pull/4412) + - Lightning 优化导入表的顺序，按照表的数据大小顺序进行导入，减少导入过程中大表执行 checksum 和 Analyze 对集群的影响，并且提高 Checksum 和 Analyze 的成功率 [#156](https://github.com/pingcap/tidb-lightning/pull/156) + - 提升 Lightning encode SQL 性能，性能提升 50%，直接解析数据源文件内容成 TiDB 的 types.Datum，省去 KV encoder 的多余解析工作 [#145](https://github.com/pingcap/tidb-lightning/pull/145) + - 日志格式改为 [Unified Log Format](https://github.com/tikv/rfcs/blob/master/text/2018-12-19-unified-log-format.md) [#162](https://github.com/pingcap/tidb-lightning/pull/162) + - 新增一些命令行选项，即使缺少配置文件也能使用。[#157](https://github.com/pingcap/tidb-lightning/pull/157) ++ 数据同步对比工具 (sync-diff-inspector) + - 支持 checkpoint，记录校验状态，重启后从上次进度继续校验 [#224](https://github.com/pingcap/tidb-tools/pull/224) + - 增加配置项 only-use-checksum，只通过计算 checksum 来检查数据是否一致 [#215](https://github.com/pingcap/tidb-tools/pull/215) + +## TiDB-Ansible + ++ TiKV 监控变更以及更新 Ansible、Grafana、Prometheus 版本 [#727](https://github.com/pingcap/tidb-ansible/pull/727) + - summary 监控适用于用户查看集群状态 + - trouble_shooting 监控适用于 DBA 排查问题 + - details 监控适用于开发分析问题 +- 修复下载 Kafka 版本 Binlog 失败的 BUG [#730](https://github.com/pingcap/tidb-ansible/pull/730) +- 修改操作系统版本限制，仅支持 CentOS 7.0 及以上，Red Hat 7.0 及以上版本的操作系统 [#733](https://github.com/pingcap/tidb-ansible/pull/733) +- 滚动升级时的版本检测改为多并发 [#736](https://github.com/pingcap/tidb-ansible/pull/736) +- 更新 README 中文档链接[#740](https://github.com/pingcap/tidb-ansible/pull/740) +- 移除重复的 TiKV 监控项，新增 trouble shooting 监控项 [#735](https://github.com/pingcap/tidb-ansible/pull/735) +- 优化 `table-regions.py` 脚本，按表显示 leader 分布 [#739](https://github.com/pingcap/tidb-ansible/pull/739) +- 更新 drainer 配置文件 [#745](https://github.com/pingcap/tidb-ansible/pull/745) +- 优化 TiDB 监控，新增以 SQL 类别显示延迟的监控项 [#747](https://github.com/pingcap/tidb-ansible/pull/747) +- 更新 Lightning 配置文件，新增 tidb_lightning_ctl 脚本 [#1e946f8](https://github.com/pingcap/tidb-ansible/commit/1e946f89908e8fd6ef84128c6da3064ddfccf6a8) diff --git a/releases/rn.md b/releases/rn.md index bb3417e7d011..07e355f7f68b 100644 --- a/releases/rn.md +++ b/releases/rn.md @@ -9,11 +9,13 @@ TiDB 历史版本发布声明如下： ## 3.0 -- [3.0.0 Beta.1](../releases/3.0.0-beta.1.md) -- [3.0 Beta](../releases/3.0beta.md) +- [3.0.0-rc.1](../releases/3.0.0-rc.1.md) +- [3.0.0-beta.1](../releases/3.0.0-beta.1.md) +- [3.0.0-beta](../releases/3.0beta.md) ## 2.1 +- [2.1.9](../releases/2.1.9.md) - [2.1.8](../releases/2.1.8.md) - [2.1.7](../releases/2.1.7.md) - [2.1.6](../releases/2.1.6.md) diff --git a/sql/aggregate-group-by-functions.md b/sql/aggregate-group-by-functions.md index 58f5e344fede..9babc180e351 100644 --- a/sql/aggregate-group-by-functions.md +++ b/sql/aggregate-group-by-functions.md @@ -21,7 +21,7 @@ TiDB 支持的 MySQL GROUP BY 聚合函数如下所示： | [`MIN()`](https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_min) | 返回最小值 | | [`GROUP_CONCAT()`](https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_group-concat) | 返回连接的字符串 | -> **注意**： +> **注意：** > > - 除非另有说明，否则组函数默认忽略 `NULL` 值。 > - 如果在不包含 `GROUP BY` 子句的语句中使用组函数，则相当于对所有行进行分组。 diff --git a/sql/character-set-support.md b/sql/character-set-support.md index 17f436caf851..1fbc67989f93 100644 --- a/sql/character-set-support.md +++ b/sql/character-set-support.md @@ -26,7 +26,9 @@ mysql> SHOW CHARACTER SET; 5 rows in set (0.00 sec) ``` -> **注意**：在 `TiDB` 中实际上 `utf8` 被当做成了 `utf8mb4` 来处理。 +> **注意：** +> +> 在 `TiDB` 中实际上 `utf8` 被当做成了 `utf8mb4` 来处理。 对于字符集来说，至少会有一个 Collation（排序规则）与之对应。而大部分字符集实际上会有多个 Collation。利用以下的语句可以查看： @@ -62,7 +64,9 @@ mysql> SHOW COLLATION WHERE Charset = 'latin1'; 每一个字符集，都有一个默认的 Collation，例如 `utf8` 的默认 Collation 就为 `utf8_bin`。 -**注意** `TiDB` 目前的 Collation 都是区分大小写的。 +> **注意：** +> +> `TiDB` 目前的 Collation 都是区分大小写的。 ## Collation 命名规则 @@ -80,7 +84,9 @@ mysql> SHOW COLLATION WHERE Charset = 'latin1'; | \_ci | 大小写不敏感 | | \_cs | 大小写敏感 | -> **注意**：目前为止 TiDB 只支持部分以上提到的 Collation。 +> **注意：** +> +> 目前为止 TiDB 只支持部分以上提到的 Collation。 ## 数据库 Character Set 和 Collation diff --git a/sql/date-and-time-types.md b/sql/date-and-time-types.md index 6bbcae8257da..4d5a95d0fcb0 100644 --- a/sql/date-and-time-types.md +++ b/sql/date-and-time-types.md @@ -45,7 +45,9 @@ TiDB 将 TIMESTAMP 从当前时区转成 UTC 时区存储，检索时再从 UTC 不合法的 DATE，DATETIME，TIMESTAMP 值会被自动地转成相应类型的零值（'0000-00-00' 或 '0000-00-00 00:00:00'）。 -注意，TIMESTAMP 类型的值是不允许月份或者日里面出现零的，唯一的例外是零值本身 '0000-00-00 00:00:00'。 +> **注意：** +> +> TIMESTAMP 类型的值是不允许月份或者日里面出现零的，唯一的例外是零值本身 '0000-00-00 00:00:00'。 两位数的年份是有歧义的，会按照如下规则解释： @@ -58,7 +60,9 @@ TIME 类型的值的格式是 'HH:MM:SS'，值的范围是 '-838:59:59' 到 '838 TIME 类型可以包含分数部分，如果包含分数部分，那么 TIME 的表示范围则是 '-838:59:59.000000' 到 '838:59:59.000000'。 -注意缩写的时间，'11:12' 表示的是 '11:12:00' 而不是 '00:11:12'，然而 '1112' 表示的是 '00:11:12'。这里的区别是是否包含分号 :，处理起来是不一样的。 +> **注意：** +> +> 关于缩写的时间，'11:12' 表示的是 '11:12:00' 而不是 '00:11:12'，然而 '1112' 表示的是 '00:11:12'。这里的区别是是否包含分号 :，处理起来是不一样的。 ## YEAR 类型 diff --git a/sql/ddl.md b/sql/ddl.md index 66cec98e4da6..f70b221377ac 100644 --- a/sql/ddl.md +++ b/sql/ddl.md @@ -207,7 +207,9 @@ TRUNCATE [TABLE] tbl_name 此操作于删除指定表全表数据的操作类似，但是操作的执行速度会远快于删除全表的速度，且不受表内数据行数影响。 -> **注意**：使用此语句后，原先表内的 `AUTO_INCREMENT` 的值不会记录，会被重新计数。 +> **注意：** +> +> 使用此语句后，原先表内的 `AUTO_INCREMENT` 的值不会记录，会被重新计数。 ## RENAME TABLE 语法 diff --git a/sql/dml.md b/sql/dml.md index 54adc9c47a4a..1f0493776c20 100644 --- a/sql/dml.md +++ b/sql/dml.md @@ -49,7 +49,7 @@ SELECT |`HAVING where_condition` | Having 子句与 Where 子句作用类似，Having 子句可以让过滤 GroupBy 后的各种数据，Where 子句用于在聚合前过滤记录。| |`ORDER BY` | OrderBy 子句用于指定结果排序顺序，可以按照列、表达式或者是 `select_expr` 列表中某个位置的字段进行排序。| |`LIMIT` | Limit 子句用于限制结果条数。Limit 接受一个或两个数字参数，如果只有一个参数，那么表示返回数据的最大行数；如果是两个参数，那么第一个参数表示返回数据的第一行的偏移量（第一行数据的偏移量是 0），第二个参数指定返回数据的最大条目数。| -|`FOR UPDATE` | 对查询结果集所有数据上读锁，以监测其他事务对这些的并发修改。TiDB 使用[乐观事务模型](../sql/mysql-compatibility.md#事务)在语句执行期间不会检测锁冲突，在事务的提交阶段才会检测事务冲突，如果执行 Select For Update 期间，有其他事务修改相关的数据，那么包含 Select For Update 语句的事务会提交失败。| +|`FOR UPDATE` | 对查询结果集所有数据上读锁（对于在查询条件内，但是不在结果集的数据，将不会加锁，如事务启动后由其他事务写入的数据），以监测其他事务对这些的并发修改。TiDB 使用[乐观事务模型](../sql/mysql-compatibility.md#事务)在语句执行期间不会检测锁冲突，在事务的提交阶段才会检测事务冲突，如果执行 Select For Update 期间，有其他事务修改相关的数据，那么包含 Select For Update 语句的事务会提交失败。| |`LOCK IN SHARE MODE` | TiDB 出于兼容性解析这个语法，但是不做任何处理| ## Insert 语句 diff --git a/sql/error.md b/sql/error.md index 997414531266..1ea059f0fa19 100644 --- a/sql/error.md +++ b/sql/error.md @@ -21,7 +21,7 @@ TiDB 兼容 MySQL 的错误码，在大多数情况下，返回和 MySQL 一样 | 9003 | TiKV 操作繁忙，一般出现在数据库负载比较高时，请检查 TiKV Server 状态/监控/日志 | | 9004 | 当数据库上承载的业务存在大量的事务冲突时，会遇到这种错误，请检查业务代码 | | 9005 | 某个 Raft Group 不可用，如副本数目不足，出现在 TiKV 比较繁忙或者是 TiKV 节点停机的时候，请检查 TiKV Server 状态/监控/日志 | -| 9006 | GC Life Time 间隔时间过短，长事务本应读到的数据可能被清理了,应增加GC Life Time | +| 9006 | GC Life Time 间隔时间过短，长事务本应读到的数据可能被清理了，应增加 GC Life Time | | 9500 | 单个事务过大，原因及解决方法请参考[这里](../FAQ.md#出现-transaction-too-large-报错怎么办) | ## 故障诊断 diff --git a/sql/generated-columns.md b/sql/generated-columns.md index 2d27746880fd..592e68b29e02 100644 --- a/sql/generated-columns.md +++ b/sql/generated-columns.md @@ -8,7 +8,7 @@ category: user guide 为了在功能上兼容 MySQL 5.7，TiDB 支持 generated column。Generated column 的主要的作用之一：从 JSON 数据类型中解出数据，并为该数据建立索引。 -## 使用 generated column 对 JSON 建索引 +## 使用 generated stored column 对 JSON 建索引 MySQL 5.7 及 TiDB 都不能直接为 JSON 类型的列添加索引，即**不支持**如下表结构： @@ -21,34 +21,40 @@ CREATE TABLE person ( ); ``` -为 JSON 列添加索引之前，首先必须抽取该列为 generated column。以 `city` generated column 为例，你可以添加索引： +为 JSON 列添加索引之前，首先必须抽取该列为 generated stored column。 + +> **注意：** +> +> 必须是 generated stored column 上建立的索引才能被优化器使用到，如果在 generated virtual column 上建立索引，优化器目前将无法使用这个索引，会在后续版本中改进（ISSUE [#5189](https://github.com/pingcap/tidb/issues/5189)）。 + +以 `city` generated stored column 为例，你可以添加索引： ```sql CREATE TABLE person ( id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, name VARCHAR(255) NOT NULL, address_info JSON, - city VARCHAR(64) AS (JSON_UNQUOTE(JSON_EXTRACT(address_info, '$.city'))) VIRTUAL, + city VARCHAR(64) AS (JSON_UNQUOTE(JSON_EXTRACT(address_info, '$.city'))) STORED, KEY (city) ); ``` -该表中，`city` 列是一个 **generated column**。顾名思义，此列由该表的其他列生成，对此列进行插入或更新操作时，并不能对之赋值。此列按需生成，并不存储在数据库中，也不占用内存空间，因而是**虚拟的**。`city` 列的索引**存储在数据库中**，并使用和 `varchar(64)` 类的其他索引相同的结构。 +该表中，`city` 列是一个 **generated stored column**。顾名思义，此列由该表的其他列生成，对此列进行插入或更新操作时，并不能对之赋值。此列按其定义的表达式生成，并存储在数据库中，这样在读取此列时，就可以直接读取，不用再读取其依赖的 `address_info` 列后再计算得到。`city` 列的索引**存储在数据库中**，并使用和 `varchar(64)` 类的其他索引相同的结构。 -可使用 generated column 的索引，以提高如下语句的执行速度： +可使用 generated stored column 的索引，以提高如下语句的执行速度： ```sql SELECT name, id FROM person WHERE city = 'Beijing'; ``` -如果 `$.city` 路径中无数据，则 `JSON_EXTRACT` 返回 `NULL`。如果你想增加约束：`city` 列必须是`NOT NULL`，则可按照以下方式定义 virtual column： +如果 `$.city` 路径中无数据，则 `JSON_EXTRACT` 返回 `NULL`。如果想增加约束，`city` 列必须是 `NOT NULL`，则可按照以下方式定义 virtual column： ```sql CREATE TABLE person ( id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, name VARCHAR(255) NOT NULL, address_info JSON, - city VARCHAR(64) AS (JSON_UNQUOTE(JSON_EXTRACT(address_info, '$.city'))) VIRTUAL NOT NULL, + city VARCHAR(64) AS (JSON_UNQUOTE(JSON_EXTRACT(address_info, '$.city'))) STORED NOT NULL, KEY (city) ); ``` @@ -60,6 +66,19 @@ mysql> INSERT INTO person (name, address_info) VALUES ('Morgan', JSON_OBJECT('Co ERROR 1048 (23000): Column 'city' cannot be null ``` +## 使用 generated virtual column + +TiDB 也支持 generated virtual column，和 generated store column 不同的是，此列按需生成，并不存储在数据库中，也不占用内存空间，因而是**虚拟的**。TiDB 虽然支持在 generated virtual column 上建立索引，优化器目前将无法使用这个索引，所以这个索引将没有意义，会在后续版本中改进（ISSUE [#5189](https://github.com/pingcap/tidb/issues/5189)）。 + +```sql +CREATE TABLE person ( + id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, + name VARCHAR(255) NOT NULL, + address_info JSON, + city VARCHAR(64) AS (JSON_UNQUOTE(JSON_EXTRACT(address_info, '$.city'))) VIRTUAL +); +``` + ## 局限性 目前 JSON and generated column 有以下局限性： diff --git a/sql/literal-value-null-values.md b/sql/literal-value-null-values.md index 865081433d36..d821d3f59811 100644 --- a/sql/literal-value-null-values.md +++ b/sql/literal-value-null-values.md @@ -7,4 +7,6 @@ category: user guide `NULL` 代表数据为空，它是大小写不敏感的，与 `\N`(大小写敏感) 同义。 -需要注意的是 `NULL` 跟 `0` 并不一样，跟空字符串 `''` 也不一样。 +> **注意：** +> +> `NULL` 跟 `0` 并不一样，跟空字符串 `''` 也不一样。 diff --git a/sql/literal-values.md b/sql/literal-values.md index 7069f1274185..cf6eb3f45a1a 100644 --- a/sql/literal-values.md +++ b/sql/literal-values.md @@ -89,7 +89,9 @@ integer 可以包括 `.` 作为小数点分隔，数字前可以有 `-` 或者 ` `NULL` 代表数据为空，它是大小写不敏感的，与 `\N`(大小写敏感) 同义。 -需要注意的是 `NULL` 跟 `0` 并不一样，跟空字符串 `''` 也不一样。 +> **注意：** +> +> `NULL` 跟 `0` 并不一样，跟空字符串 `''` 也不一样。 ## Hexadecimal Literals diff --git a/sql/mysql-compatibility.md b/sql/mysql-compatibility.md index a01b2a8d2b4b..08cec825ea4d 100644 --- a/sql/mysql-compatibility.md +++ b/sql/mysql-compatibility.md @@ -11,7 +11,9 @@ TiDB 支持 MySQL 传输协议及其绝大多数的语法。这意味着您现 不过一些特性由于在分布式环境下没法很好的实现，目前暂时不支持或者是表现与 MySQL 有差异。一些 MySQL 语法在 TiDB 中可以解析通过，但是不会做任何后续的处理，例如 `Create Table` 语句中 `Engine` 以及 `Partition` 选项，都是解析并忽略。 -> **注意**：本页内容仅涉及 MySQL 与 TiDB 的总体差异。关于[与 MySQL 安全特性差异](../sql/security-compatibility.md)及[事务模型](../sql/transaction-model.md)的兼容信息请查看各自具体页面。 +> **注意：** +> +> 本页内容仅涉及 MySQL 与 TiDB 的总体差异。关于[与 MySQL 安全特性差异](../sql/security-compatibility.md)及[事务模型](../sql/transaction-model.md)的兼容信息请查看各自具体页面。 ## 不支持的特性 diff --git a/sql/optimizer-hints.md b/sql/optimizer-hints.md index 03c91dedca47..04c6419e81ea 100644 --- a/sql/optimizer-hints.md +++ b/sql/optimizer-hints.md @@ -7,7 +7,9 @@ category: user guide TiDB 支持 Optimizer Hints 语法，它基于 MySQL 5.7 中介绍的类似 comment 的语法，例如 `/*+ TIDB_XX(t1, t2) */`。当 TiDB 优化器选择的不是最优查询计划时，建议使用 Optimizer Hints。 -> **注意**：MySQL 命令行客户端在 5.7.7 版本之前默认清除了 Optimizer Hints。如果需要在这些早期版本的客户端中使用 `Hint` 语法，需要在启动客户端时加上 `--comments` 选项，例如 `mysql -h 127.0.0.1 -P 4000 -uroot --comments`。 +> **注意：** +> +> MySQL 命令行客户端在 5.7.7 版本之前默认清除了 Optimizer Hints。如果需要在这些早期版本的客户端中使用 `Hint` 语法，需要在启动客户端时加上 `--comments` 选项，例如 `mysql -h 127.0.0.1 -P 4000 -uroot --comments`。 ## 语法 diff --git a/sql/privilege.md b/sql/privilege.md index a96c63eb1348..7b8aa795d160 100644 --- a/sql/privilege.md +++ b/sql/privilege.md @@ -5,76 +5,13 @@ category: user guide # 权限管理 -## 权限管理概述 +TiDB 的权限管理系统按照 MySQL 的权限管理进行实现，TiDB 支持大部分的 MySQL 的语法和权限类型。 -TiDB 的权限管理系统是按照 MySQL 的权限管理进行实现，大部分的 MySQL 的语法和权限类型都是支持的。如果发现行为跟 MySQL 不一致的地方，欢迎[提 issue](https://github.com/pingcap/tidb/issues/new/choose)。 +本文档主要介绍 TiDB 权限相关操作、各项操作需要的权限以及权限系统的实现。 -## 示例 +## 权限相关操作 -### 用户账户操作 - -TiDB 的用户账户名由一个用户名和一个主机名组成。账户名的语法为 `'user_name'@'host_name'`。 - -- `user_name` 大小写敏感。 -- `host_name` 可以是一个主机名或 IP 地址。主机名或 IP 地址中允许使用通配符 `%` 和 `_`。例如，名为 `'%'` 的主机名可以匹配所有主机，`'192.168.1.%'` 可以匹配子网中的所有主机。 - -#### 添加用户 - -```sql -CREATE USER 'test'@'127.0.0.1' IDENTIFIED BY 'xxx'; -``` - -host 支持模糊匹配，比如： - -```sql -CREATE USER 'test'@'192.168.10.%'; -``` - -允许 `test` 用户从 `192.168.10` 子网的任何一个主机登陆。 - -如果没有指定 host，则默认是所有 IP 均可登陆。如果没有指定密码，默认为空： - -```sql -CREATE USER 'test'; -``` - -等价于 - -```sql -CREATE USER 'test'@'%' IDENTIFIED BY ''; -``` - -#### 更改密码 - -```sql -SET PASSWORD FOR 'root'@'%' = 'xxx'; -``` - -#### 删除用户 - -```sql -DROP USER 'test'@'%'; -``` - -这个操作会清除用户在 `mysql.user` 表里面的记录项，并且清除在授权表里面的相关记录。 - -#### 忘记 root 密码 - -使用一个特殊的启动参数启动 TiDB（需要 root 权限）： - -```bash -sudo ./tidb-server -skip-grant-table=true -``` - -这个参数启动，TiDB 会跳过权限系统，然后使用 root 登陆以后修改密码： - -```bash -mysql -h 127.0.0.1 -P 4000 -u root -``` - -### 权限相关操作 - -#### 授予权限 +### 授予权限 授予 `xxx` 用户对数据库 `test` 的读权限： @@ -82,7 +19,7 @@ mysql -h 127.0.0.1 -P 4000 -u root GRANT SELECT ON test.* TO 'xxx'@'%'; ``` -为 test 用户授予所有数据库，全部权限： +为 `xxx` 用户授予所有数据库，全部权限： ```sql GRANT ALL PRIVILEGES ON *.* TO 'xxx'@'%'; @@ -106,7 +43,7 @@ mysql> SELECT user,host FROM mysql.user WHERE user='xxxx'; 1 row in set (0.00 sec) ``` -例子中 `xxxx@%` 就是自动添加进去的用户。 +上述示例中，`xxxx@%` 即自动添加的用户。 `GRANT` 对于数据库或者表的授权，不检查数据库或表是否存在。 @@ -143,7 +80,7 @@ mysql> SELECT user,host,db FROM mysql.db WHERE user='genius'; 这个例子中通过 `%` 模糊匹配，所有 `te` 开头的数据库，都被授予了权限。 -#### 收回权限 +### 收回权限 `REVOKE` 语句与 `GRANT` 对应： @@ -151,7 +88,9 @@ mysql> SELECT user,host,db FROM mysql.db WHERE user='genius'; REVOKE ALL PRIVILEGES ON `test`.* FROM 'genius'@'localhost'; ``` -> **注意**：revoke 收回权限时只做精确匹配，若找不到记录则报错。而 grant 授予权限时可以使用模糊匹配。 +> **注意：** +> +> `REVOKE` 收回权限时只做精确匹配，若找不到记录则报错。而 `GRANT` 授予权限时可以使用模糊匹配。 ```sql mysql> REVOKE ALL PRIVILEGES ON `te%`.* FROM 'genius'@'%'; @@ -165,9 +104,9 @@ mysql> GRANT ALL PRIVILEGES ON `te\%`.* TO 'genius'@'localhost'; Query OK, 0 rows affected (0.00 sec) ``` -上述例子是精确匹配名叫 `te%` 的数据库，注意使用 `\` 转义字符。 +上述例子是精确匹配名为 `te%` 的数据库，注意使用 `\` 转义字符。 -以单引号包含的，是一个字符串。以反引号包含的，是一个 identifier。注意下面的区别： +以单引号包含的部分，是一个字符串。以反引号包含的部分，是一个 identifier。注意下面的区别： ```sql mysql> GRANT ALL PRIVILEGES ON 'test'.* TO 'genius'@'localhost'; @@ -179,14 +118,14 @@ mysql> GRANT ALL PRIVILEGES ON `test`.* TO 'genius'@'localhost'; Query OK, 0 rows affected (0.00 sec) ``` -如果一些特殊的关键字想做为表名，可以用反引号包含起来。比如： +如果想将一些特殊的关键字做为表名，可以用反引号包含起来。比如： ```sql mysql> CREATE TABLE `select` (id int); Query OK, 0 rows affected (0.27 sec) ``` -#### 查看为用户分配的权限 +### 查看为用户分配的权限 `SHOW GRANTS` 语句可以查看为用户分配了哪些权限。例如： @@ -195,129 +134,36 @@ SHOW GRANTS; # 查看当前用户的权限 SHOW GRANTS for 'root'@'%'; # 查看某个特定用户的权限 ``` -更精确的方式，可以通过直接查看授权表的数据实现。比如想知道，`test@%` 该用户是否拥有对 `db1.t` 的 `Insert` 权限。 - -先查看该用户是否拥有全局 `Insert` 权限： - -```sql -SELECT Insert_priv FROM mysql.user WHERE user='test' AND host='%'; -``` - -如果没有，再查看该用户是否拥有 `db1` 数据库级别的 `Insert` 权限： - -```sql -SELECT Insert_priv FROM mysql.db WHERE user='test' AND host='%'; -``` - -如果仍然没有，则继续判断是否拥有 `db1.t` 这张表的 `Insert` 权限： - -```sql -SELECT table_priv FROM mysql.tables_priv WHERE user='test' AND host='%' AND db='db1'; -``` - -### 权限系统的实现 - -#### 授权表 - -有几张系统表是非常特殊的表，权限相关的数据全部存储在这几张表内。 - -- mysql.user 用户账户，全局权限 -- mysql.db 数据库级别的权限 -- mysql.tables_priv 表级别的权限 -- mysql.columns_priv 列级别的权限，当前暂不支持 - -这几张表包含了数据的生效范围和权限信息。例如，`mysql.user` 表的部分数据： - -```sql -mysql> SELECT User,Host,Select_priv,Insert_priv FROM mysql.user LIMIT 1; -+------|------|-------------|-------------+ -| User | Host | Select_priv | Insert_priv | -+------|------|-------------|-------------+ -| root | % | Y | Y | -+------|------|-------------|-------------+ -1 row in set (0.00 sec) -``` - -这条记录中，Host 和 User 决定了 root 用户从任意主机（%）发送过来的连接请求可以被接受，而 `Select_priv` 和 `Insert_priv` 表示用户拥有全局的 `Select` 和 `Insert` 权限。`mysql.user` 这张表里面的生效范围是全局的。 - -`mysql.db` 表里面包含的 Host 和 User 决定了用户可以访问哪些数据库，权限列的生效范围是数据库。 - -理论上，所有权限管理相关的操作，都可以通过直接对授权表的 CRUD 操作完成。 - -实现层面其实也只是包装了一层语法糖。例如删除用户会执行： - -```sql -DELETE FROM mysql.user WHERE user='test'; -``` - -但是，不推荐手动修改授权表，建议使用 `DROP USER` 语句： - -```sql -DROP USER 'test'; -``` - -#### 连接验证 - -当客户端发送连接请求时，TiDB 服务器会对登陆操作进行验证。验证过程先检查 `mysql.user` 表，当某条记录的 User 和 Host 和连接请求匹配上了，再去验证 Password。用户身份基于两部分信息，发起连接的客户端的 Host，以及用户名 User。如果 User不为空，则用户名必须精确匹配。 - -User+Host 可能会匹配 `user` 表里面多行，为了处理这种情况，`user` 表的行是排序过的，客户端连接时会依次去匹配，并使用首次匹配到的那一行做权限验证。排序是按 Host 在前，User 在后。 - -#### 请求验证 - -连接成功之后，请求验证会检测执行操作是否拥有足够的权限。 - -对于数据库相关请求 (`INSERT`，`UPDATE`)，先检查 `mysql.user` 表里面的用户全局权限，如果权限够，则直接可以访问。如果全局权限不足，则再检查 `mysql.db` 表。 - -`user` 表的权限是全局的，并且不管默认数据库是哪一个。比如 `user` 里面有 DELETE 权限，任何一行，任何的表，任何的数据库。 - -`db`表里面，User 为空是匹配匿名用户，User 里面不能有通配符。Host 和 Db 列里面可以有 `%` 和 `_`，可以模式匹配。 - -`user` 和 `db` 读到内存也是排序的。 - -`tables_priv` 和 `columns_priv` 中使用 `%` 是类似的，但是在`Db`, `Table_name`, `Column_name` 这些列不能包含 `%`。加载进来时排序也是类似的。 - -#### 生效时机 - -TiDB 启动时，将一些权限检查的表加载到内存，之后使用缓存的数据来验证权限。系统会周期性的将授权表从数据库同步到缓存，生效则是由同步的周期决定，目前这个值设定的是5分钟。 - -修改了授权表，如果需要立即生效，可以手动调用： - -```sql -FLUSH PRIVILEGES; -``` - -### 限制和约束 +更精确的方式，可以通过直接查看授权表的数据实现。比如想知道，名为 `test@%` 的用户是否拥有对 `db1.t` 的 `Insert` 权限： -一些使用频率偏低的权限当前版本的实现中还未做检查，比如 FILE/USAGE/SHUTDOWN/EXECUTE/PROCESS/INDEX 等等，未来会陆续完善。 +1. 先查看该用户是否拥有全局 `Insert` 权限： -现阶段对权限的支持还没有做到 column 级别。 + ```sql + SELECT Insert_priv FROM mysql.user WHERE user='test' AND host='%'; + ``` -## CREATE USER 语句 +2. 如果没有，再查看该用户是否拥有 `db1` 数据库级别的 `Insert` 权限： -```sql -CREATE USER [IF NOT EXISTS] - user [auth_spec] [, user [auth_spec]] ... -auth_spec: { - IDENTIFIED BY 'auth_string' - | IDENTIFIED BY PASSWORD 'hash_string' -} -``` + ```sql + SELECT Insert_priv FROM mysql.db WHERE user='test' AND host='%'; + ``` -User 参见[用户账号名](../sql/user-account-management.md)。 +3. 如果仍然没有，则继续判断是否拥有 `db1.t` 这张表的 `Insert` 权限： -* `IDENTIFIED BY 'auth_string'`：设置登录密码时，`auth_string` 会被 TiDB 经过加密存储在 `mysql.user` 表中。 -* `IDENTIFIED BY PASSWORD 'hash_string'`：设置登录密码，`hash_string` 是一个类似于 `*EBE2869D7542FCE37D1C9BBC724B97BDE54428F1` 的 41 位字符串，会被 TiDB 直接存储在 `mysql.user` 表中，该字符串可以通过 `SELECT password('auth_string')` 加密得到。 + ```sql + SELECT table_priv FROM mysql.tables_priv WHERE user='test' AND host='%' AND db='db1'; + ``` -# TiDB 各操作需要的权限 +## TiDB 各操作需要的权限 -TiDB 目前用户拥有的权限可以在 `INFORMATION_SCHEMA.USER_PRIVILEGES` 表中查找到。 +TiDB 用户目前拥有的权限可以在 `INFORMATION_SCHEMA.USER_PRIVILEGES` 表中查找到。 | 权限类型 | 权限变量名 | 权限简述 | -| :------------: | :------------: | :----------------------: | +| :------------ | :------------ | :---------------------- | | ALL | AllPriv | 所有权限 | | Drop | DropPriv | 删除 schema/table | | Index | IndexPriv | 创建/删除 index | -| Alter | AlterPriv | 执行 alter 语句 | +| Alter | AlterPriv | 执行 `ALTER` 语句 | | Super | SuperPriv | 所有权限 | | Grant | GrantPriv | 授予其他用户权限 | | Create | CreatePriv | 创建 schema/table | @@ -336,82 +182,164 @@ TiDB 目前用户拥有的权限可以在 `INFORMATION_SCHEMA.USER_PRIVILEGES` | Create Role | CreateRolePriv | 执行 create role | | Show Databases | ShowDBPriv | 显示 database 内的表情况 | -## ALTER - -对于所有的 `ALTER` 语句，均需要用户对所操作的表拥有 `ALTER` 权限。除 `ALTER ... DROP` 和 `ALTER ... RENAME TO` 外，均需要对所操作表拥有 `INSERT` 和 `CREATE` 权限。 +### ALTER -对于 `ALTER ... DROP` 语句，需要对表拥有 `DROP` 权限。对于 `ALTER ... RENAME TO` 语句，需要对重命名前的表拥有 `DROP` 权限，对重命名后的表拥有 `CREATE` 和 `INSERT` 权限。 +- 对于所有的 `ALTER` 语句，均需要用户对所操作的表拥有 `ALTER` 权限。 +- 除 `ALTER...DROP` 和 `ALTER...RENAME TO` 外，均需要对所操作表拥有 `INSERT` 和 `CREATE` 权限。 +- 对于 `ALTER...DROP` 语句，需要对表拥有 `DROP` 权限。 +- 对于 `ALTER...RENAME TO` 语句，需要对重命名前的表拥有 `DROP` 权限，对重命名后的表拥有 `CREATE` 和 `INSERT` 权限。 -注：根据 MySQL 5.7 文档中的说明，`ALTER` 表需要 `INSERT` 和 `CREATE` 权限，但在 MySQL 5.7.25 版本实际情况中，`ALTER` 表仅需要 `ALTER` 权限。为了尽可能减少对用户的困扰，TiDB 中的 ALTER 权限目前与 MySQL 实际行为保持一致。 +> **注意：** +> +> 根据 MySQL 5.7 文档中的说明，对表进行 `ALTER` 操作需要 `INSERT` 和 `CREATE` 权限，但在 MySQL 5.7.25 版本实际情况中，该操作仅需要 `ALTER` 权限。目前，TiDB 中的 `ALTER` 权限与 MySQL 实际行为保持一致。 -## CREATE DATABASE +### CREATE DATABASE 需要对数据库拥有 `CREATE` 权限。 -## CREATE INDEX +### CREATE INDEX 需要对所操作的表拥有 `INDEX` 权限。 -## CREATE TABLE +### CREATE TABLE -需要对所操作的表拥有 `CREATE` 权限；若使用 `CREATE TABLE .... LIKE ....` 需要对相关的表拥有 `SELECT` 权限。 +需要对所操作的表拥有 `CREATE` 权限；若使用 `CREATE TABLE...LIKE...` 需要对相关的表拥有 `SELECT` 权限。 -## CREATE VIEW +### CREATE VIEW 需要拥有 `CREATE VIEW` 权限。 -注：如果当前登录用户与创建视图的用户不同，除需要 `CREATE VIEW` 权限外，我们还需要 `SUPER` 权限。 +> **注意：** +> +> 如果当前登录用户与创建视图的用户不同，除需要 `CREATE VIEW` 权限外，还需要 `SUPER` 权限。 -## DROP DATABASE +### DROP DATABASE 需要对数据库拥有 `DROP` 权限。 -## DROP INDEX +### DROP INDEX 需要对所操作的表拥有 `INDEX` 权限。 -## DROP TABLES +### DROP TABLES 需要对所操作的表拥有 `DROP` 权限。 -## TRUNCATE TABLE +### TRUNCATE TABLE 需要对所操作的表拥有 `DROP` 权限。 -## RENAME TABLE +### RENAME TABLE 需要对重命名前的表拥有 `ALTER` 和 `DROP` 权限，对重命名后的表拥有 `CREATE` 和 `INSERT` 权限。 -## ANALYZE TABLE +### ANALYZE TABLE 需要对所操作的表拥有 `INSERT` 和 `SELECT` 权限。 -## SHOW +### SHOW `SHOW CREATE TABLE` 需要任意一种权限。 `SHOW CREATE VIEW` 需要 `SHOW VIEW` 权限。 -## CREATE ROLE/USER +### CREATE ROLE/USER `CREATE ROLE` 需要 `CREATE ROLE` 权限。 `CREATE USER` 需要 `CREATE USER` 权限 -## DROP ROLE/USER +### DROP ROLE/USER `DROP ROLE` 需要 `DROPROLE` 权限。 `DROP USER` 需要 `CREATEUSER` 权限 -## ALTER USER +### ALTER USER `ALTER USER` 需要 `CREATEUSER` 权限。 -## GRANT +### GRANT `GRANT` 需要 `GRANT` 权限并且拥有 `GRANT` 所赋予的权限。 -## REVOKE +### REVOKE `REVOKE` 需要 `SUPER` 权限。 + +## 权限系统的实现 + +### 授权表 + +以下几张系统表是非常特殊的表，权限相关的数据全部存储在这几张表内。 + +- `mysql.user`：用户账户，全局权限 +- `mysql.db`：数据库级别的权限 +- `mysql.tables_priv`：表级别的权限 +- `mysql.columns_priv`：列级别的权限，当前暂不支持 + +这几张表包含了数据的生效范围和权限信息。例如，`mysql.user` 表的部分数据： + +```sql +mysql> SELECT User,Host,Select_priv,Insert_priv FROM mysql.user LIMIT 1; ++------|------|-------------|-------------+ +| User | Host | Select_priv | Insert_priv | ++------|------|-------------|-------------+ +| root | % | Y | Y | ++------|------|-------------|-------------+ +1 row in set (0.00 sec) +``` + +这条记录中，`Host` 和 `User` 决定了 root 用户从任意主机 (%) 发送过来的连接请求可以被接受，而 `Select_priv` 和 `Insert_priv` 表示用户拥有全局的 `Select` 和 `Insert` 权限。`mysql.user` 这张表里面的生效范围是全局的。 + +`mysql.db` 表里面包含的 `Host` 和 `User` 决定了用户可以访问哪些数据库，权限列的生效范围是数据库。 + +理论上，所有权限管理相关的操作，都可以通过直接对授权表的 CRUD 操作完成。 + +实现层面其实也只是包装了一层语法糖。例如删除用户会执行： + +```sql +DELETE FROM mysql.user WHERE user='test'; +``` + +但是，不推荐手动修改授权表，建议使用 `DROP USER` 语句： + +```sql +DROP USER 'test'; +``` + +### 连接验证 + +当客户端发送连接请求时，TiDB 服务器会对登录操作进行验证。验证过程先检查 `mysql.user` 表，当某条记录的 `User` 和 `Host` 和连接请求匹配上了，再去验证 Password。用户身份基于两部分信息，发起连接的客户端的 `Host`，以及用户名 `User`。如果 `User` 不为空，则用户名必须精确匹配。 + +User+Host 可能会匹配 `user` 表里面多行，为了处理这种情况，`user` 表的行是排序过的，客户端连接时会依次去匹配，并使用首次匹配到的那一行做权限验证。排序是按 `Host` 在前，`User` 在后。 + +### 请求验证 + +连接成功之后，请求验证会检测执行操作是否拥有足够的权限。 + +对于数据库相关请求 (`INSERT`，`UPDATE`)，先检查 `mysql.user` 表里面的用户全局权限，如果权限够，则直接可以访问。如果全局权限不足，则再检查 `mysql.db` 表。 + +`user` 表的权限是全局的，并且不管默认数据库是哪一个。比如 `user` 里面有 `DELETE` 权限，任何一行，任何的表，任何的数据库。 + +`db`表里面，User 为空是匹配匿名用户，User 里面不能有通配符。Host 和 Db 列里面可以有 `%` 和 `_`，可以模式匹配。 + +`user` 和 `db` 读到内存也是排序的。 + +`tables_priv` 和 `columns_priv` 中使用 `%` 是类似的，但是在`Db`, `Table_name`, `Column_name` 这些列不能包含 `%`。加载进来时排序也是类似的。 + +### 生效时机 + +TiDB 启动时，将一些权限检查的表加载到内存，之后使用缓存的数据来验证权限。系统会周期性的将授权表从数据库同步到缓存，生效则是由同步的周期决定，目前这个值设定的是 5 分钟。 + +修改了授权表，如果需要立即生效，可以手动调用： + +```sql +FLUSH PRIVILEGES; +``` + +### 限制和约束 + +一些使用频率偏低的权限当前版本的实现中还未做检查，比如 `FILE`/`USAGE`/`SHUTDOWN`/`EXECUTE`/`PROCESS`/`INDEX` 等等，未来会陆续完善。 + +现阶段对权限的支持还没有做到 column 级别。 diff --git a/sql/slow-query.md b/sql/slow-query.md index b8ec13e95470..76f2d5139a55 100644 --- a/sql/slow-query.md +++ b/sql/slow-query.md @@ -5,85 +5,211 @@ category: user guide # 慢查询日志 +TiDB 在 V2.1.8 之后更改了慢日志格式，V2.1.8 之前的版本请看[这个文档]()。 + 一条不合理的 SQL 语句会导致整个集群压力增大，响应变慢。对于这种问题，需要用慢查询日志来定位有问题的语句，解决性能问题。 ### 获取日志 -通过在 TiDB 的日志文件上 grep `SLOW_QUERY` 这个关键字，可以得到执行时间超过 [slow-threshold](../op-guide/tidb-config-file.md#slow-threshold) 的语句日志。 - -`slow-threshold` 可以通过配置文件修改，默认是 300ms。如果配置了 [slow-query-file](../op-guide/tidb-config-file.md#slow-query-file)，慢查询日志会全部写在这个文件里。 +TiDB 会将执行时间超过 [slow-threshold](../op-guide/tidb-config-file.md#slow-threshold) 的语句默认单独输出到 [slow-query-file](../op-guide/tidb-config-file.md#slow-query-file) 文件中 ，并对慢日志的格式做了兼容，可以用 `pt-query-digest` 直接分析慢日志文件。`slow-threshold` 可以通过配置文件修改，默认是 300ms。`slow-query-file` 默认是 `tidb-slow.log`。 ### 示例 -``` -2018/08/20 19:52:08.632 adapter.go:363: [warning] [SLOW_QUERY] cost_time:18.647928814s -process_time:1m6.768s wait_time:12m11.212s backoff_time:600ms request_count:2058 -total_keys:1869712 processed_keys:1869710 succ:true con:3 user:root@127.0.0.1 -txn_start_ts:402329674704224261 database:test table_ids:[31],index_ids:[1], -sql:select count(c) from sbtest1 use index (k_1) +```sql +# Time: 2019-03-18-12:10:19.513961 +0800 +# Txn_start_ts: 407078752230047745 +# User: root@127.0.0.1 +# Conn_ID: 1 +# Query_time: 16.479155653 +# Process_time: 5.634 Wait_time: 0.002 Request_count: 2 Total_keys: 20002 Process_keys: 20000 +# DB: test +# Index_ids: [1] +# Is_internal: false +# Digest: 3635413fe0c8e1aa8307f4f018fe1a9325ea0b97452500106d3f6783fcb65e33 +# Num_cop_tasks: 10 +# Cop_proc_avg: 1 Cop_proc_p90: 2 Cop_proc_max: 3 Cop_proc_addr: 10.6.131.78 +# Cop_wait_avg: 5 Cop_wait_p90: 6 Cop_wait_max: 7 Cop_wait_addr: 10.6.131.79 +# Memory_max: 4096 +select * from t_slim, t_wide where t_slim.c0=t_wide.c0; ``` ### 字段解析 -#### cost_time - -表示执行这个语句花费的时间。只有执行时间超过 slow-threshold 的语句才会输出这个日志。 - -#### process_time - -表示这个语句在 TiKV 的处理时间之和，因为数据会并行的发到 TiKV 执行，这个值可能会超过 cost_time。 - -#### wait_time - -表示这个语句在 TiKV 的等待时间之和，因为 TiKV 的 Coprocessor 线程数是有限的，当所有的 Coprocessor 线程都在工作的时候，请求会排队，当队列中有某些请求耗时很长的时候，后面的请求的等待时间都会增加。 - -#### backoff_time - -表示语句遇到需要重试的错误时在重试前等待的时间，常见的需要重试的错误有以下几种：遇到了 lock、Region 分裂、`tikv server is busy`。 - -#### request_count - -表示这个语句发送的 Coprocessor 请求的数量。 - -#### total_keys - -表示 Coprocessor 扫过的 key 的数量 - -#### processed_keys +* `Time`：表示日志打印时间。 +* `Txn_start_ts`：表示事务的开始时间戳，也是事务的 ID，可以用这个值在日志中 grep 出事务相关的日志。 +* `User`：表示执行语句的用户名。 +* `Conn_ID`：表示 connection ID，即 session ID，可以用类似 `con: 3` 的关键字在 TiDB 日志中 grep 出 session ID 为 3 的日志。 +* `Query_time`：表示执行这个语句花费的时间。只有执行时间超过 slow-threshold 的语句才会输出这个日志，单位是秒，以下所有的时间字段的单位都是秒。 +* `Process_time`：执行 SQL 在 TiKV 的处理时间之和，因为数据会并行的发到 TiKV 执行，这个值可能会超过 `Query_time`。 +* `Wait_time`：表示这个语句在 TiKV 的等待时间之和，因为 TiKV 的 Coprocessor 线程数是有限的，当所有的 Coprocessor 线程都在工作的时候，请求会排队；当队列中有某些请求耗时很长的时候，后面的请求的等待时间都会增加。 +* `Backoff_time`：表示语句遇到需要重试的错误时在重试前等待的时间，常见的需要重试的错误有以下几种：遇到了 lock、Region 分裂、`tikv server is busy`。 +* `Request_count`：表示这个语句发送的 Coprocessor 请求的数量。 +* `Total_keys`：表示 Coprocessor 扫过的 key 的数量。 +* `Process_keys`：表示 Coprocessor 处理的 key 的数量。相比 total_keys，processed_keys 不包含 MVCC 的旧版本。如果 processed_keys 和 total_keys 相差很大，说明旧版本比较多。 +* `DB`：表示当前的 database。 +* `Index_ids`：表示语句涉及到的索引的 ID。 +* `Is_internal`：表示是否是 TiDB 内部 SQL。true 为TiDB 内部执行的SQL，比如 analyze，load variable 等；false 为用户执行的 SQL。 +* `Digest`：表示 SQL 语句的指纹。 +* `Memory_max`：表示执行期间做多时候使用的内存数量, 单位为byte。 +* `Num_cop_tasks`：表示 [cop-tasks](/sql/understanding-the-query-execution-plan.md) 的数目。 +* `Cop_proc_avg`：cop-task 的平均执行时间。 +* `Cop_proc_p90`：cop-task 的 P90 分位执行时间。 +* `Cop_proc_max`：cop-task 的最大执行时间。 +* `Cop_proc_addr`：执行时间最长的 cop-task 所在地址。 +* `Cop_wait_avg`：cop-task 的平均等待时间。 +* `Cop_wait_p90`：cop-task 的P90分位等待时间。 +* `Cop_wait_max`：cop-task 的最大等待时间。 +* `Cop_wait_addr`：等待时间最长的 cop-task 所在地址。 +* `Query`：表示 SQL 语句。慢日志里面不会打印 `Query`，但映射到内存表后，对应的字段叫 `Query`。 + +### 慢日志内存映射表 +为了方便用 SQL 查询定位慢查询，TiDB 将慢日志内容解析后映射到 `INFORMATION_SCHEMA.SLOW_QUERY` 表中，表中 column 名和慢日志中记录的字段名一一对应。 -表示 Coprocessor 处理的 key 的数量。相比 total_keys，processed_keys 不包含 MVCC 的旧版本。如果 processed_keys 和 total_keys 相差很大，说明旧版本比较多。 - -#### succ - -表示请求是否执行成功 +```sql +tidb > show create table INFORMATION_SCHEMA.SLOW_QUERY; ++------------+-------------------------------------------------------------+ +| Table | Create Table | ++------------+-------------------------------------------------------------+ +| SLOW_QUERY | CREATE TABLE `SLOW_QUERY` ( | +| | `Time` timestamp UNSIGNED NULL DEFAULT NULL, | +| | `Txn_start_ts` bigint(20) UNSIGNED DEFAULT NULL, | +| | `User` varchar(64) DEFAULT NULL, | +| | `Conn_ID` bigint(20) UNSIGNED DEFAULT NULL, | +| | `Query_time` double UNSIGNED DEFAULT NULL, | +| | `Process_time` double UNSIGNED DEFAULT NULL, | +| | `Wait_time` double UNSIGNED DEFAULT NULL, | +| | `Backoff_time` double UNSIGNED DEFAULT NULL, | +| | `Request_count` bigint(20) UNSIGNED DEFAULT NULL, | +| | `Total_keys` bigint(20) UNSIGNED DEFAULT NULL, | +| | `Process_keys` bigint(20) UNSIGNED DEFAULT NULL, | +| | `DB` varchar(64) DEFAULT NULL, | +| | `Index_ids` varchar(100) DEFAULT NULL, | +| | `Is_internal` tinyint(1) UNSIGNED DEFAULT NULL, | +| | `Digest` varchar(64) DEFAULT NULL, | +| | `Query` varchar(4096) DEFAULT NULL | +| | ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin | ++------------+-------------------------------------------------------------+ +``` -#### con +#### 实现细节 -表示 connection ID，即 session ID, 可以用类似 `con:3 ` 的关键字在日志中 grep 出 session ID 为 3 的日志。 +`INFORMATION_SCHEMA.SLOW_QUERY` 表里面的内容是通过实时解析 TiDB 慢日志里面的内容得到的。每次查询这个表时都会去读取慢日志文件里面的内容，然后解析。 -#### user +### 查询 SLOW_QUERY 示例 -表示执行语句的用户名 +下面示例展示如何通过查询 SLOW_QUERY 表来定位慢查询。 -#### txn_start_ts +#### 查询 TopN 的慢查询 -表示事务的开始时间戳，也是事务的 ID, 可以用这个值在日志中 grep 出事务相关的日志。 +查询 Top2 的用户慢查询。`Is_internal=false` 表示排除 TiDB 内部的慢查询，只看用户的慢查询。 -#### database +```sql +/* 查询所有用户执行的SQL，且按执行消耗时间排序 */ +tidb > select `Query_time`, query from INFORMATION_SCHEMA.`SLOW_QUERY` where `Is_internal`=false order by `Query_time` desc limit 2; ++--------------+------------------------------------------------------------------+ +| Query_time | query | ++--------------+------------------------------------------------------------------+ +| 12.77583857 | select * from t_slim, t_wide where t_slim.c0=t_wide.c0; | +| 0.734982725 | select t0.c0, t1.c1 from t_slim t0, t_wide t1 where t0.c0=t1.c0; | ++--------------+------------------------------------------------------------------+ +2 rows in set +Time: 0.012s +``` -表示当前的 database +#### 查询 `test` 用户的 TopN 慢查询 +```sql +/* 查询 test 用户执行的SQL，且按执行消耗时间排序*/ +tidb > select `Query_time`, query, user from INFORMATION_SCHEMA.`SLOW_QUERY` where `Is_internal`=false and user like "test%" order by `Query_time` desc limit 2; ++-------------+------------------------------------------------------------------+----------------+ +| Query_time | query | user | ++-------------+------------------------------------------------------------------+----------------+ +| 0.676408014 | select t0.c0, t1.c1 from t_slim t0, t_wide t1 where t0.c0=t1.c1; | test@127.0.0.1 | ++-------------+------------------------------------------------------------------+----------------+ +1 row in set +Time: 0.014s +``` -#### table_ids +#### 根据 SQL 指纹来查询类似 SQL 的慢查询 +如果查询了 TopN 的SQL 后，想查询相同 SQL 指纹的查询，可以用指纹作为过滤条件。 +```sql +tidb > select query_time, query,digest from INFORMATION_SCHEMA.`SLOW_QUERY` where `Is_internal`=false order by `Query_time` desc limit 1; ++-------------+-----------------------------+------------------------------------------------------------------+ +| query_time | query | digest | ++-------------+-----------------------------+------------------------------------------------------------------+ +| 0.302558006 | select * from t1 where a=1; | 4751cb6008fda383e22dacb601fde85425dc8f8cf669338d55d944bafb46a6fa | ++-------------+-----------------------------+------------------------------------------------------------------+ +1 row in set +Time: 0.007s +tidb > select query, query_time from INFORMATION_SCHEMA.`SLOW_QUERY` where digest="4751cb6008fda383e22dacb601fde85425dc8f8cf669338d55d944bafb46a6fa"; ++-----------------------------+-------------+ +| query | query_time | ++-----------------------------+-------------+ +| select * from t1 where a=1; | 0.302558006 | +| select * from t1 where a=2; | 0.401313532 | ++-----------------------------+-------------+ +2 rows in set +``` -表示语句涉及到的表的 ID +## 查询统计信息是 pseudo 的慢查询 -#### index_ids +```sql +tidb > select query, query_time, stats from INFORMATION_SCHEMA.`SLOW_QUERY` where is_internal=false and stats like('%pseudo%'); ++-----------------------------+-------------+---------------------------------+ +| query | query_time | stats | ++-----------------------------+-------------+---------------------------------+ +| select * from t1 where a=1; | 0.302558006 | t1:pseudo | +| select * from t1 where a=2; | 0.401313532 | t1:pseudo | +| select * from t1 where a>2; | 0.602011247 | t1:pseudo | +| select * from t1 where a>3; | 0.50077719 | t1:pseudo | +| select * from t1 join t2; | 0.931260518 | t1:407872303825682445,t2:pseudo | ++-----------------------------+-------------+---------------------------------+ +``` -表示语句涉及到的索引的 ID +#### 解析其他的 TiDB 慢日志文件 -#### sql +目前查询 `INFORMATION_SCHEMA.SLOW_QUERY` 只会解析配置文件中 `slow-query-file` 设置的慢日志文件名，默认是 "tidb-slow.log"。但如果想要解析其他的日志文件，可以通过设置 session 变量 `tidb_slow_query_file` 为具体的文件路径，然后查询 `INFORMATION_SCHEMA.SLOW_QUERY` 就会按照设置的路径去解析慢日志文件。 +```sql +/* 设置慢日志文件路径，方便解析其他的慢日志文件，tidb_slow_query_file 变量的作用域是 session */ +tidb > set tidb_slow_query_file="/path-to-log/tidb-slow.log" +Query OK, 0 rows affected +Time: 0.001s +``` -表示 SQL 语句 +`INFORMATION_SCHEMA.SLOW_QUERY` 目前暂时只支持解析一个慢日志文件，如果慢日志文件超过一定大小后被 logrotate 成多个文件了，查询 `INFORMATION_SCHEMA.SLOW_QUERY` 也只会去解析一个文件。后续我们会改善这点。 + +#### 用 pt-query-digest 工具分析 TiDB 慢日志 + +可以用 pt-query-digest 工具分析 TiDB 慢日志。建议使用 pt-query-digest 3.0.13 及以上版本。示例如下： + +```shell +$pt-query-digest --version +pt-query-digest 3.0.13 + +$ pt-query-digest --report tidb-slow.log +# 320ms user time, 20ms system time, 27.00M rss, 221.32M vsz +# Current date: Mon Mar 18 13:18:51 2019 +# Hostname: localhost.localdomain +# Files: tidb-slow.log +# Overall: 1.02k total, 21 unique, 0 QPS, 0x concurrency _________________ +# Time range: 2019-03-18-12:22:16 to 2019-03-18-13:08:52 +# Attribute total min max avg 95% stddev median +# ============ ======= ======= ======= ======= ======= ======= ======= +# Exec time 218s 10ms 13s 213ms 30ms 1s 19ms +# Query size 175.37k 9 2.01k 175.89 158.58 122.36 158.58 +# Commit time 46ms 2ms 7ms 3ms 7ms 1ms 3ms +# Conn ID 71 1 16 8.88 15.25 4.06 9.83 +# Process keys 581.87k 2 103.15k 596.43 400.73 3.91k 400.73 +# Process time 31s 1ms 10s 32ms 19ms 334ms 16ms +# Request coun 1.97k 1 10 2.02 1.96 0.33 1.96 +# Total keys 636.43k 2 103.16k 652.35 793.42 3.97k 400.73 +# Txn start ts 374.38E 0 16.00E 375.48P 1.25P 89.05T 1.25P +# Wait time 943ms 1ms 19ms 1ms 2ms 1ms 972us +# Write keys 978 2 477 69.86 463.90 161.64 1.96 +# Write size 89.12k 138 43.67k 6.37k 42.34k 14.76k 136.99 +. +. +. +``` ### 定位问题语句的方法 diff --git a/sql/statistics.md b/sql/statistics.md index bedf8ea9fb50..c4fc1af114d9 100644 --- a/sql/statistics.md +++ b/sql/statistics.md @@ -11,7 +11,11 @@ TiDB 优化器会根据统计信息来选择最优的执行计划。统计信息 ### 手动收集 -可以通过执行 `ANALYZE` 语句来收集统计信息。需要注意的是，在 TiDB 中执行 `ANALYZE TABLE` 语句比在 MySQL 或 InnoDB 中耗时更长。InnoDB 采样的只是少量页面，但 TiDB 会完全重构一系列统计信息。适用于 MySQL 的脚本会误以为执行 `ANALYZE TABLE` 耗时较短。 +可以通过执行 `ANALYZE` 语句来收集统计信息。 + +> **注意：** +> +> 在 TiDB 中执行 `ANALYZE TABLE` 语句比在 MySQL 或 InnoDB 中耗时更长。InnoDB 采样的只是少量页面，但 TiDB 会完全重构一系列统计信息。适用于 MySQL 的脚本会误以为执行 `ANALYZE TABLE` 耗时较短。 语法： diff --git a/sql/system-database.md b/sql/system-database.md index 5ab15586f4bb..c2540b5d5370 100644 --- a/sql/system-database.md +++ b/sql/system-database.md @@ -1,15 +1,13 @@ --- -title: TiDB 系统数据库 +title: TiDB 系统表 category: user guide --- -# TiDB 系统数据库 +# TiDB 系统表 -TiDB 的系统数据库跟 MySQL 类似，里面包含一些服务器运行时需要的信息。本文档主要介绍 TiDB 支持的系统表。 +本文档主要介绍 TiDB 支持的系统表。 -## 支持系统表 - -### 权限系统表 +## 权限系统表 这些系统表里面包含了用户账户以及相应的授权信息： @@ -18,21 +16,21 @@ TiDB 的系统数据库跟 MySQL 类似，里面包含一些服务器运行时 * `tables_priv` 表级的权限 * `columns_priv` 列级的权限 -### 服务端帮助信息系统表 +## 服务端帮助信息系统表 * `help_topic` 目前为空 -### 统计信息相关系统表 +## 统计信息相关系统表 * `stats_buckets` 统计信息的桶 * `stats_histograms` 统计信息的直方图 * `stats_meta` 表的元信息，比如总行数和修改数 -### GC Worker 相关系统表 +## GC Worker 相关系统表 * `gc_delete_range` -### 其它系统表 +## 其它系统表 * `GLOBAL_VARIABLES` 全局系统变量表 * `tidb` 用于 TiDB 在 bootstrap 的时候记录相关版本信息 diff --git a/sql/tidb-server.md b/sql/tidb-server.md index ec81f54c2a9b..fb12b72ad2ce 100644 --- a/sql/tidb-server.md +++ b/sql/tidb-server.md @@ -9,7 +9,11 @@ TiDB 是指 TiDB 数据库系统，本篇文档涉及到 TiDB 集群的基本管 ## TiDB 集群启动配置 -可以通过命令行参数或者配置文件设置服务参数，或者是两者一起使用。注意命令行参数的优先级高于配置文件，如果同一个参数两种方式都设置，会以命令行参数中的值为准。具体信息参考[这篇](../sql/server-command-option.md)文档。 +可以通过命令行参数或者配置文件设置服务参数，或者是两者一起使用。 + +> **注意：** +> +> 命令行参数的优先级高于配置文件，如果同一个参数两种方式都设置，会以命令行参数中的值为准。具体信息参考[这篇](../sql/server-command-option.md)文档。 ## TiDB 数据库系统变量 diff --git a/sql/tidb-specific.md b/sql/tidb-specific.md index 77763bd80a87..7701b84d058e 100644 --- a/sql/tidb-specific.md +++ b/sql/tidb-specific.md @@ -205,7 +205,10 @@ set @@global.tidb_distsql_scan_concurrency = 10 默认值: 20000 这个变量用来设置自动切分插入/待删除数据的的 batch 大小。仅在 tidb_batch_insert 或 tidb_batch_delete 开启时有效。 -需要注意的是，当单行总数据大小很大时，20k 行总数据量数据会超过单个事务大小限制。因此在这种情况下，用户应当将其设置为一个较小的值。 + +> **注意：** +> +> 当单行总数据大小很大时，20k 行总数据量数据会超过单个事务大小限制。因此在这种情况下，用户应当将其设置为一个较小的值。 ### tidb_max_chunk_size @@ -319,6 +322,7 @@ set @@global.tidb_distsql_scan_concurrency = 10 默认值：0 这个变量用来设置是否禁用显式事务自动重试，设置为 1 时，不会自动重试，如果遇到事务冲突需要在应用层重试。 + 是否需要禁用自动重试，请参考[自动重试的风险](/sql/transaction-isolation.md#乐观事务注意事项)。 ### tidb_enable_table_partition diff --git a/sql/transaction-isolation.md b/sql/transaction-isolation.md index b060fb86d58b..701efb2b200d 100644 --- a/sql/transaction-isolation.md +++ b/sql/transaction-isolation.md @@ -18,7 +18,9 @@ sql 92标准定义了4种隔离级别，读未提交、读已提交、可重复 TiDB 实现了快照隔离 (Snapshot Isolation) 级别的一致性。为与 MySQL 保持一致，又称其为“可重复读”。该隔离级别不同于 [ANSI 可重复读隔离级别](#与-ansi-可重复读隔离级别的区别)和 [MySQL 可重复读隔离级别](#与-mysql-可重复读隔离级别的区别)。 -> **注意：** 在默认设置中，事务可能因为自动重试显示更新丢失。关于该项功能的补充信息和应如何关掉该项功能，请参考[自动重试导致的事务异常](#自动重试导致的事务异常)和[事务重试](#事务重试)。 +> **注意：** +> +> 在默认设置中，事务可能因为自动重试显示更新丢失。关于该项功能的补充信息和应如何关掉该项功能，请参考[自动重试导致的事务异常](#自动重试导致的事务异常)和[事务重试](#事务重试)。 TiDB 使用 [Percolator 事务模型](https://research.google.com/pubs/pub36726.html)，当事务启动时会获取全局读时间戳，事务提交时也会获取全局提交时间戳，并以此确定事务的执行顺序，如果想了解 TiDB 事务模型的实现可以详细阅读以下两篇文章：[TiKV 的 MVCC (Multi-Version Concurrency Control) 机制](https://pingcap.com/blog-cn/mvcc-in-tikv/)，[Percolator 和 TiDB 事务算法](https://pingcap.com/blog-cn/percolator-and-txn/)。 @@ -85,7 +87,7 @@ retry-limit = 10 | `update t set balance = balance - 100 where id = 1;` | `delete from t where id = 1;` | | | `commit;` | | // 使用 affected_rows 的结果决定后续的逻辑 | | -| `if affected_rows > 100 {` | | +| `if affected_rows > 0 {` | | | `update t set balance = balance + 100 where id = 2;` | | | `}` | | | `commit;` // 自动重试 | | diff --git a/sql/transaction.md b/sql/transaction.md index c95678ae98d5..f7dfcefe11af 100644 --- a/sql/transaction.md +++ b/sql/transaction.md @@ -91,4 +91,7 @@ SELECT * FROM T; -- MySQL 返回 1 2；TiDB 返回 1 ``` 惰性检查的意义在于，如果对事务中每个 `INSERT` 语句都立刻进行唯一性约束检查，将造成很高的网络开销。而在提交时进行一次批量检查，将会大幅提升性能。 -> **注意**：本优化对于 `INSERT IGNORE` 和 `INSERT ON DUPLICATE KEY UPDATE` 不会生效，仅对与普通的 `INSERT` 语句生效。 + +> **注意：** +> +> 本优化对于 `INSERT IGNORE` 和 `INSERT ON DUPLICATE KEY UPDATE` 不会生效，仅对与普通的 `INSERT` 语句生效。 diff --git a/sql/understanding-the-query-execution-plan.md b/sql/understanding-the-query-execution-plan.md index d78523360b47..d53ce2408665 100644 --- a/sql/understanding-the-query-execution-plan.md +++ b/sql/understanding-the-query-execution-plan.md @@ -99,7 +99,9 @@ TiDB 的索引数据和表数据一样，也存放在 TiKV 中。它的 key 是 ### 范围查询 在 WHERE/HAVING/ON 条件中，TiDB 优化器会分析主键或索引键的查询返回。如数字、日期类型的比较符，如大于、小于、等于以及大于等于、小于等于，字符类型的 LIKE 符号等。 + 值得注意的是，TiDB 目前只支持比较符一端是列，另一端是常量，或可以计算成某一常量的情况，类似 `year(birth_day) < 1992` 的查询条件是不能利用索引的。还要注意应尽可能使用同一类型进行比较，以避免引入额外的 cast 操作而导致不能利用索引，如 `user_id = 123456`，如果 `user_id` 是字符串，需要将 `123456` 也写成字符串常量的形式。 + 针对同一列的范围查询条件使用 `AND` 和 `OR` 组合后，等于对范围求交集或者并集。对于多维组合索引，可以写多个列的条件。例如对组合索引`(a, b, c)`，当 a 为等值查询时，可以继续求 b 的查询范围，当 b 也为等值查询时，可以继续求 c 的查询范围，反之如果 a 为非等值查询，则只能求 a 的范围。 ## Operator Info diff --git a/sql/user-account-management.md b/sql/user-account-management.md index ff91e2a8ea65..cc4a568eb552 100644 --- a/sql/user-account-management.md +++ b/sql/user-account-management.md @@ -5,11 +5,13 @@ category: user guide # TiDB 用户账户管理 +本文档主要介绍如何管理 TiDB 用户账户。 + ## 用户名和密码 TiDB 将用户账户存储在 `mysql.user` 系统表里面。每个账户由用户名和 host 作为标识。每个账户可以设置一个密码。 -通过 MySQL 客户端连接到 TiDB 服务器，通过指定的账户和密码登陆： +通过 MySQL 客户端连接到 TiDB 服务器，通过指定的账户和密码登录： ``` shell> mysql --port 4000 --user xxx --password @@ -25,10 +27,51 @@ shell> mysql -P 4000 -u xxx -p 添加用户有两种方式： -* 通过标准的用户管理的 SQL 语句创建用户以及授予权限，比如 `CREATE USER` 和 `GRANT` 。 -* 直接通过 `INSERT` ， `UPDATE` 和 `DELETE` 操作授权表。 +* 通过标准的用户管理的 SQL 语句创建用户以及授予权限，比如 `CREATE USER` 和 `GRANT`。 +* 直接通过 `INSERT`、`UPDATE` 和 `DELETE` 操作授权表。 + +推荐使用第一种方式。第二种方式修改容易导致一些不完整的修改，因此不推荐。还有另一种可选方式是使用第三方工具的图形化界面工具。 + +```sql +CREATE USER [IF NOT EXISTS] + user [auth_spec] [, user [auth_spec]] ... +auth_spec: { + IDENTIFIED BY 'auth_string' + | IDENTIFIED BY PASSWORD 'hash_string' +} +``` + +* `IDENTIFIED BY 'auth_string'`：设置登录密码时，`auth_string` 会被 TiDB 经过加密存储在 `mysql.user` 表中。 +* `IDENTIFIED BY PASSWORD 'hash_string'`：设置登录密码，`hash_string` 是一个类似于 `*EBE2869D7542FCE37D1C9BBC724B97BDE54428F1` 的 41 位字符串，会被 TiDB 直接存储在 `mysql.user` 表中，该字符串可以通过 `SELECT password('auth_string')` 加密得到。 + +```sql +CREATE USER 'test'@'127.0.0.1' IDENTIFIED BY 'xxx'; +``` + +TiDB 的用户账户名由一个用户名和一个主机名组成。账户名的语法为 `'user_name'@'host_name'`。 + +- `user_name` 大小写敏感。 +- `host_name` 可以是一个主机名或 IP 地址。主机名或 IP 地址中允许使用通配符 `%` 和 `_`。例如，名为 `'%'` 的主机名可以匹配所有主机，`'192.168.1.%'` 可以匹配子网中的所有主机。 + +host 支持模糊匹配，比如： + +```sql +CREATE USER 'test'@'192.168.10.%'; +``` + +允许 `test` 用户从 `192.168.10` 子网的任何一个主机登录。 + +如果没有指定 host，则默认是所有 IP 均可登录。如果没有指定密码，默认为空： + +```sql +CREATE USER 'test'; +``` + +等价于 -推荐的方式是使用第一种。第二种方式修改容易导致一些不完整的修改，因此不推荐。还有另一种可选方式是使用第三方工具的图形化界面工具。 +```sql +CREATE USER 'test'@'%' IDENTIFIED BY ''; +``` 下面的例子用 `CREATE USER` 和 `GRANT` 语句创建了四个账户： @@ -58,9 +101,11 @@ mysql> SHOW GRANTS FOR 'admin'@'localhost'; 使用 `DROP USER` 语句可以删除用户，例如： ```sql -mysql> DROP USER 'jeffrey'@'localhost'; +mysql> DROP USER 'test'@'localhost'; ``` +这个操作会清除用户在 `mysql.user` 表里面的记录项，并且清除在授权表里面的相关记录。 + ## 保留用户账户 TiDB 在数据库初始化时会生成一个 `'root'@'%'` 的默认账户。 @@ -71,25 +116,46 @@ TiDB 在数据库初始化时会生成一个 `'root'@'%'` 的默认账户。 ## 设置密码 -TiDB 将密码存在 `mysql.user` 系统数据库里面。只有拥有 `CREATE USER` 权限，或者拥有 `mysql` 数据库权限（ `INSERT` 权限用于创建， `UPDATE` 权限用于更新）的用户才能够设置或修改密码。 +TiDB 将密码存在 `mysql.user` 系统数据库里面。只有拥有 `CREATE USER` 权限，或者拥有 `mysql` 数据库权限（`INSERT` 权限用于创建，`UPDATE` 权限用于更新）的用户才能够设置或修改密码。 -在 `CREATE USER` 创建用户时可以通过 `IDENTIFIED BY` 指定密码： +- 在 `CREATE USER` 创建用户时可以通过 `IDENTIFIED BY` 指定密码： -```sql -CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'mypass'; -``` + ```sql + CREATE USER 'test'@'localhost' IDENTIFIED BY 'mypass'; + ``` -为一个已存在的账户修改密码，可以通过 `SET PASSWORD FOR` 或者 `ALTER USER` 语句完成： +- 为一个已存在的账户修改密码，可以通过 `SET PASSWORD FOR` 或者 `ALTER USER` 语句完成： -```sql -SET PASSWORD FOR 'root'@'%' = 'xxx'; -``` + ```sql + SET PASSWORD FOR 'root'@'%' = 'xxx'; + ``` -或者 + 或者 -```sql -ALTER USER 'jeffrey'@'localhost' IDENTIFIED BY 'mypass'; -``` + ```sql + ALTER USER 'test'@'localhost' IDENTIFIED BY 'mypass'; + ``` + +## 忘记 `root` 密码 + +1. 修改配置文件，在 `security` 部分添加 `skip-grant-table`： + + > [security] + > skip-grant-table = true + +2. 使用修改后的配置启动 TiDB（需要 `root` 权限）： + + ```bash + sudo ./tidb-server -skip-grant-table=true -store=tikv -path=... + ``` + + 这个配置参数会让 TiDB 跳过权限系统。 + +3. 然后使用 `root` 登录后修改密码： + + ```bash + mysql -h 127.0.0.1 -P 4000 -u root + ``` ## `FLUSH PRIVILEGES` diff --git a/sql/util.md b/sql/util.md index 6e8a7a7ab01d..9c08f2d57692 100644 --- a/sql/util.md +++ b/sql/util.md @@ -93,8 +93,7 @@ dot xx.dot -T png -O USE db_name ``` - -切换默认 Database，当 SQL 语句中的表没有显式指定的 Database 时，即使用默认 Database。 +切换需要使用的 Database 的时候，如果 SQL 语句中的表没有显式指定的 Database，即默认使用当前选定的 Database。 ## `TRACE` 语句 diff --git a/support.md b/support.md index 48ee2aef75c7..8723a479d275 100644 --- a/support.md +++ b/support.md @@ -7,7 +7,7 @@ category: resources 您可以通过以下任何一种方式找到我们的社区成员： -+ Slack Channel: [http://bit.ly/tidbslack](http://bit.ly/tidbslack) ++ Slack Channel: [https://pingcap.com/tidbslack](https://pingcap.com/tidbslack) + Google Groups: [https://groups.google.com/forum/#!forum/tidb-user](https://groups.google.com/forum/#!forum/tidb-user) + Stack Overflow: [https://stackoverflow.com/questions/tagged/tidb](https://stackoverflow.com/questions/tagged/tidb) + Twitter: [https://twitter.com/PingCAP](https://twitter.com/PingCAP) diff --git a/tispark/tispark-quick-start-guide_v1.x.md b/tispark/tispark-quick-start-guide_v1.x.md index 8218a15e4710..762498fd7bbe 100644 --- a/tispark/tispark-quick-start-guide_v1.x.md +++ b/tispark/tispark-quick-start-guide_v1.x.md @@ -61,7 +61,9 @@ mysql --local-infile=1 -h 192.168.0.2 -P 4000 -u root < dss.ddl ./sample_data.sh ``` -> **注意**：执行脚本的机器上需要安装 MySQL client，CentOS 用户可通过 `yum -y install mysql` 来安装。 +> **注意：** +> +> 执行脚本的机器上需要安装 MySQL client，CentOS 用户可通过 `yum -y install mysql` 来安装。 登录 TiDB 并验证数据包含 `TPCH_001` 库及以下表： diff --git a/tispark/tispark-user-guide_v1.x.md b/tispark/tispark-user-guide_v1.x.md index b615fb319f07..e9ab0651b61f 100644 --- a/tispark/tispark-user-guide_v1.x.md +++ b/tispark/tispark-user-guide_v1.x.md @@ -110,7 +110,11 @@ ${SPARK_INSTALL_PATH}/jars 你可以在[这里](https://spark.apache.org/downloads.html)下载 Apache Spark。 -对于 Standalone 模式且无需 Hadoop 支持，则选择 Spark 2.1.x 且带有 Hadoop 依赖的 Pre-build with Apache Hadoop 2.x 任意版本。如有需要配合使用的 Hadoop 集群，则选择对应的 Hadoop 版本号。你也可以选择从源代码[自行构建](https://spark.apache.org/docs/2.1.0/building-spark.html)以配合官方 Hadoop 2.6 之前的版本。注意目前 TiSpark 仅支持 Spark 2.1.x 版本。 +对于 Standalone 模式且无需 Hadoop 支持，则选择 Spark 2.1.x 且带有 Hadoop 依赖的 Pre-build with Apache Hadoop 2.x 任意版本。如有需要配合使用的 Hadoop 集群，则选择对应的 Hadoop 版本号。你也可以选择从源代码[自行构建](https://spark.apache.org/docs/2.1.0/building-spark.html)以配合官方 Hadoop 2.6 之前的版本。 + +> **注意：** +> +> 目前 TiSpark 仅支持 Spark 2.1.x 版本。 如果你已经有了 Spark 二进制文件，并且当前 PATH 为 SPARKPATH，需将 TiSpark jar 包拷贝到 `${SPARKPATH}/jars` 目录下。 diff --git a/tools/binlog-slave-client.md b/tools/binlog/binlog-slave-client.md similarity index 84% rename from tools/binlog-slave-client.md rename to tools/binlog/binlog-slave-client.md index 58a74abf2b48..5c06c0defe92 100644 --- a/tools/binlog-slave-client.md +++ b/tools/binlog/binlog-slave-client.md @@ -5,9 +5,9 @@ category: tools # Binlog Slave Client 用户文档 -目前 Drainer 提供了多种输出方式，包括 MySQL、TiDB、TheFlash、pb 格式文件等。但是用户往往有一些自定义的需求，比如输出到 Elasticsearch、Hive 等，这些需求 Drainer 现在还没有实现，因此 Drainer 增加了输出到 Kafka 的功能，将 binlog 数据解析后按一定的格式再输出到 Kafka 中，用户编写代码从 Kafka 中读出数据再进行处理。 +目前 Drainer 提供了多种输出方式，包括 MySQL、TiDB、file 等。但是用户往往有一些自定义的需求，比如输出到 Elasticsearch、Hive 等，这些需求 Drainer 现在还没有实现，因此 Drainer 增加了输出到 Kafka 的功能，将 binlog 数据解析后按一定的格式再输出到 Kafka 中，用户编写代码从 Kafka 中读出数据再进行处理。 -## 配置 Drainer +## 配置 Kafka Drainer 修改 Drainer 的配置文件，设置输出为 Kafka，相关配置如下： @@ -52,7 +52,7 @@ message ColumnInfo { // https://dev.mysql.com/doc/refman/8.0/en/data-types.html // numeric 类型：int bigint smallint tinyint float double decimal bit // string 类型：text longtext mediumtext char tinytext varchar - // blob longblog mediumblog binary tinyblob varbinary + // blob longblob mediumblob binary tinyblob varbinary // enum set // json 类型：json optional string mysql_type = 2 [ (gogoproto.nullable) = false ]; @@ -86,9 +86,9 @@ message TableMutation { optional Row change_row = 3; } -// DMLData 保存一个表所有的 DML 造成的数据变更 +// DMLData 保存一个事务所有的 DML 造成的数据变更 message DMLData { - // `tables` 包含一个表的所有数据变更 + // `tables` 包含事务中所有表的数据变更 repeated Table tables = 1; } @@ -112,7 +112,6 @@ enum BinlogType { message Binlog { optional BinlogType type = 1 [ (gogoproto.nullable) = false ]; optional int64 commit_ts = 2 [ (gogoproto.nullable) = false ]; - // dml_data 是由 DML 类型的数据序列化后生成的数据 optional DMLData dml_data = 3; optional DDLData ddl_data = 4; } @@ -125,7 +124,7 @@ message Binlog { TiDB-Tools 项目提供了用于读取 Kafka 中 binlog 数据的 Driver，具有如下功能： * 读取 Kafka 的数据 -* 根据 commit ts 查找到 Kafka 中存储的 binlog 的位置 +* 根据 commit ts 查找 binlog 在 kafka 中的储存位置 使用该 Driver 时，用户需要配置如下信息： @@ -133,8 +132,9 @@ TiDB-Tools 项目提供了用于读取 Kafka 中 binlog 数据的 Driver，具 * CommitTS：从哪个 commit ts 开始读取 binlog * Offset：从 Kafka 哪个 offset 开始读取，如果设置了 CommitTS 就不用配置该参数 * ClusterID：TiDB 集群的 cluster ID +* Topic: Kafka Topic 名称，如果 Topic 名称为空，将会使用 drainer _obinlog 中的默认名称 -用户以包的形式引用 Driver 的代码即可使用，可以参考 Driver 中提供的的示例代码来学习如何使用 Driver 以及 binlog 数据的解析，目前提供了两个例子： +用户以包的形式引用 Driver 的代码即可使用，可以参考 Driver 中提供的示例代码来学习如何使用 Driver 以及 binlog 数据的解析，目前提供了两个例子： * 使用该 Driver 将数据同步到 MySQL，该示例包含将 binlog 转化为 SQL 的具体方法 * 使用该 Driver 将数据打印出来 diff --git a/tools/tidb-binlog-cluster.md b/tools/binlog/deploy.md similarity index 52% rename from tools/tidb-binlog-cluster.md rename to tools/binlog/deploy.md index 9f653b9b050c..5e9387da9396 100644 --- a/tools/tidb-binlog-cluster.md +++ b/tools/binlog/deploy.md @@ -1,68 +1,13 @@ --- -title: TiDB-Binlog Cluster 版本用户文档 +title: TiDB-Binlog 集群部署 category: tools --- -# TiDB-Binlog Cluster 版本用户文档 +# TiDB-Binlog 集群部署 -本文档介绍 cluster 版本 TiDB-Binlog 的架构以及部署方案。 +## 使用 TiDB-Ansible 部署 TiDB-Binlog -TiDB-Binlog 是一个用于收集 TiDB 的 Binlog，并提供实时备份和同步功能的商业工具。 - -TiDB-Binlog 支持以下功能场景： - -* **数据同步**：同步 TiDB 集群数据到其他数据库 -* **实时备份和恢复**：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复 - -## TiDB-Binlog 架构 - -TiDB-Binlog 的整体架构： - -![TiDB-Binlog 架构](../media/tidb_binlog_cluster_architecture.png) - -TiDB-Binlog 集群主要分为 Pump 和 Drainer 两个组件： - -### Pump - -Pump 用于实时记录 TiDB 产生的 Binlog，并将 Binlog 按照事务的提交时间进行排序，再提供给 Drainer 进行消费。 - -### Drainer - -Drainer 从各个 Pump 中收集 Binlog 进行归并，再将 Binlog 转化成 SQL 或者指定格式的数据，最终同步到下游。 - -## 主要特性 - -* 多个 Pump 形成一个集群，可以水平扩容； -* TiDB 通过内置的 Pump Client 将 Binlog 分发到各个 Pump； -* Pump 负责存储 Binlog，并将 Binlog 按顺序提供给 Drainer； -* Drainer 负责读取各个 Pump 的 Binlog，归并排序后发送到下游。 - -## 服务器要求 - -Pump 和 Drainer 都支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器平台上。对于开发，测试以及生产环境的服务器硬件配置有以下要求和建议： - -| 服务 | 部署数量 | CPU | 磁盘 | 内存 | -| -------- | -------- | --------| --------------- | ------ | -| Pump | 3 | 8核+ | SSD, 200 GB+ | 16G | -| Drainer | 1 | 8核+ | SAS, 100 GB+ （如果输出为本地文件，则使用 SSD，并增加磁盘大小） | 16G | - -## 注意 - -* 需要使用 TiDB v2.0.8-binlog、v2.1.0-rc.5 及以上版本，否则不兼容该版本的 TiDB-Binlog。 -* 在运行 TiDB 时，需要保证至少一个 Pump 正常运行。 -* 通过给 TiDB 增加启动参数 enable-binlog 来开启 binlog 服务。尽量保证同一集群的所有 TiDB 都开启了 binlog 服务，否则在同步数据时可能会导致上下游数据不一致。如果要临时运行一个不开启 binlog 服务的 TiDB 实例，需要在 TiDB 的配置文件中设置 `run_ddl= false`。 -* Drainer 不支持对 ignore schemas（在过滤列表中的 schemas）的 table 进行 rename DDL 操作。 -* 在已有的 TiDB 集群中启动 Drainer，一般需要全量备份并且获取 savepoint，然后导入全量备份，最后启动 Drainer 从 savepoint 开始同步增量数据。 -* Drainer 支持将 Binlog 同步到 MySQL、TiDB、Kafka 或者本地文件。如果需要将 Binlog 同步到其他类型的目的地中，可以设置 Drainer 将 Binlog 同步到 Kafka，再读取 Kafka 中的数据进行自定义处理，参考 [binlog slave client 用户文档](../tools/binlog-slave-client.md)。 -* 如果 TiDB-Binlog 用于增量恢复，可以设置下游为 `pb`，Drainer 会将 binlog 转化为指定的 proto buffer 格式的数据，再写入到本地文件中。这样就可以使用 [Reparo](../tools/reparo.md) 恢复增量数据。 -* Pump/Drainer 的状态需要区分已暂停（paused）和下线（offline），Ctrl + C 或者 kill 进程，Pump 和 Drainer 的状态都将变为 paused。暂停状态的 Pump 不需要将已保存的 Binlog 数据全部发送到 Drainer；如果需要较长时间退出 Pump（或不再使用该 Pump），需要使用 binlogctl 工具来下线 Pump。Drainer 同理。 -* 如果下游为 MySQL/TiDB，数据同步后可以使用 [sync-diff-inspector](../tools/sync-diff-inspector.md) 进行数据校验。 - -## TiDB-Binlog 部署 - -### 使用 TiDB-Ansible 部署 TiDB-Binlog - -#### 第 1 步：下载 TiDB-Ansible +### 第 1 步：下载 TiDB-Ansible 1. 以 TiDB 用户登录中控机并进入 `/home/tidb` 目录。以下为 TiDB-Ansible 分支与 TiDB 版本的对应关系，版本选择可咨询官方 info@pingcap.com。 @@ -92,7 +37,7 @@ Pump 和 Drainer 都支持部署和运行在 Intel x86-64 架构的 64 位通用 $ git clone https://github.com/pingcap/tidb-ansible.git ``` -#### 第 2 步：部署 Pump +### 第 2 步：部署 Pump 1. 修改 tidb-ansible/inventory.ini 文件 @@ -113,23 +58,23 @@ Pump 和 Drainer 都支持部署和运行在 Intel x86-64 架构的 64 位通用 172.16.10.74 ``` - 默认 Pump 保留 5 天数据，如需修改可修改 `tidb-ansible/conf/pump.yml` 文件中 `gc` 变量值，并取消注释，如修改为 7。 + 默认 Pump 保留 7 天数据，如需修改可修改 `tidb-ansible/conf/pump.yml` 文件中 `gc` 变量值，并取消注释。 ```yaml global: # an integer value to control the expiry date of the binlog data, which indicates for how long (in days) the binlog data would be stored # must be bigger than 0 - gc: 7 + # gc: 7 ``` - 请确保部署目录有足够空间存储 binlog，详见：[部署目录调整](../op-guide/ansible-deployment.md#部署目录调整)，也可为 Pump 设置单独的部署目录。 + 请确保部署目录有足够空间存储 binlog，详见：[部署目录调整](../../op-guide/ansible-deployment.md#部署目录调整)，也可为 Pump 设置单独的部署目录。 ```ini ## Binlog Part [pump_servers] pump1 ansible_host=172.16.10.72 deploy_dir=/data1/pump - pump2 ansible_host=172.16.10.73 deploy_dir=/data1/pump - pump3 ansible_host=172.16.10.74 deploy_dir=/data1/pump + pump2 ansible_host=172.16.10.73 deploy_dir=/data2/pump + pump3 ansible_host=172.16.10.74 deploy_dir=/data3/pump ``` 2. 部署并启动含 Pump 组件的 TiDB 集群 @@ -164,7 +109,7 @@ Pump 和 Drainer 都支持部署和运行在 Intel x86-64 架构的 64 位通用 **方式二**：从零开始部署含 Pump 组件的 TiDB 集群 - 使用 Ansible 部署 TiDB 集群，方法参考 [TiDB Ansible 部署方案](../op-guide/ansible-deployment.md)。 + 使用 Ansible 部署 TiDB 集群，方法参考 [TiDB Ansible 部署方案](../../op-guide/ansible-deployment.md)。 3. 查看 Pump 服务状态 @@ -179,7 +124,7 @@ Pump 和 Drainer 都支持部署和运行在 Intel x86-64 架构的 64 位通用 INFO[0000] pump: {NodeID: ip-172-16-10-74:8250, Addr: 172.16.10.74:8250, State: online, MaxCommitTS: 403051525717360643, UpdateTime: 2018-12-25 14:23:35 +0800 CST} ``` -#### 第 3 步：部署 Drainer +### 第 3 步：部署 Drainer 1. 获取 initial_commit_ts @@ -196,11 +141,7 @@ Pump 和 Drainer 都支持部署和运行在 Intel x86-64 架构的 64 位通用 该命令会输出 `meta: &{CommitTS:400962745252184065}`，CommitTS 的值作为 Drainer 初次启动使用的 `initial-commit-ts` 参数的值。 -2. 全量数据的备份与恢复 - - 推荐使用 mydumper 备份 TiDB 的全量数据，再使用 loader 将备份数据导入到下游。具体使用方法参考：[备份与恢复](https://github.com/pingcap/docs-cn/blob/master/op-guide/backup-restore.md)。 - -3. 修改 `tidb-ansible/inventory.ini` 文件 +2. 修改 `tidb-ansible/inventory.ini` 文件 为 `drainer_servers` 主机组添加部署机器 IP，initial_commit_ts 请设置为获取的 initial_commit_ts，仅用于 Drainer 第一次启动。 @@ -211,14 +152,14 @@ Pump 和 Drainer 都支持部署和运行在 Intel x86-64 架构的 64 位通用 drainer_mysql ansible_host=172.16.10.71 initial_commit_ts="402899541671542785" ``` - - 以下游为 pb 为例，别名为 `drainer_pb`。 + - 以下游为 file 为例，别名为 `drainer_file`。 ```ini [drainer_servers] - drainer_pb ansible_host=172.16.10.71 initial_commit_ts="402899541671542785" + drainer_file ansible_host=172.16.10.71 initial_commit_ts="402899541671542785" ``` -4. 修改配置文件 +3. 修改配置文件 - 以下游为 MySQL 为例 @@ -228,13 +169,15 @@ Pump 和 Drainer 都支持部署和运行在 Intel x86-64 架构的 64 位通用 $ vi drainer_mysql_drainer.toml ``` - > **注意：** 配置文件名命名规则为 `别名_drainer.toml`，否则部署时无法找到自定义配置文件。 + > **注意：** + > + > 配置文件名命名规则为 `别名_drainer.toml`，否则部署时无法找到自定义配置文件。 db-type 设置为 "mysql"， 配置下游 MySQL 信息。 ```toml # downstream storage, equal to --dest-db-type - # Valid values are "mysql", "pb", "kafka", "flash". + # Valid values are "mysql", "file", "kafka", "flash". db-type = "mysql" # the downstream MySQL protocol database @@ -243,50 +186,47 @@ Pump 和 Drainer 都支持部署和运行在 Intel x86-64 架构的 64 位通用 user = "root" password = "123456" port = 3306 - # Time and size limits for flash batch write # time-limit = "30s" # size-limit = "100000" ``` - - 以下游为 proto buffer（pb）格式的本地文件为例 + - 以下游为增量备份文件为例 ```bash $ cd /home/tidb/tidb-ansible/conf - $ cp drainer.toml drainer_pb_drainer.toml - $ vi drainer_pb_drainer.toml + $ cp drainer.toml drainer_file_drainer.toml + $ vi drainer_file_drainer.toml ``` - db-type 设置为 "pb"。 + db-type 设置为 "file"。 ```toml # downstream storage, equal to --dest-db-type - # Valid values are "mysql", "pb", "kafka", "flash". - db-type = "pb" + # Valid values are "mysql", "file", "kafka", "flash". + db-type = "file" - # Uncomment this if you want to use `pb` or `sql` as `db-type`. - # `Compress` compresses the output file, like the `pb` and `sql` file. Now it supports the `gzip` algorithm only. + # Uncomment this if you want to use `file` as `db-type`. # The value can be `gzip`. Leave it empty to disable compression. [syncer.to] - compression = "" # default data directory: "{{ deploy_dir }}/data.drainer" dir = "data.drainer" ``` -5. 部署 Drainer +4. 部署 Drainer ```bash $ ansible-playbook deploy_drainer.yml ``` -6. 启动 Drainer +5. 启动 Drainer ```bash $ ansible-playbook start_drainer.yml ``` -### 使用 Binary 部署 TiDB-Binlog +## 使用 Binary 部署 TiDB-Binlog -#### 下载官方 Binary +### 下载官方 Binary ```bash wget https://download.pingcap.org/tidb-{version}-linux-amd64.tar.gz @@ -299,14 +239,14 @@ sha256sum -c tidb-{version}-linux-amd64.sha256 对于 v2.1.0 GA 及以上版本，Pump 和 Drainer 已经包含在 TiDB 的下载包中，其他版本需要单独下载 Pump 和 Drainer: ```bash -wget https://download.pingcap.org/tidb-binlog-{version}-linux-amd64.tar.gz -wget https://download.pingcap.org/tidb-binlog-{version}-linux-amd64.sha256 +wget https://download.pingcap.org/tidb-binlog-latest-linux-amd64.tar.gz +wget https://download.pingcap.org/tidb-binlog-latest-linux-amd64.sha256 # 检查文件完整性，返回 ok 则正确 -sha256sum -c tidb-binlog-{version}-linux-amd64.sha256 +sha256sum -c tidb-binlog-latest-linux-amd64.sha256 ``` -#### 使用样例 +### 使用样例 假设有三个 PD，一个 TiDB，另外有两台机器用于部署 Pump，一台机器用于部署 Drainer。各个节点信息如下： @@ -337,12 +277,10 @@ Drainer="192.168.0.13" -advertise-addr string Pump 对外提供服务的 RPC 地址(-advertise-addr="192.168.0.11:8250") -config string - 配置文件路径，如果你指定了配置文件，Pump 会首先读取配置文件的配置； + 配置文件路径，如果你指定了配置文件，Pump 会首先读取配置文件的配置; 如果对应的配置在命令行参数里面也存在，Pump 就会使用命令行参数的配置来覆盖配置文件里的配置。 -data-dir string Pump 数据存储位置路径 - -enable-tolerant - 开启 tolerant 后，如果 binlog 写入失败，Pump 不会报错（默认开启） -gc int Pump 只保留多少天以内的数据 (默认 7) -heartbeat-interval int @@ -415,7 +353,7 @@ Drainer="192.168.0.13" -data-dir string Drainer 数据存储位置路径 (默认 "data.drainer") -dest-db-type string - Drainer 下游服务类型 (默认为 mysql，支持 kafka、pb、flash) + Drainer 下游服务类型 (默认为 mysql，支持 kafka、file、flash) -detect-interval int 向 PD 查询在线 Pump 的时间间隔 (默认 10，单位 秒) -disable-detect @@ -483,7 +421,7 @@ Drainer="192.168.0.13" disable-dispatch = false # Drainer 下游服务类型（默认为 mysql） - # 参数有效值为 "mysql"，"pb"，"kafka"，"flash" + # 参数有效值为 "mysql"，"file"，"kafka"，"flash" db-type = "mysql" # db 过滤列表 (默认 "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql,test")， @@ -515,7 +453,7 @@ Drainer="192.168.0.13" password = "" port = 3306 - # db-type 设置为 pb 时，存放 binlog 文件的目录 + # db-type 设置为 file 时，存放 binlog 文件的目录 # [syncer.to] # dir = "data.drainer" @@ -532,7 +470,9 @@ Drainer="192.168.0.13" - 启动示例 - > **注意**：如果下游为 MySQL/TiDB，为了保证数据的完整性，在 Drainer 初次启动前需要获取 initial-commit-ts 的值，并进行全量数据的备份与恢复。详细信息参见[部署 Drainer](#第-3-步部署-drainer)。 + > **注意：** + > + > 如果下游为 MySQL/TiDB，为了保证数据的完整性，在 Drainer 初次启动前需要获取 `initial-commit-ts` 的值，并进行全量数据的备份与恢复。详细信息参见[部署 Drainer](#第-3-步-部署-drainer)。 初次启动时使用参数 `initial-commit-ts`， 命令如下： @@ -542,160 +482,9 @@ Drainer="192.168.0.13" 如果命令行参数与配置文件中的参数重合，则使用命令行设置的参数的值。 -## TiDB-Binlog 运维 - -### Pump/Drainer 状态 - -Pump/Drainer 中状态的定义： - -* online：正常运行中； -* pausing：暂停中，当使用 kill 或者 Ctrl+C 退出进程时，都将处于该状态； -* paused：已暂停，处于该状态时 Pump 不接受写 binlog 的请求，也不继续为 Drainer 提供 binlog，Drainer 不再往下游同步数据。当 Pump/Drainer 安全退出了所有的线程后，将自己的状态切换为 paused，再退出进程； -* closing：下线中，使用 binlogctl 控制 Pump/Drainer 下线，在进程退出前都处于该状态。下线时 Pump 不再接受写 binlog 的请求，等待所有的 binlog 数据被 Drainer 消费完； -* offline：已下线，当 Pump 已经将已保存的所有 binlog 数据全部发送给 Drainer 后，该 Pump 将状态切换为 offline；Drainer 只需要等待各个线程退出后即可切换状态为 offline。 - > **注意：** > -> * 当暂停 Pump/Drainer 时，数据同步会中断； -> * Pump 在下线时需要确认自己的数据被所有的非 offline 状态的 Drainer 消费了，所以在下线 Pump 时需要确保所有的 Drainer 都是处于 online 状态，否则 Pump 无法正常下线； -> * Pump 保存的 binlog 数据只有在被所有非 offline 状态的 Drainer 消费的情况下才会被 GC 处理； -> * 不要轻易下线 Drainer，只有在永久不需要使用该 Drainer 的情况下才需要下线 Drainer。 - -关于 Pump/Drainer 暂停、下线、状态查询、状态修改等具体的操作方法，参考如下 binlogctl 工具的使用方法介绍。 - -### binlogctl 工具 - -[binlogctl](https://github.com/pingcap/tidb-tools/tree/master/tidb-binlog/binlogctl) 是一个 TiDB-Binlog 配套的运维工具，具有如下功能： - -* 获取当前 ts -* 查看 Pump/Drainer 状态 -* 修改 Pump/Drainer 状态 -* 暂停/下线 Pump/Drainer - -使用 binlogctl 的场景： - -* 第一次运行 Drainer，需要获取当前的 ts -* Pump/Drainer 异常退出，状态没有更新，对业务造成影响，可以直接使用该工具修改状态 -* 同步出现故障/检查运行情况，需要查看 Pump/Drainer 的状态 -* 维护集群，需要暂停/下线 Pump/Drainer - -binlogctl 下载链接： - -```bash -wget https://download.pingcap.org/binlogctl-new-linux-amd64.tar.gz -wget https://download.pingcap.org/binlogctl-new-linux-amd64.sha256 - -# 检查文件完整性，返回 ok 则正确 -sha256sum -c tidb-binlog-new-linux-amd64.sha256 -``` - -binlogctl 使用说明： - -命令行参数： - -```bash -Usage of binlogctl: --V -输出 binlogctl 的版本信息 --cmd string - 命令模式，包括 "generate_meta", "pumps", "drainers", "update-pump" ,"update-drainer", "pause-pump", "pause-drainer", "offline-pump", "offline-drainer" --data-dir string - 保存 Drainer 的 checkpoint 的文件的路径 (默认 "binlog_position") --node-id string - Pump/Drainer 的 ID --pd-urls string - PD 的地址，如果有多个，则用"," 连接 (默认 "http://127.0.0.1:2379") --ssl-ca string - SSL CAs 文件的路径 --ssl-cert string - PEM 格式的 X509 认证文件的路径 --ssl-key string - PEM 格式的 X509 key 文件的路径 --time-zone string - 如果设置时区，在 "generate_meta" 模式下会打印出获取到的 tso 对应的时间。例如"Asia/Shanghai" 为 CST 时区，"Local" 为本地时区 -``` - -命令示例： - -- 查询所有的 Pump/Drainer 的状态： - - 设置 `cmd` 为 `pumps` 或者 `drainers` 来查看所有 Pump 或者 Drainer 的状态。例如： - - ```bash - bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd pumps - - INFO[0000] pump: {NodeID: ip-172-16-30-67:8250, Addr: 172.16.30.192:8250, State: online, MaxCommitTS: 405197570529820673, UpdateTime: 2018-12-25 14:23:37 +0800 CST} - ``` - -- 修改 Pump/Drainer 的状态 - - 设置 `cmd` 为 `update-pump` 或者 `update-drainer` 来更新 Pump 或者 Drainer 的状态。Pump 和 Drainer 的状态可以为：online，pausing，paused，closing 以及 offline。例如： - - ```bash - bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd update-pump -node-id ip-127-0-0-1:8250 -state paused - ``` - - 这条命令会修改 Pump/Drainer 保存在 pd 中的状态。 - -- 暂停/下线 Pump/Drainer - - 分别设置 `cmd` 为 `pause-pump`、`pause-drainer`、`offline-pump`、`offline-drainer` 来暂停 Pump、暂停 Drainer、下线 Pump、下线 Drainer。例如： - - ```bash - bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd pause-pump -node-id ip-127-0-0-1:8250 - ``` - - binlogctl 会发送 HTTP 请求给 Pump/Drainer，Pump/Drainer 收到命令后会退出进程，并且将自己的状态设置为 paused/offline。 - -- 生成 Drainer 启动需要的 meta 文件 - - ```bash - bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd generate_meta - - INFO[0000] [pd] create pd client with endpoints [http://192.168.199.118:32379] - INFO[0000] [pd] leader switches to: http://192.168.199.118:32379, previous: - INFO[0000] [pd] init cluster id 6569368151110378289 - 2018/06/21 11:24:47 meta.go:117: [info] meta: &{CommitTS:400962745252184065} - ``` - - 该命令会生成一个文件 `{data-dir}/savepoint`， 该文件中保存了 Drainer 初次启动需要的 tso 信息。 - -## TiDB-Binlog 监控 - -使用 Ansible 部署成功后，可以进入 Grafana Web 界面（默认地址: ，默认账号：admin，密码：admin）查看 Pump 和 Drainer 的运行状态。 - -监控指标说明：[TiDB-Binlog 监控指标说明](../tools/tidb-binlog-monitor.md) - -## 版本升级方法 - -新版本的 TiDB（v2.0.8-binlog、v2.1.0-rc.5 及以上版本）不兼容 [Kafka 版本](../tools/tidb-binlog-kafka.md)以及 [Local 版本](../tools/tidb-binlog.md)的 TiDB-Binlog，集群升级到新版本后只能使用 Cluster 版本的 TiDB-Binlog。如果在升级前已经使用了 Kafka／Local 版本的 TiDB-Binlog，必须将其升级到 Cluster 版本。 - - TiDB-Binlog 版本与 TiDB 版本的对应关系如下： - -| TiDB-Binlog 版本 | TiDB 版本 | 说明 | -|---|---|---| -| Local | TiDB 1.0 及更低版本 || -| Kafka | TiDB 1.0 ~ TiDB 2.1 RC5 | TiDB 1.0 支持 local 版本和 Kafka 版本的 TiDB-Binlog。 | -| Cluster | TiDB v2.0.8-binlog，TiDB 2.1 RC5 及更高版本 | TiDB v2.0.8-binlog 是一个支持 Cluster 版本 TiDB-Binlog 的 2.0 特殊版本。 | - -升级流程： - -* 如果能接受重新导全量数据，则可以直接废弃老版本，按本文档部署。 - -* 如果想从原来的 checkpoint 继续同步，则使用以下升级流程： - 1. 部署新版本 Pump； - 2. 暂停 TiDB 集群业务； - 3. 更新 TiDB 以及配置，写 Binlog 到新的 Pump Cluster； - 4. TiDB 集群重新接入业务； - 5. 确认老版本的 Drainer 已经将老版本的 Pump 的数据完全同步到下游； - - 查询 Drainer 的 `status` 接口，示例命令如下： - - ```bash - $ curl 'http://172.16.10.49:8249/status' - {"PumpPos":{"172.16.10.49:8250":{"offset":32686}},"Synced": true ,"DepositWindow":{"Upper":398907800202772481,"Lower":398907799455662081}} - ``` - - 如果返回的 `Synced` 为 true，则可以认为 Binlog 数据已经全部同步到了下游。 - 6. 启动新版本 Drainer； - 7. 下线无用的老版本的 Pump、Drainer 以及依赖的 Kafka 和 Zookeeper。 +> - 在运行 TiDB 时，需要保证至少一个 Pump 正常运行。 +> - 通过给 TiDB 增加启动参数 `enable-binlog` 来开启 binlog 服务。尽量保证同一集群的所有 TiDB 都开启了 binlog 服务，否则在同步数据时可能会导致上下游数据不一致。如果要临时运行一个不开启 binlog 服务的 TiDB 实例，需要在 TiDB 的配置文件中设置 `run_ddl= false`。 +> - Drainer 不支持对 ignore schemas（在过滤列表中的 schemas）的 table 进行 rename DDL 操作。 +> - 在已有的 TiDB 集群中启动 Drainer，一般需要全量备份并且获取 savepoint，然后导入全量备份，最后启动 Drainer 从 savepoint 开始同步增量数据。 diff --git a/tools/tidb-binlog-monitor.md b/tools/binlog/monitor.md similarity index 57% rename from tools/tidb-binlog-monitor.md rename to tools/binlog/monitor.md index 0c5069490577..e019a64aced9 100644 --- a/tools/tidb-binlog-monitor.md +++ b/tools/binlog/monitor.md @@ -1,90 +1,42 @@ --- -title: TiDB-Binlog 监控指标说明 +title: TiDB-Binlog 集群监控 category: tools --- -# TiDB-Binlog 监控指标及告警说明 +# TiDB-Binlog 集群监控 -本文档介绍 Grafana 中 TiDB-Binlog 的各项监控指标说明，以及报警规则说明。 +使用 Ansible 成功部署 TiDB-Binlog 集群后，可以进入 Grafana Web 界面（默认地址: ，默认账号：admin，密码：admin）查看 Pump 和 Drainer 的运行状态。 ## 监控指标 ### Pump -#### Storage Size - -- 记录磁盘的总空间大小 (capacity)，以及可用磁盘空间大小 (available)。 - -#### Metadata - -- 记录每个 Pump 的可删除 binlog 的最大 tso (gc_tso)，以及保存的 binlog 的最大的 commit tso (max_commit_tso)。 - -#### Write Binlog QPS by Instance - -- 每个 Pump 接收到的写 binlog 请求的 QPS。 - -#### Write Binlog Latency - -- 记录每个 Pump 写 binlog 的延迟时间。 - -#### Storage Write Binlog Size - -- Pump 写 binlog 数据的大小。 - -#### Storage Write Binlog Latency - -- Pump 中的 storage 模块写 binlog 数据的延迟。 - -#### Pump Storage Error By Type - -- Pump 遇到的 error 数量，按照 error 的类型进行统计。 - -#### Query TiKV - -- Pump 通过 TiKV 查询事务状态的次数。 +| metric 名称 | 说明 | +|:----|:------------| +| Storage Size | 记录磁盘的总空间大小 (capacity)，以及可用磁盘空间大小 (available) | +| Metadata | 记录每个 Pump 的可删除 binlog 的最大 tso (gc_tso)，以及保存的 binlog 的最大的 commit tso (max_commit_tso)。 | +| Write Binlog QPS by Instance | 每个 Pump 接收到的写 binlog 请求的 QPS | +| Write Binlog Latency | 记录每个 Pump 写 binlog 的延迟时间 | +| Storage Write Binlog Size | Pump 写 binlog 数据的大小 | +| Storage Write Binlog Latency | Pump 中的 storage 模块写 binlog 数据的延迟 | +| Pump Storage Error By Type | Pump 遇到的 error 数量，按照 error 的类型进行统计 | +| Query TiKV | Pump 通过 TiKV 查询事务状态的次数 | ### Drainer -#### Checkpoint TSO - -- Drainer 已经同步到下游的 binlog 的最大 TSO 对应的时间。可以通过该指标估算同步延迟时间。 - -#### Pump Handle TSO - -- 记录 Drainer 从各个 Pump 获取到的 binlog 的最大 TSO 对应的时间。 - -#### Pull Binlog QPS by Pump NodeID - -- Drainer 从每个 Pump 获取 binlog 的 QPS。 - -#### 95% Binlog Reach Duration By Pump - -- 记录 binlog 从写入 Pump 到被 Drainer 获取到这个过程的延迟时间。 - -#### Error By Type - -- Drainer 遇到的 error 数量，按照 error 的类型进行统计。 - -#### Drainer Event - -- 各种类型 event 的数量，event 包括 ddl、insert、delete、update、flush、savepoint。 - -#### Execute Time - -- 在下游执行 SQL 语句或写数据所消耗的时间。 - -#### 95% Binlog Size - -- Drainer 从各个 Pump 获取到 binlog 数据的大小。 - -#### DDL Job Count - -- Drainer 处理的 DDL 的数量。 +| metric 名称 | 说明 | +|:----|:------------| +| Checkpoint TSO | Drainer 已经同步到下游的 binlog 的最大 TSO 对应的时间。可以通过该指标估算同步延迟时间 | +| Pump Handle TSO | 记录 Drainer 从各个 Pump 获取到的 binlog 的最大 TSO 对应的时间 | | Pull Binlog QPS by Pump NodeID | Drainer 从每个 Pump 获取 binlog 的 QPS | +| 95% Binlog Reach Duration By Pump | 记录 binlog 从写入 Pump 到被 Drainer 获取到这个过程的延迟时间 | +| Error By Type | Drainer 遇到的 error 数量，按照 error 的类型进行统计 | +| Drainer Event | 各种类型 event 的数量，event 包括 ddl、insert、delete、update、flush、savepoint | +| Execute Time | 在下游执行 SQL 语句或写数据所消耗的时间 | +| 95% Binlog Size | Drainer 从各个 Pump 获取到 binlog 数据的大小 | +| DL Job Count | Drainer 处理的 DDL 的数量| ## 监控告警规则 -目前对 TiDB-Binlog 中一些比较重要的方面配置了监控，根据指标的重要程度分为 Emergency、Critical 和 Warning 三种级别。 - ### Emergency #### binlog_pump_storage_error_count @@ -104,12 +56,12 @@ category: tools - 判断从 Pump 获取数据是否太慢： 监控 Pump handle tso 可以看每个 Pump 最近一条消息的时间，是不是有延迟特别大的 Pump，确认对应 Pump 正常运行 - + - 根据 Drainer event 和 Drainer execute latency 来判断是否下游同步太慢： - + - 如果 Drainer execute time 过大，则检查到目标库网络带宽和延迟，以及目标库状态 - 如果 Drainer execute time 不大，Drainer event 过小，则增加 work count 和 batch 进行重试 - + - 上面都不满足或者操作后没有改观，则报备开发 support@pingcap.com 进行处理 ### Warning @@ -143,7 +95,7 @@ category: tools #### binlog_drainer_execute_duration_time_more_than_10s -- 含义：Drainer 同步到 TiDB 的 transaction 耗时；如果过大则影响 Drainer 同步 +- 含义：Drainer 同步到 TiDB 的 transaction 耗时，如果过大则影响 Drainer 同步 - 监控规则：histogram_quantile(0.9, rate(binlog_drainer_execute_duration_time_bucket[1m])) > 10 - 处理方法： diff --git a/tools/binlog/operation.md b/tools/binlog/operation.md new file mode 100644 index 000000000000..6d7eb7b0053c --- /dev/null +++ b/tools/binlog/operation.md @@ -0,0 +1,131 @@ +--- +title: TiDB-Binlog 集群运维 +category: tools +--- + +# TiDB-Binlog 集群运维 + +## Pump/Drainer 状态 + +Pump/Drainer 中状态的定义： + +* online：正常运行中。 +* pausing：暂停中，当使用 kill 或者 Ctrl+C 退出进程时，都将处于该状态。当 Pump/Drainer 安全退出了所有的内部线程后，将自己的状态切换为 paused。 +* paused：已暂停，处于该状态时 Pump 不接受写 binlog 的请求，也不继续为 Drainer 提供 binlog，Drainer 不再往下游同步数据。 +* closing：下线中，使用 binlogctl 控制 Pump/Drainer 下线，在进程退出前都处于该状态。下线时 Pump 不再接受写 binlog 的请求，等待所有的 binlog 数据被 Drainer 消费完。 +* offline：已下线，当 Pump 已经将已保存的所有 binlog 数据全部发送给 Drainer 后，该 Pump 将状态切换为 offline。 + +> **注意：** +> +> * 当暂停 Pump/Drainer 时，数据同步会中断。 +> * Pump/Drainer 的状态需要区分已暂停（paused）和下线（offline），Ctrl + C 或者 kill 进程，Pump 和 Drainer 的状态会变为 pausing，最终变为 paused。进入 paused 状态前 Pump 不需要将已保存的 Binlog 数据全部发送到 Drainer，进入 offline 状态前 pump 需要将已保存的 Binlog 数据全部发送到 Drainer。如果需要较长时间退出 Pump（或不再使用该 Pump），需要使用 binlogctl 工具来下线 Pump。Drainer 同理。 +> * Pump 在下线时需要确认自己的数据被所有的非 offline 状态的 Drainer 消费了，所以在下线 Pump 时需要确保所有的 Drainer 都是处于 online 状态，否则 Pump 无法正常下线。 +> * Pump 保存的 binlog 数据只有在被所有非 offline 状态的 Drainer 消费的情况下才会被 GC 处理。 +> * 不要轻易下线 Drainer，只有在永久不需要使用该 Drainer 的情况下才需要下线 Drainer。 + +关于 Pump/Drainer 暂停、下线、状态查询、状态修改等具体的操作方法，参考如下 binlogctl 工具的使用方法介绍。 + +## binlogctl 工具 + +* 获取 TiDB 集群当前的 TSO +* 查看 Pump/Drainer 状态 +* 修改 Pump/Drainer 状态 +* 暂停/下线 Pump/Drainer + +使用 binlogctl 的场景： + +* 第一次运行 Drainer，需要获取 TiDB 集群当前的 TSO +* Pump/Drainer 异常退出，状态没有更新，对业务造成影响，可以直接使用该工具修改状态 +* 同步出现故障/检查运行情况，需要查看 Pump/Drainer 的状态 +* 维护集群，需要暂停/下线 Pump/Drainer + +binlogctl 下载链接： + +```bash +wget https://download.pingcap.org/tidb-{version}-linux-amd64.tar.gz +wget https://download.pingcap.org/tidb-{version}-linux-amd64.sha256 + +# 检查文件完整性，返回 ok 则正确 +sha256sum -c tidb-{version}-linux-amd64.sha256 +``` + +对于 v2.1.0 GA 及以上版本，binlogctl 已经包含在 TiDB 的下载包中，其他版本需要单独下载 binlogctl: + +```bash +wget https://download.pingcap.org/tidb-enterprise-tools-latest-linux-amd64.tar.gz +wget https://download.pingcap.org/tidb-enterprise-tools-latest-linux-amd64.sha256 + +# 检查文件完整性，返回 ok 则正确 +sha256sum -c tidb-enterprise-tools-latest-linux-amd64.sha256 +``` + +binlogctl 使用说明： + +命令行参数： + +```bash +Usage of binlogctl: +-V +输出 binlogctl 的版本信息 +-cmd string + 命令模式，包括 "generate_meta", "pumps", "drainers", "update-pump" ,"update-drainer", "pause-pump", "pause-drainer", "offline-pump", "offline-drainer" +-data-dir string + 保存 Drainer 的 checkpoint 的文件的路径 (默认 "binlog_position") +-node-id string + Pump/Drainer 的 ID +-pd-urls string + PD 的地址，如果有多个，则用"," 连接 (默认 "http://127.0.0.1:2379") +-ssl-ca string + SSL CAs 文件的路径 +-ssl-cert string + PEM 格式的 X509 认证文件的路径 +-ssl-key string + PEM 格式的 X509 key 文件的路径 +-time-zone string + 如果设置时区，在 "generate_meta" 模式下会打印出获取到的 tso 对应的时间。例如"Asia/Shanghai" 为 CST 时区，"Local" 为本地时区 +``` + +命令示例： + +- 查询所有的 Pump/Drainer 的状态： + + 设置 `cmd` 为 `pumps` 或者 `drainers` 来查看所有 Pump 或者 Drainer 的状态。例如： + + ```bash + bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd pumps + + [2019/04/28 09:29:59.016 +00:00] [INFO] [nodes.go:48] ["query node"] [type=pump] [node="{NodeID: 1.1.1.1:8250, Addr: pump:8250, State: online, MaxCommitTS: 408012403141509121, UpdateTime: 2019-04-28 09:29:57 +0000 UTC}"] + ``` + +- 修改 Pump/Drainer 的状态 + + 设置 `cmd` 为 `update-pump` 或者 `update-drainer` 来更新 Pump 或者 Drainer 的状态。Pump 和 Drainer 的状态可以为：online，pausing，paused，closing 以及 offline。例如： + + ```bash + bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd update-pump -node-id ip-127-0-0-1:8250 -state paused + ``` + + 这条命令会修改 Pump/Drainer 保存在 PD 中的状态。 + +- 暂停/下线 Pump/Drainer + + 分别设置 `cmd` 为 `pause-pump`、`pause-drainer`、`offline-pump`、`offline-drainer` 来暂停 Pump、暂停 Drainer、下线 Pump、下线 Drainer。例如： + + ```bash + bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd pause-pump -node-id ip-127-0-0-1:8250 + ``` + + binlogctl 会发送 HTTP 请求给 Pump/Drainer，Pump/Drainer 收到命令后会退出进程，并且将自己的状态设置为 paused/offline。 + +- 生成 Drainer 启动需要的 meta 文件 + + ```bash + bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd generate_meta + + INFO[0000] [pd] create pd client with endpoints [http://192.168.199.118:32379] + INFO[0000] [pd] leader switches to: http://192.168.199.118:32379, previous: + INFO[0000] [pd] init cluster id 6569368151110378289 + [2019/04/28 09:33:15.950 +00:00] [INFO] [meta.go:114] ["save meta"] [meta="commitTS: 408012454863044609"] + ``` + + 该命令会生成一个文件 `{data-dir}/savepoint`，该文件中保存了 Drainer 初次启动需要的 tso 信息。 diff --git a/tools/binlog/overview.md b/tools/binlog/overview.md new file mode 100644 index 000000000000..c874c2593ac9 --- /dev/null +++ b/tools/binlog/overview.md @@ -0,0 +1,60 @@ +--- +title: TiDB-Binlog 简介 +category: tools +aliases: ['/docs-cn/tools/tidb-binlog-cluster/'] +--- + +# TiDB-Binlog 简介 + +TiDB-Binlog 是一个用于收集 TiDB 的 Binlog，并提供实时备份和同步功能的商业工具。 + +TiDB-Binlog 支持以下功能场景： + +- **数据同步**：同步 TiDB 集群数据到其他数据库 +- **实时备份和恢复**：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复 + +## TiDB-Binlog 整体架构 + +![TiDB-Binlog 架构](/media/tidb_binlog_cluster_architecture.png) + +TiDB-Binlog 集群主要分为 Pump 和 Drainer 两个组件，以及 binlogctl 工具： + +### Pump + +Pump 用于实时记录 TiDB 产生的 Binlog，并将 Binlog 按照事务的提交时间进行排序，再提供给 Drainer 进行消费。 + +### Drainer + +Drainer 从各个 Pump 中收集 Binlog 进行归并，再将 Binlog 转化成 SQL 或者指定格式的数据，最终同步到下游。 + +### binlogctl 工具 + +[binlogctl](https://github.com/pingcap/tidb-tools/tree/master/tidb-binlog/binlogctl) 是一个 TiDB-Binlog 配套的运维工具，具有如下功能： + +* 获取 TiDB 集群当前的 TSO +* 查看 Pump/Drainer 状态 +* 修改 Pump/Drainer 状态 +* 暂停/下线 Pump/Drainer + +## 主要特性 + +* 多个 Pump 形成一个集群，可以水平扩容。 +* TiDB 通过内置的 Pump Client 将 Binlog 分发到各个 Pump。 +* Pump 负责存储 Binlog，并将 Binlog 按顺序提供给 Drainer。 +* Drainer 负责读取各个 Pump 的 Binlog，归并排序后发送到下游。 + +## 服务器要求 + +Pump 和 Drainer 都支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器平台上。对于开发，测试以及生产环境的服务器硬件配置有以下要求和建议： + +| 服务 | 部署数量 | CPU | 磁盘 | 内存 | +| -------- | -------- | --------| --------------- | ------ | +| Pump | 3 | 8核+ | SSD, 200 GB+ | 16G | +| Drainer | 1 | 8核+ | SAS, 100 GB+ （如果输出为本地文件，则使用 SSD，并增加磁盘大小） | 16G | + +## 注意事项 + +* 需要使用 TiDB v2.0.8-binlog、v2.1.0-rc.5 及以上版本，否则不兼容该版本的 TiDB-Binlog。 +* Drainer 支持将 Binlog 同步到 MySQL、TiDB、Kafka 或者本地文件。如果需要将 Binlog 同步到其他 Drainer 不支持的类型的系统中，可以设置 Drainer 将 Binlog 同步到 Kafka，然后根据 binlog slave protocol 进行定制处理，参考 [binlog slave client 用户文档](/tools/binlog/binlog-slave-client.md)。 +* 如果 TiDB-Binlog 用于增量恢复，可以设置配置项 `db-type="file"`，Drainer 会将 binlog 转化为指定的 [proto buffer 格式](https://github.com/pingcap/tidb-binlog/blob/master/proto/binlog.proto)的数据，再写入到本地文件中。这样就可以使用 [Reparo](/tools/binlog/reparo.md) 恢复增量数据。 +* 如果下游为 MySQL/TiDB，数据同步后可以使用 [sync-diff-inspector](/tools/sync-diff-inspector.md) 进行数据校验。 diff --git a/tools/reparo.md b/tools/binlog/reparo.md similarity index 75% rename from tools/reparo.md rename to tools/binlog/reparo.md index 6cf16a259f7d..f842cc3a2a42 100644 --- a/tools/reparo.md +++ b/tools/binlog/reparo.md @@ -7,7 +7,7 @@ category: tools Reparo 是 TiDB-Binlog 的一个配套工具，用于增量的恢复。使用 TiDB-Binlog 中的 Drainer 将 binlog 按照 protobuf 格式输出到文件，通过这种方式来备份增量数据。当需要恢复增量数据时，使用 Reparo 解析文件中的 binlog，并将其应用到 TiDB／MySQL 中。 -下载链接：[reparo-latest-linux-amd64.tar.gz](https://download.pingcap.org/reparo-latest-linux-amd64.tar.gz) +下载链接：[tidb-binlog-cluster-latest-linux-amd64.tar.gz](http://download.pingcap.org/tidb-binlog-cluster-latest-linux-amd64.tar.gz) ## Reparo 使用 @@ -83,11 +83,11 @@ password = "" ./bin/reparo -config reparo.toml ``` -### 注意 - -* data-dir 用于指定 Drainer 输出的 binlog 文件目录。 -* start-datatime 和 start-tso 效果一样，只是时间格式上的区别，用于指定开始恢复的时间点；如果不指定，则默认在第一个 binlog 文件开始恢复。 -* stop-datetime 和 stop-tso 效果一样，只是时间格式上的区别，用于指定结束恢复的时间点；如果不指定，则恢复到最后一个 binlog 文件的结尾。 -* dest-type 指定目标类型，取值为 ｀mysql｀, ｀print｀。 当值为 ｀mysql｀ 时，可以恢复到 MySQL/TiDB 等使用或兼容 MySQL 协议的数据库，需要在配置下面的 [dest-db] 填写数据库信息；当取值为 ｀print｀ 的时候，只是打印 binlog 信息，通常用于 debug，以及查看 binlog 的内容，此时不需要填写 [dest-db] 。 -* replicate-do-db 用于指定恢复的库，不指定的话，则全部都恢复。 -* replicate-do-table 用于指定要恢复的表，不指定的话，则全部都恢复。 \ No newline at end of file +> **注意：** +> +> - data-dir 用于指定 Drainer 输出的 binlog 文件目录。 +> - start-datatime 和 start-tso 效果一样，只是时间格式上的区别，用于指定开始恢复的时间点；如果不指定，则默认在第一个 binlog 文件开始恢复。 +> - stop-datetime 和 stop-tso 效果一样，只是时间格式上的区别，用于指定结束恢复的时间点；如果不指定，则恢复到最后一个 binlog 文件的结尾。 +> - dest-type 指定目标类型，取值为 `mysql`、`print`。 当值为 `mysql` 时，可以恢复到 MySQL/TiDB 等使用或兼容 MySQL 协议的数据库，需要在配置下面的 [dest-db] 填写数据库信息；当取值为 `print` 的时候，只是打印 binlog 信息，通常用于 debug，以及查看 binlog 的内容，此时不需要填写 `[dest-db]`。 +> - replicate-do-db 用于指定恢复的库，不指定的话，则全部都恢复。 +> - replicate-do-table 用于指定要恢复的表，不指定的话，则全部都恢复。 \ No newline at end of file diff --git a/tools/tidb-binlog-kafka.md b/tools/binlog/tidb-binlog-kafka.md similarity index 90% rename from tools/tidb-binlog-kafka.md rename to tools/binlog/tidb-binlog-kafka.md index dc5a1d37fb58..d0f1024680ab 100644 --- a/tools/tidb-binlog-kafka.md +++ b/tools/binlog/tidb-binlog-kafka.md @@ -1,26 +1,26 @@ --- -title: TiDB-Binlog 部署方案 +title: TiDB-Binlog kafka 部署方案 category: tools --- -# TiDB-Binlog 部署方案 +# TiDB-Binlog Kafka 部署方案 本文档介绍如何部署 Kafka 版本的 TiDB-Binlog。 ## TiDB-Binlog 简介 -TiDB-Binlog 用于收集 TiDB 的 Binlog，并提供实时备份和同步功能的商业工具。 +TiDB-Binlog 是用于收集 TiDB 的 Binlog，并提供实时备份和同步功能的商业工具。 TiDB-Binlog 支持以下功能场景: -* **数据同步**：同步 TiDB 集群数据到其他数据库 -* **实时备份和恢复**：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复 +- **数据同步**：同步 TiDB 集群数据到其他数据库 +- **实时备份和恢复**：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复 -## TiDB-Binlog 架构 +## TiDB-Binlog Kafka 架构 首先介绍 TiDB-Binlog 的整体架构。 -![TiDB-Binlog 架构](../media/tidb_binlog_kafka_architecture.png) +![TiDB-Binlog 架构](/media/tidb_binlog_kafka_architecture.png) TiDB-Binlog 集群主要分为三个组件： @@ -36,15 +36,17 @@ Drainer 从 Kafka 中收集 Binlog，并按照 TiDB 中事务的提交顺序转 Kafka 集群用来存储由 Pump 写入的 Binlog 数据，并提供给 Drainer 进行读取。 -> **注**：local 版本将 Binlog 存储在文件中，最新版本则使用 Kafka 存储。 +> **注意：** +> +> Local 版本将 Binlog 存储在文件中，Kafka 版本则使用 Kafka 存储。 ## TiDB-Binlog 安装 以下为 TiDB-Ansible 分支与 TiDB 版本的对应关系，版本选择可咨询官方 info@pingcap.com。 - | TiDB-Ansible 分支 | TiDB 版本 | 备注 | - | ---------------- | --------- | --- | - | release-2.0 | 2.0 版本 | 最新 2.0 稳定版本，可用于生产环境。 | +| TiDB-Ansible 分支 | TiDB 版本 | 备注 | +|:----|:----|:----| +| release-2.0 | 2.0 版本 | 最新 2.0 稳定版本，可用于生产环境。 | ### 下载官方 Binary @@ -65,26 +67,26 @@ cd tidb-binlog-kafka-linux-amd64 ### TiDB-Binlog 部署 -#### 注意 +#### 注意事项 * 需要为一个 TiDB 集群中的每台 TiDB server 部署一个 Pump，目前 TiDB server 只支持以 unix socket 的方式输出 Binlog。 -* 手动部署时，启动优先级为：Pump > TiDB；停止优先级为 TiDB > Pump。 +* 手动部署时，启动顺序为：Pump > TiDB。停止顺序为 TiDB > Pump。 设置 TiDB 启动参数 `binlog-socket` 为对应的 Pump 参数 `socket` 所指定的 unix socket 文件路径，最终部署结构如下图所示： - ![TiDB pump 模块部署结构](../media/tidb-pump-deployment.png) + ![TiDB pump 模块部署结构](../../media/tidb-pump-deployment.png) * Drainer 不支持对 ignore schemas（在过滤列表中的 schemas）的 table 进行 rename DDL 操作。 -* 在已有的 TiDB 集群中启动 Drainer，一般需要全量备份并且获取 savepoint，然后导入全量备份，最后启动 Drainer 从 savepoint 开始同步； +* 在已有的 TiDB 集群中启动 Drainer，一般需要全量备份并且获取 savepoint，然后导入全量备份，最后启动 Drainer 从 savepoint 开始同步。 为了保证数据的完整性，在 Pump 运行 10 分钟左右后按顺序进行如下操作： * 使用 [tidb-tools](https://github.com/pingcap/tidb-tools) 项目中的 [binlogctl](https://github.com/pingcap/tidb-tools/tree/master/tidb-binlog/binlogctl) 工具生成 Drainer 初次启动所需的 position * 全量备份，例如 mydumper 备份 TiDB * 全量导入备份到目标系统 - * Kafka 版本 Drainer 启动的 savepoint 默认保存在下游 database tidb_binlog 下的 checkpoint 表中，如果 checkpoint 表中没有效的数据，可以通过设置 `initial-commit-ts` 启动 Drainer 从指定位置开始消费 - `bin/drainer --config=conf/drainer.toml --initial-commit-ts=${position}` + * Kafka 版本 Drainer 启动的 savepoint 默认保存在下游 database tidb_binlog 下的 checkpoint 表中，如果 checkpoint 表中没有有效的数据，可以通过设置 `initial-commit-ts` 启动 Drainer 从指定位置开始消费 - `bin/drainer --config=conf/drainer.toml --initial-commit-ts=${position}` * Drainer 输出为 pb，要在配置文件中设置如下参数： @@ -103,10 +105,10 @@ cd tidb-binlog-kafka-linux-amd64 [syncer] db-type = "kafka" - # when db-type is kafka, you can uncomment this to config the down stream kafka, or it will be the same kafka addrs where drainer pull binlog from. - #[syncer.to] - # kafka-addrs = "127.0.0.1:9092" - # kafka-version = "0.8.2.0" + # when db-type is kafka, you need to use this to config the down stream kafka, or it will be the same kafka addrs where drainer pull binlog from. + [syncer.to] + kafka-addrs = "127.0.0.1:9092" + kafka-version = "0.8.2.0" ``` 输出到 kafka 的数据为按 ts 排好序的 protobuf 定义 binlog 格式，可以参考 [driver](https://github.com/pingcap/tidb-tools/tree/master/tidb-binlog/driver) 获取数据同步到下游。 @@ -123,7 +125,7 @@ cd tidb-binlog-kafka-linux-amd64 #### Kafka 配置参数推荐 - `auto.create.topics.enable = true`：如果还没有创建 topic，Kafka 会在 broker 上自动创建 topic -- `broker.id`：用来标识 Kafka 集群的必备参数，不能重复；如 `broker.id = 1` +- `broker.id`：用来标识 Kafka 集群的必备参数，不能重复，如 `broker.id = 1` - `fs.file-max = 1000000`：Kafka 会使用大量文件和网络 socket，建议修改成 1000000，通过 `vi /etc/sysctl.conf` 进行修改 - 修改以下配置为1G, 否则很容易出现事务修改数据较多导致单个消息过大写 kafka 失败 @@ -164,9 +166,9 @@ ZK2="192.168.0.12" ZK3="192.168.0.11" ``` -在 ip="192.168.0.10" 的机器上面部署 Drainer/Pump； +在 ip="192.168.0.10" 的机器上面部署 Drainer/Pump。 -对应的 PD 集群的 ip="192.168.0.16,192.168.0.15,192.168.0.14"； +对应的 PD 集群的 ip="192.168.0.16,192.168.0.15,192.168.0.14"。 对应的 Kafka 集群的 ZooKeeper 的 ip="192.168.0.13,192.168.0.12,192.168.0.11"。以此为例，说明 Pump/Drainer 的使用。 @@ -413,8 +415,10 @@ PbReader 使用示例 + 进入 Grafana Web 界面（默认地址: `http://localhost:3000`，默认账号：admin，密码：admin） 点击 Grafana Logo -> 点击 Data Sources -> 点击 Add data source -> 填写 data source 信息 - - > **注：**Type 选 Prometheus，URL 为 Prometheus 地址，根据实际情况添加/填写。 + + > **注意：** + > + > Type 选 Prometheus，URL 为 Prometheus 地址，根据实际情况添加/填写。 + 导入 dashboard 配置文件 diff --git a/tools/tidb-binlog.md b/tools/binlog/tidb-binlog-local.md similarity index 89% rename from tools/tidb-binlog.md rename to tools/binlog/tidb-binlog-local.md index 65f0ffa6b69c..a3686f56a189 100644 --- a/tools/tidb-binlog.md +++ b/tools/binlog/tidb-binlog-local.md @@ -1,56 +1,52 @@ --- -title: TiDB-Binlog 部署方案 +title: TiDB-Binlog Local 部署方案 category: tools --- -# TiDB-Binlog 部署方案 +# TiDB-Binlog Local 部署方案 -## TiDB-Binlog 简介 +## TiDB-Binlog-local 简介 -TiDB-Binlog 用于收集 TiDB 的 Binlog，并提供实时备份和同步功能的商业工具。 +TiDB-Binlog 是用于收集 TiDB 的 Binlog，并提供实时备份和同步功能的商业工具。 TiDB-Binlog 支持以下功能场景: * **数据同步**：同步 TiDB 集群数据到其他数据库。 * **实时备份和恢复**：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复。 -## TiDB-Binlog 架构 +## TiDB-Binlog-local 架构 -首先介绍 TiDB-Binlog 的整体架构。 +下图为 TiDB-Binlog 的整体架构。 -![TiDB-Binlog 架构](../media/architecture.jpeg) +![TiDB-Binlog 架构](/media/architecture.jpeg) TiDB-Binlog 集群主要分为两个组件： -#### Pump +- **Pump** 是一个守护进程，在每个 TiDB 的主机上后台运行。他的主要功能是实时记录 TiDB 产生的 Binlog 并顺序写入磁盘文件 -Pump 是一个守护进程，在每个 TiDB 的主机上后台运行。他的主要功能是实时记录 TiDB 产生的 Binlog 并顺序写入磁盘文件 +- **Drainer** 从各个 Pump 节点收集 Binlog，并按照在 TiDB 中事务的提交顺序转化为指定数据库兼容的 SQL 语句，最后同步到目的数据库或者写到顺序文件 -#### Drainer +## TiDB-Binlog-local 安装 -Drainer 从各个 Pump 节点收集 Binlog，并按照在 TiDB 中事务的提交顺序转化为指定数据库兼容的 SQL 语句，最后同步到目的数据库或者写到顺序文件 +### TiDB-Binlog-local 下载 -## TiDB-Binlog 安装 +TiDB-Binlog 包含在 tidb-enterprise-tools 安装包中，可[在此下载](/tools/download.md)。 -### TiDB-Binlog 下载 - -TiDB-Binlog 包含在 tidb-enterprise-tools 安装包中，可[在此下载](../tools/download.md)。 - -### TiDB-Binlog 部署 +### TiDB-Binlog-local 部署 #### 注意 * 需要为一个 TiDB 集群中的每台 TiDB server 部署一个 Pump，目前 TiDB server 只支持以 unix socket 方式的输出 binlog。 -* 手动部署时， 启动优先级为： Pump > TiDB ； 停止优先级为 TiDB > Pump +* 手动部署时， 启动顺序为： Pump > TiDB，停止顺序为 TiDB > Pump 我们设置 TiDB 启动参数 binlog-socket 为对应的 Pump 的参数 socket 所指定的 unix socket 文件路径，最终部署结构如下图所示： - ![TiDB pump 模块部署结构](../media/tidb-pump-deployment.png) + ![TiDB pump 模块部署结构](/media/tidb-pump-deployment.png) * drainer 不支持对 ignore schemas（在过滤列表中的 schemas） 的 table 进行 rename DDL 操作 -* 在已有的 TiDB 集群中启动 drainer，一般需要全量备份 并且获取 savepoint，然后导入全量备份，最后启动 drainer 从 savepoint 开始同步； +* 在已有的 TiDB 集群中启动 drainer，一般需要全量备份 并且获取 savepoint，然后导入全量备份，最后启动 drainer 从 savepoint 开始同步。 为了保证数据的完整性，在 pump 运行 10 分钟左右后按顺序进行下面的操作 @@ -70,7 +66,7 @@ TiDB-Binlog 包含在 tidb-enterprise-tools 安装包中，可[在此下载](../ dir = "/path/pb-dir" ``` -#### 使用 tidb-ansible 部署 PUMP (推荐) +#### 使用 tidb-ansible 部署 Pump (推荐) * 搭建全新的 TiDB Cluster，启动顺序 pd-server -> tikv-server -> pump -> tidb-server -> drainer * 修改 tidb-ansible inventory.ini 文件 @@ -85,7 +81,7 @@ TiDB-Binlog 包含在 tidb-enterprise-tools 安装包中，可[在此下载](../ * 执行 ansible-playbook rolling_update.yml --tags=tidb * drainer 目前需要手动部署 -#### 使用 Binary 部署 PUMP +#### 使用 Binary 部署 Pump 1. PUMP 命令行参数说明 diff --git a/tools/binlog/upgrade.md b/tools/binlog/upgrade.md new file mode 100644 index 000000000000..683071ea578c --- /dev/null +++ b/tools/binlog/upgrade.md @@ -0,0 +1,42 @@ +--- +title: TiDB-Binlog Cluster 版本升级方法 +category: tools +--- + +# TiDB-Binlog Cluster 版本升级方法 + +新版本的 TiDB（v2.0.8-binlog、v2.1.0-rc.5 及以上版本）不兼容 [Kafka 版本](/tools/binlog/tidb-binlog-kafka.md)以及 [Local 版本](/tools/binlog/tidb-binlog-local.md)的 TiDB-Binlog，集群升级到新版本后只能使用 Cluster 版本的 TiDB-Binlog。如果在升级前已经使用了 Kafka／Local 版本的 TiDB-Binlog，必须将其升级到 Cluster 版本。 + +TiDB-Binlog 版本与 TiDB 版本的对应关系如下： + +| TiDB-Binlog 版本 | TiDB 版本 | 说明 | +|---|---|---| +| Local | TiDB 1.0 及更低版本 || +| Kafka | TiDB 1.0 ~ TiDB 2.1 RC5 | TiDB 1.0 支持 local 版本和 Kafka 版本的 TiDB-Binlog。 | +| Cluster | TiDB v2.0.8-binlog，TiDB 2.1 RC5 及更高版本 | TiDB v2.0.8-binlog 是一个支持 Cluster 版本 TiDB-Binlog 的 2.0 特殊版本。 | + +## 升级流程 + +> **注意：** +> +> 如果能接受重新导全量数据，则可以直接废弃老版本，按 [TiDB-Binlog 集群部署](/tools/binlog/deploy.md)中的步骤重新部署。 + +如果想从原来的 checkpoint 继续同步，使用以下升级流程： + +1. 部署新版本 Pump。 +2. 暂停 TiDB 集群业务。 +3. 更新 TiDB 以及配置，写 Binlog 到新的 Pump Cluster。 +4. TiDB 集群重新接入业务。 +5. 确认老版本的 Drainer 已经将老版本的 Pump 的数据完全同步到下游。 + + 查询 Drainer 的 `status` 接口，示例命令如下： + + ```bash + $ curl 'http://172.16.10.49:8249/status' + {"PumpPos":{"172.16.10.49:8250":{"offset":32686}},"Synced": true ,"DepositWindow":{"Upper":398907800202772481,"Lower":398907799455662081}} + ``` + + 如果返回的 `Synced` 为 true，则可以认为 Binlog 数据已经全部同步到了下游。 + +6. 启动新版本 Drainer； +7. 下线老版本的 Pump、Drainer 以及依赖的 Kafka 和 ZookeSeper。 diff --git a/tools/dm/cluster-operations.md b/tools/dm/cluster-operations.md index d8045ca4f17a..db4508bb0959 100644 --- a/tools/dm/cluster-operations.md +++ b/tools/dm/cluster-operations.md @@ -74,7 +74,9 @@ DM-master 重启时会自动向每个 DM-worker 实例请求任务信息，重 ### 重启 DM-worker -> **注意**：尽量避免在 sharding DDL 同步过程中重启 DM-worker。 +> **注意：** +> +> 尽量避免在 sharding DDL 同步过程中重启 DM-worker。 使用以下两种方法中任一种重启 DM-worker 组件： @@ -157,7 +159,7 @@ DM-master 重启时会自动向每个 DM-worker 实例请求任务信息，重 1. 为中控机设置 SSH 互信以及 sudo 规则。 - 1. 参考[在中控机上配置 SSH 互信和 sudo 规则](/tools/dm/deployment.md#第-5-步-在中控机上配置-ssh-互信和-sudo-规则)，使用 `tidb` 用户登陆至中控机，并将 `172.16.10.74` 添加至 `hosts.ini` 文件中的 `[servers]` 部分。 + 1. 参考[在中控机上配置 SSH 互信和 sudo 规则](/tools/dm/deployment.md#第-5-步-在中控机上配置-ssh-互信和-sudo-规则)，使用 `tidb` 用户登录至中控机，并将 `172.16.10.74` 添加至 `hosts.ini` 文件中的 `[servers]` 部分。 ``` $ cd /home/tidb/dm-ansible @@ -251,7 +253,7 @@ DM-master 重启时会自动向每个 DM-worker 实例请求任务信息，重 1. 为中控机设置 SSH 互信以及 sudo 规则。 - 1. 参考[在中控机上配置 SSH 互信和 sudo 规则](/tools/dm/deployment.md#第-5-步-在中控机上配置-ssh-互信和-sudo-规则)，使用 `tidb` 账户登陆至中控机，并将 `172.16.10.80` 添加至 `hosts.ini` 文件中的 `[servers]` 部分。 + 1. 参考[在中控机上配置 SSH 互信和 sudo 规则](/tools/dm/deployment.md#第-5-步-在中控机上配置-ssh-互信和-sudo-规则)，使用 `tidb` 账户登录至中控机，并将 `172.16.10.80` 添加至 `hosts.ini` 文件中的 `[servers]` 部分。 ``` $ cd /home/tidb/dm-ansible @@ -273,7 +275,9 @@ DM-master 重启时会自动向每个 DM-worker 实例请求任务信息，重 2. 关闭待替换的 DM-master 实例。 - > **注意**：如果机器 `172.16.10.71` 宕机，无法通过 SSH 登陆，请忽略此步。 + > **注意：** + > + > 如果机器 `172.16.10.71` 宕机，无法通过 SSH 登录，请忽略此步。 ``` $ ansible-playbook stop.yml --tags=dm-master @@ -311,7 +315,7 @@ DM-master 重启时会自动向每个 DM-worker 实例请求任务信息，重 1. 为中控机设置 SSH 互信以及 sudo 规则。 - 1. 参考[在中控机上配置 SSH 互信和 sudo 规则](/tools/dm/deployment.md#第-5-步-在中控机上配置-ssh-互信和-sudo-规则)，使用 `tidb` 账户登陆至中控机，并将 `172.16.10.75` 添加至 `hosts.ini` 文件中的 `[servers]` 部分。 + 1. 参考[在中控机上配置 SSH 互信和 sudo 规则](/tools/dm/deployment.md#第-5-步-在中控机上配置-ssh-互信和-sudo-规则)，使用 `tidb` 账户登录至中控机，并将 `172.16.10.75` 添加至 `hosts.ini` 文件中的 `[servers]` 部分。 ``` $ cd /home/tidb/dm-ansible $ vi hosts.ini @@ -332,7 +336,9 @@ DM-master 重启时会自动向每个 DM-worker 实例请求任务信息，重 2. 下线待替换 DM-worker 实例。 - > **注意**：如果机器 `172.16.10.71` 宕机，无法通过 SSH 登陆，请忽略此步。 + > **注意：** + > + > 如果机器 `172.16.10.71` 宕机，无法通过 SSH 登录，请忽略此步。 ``` $ ansible-playbook stop.yml --tags=dm-worker -l dm_worker1 diff --git a/tools/dm/data-synchronization-features.md b/tools/dm/data-synchronization-features.md index 38569bff8483..b25db7b2dc91 100644 --- a/tools/dm/data-synchronization-features.md +++ b/tools/dm/data-synchronization-features.md @@ -12,7 +12,7 @@ category: tools Table routing 提供将上游 MySQL/MariaDB 实例的某些表同步到下游指定表的功能。 -> **注意**： +> **注意：** > > - 不支持对同一个表设置多个不同的路由规则。 > - Schema 的匹配规则需要单独设置，用来同步 `create/drop schema xx`，例如下面[参数配置](#参数配置)中的 rule-2。 @@ -48,7 +48,7 @@ routes: - `rule-1` 用来同步匹配上 `schema-pattern: "test_*"` 和 `table-pattern: "t_*"` 的表的 DML/DDL 语句到下游的 `test`.`t`。 - `rule-2` 用来同步匹配上 `schema-pattern: "test_*"` 的库的 DDL 语句，例如 `create/drop schema xx`。 -> **注意**： +> **注意：** > > - 如果下游 TiDB `schema: test` 已经存在， 并且不会被删除，则可以省略 `rule-2`。 > - 如果下游 TiDB `schema: test` 不存在，只设置了 `rule_1`，则同步会报错 `schema test doesn't exist`。 @@ -155,7 +155,9 @@ black-white-list: 3. 如果 `do-tables` 和 `ignore-tables` 都为空，则同步 `test`.`t`。 -> **注意**：判断 schema `test` 是否被过滤，只进行 **schema 过滤判断** +> **注意：** +> +> 判断 schema `test` 是否被过滤，只进行 **schema 过滤判断** ### 使用示例 @@ -206,7 +208,9 @@ black-white-list: Binlog event filter 是比同步表黑白名单更加细粒度的过滤规则，可以指定只同步或者过滤掉某些 `schema / table` 的指定类型 binlog，比如 `INSERT`，`TRUNCATE TABLE`。 -> **注意**：同一个表匹配上多个规则，将会顺序应用这些规则，并且黑名单的优先级高于白名单，即如果同时存在规则 `Ignore` 和 `Do` 应用在某个 table 上，那么 `Ignore` 生效。 +> **注意：** +> +> 同一个表匹配上多个规则，将会顺序应用这些规则，并且黑名单的优先级高于白名单，即如果同时存在规则 `Ignore` 和 `Do` 应用在某个 table 上，那么 `Ignore` 生效。 ### 参数配置 @@ -288,7 +292,9 @@ filters: - `do-table-rule` 只同步所有匹配到 pattern `test_*`.`t_*` 的 table 的 `create table`、`insert`、`update`、`delete` 操作。 - `do-schema-rule` 只同步所有匹配到 pattern `test_*` 的 schema 的 `create database` 操作。 -> **注意**：同步 `create database/table` 的原因是创建库和表后才能同步 `DML`。 +> **注意：** +> +> 同步 `create database/table` 的原因是创建库和表后才能同步 `DML`。 ```yaml filters: @@ -320,7 +326,9 @@ filters: 对于 TiDB parser 不支持的 SQL 语句，DM 无法解析获得 `schema`/`table` 信息，因此需要使用全局过滤规则：`schema-pattern: "*"`。 -> **注意**：全局过滤规则的设置必须尽可能严格，以避免预期之外地过滤掉需要同步的数据。 +> **注意：** +> +> 全局过滤规则的设置必须尽可能严格，以避免预期之外地过滤掉需要同步的数据。 可设置如下规则过滤 TiDB parser 不支持的 `PARTITION` 语句： @@ -336,7 +344,7 @@ filters: Column mapping 提供对表的列值进行修改的功能。可以根据不同的表达式对表的指定列做不同的修改操作，目前只支持 DM 提供的内置表达式。 -> **注意**： +> **注意：** > > - 不支持修改 column 的类型和表结构。 > - 不支持对同一个表设置多个不同的列值转换规则。 @@ -436,7 +444,7 @@ column-mappings: DM 支持通过 heartbeat 真实同步数据来计算每个同步任务与 MySQL/MariaDB 的实时同步延迟。 -> **注意**： +> **注意：** > > - 同步延迟的估算的精度在秒级别。 > - heartbeat 相关的 binlog 不会同步到下游，在计算延迟后会被丢弃。 diff --git a/tools/dm/dm-upgrade.md b/tools/dm/dm-upgrade.md index 1fdf56be4d64..689587890e08 100644 --- a/tools/dm/dm-upgrade.md +++ b/tools/dm/dm-upgrade.md @@ -12,7 +12,7 @@ category: tools - 如果 Upgrade-A-B 与 Upgrade-B-C 之间存在交叠（如同一个配置项的不同变更），则推荐先执行 Upgrade-A-B 升级到 V-B，升级完成后再执行 Upgrade-B-C 升级到 V-C。 - 如果 Upgrade-A-B 与 Upgrade-B-C 之间不存在交叠，则可将 Upgrade-A-B 与 Upgrade-B-C 的操作合并为 Upgrade-A-C，执行后直接从 V-A 升级到 V-C。 -> **注意**： +> **注意：** > > - 若无特殊说明，各版本的升级操作均为从前一个有升级指引的版本向当前版本升级。 > - 若无特殊说明，各升级操作示例均假定已经下载了对应版本的 DM 和 DM-Ansible 且 DM binary 存在于 DM-Ansible 的相应目录中（下载 DM binary 可以参考[更新组件版本](/tools/dm/cluster-operations.md#更新组件版本)）。 @@ -97,7 +97,9 @@ Go Version: go version go1.11.2 linux/amd64 - `source_id`：存在于 `inventory.ini` 中，用于标识一个上游 MySQL 实例或一个主从复制组。 - `source-id`：存在于任务配置文件的 `mysql-instances` 中，其取值与 `inventory.ini` 中的 `source_id` 对应。 -> **注意**：如果需要确保已有任务存储在下游数据库的断点信息能继续被使用，`source_id`/`source-id` 的值需要与对应 DM-worker 变更前的 `instance-id` 一致。 +> **注意：** +> +> 如果需要确保已有任务存储在下游数据库的断点信息能继续被使用，`source_id`/`source-id` 的值需要与对应 DM-worker 变更前的 `instance-id` 一致。 ### 升级操作示例 diff --git a/tools/dm/dm-worker-intro.md b/tools/dm/dm-worker-intro.md index b660809f7ccd..6d6b8ff8a374 100644 --- a/tools/dm/dm-worker-intro.md +++ b/tools/dm/dm-worker-intro.md @@ -90,4 +90,6 @@ GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER,INDEX ON db.table TO 'your_ | Loader | 无 | `SELECT`（查询 checkpoint 历史）
`CREATE`（创建数据库或表）
`DELETE`（删除 checkpoint）
`INSERT`（插入 dump 数据）| 读/写本地文件 | | Binlog replication | `REPLICATION SLAVE`（读 binlog）
`REPLICATION CLIENT` (`show master status`, `show slave status`) | `SELECT`（显示索引和列）
`INSERT` (DML)
`UPDATE` (DML)
`DELETE` (DML)
`CREATE`（创建数据库或表）
`DROP`（删除数据库或表）
`ALTER`（修改表）
`INDEX`（创建或删除索引）| 本地读/写磁盘 | -> **注意**：这些权限并非一成不变。随着需求改变，这些权限也可能会改变。 +> **注意：** +> +> 这些权限并非一成不变。随着需求改变，这些权限也可能会改变。 diff --git a/tools/dm/manage-task.md b/tools/dm/manage-task.md index eb9c5a733886..cfa68da1dfaf 100644 --- a/tools/dm/manage-task.md +++ b/tools/dm/manage-task.md @@ -542,4 +542,6 @@ update-task [-w "127.0.0.1:10181"] ./task.yaml `refresh-worker-tasks` 命令用于强制刷新 DM-master 内存中维护的 `task => DM-workers` 映射关系。 -> **注意**：一般不需要使用此命令。仅当已确定 `task => DM-workers` 映射关系存在，但执行其它命令时仍提示必须刷新它时，你才需要使用此命令。 +> **注意：** +> +> 一般不需要使用此命令。仅当已确定 `task => DM-workers` 映射关系存在，但执行其它命令时仍提示必须刷新它时，你才需要使用此命令。 diff --git a/tools/dm/manually-handling-sharding-ddl-locks.md b/tools/dm/manually-handling-sharding-ddl-locks.md index 21e1d0aabfb6..f0ed567ebfb2 100644 --- a/tools/dm/manually-handling-sharding-ddl-locks.md +++ b/tools/dm/manually-handling-sharding-ddl-locks.md @@ -7,7 +7,7 @@ category: tools DM (Data Migration) 使用 sharding DDL lock 来确保分库分表的 DDL 操作可以正确执行。绝大多数情况下，该锁定机制可自动完成；但在部分异常情况发生时，需要使用 `unlock-ddl-lock`/`break-ddl-lock` 手动处理异常的 DDL lock。 -> **注意**： +> **注意：** > > - 不要轻易使用 `unlock-ddl-lock`/`break-ddl-lock` 命令，除非完全明确当前场景下使用这些命令可能会造成的影响，并能接受这些影响。 > - 在手动处理异常的 DDL lock 前，请确保已经了解 DM 的[分库分表合并同步原理](/tools/dm/shard-merge.md#实现原理)。 @@ -298,7 +298,9 @@ MySQL 及 DM 操作与处理流程如下： 2. 更新任务配置文件，将已下线 DM-worker 对应的信息从配置文件中移除。 3. 使用 `start-task` 及新任务配置文件重新启动任务。 -> **注意**：在 `unlock-ddl-lock` 之后，如果已下线的 DM-worker 重新上线并尝试对其中的分表进行数据同步，则会由于数据与下游的表结构不匹配而发生错误。 +> **注意：** +> +> 在 `unlock-ddl-lock` 之后，如果已下线的 DM-worker 重新上线并尝试对其中的分表进行数据同步，则会由于数据与下游的表结构不匹配而发生错误。 ### 场景二：unlock 过程中部分 DM-worker 重启 diff --git a/tools/dm/monitor.md b/tools/dm/monitor.md index 2937c6302289..bbfd91b75487 100644 --- a/tools/dm/monitor.md +++ b/tools/dm/monitor.md @@ -8,17 +8,36 @@ category: tools 使用 DM-Ansible 部署 DM 集群的时候，会默认部署一套[监控系统](/tools/dm/practice.md#第-7-步监控任务与查看日志)。 -> **注意**：目前只有 DM-worker 提供了 metrics，DM-master 暂未提供。 +> **注意：** +> +> 目前只有 DM-worker 提供了 metrics，DM-master 暂未提供。 ## Task +在 Grafana dashboard 中，DM 默认名称为 `DM-task`。 + +### overview + +overview 下包含运行当前选定 task 的所有 DM-worker instance 的部分监控指标。当前默认告警规则只针对于单个 DM-worker instance。 + +| metric 名称 | 说明 | 告警说明 | +|:----|:------------|:----| +| task state | 同步子任务的状态 | N/A | +| storage capacity | relay log 占有的磁盘的总容量 | N/A | +| storage remain | relay log 占有的磁盘的剩余可用容量 | N/A | +| binlog file gap between master and relay | relay 与上游 master 相比落后的 binlog file 个数 | N/A | +| load progress | loader 导入过程的进度百分比，值变化范围为：0% - 100% | N/A | +| binlog file gap between master and syncer | 与上游 master 相比 binlog replication 落后的 binlog file 个数 | N/A | +| shard lock resolving | 当前子任务是否正在等待 shard DDL 同步，大于 0 表示正在等待同步 | N/A | + + ### task 状态 | metric 名称 | 说明 | 告警说明 | |:----|:------------|:----| | task state | 同步子任务的状态 | 当子任务状态处于 paused 超过 10 分钟时| -## Relay log +### Relay log | metric 名称 | 说明 | 告警说明 | |:----|:------------|:----| @@ -26,16 +45,16 @@ category: tools | storage remain | relay log 占有的磁盘的剩余可用容量 | 小于 10G 的时候需要告警 | | process exits with error | relay log 在 DM-worker 内部遇到错误并且退出了 | 立即告警 | | relay log data corruption | relay log 文件损坏的个数 | 立即告警 | -| fail to read binlog from master | relay 从上游的 mysql 读取 binlog 时遇到的错误数 | 立即告警 | +| fail to read binlog from master | relay 从上游的 MySQL 读取 binlog 时遇到的错误数 | 立即告警 | | fail to write relay log | relay 写 binlog 到磁盘时遇到的错误数 | 立即告警 | | binlog file index | relay log 最大的文件序列号。如 value = 1 表示 relay-log.000001 | N/A | | binlog file gap between master and relay | relay 与上游 master 相比落后的 binlog file 个数 | 落后 binlog file 个数超过 1 个（不含 1 个）且持续 10 分钟时 | | binlog pos | relay log 最新文件的写入 offset | N/A | | read binlog duration | relay log 从上游的 MySQL 读取 binlog 的时延，单位：秒 | N/A | -| write relay log duration | relay log 每次写 binlog 到磁盘的时延，单位：秒。| N/A | +| write relay log duration | relay log 每次写 binlog 到磁盘的时延，单位：秒| N/A | | binlog size | relay log 写到磁盘的单条 binlog 的大小 | N/A | -## Dumper +### Dumper 下面 metrics 仅在 `task-mode` 为 `full` 或者 `all` 模式下会有值。 @@ -43,13 +62,13 @@ category: tools |:----|:------------|:----| | dump process exits with error | dumper 在 DM-worker 内部遇到错误并且退出了 | 立即告警 | -## Loader +### Loader 下面 metrics 仅在 `task-mode` 为 `full` 或者 `all` 模式下会有值。 | metric 名称 | 说明 | 告警说明 | |:----|:------------|:----| -| load progress | loader 导入过程的进度百分比，值变化范围为：0 %- 100 % | N/A | +| load progress | loader 导入过程的进度百分比，值变化范围为：0% - 100% | N/A | | data file size | loader 导入的全量数据中数据文件（内含 `INSERT INTO` 语句）的总大小 | N/A | | load process exits with error | loader 在 DM-worker 内部遇到错误并且退出了 | 立即告警 | | table count | loader 导入的全量数据中 table 的数量总和 | N/A | @@ -57,7 +76,7 @@ category: tools | latency of execute transaction | loader 在执行事务的时延，单位：秒 | N/A | | latency of query | loader 执行 query 的耗时，单位：秒 | N/A | -## Binlog replication +### Binlog replication 下面 metrics 仅在 `task-mode` 为 `incremental` 或者 `all` 模式下会有值。 @@ -66,7 +85,7 @@ category: tools | remaining time to sync | 预计 syncer 还需要多少分钟可以和 master 完全同步，单位：分钟 | N/A | | replicate lag | master 到 syncer 的 binlog 复制延迟时间，单位：秒 | N/A | | process exist with error | binlog replication 在 DM-worker 内部遇到错误并且退出了 | 立即告警 | -| binlog file gap between master and syncer | 与上游 master 相比落后的 binlog file 个数。| 落后 binlog file 个数超过 1 个（不含 1 个）且持续 10 分钟时 | +| binlog file gap between master and syncer | 与上游 master 相比落后的 binlog file 个数 | 落后 binlog file 个数超过 1 个（不含 1 个）且持续 10 分钟时 | | binlog file gap between relay and syncer | 与 relay 相比落后的 binlog file 个数 | 落后 binlog file 个数超过 1 个（不含 1 个）且持续 10 分钟时 | | binlog event qps | 单位时间内接收到的 binlog event 数量 (不包含需要跳过的 event) | N/A | | skipped binlog event qps | 单位时间内接收到的需要跳过的 binlog event 数量 | N/A | @@ -76,3 +95,34 @@ category: tools | execution latency | syncer 执行 transaction 到下游的耗时，单位：秒 | N/A | | unsynced tables | 当前子任务内还未收到 shard DDL 的分表数量 | N/A | | shard lock resolving | 当前子任务是否正在等待 shard DDL 同步，大于 0 表示正在等待同步 | N/A | + + +## Instance + +在 Grafana dashboard 中，instance 的默认名称为 `DM-instance`。 + +### Relay log + +| metric 名称 | 说明 | 告警说明 | +|:----|:------------|:----| +| storage capacity | relay log 占有的磁盘的总容量 | N/A | +| storage remain | relay log 占有的磁盘的剩余可用容量 | 小于 10G 的时候需要告警 | +| process exits with error | relay log 在 DM-worker 内部遇到错误并且退出了 | 立即告警 | +| relay log data corruption | relay log 文件损坏的个数 | 立即告警 | +| fail to read binlog from master | relay 从上游的 MySQL 读取 binlog 时遇到的错误数 | 立即告警 | +| fail to write relay log | relay 写 binlog 到磁盘时遇到的错误数 | 立即告警 | +| binlog file index | relay log 最大的文件序列号。如 value = 1 表示 relay-log.000001 | N/A | +| binlog file gap between master and relay | relay 与上游 master 相比落后的 binlog file 个数 | 落后 binlog file 个数超过 1 个（不含 1 个）且持续 10 分钟时 | +| binlog pos | relay log 最新文件的写入 offset | N/A | +| read binlog duration | relay log 从上游的 MySQL 读取 binlog 的时延，单位：秒 | N/A | +| write relay log duration | relay log 每次写 binlog 到磁盘的时延，单位：秒 | N/A | +| binlog size | relay log 写到磁盘的单条 binlog 的大小 | N/A | + +### task + +| metric 名称 | 说明 | 告警说明 | +|:----|:------------|:----| +| task state | 同步子任务的状态 | 当子任务状态处于 paused 超过 10 分钟时 | +| load progress | loader 导入过程的进度百分比，值变化范围为：0% - 100% | N/A | +| binlog file gap between master and syncer | 与上游 master 相比 binlog replication 落后的 binlog file 个数 | N/A | +| shard lock resolving | 当前子任务是否正在等待 shard DDL 同步，大于 0 表示正在等待同步 | N/A | diff --git a/tools/dm/overview.md b/tools/dm/overview.md index db5246d97eaf..a15480496858 100644 --- a/tools/dm/overview.md +++ b/tools/dm/overview.md @@ -75,6 +75,12 @@ DM 支持对原分库分表进行合库合表操作，但需要满足一些[使 - 5.5 < MySQL 版本 < 5.8 - MariaDB 版本 >= 10.1.2 + + > **注意：** + > + > 如果上游 MySQL/MariaDB server 间构成主从复制结构，则 + > - 5.7.1 < MySQL 版本 < 5.8 + > - MariaDB 版本 >= 10.1.3 在使用 dmctl 启动任务时，DM 会自动对任务上下游数据库的配置、权限等进行[前置检查](/tools/dm/precheck.md)。 diff --git a/tools/dm/practice.md b/tools/dm/practice.md index fd4b4e07540c..07984d3f73df 100644 --- a/tools/dm/practice.md +++ b/tools/dm/practice.md @@ -11,7 +11,7 @@ category: tools 目前推荐使用 DM-Ansible 部署 DM 集群，具体部署方法参照 [使用 DM-Ansible 部署 DM 集群](/tools/dm/deployment.md)。 -> **注意**： +> **注意：** > > - 在 DM 所有的配置文件中，数据库的密码要使用 dmctl 加密后的密文。如果数据库密码为空，则不需要加密。关于如何使用 dmctl 加密明文密码，参考[使用 dmctl 加密上游 MySQL 用户密码](/tools/dm/deployment.md#使用-dmctl-加密上游-mysql-用户密码)。 > - 上下游数据库用户必须拥有相应的读写权限。 @@ -50,7 +50,9 @@ category: tools dm-worker = "172.16.10.73:8262" ``` - > **注意**：`{ansible deploy}/conf/dm-master.toml` 中的 `{ansible deploy}` 表示使用 DM-Ansible 部署 DM 时通过 `deploy_dir` 参数指定的目录。 + > **注意：** + > + > `{ansible deploy}/conf/dm-master.toml` 中的 `{ansible deploy}` 表示使用 DM-Ansible 部署 DM 时通过 `deploy_dir` 参数指定的目录。 ## 第 3 步：配置任务 @@ -106,7 +108,9 @@ mydumpers: - 启动数据同步任务时，DM 自动检查相应的权限和配置。 - 也可使用 `check-task` 命令手动前置检查上游的 MySQL 实例配置是否符合 DM 的配置要求。 -> **注意**：第一次启动数据同步任务时，必须确保上游数据库已配置。否则，启动任务时会报错。 +> **注意：** +> +> 第一次启动数据同步任务时，必须确保上游数据库已配置。否则，启动任务时会报错。 1. 进入 dmctl 目录 `/home/tidb/dm-ansible/resources/bin/`。 diff --git a/tools/dm/relay-log.md b/tools/dm/relay-log.md index 688f4648dd04..eb9e9780d2bc 100644 --- a/tools/dm/relay-log.md +++ b/tools/dm/relay-log.md @@ -67,7 +67,9 @@ DM-worker 每次启动时（或在 DM-worker 暂停后 relay log 恢复同步） - 在 GTID 模式下，DM-worker 从初始上游 GTID 开始同步。 - > **注意**：若上游的 relay log 被清理掉，则会发生错误。在这种情况下，需设置 `relay-binlog-gtid` 来指定同步的起始位置。 + > **注意：** + > + > 若上游的 relay log 被清理掉，则会发生错误。在这种情况下，需设置 `relay-binlog-gtid` 来指定同步的起始位置。 - 若不存在有效的本地 relay log： diff --git a/tools/dm/shard-merge-scenario.md b/tools/dm/shard-merge-scenario.md index 84063991bb27..0d80feed966d 100644 --- a/tools/dm/shard-merge-scenario.md +++ b/tools/dm/shard-merge-scenario.md @@ -93,7 +93,9 @@ category: tools action: Ignore ``` - > **注意**：同步需求 #4、#5 和 #7 的操作意味着过滤掉所有对 `user` 库的删除操作，所以此处配置了库级别的过滤规则。但是 `user` 库以后加入表的删除操作也都会被过滤。 + > **注意：** + > + > 同步需求 #4、#5 和 #7 的操作意味着过滤掉所有对 `user` 库的删除操作，所以此处配置了库级别的过滤规则。但是 `user` 库以后加入表的删除操作也都会被过滤。 - 要满足同步需求 #6，配置 [Binlog event filter 规则](/tools/dm/data-synchronization-features.md#binlog-event-filter) 如下： diff --git a/tools/dm/shard-merge.md b/tools/dm/shard-merge.md index 2056e1dac22d..be558120a865 100644 --- a/tools/dm/shard-merge.md +++ b/tools/dm/shard-merge.md @@ -7,7 +7,9 @@ category: tools 本文介绍了 DM 提供的分库分表合并同步功能。此功能用于将上游 MySQL/MariaDB 实例中结构相同的表同步到下游 TiDB 的同一个表中。DM 不仅支持同步上游的 DML 数据，也支持协调同步多个上游分表的 DDL 表结构变更。 -> **注意**：要执行分库分表合并同步任务，必须在任务配置文件中设置 `is-sharding: true`。 +> **注意：** +> +> 要执行分库分表合并同步任务，必须在任务配置文件中设置 `is-sharding: true`。 ### 使用限制 diff --git a/tools/dm/simple-synchronization-scenario.md b/tools/dm/simple-synchronization-scenario.md index 2db4242fe51a..7a48ba7f1901 100644 --- a/tools/dm/simple-synchronization-scenario.md +++ b/tools/dm/simple-synchronization-scenario.md @@ -128,7 +128,9 @@ category: tools action: Ignore ``` - > **注意**：`store-filter-rule` 不同于 `log-filter-rule` 和 `user-filter-rule`。`store-filter-rule` 是针对整个 `store` 库的规则，而 `log-filter-rule` 和 `user-filter-rule` 是针对 `user` 库中 `log` 表的规则。 + > **注意：** + > + > `store-filter-rule` 不同于 `log-filter-rule` 和 `user-filter-rule`。`store-filter-rule` 是针对整个 `store` 库的规则，而 `log-filter-rule` 和 `user-filter-rule` 是针对 `user` 库中 `log` 表的规则。 - 为了满足[同步要求](#同步要求)中的第三点要求，需要配置以下 [black & white table lists 规则](/tools/dm/data-synchronization-features.md#black--white-table-lists)： diff --git a/tools/dm/skip-replace-sqls.md b/tools/dm/skip-replace-sqls.md index c39d00fa02d0..91d095c50c23 100644 --- a/tools/dm/skip-replace-sqls.md +++ b/tools/dm/skip-replace-sqls.md @@ -54,7 +54,8 @@ category: tools 对于合库合表场景，如果需要由 DM 自动选择 DDL lock owner 来执行跳过/替代执行操作，则由于不同 DM-worker 上 DDL 语句对应的 binlog position 无逻辑关联且难以确定，因此只能使用 DDL pattern 匹配模式。 -> **注意**： +> **注意：** +> > - 一个 binlog event 只能注册一个使用 `--binlog-pos` 指定的 operator，后注册的 operator 会覆盖之前已经注册的 operator。 > - 不要尝试为一个 binlog event 同时使用 `--binlog-pos` 和 `--sql-pattern` 指定 operator。 > - operator 在与 binlog event 匹配成功后（而非执行成功后）即会被删除，后续如果需要再进行（`--sql-pattern`）匹配则必须重新注册。 diff --git a/tools/dm/troubleshooting.md b/tools/dm/troubleshooting.md index ddd00819b147..3a94c452c0b7 100644 --- a/tools/dm/troubleshooting.md +++ b/tools/dm/troubleshooting.md @@ -35,7 +35,9 @@ category: tools 你需要使用 dmctl 手动处理 TiDB 不兼容的 DDL 语句（包括手动跳过该 DDL 语句或使用用户指定的 DDL 语句替换原 DDL 语句，详见[跳过 (skip) 或替代执行 (replace) 异常的 SQL 语句](/tools/dm/skip-replace-sqls.md)）。 -> **注意：** TiDB 目前并不兼容 MySQL 支持的所有 DDL 语句，详见 [TiDB 已支持的 DDL 语句](/sql/ddl.md)。 +> **注意：** +> +> TiDB 目前并不兼容 MySQL 支持的所有 DDL 语句，详见 [TiDB 已支持的 DDL 语句](/sql/ddl.md)。 ## 重置数据同步任务 diff --git a/tools/lightning/checkpoints.md b/tools/lightning/checkpoints.md index 7f003e40263e..070f42353113 100644 --- a/tools/lightning/checkpoints.md +++ b/tools/lightning/checkpoints.md @@ -86,7 +86,9 @@ tidb-lightning-ctl --checkpoint-error-ignore=all 如果导入 `` `schema`.`table` `` 这个表曾经出错，这条命令会清除出错状态，如同没事发生过一样。传入 "all" 会对所有表进行上述操作。 -> **注意**：除非确定错误可以忽略，否则不要使用这个选项。如果错误是真实的话，可能会导致数据不完全。启用校验和 (CHECKSUM) 可以防止数据出错被忽略。 +> **注意：** +> +> 除非确定错误可以忽略，否则不要使用这个选项。如果错误是真实的话，可能会导致数据不完全。启用校验和 (CHECKSUM) 可以防止数据出错被忽略。 ### `--checkpoint-remove` diff --git a/tools/lightning/deployment.md b/tools/lightning/deployment.md index 4897b33066cf..02fad5a06390 100644 --- a/tools/lightning/deployment.md +++ b/tools/lightning/deployment.md @@ -42,7 +42,9 @@ category: tools 如果机器充裕的话，可以部署多套 `tidb-lightning` + `tikv-importer`，然后将源数据以表为粒度进行切分，并发导入。 -> **注意**：`tidb-lightning` 是 CPU 密集型程序，如果和其它程序混合部署，需要通过 `region-concurrency` 限制 `tidb-lightning` 的 CPU 实际占用核数，否则会影响其他程序的正常运行。建议将混合部署机器上 75% 的 CPU 分配给 `tidb-lightning`。例如，机器为 32 核，则 `tidb-lightning` 的 `region-concurrency` 可设为 24。 +> **注意：** +> +> `tidb-lightning` 是 CPU 密集型程序，如果和其它程序混合部署，需要通过 `region-concurrency` 限制 `tidb-lightning` 的 CPU 实际占用核数，否则会影响其他程序的正常运行。建议将混合部署机器上 75% 的 CPU 分配给 `tidb-lightning`。例如，机器为 32 核，则 `tidb-lightning` 的 `region-concurrency` 可设为 24。 此外，目标 TiKV 集群必须有足够空间接收新导入的数据。除了[标准硬件配置](../../op-guide/recommendation.md)以外，目标 TiKV 集群的总存储空间必须大于 **数据源大小 × [副本数量](../../FAQ.md#3-2-6-%E6%AF%8F%E4%B8%AA-region-%E7%9A%84-replica-%E6%95%B0%E9%87%8F%E5%8F%AF%E9%85%8D%E7%BD%AE%E5%90%97-%E8%B0%83%E6%95%B4%E7%9A%84%E6%96%B9%E6%B3%95%E6%98%AF) × 2**。例如集群默认使用 3 副本，那么总存储空间需为数据源大小的 6 倍以上。 @@ -62,7 +64,7 @@ category: tools - `-F 256`：将每张表切分成多个文件，每个文件大小约为 256 MB。 - `--skip-tz-utc`：添加这个参数则会忽略掉 TiDB 与导数据的机器之间时区设置不一致的情况，禁止自动转换。 -如果数据源是 CSV 文件，请参考 [CSV 支持](../../tools/lightning/csv.md]获取配置信息。 +如果数据源是 CSV 文件，请参考 [CSV 支持](/tools/lightning/csv.md)获取配置信息。 ## 部署 TiDB-Lightning @@ -153,7 +155,7 @@ TiDB-Lightning 可随 TiDB 集群一起用 [Ansible 部署](../../op-guide/ansib 通过以下链接获取 TiDB-Lightning 安装包（需选择与集群相同的版本）： -- **v2.1.6**: https://download.pingcap.org/tidb-lightning-v2.1.6-linux-amd64.tar.gz +- **v2.1.6**: https://download.pingcap.org/tidb-v2.1.6-linux-amd64.tar.gz - **v2.0.9**: https://download.pingcap.org/tidb-lightning-v2.0.9-linux-amd64.tar.gz - 最新 unstable 版本：https://download.pingcap.org/tidb-lightning-test-xx-latest-linux-amd64.tar.gz diff --git a/tools/lightning/filter.md b/tools/lightning/filter.md index 6f1cf8099def..a6def7e62220 100644 --- a/tools/lightning/filter.md +++ b/tools/lightning/filter.md @@ -56,7 +56,9 @@ tbl-name = "table-pattern-5" * 否则，如果表的限定名称匹配 `ignore-tables` 列表中**任何**一对，表会被略过。 * 如果表的限定名称**同时**匹配 `do-tables` 和 `ignore-tables` 列表，表会被导入。 -注意，Lightning 会先执行数据库过滤规则，之后才执行表的过滤规则。所以，如果一个数据库已被 `ignore-dbs` 略过，即使其下的表匹配 `do-tables` 也不会再被导入。 +> **注意：** +> +> Lightning 会先执行数据库过滤规则，之后才执行表的过滤规则。所以，如果一个数据库已被 `ignore-dbs` 略过，即使其下的表匹配 `do-tables` 也不会再被导入。 ## 例子 diff --git a/tools/lightning/overview-architecture.md b/tools/lightning/overview-architecture.md index 36100e7036a4..0390848053df 100644 --- a/tools/lightning/overview-architecture.md +++ b/tools/lightning/overview-architecture.md @@ -17,7 +17,7 @@ TiDB-Lightning 主要包含两个部分: - **`tidb-lightning`**（“前端”）：主要完成适配工作，通过读取数据源，在下游 TiDB 集群建表、将数据转换成键/值对 (KV 对) 发送到 `tikv-importer`、检查数据完整性等。 - **`tikv-importer`**（“后端”）：主要完成将数据导入 TiKV 集群的工作，把 `tidb-lightning` 写入的 KV 对缓存、排序、切分并导入到 TiKV 集群。 -![TiDB-Lightning 其整体架构](../../media/tidb-lightning.svg) +![TiDB-Lightning 其整体架构](/media/tidb-lightning-architecture.png) TiDB-Lightning 整体工作原理如下： diff --git a/tools/loader.md b/tools/loader.md index f94497f9b7c7..3455a096bd5b 100644 --- a/tools/loader.md +++ b/tools/loader.md @@ -56,8 +56,8 @@ Loader 包含在 tidb-enterprise-tools 安装包中，可[在此下载](../tools TiDB 服务 host IP (default "127.0.0.1") -p string TiDB 账户密码 - -pprof-addr string - Loader 的 pprof 地址，用于对 Loader 进行性能调试 (默认为 ":10084") + -status-addr string + Prometheus 可以通过该地址拉取 Loader metrics, 也是 Loader 的 pprof 调试地址 (默认为 ":8272")。 -t int 线程数 (默认为 16). 每个线程同一时刻只能操作一个数据文件。 -u string @@ -78,8 +78,8 @@ log-file = "loader.log" # 需要导入的数据存放路径 (default "./") dir = "./" -# Loader 的 pprof 地址，用于对 Loader 进行性能调试 (默认为 ":10084") -pprof-addr = "127.0.0.1:10084" +## Prometheus 可以通过该地址拉取 Loader metrics, 也是 Loader 的 pprof 调试地址 (默认为 ":8272")。 +status-addr = ":8272" # checkpoint 数据库名，loader 在运行过程中会不断的更新这个数据库，在中断并恢复后， # 会通过这个库获取上次运行的进度 (默认为 "tidb_loader") @@ -138,4 +138,4 @@ pattern-schema = "example_db" pattern-table = "table_*" target-schema = "example_db" target-table = "table" -``` \ No newline at end of file +``` diff --git a/tools/syncer.md b/tools/syncer.md index e3edbcced9e1..2c7a2fd2f712 100644 --- a/tools/syncer.md +++ b/tools/syncer.md @@ -34,7 +34,7 @@ binlog-pos = 930143241 binlog-gtid = "2bfabd22-fff7-11e6-97f7-f02fa73bcb01:1-23,61ccbb5d-c82d-11e6-ac2e-487b6bd31bf7:1-4" ``` -> **注：** +> **注意：** > > - `syncer.meta` 只需要第一次使用的时候配置，后续 Syncer 同步新的 binlog 之后会自动将其更新到最新的 position。 > - 如果使用 binlog position 同步则只需要配置 binlog-name binlog-pos; 使用 gtid 同步则需要设置 gtid，且启动 Syncer 时带有 `--enable-gtid`。 @@ -52,7 +52,7 @@ Usage of syncer: -auto-fix-gtid 当 mysql master/slave 切换时，自动修复 gtid 信息；默认 false -b int - batch 事务大小 (默认 10) + batch 事务大小 (默认 100) -c int syncer 处理 batch 线程数 (默认 16) -config string @@ -95,10 +95,10 @@ server-id = 101 ## meta 文件地址 meta = "./syncer.meta" worker-count = 16 -batch = 1000 +batch = 100 flavor = "mysql" -## pprof 调试地址，Prometheus 也可以通过该地址拉取 Syncer metrics +## Prometheus 可以通过该地址拉取 Syncer metrics，也是 Syncer 的 pprof 调试地址 status-addr = ":8271" ## 如果设置为 true，Syncer 遇到 DDL 语句时就会停止退出 @@ -352,6 +352,12 @@ target-table = "order_2017" - 5.5 < MySQL 版本 < 5.8 - MariaDB 版本 >= 10.1.2（更早版本的 binlog 部分字段类型格式与 MySQL 不一致） + + > **注意：** + > + > 如果上游 MySQL/MariaDB server 间构成主从复制结构，则 + > - 5.7.1 < MySQL 版本 < 5.8 + > - MariaDB 版本 >= 10.1.3 2. 检查源库 `server-id`。 @@ -480,6 +486,10 @@ target-table = "order_2017" +---------------+-----------------------------------------------------------------------------------+ 1 row in set (0.01 sec) ``` +6. 检查字符集。 + + TiDB 和 MySQL 的字符集的兼容性不同，详见 [TiDB 支持的字符集](/sql/character-set-support.md)。 + ## 监控方案 diff --git a/tools/tikv-control.md b/tools/tikv-control.md index c47fd62d3b5d..bcc2853e9930 100644 --- a/tools/tikv-control.md +++ b/tools/tikv-control.md @@ -33,7 +33,9 @@ $ tikv-ctl --to-hex "\252\377" AAFF ``` -> **注意**：在命令行上指定 `escaped` 形式的 key 时，需要用双引号引起来，否则 bash 会将反斜杠吃掉，导致结果错误。 +> **注意：** +> +> 在命令行上指定 `escaped` 形式的 key 时，需要用双引号引起来，否则 bash 会将反斜杠吃掉，导致结果错误。 ## 各项子命令及部分参数、选项 @@ -92,7 +94,9 @@ key: zmDB:29\000\000\377\000\374\000\000\000\000\000\000\377\000H\000\000\000\00 write cf value: start_ts: 399650105199951882 commit_ts: 399650105213059076 short_value: "\000\000\000\000\000\000\000\001" ``` -> **注意**：该命令中，key 同样需要是 escaped 形式的 raw key。 +> **注意：** +> +> 该命令中，key 同样需要是 escaped 形式的 raw key。 ### 打印某个 key 的值 @@ -141,8 +145,8 @@ $ tikv-ctl --db /path/to/tikv/db tombstone -p 127.0.0.1:2379 -r 2 success! ``` -> **注意**： -> +> **注意：** +> > - `-p` 选项的参数指定 PD 的 endpoints，它没有 `http` 前缀。 > - **这个命令只支持本地模式**。需要指定 PD 的 endpoints 的原因是需要询问 PD 是否可以安全地 tombstone。因此，在 tombstone 之前往往还需要在 `pd-ctl` 中把该 Region 在这台机器上的对应 Peer 拿掉。 @@ -157,7 +161,9 @@ $ tikv-ctl --host 127.0.0.1:21061 consistency-check -r 2 DebugClient::check_region_consistency: RpcFailure(RpcStatus { status: Unknown, details: Some("StringError(\"Leader is on store 1\")") }) ``` -需要注意的是，即使这个命令返回了成功，也需要去检查是否有 TiKV panic 了，因为这个命令只是给 Leader 发起一个 Consistency-check 的 propose，至于整个检查流程成功与否并不能在客户端知道。 +> **注意：** +> +> 即使这个命令返回了成功，也需要去检查是否有 TiKV panic 了，因为这个命令只是给 Leader 发起一个 Consistency-check 的 propose，至于整个检查流程成功与否并不能在客户端知道。 ### Dump snapshot meta @@ -220,8 +226,8 @@ $ tikv-ctl --db /path/to/tikv/db unsafe-recover remove-fail-stores -s 4,5 --all- 之后启动 TiKV，这些 Region 便可以以剩下的健康的副本继续提供服务了。这个命令常用于多个 TiKV store 损坏或被删除的情况。 -> **注意**： -> +> **注意：** +> > - **这个命令只支持本地模式**。在运行成功后，会打印 `success!`。 > - 一般来说，需要使用这个命令的地方，对于指定 Region 的 peers 所在的每个 store，均须运行这个命令。 > - 如果使用 `--all-regions`，通常需要在集群剩余所有健康的 store 上执行这个命令。 @@ -237,8 +243,8 @@ $ tikv-ctl --db /path/to/tikv/db recover-mvcc -r 1001,1002 -p 127.0.0.1:2379 success! ``` -> **注意**： -> +> **注意：** +> > - **这个命令只支持本地模式**。在运行成功后，会打印 `success!`。 > - `-p` 选项指定 PD 的 endpoint，不使用 `http` 前缀，用于查询指定的 `region_id` 是否有效。 > - 对于指定 Region 的 peers 所在的每个 store，均须执行这个命令。 diff --git a/trouble-shooting.md b/trouble-shooting.md index eead39fd100a..51ce1cb7b6d8 100644 --- a/trouble-shooting.md +++ b/trouble-shooting.md @@ -5,11 +5,11 @@ category: advanced # TiDB 集群故障诊断 -当试用 TiDB 遇到问题时，请先参考本篇文档。如果问题未解决，请按文档要求收集必要的信息通过 Github [提供给 TiDB 开发者](https://github.com/pingcap/tidb/issues/new)。 +当试用 TiDB 遇到问题时，请先参考本篇文档。如果问题未解决，请按文档要求收集必要的信息通过 Github [提供给 TiDB 开发者](https://github.com/pingcap/tidb/issues/new/choose)。 ## 如何给 TiDB 开发者报告错误 -当使用 TiDB 遇到问题并且通过后面所列信息无法解决时，请收集以下信息并[创建新 Issue](https://github.com/pingcap/tidb/issues/new): +当使用 TiDB 遇到问题并且通过后面所列信息无法解决时，请收集以下信息并[创建新 Issue](https://github.com/pingcap/tidb/issues/new/choose): + 具体的出错信息以及正在执行的操作 + 当前所有组件的状态 @@ -30,7 +30,7 @@ category: advanced + panic - 程序有错误，请将具体的 panic log [提供给 TiDB 开发者](https://github.com/pingcap/tidb/issues/new)。 + 程序有错误，请将具体的 panic log [提供给 TiDB 开发者](https://github.com/pingcap/tidb/issues/new/choose)。 如果是清空数据并重新部署服务，请确认以下信息： @@ -145,4 +145,4 @@ tidb-server 无法启动的常见情况包括： + pd-server 和 tikv-server 是否分开部署 + 目前正在进行什么操作 + 用 `top -H` 命令查看当前占用 CPU 的线程名 -+ 最近一段时间的网络/IO 监控数据是否有异常 \ No newline at end of file ++ 最近一段时间的网络/IO 监控数据是否有异常 diff --git a/v1.0/FAQ.md b/v1.0/FAQ.md index a9ae19a668a7..e9036cde78ea 100755 --- a/v1.0/FAQ.md +++ b/v1.0/FAQ.md @@ -240,9 +240,9 @@ Binary 不是我们建议的安装方式，对升级支持也不友好，建议 | 滚动升级除 PD 外模块 | ansible-playbook rolling\_update.yml --skip-tags=pd | | 滚动升级监控组件 | ansible-playbook rolling\_update\_monitor.yml | -### 3.1.2 TiDB 如何登陆？ +### 3.1.2 TiDB 如何登录？ -和 MySQL 登陆方式一样，可以按照下面例子进行登陆。 +和 MySQL 登录方式一样，可以按照下面例子进行登录。 `mysql -h 127.0.0.1 -uroot -P4000` @@ -518,9 +518,9 @@ loader的 -t 参数可以根据 TiKV 的实例个数以及负载进行评估调 TiDB 支持绝大多数 MySQL 语法，一般不需要修改代码。我们提供了一个[检查工具](https://github.com/pingcap/tidb-tools/tree/master/checker)，用于检查 MySQL 中的 Schema 是否和 TiDB 兼容。 -### 4.1.4 不小心把 MySQL 的 user 表导入到 TiDB 了，或者忘记密码，无法登陆，如何处理？ +### 4.1.4 不小心把 MySQL 的 user 表导入到 TiDB 了，或者忘记密码，无法登录，如何处理？ -重启 TiDB 服务，配置文件中增加 `-skip-grant-table=true` 参数，无密码登陆集群后，可以根据情况重建用户，或者重建 mysql.user 表，具体表结构搜索官网。 +重启 TiDB 服务，配置文件中增加 `-skip-grant-table=true` 参数，无密码登录集群后，可以根据情况重建用户，或者重建 mysql.user 表，具体表结构搜索官网。 ### 4.1.5 如何导出 TiDB 数据？ diff --git a/v1.0/benchmark/sysbench.md b/v1.0/benchmark/sysbench.md index 5873b10bc22d..d116a4e79905 100755 --- a/v1.0/benchmark/sysbench.md +++ b/v1.0/benchmark/sysbench.md @@ -9,7 +9,9 @@ draft: true ## 测试目的 测试 TiDB 在 OLTP 场景下的性能以及水平扩展能力。 -> **注意**: 不同的测试环境可能使测试结果发生改变。 +> **注意：** +> +> 不同的测试环境可能使测试结果发生改变。 ## 测试版本、时间、地点 diff --git a/v1.0/op-guide/ansible-deployment.md b/v1.0/op-guide/ansible-deployment.md index 58dc819f156f..92e286617b2f 100755 --- a/v1.0/op-guide/ansible-deployment.md +++ b/v1.0/op-guide/ansible-deployment.md @@ -28,7 +28,9 @@ Ansible 是一款自动化运维工具，[TiDB-Ansible](https://github.com/pingc - 机器的时间、时区设置一致，开启 NTP 服务且在正常同步时间，可参考[如何检测 NTP 服务是否正常](#如何检测-ntp-服务是否正常)。 - 创建 `tidb` 普通用户作为程序运行用户，tidb 用户可以免密码 sudo 到 root 用户，可参考[如何配置 ssh 互信及 sudo 免密码](#如何配置-ssh-互信及-sudo-免密码)。 - > **注：使用 Ansible 方式部署时，TiKV 及 PD 节点数据目录所在磁盘请使用 SSD 磁盘，否则无法通过检测。** 如果仅验证功能，建议使用 [Docker Compose 部署方案](docker-compose.md)单机进行测试。 + > **注意：** + > + > 使用 Ansible 方式部署时，TiKV 及 PD 节点数据目录所在磁盘请使用 SSD 磁盘，否则无法通过检测。** 如果仅验证功能，建议使用 [Docker Compose 部署方案](docker-compose.md)单机进行测试。 2. 部署中控机一台: @@ -68,7 +70,9 @@ cd /home/tidb git clone https://github.com/pingcap/tidb-ansible.git ``` -> **注：** 生产环境请下载 GA 版本部署 TiDB。 +> **注意：** +> +> 生产环境请下载 GA 版本部署 TiDB。 ## 分配机器资源，编辑 inventory.ini 文件 @@ -424,7 +428,9 @@ synchronised to NTP server (85.199.214.101) at stratum 2 time correct to within 91 ms polling server every 1024 s ``` -> **注：**Ubuntu 系统请安装 ntpstat 软件包。 +> **注意：** +> +> Ubuntu 系统请安装 ntpstat 软件包。 以下情况表示 NTP 服务未正常同步： diff --git a/v1.0/op-guide/backup-restore.md b/v1.0/op-guide/backup-restore.md index 49f87122b4f5..b8e073a200e2 100755 --- a/v1.0/op-guide/backup-restore.md +++ b/v1.0/op-guide/backup-restore.md @@ -44,7 +44,9 @@ cd tidb-enterprise-tools-latest-linux-amd64 我们使用 `mydumper` 从 TiDB 导出数据进行备份，然后用 `loader` 将其导入到 TiDB 里面进行恢复。 -> 注意：虽然 TiDB 也支持使用 MySQL 官方的 `mysqldump` 工具来进行数据的备份恢复工作，但相比于 `mydumper` / `loader`，性能会慢很多，大量数据的备份恢复会花费很多时间，这里我们并不推荐。 +> **注意：** +> +> 虽然 TiDB 也支持使用 MySQL 官方的 `mysqldump` 工具来进行数据的备份恢复工作，但相比于 `mydumper`/`loader`，性能会慢很多，大量数据的备份恢复会花费很多时间，这里我们并不推荐。 ### `mydumper`/`loader` 全量备份恢复最佳实践 为了快速的备份恢复数据 (特别是数据量巨大的库), 可以参考下面建议 diff --git a/v1.0/op-guide/monitor.md b/v1.0/op-guide/monitor.md index 172d9b4c93bf..98169f358f22 100755 --- a/v1.0/op-guide/monitor.md +++ b/v1.0/op-guide/monitor.md @@ -30,7 +30,7 @@ curl http://127.0.0.1:10080/status ### PD Server PD API 地址： ``http://${host}:${port}/pd/api/v1/${api_name}``。 -其中 port 默认为 2379，各类 api_name 详细信息参见 [PD API Doc](https://cdn.rawgit.com/pingcap/docs/master/op-guide/pd-api-v1.html)。 +其中 port 默认为 2379，各类 api_name 详细信息参见 [PD API Doc](https://download.pingcap.com/pd-api-v1.html)。 通过这个接口可以获取当前所有 TiKV 的状态以及负载均衡信息。其中最重要也是最常用的接口获取 TiKV 集群所有节点状态的接口，下面以一个单个 TiKV 构成的集群为例，说明一些用户需要了解的信息： diff --git a/v1.0/sql/dml.md b/v1.0/sql/dml.md index 15ec467ae69c..701bde99fd5c 100755 --- a/v1.0/sql/dml.md +++ b/v1.0/sql/dml.md @@ -46,7 +46,7 @@ SELECT |`HAVING where_condition` | Having 子句与 Where 子句作用类似，Having 子句可以让过滤 GroupBy 后的各种数据，Where 子句用于在聚合前过滤记录。| |`ORDER BY` | OrderBy 子句用于指定结果排序顺序，可以按照列、表达式或者是 `select_expr` 列表中某个位置的字段进行排序。| |`LIMIT` | Limit 子句用于限制结果条数。Limit 接受一个或两个数字参数，如果只有一个参数，那么表示返回数据的最大行数；如果是两个参数，那么第一个参数表示返回数据的第一行的偏移量（第一行数据的偏移量是 0），第二个参数指定返回数据的最大条目数。| -|`FOR UPDATE` | 对查询结果集所有数据上读锁，以监测其他事务对这些的并发修改。TiDB 使用[乐观事务模型](mysql-compatibility.md#事务)在语句执行期间不会检测锁冲突，在事务的提交阶段才会检测事务冲突，如果执行 Select For Update 期间，有其他事务修改相关的数据，那么包含 Select For Update 语句的事务会提交失败。| +|`FOR UPDATE` | 对查询结果集所有数据上读锁（对于在查询条件内，但是不在结果集的数据，将不会加锁，如事务启动后由其他事务写入的数据），以监测其他事务对这些的并发修改。TiDB 使用[乐观事务模型](mysql-compatibility.md#事务)在语句执行期间不会检测锁冲突，在事务的提交阶段才会检测事务冲突，如果执行 Select For Update 期间，有其他事务修改相关的数据，那么包含 Select For Update 语句的事务会提交失败。| |`LOCK IN SHARE MODE` | TiDB 出于兼容性解析这个语法，但是不做任何处理| ## Insert 语句 diff --git a/v1.0/sql/privilege.md b/v1.0/sql/privilege.md index af309b79c4de..0d1cdcc3df32 100755 --- a/v1.0/sql/privilege.md +++ b/v1.0/sql/privilege.md @@ -31,9 +31,9 @@ create user 'test'@'127.0.0.1' identified by 'xxx'; create user 'test'@'192.168.10.%'; ``` -允许 `test` 用户从 `192.168.10` 子网的任何一个主机登陆。 +允许 `test` 用户从 `192.168.10` 子网的任何一个主机登录。 -如果没有指定 host，则默认是所有 IP 均可登陆。如果没有指定密码，默认为空： +如果没有指定 host，则默认是所有 IP 均可登录。如果没有指定密码，默认为空： ```sql create user 'test'; @@ -61,7 +61,7 @@ drop user 'test'@'%'; sudo ./tidb-server -skip-grant-table=true ``` -这个参数启动，TiDB 会跳过权限系统，然后使用 root 登陆以后修改密码： +这个参数启动，TiDB 会跳过权限系统，然后使用 root 登录以后修改密码： ```base mysql -h 127.0.0.1 -P 4000 -u root @@ -248,7 +248,7 @@ delete from mysql.user where user='test'; #### 连接验证 -当客户端发送连接请求时，TiDB 服务器会对登陆操作进行验证。验证过程先检查 `mysql.user` 表，当某条记录的 User 和 Host 和连接请求匹配上了，再去验证 Password。用户身份基于两部分信息，发起连接的客户端的 Host，以及用户名 User。如果 User不为空，则用户名必须精确匹配。 +当客户端发送连接请求时，TiDB 服务器会对登录操作进行验证。验证过程先检查 `mysql.user` 表，当某条记录的 User 和 Host 和连接请求匹配上了，再去验证 Password。用户身份基于两部分信息，发起连接的客户端的 Host，以及用户名 User。如果 User不为空，则用户名必须精确匹配。 User+Host 可能会匹配 `user` 表里面多行，为了处理这种情况，`user` 表的行是排序过的，客户端连接时会依次去匹配，并使用首次匹配到的那一行做权限验证。排序是按 Host 在前，User 在后。 diff --git a/v1.0/sql/user-account-management.md b/v1.0/sql/user-account-management.md index bb40c35b094b..6d0c370c5ab4 100755 --- a/v1.0/sql/user-account-management.md +++ b/v1.0/sql/user-account-management.md @@ -9,7 +9,7 @@ category: user guide TiDB 将用户账户存储在 `mysql.user` 系统表里面。每个账户由用户名和 host 作为标识。每个账户可以设置一个密码。 -通过 MySQL 客户端连接到 TiDB 服务器，通过指定的账户和密码登陆： +通过 MySQL 客户端连接到 TiDB 服务器，通过指定的账户和密码登录： ``` shell> mysql --port 4000 --user xxx --password diff --git a/v1.0/sql/util.md b/v1.0/sql/util.md index 03ec105b6127..f18d3b1d2273 100755 --- a/v1.0/sql/util.md +++ b/v1.0/sql/util.md @@ -91,4 +91,4 @@ dot xx.dot -T png -O USE db_name ``` -切换默认 Database，当 SQL 语句中的表没有显式指定的 Database 时，即使用默认 Database。 +切换需要使用的 Database 的时候，如果 SQL 语句中的表没有显式指定的 Database，即默认使用当前选定的 Database。 diff --git a/v2.0/FAQ.md b/v2.0/FAQ.md index 16c517cc0c26..203b69e5e085 100755 --- a/v2.0/FAQ.md +++ b/v2.0/FAQ.md @@ -248,9 +248,9 @@ Binary 不是我们建议的安装方式，对升级支持也不友好，建议 | 滚动升级除 PD 外模块 | ansible-playbook rolling\_update.yml --skip-tags=pd | | 滚动升级监控组件 | ansible-playbook rolling\_update\_monitor.yml | -### 3.1.2 TiDB 如何登陆？ +### 3.1.2 TiDB 如何登录？ -和 MySQL 登陆方式一样，可以按照下面例子进行登陆。 +和 MySQL 登录方式一样，可以按照下面例子进行登录。 `mysql -h 127.0.0.1 -uroot -P4000` @@ -530,9 +530,9 @@ loader的 -t 参数可以根据 TiKV 的实例个数以及负载进行评估调 TiDB 支持绝大多数 MySQL 语法，一般不需要修改代码。我们提供了一个[检查工具](https://github.com/pingcap/tidb-tools/tree/master/checker)，用于检查 MySQL 中的 Schema 是否和 TiDB 兼容。 -### 4.1.4 不小心把 MySQL 的 user 表导入到 TiDB 了，或者忘记密码，无法登陆，如何处理？ +### 4.1.4 不小心把 MySQL 的 user 表导入到 TiDB 了，或者忘记密码，无法登录，如何处理？ -重启 TiDB 服务，配置文件中增加 `-skip-grant-table=true` 参数，无密码登陆集群后，可以根据情况重建用户，或者重建 mysql.user 表，具体表结构搜索官网。 +重启 TiDB 服务，配置文件中增加 `-skip-grant-table=true` 参数，无密码登录集群后，可以根据情况重建用户，或者重建 mysql.user 表，具体表结构搜索官网。 ### 4.1.5 如何导出 TiDB 数据？ diff --git a/v2.0/op-guide/monitor.md b/v2.0/op-guide/monitor.md index 172d9b4c93bf..98169f358f22 100755 --- a/v2.0/op-guide/monitor.md +++ b/v2.0/op-guide/monitor.md @@ -30,7 +30,7 @@ curl http://127.0.0.1:10080/status ### PD Server PD API 地址： ``http://${host}:${port}/pd/api/v1/${api_name}``。 -其中 port 默认为 2379，各类 api_name 详细信息参见 [PD API Doc](https://cdn.rawgit.com/pingcap/docs/master/op-guide/pd-api-v1.html)。 +其中 port 默认为 2379，各类 api_name 详细信息参见 [PD API Doc](https://download.pingcap.com/pd-api-v1.html)。 通过这个接口可以获取当前所有 TiKV 的状态以及负载均衡信息。其中最重要也是最常用的接口获取 TiKV 集群所有节点状态的接口，下面以一个单个 TiKV 构成的集群为例，说明一些用户需要了解的信息： diff --git a/v2.0/sql/dml.md b/v2.0/sql/dml.md index 15ec467ae69c..701bde99fd5c 100755 --- a/v2.0/sql/dml.md +++ b/v2.0/sql/dml.md @@ -46,7 +46,7 @@ SELECT |`HAVING where_condition` | Having 子句与 Where 子句作用类似，Having 子句可以让过滤 GroupBy 后的各种数据，Where 子句用于在聚合前过滤记录。| |`ORDER BY` | OrderBy 子句用于指定结果排序顺序，可以按照列、表达式或者是 `select_expr` 列表中某个位置的字段进行排序。| |`LIMIT` | Limit 子句用于限制结果条数。Limit 接受一个或两个数字参数，如果只有一个参数，那么表示返回数据的最大行数；如果是两个参数，那么第一个参数表示返回数据的第一行的偏移量（第一行数据的偏移量是 0），第二个参数指定返回数据的最大条目数。| -|`FOR UPDATE` | 对查询结果集所有数据上读锁，以监测其他事务对这些的并发修改。TiDB 使用[乐观事务模型](mysql-compatibility.md#事务)在语句执行期间不会检测锁冲突，在事务的提交阶段才会检测事务冲突，如果执行 Select For Update 期间，有其他事务修改相关的数据，那么包含 Select For Update 语句的事务会提交失败。| +|`FOR UPDATE` | 对查询结果集所有数据上读锁（对于在查询条件内，但是不在结果集的数据，将不会加锁，如事务启动后由其他事务写入的数据），以监测其他事务对这些的并发修改。TiDB 使用[乐观事务模型](mysql-compatibility.md#事务)在语句执行期间不会检测锁冲突，在事务的提交阶段才会检测事务冲突，如果执行 Select For Update 期间，有其他事务修改相关的数据，那么包含 Select For Update 语句的事务会提交失败。| |`LOCK IN SHARE MODE` | TiDB 出于兼容性解析这个语法，但是不做任何处理| ## Insert 语句 diff --git a/v2.0/sql/privilege.md b/v2.0/sql/privilege.md index af309b79c4de..0d1cdcc3df32 100755 --- a/v2.0/sql/privilege.md +++ b/v2.0/sql/privilege.md @@ -31,9 +31,9 @@ create user 'test'@'127.0.0.1' identified by 'xxx'; create user 'test'@'192.168.10.%'; ``` -允许 `test` 用户从 `192.168.10` 子网的任何一个主机登陆。 +允许 `test` 用户从 `192.168.10` 子网的任何一个主机登录。 -如果没有指定 host，则默认是所有 IP 均可登陆。如果没有指定密码，默认为空： +如果没有指定 host，则默认是所有 IP 均可登录。如果没有指定密码，默认为空： ```sql create user 'test'; @@ -61,7 +61,7 @@ drop user 'test'@'%'; sudo ./tidb-server -skip-grant-table=true ``` -这个参数启动，TiDB 会跳过权限系统，然后使用 root 登陆以后修改密码： +这个参数启动，TiDB 会跳过权限系统，然后使用 root 登录以后修改密码： ```base mysql -h 127.0.0.1 -P 4000 -u root @@ -248,7 +248,7 @@ delete from mysql.user where user='test'; #### 连接验证 -当客户端发送连接请求时，TiDB 服务器会对登陆操作进行验证。验证过程先检查 `mysql.user` 表，当某条记录的 User 和 Host 和连接请求匹配上了，再去验证 Password。用户身份基于两部分信息，发起连接的客户端的 Host，以及用户名 User。如果 User不为空，则用户名必须精确匹配。 +当客户端发送连接请求时，TiDB 服务器会对登录操作进行验证。验证过程先检查 `mysql.user` 表，当某条记录的 User 和 Host 和连接请求匹配上了，再去验证 Password。用户身份基于两部分信息，发起连接的客户端的 Host，以及用户名 User。如果 User不为空，则用户名必须精确匹配。 User+Host 可能会匹配 `user` 表里面多行，为了处理这种情况，`user` 表的行是排序过的，客户端连接时会依次去匹配，并使用首次匹配到的那一行做权限验证。排序是按 Host 在前，User 在后。 diff --git a/v2.0/sql/user-account-management.md b/v2.0/sql/user-account-management.md index bb40c35b094b..6d0c370c5ab4 100755 --- a/v2.0/sql/user-account-management.md +++ b/v2.0/sql/user-account-management.md @@ -9,7 +9,7 @@ category: user guide TiDB 将用户账户存储在 `mysql.user` 系统表里面。每个账户由用户名和 host 作为标识。每个账户可以设置一个密码。 -通过 MySQL 客户端连接到 TiDB 服务器，通过指定的账户和密码登陆： +通过 MySQL 客户端连接到 TiDB 服务器，通过指定的账户和密码登录： ``` shell> mysql --port 4000 --user xxx --password diff --git a/v2.0/sql/util.md b/v2.0/sql/util.md index 03ec105b6127..f18d3b1d2273 100755 --- a/v2.0/sql/util.md +++ b/v2.0/sql/util.md @@ -91,4 +91,4 @@ dot xx.dot -T png -O USE db_name ``` -切换默认 Database，当 SQL 语句中的表没有显式指定的 Database 时，即使用默认 Database。 +切换需要使用的 Database 的时候，如果 SQL 语句中的表没有显式指定的 Database，即默认使用当前选定的 Database。 diff --git a/v2.1/FAQ.md b/v2.1/FAQ.md index 79c343f90db1..dcb83acdc023 100755 --- a/v2.1/FAQ.md +++ b/v2.1/FAQ.md @@ -114,7 +114,7 @@ TiDB 的 sql_mode 与 MySQL 的 sql_mode 设置方法有一些差别，TiDB 不 #### 1.1.24 TiDB 支持哪些认证协议，过程是怎样的？ -这一层跟 MySQL 一样，走的 SASL 认证协议，用于用户登陆认证，对密码的处理流程。 +这一层跟 MySQL 一样，走的 SASL 认证协议，用于用户登录认证，对密码的处理流程。 客户端连接 TiDB 的时候，走的是 challenge-response（挑战-应答）的认证模式，过程如下： @@ -345,9 +345,9 @@ Binary 不是我们建议的安装方式，对升级支持也不友好，建议 | 滚动升级除 PD 外模块 | ansible-playbook rolling\_update.yml --skip-tags=pd | | 滚动升级监控组件 | ansible-playbook rolling\_update\_monitor.yml | -#### 3.1.2 TiDB 如何登陆？ +#### 3.1.2 TiDB 如何登录？ -和 MySQL 登陆方式一样，可以按照下面例子进行登陆。 +和 MySQL 登录方式一样，可以按照下面例子进行登录。 `mysql -h 127.0.0.1 -uroot -P4000` @@ -683,9 +683,9 @@ loader 的 -t 参数可以根据 TiKV 的实例个数以及负载进行评估调 TiDB 支持绝大多数 MySQL 语法，一般不需要修改代码。我们提供了一个[检查工具](https://github.com/pingcap/tidb-tools/tree/master/checker)，用于检查 MySQL 中的 Schema 是否和 TiDB 兼容。 -#### 4.1.4 不小心把 MySQL 的 user 表导入到 TiDB 了，或者忘记密码，无法登陆，如何处理？ +#### 4.1.4 不小心把 MySQL 的 user 表导入到 TiDB 了，或者忘记密码，无法登录，如何处理？ -重启 TiDB 服务，配置文件中增加 `-skip-grant-table=true` 参数，无密码登陆集群后，可以根据情况重建用户，或者重建 mysql.user 表，具体表结构搜索官网。 +重启 TiDB 服务，配置文件中增加 `-skip-grant-table=true` 参数，无密码登录集群后，可以根据情况重建用户，或者重建 mysql.user 表，具体表结构搜索官网。 #### 4.1.5 在 Loader 运行的过程中，TiDB 可以对外提供服务吗？ 该操作进行逻辑插入，TiDB 仍可对外提供服务，但不要执行相关 DDL 操作。 diff --git a/v2.1/benchmark/sysbench-v2.md b/v2.1/benchmark/sysbench-v2.md index 01c05bdc3dad..329cb41a931f 100755 --- a/v2.1/benchmark/sysbench-v2.md +++ b/v2.1/benchmark/sysbench-v2.md @@ -26,10 +26,7 @@ IDC 机器 | OS | Linux (CentOS 7.3.1611) | | CPU | 40 vCPUs, Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz | | RAM | 128GB | -| DISK | Optane 500GB SSD * 1 | - -Sysbench 测试脚本： -https://github.com/pingcap/tidb-bench/tree/master/sysbench +| DISK | Optane 500GB SSD * 1 | ## 测试方案 diff --git a/v2.1/benchmark/sysbench.md b/v2.1/benchmark/sysbench.md index 36f39aef5f16..29cb054450cc 100755 --- a/v2.1/benchmark/sysbench.md +++ b/v2.1/benchmark/sysbench.md @@ -10,7 +10,9 @@ draft: true 测试 TiDB 在 OLTP 场景下的性能以及水平扩展能力。 -> **注意**: 不同的测试环境可能使测试结果发生改变。 +> **注意：** +> +> 不同的测试环境可能使测试结果发生改变。 ## 测试版本、时间、地点 diff --git a/v2.1/benchmark/tpch-v2.md b/v2.1/benchmark/tpch-v2.md index de31f746af7d..aac0be586270 100755 --- a/v2.1/benchmark/tpch-v2.md +++ b/v2.1/benchmark/tpch-v2.md @@ -9,7 +9,9 @@ category: benchmark 测试 TiDB 在 OLAP 场景下 2.0 和 2.1 版本的性能对比。 -> **注意**：不同的测试环境可能使测试结果发生改变。 +> **注意：** +> +> 不同的测试环境可能使测试结果发生改变。 ## 测试环境 diff --git a/v2.1/benchmark/tpch.md b/v2.1/benchmark/tpch.md index 1d8f1ba9031b..7e45daaeaeaa 100755 --- a/v2.1/benchmark/tpch.md +++ b/v2.1/benchmark/tpch.md @@ -9,7 +9,9 @@ category: benchmark 测试 TiDB 在 OLAP 场景下 1.0 和 2.0 版本的性能对比。 -> **注意**：不同的测试环境可能使测试结果发生改变。 +> **注意：** +> +> 不同的测试环境可能使测试结果发生改变。 ## 测试环境 diff --git a/v2.1/op-guide/ansible-deployment-rolling-update.md b/v2.1/op-guide/ansible-deployment-rolling-update.md index 4bdca69f2782..4a103736590c 100755 --- a/v2.1/op-guide/ansible-deployment-rolling-update.md +++ b/v2.1/op-guide/ansible-deployment-rolling-update.md @@ -7,7 +7,9 @@ category: deployment 滚动升级 TiDB 集群时，会串行关闭服务，更新服务 binary 和配置文件，再启动服务。在前端配置负载均衡的情况下，滚动升级期间不影响业务运行（最小环境 ：pd * 3、tidb * 2、tikv * 3）。 -> **注**：如果 TiDB 集群开启了 binlog，部署了 Pump 和 Drainer 服务，升级 TiDB 服务时会升级 Pump，请先停止 Drainer 服务再执行滚动升级操作。 +> **注意：** +> +> 如果 TiDB 集群开启了 binlog，部署了 Pump 和 Drainer 服务，升级 TiDB 服务时会升级 Pump，请先停止 Drainer 服务再执行滚动升级操作。 ## 升级组件版本 @@ -21,7 +23,9 @@ category: deployment tidb_version = v2.0.7 ``` - > **注**：如果使用 master 分支的 tidb-ansible，`tidb_version = latest` 保持不变即可，latest 版本的 TiDB 安装包会每日更新。 + > **注意：** + > + > 如果使用 master 分支的 tidb-ansible，`tidb_version = latest` 保持不变即可，latest 版本的 TiDB 安装包会每日更新。 2. 删除原有的 downloads 目录 `/home/tidb/tidb-ansible/downloads/` diff --git a/v2.1/op-guide/ansible-deployment-scale.md b/v2.1/op-guide/ansible-deployment-scale.md index e9bc3bf9a0e6..18045de3886d 100755 --- a/v2.1/op-guide/ansible-deployment-scale.md +++ b/v2.1/op-guide/ansible-deployment-scale.md @@ -87,7 +87,8 @@ TiDB 集群可以在不影响线上服务的情况下进行扩容和缩容。以 ansible-playbook bootstrap.yml -l 172.16.10.101,172.16.10.102 ``` - > **注**： + > **注意：** + > > 如果 `inventory.ini` 中为节点配置了别名，如 `node101 ansible_host=172.16.10.101`，执行 ansible-playbook 时 -l 请指定别名，以下步骤类似。例如：`ansible-playbook bootstrap.yml -l node101,node102` 3. 部署新增节点： diff --git a/v2.1/op-guide/ansible-deployment.md b/v2.1/op-guide/ansible-deployment.md index 302f7dd837b2..ad6f0c424591 100755 --- a/v2.1/op-guide/ansible-deployment.md +++ b/v2.1/op-guide/ansible-deployment.md @@ -22,7 +22,9 @@ Ansible 是一款自动化运维工具，[TiDB-Ansible](https://github.com/pingc - [清除集群数据](../op-guide/ansible-operation.md#清除集群数据) - [销毁集群](../op-guide/ansible-operation.md#销毁集群) -> **注**：对于生产环境，须使用 TiDB-Ansible 部署 TiDB 集群。如果只是用于测试 TiDB 或体验 TiDB 的特性，建议[使用 Docker Compose 在单机上快速部署 TiDB 集群](../op-guide/docker-compose.md)。 +> **注意：** +> +> 对于生产环境，须使用 TiDB-Ansible 部署 TiDB 集群。如果只是用于测试 TiDB 或体验 TiDB 的特性，建议[使用 Docker Compose 在单机上快速部署 TiDB 集群](../op-guide/docker-compose.md)。 ## 准备机器 @@ -32,7 +34,9 @@ Ansible 是一款自动化运维工具，[TiDB-Ansible](https://github.com/pingc - 推荐安装 CentOS 7.3 及以上版本 Linux 操作系统，x86_64 架构 (amd64)。 - 机器之间内网互通。 - > **注：使用 Ansible 方式部署时，TiKV 及 PD 节点数据目录所在磁盘请使用 SSD 磁盘，否则无法通过检测。** 如果仅验证功能，建议使用 [Docker Compose 部署方案](../op-guide/docker-compose.md)单机进行测试。 + > **注意：** + > + > 使用 Ansible 方式部署时，TiKV 及 PD 节点数据目录所在磁盘请使用 SSD 磁盘，否则无法通过检测。** 如果仅验证功能，建议使用 [Docker Compose 部署方案](../op-guide/docker-compose.md)单机进行测试。 2. 部署中控机一台: @@ -143,7 +147,9 @@ The key's randomart image is: $ git clone https://github.com/pingcap/tidb-ansible.git ``` -> **注**：请务必按文档操作，将 `tidb-ansible` 下载到 `/home/tidb` 目录下，权限为 `tidb` 用户，不要下载到 `/root` 下，否则会遇到权限问题。 +> **注意：** +> +> 请务必按文档操作，将 `tidb-ansible` 下载到 `/home/tidb` 目录下，权限为 `tidb` 用户，不要下载到 `/root` 下，否则会遇到权限问题。 ## 在中控机器上安装 Ansible 及其依赖 @@ -311,8 +317,9 @@ UUID=c51eb23b-195c-4061-92a9-3fad812cc12f /data1 ext4 defaults,nodelalloc,noatim 以 `tidb` 用户登录中控机，`inventory.ini` 文件路径为 `/home/tidb/tidb-ansible/inventory.ini`。 -> **注：** 请使用内网 IP 来部署集群，如果部署目标机器 SSH 端口非默认 22 端口，需添加 `ansible_port` 变量，如： -> `TiDB1 ansible_host=172.16.10.1 ansible_port=5555` +> **注意：** +> +> 请使用内网 IP 来部署集群，如果部署目标机器 SSH 端口非默认 22 端口，需添加 `ansible_port` 变量，如 `TiDB1 ansible_host=172.16.10.1 ansible_port=5555`。 标准 TiDB 集群需要 6 台机器: @@ -465,7 +472,9 @@ TiKV1-1 ansible_host=172.16.10.4 deploy_dir=/data1/deploy #### 其他变量调整 -> **注：** 以下控制变量开启请使用首字母大写 `True`，关闭请使用首字母大写 `False`。 +> **注意：** +> +> 以下控制变量开启请使用首字母大写 `True`，关闭请使用首字母大写 `False`。 | 变量 | 含义 | | --------------- | ---------------------------------------------------------- | @@ -529,7 +538,9 @@ TiKV1-1 ansible_host=172.16.10.4 deploy_dir=/data1/deploy ansible-playbook deploy.yml ``` - >**注**：Grafana Dashboard 上的 Report 按钮可用来生成 PDF 文件，此功能依赖 `fontconfig` 包和英文字体。如需使用该功能，登录 **grafana_servers** 机器，用以下命令安装： + > **注意：** + > + > Grafana Dashboard 上的 Report 按钮可用来生成 PDF 文件，此功能依赖 `fontconfig` 包和英文字体。如需使用该功能，登录 **grafana_servers** 机器，用以下命令安装： > > ``` > $ sudo yum install fontconfig open-sans-fonts @@ -619,7 +630,9 @@ synchronised to NTP server (85.199.214.101) at stratum 2 polling server every 1024 s ``` -> **注：** Ubuntu 系统需安装 ntpstat 软件包。 +> **注意：** +> +> Ubuntu 系统需安装 ntpstat 软件包。 以下情况表示 NTP 服务未正常同步： diff --git a/v2.1/op-guide/backup-restore.md b/v2.1/op-guide/backup-restore.md index 7f3f91ae96ad..20f5baf7ff01 100755 --- a/v2.1/op-guide/backup-restore.md +++ b/v2.1/op-guide/backup-restore.md @@ -40,7 +40,9 @@ cd tidb-enterprise-tools-latest-linux-amd64 可使用 [`mydumper`](../tools/mydumper.md) 从 TiDB 导出数据进行备份，然后用 [`loader`](../tools/loader.md) 将其导入到 TiDB 里面进行恢复。 -> **注意**：必须使用企业版工具集包的 `mydumper`，不要使用你的操作系统的包管理工具提供的 `mydumper`。`mydumper` 的上游版本并不能对 TiDB 进行正确处理 ([#155](https://github.com/maxbube/mydumper/pull/155))。由于使用 `mysqldump` 进行数据备份和恢复都要耗费许多时间，这里也并不推荐。 +> **注意：** +> +> 必须使用企业版工具集包的 `mydumper`，不要使用你的操作系统的包管理工具提供的 `mydumper`。`mydumper` 的上游版本并不能对 TiDB 进行正确处理 ([#155](https://github.com/maxbube/mydumper/pull/155))。由于使用 `mysqldump` 进行数据备份和恢复都要耗费许多时间，这里也并不推荐。 ### `mydumper`/`loader` 全量备份恢复最佳实践 diff --git a/v2.1/op-guide/configuration.md b/v2.1/op-guide/configuration.md index 0fbcae40575f..b200551dc348 100755 --- a/v2.1/op-guide/configuration.md +++ b/v2.1/op-guide/configuration.md @@ -129,7 +129,11 @@ category: deployment + PROXY Protocol 请求头读取超时时间。 + 默认: 5 -+ 单位为秒。注意：请不要配置成0，除非特殊情况，一般使用默认值即可。 ++ 单位为秒。 + +> **注意：** +> +> 请不要配置成0，除非特殊情况，一般使用默认值即可。 ## Placement Driver (PD) diff --git a/v2.1/op-guide/cross-dc-deployment.md b/v2.1/op-guide/cross-dc-deployment.md index 8cef95037bad..5ec7bfb2bf3e 100755 --- a/v2.1/op-guide/cross-dc-deployment.md +++ b/v2.1/op-guide/cross-dc-deployment.md @@ -59,7 +59,9 @@ TiDB, TiKV, PD 分别分布在 3 个不同的中心，这是最常规，可用 另外部分用户采用这种方式做双数据中心多活，两个数据中心各有一个集群，将业务分为两个库，每个库服务一部分数据，每个数据中心的业务只会访问一个库，两个集群之间通过 binlog 将本数据中心业务所涉及的库中的数据变更同步到对端机房，形成环状备份。 -注意：在两数据中心 + binlog 同步部署方案中，数据中心之间只有 binlog 异步复制。在数据中心间的延迟较高的情况下，从集群落后主集群的数据量会增大。当主集群故障后（DR），会造成数据丢失，丢失的数据量受网络延迟等因素影响。 +> **注意：** +> +> 在两数据中心 + binlog 同步部署方案中，数据中心之间只有 binlog 异步复制。在数据中心间的延迟较高的情况下，从集群落后主集群的数据量会增大。当主集群故障后（DR），会造成数据丢失，丢失的数据量受网络延迟等因素影响。 ## 高可用和容灾分析 diff --git a/v2.1/op-guide/docker-compose.md b/v2.1/op-guide/docker-compose.md index 901f063cb8ac..5efe0bb123b9 100755 --- a/v2.1/op-guide/docker-compose.md +++ b/v2.1/op-guide/docker-compose.md @@ -7,7 +7,9 @@ category: deployment 本文档介绍如何在单机上通过 Docker Compose 快速一键部署一套 TiDB 测试集群。[Docker Compose](https://docs.docker.com/compose/overview) 可以通过一个 YAML 文件定义多个容器的应用服务，然后一键启动或停止。 -> **注**：对于生产环境，不要使用 Docker Compose 进行部署，而应[使用 Ansible 部署 TiDB 集群](../op-guide/ansible-deployment.md)。 +> **注意：** +> +> 对于生产环境，不要使用 Docker Compose 进行部署，而应[使用 Ansible 部署 TiDB 集群](../op-guide/ansible-deployment.md)。 ## 准备环境 diff --git a/v2.1/op-guide/docker-deployment.md b/v2.1/op-guide/docker-deployment.md index 86a429f3d7cf..dc5a7427677c 100755 --- a/v2.1/op-guide/docker-deployment.md +++ b/v2.1/op-guide/docker-deployment.md @@ -7,7 +7,9 @@ category: deployment 本文介绍如何使用 Docker 部署一个多节点的 TiDB 集群。 -> **注**：对于生产环境，不要使用 Docker 进行部署，而应[使用 Ansible 部署 TiDB 集群](../op-guide/ansible-deployment.md)。 +> **注意：** +> +> 对于生产环境，不要使用 Docker 进行部署，而应[使用 Ansible 部署 TiDB 集群](../op-guide/ansible-deployment.md)。 ## 环境准备 diff --git a/v2.1/op-guide/gc.md b/v2.1/op-guide/gc.md index cc13f9ed812c..f96ad08912ee 100755 --- a/v2.1/op-guide/gc.md +++ b/v2.1/op-guide/gc.md @@ -46,7 +46,9 @@ update mysql.tidb set VARIABLE_VALUE = '24h' where VARIABLE_NAME = 'tikv_gc_life 时长字符串的形式是数字后接时间单位的序列，如 `24h`、`2h30m`、`2.5h`。可以使用的时间单位包括 "h"、"m"、"s"。 -需要注意的是，在数据更新频繁的场景下如果将 `tikv_gc_life_time` 设置得比较大（如数天甚至数月），可能会有一些潜在的问题： +> **注意：** +> +> 在数据更新频繁的场景下如果将 `tikv_gc_life_time` 设置得比较大（如数天甚至数月），可能会有一些潜在的问题： * 随着版本的不断增多，数据占用的磁盘空间会随之增加。 * 大量的历史版本会在一定程度上导致查询变慢，主要影响范围查询（如 `select count(*) from t`）。 diff --git a/v2.1/op-guide/history-read.md b/v2.1/op-guide/history-read.md index 4ce53baa8d0c..674ef0cc0ec1 100755 --- a/v2.1/op-guide/history-read.md +++ b/v2.1/op-guide/history-read.md @@ -19,7 +19,9 @@ TiDB 实现了通过标准 SQL 接口读取历史数据功能，无需特殊的 “2016-10-08 16:45:26.999”，一般来说可以只写到秒，比如”2016-10-08 16:45:26”。 当这个变量被设置时，TiDB 会用这个时间戳建立 Snapshot（没有开销，只是创建数据结构），随后所有的 Select 操作都会在这个 Snapshot 上读取数据。 -> **注意**：TiDB 的事务是通过 PD 进行全局授时，所以存储的数据版本也是以 PD 所授时间戳作为版本号。在生成 Snapshot 时，是以 tidb_snapshot 变量的值作为版本号，如果 TiDB Server 所在机器和 PD Server 所在机器的本地时间相差较大，需要以 PD 的时间为准。 +> **注意：** +> +> TiDB 的事务是通过 PD 进行全局授时，所以存储的数据版本也是以 PD 所授时间戳作为版本号。在生成 Snapshot 时，是以 tidb_snapshot 变量的值作为版本号，如果 TiDB Server 所在机器和 PD Server 所在机器的本地时间相差较大，需要以 PD 的时间为准。 当读取历史版本操作结束后，可以结束当前 Session 或者是通过 Set 语句将 tidb_snapshot 变量的值设为 ""，即可读取最新版本的数据。 @@ -97,8 +99,8 @@ TiDB 使用周期性运行的 GC（Garbage Collection，垃圾回收）来进行 Query OK, 0 rows affected (0.00 sec) ``` - > **注意**： - > + > **注意：** + > > - 这里的时间设置的是 update 语句之前的那个时间。 > - 在 `tidb_snapshot` 前须使用 `@@` 而非 `@`，因为 `@@` 表示系统变量，`@` 表示用户变量。 @@ -135,4 +137,6 @@ TiDB 使用周期性运行的 GC（Garbage Collection，垃圾回收）来进行 3 rows in set (0.00 sec) ``` - > **注意**：在 `tidb_snapshot` 前须使用 `@@` 而非 `@`，因为 `@@` 表示系统变量，`@` 表示用户变量。 \ No newline at end of file + > **注意：** + > + > 在 `tidb_snapshot` 前须使用 `@@` 而非 `@`，因为 `@@` 表示系统变量，`@` 表示用户变量。 \ No newline at end of file diff --git a/v2.1/op-guide/horizontal-scale.md b/v2.1/op-guide/horizontal-scale.md index 93ff949a4ed2..d1cb522f6a10 100755 --- a/v2.1/op-guide/horizontal-scale.md +++ b/v2.1/op-guide/horizontal-scale.md @@ -9,7 +9,9 @@ category: deployment TiDB 集群可以在不影响线上服务的情况下动态进行扩容和缩容。 -> **注**：如果使用 Ansible 部署 TiDB 集群，请参考[使用 Ansible 扩容缩容](../op-guide/ansible-deployment-scale.md)。 +> **注意：** +> +> 如果使用 Ansible 部署 TiDB 集群，请参考[使用 Ansible 扩容缩容](../op-guide/ansible-deployment-scale.md)。 下面分别介绍如何增加或者删除 PD，TiKV 以及 TiDB 的节点。 diff --git a/v2.1/op-guide/migration-overview.md b/v2.1/op-guide/migration-overview.md index 86105d6537dc..a5757fc244bd 100755 --- a/v2.1/op-guide/migration-overview.md +++ b/v2.1/op-guide/migration-overview.md @@ -30,7 +30,9 @@ category: advanced ## MySQL 开启 binlog -**注意： 只有上文提到的第二种场景才需要在 dump 数据之前先开启 binlog** +> **注意：** +> +> 只有上文提到的第二种场景才需要在 dump 数据之前先开启 binlog** + MySQL 开启 binlog 功能，参考 [Setting the Replication Master Configuration](http://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) + Binlog 格式必须使用 `ROW` format，这也是 MySQL 5.7 之后推荐的 binlog 格式，可以使用如下语句打开: diff --git a/v2.1/op-guide/migration.md b/v2.1/op-guide/migration.md index 0ec6e41ac676..46352bd4b6c6 100755 --- a/v2.1/op-guide/migration.md +++ b/v2.1/op-guide/migration.md @@ -11,7 +11,9 @@ category: advanced 你可以使用 `mydumper` 从 MySQL 导出数据，然后用 `loader` 将其导入到 TiDB 里面。 -> **注意**：虽然 TiDB 也支持使用 MySQL 官方的 `mysqldump` 工具来进行数据的迁移工作，但相比于 `mydumper`/`loader`，性能会慢很多，大量数据的迁移会花费很多时间，这里我们并不推荐。 +> **注意：** +> +> 虽然 TiDB 也支持使用 MySQL 官方的 `mysqldump` 工具来进行数据的迁移工作，但相比于 `mydumper`/`loader`，性能会慢很多，大量数据的迁移会花费很多时间，这里我们并不推荐。 ### `mydumper`/`loader` 全量导入数据最佳实践 @@ -46,13 +48,19 @@ category: advanced `--skip-tz-utc` 添加这个参数忽略掉 MySQL 与导数据的机器之间时区设置不一致的情况，禁止自动转换。 -> 注意：在阿里云等一些需要 `super privilege` 的云上面，`mydumper` 需要加上 `--no-locks` 参数，否则会提示没有权限操作。 +> **注意：** +> +> 在阿里云等一些需要 `super privilege` 的云上面，`mydumper` 需要加上 `--no-locks` 参数，否则会提示没有权限操作。 ### 向 TiDB 导入数据 -> 注意：目前 TiDB 支持 UTF8mb4 [字符编码](../sql/character-set-support.md)，假设 mydumper 导出数据为 latin1 字符编码，请使用 `iconv -f latin1 -t utf-8 $file -o /data/imdbload/$basename` 命令转换，$file 为已有文件，$basename 为转换后文件。 +> **注意：** +> +> 目前 TiDB 支持 UTF8mb4 [字符编码](../sql/character-set-support.md)，假设 mydumper 导出数据为 latin1 字符编码，请使用 `iconv -f latin1 -t utf-8 $file -o /data/imdbload/$basename` 命令转换，$file 为已有文件，$basename 为转换后文件。 -> 注意：如果 mydumper 使用 -m 参数，会导出不带表结构的数据，这时 loader 无法导入数据。 +> **注意：** +> +> 如果 mydumper 使用 -m 参数，会导出不带表结构的数据，这时 loader 无法导入数据。 我们使用 `loader` 将之前导出的数据导入到 TiDB。Loader 的下载和具体的使用方法见 [Loader 使用文档](../tools/loader.md) @@ -141,9 +149,10 @@ binlog-pos = 930143241 binlog-gtid = "2bfabd22-fff7-11e6-97f7-f02fa73bcb01:1-23,61ccbb5d-c82d-11e6-ac2e-487b6bd31bf7:1-4" ``` -+ 注意：`syncer.meta` 只需要第一次使用的时候配置，后续 `syncer` 同步新的 binlog 之后会自动将其更新到最新的 position。 - -+ 注意： 如果使用 binlog position 同步则只需要配置 binlog-name binlog-pos; 使用 gtid 同步则需要设置 gtid，且启动 syncer 时带有 `--enable-gtid` +> **注意：** +> +> - `syncer.meta` 只需要第一次使用的时候配置，后续 `syncer` 同步新的 binlog 之后会自动将其更新到最新的 position。 +> - 如果使用 binlog position 同步则只需要配置 binlog-name binlog-pos; 使用 gtid 同步则需要设置 gtid，且启动 syncer 时带有 `--enable-gtid` ### 启动 `syncer` diff --git a/v2.1/op-guide/monitor.md b/v2.1/op-guide/monitor.md index 29ecc07d918f..001d4494ee11 100755 --- a/v2.1/op-guide/monitor.md +++ b/v2.1/op-guide/monitor.md @@ -36,7 +36,7 @@ curl http://127.0.0.1:10080/status PD API 地址：`http://${host}:${port}/pd/api/v1/${api_name}`。 -其中 port 默认为 2379，各类 api_name 详细信息参见 [PD API Doc](https://cdn.rawgit.com/pingcap/docs/master/op-guide/pd-api-v1.html)。 +其中 port 默认为 2379，各类 api_name 详细信息参见 [PD API Doc](https://download.pingcap.com/pd-api-v1.html)。 通过这个接口可以获取当前所有 TiKV 的状态以及负载均衡信息。其中最重要也是最常用的接口获取 TiKV 集群所有节点状态的接口，下面以一个单个 TiKV 构成的集群为例，说明一些用户需要了解的信息： diff --git a/v2.1/op-guide/recommendation.md b/v2.1/op-guide/recommendation.md index 1f918f1e3be8..e04b69567067 100755 --- a/v2.1/op-guide/recommendation.md +++ b/v2.1/op-guide/recommendation.md @@ -18,7 +18,7 @@ TiDB 作为一款开源分布式 NewSQL 数据库，可以很好的部署和运 | Oracle Enterprise Linux | 7.3 及以上 | | Ubuntu LTS | 16.04 及以上 | -> **注**： +> **注意：** > > - TiDB 只支持 Red Hat 兼容内核 (RHCK) 的 Oracle Enterprise Linux，不支持 Oracle Enterprise Linux 提供的 Unbreakable Enterprise Kernel。 > - TiDB 在 CentOS 7.3 的环境下进行过大量的测试，同时社区也有很多该操作系统部署的最佳实践，因此，建议使用 CentOS 7.3 以上的 Linux 操作系统来部署 TiDB。 @@ -36,7 +36,7 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器 | PD | 4核+ | 8 GB+ | SAS, 200 GB+ | 千兆网卡 | 1（可与 TiDB 同机器） | | TiKV | 8核+ | 32 GB+ | SSD, 200 GB+ | 千兆网卡 | 3 | -> **注**： +> **注意：** > > - 验证测试环境中的 TiDB 和 PD 可以部署在同一台服务器上。 > - 如进行性能相关的测试，避免采用低性能存储和网络硬件配置，防止对测试结果的正确性产生干扰。 @@ -51,7 +51,7 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器 | TiKV | 16核+ | 32 GB+ | SSD | 万兆网卡（2块最佳） | 3 | | 监控 | 8核+ | 16 GB+ | SAS | 千兆网卡 | 1 | -> **注**： +> **注意：** > > - 生产环境中的 TiDB 和 PD 可以部署和运行在同服务器上，如对性能和可靠性有更高的要求，应尽可能分开部署。 > - 生产环境强烈推荐使用更高的配置。 diff --git a/v2.1/op-guide/tidb-config-file.md b/v2.1/op-guide/tidb-config-file.md index 899d94c543d5..1cfe9eec4c0d 100755 --- a/v2.1/op-guide/tidb-config-file.md +++ b/v2.1/op-guide/tidb-config-file.md @@ -31,7 +31,10 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ + 这个选项可以设置 TiDB 的系统变量 `lower_case_table_names` 的值。 + 默认: 2 + 具体可以查看 MySQL 关于这个变量的[描述](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_lower_case_table_names) -+ 注意：目前 TiDB 只支持将该选项的值设为 2，即按照大小写来保存表名，按照小写来比较（不区分大小写）。 + +> **注意：** +> +> 目前 TiDB 只支持将该选项的值设为 2，即按照大小写来保存表名，按照小写来比较（不区分大小写）。 ### `compatible-kill-query` diff --git a/v2.1/op-guide/tidb-v2.0-upgrade-guide.md b/v2.1/op-guide/tidb-v2.0-upgrade-guide.md index f718c9f4971b..c629acf65267 100755 --- a/v2.1/op-guide/tidb-v2.0-upgrade-guide.md +++ b/v2.1/op-guide/tidb-v2.0-upgrade-guide.md @@ -28,7 +28,9 @@ Name: jmespath Version: 0.9.0 ``` -> **注意**：请务必按以上文档安装 Ansible 及其依赖。确认 Jinja2 版本是否正确，否则启动 Grafana 时会报错。确认 jmespath 版本是否正确，否则滚动升级 TiKV 时会报错。 +> **注意：** +> +> 请务必按以上文档安装 Ansible 及其依赖。确认 Jinja2 版本是否正确，否则启动 Grafana 时会报错。确认 jmespath 版本是否正确，否则滚动升级 TiKV 时会报错。 ## 在中控机器上下载 TiDB-Ansible diff --git a/v2.1/op-guide/tidb-v2.1-upgrade-guide.md b/v2.1/op-guide/tidb-v2.1-upgrade-guide.md index a6d757270776..6030c1d37052 100755 --- a/v2.1/op-guide/tidb-v2.1-upgrade-guide.md +++ b/v2.1/op-guide/tidb-v2.1-upgrade-guide.md @@ -36,7 +36,9 @@ Name: jmespath Version: 0.9.3 ``` -> **注意**：请务必按以上文档安装 Ansible 及其依赖。确认 Jinja2 版本是否正确，否则启动 Grafana 时会报错。确认 jmespath 版本是否正确，否则滚动升级 TiKV 时会报错。 +> **注意：** +> +> 请务必按以上文档安装 Ansible 及其依赖。确认 Jinja2 版本是否正确，否则启动 Grafana 时会报错。确认 jmespath 版本是否正确，否则滚动升级 TiKV 时会报错。 ## 在中控机器上下载 TiDB-Ansible diff --git a/v2.1/releases/205.md b/v2.1/releases/205.md index ab57e8e02212..588bed594a4d 100755 --- a/v2.1/releases/205.md +++ b/v2.1/releases/205.md @@ -22,7 +22,7 @@ category: Releases - 支持注释中存在多个星号的情况 [#6858](https://github.com/pingcap/tidb/pull/6858) - Bug Fixes - 修复 `KILL QUERY` 语句权限检查问题 [#7003](https://github.com/pingcap/tidb/pull/7003) - - 修复用户数量超过 1024 时可能造成无法登陆的问题 [#6986](https://github.com/pingcap/tidb/pull/6986) + - 修复用户数量超过 1024 时可能造成无法登录的问题 [#6986](https://github.com/pingcap/tidb/pull/6986) - 修复一个写入无符号类型 `float`/`double` 数据的问题 [#6940](https://github.com/pingcap/tidb/pull/6940) - 修复 `COM_FIELD_LIST` 命令的兼容性，解决部分 MariaDB 客户端遇到 Panic 的问题 [#6929](https://github.com/pingcap/tidb/pull/6929) - 修复 `CREATE TABLE IF NOT EXISTS LIKE` 行为 [#6928](https://github.com/pingcap/tidb/pull/6928) diff --git a/v2.1/sql/aggregate-group-by-functions.md b/v2.1/sql/aggregate-group-by-functions.md index 58f5e344fede..9babc180e351 100755 --- a/v2.1/sql/aggregate-group-by-functions.md +++ b/v2.1/sql/aggregate-group-by-functions.md @@ -21,7 +21,7 @@ TiDB 支持的 MySQL GROUP BY 聚合函数如下所示： | [`MIN()`](https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_min) | 返回最小值 | | [`GROUP_CONCAT()`](https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_group-concat) | 返回连接的字符串 | -> **注意**： +> **注意：** > > - 除非另有说明，否则组函数默认忽略 `NULL` 值。 > - 如果在不包含 `GROUP BY` 子句的语句中使用组函数，则相当于对所有行进行分组。 diff --git a/v2.1/sql/character-set-support.md b/v2.1/sql/character-set-support.md index 17f436caf851..1fbc67989f93 100755 --- a/v2.1/sql/character-set-support.md +++ b/v2.1/sql/character-set-support.md @@ -26,7 +26,9 @@ mysql> SHOW CHARACTER SET; 5 rows in set (0.00 sec) ``` -> **注意**：在 `TiDB` 中实际上 `utf8` 被当做成了 `utf8mb4` 来处理。 +> **注意：** +> +> 在 `TiDB` 中实际上 `utf8` 被当做成了 `utf8mb4` 来处理。 对于字符集来说，至少会有一个 Collation（排序规则）与之对应。而大部分字符集实际上会有多个 Collation。利用以下的语句可以查看： @@ -62,7 +64,9 @@ mysql> SHOW COLLATION WHERE Charset = 'latin1'; 每一个字符集，都有一个默认的 Collation，例如 `utf8` 的默认 Collation 就为 `utf8_bin`。 -**注意** `TiDB` 目前的 Collation 都是区分大小写的。 +> **注意：** +> +> `TiDB` 目前的 Collation 都是区分大小写的。 ## Collation 命名规则 @@ -80,7 +84,9 @@ mysql> SHOW COLLATION WHERE Charset = 'latin1'; | \_ci | 大小写不敏感 | | \_cs | 大小写敏感 | -> **注意**：目前为止 TiDB 只支持部分以上提到的 Collation。 +> **注意：** +> +> 目前为止 TiDB 只支持部分以上提到的 Collation。 ## 数据库 Character Set 和 Collation diff --git a/v2.1/sql/date-and-time-types.md b/v2.1/sql/date-and-time-types.md index 6bbcae8257da..8ad288c4e07e 100755 --- a/v2.1/sql/date-and-time-types.md +++ b/v2.1/sql/date-and-time-types.md @@ -58,7 +58,9 @@ TIME 类型的值的格式是 'HH:MM:SS'，值的范围是 '-838:59:59' 到 '838 TIME 类型可以包含分数部分，如果包含分数部分，那么 TIME 的表示范围则是 '-838:59:59.000000' 到 '838:59:59.000000'。 -注意缩写的时间，'11:12' 表示的是 '11:12:00' 而不是 '00:11:12'，然而 '1112' 表示的是 '00:11:12'。这里的区别是是否包含分号 :，处理起来是不一样的。 +> **注意：** +> +> 关于缩写的时间，'11:12' 表示的是 '11:12:00' 而不是 '00:11:12'，然而 '1112' 表示的是 '00:11:12'。这里的区别是是否包含分号 :，处理起来是不一样的。 ## YEAR 类型 diff --git a/v2.1/sql/ddl.md b/v2.1/sql/ddl.md index 66cec98e4da6..f70b221377ac 100755 --- a/v2.1/sql/ddl.md +++ b/v2.1/sql/ddl.md @@ -207,7 +207,9 @@ TRUNCATE [TABLE] tbl_name 此操作于删除指定表全表数据的操作类似，但是操作的执行速度会远快于删除全表的速度，且不受表内数据行数影响。 -> **注意**：使用此语句后，原先表内的 `AUTO_INCREMENT` 的值不会记录，会被重新计数。 +> **注意：** +> +> 使用此语句后，原先表内的 `AUTO_INCREMENT` 的值不会记录，会被重新计数。 ## RENAME TABLE 语法 diff --git a/v2.1/sql/dml.md b/v2.1/sql/dml.md index e7c5d5602b21..c0e8293d269a 100755 --- a/v2.1/sql/dml.md +++ b/v2.1/sql/dml.md @@ -48,7 +48,7 @@ SELECT |`HAVING where_condition` | Having 子句与 Where 子句作用类似，Having 子句可以让过滤 GroupBy 后的各种数据，Where 子句用于在聚合前过滤记录。| |`ORDER BY` | OrderBy 子句用于指定结果排序顺序，可以按照列、表达式或者是 `select_expr` 列表中某个位置的字段进行排序。| |`LIMIT` | Limit 子句用于限制结果条数。Limit 接受一个或两个数字参数，如果只有一个参数，那么表示返回数据的最大行数；如果是两个参数，那么第一个参数表示返回数据的第一行的偏移量（第一行数据的偏移量是 0），第二个参数指定返回数据的最大条目数。| -|`FOR UPDATE` | 对查询结果集所有数据上读锁，以监测其他事务对这些的并发修改。TiDB 使用[乐观事务模型](../sql/mysql-compatibility.md#事务)在语句执行期间不会检测锁冲突，在事务的提交阶段才会检测事务冲突，如果执行 Select For Update 期间，有其他事务修改相关的数据，那么包含 Select For Update 语句的事务会提交失败。| +|`FOR UPDATE` | 对查询结果集所有数据上读锁（对于在查询条件内，但是不在结果集的数据，将不会加锁，如事务启动后由其他事务写入的数据），以监测其他事务对这些的并发修改。TiDB 使用[乐观事务模型](../sql/mysql-compatibility.md#事务)在语句执行期间不会检测锁冲突，在事务的提交阶段才会检测事务冲突，如果执行 Select For Update 期间，有其他事务修改相关的数据，那么包含 Select For Update 语句的事务会提交失败。| |`LOCK IN SHARE MODE` | TiDB 出于兼容性解析这个语法，但是不做任何处理| ## Insert 语句 diff --git a/v2.1/sql/encrypted-connections.md b/v2.1/sql/encrypted-connections.md index 63824b0c2f1b..d30153b2967b 100755 --- a/v2.1/sql/encrypted-connections.md +++ b/v2.1/sql/encrypted-connections.md @@ -82,7 +82,9 @@ MySQL 5.7 及以上版本自带的客户端默认尝试使用安全连接，若 - 若要使 TiDB 服务端验证 MySQL 客户端身份，TiDB 服务端需配置 `ssl-cert`、`ssl-key`、`ssl-ca` 参数，客户端需至少指定 `--ssl-cert`、`--ssl-key` 参数。必须确保服务端配置的证书和客户端配置的证书都是由服务端配置指定的 `ssl-ca` 签发的。 - 若要进行双向身份验证，请同时满足上述要求。 -注：目前 TiDB 尚不支持强制验证客户端身份，即服务端对客户端的身份验证是可选的。若客户端在 TLS 握手时未出示自己的身份证书，也能正常建立 TLS 连接。 +> **注意：** +> +> 目前 TiDB 尚不支持强制验证客户端身份，即服务端对客户端的身份验证是可选的。若客户端在 TLS 握手时未出示自己的身份证书，也能正常建立 TLS 连接。 ## 检查当前连接是否是加密连接 diff --git a/v2.1/sql/literal-value-null-values.md b/v2.1/sql/literal-value-null-values.md index 865081433d36..d821d3f59811 100755 --- a/v2.1/sql/literal-value-null-values.md +++ b/v2.1/sql/literal-value-null-values.md @@ -7,4 +7,6 @@ category: user guide `NULL` 代表数据为空，它是大小写不敏感的，与 `\N`(大小写敏感) 同义。 -需要注意的是 `NULL` 跟 `0` 并不一样，跟空字符串 `''` 也不一样。 +> **注意：** +> +> `NULL` 跟 `0` 并不一样，跟空字符串 `''` 也不一样。 diff --git a/v2.1/sql/privilege.md b/v2.1/sql/privilege.md index 4d4fbca4f3fb..6b47393e722f 100755 --- a/v2.1/sql/privilege.md +++ b/v2.1/sql/privilege.md @@ -30,9 +30,9 @@ host 支持模糊匹配，比如： CREATE USER 'test'@'192.168.10.%'; ``` -允许 `test` 用户从 `192.168.10` 子网的任何一个主机登陆。 +允许 `test` 用户从 `192.168.10` 子网的任何一个主机登录。 -如果没有指定 host，则默认是所有 IP 均可登陆。如果没有指定密码，默认为空： +如果没有指定 host，则默认是所有 IP 均可登录。如果没有指定密码，默认为空： ```sql CREATE USER 'test'; @@ -66,7 +66,7 @@ DROP USER 'test'@'%'; sudo ./tidb-server -skip-grant-table=true ``` -这个参数启动，TiDB 会跳过权限系统，然后使用 root 登陆以后修改密码： +这个参数启动，TiDB 会跳过权限系统，然后使用 root 登录以后修改密码： ```bash mysql -h 127.0.0.1 -P 4000 -u root @@ -151,7 +151,9 @@ mysql> SELECT user,host,db FROM mysql.db WHERE user='genius'; REVOKE ALL PRIVILEGES ON `test`.* FROM 'genius'@'localhost'; ``` -> **注意**：revoke 收回权限时只做精确匹配，若找不到记录则报错。而 grant 授予权限时可以使用模糊匹配。 +> **注意：** +> +> revoke 收回权限时只做精确匹配，若找不到记录则报错。而 grant 授予权限时可以使用模糊匹配。 ```sql mysql> REVOKE ALL PRIVILEGES ON `te%`.* FROM 'genius'@'%'; @@ -258,7 +260,7 @@ DROP USER 'test'; #### 连接验证 -当客户端发送连接请求时，TiDB 服务器会对登陆操作进行验证。验证过程先检查 `mysql.user` 表，当某条记录的 User 和 Host 和连接请求匹配上了，再去验证 Password。用户身份基于两部分信息，发起连接的客户端的 Host，以及用户名 User。如果 User不为空，则用户名必须精确匹配。 +当客户端发送连接请求时，TiDB 服务器会对登录操作进行验证。验证过程先检查 `mysql.user` 表，当某条记录的 User 和 Host 和连接请求匹配上了，再去验证 Password。用户身份基于两部分信息，发起连接的客户端的 Host，以及用户名 User。如果 User不为空，则用户名必须精确匹配。 User+Host 可能会匹配 `user` 表里面多行，为了处理这种情况，`user` 表的行是排序过的，客户端连接时会依次去匹配，并使用首次匹配到的那一行做权限验证。排序是按 Host 在前，User 在后。 diff --git a/v2.1/sql/tidb-specific.md b/v2.1/sql/tidb-specific.md index fb3426e30970..542d68add338 100755 --- a/v2.1/sql/tidb-specific.md +++ b/v2.1/sql/tidb-specific.md @@ -205,7 +205,10 @@ set @@global.tidb_distsql_scan_concurrency = 10 默认值: 20000 这个变量用来设置自动切分插入/待删除数据的的 batch 大小。仅在 tidb_batch_insert 或 tidb_batch_delete 开启时有效。 -需要注意的是，当单行总数据大小很大时，20k 行总数据量数据会超过单个事务大小限制。因此在这种情况下，用户应当将其设置为一个较小的值。 + +> **注意：** +> +> 当单行总数据大小很大时，20k 行总数据量数据会超过单个事务大小限制。因此在这种情况下，用户应当将其设置为一个较小的值。 ### tidb_max_chunk_size @@ -375,7 +378,9 @@ set @@global.tidb_distsql_scan_concurrency = 10 TiDB 支持 Optimizer Hints 语法，它基于 MySQL 5.7 中介绍的类似 comment 的语法，例如 `/*+ TIDB_XX(t1, t2) */`。当 TiDB 优化器选择的不是最优查询计划时，建议使用 Optimizer Hints。 -> **注意**：MySQL 命令行客户端在 5.7.7 版本之前默认清除了 Optimizer Hints。如果需要在这些早期版本的客户端中使用 `Hint` 语法，需要在启动客户端时加上 `--comments` 选项，例如 `mysql -h 127.0.0.1 -P 4000 -uroot --comments`。 +> **注意：** +> +> MySQL 命令行客户端在 5.7.7 版本之前默认清除了 Optimizer Hints。如果需要在这些早期版本的客户端中使用 `Hint` 语法，需要在启动客户端时加上 `--comments` 选项，例如 `mysql -h 127.0.0.1 -P 4000 -uroot --comments`。 ### TIDB_SMJ(t1, t2) diff --git a/v2.1/sql/time-zone.md b/v2.1/sql/time-zone.md index 358dd981cdf8..ae50f7d57a26 100755 --- a/v2.1/sql/time-zone.md +++ b/v2.1/sql/time-zone.md @@ -37,7 +37,9 @@ mysql> SELECT @@global.time_zone, @@session.time_zone; `NOW()` 和 `CURTIME()` 的返回值都受到时区设置的影响。 -注意，只有 Timestamp 数据类型的值是受时区影响的。可以理解为， Timestamp 数据类型的实际表示使用的是 (字面值 + 时区信息)。其它时间和日期类型，比如 Datetime/Date/Time 是不包含时区信息的，所以也不受到时区变化的影响。 +> **注意：** +> +> 只有 Timestamp 数据类型的值是受时区影响的。可以理解为， Timestamp 数据类型的实际表示使用的是 (字面值 + 时区信息)。其它时间和日期类型，比如 Datetime/Date/Time 是不包含时区信息的，所以也不受到时区变化的影响。 ```sql mysql> create table t (ts timestamp, dt datetime); diff --git a/v2.1/sql/understanding-the-query-execution-plan.md b/v2.1/sql/understanding-the-query-execution-plan.md index 02d600ea172b..c36cfbfdf9fd 100755 --- a/v2.1/sql/understanding-the-query-execution-plan.md +++ b/v2.1/sql/understanding-the-query-execution-plan.md @@ -92,7 +92,11 @@ TiDB 的索引数据和表数据一样，也存放在 TiKV 中。它的 key 是 ### 范围查询 在 WHERE/HAVING/ON 条件中，TiDB 优化器会分析主键或索引键的查询返回。如数字、日期类型的比较符，如大于、小于、等于以及大于等于、小于等于，字符类型的 LIKE 符号等。 -值得注意的是，TiDB 目前只支持比较符一端是列，另一端是常量，或可以计算成某一常量的情况，类似 `year(birth_day) < 1992` 的查询条件是不能利用索引的。还要注意应尽可能使用同一类型进行比较，以避免引入额外的 cast 操作而导致不能利用索引，如 `user_id = 123456`，如果 `user_id` 是字符串，需要将 `123456` 也写成字符串常量的形式。 + +> **注意：** +> +> TiDB 目前只支持比较符一端是列，另一端是常量，或可以计算成某一常量的情况，类似 `year(birth_day) < 1992` 的查询条件是不能利用索引的。还要注意应尽可能使用同一类型进行比较，以避免引入额外的 cast 操作而导致不能利用索引，如 `user_id = 123456`，如果 `user_id` 是字符串，需要将 `123456` 也写成字符串常量的形式。 + 针对同一列的范围查询条件使用 `AND` 和 `OR` 组合后，等于对范围求交集或者并集。对于多维组合索引，可以写多个列的条件。例如对组合索引`(a, b, c)`，当 a 为等值查询时，可以继续求 b 的查询范围，当 b 也为等值查询时，可以继续求 c 的查询范围，反之如果 a 为非等值查询，则只能求 a 的范围。 ## Operator Info @@ -105,7 +109,11 @@ TableScan 表示在 KV 端对表数据进行扫描，TableReader 表示在 TiDB Index 在 TiDB 端的读取方式有两种：IndexReader 表示直接从索引中读取索引列，适用于 SQL 语句中仅引用了该索引相关的列或主键；IndexLookUp 表示从索引中过滤部分数据，仅返回这些数据的 Handle ID，通过 Handle ID 再次查找表数据，这种方式需要两次从 TiKV 获取数据。Index 的读取方式是由优化器自动选择的。 -IndexScan 是 KV 端读取索引数据的算子，和 TableScan 功能类似。table 表示 SQL 语句中的表名，如果表名被重命名，则显示重命名。index 表示索引名。range 表示扫描的数据范围。out of order 表示 index scan 是否按照顺序返回。注意在 TiDB 中，多列或者非 int 列构成的主键是当作唯一索引处理的。 +IndexScan 是 KV 端读取索引数据的算子，和 TableScan 功能类似。table 表示 SQL 语句中的表名，如果表名被重命名，则显示重命名。index 表示索引名。range 表示扫描的数据范围。out of order 表示 index scan 是否按照顺序返回。 + +> **注意：** +> +> 在 TiDB 中，多列或者非 int 列构成的主键是当作唯一索引处理的。 ### Selection @@ -129,4 +137,6 @@ TiDB 支持三种 Join 算法：Hash Join，Sort Merge Join 和 Index Look up Jo Apply 是 TiDB 用来描述子查询的一种算子，行为类似于 Nested Loop，即每次从外表中取一条数据，带入到内表的关联列中，并执行，最后根据 Apply 内联的 Join 算法进行连接计算。 -值得注意的是，Apply 一般会被查询优化器自动转换为 Join 操作。用户在编写 SQL 的过程中应尽量避免 Apply 算子的出现。 +> **注意：** +> +> Apply 一般会被查询优化器自动转换为 Join 操作。用户在编写 SQL 的过程中应尽量避免 Apply 算子的出现。 diff --git a/v2.1/sql/user-account-management.md b/v2.1/sql/user-account-management.md index ae74de4c256a..1929ed68a207 100755 --- a/v2.1/sql/user-account-management.md +++ b/v2.1/sql/user-account-management.md @@ -9,7 +9,7 @@ category: user guide TiDB 将用户账户存储在 `mysql.user` 系统表里面。每个账户由用户名和 host 作为标识。每个账户可以设置一个密码。 -通过 MySQL 客户端连接到 TiDB 服务器，通过指定的账户和密码登陆： +通过 MySQL 客户端连接到 TiDB 服务器，通过指定的账户和密码登录： ``` shell> mysql --port 4000 --user xxx --password diff --git a/v2.1/sql/util.md b/v2.1/sql/util.md index eeaee8ff95f9..46c77205bffb 100755 --- a/v2.1/sql/util.md +++ b/v2.1/sql/util.md @@ -93,4 +93,4 @@ dot xx.dot -T png -O USE db_name ``` -切换默认 Database，当 SQL 语句中的表没有显式指定的 Database 时，即使用默认 Database。 +切换需要使用的 Database 的时候，如果 SQL 语句中的表没有显式指定的 Database，即默认使用当前选定的 Database。 diff --git a/v2.1/tispark/tispark-user-guide.md b/v2.1/tispark/tispark-user-guide.md index b615fb319f07..e9ab0651b61f 100755 --- a/v2.1/tispark/tispark-user-guide.md +++ b/v2.1/tispark/tispark-user-guide.md @@ -110,7 +110,11 @@ ${SPARK_INSTALL_PATH}/jars 你可以在[这里](https://spark.apache.org/downloads.html)下载 Apache Spark。 -对于 Standalone 模式且无需 Hadoop 支持，则选择 Spark 2.1.x 且带有 Hadoop 依赖的 Pre-build with Apache Hadoop 2.x 任意版本。如有需要配合使用的 Hadoop 集群，则选择对应的 Hadoop 版本号。你也可以选择从源代码[自行构建](https://spark.apache.org/docs/2.1.0/building-spark.html)以配合官方 Hadoop 2.6 之前的版本。注意目前 TiSpark 仅支持 Spark 2.1.x 版本。 +对于 Standalone 模式且无需 Hadoop 支持，则选择 Spark 2.1.x 且带有 Hadoop 依赖的 Pre-build with Apache Hadoop 2.x 任意版本。如有需要配合使用的 Hadoop 集群，则选择对应的 Hadoop 版本号。你也可以选择从源代码[自行构建](https://spark.apache.org/docs/2.1.0/building-spark.html)以配合官方 Hadoop 2.6 之前的版本。 + +> **注意：** +> +> 目前 TiSpark 仅支持 Spark 2.1.x 版本。 如果你已经有了 Spark 二进制文件，并且当前 PATH 为 SPARKPATH，需将 TiSpark jar 包拷贝到 `${SPARKPATH}/jars` 目录下。 diff --git a/v2.1/tools/lightning/checkpoints.md b/v2.1/tools/lightning/checkpoints.md index 2e6a7880fa77..0aa5b8d63783 100755 --- a/v2.1/tools/lightning/checkpoints.md +++ b/v2.1/tools/lightning/checkpoints.md @@ -72,7 +72,9 @@ tidb-lightning-ctl --checkpoint-error-ignore=all 如果导入 `` `schema`.`table` `` 这个表曾经出错，这条命令会清除出错状态，如同没事发生过一样。传入 "all" 会对所有表进行上述操作。 -> **注意**：除非确定错误可以忽略，否则不要使用这个选项。如果错误是真实的话，可能会导致数据不完全。启用校验和 (CHECKSUM) 可以防止数据出错被忽略。 +> **注意：** +> +> 除非确定错误可以忽略，否则不要使用这个选项。如果错误是真实的话，可能会导致数据不完全。启用校验和 (CHECKSUM) 可以防止数据出错被忽略。 ### `--checkpoint-remove` diff --git a/v2.1/tools/lightning/deployment.md b/v2.1/tools/lightning/deployment.md index a113d66a57b3..cfb21b1f7a8e 100755 --- a/v2.1/tools/lightning/deployment.md +++ b/v2.1/tools/lightning/deployment.md @@ -55,7 +55,9 @@ category: tools - 1 TB+ SSD 硬盘，IOPS 越高越好 - 使用万兆网卡 -> **注意**：`tidb-lightning` 是 CPU 密集型程序，如果和其它程序混合部署，需要通过 `region-concurrency` 限制 `tidb-lightning` 的 CPU 实际占用核数，否则会影响其他程序的正常运行。建议将混合部署机器上 75% 的 CPU 分配给 `tidb-lightning`。例如，机器为 32 核，则 `tidb-lightning` 的 `region-concurrency` 可设为 24。 +> **注意：** +> +> `tidb-lightning` 是 CPU 密集型程序，如果和其它程序混合部署，需要通过 `region-concurrency` 限制 `tidb-lightning` 的 CPU 实际占用核数，否则会影响其他程序的正常运行。建议将混合部署机器上 75% 的 CPU 分配给 `tidb-lightning`。例如，机器为 32 核，则 `tidb-lightning` 的 `region-concurrency` 可设为 24。 ## 部署 TiDB-Lightning diff --git a/v2.1/tools/lightning/overview-architecture.md b/v2.1/tools/lightning/overview-architecture.md index 6cb320fca92a..df8b29fe72e1 100755 --- a/v2.1/tools/lightning/overview-architecture.md +++ b/v2.1/tools/lightning/overview-architecture.md @@ -14,7 +14,7 @@ TiDB-Lightning 主要包含两个部分: - **`tidb-lightning`**（“前端”）：主要完成适配工作，通过读取 SQL dump，在下游 TiDB 集群建表、将数据转换成键/值对 (KV 对) 发送到 `tikv-importer`、检查数据完整性等。 - **`tikv-importer`**（“后端”）：主要完成将数据导入 TiKV 集群的工作，把 `tidb-lightning` 写入的 KV 对缓存、排序、切分并导入到 TiKV 集群。 -![TiDB-Lightning 其整体架构](../../media/tidb-lightning.svg) +![TiDB-Lightning 其整体架构](/media/tidb-lightning-architecture.png) TiDB-Lightning 整体工作原理如下： diff --git a/v2.1/tools/tidb-binlog-cluster.md b/v2.1/tools/tidb-binlog-cluster.md index 9f653b9b050c..9beb5f7c16a7 100755 --- a/v2.1/tools/tidb-binlog-cluster.md +++ b/v2.1/tools/tidb-binlog-cluster.md @@ -228,7 +228,9 @@ Pump 和 Drainer 都支持部署和运行在 Intel x86-64 架构的 64 位通用 $ vi drainer_mysql_drainer.toml ``` - > **注意：** 配置文件名命名规则为 `别名_drainer.toml`，否则部署时无法找到自定义配置文件。 + > **注意：** + > + > 配置文件名命名规则为 `别名_drainer.toml`，否则部署时无法找到自定义配置文件。 db-type 设置为 "mysql"， 配置下游 MySQL 信息。 @@ -532,7 +534,9 @@ Drainer="192.168.0.13" - 启动示例 - > **注意**：如果下游为 MySQL/TiDB，为了保证数据的完整性，在 Drainer 初次启动前需要获取 initial-commit-ts 的值，并进行全量数据的备份与恢复。详细信息参见[部署 Drainer](#第-3-步部署-drainer)。 + > **注意：** + > + > 如果下游为 MySQL/TiDB，为了保证数据的完整性，在 Drainer 初次启动前需要获取 initial-commit-ts 的值，并进行全量数据的备份与恢复。详细信息参见[部署 Drainer](#第-3-步部署-drainer)。 初次启动时使用参数 `initial-commit-ts`， 命令如下： diff --git a/v2.1/tools/tidb-binlog-kafka.md b/v2.1/tools/tidb-binlog-kafka.md index 027573bd168b..613591b56bd7 100755 --- a/v2.1/tools/tidb-binlog-kafka.md +++ b/v2.1/tools/tidb-binlog-kafka.md @@ -36,7 +36,9 @@ Drainer 从 Kafka 中收集 Binlog，并按照 TiDB 中事务的提交顺序转 Kafka 集群用来存储由 Pump 写入的 Binlog 数据，并提供给 Drainer 进行读取。 -> **注**：local 版本将 Binlog 存储在文件中，最新版本则使用 Kafka 存储。 +> **注意：** +> +> local 版本将 Binlog 存储在文件中，最新版本则使用 Kafka 存储。 ## TiDB-Binlog 安装 @@ -414,7 +416,9 @@ PbReader 使用示例 点击 Grafana Logo -> 点击 Data Sources -> 点击 Add data source -> 填写 data source 信息 - > **注：**Type 选 Prometheus，URL 为 Prometheus 地址，根据实际情况添加/填写。 + > **注意：** + > + > Type 选 Prometheus，URL 为 Prometheus 地址，根据实际情况添加/填写。 + 导入 dashboard 配置文件 diff --git a/v2.1/tools/tikv-control.md b/v2.1/tools/tikv-control.md index c47fd62d3b5d..bcc2853e9930 100755 --- a/v2.1/tools/tikv-control.md +++ b/v2.1/tools/tikv-control.md @@ -33,7 +33,9 @@ $ tikv-ctl --to-hex "\252\377" AAFF ``` -> **注意**：在命令行上指定 `escaped` 形式的 key 时，需要用双引号引起来，否则 bash 会将反斜杠吃掉，导致结果错误。 +> **注意：** +> +> 在命令行上指定 `escaped` 形式的 key 时，需要用双引号引起来，否则 bash 会将反斜杠吃掉，导致结果错误。 ## 各项子命令及部分参数、选项 @@ -92,7 +94,9 @@ key: zmDB:29\000\000\377\000\374\000\000\000\000\000\000\377\000H\000\000\000\00 write cf value: start_ts: 399650105199951882 commit_ts: 399650105213059076 short_value: "\000\000\000\000\000\000\000\001" ``` -> **注意**：该命令中，key 同样需要是 escaped 形式的 raw key。 +> **注意：** +> +> 该命令中，key 同样需要是 escaped 形式的 raw key。 ### 打印某个 key 的值 @@ -141,8 +145,8 @@ $ tikv-ctl --db /path/to/tikv/db tombstone -p 127.0.0.1:2379 -r 2 success! ``` -> **注意**： -> +> **注意：** +> > - `-p` 选项的参数指定 PD 的 endpoints，它没有 `http` 前缀。 > - **这个命令只支持本地模式**。需要指定 PD 的 endpoints 的原因是需要询问 PD 是否可以安全地 tombstone。因此，在 tombstone 之前往往还需要在 `pd-ctl` 中把该 Region 在这台机器上的对应 Peer 拿掉。 @@ -157,7 +161,9 @@ $ tikv-ctl --host 127.0.0.1:21061 consistency-check -r 2 DebugClient::check_region_consistency: RpcFailure(RpcStatus { status: Unknown, details: Some("StringError(\"Leader is on store 1\")") }) ``` -需要注意的是，即使这个命令返回了成功，也需要去检查是否有 TiKV panic 了，因为这个命令只是给 Leader 发起一个 Consistency-check 的 propose，至于整个检查流程成功与否并不能在客户端知道。 +> **注意：** +> +> 即使这个命令返回了成功，也需要去检查是否有 TiKV panic 了，因为这个命令只是给 Leader 发起一个 Consistency-check 的 propose，至于整个检查流程成功与否并不能在客户端知道。 ### Dump snapshot meta @@ -220,8 +226,8 @@ $ tikv-ctl --db /path/to/tikv/db unsafe-recover remove-fail-stores -s 4,5 --all- 之后启动 TiKV，这些 Region 便可以以剩下的健康的副本继续提供服务了。这个命令常用于多个 TiKV store 损坏或被删除的情况。 -> **注意**： -> +> **注意：** +> > - **这个命令只支持本地模式**。在运行成功后，会打印 `success!`。 > - 一般来说，需要使用这个命令的地方，对于指定 Region 的 peers 所在的每个 store，均须运行这个命令。 > - 如果使用 `--all-regions`，通常需要在集群剩余所有健康的 store 上执行这个命令。 @@ -237,8 +243,8 @@ $ tikv-ctl --db /path/to/tikv/db recover-mvcc -r 1001,1002 -p 127.0.0.1:2379 success! ``` -> **注意**： -> +> **注意：** +> > - **这个命令只支持本地模式**。在运行成功后，会打印 `success!`。 > - `-p` 选项指定 PD 的 endpoint，不使用 `http` 前缀，用于查询指定的 `region_id` 是否有效。 > - 对于指定 Region 的 peers 所在的每个 store，均须执行这个命令。