diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 5cf166b04d6a..7947102b65b4 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -19,9 +19,10 @@ By default, **CHOOSE MASTER ONLY** so your changes will be applied to the next T For details, see [tips for choosing the affected versions (in Chinese)](https://github.com/pingcap/docs-cn/blob/master/CONTRIBUTING.md#版本选择指南). - [ ] master (the latest development version) +- [ ] v7.3 (TiDB 7.3 versions) +- [ ] v7.2 (TiDB 7.2 versions) - [ ] v7.1 (TiDB 7.1 versions) - [ ] v7.0 (TiDB 7.0 versions) -- [ ] v6.6 (TiDB 6.6 versions) - [ ] v6.5 (TiDB 6.5 versions) - [ ] v6.1 (TiDB 6.1 versions) - [ ] v5.4 (TiDB 5.4 versions) diff --git a/.github/workflows/dispatch.yml b/.github/workflows/dispatch.yml index e19a11e87a1b..35c5683680f5 100644 --- a/.github/workflows/dispatch.yml +++ b/.github/workflows/dispatch.yml @@ -6,7 +6,18 @@ on: - ".github/**" branches: - master - - release-* + - release-7.2 + - release-7.1 + - release-7.0 + - release-6.5 + - release-6.1 + - release-5.4 + - release-5.3 + - release-5.2 + - release-5.1 + - release-5.0 + - release-4.0 + - release-3.0 jobs: trigger: diff --git a/.github/workflows/link-fail-fast.yaml b/.github/workflows/link-fail-fast.yaml index 070286920b9a..146f4d0a21f0 100644 --- a/.github/workflows/link-fail-fast.yaml +++ b/.github/workflows/link-fail-fast.yaml @@ -23,7 +23,7 @@ jobs: - name: Link Checker if: ${{ steps.changed-files.outputs.all_changed_files }} - uses: lycheeverse/lychee-action@v1.5.0 + uses: lycheeverse/lychee-action@v1.6.1 with: fail: true args: -E --exclude-mail -i -n -t 45 -- '${{ steps.changed-files.outputs.all_changed_files }}' diff --git a/.github/workflows/link.yaml b/.github/workflows/link.yaml index 34a6aef94e40..52ca7236df81 100644 --- a/.github/workflows/link.yaml +++ b/.github/workflows/link.yaml @@ -17,7 +17,7 @@ jobs: curl https://raw.githubusercontent.com/pingcap/docs/master/.lycheeignore --output .lycheeignore - name: Check Links - uses: lycheeverse/lychee-action@v1.5.0 + uses: lycheeverse/lychee-action@v1.6.1 with: # For parameter description, see https://github.com/lycheeverse/lychee#commandline-parameters args: -E --exclude-mail -v -i -n -t 45 -- **/*.md *.md diff --git a/.github/workflows/media.yml b/.github/workflows/media.yml index 640577a27a58..c504b945e513 100644 --- a/.github/workflows/media.yml +++ b/.github/workflows/media.yml @@ -11,7 +11,7 @@ jobs: name: Upload media files runs-on: ubuntu-latest steps: - - uses: actions/checkout@master + - uses: actions/checkout@v3 with: # Must use at least depth 2! fetch-depth: 2 diff --git a/.github/workflows/rebase.yml b/.github/workflows/rebase.yml index 4e495b30a061..73cce3c0fa89 100644 --- a/.github/workflows/rebase.yml +++ b/.github/workflows/rebase.yml @@ -9,7 +9,7 @@ jobs: runs-on: ubuntu-latest steps: - name: Checkout the latest code - uses: actions/checkout@v2 + uses: actions/checkout@v3 with: token: ${{ secrets.REBASE_SECRET_KEY }} fetch-depth: 0 # otherwise, you will fail to push refs to dest repo diff --git a/OWNERS b/OWNERS new file mode 100644 index 000000000000..ec95e7e30cb6 --- /dev/null +++ b/OWNERS @@ -0,0 +1,54 @@ +# See the OWNERS docs at https://go.k8s.io/owners +approvers: + - breezewish + - CaitinChen + - CharLotteiu + - cofyc + - csuzhangxc + - DanielZhangQD + - dcalvin + - dragonly + - en-jin19 + - hfxsd + - jackysp + - kissmydb + - lance6716 + - lichunzhu + - lilin90 + - Liuxiaozhen12 + - morgo + - Oreoxmt + - overvenus + - qiancai + - queenypingcap + - ran-huang + - shichun-0415 + - SunRunAway + - tangenta + - TomShawn + - toutdesuite + - WangXiangUSTC + - yikeke + - YiniXu9506 +reviewers: + - 3pointer + - amyangfei + - anotherrachel + - aylei + - crazycs520 + - dveeden + - ericsyh + - glkappe + - GMHDBJD + - Icemap + - Joyinqin + - junlan-zhang + - KanShiori + - lucklove + - lysu + - ngaut + - superlzs0476 + - tiancaiamao + - weekface + - Yisaer + - zimulala diff --git a/README.md b/README.md index d5e1b71d434c..f1d6530a1059 100644 --- a/README.md +++ b/README.md @@ -13,6 +13,8 @@ | 文档仓库 branch | 对应 TiDB 文档版本 | |:---------|:----------| | [`master`](https://github.com/pingcap/docs-cn/tree/master) | dev 最新开发版 | +| [`release-7.2`](https://github.com/pingcap/docs-cn/tree/release-7.2) | 7.2 开发里程碑版 (DMR) | +| [`release-7.1`](https://github.com/pingcap/docs-cn/tree/release-7.1) | 7.1 长期支持版 (LTS) | | [`release-7.0`](https://github.com/pingcap/docs-cn/tree/release-7.0) | 7.0 开发里程碑版 (DMR) | | [`release-6.6`](https://github.com/pingcap/docs-cn/tree/release-6.6) | 6.6 开发里程碑版 (DMR) | | [`release-6.5`](https://github.com/pingcap/docs-cn/tree/release-6.5) | 6.5 长期支持版 (LTS) | diff --git a/TOC.md b/TOC.md index 0f9e051ce03a..ee321dd024b1 100644 --- a/TOC.md +++ b/TOC.md @@ -4,11 +4,12 @@ - [文档中心](https://docs.pingcap.com/zh) - 关于 TiDB - [TiDB 简介](/overview.md) - - [TiDB 7.0 Release Notes](/releases/release-7.0.0.md) + - [TiDB 7.2 Release Notes](/releases/release-7.2.0.md) - [功能概览](/basic-features.md) - [与 MySQL 的兼容性](/mysql-compatibility.md) - [使用限制](/tidb-limitations.md) - [荣誉列表](/credits.md) + - [路线图](/tidb-roadmap.md) - 快速上手 - [快速上手 TiDB](/quick-start-with-tidb.md) - [快速上手 HTAP](/quick-start-with-htap.md) @@ -17,7 +18,7 @@ - 应用开发 - [概览](/develop/dev-guide-overview.md) - 快速开始 - - [使用 TiDB Cloud (Serverless Tier) 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md) + - [使用 TiDB Serverless 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md) - [使用 TiDB 的增删改查 SQL](/develop/dev-guide-tidb-crud-sql.md) - 示例程序 - [Golang](/develop/dev-guide-sample-application-golang.md) @@ -92,7 +93,7 @@ - [跨机房部署拓扑结构](/geo-distributed-deployment-topology.md) - [混合部署拓扑结构](/hybrid-deployment-topology.md) - 安装与启动 - - [使用 TiUP 部署（推荐）](/production-deployment-using-tiup.md) + - [使用 TiUP 部署](/production-deployment-using-tiup.md) - [在 Kubernetes 上部署](/tidb-in-kubernetes.md) - [验证集群状态](/post-installation-check.md) - 测试集群性能 @@ -101,7 +102,8 @@ - [对 TiDB 进行 CH-benCHmark 测试](/benchmark/benchmark-tidb-using-ch.md) - 数据迁移 - [数据迁移概述](/migration-overview.md) - - [迁移工具](/migration-tools.md) + - [数据迁移工具](/migration-tools.md) + - [数据导入最佳实践](/tidb-lightning/data-import-best-practices.md) - 数据迁移场景 - [从 Aurora 迁移数据到 TiDB](/migrate-aurora-to-tidb.md) - [从小数据量 MySQL 迁移数据到 TiDB](/migrate-small-mysql-to-tidb.md) @@ -125,8 +127,9 @@ - [与 Apache Kafka 和 Apache Flink 进行数据集成](/replicate-data-to-kafka.md) - 运维操作 - 升级 TiDB 版本 - - [使用 TiUP 升级（推荐）](/upgrade-tidb-using-tiup.md) + - [使用 TiUP 升级](/upgrade-tidb-using-tiup.md) - [使用 TiDB Operator](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/upgrade-a-tidb-cluster) + - [平滑升级 TiDB](/smooth-upgrade-tidb.md) - [TiFlash v6.2 升级帮助](/tiflash-620-upgrade-guide.md) - 扩缩容 - [使用 TiUP（推荐）](/scale-tidb-using-tiup.md) @@ -151,7 +154,8 @@ - BR 特性 - [自动调节](/br/br-auto-tune.md) - [批量建表](/br/br-batch-create-table.md) - - [断点备份](/br/br-checkpoint.md) + - [断点备份](/br/br-checkpoint-backup.md) + - [断点恢复](/br/br-checkpoint-restore.md) - [使用 Dumpling 和 TiDB Lightning 备份与恢复](/backup-and-restore-using-dumpling-lightning.md) - [备份与恢复 RawKV](/br/rawkv-backup-and-restore.md) - [增量备份与恢复](/br/br-incremental-guide.md) @@ -260,6 +264,7 @@ - [Optimizer Hints](/optimizer-hints.md) - [执行计划管理](/sql-plan-management.md) - [优化规则及表达式下推的黑名单](/blocklist-control-plan.md) + - [Optimizer Fix Controls](/optimizer-fix-controls.md) - 教程 - [单区域多 AZ 部署](/multi-data-centers-in-one-city-deployment.md) - [双区域多 AZ 部署](/three-data-centers-in-two-cities-deployment.md) @@ -383,51 +388,7 @@ - [tiup-cluster 部署运维生产集群](/tiup/tiup-cluster.md) - [tiup-mirror 定制离线镜像](/tiup/tiup-mirror.md) - [tiup-bench 进行 TPCC/TPCH 压力测试](/tiup/tiup-bench.md) - - PingCAP Clinic 诊断服务 - - [概述](/clinic/clinic-introduction.md) - - [快速上手](/clinic/quick-start-with-clinic.md) - - [使用 PingCAP Clinic 诊断集群](/clinic/clinic-user-guide-for-tiup.md) - - [使用 PingCAP Clinic 生成诊断报告](/clinic/clinic-report.md) - - [采集 SQL 查询计划信息](/clinic/clinic-collect-sql-query-plan.md) - - [数据采集说明](/clinic/clinic-data-instruction-for-tiup.md) - [TiDB Operator](/tidb-operator-overview.md) - - [Dumpling](/dumpling-overview.md) - - TiDB Lightning - - [概述](/tidb-lightning/tidb-lightning-overview.md) - - [快速上手](/get-started-with-tidb-lightning.md) - - [部署 TiDB Lightning](/tidb-lightning/deploy-tidb-lightning.md) - - [目标数据库要求](/tidb-lightning/tidb-lightning-requirements.md) - - 数据源 - - [文件匹配规则](/tidb-lightning/tidb-lightning-data-source.md) - - [CSV](/tidb-lightning/tidb-lightning-data-source.md#csv) - - [SQL](/tidb-lightning/tidb-lightning-data-source.md#sql) - - [Parquet](/tidb-lightning/tidb-lightning-data-source.md#parquet) - - [自定义文件匹配](/tidb-lightning/tidb-lightning-data-source.md#自定义文件匹配) - - Physical Import Mode - - [概述](/tidb-lightning/tidb-lightning-physical-import-mode.md) - - [必要条件及限制](/tidb-lightning/tidb-lightning-physical-import-mode.md#必要条件及限制) - - [配置及使用](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md) - - [冲突检测](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#冲突数据检测) - - [性能调优](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#性能调优) - - Logical Import Mode - - [概述](/tidb-lightning/tidb-lightning-logical-import-mode.md) - - [必要条件及限制](/tidb-lightning/tidb-lightning-logical-import-mode.md#必要条件) - - [配置及使用](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md) - - [冲突检测](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md#冲突数据检测) - - [性能调优](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md#性能调优) - - [前置检查](/tidb-lightning/tidb-lightning-prechecks.md) - - [表库过滤](/table-filter.md) - - [断点续传](/tidb-lightning/tidb-lightning-checkpoints.md) - - [并行导入](/tidb-lightning/tidb-lightning-distributed-import.md) - - [可容忍错误](/tidb-lightning/tidb-lightning-error-resolution.md) - - [故障处理](/tidb-lightning/troubleshoot-tidb-lightning.md) - - 参考手册 - - [完整配置文件](/tidb-lightning/tidb-lightning-configuration.md) - - [命令行参数](/tidb-lightning/tidb-lightning-command-line-full.md) - - [监控告警](/tidb-lightning/monitor-tidb-lightning.md) - - [Web 界面](/tidb-lightning/tidb-lightning-web-interface.md) - - [FAQ](/tidb-lightning/tidb-lightning-faq.md) - - [术语表](/tidb-lightning/tidb-lightning-glossary.md) - TiDB Data Migration - [关于 Data Migration](/dm/dm-overview.md) - [架构简介](/dm/dm-arch.md) @@ -486,33 +447,33 @@ - [导出和导入集群的数据源和任务配置](/dm/dm-export-import-config.md) - [处理告警](/dm/dm-handle-alerts.md) - [日常巡检](/dm/dm-daily-check.md) - - 参考手册 - - 架构组件 - - [DM-worker 说明](/dm/dm-worker-intro.md) - - [安全模式](/dm/dm-safe-mode.md) - - [Relay Log](/dm/relay-log.md) - - [DDL 特殊处理说明](/dm/dm-ddl-compatible.md) - - 运行机制 - - [DML 同步机制](/dm/dm-dml-replication-logic.md) - - 命令行 - - [DM-master & DM-worker](/dm/dm-command-line-flags.md) - - 配置文件 - - [概述](/dm/dm-config-overview.md) - - [数据源配置](/dm/dm-source-configuration-file.md) - - [迁移任务配置](/dm/task-configuration-file-full.md) - - [DM-master 配置](/dm/dm-master-configuration-file.md) - - [DM-worker 配置](/dm/dm-worker-configuration-file.md) - - [Table Selector](/dm/table-selector.md) - - [OpenAPI](/dm/dm-open-api.md) - - [兼容性目录](/dm/dm-compatibility-catalog.md) - - 安全 - - [为 DM 的连接开启加密传输](/dm/dm-enable-tls.md) - - [生成自签名证书](/dm/dm-generate-self-signed-certificates.md) - - 监控告警 - - [监控指标](/dm/monitor-a-dm-cluster.md) - - [告警信息](/dm/dm-alert-rules.md) - - [错误码](/dm/dm-error-handling.md#常见故障处理方法) - - [术语表](/dm/dm-glossary.md) + - 参考手册 + - 架构组件 + - [DM-worker 说明](/dm/dm-worker-intro.md) + - [安全模式](/dm/dm-safe-mode.md) + - [Relay Log](/dm/relay-log.md) + - [DDL 特殊处理说明](/dm/dm-ddl-compatible.md) + - 运行机制 + - [DML 同步机制](/dm/dm-dml-replication-logic.md) + - 命令行 + - [DM-master & DM-worker](/dm/dm-command-line-flags.md) + - 配置文件 + - [概述](/dm/dm-config-overview.md) + - [数据源配置](/dm/dm-source-configuration-file.md) + - [迁移任务配置](/dm/task-configuration-file-full.md) + - [DM-master 配置](/dm/dm-master-configuration-file.md) + - [DM-worker 配置](/dm/dm-worker-configuration-file.md) + - [Table Selector](/dm/table-selector.md) + - [OpenAPI](/dm/dm-open-api.md) + - [兼容性目录](/dm/dm-compatibility-catalog.md) + - 安全 + - [为 DM 的连接开启加密传输](/dm/dm-enable-tls.md) + - [生成自签名证书](/dm/dm-generate-self-signed-certificates.md) + - 监控告警 + - [监控指标](/dm/monitor-a-dm-cluster.md) + - [告警信息](/dm/dm-alert-rules.md) + - [错误码](/dm/dm-error-handling.md#常见故障处理方法) + - [术语表](/dm/dm-glossary.md) - 使用示例 - [使用 DM 迁移数据](/dm/migrate-data-using-dm.md) - [快速创建迁移任务](/dm/quick-start-create-task.md) @@ -521,6 +482,43 @@ - [常见问题](/dm/dm-faq.md) - [错误处理及恢复](/dm/dm-error-handling.md) - [版本发布历史](/dm/dm-release-notes.md) + - TiDB Lightning + - [概述](/tidb-lightning/tidb-lightning-overview.md) + - [快速上手](/get-started-with-tidb-lightning.md) + - [部署 TiDB Lightning](/tidb-lightning/deploy-tidb-lightning.md) + - [目标数据库要求](/tidb-lightning/tidb-lightning-requirements.md) + - 数据源 + - [文件匹配规则](/tidb-lightning/tidb-lightning-data-source.md) + - [CSV](/tidb-lightning/tidb-lightning-data-source.md#csv) + - [SQL](/tidb-lightning/tidb-lightning-data-source.md#sql) + - [Parquet](/tidb-lightning/tidb-lightning-data-source.md#parquet) + - [自定义文件匹配](/tidb-lightning/tidb-lightning-data-source.md#自定义文件匹配) + - 物理导入模式 + - [概述](/tidb-lightning/tidb-lightning-physical-import-mode.md) + - [必要条件及限制](/tidb-lightning/tidb-lightning-physical-import-mode.md#必要条件及限制) + - [配置及使用](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md) + - [冲突检测](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#冲突数据检测) + - [性能调优](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#性能调优) + - 逻辑导入模式 + - [概述](/tidb-lightning/tidb-lightning-logical-import-mode.md) + - [必要条件及限制](/tidb-lightning/tidb-lightning-logical-import-mode.md#必要条件) + - [配置及使用](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md) + - [冲突检测](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md#冲突数据检测) + - [性能调优](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md#性能调优) + - [前置检查](/tidb-lightning/tidb-lightning-prechecks.md) + - [表库过滤](/table-filter.md) + - [断点续传](/tidb-lightning/tidb-lightning-checkpoints.md) + - [并行导入](/tidb-lightning/tidb-lightning-distributed-import.md) + - [可容忍错误](/tidb-lightning/tidb-lightning-error-resolution.md) + - [故障处理](/tidb-lightning/troubleshoot-tidb-lightning.md) + - 参考手册 + - [完整配置文件](/tidb-lightning/tidb-lightning-configuration.md) + - [命令行参数](/tidb-lightning/tidb-lightning-command-line-full.md) + - [监控告警](/tidb-lightning/monitor-tidb-lightning.md) + - [Web 界面](/tidb-lightning/tidb-lightning-web-interface.md) + - [FAQ](/tidb-lightning/tidb-lightning-faq.md) + - [术语表](/tidb-lightning/tidb-lightning-glossary.md) + - [Dumpling](/dumpling-overview.md) - TiCDC - [概述](/ticdc/ticdc-overview.md) - [安装部署与集群运维](/ticdc/deploy-ticdc.md) @@ -533,8 +531,10 @@ - [管理 Changefeed](/ticdc/ticdc-manage-changefeed.md) - [日志过滤器](/ticdc/ticdc-filter.md) - [双向复制](/ticdc/ticdc-bidirectional-replication.md) + - [单行数据正确性校验](/ticdc/ticdc-integrity-check.md) - 监控告警 - - [监控指标](/ticdc/monitor-ticdc.md) + - [基本监控指标](/ticdc/ticdc-summary-monitor.md) + - [详细监控指标](/ticdc/monitor-ticdc.md) - [报警规则](/ticdc/ticdc-alert-rules.md) - 参考指南 - [架构设计与原理](/ticdc/ticdc-architecture.md) @@ -547,7 +547,9 @@ - [TiCDC CSV Protocol](/ticdc/ticdc-csv.md) - [TiCDC Open API v2](/ticdc/ticdc-open-api-v2.md) - [TiCDC Open API v1](/ticdc/ticdc-open-api.md) - - [Storage sink 消费程序编写指引](/ticdc/ticdc-storage-consumer-dev-guide.md) + - TiCDC 数据消费 + - [基于 Avro 的 TiCDC 行数据 Checksum 校验](/ticdc/ticdc-avro-checksum-verification.md) + - [Storage sink 消费程序编写指引](/ticdc/ticdc-storage-consumer-dev-guide.md) - [兼容性](/ticdc/ticdc-compatibility.md) - [故障处理](/ticdc/troubleshoot-ticdc.md) - [常见问题解答](/ticdc/ticdc-faq.md) @@ -572,6 +574,21 @@ - [故障诊断](/tidb-binlog/troubleshoot-tidb-binlog.md) - [常见错误修复](/tidb-binlog/handle-tidb-binlog-errors.md) - [FAQ](/tidb-binlog/tidb-binlog-faq.md) + - PingCAP Clinic 诊断服务 + - [概述](/clinic/clinic-introduction.md) + - [快速上手](/clinic/quick-start-with-clinic.md) + - [使用 PingCAP Clinic 诊断集群](/clinic/clinic-user-guide-for-tiup.md) + - [使用 PingCAP Clinic 生成诊断报告](/clinic/clinic-report.md) + - [采集 SQL 查询计划信息](/clinic/clinic-collect-sql-query-plan.md) + - [数据采集说明](/clinic/clinic-data-instruction-for-tiup.md) + - TiSpark + - [TiSpark 用户指南](/tispark-overview.md) + - sync-diff-inspector + - [概述](/sync-diff-inspector/sync-diff-inspector-overview.md) + - [不同库名或表名的数据校验](/sync-diff-inspector/route-diff.md) + - [分库分表场景下的数据校验](/sync-diff-inspector/shard-diff.md) + - [TiDB 主从集群的数据校验](/sync-diff-inspector/upstream-downstream-diff.md) + - [基于 DM 同步场景下的数据校验](/sync-diff-inspector/dm-diff.md) - TiUniManager - [概述](/tiunimanager/tiunimanager-overview.md) - [安装和运维](/tiunimanager/tiunimanager-install-and-maintain.md) @@ -589,14 +606,6 @@ - [v1.0.2](/tiunimanager/tiunimanager-release-1.0.2.md) - [v1.0.1](/tiunimanager/tiunimanager-release-1.0.1.md) - [v1.0.0](/tiunimanager/tiunimanager-release-1.0.0.md) - - sync-diff-inspector - - [概述](/sync-diff-inspector/sync-diff-inspector-overview.md) - - [不同库名或表名的数据校验](/sync-diff-inspector/route-diff.md) - - [分库分表场景下的数据校验](/sync-diff-inspector/shard-diff.md) - - [TiDB 主从集群的数据校验](/sync-diff-inspector/upstream-downstream-diff.md) - - [基于 DM 同步场景下的数据校验](/sync-diff-inspector/dm-diff.md) - - TiSpark - - [TiSpark 用户指南](/tispark-overview.md) - 参考指南 - 架构 - [概述](/tidb-architecture.md) @@ -623,6 +632,7 @@ - [TiFlash 数据落盘](/tiflash/tiflash-spill-disk.md) - [TiFlash 数据校验](/tiflash/tiflash-data-validation.md) - [TiFlash 兼容性说明](/tiflash/tiflash-compatibility.md) + - [TiFlash Pipeline Model 执行模型](/tiflash/tiflash-pipeline-model.md) - [系统变量](/system-variables.md) - 配置文件参数 - [tidb-server](/tidb-configuration-file.md) @@ -683,7 +693,9 @@ - [`ADMIN CHECKSUM TABLE`](/sql-statements/sql-statement-admin-checksum-table.md) - [`ADMIN CHECK [TABLE|INDEX]`](/sql-statements/sql-statement-admin-check-table-index.md) - [`ADMIN CLEANUP`](/sql-statements/sql-statement-admin-cleanup.md) + - [`ADMIN PAUSE DDL`](/sql-statements/sql-statement-admin-pause-ddl.md) - [`ADMIN RECOVER INDEX`](/sql-statements/sql-statement-admin-recover.md) + - [`ADMIN RESUME DDL`](/sql-statements/sql-statement-admin-resume-ddl.md) - [`ADMIN SHOW DDL [JOBS|QUERIES]`](/sql-statements/sql-statement-admin-show-ddl.md) - [`ADMIN SHOW TELEMETRY`](/sql-statements/sql-statement-admin-show-telemetry.md) - [`ALTER DATABASE`](/sql-statements/sql-statement-alter-database.md) @@ -698,8 +710,8 @@ - [`BACKUP`](/sql-statements/sql-statement-backup.md) - [`BATCH`](/sql-statements/sql-statement-batch.md) - [`BEGIN`](/sql-statements/sql-statement-begin.md) - - [`CANCEL LOAD DATA` 和 `DROP LOAD DATA`](/sql-statements/sql-statement-operate-load-data-job.md) - [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md) + - [`CANCEL IMPORT JOB`](/sql-statements/sql-statement-cancel-import-job.md) - [`CHANGE COLUMN`](/sql-statements/sql-statement-change-column.md) - [`CHANGE DRAINER`](/sql-statements/sql-statement-change-drainer.md) - [`CHANGE PUMP`](/sql-statements/sql-statement-change-pump.md) @@ -743,6 +755,7 @@ - [`FLUSH TABLES`](/sql-statements/sql-statement-flush-tables.md) - [`GRANT `](/sql-statements/sql-statement-grant-privileges.md) - [`GRANT `](/sql-statements/sql-statement-grant-role.md) + - [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) - [`INSERT`](/sql-statements/sql-statement-insert.md) - [`KILL [TIDB]`](/sql-statements/sql-statement-kill.md) - [`LOAD DATA`](/sql-statements/sql-statement-load-data.md) @@ -789,10 +802,10 @@ - [`SHOW ERRORS`](/sql-statements/sql-statement-show-errors.md) - [`SHOW [FULL] FIELDS FROM`](/sql-statements/sql-statement-show-fields-from.md) - [`SHOW GRANTS`](/sql-statements/sql-statement-show-grants.md) + - [`SHOW IMPORT JOB`](/sql-statements/sql-statement-show-import-job.md) - [`SHOW INDEX [FROM|IN]`](/sql-statements/sql-statement-show-index.md) - [`SHOW INDEXES [FROM|IN]`](/sql-statements/sql-statement-show-indexes.md) - [`SHOW KEYS [FROM|IN]`](/sql-statements/sql-statement-show-keys.md) - - [`SHOW LOAD DATA`](/sql-statements/sql-statement-show-load-data.md) - [`SHOW MASTER STATUS`](/sql-statements/sql-statement-show-master-status.md) - [`SHOW PLACEMENT`](/sql-statements/sql-statement-show-placement.md) - [`SHOW PLACEMENT FOR`](/sql-statements/sql-statement-show-placement-for.md) @@ -957,6 +970,7 @@ - [使用示例](/dashboard/dashboard-diagnostics-usage.md) - [监控指标页面](/dashboard/dashboard-monitoring.md) - [日志搜索页面](/dashboard/dashboard-log-search.md) + - [资源管控页面](/dashboard/dashboard-resource-manager.md) - 实例性能分析 - [手动分析页面](/dashboard/dashboard-profiling.md) - [持续分析页面](/dashboard/continuous-profiling.md) @@ -967,6 +981,8 @@ - [遥测](/telemetry.md) - [错误码](/error-codes.md) - [通过拓扑 label 进行副本调度](/schedule-replicas-by-topology-labels.md) + - 内部组件介绍 + - [TiDB 后端任务分布式并行执行框架](/tidb-distributed-execution-framework.md) - 常见问题解答 (FAQ) - [FAQ 汇总](/faq/faq-overview.md) - [产品 FAQ](/faq/tidb-faq.md) @@ -984,11 +1000,17 @@ - [版本发布时间线](/releases/release-timeline.md) - [TiDB 版本规则](/releases/versioning.md) - [TiDB 离线包](/binary-package.md) + - v7.2 + - [7.2.0-DMR](/releases/release-7.2.0.md) + - v7.1 + - [7.1.0](/releases/release-7.1.0.md) - v7.0 - [7.0.0-DMR](/releases/release-7.0.0.md) - v6.6 - [6.6.0-DMR](/releases/release-6.6.0.md) - v6.5 + - [6.5.3](/releases/release-6.5.3.md) + - [6.5.2](/releases/release-6.5.2.md) - [6.5.1](/releases/release-6.5.1.md) - [6.5.0](/releases/release-6.5.0.md) - v6.4 @@ -998,6 +1020,7 @@ - v6.2 - [6.2.0-DMR](/releases/release-6.2.0.md) - v6.1 + - [6.1.6](/releases/release-6.1.6.md) - [6.1.5](/releases/release-6.1.5.md) - [6.1.4](/releases/release-6.1.4.md) - [6.1.3](/releases/release-6.1.3.md) diff --git a/_index.md b/_index.md index f1c761a72849..df0f0f1dd220 100644 --- a/_index.md +++ b/_index.md @@ -43,7 +43,7 @@ hide_commit: true [使用 TiUP 部署 TiDB（推荐）](https://docs.pingcap.com/zh/tidb/dev/production-deployment-using-tiup) -[在 Kubernetes 上部署 TiDB](https://docs.pingcap.com/zh/tidb/dev/tidb-in-kubernetes) +[在 Kubernetes 上部署 TiDB](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable) @@ -101,33 +101,33 @@ hide_commit: true [TiUP](https://docs.pingcap.com/zh/tidb/dev/tiup-overview) -[Dumpling](https://docs.pingcap.com/zh/tidb/dev/dumpling-overview) +[TiDB Operator](https://docs.pingcap.com/zh/tidb/dev/tidb-operator-overview) -[TiDB Lightning](https://docs.pingcap.com/zh/tidb/dev/tidb-lightning-overview) +[TiDB Data Migration (DM)](https://docs.pingcap.com/zh/tidb/dev/dm-overview) -[Data Migration](https://docs.pingcap.com/zh/tidb/dev/dm-overview) +[TiDB Lightning](https://docs.pingcap.com/zh/tidb/dev/tidb-lightning-overview) -[Backup & Restore (BR)](https://docs.pingcap.com/zh/tidb/dev/backup-and-restore-overview) +[Dumpling](https://docs.pingcap.com/zh/tidb/dev/dumpling-overview) [TiCDC](https://docs.pingcap.com/zh/tidb/dev/ticdc-overview) +[Backup & Restore (BR)](https://docs.pingcap.com/zh/tidb/dev/backup-and-restore-overview) + [PingCAP Clinic](https://docs.pingcap.com/zh/tidb/dev/clinic-introduction) [TiUniManager](https://docs.pingcap.com/zh/tidb/dev/tiunimanager-overview) -[TiDB Operator](https://docs.pingcap.com/zh/tidb/dev/tidb-operator-overview) - -[TiSpark](https://docs.pingcap.com/zh/tidb/dev/tispark-overview) - +[TiDB 路线图](https://docs.pingcap.com/zh/tidb/dev/tidb-roadmap) + [TiDB 配置文件参数](https://docs.pingcap.com/zh/tidb/dev/tidb-configuration-file) [TiDB 命令行参数](https://docs.pingcap.com/zh/tidb/dev/command-line-flags-for-tidb-configuration) -[TiDB Control](https://docs.pingcap.com/zh/tidb/dev/tidb-control) +[TiDB Control](https://docs.pingcap.com/zh/tidb/dev/tidb-control) [系统变量](https://docs.pingcap.com/zh/tidb/dev/system-variables) diff --git a/alert-rules.md b/alert-rules.md index 18065dd1e592..84f5145314c0 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -44,11 +44,11 @@ aliases: ['/docs-cn/dev/alert-rules/','/docs-cn/dev/reference/alert-rules/'] * 规则描述： - TiDB 访问 TiKV 时发生了 Region 错误。如果在 10 分钟之内该错误多于 6000 次，则报警。 + TiDB server 根据自己的缓存信息访问 TiKV 的 Region leader。如果 Region leader 有变化或者当前 TiKV 的 Region 信息与 TiDB 的缓存不一致，就会产生 Region 缓存错误。如果在 10 分钟之内该错误多于 6000 次，则报警。 * 处理方法： - 查看 TiKV 的监控状态。 + 查看 [**TiKV-Details** > **Cluster** 面板](/grafana-tikv-dashboard.md#cluster)，检查 leader 的分布是否均衡。 #### `TiDB_domain_load_schema_total` @@ -425,8 +425,10 @@ aliases: ['/docs-cn/dev/alert-rules/','/docs-cn/dev/reference/alert-rules/'] * 处理方法： - * 检查 store 性能是否异常 - * 调大 TiKV `raftstore.inspect-interval` 参数，提高延迟检测的超时上限 + * 观察 [**TiKV-Details** > **PD** 面板](/grafana-tikv-dashboard.md#pd)，查看 Store Slow Score 监控指标，找出指标数值超过 80 的节点，该节点即为被检测到的慢节点。 + * 观察 [**TiKV-Details** > **Raft IO** 面板](/grafana-tikv-dashboard.md#raft-io)，查看延迟是否升高。如果延迟很高，表明磁盘可能存在瓶颈。 + * 调大 TiKV [`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval) 参数，提高延迟检测的超时上限。 + * 如果需要进一步分析报警的 TiKV 节点的性能问题，找到优化方法，可以参考[性能分析和优化方法](/performance-tuning-methods.md#storage-async-write-durationstore-duration-和-apply-duration)。 ## TiKV 报警规则 @@ -494,9 +496,9 @@ aliases: ['/docs-cn/dev/alert-rules/','/docs-cn/dev/reference/alert-rules/'] * 处理方法： - 1. 观察 Raft Propose 监控，看这个报警的 TiKV 节点是否明显有比其他 TiKV 高很多。如果是，表明这个 TiKV 上有热点，需要检查热点调度是否能正常工作。 - 2. 观察 Raft IO 监控，看延迟是否升高。如果延迟很高，表明磁盘可能有瓶颈。一个能缓解但不怎么安全的办法是将 `sync-log` 改成 `false`。 - 3. 观察 Raft Process 监控，看 tick duration 是否很高。如果是，需要在 `[raftstore]` 配置下加上 `raft-base-tick-interval = “2s”`。 + 1. 观察 [**TiKV-Details** > **Raft Propose** 面板](/grafana-tikv-dashboard.md#raft-propose)，查看这个报警的 TiKV 节点是否明显比其他 TiKV 高很多。如果是，表明这个 TiKV 上有热点，需要检查热点调度是否能正常工作。 + 2. 观察 [**TiKV-Details** > **Raft IO** 面板](/grafana-tikv-dashboard.md#raft-io)，查看延迟是否升高。如果延迟很高，表明磁盘可能存在瓶颈。 + 3. 观察 [**TiKV-Details** > **Raft process** 面板](/grafana-tikv-dashboard.md#raft-process)，关注 `tick duration` 是否很高。如果是，需要将 TiKV 配置项 [`raftstore.raft-base-tick-interval`](/tikv-configuration-file.md#raft-base-tick-interval) 设置为 `"2s"`。 #### `TiKV_write_stall` @@ -550,8 +552,9 @@ aliases: ['/docs-cn/dev/alert-rules/','/docs-cn/dev/reference/alert-rules/'] * 处理方法： - 1. 检查 Raftstore 上的压力，参考 [`TiKV_channel_full_total`](#tikv_channel_full_total) 的处理方法。 - 2. 检查 apply worker 线程的压力。 + 1. 观察 [**TiKV-Details** > **Raft propose** 面板](/grafana-tikv-dashboard.md#raft-propose)，查看这个报警的 TiKV 节点的 **99% Propose wait duration per server** 是否明显比其他 TiKV 高很多。如果是，表明这个 TiKV 上有热点，需要检查热点调度是否能正常工作。 + 2. 观察 [**TiKV-Details** > **Raft IO** 面板](/grafana-tikv-dashboard.md#raft-io)，查看延迟是否升高。如果延迟很高，表明磁盘可能存在瓶颈。 + 3. 如果需要进一步分析报警的 TiKV 节点的性能问题，找到优化方法，可以参考[性能分析和优化方法](/performance-tuning-methods.md#storage-async-write-durationstore-duration-和-apply-duration)。 #### `TiKV_coprocessor_request_wait_seconds` @@ -749,7 +752,7 @@ aliases: ['/docs-cn/dev/alert-rules/','/docs-cn/dev/reference/alert-rules/'] * 处理方法： - 查看是哪一类任务的值偏高，通常 Coprocessor、apply worker 这类任务都可以在其他指标里找到解决办法。 + 观察 [**TiKV-Details** > **Task** 面板](/grafana-tikv-dashboard.md#task)，查看是哪一类任务的 `Worker pending tasks` 值偏高。 #### `TiKV_low_space` diff --git a/auto-increment.md b/auto-increment.md index b172b7e7ab39..1e971ee4de72 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -12,6 +12,8 @@ aliases: ['/docs-cn/dev/auto-increment/'] > > 使用 `AUTO_INCREMENT` 可能会给生产环境带热点问题，因此推荐使用 [`AUTO_RANDOM`](/auto-random.md) 代替。详情请参考 [TiDB 热点问题处理](/troubleshoot-hot-spot-issues.md#tidb-热点问题处理)。 +在 [`CREATE TABLE`](/sql-statements/sql-statement-create-table.md) 语句中也可以使用 `AUTO_INCREMENT` 参数来指定自增字段的初始值。 + ## 基本概念 `AUTO_INCREMENT` 是用于自动填充缺省列值的列属性。当 `INSERT` 语句没有指定 `AUTO_INCREMENT` 列的具体值时，系统会自动地为该列分配一个值。 @@ -344,6 +346,7 @@ CREATE TABLE t(a int AUTO_INCREMENT key) AUTO_ID_CACHE 1; > > - 对于 TiDB v6.4.0 之前的版本，由于每次分配 ID 都需要通过一个 TiKV 事务完成 `AUTO_INCREMENT` 值的持久化修改，因此设置 `AUTO_ID_CACHE` 为 `1` 会出现性能下降。 > - 对于 v6.4.0 及以上版本，由于引入了中心化的分配服务，`AUTO_INCREMENT` 值的修改只是在 TiDB 服务进程中的一个内存操作，相较于之前版本更快。 +> - 将 `AUTO_ID_CACHE` 设置为 `1` 表示 TiDB 使用默认的缓存大小 `30000`。 使用 MySQL 兼容模式后，能保证 ID **唯一**、**单调递增**，行为几乎跟 MySQL 完全一致。即使跨 TiDB 实例访问，ID 也不会出现回退。只有当中心化服务的“主” TiDB 实例异常崩溃时，才有可能造成少量 ID 不连续。这是因为主备切换时，“备” 节点需要丢弃一部分之前的“主” 节点可能已经分配的 ID，以保证 ID 不出现重复。 diff --git a/auto-random.md b/auto-random.md index 299114cd2ab3..a4678d181266 100644 --- a/auto-random.md +++ b/auto-random.md @@ -12,6 +12,8 @@ aliases: ['/docs-cn/dev/auto-random/','/docs-cn/dev/reference/sql/attributes/aut 关于如何在高并发写入场景下调优 TiDB，请参阅 [TiDB 高并发写入场景最佳实践](/best-practices/high-concurrency-best-practices.md)。 +在 [`CREATE TABLE`](/sql-statements/sql-statement-create-table.md) 语句中的 `AUTO_RANDOM_BASE` 参数，也可以用来指定 `AUTO_RANDOM` 自增部分的初始值，该参数可以被认为属于内部接口的一部分，对于用户而言请忽略。 + ## 基本概念 `AUTO_RANDOM` 是应用在 `BIGINT` 类型列的属性，用于列值的自动分配。其自动分配的值满足**随机性**和**唯一性**。 @@ -104,6 +106,24 @@ TiDB 自动分配的 `AUTO_RANDOM(S, R)` 列值共有 64 位： 要查看某张含有 `AUTO_RANDOM` 属性的表的分片位数量，除了 `SHOW CREATE TABLE` 以外，还可以在系统表 `INFORMATION_SCHEMA.TABLES` 中 `TIDB_ROW_ID_SHARDING_INFO` 一列中查到模式为 `PK_AUTO_RANDOM_BITS=x` 的值，其中 `x` 为分片位的数量。 +创建完一张含有 `AUTO_RANDOM` 属性的表后，可以使用 `SHOW WARNINGS` 查看当前表可支持的最大隐式分配的次数： + +```sql +CREATE TABLE t (a BIGINT AUTO_RANDOM, b VARCHAR(255), PRIMARY KEY (a)); +SHOW WARNINGS; +``` + +输出结果如下： + +```sql ++-------+------+---------------------------------------------------------+ +| Level | Code | Message | ++-------+------+---------------------------------------------------------+ +| Note | 1105 | Available implicit allocation times: 288230376151711743 | ++-------+------+---------------------------------------------------------+ +1 row in set (0.00 sec) +``` + ## 使用限制 目前在 TiDB 中使用 `AUTO_RANDOM` 有以下限制： diff --git a/basic-features.md b/basic-features.md index 0d85bdf23054..077e05ab711e 100644 --- a/basic-features.md +++ b/basic-features.md @@ -20,8 +20,8 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0 ## 数据类型，函数和操作符 -| 数据类型，函数，操作符 | 7.0 | 6.6 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | -|---|---|:---:|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:| +| 数据类型，函数，操作符 | 7.2 | 7.1 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | +|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | [数值类型](/data-type-numeric.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [日期和时间类型](/data-type-date-and-time.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [字符串类型](/data-type-string.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | @@ -44,33 +44,34 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0 ## 索引和约束 -| 索引和约束 | 7.0 | 6.6 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | -|---|---|---|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:| +| 索引和约束 | 7.2 | 7.1 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | +|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | [表达式索引](/sql-statements/sql-statement-create-index.md#表达式索引) [^2] | Y | Y | Y | E | E | E | E | E | E | E | | [列式存储 (TiFlash)](/tiflash/tiflash-overview.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | -| [使用 FastScan 加速 OLAP 场景下的查询](/tiflash/use-fastscan.md) | Y | E | E | N | N | N | N | N | N | N | +| [使用 FastScan 加速 OLAP 场景下的查询](/tiflash/use-fastscan.md) | Y | Y | E | N | N | N | N | N | N | N | | [RocksDB 引擎](/storage-engine/rocksdb-overview.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [Titan 插件](/storage-engine/titan-overview.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [Titan Level Merge](/storage-engine/titan-configuration.md#level-merge实验功能) | E | E | E | E | E | E | E | E | E | E | | [使用 bucket 提高数据扫描并发度](/tune-region-performance.md#使用-bucket-增加并发) | E | E | E | E | N | N | N | N | N | N | | [不可见索引](/sql-statements/sql-statement-add-index.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | N | | [复合主键](/constraints.md#主键约束) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | +| [`CHECK` 约束](/constraints.md#check-约束) | Y | N | N | N | N | N | N | N | N | N | | [唯一约束](/constraints.md#唯一约束) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [整型主键上的聚簇索引](/constraints.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [复合或非整型主键上的聚簇索引](/constraints.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | N | -| [多值索引](/sql-statements/sql-statement-create-index.md#多值索引) | E | E | N | N | N | N | N | N | N | N | +| [多值索引](/sql-statements/sql-statement-create-index.md#多值索引) | Y | Y | N | N | N | N | N | N | N | N | | [外键约束](/constraints.md#外键约束) | Y | Y | N | N | N | N | N | N | N | N | -| [TiFlash 延迟物化](/tiflash/tiflash-late-materialization.md) | E | N | N | N | N | N | N | N | N | N | +| [TiFlash 延迟物化](/tiflash/tiflash-late-materialization.md) | Y | Y | N | N | N | N | N | N | N | N | ## SQL 语句 -| SQL 语句 [^3] | 7.0 | 6.6 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | -|---|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| +| SQL 语句 [^3] | 7.2 | 7.1 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | +|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | `SELECT`，`INSERT`，`UPDATE`，`DELETE`，`REPLACE` | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | `INSERT ON DUPLICATE KEY UPDATE` | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | `LOAD DATA INFILE` | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | `SELECT INTO OUTFILE` | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | -| `INNER JOIN`, LEFT\|RIGHT [OUTER] JOIN | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | +| `INNER JOIN`, LEFT\|RIGHT [OUTER] JOIN | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | `UNION`，`UNION ALL` | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [`EXCEPT` 和 `INTERSECT` 运算符](/functions-and-operators/set-operators.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | N | | `GROUP BY`，`ORDER BY` | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | @@ -84,14 +85,14 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0 | [`BATCH [ON COLUMN] LIMIT INTEGER INSERT/UPDATE/REPLACE`](/sql-statements/sql-statement-batch.md) | Y | Y | Y | N | N | N | N | N | N | N | | [`ALTER TABLE ... COMPACT`](/sql-statements/sql-statement-alter-table-compact.md) | Y | Y | Y | E | N | N | N | N | N | N | | [表级锁 (Table Lock)](/sql-statements/sql-statement-lock-tables-and-unlock-tables.md) | E | E | E | E | E | E | E | E | E | E | -| [物化列式存储的查询结果](/tiflash/tiflash-results-materialization.md) | E | E | E | N | N | N | N | N | N | N | +| [物化列式存储的查询结果](/tiflash/tiflash-results-materialization.md) | Y | Y | E | N | N | N | N | N | N | N | ## 高级 SQL 功能 -| 高级 SQL 功能 | 7.0 | 6.6 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | -|---|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|---|:---:| +| 高级 SQL 功能 | 7.2 | 7.1 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | +|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | [Prepare 语句执行计划缓存](/sql-prepared-plan-cache.md) | Y | Y | Y | Y | Y | Y | E | E | E | E | -| [非 Prepare 语句执行计划缓存](/sql-non-prepared-plan-cache.md) | E | N | N | N | N | N | N | N | N | N | +| [非 Prepare 语句执行计划缓存](/sql-non-prepared-plan-cache.md) | E | E | N | N | N | N | N | N | N | N | | [执行计划管理 (SPM)](/sql-plan-management.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [根据历史执行计划创建绑定](/sql-plan-management.md#根据历史执行计划创建绑定) | Y | Y | E | N | N | N | N | N | N | N | | [下推计算结果缓存 (Coprocessor Cache)](/coprocessor-cache.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | E | @@ -101,21 +102,22 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0 | [Optimizer hints](/optimizer-hints.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [MPP 执行引擎](/explain-mpp.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | N | | [MPP 执行引擎 - compression exchange](/explain-mpp.md#mpp-version-和-exchange-数据压缩) | Y | Y | N | N | N | N | N | N | N | N | +| [TiFlash Pipeline 执行模型](/tiflash/tiflash-pipeline-model.md) | E | N | N | N | N | N | N | N | N | N | | [索引合并](/explain-index-merge.md) | Y | Y | Y | Y | Y | E | E | E | E | E | | [基于 SQL 的数据放置规则](/placement-rules-in-sql.md) | Y | Y | Y | Y | E | E | N | N | N | N | | [Cascades Planner](/system-variables.md#tidb_enable_cascades_planner) | E | E | E | E | E | E | E | E | E | E | ## 数据定义语言 (DDL) -| 数据定义语言 (DDL) | 7.0 | 6.6 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | -|---|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| +| 数据定义语言 (DDL) | 7.2 | 7.1 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | +|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | `CREATE`，`DROP`，`ALTER`，`RENAME`，`TRUNCATE` | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | -| [生成列](/generated-columns.md) | E | E | E | E | E | E | E | E | E | E | +| [生成列](/generated-columns.md) | Y | Y | E | E | E | E | E | E | E | E | | [视图](/views.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [序列](/sql-statements/sql-statement-create-sequence.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | -| [`AUTO_INCREMENT` 列](/auto-increment.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | +| [`AUTO_INCREMENT` 列](/auto-increment.md) | Y | Y | Y[^4] | Y | Y | Y | Y | Y | Y | Y | | [`AUTO_RANDOM` 列](/auto-random.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | -| [TTL (Time to Live)](/time-to-live.md) | Y | E | E | N | N | N | N | N | N | N | +| [TTL (Time to Live)](/time-to-live.md) | Y | Y | E | N | N | N | N | N | N | N | | [DDL 算法断言](/sql-statements/sql-statement-alter-table.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | 在单条语句中添加多列 | Y | Y | Y | E | E | E | E | E | E | E | | [更改列类型](/sql-statements/sql-statement-modify-column.md) | Y | Y | Y | Y | Y | Y | Y | Y | N | N | @@ -124,11 +126,12 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0 | [添加索引加速](/system-variables.md#tidb_ddl_enable_fast_reorg-从-v630-版本开始引入) | Y | Y | Y | N | N | N | N | N | N | N | | [元数据锁](/metadata-lock.md) | Y | Y | Y | N | N | N | N | N | N | N | | [`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-to-timestamp.md) | Y | Y | Y | N | N | N | N | N | N | N | +| [暂停](/sql-statements/sql-statement-admin-pause-ddl.md)/[恢复](/sql-statements/sql-statement-admin-resume-ddl.md) DDL | E | N | N | N | N | N | N | N | N | N | ## 事务 -| 事务 | 7.0 | 6.6 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | -|---|---|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| +| 事务 | 7.2 | 7.1 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | +|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | [Async commit](/system-variables.md#tidb_enable_async_commit-从-v50-版本开始引入) | Y | Y | Y | Y | Y | Y | Y | Y | Y | N | | [1PC](/system-variables.md#tidb_enable_1pc-从-v50-版本开始引入) | Y | Y | Y | Y | Y | Y | Y | Y | Y | N | | [大事务 (10 GB)](/transaction-overview.md#事务限制) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | @@ -139,23 +142,24 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0 ## 分区 -| 分区 | 7.0 | 6.6 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | -|---|---|:---:|:---:|---|:---:|:---:|:---:|:---:|:---:|:---:| +| 分区 | 7.2 | 7.1 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | +|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | [Range 分区](/partitioned-table.md#range-分区) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [Hash 分区](/partitioned-table.md#hash-分区) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | -| [Key 分区](/partitioned-table.md#key-分区) | Y | N | N | N | N | N | N | N | N | N | +| [Key 分区](/partitioned-table.md#key-分区) | Y | Y | N | N | N | N | N | N | N | N | | [List 分区](/partitioned-table.md#list-分区) | Y | Y | Y | Y | E | E | E | E | E | N | | [List COLUMNS 分区](/partitioned-table.md#list-columns-分区) | Y | Y | Y | Y | E | E | E | E | E | N | | [`EXCHANGE PARTITION`](/partitioned-table.md) | Y | Y | Y | E | E | E | E | E | E | N | -| [`REORGANIZE PARTITION`](/partitioned-table.md#重组分区) | Y | N | N | N | N | N | N | N | N | N | +| [`REORGANIZE PARTITION`](/partitioned-table.md#重组分区) | Y | Y | N | N | N | N | N | N | N | N | +| [`COALESCE PARTITION`](/partitioned-table.md#减少分区数量) | Y | Y | N | N | N | N | N | N | N | N | | [动态裁剪](/partitioned-table.md#动态裁剪模式) | Y | Y | Y | Y | E | E | E | E | N | N | | [Range COLUMNS 分区](/partitioned-table.md#range-columns-分区) | Y | Y | Y | N | N | N | N | N | N | N | -| [Range INTERVAL 分区](/partitioned-table.md#range-interval-分区) | E | E | E | N | N | N | N | N | N | N | +| [Range INTERVAL 分区](/partitioned-table.md#range-interval-分区) | Y | Y | E | N | N | N | N | N | N | N | ## 统计信息 -| 统计信息 | 7.0 | 6.6 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | -|---|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|---|:---:| +| 统计信息 | 7.2 | 7.1 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | +|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | [CM-Sketch](/statistics.md) | 默认关闭 | 默认关闭 | 默认关闭 | 默认关闭 | 默认关闭 | 默认关闭 | Y | Y | Y | Y | | [直方图](/statistics.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | 扩展统计信息（多列） | E | E | E | E | E | E | E | E | E | N | @@ -167,11 +171,12 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0 | [限制统计信息的内存使用量](/statistics.md#统计信息收集的内存限制) | E | E | E | E | N | N | N | N | N | N | | [随机采样约 10000 行数据来快速构建统计信息](/system-variables.md#tidb_enable_fast_analyze) | E | E | E | E | E | E | E | E | E | E | | [锁定统计信息](/statistics.md#锁定统计信息) | E | E | E | N | N | N | N | N | N | N | +| [轻量级统计信息初始化](/statistics.md#统计信息的加载) | Y | E | N | N | N | N | N | N | N | N | ## 安全 -| 安全 | 7.0 | 6.6 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | -|---|---|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| +| 安全 | 7.2 | 7.1 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | +|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | [传输层加密 (TLS)](/enable-tls-between-clients-and-servers.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [静态加密 (TDE)](/encryption-at-rest.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [基于角色的访问控制 (RBAC)](/role-based-access-control.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | @@ -179,6 +184,8 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0 | [`caching_sha2_password` 认证](/system-variables.md#default_authentication_plugin) | Y | Y | Y | Y | Y | Y | Y | N | N | N | | [`tidb_sm3_password` 认证](/system-variables.md#default_authentication_plugin) | Y | Y | Y | N | N | N | N | N | N | N | | [`tidb_auth_token` 认证](/system-variables.md#default_authentication_plugin) | Y | Y | Y | N | N | N | N | N | N | N | +| [`authentication_ldap_sasl` 认证](/system-variables.md#default_authentication_plugin) | Y | Y | N | N | N | N | N | N | N | N | +| [`authentication_ldap_simple` 认证](/system-variables.md#default_authentication_plugin) | Y | Y | N | N | N | N | N | N | N | N | | [密码管理](/password-management.md) | Y | Y | Y | N | N | N | N | N | N | N | | [与 MySQL 兼容的 `GRANT` 权限管理](/privilege-management.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [动态权限](/privilege-management.md#动态权限) | Y | Y | Y | Y | Y | Y | Y | Y | N | N | @@ -187,23 +194,24 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0 ## 数据导入和导出 -| 数据导入和导出 | 7.0 | 6.6 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | -|---|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| +| 数据导入和导出 | 7.2 | 7.1 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | +|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | [快速导入 (TiDB Lightning)](/tidb-lightning/tidb-lightning-overview.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | +| [快速导入 (`IMPORT INTO`)](/sql-statements/sql-statement-import-into.md) | E | N | N | N | N | N | N | N | N | N | | mydumper 逻辑导出 | 已废弃 | 已废弃 | 已废弃 | 已废弃 | 已废弃 | 已废弃 | 已废弃 | 已废弃 | 已废弃 | 已废弃 | | [Dumpling 逻辑导出](/dumpling-overview.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | -| [事务 `LOAD DATA`](/sql-statements/sql-statement-load-data.md) | E [^5] | Y | Y | Y | Y | Y | Y | Y | Y | N [^6] | +| [事务 `LOAD DATA`](/sql-statements/sql-statement-load-data.md) [^5] | Y | Y | Y | Y | Y | Y | Y | Y | Y | N [^6] | | [数据迁移工具](/migration-overview.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [Change data capture (CDC)](/ticdc/ticdc-overview.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | -| [TiCDC 支持保存数据到存储服务 (S3/NFS/Azure Blob Storage/GCP)](/ticdc/ticdc-sink-to-cloud-storage.md) | Y | E | E | N | N | N | N | N | N | N | +| [TiCDC 支持保存数据到存储服务 (Amazon S3/GCS/Azure Blob Storage/NFS)](/ticdc/ticdc-sink-to-cloud-storage.md) | Y | Y | E | N | N | N | N | N | N | N | | [TiCDC 支持在两个 TiDB 集群之间进行双向复制](/ticdc/ticdc-bidirectional-replication.md) | Y | Y | Y | N | N | N | N | N | N | N | -| [TiCDC OpenAPI v2](/ticdc/ticdc-open-api-v2.md) | Y | N | N | N | N | N | N | N | N | N | +| [TiCDC OpenAPI v2](/ticdc/ticdc-open-api-v2.md) | Y | Y | N | N | N | N | N | N | N | N | ## 管理，可视化和工具 -| 管理，可视化和工具 | 7.0 | 6.6 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | -|---|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| +| 管理，可视化和工具 | 7.2 | 7.1 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 | 5.0 | 4.0 | +|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | [TiDB Dashboard 图形化展示](/dashboard/dashboard-intro.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | | [TiDB Dashboard 持续性能分析功能](/dashboard/continuous-profiling.md) | Y | Y | Y | Y | E | E | N | N | N | N | | [TiDB Dashboard Top SQL 功能](/dashboard/top-sql.md) | Y | Y | Y | Y | E | N | N | N | N | N | @@ -230,8 +238,9 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0 | [全局内存控制](/configure-memory-usage.md#如何配置-tidb-server-实例使用内存的阈值) | Y | Y | Y | N | N | N | N | N | N | N | | [RawKV 跨集群复制](/tikv-configuration-file.md#api-version-从-v610-版本开始引入) | E | E | E | N | N | N | N | N | N | N | | [Green GC](/system-variables.md#tidb_gc_scan_lock_mode-从-v50-版本开始引入) | E | E | E | E | E | E | E | E | E | N | -| [资源管控 (Resource Control)](/tidb-resource-control.md) | E | E | N | N | N | N | N | N | N | N | -| [TiFlash 存算分离架构与 S3 支持](/tiflash/tiflash-disaggregated-and-s3.md) | E | N | N | N | N | N | N | N | N | N | +| [资源管控 (Resource Control)](/tidb-resource-control.md) | Y | Y | N | N | N | N | N | N | N | N | +| [Runaway Queries 自动管理](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries) | E | N | N | N | N | N | N | N | N | N | +| [TiFlash 存算分离架构与 S3 支持](/tiflash/tiflash-disaggregated-and-s3.md) | E | E | N | N | N | N | N | N | N | N | [^1]: TiDB 误将 latin1 处理为 utf8 的子集。见 [TiDB #18955](https://github.com/pingcap/tidb/issues/18955)。 @@ -239,8 +248,8 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0 [^3]: TiDB 支持的完整 SQL 列表，见[语句参考](/sql-statements/sql-statement-select.md)。 -[^4]: 从 [TiDB v6.4.0](/releases/release-6.4.0.md) 开始，支持[高性能、全局单调递增的 `AUTO_INCREMENT` 列](/auto-increment.md#mysql-兼容模式) +[^4]: 从 [TiDB v6.4.0](/releases/release-6.4.0.md) 开始，支持[高性能、全局单调递增的 `AUTO_INCREMENT` 列](/auto-increment.md#mysql-兼容模式)。 -[^5]: 对于 [TiDB v7.0.0](/releases/release-7.0.0.md)，新增参数 `FORMAT`、`FIELDS DEFINED NULL BY`、`With batch_size=,detached`，以及新增支持从 S3 和 GCS 导入数据，均为实验特性。 +[^5]: 从 [TiDB v7.0.0](/releases/release-7.0.0.md) 开始新增的参数 `FIELDS DEFINED NULL BY` 以及新增支持从 S3 和 GCS 导入数据，均为实验特性。 [^6]: 对于 TiDB v4.0，事务 `LOAD DATA` 不保证原子性。 diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index 790b61385ad5..3020e4c50690 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/benchmark/benchmark-tidb-using-sysbench.md @@ -139,7 +139,7 @@ sysbench --config-file=config oltp_point_select --tables=32 --table-size=1000000 数据预热可将磁盘中的数据载入内存的 block cache 中，预热后的数据对系统整体的性能有较大的改善，建议在每次重启集群后进行一次数据预热。 ```bash -sysbench --config-file=config oltp_point_select --tables=32 --table-size=10000000 warmup +sysbench --config-file=config oltp_point_select --tables=32 --table-size=10000000 prewarm ``` ### Point select 测试命令 diff --git a/best-practices/java-app-best-practices.md b/best-practices/java-app-best-practices.md index 7c109ba3c7b3..49e4d2bf24d1 100644 --- a/best-practices/java-app-best-practices.md +++ b/best-practices/java-app-best-practices.md @@ -11,7 +11,7 @@ aliases: ['/docs-cn/dev/best-practices/java-app-best-practices/','/docs-cn/dev/r 通常 Java 应用中和数据库相关的常用组件有： -- 网络协议：客户端通过标准 [MySQL 协议](https://dev.mysql.com/doc/internals/en/client-server-protocol.html)和 TiDB 进行网络交互。 +- 网络协议：客户端通过标准 [MySQL 协议](https://dev.mysql.com/doc/dev/mysql-server/latest/PAGE_PROTOCOL.html)和 TiDB 进行网络交互。 - JDBC API 及实现：Java 应用通常使用 [JDBC (Java Database Connectivity)](https://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/) 来访问数据库。JDBC 定义了访问数据库 API，而 JDBC 实现完成标准 API 到 MySQL 协议的转换，常见的 JDBC 实现是 [MySQL Connector/J](https://github.com/mysql/mysql-connector-j)，此外有些用户可能使用 [MariaDB Connector/J](https://mariadb.com/kb/en/library/about-mariadb-connector-j/#about-mariadb-connectorj)。 - 数据库连接池：为了避免每次创建连接，通常应用会选择使用数据库连接池来复用连接，JDBC [DataSource](https://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource.html) 定义了连接池 API，开发者可根据实际需求选择使用某种开源连接池实现。 - 数据访问框架：应用通常选择通过数据访问框架 ([MyBatis](http://www.mybatis.org/mybatis-3/zh/index.html), [Hibernate](https://hibernate.org/)) 的封装来进一步简化和管理数据库访问操作。 diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index 675c1d7ce49b..53f8cfdb96a7 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -297,4 +297,4 @@ Region Merge 速度慢也很有可能是受到 limit 配置的限制（`merge-sc 实践中，如果能确定这个节点的故障是不可恢复的，可以立即做下线处理，这样 PD 能尽快补齐副本，降低数据丢失的风险。与之相对，如果确定这个节点是能恢复的，但可能半小时之内来不及，则可以把 `max-store-down-time` 临时调整为比较大的值，这样能避免超时之后产生不必要的副本补充，造成资源浪费。 -自 v5.2.0 起，TiKV 引入了慢节点检测机制。通过对 TiKV 中的请求进行采样，计算出一个范围在 1~100 的分数。当分数大于等于 80 时，该 TiKV 节点会被设置为 slow 状态。可以通过添加 [`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe) 来针对慢节点进行对应的检测和调度。当检测到有且只有一个 TiKV 节点为慢节点，并且该 TiKV 的 slow score 到达上限（默认 100）时，将节点上的 leader 驱逐（其作用类似于 `evict-leader-scheduler`）。 +自 v5.2.0 起，TiKV 引入了慢节点检测机制。通过对 TiKV 中的请求进行采样，计算出一个范围在 1~100 的分数。当分数大于等于 80 时，该 TiKV 节点会被设置为 slow 状态。可以通过添加 [`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe) 来针对慢节点进行对应的检测和调度。当检测到有且只有一个 TiKV 节点为慢节点，并且该 TiKV 的 slow score 到达限定值（默认 80）时，将节点上的 leader 驱逐（其作用类似于 `evict-leader-scheduler`）。 diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index 95134b7620e2..fefdc2b51da7 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -45,7 +45,7 @@ TiDB 备份恢复功能可以用于满足以下业务的需求： ## 功能使用 -根据 TiDB 部署方式的不同，使用备份恢复功能的方式也不同。本文主要介绍在 On-Premise 物理部署方式下，如何使用 br 命令行工具进行 TiDB 的备份和恢复。 +根据 TiDB 部署方式的不同，使用备份恢复功能的方式也不同。本文主要介绍在本地部署方式下，如何使用 br 命令行工具进行 TiDB 的备份和恢复。 其它 TiDB 的部署方式的备份恢复功能使用，可以参考： @@ -117,7 +117,7 @@ TiDB 支持将数据备份到 Amazon S3、Google Cloud Storage (GCS)、Azure Blo | 聚簇索引 | [#565](https://github.com/pingcap/br/issues/565) | 确保恢复时集群的 `tidb_enable_clustered_index` 全局变量和备份时一致，否则会导致数据不一致的问题，例如 `default not found` 和数据索引不一致。 | | New collation | [#352](https://github.com/pingcap/br/issues/352) | 确保恢复时集群的 `new_collations_enabled_on_first_bootstrap` 变量值和备份时的一致，否则会导致数据索引不一致和 checksum 通不过。更多信息，请参考 [FAQ - BR 为什么会报 `new_collations_enabled_on_first_bootstrap` 不匹配？](/faq/backup-and-restore-faq.md#恢复时为什么会报-new_collations_enabled_on_first_bootstrap-不匹配)。 | | 全局临时表 | | 确保使用 BR v5.3.0 及以上版本进行备份和恢复，否则会导致全局临时表的表定义错误。 | -| TiDB Lightning Physical Import| |上游数据库使用 TiDB Lightning Physical 方式导入的数据，无法作为数据日志备份下来。推荐在数据导入后执行一次全量备份，细节参考[上游数据库使用 TiDB Lightning Physical 方式导入数据的恢复](/faq/backup-and-restore-faq.md#上游数据库使用-tidb-lightning-physical-方式导入数据时为什么无法使用日志备份功能)。| +| TiDB Lightning 物理导入模式| |上游数据库使用 TiDB Lightning 物理导入模式导入的数据，无法作为数据日志备份下来。推荐在数据导入后执行一次全量备份，细节参考[上游数据库使用 TiDB Lightning 物理导入模式导入数据的恢复](/faq/backup-and-restore-faq.md#上游数据库使用-tidb-lightning-物理导入模式导入数据时为什么无法使用日志备份功能)。| ### 版本间兼容性 diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md index c822139a00b6..b6eaeadcd983 100644 --- a/br/backup-and-restore-storages.md +++ b/br/backup-and-restore-storages.md @@ -55,6 +55,8 @@ BACKUP DATABASE * TO 's3://bucket-name/prefix' SEND_CREDENTIALS_TO_TIKV = FALSE; - `sse`：加密上传的服务端加密算法，可以设置为空、`AES256` 或 `aws:kms` - `sse-kms-key-id`：如果 `sse` 设置为 `aws:kms`，则使用该参数指定 KMS ID - `acl`：上传对象的标准 ACL (Canned ACL)，例如 `private`、`authenticated-read` + - `role-arn`：当需要使用特定的 [IAM 角色](https://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/id_roles.html)来访问第三方 Amazon S3 的数据时，使用这个参数来指定 IAM 角色的对应 [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/zh_cn/general/latest/gr/aws-arns-and-namespaces.html)（例如 `arn:aws:iam::888888888888:role/my-role`）。关于使用 IAM 角色访问第三方 Amazon S3 数据的场景，请参考 [AWS 相关文档介绍](https://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)。 + - `external-id`：当需要使用特定的 [IAM 角色](https://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/id_roles.html)来访问第三方 Amazon S3 的数据时，可能需要同时提供正确的[外部 ID](https://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) 来确保用户有权限代入该 IAM 角色。这个参数用来指定对应的外部 ID，确保成功代入 IAM 角色。外部 ID 可以是任意字符串，并且不是必须的，一般由控制 Amazon S3 数据访问的第三方来指定。如果第三方对于 IAM 角色没有要求指定外部 ID，则可以不需要提供该参数也能顺利代入对应的 IAM 角色，从而访问对应的 Amazon S3 数据。
@@ -76,7 +78,8 @@ BACKUP DATABASE * TO 's3://bucket-name/prefix' SEND_CREDENTIALS_TO_TIKV = FALSE; - `account-name`：存储账户名 - `account-key`：访问密钥 - - `access-tier`：上传对象的存储类别，例如 `Hot`、`Cool`、`Archive`，默认为 `Hot` + - `sas-token`：共享访问签名令牌 + - `access-tier`：上传对象的存储类别，例如 `Hot`、`Cool`、`Archive`，默认值为该存储账户的默认访问层。
@@ -149,7 +152,7 @@ BACKUP DATABASE * TO 's3://bucket-name/prefix' SEND_CREDENTIALS_TO_TIKV = FALSE; 在备份之前，需要为 br 命令行工具访问 Amazon S3 中的备份目录设置相应的访问权限： - 备份时 TiKV 和 br 命令行工具需要的访问备份数据目录的最小权限：`s3:ListBucket`、`s3:PutObject` 和 `s3:AbortMultipartUpload`。 -- 恢复时 TiKV 和 br 命令行工具需要的访问备份数据目录的最小权限：`s3:ListBucket` 和 `s3:GetObject`。 +- 恢复时 TiKV 和 br 命令行工具需要的访问备份数据目录的最小权限：`s3:ListBucket`、`s3:GetObject` 和 `s3:PutObject`。br 命令行工具会将断点信息写到备份数据目录下的 `./checkpoints` 子目录。在恢复日志备份数据时，br 命令行工具会将备份恢复集群的表 ID 映射关系写到备份数据目录下的 `./pitr_id_maps` 子目录。 如果你还没有创建备份数据保存目录，可以参考[创建存储桶](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/user-guide/create-bucket.html)在指定的区域中创建一个 S3 存储桶。如果需要使用文件夹，可以参考[使用文件夹在 Amazon S3 控制台中组织对象](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/user-guide/create-folder.html)在存储桶中创建一个文件夹。 @@ -185,11 +188,15 @@ BACKUP DATABASE * TO 's3://bucket-name/prefix' SEND_CREDENTIALS_TO_TIKV = FALSE;
-- 方式一：指定访问密钥 +- 方式一：指定共享访问签名 + + 在 URI 中配置 `account-name` 和 `sas-token`，则使用该参数指定的存储账户名和共享访问签名令牌。由于共享访问签名令牌中带有 `&` 的字符，需要将其编码为 `%26` 后再添加到 URI 中。你也可以直接对整个 `sas-token` 进行一次百分号编码。 + +- 方式二：指定访问密钥 - 在 URI 配置 `account-name` 和 `account-key`，则使用该参数指定的密钥。除了在 URI 中指定密钥文件外，还支持 br 命令行工具读取 `$AZURE_STORAGE_KEY` 的方式。 + 在 URI 中配置 `account-name` 和 `account-key`，则使用该参数指定的存储账户名和密钥。除了在 URI 中指定密钥文件外，还支持 br 命令行工具读取 `$AZURE_STORAGE_KEY` 的方式。 -- 方式二：使用 Azure AD 备份恢复 +- 方式三：使用 Azure AD 备份恢复 在 br 命令行工具运行环境配置环境变量 `$AZURE_CLIENT_ID`、`$AZURE_TENANT_ID` 和 `$AZURE_CLIENT_SECRET`。 diff --git a/br/backup-and-restore-use-cases.md b/br/backup-and-restore-use-cases.md index b6410536f4d0..422549487649 100644 --- a/br/backup-and-restore-use-cases.md +++ b/br/backup-and-restore-use-cases.md @@ -17,7 +17,7 @@ aliases: ['/docs-cn/dev/br/backup-and-restore-use-cases/','/docs-cn/dev/referenc ## 部署 TiDB 集群和 br 命令行工具 -使用 PITR 功能，需要部署 v6.2.0 或以上版本的 TiDB 集群，并且更新 br 命令行工具到与 TiDB 集群相同的版本，本文假设使用的是 v7.0.0 版本。 +使用 PITR 功能，需要部署 v6.2.0 或以上版本的 TiDB 集群，并且更新 br 命令行工具到与 TiDB 集群相同的版本，本文假设使用的是 v7.2.0 版本。 下表介绍了在 TiDB 集群中使用日志备份功能的推荐配置。 @@ -44,13 +44,13 @@ aliases: ['/docs-cn/dev/br/backup-and-restore-use-cases/','/docs-cn/dev/referenc - 安装： ```shell - tiup install br:v7.0.0 + tiup install br:v7.2.0 ``` - 升级： ```shell - tiup update br:v7.0.0 + tiup update br:v7.2.0 ``` ## 配置备份存储 (Amazon S3) @@ -71,7 +71,7 @@ aliases: ['/docs-cn/dev/br/backup-and-restore-use-cases/','/docs-cn/dev/referenc 2. 配置 br 命令行工具和 TiKV 访问 S3 中的备份目录的权限。本文推荐使用最安全的 IAM 访问方式，配置过程可以参考[控制存储桶访问](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/userguide/walkthrough1.html)。权限要求如下： - 备份集群的 TiKV 和 br 命令行工具需要的 `s3://tidb-pitr-bucket/backup-data` 权限：`s3:ListBucket`、`s3:PutObject` 和 `s3:AbortMultipartUpload`。 - - 恢复集群的 TiKV 和 br 命令行工具需要 `s3://tidb-pitr-bucket/backup-data` 的最小权限：`s3:ListBucket` 和 `s3:GetObject`。 + - 恢复集群的 TiKV 和 br 命令行工具需要 `s3://tidb-pitr-bucket/backup-data` 的最小权限：`s3:ListBucket`、`s3:GetObject` 和 `s3:PutObject`。 3. 规划备份数据保存的目录结构，以及快照（全量）备份和日志备份的目录。 diff --git a/br/br-checkpoint.md b/br/br-checkpoint-backup.md similarity index 81% rename from br/br-checkpoint.md rename to br/br-checkpoint-backup.md index 38ea87914e00..fa4f6a90159f 100644 --- a/br/br-checkpoint.md +++ b/br/br-checkpoint-backup.md @@ -1,17 +1,26 @@ --- title: 断点备份 -summary: 了解断点备份功能，包括它的使用场景、使用方法以及实现原理。 +summary: 了解断点备份功能，包括它的使用场景、实现原理以及使用方法。 +aliases: ["/zh/tidb/dev/br-checkpoint"] --- # 断点备份 快照备份会因为一些可恢复性错误导致提前结束，例如硬盘空间占满、节点宕机等等一些突发情况。在 TiDB v6.5.0 之前，在错误被处理之后，之前备份的数据会作废，你需要重新进行备份。对大规模集群来说，会造成大量额外成本。 -为了尽可能继续上一次的备份，从 TiDB v6.5.0 起，备份恢复特性引入了断点备份的功能，此功能默认开启。开启该功能后，备份在意外退出后可以保留上一次备份的大部分进度。 +为了尽可能继续上一次的备份，从 TiDB v6.5.0 起，备份恢复特性引入了断点备份的功能。该功能可以在备份意外中断后保留上一次备份的大部分进度。 ## 使用场景 -如果你的 TiDB 集群规模很大，无法接受备份失败后需要重新备份的情况，那么，你可以开启断点备份功能。开启该功能后，br 工具会定期记录已备份的分片，使得在下一次重试备份时回到离上一次退出时较近的进度。 +如果你的 TiDB 集群规模很大，无法接受备份失败后需要重新备份的情况，那么，你可以使用断点备份功能重试备份。br 工具会定期记录已备份的分片，使得在下一次重试备份时回到离上一次退出时较近的进度。 + +## 实现原理 + +在快照备份过程中，br 工具将表编码成对应的键空间，并生成备份的 RPC 请求发送给所有 TiKV 节点。接收到备份请求后，TiKV 节点会选择请求范围内的数据进行备份。每当 TiKV 节点备份完一个 Region 级别的数据，就会返回给 br 工具这段范围相关的备份信息。 + +通过记录这些返回的备份信息，br 工具能够及时获知已备份完成的键范围。断点备份功能会定期将这些新增的相关备份信息上传至外部存储中，从而持久化存储该备份任务已完成的键范围。 + +在重试备份时，br 工具会从外部存储读取已经备份的键范围，再与所需备份的键范围做比较，获得一个差集，从而得出断点备份还需要备份的键范围。 ## 使用限制 @@ -42,11 +51,3 @@ br backup full \ - 由错误引起的退出，br 工具会在退出前将已备份的数据元信息持久化到外部存储中，因此只有正在备份的数据需要在下一次重试中重新备份。 - 如果 br 工具进程被系统中断，那么 br 将无法把已备份的数据元信息持久化到外部存储中。br 工具持久化已备份的数据元信息的周期为 30 秒，因此大约最近 30 秒内的已完成备份的数据无法持久化到外部存储，在下次重试时需要重新备份。 - -## 实现原理 - -在快照备份过程中，br 工具将表编码成对应的键空间，并生成备份的 RPC 请求发送给所有 TiKV 节点。接收到备份请求后，TiKV 节点会选择请求范围内的数据进行备份。每当 TiKV 节点备份完一个 `region` 级别的数据，就会返回给 br 工具这段范围相关的备份信息。 - -通过记录这些返回的备份信息，br 工具能够及时获知已备份完成的键范围。断点备份功能会定期将这些新增的相关备份信息上传至外部存储中，从而持久化存储该备份任务已完成的键范围。 - -在重试备份时，br 工具会从外部存储读取已经备份的键范围，再与所需备份的键范围做比较，获得一个差集，从而得出断点备份还需要备份的键范围。 diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md new file mode 100644 index 000000000000..19f735553a70 --- /dev/null +++ b/br/br-checkpoint-restore.md @@ -0,0 +1,62 @@ +--- +title: 断点恢复 +summary: 了解断点恢复功能，包括它的使用场景、实现原理以及使用方法。 +--- + +# 断点恢复 + +快照恢复或日志恢复会因为一些可恢复性错误导致提前结束，例如硬盘空间占满、节点宕机等等一些突发情况。在 TiDB v7.1.0 之前，在错误被处理之后，之前恢复的进度会作废，你需要重新进行恢复。对大规模集群来说，会造成大量额外成本。 + +为了尽可能继续上一次的恢复，从 TiDB v7.1.0 起，备份恢复特性引入了断点恢复的功能。该功能可以在意外中断后保留上一次恢复的大部分进度。 + +## 使用场景 + +如果你的 TiDB 集群规模很大，无法接受恢复失败后需要重新恢复的情况，那么，你可以使用断点恢复功能重试恢复。br 工具会定期记录已恢复的分片，使得在下一次重试恢复时回到离上一次退出时较近的进度。 + +## 实现原理 + +断点恢复的实现原理分为快照恢复和日志恢复两部分。 + +### 快照恢复 + +快照恢复的实现原理与[快照备份](/br/br-checkpoint-backup.md#实现原理)类似，br 工具会批量恢复一段键范围 (Region) 内的所有的 SST 文件。恢复完成后，br 工具记录下这段范围以及该范围对应的恢复集群的表 ID。断点恢复功能会定期将这些新增的相关恢复信息上传至外部存储中，从而持久化存储该恢复任务已完成的键范围。 + +在重试恢复时，br 工具会从外部存储读取已经恢复的键范围，并匹配相关的表 ID。在恢复过程中，会跳过与断点恢复记录的键范围重叠且对应表 ID 相同的范围。 + +如果在重试恢复前，你删除了某些表，那么重试恢复时新创建的表的 ID 会与之前记录在断点恢复的表 ID 不同，从而绕过使用之前的断点恢复信息，重新恢复该表，也就是说，新的 ID 的同个表可以不使用旧的 ID 的断点恢复信息，而是重新记录新 ID 对应的断点恢复信息。 + +由于数据采用了 MVCC（多版本并发控制）机制，带有固定 TS 的数据可以被无序且重复写入。 + +快照恢复在恢复库表 DDL 时添加了 `ifExists` 参数。对于已经存在的库表（视为已经创建完毕），br 工具会自动跳过恢复。 + +### 日志恢复 + +日志恢复需要按照时间顺序恢复 TiKV 节点备份下来的数据元信息 (meta-kv)。断点恢复首先会根据 meta-kv 数据为备份集群和恢复集群建立一一对应的 ID 映射关系，以确保在不同重试恢复过程中 meta-kv 的 ID 保持一致。这样，meta-kv 就具备了重新恢复的能力。 + +与快照备份文件不同，日志备份文件的范围可能会重叠，因此无法直接使用键范围作为恢复进度的元信息。同时，日志备份文件数量可能非常多。不过，每个日志备份文件在日志备份元信息中的位置是固定的，因此可以为每个日志备份文件指定一个日志备份元信息中唯一的位置作为恢复进度的元信息。 + +日志备份元信息中包含一个存放文件元信息的数组。数组中的每个文件元信息代表一个由多个日志备份文件拼接而成的文件。文件元信息记录了这些日志备份文件在拼接文件中的偏移和大小。因此，br 工具可以使用三元组 `(日志备份元信息名，文件元信息数组偏移，日志备份文件数组偏移)` 来唯一标识一个日志备份文件。 + +## 使用限制 + +断点恢复功能依赖于 GC 机制，且无法记录所有已恢复的数据，具体描述如下。 + +### GC 会被停止 + +在日志恢复过程中，日志数据恢复的顺序是无序的，因此可能会出现一个 key 的删除记录优先于该 key 的写入记录恢复的情况。如果此时触发 GC，该 key 的所有数据会被删除，导致该 key 后续恢复的写入记录无法被 GC 处理。为了避免这种情况，br 命令行工具会在日志恢复过程中暂停 GC。当 br 工具中途退出后，GC 将仍然保持暂停状态。 + +日志恢复完成后会重新启动 GC，不需要手动启动。但如果你不想再继续恢复时，请手动开启 GC，开启方法如下： + +br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold = -1.0`，将 [`gc.ratio-threshold`](/tikv-configuration-file.md#ratio-threshold) 的值设置成负数来暂停 GC。你可以通过修改 `gc.ratio-threshold` 的值手动开启 GC，例如执行 `SET config tikv gc.ratio-threshold = 1.1` 将参数重置为默认值。 + +### 部分数据需要重新恢复 + +在重试恢复时，部分已恢复的数据可能需要重新恢复，包括正在恢复的数据和还未被断点记录的数据。 + +- 由错误引起的退出，br 工具会在退出前将已恢复的数据元信息持久化到外部存储中，因此只有正在恢复的数据需要在下一次重试中重新恢复。 + +- 如果 br 工具进程被系统中断，那么 br 将无法把已恢复的数据元信息持久化到外部存储中。br 工具持久化已恢复的数据元信息的周期为 30 秒，因此大约最近 30 秒内的已完成恢复的数据无法持久化到外部存储，在下次重试时需要重新恢复。 + +### 不要在恢复期间修改集群数据 + +在恢复失败后，请避免向集群写入或删除数据、删除或创建表。由于备份数据中可能包含重命名表的 DDL 操作，断点恢复无法确认被删除的表或已存在的表是否是外部操作引起的，这会影响下次重试恢复的准确性。 diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md index a7806335adb8..5a70e96539c6 100644 --- a/br/br-pitr-guide.md +++ b/br/br-pitr-guide.md @@ -114,12 +114,18 @@ Restore KV Files <-------------------------------------------------------------- > > 以上功能指标是根据下述两个场景测试得出的结论，如有出入，建议以实际测试结果为准： > -> - 全量恢复速度 = 全量恢复集群数据量 /（时间 * TiKV 数量） +> - 全量恢复速度 = 全量恢复数据量 /（时间 * TiKV 数量） > - 日志恢复速度 = 日志恢复总量 /（时间 * TiKV 数量） +> +> 其中全量恢复数据量，是指单个副本中所有 KV 的逻辑大小，并不代表实际恢复的数据量。BR 恢复数据时会根据集群设置的副本数来恢复全部副本，当副本数越多时，实际恢复的数据量也就越多。 +> 所有测试集群默认设置 3 副本。 +> 如果想提升整体恢复的性能，可以通过根据实际情况调整 TiKV 配置文件中的 [`import.num-threads`](/tikv-configuration-file.md#import) 配置项以及 BR 命令的 [`concurrency`](/br/use-br-command-line-tool.md#常用选项) 参数。 测试场景 1（[TiDB Cloud](https://tidbcloud.com) 上部署） - TiKV 节点（8 core，16 GB 内存）数量：21 +- TiKV 配置项 `import.num-threads`：8 +- BR 命令参数 `concurrency`：128 - Region 数量：183,000 - 集群新增日志数据：10 GB/h - 写入 (INSERT/UPDATE/DELETE) QPS：10,000 @@ -127,6 +133,8 @@ Restore KV Files <-------------------------------------------------------------- 测试场景 2（本地部署） - TiKV 节点（8 core，64 GB 内存）数量：6 +- TiKV 配置项 `import.num-threads`：8 +- BR 命令参数 `concurrency`：128 - Region 数量：50,000 - 集群新增日志数据：10 GB/h - 写入 (INSERT/UPDATE/DELETE) QPS：10,000 diff --git a/br/use-br-command-line-tool.md b/br/use-br-command-line-tool.md index 4fe461023ee9..b26a6606ef8f 100644 --- a/br/use-br-command-line-tool.md +++ b/br/use-br-command-line-tool.md @@ -47,6 +47,7 @@ br backup full --pd "${PD_IP}:2379" \ * `--cert`：指定 PEM 格式的 SSL 证书文件路径。 * `--key`：指定 PEM 格式的 SSL 证书密钥文件路径。 * `--status-addr`：向 Prometheus 提供统计数据的监听地址。 +* `--concurrency`：备份或恢复阶段的任务并发数。 ## 全量备份命令行 diff --git a/choose-index.md b/choose-index.md index e28d4cd75971..3cbc29b82681 100644 --- a/choose-index.md +++ b/choose-index.md @@ -143,10 +143,6 @@ mysql> SHOW WARNINGS; ## 使用多值索引 -> **警告：** -> -> 当前该功能为实验特性，不建议在生产环境中使用。 - [多值索引](/sql-statements/sql-statement-create-index.md#多值索引)和普通索引有所不同，TiDB 目前只会使用 [IndexMerge](/explain-index-merge.md) 来访问多值索引。因此要想使用多值索引进行数据访问，请确保`tidb_enable_index_merge` 被设置为 `ON`。 目前 TiDB 支持将 `json_member_of`、`json_contains` 和 `json_overlaps` 条件自动转换成 IndexMerge 来访问多值索引。既可以依赖优化器根据代价自动选择，也可通过 [`use_index_merge`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-) optimizer hint 或 [`use_index`](/optimizer-hints.md#use_indext1_name-idx1_name--idx2_name-) 指定选择多值索引，见下面例子： diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md index 6522d639e675..723073c35139 100644 --- a/command-line-flags-for-tidb-configuration.md +++ b/command-line-flags-for-tidb-configuration.md @@ -120,11 +120,11 @@ aliases: ['/docs-cn/dev/command-line-flags-for-tidb-configuration/','/docs-cn/de + 允许使用 [PROXY 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)连接 TiDB 的代理服务器地址列表。 + 默认："" + 通常情况下，通过反向代理使用 TiDB 时，TiDB 会将反向代理服务器的 IP 地址视为客户端 IP 地址。对于支持 [PROXY 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)的反向代理（如 HAProxy），开启 PROXY 协议后能让反向代理透传客户端真实的 IP 地址给 TiDB。 -+ 配置该参数后，TiDB 将允许配置的源 IP 地址使用 PROXY 协议连接到 TiDB，且拒绝这些源 IP 地址使用非 PROXY 协议连接。若该参数为空，则任何源 IP 地址都不能使用 PROXY 协议连接到 TiDB。地址可以使用 IP 地址格式 (192.168.1.50) 或者 CIDR 格式 (192.168.1.0/24)，并可用 `,` 分隔多个地址，或用 `*` 代表所有 IP 地址。 ++ 配置该参数后，TiDB 将允许配置的源 IP 地址使用 PROXY 协议连接到 TiDB，且拒绝这些源 IP 地址使用非 PROXY 协议连接。其他地址可以使用非 PROXY 协议连接到 TiDB。若该参数为空，则任何源 IP 地址都不能使用 PROXY 协议连接到 TiDB。地址可以使用 IP 地址格式 (192.168.1.50) 或者 CIDR 格式 (192.168.1.0/24)，并可用 `,` 分隔多个地址，或用 `*` 代表所有 IP 地址。 > **警告：** > -> 需谨慎使用 `*` 符号，因为它可能引入安全风险，允许来自任何 IP 的客户端自行汇报其 IP 地址。另外，它可能会导致部分直接连接 TiDB 的内部组件无法使用，例如 TiDB Dashboard。 +> 需谨慎使用 `*` 符号，因为它可能引入安全风险，允许来自任何 IP 的客户端自行汇报其 IP 地址。另外，当 [`--proxy-protocol-fallbackable`](#--proxy-protocol-fallbackable) 设置为 `true` 以外的值时，使用 `*` 可能会导致部分直接连接 TiDB 的内部组件无法使用，例如 TiDB Dashboard。 > **注意：** > @@ -132,7 +132,7 @@ aliases: ['/docs-cn/dev/command-line-flags-for-tidb-configuration/','/docs-cn/de ## `--proxy-protocol-fallbackable` -+ 用于控制是否启用 PROXY 协议回退模式。如果设置为 `true`，TiDB 可以接受非 PROXY 协议规范或者没有发送 PROXY 协议头的客户端连接。默认情况下，TiDB 仅接受发送 PROXY 协议头的客户端连接。 ++ 用于控制是否启用 PROXY 协议回退模式。如果设置为 `true`，TiDB 可以接受属于 `--proxy-protocol-networks` 的客户端使用非 PROXY 协议规范或者没有发送 PROXY 协议头的客户端连接。默认情况下，TiDB 仅接受属于 `--proxy-protocol-networks` 的客户端发送 PROXY 协议头的客户端连接。 + 默认：`false` ## `--proxy-protocol-header-timeout` diff --git a/config-templates/complex-tiflash.yaml b/config-templates/complex-tiflash.yaml index 48c5b85aea31..6d664dcafe8b 100644 --- a/config-templates/complex-tiflash.yaml +++ b/config-templates/complex-tiflash.yaml @@ -103,7 +103,6 @@ tiflash_servers: - host: 10.0.1.11 # ssh_port: 22 # tcp_port: 9000 - # http_port: 8123 # flash_service_port: 3930 # flash_proxy_port: 20170 # flash_proxy_status_port: 20292 diff --git a/configure-load-base-split.md b/configure-load-base-split.md index 200bbd63c4ff..e05e62e016c3 100644 --- a/configure-load-base-split.md +++ b/configure-load-base-split.md @@ -31,9 +31,9 @@ Load Base Split 后的 Region 不会被迅速 Merge。一方面，PD 的 `MergeC 目前的 Load Base Split 的控制参数如下： -- `split.qps-threshold`：表明一个 Region 被识别为热点的 QPS 阈值，默认为每秒 `3000` QPS。 -- `split.byte-threshold`：自 v5.0 引入，表明一个 Region 被识别为热点的流量阈值，单位为 Byte，默认为每秒 `30 MiB` 流量。 -- `split.region-cpu-overload-threshold-ratio`：自 v6.2.0 引入，表明一个 Region 被识别为热点的 CPU 使用率（占读线程池 CPU 时间的百分比）阈值，默认为 `0.25`。 +- [`split.qps-threshold`](/tikv-configuration-file.md#qps-threshold)：表明一个 Region 被识别为热点的 QPS 阈值。当 [`region-split-size`](/tikv-configuration-file.md#region-split-size) 小于 4 GB 时，默认为每秒 `3000` QPS。当 `region-split-size` 大于或等于 4 GB 时，默认值为每秒 `7000` QPS。 +- [`split.byte-threshold`](/tikv-configuration-file.md#byte-threshold-从-v50-版本开始引入)：自 v5.0 引入，表明一个 Region 被识别为热点的流量阈值，单位为 Byte。当 `region-split-size` 小于 4 GB 时，默认值为每秒 `30 MiB` 流量。当 `region-split-size` 大于或等于 4 GB 时，默认值为每秒 `100 MiB` 流量。 +- [`split.region-cpu-overload-threshold-ratio`](/tikv-configuration-file.md#region-cpu-overload-threshold-ratio-从-v620-版本开始引入)：自 v6.2.0 引入，表明一个 Region 被识别为热点的 CPU 使用率（占读线程池 CPU 时间的百分比）阈值。当 `region-split-size` 小于 4 GB 时，默认值为 `0.25`。当 `region-split-size` 大于或等于 4 GB 时，默认值为 `0.75`。 如果连续 10s 内，某个 Region 每秒的各类读请求之和超过了 `split.qps-threshold`、流量超过了 `split.byte-threshold`，或 CPU 使用率在 Unified Read Pool 内的占比超过了 `split.region-cpu-overload-threshold-ratio`，那么就会尝试对此 Region 进行拆分。 diff --git a/configure-memory-usage.md b/configure-memory-usage.md index e8923eadd92e..8537f7652400 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -65,6 +65,10 @@ SET GLOBAL tidb_server_memory_limit = "32GB"; 在 tidb-server 实例内存用量到达总内存的一定比例时（比例由系统变量 [`tidb_server_memory_limit_gc_trigger`](/system-variables.md#tidb_server_memory_limit_gc_trigger-从-v640-版本开始引入) 控制）, tidb-server 会尝试主动触发一次 Golang GC 以缓解内存压力。为了避免实例内存在阈值上下范围不断波动导致频繁 GC 进而带来的性能问题，该 GC 方式 1 分钟最多只会触发 1 次。 +> **注意：** +> +> 在混合部署的情况下，`tidb_server_memory_limit` 为单个 tidb-server 实例的内存使用阈值，而不是整个物理机的总内存阈值。 + ## 使用 INFORMATION_SCHEMA 系统表查看当前 tidb-server 的内存用量 要查看当前实例或集群的内存使用情况，你可以查询系统表 [`INFORMATION_SCHEMA.(CLUSTER_)MEMORY_USAGE`](/information-schema/information-schema-memory-usage.md)。 diff --git a/configure-store-limit.md b/configure-store-limit.md index a9ba538ba650..db1f59136d11 100644 --- a/configure-store-limit.md +++ b/configure-store-limit.md @@ -67,3 +67,9 @@ store limit 1 5 // 设置 store 1 添加和删除 peer 的 store limit 1 5 add-peer // 设置 store 1 添加 peer 的速度上限为每分钟 5 个。 store limit 1 5 remove-peer // 设置 store 1 删除 peer 的速度上限为每分钟 5 个。 ``` + +## Store Limit v2 原理 + +当 [`store-limit-version`](/pd-configuration-file.md#store-limit-version-从-v710-版本开始引入) 设置为 `v2` 时，Store Limit v2 生效。在此模式下，Operator 调度限制将根据 TiKV Snapshot 执行情况进行动态调整。当 TiKV 积压的任务较少时，PD 会增加其调度任务。相反，PD 会减少对该节点的调度任务。此时，你无需关注如何设置 `store limit` 以加快调度进度。 + +在该模式下，TiKV 执行速度成为迁移进度的主要瓶颈。你可以通过 **TiKV Details** > **Snapshot** > **Snapshot Speed** 面板判断当前调度速度是否达到 TiKV 限流设置。通过调整 TiKV Snapshot Limit ([`snap-io-max-bytes-per-sec`](/tikv-configuration-file.md#snap-io-max-bytes-per-sec)) 来增加或减少该节点的调度速度。 \ No newline at end of file diff --git a/constraints.md b/constraints.md index e07430cfbbbd..1c185d0c3d22 100644 --- a/constraints.md +++ b/constraints.md @@ -51,22 +51,92 @@ Query OK, 1 row affected (0.03 sec) ## `CHECK` 约束 -TiDB 会解析并忽略 `CHECK` 约束。该行为与 MySQL 5.7 的相兼容。 +> **注意：** +> +> `CHECK` 约束功能默认关闭，需要将变量 [`tidb_enable_check_constraint`](/system-variables.md#tidb_enable_check_constraint-从-v720-版本开始引入) 设置为 `ON` 后才能开启。 + +`CHECK` 约束用于限制表中某个字段的值必须满足指定条件。当为表添加 `CHECK` 约束后，在插入或者更新表的数据时，TiDB 会检查约束条件是否满足，如果不满足，则会报错。 -示例如下： +TiDB 中 `CHECK` 约束的语法如下，与 MySQL 中一致： ```sql -DROP TABLE IF EXISTS users; -CREATE TABLE users ( - id INT NOT NULL PRIMARY KEY AUTO_INCREMENT, - username VARCHAR(60) NOT NULL, - UNIQUE KEY (username), - CONSTRAINT min_username_length CHECK (CHARACTER_LENGTH(username) >=4) -); -INSERT INTO users (username) VALUES ('a'); -SELECT * FROM users; +[CONSTRAINT [symbol]] CHECK (expr) [[NOT] ENFORCED] ``` +语法说明： + +- `[]` 中的内容表示可选项。 +- `CONSTRAINT [symbol]` 表示 `CHECK` 约束的名称。 +- `CHECK (expr)` 表示约束条件，其中 `expr` 需要为一个布尔表达式。对于表中的每一行，该表达式的计算结果必须为 `TRUE`、`FALSE` 或 `UNKNOWN` (对于 `NULL` 值) 中的一个。对于某行数据，如果该表达式计算结果为 `FALSE`，则表示违反约束条件。 +- `[NOT] ENFORCED` 表示是否执行约束，可以用于启用或者禁用 `CHECK` 约束。 + +### 添加 `CHECK` 约束 + +在 TiDB 中，你可以在 [`CREATE TABLE`](/sql-statements/sql-statement-create-table.md) 或者 [`ALTER TABLE`](/sql-statements/sql-statement-modify-column.md) 语句中为表添加 `CHECK` 约束。 + +- 在 `CREATE TABLE` 语句中添加 `CHECK` 约束的示例： + + ```sql + CREATE TABLE t(a INT CHECK(a > 10) NOT ENFORCED, b INT, c INT, CONSTRAINT c1 CHECK (b > c)); + ``` + +- 在 `ALTER TABLE` 语句中添加 `CHECK` 约束的示例： + + ```sql + ALTER TABLE t ADD CONSTRAINT CHECK (1 < c); + ``` + +在添加或者启用 `CHECK` 约束时，TiDB 会对表中的存量数据进行校验。如果存在违反约束的数据，添加 `CHECK` 约束操作将失败并且报错。 + +在添加 `CHECK` 约束时，可以指定约束名，也可以不指定约束名。如果不指定约束名，那么 TiDB 会自动生成一个格式为 `_chk_<1, 2, 3...>` 的约束名。 + +### 查看 `CHECK` 约束 + +你可以通过 [`SHOW CREATE TABLE`](/sql-statements/sql-statement-show-create-table.md) 查看表中的约束信息。例如： + +```sql +SHOW CREATE TABLE t; ++-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Table | Create Table | ++-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| t | CREATE TABLE `t` ( + `a` int(11) DEFAULT NULL, + `b` int(11) DEFAULT NULL, + `c` int(11) DEFAULT NULL, +CONSTRAINT `c1` CHECK ((`b` > `c`)), +CONSTRAINT `t_chk_1` CHECK ((`a` > 10)) /*!80016 NOT ENFORCED */, +CONSTRAINT `t_chk_2` CHECK ((1 < `c`)) +) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin | ++-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +1 row in set (0.00 sec) +``` + +### 删除 `CHECK` 约束 + +删除 `CHECK` 约束时，你需要指定需要删除的约束名。例如： + +```sql +ALTER TABLE t DROP CONSTRAINT t_chk_1; +``` + +### 启用或禁用 `CHECK` 约束 + +在为表[添加 `CHECK` 约束](#添加-check-约束)的时候，可以指定当插入或者更新数据时 TiDB 是否执行约束检查。 + +- 如果指定了 `NOT ENFORCED`，当插入或者更新数据时，TiDB 不会检查约束条件。 +- 如果未指定 `NOT ENFORCED` 或者指定了 `ENFORCED`，当插入或者更新数据时，TiDB 会检查约束条件。 + +除了在添加约束时候指定 `[NOT] ENFORCED`，你还可以在 `ALTER TABLE` 语句中启用或者禁用 `CHECK` 约束。例如： + +```sql +ALTER TABLE t ALTER CONSTRAINT c1 NOT ENFORCED; +``` + +### 与 MySQL 的兼容性 + +- 不支持在添加列的同时添加 `CHECK` 约束（例如，`ALTER TABLE t ADD COLUMN a CHECK(a > 0)`)），否则只有列会被添加成功，TiDB 会忽略 `CHECK` 约束但不会报错。 +- 不支持使用 `ALTER TABLE t CHANGE a b int CHECK(b > 0)` 添加 `CHECK` 约束，使用该语句时 TiDB 会报错。 + ## 唯一约束 唯一约束是指唯一索引和主键列中所有的非空值都是唯一的。 @@ -246,6 +316,8 @@ ERROR 1062 (23000): Duplicate entry 'bill' for key 'users.username' ERROR 9007 (HY000): Write conflict, txnStartTS=435688780611190794, conflictStartTS=435688783311536129, conflictCommitTS=435688783311536130, key={tableID=74, indexID=1, indexValues={bill, }} primary={tableID=74, indexID=1, indexValues={bill, }}, reason=LazyUniquenessCheck [try again later] ``` +- 关闭该变量时，如果多个悲观事务之间存在写冲突，悲观锁可能会在其它悲观事务提交时被强制回滚，因此产生 `PessimisticLockNotFound` 错误。发生该错误时，说明该业务不适合推迟悲观事务的唯一约束检查，应考虑调整业务避免冲突，或在发生错误后重试事务。 + - 关闭该变量会导致悲观事务中可能报出错误 `8147: LazyUniquenessCheckFailure`。 > **注意：** diff --git a/control-execution-plan.md b/control-execution-plan.md index fc341840122f..d55f2a42cd48 100644 --- a/control-execution-plan.md +++ b/control-execution-plan.md @@ -10,3 +10,5 @@ SQL 性能调优的前两个章节介绍了如何理解 TiDB 的执行计划以 - [Optimizer Hints](/optimizer-hints.md)中，我们会介绍如何使用 Hint 来指导 TiDB 生成执行计划。 - 但是使用 Hint 会侵入性地更改 SQL，在一些场景下并不能简单的插入 Hint。在[执行计划管理](/sql-plan-management.md)中，我们会介绍 TiDB 如何使用另一种语法来非侵入地控制执行计划的生成，同时还会介绍后台自动对执行计划进行演进的手段。该手段可用来减轻诸如版本升级等原因造成的执行计划不稳定和集群性能下降的问题。 - 最后在[优化规则及表达式下推的黑名单](/blocklist-control-plan.md)中，我们会介绍黑名单的使用。 + +除以上手段之外，执行计划还会被一部分系统变量所影响。通过在系统级或会话级对变量进行修改，能够控制执行计划的生成。自 v7.1.0 起，TiDB 引入了一个相对特殊的变量 [`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-从-v710-版本开始引入)。这个变量能够接受多个控制项，用来更细粒度地控制优化器的行为，避免集群升级后优化器行为变化导致的性能回退。详细介绍请参考 [Optimizer Fix Controls](/optimizer-fix-controls.md)。 diff --git a/credits.md b/credits.md index 7072aed23e60..f2b81115d929 100644 --- a/credits.md +++ b/credits.md @@ -14,26 +14,19 @@ TiDB 开发者为 TiDB 的新功能开发、性能优化、稳定性保障做出 - [pingcap/tidb](https://github.com/pingcap/tidb/graphs/contributors) - [tikv/tikv](https://github.com/tikv/tikv/graphs/contributors) -- [pingcap/parser](https://github.com/pingcap/parser/graphs/contributors) - [tikv/pd](https://github.com/tikv/pd/graphs/contributors) - [pingcap/tiflash](https://github.com/pingcap/tiflash/graphs/contributors) - [pingcap/tidb-operator](https://github.com/pingcap/tidb-operator/graphs/contributors) - [pingcap/tiup](https://github.com/pingcap/tiup/graphs/contributors) -- [pingcap/br](https://github.com/pingcap/br/graphs/contributors) -- [pingcap/dm](https://github.com/pingcap/dm/graphs/contributors) - [pingcap/tidb-binlog](https://github.com/pingcap/tidb-binlog/graphs/contributors) - [pingcap/tidb-dashboard](https://github.com/pingcap/tidb-dashboard/graphs/contributors) - [pingcap/tiflow](https://github.com/pingcap/tiflow/graphs/contributors) - [pingcap/tidb-tools](https://github.com/pingcap/tidb-tools/graphs/contributors) -- [pingcap/tidb-lightning](https://github.com/pingcap/tidb-lightning/graphs/contributors) - [pingcap/tispark](https://github.com/pingcap/tispark/graphs/contributors) -- [pingcap/dumpling](https://github.com/pingcap/dumpling/graphs/contributors) - [tikv/client-java](https://github.com/tikv/client-java/graphs/contributors) - [tidb-incubator/TiBigData](https://github.com/tidb-incubator/TiBigData/graphs/contributors) - [ti-community-infra](https://github.com/orgs/ti-community-infra/people) -完整的贡献者名单，请查阅 [SIG | TiDB DevGroup](https://contributor.tidb.io/sig) - ## TiDB 文档写作者和译员 TiDB 文档写作者和译员为 TiDB 及相关项目撰写文档、提供翻译。以下链接包含了 TiDB 文档相关 repo 的贡献者名单： @@ -41,5 +34,4 @@ TiDB 文档写作者和译员为 TiDB 及相关项目撰写文档、提供翻译 - [pingcap/docs-cn](https://github.com/pingcap/docs-cn/graphs/contributors) - [pingcap/docs](https://github.com/pingcap/docs/graphs/contributors) - [pingcap/docs-tidb-operator](https://github.com/pingcap/docs-tidb-operator/graphs/contributors) -- [pingcap/docs-dm](https://github.com/pingcap/docs-dm/graphs/contributors) - [tikv/website](https://github.com/tikv/website/graphs/contributors) diff --git a/dashboard/continuous-profiling.md b/dashboard/continuous-profiling.md index 3dc229b474b0..89b8f3195e8c 100644 --- a/dashboard/continuous-profiling.md +++ b/dashboard/continuous-profiling.md @@ -38,7 +38,7 @@ summary: 了解如何持续地收集 TiDB、TiKV、PD 各个实例的性能数 你可以通过以下任一方式访问持续性能分析页面： -- 登录后，在左侧导航栏中点击**高级调试** (Advanced Debugging) > **实例性能分析** (Profiling Instances) > **持续分析** (Continuous Profiling)。 +- 登录 TiDB Dashboard 后，在左侧导航栏中点击**高级调试** (Advanced Debugging) > **实例性能分析** (Profiling Instances) > **持续分析** (Continuous Profiling)。 ![访问页面](/media/dashboard/dashboard-conprof-access.png) diff --git a/dashboard/dashboard-cluster-info.md b/dashboard/dashboard-cluster-info.md index b94d6d7768eb..126c00031487 100644 --- a/dashboard/dashboard-cluster-info.md +++ b/dashboard/dashboard-cluster-info.md @@ -12,11 +12,9 @@ aliases: ['/docs-cn/dev/dashboard/dashboard-cluster-info/'] 可以通过以下两种方法访问集群信息页面： -- 登录后，左侧导航条点击**集群信息** (Cluster Info)： +* 登录 TiDB Dashboard 后，在左侧导航栏中点击**集群信息** (Cluster Info)。 - ![访问](/media/dashboard/dashboard-cluster-info-access-v650.png) - -- 在浏览器中访问 （将 `127.0.0.1:2379` 替换为实际 PD 实例地址和端口）。 +* 在浏览器中访问 （将 `127.0.0.1:2379` 替换为实际 PD 实例地址和端口）。 ## 实例列表 diff --git a/dashboard/dashboard-diagnostics-access.md b/dashboard/dashboard-diagnostics-access.md index 5e6e3c3c5abf..2883d5aaf128 100644 --- a/dashboard/dashboard-diagnostics-access.md +++ b/dashboard/dashboard-diagnostics-access.md @@ -15,11 +15,11 @@ aliases: ['/docs-cn/dev/dashboard/dashboard-diagnostics-access/'] 可以通过以下两种方法访问集群诊断页面： -* 登录后，左侧导航条点击**集群诊断** (Cluster Diagnostics)： +* 登录 TiDB Dashboard 后，在左侧导航栏中点击**集群诊断** (Cluster Diagnostics)。 ![访问](/media/dashboard/dashboard-diagnostics-access-v650.png) -* 在浏览器中访问 [http://127.0.0.1:2379/dashboard/#/diagnose](http://127.0.0.1:2379/dashboard/#/diagnose)（将 `127.0.0.1:2379` 替换为任意实际 PD 地址和端口）。 +* 在浏览器中访问 [http://127.0.0.1:2379/dashboard/#/diagnose](http://127.0.0.1:2379/dashboard/#/diagnose)（将 `127.0.0.1:2379` 替换为你的实际 PD 地址和端口）。 ## 生成诊断报告 diff --git a/dashboard/dashboard-intro.md b/dashboard/dashboard-intro.md index 19bd8e2e7928..86996a352f69 100644 --- a/dashboard/dashboard-intro.md +++ b/dashboard/dashboard-intro.md @@ -59,6 +59,12 @@ TiDB Dashboard 在 GitHub 上[开源](https://github.com/pingcap-incubator/tidb- 参阅[日志搜索页面](/dashboard/dashboard-log-search.md)了解详情。 +## 预估资源管控容量 + +为使用[资源管控 (Resource Control)](/tidb-resource-control.md) 特性实现资源隔离，集群管理员可以定义资源组 (Resource Group)，通过资源组限定配额。 + +在进行资源规划之前，你需要了解集群的整体容量。参阅[资源管控页面](/dashboard/dashboard-resource-manager.md)了解详情。 + ## 收集分析各个组件的性能数据 高级调试功能：无需第三方工具，在线地对各个组件进行性能分析，剖析组件实例在分析时间段内执行的各种内部操作及比例。 diff --git a/dashboard/dashboard-profiling.md b/dashboard/dashboard-profiling.md index 75567abce357..a39ff5ce5d6c 100644 --- a/dashboard/dashboard-profiling.md +++ b/dashboard/dashboard-profiling.md @@ -34,7 +34,7 @@ aliases: ['/docs-cn/dev/dashboard/dashboard-profiling/'] 可以通过以下两种方法访问实例性能分析页面： -- 登录后，左侧导航条点击**高级调试** (Advanced Debugging) > **实例性能分析** (Profile Instances) > **手动分析** (Manual Profiling)： +- 登录 TiDB Dashboard 后，在左侧导航栏中点击**高级调试** (Advanced Debugging) > **实例性能分析** (Profile Instances) > **手动分析** (Manual Profiling)： ![访问页面](/media/dashboard/dashboard-profiling-access.png) diff --git a/dashboard/dashboard-resource-manager.md b/dashboard/dashboard-resource-manager.md new file mode 100644 index 000000000000..e7e16b625334 --- /dev/null +++ b/dashboard/dashboard-resource-manager.md @@ -0,0 +1,76 @@ +--- +title: TiDB Dashboard 资源管控页面 +summary: 介绍如何使用 TiDB Dashboard 的资源管控页面查看资源管控相关信息，以便预估集群容量，更好地进行资源配置。 +--- + +# TiDB Dashboard 资源管控页面 + +为使用[资源管控 (Resource Control)](/tidb-resource-control.md) 特性实现资源隔离，集群管理员可以定义资源组 (Resource Group)，通过资源组限定配额。在进行资源规划之前，你需要了解集群的整体容量。该页面可以帮助你查看资源管控相关信息，以便预估集群容量，更好地进行资源配置。 + +## 访问方式 + +可以通过以下两种方法访问资源管控页面： + +* 登录 TiDB Dashboard 后，在左侧导航栏中点击**资源管控** (Resource Manager)。 + +* 在浏览器中访问 （将 `127.0.0.1:2379` 替换为你的实际 PD 地址和端口）。 + +## 资源管控详情 + +资源管控详情页面如下图所示： + +![TiDB Dashboard: Resource Manager](/media/dashboard/dashboard-resource-manager-info.png) + +资源管控详情页包含以下三个部分： + +- 配置 (Configuration)：数据来自于 TiDB 的 `RESOURCE_GROUPS` 表中所有资源组的信息。参见 [`RESOURCE_GROUPS`](/information-schema/information-schema-resource-groups.md) 文档。 + +- 容量估算 (Estimate Capacity)：在进行资源规划之前，你需要了解集群的整体容量。目前提供两种估算方式： + + - [基于硬件部署估算容量](/sql-statements/sql-statement-calibrate-resource.md#基于硬件部署估算容量) + - [根据实际负载估算容量](/sql-statements/sql-statement-calibrate-resource.md#根据实际负载估算容量) + +- 监控指标 (Metrics)：通过观察面板上的指标，可以了解当前集群整体的资源消耗状态。 + +## 容量估算 + +在进行资源规划之前，你需要了解集群的整体容量。目前提供两种估算方式预估当前集群的 [Request Unit (RU)](/tidb-resource-control.md#什么是-request-unit-ru#什么是-request-unit-ru) 的容量： + +- [基于硬件部署估算容量](/sql-statements/sql-statement-calibrate-resource.md#基于硬件部署估算容量) (Calibrate by Hardware) + + 目前提供了以下负载类型供选择： + + - `tpcc`：数据写入较重的负载，根据类似 `TPC-C` 的负载模型预测。 + - `oltp_write_only`：数据写入较重的负载，根据类似 `sysbench oltp_write_only` 的负载模型预测。 + - `oltp_read_write`：数据读写平衡的负载，根据类似 `sysbench oltp_read_write` 的负载模型预测。 + - `oltp_read_only`：数据读取较重的负载，根据类似 `sysbench oltp_read_only` 的负载模型预测。 + + ![基于硬件部署估算容量](/media/dashboard/dashboard-resource-manager-calibrate-by-hardware.png) + + 用户资源分组总请求单元 (Total RU of user resource groups) 表示当前除 `default` 用户外的 RU 总量。当该数值小于容量估算值时，系统会发出提醒。系统预定义的 `default` 资源组默认拥有无限用量。当所有用户都属于 `default` 资源组时，资源分配方式与关闭资源管控时相同。 + +- [根据实际负载估算容量](/sql-statements/sql-statement-calibrate-resource.md#根据实际负载估算容量) (Calibrate by Workload) + + ![根据实际负载估算容量](/media/dashboard/dashboard-resource-manager-calibrate-by-workload.png) + + 可以选择 10 分钟至 24 小时的时间范围进行预估。时区与前端用户所处时区相同。 + + - 如果时间窗口范围不满足 10 分钟至 24 小时的条件，会报错 `Error 1105 (HY000): the duration of calibration is too short, which could lead to inaccurate output. Please make the duration between 10m0s and 24h0m0s`。 + + - 如果时间窗口范围内的负载过低，会报错 `Error 1105 (HY000): The workload in selected time window is too low, with which TiDB is unable to reach a capacity estimation; please select another time window with higher workload, or calibrate resource by hardware instead`。 + + 可以通过[监控指标](#监控指标)中的 **CPU Usage** 选择合适的时间范围。 + +## 监控指标 + +通过观察面板上的指标，可以了解当前集群整体的资源消耗状态。监控指标及其含义如下： + +- Total RU Consumed：实时统计的 Request Unit 总消耗量 +- RU Consumed by Resource Groups：以资源组为单位进行实时统计的 Request Unit 消耗数量 +- TiDB + - CPU Quota：TiDB 最大 CPU 占用率 + - CPU Usage：所有 TiDB 实例 CPU 占用率 +- TiKV + - CPU Quota：TiKV 最大 CPU 占用率 + - CPU Usage：所有 TiKV 实例 CPU 占用率 + - IO MBps：所有 TiKV 实例的 I/O 吞吐量 \ No newline at end of file diff --git a/dashboard/dashboard-slow-query.md b/dashboard/dashboard-slow-query.md index 669d7b8bb89d..7796613e4f8b 100644 --- a/dashboard/dashboard-slow-query.md +++ b/dashboard/dashboard-slow-query.md @@ -18,11 +18,9 @@ aliases: ['/docs-cn/dev/dashboard/dashboard-slow-query/'] 可以通过以下两种方法访问慢查询页面： -* 登录后，左侧导航条点击**慢查询** (**Slow Queries**)： +* 登录 TiDB Dashboard 后，在左侧导航栏中点击**慢查询** (Slow Queries)。 -![access 访问页面](/media/dashboard/dashboard-slow-queries-access-v620.png) - -* 在浏览器中访问 （将 `127.0.0.1:2379` 替换为任意实际 PD 地址和端口）。 +* 在浏览器中访问 （将 `127.0.0.1:2379` 替换为你的实际 PD 地址和端口）。 慢查询页面所展示的所有数据都来自于 TiDB 慢查询系统表及慢查询日志，参见[慢查询日志](/identify-slow-queries.md)文档了解详细情况。 @@ -38,6 +36,12 @@ aliases: ['/docs-cn/dev/dashboard/dashboard-slow-query/'] ![显示更多列信息](/media/dashboard/dashboard-slow-queries-list2-v620.png) +### 导出慢查询到本地 + +点击页面右上角 ☰ (**更多**) 可以显示**导出** (**Export**) 选项。点击**导出** (**Export**) 后，TiDB Dashboard 会将当前列表中的慢查询以 CSV 文件的格式进行导出。 + +![导出慢查询到本地](/media/dashboard/dashboard-slow-queries-export-v651.png) + ### 修改列表排序依据 列表默认以**结束运行时间** (**Finish Time**) 逆序排序，点击不同的列标题可以修改排序依据或切换排序顺序： diff --git a/dashboard/dashboard-statement-list.md b/dashboard/dashboard-statement-list.md index 3f27e1ad678c..f6ffc351b00b 100644 --- a/dashboard/dashboard-statement-list.md +++ b/dashboard/dashboard-statement-list.md @@ -14,11 +14,9 @@ aliases: ['/docs-cn/dev/dashboard/dashboard-statement-list/'] 可以通过以下两种方法访问 SQL 语句分析页面： -- 登录后，左侧导航条点击 "**SQL 语句分析**" (SQL Statements)。 +* 登录 TiDB Dashboard 后，在左侧导航栏中点击**SQL 语句分析** (SQL Statements)。 - ![访问](/media/dashboard/dashboard-statement-access.png) - -- 在浏览器中访问 （将 `127.0.0.1:2379` 替换为实际 PD 实例地址和端口）。 +* 在浏览器中访问 （将 `127.0.0.1:2379` 替换为实际 PD 实例地址和端口）。 SQL 语句分析页面所展示的所有数据都来自于 TiDB Statement 系统表，参见 [Statement Summary Tables](/statement-summary-tables.md) 文档了解该系统表的详细情况。 diff --git a/dashboard/top-sql.md b/dashboard/top-sql.md index 8c4a06f3ce12..5e22e7784646 100644 --- a/dashboard/top-sql.md +++ b/dashboard/top-sql.md @@ -35,7 +35,7 @@ Top SQL 不能用于解答与性能无关的问题，例如数据正确性或异 你可以通过以下任一方式访问 Top SQL 页面： -- 登录 TiDB Dashboard 后，在左侧导航栏中点击**Top SQL** +- 登录 TiDB Dashboard 后，在左侧导航栏中点击**Top SQL**。 ![Top SQL](/media/dashboard/top-sql-access.png) diff --git a/data-type-date-and-time.md b/data-type-date-and-time.md index cbb7bf1b2c95..c7b169777a62 100644 --- a/data-type-date-and-time.md +++ b/data-type-date-and-time.md @@ -228,7 +228,7 @@ CREATE TABLE t1 ( ## 时间值的小数部分 -`DATETIME` 和 `TIMESTAMP` 值最多可以有 6 位小数，精确到毫秒。如果包含小数部分，值的格式为 `YYYY-MM-DD HH:MM:SS[.fraction]`，小数部分的范围为 `000000` 到`999999`。必须使用小数点分隔小数部分与其他部分。 +`DATETIME` 和 `TIMESTAMP` 值最多可以有 6 位小数，精确到微秒。如果包含小数部分，值的格式为 `YYYY-MM-DD HH:MM:SS[.fraction]`，小数部分的范围为 `000000` 到`999999`。必须使用小数点分隔小数部分与其他部分。 + 使用 `type_name(fsp)` 可以定义精确到小数的列，其中 `type_name` 可以是`TIME`、`DATETIME` 或 `TIMESTAMP`。例如： diff --git a/data-type-json.md b/data-type-json.md index cb6d72c303c9..8a5b183e1a48 100644 --- a/data-type-json.md +++ b/data-type-json.md @@ -27,7 +27,7 @@ SELECT id FROM city WHERE population >= 100; ## 使用限制 -- 暂不支持将 JSON 函数下推至 TiFlash。 +- 目前 TiDB 仅支持下推部分 JSON 函数到 TiFlash。详情请参考 [TiFlash 支持下推的表达式](/tiflash/tiflash-supported-pushdown-calculations.md#支持下推的表达式)。 - TiDB Backup & Restore（BR）在 v6.3.0 版本对 JSON 列的数据的编码进行了修改。因此不建议使用 BR 恢复包含 JSON 列的数据到 v6.3.0 之前的 TiDB 集群。 - 请勿使用任何同步工具同步非标准 JSON 类型（例如 DATE、DATETIME、TIME 等）的数据。 diff --git a/data-type-numeric.md b/data-type-numeric.md index 7d1fd24691ba..a439c839ab48 100644 --- a/data-type-numeric.md +++ b/data-type-numeric.md @@ -163,6 +163,10 @@ DOUBLE PRECISION [(M,D)] [UNSIGNED] [ZEROFILL], REAL[(M,D)] [UNSIGNED] [ZEROFILL > > 与在 MySQL 中一样，`DOUBLE` 数据类型存储近似值。对于货币之类的精确值，建议使用 `DECIMAL` 类型。 +> **注意：** +> +> 当 TiDB 将用科学计数法表示的双精度浮点数转换到 `CHAR` 类型时，其结果在显示上与 MySQL 不一致，详情参见 [Cast 函数和操作符](/functions-and-operators/cast-functions-and-operators.md)。 + ### 存储空间 每种类型对存储空间的需求如下表所示： diff --git a/data-type-string.md b/data-type-string.md index 759c166db17b..6e0781997f07 100644 --- a/data-type-string.md +++ b/data-type-string.md @@ -61,7 +61,7 @@ TINYTEXT [CHARACTER SET charset_name] [COLLATE collation_name] ### `MEDIUMTEXT` 类型 -类似于 [`TEXT`](#text-类型)，区别在于最大列长度为 16,777,215。但由于 [TiDB 单列的限制](/tidb-limitations.md#单列的限制)，TiDB 中默认单列存储最大不超过 6 MiB，可通过配置项将该限制调整至 120 MiB。 +类似于 [`TEXT`](#text-类型)，区别在于最大列长度为 16,777,215。但由于 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-从-v50-版本开始引入) 的限制，TiDB 中默认单行存储最大不超过 6 MiB，可通过配置项将该限制调整至 120 MiB。 {{< copyable "sql" >}} @@ -71,7 +71,7 @@ MEDIUMTEXT [CHARACTER SET charset_name] [COLLATE collation_name] ### `LONGTEXT` 类型 -类似于 [`TEXT`](#text-类型)，区别在于最大列长度为 4,294,967,295。但由于 [TiDB 单列的限制](/tidb-limitations.md#单列的限制)，TiDB 中默认单列存储最大不超过 6 MiB，可通过配置项将该限制调整至 120 MiB。 +类似于 [`TEXT`](#text-类型)，区别在于最大列长度为 4,294,967,295。但由于 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-从-v50-版本开始引入) 的限制，TiDB 中默认单行存储最大不超过 6 MiB，可通过配置项将该限制调整至 120 MiB。 {{< copyable "sql" >}} @@ -121,7 +121,7 @@ TINYBLOB ### `MEDIUMBLOB` 类型 -类似于 [`BLOB`](#blob-类型)，区别在于最大列长度为 16,777,215。但由于 [TiDB 单列的限制](/tidb-limitations.md#单列的限制)，TiDB 中默认单列存储最大不超过 6 MiB，可通过配置项将该限制调整至 120 MiB。 +类似于 [`BLOB`](#blob-类型)，区别在于最大列长度为 16,777,215。但由于 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-从-v50-版本开始引入) 的限制，TiDB 中默认单行存储最大不超过 6 MiB，可通过配置项将该限制调整至 120 MiB。 {{< copyable "sql" >}} @@ -131,7 +131,7 @@ MEDIUMBLOB ### `LONGBLOB` 类型 -类似于 [`BLOB`](#blob-类型)，区别在于最大列长度为 4,294,967,295。但由于 [TiDB 单列的限制](/tidb-limitations.md#单列的限制)，TiDB 中默认单列存储最大不超过 6 MB，可通过配置项将该限制调整至 120 MiB。 +类似于 [`BLOB`](#blob-类型)，区别在于最大列长度为 4,294,967,295。但由于 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-从-v50-版本开始引入) 的限制，TiDB 中默认单行存储最大不超过 6 MiB，可通过配置项将该限制调整至 120 MiB。 {{< copyable "sql" >}} diff --git a/ddl-introduction.md b/ddl-introduction.md index f9b837934517..dd53120df1bd 100644 --- a/ddl-introduction.md +++ b/ddl-introduction.md @@ -176,7 +176,15 @@ absent -> delete only -> write only -> write reorg -> public - `ADMIN CANCEL DDL JOBS job_id [, job_id]`：用于取消已经提交但未执行完成的 DDL 任务。取消完成后，执行 DDL 任务的 SQL 语句会返回 `ERROR 8214 (HY000): Cancelled DDL job` 错误。 - 取消一个已经执行完成的 DDL 任务会在 RESULT 列看到 `DDL Job:90 not found` 的错误，表示该任务已从 DDL 等待队列中被移除。 + 取消一个已经执行完成的 DDL 任务会在 `RESULT` 列看到 `DDL Job:90 not found` 的错误，表示该任务已从 DDL 等待队列中被移除。 + +- `ADMIN PAUSE DDL JOBS job_id [, job_id]`：用于暂停正在执行的 DDL 任务。执行该命令后，执行 DDL 任务的 SQL 语句体现为正在执行，后台任务暂停执行。详情参阅 [`ADMIN PAUSE DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)。（实验特性） + + 只有处于执行中或仍在等待中的 DDL 任务可以暂停，否则会在 `RESULT` 列看到 `Job 3 can't be paused now`。 + +- `ADMIN RESUME DDL JOBS job_id [, job_id]`：用于恢复已被暂停的 DDL 任务。执行该命令后，执行 DDL 任务的 SQL 语句体现为正在执行，后台任务正常执行。详情参阅 [`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)。（实验特性） + + 你只能对暂停状态的 DDL 任务进行恢复操作，否则会在 `RESULT` 列看到 `Job 3 can't be resumed`。 ## 常见问题 diff --git a/develop/dev-guide-build-cluster-in-cloud.md b/develop/dev-guide-build-cluster-in-cloud.md index 785286497ff0..14663eaa9357 100644 --- a/develop/dev-guide-build-cluster-in-cloud.md +++ b/develop/dev-guide-build-cluster-in-cloud.md @@ -1,30 +1,30 @@ --- -title: 使用 TiDB Cloud (Serverless Tier) 构建 TiDB 集群 -summary: 使用 TiDB Cloud (Serverless Tier) 构建 TiDB 集群，并连接 TiDB Cloud 集群。 +title: 使用 TiDB Serverless 构建 TiDB 集群 +summary: 使用 TiDB Serverless 构建 TiDB 集群，并连接 TiDB Serverless 集群。 aliases: ['/zh/tidb/dev/build-cluster-in-cloud'] --- -# 使用 TiDB Cloud (Serverless Tier) 构建 TiDB 集群 +# 使用 TiDB Serverless 构建 TiDB 集群 -本章节将介绍如何以最快的方式开始使用 TiDB。你将使用 [TiDB Cloud](https://en.pingcap.com/tidb-cloud) 创建并启动一个 Serverless Tier 集群，使用 TiDB SQL 客户端，插入数据。随后将从示例程序读取出数据。 +本章节将介绍如何以最快的方式开始使用 TiDB。你将使用 [TiDB Cloud](https://en.pingcap.com/tidb-cloud) 创建并启动一个 TiDB Serverless 集群，使用 TiDB SQL 客户端，插入数据。随后将从示例程序读取出数据。 若你需要在本地计算机上启动 TiDB，请参阅[本地启动 TiDB](/quick-start-with-tidb.md)。 -## 第 1 步：创建 Serverless Tier 集群 +## 第 1 步：创建 TiDB Serverless 集群 1. 如果你还未拥有 TiDB Cloud 账号，请先在此[注册](https://tidbcloud.com/free-trial)。 2. 使用你的 TiDB Cloud 账号[登录](https://tidbcloud.com/)。 登录后，默认进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面。 -3. 对于新注册的用户，TiDB Cloud 会自动为你创建一个 Serverless Tier 集群 `Cluster0`。你可以使用这个默认集群进行后续操作，也可以自行创建一个新的 Serverless Tier 集群。 +3. 对于新注册的用户，TiDB Cloud 会自动为你创建一个 TiDB Serverless 集群 `Cluster0`。你可以使用这个默认集群进行后续操作，也可以自行创建一个新的 TiDB Serverless 集群。 - 如果你想创建一个新的 Serverless Tier 集群，请进行以下操作： + 如果你想创建一个新的 TiDB Serverless 集群，请进行以下操作： 1. 点击 **Create Cluster**。 - 2. **Create Cluster** 页面默认选择 **Serverless Tier**。你可以根据需要修改集群名称、选择可用区，然后点击 **Create**。你的 Serverless Tier 集群将于 30 秒后创建完毕。 + 2. **Create Cluster** 页面默认选择 **Serverless**。你可以根据需要修改集群名称、选择可用区，然后点击 **Create**。你的 TiDB Serverless 集群将于 30 秒后创建完毕。 4. 点击目标集群名称，进入集群概览页面，然后点击右上角的 **Connect** 按钮，弹出连接对话框。 @@ -34,7 +34,7 @@ aliases: ['/zh/tidb/dev/build-cluster-in-cloud'] > **注意：** > - > 在连接到 [Serverless Tier](https://docs.pingcap.com/tidbcloud/select-cluster-tier#serverless-tier) 集群时，你需要给用户名加上前缀并使用单引号包裹用户名。你可以在 [TiDB Cloud 用户名前缀](https://docs.pingcap.com/tidbcloud/select-cluster-tier#user-name-prefix) 中获得更多信息。 + > 在连接到 [TiDB Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-serverless-beta) 集群时，你需要给用户名加上前缀并使用单引号包裹用户名。你可以在 [TiDB Cloud 用户名前缀](https://docs.pingcap.com/tidbcloud/select-cluster-tier#user-name-prefix) 中获得更多信息。 ## 第 2 步：连接到集群 @@ -117,8 +117,8 @@ aliases: ['/zh/tidb/dev/build-cluster-in-cloud'] > **注意：** > -> - 在连接 Serverless Tier 集群时，[必须使用 TLS 连接](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-tier-clusters)。 -> - 如果你在连接时遇到问题，可阅读 [TiDB Cloud Serverless Tier 集群安全连接](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-tier-clusters) 来获得更多信息。 +> - 在连接 TiDB Serverless 集群时，[必须使用 TLS 连接](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-tier-clusters)。 +> - 如果你在连接时遇到问题，可阅读 [TiDB Serverless 集群安全连接](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-tier-clusters) 来获得更多信息。 3. 填写密码，完成登录。 diff --git a/develop/dev-guide-choose-driver-or-orm.md b/develop/dev-guide-choose-driver-or-orm.md index 02207f869621..778bcc1622e9 100644 --- a/develop/dev-guide-choose-driver-or-orm.md +++ b/develop/dev-guide-choose-driver-or-orm.md @@ -28,7 +28,7 @@ TiDB 兼容 MySQL 的协议，但存在部分与 MySQL 不兼容或有差异的 支持等级：**Full** -按照 [MySQL 文档](https://dev.mysql.com/doc/connector-j/8.0/en/)中的说明下载并配置 Java JDBC 驱动程序即可使用。对于 TiDB v6.3.0 及以上版本，建议使用 MySQL Connector/J 8.0.29 及以上版本。 +按照 [MySQL 文档](https://dev.mysql.com/doc/connector-j/8.0/en/)中的说明下载并配置 Java JDBC 驱动程序即可使用。对于 TiDB v6.3.0 及以上版本，建议使用 MySQL Connector/J 8.0.33 及以上版本。 > **建议：** > @@ -272,7 +272,7 @@ go get -u gorm.io/driver/mysql
-支持等级：**Compatible** +支持等级：**Full** [Django](https://docs.djangoproject.com/) 是一个流行的 Python 的开发框架，你可以使用 `pip install Django==3.2.16 django-tidb>=3.0.0` 获取你的应用程序的所有依赖项。建议使用 Django **3.2.16** 及以上版本。 diff --git a/develop/dev-guide-connect-to-tidb.md b/develop/dev-guide-connect-to-tidb.md index fdaa400c3c74..3c43b49abf40 100644 --- a/develop/dev-guide-connect-to-tidb.md +++ b/develop/dev-guide-connect-to-tidb.md @@ -8,7 +8,7 @@ aliases: ['/zh/tidb/dev/connect-to-tidb'] **TiDB** 高度兼容 **MySQL** 协议，全量的客户端连接参数列表，请参阅 [MySQL Client Options](https://dev.mysql.com/doc/refman/5.7/en/mysql-command-options.html)。 -TiDB 支持 [MySQL 客户端/服务器协议](https://dev.mysql.com/doc/internals/en/client-server-protocol.html)。这使得大多数客户端驱动程序和 ORM 框架可以像连接到 MySQL 一样地连接到 TiDB。 +TiDB 支持 [MySQL 客户端/服务器协议](https://dev.mysql.com/doc/dev/mysql-server/latest/PAGE_PROTOCOL.html)。这使得大多数客户端驱动程序和 ORM 框架可以像连接到 MySQL 一样地连接到 TiDB。 ## MySQL diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index ef57465332a5..cdc2dae1f45c 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -13,7 +13,7 @@ aliases: ['/zh/tidb/dev/connection-parameters'] TiDB (MySQL) 连接建立是比较昂贵的操作（至少对于 OLTP 来讲），除了建立 TCP 连接外还需要进行连接鉴权操作，所以客户端通常会把 TiDB (MySQL) 连接保存到连接池中进行复用。 -Java 的连接池实现很多 ([HikariCP](https://github.com/brettwooldridge/HikariCP), [tomcat-jdbc](https://tomcat.apache.org/tomcat-10.1-doc/jdbc-pool.html), [durid](https://github.com/alibaba/druid), [c3p0](https://www.mchange.com/projects/c3p0/), [dbcp](https://commons.apache.org/proper/commons-dbcp/))，TiDB 不会限定使用的连接池，应用可以根据业务特点自行选择连接池实现。 +Java 的连接池实现很多 ([HikariCP](https://github.com/brettwooldridge/HikariCP), [tomcat-jdbc](https://tomcat.apache.org/tomcat-10.1-doc/jdbc-pool.html), [druid](https://github.com/alibaba/druid), [c3p0](https://www.mchange.com/projects/c3p0/), [dbcp](https://commons.apache.org/proper/commons-dbcp/))，TiDB 不会限定使用的连接池，应用可以根据业务特点自行选择连接池实现。 ### 连接数配置 diff --git a/develop/dev-guide-create-database.md b/develop/dev-guide-create-database.md index 489cf5242b7b..637f8bce2b44 100644 --- a/develop/dev-guide-create-database.md +++ b/develop/dev-guide-create-database.md @@ -16,7 +16,7 @@ aliases: ['/zh/tidb/dev/create-database'] 在阅读本页面之前，你需要准备以下事项： -- [使用 TiDB Cloud (Serverless Tier) 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [使用 TiDB Serverless 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md)。 - 阅读[数据库模式概览](/develop/dev-guide-schema-design-overview.md)。 ## 什么是数据库 diff --git a/develop/dev-guide-create-secondary-indexes.md b/develop/dev-guide-create-secondary-indexes.md index 420369bc21c9..ff13825529c9 100644 --- a/develop/dev-guide-create-secondary-indexes.md +++ b/develop/dev-guide-create-secondary-indexes.md @@ -12,7 +12,7 @@ aliases: ['/zh/tidb/dev/create-secondary-indexes'] 在阅读本页面之前，你需要准备以下事项： -- [使用 TiDB Cloud (Serverless Tier) 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [使用 TiDB Serverless 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md)。 - 阅读[数据库模式概览](/develop/dev-guide-schema-design-overview.md)。 - [创建一个数据库](/develop/dev-guide-create-database.md)。 - [创建表](/develop/dev-guide-create-table.md)。 diff --git a/develop/dev-guide-create-table.md b/develop/dev-guide-create-table.md index cdb6c00e3366..4f6cedf57e8d 100644 --- a/develop/dev-guide-create-table.md +++ b/develop/dev-guide-create-table.md @@ -16,7 +16,7 @@ aliases: ['/zh/tidb/dev/create-table'] 在阅读本页面之前，你需要准备以下事项： -- [使用 TiDB Cloud (Serverless Tier) 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [使用 TiDB Serverless 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md)。 - 阅读[数据库模式概览](/develop/dev-guide-schema-design-overview.md)。 - [创建一个数据库](/develop/dev-guide-create-database.md)。 @@ -60,9 +60,9 @@ CREATE TABLE `bookshop`.`users` ( **参数描述** -- `{column_name}`: 列名。 -- `{data_type}`: 列的[数据类型](/basic-features.md#数据类型函数和操作符)。 -- `{column_qualification}`: 列的限定条件，如**列级约束**或[生成列（实验功能）](/generated-columns.md)子句。 +- `{column_name}`：列名。 +- `{data_type}`：列的[数据类型](/basic-features.md#数据类型函数和操作符)。 +- `{column_qualification}`：列的限定条件，如**列级约束**或[生成列](/generated-columns.md)子句。 可以为 `users` 表添加一些列，如他们的唯一标识 `id`，余额 `balance` 及昵称 `nickname`。 @@ -107,7 +107,7 @@ CREATE TABLE `bookshop`.`books` ( > **注意：** > -> TiDB 中，关于 **Primary Key** 的默认定义与 MySQL 常用存储引擎 [InnoDB](https://mariadb.com/kb/en/innodb/) 不一致。**InnoDB** 中，**Primary Key** 的语义为：唯一，不为空，**且为聚簇索引**。 +> TiDB 中，关于 **Primary Key** 的默认定义与 MySQL 常用存储引擎 [InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html) 不一致。**InnoDB** 中，**Primary Key** 的语义为：唯一，不为空，**且为聚簇索引**。 > > 而在 TiDB 中，**Primary Key** 的定义为：唯一，不为空。但主键不保证为**聚簇索引**。而是由另一组关键字 `CLUSTERED`、`NONCLUSTERED` 额外控制 **Primary Key** 是否为聚簇索引，若不指定，则由系统变量 `@@global.tidb_enable_clustered_index` 影响，具体说明请看[此文档](/clustered-indexes.md)。 @@ -263,7 +263,7 @@ ALTER TABLE `bookshop`.`ratings` SET TIFLASH REPLICA 1; > **注意：** > -> 如果你的集群，不包含 TiFlash 节点，此 SQL 语句将会报错：`1105 - the tiflash replica count: 1 should be less than the total tiflash server count: 0` 你可以[使用 TiDB Cloud (Serverless Tier) 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md#第-1-步创建-serverless-tier-集群) 来创建一个含有 TiFlash 的集群。 +> 如果你的集群，不包含 TiFlash 节点，此 SQL 语句将会报错：`1105 - the tiflash replica count: 1 should be less than the total tiflash server count: 0` 你可以[使用 TiDB Serverless 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md#第-1-步创建-tidb-serverless-集群) 来创建一个含有 TiFlash 的集群。 随后正常进行查询即可： diff --git a/develop/dev-guide-delete-data.md b/develop/dev-guide-delete-data.md index b2dfffb5c094..8a8a2a494bf3 100644 --- a/develop/dev-guide-delete-data.md +++ b/develop/dev-guide-delete-data.md @@ -12,7 +12,7 @@ aliases: ['/zh/tidb/dev/delete-data'] 在阅读本页面之前，你需要准备以下事项： -- [使用 TiDB Cloud (Serverless Tier) 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [使用 TiDB Serverless 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md)。 - 阅读[数据库模式概览](/develop/dev-guide-schema-design-overview.md)，并[创建数据库](/develop/dev-guide-create-database.md)、[创建表](/develop/dev-guide-create-table.md)、[创建二级索引](/develop/dev-guide-create-secondary-indexes.md)。 - 需先[插入数据](/develop/dev-guide-insert-data.md)才可删除。 diff --git a/develop/dev-guide-insert-data.md b/develop/dev-guide-insert-data.md index d6b055317fad..7006c641fb61 100644 --- a/develop/dev-guide-insert-data.md +++ b/develop/dev-guide-insert-data.md @@ -14,7 +14,7 @@ aliases: ['/zh/tidb/dev/insert-data'] 在阅读本页面之前，你需要准备以下事项： -- [使用 TiDB Cloud (Serverless Tier) 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [使用 TiDB Serverless 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md)。 - 阅读[数据库模式概览](/develop/dev-guide-schema-design-overview.md)，并[创建数据库](/develop/dev-guide-create-database.md)、[创建表](/develop/dev-guide-create-table.md)、[创建二级索引](/develop/dev-guide-create-secondary-indexes.md)。 ## 插入行 diff --git a/develop/dev-guide-proxysql-integration.md b/develop/dev-guide-proxysql-integration.md index 5b3590f540ff..ee884a4a4c88 100644 --- a/develop/dev-guide-proxysql-integration.md +++ b/develop/dev-guide-proxysql-integration.md @@ -20,7 +20,7 @@ summary: 介绍 TiDB 与 ProxySQL 集成的方法。
-请参考[使用 TiDB Cloud (Serverless Tier) 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md)。 +请参考[使用 TiDB Serverless 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md)。
diff --git a/develop/dev-guide-sample-application-django.md b/develop/dev-guide-sample-application-django.md index 3a783cf5d055..f1b55a50e8a0 100644 --- a/develop/dev-guide-sample-application-django.md +++ b/develop/dev-guide-sample-application-django.md @@ -29,7 +29,7 @@ summary: 给出一个 Django 构建 TiDB 应用程序示例。
-[创建 Serverless Tier 集群](/develop/dev-guide-build-cluster-in-cloud.md#第-1-步创建-serverless-tier-集群)。 +[创建 TiDB Serverless 集群](/develop/dev-guide-build-cluster-in-cloud.md#第-1-步创建-tidb-serverless-集群)。
@@ -72,7 +72,7 @@ summary: 给出一个 Django 构建 TiDB 应用程序示例。 ### 第 4 步第 1 部分：TiDB Cloud 更改参数 -若你使用 TiDB Cloud Serverless Tier 集群，更改 `example_project/settings.py` 中的 `DATABASES` 参数： +若你使用 TiDB Serverless 集群，更改 `example_project/settings.py` 中的 `DATABASES` 参数： ```python DATABASES = { @@ -87,9 +87,9 @@ DATABASES = { } ``` -另外，由于 TiDB Cloud Serverless Tier 需要使用 SSL 连接。因此，需要提供 CA 证书路径。你可以在 [TiDB Cloud Serverless Tier 安全连接文档](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-tier-clusters#where-is-the-ca-root-path-on-my-system) 中查看不同操作系统的 CA 证书路径。 +另外，由于 TiDB Serverless 需要使用 SSL 连接。因此，需要提供 CA 证书路径。你可以在 [TiDB Serverless 安全连接文档](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-tier-clusters#where-is-the-ca-root-path-on-my-system) 中查看不同操作系统的 CA 证书路径。 -若你设定的密码为 `123456`，而且从 TiDB Cloud Serverless Tier 集群面板中得到的连接信息为： +若你设定的密码为 `123456`，而且从 TiDB Serverless 集群面板中得到的连接信息为： - Endpoint: `xxx.tidbcloud.com` - Port: `4000` diff --git a/develop/dev-guide-sample-application-golang.md b/develop/dev-guide-sample-application-golang.md index dad286442e49..2e2066422f79 100644 --- a/develop/dev-guide-sample-application-golang.md +++ b/develop/dev-guide-sample-application-golang.md @@ -22,7 +22,7 @@ summary: 给出一个 TiDB 和 Golang 的简单 CRUD 应用程序示例。
-[创建 Serverless Tier 集群](/develop/dev-guide-build-cluster-in-cloud.md#第-1-步创建-serverless-tier-集群)。 +[创建 TiDB Serverless 集群](/develop/dev-guide-build-cluster-in-cloud.md#第-1-步创建-tidb-serverless-集群)。
@@ -750,13 +750,13 @@ mysql --host 127.0.0.1 --port 4000 -u root -若你使用 TiDB Cloud Serverless Tier 集群，更改 `gorm.go` 内 `dsn` 参数值： +若你使用 TiDB Serverless 集群，更改 `gorm.go` 内 `dsn` 参数值： ```go dsn := "root:@tcp(127.0.0.1:4000)/test?charset=utf8mb4" ``` -若你设定的密码为 `123456`，而且从 TiDB Cloud Serverless Tier 集群面板中得到的连接信息为： +若你设定的密码为 `123456`，而且从 TiDB Serverless 集群面板中得到的连接信息为： - Endpoint: `xxx.tidbcloud.com` - Port: `4000` @@ -777,13 +777,13 @@ dsn := "2aEp24QWEDLqRFs.root:123456@tcp(xxx.tidbcloud.com:4000)/test?charset=utf
-若你使用 TiDB Cloud Serverless Tier 集群，更改 `sqldriver.go` 内 `dsn` 参数的值： +若你使用 TiDB Serverless 集群，更改 `sqldriver.go` 内 `dsn` 参数的值： ```go dsn := "root:@tcp(127.0.0.1:4000)/test?charset=utf8mb4" ``` -若你设定的密码为 `123456`，而且从 TiDB Cloud Serverless Tier 集群面板中得到的连接信息为： +若你设定的密码为 `123456`，而且从 TiDB Serverless 集群面板中得到的连接信息为： - Endpoint: `xxx.tidbcloud.com` - Port: `4000` diff --git a/develop/dev-guide-sample-application-java.md b/develop/dev-guide-sample-application-java.md index ffc787ebc2fd..a02361be8439 100644 --- a/develop/dev-guide-sample-application-java.md +++ b/develop/dev-guide-sample-application-java.md @@ -32,7 +32,7 @@ aliases: ['/zh/tidb/dev/sample-application-java']
-[创建 Serverless Tier 集群](/develop/dev-guide-build-cluster-in-cloud.md#第-1-步创建-serverless-tier-集群)。 +[创建 TiDB Serverless 集群](/develop/dev-guide-build-cluster-in-cloud.md#第-1-步创建-tidb-serverless-集群)。
@@ -1463,7 +1463,7 @@ mysql --host 127.0.0.1 --port 4000 -u root -若你使用 TiDB Cloud Serverless Tier 集群，更改 `mybatis-config.xml` 内关于 `dataSource.url`、`dataSource.username`、`dataSource.password` 的参数： +若你使用 TiDB Serverless 集群，更改 `mybatis-config.xml` 内关于 `dataSource.url`、`dataSource.username`、`dataSource.password` 的参数： ```xml @@ -1506,7 +1506,7 @@ mysql --host 127.0.0.1 --port 4000 -u root ``` -若你设定的密码为 `123456`，而且从 TiDB Cloud Serverless Tier 集群面板中得到的连接信息为： +若你设定的密码为 `123456`，而且从 TiDB Serverless 集群面板中得到的连接信息为： - Endpoint: `xxx.tidbcloud.com` - Port: `4000` @@ -1538,7 +1538,7 @@ mysql --host 127.0.0.1 --port 4000 -u root -若你使用 TiDB Cloud Serverless Tier 集群，更改 `hibernate.cfg.xml` 内关于 `hibernate.connection.url`、`hibernate.connection.username`、`hibernate.connection.password` 的参数： +若你使用 TiDB Serverless 集群，更改 `hibernate.cfg.xml` 内关于 `hibernate.connection.url`、`hibernate.connection.username`、`hibernate.connection.password` 的参数： ```xml @@ -1566,7 +1566,7 @@ mysql --host 127.0.0.1 --port 4000 -u root ``` -若你设定的密码为 `123456`，而且从 TiDB Cloud Serverless Tier 集群面板中得到的连接信息为： +若你设定的密码为 `123456`，而且从 TiDB Serverless 集群面板中得到的连接信息为： - Endpoint: `xxx.tidbcloud.com` - Port: `4000` @@ -1604,7 +1604,7 @@ mysql --host 127.0.0.1 --port 4000 -u root -若你使用 TiDB Cloud Serverless Tier 集群，更改 `JDBCExample.java` 内关于 Host、Port、User、Password 的参数： +若你使用 TiDB Serverless 集群，更改 `JDBCExample.java` 内关于 Host、Port、User、Password 的参数： ```java mysqlDataSource.setServerName("localhost"); @@ -1614,7 +1614,7 @@ mysqlDataSource.setUser("root"); mysqlDataSource.setPassword(""); ``` -若你设定的密码为 `123456`，而且从 TiDB Cloud Serverless Tier 集群面板中得到的连接信息为： +若你设定的密码为 `123456`，而且从 TiDB Serverless 集群面板中得到的连接信息为： - Endpoint: `xxx.tidbcloud.com` - Port: `4000` diff --git a/develop/dev-guide-sample-application-python.md b/develop/dev-guide-sample-application-python.md index a97557506be2..a77ae2761d54 100644 --- a/develop/dev-guide-sample-application-python.md +++ b/develop/dev-guide-sample-application-python.md @@ -22,7 +22,7 @@ summary: 给出一个 TiDB 和 Python 的简单 CRUD 应用程序示例。
-[创建 Serverless Tier 集群](/develop/dev-guide-build-cluster-in-cloud.md#第-1-步创建-serverless-tier-集群)。 +[创建 TiDB Serverless 集群](/develop/dev-guide-build-cluster-in-cloud.md#第-1-步创建-tidb-serverless-集群)。
@@ -835,7 +835,7 @@ mycli --host 127.0.0.1 --port 4000 -u root --no-warn < player_init.sql ### 第 3 步第 2 部分：TiDB Cloud 更改参数 -若你使用了 TiDB Cloud Serverless Tier 集群，此处需使用系统本地的 CA 证书，并将证书路径记为 `` 以供后续指代。请参考以下系统相关的证书路径地址： +若你使用了 TiDB Serverless 集群，此处需使用系统本地的 CA 证书，并将证书路径记为 `` 以供后续指代。请参考以下系统相关的证书路径地址： @@ -865,19 +865,19 @@ mycli --host 127.0.0.1 --port 4000 -u root --no-warn < player_init.sql -若设置后仍有证书错误，请查阅 [TiDB Cloud Serverless Tier 安全连接文档](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-tier-clusters)。 +若设置后仍有证书错误，请查阅 [TiDB Serverless 安全连接文档](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-tier-clusters)。
-若你使用 TiDB Cloud Serverless Tier 集群，更改 `sqlalchemy_example.py` 内 `create_engine` 函数的入参： +若你使用 TiDB Serverless 集群，更改 `sqlalchemy_example.py` 内 `create_engine` 函数的入参： ```python engine = create_engine('mysql://root:@127.0.0.1:4000/test') ``` -若你设定的密码为 `123456`，而且从 TiDB Cloud Serverless Tier 集群面板中得到的连接信息为： +若你设定的密码为 `123456`，而且从 TiDB Serverless 集群面板中得到的连接信息为： - Endpoint: `xxx.tidbcloud.com` - Port: `4000` @@ -898,13 +898,13 @@ engine = create_engine('mysql://2aEp24QWEDLqRFs.root:123456@xxx.tidbcloud.com:40
-若你使用 TiDB Cloud Serverless Tier 集群，更改 `peewee_example.py` 内 `connect` 函数的入参： +若你使用 TiDB Serverless 集群，更改 `peewee_example.py` 内 `connect` 函数的入参： ```python db = connect('mysql://root:@127.0.0.1:4000/test') ``` -若你设定的密码为 `123456`，而且从 TiDB Cloud Serverless Tier 集群面板中得到的连接信息为： +若你设定的密码为 `123456`，而且从 TiDB Serverless 集群面板中得到的连接信息为： - Endpoint: `xxx.tidbcloud.com` - Port: `4000` @@ -932,7 +932,7 @@ db = connect('mysql://root:@127.0.0.1:4000/test')
-若你使用 TiDB Cloud Serverless Tier 集群，更改 `mysqlclient_example.py` 内 `get_connection` 函数： +若你使用 TiDB Serverless 集群，更改 `mysqlclient_example.py` 内 `get_connection` 函数： ```python def get_connection(autocommit: bool = True) -> MySQLdb.Connection: @@ -946,7 +946,7 @@ def get_connection(autocommit: bool = True) -> MySQLdb.Connection: ) ``` -若你设定的密码为 `123456`，而且从 TiDB Cloud Serverless Tier 集群面板中得到的连接信息为： +若你设定的密码为 `123456`，而且从 TiDB Serverless 集群面板中得到的连接信息为： - Endpoint: `xxx.tidbcloud.com` - Port: `4000` @@ -974,7 +974,7 @@ def get_connection(autocommit: bool = True) -> MySQLdb.Connection:
-若你使用 TiDB Cloud Serverless Tier 集群，更改 `pymysql_example.py` 内 `get_connection` 函数： +若你使用 TiDB Serverless 集群，更改 `pymysql_example.py` 内 `get_connection` 函数： ```python def get_connection(autocommit: bool = False) -> Connection: @@ -987,7 +987,7 @@ def get_connection(autocommit: bool = False) -> Connection: autocommit=autocommit) ``` -若你设定的密码为 `123456`，而且从 TiDB Cloud Serverless Tier 集群面板中得到的连接信息为： +若你设定的密码为 `123456`，而且从 TiDB Serverless 集群面板中得到的连接信息为： - Endpoint: `xxx.tidbcloud.com` - Port: `4000` @@ -1013,7 +1013,7 @@ def get_connection(autocommit: bool = False) -> Connection:
-若你使用 TiDB Cloud Serverless Tier 集群，更改 `mysql_connector_python_example.py` 内 `get_connection` 函数： +若你使用 TiDB Serverless 集群，更改 `mysql_connector_python_example.py` 内 `get_connection` 函数： ```python def get_connection(autocommit: bool = True) -> MySQLConnection: @@ -1026,7 +1026,7 @@ def get_connection(autocommit: bool = True) -> MySQLConnection: return connection ``` -若你设定的密码为 `123456`，而且从 TiDB Cloud Serverless Tier 集群面板中得到的连接信息为： +若你设定的密码为 `123456`，而且从 TiDB Serverless 集群面板中得到的连接信息为： - Endpoint: `xxx.tidbcloud.com` - Port: `4000` diff --git a/develop/dev-guide-sample-application-spring-boot.md b/develop/dev-guide-sample-application-spring-boot.md index f16d9fbe07fe..67d13834e58d 100644 --- a/develop/dev-guide-sample-application-spring-boot.md +++ b/develop/dev-guide-sample-application-spring-boot.md @@ -31,7 +31,7 @@ aliases: ['/zh/tidb/dev/sample-application-spring-boot']
-[创建 Serverless Tier 集群](/develop/dev-guide-build-cluster-in-cloud.md#第-1-步创建-serverless-tier-集群)。 +[创建 TiDB Serverless 集群](/develop/dev-guide-build-cluster-in-cloud.md#第-1-步创建-tidb-serverless-集群)。
@@ -118,7 +118,7 @@ aliases: ['/zh/tidb/dev/sample-application-spring-boot'] ### 第 5 步第 1 部分：TiDB Cloud 更改参数 -若你使用 TiDB Cloud Serverless Tier 集群，更改 `application.yml`（位于 `src/main/resources` 内）关于 `spring.datasource.url`、`spring.datasource.username`、`spring.datasource.password` 的参数： +若你使用 TiDB Serverless 集群，更改 `application.yml`（位于 `src/main/resources` 内）关于 `spring.datasource.url`、`spring.datasource.username`、`spring.datasource.password` 的参数： ```yaml spring: @@ -134,7 +134,7 @@ spring: ddl-auto: create-drop ``` -若你设定的密码为 `123456`，而且从 TiDB Cloud Serverless Tier 集群面板中得到的连接信息为： +若你设定的密码为 `123456`，而且从 TiDB Serverless 集群面板中得到的连接信息为： - Endpoint: `xxx.tidbcloud.com` - Port: `4000` diff --git a/develop/dev-guide-schema-design-overview.md b/develop/dev-guide-schema-design-overview.md index 68743979fc0f..a27a63de4d9e 100644 --- a/develop/dev-guide-schema-design-overview.md +++ b/develop/dev-guide-schema-design-overview.md @@ -26,7 +26,7 @@ TiDB 集群包含一个名为 `test` 的数据库。但建议你自行创建数 TiDB 语境中的 Table 或者说表，从属于某个[数据库](#数据库-database)。 -表包含数据**行**。每行数据中的每个值都属于一个特定的**列**。每列都只允许单一数据类型的数据值。列可添加[约束](/constraints.md)来进一步限定。你还可以添加[生成列（实验特性）](/generated-columns.md)用于计算。 +表包含数据**行**。每行数据中的每个值都属于一个特定的**列**。每列都只允许单一数据类型的数据值。列可添加[约束](/constraints.md)来进一步限定。你还可以添加[生成列](/generated-columns.md)用于计算。 ## 索引 Index @@ -39,7 +39,7 @@ TiDB 语境中的 Table 或者说表，从属于某个[数据库](#数据库-dat > **注意：** > -> TiDB 中，关于 **Primary Key** 的默认定义与 MySQL 常用存储引擎 [InnoDB](https://mariadb.com/kb/en/innodb/) 不一致。**InnoDB** 中，**Primary Key** 的语义为：唯一，不为空，**且为聚簇索引**。 +> TiDB 中，关于 **Primary Key** 的默认定义与 MySQL 常用存储引擎 [InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html) 不一致。**InnoDB** 中，**Primary Key** 的语义为：唯一，不为空，**且为聚簇索引**。 > > 而在 TiDB 中，**Primary Key** 的定义为：唯一，不为空。但主键不保证为**聚簇索引**。而是由另一组关键字 `CLUSTERED`、`NONCLUSTERED` 额外控制 **Primary Key** 是否为聚簇索引，若不指定，则由系统变量 `@@global.tidb_enable_clustered_index` 影响，具体说明请看[聚簇索引](/clustered-indexes.md)。 diff --git a/develop/dev-guide-third-party-support.md b/develop/dev-guide-third-party-support.md index a9070752562c..4206cc39525a 100644 --- a/develop/dev-guide-third-party-support.md +++ b/develop/dev-guide-third-party-support.md @@ -251,8 +251,8 @@ PingCAP 与开源社区合作，通过三方工具提供以下支持： Python Django - v4.0.5 - Compatible + v4.1 + Full django-tidb TiDB 和 Django 的简单 CRUD 应用程序 diff --git a/develop/dev-guide-tidb-crud-sql.md b/develop/dev-guide-tidb-crud-sql.md index d847b296a21b..b0be1c1519ad 100644 --- a/develop/dev-guide-tidb-crud-sql.md +++ b/develop/dev-guide-tidb-crud-sql.md @@ -10,7 +10,7 @@ aliases: ['/zh/tidb/dev/tidb-crud-sql'] ## 在开始之前 -请确保你已经连接到 TiDB 集群，若未连接，请参考[使用 TiDB Cloud (Serverless Tier) 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md#第-1-步创建-serverless-tier-集群)来创建一个 Serverless Tier 集群。 +请确保你已经连接到 TiDB 集群，若未连接，请参考[使用 TiDB Serverless 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md#第-1-步创建-tidb-serverless-集群)来创建一个 TiDB Serverless 集群。 ## 基本 SQL 操作 diff --git a/develop/dev-guide-timeouts-in-tidb.md b/develop/dev-guide-timeouts-in-tidb.md index 053e3829f355..68e503fa860f 100644 --- a/develop/dev-guide-timeouts-in-tidb.md +++ b/develop/dev-guide-timeouts-in-tidb.md @@ -26,7 +26,7 @@ TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新 ## SQL 执行时间超时 -TiDB 还提供了一个系统变量来限制单条 SQL 语句的执行时间：max_execution_time，它的默认值为 0，表示无限制。`max_execution_time` 目前对所有类型的 statement 生效，并非只对 SELECT 语句生效。其单位为 ms，但实际精度在 100ms 级别，而非更准确的毫秒级别。 +TiDB 还提供了一个系统变量来限制单条 SQL 语句的执行时间，仅对“只读”语句生效：`max_execution_time`，它的默认值为 0，表示无限制。`max_execution_time` 的单位为 ms，但实际精度在 100ms 级别，而非更准确的毫秒级别。 ## JDBC 查询超时 @@ -36,6 +36,6 @@ TiDB 提供了三个与 MySQL 兼容的超时控制参数： - **wait_timeout**，控制与 Java 应用连接的非交互式空闲超时时间。在 TiDB v5.4 及以上版本中，默认值为 `28800` 秒，即空闲超时为 8 小时。在 v5.4 之前，默认值为 `0`，即没有时间限制。 - **interactive_timeout**，控制与 Java 应用连接的交互式空闲超时时间，默认值为 8 小时。 -- **max_execution_time**，控制连接中 SQL 执行的超时时间，默认值是 0，即允许连接无限忙碌（一个 SQL 语句执行无限的长的时间）。 +- **max_execution_time**，控制连接中 SQL 执行的超时时间，仅对“只读”语句生效，默认值是 0，即允许连接无限忙碌（一个 SQL 语句执行无限的长的时间）。 但在实际生产环境中，空闲连接和一直无限执行的 SQL 对数据库和应用都有不好的影响。你可以通过在应用的连接字符串中配置这两个 session 级的变量来避免空闲连接和执行时间过长的 SQL 语句。例如，设置 `sessionVariables=wait_timeout=3600（1 小时）`和 `sessionVariables=max_execution_time=300000（5 分钟）`。 diff --git a/develop/dev-guide-update-data.md b/develop/dev-guide-update-data.md index 044d11d4f449..2f743dfbecd1 100644 --- a/develop/dev-guide-update-data.md +++ b/develop/dev-guide-update-data.md @@ -15,7 +15,7 @@ aliases: ['/zh/tidb/dev/update-data'] 在阅读本页面之前，你需要准备以下事项： -- [使用 TiDB Cloud (Serverless Tier) 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md) +- [使用 TiDB Serverless 构建 TiDB 集群](/develop/dev-guide-build-cluster-in-cloud.md) - 阅读[数据库模式概览](/develop/dev-guide-schema-design-overview.md)，并[创建数据库](/develop/dev-guide-create-database.md)、[创建表](/develop/dev-guide-create-table.md)、[创建二级索引](/develop/dev-guide-create-secondary-indexes.md) - 若需使用 `UPDATE` 语句更新数据，需先[插入数据](/develop/dev-guide-insert-data.md) diff --git a/develop/dev-guide-use-stale-read.md b/develop/dev-guide-use-stale-read.md index 07b72bd8ac22..aa5bdf558f42 100644 --- a/develop/dev-guide-use-stale-read.md +++ b/develop/dev-guide-use-stale-read.md @@ -101,7 +101,7 @@ SELECT id, title, type, price FROM books AS OF TIMESTAMP '2022-04-20 15:20:00' O - `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS('2016-10-08 16:45:26', '2016-10-08 16:45:29')` 表示读取在 2016 年 10 月 8 日 16 点 45 分 26 秒到 29 秒的时间范围内尽可能新的数据。 - `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS(NOW() - INTERVAL 20 SECOND, NOW())` 表示读取 20 秒前到现在的时间范围内尽可能新的数据。 -需要注意的是，设定的时间戳或时间戳的范围不能过早或晚于当前时间。 +需要注意的是，设定的时间戳或时间戳的范围不能过早或晚于当前时间。此外 `NOW()` 默认精确到秒，当精度要求较高时，需要添加参数，例如 `NOW(3)` 精确到毫秒。详情请参考 [MySQL 文档](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_now)。 过期的数据在 TiDB 当中会由[垃圾回收器](/garbage-collection-overview.md)进行回收，数据在被清除之前会被保留一小段时间，这段时间被称为 [GC Life Time (默认 10 分钟)](/system-variables.md#tidb_gc_life_time-从-v50-版本开始引入)。每次进行 GC 时，将以当前时间减去该时间周期的值作为 **GC Safe Point**。如果尝试读取 GC Safe Point 之前数据，TiDB 会报如下错误： diff --git a/dm/dm-glossary.md b/dm/dm-glossary.md index d7591107b900..fc3599b073fc 100644 --- a/dm/dm-glossary.md +++ b/dm/dm-glossary.md @@ -12,11 +12,11 @@ aliases: ['/docs-cn/tidb-data-migration/dev/glossary/'] ### Binlog -在 TiDB DM 中，Binlog 通常指 MySQL/MariaDB 生成的 binary log 文件，具体请参考 [MySQL Binary Log](https://dev.mysql.com/doc/internals/en/binary-log.html) 与 [MariaDB Binary Log](https://mariadb.com/kb/en/library/binary-log/)。 +在 TiDB DM 中，Binlog 通常指 MySQL/MariaDB 生成的 binary log 文件，具体请参考 [MySQL Binary Log](https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_replication.html) 与 [MariaDB Binary Log](https://mariadb.com/kb/en/library/binary-log/)。 ### Binlog event -MySQL/MariaDB 生成的 Binlog 文件中的数据变更信息，具体请参考 [MySQL Binlog Event](https://dev.mysql.com/doc/internals/en/binlog-event.html) 与 [MariaDB Binlog Event](https://mariadb.com/kb/en/library/1-binlog-events/)。 +MySQL/MariaDB 生成的 Binlog 文件中的数据变更信息，具体请参考 [MySQL Binlog Event](https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_replication_binlog_event.html) 与 [MariaDB Binlog Event](https://mariadb.com/kb/en/library/1-binlog-events/)。 ### Binlog event filter diff --git a/dm/dm-open-api.md b/dm/dm-open-api.md index fee4f3dbe154..fe5396bf59f1 100644 --- a/dm/dm-open-api.md +++ b/dm/dm-open-api.md @@ -28,6 +28,8 @@ TiDB Data Migration (DM) 提供 OpenAPI 功能，你可以通过 OpenAPI 方便 > - DM 提供符合 OpenAPI 3.0.0 标准的 [Spec 文档](https://github.com/pingcap/tiflow/blob/master/dm/openapi/spec/dm.yaml)，其中包含了所有 API 的请求参数和返回体，你可自行复制到如 [Swagger Editor](https://editor.swagger.io/) 等工具中在线预览文档。 > > - 部署 DM-master 后，你可访问 `http://{master-addr}/api/v1/docs` 在线预览文档。 +> +> - 配置文件中支持的某些功能在 OpenAPI 中是不支持的，二者的功能没有完全对齐。在生产环境中，建议使用[配置文件](/dm/dm-config-overview.md)。 你可以通过 OpenAPI 完成 DM 集群的如下运维操作： diff --git a/dm/dm-precheck.md b/dm/dm-precheck.md index f21e8007a0fa..35e106cfbf45 100644 --- a/dm/dm-precheck.md +++ b/dm/dm-precheck.md @@ -88,22 +88,22 @@ tiup dmctl check-task ./task.yaml * 分表中自增主键检查 - 分表存在自增主键时返回警告。如果存在自增主键冲突，请参照[自增主键冲突处理](/dm/shard-merge-best-practices.md#自增主键冲突处理)解决。 - + #### Physical Import 检查项 -在任务配置中使用 `import-mode: "physical"` 后，会增加如下的前置检查项以保证 [Physical Import](/tidb-lightning/tidb-lightning-physical-import-mode.md) 正常运行。如果参照提示后仍然难以完成这些前置检查，你可以尝试使用 [Logical Import](/tidb-lightning/tidb-lightning-logical-import-mode.md) 进行导入。 +在任务配置中使用 `import-mode: "physical"` 后，会增加如下的前置检查项以保证[物理导入模式](/tidb-lightning/tidb-lightning-physical-import-mode.md)正常运行。如果参照提示后仍然难以完成这些前置检查，你可以尝试使用[逻辑导入模式](/tidb-lightning/tidb-lightning-logical-import-mode.md)进行导入。 * 下游数据库中的空 Region - 如果空 Region 的数量大于 `max(1000, 表的数量 * 3)`，即大于“1000”和“3 倍表数量”二者中的较大者，前置检查会向用户返回警告。可以调整 PD 相关参数加快空 Region 的合并速度，并等待空 Region 数量下降以解除警告。参见 [PD 调度策略最佳实践 - Region Merge 速度慢](/best-practices/pd-scheduling-best-practices.md#region-merge-速度慢) - + * 下游数据库中的 Region 分布 - 统计不同的 TiKV 上的 Region 数目。假设 Region 数最少的 TiKV 节点上拥有 `a` 个 Region，Region 数最多的 TiKV 节点上拥有 `b` 个 Region，如果 a/b 小于 0.75，则前置检查会向用户返回警告。可以调整 PD 相关参数加快 Region 调度速度，并等待 Region 数目变化以解除警告。参见 [PD 调度策略最佳实践 - Leader/Region 分布不均衡](/best-practices/pd-scheduling-best-practices.md#leaderregion-分布不均衡) * 下游数据库 TiDB、PD、TiKV 组件的版本 - - Physical Import 需要调用 TiDB、PD、TiKV 接口，如果版本不符合要求，会返回错误。 + - 物理导入模式需要调用 TiDB、PD、TiKV 接口，如果版本不符合要求，会返回错误。 * 下游数据库的剩余空间 @@ -111,7 +111,7 @@ tiup dmctl check-task ./task.yaml * 下游数据库是否在运行与 Physical Import 不兼容的任务 - - 目前 Physical Import 不兼容 [TiCDC](/ticdc/ticdc-overview.md)、[PITR](/br/br-pitr-guide.md) 任务，如果发现下游数据库正在运行这些任务，前置检查会返回错误。 + - 目前物理导入模式不兼容 [TiCDC](/ticdc/ticdc-overview.md)、[PITR](/br/br-pitr-guide.md) 任务，如果发现下游数据库正在运行这些任务，前置检查会返回错误。 ### 增量数据迁移检查项 @@ -154,11 +154,11 @@ tiup dmctl check-task ./task.yaml |schema_of_shard_tables|检查上游 MySQL 多实例分库分表的表结构一致性| |auto_increment_ID|检查上游 MySQL 多实例分库分表的自增主键冲突| |online_ddl|检查上游是否处于 [Online-DDL](/dm/feature-online-ddl.md) 过程中| -|empty_region|Physical Import 检查空 Region 的数目| -|region_distribution|Physical Import 检查 Region 的分布| +|empty_region|物理导入模式检查空 Region 的数目| +|region_distribution|物理导入模式检查 Region 的分布| |downstream_version|检查下游数据库 TiDB、PD、TiKV 的版本| |free_space|检查下游数据库的剩余空间| -|downstream_mutex_features|检查下游数据库是否存在与 Physical Import 不兼容的任务| +|downstream_mutex_features|检查下游数据库是否存在与物理导入模式不兼容的任务| > **注意：** > diff --git a/dm/feature-shard-merge-optimistic.md b/dm/feature-shard-merge-optimistic.md index f830238cf8bd..17b9ca85e7b2 100644 --- a/dm/feature-shard-merge-optimistic.md +++ b/dm/feature-shard-merge-optimistic.md @@ -20,7 +20,7 @@ DM 支持在线上执行分库分表的 DDL 语句（通称 Sharding DDL）， ## 乐观协调模式的配置 -在任务的配置文件中指定 `shard-mode` 为 `optimistic` 则使用“乐观协调”模式，示例配置文件可以参考 [DM 任务完整配置文件介绍](/dm/task-configuration-file-full.md)。 +在任务的配置文件中指定 `shard-mode` 为 `optimistic` 则使用“乐观协调”模式，可通过开启 `strict-optimistic-shard-mode` 限制“乐观协调”模式的行为，示例配置文件可以参考 [DM 任务完整配置文件介绍](/dm/task-configuration-file-full.md)。 ## 使用限制 @@ -41,7 +41,7 @@ DM 支持在线上执行分库分表的 DDL 语句（通称 Sharding DDL）， - 增加没有默认值且非空的列：`ALTER TABLE table_name ADD COLUMN column_1 NOT NULL;`。 - 重命名索引：`ALTER TABLE table_name RENAME INDEX index_1 TO index_2;`。 -各分表在执行以上 DDL 时，若顺序不同将导致同步中断，例如下述场景： +各分表在执行以上 DDL 时，如果指定 `strict-optimistic-shard-mode: true`，会直接中断任务并报错。如果指定 `strict-optimistic-shard-mode: false` 或未指定，若分表 DDL 顺序不同，将导致同步中断，例如下述场景： - 分表 1 先重命名列，再修改列类型 1. 重命名列：`ALTER TABLE table_name RENAME COLUMN column_1 TO column_2;`。 diff --git a/dm/maintain-dm-using-tiup.md b/dm/maintain-dm-using-tiup.md index 2bae43045072..10ba08e4ea51 100644 --- a/dm/maintain-dm-using-tiup.md +++ b/dm/maintain-dm-using-tiup.md @@ -242,7 +242,7 @@ Flags: -N, --node strings Specify the nodes --overwrite Use this package in the future scale-out operations -R, --role strings Specify the role - --transfer-timeout int Timeout in seconds when transferring dm-master leaders (default 300) + --transfer-timeout int Timeout in seconds when transferring dm-master leaders (default 600) Global Flags: --native-ssh Use the native SSH client installed on local system instead of the build-in one. @@ -390,7 +390,7 @@ tiup dmctl --master-addr master1:8261 operate-source create /tmp/source1.yml 此时可以通过命令行参数 `--native-ssh` 启用系统自带命令行： -- 部署集群：`tiup dm deploy --native-ssh`，其中 `` 为集群名称，`` 为 DM 集群版本（例如 `v6.5.0`），`` 为拓扑文件路径 +- 部署集群：`tiup dm deploy --native-ssh`，其中 `` 为集群名称，`` 为 DM 集群版本（例如 `v7.2.0`），`` 为拓扑文件路径 - 启动集群：`tiup dm start --native-ssh` - 升级集群：`tiup dm upgrade ... --native-ssh` diff --git a/dm/quick-start-create-task.md b/dm/quick-start-create-task.md index 5f0e2fba298d..578de1ebb54e 100644 --- a/dm/quick-start-create-task.md +++ b/dm/quick-start-create-task.md @@ -69,7 +69,7 @@ docker run --rm --name mysql-3307 -p 3307:3307 -e MYSQL_ALLOW_EMPTY_PASSWORD=tru {{< copyable "shell-regular" >}} ```bash -wget https://download.pingcap.org/tidb-community-server-v7.0.0-linux-amd64.tar.gz +wget https://download.pingcap.org/tidb-community-server-v7.2.0-linux-amd64.tar.gz tar -xzvf tidb-latest-linux-amd64.tar.gz mv tidb-latest-linux-amd64/bin/tidb-server ./ ./tidb-server -P 4000 --store mocktikv --log-file "./tidb.log" & diff --git a/dm/task-configuration-file-full.md b/dm/task-configuration-file-full.md index b1177b0c9b06..0b4e7d3ab28b 100644 --- a/dm/task-configuration-file-full.md +++ b/dm/task-configuration-file-full.md @@ -24,6 +24,7 @@ name: test # 任务名称，需要全局唯一 task-mode: all # 任务模式，可设为 "full" - "只进行全量数据迁移"、"incremental" - "Binlog 实时同步"、"all" - "全量 + Binlog 实时同步" shard-mode: "pessimistic" # 任务协调模式，可选的模式有 ""、"pessimistic、"optimistic"。默认值为 "" 即无需协调。如果是分库分表合并任务，请设置为悲观协调模式 "pessimistic"。 # 在 v2.0.6 版本后乐观模式逐渐成熟，深入了解乐观协调模式的原理和使用限制后，也可以设置为乐观协调模式 "optimistic" +strict-optimistic-shard-mode: false # 仅在乐观协调模式下生效，限制乐观协调模式的行为，默认值为 false。在 v7.2.0 中引入，详见 https://docs.pingcap.com/zh/tidb/v7.2/feature-shard-merge-optimistic meta-schema: "dm_meta" # 下游储存 `meta` 信息的数据库 # timezone: "Asia/Shanghai" # 指定数据迁移任务时 SQL Session 使用的时区。DM 默认使用目标库的全局时区配置进行数据迁移，并且自动确保同步数据的正确性。使用自定义时区依然可以确保整个流程的正确性，但一般不需要手动指定。 @@ -119,31 +120,31 @@ loaders: # load 处理单元的运行配置参数 dir: "./dumped_data" # 全量阶段数据导入的模式。可以设置为如下几种模式： - # - "logical"(默认)。使用 TiDB Lightning logical import 进行导入。文档：https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-logical-import-mode - # - "physical"。使用 TiDB Lightning physical import 进行导入。文档：https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-physical-import-mode + # - "logical"(默认)。使用 TiDB Lightning 逻辑导入模式进行导入。文档：https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-logical-import-mode + # - "physical"。使用 TiDB Lightning 物理导入模式进行导入。文档：https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-physical-import-mode # 当前 "physical" 为实验特性，不建议在生产环境中使用。 import-mode: "logical" - # logical import 针对冲突数据的解决方式： + # 逻辑导入模式针对冲突数据的解决方式： # - "replace"（默认值）。表示用最新数据替代已有数据。 # - "ignore"。保留已有数据，忽略新数据。 # - "error"。插入重复数据时报错并停止同步任务。 on-duplicate-logical: "replace" - # physical import 针对冲突数据的解决方式： - # - "none"（默认）。对应 TiDB Lightning physical import 冲突数据检测的 "none" 选项 + # 物理导入模式针对冲突数据的解决方式： + # - "none"（默认）。对应 TiDB Lightning 物理导入模式冲突数据检测的 "none" 选项 # (https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-physical-import-mode-usage#冲突数据检测)， # 表示遇到冲突数据时不进行处理。该模式性能最佳，但下游数据库会遇到数据索引不一致的问题。 - # - "manual"。对应 TiDB Lightning physical import 冲突数据检测的 "remove" 选项 + # - "manual"。对应 TiDB Lightning 物理导入模式冲突数据检测的 "remove" 选项 # (https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-physical-import-mode-usage#冲突数据检测)。 # 在遇到冲突数据时将所有相互冲突的数据删除，并记录在 ${meta-schema}_${name}.conflict_error_v1 表中。 # 在本配置文件中，会记录在 dm_meta_test.conflict_error_v1 表中。全量导入阶段结束后，任务 # 会暂停并提示用户查询这张表并按照文档进行手动处理。使用 resume-task 命令让任务恢复运行并 # 进入到增量同步阶段。 on-duplicate-physical: "none" - # physical import 用作本地排序的目录位置，该选项的默认值与 dir 配置项一致。具体说明可以参见 TiDB Lightning 对存储空间的需求：https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-physical-import-mode#运行环境需求 + # 物理导入模式用作本地排序的目录位置，该选项的默认值与 dir 配置项一致。具体说明可以参见 TiDB Lightning 对存储空间的需求：https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-physical-import-mode#运行环境需求 sorting-dir-physical: "./dumped_data" # 磁盘空间限制，对应 TiDB Lightning disk-quota 配置。具体说明参见文档：https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-physical-import-mode-usage#磁盘资源配额-从-v620-版本开始引入 disk-quota-physical: "0" - # physical import 在导入完成一张表后，对每一个表执行 `ADMIN CHECKSUM TABLE ` 进行数据校验的配置： + # 物理导入模式在导入完成一张表后，对每一个表执行 `ADMIN CHECKSUM TABLE
` 进行数据校验的配置： # - "required"（默认值）。表示导入完成后进行数据校验，如果校验失败会让任务暂停，需要用户手动处理。 # - "optional"。表示导入完成后进行数据校验，如果校验失败会打印 warn 日志，任务不会暂停。 # - "off"。表示导入完成后不进行数据校验。 @@ -155,9 +156,9 @@ loaders: # load 处理单元的运行配置参数 # - "off"。表示导入完成后不进行 ANALYZE 操作。 # ANALYZE 只影响统计数据，在大部分场景下建议不开启 ANALYZE。 analyze: "off" - # Physical Import Mode 向 TiKV 写入 KV 数据的并发度。当 dm-worker 和 TiKV 网络传输速度超过万兆时，可适当增加这个值。 + # 物理导入模式向 TiKV 写入 KV 数据的并发度。当 dm-worker 和 TiKV 网络传输速度超过万兆时，可适当增加这个值。 # range-concurrency: 16 - # Physical Import Mode 向 TiKV 发送 KV 数据时是否启用压缩。目前仅支持 Gzip 压缩算法，可填写 "gzip" 或 "gz"。默认不启用压缩。 + # 物理导入模式向 TiKV 发送 KV 数据时是否启用压缩。目前仅支持 Gzip 压缩算法，可填写 "gzip" 或 "gz"。默认不启用压缩。 # compress-kv-pairs: "" # PD server 的地址，填一个即可。该值为空时，默认使用 TiDB 查询到的 PD 地址信息。 # pd-addr: "192.168.0.1:2379" @@ -222,7 +223,7 @@ mysql-instances: ## 配置顺序 -通过上面的配置文件示例，可以看出配置文件总共分为两个部分：`全局配置`和`实例配置`，其中`全局配置`又分为`基本信息配置`和`实例配置`，配置顺序如下： +通过上面的配置文件示例，可以看出配置文件总共分为两个部分：`全局配置`和`实例配置`，其中`全局配置`又分为`基本信息配置`和`功能配置集`。配置顺序如下： 1. 编辑[全局配置](#全局配置)。 2. 根据全局配置编辑[实例配置](#实例配置)。 diff --git a/download-ecosystem-tools.md b/download-ecosystem-tools.md index 37da2fecb0c3..083cbfda8787 100644 --- a/download-ecosystem-tools.md +++ b/download-ecosystem-tools.md @@ -58,7 +58,7 @@ TiDB 工具包中包含了一些常用的 TiDB 工具，例如数据导出工具 | 安装包 | 操作系统 | 架构 | SHA256 校验和 | |:---|:---|:---|:---| -| `https://download.pingcap.org/em-enterprise-server-{version}-linux-amd64.tar.gz` | Linux | amd64 | `https://download.pingcap.org/em-enterprise-server-{version}-linux-amd64.sha256` | +| `https://download.pingcap.org/em-enterprise-server-{version}-linux-amd64.tar.gz` | Linux | amd64 | `https://download.pingcap.org/em-enterprise-server-{version}-linux-amd64.tar.gz.sha256` | > **注意：** > diff --git a/dumpling-overview.md b/dumpling-overview.md index 5cc028dc5afc..ff38347cb167 100644 --- a/dumpling-overview.md +++ b/dumpling-overview.md @@ -6,7 +6,7 @@ aliases: ['/docs-cn/dev/dumpling-overview/','/docs-cn/dev/mydumper-overview/','/ # 使用 Dumpling 导出数据 -使用数据导出工具 [Dumpling](https://github.com/pingcap/dumpling)，你可以把存储在 TiDB 或 MySQL 中的数据导出为 SQL 或 CSV 格式，用于逻辑全量备份。Dumpling 也支持将数据导出到 Amazon S3 中。 +使用数据导出工具 [Dumpling](https://github.com/pingcap/tidb/tree/master/dumpling)，你可以把存储在 TiDB 或 MySQL 中的数据导出为 SQL 或 CSV 格式，用于逻辑全量备份。Dumpling 也支持将数据导出到 Amazon S3 中。 要快速了解 Dumpling 的基本功能，建议先观看下面的培训视频（时长 28 分钟）。注意本视频只作为功能介绍、学习参考，具体操作步骤和最新功能，请以文档内容为准。 @@ -38,10 +38,19 @@ TiDB 还提供了其他工具，你可以根据需要选择使用： - 支持导出到 Amazon S3 云盘。 - 针对 TiDB 进行了更多优化： - 支持配置 TiDB 单条 SQL 内存限制。 - - 针对 TiDB v4.0.0 及更新版本支持自动调整 TiDB GC 时间。 + - 针对 TiDB v4.0.0 及更新版本，如果 Dumpling 能够直接连接到 PD，则支持自动调整 TiDB GC 时间。 - 使用 TiDB 的隐藏列 `_tidb_rowid` 优化了单表内数据的并发导出性能。 - 对于 TiDB 可以设置 [tidb_snapshot](/read-historical-data.md#操作流程) 的值指定备份数据的时间点，从而保证备份的一致性，而不是通过 `FLUSH TABLES WITH READ LOCK` 来保证备份一致性。 +> **注意：** +> +> 在以下情况下，Dumpling 无法连接到 PD： +> +> - TiDB 集群正在 Kubernetes 上运行（Dumpling 本身在 Kubernetes 环境中运行时除外）。 +> - TiDB 集群正在 TiDB Cloud 上运行。 +> +> 在这种情况下，你需要手动[调整 TiDB GC 时间](#手动设置-tidb-gc-时间)，以避免导出失败。 + ## 从 TiDB/MySQL 导出数据 ### 需要的权限 @@ -66,7 +75,7 @@ dumpling -u root -P 4000 -h 127.0.0.1 --filetype sql -t 8 -o /tmp/test -r 200000 以上命令中： - `-h`、`-P`、`-u` 分别代表地址、端口、用户。如果需要密码验证，可以使用 `-p $YOUR_SECRET_PASSWORD` 将密码传给 Dumpling。 -- `-o`（或 `--output`）用于选择存储导出文件的目录，支持本地文件路径或[外部存储 URI 格式](/br/backup-and-restore-storages.md#uri-格式)。 +- `-o`（或 `--output`）用于选择存储导出文件的目录，支持本地文件的绝对路径或[外部存储 URI 格式](/br/backup-and-restore-storages.md#uri-格式)。 - `-t` 用于指定导出的线程数。增加线程数会增加 Dumpling 并发度提高导出速度，但也会加大数据库内存消耗，因此不宜设置过大。一般不超过 64。 - `-r` 用于指定单个文件的最大行数，指定该参数后 Dumpling 会开启表内并发加速导出，同时减少内存使用。当上游为 TiDB 且版本为 v3.0 或更新版本时，设置 `-r` 参数大于 0 表示使用 TiDB region 信息划分表内并发，具体取值不影响划分算法。对上游为 MySQL 且表的主键是 int 的场景，该参数也有表内并发效果。 - `-F` 选项用于指定单个文件的最大大小，单位为 `MiB`，可接受类似 `5GiB` 或 `8KB` 的输入。如果你想使用 TiDB Lightning 将该文件加载到 TiDB 实例中，建议将 `-F` 选项的值保持在 256 MiB 或以下。 @@ -291,21 +300,24 @@ Dumpling 导出 TiDB 较大单表（超过 1 TB）时，可能会因为导出数 + 调小 `--tidb-mem-quota-query` 参数到 `8589934592` (8GB) 或更小。可控制 TiDB 单条查询语句的内存使用。 + 调整 `--params "tidb_distsql_scan_concurrency=5"` 参数，即设置导出时的 session 变量 [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency) 从而减少 TiDB scan 操作的并发度。 -### 导出大规模数据时的 TiDB GC 设置 +### 手动设置 TiDB GC 时间 如果导出的 TiDB 版本为 v4.0.0 或更新版本，并且 Dumpling 可以访问 TiDB 集群的 PD 地址，Dumpling 会自动配置延长 GC 时间且不会对原集群造成影响。 -其他情况下，假如导出的数据量非常大，可以提前调长 GC 时间，以避免因为导出过程中发生 GC 导致导出失败： +但是，在以下场景中，Dumpling 无法自动调整 GC 时间： + +- 数据量非常大（超过 1 TB）。 +- Dumpling 无法直接连接到 PD，例如 TiDB 集群运行在 TiDB Cloud 上，或者 TiDB 集群运行在 Kubernetes 上且与 Dumpling 分离。 -{{< copyable "sql" >}} +在这些场景中，你必须提前手动调长 GC 时间，以避免因为导出过程中发生 GC 导致导出失败。 + +使用以下 SQL 语句手动调整 GC 时间： ```sql SET GLOBAL tidb_gc_life_time = '720h'; ``` -操作结束之后，再恢复 GC 时间为默认值 `10m`： - -{{< copyable "sql" >}} +在 Dumpling 退出后，无论导出是否成功，都必须将 GC 时间恢复为其原始值（默认值为 `10m`）。 ```sql SET GLOBAL tidb_gc_life_time = '10m'; @@ -333,7 +345,7 @@ SET GLOBAL tidb_gc_life_time = '10m'; | -s 或--statement-size | 控制 `INSERT` SQL 语句的大小，单位 bytes | | -F 或 --filesize | 将 table 数据划分出来的文件大小，需指明单位（如 `128B`, `64KiB`, `32MiB`, `1.5GiB`） | | --filetype| 导出文件类型（csv/sql） | "sql" | -| -o 或 --output | 导出本地文件路径或[外部存储 URI 格式](/br/backup-and-restore-storages.md#uri-格式) | "./export-${time}" | +| -o 或 --output | 导出本地文件的绝对路径或[外部存储 URI 格式](/br/backup-and-restore-storages.md#uri-格式) | "./export-${time}" | | -S 或 --sql | 根据指定的 sql 导出数据，该选项不支持并发导出 | | --consistency | flush: dump 前用 FTWRL
snapshot: 通过 TSO 来指定 dump 某个快照时间点的 TiDB 数据
lock: 对需要 dump 的所有表执行 `lock tables read` 命令
none: 不加锁 dump，无法保证一致性
auto: 对 MySQL 使用 --consistency flush；对 TiDB 使用 --consistency snapshot | "auto" | | --snapshot | snapshot tso，只在 consistency=snapshot 下生效 | diff --git a/ecosystem-tool-user-guide.md b/ecosystem-tool-user-guide.md index 9056c8f7cd31..84ba5f3b9539 100644 --- a/ecosystem-tool-user-guide.md +++ b/ecosystem-tool-user-guide.md @@ -28,7 +28,7 @@ TiDB 提供了 TiUP、TiDB Operator 和 TiUniManager 三种部署运维工具， #### TiUniManager -[TiUniManager](/tiunimanager/tiunimanager-overview.md) 是一款以 TiDB 数据库为核心的数据库管理平台，帮助用户在私有部署 (on-premises) 或公有云环境中管理 TiDB 集群。 +[TiUniManager](/tiunimanager/tiunimanager-overview.md) 是一款以 TiDB 数据库为核心的数据库管理平台，帮助用户在本地部署环境或公有云环境中管理 TiDB 集群。 TiUniManager 不仅提供对 TiDB 集群的全生命周期的可视化管理，也同时一站式提供 TiDB 数据库参数管理、数据库版本升级、克隆集群、主备集群切换、数据导入导出、数据同步、数据备份恢复服务，能有效提高 TiDB 集群运维效率，降低企业运维成本。 @@ -40,7 +40,7 @@ TiUniManager 不仅提供对 TiDB 集群的全生命周期的可视化管理， ### 在 Kubernetes 上部署运维 TiDB - TiDB Operator -[TiDB Operator](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable) 是 Kubernetes 上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或私有部署的 Kubernetes 集群上。 +[TiDB Operator](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable) 是 Kubernetes 上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或自托管的 Kubernetes 集群上。 基本信息： @@ -96,8 +96,8 @@ TiUniManager 不仅提供对 TiDB 集群的全生命周期的可视化管理， 使用 TiDB Lightning 导入数据到 TiDB 时，有以下模式： -- `Physical Import Mode` 模式：TiDB Lightning 将数据解析为有序的键值对，并直接将其导入 TiKV。这种模式一般用于导入大量的数据（TB 级别）到新集群，但在数据导入过程中集群无法提供正常的服务。 -- `Logical Import Mode` 模式：以 TiDB/MySQL 作为后端，这种模式相比 `Physical Import Mode`，导入速度较慢，但是可以在线导入，同时也支持将数据导入到 MySQL。 +- [物理导入模式](/tidb-lightning/tidb-lightning-physical-import-mode.md)：TiDB Lightning 将数据解析为有序的键值对，并直接将其导入 TiKV。这种模式一般用于导入大量的数据（TB 级别）到新集群，但在数据导入过程中集群无法提供正常的服务。 +- [逻辑导入模式](/tidb-lightning/tidb-lightning-logical-import-mode.md)：以 TiDB/MySQL 作为后端，这种模式相比物理导入模式，导入速度较慢，但是可以在线导入，同时也支持将数据导入到 MySQL。 基本信息： diff --git a/error-codes.md b/error-codes.md index d61aaf6f9df6..14aa6f212fed 100644 --- a/error-codes.md +++ b/error-codes.md @@ -297,61 +297,57 @@ TiDB 兼容 MySQL 的错误码，在大多数情况下，返回和 MySQL 一样 目前 `LOAD DATA` 不支持从 TiDB 服务器本地导入数据，可以指定 `LOCAL` 从客户端导入，或者将数据上传到 S3/GCS 再进行导入。请参考 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)。 -* Error Number: 8155 - - 目前 `LOAD DATA` 不支持从 local 导入 Parquet 格式的数据文件，只支持从 S3/GCS 导入 Parquet 格式的数据文件。你可以将数据上传到 S3/GCS 后再导入。请参考 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)。 - * Error Number: 8156 - `LOAD DATA` 语句的文件路径不能为空。需要设置正确的路径再进行导入。请参考 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)。 + 传入的文件路径不能为空。需要设置正确的路径再进行导入。 * Error Number: 8157 - 不支持的数据格式。请参考 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md) 查看支持的数据格式。 + 不支持的文件格式。请参考 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md#format) 查看支持的格式。 * Error Number: 8158 - 传入的 S3/GCS 路径无效。请参考[外部存储](/br/backup-and-restore-storages.md)设置有效的路径。 + 传入的文件路径不合法。请根据具体的错误提示进行处理。S3/GCS 路径设置可参考[外部存储](/br/backup-and-restore-storages.md#uri-格式)。 * Error Number: 8159 - TiDB 无法访问 `LOAD DATA` 语句中传入的 S3/GCS 路径。请确保填入的 S3/GCS bucket 存在，且你输入了正确的 access key 和 secret access key 以让 TiDB 服务器有权限访问 S3/GCS 对应的 bucket。 + TiDB 无法访问传入的 S3/GCS 路径。请确保填写的 S3/GCS bucket 存在，且输入了正确的 Access Key 和 Secret Access Key 以让 TiDB 服务器有权限访问 S3/GCS 对应的 bucket。 * Error Number: 8160 - `LOAD DATA` 读取数据文件失败。请根据具体的错误提示进行处理。 + 读取数据文件失败。请根据具体的错误提示进行处理。 * Error Number: 8162 - `LOAD DATA` 语句存在错误。请参考 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md) 查看已支持的功能。 + 语句存在错误。请根据具体的错误提示进行处理。 * Error Number: 8163 - 未知的 `LOAD DATA ... WITH ...` 选项。请参考 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md) 查看支持的选项。 + 未知的选项。请参考 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md#参数说明) 查看支持的选项。 * Error Number: 8164 - `LOAD DATA ... WITH ...` 选项取值无效。请参考 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md) 查看有效的取值。 + 选项取值无效。请参考 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md#参数说明) 查看有效的取值。 * Error Number: 8165 - 重复指定了 `LOAD DATA ... WITH ...` 选项，每个选项只能指定一次。 + 重复指定了选项，每个选项只能指定一次。 * Error Number: 8166 - 某些 `LOAD DATA ... WITH ...` 选项只能在特定的导入模式下才可以使用。请参考 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md) 查看支持的选项。 + 某些选项只能在特定的条件下才可以使用。请根据具体的错误提示进行处理。请参考 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md#参数说明) 查看支持的选项。 * Error Number: 8170 - 指定的 `LOAD DATA` job 不存在或不是由当前用户创建。目前用户只能查看自己创建的 job。 + 指定的 job 不存在。 * Error Number: 8171 - 对不支持的 `LOAD DATA` 任务状态不能进行运维操作。请根据具体的错误提示进行处理。 + 该 job 的状态不能进行当前操作。请根据具体的错误提示进行处理。 -* Error Number: 8172 +* Error Number: 8173 - 指定 `LOCAL` 的 `LOAD DATA` 不能在后台运行，只有使用 S3/GCS 路径的 `LOAD DATA` 可以在后台运行。请参考 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md) 更改 SQL 语句。 + 执行 `IMPORT INTO` 时，TiDB 会对当前环境进行检查，比如检查下游表是否为空等。请根据具体的错误提示进行处理。 * Error Number: 8200 @@ -401,6 +397,54 @@ TiDB 兼容 MySQL 的错误码，在大多数情况下，返回和 MySQL 一样 TiDB 目前不支持在新添加的列上使用 Sequence 作为默认值，如果尝试进行这类操作会返回该错误。 +* Error Number: 8248 + + 资源组已存在。在重复创建资源组时返回该错误。 + +* Error Number: 8249 + + 资源组不存在。在修改或绑定不存在的资源组时返回该错误。请参考[创建资源组](/tidb-resource-control.md#创建资源组)。 + +* Error Number: 8250 + + 完整的报错信息如下： + + `ERROR 8250 (HY000) : Resource control feature is disabled. Run "SET GLOBAL tidb_enable_resource_control='on'" to enable the feature` + + 资源控制的功能没有打开时，使用资源管控 (Resource Control) 相关功能会返回该错误。你可以开启全局变量 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-从-v660-版本开始引入) 启用资源管控。 + +* Error Number: 8251 + + `Resource Control` 组件在 TiDB 启动时进行初始化，相关配置会从 `Resource Control` 的服务端 `Resource Manager` 上获取，如果此过程中出错，则会返回此错误。 + +* Error Number: 8252 + + 完整的报错信息如下： + + `ERROR 8252 (HY000) : Exceeded resource group quota limitation` + + 在尝试消耗超过资源组的限制时返回该错误。一般出现该错误，是由于单次事务太大或者并发太多导致，需调整事务大小或减少客户端并发数。 + +* Error Number: 8253 + + 查询终止，因为满足 Runaway Queries 的条件。请参考 [Runaway Queries](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries)。 + +* Error Number: 8254 + + 查询终止，因为被 Runaway Queries 免疫命中。请参考 [Runaway Queries](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries)。 + +* Error Number: 8260 + + DDL 操作无法被 `ADMIN PAUSE` 暂停运行。 + +* Error Number: 8261 + + DDL 操作无法被 `ADMIN RESUME` 恢复运行。 + +* Error Number: 8262 + + DDL 已经被 `ADMIN PAUSE` 暂停，无法再次执行。 + * Error Number: 9001 完整的报错信息为 `ERROR 9001 (HY000) : PD Server Timeout`。 diff --git a/exporting-grafana-snapshots.md b/exporting-grafana-snapshots.md index 995a3254a7f2..0222650f0620 100644 --- a/exporting-grafana-snapshots.md +++ b/exporting-grafana-snapshots.md @@ -10,6 +10,10 @@ summary: 了解如何将 Grafana 监控数据导出为快照以及如何将快 # 将 Grafana 监控数据导出成快照 +> **注意：** +> +> 目前该工具仅支持在 Grafana v6.x.x 上使用。 + 在故障诊断中，监控数据十分重要。当你请求远程协助时，技术支持人员有时需要查看 Grafana Dashboard 以确认问题所在。[MetricsTool](https://metricstool.pingcap.net/) 用于将 Grafana Dashboard 的快照导出为本地文件，并将快照可视化。因此，你可以在不泄露 Grafana 服务器上其他敏感信息的前提下，将监控数据以快照形式分享给外部人员，同时也方便外部人员准确识读数据图表。 ## 使用方法 @@ -40,10 +44,6 @@ MetricsTool 导出的快照文件包含快照生成时的监控指标实际数 不会。快照文件解析全部在浏览器中完成，Visualizer 不会将任何信息发送给 PingCAP。你可以放心地使用 Visualizer 查看带有敏感信息的快照文件，不用担心信息会泄露给第三方。 -### MetricsTool 可以导出除 Grafana 外其他监控工具的数据吗？ - -不能。目前该工具仅支持在 Grafana v6.x.x 上使用。 - ### 可以在所有监控指标数据都加载完毕前就运行脚本吗？ 可以。虽然脚本会弹出提示，让你等所有监控数据加载完毕后再运行，但可以手动跳过等待并导出快照，以免有些监控数据加载的时间过长。 diff --git a/faq/backup-and-restore-faq.md b/faq/backup-and-restore-faq.md index 773dc2750a0e..559241498f74 100644 --- a/faq/backup-and-restore-faq.md +++ b/faq/backup-and-restore-faq.md @@ -37,11 +37,11 @@ TiKV 支持[动态配置](/tikv-control.md#动态修改-tikv-的配置)自动调 在大多数情况下，因为 flashback 具有更短的 RPO（接近零）和 RTO，flashback 比 PITR 更适合由于人为错误导致的数据错误场景。但当集群完全不可用时，flashback 集群功能也无法运行，此时 PITR 是恢复集群的唯一方案。因此，相比于 flashback，虽然 PITR 的 RPO（最长 5 分钟）和 RTO 时间较长，但 PITR 是制定数据库灾难恢复策略时必须考虑的数据安全基础。 -### 上游数据库使用 TiDB Lightning Physical 方式导入数据时，为什么无法使用日志备份功能？ +### 上游数据库使用 TiDB Lightning 物理导入模式导入数据时，为什么无法使用日志备份功能？ -目前日志备份功能还没有完全适配 TiDB Lightning，导致 TiDB Lightning Physical 方式导入的数据无法备份到日志中。 +目前日志备份功能还没有完全适配 TiDB Lightning，导致 TiDB Lightning 物理导入模式导入的数据无法备份到日志中。 -在创建日志备份任务的上游集群中，请尽量避免使用 TiDB Lightning Physical 方式导入数据。可以选择使用 TiDB Lightning Logical 方式导入数据。若确实需要使用 Physical 导入方式，可在导入完成之后做一次快照备份操作，这样，PITR 就可以恢复到快照备份之后的时间点。 +在创建日志备份任务的上游集群中，请尽量避免使用 TiDB Lightning 物理导入模式导入数据。可以选择使用 TiDB Lightning 逻辑导入模式导入数据。若确实需要使用物理导入模式，可在导入完成之后做一次快照备份操作，这样，PITR 就可以恢复到快照备份之后的时间点。 ### 索引加速功能为什么与 PITR 功能不兼容？ diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index cc778ec79144..92359454d99e 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -114,6 +114,6 @@ Direct 模式就是把写入请求直接封装成 I/O 指令发到磁盘，这 ## TiDB 支持在公有云上部署吗？ -TiDB 支持在 [Google GKE](https://docs.pingcap.com/zh/tidb-in-kubernetes/v1.1/deploy-on-gcp-gke)、[AWS EKS](https://docs.pingcap.com/zh/tidb-in-kubernetes/v1.1/deploy-on-aws-eks) 和[阿里云 ACK](https://docs.pingcap.com/zh/tidb-in-kubernetes/v1.1/deploy-on-alibaba-cloud) 上部署使用。 +TiDB 支持在 [Google Cloud GKE](https://docs.pingcap.com/zh/tidb-in-kubernetes/v1.1/deploy-on-gcp-gke)、[AWS EKS](https://docs.pingcap.com/zh/tidb-in-kubernetes/v1.1/deploy-on-aws-eks) 和[阿里云 ACK](https://docs.pingcap.com/zh/tidb-in-kubernetes/v1.1/deploy-on-alibaba-cloud) 上部署使用。 此外，TiDB 云上部署也已在京东云、UCloud 上线。 diff --git a/faq/upgrade-faq.md b/faq/upgrade-faq.md index 6f9fde263a22..e9a247e1cd44 100644 --- a/faq/upgrade-faq.md +++ b/faq/upgrade-faq.md @@ -18,9 +18,15 @@ aliases: ['/docs-cn/dev/faq/upgrade-faq/','/docs-cn/dev/faq/upgrade/'] ### 集群在执行 DDL 请求期间可以进行升级操作吗？ -集群中有 DDL 语句正在被执行时（通常为 `ADD INDEX` 和列类型变更等耗时较久的 DDL 语句），**请勿进行**升级操作。在升级前，建议使用 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md) 命令查看集群中是否有正在进行的 DDL Job。如需升级，请等待 DDL 执行完成或使用 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md) 命令取消该 DDL Job 后再进行升级。 +* 如果升级前 TiDB 的版本低于 v7.1.0： -另外，在升级 TiDB 集群的过程中，**请勿执行** DDL 语句，否则可能会出现行为未定义的问题。 + * 集群中有 DDL 语句正在被执行时（通常为 `ADD INDEX` 和列类型变更等耗时较久的 DDL 语句），**请勿进行**升级操作。在升级前，建议使用 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md) 命令查看集群中是否有正在进行的 DDL Job。如需升级，请等待 DDL 执行完成或使用 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md) 命令取消该 DDL Job 后再进行升级。 + + * 在升级 TiDB 集群的过程中，**请勿执行** DDL 语句，否则可能会出现行为未定义的问题。 + +* 如果升级前 TiDB 的版本为 v7.1.0 或更高的版本： + + * 不用遵循限制低版本升级时的限制，即在升级时可以接收用户 DDL 任务。建议参考[平滑升级 TiDB](/smooth-upgrade-tidb.md)。 ### Binary 如何升级？ diff --git a/foreign-key.md b/foreign-key.md index 72214cce2623..07d41d96c4ab 100644 --- a/foreign-key.md +++ b/foreign-key.md @@ -7,6 +7,10 @@ summary: TiDB 数据库中外键约束的使用概况。 从 v6.6.0 开始，TiDB 支持外键以及外键约束功能，外键允许跨表交叉引用相关数据，外键约束则可以保证相关数据的一致性。 +> **注意：** +> +> 外键功能通常适用于为中小规模的数据提供完整性和一致性约束校验，但是在大数据量和分布式数据库系统下，使用外键可能会导致严重的性能问题，并对系统产生不可预知的影响。如果计划使用外键，请进行充分验证后谨慎使用。 + 外键是在子表中定义的，语法如下： ```ebnf+diagram @@ -197,7 +201,7 @@ Create Table: CREATE TABLE `child` ( - [`INFORMATION_SCHEMA.KEY_COLUMN_USAGE`](/information-schema/information-schema-key-column-usage.md) - [`INFORMATION_SCHEMA.TABLE_CONSTRAINTS`](/information-schema/information-schema-table-constraints.md) -- [`INFORMATION_SCHEMA.TABLE_CONSTRAINTS`](/information-schema/information-schema-table-constraints.md) +- [`INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS`](/information-schema/information-schema-referential-constraints.md) 下面提供了查询示例： @@ -308,3 +312,31 @@ Create Table | CREATE TABLE `child` ( ### 与 MySQL 的兼容性 创建外键未指定名称时，TiDB 自动生成的外键名称和 MySQL 不一样。例如 TiDB 生成的外键名称为 `fk_1`、`fk_2`、`fk_3` 等，MySQL 生成的外键名称为 `table_name_ibfk_1`、 `table_name_ibfk_2`、`table_name_ibfk_3` 等。 + +MySQL 和 TiDB 均能解析但会忽略以内联 `REFERENCES` 的方式定义的外键。只有当 `REFERENCES` 作为 `FOREIGN KEY` 定义的一部分时，才会进行检查和执行。下面的示例在定义外键约束时只使用了 `REFERENCES`： + +```sql +CREATE TABLE parent ( + id INT KEY +); + +CREATE TABLE child ( + id INT, + pid INT REFERENCES parent(id) +); + +SHOW CREATE TABLE child; +``` + +输出结果显示 `child` 表不包含任何外键： + +```sql ++-------+-------------------------------------------------------------+ +| Table | Create Table | ++-------+-------------------------------------------------------------+ +| child | CREATE TABLE `child` ( | +| | `id` int(11) DEFAULT NULL, | +| | `pid` int(11) DEFAULT NULL | +| | ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin | ++-------+-------------------------------------------------------------+ +``` diff --git a/functions-and-operators/cast-functions-and-operators.md b/functions-and-operators/cast-functions-and-operators.md index 1f8f4c3a2037..f012f2d8e2ba 100644 --- a/functions-and-operators/cast-functions-and-operators.md +++ b/functions-and-operators/cast-functions-and-operators.md @@ -14,3 +14,7 @@ Cast 函数和操作符用于将某种数据类型的值转换为另一种数据 | [`BINARY`](https://dev.mysql.com/doc/refman/5.7/en/cast-functions.html#operator_binary) | 将一个字符串转换成一个二进制字符串 | | [`CAST()`](https://dev.mysql.com/doc/refman/5.7/en/cast-functions.html#function_cast) | 将一个值转换成一个确定类型 | | [`CONVERT()`](https://dev.mysql.com/doc/refman/5.7/en/cast-functions.html#function_convert) | 将一个值转换成一个确定类型 | + +> **注意：** +> +> TiDB 和 MySQL 对于 `SELECT CAST(MeN AS CHAR)`（或者等价的 `SELECT CONVERT(MeM, CHAR)`）的结果显示不一致，其中 `MeN` 是用科学计数法表示的双精度浮点数。MySQL 在 `-15 <= N <= 14` 时显示完整数值，在 `N < -15` 或 `N > 14` 时显示科学计数法。而 TiDB 始终显示完整数值。例如，MySQL 对于 `SELECT CAST(3.1415e15 AS CHAR)` 的显示结果为 `3.1415e15`，而 TiDB 的显示结果为 `3141500000000000`。 diff --git a/functions-and-operators/date-and-time-functions.md b/functions-and-operators/date-and-time-functions.md index 48c4c22f6c5c..e6aaa11970c8 100644 --- a/functions-and-operators/date-and-time-functions.md +++ b/functions-and-operators/date-and-time-functions.md @@ -7,6 +7,11 @@ aliases: ['/docs-cn/dev/functions-and-operators/date-and-time-functions/','/docs TiDB 支持使用 MySQL 5.7 中提供的所有[日期和时间函数](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html)。 +> **注意：** +> +> - MySQL 常常会接受格式不正确的日期和时间值。例如，`'2020-01-01\n\t01:01:01'` 和 `'2020-01_01\n\t01:01'` 被视为有效的日期和时间值。 +> - TiDB 会尽量与 MySQL 的行为保持一致，但可能无法在所有情况下完全匹配。建议使用正确的格式化日期，TiDB 文档中未记录将如何处理格式不正确的值。 + ## 日期时间函数表 | 函数名 | 功能描述 | @@ -72,6 +77,25 @@ TiDB 支持使用 MySQL 5.7 中提供的所有[日期和时间函数](https://de | [`YEAR()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_year) | 返回参数对应的年数| | [`YEARWEEK()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_yearweek) | 返回年数和星期数 | +## MySQL 兼容性 + +TiDB 支持 `str_to_date()` 函数，但是无法解析所有的日期和时间值。此外，TiDB 不支持以下日期和时间格式化选项： + +| 格式 | 说明 | +|--------|---------------------------------------------------------------------------------------| +| "%a" | 星期名的缩写（例如 Sun..Sat） | +| "%D" | 带英文后缀的月份日期（例如 0th，1st，2nd，3rd） | +| "%U" | 星期 (00..53)，星期日是每周的第一天；WEEK() mode 0 | +| "%u" | 星期 (00..53)，星期一是每周的第一天；WEEK() mode 1 | +| "%V" | 星期 (01..53)，星期日是每周的第一天；WEEK() mode 2；和 "%X" 一起使用 | +| "%v" | 星期 (01..53)，星期一是每周的第一天；WEEK() mode 3；和 "%x" 一起使用 | +| "%W" | 星期名（例如 Sunday..Saturday） | +| "%w" | 一周中的天名 (0=Sunday..6=Saturday) | +| "%X" | 星期天是每周第一天的年份，数字类型，四位数字 | +| "%x" | 星期一是每周第一天的年份，数字类型，四位数字 | + +更多信息，参见 [GitHub Issue #30082](https://github.com/pingcap/tidb/issues/30082)。 + ## 相关系统变量 `default_week_format` 变量影响 `WEEK()` 函数。 diff --git a/functions-and-operators/expressions-pushed-down.md b/functions-and-operators/expressions-pushed-down.md index be491e615200..867d8dca2191 100644 --- a/functions-and-operators/expressions-pushed-down.md +++ b/functions-and-operators/expressions-pushed-down.md @@ -15,306 +15,18 @@ TiFlash 也支持[本页](/tiflash/tiflash-supported-pushdown-calculations.md) | 表达式分类 | 具体操作 | | :-------------- | :------------------------------------- | | [逻辑运算](/functions-and-operators/operators.md#逻辑操作符) | AND (&&), OR (||), NOT (!), XOR | -| [位运算](/functions-and-operators/operators.md#操作符) | [&][operator_bitwise-and], [~][operator_bitwise-invert], [\|][operator_bitwise-or], [^][operator_bitwise-xor], [<<][operator_left-shift], [>>][operator_right-shift] | -| [比较运算](/functions-and-operators/operators.md#比较方法和操作符) | [<][operator_less-than], [<=][operator_less-than-or-equal], [=][operator_equal], [!= (<\>)][operator_not-equal], [>][operator_greater-than], [>=][operator_greater-than-or-equal], [<=>][operator_equal-to], [BETWEEN ... AND ...][operator_between], [COALESCE()][function_coalesce], [IN()][operator_in], [INTERVAL()][function_interval], [IS NOT NULL][operator_is-not-null], [IS NOT][operator_is-not], [IS NULL][operator_is-null], [IS][operator_is], [ISNULL()][function_isnull], [LIKE][operator_like], [NOT BETWEEN ... AND ...][operator_not-between], [NOT IN()][operator_not-in], [NOT LIKE][operator_not-like], [STRCMP()][function_strcmp] | -| [数值运算](/functions-and-operators/numeric-functions-and-operators.md) | [+][operator_plus], [-][operator_minus], [*][operator_times], [/][operator_divide], [DIV][operator_div], [% (MOD)][operator_mod], [-][operator_unary-minus], [ABS()][function_abs], [ACOS()][function_acos], [ASIN()][function_asin], [ATAN()][function_atan], [ATAN2(), ATAN()][function_atan2], [CEIL()][function_ceil], [CEILING()][function_ceiling], [CONV()][function_conv], [COS()][function_cos], [COT()][function_cot], [CRC32()][function_crc32], [DEGREES()][function_degrees], [EXP()][function_exp], [FLOOR()][function_floor], [LN()][function_ln], [LOG()][function_log], [LOG10()][function_log10], [LOG2()][function_log2], [MOD()][function_mod], [PI()][function_pi], [POW()][function_pow], [POWER()][function_power], [RADIANS()][function_radians], [RAND()][function_rand], [ROUND()][function_round], [SIGN()][function_sign], [SIN()][function_sin], [SQRT()][function_sqrt] | -| [控制流运算](/functions-and-operators/control-flow-functions.md) | [CASE][operator_case], [IF()][function_if], [IFNULL()][function_ifnull] | -| [JSON 运算](/functions-and-operators/json-functions.md) | [JSON_ARRAY([val[, val] ...])][json_array],
[JSON_CONTAINS(target, candidate[, path])][json_contains],
[JSON_EXTRACT(json_doc, path[, path] ...)][json_extract],
[JSON_INSERT(json_doc, path, val[, path, val] ...)][json_insert],
[JSON_LENGTH(json_doc[, path])][json_length],
[JSON_MERGE(json_doc, json_doc[, json_doc] ...)][json_merge],
[JSON_OBJECT([key, val[, key, val] ...])][json_object],
[JSON_REMOVE(json_doc, path[, path] ...)][json_remove],
[JSON_REPLACE(json_doc, path, val[, path, val] ...)][json_replace],
[JSON_SET(json_doc, path, val[, path, val] ...)][json_set],
[JSON_TYPE(json_val)][json_type],
[JSON_UNQUOTE(json_val)][json_unquote],
[JSON_VALID(val)][json_valid] | -| [日期运算](/functions-and-operators/date-and-time-functions.md) | [DATE()][function_date], [DATE_FORMAT()][function_date-format], [DATEDIFF()][function_datediff], [DAYOFMONTH()][function_dayofmonth], [DAYOFWEEK()][function_dayofweek], [DAYOFYEAR()][function_dayofyear], [FROM_DAYS()][function_from-days], [HOUR()][function_hour], [MAKEDATE()][function_makedate], [MAKETIME()][function_maketime], [MICROSECOND()][function_microsecond], [MINUTE()][function_minute], [MONTH()][function_month], [MONTHNAME()][function_monthname], [PERIOD_ADD()][function_period-add], [PERIOD_DIFF()][function_period-diff], [SEC_TO_TIME()][function_sec-to-time], [SECOND()][function_second], [SYSDATE()][function_sysdate], [TIME_TO_SEC()][function_time-to-sec], [TIMEDIFF()][function_timediff], [WEEK()][function_week], [WEEKOFYEAR()][function_weekofyear], [YEAR()][function_year] | -| [字符串函数](/functions-and-operators/string-functions.md) | [ASCII()][function_ascii], [BIT_LENGTH()][function_bit-length], [CHAR()][function_char], [CHAR_LENGTH()][function_char-length], [CONCAT()][function_concat], [CONCAT_WS()][function_concat-ws], [ELT()][function_elt], [FIELD()][function_field], [HEX()][function_hex], [LENGTH()][function_length], [LIKE][operator_like], [LTRIM()][function_ltrim], [MID()][function_mid], [NOT LIKE][operator_not-like], [NOT REGEXP][operator_not-regexp], [REGEXP][operator_regexp], [REPLACE()][function_replace], [REVERSE()][function_reverse], [RIGHT()][function_right], [RTRIM()][function_rtrim], [SPACE()][function_space], [STRCMP()][function_strcmp], [SUBSTR()][function_substr], [SUBSTRING()][function_substring] | -| [聚合函数](/functions-and-operators/aggregate-group-by-functions.md#group-by-聚合函数) | [COUNT()][function_count], [COUNT(DISTINCT)][function_count-distinct], [SUM()][function_sum], [AVG()][function_avg], [MAX()][function_max], [MIN()][function_min], [VARIANCE()][function_variance], [VAR_POP()][function_var-pop], [STD()][function_std], [STDDEV()][function_stddev], [STDDEV_POP][function_stddev-pop], [VAR_SAMP()][function_var-samp], [STDDEV_SAMP()][function_stddev-samp], [JSON_ARRAYAGG(key)][json_arrayagg], [JSON_OBJECTAGG(key, value)][function_json-objectagg] | -| [加密和压缩函数](/functions-and-operators/encryption-and-compression-functions.md#加密和压缩函数) | [MD5()][function_md5], [SHA1(), SHA()][function_sha1], [UNCOMPRESSED_LENGTH()][function_uncompressed-length] | -| [Cast 函数](/functions-and-operators/cast-functions-and-operators.md#cast-函数和操作符) | [CAST()][function_cast], [CONVERT()][function_convert] | -| [其他函数](/functions-and-operators/miscellaneous-functions.md#支持的函数) | [UUID()][function_uuid] | +| [位运算](/functions-and-operators/operators.md#操作符) | [&](https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html#operator_bitwise-and), [~](https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html#operator_bitwise-invert), [\|](https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html#operator_bitwise-or), [`^`](https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html#operator_bitwise-xor), [`<<`](https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html#operator_left-shift), [`>>`](https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html#operator_right-shift) | +| [比较运算](/functions-and-operators/operators.md#比较方法和操作符) | [`<`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_less-than), [`<=`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_less-than-or-equal), [`=`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_equal), [`!= (<>)`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_not-equal), [`>`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_greater-than), [`>=`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_greater-than-or-equal), [`<=>`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_equal-to), [BETWEEN ... AND ...](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_between), [COALESCE()](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#function_coalesce), [IN()](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_in), [INTERVAL()](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#function_interval), [IS NOT NULL](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is-not-null), [IS NOT](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is-not), [IS NULL](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is-null), [IS](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is), [ISNULL()](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#function_isnull), [LIKE](https://dev.mysql.com/doc/refman/5.7/en/string-comparison-functions.html#operator_like), [NOT BETWEEN ... AND ...](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_not-between), [NOT IN()](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_not-in), [NOT LIKE](https://dev.mysql.com/doc/refman/5.7/en/string-comparison-functions.html#operator_not-like), [STRCMP()](https://dev.mysql.com/doc/refman/5.7/en/string-comparison-functions.html#function_strcmp) | +| [数值运算](/functions-and-operators/numeric-functions-and-operators.md) | [+](https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_plus), [-](https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_minus), [*](https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_times), [/](https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_divide), [DIV](https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_div), [% (MOD)](https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_mod), [-](https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_unary-minus), [ABS()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_abs), [ACOS()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_acos), [ASIN()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_asin), [ATAN()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_atan), [ATAN2(), ATAN()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_atan2), [CEIL()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_ceil), [CEILING()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_ceiling), [CONV()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_conv), [COS()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_cos), [COT()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_cot), [CRC32()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_crc32), [DEGREES()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_degrees), [EXP()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_exp), [FLOOR()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_floor), [LN()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_ln), [LOG()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_log), [LOG10()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_log10), [LOG2()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_log2), [MOD()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_mod), [PI()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_pi), [POW()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_pow), [POWER()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_power), [RADIANS()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_radians), [RAND()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_rand), [ROUND()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_round), [SIGN()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_sign), [SIN()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_sin), [SQRT()](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_sqrt) | +| [控制流运算](/functions-and-operators/control-flow-functions.md) | [CASE](https://dev.mysql.com/doc/refman/5.7/en/flow-control-functions.html#operator_case), [IF()](https://dev.mysql.com/doc/refman/5.7/en/flow-control-functions.html#function_if), [IFNULL()](https://dev.mysql.com/doc/refman/5.7/en/flow-control-functions.html#function_ifnull) | +| [JSON 运算](/functions-and-operators/json-functions.md) | [JSON_ARRAY([val[, val] ...])](https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html#function_json-array),
[JSON_CONTAINS(target, candidate[, path])](https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-contains),
[JSON_EXTRACT(json_doc, path[, path] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-extract),
[JSON_INSERT(json_doc, path, val[, path, val] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-insert),
[JSON_LENGTH(json_doc[, path])](https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-length),
[JSON_MERGE(json_doc, json_doc[, json_doc] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-merge),
[JSON_OBJECT([key, val[, key, val] ...])](https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html#function_json-object),
[JSON_REMOVE(json_doc, path[, path] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-remove),
[JSON_REPLACE(json_doc, path, val[, path, val] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-replace),
[JSON_SET(json_doc, path, val[, path, val] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-set),
[JSON_TYPE(json_val)](https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-type),
[JSON_UNQUOTE(json_val)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-unquote),
[JSON_VALID(val)](https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-valid) | +| [日期运算](/functions-and-operators/date-and-time-functions.md) | [DATE()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_date), [DATE_FORMAT()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_date-format), [DATEDIFF()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_datediff), [DAYOFMONTH()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_dayofmonth), [DAYOFWEEK()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_dayofweek), [DAYOFYEAR()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_dayofyear), [FROM_DAYS()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_from-days), [HOUR()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_hour), [MAKEDATE()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_makedate), [MAKETIME()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_maketime), [MICROSECOND()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_microsecond), [MINUTE()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_minute), [MONTH()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_month), [MONTHNAME()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_monthname), [PERIOD_ADD()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_period-add), [PERIOD_DIFF()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_period-diff), [SEC_TO_TIME()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_sec-to-time), [SECOND()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_second), [SYSDATE()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_sysdate), [TIME_TO_SEC()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_time-to-sec), [TIMEDIFF()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_timediff), [WEEK()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_week), [WEEKOFYEAR()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_weekofyear), [YEAR()](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_year) | +| [字符串函数](/functions-and-operators/string-functions.md) | [ASCII()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_ascii), [BIT_LENGTH()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_bit-length), [CHAR()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_char), [CHAR_LENGTH()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_char-length), [CONCAT()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_concat), [CONCAT_WS()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_concat-ws), [ELT()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_elt), [FIELD()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_field), [HEX()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_hex), [LENGTH()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_length), [LIKE](https://dev.mysql.com/doc/refman/5.7/en/string-comparison-functions.html#operator_like), [LTRIM()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_ltrim), [MID()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_mid), [NOT LIKE](https://dev.mysql.com/doc/refman/5.7/en/string-comparison-functions.html#operator_not-like), [NOT REGEXP](https://dev.mysql.com/doc/refman/5.7/en/regexp.html#operator_not-regexp), [REGEXP](https://dev.mysql.com/doc/refman/5.7/en/regexp.html#operator_regexp), [REPLACE()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_replace), [REVERSE()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_reverse), [RIGHT()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_right), [RTRIM()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_rtrim), [SPACE()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_space), [STRCMP()](https://dev.mysql.com/doc/refman/5.7/en/string-comparison-functions.html#function_strcmp), [SUBSTR()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_substr), [SUBSTRING()](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_substring) | +| [聚合函数](/functions-and-operators/aggregate-group-by-functions.md#group-by-聚合函数) | [COUNT()](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_count), [COUNT(DISTINCT)](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_count-distinct), [SUM()](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_sum), [AVG()](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_avg), [MAX()](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_max), [MIN()](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_min), [VARIANCE()](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_variance), [VAR_POP()](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_var-pop), [STD()](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_std), [STDDEV()](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_stddev), [STDDEV_POP](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_stddev-pop), [VAR_SAMP()](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_var-samp), [STDDEV_SAMP()](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_stddev-samp), [JSON_ARRAYAGG(key)](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_json-arrayagg), [JSON_OBJECTAGG(key, value)](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_json-objectagg) | +| [加密和压缩函数](/functions-and-operators/encryption-and-compression-functions.md#加密和压缩函数) | [MD5()](https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_md5), [SHA1(), SHA()](https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_sha1), [UNCOMPRESSED_LENGTH()](https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_uncompressed-length) | +| [Cast 函数](/functions-and-operators/cast-functions-and-operators.md#cast-函数和操作符) | [CAST()](https://dev.mysql.com/doc/refman/5.7/en/cast-functions.html#function_cast), [CONVERT()](https://dev.mysql.com/doc/refman/5.7/en/cast-functions.html#function_convert) | +| [其他函数](/functions-and-operators/miscellaneous-functions.md#支持的函数) | [UUID()](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_uuid) | ## 禁止特定表达式下推 当[已支持下推的表达式列表](#已支持下推的表达式列表)中的函数和运算符，或特定的数据类型（**仅限** [`ENUM` 类型](/data-type-string.md#enum-类型)和 [`BIT` 类型](/data-type-numeric.md#bit-类型)）的计算过程因下推而出现异常时，你可以使用黑名单功能禁止其下推，从而快速恢复 TiDB 业务。具体而言，你可以将函数名、运算符名，或数据列类型加入黑名单 `mysql.expr_pushdown_blacklist` 中，以禁止特定表达式下推。具体方法，请参阅[表达式下推黑名单](/blocklist-control-plan.md#禁止特定表达式下推)。 - -[function_abs]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_abs - -[function_acos]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_acos - -[function_ascii]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_ascii - -[function_asin]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_asin - -[function_atan]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_atan - -[function_atan2]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_atan2 - -[function_avg]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_avg - -[function_bit-length]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_bit-length - -[function_cast]: https://dev.mysql.com/doc/refman/5.7/en/cast-functions.html#function_cast - -[function_ceil]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_ceil - -[function_ceiling]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_ceiling - -[function_char-length]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_char-length - -[function_char]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_char - -[function_coalesce]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#function_coalesce - -[function_concat-ws]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_concat-ws - -[function_concat]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_concat - -[function_conv]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_conv - -[function_convert]: https://dev.mysql.com/doc/refman/5.7/en/cast-functions.html#function_convert - -[function_cos]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_cos - -[function_cot]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_cot - -[function_count-distinct]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_count-distinct - -[function_count]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_count - -[function_crc32]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_crc32 - -[function_date-format]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_date-format - -[function_date]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_date - -[function_datediff]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_datediff - -[function_dayofmonth]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_dayofmonth - -[function_dayofweek]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_dayofweek - -[function_dayofyear]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_dayofyear - -[function_degrees]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_degrees - -[function_elt]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_elt - -[function_exp]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_exp - -[function_field]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_field - -[function_floor]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_floor - -[function_from-days]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_from-days - -[function_hex]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_hex - -[function_hour]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_hour - -[function_if]: https://dev.mysql.com/doc/refman/5.7/en/flow-control-functions.html#function_if - -[function_ifnull]: https://dev.mysql.com/doc/refman/5.7/en/flow-control-functions.html#function_ifnull - -[function_interval]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#function_interval - -[function_isnull]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#function_isnull - -[function_json-objectagg]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_json-objectagg - -[function_length]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_length - -[function_ln]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_ln - -[function_log]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_log - -[function_log10]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_log10 - -[function_log2]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_log2 - -[function_ltrim]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_ltrim - -[function_makedate]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_makedate - -[function_maketime]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_maketime - -[function_max]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_max - -[function_md5]: https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_md5 - -[function_microsecond]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_microsecond - -[function_mid]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_mid - -[function_min]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_min - -[function_minute]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_minute - -[function_mod]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_mod - -[function_month]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_month - -[function_monthname]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_monthname - -[function_period-add]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_period-add - -[function_period-diff]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_period-diff - -[function_pi]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_pi - -[function_pow]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_pow - -[function_power]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_power - -[function_radians]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_radians - -[function_rand]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_rand - -[function_replace]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_replace - -[function_reverse]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_reverse - -[function_right]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_right - -[function_round]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_round - -[function_rtrim]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_rtrim - -[function_sec-to-time]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_sec-to-time - -[function_second]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_second - -[function_sha1]: https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_sha1 - -[function_sign]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_sign - -[function_sin]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_sin - -[function_space]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_space - -[function_sqrt]: https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_sqrt - -[function_std]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_std - -[function_stddev-pop]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_stddev-pop - -[function_stddev-samp]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_stddev-samp - -[function_stddev]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_stddev - -[function_strcmp]: https://dev.mysql.com/doc/refman/5.7/en/string-comparison-functions.html#function_strcmp - -[function_substr]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_substr - -[function_substring]: https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_substring - -[function_sum]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_sum - -[function_sysdate]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_sysdate - -[function_time-to-sec]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_time-to-sec - -[function_timediff]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_timediff - -[function_uncompressed-length]: https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_uncompressed-length - -[function_uuid]: https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_uuid - -[function_var-pop]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_var-pop - -[function_var-samp]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_var-samp - -[function_variance]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_variance - -[function_week]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_week - -[function_weekofyear]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_weekofyear - -[function_year]: https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_year - -[json_array]: https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html#function_json-array - -[json_arrayagg]:https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_json-arrayagg - -[json_contains]: https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-contains - -[json_extract]: https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-extract - -[json_insert]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-insert - -[json_length]: https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-length - -[json_merge]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-merge - -[json_object]: https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html#function_json-object - -[json_remove]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-remove - -[json_replace]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-replace - -[json_set]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-set - -[json_type]: https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-type - -[json_unquote]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-unquote - -[json_valid]: https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-valid - -[operator_between]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_between - -[operator_bitwise-and]: https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html#operator_bitwise-and - -[operator_bitwise-invert]: https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html#operator_bitwise-invert - -[operator_bitwise-or]: https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html#operator_bitwise-or - -[operator_bitwise-xor]: https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html#operator_bitwise-xor - -[operator_case]: https://dev.mysql.com/doc/refman/5.7/en/flow-control-functions.html#operator_case - -[operator_div]: https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_div - -[operator_divide]: https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_divide - -[operator_equal-to]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_equal-to - -[operator_equal]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_equal - -[operator_greater-than-or-equal]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_greater-than-or-equal - -[operator_greater-than]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_greater-than - -[operator_in]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_in - -[operator_is-not-null]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is-not-null - -[operator_is-not]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is-not - -[operator_is-null]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is-null - -[operator_is]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is - -[operator_left-shift]: https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html#operator_left-shift - -[operator_less-than-or-equal]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_less-than-or-equal - -[operator_less-than]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_less-than - -[operator_like]: https://dev.mysql.com/doc/refman/5.7/en/string-comparison-functions.html#operator_like - -[operator_minus]: https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_minus - -[operator_mod]: https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_mod - -[operator_not-between]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_not-between - -[operator_not-equal]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_not-equal - -[operator_not-in]: https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_not-in - -[operator_not-like]: https://dev.mysql.com/doc/refman/5.7/en/string-comparison-functions.html#operator_not-like - -[operator_not-regexp]: https://dev.mysql.com/doc/refman/5.7/en/regexp.html#operator_not-regexp - -[operator_plus]: https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_plus - -[operator_regexp]: https://dev.mysql.com/doc/refman/5.7/en/regexp.html#operator_regexp - -[operator_right-shift]: https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html#operator_right-shift - -[operator_times]: https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_times - -[operator_unary-minus]: https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_unary-minus diff --git a/functions-and-operators/json-functions.md b/functions-and-operators/json-functions.md index 26d48b0efe8a..f501173cc58a 100644 --- a/functions-and-operators/json-functions.md +++ b/functions-and-operators/json-functions.md @@ -11,133 +11,67 @@ TiDB 支持 MySQL 5.7 GA 版本发布的大多数 JSON 函数。 | 函数 | 功能描述 | | ------------------------------------------------------------------ | ---------------------------------------------------------- | -| [JSON_ARRAY([val[, val] ...])][json_array] | 根据一系列元素创建一个 JSON 文档 | -| [JSON_OBJECT(key, val[, key, val] ...)][json_object] | 根据一系列 K/V 对创建一个 JSON 文档 | -| [JSON_QUOTE(string)][json_quote] | 返回一个字符串，该字符串为带引号的 JSON 值 | +| [JSON_ARRAY([val[, val] ...])](https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html#function_json-array) | 根据一系列元素创建一个 JSON 文档 | +| [JSON_OBJECT(key, val[, key, val] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html#function_json-object) | 根据一系列 K/V 对创建一个 JSON 文档 | +| [JSON_QUOTE(string)](https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html#function_json-quote) | 返回一个字符串，该字符串为带引号的 JSON 值 | ## 搜索 JSON 值的函数 | 函数 | 功能描述 | | ------------------------------------------------------------ | ------------------------------------------------------------ | -| [JSON_CONTAINS(target, candidate[, path])][json_contains] | 通过返回 1 或 0 来表示目标 JSON 文档中是否包含给定的 candidate JSON 文档 | -| [JSON_CONTAINS_PATH(json_doc, one_or_all, path[, path] ...)][json_contains_path] | 通过返回 0 或 1 来表示一个 JSON 文档在给定路径是否包含数据 | -| [JSON_EXTRACT(json_doc, path[, path] ...)][json_extract] | 从 JSON 文档中解出某一路径对应的子文档 | -| [->][json_short_extract] | 返回执行路径后面的 JSON 列的值；`JSON_EXTRACT(doc, path_literal)` 的别名 | -| [->>][json_short_extract_unquote] | 返回执行路径后面的 JSON 列的值和转义后的结果； `JSON_UNQUOTE(JSON_EXTRACT(doc, path_literal))` 的别名 | -| [JSON_KEYS(json_doc[, path])][json_keys] | 返回从 JSON 对象的顶级值作为 JSON array 的键，如果给定了路径参数，则从选定路径中获取顶级键 | -| [JSON_SEARCH(json_doc, one_or_all, search_str[, escape_char[, path] ...])][json_search] | 返回指定字符在 JSON 文档中的路径 | -| [value MEMBER OF(json_array)][MEMBER_OF] | 如果传入值是 JSON array 中的一个元素，返回 1，否则返回 0 | -| [JSON_OVERLAPS(json_doc1, json_doc2)][json_overlaps] | 表示两个 JSON 文档中是否包含公共部分。返回 1 表示两个 JSON 文档中包含公共部分，否则返回 0 | +| [JSON_CONTAINS(target, candidate[, path])](https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-contains) | 通过返回 1 或 0 来表示目标 JSON 文档中是否包含给定的 candidate JSON 文档 | +| [JSON_CONTAINS_PATH(json_doc, one_or_all, path[, path] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-contains-path) | 通过返回 0 或 1 来表示一个 JSON 文档在给定路径是否包含数据 | +| [JSON_EXTRACT(json_doc, path[, path] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-extract) | 从 JSON 文档中解出某一路径对应的子文档 | +| [->](https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#operator_json-column-path) | 返回执行路径后面的 JSON 列的值；`JSON_EXTRACT(doc, path_literal)` 的别名 | +| [->>](https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#operator_json-inline-path) | 返回执行路径后面的 JSON 列的值和转义后的结果； `JSON_UNQUOTE(JSON_EXTRACT(doc, path_literal))` 的别名 | +| [JSON_KEYS(json_doc[, path])](https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-keys) | 返回从 JSON 对象的顶级值作为 JSON array 的键，如果给定了路径参数，则从选定路径中获取顶级键 | +| [JSON_SEARCH(json_doc, one_or_all, search_str[, escape_char[, path] ...])](https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-search) | 返回指定字符在 JSON 文档中的路径 | +| [value MEMBER OF(json_array)](https://dev.mysql.com/doc/refman/8.0/en/json-search-functions.html#operator_member-of) | 如果传入值是 JSON array 中的一个元素，返回 1，否则返回 0 | +| [JSON_OVERLAPS(json_doc1, json_doc2)](https://dev.mysql.com/doc/refman/8.0/en/json-search-functions.html#function_json-overlaps) | 表示两个 JSON 文档中是否包含公共部分。返回 1 表示两个 JSON 文档中包含公共部分，否则返回 0 | ## 修改 JSON 值的函数 | 函数 | 功能描述 | | --------------------------------- | ----------- | -| [JSON_APPEND(json_doc, path, value)][json_append] | `JSON_ARRAY_APPEND` 的别名 | -| [JSON_ARRAY_APPEND(json_doc, path, value)][json_array_append] | 将值追加到指定路径的 JSON 数组的末尾 | -| [JSON_ARRAY_INSERT(json_doc, path, val[, path, val] ...)][json_array_insert] | 将数组插入 JSON 文档，并返回修改后的文档 | -| [JSON_INSERT(json_doc, path, val[, path, val] ...)][json_insert] | 在 JSON 文档中在某一路径下插入子文档 | -| [JSON_MERGE(json_doc, json_doc[, json_doc] ...)][json_merge] | 已废弃的 `JSON_MERGE_PRESERVE` 别名 | -| [JSON_MERGE_PATCH(json_doc, json_doc[, json_doc] ...)][json_merge_patch] | 合并 JSON 文档 | -| [JSON_MERGE_PRESERVE(json_doc, json_doc[, json_doc] ...)][json_merge_preserve] | 将两个或多个 JSON 文档合并成一个文档，并返回合并结果 | -| [JSON_REMOVE(json_doc, path[, path] ...)][json_remove] | 移除 JSON 文档中某一路径下的子文档 | -| [JSON_REPLACE(json_doc, path, val[, path, val] ...)][json_replace] | 替换 JSON 文档中的某一路径下的子文档 | -| [JSON_SET(json_doc, path, val[, path, val] ...)][json_set] | 在 JSON 文档中为某一路径设置子文档 | -| [JSON_UNQUOTE(json_val)][json_unquote] | 去掉 JSON 值外面的引号，返回结果为字符串 | -| [JSON_ARRAY_APPEND(json_doc, path, val[, path, val] ...)][json_array_append] | 将值添加到 JSON 文档指定数组的末尾，并返回添加结果 | -| [JSON_ARRAY_INSERT(json_doc, path, val[, path, val] ...)][json_array_insert] | 将值插入到 JSON 文档的指定位置，并返回插入结果 | +| [JSON_APPEND(json_doc, path, value)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-append) | `JSON_ARRAY_APPEND` 的别名 | +| [JSON_ARRAY_APPEND(json_doc, path, value)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-array-append) | 将值追加到指定路径的 JSON 数组的末尾 | +| [JSON_ARRAY_INSERT(json_doc, path, val[, path, val] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-array-insert) | 将数组插入 JSON 文档，并返回修改后的文档 | +| [JSON_INSERT(json_doc, path, val[, path, val] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-insert) | 在 JSON 文档中在某一路径下插入子文档 | +| [JSON_MERGE(json_doc, json_doc[, json_doc] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-merge) | 已废弃的 `JSON_MERGE_PRESERVE` 别名 | +| [JSON_MERGE_PATCH(json_doc, json_doc[, json_doc] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-merge-patch) | 合并 JSON 文档 | +| [JSON_MERGE_PRESERVE(json_doc, json_doc[, json_doc] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-merge-preserve) | 将两个或多个 JSON 文档合并成一个文档，并返回合并结果 | +| [JSON_REMOVE(json_doc, path[, path] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-remove) | 移除 JSON 文档中某一路径下的子文档 | +| [JSON_REPLACE(json_doc, path, val[, path, val] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-replace) | 替换 JSON 文档中的某一路径下的子文档 | +| [JSON_SET(json_doc, path, val[, path, val] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-set) | 在 JSON 文档中为某一路径设置子文档 | +| [JSON_UNQUOTE(json_val)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-unquote) | 去掉 JSON 值外面的引号，返回结果为字符串 | +| [JSON_ARRAY_APPEND(json_doc, path, val[, path, val] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-array-append) | 将值添加到 JSON 文档指定数组的末尾，并返回添加结果 | +| [JSON_ARRAY_INSERT(json_doc, path, val[, path, val] ...)](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-array-insert) | 将值插入到 JSON 文档的指定位置，并返回插入结果 | ## 返回 JSON 值属性的函数 | 函数 | 功能描述 | | --------------------------------- | ----------- | -| [JSON_DEPTH(json_doc)][json_depth] | 返回 JSON 文档的最大深度 | -| [JSON_LENGTH(json_doc[, path])][json_length] | 返回 JSON 文档的长度；如果路径参数已定，则返回该路径下值的长度 | -| [JSON_TYPE(json_val)][json_type] | 检查某 JSON 文档内部内容的类型 | -| [JSON_VALID(json_doc)][json_valid] | 检查 JSON 文档内容是否有效；用于将列转换为 JSON 类型之前对该列进行检查 | +| [JSON_DEPTH(json_doc)](https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-depth) | 返回 JSON 文档的最大深度 | +| [JSON_LENGTH(json_doc[, path])](https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-length) | 返回 JSON 文档的长度；如果路径参数已定，则返回该路径下值的长度 | +| [JSON_TYPE(json_val)](https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-type) | 检查某 JSON 文档内部内容的类型 | +| [JSON_VALID(json_doc)](https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-valid) | 检查 JSON 文档内容是否有效；用于将列转换为 JSON 类型之前对该列进行检查 | ## 效用函数 | 函数 | 功能描述 | | --------------------------------- | ----------- | -| [JSON_PRETTY(json_doc)][json_pretty] |格式化 JSON 文档 | -| [JSON_STORAGE_FREE(json_doc)][json_storage_free] | 返回该 JSON 对象的存储空间中空闲的字节数。由于 TiDB 采用与 MySQL 完全不同的存储结构，本函数对合法的 JSON 值总是返回 0，主要用于兼容 MySQL 8.0 | -| [JSON_STORAGE_SIZE(json_doc)][json_storage_size] | 返回存储 JSON 值所需的大致字节大小，由于不考虑 TiKV 压缩的字节大小，因此函数的输出与 MySQL 不严格兼容 | +| [JSON_PRETTY(json_doc)](https://dev.mysql.com/doc/refman/5.7/en/json-utility-functions.html#function_json-pretty) |格式化 JSON 文档 | +| [JSON_STORAGE_FREE(json_doc)](https://dev.mysql.com/doc/refman/8.0/en/json-utility-functions.html#function_json-storage-free) | 返回该 JSON 对象的存储空间中空闲的字节数。由于 TiDB 采用与 MySQL 完全不同的存储结构，本函数对合法的 JSON 值总是返回 0，主要用于兼容 MySQL 8.0 | +| [JSON_STORAGE_SIZE(json_doc)](https://dev.mysql.com/doc/refman/5.7/en/json-utility-functions.html#function_json-storage-size) | 返回存储 JSON 值所需的大致字节大小，由于不考虑 TiKV 压缩的字节大小，因此函数的输出与 MySQL 不严格兼容 | ## 聚合函数 | 函数 | 功能描述 | | --------------------------------- | ----------- | -| [JSON_ARRAYAGG(key)][json_arrayagg] | 提供指定列 key 的聚合 | -| [JSON_OBJECTAGG(key, value)][json_objectagg] | 提供给定两列键值对的聚合 | +| [JSON_ARRAYAGG(key)](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_json-arrayagg) | 提供指定列 key 的聚合 | +| [JSON_OBJECTAGG(key, value)](https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_json-objectagg) | 提供给定两列键值对的聚合 | ## 另请参阅 * [JSON Function Reference](https://dev.mysql.com/doc/refman/5.7/en/json-function-reference.html) * [JSON Data Type](/data-type-json.md) - -[json_extract]: https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-extract - -[json_short_extract]: https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#operator_json-column-path - -[json_short_extract_unquote]: https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#operator_json-inline-path - -[json_unquote]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-unquote - -[json_type]: https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-type - -[json_set]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-set - -[json_insert]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-insert - -[json_replace]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-replace - -[json_remove]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-remove - -[json_merge]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-merge - -[json_merge_patch]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-merge-patch - -[json_merge_preserve]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-merge-preserve - -[json_object]: https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html#function_json-object - -[json_array]: https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html#function_json-array - -[json_keys]: https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-keys - -[json_length]: https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-length - -[json_valid]: https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-valid - -[json_quote]: https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html#function_json-quote - -[json_contains]: https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-contains - -[json_contains_path]: https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-contains-path - -[json_arrayagg]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_json-arrayagg - -[json_depth]: https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-depth - -[json_search]: https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-search - -[json_append]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-append - -[json_array_append]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-array-append - -[json_array_insert]: https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-array-insert - -[json_arrayagg]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_json-arrayagg - -[json_objectagg]: https://dev.mysql.com/doc/refman/5.7/en/aggregate-functions.html#function_json-objectagg - -[json_pretty]: https://dev.mysql.com/doc/refman/5.7/en/json-utility-functions.html#function_json-pretty - -[json_storage_free]: https://dev.mysql.com/doc/refman/8.0/en/json-utility-functions.html#function_json-storage-free - -[json_storage_size]: https://dev.mysql.com/doc/refman/5.7/en/json-utility-functions.html#function_json-storage-size - -[MEMBER_OF]: https://dev.mysql.com/doc/refman/8.0/en/json-search-functions.html#operator_member-of - -[json_overlaps]: https://dev.mysql.com/doc/refman/8.0/en/json-search-functions.html#function_json-overlaps diff --git a/functions-and-operators/operators.md b/functions-and-operators/operators.md index daf25a5f5876..1b9cdf3d9445 100644 --- a/functions-and-operators/operators.md +++ b/functions-and-operators/operators.md @@ -31,6 +31,7 @@ aliases: ['/docs-cn/dev/functions-and-operators/operators/','/docs-cn/dev/refere | [`<`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_less-than) | 小于 | | [`<=`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_less-than-or-equal) | 小于或等于 | | [`LIKE`](https://dev.mysql.com/doc/refman/5.7/en/string-comparison-functions.html#operator_like) | 简单模式匹配 | +| [`ILIKE`](https://www.postgresql.org/docs/current/functions-matching.html) | 大小写不敏感的简单模式匹配（TiDB 支持但 MySQL 不支持） | | [`-`](https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_minus) | 减 | | [`%`, `MOD`](https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_mod) | 求余 | | [`NOT`, `!`](https://dev.mysql.com/doc/refman/5.7/en/logical-operators.html#operator_not) | 取反 | @@ -99,6 +100,7 @@ OR, || | [`<`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_less-than) | 小于 | | [`<=`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_less-than-or-equal) | 小于或等于 | | [`LIKE`](https://dev.mysql.com/doc/refman/5.7/en/string-comparison-functions.html#operator_like) | 简单模式匹配 | +| [`ILIKE`](https://www.postgresql.org/docs/current/functions-matching.html) | 大小写不敏感的简单模式匹配（TiDB 支持但 MySQL 不支持） | | [`NOT BETWEEN ... AND ...`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_not-between) | 判断值是否不在范围内 | | [`!=`, `<>`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_not-equal) | 不等于 | | [`NOT IN()`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_not-in) | 判断值是否不在一个值的集合内 | @@ -126,3 +128,7 @@ OR, || | [`:=`](https://dev.mysql.com/doc/refman/5.7/en/assignment-operators.html#operator_assign-value) | 赋值 | 详情参见[这里](https://dev.mysql.com/doc/refman/5.7/en/group-by-functional-dependence.html)。 + +## MySQL 兼容性 + +* MySQL 不支持 `ILIKE` 操作符。 diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md index eec8ab8f7e11..d4e8b3efd503 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -5,27 +5,29 @@ summary: 学习使用 TiDB 特有的函数。 # TiDB 特有的函数 -本文档介绍 TiDB 特有的函数。 +以下函数为 TiDB 中特有的函数，与 MySQL 不兼容： -## TIDB_BOUNDED_STALENESS +| 函数名 | 函数说明 | +| :-------------- | :------------------------------------- | +| `TIDB_BOUNDED_STALENESS()` | `TIDB_BOUNDED_STALENESS` 函数指示 TiDB 在指定时间范围内读取尽可能新的数据。参见[使用 AS OF TIMESTAMP 语法读取历史数据](/as-of-timestamp.md)。 | +| [`TIDB_DECODE_KEY(str)`](#tidb_decode_key) | `TIDB_DECODE_KEY` 函数用于将 TiDB 编码的键输入解码为包含 `_tidb_rowid` 和 `table_id` 的 JSON 结构。你可以在一些系统表和日志输出中找到 TiDB 的编码键。 | +| [`TIDB_DECODE_PLAN(str)`](#tidb_decode_plan) | `TIDB_DECODE_PLAN` 函数用于解码 TiDB 执行计划。 | +| `TIDB_IS_DDL_OWNER()` | `TIDB_IS_DDL_OWNER` 函数用于检查你连接的 TiDB 实例是否是 DDL Owner。DDL Owner 代表集群中所有其他节点执行 DDL 语句的 TiDB 实例。 | +| [`TIDB_PARSE_TSO(num)`](#tidb_parse_tso) | `TIDB_PARSE_TSO` 函数用于从 TiDB TSO 时间戳中提取物理时间戳。参见 [`tidb_current_ts`](/system-variables.md#tidb_current_ts)。 | +| [`TIDB_VERSION()`](#tidb_version) | `TIDB_VERSION` 函数用于获取当前连接的 TiDB 服务器版本和构建详细信息。 | +| [`TIDB_DECODE_SQL_DIGESTS(digests, stmtTruncateLength)`](#tidb_decode_sql_digests) | `TIDB_DECODE_SQL_DIGESTS` 函数用于在集群中查询一组 SQL Digest 所对应的 SQL 语句的归一化形式（即去除格式和参数后的形式）。 | +| `VITESS_HASH(str)` | `VITESS_HASH` 函数返回与 Vitess 的 `HASH` 函数兼容的字符串哈希值，有助于从 Vitess 迁移数据。 | +| `TIDB_SHARD()` | `TIDB_SHARD` 函数用于创建一个 SHARD INDEX 来打散热点索引。SHARD INDEX 是一种以 `TIDB_SHARD` 函数为前缀的表达式索引。 | +| `TIDB_ROW_CHECKSUM()` | `TIDB_ROW_CHECKSUM()` 函数用于查询行数据的 Checksum 值。该函数只能用于 FastPlan 流程的 `SELECT` 语句，即你可通过形如 `SELECT TIDB_ROW_CHECKSUM() FROM t WHERE id = ?` 或 `SELECT TIDB_ROW_CHECKSUM() FROM t WHERE id IN (?, ?, ...)` 的语句进行查询。参见[数据正确性校验](/ticdc/ticdc-integrity-check.md)。 | -`TIDB_BOUNDED_STALENESS` 是 TiDB 的内部函数，用于指定一个时间范围。用法为 `TIDB_BOUNDED_STALENESS(t1, t2)`，其中 t1 和 t2 为时间范围的两端，支持使用日期时间和时间函数。 +## 示例 -使用该函数，TiDB 会在指定的时间范围内选择一个合适的时间戳，该时间戳能保证所访问的副本上不存在开始于这个时间戳之前且还没有提交的相关事务，即能保证所访问的可用副本上执行读取操作而且不会被阻塞。 +下面为部分以上函数的示例。 -## TIDB_DECODE_KEY +### TIDB_DECODE_KEY `TIDB_DECODE_KEY` 函数用于将 TiDB 编码的键输入解码为包含 `_tidb_rowid` 和 `table_id` 的 JSON 结构。你可以在一些系统表和日志输出中找到 TiDB 的编码键。 -### 语法图 - -```ebnf+diagram -TableStmt ::= - "TIDB_DECODE_KEY(" STR ")" -``` - -### 示例 - 以下示例中，表 `t1` 有一个隐藏的 `rowid`，该 `rowid` 由 TiDB 生成。语句中使用了 `TIDB_DECODE_KEY` 函数。结果显示，隐藏的 `rowid` 被解码后并输出，这是典型的非聚簇主键结果。 {{< copyable "sql" >}} @@ -104,24 +106,11 @@ select tidb_decode_key('7480000000000000FF3E5F720400000000FF0000000601633430FF33 1 row in set (0.001 sec) ``` -### MySQL 兼容性 - -`TIDB_DECODE_KEY` 是 TiDB 特有的函数，和 MySQL 不兼容。 - -## TIDB_DECODE_PLAN +### TIDB_DECODE_PLAN -`TIDB_DECODE_PLAN` 函数用于解码 TiDB 执行计划。你可以在慢查询日志中找到 TiDB 执行计划。 +你可以在慢查询日志中找到编码形式的 TiDB 执行计划，然后使用 `TIDB_DECODE_PLAN()` 函数将编码的执行计划解码为易读的形式。 -### 语法图 - -```ebnf+diagram -TableStmt ::= - "TIDB_DECODE_PLAN(" STR ")" -``` - -### 示例 - -{{< copyable "sql" >}} +该函数很有用，因为在执行语句时 TiDB 会捕获执行计划。重新执行 `EXPLAIN` 中的语句可能会产生不同的结果，因为数据分布和统计数据会随着时间的推移而变化。 ```sql SELECT tidb_decode_plan('8QIYMAkzMV83CQEH8E85LjA0CWRhdGE6U2VsZWN0aW9uXzYJOTYwCXRpbWU6NzEzLjHCtXMsIGxvb3BzOjIsIGNvcF90YXNrOiB7bnVtOiAxLCBtYXg6IDU2OC41wgErRHByb2Nfa2V5czogMCwgcnBjXxEpAQwFWBAgNTQ5LglZyGNvcHJfY2FjaGVfaGl0X3JhdGlvOiAwLjAwfQkzLjk5IEtCCU4vQQoxCTFfNgkxXzAJMwm2SGx0KHRlc3QudC5hLCAxMDAwMCkNuQRrdgmiAHsFbBQzMTMuOMIBmQnEDDk2MH0BUgEEGAoyCTQzXzUFVwX1oGFibGU6dCwga2VlcCBvcmRlcjpmYWxzZSwgc3RhdHM6cHNldWRvCTk2ISE2aAAIMTUzXmYA')\G @@ -135,69 +124,15 @@ SELECT tidb_decode_plan('8QIYMAkzMV83CQEH8E85LjA0CWRhdGE6U2VsZWN0aW9uXzYJOTYwCXR └─TableFullScan_5 cop[tikv] 960 table:t, keep order:false, stats:pseudo 960 tikv_task:{time:153µs, loops:960} N/A N/A ``` -### MySQL 兼容性 - -`TIDB_DECODE_PLAN` 是 TiDB 特有的函数，和 MySQL 不兼容。 - -## TIDB_IS_DDL_OWNER - -`TIDB_IS_DDL_OWNER` 函数用于检查你连接的 TiDB 实例是否是 DDL Owner。DDL Owner 代表集群中所有其他节点执行 DDL 语句的 TiDB 实例。 - -### 语法图 - -```ebnf+diagram -TableStmt ::= - "TIDB_IS_DDL_OWNER())" -``` - -### 示例 - -{{< copyable "sql" >}} - -```sql -SELECT tidb_is_ddl_owner(); -``` - -```sql -+---------------------+ -| tidb_is_ddl_owner() | -+---------------------+ -| 1 | -+---------------------+ -1 row in set (0.00 sec) -``` - -### MySQL 兼容性 - -`TIDB_IS_DDL_OWNER` 是 TiDB 特有的函数，和 MySQL 不兼容。 - -### 另请参阅 - -- [ADMIN SHOW DDL](/sql-statements/sql-statement-admin-show-ddl.md) -- [ADMIN CANCEL DDL](/sql-statements/sql-statement-admin-cancel-ddl.md) - -## TIDB_PARSE_TSO +### TIDB_PARSE_TSO `TIDB_PARSE_TSO` 函数用于从 TiDB TSO 时间戳中提取物理时间戳。 -TSO 指 Time Stamp Oracle，是 PD (Placement Driver) 为每个事务提供的单调递增的时间戳。 - -TSO 是一串数字，包含以下两部分： +TSO 指 Time Stamp Oracle，是 PD (Placement Driver) 为每个事务提供的单调递增的时间戳。TSO 是一串数字，包含以下两部分： - 一个物理时间戳 - 一个逻辑计数器 -### 语法图 - -```ebnf+diagram -TableStmt ::= - "TIDB_PARSE_TSO(" NUM ")" -``` - -### 示例 - -{{< copyable "sql" >}} - ```sql BEGIN; SELECT TIDB_PARSE_TSO(@@tidb_current_ts); @@ -215,29 +150,10 @@ ROLLBACK; 以上示例使用 `TIDB_PARSE_TSO` 函数从 `tidb_current_ts` 会话变量提供的可用时间戳编号中提取物理时间戳。因为每个事务都会分配到时间戳，所以此函数在事务中运行。 -### MySQL 兼容性 - -`TIDB_PARSE_TSO` 是 TiDB 特有的函数，和 MySQL 不兼容。 - -### 另请参阅 - -- [`tidb_current_ts`](/system-variables.md#tidb_current_ts) - -## TIDB_VERSION +### TIDB_VERSION `TIDB_VERSION` 函数用于获取当前连接的 TiDB 服务器版本和构建详细信息。向 GitHub 上提交 issue 时，你可使用此函数获取相关信息。 -### 语法图 - -```ebnf+diagram -TableStmt ::= - "TIDB_VERSION()" -``` - -### 示例 - -{{< copyable "sql" >}} - ```sql SELECT TIDB_VERSION()\G ``` @@ -256,13 +172,9 @@ Check Table Before Drop: false 1 row in set (0.00 sec) ``` -### MySQL 兼容性 - -`TIDB_VERSION` 是 TiDB 特有的函数，和 MySQL 不兼容。如果要求兼容 MySQL，可以使用 `VERSION` 获取版本信息，但结果不包含详细的构建信息。 - -## TIDB_DECODE_SQL_DIGESTS +### TIDB_DECODE_SQL_DIGESTS -`TIDB_DECODE_SQL_DIGESTS` 函数用于在集群中查询一组 SQL Digest 所对应的 SQL 语句的归一化形式（即去除格式和参数后的形式）。函数接受 1 个或 2 个参数： +`TIDB_DECODE_SQL_DIGESTS()` 函数用于在集群中查询一组 SQL Digest 所对应的 SQL 语句的归一化形式（即去除格式和参数后的形式）。函数接受 1 个或 2 个参数： * `digests`：字符串类型，该参数应符合 JSON 字符串数组的格式，数组中的每个字符串应为一个 SQL Digest。 * `stmtTruncateLength`：可选参数，整数类型，用来限制返回结果中每条 SQL 语句的长度，超过指定的长度会被截断。0 表示不限制长度。 @@ -276,17 +188,6 @@ Check Table Before Drop: false > * 该函数开销较大，在行数很多的查询中（比如在规模较大、比较繁忙的集群上查询 `information_schema.cluster_tidb_trx` 全表时）直接使用该函数可能导致查询运行时间较长。请谨慎使用。 > * 该函数开销大的原因是，其每次被调用时，都会在内部发起对 `STATEMENTS_SUMMARY`、`STATEMENTS_SUMMARY_HISTORY`、`CLUSTER_STATEMENTS_SUMMARY` 和 `CLUSTER_STATEMENTS_SUMMARY_HISTORY` 这几张表的查询，且其中涉及 `UNION` 操作。且该函数目前不支持向量化，即对于多行数据调用该函数时，对每行都会独立进行一次上述的查询。 -### 语法图 - -```ebnf+diagram -DecodeSQLDigestsExpr ::= - "TIDB_DECODE_SQL_DIGESTS" "(" digests ( "," stmtTruncateLength )? ")" -``` - -### 示例 - -{{< copyable "sql" >}} - ```sql set @digests = '["e6f07d43b5c21db0fbb9a31feac2dc599787763393dd5acbfad80e247eb02ad5","38b03afa5debbdf0326a014dbe5012a62c51957f1982b3093e748460f8b00821","e5796985ccafe2f71126ed6c0ac939ffa015a8c0744a24b7aee6d587103fd2f7"]'; @@ -304,8 +205,6 @@ select tidb_decode_sql_digests(@digests); 上面的例子中，参数是一个包含 3 个 SQL Digest 的 JSON 数组，其对应的 SQL 语句分别为查询结果中给出的三项。但是其中第二条 SQL Digest 所对应的 SQL 语句未能从集群中找到，因而结果中的第二项为 `null`。 -{{< copyable "sql" >}} - ```sql select tidb_decode_sql_digests(@digests, 10); ``` @@ -321,21 +220,15 @@ select tidb_decode_sql_digests(@digests, 10); 上述调用指定了第二个参数（即截断长度）为 10，而查询结果中的第三条语句的长度大于 10，因而仅保留了前 10 个字符，并在尾部添加了 `"..."` 表示发生了截断。 -### MySQL 兼容性 - -`TIDB_DECODE_SQL_DIGESTS` 是 TiDB 特有的函数，和 MySQL 不兼容。 - -### 另请参阅 +另请参阅： - [`Statement Summary Tables`](/statement-summary-tables.md) - [`INFORMATION_SCHEMA.TIDB_TRX`](/information-schema/information-schema-tidb-trx.md) -## TIDB_SHARD +### TIDB_SHARD `TIDB_SHARD` 函数用于创建一个 SHARD INDEX 来打散热点索引。SHARD INDEX 是一种以 `TIDB_SHARD` 函数为前缀的表达式索引。 -### SHARD INDEX - - 创建方式： 使用 `uk((tidb_shard(a)), a))` 为字段 `a` 创建一个 SHARD INDEX。当二级唯一索引 `uk((tidb_shard(a)), a))` 的索引字段 `a` 上存在因单调递增或递减而产生的热点时，索引的前缀 `tidb_shard(a)` 会打散热点，从而提升集群可扩展性。 @@ -358,14 +251,7 @@ select tidb_decode_sql_digests(@digests, 10); - SHARD INDEX 无法走 FastPlan 流程，影响优化器性能。 - SHARD INDEX 无法使用执行计划缓存。 -### 语法图 - -```ebnf+diagram -TIDBShardExpr ::= - "TIDB_SHARD" "(" expr ")" -``` - -### 示例 +`TIDB_SHARD` 函数的使用示例如下： - 使用 `TIDB_SHARD` 函数计算 SHARD 值 @@ -396,6 +282,37 @@ TIDBShardExpr ::= CREATE TABLE test(id INT PRIMARY KEY CLUSTERED, a INT, b INT, UNIQUE KEY uk((tidb_shard(a)), a)); ``` -### MySQL 兼容性 +### TIDB_ROW_CHECKSUM + +`TIDB_ROW_CHECKSUM` 函数用于查询行数据的 Checksum 值。该函数只能用于 FastPlan 流程的 `SELECT` 语句，即你可通过形如 `SELECT TIDB_ROW_CHECKSUM() FROM t WHERE id = ?` 或 `SELECT TIDB_ROW_CHECKSUM() FROM t WHERE id IN (?, ?, ...)` 的语句进行查询。 + +在 TiDB 中开启行数据 Checksum 功能 [`tidb_enable_row_level_checksum`](/system-variables.md#tidb_enable_row_level_checksum-从-v710-版本开始引入)： + +```sql +SET GLOBAL tidb_enable_row_level_checksum = ON; +``` + +创建表 `t` 并插入数据： -`TIDB_SHARD` 是 TiDB 特有的函数，和 MySQL 不兼容。 +```sql +USE test; +CREATE TABLE t (id INT PRIMARY KEY, k INT, c int); +INSERT INTO TABLE t values (1, 10, a); +``` + +查询表 `t` 中 `id = 1` 的行数据的 Checksum 值： + +```sql +SELECT *, TIDB_ROW_CHECKSUM() FROM t WHERE id = 1; +``` + +输出结果如下： + +```sql ++----+------+------+---------------------+ +| id | k | c | TIDB_ROW_CHECKSUM() | ++----+------+------+---------------------+ +| 1 | 10 | a | 3813955661 | ++----+------+------+---------------------+ +1 row in set (0.000 sec) +``` diff --git a/generated-columns.md b/generated-columns.md index 5a55a12f1258..06da3251294c 100644 --- a/generated-columns.md +++ b/generated-columns.md @@ -5,10 +5,6 @@ aliases: ['/docs-cn/dev/generated-columns/','/docs-cn/dev/reference/sql/generate # 生成列 -> **警告：** -> -> 当前该功能为实验特性，不建议在生产环境中使用。 - 本文介绍生成列的概念以及用法。 ## 生成列的基本概念 diff --git a/glossary.md b/glossary.md index 2d949f9c453d..9d83220d6cd1 100644 --- a/glossary.md +++ b/glossary.md @@ -46,6 +46,10 @@ ACID 是指数据库管理系统在写入或更新资料的过程中，为保证 缓存表 (Cached Table) 是指 TiDB 把整张表的数据加载到服务器的内存中，直接从内存中获取表数据，避免从 TiKV 获取表数据，从而提升读性能。详情参见[缓存表](/cached-tables.md)。 +### Coalesce Partition + +Coalesce Partition 是一种减少 Hash 分区表或 Key 分区表中分区数量的方法。详情参见[管理 Hash 分区和 Key 分区](/partitioned-table.md#管理-hash-分区和-key-分区)。 + ### Continuous Profiling 持续性能分析 (Continuous Profiling) 是从 TiDB v5.3 起引入的一种从系统调用层面解读资源开销的方法。引入该方法后，TiDB 可提供数据库源码级性能观测，通过火焰图的形式帮助研发、运维人员定位性能问题的根因。详情参见 [TiDB Dashboard 实例性能分析 - 持续分析页面](/dashboard/continuous-profiling.md)。 @@ -99,6 +103,10 @@ Operator Step 是 Operator 执行过程的一个步骤，一个 Operator 常常 ## P +### Partitioning + +[Partitioning](/partitioned-table.md)（分区）指通过 `RANGE`、`LIST`、`HASH` 和 `KEY` 等分区方法在物理上将一张表划分为较小的分区。 + ### Pending/Down Pending 和 Down 是 Peer 可能出现的两种特殊状态。其中 Pending 表示 Follower 或 Learner 的 raft log 与 Leader 有较大差距，Pending 状态的 Follower 无法被选举成 Leader。Down 是指 Leader 长时间没有收到对应 Peer 的消息，通常意味着对应节点发生了宕机或者网络隔离。 @@ -119,7 +127,7 @@ Pending 和 Down 是 Peer 可能出现的两种特殊状态。其中 Pending 表 ## R -## Raft Engine +### Raft Engine 一种内置的持久化存储引擎，有着日志结构的设计，为 TiKV 提供 multi-Raft 日志存储。从 v5.4 起，TiDB 支持使用 Raft Engine 作为 TiKV 的日志存储引擎。详情参见 [Raft Engine](/tikv-configuration-file.md#raft-engine)。 diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index 8e5d03454b4a..c903a9fbb7cb 100644 --- a/grafana-tidb-dashboard.md +++ b/grafana-tidb-dashboard.md @@ -112,6 +112,8 @@ aliases: ['/docs-cn/dev/grafana-tidb-dashboard/','/docs-cn/dev/reference/key-mon - KV Request OPS：KV Request 根据 TiKV 显示执行次数 - KV Request Duration 99 by store：根据 TiKV 显示 KV Request 执行时间 - KV Request Duration 99 by type：根据类型显示 KV Request 的执行时间 +- Stale Read OPS：每秒执行的 Stale Read 的数量，根据结果分为 hit 和 miss 进行统计 +- Stale Read Traffic：Stale Read 消耗的流量，根据结果分为 hit 和 miss 进行统计 ### PD Client diff --git a/hardware-and-software-requirements.md b/hardware-and-software-requirements.md index 66ed02527720..b9597e90bce6 100644 --- a/hardware-and-software-requirements.md +++ b/hardware-and-software-requirements.md @@ -24,7 +24,8 @@ TiDB 作为一款开源一栈式实时 HTAP 数据库，可以很好地部署和 | Amazon Linux 2 |
  • x86_64
  • ARM 64
| | 麒麟欧拉版 V10 SP1/SP2 |
  • x86_64
  • ARM 64
| | UOS V20 |
  • x86_64
  • ARM 64
| -| macOS Catalina 及以上的版本 |
  • x86_64
  • ARM 64
| +| openEuler 22.03 LTS SP1 | x86_64 | +| macOS 12 (Monterey) 及以上的版本 |
  • x86_64
  • ARM 64
| | Oracle Enterprise Linux 7.3 及以上的 7.x 版本 | x86_64 | | Ubuntu LTS 18.04 及以上的版本 | x86_64 | | CentOS 8 Stream |
  • x86_64
  • ARM 64
| @@ -45,13 +46,20 @@ TiDB 作为一款开源一栈式实时 HTAP 数据库，可以很好地部署和 | 编译和构建 TiDB 所需的依赖库 | 版本 | | :--- | :--- | -| Golang | 1.18.5 及以上版本 | +| Golang | 1.20 及以上版本 | | Rust | nightly-2022-07-31 及以上版本 | | GCC | 7.x | | LLVM | 13.0 及以上版本 | 运行时所需的依赖库：glibc（2.28-151.el8 版本） +### Docker 镜像依赖 + +支持的 CPU 架构如下： + +- x86_64，从 TiDB v6.6.0 开始，需要 [x84-64-v2 指令集](https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level) +- ARM 64 + ## 软件配置要求 ### 中控机软件配置 @@ -100,7 +108,7 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器 | **组件** | **CPU** | **内存** | **硬盘类型** | **网络** | **实例数量(最低要求)** | | --- | --- | --- | --- | --- | --- | -| TiDB | 16 核+ | 48 GB+ | SAS | 万兆网卡（2 块最佳） | 2 | +| TiDB | 16 核+ | 48 GB+ | SSD | 万兆网卡（2 块最佳） | 2 | | PD | 8 核+ | 16 GB+ | SSD | 万兆网卡（2 块最佳） | 3 | | TiKV | 16 核+ | 64 GB+ | SSD | 万兆网卡（2 块最佳） | 3 | | TiFlash | 48 核+ | 128 GB+ | 1 or more SSDs | 万兆网卡（2 块最佳） | 2 | @@ -139,7 +147,6 @@ TiDB 作为开源一栈式实时 HTAP 数据库，其正常运行需要网络环 | PD | 2379 | 提供 TiDB 和 PD 通信端口 | | PD | 2380 | PD 集群节点间通信端口 | |TiFlash|9000|TiFlash TCP 服务端口| -|TiFlash|8123|TiFlash HTTP 服务端口| |TiFlash|3930|TiFlash RAFT 服务和 Coprocessor 服务端口| |TiFlash|20170|TiFlash Proxy 服务端口| |TiFlash|20292|Prometheus 拉取 TiFlash Proxy metrics 端口| diff --git a/identify-slow-queries.md b/identify-slow-queries.md index d840d8762b4c..b7f51d9a9397 100644 --- a/identify-slow-queries.md +++ b/identify-slow-queries.md @@ -63,7 +63,13 @@ Slow Query 基础信息： * `Txn_start_ts`：表示事务的开始时间戳，也是事务的唯一 ID，可以用这个值在 TiDB 日志中查找事务相关的其他日志。 * `Is_internal`：表示是否为 TiDB 内部的 SQL 语句。`true` 表示 TiDB 系统内部执行的 SQL 语句，`false` 表示用户执行的 SQL 语句。 * `Index_names`：表示这个语句执行用到的索引。 -* `Stats`：表示这个语句涉及表的统计信息健康状态，`pseudo` 状态表示统计信息状态不健康。 +* `Stats`：表示这个语句使用到的统计信息的健康状态、内部版本号、总行数、修改行数以及加载状态。`pseudo` 状态表示统计信息不健康。如果有尝试使用但没有完全加载的统计信息，会在之后输出其内部状态。例如，`t1:439478225786634241[105000;5000][col1:allEvicted][idx1:allEvicted]` 的含义如下： + - `t1`：本次查询优化过程中使用了 `t1` 表上的统计信息 + - `439478225786634241`：其内部版本号 + - `105000`：统计信息中维护的总行数 + - `5000`：自上次收集统计信息以来记录的修改的行数 + - `col1:allEvicted`：`col1` 列对应的统计信息没有完全加载 + - `idx1:allEvicted`：`idx1` 索引对应的统计信息没有完全加载 * `Succ`：表示语句是否执行成功。 * `Backoff_time`：表示语句遇到需要重试的错误时在重试前等待的时间。常见的需要重试的错误有以下几种：遇到了 lock、Region 分裂、`tikv server is busy`。 * `Plan`：表示语句的执行计划，用 `select tidb_decode_plan('xxx...')` SQL 语句可以解析出具体的执行计划。 @@ -94,6 +100,8 @@ Slow Query 基础信息： * `Write_keys`：表示该事务向 TiKV 的 Write CF 写入 Key 的数量。 * `Write_size`：表示事务提交时写 key 或 value 的总大小。 * `Prewrite_region`：表示事务两阶段提交中第一阶段（prewrite 阶段）涉及的 TiKV Region 数量。每个 Region 会触发一次远程过程调用。 +* `Wait_prewrite_binlog_time`：表示事务提交时用于写 binlog 的时间。 +* `Resolve_lock_time`：表示事务提交时遇到锁后，清理锁或者等待锁过期的时间。 和内存使用相关的字段： @@ -126,6 +134,12 @@ Slow Query 基础信息： * `Cop_wait_p90`：cop-task 的 P90 分位等待时间。 * `Cop_wait_max`：cop-task 的最大等待时间。 * `Cop_wait_addr`：等待时间最长的 cop-task 所在地址。 +* `Rocksdb_delete_skipped_count`：RocksDB 读数据过程中已删除 Key 的扫描数。 +* `Rocksdb_key_skipped_count`：RocksDB 扫数据时遇到的已删除 (tombstone) Key 数量。 +* `Rocksdb_block_cache_hit_count`：RocksDB 从 Block Cache 缓存中读数据的次数。 +* `Rocksdb_block_read_count`：RocksDB 从文件系统中读数据的次数。 +* `Rocksdb_block_read_byte`：RocksDB 从文件系统中读数据的数据量。 +* `Rocksdb_block_read_time`：RocksDB 从文件系统中读数据的时间。 * `Cop_backoff_{backoff-type}_total_times`：因某种错误造成的 backoff 总次数。 * `Cop_backoff_{backoff-type}_total_time`：因某种错误造成的 backoff 总时间。 * `Cop_backoff_{backoff-type}_max_time`：因某种错误造成的最大 backoff 时间。 @@ -133,6 +147,19 @@ Slow Query 基础信息： * `Cop_backoff_{backoff-type}_avg_time`：因某种错误造成的平均 backoff 时间。 * `Cop_backoff_{backoff-type}_p90_time`：因某种错误造成的 P90 分位 backoff 时间。 +`backoff-type` 一般有以下几种： + +* `tikvRPC`：给 TiKV 发送 RPC 请求失败而产生的 backoff。 +* `tiflashRPC`：给 TiFlash 发送 RPC 请求失败而产生的 backoff。 +* `pdRPC`：给 PD 发送 RPC 请求失败而产生的 backoff。 +* `txnLock`：遇到锁冲突后产生的 backoff。 +* `regionMiss`：Region 发生分裂或者合并后，TiDB 的 Region 缓存信息过期导致请求失败而产生的 backoff。 +* `regionScheduling`：Region 还在调度中，尚未选出 Leader 导致无法处理请求而产生的 backoff。 +* `tikvServerBusy`：因为 TiKV 负载太高无法处理新请求而产生的 backoff。 +* `tiflashServerBusy`：因为 TiFlash 负载太高无法处理新请求而产生的 backoff。 +* `tikvDiskFull`：因为 TiKV 的磁盘满了而产生的 backoff。 +* `txnLockFast`：因为读数据时遇到了锁而产生的 backoff。 + ## 相关系统变量 * [tidb_slow_log_threshold](/system-variables.md#tidb_slow_log_threshold)：设置慢日志的阈值，执行时间超过阈值的 SQL 语句将被记录到慢日志中。默认值是 300 ms。 diff --git a/information-schema/information-schema-resource-groups.md b/information-schema/information-schema-resource-groups.md index 08c2b4df0100..8751a0de4337 100644 --- a/information-schema/information-schema-resource-groups.md +++ b/information-schema/information-schema-resource-groups.md @@ -5,10 +5,6 @@ summary: 了解 information_schema 表 `RESOURCE_GROUPS`。 # RESOURCE_GROUPS -> **警告:** -> -> 资源管控是 TiDB 在 v6.6.0 中引入的实验特性，其语法或者行为表现在 GA 前可能会发生变化。 - `RESOURCE_GROUPS` 表展示所有资源组 (resource group) 的信息，见[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)。 ```sql @@ -68,11 +64,11 @@ SELECT * FROM information_schema.resource_groups WHERE NAME = 'rg1'; -- 查看 ``` ```sql -+------+------------+----------+-----------+ -| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | -+------+------------+----------+-----------+ -| rg1 | 1000 | MEDIUM | NO | -+------+------------+----------+-----------+ ++------+------------+----------+-----------+-------------+ +| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT | ++------+------------+----------+-----------+-------------+ +| rg1 | 1000 | MEDIUM | NO | NULL | ++------+------------+----------+-----------+-------------+ 1 row in set (0.00 sec) ``` diff --git a/information-schema/information-schema-tidb-servers-info.md b/information-schema/information-schema-tidb-servers-info.md index 5e20c88f7e62..2f2ca5e1ea67 100644 --- a/information-schema/information-schema-tidb-servers-info.md +++ b/information-schema/information-schema-tidb-servers-info.md @@ -46,8 +46,8 @@ SELECT * FROM TIDB_SERVERS_INFO\G PORT: 4000 STATUS_PORT: 10080 LEASE: 45s - VERSION: 5.7.25-TiDB-v6.5.0 - GIT_HASH: 827d8ff2d22ac4c93ae1b841b79d468211e1d393 + VERSION: 5.7.25-TiDB-v7.2.0 + GIT_HASH: 635a4362235e8a3c0043542e629532e3c7bb2756 BINLOG_STATUS: Off LABELS: 1 row in set (0.006 sec) diff --git a/keywords.md b/keywords.md index c6a4d2ff1fd4..8a01665c8193 100644 --- a/keywords.md +++ b/keywords.md @@ -79,9 +79,12 @@ Query OK, 0 rows affected (0.08 sec) - ANALYZE (R) - AND (R) - ANY +- ARRAY (R) - AS (R) - ASC (R) - ASCII +- ATTRIBUTE +- ATTRIBUTES - AUTO_ID_CACHE - AUTO_INCREMENT - AUTO_RANDOM @@ -95,11 +98,13 @@ Query OK, 0 rows affected (0.08 sec) - BACKUP - BACKUPS - BEGIN +- BERNOULLI - BETWEEN (R) - BIGINT (R) - BINARY (R) - BINDING - BINDINGS +- BINDING_CACHE - BINLOG - BIT - BLOB (R) @@ -116,11 +121,14 @@ Query OK, 0 rows affected (0.08 sec) C - CACHE +- CALIBRATE +- CALL (R) - CANCEL (R) - CAPTURE - CASCADE (R) - CASCADED - CASE (R) +- CAUSAL - CHAIN - CHANGE (R) - CHAR (R) @@ -132,13 +140,17 @@ Query OK, 0 rows affected (0.08 sec) - CIPHER - CLEANUP - CLIENT +- CLIENT_ERRORS_SUMMARY +- CLOSE +- CLUSTER +- CLUSTERED - CMSKETCH (R) - COALESCE - COLLATE (R) - COLLATION - COLUMN (R) -- COLUMNS - COLUMN_FORMAT +- COLUMNS - COMMENT - COMMIT - COMMITTED @@ -148,9 +160,11 @@ Query OK, 0 rows affected (0.08 sec) - CONCURRENCY - CONFIG - CONNECTION +- CONSISTENCY - CONSISTENT - CONSTRAINT (R) - CONTEXT +- CONTINUE (R) - CONVERT (R) - CPU - CREATE (R) @@ -169,6 +183,7 @@ Query OK, 0 rows affected (0.08 sec) - CURRENT_TIME (R) - CURRENT_TIMESTAMP (R) - CURRENT_USER (R) +- CURSOR (R) - CYCLE D @@ -186,17 +201,20 @@ Query OK, 0 rows affected (0.08 sec) - DDL (R) - DEALLOCATE - DECIMAL (R) +- DECLARE - DEFAULT (R) - DEFINER -- DELAYED (R) - DELAY_KEY_WRITE +- DELAYED (R) - DELETE (R) - DENSE_RANK (R-Window) - DEPTH (R) - DESC (R) - DESCRIBE (R) +- DIGEST - DIRECTORY - DISABLE +- DISABLED - DISCARD - DISK - DISTINCT (R) @@ -213,7 +231,9 @@ Query OK, 0 rows affected (0.08 sec) E - ELSE (R) +- ELSEIF (R) - ENABLE +- ENABLED - ENCLOSED (R) - ENCRYPTION - END @@ -233,6 +253,7 @@ Query OK, 0 rows affected (0.08 sec) - EXCLUSIVE - EXECUTE - EXISTS (R) +- EXIT (R) - EXPANSION - EXPIRE - EXPLAIN (R) @@ -240,8 +261,10 @@ Query OK, 0 rows affected (0.08 sec) F +- FAILED_LOGIN_ATTEMPTS - FALSE (R) - FAULTS +- FETCH (R) - FIELDS - FILE - FIRST @@ -254,6 +277,7 @@ Query OK, 0 rows affected (0.08 sec) - FORCE (R) - FOREIGN (R) - FORMAT +- FOUND - FROM (R) - FULL - FULLTEXT (R) @@ -271,9 +295,12 @@ Query OK, 0 rows affected (0.08 sec) H +- HANDLER - HASH - HAVING (R) +- HELP - HIGH_PRIORITY (R) +- HISTOGRAM - HISTORY - HOSTS - HOUR @@ -286,6 +313,7 @@ Query OK, 0 rows affected (0.08 sec) - IDENTIFIED - IF (R) - IGNORE (R) +- ILIKE (R) - IMPORT - IMPORTS - IN (R) @@ -295,6 +323,7 @@ Query OK, 0 rows affected (0.08 sec) - INDEXES - INFILE (R) - INNER (R) +- INOUT (R) - INSERT (R) - INSERT_METHOD - INSTANCE @@ -305,6 +334,7 @@ Query OK, 0 rows affected (0.08 sec) - INT4 (R) - INT8 (R) - INTEGER (R) +- INTERSECT (R) - INTERVAL (R) - INTO (R) - INVISIBLE @@ -314,6 +344,7 @@ Query OK, 0 rows affected (0.08 sec) - IS (R) - ISOLATION - ISSUER +- ITERATE (R) J @@ -335,11 +366,12 @@ Query OK, 0 rows affected (0.08 sec) - LAG (R-Window) - LANGUAGE - LAST -- LASTVAL - LAST_BACKUP - LAST_VALUE (R-Window) +- LASTVAL - LEAD (R-Window) - LEADING (R) +- LEAVE (R) - LEFT (R) - LESS - LEVEL @@ -354,6 +386,7 @@ Query OK, 0 rows affected (0.08 sec) - LOCALTIMESTAMP (R) - LOCATION - LOCK (R) +- LOCKED - LOGS - LONG (R) - LONGBLOB (R) @@ -376,6 +409,7 @@ Query OK, 0 rows affected (0.08 sec) - MEDIUMBLOB (R) - MEDIUMINT (R) - MEDIUMTEXT (R) +- MEMBER - MEMORY - MERGE - MICROSECOND @@ -406,6 +440,7 @@ Query OK, 0 rows affected (0.08 sec) - NODE_STATE (R) - NOMAXVALUE - NOMINVALUE +- NONCLUSTERED - NONE - NOT (R) - NOWAIT @@ -419,18 +454,25 @@ Query OK, 0 rows affected (0.08 sec) O +- OF (R) +- OFF - OFFSET +- OLTP_READ_ONLY +- OLTP_READ_WRITE +- OLTP_WRITE_ONLY - ON (R) +- ON_DUPLICATE - ONLINE - ONLY -- ON_DUPLICATE - OPEN - OPTIMISTIC (R) - OPTIMIZE (R) - OPTION (R) +- OPTIONAL - OPTIONALLY (R) - OR (R) - ORDER (R) +- OUT (R) - OUTER (R) - OUTFILE (R) - OVER (R-Window) @@ -445,15 +487,21 @@ Query OK, 0 rows affected (0.08 sec) - PARTITIONING - PARTITIONS - PASSWORD +- PASSWORD_LOCK_TIME +- PAUSE +- PERCENT - PERCENT_RANK (R-Window) - PER_DB - PER_TABLE - PESSIMISTIC (R) - PLACEMENT (S) - PLUGINS +- POINT +- POLICY - PRECEDING - PRECISION (R) - PREPARE +- PRESERVE - PRE_SPLIT_REGIONS - PRIMARY (R) - PRIVILEGES @@ -462,7 +510,9 @@ Query OK, 0 rows affected (0.08 sec) - PROCESSLIST - PROFILE - PROFILES +- PROXY - PUMP (R) +- PURGE Q @@ -480,6 +530,7 @@ Query OK, 0 rows affected (0.08 sec) - REAL (R) - REBUILD - RECOVER +- RECURSIVE (R) - REDUNDANT - REFERENCES (R) - REGEXP (R) @@ -495,12 +546,18 @@ Query OK, 0 rows affected (0.08 sec) - REPEATABLE - REPLACE (R) - REPLICA +- REPLICAS - REPLICATION - REQUIRE (R) +- REQUIRED +- RESOURCE - RESPECT +- RESTART - RESTORE - RESTORES - RESTRICT (R) +- RESUME +- REUSE - REVERSE - REVOKE (R) - RIGHT (R) @@ -509,20 +566,22 @@ Query OK, 0 rows affected (0.08 sec) - ROLLBACK - ROUTINE - ROW (R) -- ROWS (R-Window) - ROW_COUNT - ROW_FORMAT - ROW_NUMBER (R-Window) +- ROWS (R-Window) - RTREE S - SAMPLES (R) +- SAN +- SAVEPOINT - SECOND +- SECOND_MICROSECOND (R) - SECONDARY_ENGINE - SECONDARY_LOAD - SECONDARY_UNLOAD -- SECOND_MICROSECOND (R) - SECURITY - SELECT (R) - SEND_CREDENTIALS_TO_TIKV @@ -540,6 +599,7 @@ Query OK, 0 rows affected (0.08 sec) - SHUTDOWN - SIGNED - SIMPLE +- SKIP - SKIP_SCHEMA_FILES - SLAVE - SLOW @@ -564,17 +624,25 @@ Query OK, 0 rows affected (0.08 sec) - SQL_TSI_SECOND - SQL_TSI_WEEK - SQL_TSI_YEAR +- SQLEXCEPTION (R) +- SQLSTATE (R) +- SQLWARNING (R) - SSL (R) - START - STARTING (R) - STATS (R) - STATS_AUTO_RECALC - STATS_BUCKETS (R) +- STATS_COL_CHOICE +- STATS_COL_LIST +- STATS_EXTENDED (R) - STATS_HEALTHY (R) - STATS_HISTOGRAMS (R) - STATS_META (R) +- STATS_OPTIONS - STATS_PERSISTENT - STATS_SAMPLE_PAGES +- STATS_SAMPLE_RATE - STATUS - STORAGE - STORED (R) @@ -586,12 +654,14 @@ Query OK, 0 rows affected (0.08 sec) - SUPER - SWAPS - SWITCHES +- SYSTEM - SYSTEM_TIME T - TABLE (R) - TABLES +- TABLESAMPLE (R) - TABLESPACE - TABLE_CHECKSUM - TEMPORARY @@ -611,6 +681,7 @@ Query OK, 0 rows affected (0.08 sec) - TO (R) - TOKEN_ISSUER - TOPN (R) +- TPCC - TRACE - TRADITIONAL - TRAILING (R) @@ -619,7 +690,11 @@ Query OK, 0 rows affected (0.08 sec) - TRIGGERS - TRUE (R) - TRUNCATE +- TTL +- TTL_ENABLE +- TTL_JOB_INTERVAL - TYPE +- TiDB_CURRENT_TSO (R) U @@ -632,6 +707,7 @@ Query OK, 0 rows affected (0.08 sec) - UNKNOWN - UNLOCK (R) - UNSIGNED (R) +- UNTIL (R) - UPDATE (R) - USAGE (R) - USE (R) @@ -657,15 +733,18 @@ Query OK, 0 rows affected (0.08 sec) W +- WAIT - WARNINGS - WEEK - WEIGHT_STRING - WHEN (R) - WHERE (R) +- WHILE (R) - WIDTH (R) - WINDOW (R-Window) - WITH (R) - WITHOUT +- WORKLOAD - WRITE (R) X diff --git a/media/dashboard/dashboard-resource-manager-calibrate-by-hardware.png b/media/dashboard/dashboard-resource-manager-calibrate-by-hardware.png new file mode 100644 index 000000000000..b9f6596e25a7 Binary files /dev/null and b/media/dashboard/dashboard-resource-manager-calibrate-by-hardware.png differ diff --git a/media/dashboard/dashboard-resource-manager-calibrate-by-workload.png b/media/dashboard/dashboard-resource-manager-calibrate-by-workload.png new file mode 100644 index 000000000000..bbc659e5ccb5 Binary files /dev/null and b/media/dashboard/dashboard-resource-manager-calibrate-by-workload.png differ diff --git a/media/dashboard/dashboard-resource-manager-info.png b/media/dashboard/dashboard-resource-manager-info.png new file mode 100644 index 000000000000..0055b7709744 Binary files /dev/null and b/media/dashboard/dashboard-resource-manager-info.png differ diff --git a/media/dashboard/dashboard-slow-queries-export-v651.png b/media/dashboard/dashboard-slow-queries-export-v651.png new file mode 100644 index 000000000000..b587f8ead4fb Binary files /dev/null and b/media/dashboard/dashboard-slow-queries-export-v651.png differ diff --git a/media/dist-task/dist-task-architect.jpg b/media/dist-task/dist-task-architect.jpg new file mode 100644 index 000000000000..aea83125351c Binary files /dev/null and b/media/dist-task/dist-task-architect.jpg differ diff --git a/media/non-prepapred-plan-cache-unsupprot.png b/media/non-prepapred-plan-cache-unsupprot.png new file mode 100644 index 000000000000..6c365ffe639b Binary files /dev/null and b/media/non-prepapred-plan-cache-unsupprot.png differ diff --git a/media/ticdc/ticdc-summary-monitor-changefeed.png b/media/ticdc/ticdc-summary-monitor-changefeed.png new file mode 100644 index 000000000000..0c991cb90c6a Binary files /dev/null and b/media/ticdc/ticdc-summary-monitor-changefeed.png differ diff --git a/media/ticdc/ticdc-summary-monitor-cloud-storage.png b/media/ticdc/ticdc-summary-monitor-cloud-storage.png new file mode 100644 index 000000000000..d6fa1e4887d5 Binary files /dev/null and b/media/ticdc/ticdc-summary-monitor-cloud-storage.png differ diff --git a/media/ticdc/ticdc-summary-monitor-dataflow-mounter.png b/media/ticdc/ticdc-summary-monitor-dataflow-mounter.png new file mode 100644 index 000000000000..a3607457d399 Binary files /dev/null and b/media/ticdc/ticdc-summary-monitor-dataflow-mounter.png differ diff --git a/media/ticdc/ticdc-summary-monitor-dataflow-puller.png b/media/ticdc/ticdc-summary-monitor-dataflow-puller.png new file mode 100644 index 000000000000..a960e01d98b3 Binary files /dev/null and b/media/ticdc/ticdc-summary-monitor-dataflow-puller.png differ diff --git a/media/ticdc/ticdc-summary-monitor-dataflow-sink.png b/media/ticdc/ticdc-summary-monitor-dataflow-sink.png new file mode 100644 index 000000000000..d7bfab00c134 Binary files /dev/null and b/media/ticdc/ticdc-summary-monitor-dataflow-sink.png differ diff --git a/media/ticdc/ticdc-summary-monitor-dataflow-sorter.png b/media/ticdc/ticdc-summary-monitor-dataflow-sorter.png new file mode 100644 index 000000000000..5b55bedd7cbb Binary files /dev/null and b/media/ticdc/ticdc-summary-monitor-dataflow-sorter.png differ diff --git a/media/ticdc/ticdc-summary-monitor-mq-sink.png b/media/ticdc/ticdc-summary-monitor-mq-sink.png new file mode 100644 index 000000000000..639f45a315d0 Binary files /dev/null and b/media/ticdc/ticdc-summary-monitor-mq-sink.png differ diff --git a/media/ticdc/ticdc-summary-monitor-redo.png b/media/ticdc/ticdc-summary-monitor-redo.png new file mode 100644 index 000000000000..c9d155f77c26 Binary files /dev/null and b/media/ticdc/ticdc-summary-monitor-redo.png differ diff --git a/media/ticdc/ticdc-summary-monitor-server.png b/media/ticdc/ticdc-summary-monitor-server.png new file mode 100644 index 000000000000..b28f788b6e22 Binary files /dev/null and b/media/ticdc/ticdc-summary-monitor-server.png differ diff --git a/media/ticdc/ticdc-summary-monitor-transaction-sink.png b/media/ticdc/ticdc-summary-monitor-transaction-sink.png new file mode 100644 index 000000000000..c6c9ceb8d5fa Binary files /dev/null and b/media/ticdc/ticdc-summary-monitor-transaction-sink.png differ diff --git a/media/ticdc/ticdc-summary-monitor.png b/media/ticdc/ticdc-summary-monitor.png new file mode 100644 index 000000000000..9c255b6e711f Binary files /dev/null and b/media/ticdc/ticdc-summary-monitor.png differ diff --git a/media/tiflash/tiflash-pipeline-model.png b/media/tiflash/tiflash-pipeline-model.png new file mode 100644 index 000000000000..f97c57c90524 Binary files /dev/null and b/media/tiflash/tiflash-pipeline-model.png differ diff --git a/metadata-lock.md b/metadata-lock.md index 99b6d0417780..31d4204964d2 100644 --- a/metadata-lock.md +++ b/metadata-lock.md @@ -64,7 +64,7 @@ summary: 介绍 TiDB 中元数据锁的概念、原理、实现和影响。 | `COMMIT;` | | | `BEGIN;` | | | | `ALTER TABLE t MODIFY COLUMN a CHAR(10);` | - | `SELECT * FROM t;` (报错 `Information schema is changed`) | | + | `SELECT * FROM t;` (报错 `Error 8028: Information schema is changed`) | | ## 元数据锁的可观测性 diff --git a/metrics-schema.md b/metrics-schema.md index a164fc901547..9e27ee92dafc 100644 --- a/metrics-schema.md +++ b/metrics-schema.md @@ -116,7 +116,7 @@ select * from information_schema.metrics_tables where table_name='tidb_query_dur ``` * `TABLE_NAME`：对应于 `metrics_schema` 中的表名，这里表名是 `tidb_query_duration`。 -* `PROMQL`：因为监控表的原理是将 SQL 映射成 `PromQL` 后向 Prometheus 请求数据，并将 Prometheus 返回的结果转换成 SQL 查询结果。该字段是 `PromQL` 的表达式模板，查询监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 +* `PROMQL`：监控表的原理是将 SQL 映射成 `PromQL` 后向 Prometheus 请求数据，并将 Prometheus 返回的结果转换成 SQL 查询结果。该字段是 `PromQL` 的表达式模板，查询监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 * `LABELS`：监控项定义的 label，`tidb_query_duration` 有两个 label，分别是 `instance` 和 `sql_type`。 * `QUANTILE`：百分位。直方图类型的监控数据会指定一个默认百分位。如果值为 `0`，表示该监控表对应的监控不是直方图。`tidb_query_duration` 默认查询 0.9，也就是 P90 的监控值。 * `COMMENT`：对这个监控表的解释。可以看出 `tidb_query_duration` 表是用来查询 TiDB query 执行的百分位时间，如 P999/P99/P90 的查询耗时，单位是秒。 @@ -144,7 +144,7 @@ show create table metrics_schema.tidb_query_duration; ``` * `time`：监控项的时间。 -* `instance` 和 `sql_type`：是 `tidb_query_duration` 这个监控项的 label。`instance` 表示监控的地址，`sql_type` 表示执行 SQL 的类似。 +* `instance` 和 `sql_type`：`tidb_query_duration` 监控项的 label。`instance` 表示监控的地址，`sql_type` 表示执行 SQL 的类似。 * `quantile`，百分位，直方图类型的监控都会有该列，表示查询的百分位时间，如 `quantile=0.9` 就是查询 P90 的时间。 * `value`：监控项的值。 diff --git a/migrate-aurora-to-tidb.md b/migrate-aurora-to-tidb.md index ca9bb0088f2b..beef1d329203 100644 --- a/migrate-aurora-to-tidb.md +++ b/migrate-aurora-to-tidb.md @@ -8,108 +8,130 @@ aliases: ['/zh/tidb/dev/migrate-from-aurora-using-lightning/','/docs-cn/dev/migr 本文档介绍如何从 Amazon Aurora 迁移数据到 TiDB，迁移过程采用 [DB snapshot](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backups.html)，可以节约大量的空间和时间成本。整个迁移包含两个过程： -- 使用 Lightning 导入全量数据到 TiDB +- 使用 TiDB Lightning 导入全量数据到 TiDB - 使用 DM 持续增量同步到 TiDB（可选） ## 前提条件 -- [安装 Dumpling 和 Lightning](/migration-tools.md)。 +- [安装 Dumpling 和 TiDB Lightning](/migration-tools.md)。如果你要在目标端手动创建相应的表，则无需安装 Dumpling。 - [获取 Dumpling 所需上游数据库权限](/dumpling-overview.md#需要的权限)。 -- [获取 Lightning 所需下游数据库权限](/tidb-lightning/tidb-lightning-faq.md#tidb-lightning-对下游数据库的账号权限要求是怎样的)。 +- [获取 TiDB Lightning 所需下游数据库权限](/tidb-lightning/tidb-lightning-faq.md#tidb-lightning-对下游数据库的账号权限要求是怎样的)。 ## 导入全量数据到 TiDB -### 第 1 步：导出 Aurora 快照文件到 Amazon S3 +### 第 1 步：导出和导入 schema 文件 -1. 在 Aurora 上，执行以下命令，查询并记录当前 binlog 位置： +如果你已经提前手动在目标库创建好了相应的表，则可以跳过本节内容。 - ```sql - mysql> SHOW MASTER STATUS; - ``` +#### 1.1 导出 schema 文件 - 你将得到类似以下的输出，请记录 binlog 名称和位置，供后续步骤使用： +因为 Amazon Aurora 生成的快照文件并不包含建表语句文件，所以你需要使用 Dumpling 自行导出 schema 并使用 TiDB Lightning 在下游创建 schema。 - ``` - +------------------+----------+--------------+------------------+-------------------+ - | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | - +------------------+----------+--------------+------------------+-------------------+ - | mysql-bin.000002 | 52806 | | | | - +------------------+----------+--------------+------------------+-------------------+ - 1 row in set (0.012 sec) - ``` +运行以下命令时，建议使用 `--filter` 参数仅导出所需表的 schema。命令中所用参数描述，请参考 [Dumpling 主要选项表](/dumpling-overview.md#dumpling-主要选项表)。 + +```shell +export AWS_ACCESS_KEY_ID=${access_key} +export AWS_SECRET_ACCESS_KEY=${secret_key} +tiup dumpling --host ${host} --port 3306 --user root --password ${password} --filter 'my_db1.table[12],mydb.*' --consistency none --no-data --output 's3://my-bucket/schema-backup' +``` + +记录上面命令中导出的 schema 的 URI，例如 's3://my-bucket/schema-backup'，后续导入 schema 时要用到。 + +为了获取 Amazon S3 的访问权限，可以将该 Amazon S3 的 Secret Access Key 和 Access Key 作为环境变量传入 Dumpling 或 TiDB Lightning。另外，Dumpling 或 TiDB Lightning 也可以通过 `~/.aws/credentials` 读取凭证文件。使用凭证文件可以让这台机器上所有的 Dumpling 或 TiDB Lightning 任务无需再次传入相关 Secret Access Key 和 Access Key。 -2. 导出 Aurora 快照文件。具体方式请参考 Aurora 的官方文档：[Exporting DB snapshot data to Amazon S3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_ExportSnapshot.html). +#### 1.2 编写用于导入 schema 文件的 TiDB Lightning 配置文件 -请注意，上述两步的时间间隔建议不要超过 5 分钟，否则记录的 binlog 位置过旧可能导致增量同步时产生数据冲突。 +新建 `tidb-lightning-schema.toml` 文件，将以下内容复制到文件中并替换对应的内容。 -完成上述两步后，你需要准备好以下信息： +```toml +[tidb] -- 创建快照点时，Aurora binlog 的名称及位置。 -- 快照文件的 S3 路径，以及具有访问权限的 SecretKey 和 AccessKey。 +# 目标 TiDB 集群信息。 +host = ${host} +port = ${port} +user = "${user_name}" +password = "${password}" +status-port = ${status-port} # TiDB 的“状态端口”，通常为 10080 +pd-addr = "${ip}:${port}" # 集群 PD 的地址，port 通常为 2379 -### 第 2 步：导出 schema +[tikv-importer] +# 采用默认的物理导入模式 ("local")。注意该模式在导入期间下游 TiDB 无法对外提供服务。 +# 关于后端模式更多信息，请参阅：https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-overview +backend = "local" -因为 Aurora 生成的快照文件并不包含建表语句文件，所以你需要使用 Dumpling 自行导出 schema 并使用 Lightning 在下游创建 schema。你也可以跳过此步骤，并以手动方式在下游自行创建 schema。 +# 设置排序的键值对的临时存放地址，目标路径必须是一个空目录，目录空间须大于待导入数据集的大小。 +# 建议设为与 `data-source-dir` 不同的磁盘目录并使用闪存介质，独占 IO 会获得更好的导入性能。 +sorted-kv-dir = "${path}" -运行以下命令，建议使用 `--filter` 参数仅导出所需表的 schema： +[mydumper] +# 设置从 Amazon Aurora 导出的 schema 文件的地址 +data-source-dir = "s3://my-bucket/schema-backup" +``` + +如果需要在 TiDB 开启 TLS，请参考 [TiDB Lightning 配置参数](/tidb-lightning/tidb-lightning-configuration.md)。 + +#### 1.3 导入 schema 文件 -{{< copyable "shell-regular" >}} +使用 TiDB Lightning 导入 schema 到下游的 TiDB。 ```shell -tiup dumpling --host ${host} --port 3306 --user root --password ${password} --filter 'my_db1.table[12]' --no-data --output 's3://my-bucket/schema-backup' --filter "mydb.*" +export AWS_ACCESS_KEY_ID=${access_key} +export AWS_SECRET_ACCESS_KEY=${secret_access_key} +nohup tiup tidb-lightning -config tidb-lightning-schema.toml > nohup.out 2>&1 & ``` -命令中所用参数描述如下。如需更多信息可参考 [Dumpling overview](/dumpling-overview.md)。 +### 第 2 步：导出和导入 Amazon Aurora 快照文件 + +本节介绍如何导出和导入 Amazon Aurora 快照文件。 + +#### 2.1 导出 Amazon Aurora 快照文件到 Amazon S3 -|参数 |说明| -|- |-| -|-u 或 --user |Aurora MySQL 数据库的用户| -|-p 或 --password |MySQL 数据库的用户密码| -|-P 或 --port |MySQL 数据库的端口| -|-h 或 --host |MySQL 数据库的 IP 地址| -|-t 或 --thread |导出的线程数| -|-o 或 --output |存储导出文件的目录，支持本地文件路径或[外部存储 URI 格式](/br/backup-and-restore-storages.md)| -|-r 或 --row |单个文件的最大行数| -|-F |指定单个文件的最大大小，单位为 MiB，建议值 256 MiB| -|-B 或 --database |导出指定数据库| -|-T 或 --tables-list |导出指定数据表| -|-d 或 --no-data |不导出数据，仅导出 schema| -|-f 或 --filter |导出能匹配模式的表，不可用 -T 一起使用，语法可参考[table filter](/table-filter.md)| +1. 获取 Amazon Aurora binlog 的名称及位置以便于后续的增量迁移。在 Amazon Aurora 上，执行 `SHOW MASTER STATUS` 并记录当前 binlog 位置： -### 第 3 步：编写 Lightning 配置文件 + ```sql + SHOW MASTER STATUS; + ``` -根据以下内容创建 `tidb-lightning.toml` 配置文件： + 你将得到类似以下的输出，请记录 binlog 名称和位置，供后续步骤使用： -{{< copyable "shell-regular" >}} + ``` + +----------------------------+----------+--------------+------------------+-------------------+ + | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | + +----------------------------+----------+--------------+------------------+-------------------+ + | mysql-bin-changelog.018128 | 52806 | | | | + +----------------------------+----------+--------------+------------------+-------------------+ + 1 row in set (0.012 sec) + ``` -```shell -vim tidb-lightning.toml -``` +2. 导出 Amazon Aurora 快照文件。具体方式请参考 Amazon Aurora 的官方文档：[Exporting DB snapshot data to Amazon S3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_ExportSnapshot.html)。请注意，执行 `SHOW MASTER STATUS` 命令和导出 Amazon Aurora 快照文件的时间间隔建议不要超过 5 分钟，否则记录的 binlog 位置过旧可能导致增量同步时产生数据冲突。 -{{< copyable "" >}} +#### 2.2 编写用于导入快照文件的 TiDB Lightning 配置文件 + +新建 `tidb-lightning-data.toml` 文件，将以下内容复制到文件中并替换对应的内容。 ```toml [tidb] -# 目标 TiDB 集群信息. -host = ${host} # 例如：172.16.32.1 -port = ${port} # 例如：4000 -user = "${user_name}" # 例如："root" -password = "${password}" # 例如："rootroot" -status-port = ${status-port} # 表结构信息在从 TiDB 的“状态端口”获取例如：10080 -pd-addr = "${ip}:${port}" # 集群 PD 的地址，lightning 通过 PD 获取部分信息，例如 172.16.31.3:2379。当 backend = "local" 时 status-port 和 pd-addr 必须正确填写，否则导入将出现异常。 +# 目标 TiDB 集群信息。 +host = ${host} +port = ${port} +user = "${user_name}" +password = "${password}" +status-port = ${status-port} # TiDB 的“状态端口”，通常为 10080 +pd-addr = "${ip}:${port}" # 集群 PD 的地址，port 通常为 2379 [tikv-importer] -# "local"：默认使用该模式，适用于 TB 级以上大数据量，但导入期间下游 TiDB 无法对外提供服务。 -# "tidb"：TB 级以下数据量也可以采用`tidb`后端模式，下游 TiDB 可正常提供服务。关于后端模式更多信息请参阅：https://docs.pingcap.com/tidb/stable/tidb-lightning-backends +# 采用默认的物理导入模式 ("local")。注意该模式在导入期间下游 TiDB 无法对外提供服务。 +# 关于后端模式更多信息请参阅：https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-overview backend = "local" -# 设置排序的键值对的临时存放地址，目标路径必须是一个空目录，目录空间须大于待导入数据集的大小，建议设为与 `data-source-dir` 不同的磁盘目录并使用闪存介质，独占 IO 会获得更好的导入性能。 +# 设置排序的键值对的临时存放地址，目标路径必须是一个空目录，目录空间须大于待导入数据集的大小。 +# 建议设为与 `data-source-dir` 不同的磁盘目录并使用闪存介质，独占 IO 会获得更好的导入性能。 sorted-kv-dir = "${path}" [mydumper] -# 快照文件的地址 -data-source-dir = "${s3_path}" # eg: s3://my-bucket/sql-backup +# 设置从 Amazon Aurora 导出的快照文件的地址 +data-source-dir = "s3://my-bucket/sql-backup" [[mydumper.files]] # 解析 parquet 文件所需的表达式 @@ -119,37 +141,25 @@ table = '$2' type = '$3' ``` -如果需要在 TiDB 开启 TLS，请参考 [TiDB Lightning Configuration](/tidb-lightning/tidb-lightning-configuration.md)。 - -### 第 4 步：导入全量数据到 TiDB +如果需要在 TiDB 开启 TLS，请参考 [TiDB Lightning 配置参数](/tidb-lightning/tidb-lightning-configuration.md)。 -1. 使用 Lightning 在下游 TiDB 建表: +#### 2.3 导入全量数据到 TiDB - {{< copyable "shell-regular" >}} - - ```shell - tiup tidb-lightning -config tidb-lightning.toml -d 's3://my-bucket/schema-backup' - ``` - -2. 运行 `tidb-lightning`。如果直接在命令行中启动程序，可能会因为 `SIGHUP` 信号而退出，建议配合 `nohup` 或 `screen` 等工具，如： - - 将有权限访问该 Amazon S3 后端存储的账号的 SecretKey 和 AccessKey 作为环境变量传入 Lightning 节点。同时还支持从 `~/.aws/credentials` 读取凭证文件。 - - {{< copyable "shell-regular" >}} +1. 使用 TiDB Lightning 导入 Aurora Snapshot 的数据到 TiDB。 ```shell export AWS_ACCESS_KEY_ID=${access_key} - export AWS_SECRET_ACCESS_KEY=${secret_key} - nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out 2>&1 & + export AWS_SECRET_ACCESS_KEY=${secret_access_key} + nohup tiup tidb-lightning -config tidb-lightning-data.toml > nohup.out 2>&1 & ``` -3. 导入开始后，可以采用以下任意方式查看进度： +2. 导入开始后，可以采用以下任意方式查看进度： - 通过 `grep` 日志关键字 `progress` 查看进度，默认 5 分钟更新一次。 - 通过监控面板查看进度，请参考 [TiDB Lightning 监控](/tidb-lightning/monitor-tidb-lightning.md)。 - 通过 Web 页面查看进度，请参考 [Web 界面](/tidb-lightning/tidb-lightning-web-interface.md)。 -4. 导入完毕后，TiDB Lightning 会自动退出。查看 `tidb-lightning.log` 日志末尾是否有 `the whole procedure completed` 信息，如果有，表示导入成功。如果没有，则表示导入遇到了问题，可根据日志中的 error 提示解决遇到的问题。 +3. 导入完毕后，TiDB Lightning 会自动退出。查看 `tidb-lightning.log` 日志末尾是否有 `the whole procedure completed` 信息，如果有，表示导入成功。如果没有，则表示导入遇到了问题，可根据日志中的 error 提示解决遇到的问题。 > **注意：** > @@ -168,8 +178,6 @@ type = '$3' 1. 新建 `source1.yaml` 文件，写入以下内容： - {{< copyable "" >}} - ```yaml # 唯一命名，不可重复。 source-id: "mysql-01" @@ -186,8 +194,6 @@ type = '$3' 2. 在终端中执行下面的命令，使用 `tiup dmctl` 将数据源配置加载到 DM 集群中: - {{< copyable "shell-regular" >}} - ```shell tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml ``` @@ -233,7 +239,7 @@ mysql-instances: block-allow-list: "listA" # 引入上面黑白名单配置。 # syncer-config-name: "global" # syncer 配置的名称 meta: # `task-mode` 为 `incremental` 且下游数据库的 `checkpoint` 不存在时 binlog 迁移开始的位置; 如果 checkpoint 存在，则以 `checkpoint` 为准。如果 `meta` 项和下游数据库的 `checkpoint` 都不存在，则从上游当前最新的 binlog 位置开始迁移。 - binlog-name: "mysql-bin.000004" # “Step 1. 导出 Aurora 快照文件到 Amazon S3” 中记录的日志位置，当上游存在主从切换时，必须使用 gtid。 + binlog-name: "mysql-bin.000004" # “Step 1. 导出 Amazon Aurora 快照文件到 Amazon S3” 中记录的日志位置，当上游存在主从切换时，必须使用 gtid。 binlog-pos: 109227 # binlog-gtid: "09bec856-ba95-11ea-850a-58f2b4af5188:1-9" @@ -250,16 +256,12 @@ mysql-instances: 在你启动数据迁移任务之前，建议使用 `check-task` 命令检查配置是否符合 DM 的配置要求，以降低后期报错的概率： -{{< copyable "shell-regular" >}} - ```shell tiup dmctl --master-addr ${advertise-addr} check-task task.yaml ``` 使用 `tiup dmctl` 执行以下命令启动数据迁移任务。 -{{< copyable "shell-regular" >}} - ```shell tiup dmctl --master-addr ${advertise-addr} start-task task.yaml ``` @@ -277,8 +279,6 @@ tiup dmctl --master-addr ${advertise-addr} start-task task.yaml 如需了解 DM 集群中是否存在正在运行的迁移任务及任务状态等信息，可使用 `tiup dmctl` 执行 `query-status` 命令进行查询： -{{< copyable "shell-regular" >}} - ```shell tiup dmctl --master-addr ${advertise-addr} query-status ${task-name} ``` diff --git a/migrate-from-tidb-to-mysql.md b/migrate-from-tidb-to-mysql.md index 085f29e65753..6860365aa063 100644 --- a/migrate-from-tidb-to-mysql.md +++ b/migrate-from-tidb-to-mysql.md @@ -109,7 +109,9 @@ summary: 了解如何将数据从 TiDB 集群迁移至与 MySQL 兼容的数据 3. 恢复数据。 - 使用开源工具 MyLoader 导入数据到下游 MySQL。MyLoader 的安装和详细用例参见 [MyDumpler/MyLoader](https://github.com/mydumper/mydumper)。执行以下指令，将 Dumpling 导出的上游全量数据导入到下游 MySQL 实例： + 使用开源工具 MyLoader 导入数据到下游 MySQL。MyLoader 的安装和详细用例参见 [MyDumpler/MyLoader](https://github.com/mydumper/mydumper)。注意需要使用 MyLoader v0.10 或更早版本，否则会导致 MyLoader 无法处理 Dumpling 导出的 metadata 文件。 + + 执行以下指令，将 Dumpling 导出的上游全量数据导入到下游 MySQL 实例： ```shell myloader -h 127.0.0.1 -P 3306 -d ./dumpling_output/ diff --git a/migrate-large-mysql-to-tidb.md b/migrate-large-mysql-to-tidb.md index af28f4e356e6..9ed487a1505f 100644 --- a/migrate-large-mysql-to-tidb.md +++ b/migrate-large-mysql-to-tidb.md @@ -7,7 +7,7 @@ summary: 介绍如何从大数据量 MySQL 迁移数据到 TiDB。 通常数据量较低时，使用 DM 进行迁移较为简单，可直接完成全量+持续增量迁移工作。但当数据量较大时，DM 较低的数据导入速度 (30~50 GiB/h) 可能令整个迁移周期过长。本文所称“大数据量”通常指 TiB 级别以上。 -因此，本文档介绍使用 Dumpling 和 TiDB Lightning 进行全量数据迁移，其本地导入 (local backend) 模式导入速度可达每小时 500 GiB。完成全量数据迁移后，再使用 DM 完成增量数据迁移。 +因此，本文档介绍如何使用 Dumpling 和 TiDB Lightning 进行全量数据迁移。TiDB Lightning [物理导入模式](/tidb-lightning/tidb-lightning-physical-import-mode.md)的导入速度最高可达每小时 500 GiB，注意实际导入速度受硬件配置、表结构、索引数量等多方面因素的影响。完成全量数据迁移后，再使用 DM 完成增量数据迁移。 ## 前提条件 diff --git a/migration-tools.md b/migration-tools.md index 8d9c942021f7..20918f133b5e 100644 --- a/migration-tools.md +++ b/migration-tools.md @@ -16,16 +16,7 @@ TiDB 提供了丰富的数据迁移相关的工具，用于全量迁移、增量 | **上游** | MySQL，MariaDB，Aurora | | **下游** | TiDB | | **主要优势** |
  • 一体化的数据迁移任务管理工具，支持全量迁移和增量同步
  • 支持对表与操作进行过滤
  • 支持分库分表的合并迁移
| -| **使用限制** | 数据导入速度与 TiDB Lightning 的 [Logical Import Mode](/tidb-lightning/tidb-lightning-logical-import-mode.md) 大致相同，而比TiDB Lightning 的 [Physical Import Mode](/tidb-lightning/tidb-lightning-physical-import-mode.md) 低很多。建议用于 1 TB 以内的存量数据迁移。 | - -## [Dumpling](/dumpling-overview.md) - -| 使用场景 | 用于将数据从 MySQL/TiDB 进行全量导出 | -|---|---| -| **上游** | MySQL，TiDB | -| **下游（输出文件）** | SQL，CSV | -| **主要优势** |
  • 支持全新的 table-filter，筛选数据更加方便
  • 支持导出到 Amazon S3 云盘
| -| **使用限制** |
  • 如果导出后计划往非 TiDB 的数据库恢复，建议使用 Dumpling。
  • 如果导出后计划往另一个 TiDB 恢复，建议使用 [BR](/br/backup-and-restore-overview.md)。
| +| **使用限制** | 数据导入速度与 TiDB Lightning 的[逻辑导入模式](/tidb-lightning/tidb-lightning-logical-import-mode.md)大致相同，而比 TiDB Lightning 的[物理导入模式](/tidb-lightning/tidb-lightning-physical-import-mode.md)低很多。建议用于 1 TB 以内的存量数据迁移。 | ## [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) @@ -34,16 +25,16 @@ TiDB 提供了丰富的数据迁移相关的工具，用于全量迁移、增量 | **上游（输入源文件）** |
  • Dumpling 输出的文件
  • 从 Amazon Aurora 或 Apache Hive 导出的 Parquet 文件
  • CSV 文件
  • 从本地盘或 Amazon S3 云盘读取数据
| | **下游** | TiDB | | **主要优势** |
  • 支持快速导入大量数据，实现快速初始化 TiDB 集群的指定表
  • 支持断点续传
  • 支持数据过滤
| -| **使用限制** |
  • 如果使用 [Physical Import Mode](/tidb-lightning/tidb-lightning-physical-import-mode.md) 进行数据导入，TiDB Lightning 运行后，TiDB 集群将无法正常对外提供服务。
  • 如果你不希望 TiDB 集群的对外服务受到影响，可以参考 TiDB Lightning [Logical Import Mode](/tidb-lightning/tidb-lightning-logical-import-mode.md) 中的硬件需求与部署方式进行数据导入。
| +| **使用限制** |
  • 如果使用[物理导入模式](/tidb-lightning/tidb-lightning-physical-import-mode.md)进行数据导入，TiDB Lightning 运行后，TiDB 集群将无法正常对外提供服务。
  • 如果你不希望 TiDB 集群的对外服务受到影响，可以参考 TiDB Lightning [逻辑导入模式](/tidb-lightning/tidb-lightning-logical-import-mode.md)中的硬件需求与部署方式进行数据导入。
| -## [Backup & Restore (BR)](/br/backup-and-restore-overview.md) +## [Dumpling](/dumpling-overview.md) -| 使用场景 | 通过对大数据量的 TiDB 集群进行数据备份和恢复，实现数据迁移 | +| 使用场景 | 用于将数据从 MySQL/TiDB 进行全量导出 | |---|---| -| **上游** | TiDB | -| **下游（输出文件）** | SST，backup.meta 文件，backup.lock 文件 | -| **主要优势** |
  • 适用于向另一个 TiDB 迁移数据。
  • 支持数据冷备份到外部存储，可以用于灾备恢复。
| -| **使用限制** |
  • BR 恢复到 TiCDC / Drainer 的上游集群时，恢复数据无法由 TiCDC / Drainer 同步到下游。
  • BR 只支持在 `new_collations_enabled_on_first_bootstrap` 开关值相同的集群之间进行操作。
| +| **上游** | MySQL，TiDB | +| **下游（输出文件）** | SQL，CSV | +| **主要优势** |
  • 支持全新的 table-filter，筛选数据更加方便
  • 支持导出到 Amazon S3 云盘
| +| **使用限制** |
  • 如果导出后计划往非 TiDB 的数据库恢复，建议使用 Dumpling。
  • 如果导出后计划往另一个 TiDB 恢复，建议使用 [BR](/br/backup-and-restore-overview.md)。
| ## [TiCDC](/ticdc/ticdc-overview.md) @@ -54,14 +45,14 @@ TiDB 提供了丰富的数据迁移相关的工具，用于全量迁移、增量 | **主要优势** | 提供开放数据协议 (TiCDC Open Protocol)。| | **使用限制** | TiCDC 只能同步至少存在一个有效索引的表。暂不支持以下场景：
  • 单独使用 RawKV 的 TiKV 集群。
  • 在 TiDB 中创建 SEQUENCE 的 DDL 操作和 SEQUENCE 函数。
| -## [TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) +## [Backup & Restore (BR)](/br/backup-and-restore-overview.md) -| 使用场景 | 用于 TiDB 集群间的增量数据同步，如将其中一个 TiDB 集群作为另一个 TiDB 集群的从集群 | +| 使用场景 | 通过对大数据量的 TiDB 集群进行数据备份和恢复，实现数据迁移 | |---|---| | **上游** | TiDB | -| **下游（输出文件）** | TiDB，MySQL，Kafka，增量备份文件 | -| **主要优势** |
  • 支持实时备份和恢复。
  • 备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复。
| -| **使用限制** | 与部分 TiDB 版本不兼容。推荐使用 [TiCDC](/ticdc/ticdc-overview.md) 替代 TiDB Binlog。| +| **下游（输出文件）** | SST，backup.meta 文件，backup.lock 文件 | +| **主要优势** |
  • 适用于向另一个 TiDB 迁移数据。
  • 支持数据冷备份到外部存储，可以用于灾备恢复。
| +| **使用限制** |
  • BR 恢复到 TiCDC / Drainer 的上游集群时，恢复数据无法由 TiCDC / Drainer 同步到下游。
  • BR 只支持在 `new_collations_enabled_on_first_bootstrap` 开关值相同的集群之间进行操作。
| ## [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md) diff --git a/mysql-compatibility.md b/mysql-compatibility.md index dc257606101b..a46c6a64f50e 100644 --- a/mysql-compatibility.md +++ b/mysql-compatibility.md @@ -6,7 +6,7 @@ aliases: ['/docs-cn/dev/mysql-compatibility/','/docs-cn/dev/reference/mysql-comp # 与 MySQL 兼容性对比 -TiDB 高度兼容 MySQL 5.7 协议、MySQL 5.7 常用的功能及语法。MySQL 5.7 生态中的系统工具（PHPMyAdmin、Navicat、MySQL Workbench、mysqldump、Mydumper/Myloader）、客户端等均适用于 TiDB。 +TiDB 高度兼容 MySQL 协议，以及 MySQL 5.7 和 MySQL 8.0 常用的功能及语法。MySQL 生态中的系统工具（PHPMyAdmin、Navicat、MySQL Workbench、DBeaver 和[其他工具](/develop/dev-guide-third-party-support.md#gui)）、客户端等均适用于 TiDB。 但 TiDB 尚未支持一些 MySQL 功能，可能的原因如下： @@ -46,6 +46,9 @@ TiDB 高度兼容 MySQL 5.7 协议、MySQL 5.7 常用的功能及语法。MySQL * `HANDLER` 语句 * `CREATE TABLESPACE` 语句 * "Session Tracker: 将 GTID 上下文信息添加到 OK 包中" +* 降序索引 [#2519](https://github.com/pingcap/tidb/issues/2519) +* `SKIP LOCKED` 语法 [#18207](https://github.com/pingcap/tidb/issues/18207) +* 横向派生表 [#40328](https://github.com/pingcap/tidb/issues/40328) ## 与 MySQL 有差异的特性详细说明 @@ -122,9 +125,12 @@ TiDB 中，所有支持的 DDL 变更操作都是在线执行的。与 MySQL 相 * 不支持添加或删除 `CLUSTERED` 类型的主键。要了解关于 `CLUSTERED` 主键的详细信息，请参考[聚簇索引](/clustered-indexes.md)。 * 不支持指定不同类型的索引 (`HASH|BTREE|RTREE|FULLTEXT`)。若指定了不同类型的索引，TiDB 会解析并忽略这些索引。 * 分区表支持 `HASH`、`RANGE`、`LIST` 和 `KEY` 分区类型。`KEY` 分区类型暂不支持分区字段列表为空的语句。对于不支持的分区类型，TiDB 会报 `Warning: Unsupported partition type %s, treat as normal table` 错误，其中 `%s` 为不支持的具体分区类型。 -* 分区表还支持 `ADD`、`DROP`、`TRUNCATE`、`REORGANIZE` 操作，其他分区操作会被忽略。TiDB 不支持以下分区表语法： +* Range、Range COLUMNS、List、List COLUMNS 分区表支持 `ADD`、`DROP`、`TRUNCATE`、`REORGANIZE` 操作，其他分区操作会被忽略。 +* Hash 和 Key 分区表支持 `ADD`、`COALESCE`、`TRUNCATE` 操作，其他分区操作会被忽略。 +* TiDB 不支持以下分区表语法： + + `SUBPARTITION` - + `{CHECK|TRUNCATE|OPTIMIZE|REPAIR|IMPORT|DISCARD|REBUILD|COALESCE} PARTITION` + + `{CHECK|OPTIMIZE|REPAIR|IMPORT|DISCARD|REBUILD} PARTITION` 更多详情，请参考[分区表文档](/partitioned-table.md)。 diff --git a/mysql-schema.md b/mysql-schema.md index c21f5d58047f..54e65a6a5d14 100644 --- a/mysql-schema.md +++ b/mysql-schema.md @@ -39,7 +39,6 @@ aliases: ['/docs-cn/dev/system-tables/system-table-overview/','/docs-cn/dev/refe * `column_stats_usage` 列统计信息的使用情况 * `schema_index_usage` 索引的使用情况 * `analyze_jobs` 正在执行的统计信息收集任务以及过去 7 天内的历史任务记录 -* `load_data_jobs` 正在执行或历史执行的 `LOAD DATA` 任务 ## 执行计划相关系统表 @@ -57,9 +56,14 @@ aliases: ['/docs-cn/dev/system-tables/system-table-overview/','/docs-cn/dev/refe ## TTL 相关系统表 -* `mysql.tidb_ttl_table_status` 所有 TTL 表的上一次执行与正在执行的 TTL 任务 -* `mysql.tidb_ttl_task` 正在执行的 TTL 子任务 -* `mysql.tidb_ttl_job_history` 过去 90 天内 TTL 任务的执行历史 +* `tidb_ttl_table_status` 所有 TTL 表的上一次执行与正在执行的 TTL 任务 +* `tidb_ttl_task` 正在执行的 TTL 子任务 +* `tidb_ttl_job_history` 过去 90 天内 TTL 任务的执行历史 + +## Runaway Queries 相关系统表 + +* `tidb_runaway_queries` 过去 7 天内所有识别到的 Runaway Queries 的历史记录 +* `tidb_runaway_quarantined_watch` 最近活动的 Runaway Queries 的快速识别规则（包含当前有效规则，也可能还包含近期失效的规则） ## 其它系统表 @@ -68,3 +72,4 @@ aliases: ['/docs-cn/dev/system-tables/system-table-overview/','/docs-cn/dev/refe * `expr_pushdown_blacklist` 表达式下推的黑名单 * `opt_rule_blacklist` 逻辑优化规则的黑名单 * `table_cache_meta` 缓存表的信息 +* `tidb_import_jobs` 记录 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) 任务信息 diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md new file mode 100644 index 000000000000..21513eeb2d7e --- /dev/null +++ b/optimizer-fix-controls.md @@ -0,0 +1,39 @@ +--- +title: Optimizer Fix Controls +summary: 了解 Optimizer Fix Controls 以及如何使用 `tidb_opt_fix_control` 细粒度地控制 TiDB 优化器的行为 +--- + +# Optimizer Fix Controls + +随着产品迭代演进，TiDB 优化器的行为会发生变化，进而生成更加合理的执行计划。但在某些特定场景下，新的行为可能会导致非预期结果。例如： + +- 部分行为的效果和场景相关。有的行为改变，能在大多数场景下带来改进，但可能在极少数场景下导致回退。 +- 有时，行为细节的变化和其导致的结果之间的关系十分复杂。即使是对某处行为细节的改进，也可能在整体上导致执行计划回退。 + +因此，TiDB 提供了 Optimizer Fix Controls 功能，允许用户通过设置一系列 Fix 控制 TiDB 优化器的行为细节。本文档介绍了 Optimizer Fix Controls 及其使用方法，并列举了当前 TiDB 支持调整的所有 Fix。 + +## `tidb_opt_fix_control` 介绍 + +从 TiDB v7.1.0 开始，提供了 [`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-从-v710-版本开始引入) 系统变量来更细粒度地控制优化器的行为。 + +一个 Fix 是用于调整 TiDB 优化器中一处行为的控制项。它以一个数字编号表示，该数字编号对应一个 GitHub Issue，在 Issue 中会有对技术细节的描述。例如 Fix `44262` 对应 [Issue 44262](https://github.com/pingcap/tidb/issues/44262)。 + +`tidb_opt_fix_control` 支持设置多个 Fix，不同 Fix 之间使用逗号 (`,`) 分隔。格式形如 `"<#issue1>:,<#issue2>:,...,<#issueN>:"`，其中 `<#issueN>` 代表 Fix 编号。例如： + +```sql +SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; +``` + +## Optimizer Fix Controls 参考 + +### [`44262`](https://github.com/pingcap/tidb/issues/44262) 从 v7.2.0 版本开始引入 + +- 默认值：`OFF` +- 可选值：`ON`、`OFF` +- 是否允许在缺少 [GlobalStats](/statistics.md#动态裁剪模式下的分区表统计信息) 的情况下使用[动态裁剪模式](/partitioned-table.md#动态裁剪模式)访问分区表。 + +### [`44389`](https://github.com/pingcap/tidb/issues/44389) 从 v7.2.0 版本开始引入 + +- 默认值：`OFF` +- 可选值：`ON`、`OFF` +- 对形如 `c = 10 and (a = 'xx' or (a = 'kk' and b = 1))` 的过滤条件，是否尝试为 `IndexRangeScan` 更加完整地构造扫描范围，即 `range`。 diff --git a/optimizer-hints.md b/optimizer-hints.md index 5ae0740bef1d..901791564a10 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -7,38 +7,10 @@ aliases: ['/docs-cn/dev/optimizer-hints/','/docs-cn/dev/reference/performance/op TiDB 支持 Optimizer Hints 语法，它基于 MySQL 5.7 中介绍的类似 comment 的语法，例如 `/*+ HINT_NAME(t1, t2) */`。当 TiDB 优化器选择的不是最优查询计划时，建议使用 Optimizer Hints。 -> **注意：** -> -> MySQL 命令行客户端在 5.7.7 版本之前默认清除了 Optimizer Hints。如果需要在这些早期版本的客户端中使用 `Hint` 语法，需要在启动客户端时加上 `--comments` 选项，例如 `mysql -h 127.0.0.1 -P 4000 -uroot --comments`。 +如果遇到 Hint 无法生效的情况，请参考[常见 Hint 不生效问题排查](#常见-hint-不生效问题排查)。 ## 语法 -> **注意：** -> -> 如果需要提示优化器使用的表不在 `USE DATABASE` 所指定的数据库内，需要显式指定数据库名。例如： -> -> ```sql -> tidb> SELECT /*+ HASH_JOIN(t2, t) */ * FROM t, test2.t2; -> Empty set, 1 warning (0.00 sec) -> -> tidb> SHOW WARNINGS; -> +---------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ -> | Level | Code | Message | -> +---------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ -> | Warning | 1815 | There are no matching table names for (t2) in optimizer hint /*+ HASH_JOIN(t2, t) */ or /*+ TIDB_HJ(t2, t) */. Maybe you can use the table alias name | -> +---------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ -> 1 row in set (0.00 sec) -> -> tidb> SELECT /*+ HASH_JOIN(test2.t2, t) */ * FROM t, test2.t2; -> Empty set (0.00 sec) -> -> tidb> SELECT /*+ READ_FROM_STORAGE(TIFLASH[test1.t1,test2.t2]) */ t1.a FROM test1.t t1, test2.t t2 WHERE t1.a = t2.a; -> Empty set (0.00 sec) -> -> ``` -> -> 本文档中后续示例演示部分，皆是同一个数据库范围内的表。如果你使用的表不在同一个数据库内，请参照指示显式指定数据库名。 - Optimizer Hints 不区分大小写，通过 `/*+ ... */` 注释的形式跟在 `SELECT`、`UPDATE` 或 `DELETE` 关键字的后面。`INSERT` 关键字后不支持 Optimizer Hints。 多个不同的 Hint 之间需用逗号隔开，例如： @@ -814,3 +786,158 @@ SELECT /*+ NTH_PLAN(3) */ count(*) from t where a > 5; ```sql SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10; ``` + +## 常见 Hint 不生效问题排查 + +### MySQL 命令行客户端清除 Hint 导致不生效 + +MySQL 命令行客户端在 5.7.7 版本之前默认清除了 Optimizer Hints。如果需要在这些早期版本的客户端中使用 Hint 语法，需要在启动客户端时加上 `--comments` 选项。例如 `mysql -h 127.0.0.1 -P 4000 -uroot --comments`。 + +### 创建连接时不指定库名导致 Hint 不生效 + +如果创建连接时未指定数据库名，则可能出现 Hint 失效的情况。例如： + +使用 `mysql -h127.0.0.1 -P4000 -uroot` 命令连接数据库时，未使用 `-D` 参数指定数据库名。然后执行下面的 SQL 语句： + +```sql +SELECT /*+ use_index(t, a) */ a FROM test.t; +SHOW WARNINGS; +``` + +由于无法识别表 `t` 对应的数据库名，因此 `use_index(t, a)` Hint 无法生效。 + +```sql ++---------+------+----------------------------------------------------------------------+ +| Level | Code | Message | ++---------+------+----------------------------------------------------------------------+ +| Warning | 1815 | use_index(.t, a) is inapplicable, check whether the table(.t) exists | ++---------+------+----------------------------------------------------------------------+ +1 row in set (0.00 sec) +``` + +### 跨库查询不指定库名导致 Hint 不生效 + +对于跨库查询中需要访问的表，需要显式地指定数据库名，否则可能出现 Hint 失效的情况。例如执行下面跨库查询的 SQL 语句： + +```sql +USE test1; +CREATE TABLE t1(a INT, KEY(a)); +USE test2; +CREATE TABLE t2(a INT, KEY(a)); +SELECT /*+ use_index(t1, a) */ * FROM test1.t1, t2; +SHOW WARNINGS; +``` + +由于 `t1` 不在当前数据库 `test2` 下，因此 `use_index(t1, a)` Hint 无法被正确地识别。 + +```sql ++---------+------+----------------------------------------------------------------------------------+ +| Level | Code | Message | ++---------+------+----------------------------------------------------------------------------------+ +| Warning | 1815 | use_index(test2.t1, a) is inapplicable, check whether the table(test2.t1) exists | ++---------+------+----------------------------------------------------------------------------------+ +1 row in set (0.00 sec) +``` + +此时，需要显式地指定库名，即将 `use_index(t1, a)` 修改为 `use_index(test1.t1, a)`。 + +### Hint 位置不正确导致不生效 + +如果没有按照 Optimizer Hints 语法将 Hint 正确地放在指定关键字的后面，它将无法生效。例如： + +```sql +SELECT * /*+ use_index(t, a) */ FROM t; +SHOW WARNINGS; +``` + +Warning 信息如下： + +```sql ++---------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Level | Code | Message | ++---------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Warning | 1064 | You have an error in your SQL syntax; check the manual that corresponds to your TiDB version for the right syntax to use [parser:8066]Optimizer hint can only be followed by certain keywords like SELECT, INSERT, etc. | ++---------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +1 row in set (0.01 sec) +``` + +在上面的示例中，你需要将 Hint 直接放在 `SELECT` 关键字之后。具体的语法规则参见 [Hint 语法](#语法)部分。 + +### 排序规则不兼容导致 `INL_JOIN` Hint 不生效 + +如果两个表的 Join key 的排序规则不能兼容，将无法使用 IndexJoin 来执行查询。此时 [`INL_JOIN` Hint](#inl_joint1_name--tl_name-) 将无法生效。例如： + +```sql +CREATE TABLE t1 (k varchar(8), key(k)) COLLATE=utf8mb4_general_ci; +CREATE TABLE t2 (k varchar(8), key(k)) COLLATE=utf8mb4_bin; +EXPLAIN SELECT /*+ tidb_inlj(t1) */ * FROM t1, t2 WHERE t1.k=t2.k; +``` + +查询计划输出结果如下： + +```sql ++-----------------------------+----------+-----------+----------------------+----------------------------------------------+ +| id | estRows | task | access object | operator info | ++-----------------------------+----------+-----------+----------------------+----------------------------------------------+ +| HashJoin_19 | 12487.50 | root | | inner join, equal:[eq(test.t1.k, test.t2.k)] | +| ├─IndexReader_24(Build) | 9990.00 | root | | index:IndexFullScan_23 | +| │ └─IndexFullScan_23 | 9990.00 | cop[tikv] | table:t2, index:k(k) | keep order:false, stats:pseudo | +| └─IndexReader_22(Probe) | 9990.00 | root | | index:IndexFullScan_21 | +| └─IndexFullScan_21 | 9990.00 | cop[tikv] | table:t1, index:k(k) | keep order:false, stats:pseudo | ++-----------------------------+----------+-----------+----------------------+----------------------------------------------+ +5 rows in set, 1 warning (0.00 sec) +``` + +上面的 SQL 语句中 `t1.k` 和 `t2.k` 的排序规则不能相互兼容（分别为 `utf8mb4_general_ci` 和 `utf8mb4_bin`），导致 IndexJoin 无法适用。因此 `INL_JOIN` 或 `TIDB_INLJ` Hint 也无法生效。 + +```sql +SHOW WARNINGS; ++---------+------+----------------------------------------------------------------------------+ +| Level | Code | Message | ++---------+------+----------------------------------------------------------------------------+ +| Warning | 1815 | Optimizer Hint /*+ INL_JOIN(t1) */ or /*+ TIDB_INLJ(t1) */ is inapplicable | ++---------+------+----------------------------------------------------------------------------+ +1 row in set (0.00 sec) +``` + +### 连接顺序导致 `INL_JOIN` Hint 不生效 + +[`INL_JOIN(t1, t2)`](#inl_joint1_name--tl_name-) 或 `TIDB_INLJ(t1, t2)` 的语义是让 `t1` 和 `t2` 作为 `IndexJoin` 的内表与其他表进行连接，而不是直接将 `t1` 和 `t2` 进行 `IndexJoin` 连接。例如： + +```sql +EXPLAIN SELECT /*+ inl_join(t1, t3) */ * FROM t1, t2, t3 WHERE t1.id = t2.id AND t2.id = t3.id AND t1.id = t3.id; ++---------------------------------+----------+-----------+---------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| id | estRows | task | access object | operator info | ++---------------------------------+----------+-----------+---------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| IndexJoin_16 | 15625.00 | root | | inner join, inner:TableReader_13, outer key:test.t2.id, test.t1.id, inner key:test.t3.id, test.t3.id, equal cond:eq(test.t1.id, test.t3.id), eq(test.t2.id, test.t3.id) | +| ├─IndexJoin_34(Build) | 12500.00 | root | | inner join, inner:TableReader_31, outer key:test.t2.id, inner key:test.t1.id, equal cond:eq(test.t2.id, test.t1.id) | +| │ ├─TableReader_40(Build) | 10000.00 | root | | data:TableFullScan_39 | +| │ │ └─TableFullScan_39 | 10000.00 | cop[tikv] | table:t2 | keep order:false, stats:pseudo | +| │ └─TableReader_31(Probe) | 10000.00 | root | | data:TableRangeScan_30 | +| │ └─TableRangeScan_30 | 10000.00 | cop[tikv] | table:t1 | range: decided by [test.t2.id], keep order:false, stats:pseudo | +| └─TableReader_13(Probe) | 12500.00 | root | | data:TableRangeScan_12 | +| └─TableRangeScan_12 | 12500.00 | cop[tikv] | table:t3 | range: decided by [test.t2.id test.t1.id], keep order:false, stats:pseudo | ++---------------------------------+----------+-----------+---------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +``` + +在上面例子中，`t1` 和 `t3` 并没有直接被一个 `IndexJoin` 连接起来。 + +如果想要直接使用 `IndexJoin` 来连接 `t1` 和 `t3`，需要先使用 [`LEADING` Hint](#leadingt1_name--tl_name-) 指定 `t1` 和 `t3` 的连接顺序，然后再配合使用 `INL_JION`。例如： + +```sql +EXPLAIN SELECT /*+ leading(t1, t3), inl_join(t3) */ * FROM t1, t2, t3 WHERE t1.id = t2.id AND t2.id = t3.id AND t1.id = t3.id; ++---------------------------------+----------+-----------+---------------+---------------------------------------------------------------------------------------------------------------------+ +| id | estRows | task | access object | operator info | ++---------------------------------+----------+-----------+---------------+---------------------------------------------------------------------------------------------------------------------+ +| Projection_12 | 15625.00 | root | | test.t1.id, test.t1.name, test.t2.id, test.t2.name, test.t3.id, test.t3.name | +| └─HashJoin_21 | 15625.00 | root | | inner join, equal:[eq(test.t1.id, test.t2.id) eq(test.t3.id, test.t2.id)] | +| ├─TableReader_36(Build) | 10000.00 | root | | data:TableFullScan_35 | +| │ └─TableFullScan_35 | 10000.00 | cop[tikv] | table:t2 | keep order:false, stats:pseudo | +| └─IndexJoin_28(Probe) | 12500.00 | root | | inner join, inner:TableReader_25, outer key:test.t1.id, inner key:test.t3.id, equal cond:eq(test.t1.id, test.t3.id) | +| ├─TableReader_34(Build) | 10000.00 | root | | data:TableFullScan_33 | +| │ └─TableFullScan_33 | 10000.00 | cop[tikv] | table:t1 | keep order:false, stats:pseudo | +| └─TableReader_25(Probe) | 10000.00 | root | | data:TableRangeScan_24 | +| └─TableRangeScan_24 | 10000.00 | cop[tikv] | table:t3 | range: decided by [test.t1.id], keep order:false, stats:pseudo | ++---------------------------------+----------+-----------+---------------+---------------------------------------------------------------------------------------------------------------------+ +9 rows in set (0.01 sec) +``` diff --git a/partitioned-raft-kv.md b/partitioned-raft-kv.md index e53a0c720467..94f596a521f5 100644 --- a/partitioned-raft-kv.md +++ b/partitioned-raft-kv.md @@ -35,7 +35,7 @@ v6.6.0 之前，基于 Raft 的存储引擎，TiKV 使用单个 RocksDB 实例 由于该功能为实验特性，目前有以下限制： -* 暂不支持 TiDB Lightning、TiCDC、BR、Dumping 等数据导入、同步和备份工具。 +* 暂不支持基于 EBS 的快照备份。 +* 暂不支持 Online Unsafe Recovery 和 Titan。 * 暂不支持 tikv-ctl 命令行管理工具。 -* 不支持同时和 TiFlash 使用。 -* 需要在创建集群时启用，不支持在集群创建后开启。 +* 初始化以后不支持开启或者关闭。 diff --git a/partitioned-table.md b/partitioned-table.md index 2e2e290d2eaa..e1b8289b05b6 100644 --- a/partitioned-table.md +++ b/partitioned-table.md @@ -166,31 +166,21 @@ CREATE TABLE t ( name varchar(255) CHARACTER SET ascii, notes text ) -PARTITION BY RANGE COLUMNS(name,valid_until) +PARTITION BY RANGE COLUMNS(name, valid_until) (PARTITION `p2022-g` VALUES LESS THAN ('G','2023-01-01 00:00:00'), PARTITION `p2023-g` VALUES LESS THAN ('G','2024-01-01 00:00:00'), - PARTITION `p2024-g` VALUES LESS THAN ('G','2025-01-01 00:00:00'), PARTITION `p2022-m` VALUES LESS THAN ('M','2023-01-01 00:00:00'), PARTITION `p2023-m` VALUES LESS THAN ('M','2024-01-01 00:00:00'), - PARTITION `p2024-m` VALUES LESS THAN ('M','2025-01-01 00:00:00'), PARTITION `p2022-s` VALUES LESS THAN ('S','2023-01-01 00:00:00'), - PARTITION `p2023-s` VALUES LESS THAN ('S','2024-01-01 00:00:00'), - PARTITION `p2024-s` VALUES LESS THAN ('S','2025-01-01 00:00:00'), - PARTITION `p2022-` VALUES LESS THAN (0x7f,'2023-01-01 00:00:00'), - PARTITION `p2023-` VALUES LESS THAN (0x7f,'2024-01-01 00:00:00'), - PARTITION `p2024-` VALUES LESS THAN (0x7f,'2025-01-01 00:00:00')) + PARTITION `p2023-s` VALUES LESS THAN ('S','2024-01-01 00:00:00')) ``` -该语句将按年份和名字的范围 ['', 'G')、['G', 'M')、['M', 'S')、['S',) 进行分区，删除无效数据，同时仍然可以在 `name` 和 `valid_until` 列上进行分区裁剪。其中，`[,)` 是一个半开半闭区间，比如 ['G', 'M')，表示包含 `G`、大于 `G` 并小于 `M` 的数据，但不包含 `M`。 +该语句将按名字和年份的范围 `[ ('', ''), ('G', '2023-01-01 00:00:00') )`，`[ ('G', '2023-01-01 00:00:00'), ('G', '2024-01-01 00:00:00') )`，`[ ('G', '2024-01-01 00:00:00'), ('M', '2023-01-01 00:00:00') )`，`[ ('M', '2023-01-01 00:00:00'), ('M', '2024-01-01 00:00:00') )`，`[ ('M', '2024-01-01 00:00:00'), ('S', '2023-01-01 00:00:00') )`，`[ ('S', '2023-01-01 00:00:00'), ('S', '2024-01-01 00:00:00') )` 进行分区，删除无效数据，同时仍然可以在 name 和 valid_until 列上进行分区裁剪。其中，`[,)` 是一个左闭右开区间，比如 `[ ('G', '2023-01-01 00:00:00'), ('G', '2024-01-01 00:00:00') )`，表示 name 为 `'G'` ，年份包含 2023-01-01 00:00:00 并大于 2023-01-01 00:00:00 但小于 2024-01-01 00:00:00 的数据，其中不包含 `(G, 2024-01-01 00:00:00)`。 ### Range INTERVAL 分区 TiDB v6.3.0 新增了 Range INTERVAL 分区特性，作为语法糖（syntactic sugar）引入。Range INTERVAL 分区是对 Range 分区的扩展。你可以使用特定的间隔（interval）轻松创建分区。 -> **警告：** -> -> 该功能目前是实验性功能，请注意使用场景限制。该功能会在未事先通知的情况下发生变化或删除。语法和实现可能会在 GA 前发生变化。如果发现 bug，请提 [Issues · pingcap/tidb](https://github.com/pingcap/tidb/issues) 反馈。 - 其语法如下： ```sql @@ -803,9 +793,11 @@ Empty set (0.00 sec) - 使用 `ALTER TABLE <表名> TRUNCATE PARTITION <分区列表>` 语句清空分区里的数据。`TRUNCATE PARTITION` 的逻辑与 [`TRUNCATE TABLE`](/sql-statements/sql-statement-truncate.md) 相似，但它的操作对象为分区。 - 使用 `ALTER TABLE <表名> REORGANIZE PARTITION <分区列表> INTO (<新的分区说明>)`语句对分区进行合并、拆分、或者其他修改。 -对于 `LIST` 和 `RANGE` 分区表，暂不支持 `REORGANIZE PARTITION` 语句。 +对于 `HASH` 和 `KEY` 分区表，你可以进行以下分区管理操作： -对于 `HASH` 和 `KEY` 分区表，目前只支持 `ALTER TABLE ... TRUNCATE PARTITION` 分区管理语句，不支持 `COALESCE PARTITION` 和 `ADD PARTITION` 语句。 +- 使用 `ALTER TABLE
COALESCE PARTITION <要减少的分区数量>` 语句减少分区数量。此操作会重组分区，将所有数据按照新的分区个数复制到对应的分区。 +- 使用 `ALTER TABLE
ADD PARTITION <要增加的分区数量 | (新的分区说明)>` 语句增加分区的数量。此操作会重组分区，将所有数据按照新的分区个数复制到对应的分区。 +- 使用 `ALTER TABLE
TRUNCATE PARTITION <分区列表>` 语句清空分区里的数据。`TRUNCATE PARTITION` 的逻辑与 [`TRUNCATE TABLE`](/sql-statements/sql-statement-truncate.md) 相似，但它的操作对象为分区。 `EXCHANGE PARTITION` 语句用来交换分区和非分区表，类似于重命名表如 `RENAME TABLE t1 TO t1_tmp, t2 TO t1, t1_tmp TO t2` 的操作。 @@ -858,7 +850,7 @@ PARTITION BY LIST (level) ( PARTITION l5 VALUES IN (5)); ``` -### 删除分区 +#### 删除分区 ```sql ALTER TABLE members DROP PARTITION p1990; @@ -866,7 +858,7 @@ ALTER TABLE members DROP PARTITION p1990; ALTER TABLE member_level DROP PARTITION l5; ``` -### 清空分区 +#### 清空分区 ```sql ALTER TABLE members TRUNCATE PARTITION p1980; @@ -874,7 +866,7 @@ ALTER TABLE members TRUNCATE PARTITION p1980; ALTER TABLE member_level TRUNCATE PARTITION l4; ``` -### 添加分区 +#### 添加分区 ```sql ALTER TABLE members ADD PARTITION (PARTITION `p1990to2010` VALUES LESS THAN (2010)); @@ -892,7 +884,7 @@ ALTER TABLE members ADD PARTITION (PARTITION p1990 VALUES LESS THAN (2000)); ERROR 1493 (HY000): VALUES LESS THAN value must be strictly increasing for each partition ``` -### 重组分区 +#### 重组分区 拆分分区： @@ -967,40 +959,101 @@ ALTER TABLE member_level REORGANIZE PARTITION l1_2,l3,l4,l5,l6 INTO ERROR 1526 (HY000): Table has no partition for value 6 ``` -### 管理 Hash 分区 +- 分区重组后，相应分区的统计信息将会过期，并返回以下警告。此时，你可以通过 [`ANALYZE TABLE`]（/sql-statements/sql-statement-analyze-table.md）语句更新统计信息。 + + ```sql + +---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Level | Code | Message | + +---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Warning | 1105 | The statistics of related partitions will be outdated after reorganizing partitions. Please use 'ANALYZE TABLE' statement if you want to update it now | + +---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------+ + 1 row in set (0.00 sec) + ``` + +### 管理 Hash 分区和 Key 分区 + +本小节将以如下 SQL 语句创建的分区表为例，介绍如何管理 Hash 分区。对于 Key 分区，你也可以使用与 Hash 分区相同的分区管理语句。 + +```sql +CREATE TABLE example ( + id INT PRIMARY KEY, + data VARCHAR(1024) +) +PARTITION BY HASH(id) +PARTITIONS 2; +``` + +#### 增加分区数量 + +将 `example` 表的分区个数增加 1 个（从 2 增加到 3）： -跟 Range 分区不同，Hash 分区不支持 `DROP PARTITION`。 +```sql +ALTER TABLE example ADD PARTITION PARTITIONS 1; +``` -目前 TiDB 的实现暂时不支持 `ALTER TABLE ... COALESCE PARTITION`。对于暂不支持的分区管理语句，TiDB 会返回错误。 +你也可以通过添加分区定义来指定分区选项。例如，你可以通过以下语句将分区数量从 3 增加到 5，并指定新增的分区名为 `pExample4` 和 `pExample5`： ```sql -ALTER TABLE MEMBERS OPTIMIZE PARTITION p0; +ALTER TABLE example ADD PARTITION +(PARTITION pExample4 COMMENT = 'not p3, but pExample4 instead', + PARTITION pExample5 COMMENT = 'not p4, but pExample5 instead'); ``` +#### 减少分区数量 + +与 Range 和 List 分区不同，Hash 和 Key 分区不支持 `DROP PARTITION`，但可以使用 `COALESCE PARTITION` 来减少分区数量，或使用 `TRUNCATE PARTITION` 清空指定分区的所有数据。 + +将 `example` 表的分区个数减少 1 个（从 5 减少到 4）： + ```sql -ERROR 8200 (HY000): Unsupported optimize partition +ALTER TABLE example COALESCE PARTITION 1; ``` -### Key 分区管理 +> **注意：** +> +> 更改 Hash 和 Key 分区表的分区个数的过程会重组分区，将所有数据按照新的分区个数复制到对应的分区。因此，更改 Hash 和 Key 分区表的分区个数后，会遇到以下关于过时统计信息的警告。此时，你可以通过 [`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md) 语句更新统计信息。 +> +> ```sql +> +---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------+ +> | Level | Code | Message | +> +---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------+ +> | Warning | 1105 | The statistics of related partitions will be outdated after reorganizing partitions. Please use 'ANALYZE TABLE' statement if you want to update it now | +> +---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------+ +> 1 row in set (0.00 sec) +> ``` -目前 TiDB 中 Key 分区支持的分区管理语句只有 `ALTER TABLE ... TRUNCATE PARTITION`。 +为了更好地理解 `example` 表重组后的结构，你可以查看重新创建 `example` 表所使用的 SQL 语句，如下所示： ```sql -ALTER TABLE members TRUNCATE PARTITION p0; +SHOW CREATE TABLE\G ``` ``` -Query OK, 0 rows affected (0.03 sec) +*************************** 1. row *************************** + Table: example +Create Table: CREATE TABLE `example` ( + `id` int(11) NOT NULL, + `data` varchar(1024) DEFAULT NULL, + PRIMARY KEY (`id`) /*T![clustered_index] CLUSTERED */ +) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin +PARTITION BY HASH (`id`) +(PARTITION `p0`, + PARTITION `p1`, + PARTITION `p2`, + PARTITION `pExample4` COMMENT 'not p3, but pExample4 instead') +1 row in set (0.01 sec) ``` -对于暂不支持的分区管理语句，TiDB 会返回错误。 +#### 清空分区 + +清空指定分区的所有数据： ```sql -ALTER TABLE members OPTIMIZE PARTITION p0; +ALTER TABLE example TRUNCATE PARTITION p0; ``` -```sql -ERROR 8200 (HY000): Unsupported optimize partition +``` +Query OK, 0 rows affected (0.03 sec) ``` ## 分区裁剪 diff --git a/pd-configuration-file.md b/pd-configuration-file.md index 060deaeddf05..ddb12d1b555c 100644 --- a/pd-configuration-file.md +++ b/pd-configuration-file.md @@ -159,6 +159,17 @@ pd-server 相关配置项。 > > 如果是从 v4.0 升级至当前版本，升级后的 `flow-round-by-digit` 行为和升级前的 `trace-region-flow` 行为默认保持一致：如果升级前 `trace-region-flow` 为 false，则升级后 `flow-round-by-digit` 为 127；如果升级前 `trace-region-flow` 为 true，则升级后 `flow-round-by-digit` 为 3。 +### `min-resolved-ts-persistence-interval` 从 v6.0.0 版本开始引入 + ++ 设置 PD leader 对集群中 Resolved TS 最小值进行持久化的间隔时间。如果该值设置为 `0`，表示禁用该功能。 ++ 默认值：在 v6.3.0 之前版本中为 `"0s"`，在 v6.3.0 及之后的版本中为 `"1s"`，即最小正值。 ++ 最小值：`"0s"` ++ 单位：秒 + +> **注意：** +> +> 对于从 v6.0.0~v6.2.0 升级上来的集群，`min-resolved-ts-persistence-interval` 的默认值在升级后将不会发生变化，即仍然为 `"0s"`。若要开启该功能，需要手动修改该配置项的值。 + ## security 安全相关配置项。 @@ -355,7 +366,7 @@ pd-server 相关配置项。 ### `enable-diagnostic` 从 v6.3.0 版本开始引入 + 是否开启诊断功能。开启特性时，PD 将会记录调度中的一些状态来帮助诊断。开启时会略微影响调度速度，在 Store 数量较多时会消耗较大内存。 -+ 默认值：false ++ 默认值：从 v7.1.0 起，默认值从 `false` 变更为 `true`。如果从 v7.1.0 之前版本的集群升级至 v7.1.0 及之后的版本，该默认值不发生变化。 ### `hot-regions-write-interval` 从 v5.4.0 版本开始引入 @@ -403,6 +414,18 @@ pd-server 相关配置项。 + 默认值：true + 参考 [Placement Rules 使用文档](/configure-placement-rules.md) +### `store-limit-version` 从 v7.1.0 版本开始引入 + +> **警告：** +> +> 在当前版本中，将该配置项设置为 `"v2"` 为实验特性，不建议在生产环境中使用。 + ++ 设置 `store limit` 工作模式 ++ 默认值：v1 ++ 可选值： + + v1：在 v1 模式下，你可以手动修改 `store limit` 以限制单个 TiKV 调度速度。 + + v2：（实验特性）在 v2 模式下，你无需关注 `store limit` 值，PD 将根据 TiKV Snapshot 执行情况动态调整 TiKV 调度速度。详情请参考 [Store Limit v2 原理](/configure-store-limit.md#store-limit-v2-原理)。 + ## label-property 标签相关的配置项。 diff --git a/pd-control.md b/pd-control.md index babab2a42955..703dcc7eb0b5 100644 --- a/pd-control.md +++ b/pd-control.md @@ -23,16 +23,16 @@ PD Control 是 PD 的命令行工具，用于获取集群状态信息和调整 | 安装包 | 操作系统 | 架构 | SHA256 校验和 | | :------------------------------------------------------------------------ | :------- | :---- | :--------------------------------------------------------------- | -| `https://download.pingcap.org/tidb-community-server-{version}-linux-amd64.tar.gz` (pd-ctl) | Linux | amd64 | `https://download.pingcap.org/tidb-community-server-{version}-linux-amd64.sha256` | -| `https://download.pingcap.org/tidb-community-server-{version}-linux-arm64.tar.gz` (pd-ctl) | Linux | arm64 | `https://download.pingcap.org/tidb-community-server-{version}-linux-arm64.sha256` | +| `https://download.pingcap.org/tidb-community-server-{version}-linux-amd64.tar.gz` (pd-ctl) | Linux | amd64 | `https://download.pingcap.org/tidb-community-server-{version}-linux-amd64.tar.gz.sha256` | +| `https://download.pingcap.org/tidb-community-server-{version}-linux-arm64.tar.gz` (pd-ctl) | Linux | arm64 | `https://download.pingcap.org/tidb-community-server-{version}-linux-arm64.tar.gz.sha256` | > **注意：** > -> 下载链接中的 `{version}` 为 TiDB 的版本号。例如，amd64 架构的 `v7.0.0` 版本的下载链接为 `https://download.pingcap.org/tidb-community-server-v7.0.0-linux-amd64.tar.gz`。 +> 下载链接中的 `{version}` 为 TiDB 的版本号。例如，amd64 架构的 `v7.2.0` 版本的下载链接为 `https://download.pingcap.org/tidb-community-server-v7.2.0-linux-amd64.tar.gz`。 ### 源码编译 -1. [Go](https://golang.org/) Version 1.19 以上 +1. [Go](https://golang.org/) 1.20 或以上版本 2. 在 PD 项目根目录使用 `make` 或者 `make pd-ctl` 命令进行编译，生成 bin/pd-ctl ## 简单例子 @@ -451,7 +451,13 @@ config show cluster-version - `enable-placement-rules` 用于开启 placement rules，在 v5.0 及以上的版本默认开启。 -- `store-limit-mode` 用于控制 store 限速机制的模式。主要有两种模式：`auto` 和 `manual`。`auto` 模式下会根据 load 自动进行平衡调整（实验性功能）。 +- `store-limit-mode` 用于控制 store 限速机制的模式。主要有两种模式：`auto` 和 `manual`。`auto` 模式下会根据 load 自动进行平衡调整（弃用）。 + +- `store-limit-version` 用于设置 `store limit` 限制模式，目前提供两种方式：`v1` 和 `v2`。默认值为 `v1`。在 `v1` 模式下，你可以手动修改 `store limit` 以限制单个 TiKV 调度速度。`v2` 模式为实验特性，在 `v2` 模式下，你无需关注 `store limit` 值，PD 将根据 TiKV Snapshot 执行情况动态调整 TiKV 调度速度。详情请参考 [Store Limit v2 原理](/configure-store-limit.md#store-limit-v2-原理)。 + + ```bash + config set store-limit-version v2 // 使用 Store Limit v2 + ``` - PD 会对流量信息的末尾数字进行四舍五入处理，减少 Region 流量信息变化引起的统计信息更新。该配置项用于指定对 Region 流量信息的末尾进行四舍五入的位数。例如流量 `100512` 会归约到 `101000`。默认值为 `3`。该配置替换了 `trace-region-flow`。 diff --git a/pd-recover.md b/pd-recover.md index 18cfcece492a..54f99d20db50 100644 --- a/pd-recover.md +++ b/pd-recover.md @@ -13,7 +13,7 @@ PD Recover 是对 PD 进行灾难性恢复的工具，用于恢复无法正常 ### 从源代码编译 -* [Go](https://golang.org/)：PD Recover 使用了 Go 模块，请安装 Go v1.19 或更新版本。 +* [Go](https://golang.org/)：PD Recover 使用了 Go 模块，请安装 Go 1.20 或以上版本。 * 在 [PD](https://github.com/pingcap/pd) 根目录下，运行 `make pd-recover` 命令来编译源代码并生成 `bin/pd-recover`。 > **注意：** @@ -24,9 +24,51 @@ PD Recover 是对 PD 进行灾难性恢复的工具，用于恢复无法正常 PD Recover 的安装包位于 TiDB 离线工具包中。下载方式，请参考 [TiDB 工具下载](/download-ecosystem-tools.md)。 -## 快速开始 +下面介绍两种重建集群的方式：从存活的 PD 节点重建和完全重建。 -### 获取 Cluster ID +## 方式一：从存活的 PD 节点重建集群 + +当 PD 集群的大多数节点发生灾难性故障时，集群将无法提供服务。当还有 PD 节点存活时，可以选择一个存活的 PD 节点，通过强制修改 Raft Group 的成员，使该节点重新恢复服务。具体操作步骤如下： + +### 第 1 步：停止所有节点 + +停止集群中的 TiDB、TiKV 和 TiFlash 服务进程，以防止在恢复过程中与 PD 参数交互，造成数据错乱或其他无法挽救的异常状况。 + +### 第 2 步：启动存活的 PD 节点 + +使用启动参数 `--force-new-cluster` 拉起该存活的 PD 节点，如： + +```shell +./bin/pd-server --force-new-cluster --name=pd-127.0.0.10-2379 --client-urls=http://0.0.0.0:2379 --advertise-client-urls=http://127.0.0.1:2379 --peer-urls=http://0.0.0.0:2380 --advertise-peer-urls=http://127.0.0.1:2380 --config=conf/pd.toml +``` + +### 第 3 步：使用 `pd-recover` 修复元数据 + +该方法是利用少数派 PD 节点恢复服务，但由于该节点可能存在数据落后的情况，因此对于 `alloc_id` 和 `tso` 等数据，一旦发生回退，可能导致集群数据错乱或不可用。为确保该节点能提供正确的分配 ID 和 TSO 等服务，需要使用 `pd-recover` 修改元数据。具体命令参考： + +```shell +./bin/pd-recover --from-old-member --endpoints=http://127.0.0.1:2379 # 指定对应的 PD 地址 +``` + +> **注意：** +> +> 该步骤会自动将存储中的 `alloc_id` 增加一个安全值 `100000000`。这将导致后续集群中分配的 ID 偏大。 +> +> 此外，`pd-recover` 不会修改 TSO。因此，在执行此步骤之前，请确保本地时间晚于故障发生时间，并且确认故障前 PD 组件之间已开启 NTP 时钟同步服务。如果未开启，则需要将本地时钟调整到一个未来的时间，以确保 TSO 不会回退。 + +### 第 4 步：重启这个 PD + +当上一步出现 `recovery is successful` 的提示信息后，重启 PD。 + +### 第 5 步：扩容 PD 并启动集群 + +通过部署工具扩容 PD，并启动集群中的其他组件。至此服务恢复。 + +## 方式二：完全重建 PD 集群 + +该方式适用于所有 PD 的数据都丢失，但 TiDB、TiKV 和 TiFlash 等其他组件数据都还存在的情况。 + +### 第 1 步：获取 Cluster ID 一般在 PD、TiKV 或 TiDB 的日志中都可以获取 Cluster ID。你可以直接在服务器上查看日志以获取 Cluster ID。 @@ -77,7 +119,7 @@ cat {{/path/to}}/tikv.log | grep "connect to PD cluster" ... ``` -### 获取已分配 ID +### 第 2 步：获取已分配 ID 在指定已分配 ID 时，需指定一个比当前最大的已分配 ID 更大的值。可以从监控中获取已分配 ID，也可以直接在服务器上查看日志。 @@ -102,11 +144,11 @@ cat {{/path/to}}/pd*.log | grep "idAllocator allocates a new id" | awk -F'=' '{ 你也可以在所有 PD server 中运行上述命令，找到最大的值。 -### 部署一套新的 PD 集群 +### 第 3 步：部署一套新的 PD 集群 部署新的 PD 集群之前，需要停止当前的 PD 集群，然后删除旧的数据目录（或者用 `--data-dir` 指定新的数据目录）。 -### 使用 pd-recover +### 第 4 步：使用 pd-recover 只需在一个 PD 节点上执行 `pd-recover` 即可。 @@ -116,7 +158,7 @@ cat {{/path/to}}/pd*.log | grep "idAllocator allocates a new id" | awk -F'=' '{ ./pd-recover -endpoints http://10.0.1.13:2379 -cluster-id 6747551640615446306 -alloc-id 10000 ``` -### 重启整个集群 +### 第 5 步：重启整个集群 当出现 `recovery is successful` 的提示信息时，重启整个集群。 diff --git a/post-installation-check.md b/post-installation-check.md index a481825fbe3d..9a6b58fac88d 100644 --- a/post-installation-check.md +++ b/post-installation-check.md @@ -63,7 +63,7 @@ mysql -u root -h ${tidb_server_host_IP_address} -P 4000 ```sql Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 3 -Server version: 5.7.25-TiDB-v5.0.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 5.7 compatible +Server version: 5.7.25-TiDB-v7.2.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 5.7 compatible Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved. diff --git a/predicate-push-down.md b/predicate-push-down.md index efdf647bc9fd..d822915e07c2 100644 --- a/predicate-push-down.md +++ b/predicate-push-down.md @@ -46,7 +46,7 @@ explain select * from t where a < substring('123', 1, 1); 该查询与示例 1 中的查询生成了完成一样的执行计划，这是因为谓词 `a < substring('123', 1, 1)` 的 `substring` 的入参均为常量，因此可以提前计算，进而简化得到等价的谓词 `a < 1`。进一步的，可以将 `a < 1` 下推至 TiKV 上。 -### 示例 3: 谓词下推到 join 下方 +### 示例 3: 谓词下推到 join 下方 ```sql create table t(id int primary key, a int not null); @@ -73,20 +73,20 @@ explain select * from t join s on t.a = s.a where t.a < 1; ### 示例 4: 存储层不支持的谓词无法下推 ```sql -create table t(id int primary key, a int not null); -desc select * from t where substring('123', a, 1) = '1'; -+-------------------------+---------+-----------+---------------+----------------------------------------+ -| id | estRows | task | access object | operator info | -+-------------------------+---------+-----------+---------------+----------------------------------------+ -| Selection_7 | 2.00 | root | | eq(substring("123", test.t.a, 1), "1") | -| └─TableReader_6 | 2.00 | root | | data:TableFullScan_5 | -| └─TableFullScan_5 | 2.00 | cop[tikv] | table:t | keep order:false, stats:pseudo | -+-------------------------+---------+-----------+---------------+----------------------------------------+ +create table t(id int primary key, a varchar(10) not null); +desc select * from t where truncate(a, " ") = '1'; ++-------------------------+----------+-----------+---------------+---------------------------------------------------+ +| id | estRows | task | access object | operator info | ++-------------------------+----------+-----------+---------------+---------------------------------------------------+ +| Selection_5 | 8000.00 | root | | eq(truncate(cast(test.t.a, double BINARY), 0), 1) | +| └─TableReader_7 | 10000.00 | root | | data:TableFullScan_6 | +| └─TableFullScan_6 | 10000.00 | cop[tikv] | table:t | keep order:false, stats:pseudo | ++-------------------------+----------+-----------+---------------+---------------------------------------------------+ ``` -在该查询中，存在谓词 `substring('123', a, 1) = '1'`。 +在该查询中，存在谓词 `truncate(a, " ") = '1'`。 -从 explain 结果中可以看到，该谓词没有被下推到 TiKV 上进行计算，这是因为 TiKV coprocessor 中没有对 `substring` 内置函数进行支持，因此无法将其下推到 TiKV 上。 +从 explain 结果中可以看到，该谓词没有被下推到 TiKV 上进行计算，这是因为 TiKV coprocessor 中没有对 `truncate` 内置函数进行支持，因此无法将其下推到 TiKV 上。 ### 示例 5: 外连接中内表上的谓词不能下推 diff --git a/privilege-management.md b/privilege-management.md index 3760f40efa14..4c753ccb29ae 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -342,6 +342,10 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; 需要拥有 `SUPER` 或者 `BACKUP_ADMIN` 权限。 +### CANCEL IMPORT JOB + +需要 `SUPER` 权限来取消属于其他用户的任务，否则只能取消当前用户创建的任务。 + ### CREATE DATABASE 需要拥有全局 `CREATE` 权限。 @@ -374,6 +378,10 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; 需要对所操作的表拥有 `DROP` 权限。 +### IMPORT INTO + +需要对目标表拥有 `SELECT`、`UPDATE`、`INSERT`、`DELETE` 和 `ALTER` 权限。如果是导入存储在 TiDB 本地的文件，还需要有 `FILE` 权限。 + ### LOAD DATA `LOAD DATA` 需要对所操作的表拥有 `INSERT` 权限。执行 `REPLACE INTO` 语句还需要对所操作的表拥有 `DELETE` 权限。 @@ -400,6 +408,8 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; `SHOW PROCESSLIST` 需要 `SUPER` 权限来显示属于其他用户的连接。 +`SHOW IMPORT JOB` 需要 `SUPER` 权限来显示属于其他用户的任务，否则只能看到当前用户创建的任务。 + ### CREATE ROLE/USER `CREATE ROLE` 需要 `CREATE ROLE` 权限。 @@ -458,6 +468,10 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; 需要拥有 `SUPER` 或者 `RESOURCE_GROUP_ADMIN` 权限。 +### CALIBRATE RESOURCE + +需要拥有 `SUPER` 或者 `RESOURCE_GROUP_ADMIN` 权限。 + ## 权限系统的实现 ### 授权表 diff --git a/production-deployment-using-tiup.md b/production-deployment-using-tiup.md index 7449663f2e1f..de60c47efb6d 100644 --- a/production-deployment-using-tiup.md +++ b/production-deployment-using-tiup.md @@ -138,12 +138,12 @@ aliases: ['/docs-cn/dev/production-offline-deployment-using-tiup/', '/zh/tidb/de 如果从官网下载的离线镜像不满足你的具体需求，或者希望对已有的离线镜像内容进行调整，例如增加某个组件的新版本等，可以采取以下步骤进行操作： - 1. 在制作离线镜像时，可通过参数指定具体的组件和版本等信息，获得不完整的离线镜像。例如，要制作一个只包括 v1.11.3 版本 TiUP 和 TiUP Cluster 的离线镜像，可执行如下命令： + 1. 在制作离线镜像时，可通过参数指定具体的组件和版本等信息，获得不完整的离线镜像。例如，要制作一个只包括 v1.12.3 版本 TiUP 和 TiUP Cluster 的离线镜像，可执行如下命令： {{< copyable "shell-regular" >}} ```bash - tiup mirror clone tiup-custom-mirror-v1.11.3 --tiup v1.11.3 --cluster v1.11.3 + tiup mirror clone tiup-custom-mirror-v1.12.3 --tiup v1.12.3 --cluster v1.12.3 ``` 如果只需要某一特定平台的组件，也可以通过 `--os` 和 `--arch` 参数来指定。 @@ -175,10 +175,10 @@ aliases: ['/docs-cn/dev/production-offline-deployment-using-tiup/', '/zh/tidb/de {{< copyable "shell-regular" >}} ```bash - tiup mirror merge tiup-custom-mirror-v1.11.3 + tiup mirror merge tiup-custom-mirror-v1.12.3 ``` - 5. 上述步骤完成后，通过 `tiup list` 命令检查执行结果。在本文例子中，使用 `tiup list tiup` 和 `tiup list cluster` 均应能看到对应组件的 `v1.11.3` 版本出现在结果中。 + 5. 上述步骤完成后，通过 `tiup list` 命令检查执行结果。在本文例子中，使用 `tiup list tiup` 和 `tiup list cluster` 均应能看到对应组件的 `v1.12.3` 版本出现在结果中。 #### 部署离线环境 TiUP 组件 @@ -341,13 +341,13 @@ alertmanager_servers: {{< copyable "shell-regular" >}} ```shell - tiup cluster deploy tidb-test v7.0.0 ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa] + tiup cluster deploy tidb-test v7.2.0 ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa] ``` 以上部署示例中： - `tidb-test` 为部署的集群名称。 -- `v7.0.0` 为部署的集群版本，可以通过执行 `tiup list tidb` 来查看 TiUP 支持的最新可用版本。 +- `v7.2.0` 为部署的集群版本，可以通过执行 `tiup list tidb` 来查看 TiUP 支持的最新可用版本。 - 初始化配置文件为 `topology.yaml`。 - `--user root` 表示通过 root 用户登录到目标主机完成集群部署，该用户需要有 ssh 到目标机器的权限，并且在目标机器有 sudo 权限。也可以用其他有 ssh 和 sudo 权限的用户完成部署。 - [-i] 及 [-p] 为可选项，如果已经配置免密登录目标机，则不需填写。否则选择其一即可，[-i] 为可登录到目标机的 root 用户（或 --user 指定的其他用户）的私钥，也可使用 [-p] 交互式输入该用户的密码。 diff --git a/quick-start-with-tidb.md b/quick-start-with-tidb.md index 1e74696445b8..11af47bee512 100644 --- a/quick-start-with-tidb.md +++ b/quick-start-with-tidb.md @@ -81,10 +81,10 @@ TiDB 是一个分布式系统。最基础的 TiDB 测试集群通常由 2 个 Ti {{< copyable "shell-regular" >}} ```shell - tiup playground v7.0.0 --db 2 --pd 3 --kv 3 + tiup playground v7.2.0 --db 2 --pd 3 --kv 3 ``` - 上述命令会在本地下载并启动某个版本的集群（例如 v7.0.0）。最新版本可以通过执行 `tiup list tidb` 来查看。运行结果将显示集群的访问方式： + 上述命令会在本地下载并启动某个版本的集群（例如 v7.2.0）。最新版本可以通过执行 `tiup list tidb` 来查看。运行结果将显示集群的访问方式： ```log CLUSTER START SUCCESSFULLY, Enjoy it ^-^ @@ -198,10 +198,10 @@ TiDB 是一个分布式系统。最基础的 TiDB 测试集群通常由 2 个 Ti {{< copyable "shell-regular" >}} ```shell - tiup playground v7.0.0 --db 2 --pd 3 --kv 3 + tiup playground v7.2.0 --db 2 --pd 3 --kv 3 ``` - 上述命令会在本地下载并启动某个版本的集群（例如 v7.0.0）。最新版本可以通过执行 `tiup list tidb` 来查看。运行结果将显示集群的访问方式： + 上述命令会在本地下载并启动某个版本的集群（例如 v7.2.0）。最新版本可以通过执行 `tiup list tidb` 来查看。运行结果将显示集群的访问方式： ```log CLUSTER START SUCCESSFULLY, Enjoy it ^-^ @@ -432,7 +432,7 @@ TiDB 是一个分布式系统。最基础的 TiDB 测试集群通常由 2 个 Ti ``` - 参数 `` 表示设置集群名称 - - 参数 `` 表示设置集群版本，例如 `v6.5.0`。可以通过 `tiup list tidb` 命令来查看当前支持部署的 TiDB 版本 + - 参数 `` 表示设置集群版本，例如 `v7.2.0`。可以通过 `tiup list tidb` 命令来查看当前支持部署的 TiDB 版本 - 参数 `-p` 表示在连接目标机器时使用密码登录 > **注意：** diff --git a/read-historical-data.md b/read-historical-data.md index b2f721112099..595d83a60632 100644 --- a/read-historical-data.md +++ b/read-historical-data.md @@ -219,6 +219,6 @@ SET GLOBAL tidb_gc_life_time="60m"; 如果想要恢复历史版本的数据，可以使用以下任意一种方法进行设置： -- 对于简单场景，在设置 `tidb_snapshot` 变量后使用 `SELECT` 语句并复制粘贴输出结果，或者使用 `SELECT ... INTO LOCAL OUTFLE` 语句并使用 `LOAD DATA` 语句来导入数据。 +- 对于简单场景，在设置 `tidb_snapshot` 变量后使用 [`SELECT`](/sql-statements/sql-statement-select.md) 语句并复制粘贴输出结果，或者使用 `SELECT ... INTO OUTFILE` 语句并使用 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md) 语句来导入数据。 - 使用 [Dumpling](/dumpling-overview.md#导出-tidb-的历史数据快照) 导出 TiDB 的历史数据快照。Dumpling 在导出较大的数据集时有较好的性能。 diff --git a/releases/release-5.2.0.md b/releases/release-5.2.0.md index c941b074a54f..bb8ee9cd20f7 100644 --- a/releases/release-5.2.0.md +++ b/releases/release-5.2.0.md @@ -20,7 +20,7 @@ TiDB 版本：5.2.0 - 新增 TiFlash I/O 限流功能，提升 TiFlash 读写稳定性。 - 为 TiKV 引入新的流控机制代替之前的 RocksDB write stall 流控机制，提升 TiKV 流控稳定性。 - 简化 Data Migration (DM) 工具运维，降低运维管理的成本。 -- TiCDC 支持 HTTP 协议 OpenAPI 对 TiCDC 任务进行管理，在 Kubernetes 以及 On-Premises 环境下提供更友好的运维方式。(实验特性) +- TiCDC 支持 HTTP 协议 OpenAPI 对 TiCDC 任务进行管理，在 Kubernetes 以及本地部署环境下提供更友好的运维方式。(实验特性) ## 兼容性更改 @@ -161,7 +161,7 @@ TiDB 版本：5.2.0 ### TiDB 数据共享订阅 -TiCDC 支持 HTTP 协议 OpenAPI 对 TiCDC 任务进行管理，在 Kubernetes 以及 On-Premises 环境下提供更友好的运维方式。(实验特性） +TiCDC 支持 HTTP 协议 OpenAPI 对 TiCDC 任务进行管理，在 Kubernetes 以及本地部署环境下提供更友好的运维方式。(实验特性） [#2411](https://github.com/pingcap/tiflow/issues/2411) diff --git a/releases/release-6.0.0-dmr.md b/releases/release-6.0.0-dmr.md index 52f4058da5f4..8d0bd0010ae3 100644 --- a/releases/release-6.0.0-dmr.md +++ b/releases/release-6.0.0-dmr.md @@ -264,7 +264,7 @@ v6.0.0 是 DMR 版本，版本名称为 6.0.0-DMR。 - 企业级数据库管理平台 TiDB Enterprise Manager - TiDB Enterprise Manager 是一款以 TiDB 数据库为核心的企业级数据库管理平台，帮助用户在私有部署 (on-premises) 或公有云环境中管理 TiDB 集群。 + TiDB Enterprise Manager 是一款以 TiDB 数据库为核心的企业级数据库管理平台，帮助用户在本地部署环境或公有云环境中管理 TiDB 集群。 TiDB Enterprise Manager 不仅为 TiDB 集群提供全生命周期的可视化管理，也同时一站式提供 TiDB 数据库的参数管理、数据库版本升级、克隆集群、主备集群切换、数据导入导出、数据同步、数据备份恢复服务，能有效提高 TiDB 集群运维效率，降低企业运维成本。 diff --git a/releases/release-6.1.6.md b/releases/release-6.1.6.md new file mode 100644 index 000000000000..dcc3bafe336f --- /dev/null +++ b/releases/release-6.1.6.md @@ -0,0 +1,97 @@ +--- +title: TiDB 6.1.6 Release Notes +summary: 了解 TiDB 6.1.6 版本的兼容性变更、改进提升，以及错误修复。 +--- + +# TiDB 6.1.6 Release Notes + +发版日期：2023 年 4 月 12 日 + +TiDB 版本：6.1.6 + +试用链接：[快速体验](https://docs.pingcap.com/zh/tidb/v6.1/quick-start-with-tidb) | [生产部署](https://docs.pingcap.com/zh/tidb/v6.1/production-deployment-using-tiup) | [下载离线包](https://cn.pingcap.com/product-community/?version=v6.1.6#version-list) + +## 兼容性变更 + +- TiCDC 修复了 Avro 编码 FLOAT 类型数据错误的问题 [#8490](https://github.com/pingcap/tiflow/issues/8490) @[3AceShowHand](https://github.com/3AceShowHand) + + 在升级 TiCDC 集群到 v6.1.6 或更高的 v6.1.x 版本时，如果使用 Avro 同步的表包含 `FLOAT` 类型数据，请在升级前手动调整 Confluent Schema Registry 的兼容性策略为 `None`，使 changefeed 能够成功更新 schema。否则，在升级之后 changefeed 将无法更新 schema 并进入错误状态。 + +## 提升改进 + ++ TiDB + - Prepared Plan Cache 支持缓存 BatchPointGet 计划 [#42125](https://github.com/pingcap/tidb/issues/42125) @[qw4990](https://github.com/qw4990) + - Index Join 支持更多的 SQL 格式 [#40505](https://github.com/pingcap/tidb/issues/40505) @[Yisaer](https://github.com/Yisaer) + ++ TiKV + + - 支持在小于 1 core 的 CPU 下启动 TiKV [#13586](https://github.com/tikv/tikv/issues/13586) [#13752](https://github.com/tikv/tikv/issues/13752) [#14017](https://github.com/tikv/tikv/issues/14017) @[andreid-db](https://github.com/andreid-db) + +## Bug 修复 + ++ TiDB + + - 修复 `ignore_plan_cache` hint 对 INSERT 语句可能不生效的问题 [#40079](https://github.com/pingcap/tidb/issues/40079) [#39717](https://github.com/pingcap/tidb/issues/39717) @[qw4990](https://github.com/qw4990) + - 修复了 `indexMerge` 遇到错误后可能会导致 TiDB 崩溃的问题 [#41047](https://github.com/pingcap/tidb/issues/41047) [#40877](https://github.com/pingcap/tidb/issues/40877) @[guo-shaoge](https://github.com/guo-shaoge) @[windtalker](https://github.com/windtalker) + - 修复错误下推包含虚拟列的 TopN 算子到 TiKV 或 TiFlash 导致结果错误的问题 [#41355](https://github.com/pingcap/tidb/issues/41355) @[Dousir9](https://github.com/Dousir9) + - 修复了使用 `Prepare` 或 `Execute` 查询某些虚拟表时无法将表 ID 下推，导致在大量 Region 的情况下 PD OOM 的问题 [#39605](https://github.com/pingcap/tidb/issues/39605) @[djshow832](https://github.com/djshow832) + - 修复 Plan Cache 处理 `int_col in (decimal...)` 条件时可能缓存 FullScan 计划的问题 [#40224](https://github.com/pingcap/tidb/issues/40224) @[qw4990](https://github.com/qw4990) + - 修复 IndexMerge 计划在 SET 类型列上可能生成错误区间的问题 [#41273](https://github.com/pingcap/tidb/issues/41273) [#41293](https://github.com/pingcap/tidb/issues/41293) @[time-and-fate](https://github.com/time-and-fate) + - 修复了无符号的 `TINYINT`/`SMALLINT`/`INT` 和小于 `0` 的 `DECIMAL`/`FLOAT`/`DOUBLE` 类型比较时，结果可能出错的问题 [#41736](https://github.com/pingcap/tidb/issues/41736) @[LittleFall](https://github.com/LittleFall) + - 修复了查询 `INFORMATION_SCHEMA.CLUSTER_SLOW_QUERY` 表导致 TiDB 服务器 OOM 的问题，在 Grafana dashboard 中查看慢查询记录的时候可能会触发该问题 [#33893](https://github.com/pingcap/tidb/issues/33893) @[crazycs520](https://github.com/crazycs520) + - 修复 Range 分区允许多个 `MAXVALUE` 分区的问题 [#36329](https://github.com/pingcap/tidb/issues/36329) @[u5surf](https://github.com/u5surf) + - 修复 Plan Cache 可能缓存 Shuffle 算子导致返回错误结果的问题 [#38335](https://github.com/pingcap/tidb/issues/38335) @[qw4990](https://github.com/qw4990) + - 修复了时区中的数据争用可能导致数据和索引不一致问题 [#40710](https://github.com/pingcap/tidb/issues/40710) @[wjhuang2016](https://github.com/wjhuang2016) + - 修复了 `indexMerge` 中可能会出现 goroutine 泄露的问题 [#41545](https://github.com/pingcap/tidb/issues/41545) [#41605](https://github.com/pingcap/tidb/issues/41605) @[guo-shaoge](https://github.com/guo-shaoge) + - 修复在使用 Cursor Fetch 且在 Execute、Fetch、Close 之间运行其它语句后，Fetch 与 Close 命令可能会返回错误结果或造成 TiDB Panic 的问题 [#40094](https://github.com/pingcap/tidb/issues/40094) [@YangKeao](https://github.com/YangKeao) + - 修复了使用 DDL 修改浮点类型时，保持长度不变且减少小数位后，旧数据仍然保持原样的问题 [#41281](https://github.com/pingcap/tidb/issues/41281) [@zimulala](https://github.com/zimulala) + - 修复了 Join `information_schema.columns` 表会造成 TiDB panic 的问题 [#32459](https://github.com/pingcap/tidb/issues/32459) [@tangenta](https://github.com/tangenta) + - 修复了生成执行计划过程中，因为获取的 InfoSchema 不一致而导致的 TiDB panic 的问题 [#41622](https://github.com/pingcap/tidb/issues/41622) [@tiancaiamao](https://github.com/tiancaiamao) + - 修复 TiFlash 执行中遇到生成列会报错的问题 [#40663](https://github.com/pingcap/tidb/issues/40663) @[guo-shaoge](https://github.com/guo-shaoge) + - 修复当同一个 SQL 中出现多个不同的分区表时，TiDB 可能执行得到错误结果的问题 [#42135](https://github.com/pingcap/tidb/issues/42135) @[mjonss](https://github.com/mjonss) + - 修复 Plan Cache 可能缓存 Shuffle 算子导致返回错误结果的问题 [#38335](https://github.com/pingcap/tidb/issues/38335) @[qw4990](https://github.com/qw4990) @[fzzf678](https://github.com/fzzf678) + - 修复使用 Index Merge 的方式读取包含 `SET` 类型列的表时，结果可能出错的问题 [#41293](https://github.com/pingcap/tidb/issues/41293) @[time-and-fate](https://github.com/time-and-fate) + - 修复在开启 Prepared Plan Cache 的情况下，索引全表扫可能会报错的问题 [#42150](https://github.com/pingcap/tidb/issues/42150) @[fzzf678](https://github.com/fzzf678) + - 修复在 DDL 执行过程中，使用 PointGet 读取表的 SQL 语句可能会在执行时抛出 panic 的问题 [#41622](https://github.com/pingcap/tidb/issues/41622) @[tiancaiamao](https://github.com/tiancaiamao) + - 修复事务内执行 PointUpdate 之后，`SELECT` 结果不正确的问题 [#28011](https://github.com/pingcap/tidb/issues/28011) @[zyguan](https://github.com/zyguan) + - 定期清理过期的 Region 缓存，避免内存泄漏和性能下降问题 [#40461](https://github.com/pingcap/tidb/issues/40461) @[sticnarf](https://github.com/sticnarf) @[zyguan](https://github.com/zyguan) + - 修复 `INSERT IGNORE` 和 `REPLACE` 语句对不修改 value 的 key 没有加锁的问题 [#42121](https://github.com/pingcap/tidb/issues/42121) @[zyguan](https://github.com/zyguan) + ++ TiKV + + - 修复转换 `const Enum` 类型到其他类型时报错的问题 [#14156](https://github.com/tikv/tikv/issues/14156) @[wshwsh12](https://github.com/wshwsh12) + - 修复 CPU 配额限制的问题 [13084](https://github.com/tikv/tikv/issues/13084) @[BornChanger](https://github.com/BornChanger) + - 修复 Snapshot Last Index 不正确的问题 [12618](https://github.com/tikv/tikv/issues/12618) @[LintianShi](https://github.com/LintianShi) + ++ PD + + - 修复 Region Scatter 接口可能导致 leader 分布不均匀的问题 [#6017](https://github.com/tikv/pd/issues/6017) @[HunDunDM](https://github.com/HunDunDM) + - 修复 Online Unsafe Recovery 超时机制不生效的问题 [#6107](https://github.com/tikv/pd/issues/6107) @[v01dstar](https://github.com/v01dstar) + ++ TiFlash + + - 修复半连接在计算笛卡尔积时，使用内存过量的问题 [#6730](https://github.com/pingcap/tiflash/issues/6730) @[gengliqi](https://github.com/gengliqi) + - 修复 TiFlash 日志搜索过慢的问题 [#6829](https://github.com/pingcap/tiflash/issues/6829) @[hehechen](https://github.com/hehechen) + - 修复了开启 new collation 后 TopN/Sort 算子结果可能出错的问题 [#6807](https://github.com/pingcap/tiflash/issues/6807) @[xzhangxian1008](https://github.com/xzhangxian1008) + - 修复了 Decimal 转换在某些情况下进位错误的问题 [#6994](https://github.com/pingcap/tiflash/issues/6994) @[windtalker](https://github.com/windtalker) + - 修复 TiFlash 无法识别生成列的问题 [#6801](https://github.com/pingcap/tiflash/issues/6801) @[guo-shaoge](https://github.com/guo-shaoge) + - 修复了 Decimal 除法在某些情况下最后一位未进位的问题 [#7022](https://github.com/pingcap/tiflash/issues/7022) @[LittleFall](https://github.com/LittleFall) + ++ Tools + + + TiCDC + + - 修复同步数据时由于 `UPDATE` 和 `INSERT` 语句乱序可能导致 `Duplicate entry` 错误的问题 [#8597](https://github.com/pingcap/tiflow/issues/8597) @[sdojjy](https://github.com/sdojjy) + - 修复由于 PD 和 TiCDC 之间的网络隔离引起 TiCDC 程序异常退出的问题 [#8562](https://github.com/pingcap/tiflow/issues/8562) @[overvenus](https://github.com/overvenus) + - 修复下游为 TiDB 或 MySQL 时，无主键且非空唯一索引所在列指定了 CHARACTER SET 同步时可能会出现数据不一致的问题 [#8420](https://github.com/pingcap/tiflow/issues/8420) @[zhaoxinyu](https://github.com/zhaoxinyu) + - 修复 `db sorter` 使用内存时未受 `cgroup memory limit` 限制的问题 [#8588](https://github.com/pingcap/tiflow/issues/8588) @[amyangfei](https://github.com/amyangfei) + - 优化 `cdc cli` 在遇到非法输入时的错误提示 [#7903](https://github.com/pingcap/tiflow/issues/7903) @[CharlesCheung96](https://github.com/CharlesCheung96) + - 修复 redo log 容忍 S3 存储故障的时间过短的问题 [#8089](https://github.com/pingcap/tiflow/issues/8089) @[CharlesCheung96](https://github.com/CharlesCheung96) + - 修复在 PD 异常时，暂停一个 changefeed 会错误设置状态的问题 [#8330](https://github.com/pingcap/tiflow/issues/8330) @[sdojjy](https://github.com/sdojjy) + + + TiDB Lightning + + - 修复冲突处理逻辑 (`duplicate-resolution`) 可能导致 checksum 不一致的问题 [#40657](https://github.com/pingcap/tidb/issues/40657) @[gozssky](https://github.com/gozssky) + - 修复 TiDB Lightning 在 split-region 阶段发生 panic 的问题 [#40934](https://github.com/pingcap/tidb/issues/40934) @[lance6716](https://github.com/lance6716) + - 修复了在使用 Local Backend 模式导入数据时，当导入目标表的复合主键中存在 `auto_random` 列，且源数据中没有指定该列的值时，相关列没有自动生成数据的问题 [#41454](https://github.com/pingcap/tidb/issues/41454) @[D3Hunter](https://github.com/D3Hunter) + - 修复在并行导入时，当除最后一个 TiDB Lightning 实例外的其他实例都遇到本地重复记录时，TiDB Lightning 可能会错误地跳过冲突处理的问题 [#40923](https://github.com/pingcap/tidb/issues/40923) @[lichunzhu](https://github.com/lichunzhu) diff --git a/releases/release-6.2.0.md b/releases/release-6.2.0.md index 6b21b908d734..c341633e884c 100644 --- a/releases/release-6.2.0.md +++ b/releases/release-6.2.0.md @@ -22,7 +22,7 @@ TiDB 版本：6.2.0-DMR - 引入新的 DDL 并行执行框架，减少 DDL 阻塞，大幅提升执行效率。 - TiKV 支持[自适应调整 CPU 使用率](/tikv-configuration-file.md#后台限流)，确保数据库稳定高效运行。 - 支持 [point-in-time recovery (PITR)](/br/backup-and-restore-overview.md)，允许恢复备份集群的历史任意时间点的快照。 -- TiDB Lightning 使用 Physical Import Mode [导入时限制调度范围从集群降低到表级别](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#导入时限制调度范围从集群降低到表级别)。 +- TiDB Lightning 使用物理导入模式[导入时限制调度范围从集群降低到表级别](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#导入时暂停-pd-调度的范围)。 - Backup & Restore (BR) 支持[恢复用户和权限数据](/br/br-snapshot-guide.md#恢复-mysql-数据库下的表)，备份恢复体验更平滑。 - TiCDC 支持[过滤指定类型的 DDL 事件](/ticdc/ticdc-filter.md#event-filter-事件过滤器-从-v620-版本开始引入)，解锁更多数据同步场景。 - 事务中支持 [`SAVEPOINT` 机制](/sql-statements/sql-statement-savepoint.md)，可以灵活地控制事务内的回退节点。 @@ -204,7 +204,7 @@ TiDB 版本：6.2.0-DMR [用户文档](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#磁盘资源配额-从-v620-版本开始引入) [#446](https://github.com/pingcap/tidb-lightning/issues/446) @[buchuitoudegou](https://github.com/buchuitoudegou) -* TiDB Lightning 支持使用 Physical Import Mode 导入数据到生产集群 +* TiDB Lightning 支持使用物理导入模式导入数据到生产集群 TiDB Lightning 原有的物理导入模式 (backend='local') 对目标集群影响较大，例如导入过程将停止 PD 调度等，因此仅适用于目标集群初次导入数据。 @@ -212,9 +212,9 @@ TiDB 版本：6.2.0-DMR 此特性无需手动配置，目标 TiDB 集群版本在 v6.1.0 及以上且 TiDB Lightning 在 v6.2.0 及以上时自动生效。 - [用户文档](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#导入时限制调度范围从集群降低到表级别) [#35148](https://github.com/pingcap/tidb/issues/35148) @[gozssky](https://github.com/gozssky) + [用户文档](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#导入时暂停-pd-调度的范围) [#35148](https://github.com/pingcap/tidb/issues/35148) @[gozssky](https://github.com/gozssky) -* 调整 [TiDB Lightning 在线文档](/tidb-lightning/tidb-lightning-overview.md)，使其目录结构更加合理和清晰。同时对文档中关于“后端模式”的描述进行了修改，使用 Physical Import Mode 替代原有 local backend，使用 Logical Import Mode 替代原有 tidb backend ，以降低新用户的理解难度。 +* 调整 [TiDB Lightning 在线文档](/tidb-lightning/tidb-lightning-overview.md)，使其目录结构更加合理和清晰。同时对文档中关于“后端模式”的描述进行了修改，使用物理导入模式替代原有 `local` 后端模式，使用逻辑导入模式替代原有 `tidb` 后端模式，以降低新用户的理解难度。 ### 数据共享与订阅 @@ -262,6 +262,7 @@ TiDB 版本：6.2.0-DMR | TiKV | [quota.background-write-bandwidth](/tikv-configuration-file.md#background-write-bandwidth-从-v620-版本开始引入) | 新增 | 限制后台事务写入的带宽（暂未生效）。| | TiKV | [quota.background-read-bandwidth](/tikv-configuration-file.md#background-read-bandwidth-从-v620-版本开始引入) | 新增 | 限制后台事务读取数据和 Coprocessor 读取数据的带宽（暂未生效）。 | | TiKV | [quota.enable-auto-tune](/tikv-configuration-file.md#enable-auto-tune-从-v620-版本开始引入) | 新增 | 是否支持 quota 动态调整。如果打开该配置项，TiKV 会根据 TiKV 实例的负载情况动态调整对后台请求的限制 quota。 | +| TiKV | [rocksdb.defaultcf|writecf|lockcf.format-version](/tikv-configuration-file.md#format-version-从-v620-版本开始引入) | 新增 | 设置 SST 文件的格式版本。 | | TiKV | rocksdb.enable-pipelined-commit | 删除 | 该配置不再生效。 | | TiKV | gc-merge-rewrite | 删除 | 该配置不再生效。 | | TiKV | [log-backup.enable](/tikv-configuration-file.md#enable-从-v620-版本开始引入) | 新增 | TiKV 是否开启日志备份功能。 | diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index 82e079ed5a09..1478e28447c9 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -8,6 +8,10 @@ title: TiDB 6.3.0 Release Notes TiDB 版本：6.3.0-DMR +> **注意：** +> +> TiDB 6.3.0-DMR 的用户文档已[归档](https://docs-archive.pingcap.com/zh/tidb/v6.3)。如无特殊需求，建议使用 TiDB 数据库的[最新 LTS 版本](https://docs.pingcap.com/zh/tidb/stable)。 + 试用链接：[快速体验](https://docs.pingcap.com/zh/tidb/v6.3/quick-start-with-tidb) | [下载离线包](https://cn.pingcap.com/product-community/?version=v6.3.0-DMR#version-list) 在 6.3.0-DMR 版本中，你可以获得以下关键特性： @@ -170,7 +174,7 @@ TiDB 版本：6.3.0-DMR * PITR 支持 [GCS 和 Azure Blob Storage](/br/backup-and-restore-storages.md) 作为备份存储 @[joccau](https://github.com/joccau) - 部署在 GCP 或者 Azure 上的用户，将 TiDB 集群升级至 v6.3.0 就可以使用 PITR 功能。 + 部署在 Google Cloud 或者 Azure 上的用户，将 TiDB 集群升级至 v6.3.0 就可以使用 PITR 功能。 * BR 支持 AWS S3 Object Lock [#13442](https://github.com/tikv/tikv/issues/13442) @[3pointer](https://github.com/3pointer) diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 1374dbc3f579..faa610dd590a 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -8,6 +8,10 @@ title: TiDB 6.4.0 Release Notes TiDB 版本：6.4.0-DMR +> **注意：** +> +> TiDB 6.4.0-DMR 的用户文档已[归档](https://docs-archive.pingcap.com/zh/tidb/v6.4)。如无特殊需求，建议使用 TiDB 数据库的[最新 LTS 版本](https://docs.pingcap.com/zh/tidb/stable)。 + 试用链接：[快速体验](https://docs.pingcap.com/zh/tidb/v6.4/quick-start-with-tidb) | [下载离线包](https://cn.pingcap.com/product-community/?version=v6.4.0-DMR#version-list) 在 6.4.0-DMR 版本中，你可以获得以下关键特性： diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index 1a59eef35b22..175e2210380b 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -284,7 +284,7 @@ TiDB 6.5.0 为长期支持版本 (Long-Term Support Release, LTS)。 TiDB 快照备份功能支持断点续传。当 BR 遇到可恢复的错误时会进行重试，但是超过固定重试次数之后会备份退出。断点续传功能允许对持续更长时间的可恢复故障进行重试恢复，比如几十分钟的网络故障。 - 需要注意的是，如果你没有在 BR 退出后一个小时内完成故障恢复，那么还未备份的快照数据可能会被 GC 机制回收，从而造成备份失败。更多信息，请参考[用户文档](/br/br-checkpoint.md)。 + 需要注意的是，如果你没有在 BR 退出后一个小时内完成故障恢复，那么还未备份的快照数据可能会被 GC 机制回收，从而造成备份失败。更多信息，请参考[用户文档](/br/br-checkpoint-backup.md#确保在-gc-前重试)。 * PITR 性能大幅提升 [@joccau](https://github.com/joccau) diff --git a/releases/release-6.5.1.md b/releases/release-6.5.1.md index e36dabb022a3..c6e75d2c03c2 100644 --- a/releases/release-6.5.1.md +++ b/releases/release-6.5.1.md @@ -112,7 +112,7 @@ TiDB 版本：6.5.1 - 修复慢日志中查询计划算子可能缺失的问题 [#41458](https://github.com/pingcap/tidb/issues/41458) @[time-and-fate](https://github.com/time-and-fate) - 修复错误下推包含虚拟列的 TopN 算子到 TiKV 或 TiFlash 导致结果错误的问题 [#41355](https://github.com/pingcap/tidb/issues/41355) @[Dousir9](https://github.com/Dousir9) - 修复添加索引时数据不一致的问题 [#40698](https://github.com/pingcap/tidb/issues/40698) [#40730](https://github.com/pingcap/tidb/issues/40730) [#41459](https://github.com/pingcap/tidb/issues/41459) [#40464](https://github.com/pingcap/tidb/issues/40464) [#40217](https://github.com/pingcap/tidb/issues/40217) @[tangenta](https://github.com/tangenta) - - 修复添加索引时出现 "Pessimistic lock not found" 的报错问题 [#41515](https://github.com/pingcap/tidb/issues/41515) @[tangenta](https://github.com/tangenta) + - 修复添加索引时出现 `PessimisticLockNotFound` 的报错问题 [#41515](https://github.com/pingcap/tidb/issues/41515) @[tangenta](https://github.com/tangenta) - 修复添加唯一索引时误报重复键的问题 [#41630](https://github.com/pingcap/tidb/issues/41630) @[tangenta](https://github.com/tangenta) - 修复 TiDB 使用 `paging` 时性能下降的问题 [#40741](https://github.com/pingcap/tidb/issues/40741) @[solotzg](https://github.com/solotzg) diff --git a/releases/release-6.5.2.md b/releases/release-6.5.2.md new file mode 100644 index 000000000000..e42f5383e2bf --- /dev/null +++ b/releases/release-6.5.2.md @@ -0,0 +1,109 @@ +--- +title: TiDB 6.5.2 Release Notes +summary: 了解 TiDB 6.5.2 版本的兼容性变更、改进提升，以及错误修复。 +--- + +# TiDB 6.5.2 Release Notes + +发版日期：2023 年 4 月 21 日 + +TiDB 版本：6.5.2 + +试用链接：[快速体验](https://docs.pingcap.com/zh/tidb/v6.5/quick-start-with-tidb) | [生产部署](https://docs.pingcap.com/zh/tidb/v6.5/production-deployment-using-tiup) | [下载离线包](https://cn.pingcap.com/product-community/?version=v6.5.2#version-list) + +## 兼容性变更 + +- TiCDC 修复了 Avro 编码 `FLOAT` 类型数据错误的问题 [#8490](https://github.com/pingcap/tiflow/issues/8490) @[3AceShowHand](https://github.com/3AceShowHand) + + 在升级 TiCDC 集群到 v6.5.2 或更高的 v6.5.x 版本时，如果使用 Avro 同步的表包含 `FLOAT` 类型数据，请在升级前手动调整 Confluent Schema Registry 的兼容性策略为 `None`，使 changefeed 能够成功更新 schema。否则，在升级之后 changefeed 将无法更新 schema 并进入错误状态。 + +- 为了解决同步分区表到存储服务时可能丢数据的问题，TiCDC 配置项 [`sink.enable-partition-separator`](/ticdc/ticdc-changefeed-config.md#ticdc-changefeed-配置文件说明) 默认值从 `false` 修改为 `true`，代表默认会将表中各个分区的数据分不同的目录来存储。建议保持该配置项为 `true` 以避免该问题。[#8724](https://github.com/pingcap/tiflow/issues/8724) @[CharlesCheung96](https://github.com/CharlesCheung96) + +## 改进提升 + ++ TiDB + + - Prepared Plan Cache 支持缓存 BatchPointGet 计划 [#42125](https://github.com/pingcap/tidb/issues/42125) @[qw4990](https://github.com/qw4990) + - Index Join 支持更多的 SQL 格式 [#40505](https://github.com/pingcap/tidb/issues/40505) @[Yisaer](https://github.com/Yisaer) + - 将 Index Merge Reader 中的一些 Log 等级从 `"info"` 降低为 `"debug"` [#41949](https://github.com/pingcap/tidb/issues/41949) @[yibin87](https://github.com/yibin87) + - 优化带 Limit 的 Range 类型分区表的 `distsql_concurrency` 设置以降低查询延迟 [#41480](https://github.com/pingcap/tidb/issues/41480) @[you06](https://github.com/you06) + ++ TiFlash + + - 减少了 TiFlash 在读取过程中的任务调度对 CPU 的消耗 [#6495](https://github.com/pingcap/tiflash/issues/6495) @[JinheLin](https://github.com/JinheLin) + - 提升默认参数下 BR 和 TiDB Lightning 向 TiFlash 导入数据的性能 [#7272](https://github.com/pingcap/tiflash/issues/7272) @[breezewish](https://github.com/breezewish) + ++ Tools + + + TiCDC + + - 发布 TiCDC Open API v2.0 [#8743](https://github.com/pingcap/tiflow/issues/8743) @[sdojjy](https://github.com/sdojjy) + - 引入 `gomemlimit` 以防止 TiCDC 出现 OOM 问题 [#8675](https://github.com/pingcap/tiflow/issues/8675) @[amyangfei](https://github.com/amyangfei) + - 采用 multi-statement 的方式优化批量执行 `UPDATE` 场景下的同步性能 [#8057](https://github.com/pingcap/tiflow/issues/8057) @[amyangfei](https://github.com/amyangfei) + - 支持在 redo applier 中拆分事务以提升 apply 吞吐，降低灾难场景的 RTO [#8318](https://github.com/pingcap/tiflow/issues/8318) @[CharlesCheung96](https://github.com/CharlesCheung96) + - 支持在 redo log 里 apply DDL 事件 [#8361](https://github.com/pingcap/tiflow/issues/8361) @[CharlesCheung96](https://github.com/CharlesCheung96) + + + TiDB Lightning + + - 支持导入带有 BOM header 的 CSV 数据文件 [#40744](https://github.com/pingcap/tidb/issues/40744) @[dsdashun](https://github.com/dsdashun) + +## 错误修复 + ++ TiDB + + - 修复缓存表执行新增列操作后，新增列值为 `NULL` 而非列的默认值的问题 [#42928](https://github.com/pingcap/tidb/issues/42928) @[lqs](https://github.com/lqs) + - 修复分区特别多并且带有 TiFlash 副本的分区表在执行 `TRUNCATE TABLE` 时，出现写冲突导致 DDL 重试的问题 [#42940](https://github.com/pingcap/tidb/issues/42940) @[mjonss](https://github.com/mjonss) + - 修复对于执行中的 `DROP TABLE` 操作，`ADMIN SHOW DDL JOBS` 的结果中缺少表名的问题 [#42268](https://github.com/pingcap/tidb/issues/42268) @[tiancaiamao](https://github.com/tiancaiamao) + - 修复读取 cgroup 信息出错导致 TiDB Server 无法启动的问题，报错信息为 "can't read file memory.stat from cgroup v1: open /sys/memory.stat no such file or directory" [#42659](https://github.com/pingcap/tidb/issues/42659) @[hawkingrei](https://github.com/hawkingrei) + - 修复在分区表上执行修改列操作时，数据截断没有正确发出警告的问题 [#24427](https://github.com/pingcap/tidb/issues/24427) @[mjonss](https://github.com/mjonss) + - 修复了生成执行计划过程中，因为获取的 InfoSchema 不一致而导致的 TiDB panic 的问题 [#41622](https://github.com/pingcap/tidb/issues/41622) @[tiancaiamao](https://github.com/tiancaiamao) + - 修复了使用 DDL 修改浮点类型时，保持长度不变且减少小数位后，旧数据仍然保持原样的问题 [#41281](https://github.com/pingcap/tidb/issues/41281) @[zimulala](https://github.com/zimulala) + - 修复事务内执行 PointUpdate 之后，`SELECT` 结果不正确的问题 [#28011](https://github.com/pingcap/tidb/issues/28011) @[zyguan](https://github.com/zyguan) + - 修复在使用 Cursor Fetch 且在 Execute、Fetch、Close 之间运行其它语句后，Fetch 与 Close 命令可能会返回错误结果或造成 TiDB Panic 的问题 [#40094](https://github.com/pingcap/tidb/issues/40094) @[YangKeao](https://github.com/YangKeao) + - 修复 `INSERT IGNORE` 和 `REPLACE` 语句对不修改 value 的 key 没有加锁的问题 [#42121](https://github.com/pingcap/tidb/issues/42121) @[zyguan](https://github.com/zyguan) + - 修复 TiFlash 执行中遇到生成列会报错的问题 [#40663](https://github.com/pingcap/tidb/issues/40663) @[guo-shaoge](https://github.com/guo-shaoge) + - 修复当同一个 SQL 中出现多个不同的分区表时，TiDB 可能执行得到错误结果的问题 [#42135](https://github.com/pingcap/tidb/issues/42135) @[mjonss](https://github.com/mjonss) + - 修复在开启 Prepared Plan Cache 的情况下，索引全表扫可能会报错的问题 [#42150](https://github.com/pingcap/tidb/issues/42150) @[fzzf678](https://github.com/fzzf678) + - 修复在开启 Prepared Plan Cache 时 Index Merge 可能得到错误结果的问题 [#41828](https://github.com/pingcap/tidb/issues/41828) @[qw4990](https://github.com/qw4990) + - 修复了设置 `max_prepared_stmt_count` 不生效的问题 [#39735](https://github.com/pingcap/tidb/issues/39735) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) + - 修复全局内存控制可能错误地 Kill 内存使用量小于 `tidb_server_memory_limit_sess_min_size` 的 SQL 的问题 [#42662](https://github.com/pingcap/tidb/issues/41828) @[XuHuaiyu](https://github.com/XuHuaiyu) + - 修复分区表动态裁剪模式下 Index Join 可能导致 panic 的问题 [#40596](https://github.com/pingcap/tidb/issues/40596) @[tiancaiamao](https://github.com/tiancaiamao) + ++ TiKV + + - 修复 TiKV 解析 cgroup path 没有正确解析 `:` 符号的问题 [#14538](https://github.com/tikv/tikv/issues/14538) @[SpadeA-Tang](https://github.com/SpadeA-Tang) + ++ PD + + - 修复 PD 可能会非预期地向 Region 添加多个 Learner 的问题 [#5786](https://github.com/tikv/pd/issues/5786) @[HunDunDM](https://github.com/HunDunDM) + - 修复了切换 Placement Rule 时可能存在的 leader 分布不均衡的问题 [#6195](https://github.com/tikv/pd/issues/6195) @[bufferflies](https://github.com/bufferflies) + ++ TiFlash + + - 修复 TiFlash 无法识别生成列的问题 [#6801](https://github.com/pingcap/tiflash/issues/6801) @[guo-shaoge](https://github.com/guo-shaoge) + - 修复了 Decimal 除法在某些情况下最后一位未进位的问题 [#7022](https://github.com/pingcap/tiflash/issues/7022) @[LittleFall](https://github.com/LittleFall) + - 修复了 Decimal 转换在某些情况下进位错误的问题 [#6994](https://github.com/pingcap/tiflash/issues/6994) @[windtalker](https://github.com/windtalker) + - 修复了开启 new collation 后 TopN/Sort 算子结果可能出错的问题 [#6807](https://github.com/pingcap/tiflash/issues/6807) @[xzhangxian1008](https://github.com/xzhangxian1008) + - 修复由于不兼容 TiCDC 导致 TiFlash 进程失败的问题 [#7212](https://github.com/pingcap/tiflash/issues/7212) @[hongyunyan](https://github.com/hongyunyan) + ++ Tools + + + Backup & Restore (BR) + + - 修复当 TiDB 集群不存在 PITR 备份任务时，`resolve lock` 频率过高的问题 [#40759](https://github.com/pingcap/tidb/issues/40759) @[joccau](https://github.com/joccau) + - 修复了在 PITR 恢复过程中等待 split Region 重试的时间不足的问题 [#42001](https://github.com/pingcap/tidb/issues/42001) @[joccau](https://github.com/joccau) + + + TiCDC + + - 修复同步到对象存储时，partition 分隔符不生效问题 [#8581](https://github.com/pingcap/tiflow/issues/8581) @[CharlesCheung96](https://github.com/CharlesCheung96) @[hi-rustin](https://github.com/hi-rustin) + - 修复同步到对象存储时，表调度可能导致数据丢失的问题 [#8256](https://github.com/pingcap/tiflow/issues/8256) @[zhaoxinyu](https://github.com/zhaoxinyu) + - 修复不可重入的 DDL 导致同步卡住的问题 [#8662](https://github.com/pingcap/tiflow/issues/8662) @[hicqu](https://github.com/hicqu) + - 修复同步到对象存储时，TiCDC 扩缩容可能导致数据丢失的问题 [#8666](https://github.com/pingcap/tiflow/issues/8666) @[CharlesCheung96](https://github.com/CharlesCheung96) + - 修复在部分场景中 `cgroup` 的内存限制不生效问题 [#8588](https://github.com/pingcap/tiflow/issues/8588) @[amyangfei](https://github.com/amyangfei) + - 修复 Redo log 在 apply 时，特殊情况下出现数据丢失的问题 [#8591](https://github.com/pingcap/tiflow/issues/8591) @[CharlesCheung96](https://github.com/CharlesCheung96) + - 修复 `db sorter` 使用内存时未受 `cgroup memory limit` 限制的问题 [#8588](https://github.com/pingcap/tiflow/issues/8588) @[amyangfei](https://github.com/amyangfei) + - 修复同步数据时由于 `UPDATE` 和 `INSERT` 语句乱序可能导致 `Duplicate entry` 错误的问题 [#8597](https://github.com/pingcap/tiflow/issues/8597) @[sdojjy](https://github.com/sdojjy) + - 修复由于 PD 和 TiCDC 之间的网络隔离引起 TiCDC 程序异常退出的问题 [#8562](https://github.com/pingcap/tiflow/issues/8562) @[overvenus](https://github.com/overvenus) + - 修复了 Kubernetes 上不能平滑升级 (graceful upgrade) TiCDC 集群的问题 [#8484](https://github.com/pingcap/tiflow/issues/8484) @[overvenus](https://github.com/overvenus) + - 修复了当所有 Kafka server 不可访问时会导致 TiCDC server panic 的问题 [#8523](https://github.com/pingcap/tiflow/issues/8523) @[3AceShowHand](https://github.com/3AceShowHand) + - 修复了重启 changefeed 可能导致数据丢失或者 checkpoint 无法推进的问题 [#8242](https://github.com/pingcap/tiflow/issues/8242) @[overvenus](https://github.com/overvenus) diff --git a/releases/release-6.5.3.md b/releases/release-6.5.3.md new file mode 100644 index 000000000000..e72488a16d28 --- /dev/null +++ b/releases/release-6.5.3.md @@ -0,0 +1,135 @@ +--- +title: TiDB 6.5.3 Release Notes +summary: 了解 TiDB 6.5.3 版本的兼容性变更、改进提升，以及错误修复。 +--- + +# TiDB 6.5.3 Release Notes + +发版日期：2023 年 6 月 14 日 + +TiDB 版本：6.5.3 + +试用链接：[快速体验](https://docs.pingcap.com/zh/tidb/v6.5/quick-start-with-tidb) | [生产部署](https://docs.pingcap.com/zh/tidb/v6.5/production-deployment-using-tiup) | [下载离线包](https://cn.pingcap.com/product-community/?version=v6.5.3#version-list) + +## 改进提升 + ++ TiDB + + - 提升了对带有 Placement Rules 的分区表的 `TRUNCATE` 操作速度 [#43070](https://github.com/pingcap/tidb/issues/43070) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - 在 resolve lock 之后避免无效的 Stale Read 重试 [#43659](https://github.com/pingcap/tidb/issues/43659) @[you06](https://github.com/you06) + - 在 Stale Read 遇到 `DataIsNotReady` 报错时使用 leader read 来降低延迟 [#765](https://github.com/tikv/client-go/pull/765) @[Tema](https://github.com/Tema) + - 为 Stale Read 增加 `Stale Read OPS` 和 `Stale Read MBps` 指标，用于监控命中率和流量 [#43325](https://github.com/pingcap/tidb/issues/43325) @[you06](https://github.com/you06) + ++ TiKV + + - 使用 gzip 压缩 `check_leader` 请求以减少流量 [#14839](https://github.com/tikv/tikv/issues/14839) @[cfzjywxk](https://github.com/cfzjywxk) + ++ PD + + - PD Leader 选举使用单独的 gRPC 链接，防止受到其他请求的影响 [#6403](https://github.com/tikv/pd/issues/6403) @[rleungx](https://github.com/rleungx) + ++ Tools + + + TiCDC + + - 优化 TiCDC 对 DDL 的处理方式，使 DDL 不阻塞其他无关的 DML Event 的使用，同时减少内存使用 [#8106](https://github.com/pingcap/tiflow/issues/8106) @[asddongmen](https://github.com/asddongmen) + - 调整 Decoder 接口，增加了新方法 `AddKeyValue` [#8861](https://github.com/pingcap/tiflow/issues/8861) @[3AceShowHand](https://github.com/3AceShowHand) + - 优化同步数据到对象存储的场景下发生 DDL 事件时的目录结构 [#8890](https://github.com/pingcap/tiflow/issues/8890) @[CharlesCheung96](https://github.com/CharlesCheung96) + - 支持同步到 Kafka-on-Pulsar 下游 [#8892](https://github.com/pingcap/tiflow/issues/8892) @[hi-rustin](https://github.com/hi-rustin) + - 当同步数据到 Kafka 时，支持 OAuth 协议验证方式 [#8865](https://github.com/pingcap/tiflow/issues/8865) @[hi-rustin](https://github.com/hi-rustin) + - 优化采用 Avro 或 CSV 协议同步数据时 TiCDC 对 `UPDATE` 语句的处理方式，即将其拆分为 `DELETE` 和 `INSERT` 语句，这样用户从 `DELETE` 语句中即可获取修改前的 old value [#9086](https://github.com/pingcap/tiflow/issues/9086) @[3AceShowHand](https://github.com/3AceShowHand) + - 增加一个配置项 `insecure-skip-verify`，控制在同步数据到 Kafka 的场景下启用 TLS 时是否设置认证算法 [#8867](https://github.com/pingcap/tiflow/issues/8867) @[hi-rustin](https://github.com/hi-rustin) + - TiCDC 优化 DDL 同步操作，减轻 DDL 操作对下游延迟的影响 [#8686](https://github.com/pingcap/tiflow/issues/8686) @[hi-rustin](https://github.com/hi-rustin) + - 优化 TiCDC 在同步任务失败时对上游 GC TLS 的设置方法 [#8403](https://github.com/pingcap/tiflow/issues/8403) @[charleszheng44](https://github.com/charleszheng44) + + + TiDB Lightning + + - 在导入数据期间遇到 `unknown RPC` 错误时，增加了重试机制 [#43291](https://github.com/pingcap/tidb/issues/43291) @[D3Hunter](https://github.com/D3Hunter) + + + TiDB Binlog + + - 优化表信息的获取方式，降低 Drainer 的初始化时间和内存占用 [#1137](https://github.com/pingcap/tidb-binlog/issues/1137) @[lichunzhu](https://github.com/lichunzhu) + +## 错误修复 + ++ TiDB + + - 修复 `min, max` 查询结果出错的问题 [#43805](https://github.com/pingcap/tidb/issues/43805) @[wshwsh12](https://github.com/wshwsh12) + - 修复窗口函数计算下推到 TiFlash 时执行计划构造错误的问题 [#43922](https://github.com/pingcap/tidb/issues/43922) @[gengliqi](https://github.com/gengliqi) + - 修复使用 CTE 的查询导致 TiDB 卡住的问题 [#43749](https://github.com/pingcap/tidb/issues/43749) [#36896](https://github.com/pingcap/tidb/issues/36896) @[guo-shaoge](https://github.com/guo-shaoge) + - 修复在使用 `AES_DECRYPT` 表达式时，SQL 报错 `runtime error: index out of range` 的问题 [#43063](https://github.com/pingcap/tidb/issues/43063) @[lcwangchao](https://github.com/lcwangchao) + - 修复 `SHOW PROCESSLIST` 语句无法显示子查询时间较长语句的事务的 TxnStart 的问题 [#40851](https://github.com/pingcap/tidb/issues/40851) @[crazycs520](https://github.com/crazycs520) + - 修复 PD 隔离可能会导致运行的 DDL 阻塞的问题 [#44014](https://github.com/pingcap/tidb/issues/44014) [#43755](https://github.com/pingcap/tidb/issues/43755) [#44267](https://github.com/pingcap/tidb/issues/44267) @[wjhuang2016](https://github.com/wjhuang2016) + - 修复使用 `UNION` 查询联合视图和临时表时 TiDB panic 的问题 [#42563](https://github.com/pingcap/tidb/issues/42563) @[lcwangchao](https://github.com/lcwangchao) + - 修复 Placement Rule 在分区表下的行为问题，使得删除的分区 Placement Rule 可以被正确设置并回收 [#44116](https://github.com/pingcap/tidb/issues/44116) @[lcwangchao](https://github.com/lcwangchao) + - 修复在 TRUNCATE 分区表的某个分区时可能造成分区的 Placement Rule 失效的问题 [#44031](https://github.com/pingcap/tidb/issues/44031) @[lcwangchao](https://github.com/lcwangchao) + - 修复在重命名表期间 TiCDC 可能丢失部分行变更的问题 [#43338](https://github.com/pingcap/tidb/issues/43338) @[tangenta](https://github.com/tangenta) + - 修复使用 BR 导入表后 DDL 作业历史记录丢失的问题 [#43725](https://github.com/pingcap/tidb/issues/43725) @[tangenta](https://github.com/tangenta) + - 修复了 `JSON_OBJECT` 在某些情况下会报错的问题 [#39806](https://github.com/pingcap/tidb/issues/39806) @[YangKeao](https://github.com/YangKeao) + - 修复 IPv6 环境下的集群无法查询部分系统视图的问题 [#43286](https://github.com/pingcap/tidb/issues/43286) @[Defined2014](https://github.com/Defined2014) @[nexustar](https://github.com/nexustar) + - 修复当 PD 成员地址发生变化时，为 `AUTO_INCREMENT` 列分配 ID 会被长时间阻塞的问题 [#42643](https://github.com/pingcap/tidb/issues/42643) @[tiancaiamao](https://github.com/tiancaiamao) + - 修复回收放置规则时，TiDB 向 PD 发送重复请求造成 PD 日志中出现大量 `full config reset` 的问题 [#33069](https://github.com/pingcap/tidb/issues/33069) @[tiancaiamao](https://github.com/tiancaiamao) + - 修复了 `SHOW PRIVILEGES` 命令显示的权限列表不完整的问题 [#40591](https://github.com/pingcap/tidb/issues/40591) @[CbcWestwolf](https://github.com/CbcWestwolf) + - 修复 `ADMIN SHOW DDL JOBS LIMIT` 返回错误结果的问题 [#42298](https://github.com/pingcap/tidb/issues/42298) @[CbcWestwolf](https://github.com/CbcWestwolf) + - 修复在开启密码强度校验时对 `tidb_auth_token` 用户进行校验导致用户创建失败的问题 [#44098](https://github.com/pingcap/tidb/issues/44098) @[CbcWestwolf](https://github.com/CbcWestwolf) + - 修复动态裁剪模式下内连接表时找不到分区的问题 [#43686](https://github.com/pingcap/tidb/issues/43686) @[mjonss](https://github.com/mjonss) + - 修复在分区表上执行 `MODIFY COLUMN` 时输出 `Data Truncated` 相关报错的问题 [#41118](https://github.com/pingcap/tidb/issues/41118) @[mjonss](https://github.com/mjonss) + - 修复 IPv6 环境下显示错误的 TiDB 地址的问题 [#43260](https://github.com/pingcap/tidb/issues/43260) @[nexustar](https://github.com/nexustar) + - 修复在谓词下推的情况下 CTE 结果错误的问题 [#43645](https://github.com/pingcap/tidb/issues/43645) @[winoros](https://github.com/winoros) + - 修复在带有非关联子查询的语句中使用公共表表达式 (CTE) 可能导致结果错误的问题 [#44051](https://github.com/pingcap/tidb/issues/44051) @[winoros](https://github.com/winoros) + - 修复 Join Reorder 可能会造成 Outer Join 结果错误的问题 [#44314](https://github.com/pingcap/tidb/issues/44314) @[AilinKid](https://github.com/AilinKid) + - 修复在一些极端情况下，悲观事务的第一条语句发生重试时，对该事务进行 resolve lock 可能影响事务正确性的问题 [#42937](https://github.com/pingcap/tidb/issues/42937) @[MyonKeminta](https://github.com/MyonKeminta) + - 修复在一些罕见的情况下，悲观事务的残留悲观锁在 GC resolve lock 时可能影响数据正确性的问题 [#43243](https://github.com/pingcap/tidb/issues/43243) @[MyonKeminta](https://github.com/MyonKeminta) + - 修复了 `batch cop` 在执行过程中的 scan detail 信息不准确的问题 [#41582](https://github.com/pingcap/tidb/issues/41582) @[you06](https://github.com/you06) + - 修复在同时使用 Stale Read 和 `PREPARE` 语句时 TiDB 无法读取到数据更新的问题 [#43044](https://github.com/pingcap/tidb/issues/43044) @[you06](https://github.com/you06) + - 修复执行 `LOAD DATA` 语句可能误报 `assertion failed` 的问题 [#43849](https://github.com/pingcap/tidb/issues/43849) @[you06](https://github.com/you06) + - 修复使用 Stale Read 过程中，当 coprocessor 遇到 `region data not ready` 情况时无法 fallback 到 leader 的问题 [#43365](https://github.com/pingcap/tidb/issues/43365) @[you06](https://github.com/you06) + ++ TiKV + + - 修复 Continuous Profiling 中的文件句柄泄露的问题 [#14224](https://github.com/tikv/tikv/issues/14224) @[tabokie](https://github.com/tabokie) + - 修复 PD 宕机可能造成 PITR 无法推进的问题 [#14184](https://github.com/tikv/tikv/issues/14184) @[YuJuncen](https://github.com/YuJuncen) + - 修复加密 Key ID 冲突会导致旧 Key 被删除的问题 [#14585](https://github.com/tikv/tikv/issues/14585) @[tabokie](https://github.com/tabokie) + - 修复 autocommit 和 point get replica read 可能破坏线性一致性的问题 [#14715](https://github.com/tikv/tikv/issues/14715) @[cfzjywxk](https://github.com/cfzjywxk) + - 修复集群从较低版本升级到 v6.5 或更高版本时，由于累计的 Lock 记录可能导致性能下降到问题 [#14780](https://github.com/tikv/tikv/issues/14780) @[MyonKeminta](https://github.com/MyonKeminta) + - 修复 TiDB Lightning 可能导致 SST 文件泄露的问题 [#14745](https://github.com/tikv/tikv/issues/14745) @[YuJuncen](https://github.com/YuJuncen) + - 修复加密密钥和 raft log 文件删除之间的潜在冲突导致 TiKV 无法启动的问题 [#14761](https://github.com/tikv/tikv/issues/14761) @[Connor1996](https://github.com/Connor1996) + ++ TiFlash + + - 修复分区表 TableScan 算子在 Region 迁移时性能劣化的问题 [#7519](https://github.com/pingcap/tiflash/issues/7519) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - 修复在 GENERATED 类型表字段与 TIMESTAMP 或 TIME 类型同时存在的情况下，查询 TiFlash 可能会报错的问题 [#7468](https://github.com/pingcap/tiflash/issues/7468) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - 修复大的更新事务可能会导致 TiFlash 反复报错重启的问题 [#7316](https://github.com/pingcap/tiflash/issues/7316) @[JaySon-Huang](https://github.com/JaySon-Huang) + - 修复 `INSERT SELECT` 语句从 TiFlash 读取数据时报错 "Truncate error cast decimal as decimal" 的问题 [#7348](https://github.com/pingcap/tiflash/issues/7348) @[windtalker](https://github.com/windtalker) + - 修复查询在 Join build 侧数据非常大，且包含许多小型字符串类型列时，消耗的内存可能会超过实际需要的问题 [#7416](https://github.com/pingcap/tiflash/issues/7416) @[yibin87](https://github.com/yibin87) + ++ Tools + + + Backup & Restore (BR) + + - 修复备份失败时 BR 的报错信息 "resolve lock timeout" 具有误导性，掩盖了实际错误的问题 [#43236](https://github.com/pingcap/tidb/issues/43236) @[YuJuncen](https://github.com/YuJuncen) + + + TiCDC + + - 修复在表数量多达 50000 个时可能出现 OOM 的问题 [#7872](https://github.com/pingcap/tiflow/issues/7872) @[sdojjy](https://github.com/sdojjy) + - 修复 TiCDC 在上游 TiDB 发生 OOM 时卡住的问题 [#8561](https://github.com/pingcap/tiflow/issues/8561) @[overvenus](https://github.com/overvenus) + - 修复 PD 出现网络隔离或 PD Owner 节点重启等故障时 TiCDC 卡住问题 [#8808](https://github.com/pingcap/tiflow/issues/8808) [#8812](https://github.com/pingcap/tiflow/issues/8812) [#8877](https://github.com/pingcap/tiflow/issues/8877) @[asddongmen](https://github.com/asddongmen) + - 修复 TiCDC 的时区设置问题 [#8798](https://github.com/pingcap/tiflow/issues/8798) @[hi-rustin](https://github.com/hi-rustin) + - 修复上游 TiKV 节点 crash 时 checkpoint lag 上升的问题 [#8858](https://github.com/pingcap/tiflow/issues/8858) @[hicqu](https://github.com/hicqu) + - 修复在同步数据到下游 MySQL 的场景中，当上游 TiDB 执行 `FLASHBACK CLUSTER TO TIMESTAMP` 语句后同步出错的问题 [#8040](https://github.com/pingcap/tiflow/issues/8040) @[asddongmen](https://github.com/asddongmen) + - 修复当同步数据到对象存储时上游的 `EXCHANGE PARTITION` 操作没有正常同步到下游的问题 [#8914](https://github.com/pingcap/tiflow/issues/8914) @[CharlesCheung96](https://github.com/CharlesCheung96) + - 修复在某些特殊场景下 sorter 组件内存使用过多导致 OOM 的问题 [#8974](https://github.com/pingcap/tiflow/issues/8974) @[hicqu](https://github.com/hicqu) + - 修复当下游为 Kafka 时，TiCDC 查询下游的元信息频率过高导致下游负载过大的问题 [#8957](https://github.com/pingcap/tiflow/issues/8957) [#8959](https://github.com/pingcap/tiflow/issues/8959) @[hi-rustin](https://github.com/hi-rustin) + - 修复当 Kafka 消息过大导致同步出错时，在 Log 中记录了消息体的问题 [#9031](https://github.com/pingcap/tiflow/issues/9031) @[darraes](https://github.com/darraes) + - 修复下游 Kafka 滚动重启时 TiCDC 节点发生 panic 的问题 [#9023](https://github.com/pingcap/tiflow/issues/9023) @[asddongmen](https://github.com/asddongmen) + - 修复同步数据到存储服务时，下游 DDL 语句对应的 JSON 文件中没有记录表中字段默认值的问题 [#9066](https://github.com/pingcap/tiflow/issues/9066) @[CharlesCheung96](https://github.com/CharlesCheung96) + + + TiDB Lightning + + - 修复宽表导入时可能出现 OOM 的问题 [#43728](https://github.com/pingcap/tidb/issues/43728) @[D3Hunter](https://github.com/D3Hunter) + - 修复大数据量导入时报 `write to tikv with no leader returned` 错误的问题 [#43055](https://github.com/pingcap/tidb/issues/43055) @[lance6716](https://github.com/lance6716) + - 修复当数据文件中存在未闭合的 delimiter 时可能 OOM 的问题 [#40400](https://github.com/pingcap/tidb/issues/40400) @[buchuitoudegou](https://github.com/buchuitoudegou) @[lance6716](https://github.com/lance6716) + + + TiDB Binlog + + - 修复遇到状态为 `CANCELED` 的 DDL 时 TiDB Binlog 报错的问题 [#1228](https://github.com/pingcap/tidb-binlog/issues/1228) @[okJiang](https://github.com/okJiang) diff --git a/releases/release-6.6.0.md b/releases/release-6.6.0.md index 73cdace55276..91f7f85c2970 100644 --- a/releases/release-6.6.0.md +++ b/releases/release-6.6.0.md @@ -9,6 +9,10 @@ summary: 了解 TiDB 6.6.0 版本的新功能、兼容性变更、改进提升 TiDB 版本：6.6.0-[DMR](/releases/versioning.md#开发里程碑版本) +> **注意：** +> +> TiDB 6.6.0-DMR 的用户文档已[归档](https://docs-archive.pingcap.com/zh/tidb/v6.6)。如无特殊需求，建议使用 TiDB 数据库的[最新 LTS 版本](https://docs.pingcap.com/zh/tidb/stable)。 + 试用链接：[快速体验](https://docs.pingcap.com/zh/tidb/v6.6/quick-start-with-tidb) | [下载离线包](https://cn.pingcap.com/product-community/?version=v6.6.0-DMR#version-list) 在 6.6.0 版本中，你可以获得以下关键特性： @@ -56,7 +60,7 @@ TiDB 版本：6.6.0-[DMR](/releases/versioning.md#开发里程碑版本) - +
数据库管理与可观测性
 DM 集成物理导入模式（实验特性）TiDB Data Migration (DM) 集成 TiDB Lightning 的 Physical Import 模式，提升 DM 全量数据迁移时的性能，大数据量场景下的迁移时间最多可提升 10 倍。TiDB Data Migration (DM) 集成 TiDB Lightning 的物理导入模式模式，提升 DM 全量数据迁移时的性能，大数据量场景下的迁移时间最多可提升 10 倍。
@@ -75,7 +79,7 @@ TiDB 版本：6.6.0-[DMR](/releases/versioning.md#开发里程碑版本) * 支持 DDL 分布式并行执行框架（实验特性）[#37125](https://github.com/pingcap/tidb/issues/37125) @[zimulala](https://github.com/zimulala) - 在过去的版本中，整个 TiDB 集群中仅允许一个 TiDB 实例作为 DDL Owner 处理 Schema 变更任务。为了进一步提升 DDL 的并发性，TiDB v6.6.0 版本引入了 DDL 分布式并行执行框架，支持集群中所有的 TiDB 实例并发执行同一个任务的 `StateWriteReorganization` 阶段，加速 DDL 的执行。该功能由系统变量 [`tidb_ddl_distribute_reorg`](/system-variables.md#tidb_ddl_distribute_reorg-从-v660-版本开始引入) 控制是否开启，目前只支持 `Add Index` 操作。 + 在过去的版本中，整个 TiDB 集群中仅允许一个 TiDB 实例作为 DDL Owner 处理 Schema 变更任务。为了进一步提升 DDL 的并发性，TiDB v6.6.0 版本引入了 DDL 分布式并行执行框架，支持集群中所有的 TiDB 实例并发执行同一个任务的 `StateWriteReorganization` 阶段，加速 DDL 的执行。该功能由系统变量 [`tidb_ddl_distribute_reorg`](https://docs.pingcap.com/zh/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-从-v660-版本开始引入) 控制是否开启，目前只支持 `Add Index` 操作。 ### 性能 @@ -93,7 +97,7 @@ TiDB 版本：6.6.0-[DMR](/releases/versioning.md#开发里程碑版本) * 解除执行计划缓存对 `LIMIT` 子句的限制 [#40219](https://github.com/pingcap/tidb/issues/40219) @[fzzf678](https://github.com/fzzf678) - TiDB v6.6.0 移除了执行计划缓存的限制，带有变量的 `LIMIT` 子句可以进入执行计划缓存，如 `LIMIT ?` 或者 `LIMIT 10, ?`。这使得更多的 SQL 能够从计划缓存中获益，提升执行效率。 + TiDB v6.6.0 移除了执行计划缓存的限制，带有变量的 `LIMIT` 子句可以进入执行计划缓存，如 `LIMIT ?` 或者 `LIMIT 10, ?`。这使得更多的 SQL 能够从计划缓存中获益，提升执行效率。目前出于安全考虑，仅支持缓存 `?` 参数值不大于 10000 的执行计划。 更多信息，请参考[用户文档](/sql-prepared-plan-cache.md)。 @@ -147,7 +151,7 @@ TiDB 版本：6.6.0-[DMR](/releases/versioning.md#开发里程碑版本) * 支持 DDL 动态资源管控（实验特性）[#38025](https://github.com/pingcap/tidb/issues/38025) @[hawkingrei](https://github.com/hawkingrei) - TiDB v6.6.0 版本引入了 DDL 动态资源管控，通过自动控制 DDL 的 CPU 使用量，尽量降低 DDL 变更任务对线上业务的影响。该功能仅在开启 [DDL 分布式并行执行框架](/system-variables.md#tidb_ddl_distribute_reorg-从-v660-版本开始引入)后生效。 + TiDB v6.6.0 版本引入了 DDL 动态资源管控，通过自动控制 DDL 的 CPU 使用量，尽量降低 DDL 变更任务对线上业务的影响。该功能仅在开启 [DDL 分布式并行执行框架](https://docs.pingcap.com/zh/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-从-v660-版本开始引入)后生效。 ### 高可用 @@ -202,9 +206,9 @@ TiDB 版本：6.6.0-[DMR](/releases/versioning.md#开发里程碑版本) 更多信息，请参考[用户文档](/tidb-configuration-file.md#initialize-sql-file-从-v660-版本开始引入)。 -- TiDB Data Migration (DM) 集成了 TiDB Lightning 的 Physical Import Mode（实验特性）@[lance6716](https://github.com/lance6716) +- TiDB Data Migration (DM) 集成了 TiDB Lightning 的物理导入模式（实验特性）@[lance6716](https://github.com/lance6716) - 在 v6.6.0 版本中，DM 的全量迁移能力集成了 TiDB Lightning 的 Physical Import Mode，使得 DM 全量数据迁移的性能最高可提升 10 倍，大大缩短了大数据量场景下的迁移时间。在 v6.6.0 以前，数据量较多的场景下，需要单独配置 TiDB Lightning 的 Physical Import Mode 任务来进行快速的全量数据迁移，再用 DM 来进行增量数据迁移，配置较为复杂。从 v6.6.0 起，在迁移大数据量的场景，无需再配置 TiDB Lightning 的任务，使用一个 DM 任务即可完成。 + 在 v6.6.0 版本中，DM 的全量迁移能力集成了 TiDB Lightning 的物理导入模式，使得 DM 全量数据迁移的性能最高可提升 10 倍，大大缩短了大数据量场景下的迁移时间。在 v6.6.0 以前，数据量较多的场景下，需要单独配置 TiDB Lightning 的物理导入模式任务来进行快速的全量数据迁移，再用 DM 来进行增量数据迁移，配置较为复杂。从 v6.6.0 起，在迁移大数据量的场景，无需再配置 TiDB Lightning 的任务，使用一个 DM 任务即可完成。 更多信息，请参考[用户文档](/dm/dm-precheck.md#physical-import-检查项)。 @@ -344,16 +348,16 @@ TiDB 版本：6.6.0-[DMR](/releases/versioning.md#开发里程碑版本) | `tidb_ttl_job_run_interval` | 删除 | 这个变量用于控制 TTL 后台清理任务的调度周期。自 v6.6.0 起删除该变量，因为自 v6.6.0 起 TiDB 为每张表提供了属性 `TTL_JOB_INTERVAL` 用于配置 TTL 运行的间隔，允许用户为每张表设置不同的运行间隔，比系统变量更加灵活。 | | [`foreign_key_checks`](/system-variables.md#foreign_key_checks) | 修改 | 用于控制是否开启外键约束检查。默认值由 `OFF` 修改为 `ON`，表示默认开启外键检查。| | [`tidb_enable_foreign_key`](/system-variables.md#tidb_enable_foreign_key-从-v630-版本开始引入) | 修改 | 用于控制是否开启外键功能。默认值由 `OFF` 修改为 `ON`，表示默认开启外键功能。| -| `tidb_enable_general_plan_cache` | 修改 | 这个变量用来控制是否开启 General Plan Cache。自 v6.6.0 起，该变量更名为 [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache)。 | +| `tidb_enable_general_plan_cache` | 修改 | 这个变量用来控制是否开启 General Plan Cache。自 v6.6.0 起，该变量更名为 [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache)。 | | [`tidb_enable_historical_stats`](/system-variables.md#tidb_enable_historical_stats) | 修改 | 这个变量用来控制是否开启历史统计信息。默认值由 `OFF` 修改为 `ON`，表示默认开启历史统计信息。 | -| [`tidb_enable_telemetry`](/system-variables.md#tidb_enable_telemetry-从-v402-版本开始引入) | 修改 | 默认值由 `ON` 修改为 `OFF`，表示默认关闭 TiDB 的遥测功能。 | -| `tidb_general_plan_cache_size` | 修改 | 这个变量用来控制 General Plan Cache 最多能够缓存的计划数量。自 v6.6.0 起，该变量更名为 [`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size)。 | +| [`tidb_enable_telemetry`](/system-variables.md#tidb_enable_telemetry-从-v402-版本开始引入) | 修改 | 默认值由 `ON` 修改为 `OFF`，表示默认关闭 TiDB 的遥测功能。 | +| `tidb_general_plan_cache_size` | 修改 | 这个变量用来控制 General Plan Cache 最多能够缓存的计划数量。自 v6.6.0 起，该变量更名为 [`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size)。 | | [`tidb_replica_read`](/system-variables.md#tidb_replica_read-从-v40-版本开始引入) | 修改 | 新增选项 `learner`，指定 TiDB 从只读节点中读取数据的 learner 副本。 | | [`tidb_replica_read`](/system-variables.md#tidb_replica_read-从-v40-版本开始引入) | 修改 | 新增选项 `prefer-leader`，以提高 TiDB 集群整体的读可用性。该选项被启用时，TiDB 会优先选择 Leader 副本进行读取操作；当 Leader 副本的处理性能显著下降时，TiDB 会自动将读操作转发给 Follower 副本。| | [`tidb_store_batch_size`](/system-variables.md#tidb_store_batch_size) | 修改 | 该变量设置 `IndexLookUp` 算子回表时多个 Coprocessor Task 的 batch 大小。`0` 代表不使用 batch。自 v6.6.0 起，默认值由 `0` 调整为 `4`，即每批请求会有 4 个 Coprocessor Task 被 batch 到一个 task 中。 | -| [`mpp_exchange_compression_mode`](/system-variables.md#mpp_exchange_compression_mode-从-v660-版本开始引入) | 新增 | 该变量用于选择 MPP Exchange 算子的数据压缩模式，当 TiDB 选择版本号为 `1` 的 MPP 执行计划时生效。默认值为 `UNSPECIFIED`，表示 TiDB 自动选择 `FAST` 压缩模式。| -| [`mpp_version`](/system-variables.md#mpp_version-从-v660-版本开始引入) | 新增 | 该变量用于指定不同版本的 MPP 执行计划。指定后，TiDB 会选择指定版本的 MPP 执行计划。默认值为 `UNSPECIFIED`，表示 TiDB 自动选择最新版本 `1`。 | -| [`tidb_ddl_distribute_reorg`](/system-variables.md#tidb_ddl_distribute_reorg-从-v660-版本开始引入) | 新增 | 这个变量用来控制是否开启分布式执行 DDL reorg 阶段，来提升此阶段的速度。默认值为 `OFF`，表示默认不开启分布式执行 DDL reorg 阶段。目前此开关只对 `ADD INDEX` 语句有效。| +| [`mpp_exchange_compression_mode`](/system-variables.md#mpp_exchange_compression_mode-从-v660-版本开始引入) | 新增 | 该变量用于选择 MPP Exchange 算子的数据压缩模式，当 TiDB 选择版本号为 `1` 的 MPP 执行计划时生效。默认值为 `UNSPECIFIED`，表示 TiDB 自动选择 `FAST` 压缩模式。| +| [`mpp_version`](/system-variables.md#mpp_version-从-v660-版本开始引入) | 新增 | 该变量用于指定不同版本的 MPP 执行计划。指定后，TiDB 会选择指定版本的 MPP 执行计划。默认值为 `UNSPECIFIED`，表示 TiDB 自动选择最新版本 `1`。 | +| [`tidb_ddl_distribute_reorg`](https://docs.pingcap.com/zh/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-从-v660-版本开始引入) | 新增 | 这个变量用来控制是否开启分布式执行 DDL reorg 阶段，来提升此阶段的速度。默认值为 `OFF`，表示默认不开启分布式执行 DDL reorg 阶段。目前此开关只对 `ADD INDEX` 语句有效。| | [`tidb_enable_historical_stats_for_capture`](/system-variables.md#tidb_enable_historical_stats_for_capture) | 新增 | 这个变量用来控制 `PLAN REPLAYER CAPTURE` 抓取的内容是否默认带历史统计信息。默认值为 `OFF`，表示默认不带历史统计信息。 | | [`tidb_enable_plan_cache_for_param_limit`](/system-variables.md#tidb_enable_plan_cache_for_param_limit-从-v660-版本开始引入) | 新增 | 这个变量用来控制 Prepared Plan Cache 是否缓存 `Limit` 后带有 `COUNT` 的执行计划。默认值为 `ON`，表示默认缓存这样的执行计划。目前不支持缓存 `Limit` 后面的 `COUNT` 具体参数值大于 10000 的执行计划。 | | [`tidb_enable_plan_replayer_capture`](/system-variables.md#tidb_enable_plan_replayer_capture) | 新增 | 这个变量用来控制是否开启 [`PLAN REPLAYER CAPTURE`](/sql-plan-replayer.md#使用-plan-replayer-capture-抓取目标计划)。默认值 `OFF`，代表默认关闭 `PLAN REPLAYER CAPTURE`。 | @@ -381,7 +385,7 @@ TiDB 版本：6.6.0-[DMR](/releases/versioning.md#开发里程碑版本) | PD | [`enable-telemetry`](/pd-configuration-file.md#enable-telemetry) | 修改 | 从 v6.6.0 起，该配置项的默认值由 `true` 改为 `false`，表示默认关闭 TiDB Dasboard 的遥测功能。 | | TiFlash | [`profile.default.max_memory_usage_for_all_queries`](/tiflash/tiflash-configuration.md#配置文件-tiflashtoml) | 修改 | 表示所有查询过程中，节点对中间数据的内存限制。自 v6.6.0 起默认值由 `0` 改为 `0.8`，表示节点占总内存的 80%。 | | TiCDC | [`consistent.storage`](/ticdc/ticdc-sink-to-mysql.md#使用前提) | 修改 | redo log 备份文件的地址，除了 NFS，支持的 `scheme` 新增了 GCS 和 Azure。 | -| DM | [`import-mode`](/dm/task-configuration-file-full.md) | 修改 | 该配置项的可选值由 `"sql"` 和 `"loader"` 变更为 `"logical"` 和 `"physical"`。默认值为 `"logical"`，即使用 TiDB Lightning 的 Logical Import Mode 进行导入。 | +| DM | [`import-mode`](/dm/task-configuration-file-full.md) | 修改 | 该配置项的可选值由 `"sql"` 和 `"loader"` 变更为 `"logical"` 和 `"physical"`。默认值为 `"logical"`，即使用 TiDB Lightning 的逻辑导入模式进行导入。 | | TiDB | [`initialize-sql-file`](/tidb-configuration-file.md#initialize-sql-file-从-v660-版本开始引入) | 新增 | 用于指定 TiDB 集群初次启动时执行的 SQL 脚本。默认值为空。 | | TiDB | [`tidb_stmt_summary_enable_persistent`](/tidb-configuration-file.md#tidb_stmt_summary_enable_persistent-从-v660-版本开始引入) | 新增 | 用于控制是否开启 statements summary 持久化。默认值为 `false`，即不开启该功能。 | | TiDB | [`tidb_stmt_summary_file_max_backups`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_backups-从-v660-版本开始引入) | 新增 | 当开启了 statements summary 持久化时，该配置用于限制持久化数据文件最大数量，默认值为 `0`，表示不限制文件数量。 | @@ -397,12 +401,12 @@ TiDB 版本：6.6.0-[DMR](/releases/versioning.md#开发里程碑版本) | PD | [`pd-server.server-memory-limit`](/pd-configuration-file.md#server-memory-limit-从-v660-版本开始引入) | 新增 | PD 实例的内存限制比例。`0` 表示不设内存限制。 | | PD | [`pd-server.server-memory-limit-gc-trigger`](/pd-configuration-file.md#server-memory-limit-gc-trigger-从-v660-版本开始引入) | 新增 | PD 尝试触发 GC 的阈值比例。默认值为 `0.7`。 | | TiCDC | [`scheduler.region-per-span`](/ticdc/ticdc-changefeed-config.md#ticdc-changefeed-配置文件说明) | 新增 | 该配置项用于将表按 Region 个数划分成多个同步范围，这些范围可由多个 TiCDC 节点同步，默认值为 `50000`。 | -| TiDB Lightning | [`compress-kv-pairs`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-任务配置) | 新增 | 该配置项控制 Physical Import Mode 向 TiKV 发送 KV 时是否启用压缩，默认值为空，表示不启用压缩。 | -| DM | [`checksum-physical`](/dm/task-configuration-file-full.md) | 新增 | 该配置项控制 Physical Import 在导入完成一张表后，对每一个表执行 `ADMIN CHECKSUM TABLE ` 进行数据校验。默认值为 `"required"`，表示导入完成后进行数据校验，如果校验失败会暂停任务，需要你手动处理。| +| TiDB Lightning | [`compress-kv-pairs`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-任务配置) | 新增 | 该配置项控制物理导入模式向 TiKV 发送 KV 时是否启用压缩，默认值为空，表示不启用压缩。 | +| DM | [`checksum-physical`](/dm/task-configuration-file-full.md) | 新增 | 该配置项控制物理导入模式在导入完成一张表后，对每一个表执行 `ADMIN CHECKSUM TABLE
` 进行数据校验。默认值为 `"required"`，表示导入完成后进行数据校验，如果校验失败会暂停任务，需要你手动处理。| | DM | [`disk-quota-physical`](/dm/task-configuration-file-full.md) | 新增 | 该配置项设置了磁盘的空间限制，对应 TiDB Lightning 的 [`disk-quota` 配置](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#磁盘资源配额-从-v620-版本开始引入)。| -| DM | [`on-duplicate-logical`](/dm/task-configuration-file-full.md) | 新增 | 该配置项控制 Logical Import 针对冲突数据的解决方式。默认值为 `"replace"`，表示用最新数据替代已有数据。 | -| DM | [`on-duplicate-physical`](/dm/task-configuration-file-full.md) | 新增 | 该配置项控制 Physical Import 针对冲突数据的解决方式。默认值为 `"none"`，表示遇到冲突数据时不进行处理。该模式性能最佳，但下游数据库会出现数据索引不一致的问题。 | -| DM | [`sorting-dir-physical`](/dm/task-configuration-file-full.md) | 新增 | 该配置项控制 Physical Import 用作本地排序的目录位置，该选项的默认值与 `dir` 配置项一致。 | +| DM | [`on-duplicate-logical`](/dm/task-configuration-file-full.md) | 新增 | 该配置项控制物理导入模式针对冲突数据的解决方式。默认值为 `"replace"`，表示用最新数据替代已有数据。 | +| DM | [`on-duplicate-physical`](/dm/task-configuration-file-full.md) | 新增 | 该配置项控制物理导入模式针对冲突数据的解决方式。默认值为 `"none"`，表示遇到冲突数据时不进行处理。该模式性能最佳，但下游数据库会出现数据索引不一致的问题。 | +| DM | [`sorting-dir-physical`](/dm/task-configuration-file-full.md) | 新增 | 该配置项控制物理导入模式用作本地排序的目录位置，该选项的默认值与 `dir` 配置项一致。 | | sync-diff-inspector | [`skip-non-existing-table`](/sync-diff-inspector/sync-diff-inspector-overview.md#配置文件说明) | 新增 | 当下游数据库的表在上游不存在时，该配置项决定是否跳过对上下游数据库表数量不一致场景的校验。 | | TiSpark | [`spark.tispark.replica_read`](/tispark-overview.md#tispark-配置) | 新增 | 控制读取副本的类型，可选值为 `leader`、`follower`、`learner`。 | | TiSpark | [`spark.tispark.replica_read.label`](/tispark-overview.md#tispark-配置) | 新增 | 设置目标 TiKV 节点的标签。 | @@ -476,7 +480,7 @@ TiDB 版本：6.6.0-[DMR](/releases/versioning.md#开发里程碑版本) + TiDB Lightning - - Physical Import Mode 支持 Keyspace [#40531](https://github.com/pingcap/tidb/issues/40531) @[iosmanthus](https://github.com/iosmanthus) + - 物理导入模式支持 Keyspace [#40531](https://github.com/pingcap/tidb/issues/40531) @[iosmanthus](https://github.com/iosmanthus) - 支持通过 `lightning.max-error` 设置最大冲突个数 [#40743](https://github.com/pingcap/tidb/issues/40743) @[dsdashun](https://github.com/dsdashun) - 支持导入带有 BOM header 的 CSV 数据文件 [#40744](https://github.com/pingcap/tidb/issues/40744) @[dsdashun](https://github.com/dsdashun) - 优化遇到 TiKV 限流错误时的处理逻辑，改为尝试其他空闲的 Region [#40205](https://github.com/pingcap/tidb/issues/40205) @[lance6716](https://github.com/lance6716) @@ -555,6 +559,7 @@ TiDB 版本：6.6.0-[DMR](/releases/versioning.md#开发里程碑版本) - 修复查询 TiFlash 相关的系统表可能会卡住的问题 [#6745](https://github.com/pingcap/tiflash/pull/6745) @[lidezhu](https://github.com/lidezhu) - 修复半连接在计算笛卡尔积时，使用内存过量的问题 [#6730](https://github.com/pingcap/tiflash/issues/6730) @[gengliqi](https://github.com/gengliqi) - 修复对 DECIMAL 数据类型进行除法运算时结果不舍入的问题 [#6393](https://github.com/pingcap/tiflash/issues/6393) @[LittleFall](https://github.com/LittleFall) + - 修复了 TiFlash 查询中由于 `start_ts` 无法唯一标识一个 MPP query 导致 MPP query 可能会被误取消的问题 [#43426](https://github.com/pingcap/tidb/issues/43426) @[hehechen](https://github.com/hehechen) + Tools diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md index 1fbea320138d..418cf915c52e 100644 --- a/releases/release-7.0.0.md +++ b/releases/release-7.0.0.md @@ -9,7 +9,7 @@ summary: 了解 TiDB 7.0.0 版本的新功能、兼容性变更、改进提升 TiDB 版本：7.0.0 -试用链接：[快速体验](https://docs.pingcap.com/zh/tidb/v7.0/quick-start-with-tidb) | [下载离线包](https://cn.pingcap.com/product-community/) +试用链接：[快速体验](https://docs.pingcap.com/zh/tidb/v7.0/quick-start-with-tidb) | [下载离线包](https://cn.pingcap.com/product-community/?version=v7.0.0-DMR#version-list) 在 7.0.0 版本中，你可以获得以下关键特性： @@ -56,8 +56,8 @@ TiDB 版本：7.0.0 - - + + @@ -150,7 +150,7 @@ TiDB 版本：7.0.0 TiDB 优化了基于资源组的资源管控特性。该特性将会极大地提升 TiDB 集群的资源利用效率和性能表现。资源管控特性的引入对 TiDB 具有里程碑的意义，你可以将一个分布式数据库集群划分成多个逻辑单元，将不同的数据库用户映射到对应的资源组中，并根据需要设置每个资源组的配额。当集群资源紧张时，来自同一个资源组的会话所使用的全部资源将被限制在配额内，避免其中一个资源组过度消耗，从而影响其他资源组中的会话正常运行。 - 该特性也可以将多个来自不同系统的中小型应用合入一个 TiDB 集群中，个别应用的负载提升，不会影响其他应用的正常运行。而在系统负载较低的时候，繁忙的应用即使超过设定的读写配额，也仍然可以被分配到所需的系统资源，达到资源的最大化利用。此外，合理利用资源管控特性可以减少集群数量，降低运维难度及管理成本。 + 该特性也可以将多个来自不同系统的中小型应用合入一个 TiDB 集群中，个别应用的负载提升，不会影响其他应用的正常运行。而在系统负载较低的时候，繁忙的应用即使超过设定的配额，也仍然可以被分配到所需的系统资源，达到资源的最大化利用。此外，合理利用资源管控特性可以减少集群数量，降低运维难度及管理成本。 该特性不仅提供了 Grafana 内置的 Resource Control Dashboard 展示资源的实际使用情况，协助你更合理地配置资源，还支持基于会话和语句级别（Hint）的动态资源管控能力。这些功能的引入将帮助你更精确地掌控 TiDB 集群的资源使用情况，并根据实际需要动态调整配额。 @@ -248,7 +248,7 @@ TiDB 版本：7.0.0 * [DBeaver](https://dbeaver.io/) v23.0.1 默认支持 TiDB [#17396](https://github.com/dbeaver/dbeaver/issues/17396) @[Icemap](https://github.com/Icemap) - 提供独立的 TiDB 模块、Icon 和标识。 - - 默认配置支持 [TiDB Cloud Serverless Tier](https://docs.pingcap.com/tidbcloud/select-cluster-tier#serverless-tier-beta)，你可以更方便地连接 Serverless Tier。 + - 默认配置支持 [TiDB Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-serverless-beta)，你可以更方便地连接 TiDB Serverless。 - 支持识别 TiDB 版本，从而显示或隐藏外键 Tab。 - 支持 Explain SQL 计划显示。 - 支持 TiDB 语法高亮，如 `PESSIMISTIC`、`OPTIMISTIC`、`AUTO_RANDOM`、`PLACEMENT`、`POLICY`、`REORGANIZE`、`EXCHANGE`、`CACHE`、`NONCLUSTERED`、`CLUSTERED` 等。 @@ -258,15 +258,13 @@ TiDB 版本：7.0.0 ### 数据迁移 -* `LOAD DATA` 语句集成 TiDB Lightning，你可以使用 `LOAD DATA` 语句完成原先需要使用 TiDB Lightning 才能完成的数据导入任务（实验特性）[#40499](https://github.com/pingcap/tidb/issues/40499) @[lance6716](https://github.com/lance6716) +* 增强 `LOAD DATA` 语句功能，支持导入云存储中的数据（实验特性）[#40499](https://github.com/pingcap/tidb/issues/40499) @[lance6716](https://github.com/lance6716) - 在集成 TiDB Lightning 之前，`LOAD DATA` 语句只能用于导入客户端的数据文件，如果你需要从云存储导入数据，不得不借助 TiDB Lightning 来实现。但是单独部署 TiDB Lightning 又会带来额外的部署成本和管理成本。将 TiDB Lightning 逻辑导入能力 (Logical Import Mode) 集成到 `LOAD DATA` 语句后，不仅可以省去 TiDB Lightning 的部署和管理成本，还可以借助 TiDB Lightning 的功能极大扩展 `LOAD DATA` 语句的能力。部分扩展的功能举例说明如下： + 之前，`LOAD DATA` 语句只能用于导入客户端的数据文件，如果你需要从云存储导入数据，不得不借助 TiDB Lightning 来实现。但是单独部署 TiDB Lightning 又会带来额外的部署成本和管理成本。现在可直接通过`LOAD DATA` 语句导入云存储中的数据。功能举例说明如下： - 支持从 Amazon S3 和 Google Cloud Storage 导入数据到 TiDB，且支持使用通配符一次性匹配多个源文件导入到 TiDB。 - 支持 `DEFINED NULL BY` 来定义 null。 - - 支持 CSV、TSV、Parquet、SQL (mydumper/dumpling) 格式的源文件。 - - 支持将任务设置为 `Detached`，让任务在后台执行。 - - 支持任务管理，可通过 `SHOW LOAD DATA jobid` 查询任务状态和进展详情，方便管理和维护。 + - 支持 CSV、TSV 格式的源文件。 更多信息，请参考[用户文档](/sql-statements/sql-statement-load-data.md)。 @@ -326,7 +324,7 @@ TiDB 版本：7.0.0 在升级 TiCDC 集群到 v7.0.0 时，如果使用 Avro 同步的表包含 `FLOAT` 类型数据，请在升级前手动调整 Confluent Schema Registry 的兼容性策略为 `None`，使 changefeed 能够成功更新 schema。否则，在升级之后 changefeed 将无法更新 schema 并进入错误状态。 -* [`LOAD DATA` SQL 语句](/sql-statements/sql-statement-load-data.md)在 v7.0.0 中新增参数 `batch_size` 来实现事务的拆分。`batch_size` 参数默认值为 `1000`，表示将待导入 TiDB 的数据拆分成多个事务提交，每一个事务插入 1000 行记录到 TiDB。在 v7.0.0 以前控制事务拆分的参数为 [`tidb_dml_batch_size`](/system-variables.md#tidb_dml_batch_size)，自 v7.0.0 起不再生效。 +* 自 v7.0.0 起，[`tidb_dml_batch_size`](/system-variables.md#tidb_dml_batch_size) 对 [`LOAD DATA` 语句](/sql-statements/sql-statement-load-data.md)不再生效。 ### 系统变量 @@ -372,13 +370,13 @@ TiDB 版本：7.0.0 | TiFlash | [`storage.s3.secret_access_key`](/tiflash/tiflash-disaggregated-and-s3.md) | 新增 | 访问 S3 的 SECRET_ACCESS_KEY。 | | TiFlash | [`storage.remote.cache.dir`](/tiflash/tiflash-disaggregated-and-s3.md) | 新增 | TiFlash Compute Node 的本地数据缓存目录。 | | TiFlash | [`storage.remote.cache.capacity`](/tiflash/tiflash-disaggregated-and-s3.md) | 新增 | TiFlash Compute Node 的本地数据缓存目录的大小。 | -| TiDB Lightning | [`add-index-by-sql`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-任务配置) | 新增 | 控制 Physical Import Mode 是否通过 SQL 方式添加索引。默认为 `false`，表示 TiDB Lightning 会将行数据以及索引数据都编码成 KV pairs 后一同导入 TiKV，实现机制和历史版本保持一致。通过 SQL 方式添加索引的优点是将导入数据与导入索引分开，可以快速导入数据，即使导入数据后，索引添加失败，也不会影响数据的一致性。 | +| TiDB Lightning | [`add-index-by-sql`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-任务配置) | 新增 | 控制物理导入模式是否通过 SQL 方式添加索引。默认为 `false`，表示 TiDB Lightning 会将行数据以及索引数据都编码成 KV pairs 后一同导入 TiKV，实现机制和历史版本保持一致。通过 SQL 方式添加索引的优点是将导入数据与导入索引分开，可以快速导入数据，即使导入数据后，索引添加失败，也不会影响数据的一致性。 | | TiCDC | [`enable-table-across-nodes`](/ticdc/ticdc-changefeed-config.md#ticdc-changefeed-配置文件说明) | 新增 | 将表按 Region 个数划分成多个同步范围，这些范围可由多个 TiCDC 节点同步。 | | TiCDC | [`region-threshold`](/ticdc/ticdc-changefeed-config.md#ticdc-changefeed-配置文件说明) | 新增 | 开启了 `enable-table-across-nodes` 后，该功能只对 Region 个数大于 `region-threshold` 值的表生效。 | | DM | [`analyze`](/dm/task-configuration-file-full.md#完整配置文件示例) | 新增 | 配置是否在 CHECKSUM 结束后对所有表逐个执行 `ANALYZE TABLE
数据库管理与可观测性
TiDB 通过 LOAD DATA 语句集成 TiDB Lightning（实验特性）集成 TiDB Lightning 的逻辑导入模式使 LOAD DATA 语句更加强大，例如支持从 S3/GCS 导入数据、支持任务管理等。LOAD DATA 语句功能增强（实验特性）LOAD DATA 语句功能增强，例如支持从 S3/GCS 导入数据。
TiCDC 支持对象存储 Sink (GA)
` 操作，可配置 `"required"`/`"optional"`/`"off"`。默认为 `"optional"`。| | DM | [`range-concurrency`](/dm/task-configuration-file-full.md#完整配置文件示例) | 新增 | 配置 dm-worker 向 TiKV 写入 KV 数据的并发数。 | | DM | [`compress-kv-pairs`](/dm/task-configuration-file-full.md#完整配置文件示例) | 新增 | 配置 dm-worker 向 TiKV 发送 KV 数据时是否启用压缩，可配置 `"gzip"`，默认为空表示不压缩。 | -| DM | [`pd-addr`](/dm/task-configuration-file-full.md#完整配置文件示例) | 新增 | 配置 Physical Import 时连接下游 PD server 的地址，填一个或多个均可。配置项为空时，默认使用 TiDB 中查询到的 PD 地址信息。 | +| DM | [`pd-addr`](/dm/task-configuration-file-full.md#完整配置文件示例) | 新增 | 配置物理导入模式时连接下游 PD server 的地址，填一个或多个均可。配置项为空时，默认使用 TiDB 中查询到的 PD 地址信息。 | ## 改进提升 @@ -389,6 +387,7 @@ TiDB 版本：7.0.0 - 避免某些情况下分区表数据需要在 TiDB 全局排序 [#26166](https://github.com/pingcap/tidb/issues/26166) @[Defined2014](https://github.com/Defined2014) - 支持同时使用 `fair lock mode` 和 `lock only if exists` 功能 [#42068](https://github.com/pingcap/tidb/issues/42068) @[MyonKeminta](https://github.com/MyonKeminta) - 支持打印事务慢日志以及相关事务内部事件 [#41863](https://github.com/pingcap/tidb/issues/41863) @[ekexium](https://github.com/ekexium) + - 支持 `ILIKE` 操作符 [#40943](https://github.com/pingcap/tidb/issues/40943) @[xzhangxian1008](https://github.com/xzhangxian1008) + PD @@ -398,6 +397,7 @@ TiDB 版本：7.0.0 - 减少 TiFlash 在写路径上的内存使用量 [#7144](https://github.com/pingcap/tiflash/issues/7144) @[hongyunyan](https://github.com/hongyunyan) - 减少 TiFlash 在有较多表的情况下的重启时间 [#7146](https://github.com/pingcap/tiflash/issues/7146) @[hongyunyan](https://github.com/hongyunyan) + - 支持下推 `ILIKE` 操作符 [#6740](https://github.com/pingcap/tiflash/issues/6740) @[xzhangxian1008](https://github.com/xzhangxian1008) + Tools @@ -485,13 +485,13 @@ TiDB 版本：7.0.0 + TiDB Data Migration (DM) - - 修复了 DM worker 节点使用 GCP Cloud Storage 时，由于断点续传信息记录过于频繁，达到了 GCP Cloud Storage 的请求频次上限，导致 DM worker 无法把数据写入 GCP Cloud Storage 中，从而导致全量数据加载失败的问题 [#8482](https://github.com/pingcap/tiflow/issues/8482) @[maxshuang](https://github.com/maxshuang) + - 修复了 DM worker 节点使用 Google Cloud Storage 时，由于断点续传信息记录过于频繁，达到了 Google Cloud Storage 的请求频次上限，导致 DM worker 无法把数据写入 Google Cloud Storage 中，从而导致全量数据加载失败的问题 [#8482](https://github.com/pingcap/tiflow/issues/8482) @[maxshuang](https://github.com/maxshuang) - 修复了在多个导入任务同时同步同一个下游的数据，并且都使用了下游元数据表来记录断点续传信息时，所有任务的断点续传信息被写入了同一张元数据表，并且使用了相同的任务 ID 的问题 [#8500](https://github.com/pingcap/tiflow/issues/8500) @[maxshuang](https://github.com/maxshuang) + TiDB Lightning - - 修复了当使用 Physical Import Mode 导入数据时，如果目标表的复合主键中存在 `auto_random` 列，但源数据中没有指定该列的值，TiDB Lightning 不能为 `auto_random` 列自动生成数据的问题 [#41454](https://github.com/pingcap/tidb/issues/41454) @[D3Hunter](https://github.com/D3Hunter) - - 修复了当使用 TiDB Lightning 的 Logical Import Mode 导入数据时，由于目标集群用户没有 `CONFIG` 权限导致导入失败的问题 [#41915](https://github.com/pingcap/tidb/issues/41915) @[lichunzhu](https://github.com/lichunzhu) + - 修复了当使用物理导入模式导入数据时，如果目标表的复合主键中存在 `auto_random` 列，但源数据中没有指定该列的值，TiDB Lightning 不能为 `auto_random` 列自动生成数据的问题 [#41454](https://github.com/pingcap/tidb/issues/41454) @[D3Hunter](https://github.com/D3Hunter) + - 修复了当使用 TiDB Lightning 的逻辑导入模式导入数据时，由于目标集群用户没有 `CONFIG` 权限导致导入失败的问题 [#41915](https://github.com/pingcap/tidb/issues/41915) @[lichunzhu](https://github.com/lichunzhu) ## 贡献者 diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md new file mode 100644 index 000000000000..b570f4a28367 --- /dev/null +++ b/releases/release-7.1.0.md @@ -0,0 +1,552 @@ +--- +title: TiDB 7.1.0 Release Notes +summary: 了解 TiDB 7.1.0 版本的新功能、兼容性变更、改进提升，以及错误修复。 +--- + +# TiDB 7.1.0 Release Notes + +发版日期：2023 年 5 月 31 日 + +TiDB 版本：7.1.0 + +试用链接：[快速体验](https://docs.pingcap.com/zh/tidb/v7.1/quick-start-with-tidb) | [生产部署](https://docs.pingcap.com/zh/tidb/v7.1/production-deployment-using-tiup) | [下载离线包](https://cn.pingcap.com/product-community/?version=v7.1.0#version-list) + +TiDB 7.1.0 为长期支持版本 (Long-Term Support Release, LTS)。 + +相比于前一个 LTS（即 6.5.0 版本），7.1.0 版本包含 [6.6.0-DMR](/releases/release-6.6.0.md) 和 [7.0.0-DMR](/releases/release-7.0.0.md) 中已发布的新功能、提升改进和错误修复，并引入了以下关键特性： + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
分类功能描述
可扩展性与性能TiFlash 支持存储计算分离和 S3 共享存储（实验特性，从 v7.0.0 开始引入）TiFlash 增加云原生架构的支持作为可选项： +
    +
  • 支持存算分离架构，提升 HTAP 资源的弹性能力。
    • +
  • 支持基于 S3 的存储引擎，以更低的成本提供共享存储。
    • +
+
TiKV 支持批量聚合数据请求（从 v6.6.0 开始引入）TiDB 支持将发送到相同 TiKV 实例的数据请求部分合并，减少子任务的数量和 RPC 请求的开销。在数据离散分布且 gRPC 线程池资源紧张的情况下，批量化请求能够提升性能超 50%。
基于负载的副本读取在读热点场景中，TiDB 可以将热点 TiKV 节点的读请求转发到副本。该功能有效地打散了读热点并优化了集群资源的利用。你可以通过调整系统变量 tidb_load_based_replica_read_threshold 控制基于负载的副本读取的触发阈值。
TiKV 支持分区 Raft KV 存储引擎 （实验特性）TiKV 引入新一代存储引擎分区 Raft KV，通过每个数据 Region 独享 RocksDB 实例，可将集群的存储能力从 TB 级扩展到 PB 级，并提供更稳定的写入延迟和更强大的扩容能力。
稳定性与高可用资源管控 (GA)支持基于资源组的资源管控，为同一集群中的不同工作负载分配并隔离资源。该功能显著提升了多应用集群的稳定性，并为多租户奠定了基础。在 v7.1.0 中，资源管控引入了根据实际负载或硬件部署估算集群容量的能力。
TiFlash 支持数据落盘（从 v7.0.0 开始引入）TiFlash 支持将中间结果落盘，以缓解数据密集型操作（如聚合、排序和 Hash Join）中的 OOM 问题。
SQL多值索引 (GA)引入 MySQL 兼容的多值索引，增强 JSON 类型，提升 TiDB 对 MySQL 8.0 的兼容性。该功能提升了对多值列进行成员检查的效率。
行级 TTL（从 v7.0.0 开始 GA）支持通过后台任务自动删除超过生命周期 (Time to live) 的数据，并以此来自动管理数据规模并提高性能。
生成列 (GA)生成列 (Generated Columns) 的值是通过实时计算列定义中的 SQL 表达式得到的。该功能将一些应用逻辑推向数据库层，从而提升查询效率。
安全LDAP 身份认证TiDB 支持与 MySQL 8.0 兼容的 LDAP 身份认证。
增强数据库审计功能（企业版）TiDB 企业版增强了数据库审计功能，通过更细粒度的事件过滤控制、更友好的过滤条件设置方式、新增的 JSON 文件输出格式、审计日志的生命周期管理，大幅提升了系统的审计能力。
+ +## 功能详情 + +### 性能 + +* 增强分区 Raft KV 存储引擎（实验特性）[#11515](https://github.com/tikv/tikv/issues/11515) [#12842](https://github.com/tikv/tikv/issues/12842) @[busyjay](https://github.com/busyjay) @[tonyxuqqi](https://github.com/tonyxuqqi) @[tabokie](https://github.com/tabokie) @[bufferflies](https://github.com/bufferflies) @[5kbpers](https://github.com/5kbpers) @[SpadeA-Tang](https://github.com/SpadeA-Tang) @[nolouch](https://github.com/nolouch) + + TiDB v6.6.0 引入了分区 Raft KV 存储引擎作为实验特性，该引擎使用多个 RocksDB 实例存储 TiKV 的 Region 数据，每个 Region 的数据都独立存储在单独的 RocksDB 实例中。分区 Raft KV 能够更好地控制 RocksDB 实例的文件数和层级，实现 Region 间数据操作的物理隔离，并支持平稳管理更多的数据。与原 TiKV 存储引擎相比，使用分区 Raft KV 引擎在相同硬件条件和读写混合场景下，可以实现大约两倍的写入吞吐并缩短大约 4/5 的弹性扩展时间。 + + 在 TiDB v7.1.0 中，分区 Raft KV 引擎与 TiFlash 兼容，并支持 TiDB Lightning、BR 和 TiCDC 等工具。 + + 该功能目前是实验特性，不推荐在生产环境中使用。目前仅支持在新集群中使用新引擎，暂不支持从原 TiKV 存储引擎直接升级到该引擎。 + + 更多信息，请参考[用户文档](/partitioned-raft-kv.md)。 + +* TiFlash 查询支持延迟物化功能 (GA) [#5829](https://github.com/pingcap/tiflash/issues/5829) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + + 在 v7.0.0 中，TiFlash 引入了延迟物化实验特性，用于优化查询性能。该特性默认关闭（系统变量 [`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-从-v700-版本开始引入) 默认为 `OFF`）。当 `SELECT` 语句中包含过滤条件（`WHERE` 子句）时，TiFlash 默认会先读取该查询所需列的全部数据，然后再根据查询条件对数据进行过滤、聚合等计算任务。开启该特性后，TiFlash 支持下推部分过滤条件到 TableScan 算子，即先扫描过滤条件相关的列数据，过滤得到符合条件的行后，再扫描这些行的其他列数据，继续后续计算，从而减少 IO 扫描和数据处理的计算量。 + + 从 v7.1.0 开始，TiFlash 延迟物化功能正式 GA，默认开启（系统变量 [`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-从-v700-版本开始引入) 默认为 `ON`），TiDB 优化器会根据统计信息和查询的过滤条件，决定哪些过滤条件会被下推到 TableScan 算子。 + + 更多信息，请参考[用户文档](/tiflash/tiflash-late-materialization.md)。 + +* TiFlash 支持根据网络交换数据量自动选择 MPP 模式的 Join 算法 [#7084](https://github.com/pingcap/tiflash/issues/7084) @[solotzg](https://github.com/solotzg) + + TiFlash MPP 模式有多种 Join 算法。在 v7.1.0 之前的版本中，TiDB 根据变量 [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-从-v50-版本开始引入) 和 [`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_count-从-v50-版本开始引入) 以及实际数据量决定 TiFlash MPP 模式是否使用 Broadcast Hash Join 算法。 + + 在 v7.1.0 中，TiDB 引入变量 [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-从-v710-版本开始引入)，控制是否基于最小网络数据交换策略选择 MPP Join 算法。该变量默认关闭，表示默认保持 v7.1.0 之前的算法选择策略。如需开启，请设置该变量为 `ON`。开启后，你无需再手动调整 [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-从-v50-版本开始引入) 和 [`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_count-从-v50-版本开始引入) 的阈值（此时这两个变量将不再生效），TiDB 会自动估算不同 Join 算法所需进行网络交换的数据量，然后选择综合开销较小的算法，从而减少网络流量，提升 MPP 查询性能。 + + 更多信息，请参考[用户文档](/tiflash/use-tiflash-mpp-mode.md#mpp-模式的算法支持)。 + +* 支持自适应副本读取缓解读热点 [#14151](https://github.com/tikv/tikv/issues/14151) @[sticnarf](https://github.com/sticnarf) @[you06](https://github.com/you06) + + 在读热点场景中，热点 TiKV 无法及时处理读请求，导致读请求排队。但是，此时并非所有 TiKV 资源都已耗尽。为了降低延迟，TiDB v7.1.0 引入了负载自适应副本读取功能，允许从其他有可用资源的 TiKV 节点读取副本，而无需在热点 TiKV 节点排队等待。你可以通过 [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-从-v700-版本开始引入) 系统变量控制读请求的排队长度。当 leader 节点的预估排队时间超过该阈值时，TiDB 会优先从 follower 节点读取数据。在读热点的情况下，与不打散读热点相比，该功能可提高读取吞吐量 70%～200%。 + + 更多信息，请参考[用户文档](/troubleshoot-hot-spot-issues.md#打散读热点)。 + +* 增强缓存非 Prepare 语句执行计划的能力（实验特性）[#36598](https://github.com/pingcap/tidb/issues/36598) @[qw4990](https://github.com/qw4990) + + TiDB v7.0.0 引入了非 Prepare 语句的执行计划缓存作为实验特性，以提升在线交易场景的并发处理能力。在 v7.1.0 中，TiDB 继续增强非 Prepare 语句执行计划，支持缓存更多模式的 SQL。 + + 为了提升内存利用率，TiDB v7.1.0 将非 Prepare 与 Prepare 语句的缓存池合并。你可以通过系统变量 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-从-v710-版本开始引入) 设置缓存大小。原有的系统变量 [`tidb_prepared_plan_cache_size`](/system-variables.md#tidb_prepared_plan_cache_size-从-v610-版本开始引入) 和 [`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size) 被废弃。 + + 为了保持向前兼容，从旧版本升级到 v7.1.0 时，缓存池大小 `tidb_session_plan_cache_size` 的值与 `tidb_prepared_plan_cache_size` 保持一致，[`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) 保持升级前的设置。经过性能测试后，你可通过 `tidb_enable_non_prepared_plan_cache` 开启非 Parepare 语句的执行计划缓存功能。 + + 非 Prepare 语句执行计划缓存默认不支持 DML 语句，若要启用支持，你可以将 [`tidb_enable_non_prepared_plan_cache_for_dml`](/system-variables.md#tidb_enable_non_prepared_plan_cache_for_dml-从-v710-版本开始引入) 系统变量设置为 `ON`。 + + 更多信息，请参考[用户文档](/sql-non-prepared-plan-cache.md)。 + +* DDL 支持分布式并行执行框架（实验特性）[#41495](https://github.com/pingcap/tidb/issues/41495) @[benjamin2037](https://github.com/benjamin2037) + + TiDB v7.1.0 之前的版本中，在同一时间只有一个 TiDB 节点能够担任 DDL Owner 并执行 DDL 任务。从 TiDB v7.1.0 开始，在新的分布式并行执行框架下，多个 TiDB 节点可以并行执行同一项 DDL 任务，从而更好地利用 TiDB 集群的资源，大幅提升 DDL 的性能。此外，你还可以通过增加 TiDB 节点来线性提升 DDL 的性能。需要注意的是，该特性是实验性特性，目前仅支持 `ADD INDEX` 操作。 + + 如果要使用分布式并行执行框架，只需将 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-从-v710-版本开始引入) 的值设置为 `ON`： + + ```sql + SET GLOBAL tidb_enable_dist_task = ON; + ``` + + 更多信息，请参考[用户文档](/tidb-distributed-execution-framework.md)。 + +### 稳定性 + +* 资源管控成为正式功能 (GA) [#38825](https://github.com/pingcap/tidb/issues/38825) @[nolouch](https://github.com/nolouch) @[BornChanger](https://github.com/BornChanger) @[glorv](https://github.com/glorv) @[tiancaiamao](https://github.com/tiancaiamao) @[Connor1996](https://github.com/Connor1996) @[JmPotato](https://github.com/JmPotato) @[hnes](https://github.com/hnes) @[CabinfeverB](https://github.com/CabinfeverB) @[HuSharp](https://github.com/HuSharp) + + TiDB 持续增强资源管控能力，在 v7.1.0 该功能正式 GA。该特性将极大地提升 TiDB 集群的资源利用率和性能表现。资源管控特性的引入对 TiDB 具有里程碑的意义，你可以将一个分布式数据库集群划分成多个逻辑单元，将不同的数据库用户映射到对应的资源组中，并根据实际需求设置每个资源组的配额。当集群资源紧张时，同一资源组内的会话所使用的全部资源将受到配额限制，防止某一资源组的过度消耗对其他资源组的会话造成影响。 + + 该特性也可以将多个来自不同系统的中小型应用整合到同一个 TiDB 集群中。即使某个应用的负载增加，也不会影响其他应用的正常运行。而在系统负载较低的时候，繁忙的应用即使超出设定的配额，仍可获得所需系统资源，实现资源的最大化利用。此外，合理利用资源管控特性可以减少集群数量，降低运维难度及管理成本。 + + 在 TiDB v7.1.0 中，该特性增加了基于实际负载和硬件部署来估算系统容量上限的能力，为你进行容量规划提供更准确的参考。这有助于你更好地管理 TiDB 的资源分配，从而满足企业级场景的稳定性需求。 + + 为了更好的用户体验，TiDB Dashboard 增加了[资源管控的管理页面](/dashboard/dashboard-resource-manager.md)。你可以在该页面查看资源组配置，并通过可视化的方式进行容量预估，便于合理配置资源。 + + 更多信息，请参考[用户文档](/tidb-resource-control.md)。 + +* 支持 Fast Online DDL 的检查点机制，提升容错性和自动恢复能力 [#42164](https://github.com/pingcap/tidb/issues/42164) @[tangenta](https://github.com/tangenta) + + TiDB v7.1.0 引入 [Fast Online DDL](/ddl-introduction.md) 的检查点机制，可以大幅提升 Fast Online DDL 的容错性和自动恢复能力。即使 TiDB owner 因故障重启或者切换，TiDB 也能够通过自动定期保存的检查点恢复部分进度，从而让 DDL 执行更加稳定高效。 + + 更多信息，请参考[用户文档](/system-variables.md#tidb_ddl_enable_fast_reorg-从-v630-版本开始引入)。 + +* BR 备份恢复工具支持断点恢复 [#42339](https://github.com/pingcap/tidb/issues/42339) @[Leavrth](https://github.com/Leavrth) + + 快照恢复或日志恢复会因为一些可恢复性错误导致提前结束，例如硬盘空间占满、节点宕机等突发情况。在 TiDB v7.1.0 之前，即使错误被及时处理，之前恢复的进度也会作废，你需要重新进行恢复。对大规模集群来说，会造成大量额外成本。 + + 为了尽可能继续上一次的恢复，从 TiDB v7.1.0 起，备份恢复特性引入了断点恢复的功能。该功能可以在意外中断后保留上一次恢复的大部分进度。 + + 更多信息，请参考[用户文档](/br/br-checkpoint-restore.md)。 + +* 优化统计信息缓存加载策略 [#42160](https://github.com/pingcap/tidb/issues/42160) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) + + TiDB v7.1.0 引入了轻量级的统计信息初始化功能作为实验特性。轻量级的统计信息初始化可以大幅减少启动时必须加载的统计信息的数量，从而提升启动过程中统计信息的加载速度。该功能提升了 TiDB 在复杂运行环境下的稳定性，并降低了部分 TiDB 节点重启对整体服务的影响。你可以通过修改 TiDB 配置参数 [`lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-从-v710-版本开始引入) 为 `true` 来开启该特性。 + + 在 TiDB 启动阶段，如果在初始统计信息加载完成之前执行 SQL，可能会产生不合理的执行计划，进而造成性能问题。为了避免这种情况，TiDB v7.1.0 引入了配置项 [`force-init-stats`](/tidb-configuration-file.md#force-init-stats-从-v710-版本开始引入)。你可以控制 TiDB 是否在统计信息初始化完成后再对外提供服务。该配置项默认关闭。 + + 更多信息，请参考[用户文档](/statistics.md#统计信息的加载)。 + +* TiCDC 支持单行数据正确性校验功能 [#8718](https://github.com/pingcap/tiflow/issues/8718) [#42747](https://github.com/pingcap/tidb/issues/42747) @[3AceShowHand](https://github.com/3AceShowHand) @[zyguan](https://github.com/zyguan) + + 从 v7.1.0 开始，TiCDC 引入了单行数据正确性校验功能。该功能基于 Checksum 算法对单行数据的正确性进行校验，可以校验一行数据从 TiDB 写入、通过 TiCDC 同步，到写入 Kafka 集群的过程中是否出现错误。TiCDC 数据正确性校验功能仅支持下游是 Kafka 的 Changefeed，目前支持 Avro 协议。 + + 更多信息，请参考[用户文档](/ticdc/ticdc-integrity-check.md)。 + +* TiCDC 优化 DDL 同步操作 [#8686](https://github.com/pingcap/tiflow/issues/8686) @[hi-rustin](https://github.com/hi-rustin) + + 在 v7.1.0 之前，当用户在一个大表上进行 DDL 操作时，如果 DDL 操作影响该表中的所有行（例如添加或删除列），TiCDC 的同步延迟会显著增加。从 v7.1.0 开始，TiCDC 对此进行了优化，减轻 DDL 操作对下游延迟的影响。 + + 更多信息，请参考[用户文档](/ticdc/ticdc-faq.md#ticdc-是否会将有损-ddl-产生的数据变更同步到下游)。 + +* 提升 TiDB Lightning 导入 TiB 级别数据时的稳定性 [#43510](https://github.com/pingcap/tidb/issues/43510) [#43657](https://github.com/pingcap/tidb/issues/43657) @[D3Hunter](https://github.com/D3Hunter) @[lance6716](https://github.com/lance6716) + + 从 v7.1.0 开始，TiDB Lightning 增加了四个配置项，可以提升在导入 TiB 级数据时的稳定性。 + + - `tikv-importer.region-split-batch-size` 用于控制批量 split Region 时的 Region 个数，默认值为 `4096`。 + - `tikv-importer.region-split-concurrency` 用于控制 Split Region 时的并发度，默认值为 CPU 核心数。 + - `tikv-importer.region-check-backoff-limit` 用于控制 split 和 scatter 操作后等待 Region 上线的重试次数，默认值为 `1800`。重试符合指数回退策略，最大重试间隔为 2 秒。若两次重试之间有任何 Region 上线，该次操作不会被计为重试次数。 + - `tikv-importer.pause-pd-scheduler-scope` 控制 TiDB Lightning 暂停 PD 调度的范围。默认值为 `"table"`，可选值为 `"table"` 和 `"global"`。对于 TiDB v6.1.0 之前的版本，只能配置 `"global"` 选项，即导入数据过程中暂停全局调度。从 v6.1.0 开始，支持 `"table"` 选项，表示仅暂停目标表数据范围所在 Region 的调度。建议在数据量较大的场景将该配置项设置为 `"global"`，以提升稳定性。 + + 更多信息，请参考[用户文档](/tidb-lightning/tidb-lightning-configuration.md)。 + +### SQL 功能 + +* 支持通过 `INSERT INTO SELECT` 语句保存 TiFlash 查询结果 (GA) [#37515](https://github.com/pingcap/tidb/issues/37515) @[gengliqi](https://github.com/gengliqi) + + 从 v6.5.0 起，TiDB 支持下推 `INSERT INTO SELECT` 语句中的 `SELECT` 子句（分析查询）到 TiFlash，你可以将 TiFlash 的查询结果方便地保存到 `INSERT INTO` 指定的 TiDB 表中供后续分析使用，起到了结果缓存（即结果物化）的效果。 + + 在 v7.1.0 版本中，该功能正式 GA。当 TiDB 执行 `INSERT INTO SELECT` 语句中的 `SELECT` 子句时，优化器将根据 [SQL 模式](/sql-mode.md)及 TiFlash 副本的代价估算自行决定是否将查询下推至 TiFlash。因此，在实验特性阶段引入的系统变量 `tidb_enable_tiflash_read_for_write_stmt` 将被废弃。需要注意的是，TiFlash 对于 `INSERT INTO SELECT` 语句的计算规则不满足 `STRICT SQL Mode` 要求，因此只有当前会话的 [SQL 模式](/sql-mode.md)为非严格模式（即 `sql_mode` 值不包含 `STRICT_TRANS_TABLES` 和 `STRICT_ALL_TABLES`），TiDB 才允许将 `INSERT INTO SELECT` 语句中的 `SELECT` 子句下推至 TiFlash。 + + 更多信息，请参考[用户文档](/tiflash/tiflash-results-materialization.md)。 + +* MySQL 兼容的多值索引 (Multi-Valued Index) 成为正式功能 (GA) [#39592](https://github.com/pingcap/tidb/issues/39592) @[xiongjiwei](https://github.com/xiongjiwei) @[qw4990](https://github.com/qw4990) @[YangKeao](https://github.com/YangKeao) + + 过滤 JSON 列中某个数组的值是一种常见操作，但使用普通索引无法加速此过程。在数组上创建多值索引可以大幅提升过滤性能。如果 JSON 列中的某个数组上存在多值索引，则函数 `MEMBER OF()`、`JSON_CONTAINS()` 和 `JSON_OVERLAPS()` 的检索条件可以利用该多值索引进行过滤，从而减少大量的 I/O 消耗，提升执行速度。 + + 在 v7.1.0 中，TiDB 多值索引成为正式功能 (GA)，支持更完整的数据类型，并与 TiDB 的工具链兼容。你可以在生产环境利用多值索引来加速对 JSON 数组的检索操作。 + + 更多信息，请参考[用户文档](/sql-statements/sql-statement-create-index.md#多值索引)。 + +* 完善 Hash 分区表和 Key 分区表的分区管理功能 [#42728](https://github.com/pingcap/tidb/issues/42728) @[mjonss](https://github.com/mjonss) + + 在 v7.1.0 之前，TiDB 中的 Hash 分区表和 Key 分区表只支持 `TRUNCATE PARTITION` 分区管理。从 v7.1.0 开始，Hash 分区表和 Key 分区表新增支持 `ADD PARTITION` 和 `COALESCE PARTITION` 分区管理。你可以根据需要灵活调整 Hash 分区表和 Key 分区表的分区数量。例如，通过 `ADD PARTITION` 语句增加分区数量，或通过 `COALESCE PARTITION` 语句减少分区数量。 + + 更多信息，请参考[用户文档](/partitioned-table.md#管理-hash-分区和-key-分区)。 + +* Range INTERVAL 分区定义语法成为正式功能 (GA) [#35683](https://github.com/pingcap/tidb/issues/35683) @[mjonss](https://github.com/mjonss) + + 在 v6.3.0 中引入的 Range INTERVAL 的分区定义语法成为正式功能 (GA)。通过该语法，你可以根据所需的间隔 (interval) 定义 Range 分区，不需要枚举所有分区，可大幅度缩短 Range 分区表的定义语句长度。语义与原有 Range 分区等价。 + + 更多信息，请参考[用户文档](/partitioned-table.md#range-interval-分区)。 + +* 生成列 (Generated Columns) 成为正式功能 (GA) @[bb7133](https://github.com/bb7133) + + 生成列是数据库中非常有价值的一个功能。在创建表时，可以定义一列的值由表中其他列的值计算而来，而不是由用户显式插入或更新。这个生成列可以是虚拟列 (Virtual Column) 或存储列 (Stored Column)。TiDB 在早期版本就提供了与 MySQL 兼容的生成列功能，在 v7.1.0 中这个功能正式 GA。 + + 使用生成列可以提升 TiDB 对 MySQL 的兼容性，方便从 MySQL 平滑迁移到 TiDB，同时也能简化数据维护复杂度，增强数据一致性并提高查询效率。 + + 更多信息，请参考[用户文档](/generated-columns.md)。 + +### 数据库管理 + +* 支持无需手动取消 DDL 的平滑升级集群功能（实验特性） [#39751](https://github.com/pingcap/tidb/issues/39751) @[zimulala](https://github.com/zimulala) + + 在 TiDB v7.1.0 之前的版本中，升级集群时需要先手动取消正在运行或排队的 DDL 任务，并在升级完成后再手动添加这些任务。 + + 为了提供更平滑的升级体验，TiDB v7.1.0 引入了自动暂停和恢复 DDL 任务的功能。从 v7.1.0 开始，你在升级集群前无需手动取消 DDL 任务。系统会自动暂停正在执行或排队的用户 DDL 任务，等待整个集群完成滚动升级后再自动恢复这些任务，让你可以更加轻松地升级 TiDB 集群。 + + 更多信息，请参考[用户文档](/smooth-upgrade-tidb.md)。 + +### 可观测性 + +* 增加优化器诊断信息 [#43122](https://github.com/pingcap/tidb/issues/43122) @[time-and-fate](https://github.com/time-and-fate) + + 获取充足的信息是 SQL 性能诊断的关键。在 v7.1.0 中，TiDB 持续为各种诊断工具增加优化器运行信息，以便更好地解释执行计划如何被选择，从而协助定位 SQL 性能问题。这些信息包括： + + * 在 [`PLAN REPLAYER`](/sql-plan-replayer.md) 的输出中增加 `debug_trace.json` 文件。 + * 在 [`EXPLAIN`](/explain-walkthrough.md) 的输出中为 `operator info` 添加部分统计信息详情。 + * 为[慢日志](/identify-slow-queries.md)的 `Stats` 字段添加部分统计信息详情。 + + 更多信息，请参考[使用 `PLAN REPLAYER` 保存和恢复集群线程信息](/sql-plan-replayer.md)、[使用 `EXPLAIN` 解读执行计划](/explain-walkthrough.md)和[慢日志查询](/identify-slow-queries.md)。 + +### 安全 + +* 更换 TiFlash 系统表信息的查询接口 [#6941](https://github.com/pingcap/tiflash/issues/6941) @[flowbehappy](https://github.com/flowbehappy) + + 从 v7.1.0 起，TiFlash 在向 TiDB 提供 [`INFORMATION_SCHEMA.TIFLASH_TABLES`](/information-schema/information-schema-tiflash-tables.md) 和 [`INFORMATION_SCHEMA.TIFLASH_SEGMENTS`](/information-schema/information-schema-tiflash-segments.md) 系统表的查询服务时，不再使用 HTTP 端口，而是使用 gRPC 端口，从而避免 HTTP 服务的安全风险。 + +* 支持 LDAP 身份认证 [#43580](https://github.com/pingcap/tidb/issues/43580) @[YangKeao](https://github.com/YangKeao) + + 从 v7.1.0 起，TiDB 支持 LDAP 身份认证，并提供了两种认证插件：`authentication_ldap_sasl` 和 `authentication_ldap_simple`。 + + 更多信息，请参考[用户文档](/security-compatibility-with-mysql.md)。 + +* 增强数据库审计功能（企业版） + + 在 v7.1.0 中，TiDB 企业版增强了数据库审计功能，大幅提升了能力范围，改善了使用体验，以满足企业对数据库安全合规的需要： + + - 引入“过滤器” (Filter) 与“规则” (Rule) 的概念，提供了更细分的审计事件定义，并支持更细粒度的审计设置。 + - 支持 JSON 格式的规则定义，提供了更加友好的设置方式。 + - 新增自动日志轮替 (Log Rotation) 和空间管理功能，支持保存时间和日志大小两个维度的设置。 + - 支持输出 TEXT 和 JSON 两种格式的审计日志，便于集成第三方工具。 + - 支持日志内容脱敏，可以替换所有字面值以增强安全性。 + + 数据库审计是 TiDB 企业版的重要功能之一，为企业提供了强大的监管和审计工具，以保证数据安全和合规性。TiDB 企业版的数据库审计功能可以帮助企业管理人员追踪数据库操作的来源和影响，确保数据不被非法窃取或篡改。同时，数据库审计还可以帮助企业遵守各种法规和合规要求，确保企业在法律和道德方面的合规性。该功能对企业信息安全具有非常重要的应用价值。 + + 该功能为企业版特性，要获取数据库审计功能及其文档，请在 [TiDB 产品页面](https://pingcap.com/zh/product/#SelectProduct)**企业版**区域点击**立即咨询**联系 PingCAP。 + +## 兼容性变更 + +> **注意：** +> +> 以下为从 v7.0.0 升级至当前版本 (v7.1.0) 所需兼容性变更信息。如果从 v6.6.0 或之前版本升级到当前版本，可能也需要考虑和查看中间版本 Release Notes 中提到的兼容性变更信息。 + +### 行为变更 + +* 为了提高安全性，TiFlash 废弃了 HTTP 服务端口（默认 `8123`），采用 gRPC 端口作为替代 + + 如果你已经将 TiFlash 升级到 v7.1.0，那么在升级 TiDB 到 v7.1.0 的过程中，TiDB 无法读取 TiFlash 系统表（[`INFORMATION_SCHEMA.TIFLASH_TABLES`](/information-schema/information-schema-tiflash-tables.md) 和 [`INFORMATION_SCHEMA.TIFLASH_SEGMENTS`](/information-schema/information-schema-tiflash-segments.md)）。 + +* TiDB v6.2.0 ~ v7.0.0 版本的 TiDB Lightning 会根据 TiDB 集群的版本决定是否暂停全局调度。当 TiDB 集群版本 >= v6.1.0 时，TiDB Lightning 只会暂停目标表数据范围所在 Region 的调度，并在目标表导入完成后恢复调度。其他版本的 TiDB Lightning 则会暂停全局调度。自 TiDB v7.1.0 开始，你可以通过 [`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md) 来控制是否暂停全局调度，默认暂停目标表数据范围所在 Region 的调度。如果目标集群版本低于 v6.1.0 则报错，此时将参数取值改为 `"global"` 后重试即可。 + +* 在 TiDB v7.1.0 中使用 [`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-to-timestamp.md) 功能可能会出现 FLASHBACK 完成后部分 Region 仍处于 FLASHBACK 过程中的问题。请尽量避免在 v7.1.0 中使用该功能。详情可见 [#44292](https://github.com/pingcap/tidb/issues/44292)。如果已经出现该问题，可以使用 [TiDB 快照备份与恢复](/br/br-snapshot-guide.md)功能进行数据恢复。 + +### 系统变量 + +| 变量名 | 修改类型 | 描述 | +|--------|------------------------------|------| +| [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-从-v630-版本开始引入) | 废弃 | 从 v7.1.0 开始，该变量废弃并且默认值从 `OFF` 修改为 `ON`。当 [`tidb_allow_mpp = ON`](/system-variables.md#tidb_allow_mpp-从-v50-版本开始引入) 时，优化器将根据 [SQL 模式](/sql-mode.md)及 TiFlash 副本的代价估算自行决定是否将查询下推至 TiFlash。 | +| [`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size) | 废弃 | 从 v7.1.0 起，该变量被废弃，你可以使用 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-从-v710-版本开始引入) 控制 Plan Cache 最多能够缓存的计划数量。 | +| [`tidb_prepared_plan_cache_size`](/system-variables.md#tidb_prepared_plan_cache_size-从-v610-版本开始引入) | 废弃 | 从 v7.1.0 起，该变量被废弃，你可以使用 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-从-v710-版本开始引入) 控制 Plan Cache 最多能够缓存的计划数量。 | +| `tidb_ddl_distribute_reorg` | 删除 | 重命名为 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-从-v710-版本开始引入)。 | +| [`default_authentication_plugin`](/system-variables.md#default_authentication_plugin) | 修改 | 扩展可选值范围：增加 `authentication_ldap_sasl` 和 `authentication_ldap_simple`。 | +| [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-从-v700-版本开始引入) | 修改 | 该变量从 v7.1.0 开始生效，用于设置基于负载的 replica read 的触发阈值。经进一步的测试后，该变量默认值从 `"0s"` 修改为 `"1s"`。 | +| [`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-从-v700-版本开始引入) | 修改 | 默认值从 `OFF` 修改为 `ON`，代表 [TiFlash 延迟物化](/tiflash/tiflash-late-materialization.md)功能默认开启。 | +| [`authentication_ldap_sasl_auth_method_name`](/system-variables.md#authentication_ldap_sasl_auth_method_name-从-v710-版本开始引入) | 新增 | 在 LDAP SASL 身份验证中，验证方法的名称。 | +| [`authentication_ldap_sasl_bind_base_dn`](/system-variables.md#authentication_ldap_sasl_bind_base_dn-从-v710-版本开始引入) | 新增 | 在 LDAP SASL 身份验证中，搜索用户的范围。如果创建用户时没有通过 `AS ...` 指定 `dn`，TiDB 会自动在 LDAP Server 的该范围中根据用户名搜索用户 `dn`。 | +| [`authentication_ldap_sasl_bind_root_dn`](/system-variables.md#authentication_ldap_sasl_bind_root_dn-从-v710-版本开始引入) | 新增 | 在 LDAP SASL 身份验证中，TiDB 登录 LDAP Server 搜索用户时使用的 `dn`。 | +| [`authentication_ldap_sasl_bind_root_pwd`](/system-variables.md#authentication_ldap_sasl_bind_root_pwd-从-v710-版本开始引入) | 新增 | 在 LDAP SASL 身份验证中，TiDB 登录 LDAP Server 搜索用户时使用的密码。 | +| [`authentication_ldap_sasl_ca_path`](/system-variables.md#authentication_ldap_sasl_ca_path-从-v710-版本开始引入) | 新增 | 在 LDAP SASL 身份验证中，TiDB 对 StartTLS 连接使用的 CA 证书的路径。 | +| [`authentication_ldap_sasl_init_pool_size`](/system-variables.md#authentication_ldap_sasl_init_pool_size-从-v710-版本开始引入) | 新增 | 在 LDAP SASL 身份验证中，TiDB 与 LDAP Server 间连接池的初始连接数。 | +| [`authentication_ldap_sasl_max_pool_size`](/system-variables.md#authentication_ldap_sasl_max_pool_size-从-v710-版本开始引入) | 新增 | 在 LDAP SASL 身份验证中，TiDB 与 LDAP Server 间连接池的最大连接数。 | +| [`authentication_ldap_sasl_server_host`](/system-variables.md#authentication_ldap_sasl_server_host-从-v710-版本开始引入) | 新增 | 在 LDAP SASL 身份验证中，LDAP Server 的主机名或地址。 | +| [`authentication_ldap_sasl_server_port`](/system-variables.md#authentication_ldap_sasl_server_port-从-v710-版本开始引入) | 新增 | 在 LDAP SASL 身份验证中，LDAP Server 的 TCP/IP 端口号。 | +| [`authentication_ldap_sasl_tls`](/system-variables.md#authentication_ldap_sasl_tls-从-v710-版本开始引入) | 新增 | 在 LDAP SASL 身份验证中，是否使用 StartTLS 对连接加密。 | +| [`authentication_ldap_simple_auth_method_name`](/system-variables.md#authentication_ldap_simple_auth_method_name-从-v710-版本开始引入) | 新增 | 在 LDAP simple 身份验证中，验证方法的名称。现在仅支持 `SIMPLE`。 | +| [`authentication_ldap_simple_bind_base_dn`](/system-variables.md#authentication_ldap_simple_bind_base_dn-从-v710-版本开始引入) | 新增 | 在 LDAP simple 身份验证中，搜索用户的范围。如果创建用户时没有通过 `AS ...` 指定 `dn`，TiDB 会自动在 LDAP Server 的该范围中根据用户名搜索用户 `dn`。 | +| [`authentication_ldap_simple_bind_root_dn`](/system-variables.md#authentication_ldap_simple_bind_root_dn-从-v710-版本开始引入) | 新增 | 在 LDAP simple 身份验证中，TiDB 登录 LDAP Server 搜索用户时使用的 `dn`。 | +| [`authentication_ldap_simple_bind_root_pwd`](/system-variables.md#authentication_ldap_simple_bind_root_pwd-从-v710-版本开始引入) | 新增 | 在 LDAP simple 身份验证中，TiDB 登录 LDAP Server 搜索用户时使用的密码。 | +| [`authentication_ldap_simple_ca_path`](/system-variables.md#authentication_ldap_simple_ca_path-从-v710-版本开始引入) | 新增 | 在 LDAP simple 身份验证中，TiDB 对 StartTLS 连接使用的 CA 证书的路径。 | +| [`authentication_ldap_simple_init_pool_size`](/system-variables.md#authentication_ldap_simple_init_pool_size-从-v710-版本开始引入) | 新增 | 在 LDAP simple 身份验证中，TiDB 与 LDAP Server 间连接池的初始连接数。 | +| [`authentication_ldap_simple_max_pool_size`](/system-variables.md#authentication_ldap_simple_max_pool_size-从-v710-版本开始引入) | 新增 | 在 LDAP simple 身份验证中，TiDB 与 LDAP Server 间连接池的最大连接数。 | +| [`authentication_ldap_simple_server_host`](/system-variables.md#authentication_ldap_simple_server_host-从-v710-版本开始引入) | 新增 | 在 LDAP simple 身份验证中，LDAP Server 的主机名或地址。 | +| [`authentication_ldap_simple_server_port`](/system-variables.md#authentication_ldap_simple_server_port-从-v710-版本开始引入) | 新增 | 在 LDAP simple 身份验证中，LDAP Server 的 TCP/IP 端口号。 | +| [`authentication_ldap_simple_tls`](/system-variables.md#authentication_ldap_simple_tls-从-v710-版本开始引入) | 新增 | 在 LDAP simple 身份验证中，是否使用 StartTLS 对连接加密。 | +| [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-从-v710-版本开始引入) | 新增 | 控制是否开启分布式执行框架。开启分布式执行后，DDL、Import 等支持的后端任务将会由集群中多个 TiDB 节点共同完成。该变量由 `tidb_ddl_distribute_reorg` 改名而来。| +| [`tidb_enable_non_prepared_plan_cache_for_dml`](/system-variables.md#tidb_enable_non_prepared_plan_cache_for_dml-从-v710-版本开始引入) | 新增 | 控制非 Prepare 语句执行计划缓存是否支持 DML 语句。 | +| [`tidb_enable_row_level_checksum`](/system-variables.md#tidb_enable_row_level_checksum-从-v710-版本开始引入) | 新增 | 控制是否开启 TiCDC 单行数据正确性校验。| +| [`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-从-v710-版本开始引入) | 新增 | 通过设置该变量，你可以更细粒度地控制优化器的行为，并且避免集群升级后优化器行为变化导致的性能回退。 | +| [`tidb_plan_cache_invalidation_on_fresh_stats`](/system-variables.md#tidb_plan_cache_invalidation_on_fresh_stats-从-v710-版本开始引入) | 新增 | 控制当某张表上的统计信息更新后，与该表相关的 Plan Cache 是否自动失效。 | +| [`tidb_plan_cache_max_plan_size`](/system-variables.md#tidb_plan_cache_max_plan_size-从-v710-版本开始引入) | 新增 | 控制可以缓存的 Prepare 或非 Prepare 语句执行计划的最大大小。 | +| [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-从-v710-版本开始引入) | 新增 | 控制是否使用最小网络数据交换策略。使用该策略时，TiDB 会估算 Broadcast Hash Join 和 Shuffled Hash Join 两种算法所需进行网络交换的数据量，并选择网络交换数据量较小的算法。该功能开启后，[`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-从-v50-版本开始引入) 和 [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-从-v50-版本开始引入) 将不再生效。 | +| [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-从-v710-版本开始引入) | 新增 | 控制 Plan Cache 最多能够缓存的计划数量。其中，Prepare 语句执行计划缓存和非 Prepare 语句执行计划缓存共用一个缓存。 | + +### 配置文件参数 + +| 配置文件 | 配置项 | 修改类型 | 描述 | +| -------- | -------- | -------- | -------- | +| TiDB | [`performance.force-init-stats`](/tidb-configuration-file.md#force-init-stats-从-v710-版本开始引入) | 新增 | 用于控制 TiDB 启动时是否在统计信息初始化完成后再对外提供服务。 | +| TiDB | [`performance.lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-从-v710-版本开始引入) | 新增 | 用于控制 TiDB 启动时是否采用轻量级的统计信息初始化。 | +| TiDB | [`log.timeout`](/tidb-configuration-file.md#timeout-从-v710-版本开始引入) | 新增 | 用于控制 TiDB 写日志操作的超时时间，当磁盘故障导致日志无法写入时，该配置可以让 TiDB 进程崩溃而不是卡死。默认值为 `0`，即不设定超时时间。 | +| TiKV | [`region-compact-min-redundant-rows`](/tikv-configuration-file.md#region-compact-min-redundant-rows-从-v710-版本开始引入) | 新增 | 触发 RocksDB compaction 需要的冗余的 MVCC 数据行数。默认值为 `50000`。 | +| TiKV | [`region-compact-redundant-rows-percent`](/tikv-configuration-file.md#region-compact-redundant-rows-percent-从-v710-版本开始引入) | 新增 | 触发 RocksDB compaction 需要的冗余的 MVCC 数据行所占比例。默认值为 `20`。 | +| TiKV | [`split.byte-threshold`](/tikv-configuration-file.md#byte-threshold-从-v50-版本开始引入) | 修改 | 当 [`region-split-size`](/tikv-configuration-file.md#region-split-size) 大于等于 4 GB 时，默认值从 `30MiB` 修改为 `100MiB`。 | +| TiKV | [`split.qps-threshold`](/tikv-configuration-file.md#qps-threshold) | 修改 | 当 [`region-split-size`](/tikv-configuration-file.md#region-split-size) 大于等于 4 GB 时，默认值从 `3000` 修改为 `7000`。 | +| TiKV | [`split.region-cpu-overload-threshold-ratio`](/tikv-configuration-file.md#region-cpu-overload-threshold-ratio-从-v620-版本开始引入) | 修改 | 当 [`region-split-size`](/tikv-configuration-file.md#region-split-size) 大于等于 4 GB 时，默认值从 `0.25` 修改为 `0.75`。 | +| TiKV | [`region-compact-check-step`](/tikv-configuration-file.md#region-compact-check-step) | 修改 | 当使用分区 Raft KV (`storage.engine="partitioned-raft-kv"`) 时，默认值从 `100` 修改为 `5`。 | +| PD | [`store-limit-version`](/pd-configuration-file.md#store-limit-version-从-v710-版本开始引入) | 新增 | 用于设置 store limit 工作模式。可选值为 `"v1"` 和 `"v2"`。 | +| PD | [`schedule.enable-diagnostic`](/pd-configuration-file.md#enable-diagnostic-从-v630-版本开始引入) | 修改 | 默认值从 `false` 修改为 `true`，默认打开调度器的诊断功能。 | +| TiFlash | `http_port` | 删除 | 废弃 TiFlash HTTP 服务端口（默认 `8123`）。 | +| TiDB Lightning | [`tikv-importer.pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md) | 新增 | 用于控制 TiDB Lightning 暂停 PD 调度的范围。默认值为 `"table"`，可选值为 `"global"` 和 `"table"`。 | +| TiDB Lightning | [`tikv-importer.region-check-backoff-limit`](/tidb-lightning/tidb-lightning-configuration.md) | 新增 | 用于控制 split 和 scatter 操作后等待 Region 上线的重试次数，默认值为 `1800`。重试符合指数回退策略，最大重试间隔为 2 秒。若两次重试之间有任何 Region 上线，该次操作不会被计为重试次数。 | +| TiDB Lightning | [`tikv-importer.region-split-batch-size`](/tidb-lightning/tidb-lightning-configuration.md) | 新增 | 用于控制一个 batch 中执行 split 和 scatter 操作的最大 Region 数量，默认值为 `4096`。 | +| TiDB Lightning | [`tikv-importer.region-split-concurrency`](/tidb-lightning/tidb-lightning-configuration.md) | 新增 | 用于控制 Split Region 时的并发度，默认值为 CPU 核心数。 | +| TiCDC | [`insecure-skip-verify`](/ticdc/ticdc-sink-to-kafka.md) | 新增 | 用于控制在同步数据到 Kafka 的场景下，启用 TLS 时是否设置认证算法。 | +| TiCDC | [`sink.only-output-updated-columns`](/ticdc/ticdc-changefeed-config.md#ticdc-changefeed-配置文件说明) | 新增 | 用于控制是否是否只向下游同步有内容更新的列，默认值为 `false`。 | +| TiCDC | [`integrity.corruption-handle-level`](/ticdc/ticdc-changefeed-config.md#ticdc-changefeed-配置文件说明) | 新增 | 用于控制当单行数据的 Checksum 校验失败时，Changefeed 打印错误行数据相关日志的级别。默认值为 `"warn"`，可选值为 `"warn"` 和 `"error"`。 | +| TiCDC | [`integrity.integrity-check-level`](/ticdc/ticdc-changefeed-config.md#ticdc-changefeed-配置文件说明) | 新增 | 用于控制是否开启单行数据的 Checksum 校验功能，默认值为 `"none"`，即不开启。 | +| TiCDC | [`sink.enable-partition-separator`](/ticdc/ticdc-changefeed-config.md#ticdc-changefeed-配置文件说明) | 修改 | 默认值从 `false` 修改为 `true`，代表默认会将表中各个分区的数据分不同的目录来存储。建议保持该配置项为 `true` 以避免同步分区表到存储服务时可能丢数据的问题。 | + +## 改进提升 + ++ TiDB + + - 在 `SHOW INDEX` 结果的 Cardinality 列中展示统计信息中对应列的不同值的数量 [#42227](https://github.com/pingcap/tidb/issues/42227) @[winoros](https://github.com/winoros) + - 使用 `SQL_NO_CACHE` 以避免 TTL Scan 查询对 TiKV block cache 造成影响 [#43206](https://github.com/pingcap/tidb/issues/43206) @[lcwangchao](https://github.com/lcwangchao) + - 改进 `MAX_EXECUTION_TIME` 相关错误信息使之与 MySQL 兼容 [#43031](https://github.com/pingcap/tidb/issues/43031) @[dveeden](https://github.com/dveeden) + - 在 IndexLookUp 中支持对分区表使用 MergeSort 算子 [#26166](https://github.com/pingcap/tidb/issues/26166) @[Defined2014](https://github.com/Defined2014) + - 改进 `caching_sha2_password` 使之与 MySQL 兼容 [#43576](https://github.com/pingcap/tidb/issues/43576) @[asjdf](https://github.com/asjdf) + ++ TiKV + + - 降低使用分区 Raft KV 时 Split 对写 QPS 的影响 [#14447](https://github.com/tikv/tikv/issues/14447) @[SpadeA-Tang](https://github.com/SpadeA-Tang) + - 优化使用分区 Raft KV 时 Snapshot 占用的空间 [#14581](https://github.com/tikv/tikv/issues/14581) @[bufferflies](https://github.com/bufferflies) + - 为 TiKV 处理请求的各个阶段提供更详细的时间信息 [#12362](https://github.com/tikv/tikv/issues/12362) @[cfzjywxk](https://github.com/cfzjywxk) + - 在日志备份中使用 PD 作为元数据存储 [#13867](https://github.com/tikv/tikv/issues/13867) @[YuJuncen](https://github.com/YuJuncen) + ++ PD + + - 新增基于 snapshot 执行细节来自动调整 store limit 大小的控制器。将 `store-limit-version` 设置为 `v2` 即可开启该控制器，开启后，用户无需手动调整 `store limit` 配置来控制扩缩容的速度 [#6147](https://github.com/tikv/pd/issues/6147) @[bufferflies](https://github.com/bufferflies) + - 新增历史负载信息，避免了存储引擎为 raft-kv2 时，热点调度器对不稳定负载所在的 Region 进行频繁调度 [#6297](https://github.com/tikv/pd/issues/6297) @[bufferflies](https://github.com/bufferflies) + - 新增 leader 健康检查机制，当 etcd leader 所在的 PD server 无法当选 leader 时，主动切换 etcd leader 来保证 PD leader 可用 [#6403](https://github.com/tikv/pd/issues/6403) @[nolouch](https://github.com/nolouch) + ++ TiFlash + + - 提升 TiFlash 在存算分离架构下的性能和稳定性 [#6882](https://github.com/pingcap/tiflash/issues/6882) @[JaySon-Huang](https://github.com/JaySon-Huang) @[breezewish](https://github.com/breezewish) @[JinheLin](https://github.com/JinheLin) + - 支持在 Semi Join 或 Anti Semi Join 中，通过选择较小的表作为 Build 端来优化查询性能 [#7280](https://github.com/pingcap/tiflash/issues/7280) @[yibin87](https://github.com/yibin87) + - 提升默认参数下 BR 和 TiDB Lightning 向 TiFlash 导入数据的性能 [#7272](https://github.com/pingcap/tiflash/issues/7272) @[breezewish](https://github.com/breezewish) + ++ Tools + + + Backup & Restore (BR) + + - 支持在备份日志时修改 TiKV 配置项 `log-backup.max-flush-interval` [#14433](https://github.com/tikv/tikv/issues/14433) @[joccau](https://github.com/joccau) + + + TiCDC + + - 优化同步数据到对象存储的场景下发生 DDL 事件时的目录结构 [#8890](https://github.com/pingcap/tiflow/issues/8890) @[CharlesCheung96](https://github.com/CharlesCheung96) + - 优化 TiCDC 在同步任务失败时对上游 GC TLS 的设置方法 [#8403](https://github.com/pingcap/tiflow/issues/8403) @[charleszheng44](https://github.com/charleszheng44) + - 支持同步到 Kafka-on-Pulsar 下游 [#8892](https://github.com/pingcap/tiflow/issues/8892) @[hi-rustin](https://github.com/hi-rustin) + - 在将数据同步到 Kafka 时，支持 open-protocol 协议在数据发生变更后只同步有变更的列 [#8706](https://github.com/pingcap/tiflow/issues/8706) @[sdojjy](https://github.com/sdojjy) + - 优化 TiCDC 在下游出现故障等场景中的错误处理方式 [#8657](https://github.com/pingcap/tiflow/issues/8657) @[hicqu](https://github.com/hicqu) + - 增加一个配置项 `insecure-skip-verify`，控制在同步数据到 Kafka 的场景下启用 TLS 时是否设置认证算法 [#8867](https://github.com/pingcap/tiflow/issues/8867) @[hi-rustin](https://github.com/hi-rustin) + + + TiDB Lightning + + - 将关于 Region 分布不均的 Precheck 项的严重级别从 `Critical` 调整为 `Warn`，以避免阻塞用户导入数据 [#42836](https://github.com/pingcap/tidb/issues/42836) @[okJiang](https://github.com/okJiang) + - 在导入数据期间遇到 `unknown RPC` 错误时，增加了重试机制 [#43291](https://github.com/pingcap/tidb/issues/43291) @[D3Hunter](https://github.com/D3Hunter) + - 增强 Region Job 的重试机制 [#43682](https://github.com/pingcap/tidb/issues/43682) @[lance6716](https://github.com/lance6716) + +## 错误修复 + ++ TiDB + + - 修复重组分区后没有提示手动 `ANALYZE TABLE` 的问题 [#42183](https://github.com/pingcap/tidb/issues/42183) @[CbcWestwolf](https://github.com/CbcWestwolf) + - 修复对于执行中的 `DROP TABLE` 操作，`ADMIN SHOW DDL JOBS` 的结果中缺少表名的问题 [#42268](https://github.com/pingcap/tidb/issues/42268) @[tiancaiamao](https://github.com/tiancaiamao) + - 修复 `Ignore Event Per Minute` 和 `Stats Cache LRU Cost` 图表在 Grafana 监控面板中有时不可见的问题 [#42562](https://github.com/pingcap/tidb/issues/42562) @[pingandb](https://github.com/pingandb) + - 修复查询表 `INFORMATION_SCHEMA.COLUMNS` 时，`ORDINAL_POSITION` 列返回结果错误的问题 [#43379](https://github.com/pingcap/tidb/issues/43379) @[bb7133](https://github.com/bb7133) + - 修复权限表中一些列大小写敏感的问题 [#41048](https://github.com/pingcap/tidb/issues/41048) @[bb7133](https://github.com/bb7133) + - 修复缓存表执行新增列操作后，新增列值为 `NULL` 而非列的默认值的问题 [#42928](https://github.com/pingcap/tidb/issues/42928) @[lqs](https://github.com/lqs) + - 修复在谓词下推的情况下 CTE 结果错误的问题 [#43645](https://github.com/pingcap/tidb/issues/43645) @[winoros](https://github.com/winoros) + - 修复分区特别多并且带有 TiFlash 副本的分区表在执行 `TRUNCATE TABLE` 时，出现写冲突导致 DDL 重试的问题 [#42940](https://github.com/pingcap/tidb/issues/42940) @[mjonss](https://github.com/mjonss) + - 修复在创建分区表时使用 `SUBPARTITION` 没有警告提醒的问题 [#41198](https://github.com/pingcap/tidb/issues/41198) [#41200](https://github.com/pingcap/tidb/issues/41200) @[mjonss](https://github.com/mjonss) + - 修复生成列在处理值溢出问题时与 MySQL 不兼容的问题 [#40066](https://github.com/pingcap/tidb/issues/40066) @[jiyfhust](https://github.com/jiyfhust) + - 修复 `REORGANIZE PARTITION` 不能与其他 DDL 操作并发的问题 [#42442](https://github.com/pingcap/tidb/issues/42442) @[bb7133](https://github.com/bb7133) + - 修复在取消 DDL 的重组分区任务后可能导致后续其他 DDL 报错的问题 [#42448](https://github.com/pingcap/tidb/issues/42448) @[lcwangchao](https://github.com/lcwangchao) + - 修复某些情况下删除操作的断言不正确的问题 [#42426](https://github.com/pingcap/tidb/issues/42426) @[tiancaiamao](https://github.com/tiancaiamao) + - 修复读取 cgroup 信息出错导致 TiDB Server 无法启动的问题，报错信息为 "can't read file memory.stat from cgroup v1: open /sys/memory.stat no such file or directory" [#42659](https://github.com/pingcap/tidb/issues/42659) @[hawkingrei](https://github.com/hawkingrei) + - 修复在包含全局索引的分区表上更新分区键数据时报 `Duplicate Key` 错误的问题 [#42312](https://github.com/pingcap/tidb/issues/42312) @[L-maple](https://github.com/L-maple) + - 修复 TTL 监控面板中 `Scan Worker Time By Phase` 图表不显示数据的问题 [#42515](https://github.com/pingcap/tidb/issues/42515) @[lcwangchao](https://github.com/lcwangchao) + - 修复在包含全局索引的分区表上进行某些查询时返回错误结果的问题 [#41991](https://github.com/pingcap/tidb/issues/41991) [#42065](https://github.com/pingcap/tidb/issues/42065) @[L-maple](https://github.com/L-maple) + - 修复在重组分区表的过程中会显示错误日志的问题 [#42180](https://github.com/pingcap/tidb/issues/42180) @[mjonss](https://github.com/mjonss) + - 修复 `INFORMATION_SCHEMA.DDL_JOBS` 表中 `QUERY` 列的数据长度可能超出列定义的问题 [#42440](https://github.com/pingcap/tidb/issues/42440) @[tiancaiamao](https://github.com/tiancaiamao) + - 修复表 `INFORMATION_SCHEMA.CLUSTER_HARDWARE` 在容器中可能显示错误的值的问题 [#42851](https://github.com/pingcap/tidb/issues/42851) @[hawkingrei](https://github.com/hawkingrei) + - 修复通过 `ORDER BY` + `LIMIT` 的方式查询分区表时，返回结果错误的问题 [#43158](https://github.com/pingcap/tidb/issues/43158) @[Defined2014](https://github.com/Defined2014) + - 修复可能出现多个使用 ingest 的方式的 DDL 任务同时运行的问题 [#42903](https://github.com/pingcap/tidb/issues/42903) @[tangenta](https://github.com/tangenta) + - 修复查询分区表时使用 `Limit` 返回错误值的问题 [#24636](https://github.com/pingcap/tidb/issues/24636) @[winoros](https://github.com/winoros) + - 修复 IPv6 环境下显示错误的 TiDB 地址的问题 [#43260](https://github.com/pingcap/tidb/issues/43260) @[nexustar](https://github.com/nexustar) + - 修复系统变量 `tidb_enable_tiflash_read_for_write_stmt` 和 `tidb_enable_exchange_partition` 显示错误的值的问题 [#43281](https://github.com/pingcap/tidb/issues/43281) @[gengliqi](https://github.com/gengliqi) + - 修复代理协议在处理某些错误数据时报错 `Header read timeout` 的问题 [#43205](https://github.com/pingcap/tidb/issues/43205) @[blacktear23](https://github.com/blacktear23) + - 修复当 `tidb_scatter_region` 变量设置为开启时，对某个分区进行 TRUNCATE 操作后没有自动分裂 Region 的问题 [#43174](https://github.com/pingcap/tidb/issues/43174) [#43028](https://github.com/pingcap/tidb/issues/43028) @[jiyfhust](https://github.com/jiyfhust) + - 在具有生成列的表上增加检查，并对不支持的列的 DDL 操作报错 [#38988](https://github.com/pingcap/tidb/issues/38988) [#24321](https://github.com/pingcap/tidb/issues/24321) @[tiancaiamao](https://github.com/tiancaiamao) + - 修复在某些类型转换出错的情况下报错信息不对的问题 [#41730](https://github.com/pingcap/tidb/issues/41730) @[hawkingrei](https://github.com/hawkingrei) + - 修复 TiDB 节点在正常 shutdown 后，在此节点上触发的 DDL 任务会被取消的问题 [#43854](https://github.com/pingcap/tidb/issues/43854) @[zimulala](https://github.com/zimulala) + - 修复当 PD 成员地址发生变化时，为 `AUTO_INCREMENT` 列分配 ID 会被长时间阻塞的问题 [#42643](https://github.com/pingcap/tidb/issues/42643) @[tiancaiamao](https://github.com/tiancaiamao) + - 修复执行 DDL 期间报 `GC lifetime is shorter than transaction duration` 错误的问题 [#40074](https://github.com/pingcap/tidb/issues/40074) @[tangenta](https://github.com/tangenta) + - 修复元数据锁非预期地阻塞 DDL 执行的问题 [#43755](https://github.com/pingcap/tidb/issues/43755) @[wjhuang2016](https://github.com/wjhuang2016) + - 修复 IPv6 环境下的集群无法查询部分系统视图的问题 [#43286](https://github.com/pingcap/tidb/issues/43286) @[Defined2014](https://github.com/Defined2014) + - 修复动态裁剪模式下内连接表时找不到分区的问题 [#43686](https://github.com/pingcap/tidb/issues/43686) @[mjonss](https://github.com/mjonss) + - 修复 analyze 表时报语法错误的问题 [#43392](https://github.com/pingcap/tidb/issues/43392) @[guo-shaoge](https://github.com/guo-shaoge) + - 修复在重命名表期间 TiCDC 可能丢失部分行变更的问题 [#43338](https://github.com/pingcap/tidb/issues/43338) @[tangenta](https://github.com/tangenta) + - 修复在客户端使用游标读导致 TiDB server 崩溃的问题 [#38116](https://github.com/pingcap/tidb/issues/38116) @[YangKeao](https://github.com/YangKeao) + - 修复 `ADMIN SHOW DDL JOBS LIMIT` 返回错误结果的问题 [#42298](https://github.com/pingcap/tidb/issues/42298) @[CbcWestwolf](https://github.com/CbcWestwolf) + - 修复使用 `UNION` 查询联合视图和临时表时 TiDB panic 的问题 [#42563](https://github.com/pingcap/tidb/issues/42563) @[lcwangchao](https://github.com/lcwangchao) + - 修复在一个事务中提交多条语句时重命名表不生效的问题 [#39664](https://github.com/pingcap/tidb/issues/39664) @[tiancaiamao](https://github.com/tiancaiamao) + - 修复时间转换时 Prepared Plan Cache 与 Non-Prepared Plan Cache 的行为不兼容性的问题 [#42439](https://github.com/pingcap/tidb/issues/42439) @[qw4990](https://github.com/qw4990) + - 修复 Plan Cache 导致 Decimal 类型的结果出错的问题 [#43311](https://github.com/pingcap/tidb/issues/43311) @[qw4990](https://github.com/qw4990) + - 修复 NAAJ (null-aware anti join) 中错误的类型检查导致 TiDB panic 的问题 [#42459](https://github.com/pingcap/tidb/issues/42459) @[AilinKid](https://github.com/AilinKid) + - 修复 RC 隔离级别下悲观事务中执行失败的 DML 可能导致数据索引不一致的问题 [#43294](https://github.com/pingcap/tidb/issues/43294) @[ekexium](https://github.com/ekexium) + - 修复在一些极端情况下，悲观事务的第一条语句发生重试时，对该事务进行 resolve lock 可能影响事务正确性的问题 [#42937](https://github.com/pingcap/tidb/issues/42937) @[MyonKeminta](https://github.com/MyonKeminta) + - 修复在一些罕见的情况下，悲观事务的残留悲观锁在 GC resolve lock 时可能影响数据正确性的问题 [#43243](https://github.com/pingcap/tidb/issues/43243) @[MyonKeminta](https://github.com/MyonKeminta) + - 修复从 `LOCK` 转换为 `PUT` 的优化导致特定查询返回重复数据的问题 [#28011](https://github.com/pingcap/tidb/issues/28011) @[zyguan](https://github.com/zyguan) + - 修复当数据未变更时唯一索引的加锁行为与数据发生变更时不一致的问题 [#36438](https://github.com/pingcap/tidb/issues/36438) @[zyguan](https://github.com/zyguan) + ++ TiKV + + - 修复在启用 `tidb_pessimistic_txn_fair_locking` 时，在某些极端情况下，RPC 失败重试导致的过期请求可能在 Resolve Lock 时影响数据正确性的问题 [#14551](https://github.com/tikv/tikv/issues/14551) @[MyonKeminta](https://github.com/MyonKeminta) + - 修复在启用 `tidb_pessimistic_txn_fair_locking` 时，在某些极端情况下，RPC 失败重试导致的过期请求可能会造成事务冲突被忽略，从而影响事务一致性的问题 [#14311](https://github.com/tikv/tikv/issues/14311) @[MyonKeminta](https://github.com/MyonKeminta) + - 修复加密 Key ID 冲突会导致旧 Key 被删除的问题 [#14585](https://github.com/tikv/tikv/issues/14585) @[tabokie](https://github.com/tabokie) + - 修复集群从较低版本升级到 v6.5 或更高版本时，由于累计的 Lock 记录可能导致性能下降到问题 [#14780](https://github.com/tikv/tikv/issues/14780) @[MyonKeminta](https://github.com/MyonKeminta) + - 修复 PITR 恢复过程中出现 `raft entry is too large` 的问题 [#14313](https://github.com/tikv/tikv/issues/14313) @[YuJuncen](https://github.com/YuJuncen) + - 修复 PITR 恢复过程中由于 `log_batch` 超过 2 GB 导致 TiKV panic 的问题 [#13848](https://github.com/tikv/tikv/issues/13848) @[YuJuncen](https://github.com/YuJuncen) + ++ PD + + - 修复 TiKV panic 后，PD 监控面板 `low space store` 数量异常的问题 [#6252](https://github.com/tikv/pd/issues/6252) @[HuSharp](https://github.com/HuSharp) + - 修复在 PD leader 切换后 Region Health 监控数据被删除的问题 [#6366](https://github.com/tikv/pd/issues/6366) @[iosmanthus](https://github.com/iosmanthus) + - 修复 Rule checker 无法修复 label 为 `schedule=deny` 的不健康 Region 的问题 [#6426](https://github.com/tikv/pd/issues/6426) @[nolouch](https://github.com/nolouch) + - 修复 TiKV 或 TiFlash 重启后部分已有 label 丢失的问题 [#6467](https://github.com/tikv/pd/issues/6467) @[JmPotato](https://github.com/JmPotato) + - 修复复制模式存在 learner 节点时可能无法切换复制状态的问题 [#14704](https://github.com/tikv/tikv/issues/14704) @[nolouch](https://github.com/nolouch) + ++ TiFlash + + - 修复开启延迟物化 (Late Materialization) 后查询 `TIMESTAMP` 或者 `TIME` 类型的数据报错的问题 [#7455](https://github.com/pingcap/tiflash/issues/7455) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - 修复大的更新事务可能会导致 TiFlash 反复报错重启的问题 [#7316](https://github.com/pingcap/tiflash/issues/7316) @[JaySon-Huang](https://github.com/JaySon-Huang) + ++ Tools + + + Backup & Restore (BR) + + - 修复集群中 TiKV 出现宕机导致备份速度降低的问题 [#42973](https://github.com/pingcap/tidb/issues/42973) @[YuJuncen](https://github.com/YuJuncen) + - 修复某些情况下备份失败会导致错误信息不准确的问题 [#43236](https://github.com/pingcap/tidb/issues/43236) @[YuJuncen](https://github.com/YuJuncen) + + + TiCDC + + - 修复 TiCDC 的时区设置问题 [#8798](https://github.com/pingcap/tiflow/issues/8798) @[hi-rustin](https://github.com/hi-rustin) + - 修复 PD 地址或 leader 出现故障时 TiCDC 不能自动恢复的问题 [#8812](https://github.com/pingcap/tiflow/issues/8812) [#8877](https://github.com/pingcap/tiflow/issues/8877) @[asddongmen](https://github.com/asddongmen) + - 修复上游 TiKV 节点 crash 时 checkpoint lag 上升的问题 [#8858](https://github.com/pingcap/tiflow/issues/8858) @[hicqu](https://github.com/hicqu) + - 修复当同步数据到对象存储时上游的 `EXCHANGE PARTITION` 操作没有正常同步到下游的问题 [#8914](https://github.com/pingcap/tiflow/issues/8914) @[CharlesCheung96](https://github.com/CharlesCheung96) + - 修复在某些特殊场景下 sorter 组件内存使用过多导致 OOM 的问题 [#8974](https://github.com/pingcap/tiflow/issues/8974) @[hicqu](https://github.com/hicqu) + - 修复下游 Kafka 滚动重启时 TiCDC 节点发生 panic 的问题 [#9023](https://github.com/pingcap/tiflow/issues/9023) @[asddongmen](https://github.com/asddongmen) + + + TiDB Data Migration (DM) + + - 修复数据同步过程中，latin1 字符集数据可能损坏的问题 [#7028](https://github.com/pingcap/tiflow/issues/7028) @[lance6716](https://github.com/lance6716) + + + TiDB Dumpling + + - 修复 `UNSIGNED INTEGER` 类型的主键无法用于拆分 Chunk 的问题 [#42620](https://github.com/pingcap/tidb/issues/42620) @[lichunzhu](https://github.com/lichunzhu) + - 修复错误设置 `--output-file-template` 可能导致 TiDB Dumpling panic 的问题 [#42391](https://github.com/pingcap/tidb/issues/42391) @[lichunzhu](https://github.com/lichunzhu) + + + TiDB Binlog + + - 修复当遇到失败的 DDL 语句时可能报错的问题 [#1228](https://github.com/pingcap/tidb-binlog/issues/1228) @[okJiang](https://github.com/okJiang) + + + TiDB Lightning + + - 修复导入性能退化的问题 [#42456](https://github.com/pingcap/tidb/issues/42456) @[lance6716](https://github.com/lance6716) + - 修复大数据量导入时报 `write to tikv with no leader returned` 错误的问题 [#43055](https://github.com/pingcap/tidb/issues/43055) @[lance6716](https://github.com/lance6716) + - 修复导入期间输出过多 `keys within region is empty, skip doIngest` 日志的问题 [#43197](https://github.com/pingcap/tidb/issues/43197) @[D3Hunter](https://github.com/D3Hunter) + - 修复 Range 部分写入时可能出现 panic 的问题 [#43363](https://github.com/pingcap/tidb/issues/43363) @[lance6716](https://github.com/lance6716) + - 修复宽表导入时可能出现 OOM 的问题 [#43728](https://github.com/pingcap/tidb/issues/43728) @[D3Hunter](https://github.com/D3Hunter) + - 修复 TiDB Lightning Grafana 面板缺失数据的问题 [#43357](https://github.com/pingcap/tidb/issues/43357) @[lichunzhu](https://github.com/lichunzhu) + - 修复未正确设置 `keyspace-name` 导致数据导入失败的问题 [#43684](https://github.com/pingcap/tidb/issues/43684) @[zeminzhou](https://github.com/zeminzhou) + - 修复当 Range 部分写入时，在某些情况下会跳过数据导入的问题 [#43768](https://github.com/pingcap/tidb/issues/43768) @[lance6716](https://github.com/lance6716) + +## 性能测试 + +如需了解 TiDB v7.1.0 的性能表现，你可以参考 TiDB Dedicated 集群的 [TPC-C 性能测试报告](https://docs.pingcap.com/tidbcloud/v7.1.0-performance-benchmarking-with-tpcc)和 [Sysbench 性能测试报告](https://docs.pingcap.com/tidbcloud/v7.1.0-performance-benchmarking-with-sysbench)（英文版）。 + +## 贡献者 + +感谢来自 TiDB 社区的贡献者们： + +- [blacktear23](https://github.com/blacktear23) +- [ethercflow](https://github.com/ethercflow) +- [hihihuhu](https://github.com/hihihuhu) +- [jiyfhust](https://github.com/jiyfhust) +- [L-maple](https://github.com/L-maple) +- [lqs](https://github.com/lqs) +- [pingandb](https://github.com/pingandb) +- [yorkhellen](https://github.com/yorkhellen) +- [yujiarista](https://github.com/yujiarista)（首次贡献者） diff --git a/releases/release-7.2.0.md b/releases/release-7.2.0.md new file mode 100644 index 000000000000..aa049790268e --- /dev/null +++ b/releases/release-7.2.0.md @@ -0,0 +1,328 @@ +--- +title: TiDB 7.2.0 Release Notes +summary: 了解 TiDB 7.2.0 版本的新功能、兼容性变更、改进提升，以及错误修复。 +--- + +# TiDB 7.2.0 Release Notes + +发版日期：2023 年 6 月 29 日 + +TiDB 版本：7.2.0 + +试用链接：[快速体验](https://docs.pingcap.com/zh/tidb/v7.2/quick-start-with-tidb) | [下载离线包](https://cn.pingcap.com/product-community/) + +在 7.2.0 版本中，你可以获得以下关键特性： + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
分类功能描述
可扩展性与性能资源组支持管理资源消耗超出预期的查询（实验特性）通过此功能，你可以更细粒度地管理执行时间超时的查询，根据查询的不同类型实现不同的行为。符合指定阈值的查询将按照你的设置被降低优先级或者终止执行。 +
TiFlash 支持 Pipeline 执行模型（实验特性）TiFlash 支持 Pipeline 执行模型，优化对线程资源的控制。
SQL支持新的 SQL 语句 IMPORT INTO，可以通过 TiDB 进行数据导入（实验特性）TiDB 引入了一个新的 SQL 语句 IMPORT INTO。该语句集成了 TiDB Lightning 的物理导入模式的能力，使你无需单独部署和管理 TiDB Lightning 即可导入数据文件到 TiDB 中。例如，通过该语句，你可以直接从 Amazon S3 或 Google Cloud Storage (GCS) 远程导入数据到 TiDB 中。
数据库管理与可观测性DDL 任务支持暂停和恢复操作（实验特性）该功能允许临时暂停资源密集型的 DDL 操作，例如索引创建，以节省资源并最小化对在线流量的影响。当资源许可时，你可以无缝恢复 DDL 任务，而无需取消和重新开始。该功能提高了资源利用率，改善了用户体验，并简化了 schema 更改过程。
+ +## 功能详情 + +### 性能 + +* 新增支持下推以下两个[窗口函数](/tiflash/tiflash-supported-pushdown-calculations.md)到 TiFlash [#7427](https://github.com/pingcap/tiflash/issues/7427) @[xzhangxian1008](https://github.com/xzhangxian1008) + + * `FIRST_VALUE` + * `LAST_VALUE` + +* TiFlash 支持 Pipeline 执行模型（实验特性）[#6518](https://github.com/pingcap/tiflash/issues/6518) @[SeaRise](https://github.com/SeaRise) + + 在 v7.2.0 版本之前，TiFlash 引擎中各个任务在执行时，需要自行申请线程资源。TiFlash 引擎通过控制任务数的方式限制线程资源使用，以避免线程资源超用，但并不能完全避免此问题。因此，在 v7.2.0 中，TiFlash 引入 Pipeline 执行模型，对所有线程资源进行统一管理，并对所有任务的执行进行统一调度，充分利用线程资源，同时避免资源超用。新增系统变量 [`tidb_enable_tiflash_pipeline_model`](/system-variables.md#tidb_enable_tiflash_pipeline_model-从-v720-版本开始引入) 用于设置是否启用 Pipeline 执行模型。 + + 更多信息，请参考[用户文档](/tiflash/tiflash-pipeline-model.md)。 + +* 降低 TiFlash 等待 schema 同步的时延 [#7630](https://github.com/pingcap/tiflash/issues/7630) @[hongyunyan](https://github.com/hongyunyan) + + 当表的 schema 发生变化时，TiFlash 需要及时从 TiKV 同步新的表结构信息。在 v7.2.0 之前，当 TiFlash 访问表数据时，只要检测到数据库中某张表的 schema 发生了变化，TiFlash 就会重新同步该数据库中所有表的 schema 信息。即使一张表没有 TiFlash 副本，TiFlash 也会同步该表的 schema 信息。当数据库中有大量表时，通过 TiFlash 只读取一张表的数据也可能因为需要等待所有表的 schema 信息同步完成而造成较高的时延。 + + 在 v7.2.0 中，TiFlash 优化了 schema 的同步机制，只同步拥有 TiFlash 副本的表的 schema 信息。当检测到某张有 TiFlash 副本的表的 schema 有变化时，TiFlash 只同步该表的 schema 信息，从而降低了 TiFlash 同步 schema 的时延，同时减少了 DDL 操作对于 TiFlash 同步数据的影响。该优化自动生效，无须任何设置。 + +* 提升统计信息收集的性能 [#44725](https://github.com/pingcap/tidb/issues/44725) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) + + TiDB v7.2.0 优化了统计信息的收集策略，会选择跳过一部分重复的信息，以及对优化器价值不高的信息，从而将统计信息收集的整体速度提升了 30%。这一改进有利于 TiDB 更及时地更新数据库对象的统计信息，生成更准确的执行计划，从而提升数据库整体性能。 + + 默认设置下，统计信息收集会跳过类型为 `JSON`、`BLOB`、`MEDIUMBLOB`、`LONGBLOB` 的列。你可以通过设置系统变量 [`tidb_analyze_skip_column_types`](/system-variables.md#tidb_analyze_skip_column_types-从-v720-版本开始引入) 来修改默认行为。当前支持设置跳过 `JSON`、`BLOB`、`TEXT` 这几个类型及其子类型。 + + 更多信息，请参考[用户文档](/system-variables.md#tidb_analyze_skip_column_types-从-v720-版本开始引入)。 + +* 提升数据和索引一致性检查的性能 [#43693](https://github.com/pingcap/tidb/issues/43693) @[wjhuang2016](https://github.com/wjhuang2016) + + [`ADMIN CHECK [TABLE|INDEX]`](/sql-statements/sql-statement-admin-check-table-index.md) 语句用于校验表中数据和对应索引的一致性。在 v7.2.0 中，TiDB 优化了数据一致性的校验方式，大幅提升了 [`ADMIN CHECK [TABLE|INDEX]`](/sql-statements/sql-statement-admin-check-table-index.md) 语句的执行效率，在大数据量场景中性能能够提升百倍。 + + 该优化默认开启（[`tidb_enable_fast_table_check`](/system-variables.md#tidb_enable_fast_table_check-从-v720-版本开始引入) 默认为 `ON`），可以大幅减少大型表数据一致性检查的时间，提升运维体验。 + + 更多信息，请参考[用户文档](/system-variables.md#tidb_enable_fast_table_check-从-v720-版本开始引入)。 + +### 稳定性 + +* 自动管理资源超出预期的查询（实验特性）[#43691](https://github.com/pingcap/tidb/issues/43691) @[Connor1996](https://github.com/Connor1996) @[CabinfeverB](https://github.com/CabinfeverB) @[glorv](https://github.com/glorv) @[HuSharp](https://github.com/HuSharp) @[nolouch](https://github.com/nolouch) + + 突发的 SQL 性能问题引发数据库整体性能下降，是数据库稳定性最常见的挑战。造成 SQL 性能问题的原因有很多，例如未经充分测试的新 SQL、数据量剧烈变化、执行计划突变等，这些问题很难从源头上完全规避。TiDB v7.2.0 增加了对资源超出预期的查询的管理能力，在上述问题发生时，能够快速降低影响范围。 + + 你可以针对某个资源组 (Resource Group) 设置查询的最长执行时间。当查询的执行时间超过设置值时，自动降低查询的优先级或者取消查询。你还可以设置在一段时间内通过文本或者执行计划立即匹配已经识别出的查询，从而避免问题查询的并发度太高时，在识别阶段就造成大量资源消耗的情况。 + + 对资源超出预期查询的自动管理能力，为你提供了有效的手段，快速应对突发的查询性能问题，降低对数据库整体性能的影响，从而提升数据库的稳定性。 + + 更多信息，请参考[用户文档](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries)。 + +* 增强根据历史执行计划创建绑定的能力 [#39199](https://github.com/pingcap/tidb/issues/39199) @[qw4990](https://github.com/qw4990) + + TiDB v7.2.0 进一步增强[根据历史执行计划创建绑定](/sql-plan-management.md#根据历史执行计划创建绑定)的能力，加强对复杂语句的解析和绑定，使绑定更稳固，并新增支持对以下 Hint 的绑定： + + - [`AGG_TO_COP()`](/optimizer-hints.md#agg_to_cop) + - [`LIMIT_TO_COP()`](/optimizer-hints.md#limit_to_cop) + - [`ORDER_INDEX`](/optimizer-hints.md#order_indext1_name-idx1_name--idx2_name- ) + - [`NO_ORDER_INDEX()`](/optimizer-hints.md#no_order_indext1_name-idx1_name--idx2_name-) + + 更多信息，请参考[用户文档](/sql-plan-management.md)。 + +* 提供 Optimizer Fix Controls 机制对优化器行为进行细粒度控制 [#43169](https://github.com/pingcap/tidb/issues/43169) @[time-and-fate](https://github.com/time-and-fate) + + 为了生成更合理的执行计划，TiDB 优化器的行为会随产品迭代而不断演进。但在某些特定场景下，这些变化可能引发性能回退。因此 TiDB 引入了 Optimizer Fix Controls 来控制优化器的一部分细粒度行为，你可以对一些新的变化进行回滚或控制。 + + 每一个可控的行为，都有一个与 Fix 号码对应的 GitHub Issue 进行说明。所有可控的行为列举在文档 [Optimizer Fix Controls](/optimizer-fix-controls.md) 中。通过设置系统变量 [`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-从-v710-版本开始引入) 可以为一个或多个行为设置目标值，进而达到行为控制的目的。 + + Optimizer Fix Controls 机制加强了你对 TiDB 优化器的细粒度管控能力，为升级过程引发的性能问题提供了新的修复手段，提升 TiDB 的稳定性。 + + 更多信息，请参考[用户文档](/optimizer-fix-controls.md)。 + +* 轻量统计信息初始化 GA [#42160](https://github.com/pingcap/tidb/issues/42160) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) + + 轻量统计信息初始化自 v7.2.0 成为正式功能。轻量级的统计信息初始化可以大幅减少启动时必须加载的统计信息的数量，从而提升启动过程中统计信息的加载速度。该功能提升了 TiDB 在复杂运行环境下的稳定性，并降低了部分 TiDB 节点重启对整体服务的影响。 + + 从 v7.2.0 起，新建的集群在启动阶段将默认加载轻量级统计信息，并在加载完成后再对外提供服务。对于从旧版本升级上来的集群，可通过修改 TiDB 配置项 [`lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-从-v710-版本开始引入) 和 [`force-init-stats`](/tidb-configuration-file.md#force-init-stats-从-v710-版本开始引入) 为 `true` 开启此功能。 + + 更多信息，请参考[用户文档](/statistics.md#统计信息的加载)。 + +### SQL 功能 + +* 支持 `CHECK` 约束 [#41711](https://github.com/pingcap/tidb/issues/41711) @[fzzf678](https://github.com/fzzf678) + + 从 v7.2.0 开始，你可以通过 `CHECK` 约束限制表中的一个或者多个字段值必须满足特定的条件。当为表添加 `CHECK` 约束后，在插入或者更新表的数据时，TiDB 会先检查约束条件是否满足，只允许满足约束的数据写入。 + + 该功能默认关闭，你可以通过将变量 [`tidb_enable_check_constraint`](/system-variables.md#tidb_enable_check_constraint-从-v720-版本开始引入) 设置为 `ON` 开启该功能。 + + 更多信息，请参考[用户文档](/constraints.md#check-约束)。 + +### 数据库管理 + +* DDL 任务支持暂停和恢复操作（实验特性）[#18015](https://github.com/pingcap/tidb/issues/18015) @[godouxm](https://github.com/godouxm) + + TiDB v7.2.0 之前的版本中，当 DDL 任务在执行期间遇到业务高峰时，为了减少对业务的影响，只能手动取消 DDL 任务。TiDB v7.2.0 引入了 DDL 任务的暂停和恢复功能，你可以在高峰时间点暂停 DDL 任务，等到业务高峰时间结束后再恢复 DDL 任务，从而避免了 DDL 操作对业务负载的影响。 + + 例如，可以通过如下 `ADMIN PAUSE DDL JOBS` 或 `ADMIN RESUME DDL JOBS` 语句暂停或者恢复多个 DDL 任务： + + ```sql + ADMIN PAUSE DDL JOBS 1,2; + ADMIN RESUME DDL JOBS 1,2; + ``` + + 更多信息，请参考[用户文档](/ddl-introduction.md#ddl-相关的命令介绍)。 + +### 数据迁移 + +* 引入新的 SQL 语句 `IMPORT INTO`，大幅提升数据导入效率（实验特性）[#42930](https://github.com/pingcap/tidb/issues/42930) @[D3Hunter](https://github.com/D3Hunter) + + `IMPORT INTO` 集成了 TiDB Lightning [物理导入模式](/tidb-lightning/tidb-lightning-physical-import-mode.md)的能力。通过该语句，你可以将 CSV、SQL 和 PARQUET 等格式的数据快速导入到 TiDB 的一张空表中。这种导入方式无需单独部署和管理 TiDB Lightning，在降低了数据导入难度的同时，大幅提升了数据导入效率。 + + 对于存储在 Amazon S3 或 GCS 的数据文件，在开启了[后端任务分布式框架](/tidb-distributed-execution-framework.md)后，`IMPORT INTO` 还支持将数据导入任务拆分成多个子任务，并将子任务调度到多个 TiDB 节点并行导入，进一步提升导入性能。 + + 更多信息，请参考[用户文档](/sql-statements/sql-statement-import-into.md)。 + +* TiDB Lightning 支持将字符集为 latin1 的源文件导入到 TiDB 中 [#44434](https://github.com/pingcap/tidb/issues/44434) @[lance6716](https://github.com/lance6716) + + 通过此功能，你可以使用 TiDB Lightning 将字符集为 latin1 的源文件直接导入到 TiDB 中。在 v7.2.0 之前，导入这样的文件需要额外的预处理或转换。从 v7.2.0 起，你只需在配置 TiDB Lightning 导入任务时指定 `character-set = "latin1"`，TiDB Lightning 就会在导入过程中自动处理字符集的转换，以确保数据的完整性和准确性。 + + 更多信息，请参考[用户文档](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-任务配置)。 + +## 兼容性变更 + +> **注意：** +> +> 以下为从 v7.1.0 升级至当前版本 (v7.2.0) 所需兼容性变更信息。如果从 v7.0.0 或之前版本升级到当前版本，可能也需要考虑和查看中间版本 release notes 中提到的兼容性变更信息。 + +### 系统变量 + +| 变量名 | 修改类型 | 描述 | +|--------|------------------------------|------| +| [`last_insert_id`](/system-variables.md#last_insert_id-从-v530-版本开始引入) | 修改 | 该变量的最大值从 `9223372036854775807` 修改为 `18446744073709551615`，和 MySQL 保持一致。 | +| [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) | 修改 | 经进一步的测试后，该变量默认值从 `OFF` 修改为 `ON`，即默认开启非 Prepare 语句执行计划缓存。 | +| [`tidb_remove_orderby_in_subquery`](/system-variables.md#tidb_remove_orderby_in_subquery-从-v610-版本开始引入) | 修改 | 经进一步的测试后，该变量默认值从 `OFF` 修改为 `ON`，即优化器改写会移除子查询中的 `ORDER BY` 子句。 | +| [`tidb_analyze_skip_column_types`](/system-variables.md#tidb_analyze_skip_column_types-从-v720-版本开始引入) | 新增 | 这个变量表示在执行 `ANALYZE` 命令收集统计信息时，跳过哪些类型的列的统计信息收集。该变量仅适用于 [`tidb_analyze_version = 2`](/system-variables.md#tidb_analyze_version-从-v510-版本开始引入) 的情况。使用 `ANALYZE TABLE t COLUMNS c1, ..., cn` 语法时，如果指定的列的类型在 `tidb_analyze_skip_column_types` 中，则不会收集该列的统计信息。 | +| [`tidb_enable_check_constraint`](/system-variables.md#tidb_enable_check_constraint-从-v720-版本开始引入) | 新增 | 这个变量用于控制 `CHECK` 约束功能是否开启。默认值 `OFF` 表示该功能默认关闭。 | +| [`tidb_enable_fast_table_check`](/system-variables.md#tidb_enable_fast_table_check-从-v720-版本开始引入) | 新增 | 这个变量用于控制是否使用基于校验和的方式来快速检查表中数据和索引的一致性。默认值 `ON` 表示该功能默认开启。 | +| [`tidb_enable_tiflash_pipeline_model`](/system-variables.md#tidb_enable_tiflash_pipeline_model-从-v720-版本开始引入) | 新增 | 这个变量用来控制是否启用 TiFlash 新的执行模型 [Pipeline Model](/tiflash/tiflash-pipeline-model.md)，默认值为 `OFF`，即关闭 Pipeline Model。 | +| [`tidb_expensive_txn_time_threshold`](/system-variables.md#tidb_expensive_txn_time_threshold-从-v720-版本开始引入) | 新增 | 控制打印 expensive transaction 日志的阈值时间，默认值是 600 秒。expensive transaction 日志会将尚未 COMMIT 或 ROLLBACK 且持续时间超过该阈值的事务的相关信息打印出来。 | + +### 配置文件参数 + +| 配置文件 | 配置项 | 修改类型 | 描述 | +| -------- | -------- | -------- | -------- | +| TiDB | [`lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-从-v710-版本开始引入) | 修改 | 经进一步的测试后，默认值从 `false` 修改为 `true`，表示 TiDB 启动时默认采用轻量级的统计信息初始化，以提高启动时统计信息初始化的效率。 | +| TiDB | [`force-init-stats`](/tidb-configuration-file.md#force-init-stats-从-v710-版本开始引入) | 修改 | 配合 `lite-init-stats`，默认值从 `false` 修改为 `true`，表示 TiDB 启动时会等到统计信息初始化完成后再对外提供服务。 | +| TiKV | [rocksdb.\[defaultcf\|writecf\|lockcf\].compaction-guard-min-output-file-size](/tikv-configuration-file.md#compaction-guard-min-output-file-size) | 修改 | 为减小 RocksDB 中 compaction 任务的数据量，该变量默认值从 `"8MB"` 修改为 `"1MB"`。 | +| TiKV | [rocksdb.\[defaultcf\|writecf\|lockcf\].optimize-filters-for-memory](/tikv-configuration-file.md#optimize-filters-for-memory-从-v720-版本开始引入) | 新增 | 控制是否生成能够最小化内存碎片的 Bloom/Ribbon filter。 | +| TiKV | [rocksdb.\[defaultcf\|writecf\|lockcf\].periodic-compaction-seconds](/tikv-configuration-file.md#periodic-compaction-seconds-从-v720-版本开始引入) | 新增 | 控制周期性 compaction 的时间，修改时间超过此值的 SST 文件将被选中进行 compaction，并被重新写入这些 SST 文件所在的层级。 | +| TiKV | [rocksdb.\[defaultcf\|writecf\|lockcf\].ribbon-filter-above-level](/tikv-configuration-file.md#ribbon-filter-above-level-从-v720-版本开始引入) | 新增 | 控制是否对于大于等于该值的 level 使用 Ribbon filter，对于小于该值的 level，使用非 block-based bloom filter。 | +| TiKV | [rocksdb.\[defaultcf\|writecf\|lockcf\].ttl](/tikv-configuration-file.md#ttl-从-v720-版本开始引入) | 新增 | 设置 SST 文件被自动选中执行 compaction 的 TTL 时间。更新时间超过 TTL 的 SST 文件将被选中并进行 compaction。 | +| TiDB Lightning | `send-kv-pairs` | 废弃 | 从 v7.2.0 版本开始，`send-kv-pairs` 不再生效。你可以使用新参数 [`send-kv-size`](/tidb-lightning/tidb-lightning-configuration.md) 来指定物理导入模式下向 TiKV 发送数据时一次请求的最大大小。 | +| TiDB Lightning | [`character-set`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-任务配置) | 修改 | 扩展支持导入的字符集，新增 `latin1` 选项，用于导入字符集为 latin1 的源文件。| +| TiDB Lightning | [`send-kv-size`](/tidb-lightning/tidb-lightning-configuration.md) | 新增 | 用于设置单次发送到 TiKV 的键值对的大小。当键值对的大小达到设定的阈值时，它们将被 TiDB Lightning 立即发送到 TiKV，避免在导入大宽表的时候由于 TiDB Lightning 节点内存积累键值对过多导致 OOM 的问题。通过调整该参数，你可以在内存使用和导入速度之间找到平衡，提高导入过程的稳定性和效率。| +| Data Migration | [`strict-optimistic-shard-mode`](/dm/feature-shard-merge-optimistic.md) | 新增 | 用于兼容历史版本 TiDB Data Migration v2.0 的分库分表同步 DDL 的行为。当用户选择乐观模式时，可以启用该参数，开启后，乐观模式下，同步任务遇到二类 DDL 时，整个任务会中断。在多个表的 DDL 变更有依赖关系的场景，可以及时中断同步，在用户手动处理完各表的 DDL 后，再继续同步数据，保障上下游数据的一致性。| +| TiCDC | [`sink.protocol`](/ticdc/ticdc-changefeed-config.md) | 修改 | 扩展下游类型是 Kafka 时的可选值范围：增加 `"open-protocol"`。用于指定编码消息时使用的格式协议。| +| TiCDC | [`sink.delete-only-output-handle-key-columns`](/ticdc/ticdc-changefeed-config.md) | 新增 | 指定 DELETE 事件的输出内容，只对 `"canal-json"` 和 `"open-protocol"` 协议有效。默认值为 `false`，即输出所有列的内容。当设置为 `true` 时，只输出主键列，或唯一索引列的内容。 | + +## 改进提升 + ++ TiDB + + - 优化构造索引扫描范围的逻辑，支持将一些复杂条件转化为索引扫描范围 [#41572](https://github.com/pingcap/tidb/issues/41572) [#44389](https://github.com/pingcap/tidb/issues/44389) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) + - 新增 `Stale Read OPS`、`Stale Read Traffic` 监控指标 [#43325](https://github.com/pingcap/tidb/issues/43325) @[you06](https://github.com/you06) + - 当 Stale Read 的 retry leader 遇到 lock 时，resolve lock 之后强制重试 leader，避免无谓开销 [#43659](https://github.com/pingcap/tidb/issues/43659) @[you06](https://github.com/you06) + - 使用估计时间计算 Stale Read ts，减少 Stale Read 的开销 [#44215](https://github.com/pingcap/tidb/issues/44215) @[you06](https://github.com/you06) + - 添加 long-running 事务日志和系统变量 [#41471](https://github.com/pingcap/tidb/issues/41471) @[crazycs520](https://github.com/crazycs520) + - 支持通过压缩的 MySQL 协议连接 TiDB，提升数据密集型查询在低网络质量下的性能，并节省带宽成本。该功能支持基于 `zlib` 和 `zstd` 的压缩算法 [#22605](https://github.com/pingcap/tidb/issues/22605) @[dveeden](https://github.com/dveeden) + - 支持将 `utf8` 和 `utf8mb3` 识别为旧的三字节 UTF-8 字符集编码，有助于将具有旧字符集编码的表从 MySQL 8.0 迁移到 TiDB [#26226](https://github.com/pingcap/tidb/issues/26226) @[dveeden](https://github.com/dveeden) + - 支持在 `UPDATE` 语句中使用 `:=` 进行赋值操作 [#44751](https://github.com/pingcap/tidb/issues/44751) @[CbcWestwolf](https://github.com/CbcWestwolf) + ++ TiKV + + - 支持通过 `pd.retry-interval` 配置在连接请求失败等场景下 PD 连接的重试间隔 [#14964](https://github.com/tikv/tikv/issues/14964) @[rleungx](https://github.com/rleungx) + - 优化资源管控调度算法，将全局的资源使用量作为调度因素 [#14604](https://github.com/tikv/tikv/issues/14604) @[Connor1996](https://github.com/Connor1996) + - 使用 gzip 压缩 `check_leader` 请求以减少流量 [#14553](https://github.com/tikv/tikv/issues/14553) @[you06](https://github.com/you06) + - 为 `check_leader` 请求增加相关监控项 [#14658](https://github.com/tikv/tikv/issues/14658) @[you06](https://github.com/you06) + - 详细记录 TiKV 处理写入命令过程中的时间信息 [#12362](https://github.com/tikv/tikv/issues/12362) @[cfzjywxk](https://github.com/cfzjywxk) + ++ PD + + - PD Leader 选举使用单独的 gRPC 连接，防止受到其他请求的影响 [#6403](https://github.com/tikv/pd/issues/6403) @[rleungx](https://github.com/rleungx) + - 默认开启 bucket split 以改善多 Region 的热点问题 [#6433](https://github.com/tikv/pd/issues/6433) @[bufferflies](https://github.com/bufferflies) + ++ Tools + + + Backup & Restore (BR) + + - 为外部存储 Azure Blob Storage 提供共享访问签名 (SAS) 的访问方式 [#44199](https://github.com/pingcap/tidb/issues/44199) @[Leavrth](https://github.com/Leavrth) + + + TiCDC + + - 优化同步到对象存储场景下发生 DDL 时存放数据文件目录的结构 [#8891](https://github.com/pingcap/tiflow/issues/8891) @[CharlesCheung96](https://github.com/CharlesCheung96) + - 在同步到 Kafka 场景下，支持 OAUTHBEARER 认证方式 [#8865](https://github.com/pingcap/tiflow/issues/8865) @[hi-rustin](https://github.com/hi-rustin) + - 在同步到 Kafka 场景下，对于 `DELETE` 操作，支持选择只输出 Handle Key [#9143](https://github.com/pingcap/tiflow/issues/9143) @[3AceShowHand](https://github.com/3AceShowHand) + + + TiDB Data Migration (DM) + + - 支持读取 MySQL 8.0 中的压缩 binlog 作为增量同步的数据源 [#6381](https://github.com/pingcap/tiflow/issues/6381) @[dveeden](https://github.com/dveeden) + + + TiDB Lightning + + - 优化导入数据过程中的重试机制，避免因 leader 切换而导致的错误 [#44478](https://github.com/pingcap/tidb/issues/44263) @[lance6716](https://github.com/lance6716) + - 数据导入完成后使用 SQL 方式校验 checksum，提升数据校验的稳定性 [#41941](https://github.com/pingcap/tidb/issues/41941) @[GMHDBJD](https://github.com/GMHDBJD) + - 优化导入宽表时 TiDB Lightning 发生 OOM 的问题 [#43853](https://github.com/pingcap/tidb/issues/43853) @[D3Hunter](https://github.com/D3Hunter) + +## 错误修复 + ++ TiDB + + - 修复使用 CTE 的查询导致 TiDB 卡住的问题 [#43749](https://github.com/pingcap/tidb/issues/43749) [#36896](https://github.com/pingcap/tidb/issues/36896) @[guo-shaoge](https://github.com/guo-shaoge) + - 修复 `min, max` 查询结果出错的问题 [#43805](https://github.com/pingcap/tidb/issues/43805) @[wshwsh12](https://github.com/wshwsh12) + - 修复 `SHOW PROCESSLIST` 语句无法显示子查询时间较长语句的事务的 TxnStart 的问题 [#40851](https://github.com/pingcap/tidb/issues/40851) @[crazycs520](https://github.com/crazycs520) + - 修复由于 Coprocessor task 中 `TxnScope` 缺失导致 Stale Read 全局优化不生效的问题 [#43365](https://github.com/pingcap/tidb/issues/43365) @[you06](https://github.com/you06) + - 修复 follower read 未处理 flashback 错误而进行重试，导致查询报错的问题 [#43673](https://github.com/pingcap/tidb/issues/43673) @[you06](https://github.com/you06) + - 修复 `ON UPDATE` 语句没有正确更新主键导致数据索引不一致的问题 [#44565](https://github.com/pingcap/tidb/issues/44565) @[zyguan](https://github.com/zyguan) + - 修改 `UNIX_TIMESTAMP()` 函数的上限为 `3001-01-19 03:14:07.999999 UTC`，与 MySQL 8.0.28+ 保持一致 [#43987](https://github.com/pingcap/tidb/issues/43987) @[YangKeao](https://github.com/YangKeao) + - 修复在 ingest 模式下创建索引失败的问题 [#44137](https://github.com/pingcap/tidb/issues/44137) @[tangenta](https://github.com/tangenta) + - 修复取消处于 rollback 状态的 DDL 任务导致相关元数据出错的问题 [#44143](https://github.com/pingcap/tidb/issues/44143) @[wjhuang2016](https://github.com/wjhuang2016) + - 修复 `memTracker` 配合 cursor fetch 使用导致内存泄漏的问题 [#44254](https://github.com/pingcap/tidb/issues/44254) @[YangKeao](https://github.com/YangKeao) + - 修复删除数据库导致 GC 推进慢的问题 [#33069](https://github.com/pingcap/tidb/issues/33069) @[tiancaiamao](https://github.com/tiancaiamao) + - 修复分区表在 Index Join 的 probe 阶段找不到对应行而报错的问题 [#43686](https://github.com/pingcap/tidb/issues/43686) @[AilinKid](https://github.com/AilinKid) @[mjonss](https://github.com/mjonss) + - 修复在创建分区表时使用 `SUBPARTITION` 没有警告提醒的问题 [#41198](https://github.com/pingcap/tidb/issues/41198) [#41200](https://github.com/pingcap/tidb/issues/41200) @[mjonss](https://github.com/mjonss) + - 修复执行时间超过 `MAX_EXECUTION_TIME` 的 query 被 kill 时的报错信息和 MySQL 不一致的问题 [#43031](https://github.com/pingcap/tidb/issues/43031) @[dveeden](https://github.com/dveeden) + - 修复 `LEADING` hint 不支持查询块别名 (query block alias) 的问题 [#44645](https://github.com/pingcap/tidb/issues/44645) @[qw4990](https://github.com/qw4990) + - 修复 `LAST_INSERT_ID()` 函数的返回类型，从 VARCHAR 变更为 LONGLONG，与 MySQL 一致 [#44574](https://github.com/pingcap/tidb/issues/44574) @[Defined2014](https://github.com/Defined2014) + - 修复在带有非关联子查询的语句中使用公共表表达式 (CTE) 可能导致结果错误的问题 [#44051](https://github.com/pingcap/tidb/issues/44051) @[winoros](https://github.com/winoros) + - 修复 Join Reorder 可能会造成 Outer Join 结果错误的问题 [#44314](https://github.com/pingcap/tidb/issues/44314) @[AilinKid](https://github.com/AilinKid) + - 修复 `PREPARE stmt FROM "ANALYZE TABLE xxx"` 会被 `tidb_mem_quota_query` kill 掉的问题 [#44320](https://github.com/pingcap/tidb/issues/44320) @[chrysan](https://github.com/chrysan) + ++ TiKV + + - 修复处理 stale 悲观锁冲突时事务返回值不正确的问题 [#13298](https://github.com/tikv/tikv/issues/13298) @[cfzjywxk](https://github.com/cfzjywxk) + - 修复内存悲观锁可能导致 Flashback 失败和数据不一致的问题 [#13303](https://github.com/tikv/tikv/issues/13303) @[JmPotato](https://github.com/JmPotato) + - 修复处理过期请求时 fair lock 的正确性问题 [#13298](https://github.com/tikv/tikv/issues/13298) @[cfzjywxk](https://github.com/cfzjywxk) + - 修复 autocommit 和 point get replica read 可能破坏线性一致性的问题 [#14715](https://github.com/tikv/tikv/issues/14715) @[cfzjywxk](https://github.com/cfzjywxk) + ++ PD + + - 修复在特殊情况下冗余副本无法自动修复的问题 [#6573](https://github.com/tikv/pd/issues/6573) @[nolouch](https://github.com/nolouch) + ++ TiFlash + + - 修复查询在 Join build 侧数据非常大，且包含许多小型字符串类型列时，消耗的内存可能会超过实际需要的问题 [#7416](https://github.com/pingcap/tiflash/issues/7416) @[yibin87](https://github.com/yibin87) + ++ Tools + + + Backup & Restore (BR) + + - 修复某些情况下误报 `checksum mismatch` 的问题 [#44472](https://github.com/pingcap/tidb/issues/44472) @[Leavrth](https://github.com/Leavrth) + - 修复某些情况下误报 `resolved lock timeout` 的问题 [#43236](https://github.com/pingcap/tidb/issues/43236) @[YuJuncen](https://github.com/YuJuncen) + - 修复在恢复统计信息的时候可能会 panic 的问题 [#44490](https://github.com/pingcap/tidb/issues/44490) @[tangenta](https://github.com/tangenta) + + + TiCDC + + - 修复在某些特殊情况下 Resolved TS 不能正常推进的问题 [#8963](https://github.com/pingcap/tiflow/issues/8963) @[CharlesCheung96](https://github.com/CharlesCheung96) + - 修复使用 Avro 或 CSV 协议场景下 `UPDATE` 操作不能输出旧值的问题 [#9086](https://github.com/pingcap/tiflow/issues/9086) @[3AceShowHand](https://github.com/3AceShowHand) + - 修复同步到 Kafka 场景下，读取下游 Metadata 太频繁导致下游压力过大的问题 [#8959](https://github.com/pingcap/tiflow/issues/8959) @[hi-rustin](https://github.com/hi-rustin) + - 修复同步到 TiDB 或 MySQL 场景下，频繁设置下游双向复制相关变量导致下游日志过多的问题 [#9180](https://github.com/pingcap/tiflow/issues/9180) @[asddongmen](https://github.com/asddongmen) + - 修复 PD 节点宕机导致 TiCDC 节点重启的问题 [#8868](https://github.com/pingcap/tiflow/issues/8868) @[asddongmen](https://github.com/asddongmen) + - 修复 TiCDC 同步到 Kafka-on-Pulsar 时不能正确建立连接的问题 [#8892](https://github.com/pingcap/tiflow/issues/8892) @[hi-rustin](https://github.com/hi-rustin) + + + TiDB Lightning + + - 修复开启 `experimental.allow-expression-index` 且默认值是 UUID 时导致 TiDB Lightning panic 的问题 [#44497](https://github.com/pingcap/tidb/issues/44497) @[lichunzhu](https://github.com/lichunzhu) + - 修复划分数据文件时任务退出导致 TiDB Lightning panic 的问题 [#43195](https://github.com/pingcap/tidb/issues/43195) @[lance6716](https://github.com/lance6716) + +## 贡献者 + +感谢来自 TiDB 社区的贡献者们： + +- [asjdf](https://github.com/asjdf) +- [blacktear23](https://github.com/blacktear23) +- [Cavan-xu](https://github.com/Cavan-xu) +- [darraes](https://github.com/darraes) +- [demoManito](https://github.com/demoManito) +- [dhysum](https://github.com/dhysum) +- [HappyUncle](https://github.com/HappyUncle) +- [jiyfhust](https://github.com/jiyfhust) +- [L-maple](https://github.com/L-maple) +- [nyurik](https://github.com/nyurik) +- [SeigeC](https://github.com/SeigeC) +- [tangjingyu97](https://github.com/tangjingyu97) \ No newline at end of file diff --git a/releases/release-notes.md b/releases/release-notes.md index dfb2776f845f..a132f4a08be0 100644 --- a/releases/release-notes.md +++ b/releases/release-notes.md @@ -7,6 +7,14 @@ aliases: ['/docs-cn/dev/releases/release-notes/','/docs-cn/dev/releases/rn/'] TiDB 历史版本发布声明如下： +## 7.2 + +- [7.2.0-DMR](/releases/release-7.2.0.md): 2023-06-29 + +## 7.1 + +- [7.1.0](/releases/release-7.1.0.md): 2023-05-31 + ## 7.0 - [7.0.0-DMR](/releases/release-7.0.0.md): 2023-03-30 @@ -17,6 +25,8 @@ TiDB 历史版本发布声明如下： ## 6.5 +- [6.5.3](/releases/release-6.5.3.md): 2023-06-14 +- [6.5.2](/releases/release-6.5.2.md): 2023-04-21 - [6.5.1](/releases/release-6.5.1.md): 2023-03-10 - [6.5.0](/releases/release-6.5.0.md): 2022-12-29 @@ -34,6 +44,7 @@ TiDB 历史版本发布声明如下： ## 6.1 +- [6.1.6](/releases/release-6.1.6.md): 2023-04-12 - [6.1.5](/releases/release-6.1.5.md): 2023-02-28 - [6.1.4](/releases/release-6.1.4.md): 2023-02-08 - [6.1.3](/releases/release-6.1.3.md): 2022-12-05 diff --git a/releases/release-timeline.md b/releases/release-timeline.md index 23906465dda9..52130a2bee77 100644 --- a/releases/release-timeline.md +++ b/releases/release-timeline.md @@ -9,6 +9,11 @@ summary: 了解 TiDB 的版本发布时间线。 | 版本 | 发布日期 | | :--- | :--- | +| [7.2.0-DMR](/releases/release-7.2.0.md) | 2023-06-29 | +| [6.5.3](/releases/release-6.5.3.md) | 2023-06-14 | +| [7.1.0](/releases/release-7.1.0.md) | 2023-05-31 | +| [6.5.2](/releases/release-6.5.2.md) | 2023-04-21 | +| [6.1.6](/releases/release-6.1.6.md) | 2023-04-12 | | [7.0.0-DMR](/releases/release-7.0.0.md) | 2023-03-30 | | [6.5.1](/releases/release-6.5.1.md) | 2023-03-10 | | [6.1.5](/releases/release-6.1.5.md) | 2023-02-28 | diff --git a/resources/cdnfresh.txt b/resources/cdnfresh.txt index 96f3f9d1dc6b..e64e981c8c4a 100644 --- a/resources/cdnfresh.txt +++ b/resources/cdnfresh.txt @@ -2,8 +2,12 @@ https://download.pingcap.org/tidb-dev-zh-manual.pdf https://download.pingcap.org/tidb-dev-en-manual.pdf https://download.pingcap.org/tidb-stable-zh-manual.pdf https://download.pingcap.org/tidb-stable-en-manual.pdf +https://download.pingcap.org/tidb-v7.2-zh-manual.pdf +https://download.pingcap.org/tidb-v7.2-en-manual.pdf https://download.pingcap.org/tidb-v7.0-zh-manual.pdf https://download.pingcap.org/tidb-v7.0-en-manual.pdf +https://download.pingcap.org/tidb-v6.5-zh-manual.pdf +https://download.pingcap.org/tidb-v6.5-en-manual.pdf https://download.pingcap.org/tidb-v6.6-zh-manual.pdf https://download.pingcap.org/tidb-v6.6-en-manual.pdf https://download.pingcap.org/tidb-v6.4-zh-manual.pdf @@ -26,6 +30,8 @@ https://download.pingcap.org/tidb-in-kubernetes-dev-zh-manual.pdf https://download.pingcap.org/tidb-in-kubernetes-dev-en-manual.pdf https://download.pingcap.org/tidb-in-kubernetes-stable-zh-manual.pdf https://download.pingcap.org/tidb-in-kubernetes-stable-en-manual.pdf +https://download.pingcap.org/tidb-in-kubernetes-v1.5-zh-manual.pdf +https://download.pingcap.org/tidb-in-kubernetes-v1.5-en-manual.pdf https://download.pingcap.org/tidb-in-kubernetes-v1.3-zh-manual.pdf https://download.pingcap.org/tidb-in-kubernetes-v1.3-en-manual.pdf https://download.pingcap.org/tidb-in-kubernetes-v1.2-zh-manual.pdf diff --git a/scale-tidb-using-tiup.md b/scale-tidb-using-tiup.md index 4b123768be8b..9d1d052813f2 100644 --- a/scale-tidb-using-tiup.md +++ b/scale-tidb-using-tiup.md @@ -37,12 +37,10 @@ TiDB 集群可以在不中断线上服务的情况下进行扩容和缩容。 > > - 从 TiUP v1.0.0 开始，扩容配置会继承原集群配置的 global 部分。 -在 scale-out.yaml 文件添加扩容拓扑配置： - -{{< copyable "shell-regular" >}} +在 scale-out.yml 文件添加扩容拓扑配置： ```shell -vi scale-out.yaml +vi scale-out.yml ``` {{< copyable "" >}} @@ -53,8 +51,8 @@ tidb_servers: ssh_port: 22 port: 4000 status_port: 10080 - deploy_dir: /data/deploy/install/deploy/tidb-4000 - log_dir: /data/deploy/install/log/tidb-4000 + deploy_dir: /tidb-deploy/tidb-4000 + log_dir: /tidb-deploy/tidb-4000/log ``` TiKV 配置文件参考： @@ -67,9 +65,9 @@ tikv_servers: ssh_port: 22 port: 20160 status_port: 20180 - deploy_dir: /data/deploy/install/deploy/tikv-20160 - data_dir: /data/deploy/install/data/tikv-20160 - log_dir: /data/deploy/install/log/tikv-20160 + deploy_dir: /tidb-deploy/tikv-20160 + data_dir: /tidb-data/tikv-20160 + log_dir: /tidb-deploy/tikv-20160/log ``` PD 配置文件参考： @@ -83,12 +81,12 @@ pd_servers: name: pd-1 client_port: 2379 peer_port: 2380 - deploy_dir: /data/deploy/install/deploy/pd-2379 - data_dir: /data/deploy/install/data/pd-2379 - log_dir: /data/deploy/install/log/pd-2379 + deploy_dir: /tidb-deploy/pd-2379 + data_dir: /tidb-data/pd-2379 + log_dir: /tidb-deploy/pd-2379/log ``` -可以使用 `tiup cluster edit-config ` 查看当前集群的配置信息，因为其中的 `global` 和 `server_configs` 参数配置默认会被 `scale-out.yaml` 继承，因此也会在 `scale-out.yaml` 中生效。 +可以使用 `tiup cluster edit-config ` 查看当前集群的配置信息，因为其中的 `global` 和 `server_configs` 参数配置默认会被 `scale-out.yml` 继承，因此也会在 `scale-out.yml` 中生效。 ### 2. 执行扩容命令 @@ -103,7 +101,7 @@ pd_servers: {{< copyable "shell-regular" >}} ```shell - tiup cluster check scale-out.yaml --cluster --user root [-p] [-i /home/root/.ssh/gcp_rsa] + tiup cluster check scale-out.yml --cluster --user root [-p] [-i /home/root/.ssh/gcp_rsa] ``` （2）自动修复集群存在的潜在风险： @@ -111,7 +109,7 @@ pd_servers: {{< copyable "shell-regular" >}} ```shell - tiup cluster check scale-out.yaml --cluster --apply --user root [-p] [-i /home/root/.ssh/gcp_rsa] + tiup cluster check scale-out.yml --cluster --apply --user root [-p] [-i /home/root/.ssh/gcp_rsa] ``` （3）执行 scale-out 命令扩容 TiDB 集群： @@ -119,12 +117,12 @@ pd_servers: {{< copyable "shell-regular" >}} ```shell - tiup cluster scale-out scale-out.yaml [-p] [-i /home/root/.ssh/gcp_rsa] + tiup cluster scale-out scale-out.yml [-p] [-i /home/root/.ssh/gcp_rsa] ``` 以上操作示例中： -- 扩容配置文件为 `scale-out.yaml`。 +- 扩容配置文件为 `scale-out.yml`。 - `--user root` 表示通过 root 用户登录到目标主机完成集群部署，该用户需要有 ssh 到目标机器的权限，并且在目标机器有 sudo 权限。也可以用其他有 ssh 和 sudo 权限的用户完成部署。 - [-i] 及 [-p] 为可选项，如果已经配置免密登录目标机，则不需填写。否则选择其一即可，[-i] 为可登录到目标机的 root 用户（或 --user 指定的其他用户）的私钥，也可使用 [-p] 交互式输入该用户的密码。 @@ -161,9 +159,9 @@ tiup cluster display > 1. 首先确认当前 TiDB 的版本支持 TiFlash，否则需要先升级 TiDB 集群至 v5.0 以上版本。 > 2. 执行 `tiup ctl:v pd -u http://: config set enable-placement-rules true` 命令，以开启 PD 的 Placement Rules 功能。或通过 [pd-ctl](/pd-control.md) 执行对应的命令。 -### 1. 添加节点信息到 scale-out.yaml 文件 +### 1. 添加节点信息到 scale-out.yml 文件 -编写 scale-out.yaml 文件，添加该 TiFlash 节点信息（目前只支持 ip，不支持域名）： +编写 scale-out.yml 文件，添加该 TiFlash 节点信息（目前只支持 ip，不支持域名）： {{< copyable "" >}} @@ -177,7 +175,7 @@ tiflash_servers: {{< copyable "shell-regular" >}} ```shell -tiup cluster scale-out scale-out.yaml +tiup cluster scale-out scale-out.yml ``` > **注意：** @@ -208,9 +206,9 @@ tiup cluster display 如果要添加 TiCDC 节点，IP 地址为 10.0.1.3、10.0.1.4，可以按照如下步骤进行操作。 -### 1. 添加节点信息到 scale-out.yaml 文件 +### 1. 添加节点信息到 scale-out.yml 文件 -编写 scale-out.yaml 文件： +编写 scale-out.yml 文件： {{< copyable "" >}} @@ -218,10 +216,10 @@ tiup cluster display cdc_servers: - host: 10.0.1.3 gc-ttl: 86400 - data_dir: /data/deploy/install/data/cdc-8300 + data_dir: /tidb-data/cdc-8300 - host: 10.0.1.4 gc-ttl: 86400 - data_dir: /data/deploy/install/data/cdc-8300 + data_dir: /tidb-data/cdc-8300 ``` ### 2. 运行扩容命令 @@ -229,7 +227,7 @@ cdc_servers: {{< copyable "shell-regular" >}} ```shell -tiup cluster scale-out scale-out.yaml +tiup cluster scale-out scale-out.yml ``` > **注意：** @@ -278,11 +276,11 @@ tiup cluster display ``` ``` -Starting /root/.tiup/components/cluster/v1.11.3/cluster display +Starting /root/.tiup/components/cluster/v1.12.3/cluster display TiDB Cluster: -TiDB Version: v7.0.0 +TiDB Version: v7.2.0 ID Role Host Ports Status Data Dir Deploy Dir diff --git a/security-compatibility-with-mysql.md b/security-compatibility-with-mysql.md index 014bd1da7034..0ce3e1e33637 100644 --- a/security-compatibility-with-mysql.md +++ b/security-compatibility-with-mysql.md @@ -122,8 +122,10 @@ TiDB 目前支持的身份验证方式可在以下的表格中查找到。服务 | `auth_socket` | 是（5.3.0 版本起） | | `tidb_sm3_password` | 是（6.3.0 版本起） | | `tidb_auth_token` | 是（6.4.0 版本起） | +| `authentication_ldap_sasl` | 是（7.1.0 版本起） | +| `authentication_ldap_simple` | 是（7.1.0 版本起） | | TLS 证书 | 是 | -| LDAP | 否 | +| LDAP | 是（7.1.0 版本起） | | PAM | 否 | | ed25519 (MariaDB) | 否 | | GSSAPI (MariaDB) | 否 | diff --git a/smooth-upgrade-tidb.md b/smooth-upgrade-tidb.md new file mode 100644 index 000000000000..98f3cff758b9 --- /dev/null +++ b/smooth-upgrade-tidb.md @@ -0,0 +1,58 @@ +--- +title: 平滑升级 TiDB +summary: 本文介绍支持无需手动取消 DDL 的平滑升级集群功能。 +--- + +# 平滑升级 TiDB + +> **警告：** +> +> 平滑升级目前为实验特性。 + +本文档介绍 TiDB 的平滑升级集群功能，支持无需手动取消 DDL 的操作。 + +从 v7.1.0 起，当将 TiDB 升级至更高的版本时，TiDB 支持平滑升级功能，取消了升级过程中的限制，提供更平滑的升级体验。此功能默认开启，且无开关控制。 + +## 功能简介 + +TiDB 引入平滑升级功能前，对于升级过程中的 DDL 操作有如下限制(可以参考[使用 TiUP 升级 TiDB](/upgrade-tidb-using-tiup.md#使用-tiup-升级-tidb)中警告部分)： + +- 在升级过程中执行 DDL 操作，TiDB 可能会出现未定义的行为。 +- 在 DDL 操作执行过程中升级 TiDB，TiDB 可能会出现未定义的行为。 + +引入平滑升级后，TiDB 升级过程不再受上述限制。 + +升级过程中，TiDB 会自动进行以下操作，无需用户干预： + +1. 暂停用户的 DDL 操作。 +2. 执行升级过程中的系统 DDL 操作。 +3. 恢复被暂停的用户的 DDL 操作。 +4. 完成升级。 + +其中，恢复的 DDL job 仍会按升级前的顺序执行。 + +## 使用限制 + +使用平滑升级功能时，需要注意以下限制。 + +### 用户操作限制 + +* 在升级前，如果集群中存在正在处理的 canceling DDL job，即有正在被处理的 DDL job 被用户取消了，由于处于 canceling 状态的 job 无法被 `pause`，TiDB 会尝试重试。如果重试失败，会报错并退出升级。 + +* 在使用 TiUP 进行升级的场景下，由于 TiUP 升级存在超时时间，如果在升级之前集群中有大量 DDL（超过 300 条）正在处理队列中等待执行，则此次升级可能会失败。 + +* 在升级过程中，不允许以下操作： + + * 对系统表（`mysql.*`、`information_schema.*`、`performance_schema.*`、`metrics_schema.*`）进行 DDL 操作。 + + * 执行手动取消 DDL job 操作：`ADMIN CANCEL DDL JOBS job_id [, job_id] ...;`。 + + * 导入数据。 + +### 工具使用限制 + +在升级过程中，不支持使用以下工具： + +* BR：BR 可能会将处于 paused 状态的 DDL 拷贝到 TiDB 中，而此状态的 DDL 不能自动 resume，可能导致后续 DDL 卡住的情况。 + +* DM 和 TiCDC：如果在升级过程中使用 DM 和 TiCDC 向 TiDB 导入 SQL，并且其中包含 DDL 操作，则该导入操作会被阻塞，并可能出现未定义错误。 diff --git a/sql-non-prepared-plan-cache.md b/sql-non-prepared-plan-cache.md index 0fd0d34a3df7..688dda532209 100644 --- a/sql-non-prepared-plan-cache.md +++ b/sql-non-prepared-plan-cache.md @@ -13,16 +13,22 @@ summary: 介绍 TiDB 中非 Prepare 语句执行计划缓存的原理、使用 ## 原理 -Non-Prepared Plan Cache 为会话级别，并且与 [Prepared Plan Cache](/sql-prepared-plan-cache.md) 相互独立，缓存的计划互不影响。Non-Prepared Plan Cache 功能的基本原理如下： +Non-Prepared Plan Cache 为会话级别，并且与 [Prepared Plan Cache](/sql-prepared-plan-cache.md) 共用一个缓存。Non-Prepared Plan Cache 功能的基本原理如下： 1. 开启 Non-Prepared Plan Cache 后，TiDB 首先根据 AST（抽象语法树）对查询进行参数化。例如，将 `SELECT * FROM t WHERE b < 10 AND a = 1` 参数化为 `SELECT * FROM t WHERE b < ? and a = ?`。 -2. 然后，使用参数化后的查询在 Non-Prepared Plan Cache 中查找。 +2. 然后，使用参数化后的查询在 Plan Cache 中查找。 3. 如果能找到可以直接复用的计划，则直接使用，并跳过整个优化过程。 4. 否则，继续进行查询优化，并在最后将生成的计划放回到缓存中，以便下次复用。 ## 使用方法 -目前，你可以通过 [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) 开启或关闭 Non-Prepared Plan Cache。同时，你还可以通过 [`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size) 来控制 Non-Prepared Plan Cache 的大小。当缓存的计划数超过 `tidb_non_prepared_plan_cache_size` 时，TiDB 会使用 LRU (Least Recently Used) 策略进行逐出。 +目前，你可以通过 [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) 开启或关闭 Non-Prepared Plan Cache。同时，你还可以通过 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-从-v710-版本开始引入) 来控制 Plan Cache 的大小。当缓存的计划数超过 `tidb_session_plan_cache_size` 时，TiDB 会使用 LRU (Least Recently Used) 策略进行逐出。 + +从 v7.1.0 开始，你可以通过变量 [`tidb_plan_cache_max_plan_size`](/system-variables.md#tidb_plan_cache_max_plan_size-从-v710-版本开始引入) 来设置可以缓存的计划的最大大小，默认为 2 MB。超过该值的执行计划将不会被缓存到 Plan Cache 中。 + +> **注意：** +> +> `tidb_session_plan_cache_size` 定义的内存会被 Prepared 和 Non-Prepared Plan Cache 共享。如果集群已经开启 Prepared Plan Cache，那么开启 Non-Prepared Plan Cache 可能降低原先 Prepared Plan Cache 的命中率。 ## 示例 @@ -37,7 +43,7 @@ Non-Prepared Plan Cache 为会话级别，并且与 [Prepared Plan Cache](/sql-p 2. 开启 Non-Prepared Plan Cache： ```sql - SET tidb_enable_non_prepared_plan_cache = true; + SET tidb_enable_non_prepared_plan_cache = ON; ``` 3. 依次执行以下查询： @@ -66,24 +72,36 @@ Non-Prepared Plan Cache 为会话级别，并且与 [Prepared Plan Cache](/sql-p ## 限制 +### 缓存限制 + TiDB 对参数化后形式相同的查询，只能缓存一个计划。例如，对于 `SELECT * FROM t WHERE a < 1` 和 `SELECT * FROM t WHERE a < 100000` 这两个查询语句，由于参数化后的形式相同，均为 `SELECT * FROM t WHERE a < ?`，因此它们会共用一个计划。 如果由此产生性能问题，可以使用 `ignore_plan_cache()` Hint 忽略计划缓存中的计划，让优化器每次重新为 SQL 生成执行计划。如果无法修改 SQL，可以通过创建 binding 来解决，例如 `CREATE BINDING FOR SELECT ... USING SELECT /*+ ignore_plan_cache() */ ...`。 +### 使用限制 + 由于上述风险以及执行计划缓存只在简单查询上有明显收益（如果查询较为复杂，查询本身执行时间较长，使用执行计划缓存收益不大），TiDB 目前对 Non-Prepared Plan Cache 的生效范围有严格的限制。具体限制如下： - [Prepared Plan Cache](/sql-prepared-plan-cache.md) 不支持的查询或者计划，Non-Prepared Plan Cache 也不支持。 -- 目前仅支持包含 `Scan`、`Selection` 或 `Projection` 算子的单表的点查或范围查询，例如 `SELECT * FROM t WHERE a < 10 AND b in (1, 2)`。 -- 不支持包含 `Agg`、`Limit`、`Window` 或 `Sort` 等复杂算子的查询。 -- 不支持包含非范围查询条件，例如： - - 不支持 `LIKE`，例如 `c LIKE 'c%'` - - 不支持 `+` 操作，例如 `a+1 < 2` +- 不支持包含 `Window` 或 `Having` 的查询。 +- 不支持包含三张表及以上 `Join` 或子查询的查询。 +- 不支持 `ORDER BY` 或者 `GROUP BY` 后直接带数字或者表达式的查询，如 `ORDER BY 1`、`GROUP BY a+1`。仅支持 `ORDER BY column_name` 和 `GROUP BY column_name`。 - 不支持过滤条件中包含 `JSON`、`ENUM`、`SET` 或 `BIT` 类型的列的查询，例如 `SELECT * FROM t WHERE json_col = '{}'`。 - 不支持过滤条件中出现 `NULL` 值的查询，例如 `SELECT * FROM t WHERE a is NULL`。 -- 不支持参数化后参数个数超过 50 个的查询，例如 `SELECT * FROM t WHERE a in (1, 2, 3, ... 51)`。 +- 不支持参数化后参数个数超过 200 个的查询，例如 `SELECT * FROM t WHERE a in (1, 2, 3, ... 201)`。 - 不支持访问分区表、虚拟列、临时表、视图、或内存表的查询，例如 `SELECT * FROM INFORMATION_SCHEMA.COLUMNS`，其中 `COLUMNS` 为 TiDB 内存表。 -- 不支持带有 Hint、子查询、Lock 的查询。 -- 不支持 DML 语句。 +- 不支持带有 Hint 或有 Binding 的查询。 +- 默认不支持 DML 语句或包含 `FOR UPDATE` 的查询语句。若要启用支持，你可以执行 `SET tidb_enable_non_prepared_plan_cache_for_dml = ON`。 + +开启此功能后，优化器会对查询进行快速判断，如果不满足 Non-Prepared Plan Cache 的支持条件，则会走正常的优化流程。 + +## 性能收益 + +在内部测试中，开启 Non-Prepared Plan Cache 功能在大多数 TP 场景下可以获得显著的性能收益。但是它也有代价，其自身也有一些额外的性能开销，包括判断查询是否支持、对查询进行参数化等。如果此功能不支持负载中的大多数查询，开启此功能反而可能影响性能。 + +此时，你需要观察 Grafana 监控中的 **Queries Using Plan Cache OPS** 面板中的 `non-prepared` 指标和 **Plan Cache Miss OPS** 面板中的 `non-prepared-unsupported` 指标。如果大多数查询都无法被支持，只有少部分查询能命中 Plan Cache，此时你可以关闭此功能。 + +![non-prepared-unsupported](/media/non-prepapred-plan-cache-unsupprot.png) ## 诊断 @@ -94,7 +112,7 @@ TiDB 对参数化后形式相同的查询，只能缓存一个计划。例如， 执行下面 `EXPLAIN FORMAT='plan_cache'` 语句，查看查询是否能够命中： ```sql -EXPLAIN FORMAT='plan_cache' SELECT * FROM t WHERE a+2 < 10; +EXPLAIN FORMAT='plan_cache' SELECT * FROM (SELECT a+1 FROM t1) t; ``` 输出结果示例如下： @@ -112,11 +130,11 @@ SHOW warnings; 输出结果示例如下： ```sql -+---------+------+-----------------------------------------------------------------------+ -| Level | Code | Message | -+---------+------+-----------------------------------------------------------------------+ -| Warning | 1105 | skip non-prep plan cache: query has some unsupported binary operation | -+---------+------+-----------------------------------------------------------------------+ ++---------+------+-------------------------------------------------------------------------------+ +| Level | Code | Message | ++---------+------+-------------------------------------------------------------------------------+ +| Warning | 1105 | skip non-prepared plan-cache: queries that have sub-queries are not supported | ++---------+------+-------------------------------------------------------------------------------+ 1 row in set (0.00 sec) ``` @@ -139,7 +157,7 @@ SHOW warnings; 2. 打开 Non-Prepared Plan Cache 开关： ```sql - SET @@tidb_enable_non_prepared_plan_cache=1; + SET @@tidb_enable_non_prepared_plan_cache = ON; ``` 3. 依次执行以下三个查询： @@ -153,7 +171,7 @@ SHOW warnings; 4. 查询 `statements_summary` 表查看查询命中缓存的情况： ```sql - SELECT digest_text, query_sample_text, exec_count, plan_in_cache, plan_cache_hits FROM INFORMATION_SCHEMA.STATEMENTS_SUMMARY WHERE digest_text LIKE '%SELECT * FROM %'; + SELECT digest_text, query_sample_text, exec_count, plan_in_cache, plan_cache_hits FROM INFORMATION_SCHEMA.STATEMENTS_SUMMARY WHERE query_sample_text LIKE '%SELECT * FROM %'; ``` 输出结果如下： @@ -162,7 +180,7 @@ SHOW warnings; +---------------------------------+------------------------------------------+------------+---------------+-----------------+ | digest_text | query_sample_text | exec_count | plan_in_cache | plan_cache_hits | +---------------------------------+------------------------------------------+------------+---------------+-----------------+ - | SELECT * FROM `t` WHERE `a` < ? | SELECT * FROM t WHERE a<1 [arguments: 1] | 3 | 1 | 2 | + | SELECT * FROM `t` WHERE `a` < ? | SELECT * FROM t WHERE a<1 | 3 | 1 | 2 | +---------------------------------+------------------------------------------+------------+---------------+-----------------+ 1 row in set (0.01 sec) ``` diff --git a/sql-plan-management.md b/sql-plan-management.md index ec14dba57512..143bdd6c78a2 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -177,10 +177,11 @@ CREATE BINDING FOR SELECT * FROM t WHERE a > 1 USING SELECT * FROM t use index(i 如需将 SQL 语句的执行计划固定为之前使用过的执行计划，可以使用 `plan_digest` 为该 SQL 语句绑定一个历史的执行计划。相比于使用 SQL 创建绑定的方式，此方式更加简便。 -目前，根据历史执行计划创建绑定有一些限制： +以下为根据历史执行计划创建绑定的注意事项： - 该功能是根据历史的执行计划生成 hint 而实现的绑定，历史的执行计划来源是 [Statement Summary Tables](/statement-summary-tables.md)，因此在使用此功能之前需开启系统变量 [`tidb_enable_stmt_summary`](/system-variables.md#tidb_enable_stmt_summary-从-v304-版本开始引入)。 -- 对于带有子查询的查询、访问 TiFlash 的查询、3 张表或更多表进行 Join 的查询，目前还不支持通过历史执行计划进行绑定。 +- 对于包含子查询的查询、访问 TiFlash 的查询、3 张表或更多表进行 Join 的查询，目前还不支持通过历史执行计划进行绑定。 +- 原执行计划对应 SQL 语句中的 hint 也会被应用在创建的绑定中，如执行 `SELECT /*+ max_execution_time(1000) */ * FROM t` 后，使用其 `plan_digest` 创建的绑定中会带上 `max_execution_time(1000)`。 使用方式: @@ -432,6 +433,8 @@ SHOW binding_cache status; 自动绑定会对符合捕获条件的查询进行捕获，为符合条件的查询生成相应的绑定。通常用于[升级时的计划回退防护](#升级时的计划回退防护)。 +Plan Baseline 是一组被允许用于 SQL 语句优化器的可接受计划。在典型的应用场景中，TiDB 仅在验证计划性能良好后才将其添加到 Baseline 中。这些计划包含优化器重新生成执行计划所需的所有信息（例如，SQL 计划标识符、提示集、绑定值、优化器环境）。 + ### 使用方式 通过将 `tidb_capture_plan_baselines` 的值设置为 `on`（其默认值为 `off`）可以打开自动捕获绑定功能。 diff --git a/sql-plan-replayer.md b/sql-plan-replayer.md index bb21b1ea44a8..c7e2d78b5945 100644 --- a/sql-plan-replayer.md +++ b/sql-plan-replayer.md @@ -31,6 +31,7 @@ TiDB 根据 `sql-statement` 整理出以下集群现场信息： - `sql-statement` 中所包含的表结构 - `sql-statement` 中所包含表的统计信息 - `EXPLAIN [ANALYZE] sql-statement` 的结果 +- 优化器进行查询优化的一些内部步骤的记录 > **注意：** > @@ -49,7 +50,7 @@ analyze table t; plan replayer dump explain select * from t; ``` -`PLAN REPLAYER DUMP` 会将以上信息打包整理成 `ZIP` 文件，并返回文件标识作为执行结果。该文件为一次性文件，被下载后 TiDB 会将其删除。 +`PLAN REPLAYER DUMP` 会将以上信息打包整理成 `ZIP` 文件，并返回文件标识作为执行结果。 > **注意：** > @@ -241,7 +242,7 @@ mysql> SELECT * FROM mysql.plan_replayer_status; > **注意：** > -> `PLAN REPLAYER CAPTURE` 的结果文件最多会在 TiDB 集群中保存一个小时，超时后 TiDB 会将其删除。 +> `PLAN REPLAYER CAPTURE` 的结果文件最多会在 TiDB 集群中保存一周，超时后 TiDB 会将其删除。 ## 使用 `PLAN REPLAYER CONTINUOUS CAPTURE` diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index 1d04f263eda5..e7f3bbc24076 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -1,19 +1,21 @@ --- -title: 执行计划缓存 +title: Prepare 语句执行计划缓存 aliases: ['/docs-cn/dev/sql-prepare-plan-cache/','zh/tidb/dev/sql-prepare-plan-cache'] --- -# 执行计划缓存 +# Prepare 语句执行计划缓存 -TiDB 支持对 `Prepare` / `Execute` 请求的执行计划缓存。其中包括以下两种形式的预处理语句： +TiDB 支持对 `Prepare`/`Execute` 请求的执行计划缓存。其中包括以下两种形式的预处理语句： - 使用 `COM_STMT_PREPARE` 和 `COM_STMT_EXECUTE` 的协议功能； -- 执行 `Prepare` / `Execute` SQL 语句查询； +- 执行 `Prepare`/`Execute` SQL 语句查询； TiDB 优化器对这两类查询的处理是一样的：`Prepare` 时将参数化的 SQL 查询解析成 AST（抽象语法树），每次 `Execute` 时根据保存的 AST 和具体的参数值生成执行计划。 当开启执行计划缓存后，每条 `Prepare` 语句的第一次 `Execute` 会检查当前查询是否可以使用执行计划缓存，如果可以则将生成的执行计划放进一个由 LRU 链表构成的缓存中；在后续的 `Execute` 中，会先从缓存中获取执行计划，并检查是否可用，如果获取和检查成功则跳过生成执行计划这一步，否则重新生成执行计划并放入缓存中。 +对于某些非 `PREPARE` 语句，TiDB 可以像 `Prepare`/`Execute` 语句一样支持执行计划缓存，详情请参考[非 Prepare 语句执行计划缓存](/sql-non-prepared-plan-cache.md)。 + 在当前版本中，当 `Prepare` 语句符合以下条件任何一条，查询或者计划不会被缓存： - `SELECT`、`UPDATE`、`INSERT`、`DELETE`、`Union`、`Intersect`、`Except` 以外的 SQL 语句； @@ -23,7 +25,7 @@ TiDB 优化器对这两类查询的处理是一样的：`Prepare` 时将参数 - 包含 `ignore_plan_cache` 这一 Hint 的查询，例如 `select /*+ ignore_plan_cache() */ * from t`； - 包含除 `?` 外其他变量（即系统变量或用户自定义变量）的查询，例如 `select * from t where a>? and b>@x`； - 查询包含无法被缓存函数。目前不能被缓存的函数有：`database()`、`current_user`、`current_role`、`user`、`connection_id`、`last_insert_id`、`row_count`、`version`、`like`； -- `LIMIT` 后面带一个变量 (`LIMIT ?`) 且变量值大于 10000 的执行计划不缓存； +- `LIMIT` 后面带有变量（例如 `LIMIT ?` 或 `LIMIT 10, ?`）且变量值大于 10000 的执行计划不缓存； - `?` 直接在 `Order By` 后的查询，如 `Order By ?`，此时 `?` 表示根据 `Order By` 后第几列排序，排序列不同的查询使用同一个计划可能导致错误结果，故不缓存；如果是普通表达式，如 `Order By a+?` 则会缓存； - `?` 紧跟在 `Group by` 后的查询，如 `Group By ?`，此时 `?` 表示根据 `Group By` 后第几列聚合，聚合列不同的查询使用同一个计划可能导致错误结果，故不缓存；如果是普通表达式，如 `Group By a+?` 则会缓存； - `?` 出现在窗口函数 `Window Frame` 定义中的查询，如 `(partition by year order by sale rows ? preceding)`；如果 `?` 出现在窗口函数的其他位置，则会缓存； @@ -31,7 +33,7 @@ TiDB 优化器对这两类查询的处理是一样的：`Prepare` 时将参数 - 会访问 `TiFlash` 的计划不会被缓存； - 大部分情况下计划中含有 `TableDual` 的计划将将不会被缓存，除非当前执行的 `Prepare` 语句不含参数，则对应的 `TableDual` 计划可以被缓存。 -LRU 链表是设计成 session 级别的缓存，因为 `Prepare` / `Execute` 不能跨 session 执行。LRU 链表的每个元素是一个 key-value 对，value 是执行计划，key 由如下几部分组成： +LRU 链表是设计成 session 级别的缓存，因为 `Prepare`/`Execute` 不能跨 session 执行。LRU 链表的每个元素是一个 key-value 对，value 是执行计划，key 由如下几部分组成： - 执行 `Execute` 时所在数据库的名字； - `Prepare` 语句的标识符，即紧跟在 `PREPARE` 关键字后的名字； @@ -40,7 +42,7 @@ LRU 链表是设计成 session 级别的缓存，因为 `Prepare` / `Execute` - 当前设置的时区，即系统变量 `time_zone` 的值； - 系统变量 `sql_select_limit` 的值； -key 中任何一项变动（如切换数据库，重命名 `Prepare` 语句，执行 DDL，或修改 SQL Mode / `time_zone` 的值），或 LRU 淘汰机制触发都会导致 `Execute` 时无法命中执行计划缓存。 +key 中任何一项变动（如切换数据库、重命名 `Prepare` 语句、执行 DDL、修改 SQL Mode/`time_zone` 的值）、或 LRU 淘汰机制触发都会导致 `Execute` 时无法命中执行计划缓存。 成功从缓存中获取到执行计划后，TiDB 会先检查执行计划是否依然合法，如果当前 `Execute` 在显式事务里执行，并且引用的表在事务前序语句中被修改，而缓存的执行计划对该表访问不包含 `UnionScan` 算子，则它不能被执行。 @@ -58,9 +60,9 @@ key 中任何一项变动（如切换数据库，重命名 `Prepare` 语句， > **注意：** > -> 执行计划缓存功能仅针对 `Prepare` / `Execute` 请求，对普通查询无效。 +> 执行计划缓存功能仅针对 `Prepare`/`Execute` 请求，对普通查询无效。 -在开启了执行计划缓存功能后，可以通过 session 级别的系统变量 `last_plan_from_cache` 查看上一条 `Execute` 语句是否使用了缓存的执行计划，例如： +在开启了执行计划缓存功能后，可以通过 SESSION 级别的系统变量 [`last_plan_from_cache`](/system-variables.md#last_plan_from_cache-从-v40-版本开始引入) 查看上一条 `Execute` 语句是否使用了缓存的执行计划，例如： {{< copyable "sql" >}} @@ -99,7 +101,7 @@ MySQL [test]> select @@last_plan_from_cache; 1 row in set (0.00 sec) ``` -如果发现某一组 `Prepare` / `Execute` 由于执行计划缓存导致了非预期行为，可以通过 SQL Hint `ignore_plan_cache()` 让该组语句不使用缓存。还是用上述的 `stmt` 为例： +如果发现某一组 `Prepare`/`Execute` 由于执行计划缓存导致了非预期行为，可以通过 SQL Hint `ignore_plan_cache()` 让该组语句不使用缓存。还是用上述的 `stmt` 为例： {{< copyable "sql" >}} @@ -152,7 +154,7 @@ mysql> SHOW WARNINGS; -- 查看查询计划无法被缓存的原因 mysql> PREPARE st FROM 'SELECT * FROM t WHERE a SET @a='1'; +mysql> SET @a='1'; Query OK, 0 rows affected (0.00 sec) mysql> EXECUTE st USING @a; -- 该优化中进行了非 INT 类型到 INT 类型的转换，产生的执行计划可能随着参数变化而存在风险，因此 TiDB 不缓存该计划 @@ -181,10 +183,12 @@ Grafana 中 `Plan Cache Memory Usage` 和 `Plan Cache Plan Num` 监控如下图 ![grafana_panels](/media/planCache-memoryUsage-planNum-panels.png) -目前可以通过变量 `tidb_prepared_plan_cache_size` 来设置每个 `SESSION` 最多缓存的计划数量，针对不同的环境，推荐的设置如下，你可以结合监控进行调整： +从 v7.1.0 开始，你可以通过变量 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-从-v710-版本开始引入) 来设置每个 `SESSION` 最多缓存的计划数量。针对不同的环境，推荐的设置如下，你可以结合监控进行调整： + +- TiDB Server 实例内存阈值 <= 64 GiB 时，`tidb_session_plan_cache_size = 50` +- TiDB Server 实例内存阈值 > 64 GiB 时，`tidb_session_plan_cache_size = 100` -- TiDB Server 实例内存阈值 <= 64 GiB 时，`tidb_prepared_plan_cache_size = 50` -- TiDB Server 实例内存阈值 > 64 GiB 时，`tidb_prepared_plan_cache_size = 100` +从 v7.1.0 开始，你可以通过变量 [`tidb_plan_cache_max_plan_size`](/system-variables.md#tidb_plan_cache_max_plan_size-从-v710-版本开始引入) 来设置可以缓存的计划的最大大小，默认为 2 MB。超过该值的执行计划将不会被缓存到 Plan Cache 中。 当 TiDB Server 的内存余量小于一定阈值时，会触发 Plan Cache 的内存保护机制，此时会对一些缓存的计划进行逐出。 diff --git a/sql-statements/sql-statement-admin-pause-ddl.md b/sql-statements/sql-statement-admin-pause-ddl.md new file mode 100644 index 000000000000..8c0d4dc5c116 --- /dev/null +++ b/sql-statements/sql-statement-admin-pause-ddl.md @@ -0,0 +1,51 @@ +--- +title: ADMIN PAUSE DDL JOBS +summary: TiDB 数据库中 ADMIN PAUSE DDL JOBS 的使用概况。 +--- + +# ADMIN PAUSE DDL JOBS + +`ADMIN PAUSE DDL` 语句用于暂停当前正在运行的 DDL 作业。可以通过 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md) 语句获取 DDL 作业的 `job_id`。 + +该语句可用于暂停已经发起但未执行完成的 DDL 任务。成功暂停后，执行 DDL 任务的 SQL 语句不会立即返回，表现为正在执行。如果尝试暂停一个已经完成的 DDL 任务，会在 `RESULT` 列看到 `DDL Job:90 not found` 的错误，表示该任务已从 DDL 等待队列中被移除。 + +> **注意：** +> +> + 该操作可以暂停 DDL 作业，但除版本升级外，其他操作和环境变更（例如机器重启、集群重启）不会暂停 DDL 作业。 +> + 版本升级时，正在运行的 DDL 作业将被暂停，同时在升级过程中发起的 DDL 作业也将被暂停。升级结束后，所有已暂停的 DDL 作业将恢复执行。升级过程中的操作为自动进行，详情查阅 [TiDB 平滑升级](/smooth-upgrade-tidb.md)。 +> + 该操作可以同时暂停多个 DDL 作业，可以通过 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md) 语句来获取 DDL 作业的 `job_id`。 +> + 如果希望暂停的作业已经执行完毕或接近执行完毕，暂停操作将失败。 + +> **警告：** +> +> 该功能目前为实验特性，不建议在生产环境中使用。该功能可能会在未事先通知的情况下发生变化或删除。如果发现 bug，请在 GitHub 上提 [issue](https://github.com/pingcap/tidb/issues) 反馈。 + +## 语法图 + +```ebnf+diagram +AdminStmt ::= + 'ADMIN' ( 'SHOW' ( 'DDL' ( 'JOBS' Int64Num? WhereClauseOptional | 'JOB' 'QUERIES' NumList )? | TableName 'NEXT_ROW_ID' | 'SLOW' AdminShowSlow ) | 'CHECK' ( 'TABLE' TableNameList | 'INDEX' TableName Identifier ( HandleRange ( ',' HandleRange )* )? ) | 'RECOVER' 'INDEX' TableName Identifier | 'CLEANUP' ( 'INDEX' TableName Identifier | 'TABLE' 'LOCK' TableNameList ) | 'CHECKSUM' 'TABLE' TableNameList | 'CANCEL' 'DDL' 'JOBS' NumList | 'PAUSE' 'DDL' 'JOBS' NumList | 'RESUME' 'DDL' 'JOBS' NumList | 'RELOAD' ( 'EXPR_PUSHDOWN_BLACKLIST' | 'OPT_RULE_BLACKLIST' | 'BINDINGS' ) | 'PLUGINS' ( 'ENABLE' | 'DISABLE' ) PluginNameList | 'REPAIR' 'TABLE' TableName CreateTableStmt | ( 'FLUSH' | 'CAPTURE' | 'EVOLVE' ) 'BINDINGS' ) + +NumList ::= + Int64Num ( ',' Int64Num )* +``` + +## 示例 + +可以通过 `ADMIN PAUSE DDL JOBS` 语句暂停当前正在运行的 DDL 作业，并返回对应作业是否暂停成功，直到被 `ADMIN RESUME DDL JOBS` 恢复： + +```sql +ADMIN PAUSE DDL JOBS job_id [, job_id] ...; +``` + +如果暂停失败，会显示失败的具体原因。 + +## MySQL 兼容性 + +`ADMIN PAUSE DDL JOBS` 语句是 TiDB 对 MySQL 语法的扩展。 + +## 另请参阅 + +* [`ADMIN SHOW DDL [JOBS|QUERIES]`](/sql-statements/sql-statement-admin-show-ddl.md) +* [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md) +* [`ADMIN RESUME DDL`](/sql-statements/sql-statement-admin-resume-ddl.md) diff --git a/sql-statements/sql-statement-admin-resume-ddl.md b/sql-statements/sql-statement-admin-resume-ddl.md new file mode 100644 index 000000000000..d34c01ebf2c6 --- /dev/null +++ b/sql-statements/sql-statement-admin-resume-ddl.md @@ -0,0 +1,52 @@ +--- +title: ADMIN RESUME DDL JOBS +summary: TiDB 数据库中 ADMIN RESUME DDL 的使用概况。 +--- + +# ADMIN RESUME DDL JOBS + +`ADMIN RESUME DDL` 语句用于恢复当前处于暂停中的 DDL 作业。可以通过 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md) 语句获取 DDL 作业的 `job_id`。 + +该语句可用于恢复处于暂停中的 DDL 任务。成功恢复后，执行 DDL 任务的 SQL 语句会一直表现为正在执行。如果尝试恢复已经完成的 DDL 任务，会在 `RESULT` 列看到 `DDL Job:90 not found` 的错误，表示该任务已从 DDL 等待队列中被移除。 + +> **注意：** +> +> + 该操作可以恢复已被暂停的 DDL 作业。 +> + 版本升级时，正在运行的 DDL 作业将被暂停，同时在升级过程中发起的 DDL 作业也将被暂停。升级结束后，所有已暂停的 DDL 作业将恢复执行。升级过程中的操作为自动进行，详情查阅 [TiDB 平滑升级](/smooth-upgrade-tidb.md)。 +> + 该操作可以同时恢复多个 DDL 作业，可以通过 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md) 语句来获取 DDL 作业的 `job_id`。 +> + 处于非暂停状态中的作业无法被恢复，操作将失败。 +> + 如果重复恢复同一个 DDL 作业，会报错 `Error Number: 8261`。 + +> **警告：** +> +> 该功能目前为实验特性，不建议在生产环境中使用。该功能可能会在未事先通知的情况下发生变化或删除。如果发现 bug，请在 GitHub 上提 [issue](https://github.com/pingcap/tidb/issues) 反馈。 + +## 语法图 + +```ebnf+diagram +AdminStmt ::= + 'ADMIN' ( 'SHOW' ( 'DDL' ( 'JOBS' Int64Num? WhereClauseOptional | 'JOB' 'QUERIES' NumList )? | TableName 'NEXT_ROW_ID' | 'SLOW' AdminShowSlow ) | 'CHECK' ( 'TABLE' TableNameList | 'INDEX' TableName Identifier ( HandleRange ( ',' HandleRange )* )? ) | 'RECOVER' 'INDEX' TableName Identifier | 'CLEANUP' ( 'INDEX' TableName Identifier | 'TABLE' 'LOCK' TableNameList ) | 'CHECKSUM' 'TABLE' TableNameList | 'CANCEL' 'DDL' 'JOBS' NumList | 'PAUSE' 'DDL' 'JOBS' NumList | 'RESUME' 'DDL' 'JOBS' NumList | 'RELOAD' ( 'EXPR_PUSHDOWN_BLACKLIST' | 'OPT_RULE_BLACKLIST' | 'BINDINGS' ) | 'PLUGINS' ( 'ENABLE' | 'DISABLE' ) PluginNameList | 'REPAIR' 'TABLE' TableName CreateTableStmt | ( 'FLUSH' | 'CAPTURE' | 'EVOLVE' ) 'BINDINGS' ) + +NumList ::= + Int64Num ( ',' Int64Num )* +``` + +## 示例 + +可以通过 `ADMIN RESUME DDL JOBS` 语句恢复当前处于暂停中的 DDL 作业，并返回对应作业是否恢复执行： + +```sql +ADMIN RESUME DDL JOBS job_id [, job_id] ...; +``` + +如果恢复失败，会显示失败的具体原因。 + +## MySQL 兼容性 + +`ADMIN RESUME DDL` 语句是 TiDB 对 MySQL 语法的扩展。 + +## 另请参阅 + +* [`ADMIN SHOW DDL [JOBS|QUERIES]`](/sql-statements/sql-statement-admin-show-ddl.md) +* [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md) +* [`ADMIN PAUSE DDL`](/sql-statements/sql-statement-admin-pause-ddl.md) diff --git a/sql-statements/sql-statement-admin-show-ddl.md b/sql-statements/sql-statement-admin-show-ddl.md index 8e7f41c84553..0931ee8f6a9e 100644 --- a/sql-statements/sql-statement-admin-show-ddl.md +++ b/sql-statements/sql-statement-admin-show-ddl.md @@ -64,7 +64,8 @@ ADMIN SHOW DDL; - `synced`：表示该操作已经执行成功，且所有 TiDB 实例都已经同步该状态。 - `rollback done`：表示该操作执行失败，回滚完成。 - `rollingback`：表示该操作执行失败，正在回滚。 - - `cancelling`：表示正在取消该操作。这个状态只有在用 `ADMIN CANCEL DDL JOBS` 命令取消 DDL 任务时才会出现。 + - `cancelling`：表示正在取消该操作。这个状态只有在用 [`ADMIN CANCEL DDL JOBS`](/sql-statements/sql-statement-admin-cancel-ddl.md) 命令取消 DDL 任务时才会出现。 + - `paused`：表示 DDL 已被暂停运行。这个状态只有在用 [`ADMIN PAUSED DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md) 命令暂停 DDL 任务时才会出现。可以通过 [`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md) 命令进行恢复运行。 示例如下： @@ -190,3 +191,5 @@ ADMIN SHOW DDL JOB QUERIES LIMIT 3 OFFSET 4; # Retrieve rows 5-7 ## 另请参阅 * [ADMIN CANCEL DDL](/sql-statements/sql-statement-admin-cancel-ddl.md) +* [ADMIN PAUSE DDL](/sql-statements/sql-statement-admin-pause-ddl.md) +* [ADMIN RESUME DDL](/sql-statements/sql-statement-admin-resume-ddl.md) diff --git a/sql-statements/sql-statement-admin.md b/sql-statements/sql-statement-admin.md index 7ea9007c34b7..045f3db793ea 100644 --- a/sql-statements/sql-statement-admin.md +++ b/sql-statements/sql-statement-admin.md @@ -18,6 +18,8 @@ aliases: ['/docs-cn/dev/sql-statements/sql-statement-admin/','/docs-cn/dev/refer | 语句 | 功能描述 | |------------------------------------------------------------------------------------------|-----------------------------| | [`ADMIN CANCEL DDL JOBS`](/sql-statements/sql-statement-admin-cancel-ddl.md) | 取消当前正在运行的 DDL 作业 | +| [`ADMIN PAUSE DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md) | 暂停当前正在运行的 DDL 作业 | +| [`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md) | 恢复当前处于暂停中的 DDL 作业 | | [`ADMIN CHECKSUM TABLE`](/sql-statements/sql-statement-admin-checksum-table.md) | 计算表中所有行和索引的 CRC64 校验和 | | [ADMIN CHECK [TABLE\|INDEX]](/sql-statements/sql-statement-admin-check-table-index.md) | 校验表中数据和对应索引的一致性 | | [ADMIN SHOW DDL [JOBS\|QUERIES]](/sql-statements/sql-statement-admin-show-ddl.md) | 显示有关当前正在运行或最近完成的 DDL 作业的详细信息| @@ -211,7 +213,8 @@ ADMIN SHOW DDL JOBS 5 WHERE state != 'synced' AND db_name = 'test'; * `synced`：表示该操作已经执行成功，且所有 TiDB 实例都已经同步该状态。 * `rollback done`：表示该操作执行失败，回滚完成。 * `rollingback`：表示该操作执行失败，正在回滚。 - * `cancelling`：表示正在取消该操作。这个状态只有在用 `ADMIN CANCEL DDL JOBS` 命令取消 DDL 作业时才会出现。 + * `cancelling`：表示正在取消该操作。这个状态只有在用 [`ADMIN CANCEL DDL JOBS`](/sql-statements/sql-statement-admin-cancel-ddl.md) 命令取消 DDL 作业时才会出现。 + * `paused`：表示 DDL 已被暂停运行。这个状态只有在用 [`ADMIN PAUSED DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md) 命令暂停 DDL 任务时才会出现。可以通过 [`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md) 命令进行恢复运行。 ## MySQL 兼容性 diff --git a/sql-statements/sql-statement-alter-resource-group.md b/sql-statements/sql-statement-alter-resource-group.md index d36ee2f9b735..ef7012b34600 100644 --- a/sql-statements/sql-statement-alter-resource-group.md +++ b/sql-statements/sql-statement-alter-resource-group.md @@ -10,29 +10,52 @@ summary: TiDB 数据库中 ALTER RESOURCE GROUP 的使用概况。 ## 语法图 ```ebnf+diagram -AlterResourceGroupStmt: +AlterResourceGroupStmt ::= "ALTER" "RESOURCE" "GROUP" IfExists ResourceGroupName ResourceGroupOptionList IfExists ::= ('IF' 'EXISTS')? -ResourceGroupName: +ResourceGroupName ::= Identifier -ResourceGroupOptionList: +ResourceGroupOptionList ::= DirectResourceGroupOption | ResourceGroupOptionList DirectResourceGroupOption | ResourceGroupOptionList ',' DirectResourceGroupOption -DirectResourceGroupOption: +DirectResourceGroupOption ::= "RU_PER_SEC" EqOpt stringLit | "PRIORITY" EqOpt ResourceGroupPriorityOption | "BURSTABLE" +| "BURSTABLE" EqOpt Boolean +| "QUERY_LIMIT" EqOpt '(' ResourceGroupRunawayOptionList ')' +| "QUERY_LIMIT" EqOpt '(' ')' +| "QUERY_LIMIT" EqOpt "NULL" -ResourceGroupPriorityOption: - LOW +ResourceGroupPriorityOption ::= + LOW | MEDIUM | HIGH + +ResourceGroupRunawayOptionList ::= + DirectResourceGroupRunawayOption +| ResourceGroupRunawayOptionList DirectResourceGroupRunawayOption +| ResourceGroupRunawayOptionList ',' DirectResourceGroupRunawayOption + +DirectResourceGroupRunawayOption ::= + "EXEC_ELAPSED" EqOpt stringLit +| "ACTION" EqOpt ResourceGroupRunawayActionOption +| "WATCH" EqOpt ResourceGroupRunawayWatchOption "DURATION" EqOpt stringLit + +ResourceGroupRunawayWatchOption ::= + EXACT +| SIMILAR + +ResourceGroupRunawayActionOption ::= + DRYRUN +| COOLDOWN +| KILL ``` TiDB 支持以下 `DirectResourceGroupOption`, 其中 [Request Unit (RU)](/tidb-resource-control.md#什么是-request-unit-ru) 是 TiDB 对 CPU、IO 等系统资源统一抽象的单位。 @@ -42,10 +65,12 @@ TiDB 支持以下 `DirectResourceGroupOption`, 其中 [Request Unit (RU)](/tidb- | `RU_PER_SEC` | 每秒 RU 填充的速度 | `RU_PER_SEC = 500` 表示此资源组每秒回填 500 个 RU。 | | `PRIORITY` | 任务在 TiKV 上处理的绝对优先级 | `PRIORITY = HIGH` 表示优先级高。若未指定则默认为 `MEDIUM`。 | | `BURSTABLE` | 允许对应的资源组超出配额后使用空余的系统资源。 | +| `QUERY_LIMIT` | 当查询执行满足该条件时，识别该查询为 Runaway Query 并执行相应的操作 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')` 表示当执行时间超过 60 秒后识别为 Runaway Query，对该查询执行终止操作，并在 10 分钟内对同样的 SQL 直接执行终止操作。`QUERY_LIMIT=()` 或 `QUERY_LIMIT=NULL` 则表示不进行 Runaway 控制。具体参数介绍参见[管理资源消耗超出预期的查询 (Runaway Queries)](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries)。 ｜ > **注意：** > > `ALTER RESOURCE GROUP` 语句只能在全局变量 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-从-v660-版本开始引入) 参数设置为 `ON` 时才能执行。 +> `ALTER RESOURCE GROUP` 语句支持以增量方式修改，未指定的参数保持不变。但其中 `QUERY_LIMIT` 作为一个整体，无法部分修改其中的参数。 ## 示例 @@ -74,18 +99,19 @@ SELECT * FROM information_schema.resource_groups WHERE NAME ='rg1'; ``` ```sql -+------+------------+----------+-----------+ -| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | -+------+------------+----------+-----------+ -| rg1 | 100 | MEDIUM | YES | -+------+------------+----------+-----------+ ++------+------------+----------+-----------+-------------+ +| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT | ++------+------------+----------+-----------+-------------+ +| rg1 | 100 | MEDIUM | YES | NULL | ++------+------------+----------+-----------+-------------+ 1 rows in set (1.30 sec) ``` ```sql ALTER RESOURCE GROUP rg1 RU_PER_SEC = 200 - PRIORITY = LOW; + PRIORITY = LOW + QUERY_LIMIT = (EXEC_ELAPSED='1s' ACTION=COOLDOWN WATCH=EXACT DURATION '30s'); ``` ```sql @@ -97,11 +123,11 @@ SELECT * FROM information_schema.resource_groups WHERE NAME ='rg1'; ``` ```sql -+------+------------+----------+-----------+ -| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | -+------+------------+----------+-----------+ -| rg1 | 200 | LOW | NO | -+------+------------+----------+-----------+ ++------+------------+----------+-----------+----------------------------------------------------+ +| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT | ++------+------------+----------+-----------+----------------------------------------------------+ +| rg1 | 200 | LOW | YES | EXEC_ELAPSED=1s, ACTION=COOLDOWN, WATCH=EXACT[30s] | ++------+------------+----------+-----------+----------------------------------------------------+ 1 rows in set (1.30 sec) ``` diff --git a/sql-statements/sql-statement-alter-user.md b/sql-statements/sql-statement-alter-user.md index 080874cdd45a..8a9602669cec 100644 --- a/sql-statements/sql-statement-alter-user.md +++ b/sql-statements/sql-statement-alter-user.md @@ -62,7 +62,9 @@ SHOW CREATE USER 'newuser'; 1 row in set (0.00 sec) ``` -{{< copyable "sql" >}} +### 修改用户基本信息 + +修改用户 `newuser` 的密码： ```sql ALTER USER 'newuser' IDENTIFIED BY 'newnewpassword'; @@ -87,7 +89,7 @@ SHOW CREATE USER 'newuser'; 1 row in set (0.00 sec) ``` -{{< copyable "sql" >}} +锁定用户 `newuser`： ```sql ALTER USER 'newuser' ACCOUNT LOCK; @@ -165,6 +167,8 @@ ALTER USER 'newuser' PASSWORD REUSE INTERVAL 90 DAY; Query OK, 0 rows affected (0.02 sec) ``` +### 修改用户绑定的资源组 + 通过 `ALTER USER ... RESOURCE GROUP` 修改用户 `newuser` 的资源组到 `rg1`： ```sql @@ -175,6 +179,37 @@ ALTER USER 'newuser' RESOURCE GROUP rg1; Query OK, 0 rows affected (0.02 sec) ``` +查看当前用户绑定的资源组： + +```sql +SELECT USER, JSON_EXTRACT(User_attributes, "$.resource_group") FROM mysql.user WHERE user = "newuser"; +``` + +``` ++---------+---------------------------------------------------+ +| USER | JSON_EXTRACT(User_attributes, "$.resource_group") | ++---------+---------------------------------------------------+ +| newuser | "rg1" | ++---------+---------------------------------------------------+ +1 row in set (0.02 sec) +``` + +取消用户绑定的资源组，即将用户绑定到 `default` 资源组。 + +```sql +ALTER USER 'newuser' RESOURCE GROUP `default`; +SELECT USER, JSON_EXTRACT(User_attributes, "$.resource_group") FROM mysql.user WHERE user = "newuser"; +``` + +``` ++---------+---------------------------------------------------+ +| USER | JSON_EXTRACT(User_attributes, "$.resource_group") | ++---------+---------------------------------------------------+ +| newuser | "default" | ++---------+---------------------------------------------------+ +1 row in set (0.02 sec) +``` + ## 另请参阅 * [Security Compatibility with MySQL](/security-compatibility-with-mysql.md) diff --git a/sql-statements/sql-statement-calibrate-resource.md b/sql-statements/sql-statement-calibrate-resource.md index d4308da1dfc6..3e9c0dd4e105 100644 --- a/sql-statements/sql-statement-calibrate-resource.md +++ b/sql-statements/sql-statement-calibrate-resource.md @@ -10,21 +10,106 @@ summary: TiDB 数据库中 CALIBRATE RESOURCE 的使用概况。 ## 语法图 ```ebnf+diagram -CalibrateResourceStmt ::= 'CALIBRATE' 'RESOURCE' -``` +CalibrateResourceStmt ::= 'CALIBRATE' 'RESOURCE' CalibrateOption + +CalibrateOption ::= +('START_TIME' 'TIMESTAMP' ('DURATION' stringLit | 'END_TIME' 'TIMESTAMP')?) +| ('WORKLOAD' ('TPCC' | 'OLTP_READ_WRITE' | 'OLTP_READ_ONLY' | 'OLTP_WRITE_ONLY'))? + +``` + +## 预估方式 + +TiDB 提供两种预估方式： + +### 根据实际负载估算容量 + +如果应用已经在线上运行，或者你能够运行实际业务测试，建议利用一段时间的实际负载来预估总容量。为了提高预估准确性，需要遵守以下约束条件： + +- 使用 `START_TIME` 参数指定预估开始的时间点，格式为 `2006-01-02 15:04:05`，默认预估结束时间为当前时间。 +- 指定完成 `START_TIME` 参数后，可以使用 `END_TIME` 参数指定预估结束时间，或者使用 `DURATION` 参数指定距离 `START_TIME` 的预估时间窗口。 +- 时间窗口范围为 10 分钟至 24 小时。 +- 在预估的时间窗口内，TiDB 与 TiKV 的 CPU 利用率不能过低，否则无法进行容量估算。 + +### 基于硬件部署估算容量 + +这种方式主要根据当前的集群配置，结合对不同负载观测的经验值进行预估。由于不同类型的负载对硬件的配比要求不同，相同配置的硬件所输出的容量也会有所不同。这里的 `WORKLOAD` 参数提供了以下不同的负载类型供选择，默认为 `TPCC`： + +- `TPCC`：数据写入较重的负载，根据类似 `TPC-C` 的负载模型预测。 +- `OLTP_WRITE_ONLY`：数据写入较重的负载，根据类似 `sysbench oltp_write_only` 的负载模型预测。 +- `OLTP_READ_WRITE`：数据读写平衡的负载，根据类似 `sysbench oltp_read_write` 的负载模型预测。 +- `OLTP_READ_ONLY`：数据读取较重的负载，根据类似 `sysbench oltp_read_only` 的负载模型预测。 + +> **注意：** +> +> 集群 RU 的容量会随集群的拓扑结构和各个组件软硬件配置的变化而变化，每个集群实际能消耗的 RU 还与实际的负载相关。基于硬件部署估算容量的预估值仅供参考，可能会与实际的最大值存在偏差。建议[根据实际负载估算容量](#根据实际负载估算容量)。 + +## 权限 + +执行此命令依赖如下配置和权限： + +- [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-从-v660-版本开始引入) 需要处于开启状态 +- 需要拥有 `SUPER` 或者 `RESOURCE_GROUP_ADMIN` 权限 +- 需要拥有 `METRICS_SCHEMA` 库下所有表的 `SELECT` 权限 ## 示例 +指定初始时间 `START_TIME` 和时间窗口 `DURATION` 大小，根据实际负载查看 RU 容量。 + ```sql -CALIBRATE RESOURCE; +CALIBRATE RESOURCE START_TIME '2023-04-18 08:00:00' DURATION '20m'; +-------+ | QUOTA | +-------+ -| 68569 | +| 27969 | +-------+ -1 row in set (0.03 sec) +1 row in set (0.01 sec) ``` -> **注意：** -> -> 集群 RU 的容量会随集群的拓扑结构和各个组件软硬件配置的变化而变化，每个集群实际能消耗的 RU 还与实际的负载相关。此预估值仅供参考，可能会与实际的最大值存在偏差。 +指定初始时间 `START_TIME` 和结束时间 `END_TIME`，根据实际负载查看 RU 容量。 + +```sql +CALIBRATE RESOURCE START_TIME '2023-04-18 08:00:00' END_TIME '2023-04-18 08:20:00'; ++-------+ +| QUOTA | ++-------+ +| 27969 | ++-------+ +1 row in set (0.01 sec) +``` + +当时间窗口范围 `DURATION` 不满足 10 分钟至 24 小时的条件，会导致报错提醒。 + +```sql +CALIBRATE RESOURCE START_TIME '2023-04-18 08:00:00' DURATION '25h'; +ERROR 1105 (HY000): the duration of calibration is too long, which could lead to inaccurate output. Please make the duration between 10m0s and 24h0m0s +CALIBRATE RESOURCE START_TIME '2023-04-18 08:00:00' DURATION '9m'; +ERROR 1105 (HY000): the duration of calibration is too short, which could lead to inaccurate output. Please make the duration between 10m0s and 24h0m0s +``` + +当时间窗口范围内的负载过低，会导致报错提醒。 + +```sql +CALIBRATE RESOURCE START_TIME '2023-04-18 08:00:00' DURATION '60m'; +ERROR 1105 (HY000): The workload in selected time window is too low, with which TiDB is unable to reach a capacity estimation; please select another time window with higher workload, or calibrate resource by hardware instead +``` + +指定 `WORKLOAD` 查看 RU 容量，默认为 `TPCC`。 + +```sql +CALIBRATE RESOURCE; ++-------+ +| QUOTA | ++-------+ +| 190470 | ++-------+ +1 row in set (0.01 sec) + +CALIBRATE RESOURCE WORKLOAD OLTP_WRITE_ONLY; ++-------+ +| QUOTA | ++-------+ +| 27444 | ++-------+ +1 row in set (0.01 sec) +``` \ No newline at end of file diff --git a/sql-statements/sql-statement-cancel-import-job.md b/sql-statements/sql-statement-cancel-import-job.md new file mode 100644 index 000000000000..c92efcad38a4 --- /dev/null +++ b/sql-statements/sql-statement-cancel-import-job.md @@ -0,0 +1,42 @@ +--- +title: CANCEL IMPORT +summary: TiDB 数据库中 CANCEL IMPORT 的使用概况。 +--- + +# CANCEL IMPORT + +`CANCEL IMPORT` 语句用于取消 TiDB 中创建的数据导入任务。 + +## 所需权限 + +只有导入任务的创建者或拥有 `SUPER` 权限的用户才能够取消任务。 + +## 语法图 + +```ebnf+diagram +CancelImportJobsStmt ::= + 'CANCEL' 'IMPORT' 'JOB' JobID +``` + +## 示例 + +下面示例取消 ID 为 1 的导入任务： + +```sql +CANCEL IMPORT JOB 1; +``` + +输出结果如下： + +``` +Query OK, 0 rows affected (0.01 sec) +``` + +## MySQL 兼容性 + +该语句是 TiDB 对 MySQL 语法的扩展。 + +## 另请参阅 + +* [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) +* [`SHOW IMPORT JOB`](/sql-statements/sql-statement-show-import-job.md) diff --git a/sql-statements/sql-statement-create-index.md b/sql-statements/sql-statement-create-index.md index 8da6e18d1d9d..d49ad9474624 100644 --- a/sql-statements/sql-statement-create-index.md +++ b/sql-statements/sql-statement-create-index.md @@ -271,10 +271,6 @@ SELECT min(col1) FROM t GROUP BY lower(col1); ## 多值索引 -> **警告：** -> -> 当前该功能为实验特性，不建议在生产环境中使用。 - 多值索引是一种定义在数组列上的二级索引。在普通索引中，一条索引记录对应一条数据记录 (1:1)。而在多值索引中，存在多条索引记录对应一条数据记录 (N:1)。多值索引用于索引 JSON 数组。例如，一个定义在 `zipcode` 字段上的多值索引会对每一个 `zipcode` 中的记录产生一条索引记录。 ```json @@ -375,13 +371,14 @@ Query OK, 1 row affected (0.00 sec) ### 特性与限制 - 如果是空 JSON 数组，则不会有对应的索引记录。 -- `CAST(... AS ... ARRAY)` 中的目标类型不能是 `BINARY`、`JSON`、`YEAR`、`FLOAT`、`DOUBLE`、`DECIMAL`。其中源类型必须是 JSON。 +- `CAST(... AS ... ARRAY)` 中的目标类型不能是 `BINARY`、`JSON`、`YEAR`、`FLOAT`、`DECIMAL`。其中源类型必须是 JSON。 - 无法使用多值索引进行排序。 - 只允许在 JSON 数组上建立多值索引。 - 多值索引不可以作为主键或外键。 - 多值索引使用额外的存储空间为：平均每行数组元素个数 * 普通二级索引使用空间。 - 相比于普通索引，DML 会对多值索引产生更多的索引记录的修改，因此多值索引会带来比普通索引更大的性能影响。 - 由于多值索引是一种特殊的表达式索引，因此具有表达式索引的限制。 +- 使用备份恢复工具 (BR)、同步工具 (TiCDC)、导入工具 (TiDB Lightning) 无法将定义了多值索引的表备份、同步、导入到低于 v6.6.0 版本的 TiDB。 ## 不可见索引 diff --git a/sql-statements/sql-statement-create-resource-group.md b/sql-statements/sql-statement-create-resource-group.md index 4235a001cb7a..87a0bb345e80 100644 --- a/sql-statements/sql-statement-create-resource-group.md +++ b/sql-statements/sql-statement-create-resource-group.md @@ -10,29 +10,52 @@ summary: TiDB 数据库中 CREATE RESOURCE GROUP 的使用概况。 ## 语法图 ```ebnf+diagram -CreateResourceGroupStmt: +CreateResourceGroupStmt ::= "CREATE" "RESOURCE" "GROUP" IfNotExists ResourceGroupName ResourceGroupOptionList IfNotExists ::= ('IF' 'NOT' 'EXISTS')? -ResourceGroupName: +ResourceGroupName ::= Identifier -ResourceGroupOptionList: +ResourceGroupOptionList ::= DirectResourceGroupOption | ResourceGroupOptionList DirectResourceGroupOption | ResourceGroupOptionList ',' DirectResourceGroupOption -DirectResourceGroupOption: +DirectResourceGroupOption ::= "RU_PER_SEC" EqOpt stringLit | "PRIORITY" EqOpt ResourceGroupPriorityOption | "BURSTABLE" +| "BURSTABLE" EqOpt Boolean +| "QUERY_LIMIT" EqOpt '(' ResourceGroupRunawayOptionList ')' +| "QUERY_LIMIT" EqOpt '(' ')' +| "QUERY_LIMIT" EqOpt "NULL" -ResourceGroupPriorityOption: +ResourceGroupPriorityOption ::= LOW | MEDIUM | HIGH + +ResourceGroupRunawayOptionList ::= + DirectResourceGroupRunawayOption +| ResourceGroupRunawayOptionList DirectResourceGroupRunawayOption +| ResourceGroupRunawayOptionList ',' DirectResourceGroupRunawayOption + +DirectResourceGroupRunawayOption ::= + "EXEC_ELAPSED" EqOpt stringLit +| "ACTION" EqOpt ResourceGroupRunawayActionOption +| "WATCH" EqOpt ResourceGroupRunawayWatchOption "DURATION" EqOpt stringLit + +ResourceGroupRunawayWatchOption ::= + EXACT +| SIMILAR + +ResourceGroupRunawayActionOption ::= + DRYRUN +| COOLDOWN +| KILL ``` 资源组的 `ResourceGroupName` 是全局唯一的，不允许重复。 @@ -43,7 +66,8 @@ TiDB 支持以下 `DirectResourceGroupOption`, 其中 [Request Unit (RU)](/tidb- |---------------|--------------|--------------------------------------| | `RU_PER_SEC` | 每秒 RU 填充的速度 | `RU_PER_SEC = 500` 表示此资源组每秒回填 500 个 RU。 | | `PRIORITY` | 任务在 TiKV 上处理的绝对优先级 | `PRIORITY = HIGH` 表示优先级高。若未指定，则默认为 `MEDIUM`。 | -| `BURSTABLE` | 允许对应的资源组超出配额后使用空余的系统资源。 | +| `BURSTABLE` | 允许对应的资源组超出配额后使用空余的系统资源。 | +| `QUERY_LIMIT` | 当查询执行满足该条件时，识别该查询为 Runaway Query 并进行相应的控制 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')` 表示当执行时间超过 60 秒后识别为 Runaway Query，对该查询执行终止操作，并在 10 分钟内对同样的 SQL 直接执行终止操作。`QUERY_LIMIT=()` 或 `QUERY_LIMIT=NULL` 则表示不进行 Runaway 控制。具体参数介绍详见[管理资源消耗超出预期的查询 (Runaway Queries)](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries)。 ｜ > **注意：** > @@ -75,7 +99,7 @@ Query OK, 0 rows affected (0.08 sec) ```sql CREATE RESOURCE GROUP IF NOT EXISTS rg2 - RU_PER_SEC = 200; + RU_PER_SEC = 200 QUERY_LIMIT=(EXEC_ELAPSED='100ms', ACTION=KILL); ``` ```sql @@ -87,12 +111,12 @@ SELECT * FROM information_schema.resource_groups WHERE NAME ='rg1' or NAME = 'rg ``` ```sql -+------+------------+----------+-----------+ -| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | -+------+------------+----------+-----------+ -| rg1 | 100 | HIGH | YES | -| rg2 | 200 | MEDIUM | NO | -+------+------------+----------+-----------+ ++------+------------+----------+-----------+---------------------------------+ +| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT | ++------+------------+----------+-----------+---------------------------------+ +| rg1 | 100 | HIGH | YES | NULL | +| rg2 | 200 | MEDIUM | NO | EXEC_ELAPSED=100ms, ACTION=KILL | ++------+------------+----------+-----------+---------------------------------+ 2 rows in set (1.30 sec) ``` @@ -104,4 +128,5 @@ MySQL 也支持 [CREATE RESOURCE GROUP](https://dev.mysql.com/doc/refman/8.0/en/ * [DROP RESOURCE GROUP](/sql-statements/sql-statement-drop-resource-group.md) * [ALTER RESOURCE GROUP](/sql-statements/sql-statement-alter-resource-group.md) +* [ALTER USER RESOURCE GROUP](/sql-statements/sql-statement-alter-user.md#修改用户绑定的资源组) * [RU](/tidb-resource-control.md#什么是-request-unit-ru) diff --git a/sql-statements/sql-statement-create-table.md b/sql-statements/sql-statement-create-table.md index 60589ea29152..316cabcfad86 100644 --- a/sql-statements/sql-statement-create-table.md +++ b/sql-statements/sql-statement-create-table.md @@ -232,7 +232,6 @@ mysql> DESC t1; * `COMMENT` 属性不支持 `WITH PARSER` 选项。 * TiDB 在单个表中默认支持 1017 列，最大可支持 4096 列。InnoDB 中相应的数量限制为 1017 列，MySQL 中的硬限制为 4096 列。详情参阅 [TiDB 使用限制](/tidb-limitations.md)。 * 当前仅支持 Range、Hash 和 Range Columns（单列）类型的分区表，详情参阅[分区表](/partitioned-table.md)。 -* TiDB 会解析并忽略 `CHECK` 约束，与 MySQL 5.7 相兼容。详情参阅 [`CHECK` 约束](/constraints.md#check-约束)。 ## 另请参阅 diff --git a/sql-statements/sql-statement-drop-resource-group.md b/sql-statements/sql-statement-drop-resource-group.md index b562f4ba86ca..f52a2e56e52b 100644 --- a/sql-statements/sql-statement-drop-resource-group.md +++ b/sql-statements/sql-statement-drop-resource-group.md @@ -10,13 +10,13 @@ summary: TiDB 数据库中 DROP RESOURCE GROUP 的使用概况。 ## 语法图 ```ebnf+diagram -DropResourceGroupStmt: +DropResourceGroupStmt ::= "DROP" "RESOURCE" "GROUP" IfExists ResourceGroupName IfExists ::= ('IF' 'EXISTS')? -ResourceGroupName: +ResourceGroupName ::= Identifier ``` @@ -50,11 +50,11 @@ SELECT * FROM information_schema.resource_groups WHERE NAME ='rg1'; ``` ```sql -+------+------------+----------+-----------+ -| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | -+------+------------+----------+-----------+ -| rg1 | 500 | MEDIUM | YES | -+------+------------+----------+-----------+ ++------+------------+----------+-----------+-------------+ +| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT | ++------+------------+----------+-----------+-------------+ +| rg1 | 500 | MEDIUM | YES | NULL | ++------+------------+----------+-----------+-------------+ 1 row in set (0.01 sec) ``` @@ -82,4 +82,4 @@ MySQL 也支持 [DROP RESOURCE GROUP](https://dev.mysql.com/doc/refman/8.0/en/dr * [ALTER RESOURCE GROUP](/sql-statements/sql-statement-alter-resource-group.md) * [CREATE RESOURCE GROUP](/sql-statements/sql-statement-create-resource-group.md) -* [RU](/tidb-resource-control.md#什么是-request-unit-ru) \ No newline at end of file +* [RU](/tidb-resource-control.md#什么是-request-unit-ru) diff --git a/sql-statements/sql-statement-flashback-to-timestamp.md b/sql-statements/sql-statement-flashback-to-timestamp.md index 5c36f84388e3..ee2850e617b6 100644 --- a/sql-statements/sql-statement-flashback-to-timestamp.md +++ b/sql-statements/sql-statement-flashback-to-timestamp.md @@ -7,6 +7,12 @@ summary: TiDB 数据库中 FLASHBACK CLUSTER TO TIMESTAMP 的使用概况。 TiDB v6.4.0 引入了 `FLASHBACK CLUSTER TO TIMESTAMP` 语法，其功能是将集群的数据恢复到特定的时间点。 +> **警告：** +> +> 在 TiDB v7.1.0 中使用该功能可能会出现 FLASHBACK 完成后部分 Region 仍处于 FLASHBACK 过程中的问题。请尽量避免在 v7.1.0 中使用该功能。详情可见 [#44292](https://github.com/pingcap/tidb/issues/44292)。 +> +> 如果已经出现该问题，可以使用 [TiDB 快照备份与恢复](/br/br-snapshot-guide.md)功能进行数据恢复。 + > **注意：** > > `FLASHBACK CLUSTER TO TIMESTAMP` 是用最新的时间戳写入特定时间点的旧数据，但不会删除当前数据，所以在使用前请确保集群有足够的存储空间来同时容纳旧数据和当前数据。 diff --git a/sql-statements/sql-statement-grant-privileges.md b/sql-statements/sql-statement-grant-privileges.md index 993c1956f850..d103a3fb50dd 100644 --- a/sql-statements/sql-statement-grant-privileges.md +++ b/sql-statements/sql-statement-grant-privileges.md @@ -100,6 +100,7 @@ SHOW GRANTS FOR 'newuser'; * 与 MySQL 类似，`USAGE` 权限表示登录 TiDB 服务器的能力。 * 目前不支持列级权限。 * 与 MySQL 类似，不存在 `NO_AUTO_CREATE_USER` sql 模式时，`GRANT` 语句将在用户不存在时自动创建一个空密码的新用户。删除此 sql-mode（默认情况下已启用）会带来安全风险。 +* `GRANT ` 语句执行成功后，在 TiDB 中语句执行的结果会在当前连接立即生效，而 [MySQL 中部分权限的结果需要等到之后的连接才生效](https://dev.mysql.com/doc/refman/8.0/en/privilege-changes.html)。见 [TiDB #39356](https://github.com/pingcap/tidb/issues/39356)。 ## 另请参阅 diff --git a/sql-statements/sql-statement-import-into.md b/sql-statements/sql-statement-import-into.md new file mode 100644 index 000000000000..fcac6978917c --- /dev/null +++ b/sql-statements/sql-statement-import-into.md @@ -0,0 +1,260 @@ +--- +title: IMPORT INTO +summary: TiDB 数据库中 IMPORT INTO 的使用概况。 +--- + +# IMPORT INTO + +`IMPORT INTO` 语句使用 TiDB Lightning 的[物理导入模式](/tidb-lightning/tidb-lightning-physical-import-mode.md)，用于将 `CSV`、`SQL`、`PARQUET` 等格式的数据导入到 TiDB 的一张空表中。 + +> **警告：** +> +> 目前该语句为实验特性，不建议在生产环境中使用。 + +`IMPORT INTO` 支持导入存储在 Amazon S3、GCS 和 TiDB 本地的数据文件。 + +- 对于存储在 S3 或 GCS 的数据文件，`IMPORT INTO` 支持通过[后端任务分布式框架](/tidb-distributed-execution-framework.md)运行。 + + - 当此框架功能开启时（即 [tidb_enable_dist_task](/system-variables.md#tidb_enable_dist_task-从-v710-版本开始引入) 为 `ON`），`IMPORT INTO` 会将一个数据导入任务拆分成多个子任务并分配到各个 TiDB 节点上运行，以提高导入效率。 + - 当此框架功能关闭时，`IMPORT INTO` 仅支持在当前用户连接的 TiDB 节点上运行。 + +- 对于存储在 TiDB 本地的数据文件，`IMPORT INTO` 仅支持在当前用户连接的 TiDB 节点上运行，因此数据文件需要存放在当前用户连接的 TiDB 节点上。如果是通过 PROXY 或者 Load Balancer 访问 TiDB，则无法导入存储在 TiDB 本地的数据文件。 + +## 已知问题 + +数据导入任务启动后，在对要导入的数据进行本地排序期间，当使用的 TiDB 磁盘空间超过了 [`DISK_QUOTA`](#withoptions) 的设定值或本地磁盘空间的 80%，并且 TiDB 已经开始向 TiKV 写入数据时，如果取消该任务或导入任务运行失败，后台导入线程会继续运行一段时间，然后才会真正退出。详情参考 [#45048](https://github.com/pingcap/tidb/issues/45048)。 + +## 使用限制 + +- 目前该语句仅支持导入 1 TiB 以下的数据。 +- 只支持导入数据到数据库中已有的空表。 +- 不支持事务，也无法回滚。在显式事务 (`BEGIN`/`END`) 中执行会报错。 +- 在导入完成前会阻塞当前连接，如果需要异步执行，可以添加 `DETACHED` 选项。 +- 不支持和 [Backup & Restore](/br/backup-and-restore-overview.md)、[`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-to-timestamp.md)、[创建索引加速](/system-variables.md#tidb_ddl_enable_fast_reorg-从-v630-版本开始引入)、TiDB Lightning 导入、TiCDC 数据同步、[Point-in-time recovery (PITR)](/br/br-log-architecture.md) 等功能同时工作。 +- 每个集群上同时只能有一个 `IMPORT INTO` 任务在运行。`IMPORT INTO` 会 precheck 是否存在运行中的任务，但并非硬限制，如果多个客户端同时执行 `IMPORT INTO` 仍有可能启动多个任务，请避免该情况，否则可能导致数据不一致或者任务失败的问题。 +- 导入数据的过程中，请勿在目标表上执行 DDL 和 DML 操作，也不要在目标数据库上执行 [`FLASHBACK DATABASE`](/sql-statements/sql-statement-flashback-database.md)，否则会导致导入失败或数据不一致。导入期间也不建议进行读操作，因为读取的数据可能不一致。请在导入完成后再进行读写操作。 +- 导入期间会占用大量系统资源，建议 TiDB 节点使用 32 核以上的 CPU 和 64 GiB 以上内存以获得更好的性能。导入期间会将排序好的数据写入到 TiDB [临时目录](/tidb-configuration-file.md#temp-dir-从-v630-版本开始引入)下，建议优先考虑配置闪存等高性能存储介质。详情请参考[物理导入使用限制](/tidb-lightning/tidb-lightning-physical-import-mode.md#必要条件及限制)。 +- TiDB [临时目录](/tidb-configuration-file.md#temp-dir-从-v630-版本开始引入)至少需要有 90 GiB 的可用空间。建议预留大于等于所需导入数据的存储空间，以保证最佳导入性能。 +- 一个导入任务只支持导入数据到一张目标表中。如需导入数据到多张目标表，需要在一张目标表导入完成后，再新建一个任务导入下一张目标表。 + +## 导入前准备 + +在使用 `IMPORT INTO` 开始导入数据前，请确保： + +- 要导入的目标表在 TiDB 中已经创建，并且是空表。 +- 当前集群有足够的剩余空间能容纳要导入的数据。 +- 当前连接的 TiDB 节点的[临时目录](/tidb-configuration-file.md#temp-dir-从-v630-版本开始引入)至少有 90 GiB 的磁盘空间。如果开启了 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-从-v710-版本开始引入)，需要确保集群中所有 TiDB 节点的临时目录都有足够的磁盘空间。 + +## 需要的权限 + +执行 `IMPORT INTO` 的用户需要有目标表的 `SELECT`、`UPDATE`、`INSERT`、`DELETE` 和 `ALTER` 权限。如果是导入存储在 TiDB 本地的文件，还需要有 `FILE` 权限。 + +## 语法图 + +```ebnf+diagram +ImportIntoStmt ::= + 'IMPORT' 'INTO' TableName ColumnNameOrUserVarList? SetClause? FROM fileLocation Format? WithOptions? + +ColumnNameOrUserVarList ::= + '(' ColumnNameOrUserVar (',' ColumnNameOrUserVar)* ')' + +SetClause ::= + 'SET' SetItem (',' SetItem)* + +SetItem ::= + ColumnName '=' Expr + +Format ::= + 'CSV' | 'SQL' | 'PARQUET' + +WithOptions ::= + 'WITH' OptionItem (',' OptionItem)* + +OptionItem ::= + optionName '=' optionVal | optionName +``` + +## 参数说明 + +### ColumnNameOrUserVarList + +用于指定数据文件中每行的各个字段如何对应到目标表列，也可以将字段对应到某个变量，用来跳过导入某些字段或者在 `SetClause` 中使用。 + +- 当不指定该参数时，数据文件中每行的字段数需要和目标表的列数一致，且各个字段会按顺序导入到对应的列。 +- 当指定该参数时，指定的列或变量个数需要和数据文件中每行的字段数一致。 + +### SetClause + +用于指定目标列值的计算方式。在 SET 表达式的右侧，可以引用在 `ColumnNameOrUserVarList` 中指定的变量。 + +SET 表达式左侧只能引用 `ColumnNameOrUserVarList` 中没有的列名。如果目标列名已经在 `ColumnNameOrUserVarList` 中，则该 SET 表达式无效。 + +### fileLocation + +用于指定数据文件的存储位置，该位置可以是 S3 或 GCS URI 路径，也可以是 TiDB 本地文件路径。 + +- S3 或 GCS URI 路径：配置详见[外部存储](/br/backup-and-restore-storages.md#uri-格式)。 +- TiDB 本地文件路径：必须为绝对路径，数据文件后缀必须为 `.csv`、`.sql` 或 `.parquet`。确保该路径对应的文件存储在当前用户连接的 TiDB 节点上，且当前连接的用户有 `FILE` 权限。 + +> **注意：** +> +> 如果目标集群开启了 [SEM](/system-variables.md#tidb_enable_enhanced_security)，则 fileLocation 不能指定为本地文件路径。 + +使用 fileLocation 可以指定单个文件，也可使用通配符 `*` 来匹配需要导入的多个文件。注意通配符只能用在文件名部分，不会匹配目录，也不会递归处理子目录下相关的文件。下面以数据存储在 S3 为例： + +- 导入单个文件：`s3:///path/to/data/foo.csv` +- 导入指定路径下的所有文件：`s3:///path/to/data/*` +- 导入指定路径下的所有以 `.csv` 结尾的文件：`s3:///path/to/data/*.csv` +- 导入指定路径下所有以 `foo` 为前缀的文件：`s3:///path/to/data/foo*` +- 导入指定路径下以 `foo` 为前缀、以 `.csv` 结尾的文件：`s3:///path/to/data/foo*.csv` + +### Format + +`IMPORT INTO` 支持 3 种数据文件格式，包括 `CSV`、`SQL` 和 `PARQUET`。当不指定该参数时，默认格式为 `CSV`。 + +### WithOptions + +你可以通过 WithOptions 来指定导入选项，控制数据导入过程。例如，如需使导入任务在后台异步执行，你可以通过在 `IMPORT INTO` 语句中添加 `WITH DETACHED` 选项来开启导入任务的 `DETACHED` 模式。 + +目前支持的选项包括： + +| 选项名 | 支持的数据格式 | 描述 | +|:---|:---|:---| +| `CHARACTER_SET=''` | CSV | 指定数据文件的字符集，默认为 `utf8mb4`。目前支持的字符集包括 `binary`、`utf8`、`utf8mb4`、`gb18030`、`gbk`、`latin1` 和 `ascii`。 | +| `FIELDS_TERMINATED_BY=''` | CSV | 指定字段分隔符，默认为 `,`。 | +| `FIELDS_ENCLOSED_BY=''` | CSV | 指定字段的定界符，默认为 `"`。 | +| `FIELDS_ESCAPED_BY=''` | CSV | 指定字段的转义符，默认为 `\`。 | +| `FIELDS_DEFINED_NULL_BY=''` | CSV | 指定字段为何值时将会被解析为 NULL，默认为 `\N`。 | +| `LINES_TERMINATED_BY=''` | CSV | 指定行分隔符，默认 `IMPORT INTO` 会自动识别分隔符为 `\n`、`\r` 或 `\r\n`，如果行分隔符为以上三种，无须显式指定该选项。 | +| `SKIP_ROWS=` | CSV | 指定需要跳过的行数，默认为 `0`。可通过该参数跳过 CSV 中的 header，如果是通过通配符来指定所需导入的源文件，该参数会对 fileLocation 中通配符匹配的所有源文件生效。 | +| `DISK_QUOTA=''` | 所有格式 | 指定数据排序期间可使用的磁盘空间阈值。默认值为 TiDB [临时目录](/tidb-configuration-file.md#temp-dir-从-v630-版本开始引入)所在磁盘空间的 80%。如果无法获取磁盘总大小，默认值为 50 GiB。当显式指定 DISK_QUOTA 时，该值同样不能超过 TiDB [临时目录](/tidb-configuration-file.md#temp-dir-从-v630-版本开始引入)所在磁盘空间的 80%。 | +| `DISABLE_TIKV_IMPORT_MODE` | 所有格式 | 指定是否禁止导入期间将 TiKV 切换到导入模式。默认不禁止。如果当前集群存在正在运行的读写业务，为避免导入过程对这部分业务造成影响，可开启该参数。 | +| `THREAD=` | 所有格式 | 指定导入的并发度。默认值为 TiDB 节点的 CPU 核数的 50%，最小值为 1。可以显示指定该参数来控制对资源的占用，但最大值不能超过 CPU 核数。如需导入数据到一个空集群，建议可以适当调大该值，以提升导入性能。如果目标集群已经用于生产环境，请根据业务要求按需调整该参数值。 | +| `MAX_WRITE_SPEED=''` | 所有格式 | 控制写入到单个 TiKV 的速度，默认无速度限制。例如设置为 `1MiB`，则限制写入速度为 1 MiB/s。| +| `CHECKSUM_TABLE=''` | 所有格式 | 配置是否在导入完成后对目标表是否执行 CHECKSUM 检查来验证导入的完整性。可选的配置项为 `"required"`（默认）、`"optional"` 和 `"off"`。`"required"` 表示在导入完成后执行 CHECKSUM 检查，如果 CHECKSUM 检查失败，则会报错退出。`"optional"` 表示在导入完成后执行 CHECKSUM 检查，如果报错，会输出一条警告日志并忽略报错。`"off"` 表示导入结束后不执行 CHECKSUM 检查。 | +| `DETACHED` | 所有格式 | 该参数用于控制 `IMPORT INTO` 是否异步执行。开启该参数后，执行 `IMPORT INTO` 会立即返回该导入任务的 `Job_ID` 等信息，且该任务会在后台异步执行。 | + +## 输出内容 + +当 `IMPORT INTO` 导入完成，或者开启了 `DETACHED` 模式时，`IMPORT INTO` 会返回当前任务的信息。以下为一些示例，字段的含义描述请参考 [`SHOW IMPORT JOB(s)`](/sql-statements/sql-statement-show-import-job.md)。 + +当 `IMPORT INTO` 导入完成时输出： + +```sql +IMPORT INTO t FROM '/path/to/small.csv'; ++--------+--------------------+--------------+----------+-------+----------+------------------+---------------+----------------+----------------------------+----------------------------+----------------------------+------------+ +| Job_ID | Data_Source | Target_Table | Table_ID | Phase | Status | Source_File_Size | Imported_Rows | Result_Message | Create_Time | Start_Time | End_Time | Created_By | ++--------+--------------------+--------------+----------+-------+----------+------------------+---------------+----------------+----------------------------+----------------------------+----------------------------+------------+ +| 60002 | /path/to/small.csv | `test`.`t` | 363 | | finished | 16B | 2 | | 2023-06-08 16:01:22.095698 | 2023-06-08 16:01:22.394418 | 2023-06-08 16:01:26.531821 | root@% | ++--------+--------------------+--------------+----------+-------+----------+------------------+---------------+----------------+----------------------------+----------------------------+----------------------------+------------+ +``` + +开启了 `DETACHED` 模式时，执行 `IMPORT INTO` 语句会立即返回输出。从输出中，你可以看到该任务状态 `Status` 为 `pending`，表示等待执行。 + +```sql +IMPORT INTO t FROM '/path/to/small.csv' WITH DETACHED; ++--------+--------------------+--------------+----------+-------+---------+------------------+---------------+----------------+----------------------------+------------+----------+------------+ +| Job_ID | Data_Source | Target_Table | Table_ID | Phase | Status | Source_File_Size | Imported_Rows | Result_Message | Create_Time | Start_Time | End_Time | Created_By | ++--------+--------------------+--------------+----------+-------+---------+------------------+---------------+----------------+----------------------------+------------+----------+------------+ +| 60001 | /path/to/small.csv | `test`.`t` | 361 | | pending | 16B | NULL | | 2023-06-08 15:59:37.047703 | NULL | NULL | root@% | ++--------+--------------------+--------------+----------+-------+---------+------------------+---------------+----------------+----------------------------+------------+----------+------------+ +``` + +## 查看和控制导入任务 + +对于开启了 `DETACHED` 模式的任务，可通过 [`SHOW IMPORT`](/sql-statements/sql-statement-show-import-job.md) 来查看当前任务的执行进度。 + +任务启动后，可通过 [`CANCEL IMPORT JOB `](/sql-statements/sql-statement-cancel-import-job.md) 来取消对应任务。 + +## 使用示例 + +### 导入带有 header 的 CSV 文件 + +```sql +IMPORT INTO t FROM '/path/to/file.csv' WITH skip_rows=1; +``` + +### 以 `DETACHED` 模式异步导入 + +```sql +IMPORT INTO t FROM '/path/to/file.csv' WITH DETACHED; +``` + +### 忽略数据文件中的特定字段 + +假设数据文件为以下 CSV 文件： + +``` +id,name,age +1,Tom,23 +2,Jack,44 +``` + +假设要导入的目标表结构为 `CREATE TABLE t(id int primary key, name varchar(100))`，则可通过以下方式来忽略导入文件中的 `age` 字段： + +```sql +IMPORT INTO t(id, name, @1) FROM '/path/to/file.csv' WITH skip_rows=1; +``` + +### 使用通配符 `*` 导入多个数据文件 + +假设在 `/path/to/` 目录下有 `file-01.csv`、`file-02.csv` 和 `file-03.csv` 三个文件，如需通过 `IMPORT INTO` 将这三个文件导入到目标表 `t` 中，可使用如下 SQL 语句： + +```sql +IMPORT INTO t FROM '/path/to/file-*.csv' +``` + +### 从 S3、GCS 导入数据 + +- 从 S3 导入数据 + + ```sql + IMPORT INTO t FROM 's3://bucket-name/test.csv?access-key=XXX&secret-access-key=XXX'; + ``` + +- 从 GCS 导入数据 + + ```sql + IMPORT INTO t FROM 'gs://bucket-name/test.csv'; + ``` + +S3 或 GCS 的 URI 路径配置详见[外部存储](/br/backup-and-restore-storages.md#uri-格式)。 + +### 通过 SetClause 语句计算列值 + +假设数据文件为以下 CSV 文件： + +``` +id,name,val +1,phone,230 +2,book,440 +``` + +要导入的目标表结构为 `CREATE TABLE t(id int primary key, name varchar(100), val int)`，并且希望在导入时将 `val` 列值扩大 100 倍，则可通过以下方式来导入： + +```sql +IMPORT INTO t(id, name, @1) SET val=@1*100 FROM '/path/to/file.csv' WITH skip_rows=1; +``` + +### 导入 SQL 格式的数据文件 + +```sql +IMPORT INTO t FROM '/path/to/file.sql' FORMAT 'sql'; +``` + +### 限制写入 TiKV 的速度 + +限制写入单个 TiKV 的速度为 10 MiB/s： + +```sql +IMPORT INTO t FROM 's3://bucket/path/to/file.parquet?access-key=XXX&secret-access-key=XXX' FORMAT 'parquet' WITH MAX_WRITE_SPEED='10MiB'; +``` + +## MySQL 兼容性 + +该语句是对 MySQL 语法的扩展。 + +## 另请参阅 + +* [`SHOW IMPORT JOB(s)`](/sql-statements/sql-statement-show-import-job.md) +* [`CANCEL IMPORT JOB`](/sql-statements/sql-statement-cancel-import-job.md) diff --git a/sql-statements/sql-statement-load-data.md b/sql-statements/sql-statement-load-data.md index 009f511c87a9..f67f94b74ecf 100644 --- a/sql-statements/sql-statement-load-data.md +++ b/sql-statements/sql-statement-load-data.md @@ -1,39 +1,35 @@ --- title: LOAD DATA summary: TiDB 数据库中 LOAD DATA 的使用概况。 -aliases: ['/docs-cn/dev/sql-statements/sql-statement-load-data/','/docs-cn/dev/reference/sql/statements/load-data/'] +aliases: ['/docs-cn/dev/sql-statements/sql-statement-load-data/','/docs-cn/dev/reference/sql/statements/load-data/','/zh/tidb/dev/sql-statement-operate-load-data-job','/zh/tidb/dev/sql-statement-show-load-data'] --- # LOAD DATA `LOAD DATA` 语句用于将数据批量加载到 TiDB 表中。 +在 v7.0.0 版本支持以下功能： + +- 支持从 S3、GCS 导入数据 +- 新增参数 `FIELDS DEFINED NULL BY` + > **警告：** > -> 当前该功能为实验特性，不建议在生产环境中使用。 +> v7.0.0 新增支持从 S3、GCS 导入数据和 `FIELDS DEFINED NULL BY` 参数为实验特性，不建议在生产环境中使用。该功能可能会在未事先通知的情况下发生变化或删除。如果发现 bug，请在 GitHub 上提 [issue](https://github.com/pingcap/tidb/issues) 反馈。 ## 语法图 ```ebnf+diagram LoadDataStmt ::= - 'LOAD' 'DATA' LocalOpt 'INFILE' stringLit FormatOpt DuplicateOpt 'INTO' 'TABLE' TableName CharsetOpt Fields Lines IgnoreLines ColumnNameOrUserVarListOptWithBrackets LoadDataSetSpecOpt LoadDataOptionListOpt + 'LOAD' 'DATA' LocalOpt 'INFILE' stringLit DuplicateOpt 'INTO' 'TABLE' TableName CharsetOpt Fields Lines IgnoreLines ColumnNameOrUserVarListOptWithBrackets LoadDataSetSpecOpt LocalOpt ::= ('LOCAL')? -FormatOpt ::= - ('FORMAT' ('DELIMITED DATA' | 'SQL FILE' | 'PARQUET'))? - Fields ::= ('TERMINATED' 'BY' stringLit | ('OPTIONALLY')? 'ENCLOSED' 'BY' stringLit | 'ESCAPED' 'BY' stringLit | 'DEFINED' 'NULL' 'BY' stringLit ('OPTIONALLY' 'ENCLOSED')?)? - -LoadDataOptionListOpt ::= - ('WITH' (LoadDataOption (',' LoadDataOption)*))? - -LoadDataOption ::= - detached | batch_size '=' numberLiteral ``` ## 参数说明 @@ -54,14 +50,8 @@ LoadDataOption ::= - 导入指定路径下所有以 `foo` 为前缀的文件：`s3:///path/to/data/foo*` - 导入指定路径下以 `foo` 为前缀、以 `.csv` 结尾的文件：`s3:///path/to/data/foo*.csv` -### `FORMAT` - -你可以通过 `FORMAT` 参数来指定数据文件的格式。如果不指定该参数，需要使用的格式为 `DELIMITED DATA`，该格式即 MySQL `LOAD DATA` 支持的数据格式。 - ### `Fields`、`Lines`、`Ignore Lines` -只有数据格式是 `DELIMITED DATA` 时，才能指定 `Fields`、`Lines`、`Ignore Lines` 等语句。 - 你可以使用 `Fields` 和 `Lines` 参数来指定如何处理数据格式： - 使用 `FIELDS TERMINATED BY` 来指定数据的分隔符号。 @@ -89,7 +79,7 @@ LoadDataOption ::= FIELDS TERMINATED BY ',' ENCLOSED BY '\"' LINES TERMINATED BY '\r\n' ``` -当数据格式为 `DELIMITED DATA` 且不指定处理数据的参数时，将按以下参数处理： +当不指定处理数据的参数时，将按以下参数处理： ```sql FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\' @@ -98,46 +88,8 @@ LINES TERMINATED BY '\n' STARTING BY '' 你可以通过 `IGNORE LINES` 参数来忽略文件开始的 `` 行。例如，可以使用 `IGNORE 1 LINES` 来忽略文件的第一行。 -### `WITH detached` - -如果你指定了 S3/GCS 路径（且未指定 `LOCAL` 参数），可以通过 `WITH detached` 来让 `LOAD DATA` 任务在后台运行。此时 `LOAD DATA` 会返回 job ID。 - -可以通过 [`SHOW LOAD DATA`](/sql-statements/sql-statement-show-load-data.md) 查看创建的 job，也可以使用 [`CANCEL LOAD DATA` 和 `DROP LOAD DATA`](/sql-statements/sql-statement-operate-load-data-job.md) 取消或删除创建的 job。 - -### `WITH batch_size=` - -可以通过 `WITH batch_size=` 来指定批量写入 TiDB 时的行数，默认值为 `1000`。如果不希望分批写入，可以指定为 `0`。 - ## 示例 -后台运行 job，执行后会输出对应的 job id： - -```sql -LOAD DATA INFILE 's3://bucket-name/test.csv?access_key=XXX&secret_access_key=XXX' INTO TABLE my_db.my_table FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '' LINES TERMINATED BY '\n' WITH detached; -``` - -```sql -+--------+ -| Job_ID | -+--------+ -| 150063 | -+--------+ -1 row in set (3.14 sec) -``` - -```sql -SHOW LOAD DATA JOB 1; -``` - -```sql -+--------+----------------------------+----------------------------+---------------------+---------------------------+--------------------+-------------+------------+-----------+------------+------------------+------------------+-------------+----------------+ -| Job_ID | Create_Time | Start_Time | End_Time | Data_Source | Target_Table | Import_Mode | Created_By | Job_State | Job_Status | Source_File_Size | Loaded_File_Size | Result_Code | Result_Message | -+--------+----------------------------+----------------------------+---------------------+---------------------------+-------------------+-------------+------------+-----------+------------+------------------+------------------+-------------+----------------+ -| 1 | 2023-03-16 22:29:12.990576 | 2023-03-16 22:29:12.991951 | 0000-00-00 00:00:00 | s3://bucket-name/test.csv | `my_db`.`my_table` | logical | root@% | loading | running | 52.43MB | 43.58MB | | | -+--------+----------------------------+----------------------------+---------------------+---------------------------+--------------------+-------------+------------+-----------+------------+------------------+------------------+-------------+----------------+ -1 row in set (0.01 sec) -``` - 通过 `LOAD DATA` 导入数据，指定数据的分隔符为逗号，忽略包围数据的引号，并且忽略文件的第一行数据。 如果此时遇到 `ERROR 1148 (42000): the used command is not allowed with this TiDB version` 报错信息。可以参考文档解决：[ERROR 1148 (42000): the used command is not allowed with this TiDB version 问题的处理方法](/error-codes.md#mysql-原生报错汇总) @@ -161,19 +113,18 @@ LOAD DATA LOCAL INFILE '/mnt/evo970/data-sets/bikeshare-data/2017Q4-capitalbikes ## MySQL 兼容性 -TiDB 中的 `LOAD DATA` 语句应该完全兼容 MySQL（除字符集选项被解析但会被忽略以外）。若发现任何兼容性差异，请在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues/new/choose)。 +TiDB 中的 `LOAD DATA` 语句语法上兼容 MySQL（除字符集选项被解析但会被忽略以外）。若发现任何语法兼容性差异，请在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues/new/choose)。 > **注意：** > > - 在 TiDB v4.0.0 之前的版本中，`LOAD DATA` 语句每 20000 行进行一次提交。 > - 从 TiDB v4.0.0 开始一直到 TiDB v6.6.0 的版本，TiDB 默认在一个事务中提交所有行。 -> - 从 TiDB v7.0.0 开始，批量提交的行数由 `LOAD DATA` 语句的 `WITH batch_size=` 参数控制，默认 1000 行提交一次。 -> - 从 TiDB v4.0.0 及以前版本升级后，可能出现 `ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058` 错误。要解决该问题，建议调大 `tidb.toml` 文件中的 [`txn-total-size-limit`](/tidb-configuration-file.md#txn-total-size-limit) 值。如果无法增加此限制，还可以将 [`tidb_dml_batch_size`](/system-variables.md#tidb_dml_batch_size) 的值设置为 `20000` 来恢复升级前的行为。 +> - 从 TiDB v4.0.0 及以前版本升级后，可能出现 `ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058` 错误。要解决该问题，建议调大 `tidb.toml` 文件中的 [`txn-total-size-limit`](/tidb-configuration-file.md#txn-total-size-limit) 值。如果无法增加此限制，还可以将 [`tidb_dml_batch_size`](/system-variables.md#tidb_dml_batch_size) 的值设置为 `20000` 来恢复升级前的行为。注意自 v7.0.0 起，`tidb_dml_batch_size` 对 `LOAD DATA` 语句不再生效。 +> - 无论以多少行为一个事务提交，`LOAD DATA` 都不会被显式事务中的 [`ROLLBACK`](/sql-statements/sql-statement-rollback.md) 语句回滚。 +> - `LOAD DATA` 语句始终以乐观事务模式执行，不受 TiDB 事务模式设置的影响。 ## 另请参阅 * [INSERT](/sql-statements/sql-statement-insert.md) * [乐观事务模型](/optimistic-transaction.md) -* [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) -* [`SHOW LOAD DATA`](/sql-statements/sql-statement-show-load-data.md) -* [`CANCEL LOAD DATA` 和 `DROP LOAD DATA`](/sql-statements/sql-statement-operate-load-data-job.md) +* [悲观事务模式](/pessimistic-transaction.md) diff --git a/sql-statements/sql-statement-operate-load-data-job.md b/sql-statements/sql-statement-operate-load-data-job.md deleted file mode 100644 index 80254bc1ad0e..000000000000 --- a/sql-statements/sql-statement-operate-load-data-job.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: CANCEL LOAD DATA 和 DROP LOAD DATA -summary: TiDB 数据库中 CANCEL LOAD DATA 和 DROP LOAD DATA 的使用概况。 ---- - -# CANCEL LOAD DATA 和 DROP LOAD DATA - -`CANCEL LOAD DATA` 语句用于取消系统中创建的 LOAD DATA 任务。 - -`DROP LOAD DATA` 语句用于删除系统中创建的 LOAD DATA 任务。 - -> **警告：** -> -> 当前该功能为实验特性，不建议在生产环境中使用。 - -## 语法图 - -```ebnf+diagram -CancelLoadDataJobsStmt ::= - 'CANCEL' 'LAOD' 'DATA' 'JOB' JobID - -DropLoadDataJobsStmt ::= - 'DROP' 'LAOD' 'DATA' 'JOB' JobID -``` - -## 示例 - -```sql -CANCEL LOAD DATA JOB 1; -``` - -``` -Query OK, 0 rows affected (0.01 sec) -``` - -```sql -DROP LOAD DATA JOB 1; -``` - -``` -Query OK, 1 row affected (0.01 sec) -``` - -## MySQL 兼容性 - -该语句是 TiDB 对 MySQL 语法的扩展。 - -## 另请参阅 - -* [LOAD DATA](/sql-statements/sql-statement-load-data.md) -* [SHOW LOAD DATA](/sql-statements/sql-statement-show-load-data.md) diff --git a/sql-statements/sql-statement-revoke-privileges.md b/sql-statements/sql-statement-revoke-privileges.md index 6ce86492c4c5..5be1157e6750 100644 --- a/sql-statements/sql-statement-revoke-privileges.md +++ b/sql-statements/sql-statement-revoke-privileges.md @@ -142,7 +142,7 @@ ERROR 1141 (42000): There is no such grant defined for user 'newuser' on host '% ## MySQL 兼容性 -`REVOKE ` 语句与 MySQL 完全兼容。如发现任何兼容性差异，请在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues/new/choose)。 +`REVOKE ` 语句执行成功后，在 TiDB 中语句执行的结果会在当前连接立即生效，而 [MySQL 中部分权限的结果需要等到之后的连接才生效](https://dev.mysql.com/doc/refman/8.0/en/privilege-changes.html)。见 [TiDB #39356](https://github.com/pingcap/tidb/issues/39356)。 ## 另请参阅 diff --git a/sql-statements/sql-statement-set-resource-group.md b/sql-statements/sql-statement-set-resource-group.md index d6db0dcdad4f..0355da6de53a 100644 --- a/sql-statements/sql-statement-set-resource-group.md +++ b/sql-statements/sql-statement-set-resource-group.md @@ -12,10 +12,10 @@ summary: TiDB 数据库中 SET RESOURCE GROUP 的使用概况。 **SetResourceGroupStmt:** ```ebnf+diagram -SetResourceGroupStmt: +SetResourceGroupStmt ::= "SET" "RESOURCE" "GROUP" ResourceGroupName -ResourceGroupName: +ResourceGroupName ::= Identifier ``` @@ -63,7 +63,7 @@ SELECT CURRENT_RESOURCE_GROUP(); 执行 `SET RESOURCE GROUP` 设置当前会话使用默认资源组。 ```sql -SET RESOURCE GROUP ``; +SET RESOURCE GROUP `default`; SELECT CURRENT_RESOURCE_GROUP(); ``` diff --git a/sql-statements/sql-statement-show-import-job.md b/sql-statements/sql-statement-show-import-job.md new file mode 100644 index 000000000000..598969433dd1 --- /dev/null +++ b/sql-statements/sql-statement-show-import-job.md @@ -0,0 +1,78 @@ +--- +title: SHOW IMPORT +summary: TiDB 数据库中 SHOW IMPORT 的使用概况。 +--- + +# SHOW IMPORT + +`SHOW IMPORT` 语句用于显示 TiDB 中已经创建的 IMPORT 任务。该语句只能显示由当前用户创建的任务。 + +## 所需权限 + +- 对于 `SHOW IMPORT JOBS` 语句，如果用户有 `SUPER` 权限，则可以看到所有 job，否则只能看到当前用户创建的 job。 +- 对于 `SHOW IMPORT JOB `，只有 job 创建者或者拥有 `SUPER` 权限的用户才可以查看。 + +## 语法图 + +```ebnf+diagram +ShowImportJobsStmt ::= + 'SHOW' 'IMPORT' 'JOBS' + +ShowImportJobStmt ::= + 'SHOW' 'IMPORT' 'JOB' JobID +``` + +`SHOW IMPORT` 语句输出结果的字段含义如下: + +| 列名 | 说明 | +|------------------|-------------------------| +| Job_ID | 任务 ID | +| Data_Source | 数据源信息 | +| Target_Table | 目标表 | +| Phase | 表示任务当前所处的阶段，导入过程分为 `importing`、`validating`、`add-index` 等阶段 | +| Status | 表示当前任务的状态。有以下几种状态：`pending` 表示任务已创建但还未开始运行；`running` 表示运行中；`canceled` 表示已经取消的任务；`failed` 表示任务失败并退出；`finished` 表示任务已完成。| +| Source_File_Size | 源文件大小 | +| Imported_Rows | 已经读到并写入目标表的数据行数 | +| Result_Message | 如果导入失败，则返回错误信息，否则为空。| +| Create_Time | 任务创建时间 | +| Start_Time | 任务启动时间 | +| End_Time | 任务结束时间 | +| Created_By | 创建该任务的数据库用户名 | + +## 示例 + +```sql +SHOW IMPORT JOBS; +``` + +``` ++--------+-------------------+--------------+----------+-------+----------+------------------+---------------+----------------+----------------------------+----------------------------+----------------------------+------------+ +| Job_ID | Data_Source | Target_Table | Table_ID | Phase | Status | Source_File_Size | Imported_Rows | Result_Message | Create_Time | Start_Time | End_Time | Created_By | ++--------+-------------------+--------------+----------+-------+----------+------------------+---------------+----------------+----------------------------+----------------------------+----------------------------+------------+ +| 1 | /path/to/file.csv | `test`.`foo` | 116 | | finished | 11GB | 950000 | | 2023-06-26 11:23:59.281257 | 2023-06-26 11:23:59.484932 | 2023-06-26 13:04:30.622952 | root@% | +| 2 | /path/to/file.csv | `test`.`bar` | 130 | | finished | 1.194TB | 49995000 | | 2023-06-26 15:42:45.079237 | 2023-06-26 15:42:45.388108 | 2023-06-26 17:29:43.023568 | root@% | ++--------+-------------------+--------------+----------+-------+----------+------------------+---------------+----------------+----------------------------+----------------------------+----------------------------+------------+ +1 row in set (0.01 sec) +``` + +```sql +SHOW IMPORT JOB 60001; +``` + +``` ++--------+--------------------+--------------+----------+-------+---------+------------------+---------------+----------------+----------------------------+------------+----------+------------+ +| Job_ID | Data_Source | Target_Table | Table_ID | Phase | Status | Source_File_Size | Imported_Rows | Result_Message | Create_Time | Start_Time | End_Time | Created_By | ++--------+--------------------+--------------+----------+-------+---------+------------------+---------------+----------------+----------------------------+------------+----------+------------+ +| 60001 | /path/to/small.csv | `test`.`t` | 361 | | pending | 16B | NULL | | 2023-06-08 15:59:37.047703 | NULL | NULL | root@% | ++--------+--------------------+--------------+----------+-------+---------+------------------+---------------+----------------+----------------------------+------------+----------+------------+ +1 row in set (0.01 sec) +``` + +## MySQL 兼容性 + +该语句是 TiDB 对 MySQL 语法的扩展。 + +## 另请参阅 + +* [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) +* [`CANCEL IMPORT JOB`](/sql-statements/sql-statement-cancel-import-job.md) diff --git a/sql-statements/sql-statement-show-indexes.md b/sql-statements/sql-statement-show-indexes.md index 6433dcc2675a..1387a36cab58 100644 --- a/sql-statements/sql-statement-show-indexes.md +++ b/sql-statements/sql-statement-show-indexes.md @@ -98,7 +98,7 @@ SHOW KEYS FROM t1; ## MySQL 兼容性 -MySQL 中的 `Cardinality` 列返回该索引上不同值的个数，而 TiDB 中的 `Cardinality` 列始终返回 `0`。 +`SHOW INDEXES [FROM|IN]` 语句与 MySQL 完全兼容。如发现任何兼容性差异，请在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues/new/choose)。 ## 另请参阅 diff --git a/sql-statements/sql-statement-show-load-data.md b/sql-statements/sql-statement-show-load-data.md deleted file mode 100644 index 7bb0c0db3593..000000000000 --- a/sql-statements/sql-statement-show-load-data.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: SHOW LOAD DATA -summary: TiDB 数据库中 SHOW LOAD DATA 的使用概况。 ---- - -# SHOW LOAD DATA - -`SHOW LOAD DATA` 语句用于显示系统中创建的 LOAD DATA 任务。该语句只能显示由当前用户创建的任务。 - -> **警告：** -> -> 当前该功能为实验特性，不建议在生产环境中使用。 - -## 语法图 - -```ebnf+diagram -ShowLoadDataJobsStmt ::= - 'SHOW' 'LAOD' 'DATA' 'JOBS' - -ShowLoadDataJobStmt ::= - 'SHOW' 'LAOD' 'DATA' 'JOB' JobID -``` - -`SHOW LOAD DATA` 语句显示的字段含义如下: - -| 列名 | 说明 | -|------------------|-------------------------| -| Job_ID | 任务 ID | -| Create_Time | 任务创建时间 | -| Start_Time | 任务启动时间 | -| End_Time | 任务结束时间 | -| Data_Source | 数据源信息 | -| Target_Table | 目标表 | -| Import_Mode | 导入模式，目前该字段只能取值 `logical` | -| Created_By | 创建该任务的数据库用户名 | -| Job_State | 表示任务当前所处的阶段，对于 `logical` 模式的任务，只有 `loading` 这一个阶段 | -| Job_Status | 表示当前任务的状态。有以下几种状态：`pending` 表示任务已创建但还未开始运行；`running` 表示运行中；`canceled` 表示已经取消的任务；`failed` 表示任务失败并退出；`finished` 表示任务已完成。 | -| Source_File_Size | 源文件大小 | -| Loaded_File_Size | 已经读到并写入目标表的数据量大小 | -| Result_Code | 任务状态为 `finished` 时，其值为 `0`。任务状态为 `failed` 时，其值为对应的错误码。 | -| Result_Message | 如果导入成功，则返回摘要信息。如果导入失败，则返回错误信息。 | - -## 示例 - -```sql -SHOW LOAD DATA JOBS; -``` - -``` -+--------+----------------------------+----------------------------+---------------------+---------------------------+--------------------+-------------+------------+-----------+------------+------------------+------------------+-------------+----------------+ -| Job_ID | Create_Time | Start_Time | End_Time | Data_Source | Target_Table | Import_Mode | Created_By | Job_State | Job_Status | Source_File_Size | Loaded_File_Size | Result_Code | Result_Message | -+--------+----------------------------+----------------------------+---------------------+---------------------------+-------------------+-------------+------------+-----------+------------+------------------+------------------+-------------+----------------+ -| 1 | 2023-03-16 22:29:12.990576 | 2023-03-16 22:29:12.991951 | 0000-00-00 00:00:00 | s3://bucket-name/test.csv | `my_db`.`my_table` | logical | root@% | loading | running | 52.43MB | 43.58MB | | | -+--------+----------------------------+----------------------------+---------------------+---------------------------+--------------------+-------------+------------+-----------+------------+------------------+------------------+-------------+----------------+ -1 row in set (0.01 sec) -``` - -```sql -SHOW LOAD DATA JOB 1; -``` - -``` -+--------+----------------------------+----------------------------+---------------------+---------------------------+--------------------+-------------+------------+-----------+------------+------------------+------------------+-------------+----------------+ -| Job_ID | Create_Time | Start_Time | End_Time | Data_Source | Target_Table | Import_Mode | Created_By | Job_State | Job_Status | Source_File_Size | Loaded_File_Size | Result_Code | Result_Message | -+--------+----------------------------+----------------------------+---------------------+---------------------------+-------------------+-------------+------------+-----------+------------+------------------+------------------+-------------+----------------+ -| 1 | 2023-03-16 22:29:12.990576 | 2023-03-16 22:29:12.991951 | 0000-00-00 00:00:00 | s3://bucket-name/test.csv | `my_db`.`my_table` | logical | root@% | loading | running | 52.43MB | 43.58MB | | | -+--------+----------------------------+----------------------------+---------------------+---------------------------+--------------------+-------------+------------+-----------+------------+------------------+------------------+-------------+----------------+ -1 row in set (0.01 sec) -``` - -## MySQL 兼容性 - -该语句是 TiDB 对 MySQL 语法的扩展。 - -## 另请参阅 - -* [`LOAD DATA`](/sql-statements/sql-statement-load-data.md) -* [`CANCEL LOAD DATA` 和 `DROP LOAD DATA`](/sql-statements/sql-statement-operate-load-data-job.md) diff --git a/statistics.md b/statistics.md index 4304d346fb30..8ac5877c509d 100644 --- a/statistics.md +++ b/statistics.md @@ -5,30 +5,13 @@ aliases: ['/docs-cn/dev/statistics/','/docs-cn/dev/reference/performance/statist # 统计信息简介 -TiDB 使用统计信息来决定[索引的选择](/choose-index.md)。变量 `tidb_analyze_version` 用于控制所收集到的统计信息。目前 TiDB 中支持两种统计信息：`tidb_analyze_version = 1` 以及 `tidb_analyze_version = 2`。在 v5.3.0 及之后的版本中，该变量的默认值为 `2`。如果从 v5.3.0 之前版本的集群升级至 v5.3.0 及之后的版本，`tidb_analyze_version` 的默认值不发生变化。 +TiDB 使用统计信息来决定[索引的选择](/choose-index.md)。 -> **注意：** -> -> 当 `tidb_analyze_version = 2` 时，如果执行 ANALYZE 语句后发生 OOM，请设置全局变量 `tidb_analyze_version = 1`，然后进行以下操作之一： -> -> - 如果 ANALYZE 语句是手动执行的，请手动 analyze 每张需要的表： -> -> ```sql -> SELECT DISTINCT(CONCAT('ANALYZE TABLE ', table_schema, '.', table_name, ';')) FROM information_schema.tables, mysql.stats_histograms WHERE stats_ver = 2 AND table_id = tidb_table_id; -> ``` -> -> - 如果 ANALYZE 语句是开启了自动 analyze 后 TiDB 自动执行的，请使用以下 SQL 语句生成 DROP STATS 的语句并执行： -> -> ```sql -> SELECT DISTINCT(CONCAT('DROP STATS ', table_schema, '.', table_name, ';')) FROM information_schema.tables, mysql.stats_histograms WHERE stats_ver = 2 AND table_id = tidb_table_id; -> ``` -> -> - 如果上一条语句返回结果太长，不方便拷贝粘贴，可以将结果导出到临时文件后，再执行: -> -> ```sql -> select distinct... into outfile '/tmp/sql.txt'; -> mysql -h XXX -u user -P 4000 ... < '/tmp/sql.txt'; -> ``` +## 统计信息版本 + +变量 `tidb_analyze_version` 用于控制所收集到的统计信息。目前 TiDB 中支持两种统计信息：`tidb_analyze_version = 1` 以及 `tidb_analyze_version = 2`。在 v5.3.0 及之后的版本中，该变量的默认值为 `2`。如果从 v5.3.0 之前版本的集群升级至 v5.3.0 及之后的版本，`tidb_analyze_version` 的默认值不发生变化。 + +Version 2 的统计信息避免了 Version 1 中因为哈希冲突导致的在较大的数据量中可能产生的较大误差，并保持了大多数场景中的估算精度。 两种版本中，TiDB 维护的统计信息如下： @@ -46,7 +29,26 @@ TiDB 使用统计信息来决定[索引的选择](/choose-index.md)。变量 `ti | 列的平均长度 | √ | √ | | 索引的平均长度 | √ | √ | -Version 2 的统计信息避免了 Version 1 中因为哈希冲突导致的在较大的数据量中可能产生的较大误差，并保持了大多数场景中的估算精度。 +当 `tidb_analyze_version = 2` 时，如果执行 ANALYZE 语句后发生 OOM，需要设置全局变量 `tidb_analyze_version = 1`，回退到 Version 1，然后根据情况进行以下操作： + +- 如果 ANALYZE 语句是手动执行的，你需要手动 ANALYZE 每张需要的表： + + ```sql + SELECT DISTINCT(CONCAT('ANALYZE TABLE ', table_schema, '.', table_name, ';')) FROM information_schema.tables, mysql.stats_histograms WHERE stats_ver = 2 AND table_id = tidb_table_id; + ``` + +- 如果 ANALYZE 语句是开启了自动 ANALYZE 后 TiDB 自动执行的，使用以下 SQL 语句生成 DROP STATS 的语句并执行： + + ```sql + SELECT DISTINCT(CONCAT('DROP STATS ', table_schema, '.', table_name, ';')) FROM information_schema.tables, mysql.stats_histograms WHERE stats_ver = 2 AND table_id = tidb_table_id; + ``` + +- 如果上一条语句返回结果太长，不方便复制粘贴，可以将结果导出到临时文件后，再执行: + + ```sql + SELECT DISTINCT... INTO outfile '/tmp/sql.txt'; + mysql -h ${TiDB_IP} -u user -P ${TIDB_PORT} ... < '/tmp/sql.txt'; + ``` 本文接下来将简单介绍其中出现的直方图和 Count-Min Sketch 以及 Top-N 这些数据结构，以及详细介绍统计信息的收集和维护。 @@ -129,7 +131,8 @@ ANALYZE TABLE TableNameList [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH > **注意：** > -> 收集部分列的统计信息的功能仅适用于 `tidb_analyze_version = 2` 的情况。 +> - 收集部分列的统计信息的功能仅适用于 [`tidb_analyze_version = 2`](/system-variables.md#tidb_analyze_version-从-v510-版本开始引入) 的情况。 +> - TiDB v7.2.0 引入了系统变量 [`tidb_analyze_skip_column_types`](/system-variables.md#tidb_analyze_skip_column_types-从-v720-版本开始引入)，该变量可以控制在执行 `ANALYZE` 命令收集统计信息时，跳过哪些类型的列的统计信息收集。该变量仅适用于 `tidb_analyze_version = 2` 的情况。 - 如果要收集指定列的统计信息，请使用以下语法： @@ -330,9 +333,9 @@ ANALYZE INCREMENTAL TABLE TableName PARTITION PartitionNameList INDEX [IndexName ### 自动更新 -在发生增加，删除以及修改语句时，TiDB 会自动更新表的总行数以及修改的行数。这些信息会定期持久化下来，更新的周期是 20 * `stats-lease`，`stats-lease` 的默认值是 3s，如果将其指定为 0，那么将不会自动更新。 +在发生增加，删除以及修改语句时，TiDB 会自动更新表的总行数以及修改的行数。这些信息会定期持久化下来，更新的周期为 20 * [`stats-lease`](/tidb-configuration-file.md#stats-lease)。`stats-lease` 配置项的默认值是 3s，如果将其指定为 0，那么统计信息将不会自动更新。 -和统计信息自动更新相关的三个系统变量如下： +#### 相关系统变量 | 系统变量名 | 默认值 | 功能 | |---|---|---| @@ -344,6 +347,12 @@ ANALYZE INCREMENTAL TABLE TableName PARTITION PartitionNameList INDEX [IndexName 为了避免小表因为少量数据修改而频繁触发自动更新，当表的行数小于 1000 时，TiDB 不会触发对此表的自动更新。你可以通过 `SHOW STATS_META` 来查看表的行数情况。 +#### 关闭自动更新 + +如果发现自动更新统计信息消耗过多的资源，影响在线业务，可以通过系统变量 [`tidb_enable_auto_analyze`](/system-variables.md#tidb_enable_auto_analyze-从-v610-版本开始引入) 关闭自动更新。 + +#### 终止后台的 `ANALYZE` 任务 + 从 TiDB v6.0 起，TiDB 支持通过 `KILL` 语句终止正在后台运行的 `ANALYZE` 任务。如果发现正在后台运行的 `ANALYZE` 任务消耗大量资源影响业务，你可以通过以下步骤终止该 `ANALYZE` 任务： 1. 执行以下 SQL 语句： @@ -684,6 +693,15 @@ DROP STATS TableName GLOBAL; - 通过修改 TiDB 配置项 [`stats-load-concurrency`](/tidb-configuration-file.md#stats-load-concurrency-从-v540-版本开始引入) 的值控制统计信息同步加载可以并发处理的最大列数。该配置项的默认值为 `5`。 - 通过修改 TiDB 配置项 [`stats-load-queue-size`](/tidb-configuration-file.md#stats-load-queue-size-从-v540-版本开始引入) 的值设置统计信息同步加载最多可以缓存多少列的请求。该配置项的默认值为 `1000`。 +在 TiDB 启动阶段，初始统计信息加载完成之前执行的 SQL 可能有不合理的执行计划，从而影响性能。为了避免这种情况，从 v7.1.0 开始，TiDB 引入了配置项 [`force-init-stats`](/tidb-configuration-file.md#force-init-stats-从-v710-版本开始引入)。你可以控制 TiDB 启动时是否在统计信息初始化完成后再对外提供服务。该配置项从 v7.2.0 起默认开启。 + +从 v7.1.0 开始，TiDB 引入了配置参数 [`lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-从-v710-版本开始引入) 用于控制是否开启轻量级的统计信息初始化。 + +- 当 `lite-init-stats` 为 `true` 时，统计信息初始化时列和索引的直方图、TopN、Count-Min Sketch 均不会加载到内存中。 +- 当 `lite-init-stats` 为 `false` 时，统计信息初始化时索引和主键的直方图、TopN、Count-Min Sketch 会被加载到内存中，非主键列的直方图、TopN、Count-Min Sketch 不会加载到内存中。当优化器需要某一索引或者列的直方图、TopN、Count-Min Sketch 时，这些统计信息会被同步或异步加载到内存中。 + +`lite-init-stats` 默认值为 `true`，即开启轻量级的统计信息初始化。将 `lite-init-stats` 设置为 `true` 可以加速统计信息初始化，避免加载不必要的统计信息，从而降低 TiDB 的内存使用。 + ## 统计信息的导入导出 ### 导出统计信息 @@ -813,4 +831,4 @@ mysql> show warnings; * [DROP STATS](/sql-statements/sql-statement-drop-stats.md) * [LOCK STATS](/sql-statements/sql-statement-lock-stats.md) * [UNLOCK STATS](/sql-statements/sql-statement-unlock-stats.md) -* [SHOW STATS_LOCKED](/sql-statements/sql-statement-show-stats-locked.md) \ No newline at end of file +* [SHOW STATS_LOCKED](/sql-statements/sql-statement-show-stats-locked.md) diff --git a/sync-diff-inspector/sync-diff-inspector-overview.md b/sync-diff-inspector/sync-diff-inspector-overview.md index e959e587f9fd..455358139ea1 100644 --- a/sync-diff-inspector/sync-diff-inspector-overview.md +++ b/sync-diff-inspector/sync-diff-inspector-overview.md @@ -24,7 +24,7 @@ aliases: ['/docs-cn/dev/sync-diff-inspector/sync-diff-inspector-overview/','/doc {{< copyable "shell-regular" >}} ```shell - docker pull pingcap/tidb-enterprise-tools:nightly + docker pull pingcap/tidb-tools:latest ``` ## sync-diff-inspector 的使用限制 diff --git a/system-variables.md b/system-variables.md index e4269df999a8..d58f3c7cf051 100644 --- a/system-variables.md +++ b/system-variables.md @@ -48,13 +48,183 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 是否允许在 `INSERT` 语句中显式指定含有 `AUTO_RANDOM` 属性的列的值。 +### `authentication_ldap_sasl_auth_method_name` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：枚举型 +- 默认值：`SCRAM-SHA-1` +- 可选值：`SCRAM-SHA-1`、`SCRAM-SHA-256`、`GSSAPI` +- LDAP SASL 身份验证中，验证方法的名称。 + +### `authentication_ldap_sasl_bind_base_dn` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：字符串 +- 默认值："" +- LDAP SASL 身份验证中，搜索用户的范围。如果创建用户时没有通过 `AS ...` 指定 `dn`，TiDB 会自动在 LDAP Server 的该范围中根据用户名搜索用户 `dn`。例如 `dc=example,dc=org`。 + +### `authentication_ldap_sasl_bind_root_dn` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：字符串 +- 默认值："" +- LDAP SASL 身份验证中，TiDB 登录 LDAP Server 搜索用户时使用的 `dn`。 + +### `authentication_ldap_sasl_bind_root_pwd` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：字符串 +- 默认值："" +- LDAP SASL 身份验证中，TiDB 登录 LDAP Server 搜索用户时使用的密码。 + +### `authentication_ldap_sasl_ca_path` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：字符串 +- 默认值："" +- LDAP SASL 身份验证中，TiDB 对 StartTLS 连接使用的 CA 证书的路径。 + +### `authentication_ldap_sasl_init_pool_size` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：整数型 +- 默认值：`10` +- 范围：`[1, 32767]` +- LDAP SASL 身份验证中，TiDB 与 LDAP Server 间连接池的初始连接数。 + +### `authentication_ldap_sasl_max_pool_size` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：整数型 +- 默认值：`1000` +- 范围：`[1, 32767]` +- LDAP SASL 身份验证中，TiDB 与 LDAP Server 间连接池的最大连接数。 + +### `authentication_ldap_sasl_server_host` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：字符串 +- 默认值："" +- LDAP SASL 身份验证中，LDAP Server 的主机名或地址。 + +### `authentication_ldap_sasl_server_port` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：整数型 +- 默认值：`389` +- 范围：`[1, 65535]` +- LDAP SASL 身份验证中，LDAP Server 的 TCP/IP 端口号。 + +### `authentication_ldap_sasl_tls` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：布尔型 +- 默认值：`OFF` +- LDAP SASL 身份验证中，是否使用 StartTLS 对连接加密。 + +### `authentication_ldap_simple_auth_method_name` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：枚举型 +- 默认值：`SIMPLE` +- 可选值：`SIMPLE` +- LDAP simple 身份验证中，验证方法的名称。现在仅支持 `SIMPLE`。 + +### `authentication_ldap_simple_bind_base_dn` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：字符串 +- 默认值："" +- LDAP simple 身份验证中，搜索用户的范围。如果创建用户时没有通过 `AS ...` 指定 `dn`，TiDB 会自动在 LDAP Server 的该范围中根据用户名搜索用户 `dn`。例如 `dc=example,dc=org`。 + +### `authentication_ldap_simple_bind_root_dn` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：字符串 +- 默认值："" +- LDAP simple 身份验证中，TiDB 登录 LDAP Server 搜索用户时使用的 `dn`。 + +### `authentication_ldap_simple_bind_root_pwd` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：字符串 +- 默认值："" +- LDAP simple 身份验证中，TiDB 登录 LDAP Server 搜索用户时使用的密码。 + +### `authentication_ldap_simple_ca_path` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：字符串 +- 默认值："" +- LDAP simple 身份验证中，TiDB 对 StartTLS 连接使用的 CA 证书的路径。 + +### `authentication_ldap_simple_init_pool_size` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：整数型 +- 默认值：`10` +- 范围：`[1, 32767]` +- LDAP simple 身份验证中，TiDB 与 LDAP Server 间连接池的初始连接数。 + +### `authentication_ldap_simple_max_pool_size` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：整数型 +- 默认值：`1000` +- 范围：`[1, 32767]` +- LDAP simple 身份验证中，TiDB 与 LDAP Server 间连接池的最大连接数。 + +### `authentication_ldap_simple_server_host` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：字符串 +- 默认值："" +- LDAP simple 身份验证中，LDAP Server 的主机名或地址。 + +### `authentication_ldap_simple_server_port` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：整数型 +- 默认值：`389` +- 范围：`[1, 65535]` +- LDAP simple 身份验证中，LDAP Server 的 TCP/IP 端口号。 + +### `authentication_ldap_simple_tls` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：布尔型 +- 默认值：`OFF` +- LDAP simple 身份验证中，是否使用 StartTLS 对连接加密。 + ### `auto_increment_increment` - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`1` - 范围：`[1, 65535]` - 控制 `AUTO_INCREMENT` 自增值字段的自增步长。该变量常与 `auto_increment_offset` 一起使用。 @@ -63,6 +233,7 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`1` - 范围：`[1, 65535]` - 控制 `AUTO_INCREMENT` 自增值字段的初始值。该变量常与 `auto_increment_increment` 一起使用。示例如下： @@ -97,6 +268,7 @@ mysql> SELECT * FROM t1; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 用于设置在非显式事务时是否自动提交事务。更多信息，请参见[事务概述](/transaction-overview.md#自动提交)。 @@ -169,6 +341,7 @@ mysql> SELECT * FROM t1; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`1000` - 范围：`[0, 4294967295]` - 这个变量用于控制公共表表达式的最大递归深度。 @@ -176,9 +349,10 @@ mysql> SELECT * FROM t1; ### `datadir` - 作用域：NONE -- 默认值：/tmp/tidb -- 这个变量表示数据存储的位置，位置可以是本地路径。如果数据存储在 TiKV 上，则可以是指向 PD 服务器的路径。 -- 如果变量值的格式为 `ip_address:port`，表示 TiDB 在启动时连接到的 PD 服务器。 +- 默认值：使用的组件和部署方式不同，默认值也不同。 + - `/tmp/tidb`：如果你将 [`--store`](/command-line-flags-for-tidb-configuration.md#--store) 设置为 `"unistore"` 或没有设置 `--store`，则默认值为 `/tmp/tidb`。 + - `${pd-ip}:${pd-port}`：如果你设置的存储引擎是 TiKV（如果使用 TiUP 和 TiDB Operator 部署，则默认的存储引擎为 TiKV），则默认值为 `${pd-ip}:${pd-port}`。 +- 这个变量表示数据存储的位置，位置可以是本地路径 `/tmp/tidb`。如果数据存储在 TiKV 上，则可以是指向 PD 服务器的路径。变量值的格式为 `${pd-ip}:${pd-port}`，表示 TiDB 在启动时连接到的 PD 服务器。 ### `ddl_slow_threshold` @@ -194,8 +368,9 @@ mysql> SELECT * FROM t1; - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：枚举型 - 默认值：`mysql_native_password` -- 可选值：`mysql_native_password`，`caching_sha2_password`，`tidb_sm3_password`，`tidb_auth_token` +- 可选值：`mysql_native_password`，`caching_sha2_password`，`tidb_sm3_password`，`tidb_auth_token`，`authentication_ldap_sasl` 或 `authentication_ldap_simple`。 - `tidb_auth_token` 认证方式仅用于 TiDB Cloud 内部实现，**不要设置为该值**。 - 服务器和客户端建立连接时，这个变量用于设置服务器对外通告的默认身份验证方式。如要了解该变量的其他可选值，参见[可用的身份验证插件](/security-compatibility-with-mysql.md#可用的身份验证插件)。 - 若要在用户登录时使用 `tidb_sm3_password` 插件，需要使用 [TiDB-JDBC](https://github.com/pingcap/mysql-connector-j/tree/release/8.0-sm3) 进行连接。 @@ -285,6 +460,7 @@ mysql> SELECT * FROM t1; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`50` - 范围：`[1, 3600]` - 单位：秒 @@ -294,6 +470,7 @@ mysql> SELECT * FROM t1; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`28800` - 范围：`[1, 31536000]` - 单位：秒 @@ -304,18 +481,20 @@ mysql> SELECT * FROM t1; - 作用域：SESSION - 类型：整数型 - 默认值：`0` -- 取值范围：`[0, 9223372036854775807]` +- 取值范围：`[0, 18446744073709551615]` - 返回由 `INSERT` 语句产生的最新 `AUTO_INSCRENT` 或者 `AUTO_RANDOM` 值，与 `LAST_INSERT_ID()` 的返回的结果相同。与 MySQL 中的 `last_insert_id` 一致。 ### `last_plan_from_binding` 从 v4.0 版本开始引入 - 作用域：SESSION +- 类型：布尔型 - 默认值：`OFF` - 该变量用来显示上一条执行的语句所使用的执行计划是否来自 binding 的[执行计划](/sql-plan-management.md)。 ### `last_plan_from_cache` 从 v4.0 版本开始引入 - 作用域：SESSION +- 类型：布尔型 - 默认值：`OFF` - 这个变量用来显示上一个 `execute` 语句所使用的执行计划是不是直接从 plan cache 中取出来的。 @@ -352,6 +531,7 @@ mysql> SELECT * FROM t1; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`0` - 范围：`[0, 2147483647]` - 单位：毫秒 @@ -359,7 +539,8 @@ mysql> SELECT * FROM t1; > **注意：** > -> `max_execution_time` 目前对所有类型的语句生效，并非只对 `SELECT` 语句生效，与 MySQL 不同（只对`SELECT` 语句生效）。实际精度在 100ms 级别，而非更准确的毫秒级别。 +> - `max_execution_time` 目前只用于控制只读语句的最大执行时长，实际精度在 100ms 级别，而非更准确的毫秒级别。 +> - 对于使用了 [`MAX_EXECUTION_TIME`](/optimizer-hints.md#max_execution_timen) Hint 的 SQL 语句，这些语句的最长执行时间将不受该变量限制，而是由该 Hint 进行限制。你也可以使用该 Hint 来创建 SQL 绑定，详情请参考 [SQL 操作常见问题](/faq/sql-faq.md#如何阻止特定的-sql-语句执行或者将某个-sql-语句加入黑名单)。 ### `max_prepared_stmt_count` @@ -397,6 +578,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`67108864` - 取值范围：`[1024, 1073741824]` - 该变量取值应为 1024 的整数倍。若取值无法被 1024 整除，则会提示 warning 并向下取整。例如设置为 1025 时，则 TiDB 中的实际取值为 1024。 @@ -461,6 +643,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; ### `port` - 作用域：NONE +- 类型：整数型 - 默认值：`4000` - 范围：`[0, 65535]` - 使用 MySQL 协议时 tidb-server 监听的端口。 @@ -468,6 +651,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; ### `rand_seed1` - 作用域：SESSION +- 类型：整数型 - 默认值：`0` - 范围：`[0, 2147483647]` - 该变量用于为 SQL 函数 `RAND()` 中使用的随机值生成器添加种子。 @@ -476,6 +660,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; ### `rand_seed2` - 作用域：SESSION +- 类型：整数型 - 默认值：`0` - 范围：`[0, 2147483647]` - 该变量用于为 SQL 函数 `RAND()` 中使用的随机值生成器添加种子。 @@ -485,6 +670,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 该变量控制是否所有 TiDB 的连接都在本地 socket 上进行通信，或使用 TLS。详情见[为 TiDB 客户端服务端间通信开启加密传输](/enable-tls-between-clients-and-servers.md)。 - 该变量设置为 `ON` 时，必须使用开启 TLS 的会话连接到 TiDB，防止在 TLS 配置不正确时出现锁定的情况。 @@ -494,6 +680,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 该变量控制 `tidb-server` 实例是否将主机名作为连接握手的一部分来解析。 - 当 DNS 不可靠时，可以启用该变量来提高网络性能。 @@ -541,12 +728,13 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - 默认值：`OFF` - 这个变量用于控制表是否必须有主键。启用该变量后，如果在没有主键的情况下创建或修改表，将返回错误。 - 该功能基于 MySQL 8.0 的特性 [`sql_require_primary_key`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_sql_require_primary_key)。 -- 强烈推荐在使用 TiCDC 时启用改变量，因为同步数据变更至 MySQL sink 时要求表必须有主键。 +- 强烈推荐在使用 TiCDC 时启用该变量，因为同步数据变更至 MySQL sink 时要求表必须有主键。 ### `sql_select_limit` 从 v4.0.2 版本开始引入 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`18446744073709551615` - 范围：`[0, 18446744073709551615]` - 单位：行 @@ -582,12 +770,14 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - 是否持久化到集群：是 - 默认值：`4096` - 取值范围：`[0, 9223372036854775807]` +- 单位：字节 - 这个变量用于控制当 [`replica-read`](#tidb_replica_read-从-v40-版本开始引入) 设置为 `closest-adaptive` 时，优先将读请求发送至 TiDB server 所在区域副本的阈值。当读请求预估的返回结果的大小超过此阈值时，TiDB 会将读请求优先发送至同一可用区的副本，否则会发送至 leader 副本。 ### `tidb_allow_batch_cop` 从 v4.0 版本开始引入 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`1` - 范围：`[0, 2]` - 这个变量用于控制 TiDB 向 TiFlash 发送 coprocessor 请求的方式，有以下几种取值： @@ -613,6 +803,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用于控制是否使用 TiFlash 的 MPP 模式执行查询，可以设置的值包括： - 0 或 OFF，代表从不使用 MPP 模式 @@ -623,6 +814,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 ### `tidb_allow_remove_auto_inc` 从 v2.1.18 和 v3.0.4 版本开始引入 - 作用域：SESSION +- 类型：布尔型 - 默认值：`OFF` - 这个变量用来控制是否允许通过 `ALTER TABLE MODIFY` 或 `ALTER TABLE CHANGE` 来移除某个列的 `AUTO_INCREMENT` 属性。默认 (`OFF`) 为不允许。 @@ -641,17 +833,73 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`2` - 范围：`[1, 2]` - 这个变量用于控制 TiDB 收集统计信息的行为。 - 在 v5.3.0 及之后的版本中，该变量的默认值为 `2`，具体可参照[统计信息简介](/statistics.md)文档。如果从 v5.3.0 之前版本的集群升级至 v5.3.0 及之后的版本，`tidb_analyze_version` 的默认值不发生变化。 +### `tidb_analyze_skip_column_types` 从 v7.2.0 版本开始引入 + +- 作用域：SESSION | GLOBAL +- 是否持久化到集群：是 +- 默认值："json,blob,mediumblob,longblob" +- 可选值："json,blob,mediumblob,longblob,text,mediumtext,longtext" +- 这个变量表示在执行 `ANALYZE` 命令收集统计信息时，跳过哪些类型的列的统计信息收集。该变量仅适用于 [`tidb_analyze_version = 2`](#tidb_analyze_version-从-v510-版本开始引入) 的情况。即使使用 `ANALYZE TABLE t COLUMNS c1, ..., cn` 语法指定列，如果指定的列的类型在 `tidb_analyze_skip_column_types` 中，也不会收集该列的统计信息。 + +```sql +mysql> SHOW CREATE TABLE t; ++-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Table | Create Table | ++-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| t | CREATE TABLE `t` ( + `a` int(11) DEFAULT NULL, + `b` varchar(10) DEFAULT NULL, + `c` json DEFAULT NULL, + `d` blob DEFAULT NULL, + `e` longblob DEFAULT NULL +) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin | ++-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +1 row in set (0.00 sec) + +mysql> SELECT @@tidb_analyze_skip_column_types; ++----------------------------------+ +| @@tidb_analyze_skip_column_types | ++----------------------------------+ +| json,blob,mediumblob,longblob | ++----------------------------------+ +1 row in set (0.00 sec) + +mysql> ANALYZE TABLE t; +Query OK, 0 rows affected, 1 warning (0.05 sec) + +mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; ++---------------------------------------------------------------------+ +| job_info | ++---------------------------------------------------------------------+ +| analyze table columns a, b with 256 buckets, 500 topn, 1 samplerate | ++---------------------------------------------------------------------+ +1 row in set (0.00 sec) + +mysql> ANALYZE TABLE t COLUMNS a, c; +Query OK, 0 rows affected, 1 warning (0.04 sec) + +mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; ++------------------------------------------------------------------+ +| job_info | ++------------------------------------------------------------------+ +| analyze table columns a with 256 buckets, 500 topn, 1 samplerate | ++------------------------------------------------------------------+ +1 row in set (0.00 sec) +``` + ### `tidb_auto_analyze_end_time` - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：时间 - 默认值：`23:59 +0000` -- 这个变量用来设置一天中允许自动 ANALYZE 更新统计信息的结束时间。例如，只允许在凌晨 1:00 至 3:00 之间自动更新统计信息，可以设置如下： +- 这个变量用来设置一天中允许自动 ANALYZE 更新统计信息的结束时间。例如，只允许在 UTC 时间的凌晨 1:00 至 3:00 之间自动更新统计信息，可以设置如下： - `tidb_auto_analyze_start_time='01:00 +0000'` - `tidb_auto_analyze_end_time='03:00 +0000'` @@ -670,7 +918,9 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：浮点数 - 默认值：`0.5` +- 范围：`[0, 18446744073709551615]` - 这个变量用来设置 TiDB 在后台自动执行 [`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md) 更新统计信息的阈值。`0.5` 指的是当表中超过 50% 的行被修改时，触发自动 ANALYZE 更新。可以指定 `tidb_auto_analyze_start_time` 和 `tidb_auto_analyze_end_time` 来限制自动 ANALYZE 的时间 > **注意：** @@ -681,8 +931,9 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：时间 - 默认值：`00:00 +0000` -- 这个变量用来设置一天中允许自动 ANALYZE 更新统计信息的开始时间。例如，只允许在凌晨 1:00 至 3:00 之间自动更新统计信息，可以设置如下： +- 这个变量用来设置一天中允许自动 ANALYZE 更新统计信息的开始时间。例如，只允许在 UTC 时间的凌晨 1:00 至 3:00 之间自动更新统计信息，可以设置如下： - `tidb_auto_analyze_start_time='01:00 +0000'` - `tidb_auto_analyze_end_time='03:00 +0000'` @@ -700,6 +951,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`10` - 范围：`[1, 2147483647]` - 这个变量用来设置读请求遇到锁的 backoff 时间。 @@ -708,6 +960,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`2` - 范围：`[0, 2147483647]` - 这个变量用来给 TiDB 的 `backoff` 最大时间增加权重，即内部遇到网络或其他组件 (TiKV, PD) 故障时，发送重试请求的最大重试时间。可以通过这个变量来调整最大重试时间，最小值为 1。 @@ -762,19 +1015,23 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`10240` - 范围：`[0, 9223372036854775807]` - 单位：行 - 如果 join 的对象为子查询，优化器无法估计子查询结果集大小，在这种情况下通过结果集行数判断。如果子查询的行数估计值小于该变量，则选择 Broadcast Hash Join 算法。否则选择 Shuffled Hash Join 算法。 +- 开启 [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-从-v710-版本开始引入) 功能后，该变量将不再生效。 ### `tidb_broadcast_join_threshold_size` 从 v5.0 版本开始引入 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`104857600` (100 MiB) - 范围：`[0, 9223372036854775807]` - 单位：字节 - 如果表大小（字节数）小于该值，则选择 Broadcast Hash Join 算法。否则选择 Shuffled Hash Join 算法。 +- 开启 [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-从-v710-版本开始引入) 功能后，该变量将不再生效。 ### `tidb_build_stats_concurrency` @@ -791,6 +1048,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用于控制是否开启[自动捕获绑定](/sql-plan-management.md#自动捕获绑定-baseline-capturing)功能。该功能依赖 Statement Summary，因此在使用自动绑定之前需打开 Statement Summary 开关。 - 开启该功能后会定期遍历一次 Statement Summary 中的历史 SQL 语句，并为至少出现两次的 SQL 语句自动创建绑定。 @@ -808,6 +1066,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：否，仅作用于当前连接的 TiDB 实例 +- 类型：布尔型 - 默认值：`ON` - 设置该变量为 `ON` 可强制只存储[基本多文种平面 (BMP)](https://zh.wikipedia.org/zh-hans/Unicode字符平面映射) 编码区段内的 `utf8` 字符值。若要存储 BMP 区段外的 `utf8` 值，推荐使用 `utf8mb4` 字符集。 - 早期版本的 TiDB 中 (v2.1.x)，`utf8` 检查更为宽松。如果你的 TiDB 集群是从早期版本升级的，推荐关闭该变量，详情参阅[升级与升级后常见问题](/faq/upgrade-faq.md)。 @@ -816,6 +1075,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`128` - 范围：`[1, 10000]` - 在单个事务的提交阶段，用于执行提交操作相关请求的 goroutine 数量。 @@ -842,6 +1102,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 该变量仅适用于乐观事务模型。悲观事务模式中的行为由 [`tidb_constraint_check_in_place_pessimistic`](#tidb_constraint_check_in_place_pessimistic-从-v630-版本开始引入) 控制。 - 当这个变量设置为 `OFF` 时，唯一索引的重复值检查会被推迟到事务提交时才进行。这有助于提高性能，但对于某些应用，可能导致非预期的行为。详情见[约束](/constraints.md#乐观事务)。 @@ -970,31 +1231,39 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用来控制是否开启添加索引加速功能，来提升创建索引回填过程的速度。开启该变量对于数据量较大的表有一定的性能提升。 +- TiDB v7.1.0 引入了快速加索引功能的检查点机制，即使 TiDB owner 因故障重启或者切换，也能够通过自动定期保存的检查点恢复部分进度。 - 要验证已经完成的 `ADD INDEX` 操作是否使用了添加索引加速功能，可以执行 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md#admin-show-ddl-jobs) 语句查看 `JOB_TYPE` 一列中是否含有 `ingest` 字样。 > **警告：** > > 目前，PITR 恢复会额外处理日志备份时间段内通过索引加速功能创建的索引，以达到兼容效果。详细内容请参考[索引加速功能为什么与 PITR 功能不兼容](/faq/backup-and-restore-faq.md#索引加速功能为什么与-pitr-功能不兼容)。 -### `tidb_ddl_distribute_reorg` 从 v6.6.0 版本开始引入 +> **注意：** +> +> 在升级到 v6.5.0 及以上版本时，建议你检查 TiDB 的 [`temp-dir`](/tidb-configuration-file.md#temp-dir-从-v630-版本开始引入) 路径是否正确挂载了 SSD 磁盘。该参数是 TiDB 的配置参数，设置后需要重启 TiDB 才能生效。因此，在升级前提前进行设置，可以避免再次重启。 + +### `tidb_enable_dist_task` 从 v7.1.0 版本开始引入 > **警告：** > -> - 该功能目前为实验特性。不推荐在生产环境中开启该功能。 -> - 当前启用此功能后，在 DDL reorg 阶段遇到某些异常只会做简单重试，还没有兼容 DDL 操作的重试方式，即目前无法依据 [`tidb_ddl_error_count_limit`](#tidb_ddl_error_count_limit) 的大小控制重试次数。 +> 该功能目前为实验特性，不建议在生产环境中使用。 - 作用域：GLOBAL - 是否持久化到集群：是 - 默认值：`OFF` -- 这个变量用于控制是否开启分布式执行 DDL reorg 阶段，来提升此阶段的速度。目前此开关只对 `ADD INDEX` 语句有效。开启该变量对于数据量较大的表有一定的性能提升。分布式 DDL 会通过 DDL 动态资源管控，控制 DDL 的 CPU 使用量，来防止对线上业务产生影响。 -- 要验证已经完成的 `ADD INDEX` 操作是否使用了此功能，可以查看 `mysql.tidb_background_subtask_history` 表是否有对应任务。 +- 这个变量用于控制是否开启 [TiDB 后端任务分布式框架](/tidb-distributed-execution-framework.md)。开启分布式框架后，DDL 和 Import 等后端任务将会由集群中多个 TiDB 节点共同完成。 +- 从 TiDB v7.1.0 开始，支持分布式执行分区表的 [`ADD INDEX`](/sql-statements/sql-statement-add-index.md)。 +- 从 TiDB v7.2.0 开始，支持分布式导入任务 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)。 +- 该变量由 `tidb_ddl_distribute_reorg` 改名而来。 ### `tidb_ddl_error_count_limit` - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`512` - 范围：`[0, 9223372036854775807]` - 这个变量用来控制 DDL 操作失败重试的次数。失败重试次数超过该参数的值后，会取消出错的 DDL 操作。 @@ -1012,6 +1281,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`256` - 范围：`[32, 10240]` - 单位：行 @@ -1032,6 +1302,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`4` - 范围：`[1, 256]` - 单位：线程 @@ -1054,6 +1325,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用来设置是否禁用显式的乐观事务自动重试，设置为 `ON` 时，不会自动重试，如果遇到事务冲突需要在应用层重试。 @@ -1069,6 +1341,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`15` - 范围：`[1, 256]` - 单位：线程 @@ -1084,6 +1357,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`0` - 范围：`[0, 2147483647]` - 单位：行 @@ -1093,12 +1367,13 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 > **注意：** > -> 自 v7.0.0 起，`tidb_dml_batch_size`对 [`LOAD DATA` 语句](/sql-statements/sql-statement-load-data.md)不再生效。如需控制 `LOAD DATA` 语句的事务大小，可使用参数 [`batch_size`](/sql-statements/sql-statement-load-data.md#with-batch_sizenumber)。 +> 自 v7.0.0 起，`tidb_dml_batch_size` 对 [`LOAD DATA` 语句](/sql-statements/sql-statement-load-data.md)不再生效。 ### `tidb_enable_1pc` 从 v5.0 版本开始引入 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 指定是否在只涉及一个 Region 的事务上启用一阶段提交特性。比起传统两阶段提交，一阶段提交能大幅降低事务提交延迟并提升吞吐。 @@ -1112,6 +1387,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 该变量控制 `ANALYZE` 读取历史时刻的数据还是读取最新的数据。当该变量设置为 `ON` 时，`ANALYZE` 读取 `ANALYZE` 开始时刻的历史数据。当该变量设置为 `OFF` 时，`ANALYZE` 读取最新的数据。 - 在 v5.2 之前，`ANALYZE` 读取最新的数据。v5.2 至 v6.1 版本 `ANALYZE` 读取 `ANALYZE` 开始时刻的历史数据。 @@ -1124,6 +1400,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 该变量控制是否启用 Async Commit 特性，使事务两阶段提交的第二阶段于后台异步进行。开启本特性能降低事务提交的延迟。 @@ -1137,6 +1414,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 该变量控制 TiDB 是否以后台操作自动更新表的统计信息。 - 在 v6.1.0 之前这个开关通过 TiDB 配置文件 (`performance.run-auto-analyze`) 进行配置，升级到 v6.1.0 时会自动继承原有设置。 @@ -1145,6 +1423,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用于控制是否允许在创建生成列或者表达式索引时引用自增列。 @@ -1168,12 +1447,22 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用于控制是否开启 cascades planner。 +### `tidb_enable_check_constraint` 从 v7.2.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：布尔型 +- 默认值：`OFF` +- 这个变量用于控制是否启用 [`CHECK` 约束](/constraints.md#check-约束)。 + ### `tidb_enable_chunk_rpc` 从 v4.0 版本开始引入 - 作用域：SESSION +- 类型：布尔型 - 默认值：`ON` - 这个变量用来设置是否启用 Coprocessor 的 `Chunk` 数据编码格式。 @@ -1181,6 +1470,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：枚举型 - 默认值：`ON` - 可选值：`OFF`，`ON`，`INT_ONLY` - 这个变量用于控制默认情况下表的主键是否使用[聚簇索引](/clustered-indexes.md)。“默认情况”即不显式指定 `CLUSTERED`/`NONCLUSTERED` 关键字的情况。可设置为 `OFF`/`ON`/`INT_ONLY`。 @@ -1192,6 +1482,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：否，仅作用于当前连接的 TiDB 实例 +- 类型：布尔型 - 默认值：`ON` - 这个变量用于控制是否同时将各个执行算子的执行信息记录入 slow query log 中。 @@ -1203,10 +1494,11 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用于控制是否开启 TiDB 对 `PREDICATE COLUMNS` 的收集。关闭该变量后，之前收集的 `PREDICATE COLUMNS` 会被清除。详情见[收集部分列的统计信息](/statistics.md#收集部分列的统计信息)。 -### `tidb_enable_ddl` +### `tidb_enable_ddl` 从 v6.3.0 版本开始引入 - 作用域：GLOBAL - 是否持久化到集群：否，仅作用于当前连接的 TiDB 实例 @@ -1217,6 +1509,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 ### `tidb_enable_enhanced_security` - 作用域：NONE +- 类型：布尔型 - 默认值：`OFF` - 这个变量表示所连接的 TiDB 服务器是否启用了安全增强模式 (SEM)。若要改变该变量值，你需要在 TiDB 服务器的配置文件中修改 `enable-sem` 项的值，并重启 TiDB 服务器。 - 安全增强模式受[安全增强式 Linux](https://zh.wikipedia.org/wiki/安全增强式Linux) 等系统设计的启发，削减拥有 MySQL `SUPER` 权限的用户能力，转而使用细粒度的 `RESTRICTED` 权限作为替代。这些细粒度的 `RESTRICTED` 权限如下： @@ -1246,6 +1539,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 可选值：`OFF` 和 `ON` - `tidb_restricted_read_only`和 [`tidb_super_read_only`](#tidb_super_read_only-从-v531-版本开始引入) 的作用相似。在大多数情况下，你只需要使用 [`tidb_super_read_only`](#tidb_super_read_only-从-v531-版本开始引入) 即可。 @@ -1291,10 +1585,24 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用来控制是否启用统计信息快速分析功能。默认值 0 表示不开启。 - 快速分析功能开启后，TiDB 会随机采样约 10000 行的数据来构建统计信息。因此在数据分布不均匀或者数据量比较少的情况下，统计信息的准确度会比较低。这可能导致执行计划不优，比如选错索引。如果可以接受普通 `ANALYZE` 语句的执行时间，则推荐关闭快速分析功能。 +### `tidb_enable_fast_table_check` 从 v7.2.0 版本开始引入 + +> **注意：** +> +> 该功能对[多值索引](/sql-statements/sql-statement-create-index.md#多值索引)和前缀索引不生效。 + +- 作用域：SESSION | GLOBAL +- 是否持久化到集群：是 +- 类型：布尔型 +- 默认值：`ON` +- 这个变量用于控制是否使用基于校验和的方式来快速检查表中数据和索引的一致性。默认值 `ON` 表示该功能默认开启。 +- 开启后，TiDB 执行 [`ADMIN CHECK [TABLE|INDEX]`](/sql-statements/sql-statement-admin-check-table-index.md) 语句的速度更快。 + ### `tidb_enable_foreign_key` 从 v6.3.0 版本开始引入 - 作用域：GLOBAL @@ -1324,13 +1632,25 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 - 类型：布尔型 -- 默认值：`OFF` +- 默认值：`ON` - 这个变量用来控制是否开启[非 Prepare 语句执行计划缓存](/sql-non-prepared-plan-cache.md)。 +### `tidb_enable_non_prepared_plan_cache_for_dml` 从 v7.1.0 版本开始引入 + +> **警告：** +> +> 非 Prepare 语句执行计划缓存目前为实验特性，不建议在生产环境中使用。该功能可能会在未事先通知的情况下发生变化或删除。如果发现 bug，请在 GitHub 上提 [issue](https://github.com/pingcap/tidb/issues) 反馈。 + +- 作用域：SESSION | GLOBAL +- 是否持久化到集群：是 +- 类型：布尔型 +- 默认值：`OFF` +- 这个变量用来控制[非 Prepare 语句执行计划缓存](/sql-non-prepared-plan-cache.md)是否支持 DML 语句。 + ### `tidb_enable_gogc_tuner` 从 v6.4.0 版本开始引入 - 作用域：GLOBAL -- 是否持久化到集群：否，仅作用于当前连接的 TiDB 实例 +- 是否持久化到集群：是 - 类型：布尔型 - 默认值：`ON` - 该变量来用控制是否开启 GOGC Tuner。 @@ -1365,6 +1685,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用于控制是否开启 index merge 功能。 @@ -1381,6 +1702,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用于允许使用 `SET SESSION` 对 `INSTANCE` 作用域的变量进行设置，用法同 `SET GLOBAL`。 - 为了兼容之前的 TiDB 版本，该变量值默认为 `ON`。 @@ -1389,6 +1711,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用来设置是否开启 `LIST (COLUMNS) TABLE PARTITION` 特性。 @@ -1404,6 +1727,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用来设置是否开启[元数据锁](/metadata-lock.md)特性。需要注意，在设置该变量时，集群中不能有 DDL 任务，以免造成非预期数据正确性、一致性问题。 @@ -1439,7 +1763,9 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：枚举型 - 默认值：`OFF` +- 可选值：`ON`、`OFF`、`WARN` - 默认情况下，用户尝试将某些语法用于尚未实现的功能时，TiDB 会报错。若将该变量值设为 `ON`，TiDB 则自动忽略此类功能不可用的情况，即不会报错。若用户无法更改 SQL 代码，可考虑将变量值设为 `ON`。 - 启用 `noop` 函数可以控制以下行为： * `LOCK IN SHARE MODE` 语法 @@ -1456,6 +1782,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 若该变量值为 `OFF`，TiDB 具有以下行为： * 使用 `SET` 设置 `noop` 的系统变量时会报 `"setting *variable_name* has no effect in TiDB"` 的警告。 @@ -1505,6 +1832,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用于控制是否使用分页 (paging) 方式发送 Coprocessor 请求。对于 [v5.4.0, v6.2.0) 区间的 TiDB 版本，该变量只对 `IndexLookup` 算子生效；对于 v6.2.0 以及之后的版本，该变量对全局生效。从 v6.4.0 版本开始，该变量默认值由 `OFF` 改成 `ON`。 - 适用场景： @@ -1521,7 +1849,8 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 -- 默认值：0 +- 类型：布尔型 +- 默认值：`OFF` - 这个变量用于控制是否开启 Apply 算子并发，并发数由 `tidb_executor_concurrency` 变量控制。Apply 算子用来处理关联子查询且默认无并发，所以执行速度较慢。打开 Apply 并发开关可增加并发度，提高执行速度。目前默认关闭。 ### `tidb_enable_pipelined_window_function` @@ -1568,6 +1897,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用来控制是否开启 [Prepared Plan Cache](/sql-prepared-plan-cache.md)。开启后，对 `Prepare`、`Execute` 请求的执行计划会进行缓存，以便在后续执行时跳过查询计划优化这个步骤，获得性能上的提升。 - 在 v6.1.0 之前这个开关通过 TiDB 配置文件 (`prepared-plan-cache.enabled`) 进行配置，升级到 v6.1.0 时会自动继承原有设置。 @@ -1576,6 +1906,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用来控制是否统计 Prepared Plan Cache 中所缓存的执行计划占用的内存。具体可见 [Prepared Plan Cache 的内存管理](/sql-prepared-plan-cache.md#prepared-plan-cache-的内存管理)。 @@ -1583,6 +1914,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用来控制优化器在一张表上的统计信息过期时的行为。 - 统计信息过期的判断标准：最近一次对某张表执行 `ANALYZE` 获得统计信息后，该表数据被修改的行数大于该表总行数的 80%，便可判定该表的统计信息已过期。该比例可通过 [`pseudo-estimate-ratio`](/tidb-configuration-file.md#pseudo-estimate-ratio) 配置参数调整。 @@ -1593,6 +1925,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量控制是否为读数据的算子开启动态内存控制功能。读数据的算子默认启用 [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency) 所允许的最大线程数来读取数据。当单条 SQL 语句的内存使用每超过 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 一次，读数据的算子会停止一个线程。 - 当读数据的算子只剩 1 个线程且当单条 SQL 语句的内存使用继续超过 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 时，该 SQL 语句会触发其它的内存控制行为，例如[落盘](/system-variables.md#tidb_enable_tmp_storage_on_oom)。 @@ -1600,10 +1933,6 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 ### `tidb_enable_resource_control` 从 v6.6.0 版本开始引入 -> **警告：** -> -> [资源管控](/tidb-resource-control.md) 目前为实验性特性，此变量定义可能在之后发生变化或者删除。 - - 作用域：GLOBAL - 是否持久化到集群：是 - 默认值：`ON` @@ -1614,6 +1943,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 可选值：`OFF`，`ON` - 该变量用于控制 TiDB 是否启用 Chunk 对象缓存。如果为 `ON`，则优先使用缓存中的 Chunk 对象，缓存中找不到申请的对象时才会从系统内存中申请。如果为 `OFF`，则直接从系统内存中申请 Chunk 对象。 @@ -1622,6 +1952,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：否，仅作用于当前连接的 TiDB 实例 +- 类型：布尔型 - 默认值：`ON` - 这个变量用于控制是否开启 slow log 功能。 @@ -1629,6 +1960,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用来控制是否开启 statement summary 功能。如果开启，SQL 的耗时等执行信息将被记录到系统表 `information_schema.STATEMENTS_SUMMARY` 中，用于定位和排查 SQL 性能问题。 @@ -1636,6 +1968,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用来控制是否可以用 `DOUBLE` 类型的无效定义创建表。该设置的目的是提供一个从 TiDB 早期版本升级的方法，因为早期版本在验证类型方面不太严格。 - 该变量的默认值 `ON` 与 MySQL 兼容。 @@ -1660,6 +1993,7 @@ Query OK, 0 rows affected (0.09 sec) - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 - 默认值：`ON` +- 类型：枚举型 - 可选值：`OFF`，`ON`，`AUTO` - 这个变量用来设置是否开启 `TABLE PARTITION` 特性。目前变量支持以下三种值： - 默认值 `ON` 表示开启 TiDB 当前已实现了的分区表类型，目前 Range partition、Hash partition 以及 Range column 单列的场景会生效。 @@ -1670,23 +2004,39 @@ Query OK, 0 rows affected (0.09 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用于动态地控制 TiDB 遥测功能是否开启，当前版本默认关闭 TiDB 的遥测功能。当所有 TiDB 实例都设置配置项 [`enable-telemetry`](/tidb-configuration-file.md#enable-telemetry-从-v402-版本开始引入) 为 `false` 时，将忽略该系统变量，并总是关闭 TiDB 遥测功能。参阅[遥测](/telemetry.md)了解该功能详情。 -### `tidb_enable_tiflash_read_for_write_stmt` 从 v6.3.0 版本开始引入 +### `tidb_enable_tiflash_pipeline_model` 从 v7.2.0 版本开始引入 -> **警告：** +- 作用域：SESSION | GLOBAL +- 是否持久化到集群：是 +- 类型：布尔型 +- 默认值：`OFF` +- 这个变量用来控制是否启用 TiFlash 新的执行模型 [Pipeline Model](/tiflash/tiflash-pipeline-model.md)。 +- 当设置该变量为 `OFF` 关闭 TiFlash Pipeline Model 时，下推到 TiFlash 的查询会使用 TiFlash 原有的执行模型 Stream Model 来执行。 +- 当设置该变量为 `ON` 开启 TiFlash Pipeline Model 时，下推到 TiFlash 的查询会使用 TiFlash 新的执行模型 Pipeline Model 来执行。 + +> **注意：** +> +> - TiFlash Pipeline Model 目前为实验特性，不建议在生产环境中使用。 +> - TiFlash Pipeline Model 目前不支持以下功能。当下列功能开启时，即使 `tidb_enable_tiflash_pipeline_model` 设置为 `ON`，下推到 TiFlash 的查询仍会使用原有的执行模型 Stream Model 来执行。 > -> 当前版本中该变量控制的功能是实验性功能，暂不建议在生产环境中使用。 +> - [Join 算子落盘](#tidb_max_bytes_before_tiflash_external_join-从-v700-版本开始引入) +> - [TiFlash 存算分离架构与 S3](/tiflash/tiflash-disaggregated-and-s3.md) + +### `tidb_enable_tiflash_read_for_write_stmt` 从 v6.3.0 版本开始引入 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 - 类型：布尔型 -- 默认值：`OFF` +- 默认值：`ON` - 这个变量用于控制包含增删改的 SQL 语句中的读取操作能否下推到 TiFlash，比如： - `INSERT INTO SELECT` 语句中的 `SELECT` 查询（典型应用场景为 [TiFlash 查询结果物化](/tiflash/tiflash-results-materialization.md)） - `UPDATE` 和 `DELETE` 语句中的 `WHERE` 条件过滤 +- 从 v7.1.0 开始，该变量废弃。当 [`tidb_allow_mpp = ON`](/system-variables.md#tidb_allow_mpp-从-v50-版本开始引入) 时，优化器将根据 [SQL 模式](/sql-mode.md)及 TiFlash 副本的代价估算自行决定是否将查询下推至 TiFlash。需要注意的是，只有当前会话的 [SQL 模式](/sql-mode.md)为非严格模式（即 `sql_mode` 值不包含 `STRICT_TRANS_TABLES` 和 `STRICT_ALL_TABLES`）时，TiDB 才允许将包含增删改的 SQL 语句（如 `INSERT INTO SELECT`）中的读取操作下推至 TiFlash。 ### `tidb_enable_tmp_storage_on_oom` @@ -1705,6 +2055,7 @@ Query OK, 0 rows affected (0.09 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用于控制是否开启 [Top SQL 特性](/dashboard/top-sql.md)。 @@ -1712,6 +2063,7 @@ Query OK, 0 rows affected (0.09 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用来开启 TSO Follower Proxy 特性。当该值为 `OFF` 时，TiDB 仅会从 PD leader 获取 TSO。开启该特性之后，TiDB 在获取 TSO 时会将请求均匀地发送到所有 PD 节点上，通过 PD follower 转发 TSO 请求，从而降低 PD leader 的 CPU 压力。 - 适合开启 TSO Follower Proxy 的场景： @@ -1734,6 +2086,7 @@ Query OK, 0 rows affected (0.09 sec) - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用于控制是否开启向量化执行。 @@ -1741,13 +2094,23 @@ Query OK, 0 rows affected (0.09 sec) - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用来控制是否开启窗口函数的支持。默认值 1 代表开启窗口函数的功能。 - 由于窗口函数会使用一些保留关键字，可能导致原先可以正常执行的 SQL 语句在升级 TiDB 后无法被解析语法，此时可以将 `tidb_enable_window_function` 设置为 `OFF`。 +### `tidb_enable_row_level_checksum` 从 v7.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 类型：布尔型 +- 默认值：`OFF` +- 这个变量用于控制是否开启 [TiCDC 单行数据正确性校验](/ticdc/ticdc-integrity-check.md)功能。 + ### `tidb_enforce_mpp` 从 v5.1 版本开始引入 - 作用域：SESSION +- 类型：布尔型 - 默认值：`OFF`（表示关闭）。如需修改此变量的默认值，请配置 [`performance.enforce-mpp`](/tidb-configuration-file.md#enforce-mpp) 参数。 - 这个变量用于控制是否忽略优化器代价估算，强制使用 TiFlash 的 MPP 模式执行查询，可以设置的值包括： - 0 或 OFF，代表不强制使用 MPP 模式（默认） @@ -1759,6 +2122,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用于控制是否启用自动演进绑定功能。该功能的详细介绍和使用方法可以参考[自动演进绑定](/sql-plan-management.md#自动演进绑定-baseline-evolution)。 - 为了减少自动演进对集群的影响，可以进行以下配置： @@ -1770,6 +2134,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：时间 - 默认值：`23:59 +0000` - 这个变量用来设置一天中允许自动演进的结束时间。 @@ -1777,6 +2142,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`600` - 范围：`[-1, 9223372036854775807]` - 单位：秒 @@ -1786,6 +2152,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：时间 - 默认值：`00:00 +0000` - 这个变量用来设置一天中允许自动演进的开始时间。 @@ -1793,6 +2160,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`5` - 范围：`[1, 256]` - 单位：线程 @@ -1824,11 +2192,22 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：GLOBAL - 是否持久化到集群：否，仅作用于当前连接的 TiDB 实例 +- 类型：整数型 - 默认值：`60` - 范围：`[10, 2147483647]` - 单位：秒 - 这个变量用来控制打印 expensive query 日志的阈值时间，默认值是 60 秒。expensive query 日志和慢日志的差别是，慢日志是在语句执行完后才打印，expensive query 日志可以把正在执行中的语句且执行时间超过阈值的语句及其相关信息打印出来。 +### `tidb_expensive_txn_time_threshold` 从 v7.2.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：否，仅作用于当前连接的 TiDB 实例 +- 类型：整数型 +- 默认值：`600` +- 范围：`[60, 2147483647]` +- 单位：秒 +- 这个变量用来控制打印 expensive transaction 日志的阈值时间，默认值是 600 秒。expensive transaction 日志会将尚未 COMMIT 或 ROLLBACK 且持续时间超过该阈值的事务的相关信息打印出来。 + ### `tidb_force_priority` - 作用域：GLOBAL @@ -1843,6 +2222,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`-1` - 范围：`[1, 256]` - 单位：线程 @@ -1852,6 +2232,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用于控制是否启用 TiKV 的垃圾回收 (GC) 机制。如果不启用 GC 机制，系统将不再清理旧版本的数据，因此会有损系统性能。 @@ -1859,6 +2240,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：Duration - 默认值：`10m0s` - 范围：`[10m0s, 8760h0m0s]` - 这个变量用于指定每次进行垃圾回收 (GC) 时保留数据的时限。变量值为 Go 的 Duration 字符串格式。每次进行 GC 时，将以当前时间减去该变量的值作为 safe point。 @@ -1884,6 +2266,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：Duration - 默认值：`10m0s` - 范围：`[10m0s, 8760h0m0s]` - 这个变量用于指定垃圾回收 (GC) 运行的时间间隔。变量值为 Go 的 Duration 字符串格式，如`"1h30m"`、`"15m"`等。 @@ -1896,6 +2279,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：枚举型 - 默认值：`LEGACY` - 可设置为：`PHYSICAL`，`LEGACY` - `LEGACY`：使用旧的扫描方式，即禁用 Green GC。 @@ -1906,6 +2290,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：GLOBAL - 是否持久化到集群：否，仅作用于当前连接的 TiDB 实例 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用来设置是否在[日志](/tidb-configuration-file.md#logfile)里记录所有的 SQL 语句。该功能默认关闭。如果系统运维人员在定位问题过程中需要追踪所有 SQL 记录，可考虑开启该功能。 - 在 TiDB 配置项 [`log.level`](/tidb-configuration-file.md#level) 为 `"info"` 或 `"debug"` 时，通过查询 `"GENERAL_LOG"` 字符串可以定位到该功能在日志中的所有记录。日志会记录以下内容： @@ -1923,7 +2308,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） > **警告：** > -> 非 Prepare 语句执行计划缓存目前为实验特性，不建议在生产环境中使用。该功能可能会在未事先通知的情况下发生变化或删除。如果发现 bug，请在 GitHub 上提 [issue](https://github.com/pingcap/tidb/issues) 反馈。 +> 从 v7.1.0 开始，该变量被废弃。请使用 [`tidb_session_plan_cache_size`](#tidb_session_plan_cache_size-从-v710-版本开始引入) 进行设置。 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 @@ -1945,7 +2330,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） ### `tidb_gogc_tuner_threshold` 从 v6.4.0 版本开始引入 - 作用域：GLOBAL -- 是否持久化到集群：否，仅作用于当前连接的 TiDB 实例 +- 是否持久化到集群：是 - 默认值：`0.6` - 范围：`[0, 0.9)` - 这个变量用来控制 GOGC Tuner 自动调节的最大内存阈值，超过阈值后 GOGC Tuner 会停止工作。 @@ -1977,6 +2362,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`-1` - 范围：`[1, 256]` - 单位：线程 @@ -1991,6 +2377,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`-1` - 范围：`[1, 256]` - 单位：线程 @@ -2005,6 +2392,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`-1` - 范围：`[1, 256]` - 单位：线程 @@ -2023,6 +2411,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用来设置是否忽略关闭 Prepared Statement 的指令。 - 如果变量值设为 `ON`，Binary 协议的 `COM_STMT_CLOSE` 信号和文本协议的 [`DEALLOCATE PREPARE`](/sql-statements/sql-statement-deallocate.md) 语句都会被忽略。 @@ -2031,6 +2420,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`25000` - 范围：`[1, 2147483647]` - 单位：行 @@ -2088,6 +2478,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`20000` - 范围：`[1, 2147483647]` - 单位：行 @@ -2097,6 +2488,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`1` - 范围：`[1, 256]` - 单位：线程 @@ -2106,6 +2498,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`32` - 范围：`[1, 32]` - 单位：行 @@ -2155,21 +2548,18 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） ### `tidb_load_based_replica_read_threshold` 从 v7.0.0 版本开始引入 -> **警告：** -> -> 当前版本中该变量控制的功能尚未完全生效，请保留默认值。 - - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 -- 默认值：`"0s"` +- 默认值：`"1s"` - 范围：`[0s, 1h]` - 类型：字符串 -- 这个变量用来设置基于负载的 replica read 的触发阈值。当 leader 节点的预估排队时间超过阈值时，TiDB 会优先从 follower 节点读取数据。格式为时间，例如 `"100ms"` 或 `"1s"`。 +- 这个变量用来设置基于负载的 replica read 的触发阈值。当 leader 节点的预估排队时间超过阈值时，TiDB 会优先从 follower 节点读取数据。格式为时间，例如 `"100ms"` 或 `"1s"`。详情见 [TiDB 热点问题处理](/troubleshoot-hot-spot-issues.md#打散读热点)。 ### `tidb_log_file_max_days` 从 v5.3.0 版本开始引入 - 作用域：GLOBAL - 是否持久化到集群：否，仅作用于当前连接的 TiDB 实例 +- 类型：整数型 - 默认值：`0` - 范围：`[0, 2147483647]` - 这个变量可以调整当前 TiDB 实例上日志的最大保留天数。默认值是实例配置文件中指定的值，见配置项 [`max-days`](/tidb-configuration-file.md#max-days)。此变量只影响当前 TiDB 实例上的配置，重启后丢失，且配置文件不受影响。 @@ -2177,6 +2567,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） ### `tidb_low_resolution_tso` - 作用域：SESSION +- 类型：布尔型 - 默认值：`OFF` - 这个变量用来设置是否启用低精度 TSO 特性。开启该功能之后，新事务会使用一个每 2s 更新一次的 TS 来读取数据。 - 主要场景是在可以容忍读到旧数据的情况下，降低小的只读事务获取 TSO 的开销。 @@ -2245,6 +2636,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`1024` - 范围：`[32, 2147483647]` - 单位：行 @@ -2254,6 +2646,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`1024` - 范围：`[100, 16384]` - 这个变量用来设置缓存 schema 版本信息（对应版本修改的相关 table IDs）的个数限制，可设置的范围 100 - 16384。此变量在 2.1.18 及之后版本支持。 @@ -2262,6 +2655,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`50000` - 范围：`[1, 9223372036854775807]` - 单位：行 @@ -2281,6 +2675,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：枚举型 - 默认值：`CANCEL` - 可选值：`CANCEL`，`LOG` - 该变量控制当单个查询使用的内存超过限制 (`tidb_mem_quota_query`) 且不能再利用临时磁盘时，TiDB 所采取的操作。详情见 [TiDB 内存控制](/configure-memory-usage.md)。 @@ -2309,6 +2704,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`33554432` (32 MiB) - 范围：`[0, 9223372036854775807]` - 单位：字节 @@ -2319,6 +2715,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`67108864` (64 MiB) - 范围：`[0, 2147483647]` - 单位：字节 @@ -2329,6 +2726,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`1073741824` (1 GiB) - 范围：`[-1, 9223372036854775807]` - 单位：字节 @@ -2357,6 +2755,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：浮点数 - 默认值：`0.7` - 范围：`[0.0, 1.0]` - 这个变量用于设置触发 tidb-server 内存告警的内存使用比率。默认情况下，当 TiDB 内存使用量超过总内存的 70% 且满足[报警条件](/configure-memory-usage.md#tidb-server-内存占用过高时的报警)时，TiDB 会打印报警日志。 @@ -2398,6 +2797,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） ### `tidb_metric_query_range_duration` 从 v4.0 版本开始引入 - 作用域：SESSION +- 类型：整数型 - 默认值：`60` - 范围：`[10, 216000]` - 单位：秒 @@ -2406,6 +2806,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） ### `tidb_metric_query_step` 从 v4.0 版本开始引入 - 作用域：SESSION +- 类型：整数型 - 默认值：`60` - 范围：`[10, 216000]` - 单位：秒 @@ -2415,6 +2816,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`128` - 范围：`[1, 9223372036854775807]` - 单位：行 @@ -2436,6 +2838,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：枚举型 - 默认值：`OFF` - 可选值：`OFF`，`ON`，`WARN` - 该变量用于控制是否在同一个 `COM_QUERY` 调用中执行多个查询。 @@ -2500,6 +2903,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`1` - 范围：`[0, 2147483647]` - 当交叉估算方法不可用时，会采用启发式估算方法。这个变量用来控制启发式方法的行为。当值为 0 时不用启发式估算方法，大于 0 时，该变量值越大，启发式估算方法越倾向 index scan，越小越倾向 table scan。 @@ -2508,7 +2912,9 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：浮点数 - 默认值：`0.9` +- 范围：`[0, 1]` - 这个变量用来设置优化器启用交叉估算 row count 方法的阈值。如果列和 handle 列之间的顺序相关性超过这个阈值，就会启用交叉估算方法。 - 交叉估算方法可以简单理解为，利用这个列的直方图来估算 handle 列需要扫的行数。 @@ -2550,6 +2956,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） ### `tidb_opt_distinct_agg_push_down` - 作用域：SESSION +- 类型：布尔型 - 默认值：`OFF` - 这个变量用来设置优化器是否执行带有 `Distinct` 的聚合函数（比如 `select count(distinct a) from t`）下推到 Coprocessor 的优化操作。当查询中带有 `Distinct` 的聚合操作执行很慢时，可以尝试设置该变量为 `1`。 @@ -2585,17 +2992,40 @@ mysql> desc select count(distinct a) from test.t; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用来控制优化器是否开启交叉估算。 ### `tidb_opt_enable_late_materialization` 从 v7.0.0 版本开始引入 +- 作用域：SESSION | GLOBAL +- 是否持久化到集群：是 +- 类型：布尔型 +- 默认值：`ON` +- 这个变量用来控制是否启用 [TiFlash 延迟物化](/tiflash/tiflash-late-materialization.md)功能。注意在 TiFlash [Fast Scan 模式](/tiflash/use-fastscan.md)下，延迟物化功能暂不可用。 +- 当设置该变量为 `OFF` 关闭 TiFlash 延迟物化功能时，如果 `SELECT` 语句中包含过滤条件（`WHERE` 子句），TiFlash 会先扫描查询所需列的全部数据后再进行过滤。当设置该变量为 `ON` 开启 TiFlash 延迟物化功能时，TiFlash 会先扫描下推到 TableScan 算子的过滤条件相关的列数据，过滤得到符合条件的行后，再扫描这些行的其他列数据，继续后续计算，从而减少 IO 扫描和数据处理的计算量。 + +### `tidb_opt_enable_mpp_shared_cte_execution` 从 v7.2.0 版本开始引入 + +> **警告：** +> +> 当前版本中该变量控制的功能尚未完全生效，请保留默认值。 + - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 - 类型：布尔型 - 默认值：`OFF` -- 这个变量用来控制是否启用 [TiFlash 延迟物化](/tiflash/tiflash-late-materialization.md)功能。 -- 默认情况下，如果 `SELECT` 语句中包含过滤条件（`WHERE` 子句），TiFlash 会先扫描查询所需列的全部数据后再进行过滤。当设置该变量为 `ON` 开启 TiFlash 延迟物化功能时，TiFlash 可以先扫描过滤条件相关的列数据，过滤得到符合条件的行后，再扫描这些行的其他列数据，继续后续计算，从而减少 IO 扫描和数据处理的计算量。 +- 该变量控制非递归的[公共表表达式 (CTE)](/sql-statements/sql-statement-with.md) 是否可以直接在 TiFlash MPP 执行而不是在 TiDB 上执行。 + +### `tidb_opt_fix_control` 从 v7.1.0 版本开始引入 + +- 作用域：SESSION | GLOBAL +- 是否持久化到集群：是 +- 类型：字符串 +- 默认值：`""` +- 这个变量用来控制优化器的一些内部行为。 +- 一部分优化器行为的选择依赖用户场景或 SQL 编写方式。通过设置该变量，你可以更细粒度地控制优化器的行为，并且避免集群升级后优化器行为变化导致的性能回退。 +- 详细介绍请参考 [Optimizer Fix Controls](/optimizer-fix-controls.md)。 ### `tidb_opt_force_inline_cte` 从 v6.3.0 版本开始引入 @@ -2621,6 +3051,7 @@ mysql> desc select count(distinct a) from test.t; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用来设置是否开启优化规则：将子查询转成 join 和 aggregation。 @@ -2662,6 +3093,7 @@ mysql> desc select count(distinct a) from test.t; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`100` - 范围：`[0, 2147483647]` - 这个变量用来设置将 Limit 和 TopN 算子下推到 TiKV 的阈值。 @@ -2737,6 +3169,7 @@ mysql> desc select count(distinct a) from test.t; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 将该变量值设为 `ON` 后，优化器总是偏好区间扫描而不是全表扫描。 - 在以下示例中，`tidb_opt_prefer_range_scan` 开启前，TiDB 优化器需要执行全表扫描。`tidb_opt_prefer_range_scan` 开启后，优化器选择了索引区间扫描。 @@ -2928,6 +3361,7 @@ SHOW WARNINGS; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用来设置优化器是否将带有 `DISTINCT` 的聚合函数（例如 `SELECT b, count(DISTINCT a) FROM t GROUP BY b`）改写为两层聚合函数（例如 `SELECT b, count(a) FROM (SELECT b, a FROM t GROUP BY b, a) t GROUP BY b`）。当聚合列有严重的数据倾斜，且 `DISTINCT` 列有很多不同的值时，这种改写能够避免查询执行过程中的数据倾斜，从而提升查询性能。 @@ -2977,6 +3411,7 @@ SHOW WARNINGS; - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用于控制是否开启 [ANALYZE 配置持久化](/statistics.md#analyze-配置持久化)特性。 @@ -2999,15 +3434,37 @@ SHOW WARNINGS; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：枚举型 - 默认值：`STRICT` - 可选值：`STRICT`，`IGNORE` - 该变量用于控制 DDL 语句是否忽略 [Placement Rules in SQL](/placement-rules-in-sql.md) 指定的放置规则。变量值为 `IGNORE` 时将忽略所有放置规则选项。 - 该变量可由逻辑转储或逻辑恢复工具使用，确保即使绑定了不合适的放置规则，也始终可以成功创建表。这类似于 mysqldump 将 `SET FOREIGN_KEY_CHECKS=0;` 写入每个转储文件的开头部分。 +### `tidb_plan_cache_invalidation_on_fresh_stats` 从 v7.1.0 版本开始引入 + +- 作用域：SESSION | GLOBAL +- 是否持久化到集群：是 +- 类型：布尔型 +- 默认值：`ON` +- 该变量用于控制当某张表上的统计信息更新后，与该表相关的 Plan Cache 是否自动失效。 +- 开启此变量有助于 Plan Cache 更有效地利用可用的统计信息生成执行计划，例如： + - 有时 Plan Cache 会在统计信息尚不可用时生成执行计划。开启此变量后，Plan Cache 会在统计信息可用时重新生成执行计划。 + - 当表上数据分布发生变化时，之前的最优执行计划可能对于现在不再是最优的。开启此变量后，Plan Cache 会在重新收集统计信息后重新生成执行计划。 +- 对于从 v7.1.0 以前的版本升级到 v7.1.0 及以上版本的 TiDB 集群，该选项默认关闭 (`OFF`)。 + +### `tidb_plan_cache_max_plan_size` 从 v7.1.0 版本开始引入 + +- 作用域：SESSION | GLOBAL +- 是否持久化到集群：是 +- 默认值：`2097152`（即 2 MB） +- 取值范围：`[0, 9223372036854775807]`，单位为 Byte。支持带单位的内存格式“KB|MB|GB|TB”。`0` 表示表示不设限制。 +- 这个变量用来控制可以缓存的 Prepare 或非 Prepare 语句执行计划的最大大小。超过该值的执行计划将不会被缓存到 Plan Cache 中。详情请参考 [Prepare 语句执行计划缓存](/sql-prepared-plan-cache.md#prepared-plan-cache-的内存管理)和[非 Prepare 语句执行计划缓存](/sql-non-prepared-plan-cache.md#使用方法)。 + ### `tidb_pprof_sql_cpu` 从 v4.0 版本开始引入 - 作用域：GLOBAL - 是否持久化到集群：否，仅作用于当前连接的 TiDB 实例 +- 类型：整数型 - 默认值：`0` - 范围：`[0, 1]` - 这个变量用来控制是否在 profile 输出中标记出对应的 SQL 语句，用于定位和排查性能问题。 @@ -3016,6 +3473,7 @@ SHOW WARNINGS; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用于控制 TiDB 优化器是否将某些过滤条件下推到前缀索引，尽量避免不必要的回表，从而提高查询性能。 - 将该变量设置为 `ON` 时，会将过滤条件下推到前缀索引。此时，假设一张表中 `col` 列是索引前缀列，查询语句中的 `col is null` 或者 `col is not null` 条件会被归为索引上的过滤条件，而不是回表时的过滤条件，从而避免不必要的回表。 @@ -3075,10 +3533,20 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; +### `tidb_prefer_broadcast_join_by_exchange_data_size` 从 v7.1.0 版本开始引入 + +- 作用域：SESSION | GLOBAL +- 是否持久化到集群：是 +- 类型：布尔型 +- 默认值：`OFF` +- 这个变量用于设定 TiDB 选择 [MPP Hash Join 算法](/tiflash/use-tiflash-mpp-mode.md#mpp-模式的算法支持)时，是否使用最小网络交换的数据量策略。开启该变量后，TiDB 会估算 Broadcast Hash Join 和 Shuffled Hash Join 两种算法所需进行网络交换的数据量，并选择网络交换数据量较小的算法。 +- 该功能开启后 [`tidb_broadcast_join_threshold_count`](#tidb_broadcast_join_threshold_count-从-v50-版本开始引入) 和 [`tidb_broadcast_join_threshold_size`](#tidb_broadcast_join_threshold_size-从-v50-版本开始引入) 将不再生效。 + ### `tidb_prepared_plan_cache_memory_guard_ratio` 从 v6.1.0 版本开始引入 - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：浮点数 - 默认值：`0.1` - 范围：`[0, 1]` - 这个变量用来控制 Prepared Plan Cache 触发内存保护机制的阈值，具体可见 [Prepared Plan Cache 的内存管理](/sql-prepared-plan-cache.md#prepared-plan-cache-的内存管理)。 @@ -3086,8 +3554,13 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; ### `tidb_prepared_plan_cache_size` 从 v6.1.0 版本开始引入 +> **警告：** +> +> 从 v7.1.0 开始，该变量被废弃。请使用 [`tidb_session_plan_cache_size`](#tidb_session_plan_cache_size-从-v710-版本开始引入) 进行设置。 + - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`100` - 范围：`[1, 100000]` - 这个变量用来控制单个 `SESSION` 的 Prepared Plan Cache 最多能够缓存的计划数量，具体可见 [Prepared Plan Cache 的内存管理](/sql-prepared-plan-cache.md#prepared-plan-cache-的内存管理)。 @@ -3101,6 +3574,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`-1` - 范围：`[-1, 256]` - 单位：线程 @@ -3111,6 +3585,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`4096` (4 KiB) - 范围：`[0, 1073741824]` - 单位：字节 @@ -3127,6 +3602,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; - 作用域：GLOBAL - 是否持久化到集群：否，仅作用于当前连接的 TiDB 实例 +- 类型：布尔型 - 默认值：`OFF` - 该变量用于优化时间戳的获取，适用于悲观事务 `READ-COMMITTED` 隔离级别下读写冲突较少的场景，开启此变量可以避免获取全局 timestamp 带来的延迟和开销，并优化事务内读语句延迟。 - 如果读写冲突较为严重，开启此功能会增加额外开销和延迟，造成性能回退。更详细的说明，请参考[读已提交隔离级别 (Read Committed) 文档](/transaction-isolation-levels.md#读已提交隔离级别-read-committed)。 @@ -3156,6 +3632,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; ### `tidb_read_staleness` 从 v5.4.0 版本开始引入 - 作用域：SESSION +- 类型：整数型 - 默认值：`0` - 范围 `[-2147483648, 0]` - 这个变量用于设置当前会话允许读取的历史数据范围。设置后，TiDB 会从参数允许的范围内选出一个尽可能新的时间戳，并影响后继的所有读操作。比如，如果该变量的值设置为 `-5`，TiDB 会在 5 秒时间范围内，保证 TiKV 拥有对应历史版本数据的情况下，选择尽可能新的一个时间戳。 @@ -3164,6 +3641,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; - 作用域：GLOBAL - 是否持久化到集群：否，仅作用于当前连接的 TiDB 实例 +- 类型：布尔型 - 默认值：`ON` - 这个变量用于控制是否在 slow log 里包含慢查询的执行计划。 @@ -3171,6 +3649,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用于控制在记录 TiDB 日志和慢日志时，是否将 SQL 中的用户信息遮蔽。 - 将该变量设置为 `1` 即开启后，假设执行的 SQL 为 `insert into t values (1,2)`，在日志中记录的 SQL 会是 `insert into t values (?,?)`，即用户输入的信息被遮蔽。 @@ -3179,6 +3658,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用来控制优化器是否可以将包含 null 的等值条件作为前缀条件来访问索引。 - 该变量默认开启。开启后，该变量可以使优化器减少需要访问的索引数据量，从而提高查询的执行速度。例如，在有多列索引 `index(a, b)` 且查询条件为 `a<=>null and b=1` 的情况下，优化器可以同时使用查询条件中的 `a<=>null` 和 `b=1` 进行索引访问。如果关闭该变量，因为 `a<=>null and b=1` 包含 null 的等值条件，优化器不会使用 `b=1` 进行索引访问。 @@ -3188,13 +3668,14 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 - 类型：布尔型 -- 默认值：`OFF` +- 默认值：在 v7.2.0 之前版本中为 `OFF`，在 v7.2.0 及之后版本中为 `ON`。 - 指定是否在子查询中移除 `ORDER BY` 子句。 ### `tidb_replica_read` 从 v4.0 版本开始引入 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：枚举型 - 默认值：`leader` - 可选值：`leader`、`follower`、`leader-and-follower`、`prefer-leader`、`closest-replicas`、`closest-adaptive` 和 `learner`。其中，`learner` 从 v6.6.0 开始引入。 - 这个变量用于控制 TiDB 的 Follower Read 功能的行为。 @@ -3204,6 +3685,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`10` - 范围：`[-1, 9223372036854775807]` - 这个变量用来设置乐观事务的最大重试次数。一个事务执行中遇到可重试的错误（例如事务冲突、事务提交过慢或表结构变更）时，会根据该变量的设置进行重试。注意当 `tidb_retry_limit = 0` 时，也会禁用自动重试。该变量仅适用于乐观事务，不适用于悲观事务。 @@ -3212,6 +3694,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`2` - 范围：`[1, 2]` - 控制新保存数据的表数据格式版本。TiDB v4.0 中默认使用版本号为 2 的[新表数据格式](https://github.com/pingcap/tidb/blob/master/docs/design/2018-07-19-row-format.md)保存新数据。 @@ -3220,10 +3703,35 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; - 需要注意的是修改该变量不会对已保存的老数据产生影响，只会对修改变量后的新写入数据使用对应版本格式保存。 +### `tidb_runtime_filter_mode` 从 v7.2.0 版本开始引入 + +> **警告：** +> +> 当前版本中该变量控制的功能尚未完全生效，请保留默认值。 + +- 作用域：SESSION | GLOBAL +- 是否持久化到集群：是 +- 类型：枚举型 +- 默认值：`OFF` +- 可选值：`OFF`，`LOCAL` + +### `tidb_runtime_filter_type` 从 v7.2.0 版本开始引入 + +> **警告：** +> +> 当前版本中该变量控制的功能尚未完全生效，请保留默认值。 + +- 作用域：SESSION | GLOBAL +- 是否持久化到集群：是 +- 类型：枚举型 +- 默认值：`IN` +- 可选值：`IN` + ### `tidb_scatter_region` - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - TiDB 默认会在建表时为新表分裂 Region。开启该变量后，会在建表语句执行时，同步打散刚分裂出的 Region。适用于批量建表后紧接着批量写入数据，能让刚分裂出的 Region 先在 TiKV 分散而不用等待 PD 进行调度。为了保证后续批量写入数据的稳定性，建表语句会等待打散 Region 完成后再返回建表成功，建表语句执行时间会是该变量关闭时的数倍。 - 如果建表时设置了 `SHARD_ROW_ID_BITS` 和 `PRE_SPLIT_REGIONS`，建表成功后会均匀切分出指定数量的 Region。 @@ -3257,6 +3765,16 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; - 取值范围：`[128, 9223372036854775807]`，单位为 Byte。支持带单位的内存格式“KB|MB|GB|TB”。 - 开启内存限制后，TiDB 会终止当前实例上内存用量最高的 SQL 语句。本变量指定此情况下 SQL 语句被终止的最小内存用量。如果 TiDB 实例的内存超限是由许多内存使用量不明显的会话导致的，可以适当调小该变量值，使得更多会话成为 Cancel 的对象。 +### `tidb_session_plan_cache_size` 从 v7.1.0 版本开始引入 + +- 作用域：SESSION | GLOBAL +- 是否持久化到集群：是 +- 类型：整数型 +- 默认值：`100` +- 范围：`[1, 100000]` +- 这个变量用来控制 Plan Cache 最多能够缓存的计划数量。其中，[Prepare 语句执行计划缓存](/sql-prepared-plan-cache.md)和[非 Prepare 语句执行计划缓存](/sql-non-prepared-plan-cache.md)共用一个缓存。 +- 从旧版本升级到 v7.1.0 及之后的版本，`tidb_session_plan_cache_size` 的值与 [`tidb_prepared_plan_cache_size`](#tidb_prepared_plan_cache_size-从-v610-版本开始引入) 保持一致。 + ### `tidb_shard_allocate_step` 从 v5.0 版本开始引入 - 作用域：SESSION | GLOBAL @@ -3278,6 +3796,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用来设置是否校验 ASCII 字符的合法性。 - 校验 ASCII 字符会损耗些许性能。当你确认输入的字符串为有效的 ASCII 字符时，可以将其设置为 `ON`。 @@ -3286,6 +3805,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 开启这个开关之后，如果对 `tx_isolation` 赋值一个 TiDB 不支持的隔离级别，不会报错，有助于兼容其他设置了（但不依赖于）不同隔离级别的应用。 @@ -3303,6 +3823,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用来设置是否校验 UTF-8 字符的合法性。 - 校验 UTF-8 字符会损耗些许性能。当你确认输入的字符串为有效的 UTF-8 字符时，可以将其设置为 `ON`。 @@ -3316,6 +3837,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：GLOBAL - 是否持久化到集群：否，仅作用于当前连接的 TiDB 实例 - 默认值：`300` +- 类型：整数型 - 范围：`[-1, 9223372036854775807]` - 单位：毫秒 - 输出慢日志的耗时阈值。当查询大于这个值，就会当做是一个慢查询，输出到慢查询日志。默认为 300 ms。 @@ -3348,6 +3870,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`0` - 这个变量用于控制 TiDB 内部统计信息缓存使用内存的上限。 @@ -3355,6 +3878,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`100` - 单位：毫秒 - 范围：`[0, 2147483647]` @@ -3364,6 +3888,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用于控制统计信息同步加载超时后，SQL 是执行失败（`OFF`），还是退回使用 pseudo 的统计信息（`ON`）。 @@ -3428,6 +3953,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`24` - 范围：`[0, 255]` - 这个变量设置了 [statement summary tables](/statement-summary-tables.md) 的历史记录容量。 @@ -3436,6 +3962,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用来控制是否在 [statement summary tables](/statement-summary-tables.md) 中包含 TiDB 内部 SQL 的信息。 @@ -3443,6 +3970,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`4096` - 范围：`[0, 2147483647]` - 这个变量控制 [statement summary tables](/statement-summary-tables.md) 显示的 SQL 字符串长度。 @@ -3451,6 +3979,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`3000` - 范围：`[1, 32767]` - 这个变量设置了 [statement summary tables](/statement-summary-tables.md) 在内存中保存的语句的最大数量。 @@ -3459,6 +3988,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`1800` - 范围：`[1, 2147483647]` - 单位：秒 @@ -3486,6 +4016,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`5000` - 范围：`[1, 10000]` - 这个变量用于控制 [Top SQL](/dashboard/top-sql.md) 每分钟最多收集 SQL 语句类型的数量。 @@ -3494,6 +4025,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`100` - 范围：`[1, 5000]` - 这个变量用于控制 [Top SQL](/dashboard/top-sql.md) 每分钟保留消耗负载最大的前多少条 SQL（即 Top N) 的数据。 @@ -3506,6 +4038,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`0` - 范围：`[0, 9223372036854775807]` - 这个变量用于限制 TiDB 同时向 TiKV 发送的请求的最大数量，0 表示没有限制。 @@ -3532,6 +4065,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`OFF` - 这个变量用于控制 `SYSDATE` 函数能否替换为 `NOW` 函数，其效果与 MYSQL 中的 [`sysdate-is-now`](https://dev.mysql.com/doc/refman/8.0/en/server-options.html#option_mysqld_sysdate-is-now) 一致。 @@ -3548,6 +4082,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`3` - 范围：`[1, 10]` - 单位：秒 @@ -3557,6 +4092,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`67108864` - 范围：`[1048576, 137438953472]` - 单位：字节 @@ -3578,6 +4114,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：浮点数 - 默认值：`0` - 范围：`[0, 10]` - 单位：毫秒 @@ -3597,6 +4134,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`0` - 范围：`[0, 9223372036854775807]` - 这个变量用来对每个 TiDB 节点的 TTL 删除操作进行限流。其值代表了在 TTL 任务中单个节点每秒允许 `DELETE` 语句执行的最大次数。当此变量设置为 `0` 时，则表示不做限制。更多信息，请参考 [Time to Live](/time-to-live.md)。 @@ -3670,6 +4208,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：枚举型 - 默认值：`FAST` - 可选值：`OFF`，`FAST`，`STRICT` - 这个变量用于设置 assertion 级别。assertion 是一项在事务提交过程中进行的数据索引一致性校验，它对正在写入的 key 是否存在进行检查。如果不符则说明数据索引不一致，会导致事务 abort。详见[数据索引一致性报错](/troubleshoot-data-inconsistency-errors.md)。 @@ -3693,6 +4232,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：枚举型 - 默认值：`pessimistic` - 可选值：`pessimistic`，`optimistic` - 这个变量用于设置事务模式。TiDB v3.0 支持了悲观事务，自 v3.0.8 开始，默认使用[悲观事务模式](/pessimistic-transaction.md)。 @@ -3703,12 +4243,14 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用于控制是否开启执行计划绑定功能，默认打开，可通过赋值 `OFF` 来关闭。关于执行计划绑定功能的使用可以参考[执行计划绑定文档](/sql-plan-management.md#创建绑定)。 ### `tidb_wait_split_region_finish` - 作用域：SESSION +- 类型：布尔型 - 默认值：`ON` - 由于打散 Region 的时间可能比较长，主要由 PD 调度以及 TiKV 的负载情况所决定。这个变量用来设置在执行 `SPLIT REGION` 语句时，是否同步等待所有 Region 都打散完成后再返回结果给客户端。 - 默认 `ON` 代表等待打散完成后再返回结果 @@ -3718,6 +4260,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) ### `tidb_wait_split_region_timeout` - 作用域：SESSION +- 类型：整数型 - 默认值：`300` - 范围：`[1, 2147483647]` - 单位：秒 @@ -3731,6 +4274,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`-1` - 范围：`[1, 256]` - 单位：线程 @@ -3788,6 +4332,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：枚举型 - 默认值：`REPEATABLE-READ` - 可选值：`READ-UNCOMMITTED`，`READ-COMMITTED`，`REPEATABLE-READ`，`SERIALIZABLE` - 这个变量用于设置事务隔离级别。TiDB 为了兼容 MySQL，支持可重复读 (`REPEATABLE-READ`)，但实际的隔离级别是快照隔离。详情见[事务隔离级别](/transaction-isolation-levels.md)。 @@ -3903,7 +4448,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：NONE - 默认值：`5.7.25-TiDB-(tidb version)` -- 这个变量的值是 MySQL 的版本和 TiDB 的版本，例如 '5.7.25-TiDB-v4.0.0-beta.2-716-g25e003253'。 +- 这个变量的值是 MySQL 的版本和 TiDB 的版本，例如 '5.7.25-TiDB-v7.2.0'。 ### `version_comment` @@ -3927,6 +4472,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：整数型 - 默认值：`28800` - 范围：`[0, 31536000]` - 单位：秒 @@ -3942,5 +4488,6 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 +- 类型：布尔型 - 默认值：`ON` - 这个变量用于控制计算窗口函数时是否采用高精度模式。 diff --git a/ticdc/deploy-ticdc.md b/ticdc/deploy-ticdc.md index b8a76e15317a..cf86b34a0f3c 100644 --- a/ticdc/deploy-ticdc.md +++ b/ticdc/deploy-ticdc.md @@ -50,25 +50,25 @@ cdc_servers: 扩容的方式与部署 TiCDC 集群的方式类似，推荐使用 TiUP 工具完成。 -1. 编写一个名为 `scale-out.yaml` 的配置文件，包含需要扩容的节点的配置信息。下面是一个示例： +1. 编写一个名为 `scale-out.yml` 的配置文件，包含需要扩容的节点的配置信息。下面是一个示例： ```shell cdc_servers: - host: 10.1.1.1 gc-ttl: 86400 - data_dir: /data/deploy/install/data/cdc-8300 + data_dir: /tidb-data/cdc-8300 - host: 10.1.1.2 gc-ttl: 86400 - data_dir: /data/deploy/install/data/cdc-8300 - - host: 10.0.1.4:8300 + data_dir: /tidb-data/cdc-8300 + - host: 10.0.1.4 gc-ttl: 86400 - data_dir: /data/deploy/install/data/cdc-8300 + data_dir: /tidb-data/cdc-8300 ``` 2. 在 TiUP 中控机上执行类似下面的命令进行扩容： ```shell - tiup cluster scale-out scale-out.yaml + tiup cluster scale-out scale-out.yml ``` 更多用例说明，请参考[扩容 TiCDC 节点](/scale-tidb-using-tiup.md#扩容-ticdc-节点)。 @@ -95,7 +95,7 @@ tiup cluster upgrade --transfer-timeout 600 > **注意：** > -> 命令中的 `` 需要替换为集群名字，`` 需要替换为目标版本号，例如 v7.0.0。 +> 命令中的 `` 需要替换为集群名字，`` 需要替换为目标版本号，例如 v7.2.0。 ### 升级的注意事项 @@ -152,7 +152,7 @@ tiup cluster upgrade --transfer-timeout 600 ## 使用 TiCDC 命令行工具来查看集群状态 -执行以下命令来查看 TiCDC 集群运行状态，注意需要将 `v` 替换为 TiCDC 集群版本，例如 `v6.5.0`： +执行以下命令来查看 TiCDC 集群运行状态，注意需要将 `v` 替换为 TiCDC 集群版本，例如 `v7.2.0`： ```shell tiup ctl:v cdc capture list --server=http://10.0.10.25:8300 diff --git a/ticdc/monitor-ticdc.md b/ticdc/monitor-ticdc.md index e88f53b3dd62..503a89e2eba7 100644 --- a/ticdc/monitor-ticdc.md +++ b/ticdc/monitor-ticdc.md @@ -1,10 +1,10 @@ --- -title: TiCDC 重要监控指标详解 -summary: 了解 TiCDC 重要的监控指标。 +title: TiCDC 详细监控指标 +summary: 了解 TiCDC 详细的监控指标。 aliases: ['/zh/tidb/dev/ticdc-grafana-dashboard'] --- -# TiCDC 重要监控指标详解 +# TiCDC 详细监控指标 使用 TiUP 部署 TiDB 集群时，一键部署的监控系统面板包含 TiCDC 面板。本文档对 TiCDC 监控面板上的各项指标进行详细说明。在日常运维中，运维人员可通过观察 TiCDC 面板上的指标了解 TiCDC 当前的状态。 diff --git a/ticdc/ticdc-alert-rules.md b/ticdc/ticdc-alert-rules.md index a7909b426425..7fc1943e2474 100644 --- a/ticdc/ticdc-alert-rules.md +++ b/ticdc/ticdc-alert-rules.md @@ -15,7 +15,7 @@ summary: 了解 TiCDC 集群监控报警规则以及处理方法。 * 报警规则： - (time() - ticdc_processor_checkpoint_ts / 1000) > 600 + (time() - ticdc_owner_checkpoint_ts / 1000) > 600 * 规则描述： @@ -29,7 +29,7 @@ summary: 了解 TiCDC 集群监控报警规则以及处理方法。 * 报警规则： - (time() - ticdc_processor_resolved_ts / 1000) > 300 + (time() - ticdc_owner_resolved_ts / 1000) > 300 * 规则描述： @@ -71,25 +71,11 @@ summary: 了解 TiCDC 集群监控报警规则以及处理方法。 收集 TiCDC 日志，定位原因。 -### `ticdc_mounter_unmarshal_and_mount_time_more_than_1s` +### `cdc_sink_flush_duration_time_more_than_10s` * 报警规则： - `histogram_quantile(0.9, rate(ticdc_mounter_unmarshal_and_mount_bucket[1m])) * 1000 > 1000` - -* 规则描述： - - TiCDC 某一同步任务解码变更数据的耗时超过 1 秒。 - -* 处理方法： - - 收集 TiCDC 日志，定位原因。 - -### `cdc_sink_execute_duration_time_more_than_10s` - -* 报警规则： - - `histogram_quantile(0.9, rate(ticdc_sink_txn_exec_duration_bucket[1m])) > 10` + `histogram_quantile(0.9, rate(ticdc_sink_txn_worker_flush_duration[1m])) > 10` * 规则描述： diff --git a/ticdc/ticdc-avro-checksum-verification.md b/ticdc/ticdc-avro-checksum-verification.md new file mode 100644 index 000000000000..94694deceb54 --- /dev/null +++ b/ticdc/ticdc-avro-checksum-verification.md @@ -0,0 +1,514 @@ +--- +title: 基于 Avro 的 TiCDC 行数据 Checksum 校验 +summary: 介绍 TiCDC 行数据 Checksum 校验的具体实现。 +--- + +# 基于 Avro 的 TiCDC 行数据 Checksum 校验 + +本文介绍如何使用 Golang 消费 TiCDC 发送到 Kafka、且由 Avro 协议编码的数据，以及如何基于[单行数据 Checksum 功能](/ticdc/ticdc-integrity-check.md)进行数据校验。 + +本示例代码位于 [`avro-checksum-verification`](https://github.com/pingcap/tiflow/tree/master/examples/golang/avro-checksum-verification) 目录下。 + +本文使用 [kafka-go](https://github.com/segmentio/kafka-go) 实现一个简单的 Kafka Consumer 程序。该程序不断地从指定的 Topic 中读取数据、计算并校验 Checksum 值。 + +```go +package main + +import ( + "context" + "encoding/binary" + "encoding/json" + "hash/crc32" + "io" + "math" + "net/http" + "strconv" + "strings" + + "github.com/linkedin/goavro/v2" + "github.com/pingcap/log" + "github.com/pingcap/tidb/parser/mysql" + "github.com/pingcap/tidb/types" + "github.com/pingcap/tiflow/pkg/errors" + "github.com/segmentio/kafka-go" + "go.uber.org/zap" +) + +const ( + // confluent avro wire format, the first byte is always 0 + // https://docs.confluent.io/platform/current/schema-registry/fundamentals/serdes-develop/index.html#wire-format + magicByte = uint8(0) +) + +func main() { + var ( + kafkaAddr = "127.0.0.1:9092" + schemaRegistryURL = "http://127.0.0.1:8081" + + topic = "avro-checksum-test" + consumerGroupID = "avro-checksum-test" + ) + + consumer := kafka.NewReader(kafka.ReaderConfig{ + Brokers: []string{kafkaAddr}, + GroupID: consumerGroupID, + Topic: topic, + MaxBytes: 10e6, // 10MB + }) + defer consumer.Close() + + ctx := context.Background() + log.Info("start consuming ...", zap.String("kafka", kafkaAddr), zap.String("topic", topic), zap.String("groupID", consumerGroupID)) + for { + // 1. 获取 kafka 消息 + message, err := consumer.FetchMessage(ctx) + if err != nil { + log.Error("read kafka message failed", zap.Error(err)) + } + + value := message.Value + if len(value) == 0 { + log.Info("delete event does not have value, skip checksum verification", zap.String("topic", topic)) + } + + // 2. 对 value 进行解码，得到对应的 value map 和 schema map + valueMap, valueSchema, err := getValueMapAndSchema(value, schemaRegistryURL) + if err != nil { + log.Panic("decode kafka value failed", zap.String("topic", topic), zap.ByteString("value", value), zap.Error(err)) + } + + // 3. 使用上一步得到的 value map 和 schema map，计算并且校验 checksum + err = CalculateAndVerifyChecksum(valueMap, valueSchema) + if err != nil { + log.Panic("calculate checksum failed", zap.String("topic", topic), zap.ByteString("value", value), zap.Error(err)) + } + + // 4. 数据消费成功，提交 offset + if err := consumer.CommitMessages(ctx, message); err != nil { + log.Error("commit kafka message failed", zap.Error(err)) + break + } + } +} +``` + +从上面的代码可以看出，`getValueMapAndSchema()` 和 `CalculateAndVerifyChecksum()` 是计算 Checksum 的关键步骤，下面分别介绍这两个函数的实现。 + +## 解码数据以及获取相应的 Schema + +`getValueMapAndSchema()` 方法的主要作用是解码数据以及获取相应的 schema，二者均以 `map[string]interface{}` 类型返回。 + +```go +// data is received kafka message's key or value, url is the schema registry url. +// return the decoded value and corresponding schema as map. +func getValueMapAndSchema(data []byte, url string) (map[string]interface{}, map[string]interface{}, error) { + schemaID, binary, err := extractSchemaIDAndBinaryData(data) + if err != nil { + return nil, nil, err + } + + codec, err := GetSchema(url, schemaID) + if err != nil { + return nil, nil, err + } + + native, _, err := codec.NativeFromBinary(binary) + if err != nil { + return nil, nil, err + } + + result, ok := native.(map[string]interface{}) + if !ok { + return nil, nil, errors.New("raw avro message is not a map") + } + + schema := make(map[string]interface{}) + if err := json.Unmarshal([]byte(codec.Schema()), &schema); err != nil { + return nil, nil, errors.Trace(err) + } + + return result, schema, nil +} + +// extractSchemaIDAndBinaryData +func extractSchemaIDAndBinaryData(data []byte) (int, []byte, error) { + if len(data) < 5 { + return 0, nil, errors.ErrAvroInvalidMessage.FastGenByArgs() + } + if data[0] != magicByte { + return 0, nil, errors.ErrAvroInvalidMessage.FastGenByArgs() + } + return int(binary.BigEndian.Uint32(data[1:5])), data[5:], nil +} + +// GetSchema query the schema registry to fetch the schema by the schema id. +// return the goavro.Codec which can be used to encode and decode the data. +func GetSchema(url string, schemaID int) (*goavro.Codec, error) { + requestURI := url + "/schemas/ids/" + strconv.Itoa(schemaID) + + req, err := http.NewRequest("GET", requestURI, nil) + if err != nil { + log.Error("Cannot create the request to look up the schema", zap.Error(err)) + return nil, errors.WrapError(errors.ErrAvroSchemaAPIError, err) + } + req.Header.Add( + "Accept", + "application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, "+ + "application/json", + ) + + httpClient := &http.Client{} + resp, err := httpClient.Do(req) + if err != nil { + return nil, err + } + defer resp.Body.Close() + + body, err := io.ReadAll(resp.Body) + if err != nil { + log.Error("Cannot parse the lookup schema response", zap.Error(err)) + return nil, errors.WrapError(errors.ErrAvroSchemaAPIError, err) + } + + if resp.StatusCode == 404 { + log.Warn("Specified schema not found in Registry", zap.String("requestURI", requestURI), zap.Int("schemaID", schemaID)) + return nil, errors.ErrAvroSchemaAPIError.GenWithStackByArgs("Schema not found in Registry") + } + + if resp.StatusCode != 200 { + log.Error("Failed to query schema from the Registry, HTTP error", + zap.Int("status", resp.StatusCode), zap.String("uri", requestURI), zap.ByteString("responseBody", body)) + return nil, errors.ErrAvroSchemaAPIError.GenWithStack("Failed to query schema from the Registry, HTTP error") + } + + var jsonResp lookupResponse + err = json.Unmarshal(body, &jsonResp) + if err != nil { + log.Error("Failed to parse result from Registry", zap.Error(err)) + return nil, errors.WrapError(errors.ErrAvroSchemaAPIError, err) + } + + codec, err := goavro.NewCodec(jsonResp.Schema) + if err != nil { + return nil, errors.WrapError(errors.ErrAvroSchemaAPIError, err) + } + return codec, nil +} + +type lookupResponse struct { + Name string `json:"name"` + SchemaID int `json:"id"` + Schema string `json:"schema"` +} + +``` + +## 计算并校验 Checksum + +上一步获取的 `valueMap` 和 `valueSchema` 包含了所有用于 Checksum 计算和校验的元素。 + +在消费端计算和校验 Checksum 的过程包含以下几个步骤： + +1. 获取期望的 Checksum 值。 +2. 遍历每一列，根据列的数据值和对应的 MySQL Type，生成字节切片，不断更新 Checksum 值。 +3. 将上一步计算得到的 Checksum 和从收到的消息里提取出来的 Checksum 做比较。如果不一致，则说明 Checksum 校验失败，数据可能发生损坏。 + +示例代码如下： + +```go +func CalculateAndVerifyChecksum(valueMap, valueSchema map[string]interface{}) error { + // fields 存放有数据变更事件的每一个列的类型信息，按照每一列的 ID 排序，该顺序和 Checksum 计算顺序相同 + fields, ok := valueSchema["fields"].([]interface{}) + if !ok { + return errors.New("schema fields should be a map") + } + + // 1. 从 valueMap 里面查找期望的 checksum 值，它被编码成 string 类型 + // 如果找不到，说明 TiCDC 发送该条数据时，还没有开启 checksum 功能，直接返回即可 + o, ok := valueMap["_tidb_row_level_checksum"] + if !ok { + return nil + } + expected := o.(string) + if expected == "" { + return nil + } + + // expectedChecksum 即是从 TiCDC 传递而来的期望的 checksum 值 + expectedChecksum, err := strconv.ParseUint(expected, 10, 64) + if err != nil { + return errors.Trace(err) + } + + // 2. 遍历每一个 field，计算 checksum 值 + var actualChecksum uint32 + // buf 用来存储每次更新 checksum 时使用的字节切片 + buf := make([]byte, 0) + for _, item := range fields { + field, ok := item.(map[string]interface{}) + if !ok { + return errors.New("schema field should be a map") + } + + // `tidbOp` 及之后的列不参与到 checksum 计算中，因为它们是一些用于辅助数据消费的列，并非真实的 TiDB 列数据 + colName := field["name"].(string) + if colName == "_tidb_op" { + break + } + + // holder 存放有列类型信息 + var holder map[string]interface{} + switch ty := field["type"].(type) { + case []interface{}: + for _, item := range ty { + if m, ok := item.(map[string]interface{}); ok { + holder = m["connect.parameters"].(map[string]interface{}) + break + } + } + case map[string]interface{}: + holder = ty["connect.parameters"].(map[string]interface{}) + default: + log.Panic("type info is anything else", zap.Any("typeInfo", field["type"])) + } + tidbType := holder["tidb_type"].(string) + + mysqlType := mysqlTypeFromTiDBType(tidbType) + + // 根据每一列的名字，从解码之后的 value map 里拿到该列的值 + value, ok := valueMap[colName] + if !ok { + return errors.New("value not found") + } + value, err := getColumnValue(value, holder, mysqlType) + if err != nil { + return errors.Trace(err) + } + + if len(buf) > 0 { + buf = buf[:0] + } + + // 根据每一列的 value 和 mysqlType，生成用于更新 checksum 的字节切片，然后更新 checksum + buf, err = buildChecksumBytes(buf, value, mysqlType) + if err != nil { + return errors.Trace(err) + } + actualChecksum = crc32.Update(actualChecksum, crc32.IEEETable, buf) + } + + if uint64(actualChecksum) != expectedChecksum { + log.Error("checksum mismatch", + zap.Uint64("expected", expectedChecksum), + zap.Uint64("actual", uint64(actualChecksum))) + return errors.New("checksum mismatch") + } + + log.Info("checksum verified", zap.Uint64("checksum", uint64(actualChecksum))) + return nil +} + +func mysqlTypeFromTiDBType(tidbType string) byte { + var result byte + switch tidbType { + case "INT", "INT UNSIGNED": + result = mysql.TypeLong + case "BIGINT", "BIGINT UNSIGNED": + result = mysql.TypeLonglong + case "FLOAT": + result = mysql.TypeFloat + case "DOUBLE": + result = mysql.TypeDouble + case "BIT": + result = mysql.TypeBit + case "DECIMAL": + result = mysql.TypeNewDecimal + case "TEXT": + result = mysql.TypeVarchar + case "BLOB": + result = mysql.TypeLongBlob + case "ENUM": + result = mysql.TypeEnum + case "SET": + result = mysql.TypeSet + case "JSON": + result = mysql.TypeJSON + case "DATE": + result = mysql.TypeDate + case "DATETIME": + result = mysql.TypeDatetime + case "TIMESTAMP": + result = mysql.TypeTimestamp + case "TIME": + result = mysql.TypeDuration + case "YEAR": + result = mysql.TypeYear + default: + log.Panic("this should not happen, unknown TiDB type", zap.String("type", tidbType)) + } + return result +} + +// value 是一个 interface 类型的值，需要根据 holder 提供的类型信息，做一次转换处理 +func getColumnValue(value interface{}, holder map[string]interface{}, mysqlType byte) (interface{}, error) { + switch t := value.(type) { + // nullable 的列，其值被编码成一个 map，只有一个键值对，键是类型，值是真实的值，此处只关心真实的值 + case map[string]interface{}: + for _, v := range t { + value = v + } + } + + switch mysqlType { + case mysql.TypeEnum: + // Enum 被编码成了 string，此处转换为对应于 Enum 定义的 int 值 + allowed := strings.Split(holder["allowed"].(string), ",") + switch t := value.(type) { + case string: + enum, err := types.ParseEnum(allowed, t, "") + if err != nil { + return nil, errors.Trace(err) + } + value = enum.Value + case nil: + value = nil + } + case mysql.TypeSet: + // Set 被编码成了 string，根据 set 定义的顺序，转换为对应的 int 值 + elems := strings.Split(holder["allowed"].(string), ",") + switch t := value.(type) { + case string: + s, err := types.ParseSet(elems, t, "") + if err != nil { + return nil, errors.Trace(err) + } + value = s.Value + case nil: + value = nil + } + } + return value, nil +} + +// buildChecksumBytes 生成用于更新 checksum 的字节切片, 参考 https://github.com/pingcap/tidb/blob/e3417913f58cdd5a136259b902bf177eaf3aa637/util/rowcodec/common.go#L308 +func buildChecksumBytes(buf []byte, value interface{}, mysqlType byte) ([]byte, error) { + if value == nil { + return buf, nil + } + + switch mysqlType { + // TypeTiny, TypeShort, TypeInt32 被编码成 int32 + // TypeLong 被编码成 int32 if signed, else int64 + // TypeLongLong，如果是 signed，被编码成 int64，否则被编码成 uint64, + // 开启 checksum 功能，bigintUnsignedHandlingMode 必须设置为 string，被编码成 string. + case mysql.TypeTiny, mysql.TypeShort, mysql.TypeLong, mysql.TypeLonglong, mysql.TypeInt24, mysql.TypeYear: + switch a := value.(type) { + case int32: + buf = binary.LittleEndian.AppendUint64(buf, uint64(a)) + case uint32: + buf = binary.LittleEndian.AppendUint64(buf, uint64(a)) + case int64: + buf = binary.LittleEndian.AppendUint64(buf, uint64(a)) + case uint64: + buf = binary.LittleEndian.AppendUint64(buf, a) + case string: + v, err := strconv.ParseUint(a, 10, 64) + if err != nil { + return nil, errors.Trace(err) + } + buf = binary.LittleEndian.AppendUint64(buf, v) + default: + log.Panic("unknown golang type for the integral value", + zap.Any("value", value), zap.Any("mysqlType", mysqlType)) + } + // Float 类型编码为 float32，Double 编码为 float64 + case mysql.TypeFloat, mysql.TypeDouble: + var v float64 + switch a := value.(type) { + case float32: + v = float64(a) + case float64: + v = a + } + if math.IsInf(v, 0) || math.IsNaN(v) { + v = 0 + } + buf = binary.LittleEndian.AppendUint64(buf, math.Float64bits(v)) + // getColumnValue 将 Enum 和 Set 转换为了 uint64 类型 + case mysql.TypeEnum, mysql.TypeSet: + buf = binary.LittleEndian.AppendUint64(buf, value.(uint64)) + case mysql.TypeBit: + // bit 类型编码为 []bytes，需要进一步转换为 uint64 + v, err := binaryLiteralToInt(value.([]byte)) + if err != nil { + return nil, errors.Trace(err) + } + buf = binary.LittleEndian.AppendUint64(buf, v) + // 非二进制类型时，编码成 string， 反之则为 []byte + case mysql.TypeVarchar, mysql.TypeVarString, mysql.TypeString, mysql.TypeTinyBlob, mysql.TypeMediumBlob, mysql.TypeLongBlob, mysql.TypeBlob: + switch a := value.(type) { + case string: + buf = appendLengthValue(buf, []byte(a)) + case []byte: + buf = appendLengthValue(buf, a) + default: + log.Panic("unknown golang type for the string value", + zap.Any("value", value), zap.Any("mysqlType", mysqlType)) + } + case mysql.TypeTimestamp, mysql.TypeDatetime, mysql.TypeDate, mysql.TypeDuration, mysql.TypeNewDate: + v := value.(string) + buf = appendLengthValue(buf, []byte(v)) + // 开启 checksum 功能时，decimalHandlingMode 必须设置为 string + case mysql.TypeNewDecimal: + buf = appendLengthValue(buf, []byte(value.(string))) + case mysql.TypeJSON: + buf = appendLengthValue(buf, []byte(value.(string))) + // Null 和 Geometry 不参与到 checksum 计算 + case mysql.TypeNull, mysql.TypeGeometry: + // do nothing + default: + return buf, errors.New("invalid type for the checksum calculation") + } + return buf, nil +} + +func appendLengthValue(buf []byte, val []byte) []byte { + buf = binary.LittleEndian.AppendUint32(buf, uint32(len(val))) + buf = append(buf, val...) + return buf +} + +// 将 []byte 转换为 uint64，参考 https://github.com/pingcap/tidb/blob/e3417913f58cdd5a136259b902bf177eaf3aa637/types/binary_literal.go#L105 +func binaryLiteralToInt(bytes []byte) (uint64, error) { + bytes = trimLeadingZeroBytes(bytes) + length := len(bytes) + + if length > 8 { + log.Error("invalid bit value found", zap.ByteString("value", bytes)) + return math.MaxUint64, errors.New("invalid bit value") + } + + if length == 0 { + return 0, nil + } + + val := uint64(bytes[0]) + for i := 1; i < length; i++ { + val = (val << 8) | uint64(bytes[i]) + } + return val, nil +} + +func trimLeadingZeroBytes(bytes []byte) []byte { + if len(bytes) == 0 { + return bytes + } + pos, posMax := 0, len(bytes)-1 + for ; pos < posMax; pos++ { + if bytes[pos] != 0 { + break + } + } + return bytes[pos:] +} +``` \ No newline at end of file diff --git a/ticdc/ticdc-avro-protocol.md b/ticdc/ticdc-avro-protocol.md index 6c2be610a664..7a51be2af7b9 100644 --- a/ticdc/ticdc-avro-protocol.md +++ b/ticdc/ticdc-avro-protocol.md @@ -7,6 +7,12 @@ summary: 了解 TiCDC Avro Protocol 的概念和使用方法。 Avro 是由 [Apache Avro™](https://avro.apache.org/) 定义的一种数据交换格式协议，[Confluent Platform](https://docs.confluent.io/platform/current/platform.html) 选择它作为默认的数据交换格式。通过本文，你可以了解 TiCDC 对 Avro 数据格式的实现，包括 TiDB 扩展字段、Avro 数据格式定义，以及和 [Confluent Schema Registry](https://docs.confluent.io/platform/current/schema-registry/index.html) 的交互。 +> **警告：** +> +> 当开启 [Old Value 功能](/ticdc/ticdc-manage-changefeed.md#输出行变更的历史值-从-v405-版本开始引入)时 (`enable-old-value = true`)，Avro 协议数据格式无法输出更新事件的旧值。 +> +> 具体原因请参考 [TiCDC 在开启 Old Value 功能后更新事件格式有何变化？](/ticdc/ticdc-faq.md#ticdc-在开启-old-value-功能后更新事件格式有何变化) + ## 使用 Avro 当使用 Message Queue (MQ) 作为下游 Sink 时，你可以在 `sink-uri` 中指定使用 Avro。TiCDC 获取 TiDB 的 DML 事件，并将这些事件封装到 Avro Message，然后发送到下游。当 Avro 检测到 schema 变化时，会向 Schema Registry 注册最新的 schema。 diff --git a/ticdc/ticdc-bidirectional-replication.md b/ticdc/ticdc-bidirectional-replication.md index d0be06e69e18..5f0f3d837dd4 100644 --- a/ticdc/ticdc-bidirectional-replication.md +++ b/ticdc/ticdc-bidirectional-replication.md @@ -38,16 +38,36 @@ TiCDC 复制功能只会将指定时间点之后的增量变更复制到下游 ## 执行 DDL -双向复制的集群不支持同步 DDL。 - -如果需要执行 DDL，采取以下步骤： - -1. 暂停所有集群中需要执行 DDL 的对应的表的写入操作。如果是添加非唯一索引，不用暂停写入。 +开启双向复制功能后，TiCDC 不会同步任何 DDL。用户需要自行在上下游集群中分别执行 DDL。 + +需要注意的是，某些 DDL 会造成表结构变更或者数据更改时序问题，从而导致数据同步后出现不一致的情况。因此，在开启双向同步功能后，只有下表中的 DDL 可以在业务不停止数据写入的情况下执行。 + +| 事件 | 是否会引起 changefeed 错误 | 说明 | +| ---------------------------- | ------ |--------------------------| +| create database | 是 | 用户手动在上下游都执行了 DDL 之后，错误可以自动恢复| +| drop database | 是 | 需要手动重启 changefeed，指定 `--overwrite-checkpoint-ts` 为该条 DDL 的commitTs 来恢复 | +| create table | 是 | 用户手动在上下游都执行了 DDL 之后，错误可以自动恢复 | +| drop table | 是 | 需要手动重启 changefeed，指定 `--overwrite-checkpoint-ts` 为该条 ddl 的commitTs 来恢复 | +| alter table comment | 否 | | +| rename index | 否 | | +| alter table index visibility | 否 | | +| add partition | 是 | 用户手动在上下游都执行了 DDL 之后，错误可以自动恢复 | +| drop partition | 否 | | +| create view | 否 | | +| drop view | 否 | | +| alter column default value | 否 | | +| reorganize partition | 是 | 用户手动在上下游都执行了 DDL 之后，错误可以自动恢复 | +| alter table ttl | 否 | | +| alter table remove ttl | 否 | | +| add **not unique** index | 否 | | +| drop **not unique** index | 否 | | + +如果需要执行以上列表中不存在的 DDL，需要采取以下步骤： + +1. 暂停所有集群中需要执行 DDL 的对应的表的写入操作。 2. 等待所有集群中对应表的所有写入已经同步到其他集群后，手动在每一个 TiDB 集群上单独执行所有的 DDL。 3. 等待 DDL 完成之后，重新恢复写入。 -注意，添加非唯一索引 DDL 不会引起双向复制链路中断，因此不用停止对应表的写入。 - ## 停止双向复制 在业务数据停止写入之后，你可以在两个集群中都插入一行特殊的值，通过检查这两行特殊的值来确保数据达到了一致的状态。 diff --git a/ticdc/ticdc-changefeed-config.md b/ticdc/ticdc-changefeed-config.md index f53d63738448..09ec1b27560c 100644 --- a/ticdc/ticdc-changefeed-config.md +++ b/ticdc/ticdc-changefeed-config.md @@ -37,6 +37,10 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl 本章节详细介绍了同步任务的配置。 ```toml +# 指定该 Changefeed 在 Capture Server 中内存配额的上限。对于超额使用部分， +# 会在运行中被 Go runtime 优先回收。默认值为 `1073741824`，即 1 GB。 +# memory-quota = 1073741824 + # 指定配置文件中涉及的库名、表名是否为大小写敏感 # 该配置会同时影响 filter 和 sink 相关配置，默认为 true case-sensitive = true @@ -45,17 +49,20 @@ case-sensitive = true enable-old-value = true # 是否开启 Syncpoint 功能，从 v6.3.0 开始支持，该功能默认关闭。 -# 从 v6.4.0 开始，使用 Syncpoint 功能需要同步任务拥有下游集群的 SYSTEM_VARIABLES_ADMIN 或者 SUPER 权限 +# 从 v6.4.0 开始，使用 Syncpoint 功能需要同步任务拥有下游集群的 SYSTEM_VARIABLES_ADMIN 或者 SUPER 权限。 +# 注意：该参数只有当下游为 Kafka 或存储服务时，才会生效。 # enable-sync-point = false # Syncpoint 功能对齐上下游 snapshot 的时间间隔 # 配置格式为 h m s，例如 "1h30m30s" # 默认值为 10m，最小值为 30s +# 注意：该参数只有当下游为 Kafka 或存储服务时，才会生效。 # sync-point-interval = "5m" # Syncpoint 功能在下游表中保存的数据的时长，超过这个时间的数据会被清理 # 配置格式为 h m s，例如 "24h30m30s" # 默认值为 24h +# 注意：该参数只有当下游为 Kafka 或存储服务时，才会生效。 # sync-point-retention = "1h" [mounter] @@ -70,65 +77,148 @@ enable-old-value = true # 过滤规则语法：https://docs.pingcap.com/zh/tidb/stable/table-filter#表库过滤语法 rules = ['*.*', '!test.*'] +# 忽略特定 start_ts 的事务 +# 默认值为空列表。 +# IgnoreTxnStartTs = [] + # 事件过滤器规则 -# 事件过滤器的详细配置规则在下方的 Event Filter 配置规则中描述 +# 事件过滤器的详细配置规则可参考：https://docs.pingcap.com/zh/tidb/stable/ticdc-filter # 第一个事件过滤器规则 -[[filter.event-filters]] -matcher = ["test.worker"] # matcher 是一个白名单，表示该过滤规则只应用于 test 库中的 worker 表 -ignore-event = ["insert"] # 过滤掉 insert 事件 -ignore-sql = ["^drop", "add column"] # 过滤掉以 "drop" 开头或者包含 "add column" 的 DDL -ignore-delete-value-expr = "name = 'john'" # 过滤掉包含 name = 'john' 条件的 delete DML -ignore-insert-value-expr = "id >= 100" # 过滤掉包含 id >= 100 条件的 insert DML -ignore-update-old-value-expr = "age < 18" # 过滤掉旧值 age < 18 的 update DML -ignore-update-new-value-expr = "gender = 'male'" # 过滤掉新值 gender = 'male' 的 update DML +# [[filter.event-filters]] +# matcher = ["test.worker"] # matcher 是一个白名单，表示该过滤规则只应用于 test 库中的 worker 表 +# ignore-event = ["insert"] # 过滤掉 insert 事件 +# ignore-sql = ["^drop", "add column"] # 过滤掉以 "drop" 开头或者包含 "add column" 的 DDL +# ignore-delete-value-expr = "name = 'john'" # 过滤掉包含 name = 'john' 条件的 delete DML +# ignore-insert-value-expr = "id >= 100" # 过滤掉包含 id >= 100 条件的 insert DML +# ignore-update-old-value-expr = "age < 18" # 过滤掉旧值 age < 18 的 update DML +# ignore-update-new-value-expr = "gender = 'male'" # 过滤掉新值 gender = 'male' 的 update DML # 第二个事件过滤器规则 -[[filter.event-filters]] -matcher = ["test.fruit"] # 该事件过滤器只应用于 test.fruit 表 -ignore-event = ["drop table"] # 忽略 drop table 事件 -ignore-sql = ["delete"] # 忽略 delete DML -ignore-insert-value-expr = "price > 1000 and origin = 'no where'" # 忽略包含 price > 1000 和 origin = 'no where' 条件的 insert DML +# [[filter.event-filters]] +# matcher = ["test.fruit"] # 该事件过滤器只应用于 test.fruit 表 +# ignore-event = ["drop table", "delete"] # 忽略 drop table 的 DDL 事件和 delete 类型的 DML 事件 +# ignore-sql = ["^drop table", "alter table"] # 忽略以 drop table 开头的，或者包含 alter table 的 DDL 语句 +# ignore-insert-value-expr = "price > 1000 and origin = 'no where'" # 忽略包含 price > 1000 和 origin = 'no where' 条件的 insert DML [scheduler] # 将表按 Region 个数划分成多个同步范围，这些范围可由多个 TiCDC 节点同步。 # 注意：该功能只在 Kafka changefeed 上生效，暂不支持 MySQL changefeed。 # 默认为 "false"。设置为 "true" 以打开该功能。 enable-table-across-nodes = false -# 打开该功能后，该功能只对 Region 个数大于 `region-threshold` 值的表生效。 + +# 打开该功能后，该功能会对 Region 个数大于 `region-threshold` 值的表生效。 region-threshold = 100000 +# 打开该功能后，该功能会对每分钟修改行数大于 `write-key-threshold` 值的表生效。 +# 注意： +# * `write-key-threshold` 参数默认值为 0，代表该功能默认不会按表的修改行数来切分表的同步范围。 +# * 你可以根据集群负载来配置该参数，如 30000，代表当表每分钟的更新行数超过 30000 时，该功能将会切分表的同步范围。 +# * 当 `region-threshold` 和 `write-key-threshold` 同时配置时， +# TiCDC 将优先检查修改行数是否大于 `write-key-threshold`， +# 如果不超过，则再检查 Region 个数是否大于 `region-threshold`。 +write-key-threshold = 0 + [sink] # 对于 MQ 类的 Sink，可以通过 dispatchers 配置 event 分发器 # 支持 partition 及 topic（从 v6.1 开始支持）两种 event 分发器。二者的详细说明见下一节。 # matcher 的匹配语法和过滤器规则语法相同，matcher 匹配规则的详细说明见下一节。 -dispatchers = [ - {matcher = ['test1.*', 'test2.*'], topic = "Topic 表达式 1", partition = "ts" }, - {matcher = ['test3.*', 'test4.*'], topic = "Topic 表达式 2", partition = "index-value" }, - {matcher = ['test1.*', 'test5.*'], topic = "Topic 表达式 3", partition = "table"}, - {matcher = ['test6.*'], partition = "ts"} -] - -# protocol 用于指定传递到下游的协议格式 -# 当下游类型是 Kafka 时，支持 canal-json、avro 两种协议。 +# 注意：该参数只有当下游为消息队列时，才会生效。 +# dispatchers = [ +# {matcher = ['test1.*', 'test2.*'], topic = "Topic 表达式 1", partition = "ts" }, +# {matcher = ['test3.*', 'test4.*'], topic = "Topic 表达式 2", partition = "index-value" }, +# {matcher = ['test1.*', 'test5.*'], topic = "Topic 表达式 3", partition = "table"}, +# {matcher = ['test6.*'], partition = "ts"} +# ] + +# protocol 用于指定编码消息时使用的格式协议 +# 当下游类型是 Kafka 时，支持 canal-json、avro 和 open-protocol。 # 当下游类型是存储服务时，目前仅支持 canal-json、csv 两种协议。 -protocol = "canal-json" +# 注意：该参数只有当下游为 Kafka 或存储服务时，才会生效。 +# protocol = "canal-json" + +# delete-only-output-handle-key-columns 用于指定 Delete 事件的输出内容，只对 canal-json 和 open-protocol 协议有效。从 v7.2.0 开始引入。 +# 默认值为 false，即输出所有列的内容。当设置为 true 时，只输出主键列，或唯一索引列的内容。 +# Avro 协议不受该参数控制，总是只输出主键列，或唯一索引列的内容。 +# CSV 协议不受该参数控制，总是输出所有列的内容。 +delete-only-output-handle-key-columns = false # 以下三个配置项仅在同步到存储服务的 sink 中使用，在 MQ 和 MySQL 类 sink 中无需设置。 # 换行符，用来分隔两个数据变更事件。默认值为空，表示使用 "\r\n" 作为换行符。 -terminator = '' -# 文件路径的日期分隔类型。可选类型有 `none`、`year`、`month` 和 `day`。默认值为 `none`，即不使用日期分隔。详见 。 -date-separator = 'none' -# 是否使用 partition 作为分隔字符串。默认值为 false，即一张表中各个 partition 的数据不会分不同的目录来存储。详见 。 -enable-partition-separator = false +# terminator = '' + +# 文件路径的日期分隔类型。可选类型有 `none`、`year`、`month` 和 `day`。默认值为 `day`，即按天分隔。详见 。 +# 注意：该参数只有当下游为存储服务时，才会生效。 +date-separator = 'day' + +# 是否使用 partition 作为分隔字符串。默认值为 true，即一张表中各个 partition 的数据会分不同的目录来存储。建议保持该配置项为 true 以避免下游分区表可能丢数据的问题 。使用示例详见 。 +# 注意：该参数只有当下游为存储服务时，才会生效。 +enable-partition-separator = true + +# Schema 注册表的 URL。 +# 注意：该参数只有当下游为消息队列时，才会生效。 +# schema-registry = "http://localhost:80801/subjects/{subject-name}/versions/{version-number}/schema" + +# 编码数据时所用编码器的线程数。 +# 默认值为 16。 +# 注意：该参数只有当下游为消息队列时，才会生效。 +# encoder-concurrency = 16 + +# 是否开启 Kafka Sink V2。Kafka Sink V2 内部使用 kafka-go 实现。 +# 默认值为 false。 +# 注意：该参数只有当下游为消息队列时，才会生效。 +# enable-kafka-sink-v2 = false + +# 是否只向下游同步有内容更新的列。从 v7.1.0 开始支持。 +# 默认值为 false。 +# 注意：该参数只有当下游为消息队列，并且使用 Open Protocol 或 Canal-JSON 时，才会生效。 +# only-output-updated-columns = false # 从 v6.5.0 开始，TiCDC 支持以 CSV 格式将数据变更记录保存至存储服务中，在 MQ 和 MySQL 类 sink 中无需设置。 -[sink.csv] +# [sink.csv] # 字段之间的分隔符。必须为 ASCII 字符，默认值为 `,`。 -delimiter = ',' +# delimiter = ',' # 用于包裹字段的引号字符。空值代表不使用引号字符。默认值为 `"`。 -quote = '"' +# quote = '"' # CSV 中列为 NULL 时将以什么字符来表示。默认值为 `\N`。 -null = '\N' +# null = '\N' # 是否在 CSV 行中包含 commit-ts。默认值为 false。 -include-commit-ts = false +# include-commit-ts = false + +# consistent 中的字段用于配置 Changefeed 的数据一致性。详细的信息，请参考 。 +# 注意：一致性相关参数只有当下游为数据库并且开启 redo log 功能时，才会生效。 +[consistent] +# 数据一致性级别。默认值为 "none"，可选值为 "none" 和 "eventual"。 +# 设置为 "none" 时将关闭 redo log。 +level = "none" +# redo log 的最大日志大小，单位为 MB。默认值为 64。 +max-log-size = 64 +# 两次 redo log 刷新的时间间隔，单位为毫秒。默认值为 2000。 +flush-interval = 2000 +# redo log 使用存储服务的 URI。默认值为空。 +storage = "" +# 是否将 redo log 存储到文件中。默认值为 false。 +use-file-backend = false + +[integrity] +# 是否开启单行数据的 Checksum 校验功能，默认值为 "none"，即不开启。可选值为 "none" 和 "correctness"。 +integrity-check-level = "none" +# 当单行数据的 Checksum 校验失败时，Changefeed 打印错误行数据相关日志的级别。默认值为 "warn"，可选值为 "warn" 和 "error"。 +corruption-handle-level = "warn" + +# 以下参数仅在下游为 Kafka 时生效。 +[sink.kafka-config] +# Kafka SASL 认证机制。该参数默认值为空，表示不使用 SASL 认证。 +sasl-mechanism = "OAUTHBEARER" +# Kafka SASL OAUTHBEARER 认证机制中的 client-id。默认值为空。在使用该认证机制时，该参数必填。 +sasl-oauth-client-id = "producer-kafka" +# Kafka SASL OAUTHBEARER 认证机制中的 client-secret。默认值为空。需要 Base64 编码。在使用该认证机制时，该参数必填。 +sasl-oauth-client-secret = "cHJvZHVjZXIta2Fma2E=" +# Kafka SASL OAUTHBEARER 认证机制中的 token-url 用于获取 token。默认值为空。在使用该认证机制时，该参数必填。 +sasl-oauth-token-url = "http://127.0.0.1:4444/oauth2/token" +# Kafka SASL OAUTHBEARER 认证机制中的 scopes。默认值为空。在使用该认证机制时，该参数可选填。 +sasl-oauth-scopes = ["producer.kafka", "consumer.kafka"] +# Kafka SASL OAUTHBEARER 认证机制中的 grant-type。默认值为 "client_credentials"。在使用该认证机制时，该参数可选填。 +sasl-oauth-grant-type = "client_credentials" +# Kafka SASL OAUTHBEARER 认证机制中的 audience。默认值为空。在使用该认证机制时，该参数可选填。 +sasl-oauth-audience = "kafka" ``` diff --git a/ticdc/ticdc-changefeed-overview.md b/ticdc/ticdc-changefeed-overview.md index 525b5ba6def9..7dc2f7071b07 100644 --- a/ticdc/ticdc-changefeed-overview.md +++ b/ticdc/ticdc-changefeed-overview.md @@ -19,7 +19,7 @@ Changefeed 是 TiCDC 中的单个同步任务。Changefeed 将一个 TiDB 集群 - Stopped：同步任务停止，由于用户手动暂停 (pause) changefeed。处于这个状态的 changefeed 会阻挡 GC 推进。 - Error：同步任务报错，由于某些可恢复的错误导致同步无法继续进行，处于这个状态的 changefeed 会不断尝试继续推进，直到状态转为 Normal。处于这个状态的 changefeed 会阻挡 GC 推进。 - Finished：同步任务完成，同步任务进度已经达到预设的 TargetTs。处于这个状态的 changefeed 不会阻挡 GC 推进。 -- Failed：同步任务失败。由于发生了某些不可恢复的错误，导致同步无法继续进行，并且无法恢复。处于这个状态的 changefeed 不会阻挡 GC 推进。 +- Failed：同步任务失败。由于发生了某些不可恢复的错误，导致同步无法继续进行，并且无法恢复。TiCDC 将为发生故障的 changefeed 保留数据 24 小时，以防止其在 GC 过程中被清除。 以上状态流转图中的编号说明如下： diff --git a/ticdc/ticdc-csv.md b/ticdc/ticdc-csv.md index e01a7247269c..9e99807b5500 100644 --- a/ticdc/ticdc-csv.md +++ b/ticdc/ticdc-csv.md @@ -7,6 +7,12 @@ summary: 了解 TiCDC CSV Protocol 的概念和使用方法。 当使用云存储服务作为下游 sink 时，你可以使用 CSV 格式将 DML 事件发送到下游云存储服务。 +> **警告：** +> +> 当开启 [Old Value 功能](/ticdc/ticdc-manage-changefeed.md#输出行变更的历史值-从-v405-版本开始引入)时 (`enable-old-value = true`)，CSV 协议数据格式无法输出更新事件的旧值。 +> +> 具体原因请参考 [TiCDC 在开启 Old Value 功能后更新事件格式有何变化？](/ticdc/ticdc-faq.md#ticdc-在开启-old-value-功能后更新事件格式有何变化) + ## 使用 CSV 使用 CSV 时的配置样例如下所示： diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 65db3e355254..f0534a681cac 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -202,6 +202,19 @@ TiCDC 对大事务（大小超过 5 GB）提供部分支持，根据场景不同 4. 建立一个新的 changefeed，从 `BackupTS` 开始同步任务。 5. 删除旧的 changefeed。 +## TiCDC 是否会将有损 DDL 产生的数据变更同步到下游？ + +有损 DDL 是指在 TiDB 中执行可能会导致数据改变的 DDL。一些常见的有损 DDL 操作包括： + +- 修改列的类型，例如：INT -> VARCHAR +- 修改列的长度，例如：VARCHAR(20) -> VARCHAR(10) +- 修改列的精度，例如：DECIMAL(10, 3) -> DECIMAL(10, 2) +- 修改列的符号（有符号数/无符号数），例如：INT UNSIGNED -> INT SIGNED + +在 TiDB v7.1.0 之前，TiCDC 会将一条新旧数据相同的 DML 事件同步到下游。当下游是 MySQL 时，这些 DML 事件不会产生任何数据变更，只有下游接收并执行该 DDL 语句后，数据才会发生变更。但是当下游是 Kafka 或者云存储时，TiCDC 会写入一条无用的数据到下游。 + +从 TiDB v7.1.0 开始，TiCDC 会过滤掉这些无用的 DML 事件，不再将它们同步到下游。 + ## 同步 DDL 到下游 MySQL 5.7 时为什么时间类型字段默认值不一致？ 比如上游 TiDB 的建表语句为 `create table test (id int primary key, ts timestamp)`，TiCDC 同步该语句到下游 MySQL 5.7，MySQL 使用默认配置，同步得到的表结构如下所示，timestamp 字段默认值会变成 `CURRENT_TIMESTAMP`： @@ -222,7 +235,7 @@ mysql root@127.0.0.1:test> show create table test; 产生表结构不一致的原因是 `explicit_defaults_for_timestamp` 的[默认值在 TiDB 和 MySQL 5.7 不同](/mysql-compatibility.md#默认设置)。从 TiCDC v5.0.1/v4.0.13 版本开始，同步到 MySQL 会自动设置 session 变量 `explicit_defaults_for_timestamp = ON`，保证同步时间类型时上下游行为一致。对于 v5.0.1/v4.0.13 以前的版本，同步时间类型时需要注意 `explicit_defaults_for_timestamp` 默认值不同带来的兼容性问题。 -## 使用 TiCDC 创建同步任务时将 `enable-old-value` 设置为 `true` 后，为什么上游的 `INSERT`/`UPDATE` 语句经 TiCDC 同步到下游后变为了 `REPLACE INTO`？ +## 使用 TiCDC 创建同步任务时将 `safe-mode` 设置为 `true` 后，为什么上游的 `INSERT`/`UPDATE` 语句经 TiCDC 同步到下游后变为了 `REPLACE INTO`？ TiCDC 提供至少一次的数据同步保证，当下游有重复数据时，会引起写冲突。为了避免该问题，TiCDC 会将 `INSERT` 和 `UPDATE` 语句转成 `REPLACE INTO` 语句。该行为由 `safe-mode` 参数来控制。 @@ -258,7 +271,7 @@ TiCDC 需要磁盘是为了缓冲上游写入高峰时下游消费不及时堆 ## 在两个异地 TiDB 集群之间同步数据，如何部署 TiCDC？ -建议将 TiCDC 部署在下游 TiDB 集群。这是因为，如果上下游网络延迟较大，例如超过 100 ms 时，由于 MySQL 传输协议的原因，TiCDC 向下游执行 SQL 的延迟会急剧增加，导致系统的吞吐下降。部署在下游能够极大缓解该问题。 +对于 v6.5.2 之前的版本，建议将 TiCDC 部署在下游 TiDB 集群。这是因为，如果上下游网络延迟较大，例如超过 100 ms 时，由于 MySQL 传输协议的原因，TiCDC 向下游执行 SQL 的延迟会急剧增加，导致系统的吞吐下降。部署在下游能够极大缓解该问题。经过优化后，v6.5.2 及之后的版本建议将 TiCDC 部署在上游集群。 ## 如何理解 DML 和 DDL 语句之间的执行顺序？ @@ -275,3 +288,99 @@ TiCDC 需要磁盘是为了缓冲上游写入高峰时下游消费不及时堆 ## 上游有运行时间比较长的未提交事务，TiCDC 同步是否会被卡住？ TiDB 有事务超时的机制，当事务运行超过 [`max-txn-ttl`](/tidb-configuration-file.md#max-txn-ttl) 后，会被 TiDB 强制回滚。TiCDC 遇到未提交的事务，会等待其提交后再继续同步其数据，因此会出现同步延迟。 + +## TiCDC 在开启 Old Value 功能后更新事件格式有何变化？ + +在下面的说明中，有效索引的定义如下： + +- 主键 (`PRIMARY KEY`) 为有效索引。 +- 唯一索引 (`UNIQUE INDEX`) 中每一列在表结构中明确定义非空 (`NOT NULL`) 且不存在虚拟生成列 (`VIRTUAL GENERATED COLUMNS`)。 + +聚簇索引指的是 TiDB 从 v5.0 开始支持的特性，用于控制含有主键的表数据的存储方式。详见[聚簇索引](/clustered-indexes.md)。 + +在开启 [Old Value 功能](/ticdc/ticdc-manage-changefeed.md#输出行变更的历史值-从-v405-版本开始引入)后，TiCDC 的表现如下： + +- 对于非有效索引列的更新事件，输出的数据中会同时包含新值和旧值。 +- 对于有效索引列的更新事件，输出的数据视不同情况而定： + - 更新唯一索引列 (`UNIQUE INDEX`)，并且该表不存在主键时，输出的数据中会同时包含新值和旧值。 + - 当上游 TiDB 集群未开启聚簇索引，更新非 INT 类型的主键列时，输出的数据中会同时包含新值和旧值。 + - 在其他情况下，更新事件会被拆分为对旧数据的删除事件和对新数据的插入事件。 + +以上行为的变化可能导致以下问题： + +### 当更新有效索引列的事件同时包含新值和旧值时，Kafka Sink 的分发行为可能无法保证将具有相同索引列的更新事件分发到同一分区 + +Kafka Sink 的 index-value 分发行为是根据索引列的值来分发的。当更新事件同时包含新值和旧值时，索引列的值会发生变化，从而导致相同索引列的更新事件被分发到不同的分区。下面是一个示例： + +在关闭 TiDB 聚簇索引功能时，创建表 `t`： + +```sql +CREATE TABLE t (a VARCHAR(255) PRIMARY KEY NONCLUSTERED); +``` + +执行如下 DML 语句： + +```sql +INSERT INTO t VALUES ("2"); +UPDATE t SET a="1" WHERE a="2"; +INSERT INTO t VALUES ("2"); +UPDATE t SET a="3" WHERE a="2"; +``` + +- 在未开启 Old Value 功能时，更新事件被拆分为删除旧值事件和插入新值事件。Kafka Sink 的 index-value 分发模式针对每个事件计算相应的分区。上述 DML 产生的事件会被发送到如下分区： + + | partition-1 | partition-2 | partition-3 | + | ------------ | ------------ | ------------ | + | INSERT a = 2 | INSERT a = 1 | INSERT a = 3 | + | DELETE a = 2 | | | + | INSERT a = 2 | | | + | DELETE a = 2 | | | + + 因为 Kafka 的每个分区内可以保证消息的顺序，Kafka 消费者可以独立地消费每个分区中的数据，最终结果和 DML 执行顺序相同。 + +- 在开启 Old Value 功能时，Kafka Sink 的 index-value 分发模式会将相同索引列的更新事件分发到不同的分区。因此上述 DML 会被分发到如下分区（更新事件同时包含新值和旧值）： + + | partition-1 | partition-2 | partition-3 | + | ------------ | ------------------------ | ------------------------ | + | INSERT a = 2 | UPDATE a = 1 WHERE a = 2 | UPDATE a = 3 WHERE a = 2 | + | INSERT a = 2 | | | + + 因为 Kafka 的各个分区之间不能保证消息的顺序，因此上述 DML 在消费过程中可能无法保证索引列的更新顺序。如果需要在输出的数据中会同时包含新值和旧值时保证索引列的更新顺序，建议在开启 Old Value 功能时，使用 default 分发模式。 + +### 对于非有效索引列的更新事件和有效索引列的更新事件同时包含新值和旧值时，Kafka Sink 的 Avro 格式无法正确输出旧值 + +在 Avro 实现中，Kafka 消息的 Value 格式只包含当前列值，因此当一个事件既有新值也有旧值时，无法正确输出旧值。如果需要输出旧值，建议关闭 Old Value 功能以获取拆分后的删除和插入事件。 + +### 对于非有效索引列的更新事件和有效索引列的更新事件同时包含新值和旧值时，Cloud Storage Sink 的 CSV 格式无法正确输出旧值 + +因为 CSV 文件的列数是固定的，当一个事件既有新值也有旧值时，无法正确输出旧值。如果需要输出旧值，建议使用 Canal-JSON 格式。 + +## 为什么通过 TiDB Operator 部署的 TiCDC 集群无法使用 cdc cli 命令进行操作？ + +因为通过 TiDB Operator 部署的 TiCDC 集群的默认端口号为 8301, 而 cdc cli 命令默认连接的 cdc 服务器的端口号是 8300。在使用 cdc cli 操作 TiCDC 集群时，你需要显式地指定 `--server` 参数，如下： + +```shell +./cdc cli changefeed list --server "127.0.0.1:8301" +[ + { + "id": "4k-table", + "namespace": "default", + "summary": { + "state": "stopped", + "tso": 441832628003799353, + "checkpoint": "2023-05-30 22:41:57.910", + "error": null + } + }, + { + "id": "big-table", + "namespace": "default", + "summary": { + "state": "normal", + "tso": 441872834546892882, + "checkpoint": "2023-06-01 17:18:13.700", + "error": null + } + } +] +``` \ No newline at end of file diff --git a/ticdc/ticdc-filter.md b/ticdc/ticdc-filter.md index 46e0554928ff..a9be2330cb88 100644 --- a/ticdc/ticdc-filter.md +++ b/ticdc/ticdc-filter.md @@ -88,3 +88,40 @@ ignore-update-new-value-expr = "gender = 'male' and age > 18" # 过滤掉新值 > - TiDB 在更新聚簇索引的列值时，会将一个 UPDATE 事件拆分成为 DELETE 和 INSERT 事件，TiCDC 无法将该类事件识别为 UPDATE 事件，因此无法正确地进行过滤。 > > - 在配置 SQL 表达式时，请确保符合 matcher 规则的所有表均包含了对应 SQL 表达式中指明的所有列，否则同步任务将无法创建成功。此外，若在同步的过程中表的结构发生变化，不再包含 SQL 表达式中的列，那么同步任务将会进入无法自动恢复的错误状态，你需要手动修改配置并进行恢复操作。 + +## DDL 白名单 + +目前 TiCDC 在同步 DDL 时使用白名单策略，只有在白名单内部的 DDL 会同步到下游，不在白名单内的 DDL 不会被 TiCDC 同步到下游。 + +以下为 TiCDC 支持同步的 DDL 的列表。 + +- create database +- drop database +- create table +- drop table +- add column +- drop column +- create index / add index +- drop index +- truncate table +- modify column +- rename table +- alter column default value +- alter table comment +- rename index +- add partition +- drop partition +- truncate partition +- create view +- drop view +- alter table character set +- alter database character set +- recover table +- add primary key +- drop primary key +- rebase auto id +- alter table index visibility +- exchange partition +- reorganize partition +- alter table ttl +- alter table remove ttl diff --git a/ticdc/ticdc-integrity-check.md b/ticdc/ticdc-integrity-check.md new file mode 100644 index 000000000000..a91ede7e88bb --- /dev/null +++ b/ticdc/ticdc-integrity-check.md @@ -0,0 +1,104 @@ +--- +title: TiCDC 单行数据正确性校验 +summary: 介绍 TiCDC 数据正确性校验功能的实现原理和使用方法。 +--- + +# TiCDC 单行数据正确性校验 + +从 v7.1.0 开始，TiCDC 引入了单行数据正确性校验功能。该功能基于 Checksum 算法，校验一行数据从 TiDB 写入、通过 TiCDC 同步，到写入 Kafka 集群的过程中数据内容是否发生错误。TiCDC 数据正确性校验功能仅支持下游是 Kafka 的 Changefeed，目前支持 Avro 协议。 + +## 实现原理 + +在启用单行数据 Checksum 正确性校验功能后，TiDB 使用 CRC32 算法计算该行数据的 Checksum 值，并将其一并写入 TiKV。TiCDC 从 TiKV 读取数据，根据相同的算法重新计算 Checksum，如果该值与 TiDB 写入的值相同，则可以证明数据在 TiDB 至 TiCDC 的传输过程中是正确的。 + +TiCDC 将数据编码成特定格式并发送至 Kafka。Kafka Consumer 读取数据后，可以使用与 TiDB 相同的算法计算得到新的 Checksum，将此值与数据中携带的 Checksum 值进行比较，若二者一致，则可证明从 TiCDC 至 Kafka Consumer 的传输链路上的数据是正确的。 + +关于 Checksum 值的计算规则，请参考 [Checksum 计算规则](#checksum-计算规则)。 + +## 启用功能 + +TiCDC 数据正确性校验功能默认关闭，要使用该功能，请执行以下步骤： + +1. 首先，你需要在上游 TiDB 中开启行数据 Checksum 功能 ([`tidb_enable_row_level_checksum`](/system-variables.md#tidb_enable_row_level_checksum-从-v710-版本开始引入))： + + ```sql + SET GLOBAL tidb_enable_row_level_checksum = ON; + ``` + + 上述配置仅对新创建的会话生效，因此需要重新连接 TiDB。 + +2. 在创建 Changefeed 的 `--config` 参数所指定的[配置文件中](/ticdc/ticdc-changefeed-config.md#ticdc-changefeed-配置文件说明)，添加如下配置： + + ```toml + [integrity] + integrity-check-level = "correctness" + corruption-handle-level = "warn" + ``` + +3. 当使用 Avro 作为数据编码格式时，你需要在 [`sink-uri`](/ticdc/ticdc-sink-to-kafka.md#sink-uri-配置-kafka) 中设置 [`enable-tidb-extension=true`](/ticdc/ticdc-sink-to-kafka.md#sink-uri-配置-kafka)。同时，为了防止数值类型在网络传输过程中发生精度丢失，导致 Checksum 校验失败，还需要设置 [`avro-decimal-handling-mode=string`](/ticdc/ticdc-sink-to-kafka.md#sink-uri-配置-kafka) 和 [`avro-bigint-unsigned-handling-mode=string`](/ticdc/ticdc-sink-to-kafka.md#sink-uri-配置-kafka)。下面是一个配置示例： + + ```shell + cdc cli changefeed create --server=http://127.0.0.1:8300 --changefeed-id="kafka-avro-checksum" --sink-uri="kafka://127.0.0.1:9092/topic-name?protocol=avro&enable-tidb-extension=true&avro-decimal-handling-mode=string&avro-bigint-unsigned-handling-mode=string" --schema-registry=http://127.0.0.1:8081 --config changefeed_config.toml + ``` + + 通过上述配置，Changefeed 会在每条写入 Kafka 的消息中携带该消息对应数据的 Checksum，你可以根据此 Checksum 的值进行数据一致性校验。 + + > **注意：** + > + > 对于已有 Changefeed，如果未设置 `avro-decimal-handling-mode` 和 `avro-bigint-unsigned-handling-mode`，开启 Checksum 校验功能时会引起 Schema 不兼容问题。可以通过修改 Schema Registry 的兼容性为 `NONE` 解决该问题。详情可参考 [Schema 兼容性](https://docs.confluent.io/platform/current/schema-registry/fundamentals/avro.html#no-compatibility-checking)。 + +## 关闭功能 + +TiCDC 默认关闭单行数据的 Checksum 校验功能。若要在开启此功能后将其关闭，请执行以下步骤： + +1. 首先，按照 [TiCDC 更新同步任务配置](/ticdc/ticdc-manage-changefeed.md#更新同步任务配置)的说明，按照 `暂停任务 -> 修改配置 -> 恢复任务` 的流程更新 Changefeed 的配置内容。在 Changefeed 的 `--config` 参数所指定的配置文件中调整 `[integrity]` 的配置内容为： + + ```toml + [integrity] + integrity-check-level = "none" + corruption-handle-level = "warn" + ``` + +2. 在上游 TiDB 中关闭行数据 Checksum 功能 ([`tidb_enable_row_level_checksum`](/system-variables.md#tidb_enable_row_level_checksum-从-v710-版本开始引入))，执行如下 SQL 语句： + + ```sql + SET GLOBAL tidb_enable_row_level_checksum = OFF; + ``` + + 上述配置仅对新创建的会话生效。在所有写入 TiDB 的客户端都完成数据库连接重建后，Changefeed 写入 Kafka 的消息中将不再携带该条消息对应数据的 Checksum 值。 + +## Checksum 计算规则 + +Checksum 计算算法的伪代码如下： + +``` +fn checksum(columns) { + let result = 0 + for column in sort_by_schema_order(columns) { + result = crc32.update(result, encode(column)) + } + return result +} +``` + +* `columns` 应该按照 column ID 排序。在 Avro schema 中，各个字段已经按照 column ID 的顺序排序，因此可以直接按照此顺序排序 `columns`。 + +* `encode(column)` 函数将 column 的值编码为字节，编码规则取决于该 column 的数据类型。具体规则如下： + + * TINYINT、SMALLINT、INT、BIGINT、MEDIUMINT 和 YEAR 类型会被转换为 UINT64 类型，并按照小端序编码。例如，数字 `0x0123456789abcdef` 会被编码为 `hex'0x0123456789abcdef'`。 + * FLOAT 和 DOUBLE 类型会被转换为 DOUBLE 类型，然后转换为 IEEE754 格式的 UINT64 类型。 + * BIT、ENUM 和 SET 类型会被转换为 UINT64 类型。 + + * BIT 类型按照二进制转换为 UINT64 类型。 + * ENUM 和 SET 类型按照其对应的 INT 值转换为 UINT64 类型。例如，`SET('a','b','c')` 类型 column 的数据值为 `'a,c'`，则该值将被编码为 `0b101`，即 `5`。 + + * TIMESTAMP、DATE、DURATION、DATETIME、JSON 和 DECIMAL 类型会被转换为 STRING 类型，然后转换为字节。 + * CHAR、VARCHAR、VARSTRING、STRING、TEXT、BLOB（包括 TINY、MEDIUM 和 LONG）等字符类型，会直接使用字节。 + * NULL 和 GEOMETRY 类型不会被纳入到 Checksum 计算中，返回空字节。 + +基于 Golang 的 Avro 数据消费和 Checksum 校验，可以参考 [TiCDC 行数据 Checksum 校验](/ticdc/ticdc-avro-checksum-verification.md)。 + +> **注意：** +> +> - 开启 Checksum 校验功能后，DECIMAL 和 UNSIGNED BIGINT 类型的数据会被转换为字符串类型。因此在下游消费者代码中需要将其转换为对应的数值类型，然后进行 Checksum 相关计算。 +> - Delete 事件只含有 Handle Key 列的内容，而 Checksum 是基于所有列计算的，所以 Delete 事件不参与到 Checksum 的校验中。 \ No newline at end of file diff --git a/ticdc/ticdc-open-api-v2.md b/ticdc/ticdc-open-api-v2.md index 8cda309088db..a98cbda533f0 100644 --- a/ticdc/ticdc-open-api-v2.md +++ b/ticdc/ticdc-open-api-v2.md @@ -90,7 +90,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/status ```json { - "version": "v7.0.0-master-dirty", + "version": "v7.2.0", "git_hash": "10413bded1bdb2850aa6d7b94eb375102e9c44dc", "id": "d2912e63-3349-447c-90ba-72a4e04b5e9e", "pid": 1447, diff --git a/ticdc/ticdc-server-config.md b/ticdc/ticdc-server-config.md index d25c21067f2c..40e49bf51091 100644 --- a/ticdc/ticdc-server-config.md +++ b/ticdc/ticdc-server-config.md @@ -23,7 +23,7 @@ summary: 了解 TiCDC 详细的命令行参数和配置文件定义。 - `cert`：TiCDC 创建 TLS 连接时使用的证书文件路径，PEM 格式，可选。 - `cert-allowed-cn`：TiCDC 创建 TLS 连接时使用的通用名称文件路径，可选。 - `key`：TiCDC 创建 TLS 连接时使用的证书密钥文件路径，PEM 格式，可选。 -- `tz`：TiCDC 服务使用的时区。TiCDC 在内部转换 `TIMESTAMP` 等时间数据类型和向下游同步数据时使用该时区，默认为进程运行本地时区。（注意如果同时指定 `tz` 参数和 `sink-uri` 中的 `time-zone` 参数，TiCDC 进程内部使用 `tz` 指定的时区，sink 向下游执行时使用 `time-zone` 指定的时区） +- `tz`：TiCDC 服务使用的时区。TiCDC 在内部转换 `TIMESTAMP` 等时间数据类型和向下游同步数据时使用该时区，默认为进程运行本地时区。（注意如果同时指定 `tz` 参数和 `sink-uri` 中的 `time-zone` 参数，TiCDC 进程内部使用 `tz` 指定的时区，sink 向下游执行时使用 `time-zone` 指定的时区，请保持二者一致。） - `cluster-id`：TiCDC 集群的 ID。可选，默认值为 `default`。`cluster-id` 是 TiCDC 集群的唯一标识，拥有相同 `cluster-id` 的 TiCDC 节点同属一个集群。长度最大为 128，需要符合正则表达式 `^[a-zA-Z0-9]+(-[a-zA-Z0-9]+)*$`，且不能是以下值：`owner`，`capture`，`task`，`changefeed`，`job`，`meta`。 ## `cdc server` 配置文件说明 diff --git a/ticdc/ticdc-sink-to-cloud-storage.md b/ticdc/ticdc-sink-to-cloud-storage.md index edeb45ff211c..9ffaf5eae28d 100644 --- a/ticdc/ticdc-sink-to-cloud-storage.md +++ b/ticdc/ticdc-sink-to-cloud-storage.md @@ -27,6 +27,7 @@ cdc cli changefeed create \ Info: {"upstream_id":7171388873935111376,"namespace":"default","id":"simple-replication-task","sink_uri":"s3://logbucket/storage_test?protocol=canal-json","create_time":"2022-11-29T18:52:05.566016967+08:00","start_ts":437706850431664129,"engine":"unified","config":{"case_sensitive":true,"enable_old_value":true,"force_replicate":false,"ignore_ineligible_table":false,"check_gc_safe_point":true,"enable_sync_point":false,"sync_point_interval":600000000000,"sync_point_retention":86400000000000,"filter":{"rules":["*.*"],"event_filters":null},"mounter":{"worker_num":16},"sink":{"protocol":"canal-json","schema_registry":"","csv":{"delimiter":",","quote":"\"","null":"\\N","include_commit_ts":false},"column_selectors":null,"transaction_atomicity":"none","encoder_concurrency":16,"terminator":"\r\n","date_separator":"none","enable_partition_separator":false},"consistent":{"level":"none","max_log_size":64,"flush_interval":2000,"storage":""}},"state":"normal","creator_version":"v6.5.0-master-dirty"} ``` +- `--server`：TiCDC 集群中任意一个 TiCDC 服务器的地址。 - `--changefeed-id`：同步任务的 ID。格式需要符合正则表达式 `^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$`。如果不指定该 ID，TiCDC 会自动生成一个 UUID（version 4 格式）作为 ID。 - `--sink-uri`：同步任务下游的地址。具体可参考[配置 Sink URI](#配置-sink-uri)。 - `--start-ts`：指定 changefeed 的开始 TSO。TiCDC 集群将从这个 TSO 开始拉取数据。默认为当前时间。 @@ -35,23 +36,13 @@ Info: {"upstream_id":7171388873935111376,"namespace":"default","id":"simple-repl ## 配置 Sink URI -本章节介绍如何在 Changefeed URI 中配置存储服务 Amazon S3、Azure Blob Storage 和 NFS。 - -### 配置外部存储 - -Amazon S3、GCS 以及 Azure Blob Storage 的 URI 参数与 BR 中这三种存储的 URI 参数相同。详细参数说明请参考 [BR 备份存储服务的 URI 格式](/br/backup-and-restore-storages.md#格式说明)。 - -### 配置 NFS - -NFS 配置样例如下： +本章节介绍如何在 Sink URI 中配置存储服务 Amazon S3、GCS、Azure Blob Storage 以及 NFS。Sink URI 用于指定 TiCDC 下游系统的连接信息，遵循以下格式： ```shell ---sink-uri="file:///my-directory/prefix" +[scheme]://[host]/[path]?[query_parameters] ``` -### 可选配置 - -URI 中其他可配置的参数如下： +URI 的 `[query_parameters]` 中可配置的参数如下： | 参数 | 描述 | 默认值 | 取值范围 | | :--------------- | :----------------------------------------------------- | :--------- | :--------------------- | @@ -59,10 +50,45 @@ URI 中其他可配置的参数如下： | `flush-interval` | 向下游存储服务保存数据变更记录的间隔 | `5s` | `[2s, 10m]` | | `file-size` | 单个数据变更文件的字节数超过 `file-size` 时将其保存至存储服务中| `67108864` | `[1048576, 536870912]` | | `protocol` | 输出到存储服务的消息协议 | N/A | `canal-json` 和 `csv` | +| `enable-tidb-extension` | `protocol` 参数为 `canal-json` 时，如果该值为 `true`，TiCDC 会发送 [WATERMARK 事件](/ticdc/ticdc-canal-json.md#watermark-event)，并在 canal-json 消息中添加 [TiDB 扩展字段](/ticdc/ticdc-canal-json.md#tidb-扩展字段)。 | `false` | `false` 和 `true` | > **注意：** > > `flush-interval` 与 `file-size` 二者只要满足其一就会向下游写入数据变更文件。 +> +> `protocol` 是必选配置，如果 TiCDC 在创建 changefeed 时未解析到该配置，将会返回 `CDC:ErrSinkUnknownProtocol` 错误。 + +### 配置外部存储 + +Amazon S3 配置样例如下： + +```shell +--sink-uri="s3://bucket/prefix?protocol=canal-json" +``` + +GCS 配置样例如下： + +```shell +--sink-uri="gcs://bucket/prefix?protocol=canal-json" +``` + +Azure Blob Storage 配置样例如下： + +```shell +--sink-uri="azure://bucket/prefix?protocol=canal-json" +``` + +> **建议：** +> +> Amazon S3、GCS 以及 Azure Blob Storage 的 URI 参数与 BR 中这三种外部存储的 URI 参数相同。详细参数说明请参考 [BR 备份存储服务的 URI 格式](/br/backup-and-restore-storages.md#格式说明)。 + +### 配置 NFS + +NFS 配置样例如下： + +```shell +--sink-uri="file:///my-directory/prefix?protocol=canal-json" +``` ## 存储路径组织结构 @@ -76,13 +102,13 @@ URI 中其他可配置的参数如下： {scheme}://{prefix}/{schema}/{table}/{table-version-separator}/{partition-separator}/{date-separator}/CDC{num}.{extension} ``` -- `scheme`：数据传输协议，即存储类型。例如：**s3**://xxxxx。 +- `scheme`：存储服务类型。例如：`s3`、`gcs`、`azure`、`file`。 - `prefix`：用户指定的父目录。例如：s3://**bucket/bbb/ccc**。 - `schema`：表所属的库名。例如：s3://bucket/bbb/ccc/**test**。 - `table`：表名。例如：s3://bucket/bbb/ccc/test/**table1**。 - `table-version-separator`：将文件路径按照表的版本进行分隔。例如：s3://bucket/bbb/ccc/test/table1/**9999**。 - `partition-separator`：将文件路径按照表的分区号进行分隔。例如：s3://bucket/bbb/ccc/test/table1/9999/**20**。 -- `date-separator`：将文件路径按照事务提交的日期进行分隔，可选值如下： +- `date-separator`：将文件路径按照事务提交的日期进行分隔，默认值为 `day`，可选值如下： - `none`：不以 `date-separator` 分隔文件路径。例如：`test.table1` 版本号为 `9999` 的所有文件都存到 `s3://bucket/bbb/ccc/test/table1/9999` 路径下。 - `year`：以事务提交的年份分隔文件路径。例如：s3://bucket/bbb/ccc/test/table1/9999/**2022**。 - `month`：以事务提交的年份和月份分隔文件路径。例如：s3://bucket/bbb/ccc/test/table1/9999/**2022-01**。 @@ -92,17 +118,14 @@ URI 中其他可配置的参数如下： > **注意：** > -> 表的版本会在以下两种情况下发生变化： -> -> - 发生 DDL 操作后，表的版本为该 DDL 在上游 TiDB 执行结束的 TSO。但是，表版本的变化并不意味着表结构的变化。例如，在表中的某一列添加注释，不会导致 `schema.json` 文件内容发生变化。 -> - 进程重启，表的版本为进程重启时 Changefeed 的 checkpoint TSO。在有很多表的情况下，重启时需要遍历所有目录并找到上一次重启时每张表写入的位置，这样的操作耗时较长。因此，TiCDC 选择在一个以 checkpoint TSO 为版本的新目录下写入数据，而不是在旧版本的目录下继续写入数据。 +> 表的版本仅在上游表发生 DDL 操作后才改变：表的版本为该 DDL 在上游 TiDB 执行结束的 TSO。但是，表版本的变化并不意味着表结构的变化。例如，在表中的某一列添加注释，不会导致 schema 文件内容发生变化。 ### Index 文件 Index 文件用于防止已写入的数据被错误覆盖，与数据变更记录存储在相同路径： ```shell -{scheme}://{prefix}/{schema}/{table}/{table-version-separator}/{partition-separator}/{date-separator}/CDC.index +{scheme}://{prefix}/{schema}/{table}/{table-version-separator}/{partition-separator}/{date-separator}/meta/CDC.index ``` Index 文件记录了当前目录下所使用到的最大文件名，比如： @@ -133,23 +156,27 @@ CDC000005.csv ### DDL 事件 -当 DDL 事件引起表的版本变更时，TiCDC 将会切换到新的路径下写入数据变更记录，例如 `test.table1` 的版本从 `9999` 变更为 `10000` 时将会在 `s3://bucket/bbb/ccc/test/table1/10000/2022-01-02/CDC000001.csv` 路径中写入数据。并且，当 DDL 事件发生时，TiCDC 将生成一个 `schema.json` 文件存储表结构信息。 +#### 表级 DDL 事件 -表结构信息将会存储到以下路径： +当上游表的 DDL 事件引起表的版本变更时，TiCDC 将会自动进行以下操作： -```shell -{scheme}://{prefix}/{schema}/{table}/{table-version-separator}/schema.json -``` +- 切换到新的路径下写入数据变更记录。例如，当 `test.table1` 的版本变更为 `441349361156227074` 时，TiCDC 将会在 `s3://bucket/bbb/ccc/test/table1/441349361156227074/2022-01-02/` 路径下写入数据。 +- 生成一个 schema 文件存储表结构信息，文件路径如下： + + ```shell + {scheme}://{prefix}/{schema}/{table}/meta/schema_{table-version}_{hash}.json + ``` -一个示例 `schema.json` 文件如下： +以 `schema_441349361156227074_3131721815.json` 为例，表结构信息文件的内容如下： ```json { "Table":"table1", "Schema":"test", "Version":1, - "TableVersion":10000, - "Query": "ALTER TABLE test.table1 ADD OfficeLocation blob(20)", + "TableVersion":441349361156227074, + "Query":"ALTER TABLE test.table1 ADD OfficeLocation blob(20)", + "Type":5, "TableColumns":[ { "ColumnName":"Id", @@ -186,6 +213,7 @@ CDC000005.csv - `Version`：Storage sink 协议版本号。 - `TableVersion`：表的版本号。 - `Query`：DDL 语句。 +- `Type`：DDL 类型。 - `TableColumns`：该数组表示表中每一列的详细信息。 - `ColumnName`：列名。 - `ColumnType`：该列的类型。详见[数据类型](#数据类型)。 @@ -196,9 +224,32 @@ CDC000005.csv - `ColumnIsPk`：值为 `true` 时表示该列是主键的一部分。 - `TableColumnsTotal`：`TableColumns` 数组的大小。 +#### 库级 DDL 事件 + +当上游数据库发生库级 DDL 事件时，TiCDC 将会自动生成一个 schema 文件存储数据库结构信息，文件路径如下： + +```shell +{scheme}://{prefix}/{schema}/meta/schema_{table-version}_{hash}.json +``` + +以 `schema_441349361156227000_3131721815.json` 为例，数据库结构信息文件的内容如下： + +```json +{ + "Table": "", + "Schema": "schema1", + "Version": 1, + "TableVersion": 441349361156227000, + "Query": "CREATE DATABASE `schema1`", + "Type": 1, + "TableColumns": null, + "TableColumnsTotal": 0 +} +``` + ## 数据类型 -本章节主要介绍 `schema.json` 文件中使用的各种数据类型。数据类型定义为 `T(M[, D])`，详见[数据类型概述](/data-type-overview.md#数据类型概述)。 +本章节主要介绍 `schema_{table-version}_{hash}.json` 文件（以下简称为 schema 文件）中使用的各种数据类型。数据类型定义为 `T(M[, D])`，详见[数据类型概述](/data-type-overview.md#数据类型概述)。 ### 整数类型 @@ -207,7 +258,7 @@ TiDB 中整数类型可被定义为 `IT[(M)] [UNSIGNED]`，其中： - `IT` 为整数类型，包括 `TINYINT`、`SMALLINT`、`MEDIUMINT`、`INT`、`BIGINT` 和 `BIT`。 - `M` 为该类型的显示宽度。 -`schema.json` 文件中对整数类型定义如下： +schema 文件中对整数类型定义如下： ```json { @@ -225,7 +276,7 @@ TiDB 中的小数类型可被定义为 `DT[(M,D)][UNSIGNED]`，其中： - `M` 为该类型数据的精度，即整数位加上小数位的总长度。 - `D` 为小数位的长度。 -`schema.json` 文件中对小数类型的定义如下： +schema 文件中对小数类型的定义如下： ```json { @@ -242,7 +293,7 @@ TiDB 中的日期类型可被定义为 `DT`，其中： - `DT` 为日期类型，包括 `DATE` 和 `YEAR`。 -`schema.json` 文件中对日期类型的定义如下： +schema 文件中对日期类型的定义如下： ```json { @@ -256,7 +307,7 @@ TiDB 中的时间类型可被定义为 `TT[(M)]`，其中： - `TT` 为时间类型，包括 `TIME`、`DATETIME` 和 `TIMESTAMP`。 - `M` 为秒的精度，取值范围为 0~6。 -`schema.json` 文件中对时间类型的定义如下： +schema 文件中对时间类型的定义如下： ```json { @@ -273,7 +324,7 @@ TiDB 中的字符串类型可被定义为 `ST[(M)]`，其中： - `ST` 为字符串类型，包括 `CHAR`、`VARCHAR`、`TEXT`、`BINARY`、`BLOB`、`JSON` 等。 - `M` 表示字符串的最大长度。 -`schema.json` 文件中对字符串类型的定义如下： +schema 文件中对字符串类型的定义如下： ```json { @@ -285,7 +336,7 @@ TiDB 中的字符串类型可被定义为 `ST[(M)]`，其中： ### Enum/Set 类型 -`schema.json` 文件中对 Enum/Set 类型的定义如下： +schema 文件中对 Enum/Set 类型的定义如下： ```json { diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index a2676ed5e654..86882a1e6dcf 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -24,6 +24,7 @@ ID: simple-replication-task Info: {"sink-uri":"kafka://127.0.0.1:9092/topic-name?protocol=canal-json&kafka-version=2.4.0&partition-num=6&max-message-bytes=67108864&replication-factor=1","opts":{},"create-time":"2020-03-12T22:04:08.103600025+08:00","start-ts":415241823337054209,"target-ts":0,"admin-job-type":0,"sort-engine":"unified","sort-dir":".","config":{"case-sensitive":true,"filter":{"rules":["*.*"],"ignore-txn-start-ts":null,"ddl-allow-list":null},"mounter":{"worker-num":16},"sink":{"dispatchers":null},"scheduler":{"type":"table-number","polling-time":-1}},"state":"normal","history":null,"error":null} ``` +- `--server`：TiCDC 集群中任意一个 TiCDC 服务器的地址。 - `--changefeed-id`：同步任务的 ID，格式需要符合正则表达式 `^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$`。如果不指定该 ID，TiCDC 会自动生成一个 UUID（version 4 格式）作为 ID。 - `--sink-uri`：同步任务下游的地址，详见：[Sink URI 配置 Kafka](/ticdc/ticdc-sink-to-kafka.md#sink-uri-配置-kafka)。 - `--start-ts`：指定 changefeed 的开始 TSO。TiCDC 集群将从这个 TSO 开始拉取数据。默认为当前时间。 @@ -60,12 +61,13 @@ URI 中可配置的的参数如下： | `compression` | 设置发送消息时使用的压缩算法（可选值为 `none`、`lz4`、`gzip`、`snappy` 和 `zstd`，默认值为 `none`）。| | `protocol` | 输出到 Kafka 的消息协议，可选值有 `canal-json`、`open-protocol`、`canal`、`avro`、`maxwell`。 | | `auto-create-topic` | 当传入的 `topic-name` 在 Kafka 集群不存在时，TiCDC 是否要自动创建该 topic（可选，默认值 `true`）。 | -| `enable-tidb-extension` | 可选，默认值是 `false`。当输出协议为 `canal-json` 时，如果该值为 `true`，TiCDC 会发送 [Resolved 事件](/ticdc/ticdc-canal-json.md#watermark-event)，并在 Kafka 消息中添加 TiDB 扩展字段。从 6.1.0 开始，该参数也可以和输出协议 `avro` 一起使用。如果该值为 `true`，TiCDC 会在 Kafka 消息中添加[三个 TiDB 扩展字段](/ticdc/ticdc-avro-protocol.md#tidb-扩展字段)。| +| `enable-tidb-extension` | 可选，默认值是 `false`。当输出协议为 `canal-json` 时，如果该值为 `true`，TiCDC 会发送 [WATERMARK 事件](/ticdc/ticdc-canal-json.md#watermark-event)，并在 Kafka 消息中添加 TiDB 扩展字段。从 6.1.0 开始，该参数也可以和输出协议 `avro` 一起使用。如果该值为 `true`，TiCDC 会在 Kafka 消息中添加[三个 TiDB 扩展字段](/ticdc/ticdc-avro-protocol.md#tidb-扩展字段)。| | `max-batch-size` | 从 v4.0.9 开始引入。当消息协议支持把多条变更记录输出至一条 Kafka 消息时，该参数用于指定这一条 Kafka 消息中变更记录的最多数量。目前，仅当 Kafka 消息的 `protocol` 为 `open-protocol` 时有效（可选，默认值 `16`）。| | `enable-tls` | 连接下游 Kafka 实例是否使用 TLS（可选，默认值 `false`）。 | | `ca` | 连接下游 Kafka 实例所需的 CA 证书文件路径（可选）。 | | `cert` | 连接下游 Kafka 实例所需的证书文件路径（可选）。 | | `key` | 连接下游 Kafka 实例所需的证书密钥文件路径（可选）。 | +| `insecure-skip-verify` | 连接下游 Kafka 实例时是否跳过证书验证（可选，默认值 `false`）。 | | `sasl-user` | 连接下游 Kafka 实例所需的 SASL/PLAIN 或 SASL/SCRAM 认证的用户名（authcid）（可选）。 | | `sasl-password` | 连接下游 Kafka 实例所需的 SASL/PLAIN 或 SASL/SCRAM 认证的密码（可选）。如有特殊字符，需要用 URL encode 转义。 | | `sasl-mechanism` | 连接下游 Kafka 实例所需的 SASL 认证方式的名称，可选值有 `plain`、`scram-sha-256`、`scram-sha-512` 和 `gssapi`。 | @@ -133,7 +135,7 @@ URI 中可配置的的参数如下： TiCDC 能够正常工作所需的最小权限集合如下： - - 对 Topic [资源类型](https://docs.confluent.io/platform/current/kafka/authorization.html#resources)的 `Create` 和 `Write` 权限。 + - 对 Topic [资源类型](https://docs.confluent.io/platform/current/kafka/authorization.html#resources)的 `Create` 、`Write` 和 `Describe` 权限。 - 对 Cluster 资源类型的 `DescribeConfigs` 权限。 ### TiCDC 集成 Kafka Connect (Confluent Platform) @@ -235,9 +237,15 @@ partition 分发器用 partition = "xxx" 来指定，支持 default、ts、index > {matcher = ['*.*'], dispatcher = "ts", partition = "table"}, > ``` +> **警告：** +> +> 当开启 [Old Value 功能](/ticdc/ticdc-manage-changefeed.md#输出行变更的历史值-从-v405-版本开始引入)时 (`enable-old-value = true`)，使用 index-value 分发器可能导致无法确保相同索引值的行变更顺序。因此，建议使用 default 分发器。 +> +> 具体原因请参考 [TiCDC 在开启 Old Value 功能后更新事件格式有何变化？](/ticdc/ticdc-faq.md#ticdc-在开启-old-value-功能后更新事件格式有何变化) + ## 横向扩展大单表的负载到多个 TiCDC 节点 -该功能通过将大单表按 Region 个数切分成多个数据范围，将这些数据范围分布到多个 TiCDC 节点上，使得多个 TiCDC 节点可以同时同步大单表。该功能可以解决以下两个问题： +该功能可以按照大单表的数据量和每分钟的修改行数将表的同步范围切分为多个，并使各个范围之间所同步的数据量和修改行数基本相同。该功能将这些范围分布到多个 TiCDC 节点进行同步，使得多个 TiCDC 节点可以同时同步大单表。该功能可以解决以下两个问题： - 单个 TiCDC 节点不能及时同步大单表。 - TiCDC 节点之间资源（CPU、内存等）消耗不均匀。 @@ -250,10 +258,18 @@ partition 分发器用 partition = "xxx" 来指定，支持 default、ts、index ```toml [scheduler] -# 设置为 "true" 以打开该功能。 +# 默认值为 "false"，设置为 "true" 以打开该功能。 enable-table-across-nodes = true # 打开该功能后，该功能只对 Region 个数大于 `region-threshold` 值的表生效。 region-threshold = 100000 +# 打开该功能后，该功能会对每分钟修改行数大于 `write-key-threshold` 值的表生效。 +# 注意： +# * 该参数默认值为 0，代表该功能默认不会按表的修改行数来切分表的同步范围。 +# * 你可以根据集群负载来配置该参数，如 30000，代表当表每分钟的更新行数超过 30000 时，该功能将会切分表的同步范围。 +# * 当 `region-threshold` 和 `write-key-threshold` 同时配置时， +# TiCDC 将优先检查修改行数是否大于 `write-key-threshold`， +# 如果不超过，则再检查 Region 个数是否大于 `region-threshold`。 +write-key-threshold = 30000 ``` 一个表包含的 Region 个数可用如下 SQL 查询： diff --git a/ticdc/ticdc-sink-to-mysql.md b/ticdc/ticdc-sink-to-mysql.md index 995f84ec94cf..c59a2eec5b64 100644 --- a/ticdc/ticdc-sink-to-mysql.md +++ b/ticdc/ticdc-sink-to-mysql.md @@ -24,6 +24,7 @@ ID: simple-replication-task Info: {"sink-uri":"mysql://root:123456@127.0.0.1:3306/","opts":{},"create-time":"2020-03-12T22:04:08.103600025+08:00","start-ts":415241823337054209,"target-ts":0,"admin-job-type":0,"sort-engine":"unified","sort-dir":".","config":{"case-sensitive":true,"filter":{"rules":["*.*"],"ignore-txn-start-ts":null,"ddl-allow-list":null},"mounter":{"worker-num":16},"sink":{"dispatchers":null},"scheduler":{"type":"table-number","polling-time":-1}},"state":"normal","history":null,"error":null} ``` +- `--server`：TiCDC 集群中任意一个 TiCDC 服务器的地址。 - `--changefeed-id`：同步任务的 ID，格式需要符合正则表达式 `^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$`。如果不指定该 ID，TiCDC 会自动生成一个 UUID（version 4 格式）作为 ID。 - `--sink-uri`：同步任务下游的地址，详见 [Sink URI 配置 `mysql`/`tidb`](#sink-uri-配置-mysqltidb)。 - `--start-ts`：指定 changefeed 的开始 TSO。TiCDC 集群将从这个 TSO 开始拉取数据。默认为当前时间。 @@ -57,11 +58,12 @@ URI 中可配置的参数如下： | `127.0.0.1` | 下游数据库的 IP。 | | `3306` | 下游数据的连接端口。 | | `worker-count` | 向下游执行 SQL 的并发度（可选，默认值为 `16`）。 | +| `cache-prep-stmts` | 向下游执行 SQL 时是否使用 prepared statement 并且开启客户端的 prepared statement 缓存（可选，默认值为 `true`）。 | | `max-txn-row` | 向下游执行 SQL 的 batch 大小（可选，默认值为 `256`）。 | | `ssl-ca` | 连接下游 MySQL 实例所需的 CA 证书文件路径（可选）。 | | `ssl-cert` | 连接下游 MySQL 实例所需的证书文件路径（可选）。 | | `ssl-key` | 连接下游 MySQL 实例所需的证书密钥文件路径（可选）。 | -| `time-zone` | 连接下游 MySQL 实例时使用的时区名称，从 v4.0.8 开始生效。（可选。如果不指定该参数，使用 TiCDC 服务进程的时区；如果指定该参数但使用空值，则表示连接 MySQL 时不指定时区，使用下游默认时区）。 | +| `time-zone` | 连接下游 MySQL 实例时使用的时区名称，从 v4.0.8 开始生效。（可选。如果不指定该参数，使用 TiCDC 服务进程的时区；如果指定该参数但使用空值，例如：`time-zone=""`，则表示连接 MySQL 时不指定时区，使用下游默认时区）。 | | `transaction-atomicity` | 指定事务的原子性级别（可选，默认值为 `none`）。当该值为 `table` 时 TiCDC 保证单表事务的原子性，当该值为 `none` 时 TiCDC 会拆分单表事务。 | 若需要对 Sink URI 中的数据库密码使用 Base64 进行编码，可以参考如下命令： diff --git a/ticdc/ticdc-summary-monitor.md b/ticdc/ticdc-summary-monitor.md new file mode 100644 index 000000000000..8f3b9acf8fd5 --- /dev/null +++ b/ticdc/ticdc-summary-monitor.md @@ -0,0 +1,101 @@ +--- +title: TiCDC 基本监控指标 +summary: 了解 TiCDC 基本的监控指标。 +--- + +# TiCDC 基本监控指标 + +从 v7.0.0 版本开始，使用 TiUP 一键部署 Grafana 时，会自动在 Grafana 监控页面新增 TiCDC Summary Dashboard。通过该监控面板，你可以快速地了解 TiCDC 服务器运行状态和同步任务的基本情况。 + +下图显示了 TiCDC Dashboard 的监控栏： + +![TiCDC Summary Dashboard - Overview](/media/ticdc/ticdc-summary-monitor.png) + +各监控栏说明如下： + +- Server：集群中 TiCDC 节点的概要信息 +- Changefeed：TiCDC 同步任务延迟和状态信息 +- Dataflow：TiCDC 内部各个模块处理数据改变的各种统计信息 +- Transaction Sink：下游为 MySQL 或者 TiDB 时的写延迟信息 +- MQ Sink: 下游为 MQ 系统时的写延迟信息 +- Cloud Storage Sink：下游为 Cloud Storage 时的写速率信息 +- Redo：开启 Redo 功能时的写延迟信息 + +## Server 监控栏 + +Server 监控栏示例如下： + +![TiCDC Summary Dashboard - Server metrics](/media/ticdc/ticdc-summary-monitor-server.png) + +- Uptime：TiCDC 节点已经运行的时间。 +- CPU usage：TiCDC 节点的 CPU 使用量。 +- Memory usage：TiCDC 节点的内存使用量。 + +## Changefeed 监控栏 + +Changefeed 监控栏示例如下： + +![TiCDC Summary Dashboard - Changefeed metrics](/media/ticdc/ticdc-summary-monitor-changefeed.png) + +- Changefeed checkpoint lag：这个指标代表上游 TiDB 集群和下游系统之间的数据复制延迟，延迟以时间为单位。该指标反映了 Changefeed 整体的数据同步状况是否健康，通常情况下，lag 越小，说明同步任务状态越好。而当 lag 上升时，通常说明 Changefeed 的同步能力或者下游系统的消费能力无法匹配上游的写入速度。 +- Changefeed resolved ts lag：这个指标代表了上游 TiDB 集群与 TiCDC 节点之间的数据延迟，延迟以时间为单位。该指标能够反映 Changefeed 拉取上游数据变更的能力，当 lag 上升时，说明 Changefeed 无法及时地拉取上游产生的数据变更。 + +## Dataflow 监控栏 + +![TiCDC Summary Dashboard - Puller metrics](/media/ticdc/ticdc-summary-monitor-dataflow-puller.png) + +- Puller output events/s：TiCDC 节点中 Puller 模块每秒输出到 Sorter 模块的数据变更个数。该指标能够反映 TiCDC 拉取上游变更事件的速度。 +- Puller output events：TiCDC 节点中 Puller 模块输出到 Sorter 模块的数据变更总数。 + +![TiCDC Summary Dashboard - Sorter metrics](/media/ticdc/ticdc-summary-monitor-dataflow-sorter.png) + +- Sorter output events/s：TiCDC 节点中 Sorter 模块每秒输出到 Sink 模块的数据变更个数。值得注意的是，Sorter 的数据输出速率会受到 Sink 模块的影响，因此在发现 Sorter 模块输出速率比 Puller 模块低时，不一定是因为 Sorter 模块排序速度过慢；而应该先观察 Sink 模块的相关指标，确认是否是因为 Sink 模块 Flush 数据的耗时较长，导致 Sorter 模块输出降低。 +- Sorter output event：TiCDC 节点中 Sorter 模块输出到 Sink 模块的数据变更总个数。 + +![TiCDC Summary Dashboard - Mounter metrics](/media/ticdc/ticdc-summary-monitor-dataflow-mounter.png) + +- Mounter output events/s：TiCDC 节点中 Mounter 模块每秒解码的数据变更的个数。当上游发生的数据变更包含较多字段时，Mounter 的解码速度可能会受到影响。 +- Mounter output event：TiCDC 节点中 Mounter 模块解码的数据变更的总个数。 + +![TiCDC Summary Dashboard - Sink metrics](/media/ticdc/ticdc-summary-monitor-dataflow-sink.png) + +- Sink flush rows/s：TiCDC 节点中 Sink 模块每秒往下游输出的数据变更个数。该指标反映的是同步任务向下游进行同步的速率，当 Sink flush rows/s 小于 Puller output events/s 时，同步延迟可能会上升。 +- Sink flush rows：TiCDC 节点中 Sink 模块输出的数据变更的总个数。 + +## Transaction Sink 监控栏 + +Transaction Sink 监控栏示意如下，该监控栏只有下游为 MySQL 或者 TiDB 时才有数据。 + +![TiCDC Summary Dashboard - Transaction Sink metrics](/media/ticdc/ticdc-summary-monitor-transaction-sink.png) + +- Backend Flush Duration：TiCDC Transaction Sink 模块在向下游执行一条 SQL 语句的耗时。通过观察该指标，能够判断下游的性能是否为同步速度的瓶颈。一般来说，p999 应该维持在 500 ms 内为佳，超过该值时，同步速度可能就会受到影响，引起 Changefeed checkpoint lag 上升。 +- Full Flush Duration：TiCDC 中每个事务从 Sorter 排序完成直到发送到下游之间的总耗时。用该值减去 Backend Flush Duration 的值，即可得出一个事务在被执行到下游之前的总排队时长。如果排队时长较高，可以考虑给同步任务分配更多的内存 Quota。 + +## MQ Sink 监控栏 + +MQ Sink 监控栏示意如下，该监控栏只有下游为 Kafka 时才有数据。 + +![TiCDC Summary Dashboard - Transaction Sink metrics](/media/ticdc/ticdc-summary-monitor-mq-sink.png) + +- Worker Send Message Duration Percentile：TiCDC MQ Sink 的 Worker 往下游发送数据的延迟。 +- Kafka Ongoing Bytes：TiCDC MQ Sink 往下游发送数据的速率。 + +## Cloud Storage Sink 监控栏 + +Cloud Storage Sink 监控栏示意如下，该监控栏只有下游为 Cloud Storage 时才有数据。 + +![TiCDC Summary Dashboard - Transaction Sink metrics](/media/ticdc/ticdc-summary-monitor-cloud-storage.png) + +- Write Bytes/s：Cloud Storage Sink 模块往下游写数据的速率。 +- File Count：Cloud Storage Sink 模块写文件的总数量。 + +## Redo 监控栏 + +Redo 监控栏示意如下，该监控栏只有在开启了 Redo Log 功能时才有数据。 + +![TiCDC Summary Dashboard - Transaction Sink metrics](/media/ticdc/ticdc-summary-monitor-redo.png) + +- Redo Write rows/s：Redo 模块每秒写数据的行数。当开启 Redo 功能时，如果发现同步任务的延迟上升，那么可以观察该指标是否和 Puller Output event/s 的值有较大差距。如果是，那么可能是由于 Redo 模块的写入能力不足造成延迟上升。 +- Redo Write Byte/s：Redo 模块每秒写数据的速率。 +- Redo flush log duration：Redo 模块往下游刷写数据的耗时。若该指标值较高，则可能是它影响了同步的速度。 +- Redo flushall duration：数据变更停留在 Redo 模块中的总时长。 \ No newline at end of file diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index e7c399845180..c91151aaf409 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -82,37 +82,9 @@ Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skipping it. ``` -如果下游是特殊的 MySQL 环境（某种公有云 RDS 或某些 MySQL 衍生版本等），使用上述方式导入时区失败，就需要通过 sink-uri 中的 `time-zone` 参数指定下游的 MySQL 时区。可以首先在 MySQL 中查询其使用的时区： +如果下游是特殊的 MySQL 环境（某种公有云 RDS 或某些 MySQL 衍生版本等），使用上述方式导入时区失败，则可以通过设置 `time-zone` 为空值来使用下游默认时区，例如：`time-zone=""`。 -```shell -show variables like '%time_zone%'; -``` - -```shell -+------------------+--------+ -| Variable_name | Value | -+------------------+--------+ -| system_time_zone | CST | -| time_zone | SYSTEM | -+------------------+--------+ -``` - -然后在创建同步任务和创建 TiCDC 服务时使用该时区： - -```shell -cdc cli changefeed create --sink-uri="mysql://root@127.0.0.1:3306/?time-zone=CST" --server=http://127.0.0.1:8300 -``` - -> **注意：** -> -> CST 可能是以下四个不同时区的缩写： -> -> - 美国中部时间：Central Standard Time (USA) UT-6:00 -> - 澳大利亚中部时间：Central Standard Time (Australia) UT+9:30 -> - 中国标准时间：China Standard Time UT+8:00 -> - 古巴标准时间：Cuba Standard Time UT-4:00 -> -> 在中国，CST 通常表示中国标准时间，使用时请注意甄别。 +在 TiCDC 中使用时区时，建议显式指定时区，例如：`time-zone="Asia/Shanghai"`。同时，请确保 TiCDC Server 的 `tz` 时区配置、Sink URI 中的 `time-zone` 时区配置和下游数据库的时区配置保持一致。这样可以避免因时区不一致导致的数据不一致问题。 ## 如何处理升级 TiCDC 后配置文件不兼容的问题？ diff --git a/tidb-binlog/get-started-with-tidb-binlog.md b/tidb-binlog/get-started-with-tidb-binlog.md index f6d77905c368..2e3da643f2ed 100644 --- a/tidb-binlog/get-started-with-tidb-binlog.md +++ b/tidb-binlog/get-started-with-tidb-binlog.md @@ -47,7 +47,7 @@ sudo yum install -y mariadb-server {{< copyable "shell-regular" >}} ```bash -curl -LO https://download.pingcap.org/tidb-community-server-v7.0.0-linux-amd64.tar.gz | tar xzf - && +curl -LO https://download.pingcap.org/tidb-community-server-v7.2.0-linux-amd64.tar.gz | tar xzf - && cd tidb-latest-linux-amd64 ``` diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index 18d077d0aa16..a6b907a3a8b7 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -46,6 +46,7 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ + TiDB 用于存放临时数据的路径。如果一个功能需要使用 TiDB 节点的本地存储，TiDB 将把对应数据临时存放在这个目录下。 + 在创建索引的过程中，如果开启了[创建索引加速](/system-variables.md#tidb_ddl_enable_fast_reorg-从-v630-版本开始引入)，那么新创建索引需要回填的数据会被先存放在 TiDB 本地临时存储路径，然后批量导入到 TiKV，从而提升索引创建速度。 ++ 在使用 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) 导入数据时，排序后的数据会被先存放在 TiDB 本地临时存储路径，然后批量导入到 TiKV。 + 默认值："/tmp/tidb" ### `oom-use-tmp-storage` @@ -82,8 +83,12 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ + 设置 `KILL` 语句的兼容性。 + 默认值：false -+ TiDB 中 `KILL xxx` 的行为和 MySQL 中的行为不相同。为杀死一条查询，在 TiDB 里需要加上 `TIDB` 关键词，即 `KILL TIDB xxx`。但如果把 `compatible-kill-query` 设置为 true，则不需要加上 `TIDB` 关键词。 -+ 这种区别很重要，因为当用户按下 Ctrl+C 时，MySQL 命令行客户端的默认行为是：创建与后台的新连接，并在该新连接中执行 `KILL` 语句。如果负载均衡器或代理已将该新连接发送到与原始会话不同的 TiDB 服务器实例，则该错误会话可能被终止，从而导致使用 TiDB 集群的业务中断。只有当您确定在 `KILL` 语句中引用的连接正好位于 `KILL` 语句发送到的服务器上时，才可以启用 `compatible-kill-query`。 ++ `compatible-kill-query` 仅在 [`enable-global-kill`](#enable-global-kill-从-v610-版本开始引入) 为 `false` 时生效。 ++ 当 [`enable-global-kill`](#enable-global-kill-从-v610-版本开始引入) 为 `false` 时，`compatible-kill-query` 控制杀死一条查询时是否需要加上 `TIDB` 关键词。 + - `compatible-kill-query` 为 `false` 时，TiDB 中 `KILL xxx` 的行为和 MySQL 中的行为不同。为杀死一条查询，在 TiDB 中需要加上 `TIDB` 关键词，即 `KILL TIDB xxx`。 + - `compatible-kill-query` 为 `true` 时，为杀死一条查询，在 TiDB 中无需加上 `TIDB` 关键词。**强烈不建议**设置 `compatible-kill-query` 为 `true`，**除非**你确定客户端将始终连接到同一个 TiDB 节点。这是因为当你在默认的 MySQL 客户端按下 Control+C 时，客户端会开启一个新连接，并在这个新连接中执行 `KILL` 语句。此时，如果客户端和 TiDB 之间存在代理，新连接可能会被路由到其他 TiDB 节点，从而错误地终止其他会话。 ++ 当 [`enable-global-kill`](#enable-global-kill-从-v610-版本开始引入) 为 `true` 时，`KILL xxx` 和 `KILL TIDB xxx` 的作用相同，但是暂不支持 Control+C 终止查询。 ++ 关于 `KILL` 语句的更多信息，请参考 [KILL [TIDB]](/sql-statements/sql-statement-kill.md)。 ### `check-mb4-value-in-utf8` @@ -110,7 +115,7 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ + 用来修改 TiDB 在以下情况下返回的版本号： - 当使用内置函数 `VERSION()` 时。 - - 当与客户端初始连接，TiDB 返回带有服务端版本号的初始握手包时。具体可以查看 MySQL 初始握手包的[描述](https://dev.mysql.com/doc/internals/en/connection-phase-packets.html#packet-Protocol::Handshake)。 + - 当与客户端初始连接，TiDB 返回带有服务端版本号的初始握手包时。具体可以查看 MySQL 初始握手包的[描述](https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_connection_phase.html#sect_protocol_connection_phase_initial_handshake)。 + 默认值："" + 默认情况下，TiDB 版本号格式为：`5.7.${mysql_latest_minor_version}-TiDB-${tidb_version}`。 @@ -213,6 +218,16 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ + 默认值：false + 表级锁用于协调多个 session 之间对同一张表的并发访问。目前已支持的锁种类包括 `READ`、`WRITE` 和 `WRITE LOCAL`。当该配置项为 `false` 时，执行 `LOCK TABLES` 和 `UNLOCK TABLES` 语句不会生效，并且会报 "LOCK/UNLOCK TABLES is not supported" 的警告。更多信息，请参考 [`LOCK TABLES` 和 `UNLOCK TABLES`](/sql-statements/sql-statement-lock-tables-and-unlock-tables.md)。 +### `labels` + ++ 指定服务器标签，例如 `{ zone = "us-west-1", dc = "dc1", rack = "rack1", host = "tidb1" }`。 ++ 默认值：`{}` + +> **注意：** +> +> - 标签 `zone` 在 TiDB 中具有特殊用途，用于指定服务器所在的区域信息，当设置 `zone` 为非空值时，对应的值会被自动用于 [`txn-score`](/system-variables.md#txn_scope) 和 [`Follower read`](/follower-read.md) 等功能。 +> - 标签 `group` 在 TiDB Operator 中具有特殊用途。对于使用 [TiDB Operator](/tidb-operator-overview.md) 部署的集群，建议不要手动指定此标签。 + ## log 日志相关的配置项。 @@ -272,6 +287,13 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ + 默认值：10000 + 当查询的行数（包括中间结果，基于统计信息）大于这个值，该操作会被认为是 `expensive` 查询，并输出一个前缀带有 `[EXPENSIVE_QUERY]` 的日志。 +### `timeout` 从 v7.1.0 版本开始引入 + ++ 用于设置 TiDB 写日志操作的超时时间。当磁盘故障导致日志无法写入时，该配置可以让 TiDB 进程崩溃而不是卡死。 ++ 默认值：0，表示不设置超时 ++ 单位：秒 ++ 在某些用户场景中，TiDB 日志可能是保存在热插拔盘或网络挂载盘上，这些磁盘可能会永久丢失。在这种场景下，TiDB 无法自动恢复，写日志操作会永久阻塞。尽管 TiDB 进程看起来仍在运行，但不会响应任何请求。该配置项用于处理这样的场景。 + ## log.file 日志文件相关的配置项。 @@ -514,20 +536,12 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ ### `stats-load-concurrency` 从 v5.4.0 版本开始引入 -> **警告：** -> -> 统计信息同步加载功能目前为实验性特性，不建议在生产环境中使用。 - + TiDB 统计信息同步加载功能可以并发处理的最大列数 + 默认值：5 + 目前的合法值范围：`[1, 128]` ### `stats-load-queue-size` 从 v5.4.0 版本开始引入 -> **警告：** -> -> 统计信息同步加载功能目前为实验性特性，不建议在生产环境中使用。 - + 用于设置 TiDB 统计信息同步加载功能最多可以缓存多少列的请求 + 默认值：1000 + 目前的合法值范围：`[1, 100000]` @@ -541,6 +555,20 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ + 用于控制 TiDB 是否开启统计信息缓存的内存上限。 + 默认值：false +### `lite-init-stats` 从 v7.1.0 版本开始引入 + ++ 用于控制 TiDB 启动时是否采用轻量级的统计信息初始化。 ++ 默认值：在 v7.2.0 之前版本中为 `false`，在 v7.2.0 及之后的版本中为 `true`。 ++ 当 `lite-init-stats` 为 `true` 时，统计信息初始化时列和索引的直方图、TopN、Count-Min Sketch 均不会加载到内存中。当 `lite-init-stats` 为 `false` 时，统计信息初始化时索引和主键的直方图、TopN、Count-Min Sketch 会被加载到内存中，非主键列的直方图、TopN、Count-Min Sketch 不会加载到内存中。当优化器需要某一索引或者列的直方图、TopN、Count-Min Sketch 时，这些统计信息会被同步或异步加载到内存中（由 [`tidb_stats_load_sync_wait`](/system-variables.md#tidb_stats_load_sync_wait-从-v540-版本开始引入) 控制）。 ++ 将 `lite-init-stats` 设置为 true，可以加速统计信息初始化，避免加载不必要的统计信息，从而降低 TiDB 的内存使用。详情请参考[统计信息的加载](/statistics.md#统计信息的加载)。 + +### `force-init-stats` 从 v7.1.0 版本开始引入 + ++ 用于控制 TiDB 启动时是否在统计信息初始化完成后再对外提供服务。 ++ 默认值：在 v7.2.0 之前版本中为 `false`，在 v7.2.0 及之后的版本中为 `true`。 ++ 当 `force-init-stats` 为 `true` 时，TiDB 启动时会等到统计信息初始化完成后再对外提供服务。需要注意的是，在表和分区数量较多且 [`lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-从-v710-版本开始引入) 为 `false` 的情况下，`force-init-stats` 为 `true` 可能会导致 TiDB 从启动到开始对外提供服务的时间变长。 ++ 当 `force-init-stats` 为 `false` 时，TiDB 在统计信息初始化未完成时即可对外提供服务，但由于统计信息初始化未完成，优化器会用 pseudo 统计信息进行决策，可能会产生不合理的执行计划。 + ## opentracing opentracing 的相关的设置。 @@ -817,7 +845,7 @@ TiDB 服务状态相关配置。 + 用于表示该 tidb-server 是否可以成为 DDL owner。 + 默认值：true -+ 该值作为系统变量 [`tidb_enable_ddl`](/system-variables.md#tidb_enable_ddl) 的初始值。 ++ 该值作为系统变量 [`tidb_enable_ddl`](/system-variables.md#tidb_enable_ddl-从-v630-版本开始引入) 的初始值。 + 在 v6.3.0 之前，该功能由配置项 `run-ddl` 进行设置。 ### `tidb_stmt_summary_enable_persistent` 从 v6.6.0 版本开始引入 @@ -886,6 +914,11 @@ PROXY 协议相关的配置项。 > > 需谨慎使用 `*` 符号，因为 `*` 允许来自任何 IP 的客户端自行汇报其 IP 地址，从而可能引入安全风险。另外，`*` 可能导致部分直接连接 TiDB 的内部组件无法使用，例如 TiDB Dashboard。 +### `fallbackable` 从 v6.5.1 版本开始引入 + ++ 用于控制是否启用 PROXY 协议回退模式。如果设置为 `true`，TiDB 可以接受属于 `proxy-protocol.networks` 的客户端使用非 PROXY 协议规范或者没有发送 PROXY 协议头的客户端连接。默认情况下，TiDB 仅接受属于 `proxy-protocol.networks` 的客户端发送 PROXY 协议头的客户端连接。 ++ 默认：`false` + ## experimental experimental 部分为 TiDB 实验功能相关的配置。该部分从 v3.1.0 开始引入。 diff --git a/tidb-control.md b/tidb-control.md index ea410e700234..b8971fefa77c 100644 --- a/tidb-control.md +++ b/tidb-control.md @@ -7,6 +7,10 @@ aliases: ['/docs-cn/dev/tidb-control/','/docs-cn/dev/reference/tools/tidb-contro TiDB Control 是 TiDB 的命令行工具，用于获取 TiDB 状态信息，多用于调试。本文介绍了 TiDB Control 的主要功能和各个功能的使用方法。 +> **注意：** +> +> TiDB Control 主要用于诊断调试，不保证和 TiDB 未来引入的新特性完全兼容。因此不推荐客户在应用程序开发或工具开发中利用 TiDB Control 获取结果。 + ## 获取 TiDB Control 本节提供了两种方式获取 TiDB Control 工具。 @@ -21,7 +25,7 @@ TiDB Control 是 TiDB 的命令行工具，用于获取 TiDB 状态信息，多 ### 从源代码编译安装 -编译环境要求：[Go](https://golang.org/) Version 1.19 以上 +编译环境要求：[Go](https://golang.org/) 1.20 或以上版本 编译步骤：在 [TiDB Control 项目](https://github.com/pingcap/tidb-ctl)根目录，使用 `make` 命令进行编译，生成 tidb-ctl。 diff --git a/tidb-distributed-execution-framework.md b/tidb-distributed-execution-framework.md new file mode 100644 index 000000000000..232396f08254 --- /dev/null +++ b/tidb-distributed-execution-framework.md @@ -0,0 +1,98 @@ +--- +title: TiDB 后端任务分布式框架 +summary: 了解 TiDB 后端任务分布式框架的使用场景与限制、使用方法和实现原理。 +--- + +# TiDB 后端任务分布式框架 + +> **警告：** +> +> 当前该功能为实验特性，不建议在生产环境中使用。 + +TiDB 采用计算存储分离架构，具有出色的扩展性和弹性的扩缩容能力。从 v7.1.0 开始，TiDB 引入了一个后端任务分布式执行框架，以进一步发挥分布式架构的资源优势。该框架的目标是实现对所有后端任务的统一调度与分布式执行，并为接入的后端任务提供统一的资源管理能力，从整体和单个后端任务两个维度提供资源管理的能力，更好地满足用户对于资源使用的预期。 + +本文档介绍了 TiDB 后端任务分布式框架的使用场景与限制、使用方法和实现原理。 + +> **注意：** +> +> 本框架不支持 SQL 查询的分布式执行。 + +## 使用场景与限制 + +在数据库中，除了核心的事务型负载任务 (TP) 和分析型查询任务 (AP)，也存在着其他重要任务，如 DDL 语句、IMPORT INTO、TTL、Analyze 和 Backup/Restore 等，即**后端任务**。这些任务需要处理数据库对象（表）中的大量数据，通常具有如下特点： + +- 需要处理一个 schema 或者一个数据库对象（表）中的所有数据。 +- 可能需要周期执行，但频率较低。 +- 如果资源控制不当，容易对事务型任务和分析型任务造成影响，影响数据库的服务质量。 + +启用 TiDB 后端任务分布式框架能够解决上述问题，并且具有以下三个优势： + +- 提供高扩展性、高可用性和高性能的统一能力支持。 +- 支持后端任务分布式执行，可以在整个 TiDB 集群可用的计算资源范围内进行灵活的调度，从而更好地利用 TiDB 集群内的计算资源。 +- 提供统一的资源使用和管理能力，从整体和单个后端任务两个维度提供资源管理的能力。 + +目前，后端任务分布式框架支持分布式执行 `ADD INDEX` 和 `IMPORT INTO`。 + +- `ADD INDEX`，即 DDL 创建索引的场景。例如以下 SQL 语句： + + ```sql + ALTER TABLE t1 ADD INDEX idx1(c1); + CREATE INDEX idx1 ON table t1(c1); + ``` + +- `IMPORT INTO` 用于将 `CSV`、`SQL`、`PARQUET` 等格式的数据导入到一张空表中。详情请参考 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)。 + +## 启用前提 + +使用分布式框架前，你需要启动 [Fast Online DDL](/system-variables.md#tidb_ddl_enable_fast_reorg-从-v630-版本开始引入) 模式。 + +1. 调整 Fast Online DDL 相关的系统变量： + + * [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-从-v630-版本开始引入)：从 TiDB v6.5.0 开始默认打开，用于启用快速模式。 + * [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-从-v630-版本开始引入)：用于控制快速模式可使用的本地磁盘最大配额。 + +2. 调整 Fast Online DDL 相关的配置项： + + * [`temp-dir`](/tidb-configuration-file.md#temp-dir-从-v630-版本开始引入)：指定快速模式能够使用的本地盘路径。 + +> **注意：** +> +> 在升级到 v6.5.0 及以上版本时，建议你检查 TiDB 的 `temp-dir` 路径是否正确挂载了 SSD 磁盘。该参数是 TiDB 的配置参数，设置后需要重启 TiDB 才能生效。因此，在升级前提前进行设置，可以避免再次重启。 + +## 启用步骤 + +1. 启用分布式框架，只需将 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-从-v710-版本开始引入) 设置为 `ON`： + + ```sql + SET GLOBAL tidb_enable_dist_task = ON; + ``` + + 在运行后端任务时，框架支持的语句会采用分布式方式执行。 + +2. 根据实际需求，调整可能影响 DDL 任务分布式执行的系统变量： + + * [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt)：使用默认值 `4` 即可，建议最大不超过 `16`。 + * [`tidb_ddl_reorg_priority`](/system-variables.md#tidb_ddl_reorg_priority) + * [`tidb_ddl_error_count_limit`](/system-variables.md#tidb_ddl_error_count_limit) + * [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size)：使用默认值即可，建议最大不超过 `1024`。 + +> **建议：** +> +> 对于分布式执行 `ADD INDEX` 语句，只需要设置 `tidb_ddl_reorg_worker_cnt`。 + +## 实现原理 + +TiDB 后端任务分布式框架的架构图如下： + +![后端任务分布式框架的架构](/media/dist-task/dist-task-architect.jpg) + +根据上图，分布式框架中任务的执行主要由以下模块负责： + +- Dispatcher：负责生成每个任务的分布式执行计划，管理执行过程，转换任务状态以及收集和反馈运行时任务信息等。 +- Scheduler：以 TiDB 节点为单位来同步分布式任务的执行，提高后端任务执行效率。 +- Subtask Executor：是实际的分布式子任务执行者，并将子任务的执行情况返回给 Scheduler，由 Scheduler 统一更新子任务的执行状态。 +- 资源池：通过对上述各种模块中计算资源进行池化，提供量化资源的使用与管理的基础。 + +## 另请参阅 + +* [DDL 执行原理及最佳实践](/ddl-introduction.md) diff --git a/tidb-in-kubernetes.md b/tidb-in-kubernetes.md index 1d57bcefcd5a..9dd20b4e3235 100644 --- a/tidb-in-kubernetes.md +++ b/tidb-in-kubernetes.md @@ -5,7 +5,7 @@ summary: 了解如何在 Kubernetes 上部署 TiDB # 在 Kubernetes 上部署 TiDB -你可以使用 [TiDB Operator](https://github.com/pingcap/tidb-operator) 在 Kubernetes 上部署 TiDB。TiDB Operator 是 Kubernetes 上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或私有部署的 Kubernetes 集群上。 +你可以使用 [TiDB Operator](https://github.com/pingcap/tidb-operator) 在 Kubernetes 上部署 TiDB。TiDB Operator 是 Kubernetes 上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或自托管的 Kubernetes 集群上。 TiDB Operator 的文档目前独立于 TiDB 文档。要查看如何在 Kubernetes 上部署 TiDB 的详细步骤，请参阅对应版本的 TiDB Operator 文档： diff --git a/tidb-lightning/data-import-best-practices.md b/tidb-lightning/data-import-best-practices.md new file mode 100644 index 000000000000..e062a741ef48 --- /dev/null +++ b/tidb-lightning/data-import-best-practices.md @@ -0,0 +1,156 @@ +--- +title: 50 TiB 数据导入最佳实践 +summary: 了解将大规模数据导入 TiDB 的最佳实践。 +--- + +# 50 TiB 数据导入最佳实践 + +本文提供了将大规模数据导入 TiDB 的最佳实践，包括影响数据导入的一些关键因素和操作步骤。PingCAP 在内部环境和客户现场都曾成功导入过 50 TiB 以上的大单表数据，基于这些真实的应用场景，沉淀了本文中的最佳实践，希望可以帮你更顺畅更高效地导入大规模数据。 + +TiDB Lightning（[物理导入模式](/tidb-lightning/tidb-lightning-physical-import-mode.md)）是一款用于将离线数据导入空表、空集群的高效的数据导入工具。TiDB Lightning 以文件作为数据源，提供了单实例和[并行导入](/tidb-lightning/tidb-lightning-distributed-import.md)两种运行方式，以满足不同规模的源文件导入。 + +- 如果源文件数据规模在 10 TiB 以内，建议通过单个 TiDB Lightning 实例进行导入。 +- 如果源文件数据规模超过 10 TiB，建议通过多个 TiDB Lightning 实例进行[并行导入](/tidb-lightning/tidb-lightning-distributed-import.md)。 +- 如果源文件数据规模特别大（比如达到 50 TiB 及以上），在使用并行导入的同时，还需要针对源数据特点、表定义、参数配置等进行一定的准备和调优，才能更好、更快地完成大规模的数据导入。 + +本文中的以下内容同时适用于导入多表和导入大单表： + +- [关键因素](#关键因素) +- [准备源文件](#准备源文件) +- [预估存储空间](#预估存储空间) +- [配置参数](#配置参数) +- [解决 "checksum mismatch" 问题](#解决-checksum-mismatch-问题) +- [开启断点续传](#开启断点续传) +- [故障处理](#故障处理) + +由于导入大单表有一些特殊要求，以下章节单独介绍了相关最佳实践： + +- [导入大单表的最佳实践](#导入大单表的最佳实践) + +## 关键因素 + +在导入大量数据时，以下关键因素会影响导入性能，甚至可能影响导入成败： + +- 源文件 + + - 单个文件内数据是否按照主键有序。有序可以达到最优导入性能。 + - 多个 TiDB Lightning 实例导入的源文件之间，是否存在重叠的主键或者非空唯一索引。重叠越少，导入性能越好。 + +- 表定义 + + - 每个表的二级索引数量、大小会影响导入速度。索引越少，导入越快，导入后占用空间越小。 + - 索引数据大小 = 索引数量 \* 索引大小 \* 数据行数。 + +- 压缩率 + + 数据导入 TiDB 集群后会被压缩存储，而压缩率无法预先计算，只有数据真正导入到 TiKV 集群后才能计算。可以先尝试导入少量数据（如 10%），获取到集群对应的压缩率，然后以此作为全部数据导入后的压缩率。 + +- 配置参数 + + 以下配置参数的设置也会影响导入性能： + + - `region-concurrency`：TiDB Lightning 主逻辑处理的并发度。 + - `send-kv-pairs`：TiDB Lightning 发送给 TiKV 单次请求中的 KV 数量。 + - `disk-quota`：使用物理导入模式时，配置 TiDB Lightning 本地临时文件使用的磁盘配额。 + - `GOMEMLIMIT`：TiDB Lightning 采用 Go 语言实现，需要[合理配置 `GOMEMLIMIT`](#配置参数)。 + + 关于 TiDB Lightning 参数信息，请参考 [TiDB Lightning 配置参数](/tidb-lightning/tidb-lightning-configuration.md)。 + +- 数据校验 + + 数据和索引导入完成后，会对每个表执行 [`ADMIN CHECKSUM`](/sql-statements/sql-statement-admin-checksum-table.md)，然后和 TiDB Lightning 本地的 Checksum 值做对比。当有很多表或单个表有很多行时，Checksum 阶段耗时会很长。 + +- Analyze 操作 + + Checksum 通过后，会对每个表执行 [`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)，构建最佳的执行计划。当有很多表或单个表很大时，Analyze 阶段耗时会很长。 + +- 相关 Issue + + 在实际导入 50 TiB 数据的过程中，存在一些在海量源文件及大规模集群下才会暴露出的问题。在选择产品版本时，请检查该版本是否已经修复了某些影响导入性能的 Issue。以下 Issue 在 v6.5.3、v7.1.0 及更新的版本中都已修复： + + - [Issue-14745](https://github.com/tikv/tikv/issues/14745)：导入完成后，TiKV Import 目录遗留大量临时文件。 + - [Issue-6426](https://github.com/tikv/pd/issues/6426)：PD [范围调度](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#导入时暂停-pd-调度的范围)接口存在未打散 Region 的情况，导致 Scatter Region 超时。v6.2.0 之前采用停止全局调度的方式，不会出现该问题。 + - [Issue-43079](https://github.com/pingcap/tidb/pull/43079)：TiDB Lightning 对 NotLeader 错误的重试未刷新 Region Peers 信息。 + - [Issue-43291](https://github.com/pingcap/tidb/issues/43291)：TiDB Lightning 未对临时文件删除的情况（"No such file or directory"）进行重试。 + +## 准备源文件 + +- 在生成文件时，在单个文件内尽量按照主键排序；如果表定义没有主键，可以添加一个自增主键，此时对文件内容顺序无要求。 +- 在给多个 TiDB Lightning 实例分配要导入的源文件时，尽量避免多个源文件之间存在重叠的主键或非空唯一索引的情况。如果生成文件是全局有序，可以按照范围划分不同的文件给不同 TiDB Lightning 实例进行导入，达到最佳导入效果。 +- 在生成文件时，每个文件尽量控制在 96 MiB 以下。 +- 如果文件特别大，超过 256 MiB，需要开启 [`strict-format`](/migrate-from-csv-files-to-tidb.md#第-4-步导入性能优化可选)。 + +## 预估存储空间 + +目前有以下两种有效的空间预估方法： + +- 假设数据总大小为 A，索引总大小为 B，副本数为 3，压缩率为 α（一般在 2.5 左右），则总的占用空间为：(A+B)\*3/α。该方法主要用于不进行任何数据导入时的估算，以此规划集群拓扑。 +- 预先导入 10% 的数据，实际占用空间再乘以 10，即可认为是该批数据最终的占用空间。该方法更加准确，尤其是对于导入大量数据时比较有效。 + +注意要预留 20% 的存储空间，后台任务如压缩、复制快照等会使用部分存储空间。 + +## 配置参数 + +需要正确设置以下配置参数： + +- `region-concurrency`：TiDB Lightning 主逻辑处理的并发度。在并行导入时，可以设置为 CPU 核数的 75%，防止出现资源过载带来 OOM 问题。 +- `send-kv-pairs`：TiDB Lightning 发送给 TiKV 单次请求中的 KV 数量。建议按照 send-kv-pairs \* row-size < 1 MiB 调整该值。v7.2.0 版本中，用 `send-kv-size` 代替了该参数，且无需单独设置。 +- `disk-quota`：尽量保证 TiDB Lightning 排序目录空间大于数据源大小。如无法保证，可以设置 `disk-quota` 为 TiDB Lightning 排序目录空间的 80%。此时 TiDB Lightning 会按照 `disk-quota` 的大小为一个批次去排序、写入，导入性能低于完整排序。 +- `GOMEMLIMIT`：TiDB Lightning 采用 Go 语言实现，设置 `GOMEMLIMIT` 为实例内存的 80%，降低因为 Go GC 机制带来的 OOM 概率。 + +关于 TiDB Lightning 参数信息，请参考 [TiDB Lightning 配置参数](/tidb-lightning/tidb-lightning-configuration.md)。 + +## 解决 "checksum mismatch" 问题 + +在数据校验过程中，可能会出现冲突数据，报错信息为："checksum mismatch"。出现该问题，可以按照以下思路解决： + +1. 排查源数据是否有主键、唯一键冲突，解决冲突后再重新导入。根据以往经验，主键和唯一键冲突是导致该报错的主要原因。 +2. 表的主键、唯一键定义是否合理。如果不合理，更改表定义后重新导入。 +3. 如果按上述两个步骤操作后仍未解决问题，需要进一步判断源数据中是否有少量（低于 10%）不可预期的冲突数据。如果需要 TiDB Lightning 帮助检测、解决冲突数据，需要开启[冲突检测功能](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#冲突数据检测)。 + +## 开启断点续传 + +大规模的数据导入，一定要参照[断点续传](/tidb-lightning/tidb-lightning-checkpoints.md)文档，开启断点续传，并推荐优先使用 MySQL 作为 Driver，避免因为 TiDB Lightning 运行在容器环境，容器退出后断点信息被一并删除。 + +如果导入过程中遇到下游 TiKV 空间不足，可以手动执行 `kill` 命令关闭（不要带 `-9` 选项）所有 TiDB Lightning 实例，待扩容后，基于断点信息继续导入。 + +## 导入大单表的最佳实践 + +多表导入会导致 Checksum、Analyze 时间的增加，甚至超过数据导入本身，但是一般不需要调整配置。如果多表中存在单个或多个大表的情况，可以把这类大表的源文件划分出来，单独进行导入。 + +本小节重点介绍大单表导入的最佳实践。大单表没有严格的定义，一般认为符合以下任一条件者即为大单表： + +- 大小超过 10 TiB +- 行数超过 10 亿、列数超过 50 的宽表 + +### 生成源文件 + +根据上述[准备源文件的步骤](#准备源文件)生成源文件，对于大单表，如果不能做到全局有序，但是可以做到文件内按主键有序，且是标准的 CSV 文件，可以尽量生成单个大文件（例如每个 20 GiB），然后开启 [`strict-format`](/migrate-from-csv-files-to-tidb.md#第-4-步导入性能优化可选)，既可以降低 TiDB Lightning 实例之间导入的数据文件中存在主键和唯一键的重叠，又能在导入前由 TiDB Lightning 实例对大文件进行切分，达到最佳的导入速度。 + +### 规划集群拓扑 + +按照每个 TiDB Lightning 实例处理 5 TiB 到 10 TiB 源数据进行准备，每个机器节点部署一个 TiDB Lightning 实例。机器节点规格可以参照 [TiDB Lightning 实例必要条件及限制](/tidb-lightning/tidb-lightning-physical-import-mode.md#必要条件及限制)。 + +### 调整配置参数 + +需要调整以下配置参数： + +- `region-concurrency` 设置为 TiDB Lightning 实例核数的 75%。 +- `send-kv-pairs` 设置为 `3200`。适用于 v7.1.0 及更早的版本。v7.2.0 开始引入了 `send-kv-size` 参数代替 `send-kv-pairs`，该参数无需配置。 +- `GOMEMLIMIT` 调整为实例所在节点内存的 80%。 + +如果导入过程中发现 PD Scatter Region 的时延超过 30 分钟，可以从以下维度进行调优： + +- 排查 TiKV 集群是否遇到 I/O 瓶颈。 +- 调高 TiKV `raftstore.apply-pool-size`，从默认值 `2` 调整为 `4` 或 `8`。 +- 降低 TiDB Lightning `region-split-concurrency` 为 CPU 核数的一半，最低可调整为 `1`。 + +### 关闭 Analyze 操作 + +当存在单个大表的情况，建议关闭 `analyze` (`analyze="off"`)。在导入结束后，再手动执行 [`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)。 + +关于 `analyze` 的相关配置，请参考 [TiDB Lightning 任务配置](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-任务配置)。 + +## 故障处理 + +如果在使用 TiDB Lightning 的过程中遇到问题，请参考 [TiDB Lightning 故障处理](/tidb-lightning/troubleshoot-tidb-lightning.md)。 diff --git a/tidb-lightning/deploy-tidb-lightning.md b/tidb-lightning/deploy-tidb-lightning.md index 0584d6b1c150..706be30ee866 100644 --- a/tidb-lightning/deploy-tidb-lightning.md +++ b/tidb-lightning/deploy-tidb-lightning.md @@ -8,8 +8,8 @@ aliases: ['/docs-cn/dev/tidb-lightning/deploy-tidb-lightning/','/docs-cn/dev/ref 本文主要介绍 TiDB Lightning 进行数据导入的硬件需求，以及手动部署 TiDB Lightning 的方式。Lightning 不同的导入模式，其硬件要求有所不同，请先阅读： -- [Physical Import Mode 必要条件及限制](/tidb-lightning/tidb-lightning-physical-import-mode.md#必要条件及限制) -- [Logical Import Mode 必要条件及限制](/tidb-lightning/tidb-lightning-logical-import-mode.md#必要条件) +- [物理导入模式必要条件及限制](/tidb-lightning/tidb-lightning-physical-import-mode.md#必要条件及限制) +- [逻辑导入模式必要条件及限制](/tidb-lightning/tidb-lightning-logical-import-mode.md#必要条件) ## 使用 TiUP 联网部署（推荐） diff --git a/tidb-lightning/tidb-lightning-command-line-full.md b/tidb-lightning/tidb-lightning-command-line-full.md index 60335ae2351c..14d040ca7e2d 100644 --- a/tidb-lightning/tidb-lightning-command-line-full.md +++ b/tidb-lightning/tidb-lightning-command-line-full.md @@ -20,7 +20,7 @@ summary: 使用命令行配置 TiDB Lightning。 | -d *directory* | 读取数据的本地目录或[外部存储 URI](/br/backup-and-restore-storages.md#uri-格式) | `mydumper.data-source-dir` | | -L *level* | 日志的等级： debug、info、warn、error 或 fatal (默认为 info) | `lightning.log-level` | | -f *rule* | [表库过滤的规则](/table-filter.md) (可多次指定) | `mydumper.filter` | -| --backend [*backend*](/tidb-lightning/tidb-lightning-overview.md) | 选择导入的模式：`local`为 Physical Import Mode，`tidb`为 Logical Import Mode | `local` | +| --backend [*backend*](/tidb-lightning/tidb-lightning-overview.md) | 选择导入的模式：`local` 为[物理导入模式](/tidb-lightning/tidb-lightning-physical-import-mode.md)，`tidb` 为[逻辑导入模式](/tidb-lightning/tidb-lightning-logical-import-mode.md) | `tikv-importer.backend` | | --log-file *file* | 日志文件路径（默认值为 `/tmp/lightning.log.{timestamp}`，设置为 '-' 表示日志输出到终端） | `lightning.log-file` | | --status-addr *ip:port* | TiDB Lightning 服务器的监听地址 | `lightning.status-port` | | --importer *host:port* | TiKV Importer 的地址 | `tikv-importer.addr` | diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index e8eac1b2fd78..20ae80926d8d 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -52,7 +52,7 @@ table-concurrency = 6 # 数据的并发数。默认与逻辑 CPU 的数量相同。 # 混合部署的情况下可以将其大小配置为逻辑 CPU 数的 75%，以限制 CPU 的使用。 -# region-concurrency = +# region-concurrency = # I/O 最大并发数。I/O 并发量太高时，会因硬盘内部缓存频繁被刷新 # 而增加 I/O 等待时间，导致缓存未命中和读取速度降低。 @@ -111,48 +111,87 @@ driver = "file" # keep-after-success = false [tikv-importer] -# "local"：Physical Import Mode，默认使用。适用于 TB 级以上大数据量，但导入期间下游 TiDB 无法对外提供服务。 -# "tidb"：Logical Import Mode。TB 级以下数据量可以采用，下游 TiDB 可正常提供服务。 +# "local"：物理导入模式（Physical Import Mode），默认使用。适用于 TB 级以上大数据量，但导入期间下游 TiDB 无法对外提供服务。 +# "tidb"：逻辑导入模式 (Logical Import Mode)。TB 级以下数据量可以采用，下游 TiDB 可正常提供服务。 # backend = "local" -# 是否允许启动多个 TiDB Lightning 实例（**physical import mode**）并行导入到一个或多个目标表。默认取值为 false。注意，这个参数**不是用于增量导入数据**，仅限目标表为空的场景使用。 -# 多个 TiDB Lightning 实例（physical import mode）同时导入一张表时，此开关必须设置为 true。但前提是目标表不能存在数据，即所有的数据都只能是由 TiDB Lightning 导入。 +# 是否允许启动多个 TiDB Lightning 实例（物理导入模式）并行导入数据到一个或多个目标表。默认取值为 false。 +# 注意，该参数**不是用于增量导入数据**，仅限目标表为空的场景使用。 +# 多个 TiDB Lightning 实例（物理导入模式）同时导入一张表时，此开关必须设置为 true。 +# 但前提是目标表不能存在数据，即所有的数据都只能是由 TiDB Lightning 导入。 # incremental-import = false # 当后端是 “importer” 时，tikv-importer 的监听地址（需改为实际地址）。 addr = "172.16.31.10:8287" -# Logical Import Mode 插入冲突数据时执行的操作。关于冲突检测详细信息请查阅：https://docs.pingcap.com/zh/tidb/dev/tidb-lightning-logical-import-mode-usage#冲突数据检测 +# 逻辑导入模式插入冲突数据时执行的操作。关于冲突检测详细信息请查阅：https://docs.pingcap.com/zh/tidb/dev/tidb-lightning-logical-import-mode-usage#冲突数据检测 # - replace：新数据替代已有数据 # - ignore：保留已有数据，忽略新数据 # - error：中止导入并报错 # on-duplicate = "replace" -# Physical Import Mode 设置是否检测和解决重复的记录（唯一键冲突）。 -# 目前支持三种解决方法： -# - record: 数据写入目标表后，将目标表中重复记录添加到目标 TiDB 中的 `lightning_task_info.conflict_error_v1` 表中。注意，该方法要求目标 TiKV 的版本为 v5.2.0 或更新版本。如果版本过低，则会启用下面的 'none' 模式。 -# - none: 不检测重复记录。该模式是三种模式中性能最佳的，但是如果数据源存在重复记录，会导致 TiDB 中出现数据不一致的情况。 -# - remove: 记录所有目标表中的重复记录，和 'record' 模式相似。但是会删除目标表所有的重复记录，以确保目标 TiDB 中的数据状态保持一致。 +# 物理导入模式设置是否检测和解决重复的记录（唯一键冲突）。 +# 目前支持两种解决方法： +# - none: 不检测重复记录。该模式是两种模式中性能最佳的，但是如果数据源存在重复记录，会导致 TiDB 中出现数据不一致的情况。 +# - remove：如果写入的数据 A 和 B 存在 Primary Key 或 Unique Key 冲突， +# 则会将 A 和 B 这两条冲突数据从目标表移除，同时记录到目标 TiDB 中的 `lightning_task_info.conflict_error_v1` 表中。 +# 你可以根据业务需求选择正确的记录重新手动写入到目标表中。注意，该方法要求目标 TiKV 的版本为 v5.2.0 或更新版本。 +# 如果版本过低，则会启用 'none' 模式。 +# 默认值为 'none'。 # duplicate-resolution = 'none' -# Physical Import Mode 一次请求中发送的 KV 数量。 +# 物理导入模式下，向 TiKV 发送数据时一次请求中最大 KV 数量。 +# 自 v7.2.0 开始，该参数废弃，设置后不再生效。如果希望调整一次请求中向 TiKV 发送的数据量，请使用 `send-kv-size` 参数。 # send-kv-pairs = 32768 -# Physical Import Mode 向 TiKV 发送 KV 时是否启用压缩。目前只支持 Gzip 压缩算法，可填写 "gzip" 或者 "gz"。默认不启用压缩。 +# 物理导入模式下，向 TiKV 发送数据时一次请求的最大大小。 +# 默认值为 "16K"，一般情况下不建议调整该参数。 +# 该参数自 v7.2.0 开始引入。 +# send-kv-size = "16K" +# 物理导入模式向 TiKV 发送 KV 时是否启用压缩。目前只支持 Gzip 压缩算法，可填写 "gzip" 或者 "gz"。默认不启用压缩。 # compress-kv-pairs = "" -# Physical Import Mode 本地进行 KV 排序的路径。如果磁盘性能较低（如使用机械盘），建议设置成与 `data-source-dir` 不同的磁盘，这样可有效提升导入性能。 +# 物理导入模式本地进行 KV 排序的路径。如果磁盘性能较低（如使用机械盘），建议设置成与 `data-source-dir` 不同的磁盘，这样可有效提升导入性能。 # sorted-kv-dir = "" -# Physical Import Mode TiKV 写入 KV 数据的并发度。当 TiDB Lightning 和 TiKV 直接网络传输速度超过万兆的时候，可以适当增加这个值。 +# 物理导入模式TiKV 写入 KV 数据的并发度。当 TiDB Lightning 和 TiKV 直接网络传输速度超过万兆的时候，可以适当增加这个值。 # range-concurrency = 16 -# Physical Import Mode 限制 TiDB Lightning 向每个 TiKV 节点写入的带宽大小，默认为 0，表示不限制。 +# 物理导入模式限制 TiDB Lightning 向每个 TiKV 节点写入的带宽大小，默认为 0，表示不限制。 # store-write-bwlimit = "128MiB" -# 使用 Physical Import Mode 时，配置 TiDB Lightning 本地临时文件使用的磁盘配额 (disk quota)。当磁盘配额不足时，TiDB Lightning 会暂停读取源数据以及写入临时文件的过程，优先将已经完成排序的 key-value 写入到 TiKV，TiDB Lightning 删除本地临时文件后，再继续导入过程。 +# 使用物理导入模式时，配置 TiDB Lightning 本地临时文件使用的磁盘配额 (disk quota)。 +# 当磁盘配额不足时，TiDB Lightning 会暂停读取源数据以及写入临时文件的过程， +# 优先将已经完成排序的 key-value 写入到 TiKV，TiDB Lightning 删除本地临时文件后，再继续导入过程。 # 需要同时配合把 `backend` 设置为 `local` 模式才能生效。 # 默认值为 MaxInt64 字节，即 9223372036854775807 字节。 -# disk-quota = "10GB" +# disk-quota = "10GB" -# Physical Import Mode 是否通过 SQL 方式添加索引。默认为 `false`，表示 TiDB Lightning 会将行数据以及索引数据都编码成 KV pairs 后一同导入 TiKV，实现机制和历史版本保持一致。如果设置为 `true`，即 TiDB Lightning 会在导入数据完成后，使用 add index 的 SQL 来添加索引。 +# 物理导入模式是否通过 SQL 方式添加索引。 +# 默认为 `false`，表示 TiDB Lightning 会将行数据以及索引数据都编码成 KV pairs 后一同导入 TiKV，实现机制和历史版本保持一致。 +# 如果设置为 `true`，即 TiDB Lightning 会在导入数据完成后，使用 add index 的 SQL 来添加索引。 # 通过 SQL 方式添加索引的优点是将导入数据与导入索引分开，可以快速导入数据，即使导入数据后，索引添加失败，也不会影响数据的一致性。 # add-index-by-sql = false -# 在使用 TiDB Lightning 导入多租户的 TiDB cluster 的场景下，指定对应的 key space 名称。默认取值为空字符串，表示 TiDB Lightning 会自动获取导入对应租户的 key space 名称；如果指定了值，则使用指定的 key space 名称来导入。 +# 在使用 TiDB Lightning 导入多租户的 TiDB cluster 的场景下，指定对应的 key space 名称。 +# 默认取值为空字符串，表示 TiDB Lightning 会自动获取导入对应租户的 key space 名称； +# 如果指定了值，则使用指定的 key space 名称来导入。 # keyspace-name = "" + +# 物理导入模式下，用于控制 TiDB Lightning 暂停 PD 调度的范围，可选值包括： +# - "table"：仅暂停目标表数据所在 Region 的调度。默认值为 "table"。 +# - "global"：暂停全局调度。当导入数据到无业务流量的集群时，建议设置为 "global"，以避免其他调度的干扰。 +# 该参数自 v7.1.0 版本开始引入。注意："table" 选项仅适用于 TiDB v6.1.0 及以上版本的目标集群。 +# pause-pd-scheduler-scope = "table" + +# 物理导入模式下，用于控制批量 Split Region 时的 Region 个数。 +# 每个 TiDB Lightning 实例最多同时 Split Region 的个数为： +# region-split-batch-size * region-split-concurrency * table-concurrency +# 该参数自 v7.1.0 版本开始引入，默认值为 `4096`。 +# region-split-batch-size = 4096 + +# 物理导入模式下，用于控制 Split Region 时的并发度。默认值为 CPU 核数。 +# 该参数自 v7.1.0 版本开始引入。 +# region-split-concurrency = + +# 物理导入模式下，用于控制 split 和 scatter 操作后等待 Region 上线的重试次数，默认值为 `1800`。 +# 重试符合指数回退策略，最大重试间隔为 2 秒。 +# 若两次重试之间有任何 Region 上线，该次操作不会被计为重试次数。 +# 该参数自 v7.1.0 版本开始引入。 +# region-check-backoff-limit = 1800 + [mydumper] # 设置文件读取的区块大小，确保该值比数据源的最长字符串长。 read-block-size = "64KiB" # 默认值 @@ -173,6 +212,7 @@ data-source-dir = "/data/my_database" # - utf8mb4：表结构文件必须使用 UTF-8 编码，否则会报错。 # - gb18030：表结构文件必须使用 GB-18030 编码，否则会报错。 # - auto：自动判断文件编码是 UTF-8 还是 GB-18030，两者皆非则会报错（默认）。 +# - latin1：源数据文件使用 MySQL latin1 字符集编码（也被称为 Code Page 1252）。 # - binary：不尝试转换编码。 character-set = "auto" @@ -181,6 +221,7 @@ character-set = "auto" # - utf8mb4：源数据文件使用 UTF-8 编码。 # - GB18030：源数据文件使用 GB-18030 编码。 # - GBK：源数据文件使用 GBK 编码（GBK 编码是对 GB-2312 字符集的拓展，也被称为 Code Page 936）。 +# - latin1：源数据文件使用 MySQL latin1 字符集编码（也被称为 Code Page 1252）。 # - binary：不尝试转换编码（默认）。 # 留空此配置将默认使用 "binary"，即不尝试转换编码。 # 需要注意的是，Lightning 不会对源数据文件的字符集做假定，仅会根据此配置对数据进行转码并导入。 @@ -201,7 +242,8 @@ data-invalid-char-replace = "\uFFFD" # 为保证数据安全而非追求处理速度，默认值为 false。 strict-format = false -# 如果 strict-format = true，TiDB Lightning 会将 CSV 大文件分割为多个文件块进行并行处理。max-region-size 是分割后每个文件块的最大大小。 +# 如果 strict-format = true，TiDB Lightning 会将 CSV 大文件分割为多个文件块进行并行处理。 +# max-region-size 是分割后每个文件块的最大大小。 # max-region-size = "256MiB" # 默认值 # 只导入与该通配符规则相匹配的表。详情见相应章节。 @@ -216,11 +258,14 @@ delimiter = '"' # 行尾定界字符，支持一个或多个字符。设置为空（默认值）表示 "\n"（换行）和 "\r\n" （回车+换行），均表示行尾。 terminator = "" # CSV 文件是否包含表头。 -# 如果 header = true，将把首行的内容作为表头处理，不作为数据导入。如果设置为 false，首行也作为 CSV 数据导入，此时请确保 CSV 文件的列顺序与目标表的列顺序一致，否则可能会导致数据差异。 +# 如果 header = true，将把首行的内容作为表头处理，不作为数据导入。如果设置为 false，首行也作为 CSV 数据导入， +# 此时请确保 CSV 文件的列顺序与目标表的列顺序一致，否则可能会导致数据差异。 header = true # CSV 表头是否匹配目标表的表结构。 -# 默认为 true，表示在导入数据时，会根据 CSV 表头的字段名去匹配目标表对应的列名，这样即使 CSV 文件和目标表列的顺序不一致也能按照对应的列名进行导入。 -# 如果 CSV 表头中的字段名和目标表的列名不匹配（例如，CSV 表头中的某些字段名在目标表中可能找不到对应的同名列）但列的顺序是一致的，请将该配置设置为 false。 +# 默认为 true，表示在导入数据时，会根据 CSV 表头的字段名去匹配目标表对应的列名， +# 这样即使 CSV 文件和目标表列的顺序不一致也能按照对应的列名进行导入。 +# 如果 CSV 表头中的字段名和目标表的列名不匹配（例如，CSV 表头中的某些字段名在目标表中可能找不到对应的同名列）但列的顺序是一致的， +# 请将该配置设置为 false。 # 这时，在导入的时候，会直接忽略 CSV 表头的内容，以避免导入错误。在这种情况下，直接把 CSV 数据按照目标表列的顺序导入。 # 因此，如果列的顺序不一致，请手动调整一致后再导入，否则可能会导致数据差异。 # 注意：只有在 header = true 时，该参数才会生效。如果 header = false ，表示 CSV 文件没有表头，此时不需要考虑相关列名匹配的问题。 @@ -289,10 +334,10 @@ max-allowed-packet = 67_108_864 # 此服务的私钥。默认为 `security.key-path` 的副本 # key-path = "/path/to/lightning.key" -# 对于 Physical Import Mode，数据导入完成后，TiDB Lightning 可以自动执行 Checksum 和 Analyze 操作。 +# 对于物理导入模式，数据导入完成后，TiDB Lightning 可以自动执行 Checksum 和 Analyze 操作。 # 在生产环境中，建议总是开启 Checksum 和 Analyze。 # 执行的顺序为：Checksum -> Analyze。 -# 注意：对于 Logical Import Mode, 无须执行这两个阶段，因此在实际运行时总是会直接跳过。 +# 注意：对于逻辑导入模式, 无须执行这两个阶段，因此在实际运行时总是会直接跳过。 [post-restore] # 配置是否在导入完成后对每一个表执行 `ADMIN CHECKSUM TABLE ` 操作来验证数据的完整性。 # 可选的配置项： @@ -318,7 +363,7 @@ switch-mode = "5m" # 在日志中打印导入进度的持续时间。 log-progress = "5m" -# 使用 Physical Import Mode 时，检查本地磁盘配额的时间间隔，默认为 60 秒。 +# 使用物理导入模式时，检查本地磁盘配额的时间间隔，默认为 60 秒。 # check-disk-quota = "60s" ``` @@ -335,7 +380,7 @@ log-progress = "5m" | -d *directory* | 读取数据的本地目录或[外部存储 URI](/br/backup-and-restore-storages.md#uri-格式) | `mydumper.data-source-dir` | | -L *level* | 日志的等级： debug、info、warn、error 或 fatal (默认为 info) | `lightning.log-level` | | -f *rule* | [表库过滤的规则](/table-filter.md) (可多次指定) | `mydumper.filter` | -| --backend [*backend*](/tidb-lightning/tidb-lightning-overview.md) | 选择导入的模式：`local`为 Physical Import Mode，`tidb`为 Logical Import Mode | `local` | +| --backend [*backend*](/tidb-lightning/tidb-lightning-overview.md) | 选择导入的模式：`local` 为物理导入模式，`tidb` 为逻辑导入模式 | `local` | | --log-file *file* | 日志文件路径（默认值为 `/tmp/lightning.log.{timestamp}`，设置为 '-' 表示日志输出到终端） | `lightning.log-file` | | --status-addr *ip:port* | TiDB Lightning 服务器的监听地址 | `lightning.status-port` | | --importer *host:port* | TiKV Importer 的地址 | `tikv-importer.addr` | diff --git a/tidb-lightning/tidb-lightning-data-source.md b/tidb-lightning/tidb-lightning-data-source.md index bfb4035f27d1..5bbcdadd1dac 100644 --- a/tidb-lightning/tidb-lightning-data-source.md +++ b/tidb-lightning/tidb-lightning-data-source.md @@ -88,13 +88,11 @@ trim-last-separator = false - 如果 `delimiter` 为空，所有字段都会被取消引用。 - 常用值： - * `'"'` 使用双引号引用字段，和 [RFC 4180] 一致。 + * `'"'` 使用双引号引用字段，和 [RFC 4180](https://tools.ietf.org/html/rfc4180) 一致。 * `''` 不引用 - 对应 LOAD DATA 语句中的 `FIELDS ENCLOSED BY` 项。 -参考 [RFC 4180](https://tools.ietf.org/html/rfc4180)。 - #### `terminator` - 指定行尾定界符。 diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md index c9370eccc5d1..edc423bb3071 100644 --- a/tidb-lightning/tidb-lightning-distributed-import.md +++ b/tidb-lightning/tidb-lightning-distributed-import.md @@ -5,7 +5,7 @@ summary: 本文档介绍了 TiDB Lightning 并行导入的概念、使用场景 # TiDB Lightning 并行导入 -TiDB Lightning 的 [Physical Import Mode](/tidb-lightning/tidb-lightning-physical-import-mode.md) 从 v5.3.0 版本开始支持单表或多表数据的并行导入。通过支持同步启动多个实例，并行导入不同的单表或多表的不同数据，使 TiDB Lightning 具备水平扩展的能力，可大大降低导入大量数据所需的时间。 +TiDB Lightning 的[物理导入模式](/tidb-lightning/tidb-lightning-physical-import-mode.md) 从 v5.3.0 版本开始支持单表或多表数据的并行导入。通过支持同步启动多个实例，并行导入不同的单表或多表的不同数据，使 TiDB Lightning 具备水平扩展的能力，可大大降低导入大量数据所需的时间。 在技术实现上，TiDB Lightning 通过在目标 TiDB 中记录各个实例以及每个导入表导入数据的元信息，协调不同实例的 Row ID 分配范围、全局 Checksum 的记录和 TiKV 及 PD 的配置变更与恢复。 @@ -18,9 +18,9 @@ TiDB Lightning 并行导入可以用于以下场景： > > - 并行导入只支持初始化 TiDB 的空表，不支持导入数据到已有业务写入的数据表，否则可能会导致数据不一致的情况。 > -> - 并行导入一般用于 Physical Import 模式，需要设置 `incremental-import = true` +> - 并行导入一般用于物理导入模式，需要设置 `incremental-import = true`。 > -> - 并行导入一般用于 Physical Import 模式；虽然也能用于 Logical Import 模式，但是一般不会带来明显的性能提升。 +> - 并行导入一般用于物理导入模式；虽然也能用于逻辑导入模式，但是一般不会带来明显的性能提升。 ## 使用说明 @@ -33,7 +33,7 @@ TiDB Lightning 并行导入可以用于以下场景： ### 解决主键或者唯一索引的冲突 -在使用 [Physical Import Mode](/tidb-lightning/tidb-lightning-physical-import-mode.md) 并行导入时，需要确保多个 TiDB Lightning 的数据源之间，以及它们和 TiDB 的目标表中的数据没有主键或者唯一索引的冲突，并且导入的目标表不能有其他应用进行数据写入。否则，TiDB Lightning 将无法保证导入结果的正确性，并且导入完成后相关的数据表将处于数据索引不一致的状态。 +在使用[物理导入模式](/tidb-lightning/tidb-lightning-physical-import-mode.md)并行导入时，需要确保多个 TiDB Lightning 的数据源之间，以及它们和 TiDB 的目标表中的数据没有主键或者唯一索引的冲突，并且导入的目标表不能有其他应用进行数据写入。否则，TiDB Lightning 将无法保证导入结果的正确性，并且导入完成后相关的数据表将处于数据索引不一致的状态。 ### 导入性能优化 @@ -96,8 +96,8 @@ data-source-dir = "/path/to/source-dir" # 是否允许向已存在数据的表导入数据。默认值为 false。 # 当使用并行导入模式时，由于多个 TiDB Lightning 实例同时导入一张表，因此此开关必须设置为 true。 incremental-import = true -# "local"：Physical Import Mode，默认使用。适用于 TB 级以上大数据量，但导入期间下游 TiDB 无法对外提供服务。 -# "tidb"：Logical Import Mode。TB 级以下数据量也可以采用，下游 TiDB 可正常提供服务。 +# "local"：物理导入模式，默认使用。适用于 TB 级以上大数据量，但导入期间下游 TiDB 无法对外提供服务。 +# "tidb"：逻辑导入模式。TB 级以下数据量也可以采用，下游 TiDB 可正常提供服务。 backend = "local" # 设置本地排序数据的路径 @@ -188,11 +188,19 @@ incremental-import = true 在并行导入过程中，如果一个或多个 TiDB Lightning 节点异常终止，需要首先根据日志中的报错明确异常退出的原因，然后根据错误类型做不同处理： -1. 如果是正常退出(如手动 Kill 等)，或内存溢出被操作系统终止等，可以在适当调整配置后直接重启 TiDB Lightning，无须任何其他操作。 +- 如果是正常退出，例如手动 Kill 或内存溢出被操作系统终止等，可以在适当调整配置后直接重启 TiDB Lightning，无须任何其他操作。 -2. 如果是不影响数据正确性的报错，如网络超时，可以在每一个失败的节点上使用 tidb-lightning-ctl 工具清除断点续传源数据中记录的错误，然后重启这些异常的节点，从断点位置继续导入，详见 [checkpoint-error-ignore](/tidb-lightning/tidb-lightning-checkpoints.md#--checkpoint-error-ignore)。 +- 如果是不影响数据正确性的报错，例如网络超时，请按以下步骤解决： -3. 如果是影响数据正确性的报错，如 checksum mismatched，表示源文件中有非法的数据，则需要在每一个失败的节点上使用 tidb-lightning-ctl 工具，清除失败的表中已导入的数据及断点续传相关的源数据，详见 [checkpoint-error-destroy](/tidb-lightning/tidb-lightning-checkpoints.md#--checkpoint-error-destroy)。此命令会删除下游导入失败表中已导入的数据，因此，应在所有 TiDB Lightning 节点（包括任务正常结束的）重新配置和导入失败的表的数据，可以配置 filters 参数只导入报错失败的表。 + 1. 在每一个失败的节点上，执行 [checkpoint-error-ignore](/tidb-lightning/tidb-lightning-checkpoints.md#--checkpoint-error-ignore) 命令，值设置为 `all`，以清除断点续传源数据中记录的错误。 + + 2. 重启这些异常的节点，从断点位置继续导入。 + +- 如果在日志中看到影响数据正确性的报错，如 checksum mismatched，表示源文件中有非法的数据，请按以下步骤解决： + + 1. 在每一个 Lightning 节点（包括成功导入数据的节点）上执行 [checkpoint-error-destroy](/tidb-lightning/tidb-lightning-checkpoints.md#--checkpoint-error-destroy) 命令，以清除失败的表中已导入的数据，并将这些表的 checkpoint 状态重置为 "not yet started"。 + + 2. 使用 [`filter`](/table-filter.md) 参数在所有 TiDB Lightning 节点（包括任务正常结束的节点）上重新配置和导入失败表的数据。重新配置任务时，不要将 checkpoint-error-destroy 命令放在每一个 Lightning 节点的启动脚本中，否则会删除多个并行导入任务使用的共享元数据，可能会导致数据导入过程出现问题。例如，如果启动了第二个 Lightning 导入任务，它将删除第一个数据导入任务写入的元数据，导致数据导入异常。 ### 导入过程中报错 "Target table is calculating checksum. Please wait until the checksum is finished and try again" diff --git a/tidb-lightning/tidb-lightning-error-resolution.md b/tidb-lightning/tidb-lightning-error-resolution.md index c6b9b057ddba..a0cd4dbc7180 100644 --- a/tidb-lightning/tidb-lightning-error-resolution.md +++ b/tidb-lightning/tidb-lightning-error-resolution.md @@ -43,7 +43,7 @@ max-error = 0 * 原始 CSV、SQL 或者 Parquet 文件中的语法错误，例如未闭合的引号 * I/O、网络、或系统权限错误 -在 Physical Import Mode 下，唯一键/主键的冲突是单独处理的。相关内容将在接下来的章节进行介绍。 +在物理导入模式下，唯一键/主键的冲突是单独处理的。相关内容将在接下来的章节进行介绍。 ## 错误报告 diff --git a/tidb-lightning/tidb-lightning-faq.md b/tidb-lightning/tidb-lightning-faq.md index 5b9e47435e2f..201a058c8c6d 100644 --- a/tidb-lightning/tidb-lightning-faq.md +++ b/tidb-lightning/tidb-lightning-faq.md @@ -79,16 +79,18 @@ ADMIN CHECKSUM TABLE `schema`.`table`; 自 v5.1 起，TiDB Lightning 可以自动识别下游的库和表。如果你使用低于 v5.1 的 TiDB Lightning，需在配置文档中的 `[mydumper]` 部分将 `no-schema` 设置为 `true` 即可。`no-schema=true` 会默认下游已经创建好所需的数据库和表，如果没有创建，会报错。 -## 有些不合法的数据，能否通过关掉严格 SQL 模式 (Strict SQL Mode) 来导入？ +## 如何禁止导入不合规的数据？ -可以。TiDB Lightning 默认的 [`sql_mode`](https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html) 为 `"STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"`。 +可以通过开启严格 SQL 模式 (Strict SQL Mode) 来实现。 -这个设置不允许一些非法的数值，例如 `1970-00-00` 这样的日期。可以修改配置文件 `[tidb]` 下的 `sql-mode` 值。 +TiDB Lightning 默认的 [`sql_mode`](https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html) 为 `"ONLY_FULL_GROUP_BY,NO_AUTO_CREATE_USER"`，允许导入某些不合规的数值，例如 `1970-00-00` 这样的日期。 + +如果要禁止导入不合规的数据，需要修改配置文件 `[tidb]` 下的 `sql-mode` 值为 `"STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"`。 ```toml ... [tidb] -sql-mode = "" +sql-mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION" ... ``` @@ -110,7 +112,7 @@ sql-mode = "" 使用 TiDB Lightning 的 SST Mode 建议配置万兆网卡。 -千兆网卡的总带宽只有 120 MB/s，而且需要与整个 TiKV 集群共享。在使用 TiDB Lightning Physical Import Mode 导入时，极易用尽所有带宽，继而因 PD 无法联络集群使集群断连。 +千兆网卡的总带宽只有 120 MB/s，而且需要与整个 TiKV 集群共享。在使用 TiDB Lightning 物理导入模式导入时，极易用尽所有带宽，继而因 PD 无法联络集群使集群断连。 ## 为什么 TiDB Lightning 需要在 TiKV 集群预留这么多空间？ diff --git a/tidb-lightning/tidb-lightning-glossary.md b/tidb-lightning/tidb-lightning-glossary.md index 7a3ad677d4ee..cca0d7d1dd64 100644 --- a/tidb-lightning/tidb-lightning-glossary.md +++ b/tidb-lightning/tidb-lightning-glossary.md @@ -16,13 +16,13 @@ aliases: ['/docs-cn/dev/tidb-lightning/tidb-lightning-glossary/','/docs-cn/dev/r 统计信息分析。指重建 TiDB 表中的统计信息，即运行 [`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md) 语句。 -因为 TiDB Lightning local backend 直接导入数据到 TiKV，统计信息不会自动更新，所以 TiDB Lightning 在导入后显式地分析每个表。如果不需要该操作，可以将 `post-restore.analyze` 设置为 `false`。 +因为 TiDB Lightning 物理导入模式直接导入数据到 TiKV，统计信息不会自动更新，所以 TiDB Lightning 在导入后显式地分析每个表。如果不需要该操作，可以将 `post-restore.analyze` 设置为 `false`。 ### `AUTO_INCREMENT_ID` 用于为自增列分配默认值的自增 ID 计数器。每张表都有一个相关联的 `AUTO_INCREMENT_ID` 计数器。在 TiDB 中，该计数器还用于分配行 ID。 -因为 TiDB Lightning local backend 直接导入数据到 TiKV，`AUTO_INCREMENT_ID` 计数器不会自动更新，所以 TiDB Lightning 显式地将 `AUTO_INCREMENT_ID` 改为一个有效值。即使表中没有自增列，这步仍是会执行。 +因为 TiDB Lightning 物理导入模式直接导入数据到 TiKV，`AUTO_INCREMENT_ID` 计数器不会自动更新，所以 TiDB Lightning 显式地将 `AUTO_INCREMENT_ID` 改为一个有效值。即使表中没有自增列，这步仍是会执行。 diff --git a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md index 7525af3e4b98..586236568702 100644 --- a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md +++ b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md @@ -1,15 +1,15 @@ --- -title: 使用 Logical Import Mode -summary: 了解在 TiDB Lightning 的 Logical Import Mode 下，如何编写数据导入任务的配置文件，如何进行性能调优等。 +title: 使用逻辑导入模式 +summary: 了解在 TiDB Lightning 的逻辑导入模式下，如何编写数据导入任务的配置文件，如何进行性能调优等。 --- -# 使用 Logical Import Mode +# 使用逻辑导入模式 -本文档介绍如何编写 [Logical Import Mode](/tidb-lightning/tidb-lightning-logical-import-mode.md) 的配置文件，如何进行性能调优等内容。 +本文档介绍如何编写[逻辑导入模式](/tidb-lightning/tidb-lightning-logical-import-mode.md)的配置文件，如何进行性能调优等内容。 ## 配置及使用 -可以通过以下配置文件使用 Logical Import Mode 执行数据导入： +可以通过以下配置文件使用逻辑导入模式执行数据导入： ```toml [lightning] @@ -28,10 +28,10 @@ check-requirements = true data-source-dir = "/data/my_database" [tikv-importer] -# 导入模式配置，设为 tidb 即使用 Logical Import Mode +# 导入模式配置，设为 tidb 即使用逻辑导入模式 backend = "tidb" -# Logical Import Mode 插入重复数据时执行的操作。 +# 逻辑导入模式插入重复数据时执行的操作。 # - replace：新数据替代已有数据 # - ignore：保留已有数据，忽略新数据 # - error：中止导入并报错 @@ -53,7 +53,7 @@ TiDB Lightning 的完整配置文件可参考[完整配置及命令行参数](/t ## 冲突数据检测 -冲突数据，即两条或两条以上的记录存在主键或唯一键列数据重复的情况。当数据源中的记录存在冲突数据，将导致该表真实总行数和使用唯一索引查询的总行数不一致的情况。TiDB Lightning 的 Logical Import Mode 通过 `on-duplicate` 配置冲突数据检测的策略，TiDB Lightning 根据策略使用不同的 SQL 语句进行插入。 +冲突数据，即两条或两条以上的记录存在主键或唯一键列数据重复的情况。当数据源中的记录存在冲突数据，将导致该表真实总行数和使用唯一索引查询的总行数不一致的情况。TiDB Lightning 的逻辑导入模式通过 `on-duplicate` 配置冲突数据检测的策略，TiDB Lightning 根据策略使用不同的 SQL 语句进行插入。 | 策略 | 冲突时默认行为 | 对应 SQL 语句 | |:---|:---|:---| @@ -63,9 +63,9 @@ TiDB Lightning 的完整配置文件可参考[完整配置及命令行参数](/t ## 性能调优 -- TiDB Lightning 的 Logical Import Mode 性能很大程度上取决于目标 TiDB 集群的写入性能，当遇到性能瓶颈时可参考 TiDB 相关[性能优化文档](/best-practices/high-concurrency-best-practices.md)。 +- TiDB Lightning 的逻辑导入模式性能很大程度上取决于目标 TiDB 集群的写入性能，当遇到性能瓶颈时可参考 TiDB 相关[性能优化文档](/best-practices/high-concurrency-best-practices.md)。 -- 如果发现目标 TiDB 集群的的写入尚未达到瓶颈，可以考虑增加 Lightning 配置中 `region-concurrency` 的值。`region-concurrency` 默认值为 CPU 核数，其含义在 Physical Import Mode 和 Logical Import Mode 下有所不同，Logical Import Mode 的 `region-concurrency` 表示写入并发数。配置示例： +- 如果发现目标 TiDB 集群的的写入尚未达到瓶颈，可以考虑增加 Lightning 配置中 `region-concurrency` 的值。`region-concurrency` 默认值为 CPU 核数，其含义在物理导入模式和逻辑导入模式下有所不同，逻辑导入模式的 `region-concurrency` 表示写入并发数。配置示例： ```toml [lightning] diff --git a/tidb-lightning/tidb-lightning-logical-import-mode.md b/tidb-lightning/tidb-lightning-logical-import-mode.md index ae5771ea95d8..73b6fb3635c2 100644 --- a/tidb-lightning/tidb-lightning-logical-import-mode.md +++ b/tidb-lightning/tidb-lightning-logical-import-mode.md @@ -1,13 +1,13 @@ --- -title: Logical Import Mode -summary: 了解 TiDB Lightning 的 Logical Import Mode。 +title: 逻辑导入模式简介 +summary: 了解 TiDB Lightning 的逻辑导入模式 (Logical Import Mode)。 --- -# Logical Import Mode 简介 +# 逻辑导入模式简介 -Logical Import Mode 是 TiDB Lightning 支持的一种数据导入方式。在 Logical Import Mode 下，TiDB Lightning 先将数据编码成 SQL，然后直接运行这些 SQL 语句进行数据导入。对于已有数据、对外提供服务的 TiDB 集群，推荐使用 Logical Import Mode 导入数据。Logical Import Mode 的行为与正常执行 SQL 并无差异，可保证 ACID。 +逻辑导入模式 (Logical Import Mode) 是 TiDB Lightning 支持的一种数据导入方式。在逻辑导入模式下，TiDB Lightning 先将数据编码成 SQL，然后直接运行这些 SQL 语句进行数据导入。对于已有数据、对外提供服务的 TiDB 集群，推荐使用逻辑导入模式导入数据。逻辑导入模式的行为与正常执行 SQL 并无差异，可保证 ACID。 -Logical Import Mode 对应的后端模式为 `tidb`。 +逻辑导入模式对应的后端模式为 `tidb`。 ## 必要条件 @@ -17,10 +17,10 @@ Logical Import Mode 对应的后端模式为 `tidb`。 **内存和 CPU**： -建议使用 4 核以上的 CPU 和 8 GiB 以上内存以获得更好的性能。根据长期的实践经验，Lightning 的 Logical Import Mode 没有显著（5 GiB 以上）的内存占用，但上调 `region-concurrency` 默认值将导致内存量增加。 +建议使用 4 核以上的 CPU 和 8 GiB 以上内存以获得更好的性能。根据长期的实践经验，TiDB Lightning 的逻辑导入模式没有显著（5 GiB 以上）的内存占用，但上调 `region-concurrency` 默认值将导致内存量增加。 **网络**：建议使用 1 Gbps 或 10 Gbps 以太网卡。 ## 使用限制 -使用多个 TiDB Lightning 向同一目标导入时，请勿混用不同的 backend，即不可同时使用 Physical Import Mode 和 Logical Import Mode 导入同一 TiDB 集群。 +使用多个 TiDB Lightning 向同一目标导入时，请勿混用不同的 backend，即不可同时使用物理导入模式和逻辑导入模式导入同一 TiDB 集群。 diff --git a/tidb-lightning/tidb-lightning-overview.md b/tidb-lightning/tidb-lightning-overview.md index c64a246b8ac6..a05868224f5d 100644 --- a/tidb-lightning/tidb-lightning-overview.md +++ b/tidb-lightning/tidb-lightning-overview.md @@ -30,11 +30,11 @@ TiDB Lightning 支持从以下位置读取： TiDB Lightning 目前支持两种导入方式，通过 `backend` 配置区分。不同的模式决定 TiDB Lightning 如何将数据导入到目标 TiDB 集群。 -- [Physical Import Mode](/tidb-lightning/tidb-lightning-physical-import-mode.md)：TiDB Lightning 首先将数据编码成键值对并排序存储在本地临时目录，然后将这些键值对上传到各个 TiKV 节点，最后调用 TiKV Ingest 接口将数据插入到 TiKV 的 RocksDB 中。如果用于初始化导入，请优先考虑使用 Physical Import Mode，其拥有较高的导入速度。Physical Import Mode 对应的后端模式为 `local`。 +- [物理导入模式](/tidb-lightning/tidb-lightning-physical-import-mode.md)：TiDB Lightning 首先将数据编码成键值对并排序存储在本地临时目录，然后将这些键值对上传到各个 TiKV 节点，最后调用 TiKV Ingest 接口将数据插入到 TiKV 的 RocksDB 中。如果用于初始化导入，请优先考虑使用物理导入模式，其拥有较高的导入速度。物理导入模式对应的后端模式为 `local`。 -- [Logical Import Mode](/tidb-lightning/tidb-lightning-logical-import-mode.md)：TiDB Lightning 先将数据编码成 SQL，然后直接运行这些 SQL 语句进行数据导入。如果需要导入的集群为生产环境线上集群，或需要导入的目标表中已包含有数据，则应使用 Logical Import Mode。Logical Import Mode 对应的后端模式为 `tidb`。 +- [逻辑导入模式](/tidb-lightning/tidb-lightning-logical-import-mode.md)：TiDB Lightning 先将数据编码成 SQL，然后直接运行这些 SQL 语句进行数据导入。如果需要导入的集群为生产环境线上集群，或需要导入的目标表中已包含有数据，则应使用逻辑导入模式。逻辑导入模式对应的后端模式为 `tidb`。 -| 导入模式 | Physical Import Mode | Logical Import Mode | +| 导入模式 | 物理导入模式 | 逻辑导入模式 | |:---|:---|:---| | 后端 | `local` | `tidb` | | 速度 | 快 (100 ~ 500 GiB/小时) | 慢 (10 ~ 50 GiB/小时) | diff --git a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md index e3076ed66894..cf99144e845e 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md @@ -1,15 +1,15 @@ --- -title: 使用 Physical Import Mode -summary: 了解如何使用 TiDB Lightning 的 Physical Import Mode。 +title: 使用物理导入模式 +summary: 了解如何使用 TiDB Lightning 的物理导入模式。 --- -# 使用 Physical Import Mode +# 使用物理导入模式 -本文档介绍如何编写 [Physical Import Mode](/tidb-lightning/tidb-lightning-physical-import-mode.md) 的配置文件，如何进行性能调优、使用磁盘资源配额等内容。 +本文档介绍如何编写[物理导入模式](/tidb-lightning/tidb-lightning-physical-import-mode.md) 的配置文件，如何进行性能调优、使用磁盘资源配额等内容。 ## 配置及使用 -可以通过以下配置文件使用 Physical Import Mode 执行数据导入： +可以通过以下配置文件使用物理导入模式执行数据导入： ```toml [lightning] @@ -28,7 +28,7 @@ check-requirements = true data-source-dir = "/data/my_database" [tikv-importer] -# 导入模式配置，设为 local 即使用 Physical Import Mode +# 导入模式配置，设为 local 即使用物理导入模式 backend = "local" # 冲突数据处理方式 @@ -40,7 +40,7 @@ sorted-kv-dir = "./some-dir" # 限制 TiDB Lightning 向每个 TiKV 节点写入的带宽大小，默认为 0，表示不限制。 # store-write-bwlimit = "128MiB" -# Physical Import Mode 是否通过 SQL 方式添加索引。默认为 `false`，表示 TiDB Lightning 会将行数据以及索引数据都编码成 KV pairs 后一同导入 TiKV，实现机制和历史版本保持一致。如果设置为 `true`，即 TiDB Lightning 会导完数据后，再使用 add index 的 SQL 来添加索引。 +# 物理导入模式是否通过 SQL 方式添加索引。默认为 `false`，表示 TiDB Lightning 会将行数据以及索引数据都编码成 KV pairs 后一同导入 TiKV，实现机制和历史版本保持一致。如果设置为 `true`，即 TiDB Lightning 会导完数据后，再使用 add index 的 SQL 来添加索引。 # 通过 SQL 方式添加索引的优点是将导入数据与导入索引分开，可以快速导入数据，即使导入数据后，索引添加失败，也不会影响数据的一致性。 # add-index-by-sql = false @@ -130,10 +130,12 @@ mysql> select table_name,index_name,key_data,row_data from conflict_error_v1 lim 根据上述信息人工甄别需要保留的重复数据，手动插回原表即可。 -## 导入时限制调度范围从集群降低到表级别 +## 导入时暂停 PD 调度的范围 自 TiDB Lightning v6.2.0 版本起，TiDB Lightning 提供机制控制导入数据过程对在线业务的影响。TiDB Lightning 不会暂停全局的调度，而是只暂停目标表数据范围所在 region 的调度，降低了对在线业务的影响。 +自 TiDB v7.1.0 版本起，你可以通过 TiDB Lightning 的参数 [`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md) 来控制暂停调度的范围。默认为 `"table"`，即只暂停目标表数据所在 Region 的调度。当集群没有业务流量时，建议设置为 `"global"` 以减少来自调度器对导入的干扰。 + > **注意：** > > TiDB Lightning 不支持导入数据到已有业务写入的数据表。 @@ -174,12 +176,12 @@ switch-mode = '0' ## 性能调优 -**提高 Lightning Physical Import Mode 导入性能最直接有效的方法：** +**提高 Lightning 物理导入模式导入性能最直接有效的方法：** - **升级 Lightning 所在节点的硬件，尤其重要的是 CPU 和 sorted-key-dir 所在存储设备的性能。** - **使用[并行导入](/tidb-lightning/tidb-lightning-distributed-import.md)特性实现水平扩展。** -当然，Lightning 也提供了部分并发相关配置以影响 Physical Import Mode 的导入性能。但是从长期实践的经验总结来看，以下四个配置项一般保持默认值即可，调整其数值并不会带来显著的性能提升，可作为了解内容阅读。 +当然，Lightning 也提供了部分并发相关配置以影响物理导入模式的导入性能。但是从长期实践的经验总结来看，以下四个配置项一般保持默认值即可，调整其数值并不会带来显著的性能提升，可作为了解内容阅读。 ``` [lightning] diff --git a/tidb-lightning/tidb-lightning-physical-import-mode.md b/tidb-lightning/tidb-lightning-physical-import-mode.md index f32d6c270742..c54171af4e79 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode.md @@ -1,24 +1,27 @@ --- -title: Physical Import Mode -summary: 了解 TiDB Lightning 的 Physical Import Mode。 +title: 物理导入模式 +summary: 了解 TiDB Lightning 的物理导入模式。 --- -# Physical Import Mode 简介 +# 物理导入模式简介 -Physical Import Mode 是 TiDB Lightning 支持的一种数据导入方式。Physical Import Mode 不经过 SQL 接口，而是直接将数据以键值对的形式插入 TiKV 节点，是一种高效、快速的导入模式。Physical Import Mode 适合导入最高 100 TB 数据量，使用前请务必自行阅读[必要条件及限制](/tidb-lightning/tidb-lightning-physical-import-mode.md#必要条件及限制)。 +物理导入模式 (Physical Import Mode) 是 TiDB Lightning 支持的一种数据导入方式。物理导入模式不经过 SQL 接口，而是直接将数据以键值对的形式插入 TiKV 节点，是一种高效、快速的导入模式。使用物理导入模式时，单个 TiDB Lightning 实例可导入的数据量为 10 TiB，理论上导入的数据量可以随着 TiDB Lightning 实例数量的增加而增加，目前已经有多个用户验证基于[并行导入](/tidb-lightning/tidb-lightning-distributed-import.md)功能可以导入的数据量达 20 TiB。 -Physical Import Mode 对应的后端模式为 `local`。 +使用前请务必自行阅读[必要条件及限制](/tidb-lightning/tidb-lightning-physical-import-mode.md#必要条件及限制)。 + +物理导入模式对应的后端模式为 `local`。 ## 原理说明 -1. 在导入数据之前，`tidb-lightning` 会自动将 TiKV 节点切换为“导入模式” (import mode)，优化写入效率并停止自动压缩。`tidb-lightning` 会根据 TiDB 集群的版本决定是否停止全局调度。 +1. 在导入数据之前，`tidb-lightning` 会自动将 TiKV 节点切换为“导入模式” (import mode)，优化写入效率并停止自动压缩。以下为各版本的 TiDB Lightning 决定暂停调度的策略： - - 当 TiDB 集群版本 >= v6.1.0 且 TiDB Lightning 版本 >= v6.2.0 时，`tidb-lightning` 在向 TiKV 导入数据时，只会暂停目标表数据范围所在 region 的调度，并在目标表导入完成后恢复调度。 - - 当 TiDB 集群版本 < v6.1.0 或 TiDB Lightning 版本 < v6.2.0 时，`tidb-lightning` 会暂停全局调度。 + - 自 v7.1.0 开始，你可以通过 [`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md) 来控制是否暂停全局调度。 + - v6.2.0 ~ v7.0.0 版本的 TiDB Lightning 会根据 TiDB 集群的版本决定是否暂停全局调度。当 TiDB 集群版本 >= v6.1.0，只会暂停目标表数据范围所在 Region 的调度，并在目标表导入完成后恢复调度。其他版本则会暂停全局调度。 + - 当 TiDB Lightning 版本 < v6.2.0 时，`tidb-lightning` 会暂停全局调度。 2. `tidb-lightning` 在目标数据库建立表结构，并获取其元数据。 - 如果将 `add-index-by-sql` 设置为 `true`，`tidb-lightning` 会使用 SQL 接口添加索引，并且会在导入数据前移除目标表的所有次级索引。 + 如果将 `add-index-by-sql` 设置为 `true`，`tidb-lightning` 会使用 SQL 接口添加索引，并且会在导入数据前移除目标表的所有次级索引。默认值为 `false`，和历史版本保持一致。 3. 每张表都会被分割为多个连续的**区块**，这样来自大表 (200 GB+) 的数据就可以多个并发导入。 @@ -26,7 +29,7 @@ Physical Import Mode 对应的后端模式为 `local`。 5. 当一个引擎文件数据写入完毕时，`tidb-lightning` 便开始对目标 TiKV 集群数据进行分裂和调度，然后导入数据到 TiKV 集群。 - 引擎文件包含两种：**数据引擎**与**索引引擎**，各自又对应两种键值对：行数据和次级索引。通常行数据在数据源里是完全有序的，而次级索引是无序的。因此，数据引擎文件在对应区块写入完成后会被立即上传，而所有的索引引擎文件只有在整张表所有区块编码完成后才会执行导入。 + 引擎文件包含两种：**数据引擎**与**索引引擎**，各自又对应两种键值对：行数据和次级索引。通常行数据在数据源里是完全有序的，而次级索引是无序的。因此，数据引擎文件在对应区块写入完成后会被立即上传，而所有的索引引擎文件只有在整张表所有区块编码完成后才会执行导入。 注意当 `tidb-lightning` 使用 SQL 接口添加索引时（即 `add-index-by-sql` 设置为 `true`），索引引擎将不会写入数据，因为此时目标表的次级索引已经在第 2 步中被移除。 @@ -62,13 +65,13 @@ Physical Import Mode 对应的后端模式为 `local`。 ### 使用限制 -- 请勿直接使用 Physical Import Mode 向已经投入生产的 TiDB 集群导入数据，这将对在线业务产生严重影响。如需向生产集群导入数据，请参考[导入时限制调度范围从集群降低到表级别](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#导入时限制调度范围从集群降低到表级别)。 +- 请勿直接使用物理导入模式向已经投入生产的 TiDB 集群导入数据，这将对在线业务产生严重影响。如需向生产集群导入数据，请参考[导入时限制调度范围从集群降低到表级别](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#导入时暂停-pd-调度的范围)。 - 默认情况下，不应同时启动多个 TiDB Lightning 实例向同一 TiDB 集群导入数据，而应考虑使用[并行导入](/tidb-lightning/tidb-lightning-distributed-import.md)特性。 -- 使用多个 TiDB Lightning 向同一目标导入时，请勿混用不同的 backend，即不可同时使用 Physical Import Mode 和 Logical Import Mode 导入同一 TiDB 集群。 +- 使用多个 TiDB Lightning 向同一目标导入时，请勿混用不同的 backend，即不可同时使用物理导入模式和逻辑导入模式导入同一 TiDB 集群。 -- 在导入数据的过程中，请勿在目标表进行写操作，否则会导致导入失败或数据不一致。导入期间也不建议进行读操作，因为读取的数据可能不一致。请在导入操作完成后再进行读写操作。 +- 在导入数据的过程中，请勿在目标表进行 DDL 和 DML 操作，否则会导致导入失败或数据不一致。导入期间也不建议进行读操作，因为读取的数据可能不一致。请在导入操作完成后再进行读写操作。 - 单个 Lightning 进程导入单表不应超过 10 TB。使用并行导入时，Lightning 实例不应超过 10 个。 @@ -84,4 +87,4 @@ Physical Import Mode 对应的后端模式为 `local`。 - TiDB Lightning 与 TiCDC 一起使用时需要注意： - - TiCDC 无法捕获 Physical Import Mode 插入的数据。 \ No newline at end of file + - TiCDC 无法捕获物理导入模式插入的数据。 diff --git a/tidb-lightning/tidb-lightning-prechecks.md b/tidb-lightning/tidb-lightning-prechecks.md index 4df18c1a5e64..8df903a7cfaf 100644 --- a/tidb-lightning/tidb-lightning-prechecks.md +++ b/tidb-lightning/tidb-lightning-prechecks.md @@ -11,9 +11,9 @@ summary: 本文档介绍了 TiDB Lightning 前置检查功能，确保 TiDB Ligh | 检查项 | 支持版本 | 解释 | | ---- | --- | ---- | -| 集群版本/状态是否正常| >= 5.3.0 | 检查配置中集群是否可以连接，Physical Import Mode 还会检查 TiKV/PD/TiFlash 版本是否支持。| +| 集群版本/状态是否正常| >= 5.3.0 | 检查配置中集群是否可以连接，物理导入模式还会检查 TiKV/PD/TiFlash 版本是否支持。| | 是否有权限读取数据 | >= 5.3.0 | 检查当从云存储（Amazon S3）读取数据的时候，是否有对应的权限，确保不会因权限缺失导致导入中断。| -| 导入空间是否足够 | >= 5.3.0 | 检查 TiKV 集群是否有足够空间导入数据。检查时会对数据源进行采样，通过采样结果预估索引大小占比。由于估算中考虑了索引，因此可能会出现尽管数据源大小低于本地盘可用空间，但依然无法通过检测的情况。Physical Import Mode 因为需要在本地进行外部排序，所以还会检查本地存储是否足够。有关 TiKV 集群空间和本地存储（即 `sort-kv-dir` 配置）空间大小的详细说明，参考 [TiDB Lightning 下游数据库所需空间](/tidb-lightning/tidb-lightning-requirements.md#目标数据库所需空间)和 [TiDB Lightning 运行时资源要求](/tidb-lightning/tidb-lightning-physical-import-mode.md#运行环境需求)| +| 导入空间是否足够 | >= 5.3.0 | 检查 TiKV 集群是否有足够空间导入数据。检查时会对数据源进行采样，通过采样结果预估索引大小占比。由于估算中考虑了索引，因此可能会出现尽管数据源大小低于本地盘可用空间，但依然无法通过检测的情况。物理导入模式因为需要在本地进行外部排序，所以还会检查本地存储是否足够。有关 TiKV 集群空间和本地存储（即 `sort-kv-dir` 配置）空间大小的详细说明，参考 [TiDB Lightning 下游数据库所需空间](/tidb-lightning/tidb-lightning-requirements.md#目标数据库所需空间)和 [TiDB Lightning 运行时资源要求](/tidb-lightning/tidb-lightning-physical-import-mode.md#运行环境需求)| | Region 分布状态 | >= 5.3.0 | 检查 TiKV 集群的 Region 分布是否均匀，以及是否存在大量空 region，如果空 Region 的数量大于 `max(1000, 表的数量 * 3)`，即大于 "1000" 和 "3 倍表数量"二者中的较大者，TiDB Lightning 无法执行导入。 | | 数据文件是否有大 CSV 文件 | >= 5.3.0 | 当备份文件中出现大于 10 GiB 的 CSV 文件且无法进行自动切分 (StrictFormat=false) 的时候，会导致导入性能下降。该检查的目的是提醒用户确保数据格式的情况下，开启自动切分 CSV 功能。 | | 是否可以从断点恢复 | >= 5.3.0 | 该检查是确保断点恢复过程中，不会出现对源文件和数据库中 schema 进行修改，导致导入错误数据的情况。| diff --git a/tidb-lightning/tidb-lightning-requirements.md b/tidb-lightning/tidb-lightning-requirements.md index 11d46943d272..d1defe6c9bb8 100644 --- a/tidb-lightning/tidb-lightning-requirements.md +++ b/tidb-lightning/tidb-lightning-requirements.md @@ -33,13 +33,13 @@ TiDB Lightning 导入数据时，根据导入方式和启用特性等，需要 - + - + diff --git a/tidb-limitations.md b/tidb-limitations.md index 3b7582c0ba8b..59e0f3b2c907 100644 --- a/tidb-limitations.md +++ b/tidb-limitations.md @@ -20,7 +20,7 @@ aliases: ['/docs-cn/dev/tidb-limitations/'] ## Databases、Tables、Views、Connections 总个数限制 -| 标识符类型 | 最大个数 | +| 类型 | 最大个数 | |:----------|:----------| | Databases | unlimited | | Tables | unlimited | @@ -52,12 +52,6 @@ aliases: ['/docs-cn/dev/tidb-limitations/'] |:----------|:----------| | Size | 默认为 6 MiB，可通过 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-从-v50-版本开始引入) 配置项调至 120 MiB | -## 单列的限制 - -| 类型 | 最大限制（默认值） | -|:----------|:----------| -| Size | 默认为 6 MiB，可通过 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-从-v50-版本开始引入) 配置项调至 120 MiB | - ## 数据类型限制 | 类型 | 最大限制 | diff --git a/tidb-monitoring-api.md b/tidb-monitoring-api.md index eb6605d5230f..b4cfef34cc7c 100644 --- a/tidb-monitoring-api.md +++ b/tidb-monitoring-api.md @@ -32,7 +32,7 @@ curl http://127.0.0.1:10080/status ``` { connections: 0, # 当前 TiDB Server 上的客户端连接数 - version: "5.7.25-TiDB-v4.0.0-rc-141-g7267747ae", # TiDB 版本号 + version: "5.7.25-TiDB-v7.2.0", # TiDB 版本号 git_hash: "7267747ae0ec624dffc3fdedb00f1ed36e10284b" # TiDB 当前代码的 Git Hash } ``` diff --git a/tidb-operator-overview.md b/tidb-operator-overview.md index c602b5c4c3c3..8335ba7b2928 100644 --- a/tidb-operator-overview.md +++ b/tidb-operator-overview.md @@ -5,7 +5,7 @@ summary: 了解 Kubernetes 上的 TiDB 集群自动部署运维工具 TiDB Opera # TiDB Operator -[TiDB Operator](https://github.com/pingcap/tidb-operator) 是 Kubernetes 上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或私有部署的 Kubernetes 集群上。 +[TiDB Operator](https://github.com/pingcap/tidb-operator) 是 Kubernetes 上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或自托管的 Kubernetes 集群上。 TiDB Operator 的文档目前独立于 TiDB 文档，文档名称为 **TiDB on Kubernetes 用户文档**。要访问 TiDB Operator 的文档，请点击以下链接： diff --git a/tidb-resource-control.md b/tidb-resource-control.md index d4fb17de587b..997a115f4b05 100644 --- a/tidb-resource-control.md +++ b/tidb-resource-control.md @@ -5,13 +5,9 @@ summary: 介绍如何通过资源管控能力来实现对应用资源消耗的 # 使用资源管控 (Resource Control) 实现资源隔离 -> **警告：** -> -> 资源管控是 TiDB 在 v7.0.0 是实验特性，其语法或者行为表现在 GA 前可能会发生变化。 +使用资源管控特性，集群管理员可以定义资源组 (Resource Group)，通过资源组限定配额。 -使用资源管控特性，集群管理员可以定义资源组 (Resource Group)，通过资源组限定读写的配额。 - -TiDB 资源管控特性提供了两层资源管理能力，包括在 TiDB 层的流控能力和 TiKV 层的优先级调度的能力。两个能力可以单独或者同时开启，详情请参见[参数组合效果表](#相关参数)。将用户绑定到某个资源组后，TiDB 层会根据用户所绑定资源组设定的读写配额对用户的读写请求做流控，TiKV 层会根据读写配额映射的优先级来对请求做调度。通过流控和调度这两层控制，可以实现应用的资源隔离，满足服务质量 (QoS) 要求。 +TiDB 资源管控特性提供了两层资源管理能力，包括在 TiDB 层的流控能力和 TiKV 层的优先级调度的能力。两个能力可以单独或者同时开启，详情请参见[参数组合效果表](#相关参数)。将用户绑定到某个资源组后，TiDB 层会根据用户所绑定资源组设定的配额对用户的读写请求做流控，TiKV 层会根据配额映射的优先级来对请求做调度。通过流控和调度这两层控制，可以实现应用的资源隔离，满足服务质量 (QoS) 要求。 - TiDB 流控：TiDB 流控使用[令牌桶算法](https://en.wikipedia.org/wiki/Token_bucket) 做流控。如果桶内令牌数不够，而且资源组没有指定 `BURSTABLE` 特性，属于该资源组的请求会等待令牌桶回填令牌并重试，重试可能会超时失败。 - TiKV 调度：你可以为资源组设置绝对优先级 ([`PRIORITY`](/information-schema/information-schema-resource-groups.md#示例))，不同的资源按照 `PRIORITY` 的设置进行调度，`PRIORITY` 高的任务会被优先调度。如果没有设置绝对优先级 (`PRIORITY`)，TiKV 会将资源组的 `RU_PER_SEC` 取值映射成各自资源组读写请求的优先级，并基于各自的优先级在存储层使用优先级队列调度处理请求。 @@ -22,6 +18,8 @@ TiDB 资源管控特性提供了两层资源管理能力，包括在 TiDB 层的 - 你可以将多个来自不同系统的中小型应用合入一个 TiDB 集群中，个别应用的负载升高，不会影响其他业务的正常运行。而在系统负载较低的时候，繁忙的应用即使超过设定的读写配额，也仍然可以被分配到所需的系统资源，达到资源的最大化利用。 - 你可以选择将所有测试环境合入一个集群，或者将消耗较大的批量任务编入一个单独的资源组，在保证重要应用获得必要资源的同时，提升硬件利用率，降低运行成本。 +- 当系统中存在多种业务负载时，可以将不同的负载分别放入各自的资源组。利用资源管控技术，确保交易类业务的响应时间不受数据分析或批量业务的影响。 +- 当集群遇到突发的 SQL 性能问题，可以结合 SQL Binding 和资源组，临时限制某个 SQL 的资源消耗。 此外，合理利用资源管控特性可以减少集群数量，降低运维难度及管理成本。 @@ -34,30 +32,57 @@ TiDB 资源管控特性提供了两层资源管理能力，包括在 TiDB 层的 ## 什么是 Request Unit (RU) -Request Unit (RU) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的单位, 目前包括 CPU、IOPS 和 IO 带宽三个指标。这三个指标的消耗会按照一定的比例统一到 RU 单位上。 - -下表是用户请求对 TiKV 存储层 CPU 和 IO 资源的消耗以及对应的 RU 权重： +Request Unit (RU) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的计量单位，用于表示对数据库的单个请求消耗的资源量。请求消耗的 RU 数量取决于多种因素，例如操作类型或正在检索或修改的数据量。目前，RU 包含以下资源的统计信息： + +
必需Logical Import Mode逻辑导入模式 information_schema.columns SELECT
Physical Import Mode物理导入模式 mysql.tidb SELECT
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
资源类型RU 消耗
Read2 storage read batches 消耗 1 RU
8 storage read requests 消耗 1 RU
64 KiB read request payload 消耗 1 RU
Write1 storage write batch 消耗 1 RU * 副本数
1 storage write request 消耗 1 RU
1 KiB write request payload 消耗 1 RU
SQL CPU 3 ms 消耗 1 RU
-| 资源 | RU 权重 | -|:-----------|:-------------| -| CPU | 1/3 RU / 毫秒 | -| 读 IO | 1/64 RU / KB | -| 写 IO | 1 RU / KB | -| 一次读请求的基本开销 | 0.25 RU | -| 一次写请求的基本开销 | 1.5 RU | - -基于上表，假设某个资源组消耗的 TiKV 时间是 `c` 毫秒，`r1` 次请求读取了 `r2` KB 数据，`w1` 次写请求写入了 `w2` KB 数据，集群中非 witness TiKV 节点数是 `n`，则该资源组消耗的总 RU 的公式如下： - -`c`\* 1/3 + (`r1` \* 0.25 + `r2` \* 1/64) + (`w1` \* 1.5 + `w2` \* 1 \* `n`) +> **注意：** +> +> - 每个写操作最终都被会复制到所有副本（TiKV 默认 3 个数据副本），并且每次复制都被认为是一个不同的写操作。 +> - 除了用户执行的查询之外，RU 还可以被后台任务消耗，例如自动统计信息收集。 +> - 上表只列举了本地部署的 TiDB 计算 RU 时涉及的相关资源，其中不包括网络和存储部分。TiDB Serverless 的 RU 可参考 [TiDB Serverless Pricing Details](https://www.pingcap.com/tidb-cloud-serverless-pricing-details/)。 ## 相关参数 资源管控特性引入了两个新的全局开关变量： -- TiDB: 通过配置全局变量 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-从-v660-版本开始引入) 控制是否打开资源组流控。 -- TiKV: 通过配置参数 [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) 控制是否使用基于资源组配额的请求调度。 +- TiDB：通过配置全局变量 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-从-v660-版本开始引入) 控制是否打开资源组流控。 +- TiKV：通过配置参数 [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) 控制是否使用基于资源组配额的请求调度。 -这两个参数的组合效果见下表： +从 v7.0.0 开始，两个开关都被默认打开。这两个参数的组合效果见下表： | `resource-control.enabled` | `tidb_enable_resource_control`= ON | `tidb_enable_resource_control`= OFF | |:----------------------------|:-----------------------------------|:------------------------------------| @@ -68,13 +93,24 @@ Request Unit (RU) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的单位, ## 使用方法 +下面介绍如何使用资源管控特性。 + +### 预估集群容量 + +在进行资源规划之前，你需要了解集群的整体容量。TiDB 提供了命令 [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md) 用来估算集群容量。目前提供两种估算方式： + +- [根据实际负载估算容量](/sql-statements/sql-statement-calibrate-resource.md#根据实际负载估算容量) +- [基于硬件部署估算容量](/sql-statements/sql-statement-calibrate-resource.md#基于硬件部署估算容量) + +可通过 [TiDB Dashboard 资源管控页面](/dashboard/dashboard-resource-manager.md)进行查看。详情请参考 [`CALIBRATE RESOURCE` 预估方式](/sql-statements/sql-statement-calibrate-resource.md#预估方式)。 + ### 管理资源组 创建、修改、删除资源组，需要拥有 `SUPER` 或者 `RESOURCE_GROUP_ADMIN` 权限。 你可以通过 [`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md) 在集群中创建资源组。 -对于已有的资源组，可以通过 [`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md) 修改资源组的读写配额，对资源组的配额修改会立即生效。 +对于已有的资源组，可以通过 [`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md) 修改资源组的配额，对资源组的配额修改会立即生效。 可以使用 [`DROP RESOURCE GROUP`](/sql-statements/sql-statement-drop-resource-group.md) 删除资源组。 @@ -82,7 +118,7 @@ Request Unit (RU) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的单位, 下面举例说明如何创建资源组。 -1. 创建 `rg1` 资源组，RU 的回填速度是每秒 500 RU，并且允许这个资源组的应用超额占用资源。 +1. 创建 `rg1` 资源组，限额是每秒 500 RU，并且允许这个资源组的应用超额占用资源。 ```sql CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 BURSTABLE; @@ -104,9 +140,9 @@ Request Unit (RU) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的单位, TiDB 支持如下三个级别的资源组设置： -- 用户级别。通过 [`CREATE USER`](/sql-statements/sql-statement-create-user.md) 或 [`ALTER USER`](/sql-statements/sql-statement-alter-user.md) 语句将用户绑定到特定的资源组。绑定后，对应的用户新创建的会话会自动绑定对应的资源组。 +- 用户级别。通过 [`CREATE USER`](/sql-statements/sql-statement-create-user.md) 或 [`ALTER USER`](/sql-statements/sql-statement-alter-user.md#修改用户绑定的资源组) 语句将用户绑定到特定的资源组。绑定后，对应的用户新创建的会话会自动绑定对应的资源组。 - 会话级别。通过 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md) 设置当前会话使用的资源组。 -- 语句级别。通过 [`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name) 设置当前语句使用的资源组。 +- 语句级别。通过 [`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name) Optimizer Hint 设置当前语句使用的资源组。 #### 将用户绑定到资源组 @@ -151,6 +187,113 @@ SET RESOURCE GROUP rg1; SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10; ``` +### 管理资源消耗超出预期的查询 (Runaway Queries) + +> **警告：** +> +> 该功能目前为实验特性，不建议在生产环境中使用。该功能可能会在未事先通知的情况下发生变化或删除。如果发现 bug，请在 GitHub 上提 [issue](https://github.com/pingcap/tidb/issues) 反馈。 + +Runaway Queries 指那些执行时间或者消耗的资源超出预期的查询。自 v7.2.0 起，TiDB 资源管控引入了对 Runaway Queries 的管理。你可以针对某个资源组设置条件来识别 Runaway Queries，并自动发起应对操作，防止集群资源完全被 Runaway Queries 占用而影响其他正常查询。 + +你可以通过在 [`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md) 或者 [`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md) 中配置 `QUERY_LIMIT` 字段，管理资源组的 Runaway Queries。 + +#### `QUERY_LIMIT` 参数说明 + +支持的条件设置： + +- `EXEC_ELAPSED`: 当查询执行的时间超限时，识别为 Runaway Query。 + +支持的应对操作 (`ACTION`)： + +- `DRYRUN`：对执行 Query 不做任何操作，仅记录识别的 Runaway Query。主要用于观测设置条件是否合理。 +- `COOLDOWN`：将查询的执行优先级降到最低，查询仍旧会以低优先级继续执行，不占用其他操作的资源。 +- `KILL`：识别到的查询将被自动终止，报错 `Query execution was interrupted, identified as runaway query`。 + +为了避免并发的 Runaway Queries 太多，在被条件识别前就将系统资源耗尽，资源管控引入了一个快速识别的机制。借助子句 `WATCH`，当某一个查询被识别为 Runaway Query 之后，在接下来的一段时间里（通过 `DURATION` 定义） ，当前 TiDB 实例会将匹配到的查询直接标记为 Runaway Query，而不再等待其被条件识别，并按照当前应对操作执行。其中 `KILL` 操作报错 `Quarantined and interrupted because of being in runaway watch list`。 + +`WATCH` 有两种匹配方式： + +- `EXACT` 表示完全相同的 SQL 才会被快速识别 +- `SIMILAR` 表示会忽略字面值 (Literal)，通过 Plan Digest 匹配所有模式 (Pattern) 相同的 SQL + +`QUERY_LIMIT` 具体格式如下： + +| 参数 | 含义 | 备注 | +|---------------|--------------|--------------------------------------| +| `EXEC_ELAPSED` | 当查询执行时间超过该值后被识别为 Runaway Query | EXEC_ELAPSED =`60s` 表示查询的执行时间超过 60 秒则被认为是 Runaway Query。 | +| `ACTION` | 当识别到 Runaway Query 时进行的动作 | 可选值有 `DRYRUN`，`COOLDOWN`，`KILL`。 | +| `WATCH` | 快速匹配已经识别到的 Runaway Query，即在一定时间内再碰到相同或相似查询直接进行相应动作 | 可选项，配置例如 `WATCH=SIMILAR DURATION '60s'`、`WATCH=EXACT DURATION '1m'`。 | + +#### 示例 + +1. 创建 `rg1` 资源组，限额是每秒 500 RU，并且定义超过 60 秒为 Runaway Query，并对 Runaway Query 降低优先级执行。 + + ```sql + CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=COOLDOWN); + ``` + +2. 修改 `rg1` 资源组，对 Runaway Query 直接终止，并且在接下来的 10 分钟里，把相同模式的查询直接标记为 Runaway Query。 + + ```sql + ALTER RESOURCE GROUP rg1 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=SIMILAR DURATION='10m'); + ``` + +3. 修改 `rg1` 资源组，取消 Runaway Queries 检查。 + + ```sql + ALTER RESOURCE GROUP rg1 QUERY_LIMIT=NULL; + ``` + +#### 可观测性 + +可以通过以下系统表获得 Runaway 相关的更多信息： + ++ `mysql.tidb_runaway_queries` 表中包含了过去 7 天内所有识别到的 Runaway Queries 的历史记录。以其中一行为例： + + ```sql + MySQL [(none)]> SELECT * FROM mysql.tidb_runaway_queries LIMIT 1\G; + *************************** 1. row *************************** + resource_group_name: rg1 + time: 2023-06-16 17:40:22 + match_type: identify + action: kill + original_sql: select * from sbtest.sbtest1 + plan_digest: 5b7d445c5756a16f910192ad449c02348656a5e9d2aa61615e6049afbc4a82e + tidb_server: 127.0.0.1:4000 + ``` + + 其中，`match_type` 为该 Runaway Query 的来源，其值如下： + + - `identify` 表示命中条件。 + - `watch` 表示被快速识别机制命中。 + ++ `mysql.tidb_runaway_quarantined_watch` 表中包含了 Runaway Queries 的快速识别规则记录。以其中两行为例： + + ```sql + MySQL [(none)]> SELECT * FROM mysql.tidb_runaway_quarantined_watch LIMIT 2\G; + *************************** 1. row *************************** + resource_group_name: rg1 + start_time: 2023-06-16 17:40:22 + end_time: 2023-06-16 18:10:22 + watch: similar + watch_text: 5b7d445c5756a16f910192ad449c02348656a5e9d2aa61615e6049afbc4a82e + tidb_server: 127.0.0.1:4000 + *************************** 2. row *************************** + resource_group_name: rg1 + start_time: 2023-06-16 17:42:35 + end_time: 2023-06-16 18:12:35 + watch: exact + watch_text: select * from sbtest.sbtest1 + tidb_server: 127.0.0.1:4000 + ``` + + 其中： + + - `start_time` 和 `end_time` 表示该快速识别规则有效的时间范围。 + - `watch` 表示被快速识别机制命中，其值如下： + - `similar` 表示按照 Plan Digest 匹配，此时列 `watch_text` 显示的是 Plan Digest。 + - `exact` 表示按照 SQL 文本匹配，此时列 `watch_text` 显示的是 SQL 文本。 + ## 关闭资源管控特性 1. 执行以下命令关闭资源管控特性： @@ -163,13 +306,29 @@ SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10; ## 监控与图表 -TiDB 会定时采集资源管控的运行时信息，并在 Grafana 的 **Resource Control Dashboard** 中提供了相关指标的可视化图表。指标详情参见 [Resource Control 监控指标详解](/grafana-resource-control-dashboard.md) 。 +TiDB 会定时采集资源管控的运行时信息，并在 Grafana 的 **Resource Control Dashboard** 中提供了相关指标的可视化图表，详见 [Resource Control 监控指标详解](/grafana-resource-control-dashboard.md)。 -TiKV 中也记录了来自于不同资源组的请求 QPS，详见 [TiKV监控指标详解](/grafana-tikv-dashboard.md#grpc) +TiKV 中也记录了来自于不同资源组的请求 QPS，详见 [TiKV 监控指标详解](/grafana-tikv-dashboard.md#grpc)。 + +TiDB Dashboard 中可以查看当前 [`RESOURCE_GROUPS`](/information-schema/information-schema-resource-groups.md) 表中资源组的数据。详见 [TiDB Dashboard 资源管控页面](/dashboard/dashboard-resource-manager.md)。 ## 工具兼容性 -资源管控目前为实验特性，不影响数据导入导出以及其他同步工具的正常使用，BR、TiDB Lightning、TiCDC 等工具不支持对资源管控相关 DDL 的处理，这些工具的资源消耗也不受资源管控的限制。 +资源管控不影响数据导入导出以及其他同步工具的正常使用，BR、TiDB Lightning、TiCDC 等工具不支持对资源管控相关 DDL 的处理，这些工具的资源消耗也不受资源管控的限制。 + +## 常见问题 + +1. 如果我暂时不想使用资源组对资源进行管控，是否一定要关闭这个特性？ + + 不需要。没有指定任何资源组的用户，将被放入系统预定义的 `default` 资源组，而 `default` 资源组默认拥有无限用量。当所有用户都属于 `default` 资源组时，资源分配方式与关闭资源管控时相同。 + +2. 一个数据库用户是否可以绑定到不同的资源组？ + + 不能。一个数据库用户只能绑定到一个资源组。但是，在会话运行的过程中，可以通过 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md) 设置当前会话使用的资源组。你也可以通过优化器 [`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name) Hint 为运行的语句设置资源组。 + +3. 当各个资源组设置的用量 (`RU_PER_SEC`) 总和超出系统容量会发生什么？ + + TiDB 在创建资源组时不会检查容量。只要系统有足够的空闲资源，TiDB 就会满足每个资源组的用量设置。当系统资源超过限制时，TiDB 会优先满足高优先级 (PRIORITY) 资源组的请求。如果同一优先级的请求无法全部满足，TiDB 会根据用量 (`RU_PER_SEC`) 的大小按比例分配。 ## 另请参阅 diff --git a/tidb-roadmap.md b/tidb-roadmap.md new file mode 100644 index 000000000000..2a8f7d8252b7 --- /dev/null +++ b/tidb-roadmap.md @@ -0,0 +1,261 @@ +--- +title: TiDB 路线图 +summary: 了解 TiDB 未来的发展方向，包括新特性和改进提升。 +--- + +# TiDB 路线图 + +TiDB 路线图展示了 TiDB 未来的计划。随着我们发布长期稳定版本 (LTS)，这个路线图将会持续更新。通过路线图，你可以预先了解 TiDB 的未来规划，以便你关注进度，了解关键里程碑，并对开发工作提出反馈。 + +在开发过程中，路线图可能会根据用户需求和反馈进行调整。越靠右侧的特性，其优先级越低。如果你有功能需求，或者想提高某个特性的优先级，请在 [GitHub](https://github.com/pingcap/tidb/issues) 上提交 issue。 + +## TiDB 重要特性规划 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
类别2023 年底 LTS 版本2024 年中 LTS 版本未来版本
+ 可扩展性与性能
增强性能 + 		+
    +
  • + 分区 Raft KV 存储引擎 GA
    支持 PB 级别的集群，提升写入速度、扩缩容操作速度，提升数据整理的稳定性 +
    • +
    +
  • + 增强副本读取功能
    降低 TiKV 跨可用区的数据传输成本 +
    • +
    +
+ 		+
    +
  • + 引入性能优化框架，适用于所有相关后台任务，如 DDL、TTL 和集群分析操作
    + 性能优化框架将这些后台任务的工作负载分散到整个集群中，从而提升性能，并减少各个节点上的资源消耗。该框架已经应用于 ADD INDEX 操作。 +
    • +
    +
  • + TiFlash 存算分离架构、基于 S3 的 TiFlash 存储引擎等功能 GA
    + 实现更具成本效益的弹性 HTAP +
    • +
+ 		+
    +
  • + 移除事务大小的限制 +
    • +
+
+ 稳定性与高可用 +
提升可靠性 + 		+
    +
  • + 后台任务支持资源管控
    + 控制后台任务（如数据导入、DDL、TTL、自动分析、数据整理等操作）对前台流量的影响 +
    • +
+ 		+
    +
  • + 多租户 +
    基于资源管控实现资源隔离 +
    • +
+ 		+
    +
  • + 增强 TiDB 内存管理 +
    • +
+
+ SQL 功能 +
增强 SQL 功能和兼容性 + 		+
    +
  • + 兼容 MySQL 8.0 +
    • +
    +
  • + 为数据导入、备份恢复、PITR 提供统一的 SQL 接口 +
    • +
+ 		+
    +
  • + 优化器支持 Cascades 框架 +
    改进查询优化框架，让优化器更具可扩展性，适应未来的需求 +
    • +
    +
+ 		+
    +
  • + 联邦查询 +
    • +
    +
  • + 全文搜索和 GIS 支持 +
    • +
    +
  • + 用户自定义函数 +
    • +
    +
+
+ 数据库管理与可观测性 +
增强数据库可管理性及其生态系统 + 		+
    +
  • + TiCDC 支持分布式同步单表数据 +
    大幅提高 TiDB 到 TiDB 的数据吞吐量 +
    • +
    +
  • + 升级期间自动暂停/恢复 DDL +
    提供平滑的升级体验 +
    • +
    +
  • + TiCDC 原生集成大数据生态 +
    例如集成 Snowflake 和 Iceburg +
    • +
+ 		+
    +
  • + TiCDC 支持多个上游数据源 +
    支持从多个 TiDB 集群到 TiCDC (N:1) +
    • +
+ 		+
    +
  • + AI 索引 +
    • +
    +
  • + 支持迁移异构数据库 +
    • +
    +
  • + 使用 AI 赋能 SQL 性能优化 +
    • +
+
+ 安全 +
增强数据安全与隐私保护 + 		+
    +
  • + 通过 Azure Key Vault 进行密钥管理 +
    由 Azure Key Vault 管理的静态加密 +
    • +
    +
  • + 列级访问控制 +
    允许针对特定列来授予或限制访问权限 +
    • +
    +
  • + 数据库级别的加密 +
    支持配置数据库级别的静态加密 +
    • +
+ 		+
    +
  • + AWS IAM 身份验证 +
    将 TiDB 作为 AWS 第三方 ARN，用于 AWS IAM 访问 +
    • +
    +
  • + 统一的 TLS CA/密钥轮换策略 +
    统一管理所有 TiDB 组件的证书 +
    • +
+ 		+
    +
  • + 基于标签的访问控制 +
    通过配置标签来授予访问权限 +
    • +
  • + 增强客户端加密 +
    • +
    +
  • + 增强数据脱敏 +
    • +
    +
  • + 增强数据生命周期管理 +
    • +
+
+ +上述表格中并未列出所有功能，当前规划可能会调整。不同的服务订阅版本中的功能可能有所不同。 + +## 已发布特性 + +以下是历史版本路线图中已交付的部分功能。更多详细信息，请参阅 [v7.1.0 Release Notes](/releases/release-7.1.0.md)。 + +- 多租户框架的基础：资源组的资源管控配额和调度 +- TiCDC 支持对象存储 sink，包括 Amazon S3 和 Azure Blob Storage (GA) +- 最快的在线添加索引 `ADD INDEX` 操作 (GA) +- TiFlash 延迟物化 (GA) +- TiFlash 支持数据落盘 (GA) +- LDAP 身份认证 +- SQL 审计日志增强（仅企业版可用） +- 分区 Raft KV 存储引擎（实验特性） +- 通用的会话级别执行计划缓存（实验特性） +- TiCDC 支持以 Kafka 为下游的分布式表级别数据同步（实验特性） + +## 已发布版本 + +- [TiDB 7.2.0 Release Notes](/releases/release-7.2.0.md) +- [TiDB 7.1.0 Release Notes](/releases/release-7.1.0.md) +- [TiDB 7.0.0 Release Notes](/releases/release-7.0.0.md) +- [TiDB 6.6.0 Release Notes](/releases/release-6.6.0.md) +- [TiDB 6.5.0 Release Notes](/releases/release-6.5.0.md) diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index c453fd3e5877..45dd9777dce1 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -479,7 +479,7 @@ TiDB 支持完整的分布式事务，自 v3.0 版本起，提供乐观事务与 ### 6.3 TiDB Lightning 问题 -- 6.3.1 TiDB Lightning 是快速的全量数据导入工具，见 [TiDB Lightning on GitHub](https://github.com/pingcap/tidb-lightning)。 +- 6.3.1 TiDB Lightning 是快速的全量数据导入工具，见 [TiDB Lightning on GitHub](https://github.com/pingcap/tidb/tree/master/br/pkg/lightning)。 - 6.3.2 导入速度太慢。 diff --git a/tiflash-performance-tuning-methods.md b/tiflash-performance-tuning-methods.md index ac500597c623..3d0359b1870e 100644 --- a/tiflash-performance-tuning-methods.md +++ b/tiflash-performance-tuning-methods.md @@ -98,7 +98,7 @@ summary: 本文介绍了 Performance Overview 面板中 TiFlash 部分，帮助 你可以通过 `(Read flow + Write flow) ÷ 总的 Write Throughput By Instance` 计算出整个 TiFlash 集群的写放大倍数。 -示例 1 ：[CH-benCHmark 负载](/benchmark/benchmark-tidb-using-ch.md) OP 环境 Raft 和 IO 指标 +示例 1 ：[CH-benCHmark 负载](/benchmark/benchmark-tidb-using-ch.md)本地部署环境 Raft 和 IO 指标 如下图所示，该 TiFlash 集群的 Raft Wait Index 和 Raft Batch Read Index 99 分位数较高，分别为 3.24 秒和 753 毫秒。这是因为该集群的 TiFlash 负载较高，数据同步存在延迟。 diff --git a/tiflash/create-tiflash-replicas.md b/tiflash/create-tiflash-replicas.md index 0bfdd7601341..c08100edc899 100644 --- a/tiflash/create-tiflash-replicas.md +++ b/tiflash/create-tiflash-replicas.md @@ -11,8 +11,6 @@ summary: 了解如何构建 TiFlash 副本。 TiFlash 接入 TiKV 集群后，默认不会开始同步数据。可通过 MySQL 客户端向 TiDB 发送 DDL 命令来为特定的表建立 TiFlash 副本： -{{< copyable "sql" >}} - ```sql ALTER TABLE table_name SET TIFLASH REPLICA count; ``` @@ -25,8 +23,6 @@ ALTER TABLE table_name SET TIFLASH REPLICA count; 为表建立 2 个副本： -{{< copyable "sql" >}} - ```sql ALTER TABLE `tpch50`.`lineitem` SET TIFLASH REPLICA 2; ``` @@ -61,8 +57,6 @@ ALTER TABLE `tpch50`.`lineitem` SET TIFLASH REPLICA 0; 可通过如下 SQL 语句查看特定表（通过 WHERE 语句指定，去掉 WHERE 语句则查看所有表）的 TiFlash 副本的状态： -{{< copyable "sql" >}} - ```sql SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = '' and TABLE_NAME = ''; ``` @@ -76,8 +70,6 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = ' 类似于按表构建 TiFlash 副本的方式，你可以在 MySQL 客户端向 TiDB 发送 DDL 命令来为指定数据库中的所有表建立 TiFlash 副本： -{{< copyable "sql" >}} - ```sql ALTER DATABASE db_name SET TIFLASH REPLICA count; ``` @@ -88,16 +80,12 @@ ALTER DATABASE db_name SET TIFLASH REPLICA count; 执行以下命令可以为 `tpch50` 库中的所有表建立 2 个 TiFlash 副本。 -{{< copyable "sql" >}} - ```sql ALTER DATABASE `tpch50` SET TIFLASH REPLICA 2; ``` 执行以下命令可以删除为 `tpch50` 库建立的 TiFlash 副本： -{{< copyable "sql" >}} - ```sql ALTER DATABASE `tpch50` SET TIFLASH REPLICA 0; ``` @@ -111,22 +99,20 @@ ALTER DATABASE `tpch50` SET TIFLASH REPLICA 0; > - 在命令执行到结束期间，如果在该库下创建表，则**可能**会对这些新增表创建 TiFlash 副本。 > - 在命令执行到结束期间，如果为该库下的表添加索引，则该命令可能陷入等待，直到添加索引完成。 > +> - 该命令执行结束后，在该库中新建的表不会自动创建 TiFlash 副本。 +> > - 该命令会跳过系统表、视图、临时表以及包含了 TiFlash 不支持字符集的表。 ### 查看库同步进度 类似于按表构建，按库构建 TiFlash 副本的命令执行成功，不代表所有表都已同步完成。可以执行下面的 SQL 语句检查数据库中所有已设置 TiFlash Replica 表的同步进度： -{{< copyable "sql" >}} - ```sql SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = ''; ``` 可以执行下面的 SQL 语句检查数据库中尚未设置 TiFlash Replica 的表名： -{{< copyable "sql" >}} - ```sql SELECT TABLE_NAME FROM information_schema.tables where TABLE_SCHEMA = "" and TABLE_NAME not in (SELECT TABLE_NAME FROM information_schema.tiflash_replica where TABLE_SCHEMA = ""); ``` @@ -153,10 +139,10 @@ SELECT TABLE_NAME FROM information_schema.tables where TABLE_SCHEMA = " tiup ctl:v pd -u http://:2379 store limit all engine tiflash 60 add-peer ``` - > 上述命令中，需要将 `v` 替换为该集群版本，例如 `v6.5.0`，`:2379` 替换为任一 PD 节点的地址。替换后样例为： + > 上述命令中，需要将 `v` 替换为该集群版本，例如 `v7.2.0`，`:2379` 替换为任一 PD 节点的地址。替换后样例为： > > ```shell - > tiup ctl:v6.1.1 pd -u http://192.168.1.4:2379 store limit all engine tiflash 60 add-peer + > tiup ctl:v7.2.0 pd -u http://192.168.1.4:2379 store limit all engine tiflash 60 add-peer > ``` 执行完毕后，几分钟内，你将观察到 TiFlash 节点的 CPU 及磁盘 IO 资源占用显著提升，TiFlash 将更快地创建副本。同时，TiKV 节点的 CPU 及磁盘 IO 资源占用也将有所上升。 diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index f0af9a9911ca..09d7edb3d9b7 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -40,8 +40,6 @@ aliases: ['/docs-cn/dev/tiflash/tiflash-configuration/','/docs-cn/dev/reference/ listen_host = "0.0.0.0" ## TiFlash TCP 服务的端口 tcp_port = 9000 -## TiFlash HTTP 服务的端口 -http_port = 8123 ## 数据块元信息的内存 cache 大小限制，通常不需要修改 mark_cache_size = 5368709120 ## 数据块 min-max 索引的内存 cache 大小限制，通常不需要修改 @@ -97,7 +95,7 @@ delta_index_cache_size = 0 ## I/O 限流功能限制下的读写流量总带宽，单位为 Byte，默认值为 0，即默认关闭 I/O 限流功能。 # max_bytes_per_sec = 0 ## max_read_bytes_per_sec 和 max_write_bytes_per_sec 的含义和 max_bytes_per_sec 类似，分别指 I/O 限流功能限制下的读流量总带宽和写流量总带宽。 - ## 分别用两个配置项控制读写带宽限制，适用于一些读写带宽限制分开计算的云盘，例如 GCP 上的 persistent disk。 + ## 分别用两个配置项控制读写带宽限制，适用于一些读写带宽限制分开计算的云盘，例如 Google Cloud 上的 persistent disk。 ## 当 max_bytes_per_sec 配置不为 0 时，优先使用 max_bytes_per_sec。 # max_read_bytes_per_sec = 0 # max_write_bytes_per_sec = 0 diff --git a/tiflash/tiflash-disaggregated-and-s3.md b/tiflash/tiflash-disaggregated-and-s3.md index 3c32149b3508..183f1e81c58d 100644 --- a/tiflash/tiflash-disaggregated-and-s3.md +++ b/tiflash/tiflash-disaggregated-and-s3.md @@ -23,8 +23,6 @@ TiFlash 默认使用存算一体的架构进行部署，即 TiFlash 节点既是 Write Node 利用本地磁盘（通常是 NVMe SSD）来缓存最新写入的数据，从而避免过多使用内存。 - Write Node 比原来存算一体的 TiFlash 节点有更快的扩容和缩容速度，即增加或者删除 Write Node 后，数据能更快地在 Write Node 之间达到平衡。原理是 Write Node 把所有数据存储到了 S3，运行时只需要在本地存储很少的数据。扩容和缩容本质上是 Region Peer 在节点间的迁移。当某个 Write Node 要将某个 Region Peer 移动到自己之上管理时，它只需要从 Region Peer 所在的 Write Node 上传到 S3 的最新文件中下载少量关于此 Region 的元数据，再从 TiKV 同步最近的 Region 更新，就可以追上 Region Leader 的进度，从而完成 Region Peer 的迁移。 - - TiFlash Compute Node 负责执行从 TiDB 节点发过来的查询请求。它首先访问 Write Node 以获取数据的快照 (data snapshots)，然后分别从 Write Node 读取最新的数据（即尚未上传到 S3 的数据），从 S3 读取剩下的大部分数据。 @@ -81,11 +79,7 @@ TiFlash 存算分离架构适用于高性价比的数据分析服务的场景。 } ``` -## 使用方式 - -默认情况下，TiUP 会将 TiFlash 部署为存算一体架构。如需将 TiFlash 部署为存算分离架构，请参考以下步骤手动进行配置： - -1. 确保 TiDB 集群中没有任何 TiFlash 节点。如果有，则需要将所有表的 TiFlash 副本数设置为 0，然后缩容掉所有 TiFlash 节点。比如： +3. 确保 TiDB 集群中没有任何 TiFlash 节点。如果有，则需要将所有表的 TiFlash 副本数设置为 0，然后缩容掉所有 TiFlash 节点。比如： ```sql SELECT * FROM INFORMATION_SCHEMA.TIFLASH_REPLICA; # 查询所有带有 TiFlash 副本的表 @@ -98,7 +92,11 @@ TiFlash 存算分离架构适用于高性价比的数据分析服务的场景。 tiup cluster prune mycluster # 移除所有处于 Tombstone 状态的 TiFlash 节点 ``` -2. 准备 TiFlash 的拓扑配置文件，比如 scale-out.topo.yaml，配置内容如下： +## 使用方式 + +默认情况下，TiUP 会将 TiFlash 部署为存算一体架构。如需将 TiFlash 部署为存算分离架构，请参考以下步骤手动进行配置： + +1. 准备 TiFlash 的拓扑配置文件，比如 scale-out.topo.yaml，配置内容如下： ```yaml tiflash_servers: @@ -162,7 +160,7 @@ TiFlash 存算分离架构适用于高性价比的数据分析服务的场景。 * `storage.s3.endpoint` 支持使用 `http` 模式和 `https` 模式连接 S3，可以直接通过修改 URL 来选择。比如 `https://s3.{region}.amazonaws.com`。 -3. 执行扩容 TiFlash 节点，并重新设置 TiFlash 副本数： +2. 执行扩容 TiFlash 节点，并重新设置 TiFlash 副本数： ```shell tiup cluster scale-out mycluster ./scale-out.topo.yaml @@ -172,7 +170,7 @@ TiFlash 存算分离架构适用于高性价比的数据分析服务的场景。 ALTER TABLE table_name SET TIFLASH REPLICA 1; ``` -4. 修改 TiDB 配置，用存算分离的方式查询 TiFlash。 +3. 修改 TiDB 配置，用存算分离的方式查询 TiFlash。 1. 以编辑模式打开 TiDB 配置文件： diff --git a/tiflash/tiflash-late-materialization.md b/tiflash/tiflash-late-materialization.md index 38a78b173c9f..659e25670c06 100644 --- a/tiflash/tiflash-late-materialization.md +++ b/tiflash/tiflash-late-materialization.md @@ -5,17 +5,16 @@ summary: 介绍通过使用 TiFlash 延迟物化的方式来加速 OLAP 场景 # 延迟物化 -> **警告：** +> **注意：** > -> 该功能目前是实验性功能，其形式和使用方法可能会在未来版本中发生变化。 +> 在 TiFlash [Fast Scan 模式](/tiflash/use-fastscan.md)下，延迟物化功能暂不可用。 -本文档介绍通过使用 TiFlash 延迟物化的方式来加速 Online Analytical Processing (OLAP) 场景的查询。 +TiFlash 延迟物化是加速 Online Analytical Processing (OLAP) 场景查询的一种优化方式。你可以通过修改变量 [`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-从-v700-版本开始引入) 来控制是否启用 TiFlash 延迟物化功能。 -默认情况下，当收到一个查询请求时，TiFlash 会先读取该查询所需列的全部数据，然后再根据查询条件对数据进行过滤、聚合等计算任务。延迟物化是一种优化方式，它支持下推部分过滤条件到 TableScan 算子，即先扫描过滤条件相关的列数据，过滤得到符合条件的行后，再扫描这些行的其他列数据，继续后续计算，从而减少 IO 扫描和数据处理的计算量。 +- 当关闭该功能时，如果 `SELECT` 语句中包含过滤条件（`WHERE` 子句），TiFlash 会先读取该查询所需列的全部数据，然后再根据查询条件对数据进行过滤、聚合等计算任务。 +- 当开启该功能时，TiFlash 支持下推部分过滤条件到 TableScan 算子，即先扫描下推到 TableScan 算子的过滤条件相关的列数据，过滤得到符合条件的行后，再扫描这些行的其他列数据，继续后续计算，从而减少 IO 扫描和数据处理的计算量。 -如果希望提升 OLAP 场景部分查询的性能，可以在 session 级别或 global 级别开启 TiFlash 延迟物化功能。你可以通过修改变量 [`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-从-v700-版本开始引入) 的值来选择是否启用 TiFlash 延迟物化功能。 - -启用 TiFlash 延迟物化功能后，TiDB 优化器会根据统计信息和查询的过滤条件，决定哪些过滤条件会被下推。优化器会优先考虑下推过滤率高的过滤条件，详细算法可以参考 [RFC 文档](https://github.com/pingcap/tidb/tree/master/docs/design/2022-12-06-support-late-materialization.md)。 +为了提升 OLAP 场景部分查询的性能，从 v7.1.0 起，TiFlash 延迟物化功能默认开启，TiDB 优化器会根据统计信息和查询的过滤条件，决定哪些过滤条件会被下推。优化器会优先考虑下推过滤率高的过滤条件，详细算法可以参考 [RFC 文档](https://github.com/pingcap/tidb/tree/master/docs/design/2022-12-06-support-late-materialization.md)。 例如： @@ -37,7 +36,7 @@ EXPLAIN SELECT a, b, c FROM t1 WHERE a < 1; ## 启用和禁用 TiFlash 延迟物化 -默认情况下，session 和 global 级别的变量 `tidb_opt_enable_late_materialization=OFF`，即未开启 TiFlash 延迟物化功能。你可以通过以下语句来查看对应的变量信息。 +默认情况下，session 和 global 级别的变量 `tidb_opt_enable_late_materialization=ON`，即开启 TiFlash 延迟物化功能。你可以通过以下语句来查看对应的变量信息。 ```sql SHOW VARIABLES LIKE 'tidb_opt_enable_late_materialization'; @@ -47,7 +46,7 @@ SHOW VARIABLES LIKE 'tidb_opt_enable_late_materialization'; +--------------------------------------+-------+ | Variable_name | Value | +--------------------------------------+-------+ -| tidb_opt_enable_late_materialization | OFF | +| tidb_opt_enable_late_materialization | ON | +--------------------------------------+-------+ ``` @@ -59,34 +58,34 @@ SHOW GLOBAL VARIABLES LIKE 'tidb_opt_enable_late_materialization'; +--------------------------------------+-------+ | Variable_name | Value | +--------------------------------------+-------+ -| tidb_opt_enable_late_materialization | OFF | +| tidb_opt_enable_late_materialization | ON | +--------------------------------------+-------+ ``` 变量 `tidb_opt_enable_late_materialization` 支持 session 级别和 global 级别的修改。 -- 如果需要在当前 session 中启用 TiFlash 延迟物化功能，可以通过以下语句设置: - +- 如果需要在当前 session 中关闭 TiFlash 延迟物化功能，可以通过以下语句设置: + ```sql - SET SESSION tidb_opt_enable_late_materialization=ON; + SET SESSION tidb_opt_enable_late_materialization=OFF; ``` -- 如果需要在 global 级别启用 TiFlash 延迟物化功能，可以通过以下语句设置： - +- 如果需要在 global 级别关闭 TiFlash 延迟物化功能，可以通过以下语句设置： + ```sql - SET GLOBAL tidb_opt_enable_late_materialization=ON; + SET GLOBAL tidb_opt_enable_late_materialization=OFF; ``` - + 设置后，新建的会话中 session 和 global 级别 `tidb_opt_enable_late_materialization` 都将默认启用新值。 -如需禁用 TiFlash 延迟物化功能，可以通过以下语句设置： +如需启用 TiFlash 延迟物化功能，可以通过以下语句设置： ```sql -SET SESSION tidb_opt_enable_late_materialization=OFF; +SET SESSION tidb_opt_enable_late_materialization=ON; ``` ```sql -SET GLOBAL tidb_opt_enable_late_materialization=OFF; +SET GLOBAL tidb_opt_enable_late_materialization=ON; ``` ## 实现机制 diff --git a/tiflash/tiflash-pipeline-model.md b/tiflash/tiflash-pipeline-model.md new file mode 100644 index 000000000000..e00a3952b4ae --- /dev/null +++ b/tiflash/tiflash-pipeline-model.md @@ -0,0 +1,122 @@ +--- +title: TiFlash Pipeline Model 执行模型 +summary: 介绍 TiFlash 新的执行模型 Pipeline Model。 +--- + +# TiFlash Pipeline Model 执行模型 + +本文介绍 TiFlash 新的执行模型 Pipeline Model。 + +从 v7.2.0 起，TiFlash 支持新的执行模型 Pipeline Model。你可以通过修改变量 [`tidb_enable_tiflash_pipeline_model`](/system-variables.md#tidb_enable_tiflash_pipeline_model-从-v720-版本开始引入) 来控制是否启用 TiFlash Pipeline Model。 + +Pipeline Model 主要借鉴了 [Morsel-Driven Parallelism: A NUMA-Aware Query Evaluation Framework for the Many-Core Age](https://dl.acm.org/doi/10.1145/2588555.2610507) 这篇论文，提供了一个精细的任务调度模型，有别于传统的线程调度模型，减少了操作系统申请和调度线程的开销以及提供精细的调度机制。 + +> **注意：** +> +> - TiFlash Pipeline Model 目前为实验特性，不建议在生产环境中使用。 +> - TiFlash Pipeline Model 目前不支持以下功能。当下列功能开启时，即使 `tidb_enable_tiflash_pipeline_model` 设置为 `ON`，下推到 TiFlash 的查询仍会使用原有的执行模型 Stream Model 来执行。 +> +> - [Join 算子落盘](/system-variables.md#tidb_max_bytes_before_tiflash_external_join-从-v700-版本开始引入) +> - [TiFlash 存算分离架构与 S3](/tiflash/tiflash-disaggregated-and-s3.md) + +## 启用和禁用 TiFlash Pipeline Model + +你可以使用系统变量 [`tidb_enable_tiflash_pipeline_model`](/system-variables.md#tidb_enable_tiflash_pipeline_model-从-v720-版本开始引入) 来开启或禁用 TiFlash Pipeline Model。该变量可以在 Session 级别和 Global 级别生效。默认情况下，`tidb_enable_tiflash_pipeline_model=OFF`，即关闭 TiFlash Pipeline Model。你可以通过以下语句来查看对应的变量信息： + +```sql +SHOW VARIABLES LIKE 'tidb_enable_tiflash_pipeline_model'; +``` + +``` ++------------------------------------+-------+ +| Variable_name | Value | ++------------------------------------+-------+ +| tidb_enable_tiflash_pipeline_model | OFF | ++------------------------------------+-------+ +``` + +```sql +SHOW GLOBAL VARIABLES LIKE 'tidb_enable_tiflash_pipeline_model'; +``` + +``` ++------------------------------------+-------+ +| Variable_name | Value | ++------------------------------------+-------+ +| tidb_enable_tiflash_pipeline_model | OFF | ++------------------------------------+-------+ +``` + +变量 `tidb_enable_tiflash_pipeline_model` 支持 session 级别和 global 级别的修改。 + +- 如果需要在当前 session 中开启 TiFlash Pipeline Model，可以通过以下语句设置： + + ```sql + SET SESSION tidb_enable_tiflash_pipeline_model=ON; + ``` + +- 如果需要在 global 级别开启 TiFlash Pipeline Model，可以通过以下语句设置： + + ```sql + SET GLOBAL tidb_enable_tiflash_pipeline_model=ON; + ``` + + 设置 global 级别后，新建的会话中 session 和 global 级别的 `tidb_enable_tiflash_pipeline_model` 都将默认启用新值。 + +如需关闭 TiFlash Pipeline Model，可以通过以下语句设置： + +```sql +SET SESSION tidb_enable_tiflash_pipeline_model=OFF; +``` + +```sql +SET GLOBAL tidb_enable_tiflash_pipeline_model=OFF; +``` + +## 设计实现 + +TiFlash 原有执行模型 Stream Model 是线程调度执行模型，每一个查询会独立申请若干条线程协同执行。 + +线程调度模型存在两个缺陷： + +- 在高并发场景下，过多的线程会引起较多上下文切换，导致较高的线程调度代价。 + +- 线程调度模型无法精准计量查询的资源使用量以及做细粒度的资源管控。 + +在新的执行模型 Pipeline Model 中进行了以下优化： + +- 查询会被划分为多个 pipeline 并依次执行。在每个 pipeline 中，数据块会被尽可能保留在缓存中，从而实现更好的时间局部性，从而提高整个执行过程的效率。 + +- 为了摆脱操作系统原生的线程调度模型，实现更加精细的调度机制，每个 pipeline 会被实例化成若干个 task，使用 task 调度模型，同时使用固定线程池，减少了操作系统申请和调度线程的开销。 + +TiFlash Pipeline Model 的架构如下： + +![TiFlash Pipeline Model Design](/media/tiflash/tiflash-pipeline-model.png) + +如上图所示，Pipeline Model 中有两个主要组成部分：Pipeline Query Executor 和 Task Scheduler。 + +- Pipeline Query Executor + + 负责将从 TiDB 节点发过来的查询请求转换为 pipeline dag。 + + 它会找到查询中的 pipeline breaker 算子，以 pipeline breaker 为边界将查询切分成若干个 pipeline，根据 pipeline 之间的依赖关系，将 pipeline 组装成一个有向无环图。 + + pipeline breaker 用于指代存在停顿/阻塞逻辑的算子，这一类算子会持续接收上游算子传来的数据块，直到所有数据块都被接收后，才会将处理结果返回给下游算子。这类算子会破坏数据处理流水线，所以被称为 pipeline breaker。pipeline breaker 的代表有 Aggregation，它会将上游算子的数据都写入到哈希表后，才对哈希表中的数据做计算返回给下游算子。 + + 在查询被转换为 pipeline dag 后，Pipeline Query Executor 会按照依赖关系依次执行每个 pipeline。pipeline 会根据查询并发度被实例化成若干个 task 提交给 Task Scheduler 执行。 + +- Task Scheduler + + 负责执行由 Pipeline Query Executor 提交过来的 task。task 会根据执行的逻辑的不同，在 Task Scheduler 里的不同组件中动态切换执行。 + + - CPU Task Thread Pool + + 执行 task 中 CPU 密集型的计算逻辑，比如数据过滤、函数计算等。 + + - IO Task Thread Pool + + 执行 task 中 IO 密集型的计算逻辑，比如计算中间结果落盘等。 + + - Wait Reactor + + 执行 task 中的等待逻辑，比如等待网络层将数据包传输给计算层等。 diff --git a/tiflash/tiflash-results-materialization.md b/tiflash/tiflash-results-materialization.md index 924f516c2d40..bb7dcabd2a0e 100644 --- a/tiflash/tiflash-results-materialization.md +++ b/tiflash/tiflash-results-materialization.md @@ -5,18 +5,16 @@ summary: 介绍如何在同一个事务中保存 TiFlash 的查询结果。 # TiFlash 查询结果物化 -> **警告：** -> -> 该功能目前是实验性功能，请注意使用场景限制。该功能会在未事先通知的情况下发生变化或删除。语法和实现可能会在 GA 前发生变化。如果发现 bug，请在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues) 反馈。 - 本文介绍如何在同一个事务 (`INSERT INTO SELECT`) 中实现将 TiFlash 查询结果保存至某一指定的 TiDB 表中。 从 v6.5.0 起，TiDB 支持将 TiFlash 查询结果保存到数据表中，即物化了 TiFlash 的查询结果。执行 `INSERT INTO SELECT` 语句时，如果 TiDB 将 `SELECT` 子查询下推到了 TiFlash，TiFlash 的查询结果可以保存到 `INSERT INTO` 指定的 TiDB 表中。v6.5.0 之前的 TiDB 版本不允许此类行为，即通过 TiFlash 执行的查询必须是只读的，你需要从应用程序层面接收 TiFlash 返回的结果，然后另行在其它事务或处理中保存结果。 > **注意：** > -> - 默认情况下 ([`tidb_allow_mpp = ON`](/system-variables.md#tidb_allow_mpp-从-v50-版本开始引入))，TiDB 优化器将依据查询代价智能选择下推查询到 TiKV 或 TiFlash。如需强制使用 TiFlash 查询，你可以设置系统变量 [`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-从-v51-版本开始引入) 为 `ON`。 -> - 在实验特性阶段，该功能默认关闭。要开启此功能，请设置系统变量 [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-从-v630-版本开始引入) 为 `ON`。 +> 默认情况下 ([`tidb_allow_mpp = ON`](/system-variables.md#tidb_allow_mpp-从-v50-版本开始引入))，优化器将根据 [SQL 模式](/sql-mode.md) 及 TiFlash 副本的代价估算自行决定是否将查询下推到 TiFlash。 +> +> - 如果当前会话的 [SQL 模式](/sql-mode.md)为非严格模式（即 `sql_mode` 值不包含 `STRICT_TRANS_TABLES` 和 `STRICT_ALL_TABLES`），优化器会根据 TiFlash 副本的代价估算自行决定是否将 `INSERT INTO SELECT` 中的 `SELECT` 子查询将下推到 TiFlash。在此模式下，如需忽略优化器代价估算强制使用 TiFlash 查询，你可以设置[`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-从-v51-版本开始引入) 为 `ON`。 +> - 如果当前会话的 [SQL 模式](/sql-mode.md)为严格模式（即 `sql_mode` 值包含 `STRICT_TRANS_TABLES` 或 `STRICT_ALL_TABLES`），`INSERT INTO SELECT` 中的 `SELECT` 子查询将无法下推到 TiFlash。 `INSERT INTO SELECT` 语法如下： diff --git a/tiflash/tiflash-supported-pushdown-calculations.md b/tiflash/tiflash-supported-pushdown-calculations.md index b6b5b3841c8d..07f6542c1f3e 100644 --- a/tiflash/tiflash-supported-pushdown-calculations.md +++ b/tiflash/tiflash-supported-pushdown-calculations.md @@ -22,7 +22,7 @@ TiFlash 支持部分算子的下推，支持的算子如下： * 只有在 [MPP 模式](/tiflash/use-tiflash-mpp-mode.md)下才能被下推 * 支持的 Join 类型包括 Inner Join、Left Join、Semi Join、Anti Semi Join、Left Semi Join、Anti Left Semi Join * 对于上述类型，既支持带等值条件的连接，也支持不带等值条件的连接（即 Cartesian Join 或者 Null-aware Semi Join）；在计算 Cartesian Join 或者 Null-aware Semi Join 时，只会使用 Broadcast 算法，而不会使用 Shuffle Hash Join 算法 -* [Window](/functions-and-operators/window-functions.md)：当前支持下推的窗口函数包括 `ROW_NUMBER()`、`RANK()`、`DENSE_RANK()`、`LEAD()` 和 `LAG()` +* [Window](/functions-and-operators/window-functions.md)：当前支持下推的窗口函数包括 `ROW_NUMBER()`、`RANK()`、`DENSE_RANK()`、`LEAD()`、`LAG()`、`FIRST_VALUE()` 和 `LAST_VALUE()` 在 TiDB 中，算子之间会呈现树型组织结构。一个算子能下推到 TiFlash 的前提条件，是该算子的所有子算子都能下推到 TiFlash。因为大部分算子都包含有表达式计算，当且仅当一个算子所包含的所有表达式均支持下推到 TiFlash 时，该算子才有可能下推给 TiFlash。 @@ -31,7 +31,7 @@ TiFlash 支持部分算子的下推，支持的算子如下： | 表达式类型 | 运算 | | :-------------- | :------------------------------------- | | [数学函数](/functions-and-operators/numeric-functions-and-operators.md) | `+`, `-`, `/`, `*`, `%`, `>=`, `<=`, `=`, `!=`, `<`, `>`, `ROUND()`, `ABS()`, `FLOOR(int)`, `CEIL(int)`, `CEILING(int)`, `SQRT()`, `LOG()`, `LOG2()`, `LOG10()`, `LN()`, `EXP()`, `POW()`, `SIGN()`, `RADIANS()`, `DEGREES()`, `CONV()`, `CRC32()`, `GREATEST(int/real)`, `LEAST(int/real)` | -| [逻辑函数](/functions-and-operators/control-flow-functions.md)和[算子](/functions-and-operators/operators.md) | `AND`, `OR`, `NOT`, `CASE WHEN`, `IF()`, `IFNULL()`, `ISNULL()`, `IN`, `LIKE`, `COALESCE`, `IS` | +| [逻辑函数](/functions-and-operators/control-flow-functions.md)和[算子](/functions-and-operators/operators.md) | `AND`, `OR`, `NOT`, `CASE WHEN`, `IF()`, `IFNULL()`, `ISNULL()`, `IN`, `LIKE`, `ILIKE`, `COALESCE`, `IS` | | [位运算](/functions-and-operators/bit-functions-and-operators.md) | `&` (bitand), \| (bitor), `~` (bitneg), `^` (bitxor) | | [字符串函数](/functions-and-operators/string-functions.md) | `SUBSTR()`, `CHAR_LENGTH()`, `REPLACE()`, `CONCAT()`, `CONCAT_WS()`, `LEFT()`, `RIGHT()`, `ASCII()`, `LENGTH()`, `TRIM()`, `LTRIM()`, `RTRIM()`, `POSITION()`, `FORMAT()`, `LOWER()`, `UCASE()`, `UPPER()`, `SUBSTRING_INDEX()`, `LPAD()`, `RPAD()`, `STRCMP()` | | [正则函数和算子](/functions-and-operators/string-functions.md) | `REGEXP`, `REGEXP_LIKE()`, `REGEXP_INSTR()`, `REGEXP_SUBSTR()`, `REGEXP_REPLACE()` | diff --git a/tiflash/use-fastscan.md b/tiflash/use-fastscan.md index 2e8bd03b8338..768fa2a94412 100644 --- a/tiflash/use-fastscan.md +++ b/tiflash/use-fastscan.md @@ -12,6 +12,39 @@ aliases: ['/zh/tidb/dev/sql-statement-set-tiflash-mode/','/zh/tidb/dev/dev-guide 某些 OLAP 对查询结果精度可以容忍一定误差。如果对查询性能有更高要求，可以在 session 级别或 global 级别开启 FastScan 功能，你可以通过修改变量 `tiflash_fastscan` 的值来选择是否启用 FastScan 功能。 +## 使用限制 + +当开启 FastScan 功能时，查询结果可能会包含表中的旧数据，即相同主键的多个历史版本的数据或者已经删除的数据。如下所示： + +```sql +CREATE TABLE t1 (a INT PRIMARY KEY, b INT); +ALTER TABLE t1 SET TIFLASH REPLICA 1; +INSERT INTO t1 VALUES(1,2); +INSERT INTO t1 VALUES(10,20); +UPDATE t1 SET b = 4 WHERE a = 1; +DELETE FROM t1 WHERE a = 10; +SET SESSION tidb_isolation_read_engines='tiflash'; + +SELECT * FROM t1; ++------+------+ +| a | b | ++------+------+ +| 1 | 4 | ++------+------+ + +SET SESSION tiflash_fastscan=ON; +SELECT * FROM t1; ++------+------+ +| a | b | ++------+------+ +| 1 | 2 | +| 1 | 4 | +| 10 | 20 | ++------+------+ +``` + +对于这些旧数据，TiFlash 在后台会自动发起数据整理（Compaction）。当这些旧数据已经被后台整理且它们的数据版本小于 GC safe point 之后，才会被物理清理。此后在 FastScan 模式下将不再返回这些数据。旧数据被整理的时机受多种因素的自动触发，你也可以通过 [`ALTER TABLE ... COMPACT`](/sql-statements/sql-statement-alter-table-compact.md) 手动触发数据整理。 + ## 启用和禁用 FastScan 默认情况下，session 和 global 级别的变量 `tiflash_fastscan=OFF`，即没有开启 FastScan 功能。你可以通过以下语句来查看对应的变量信息。 @@ -66,8 +99,8 @@ TiFlash 存储层的数据主要存放在 Delta 层和 Stable 层。 在默认状态下（即未开启 FastScan 功能），TableScan 算子过程整体包括了以下步骤： 1. Read data：在 Delta 层和 Stable 层分别建立数据流，进行各自数据的读取。 -2. Sort Merge：将步骤 1 中建立的数据流进行合并，并且将数据按照 (handle, version) 顺序排列返回。 +2. Sort Merge：将步骤 1 中建立的数据流进行合并，并且将数据按照 (主键列，时间戳列) 顺序排列返回。 3. Range Filter：根据读取范围限制，对步骤 2 中的数据进行过滤筛选并返回。 -4. MVCC + Column Filter：对步骤 3 中的数据进行 MVCC 过滤，同时过滤掉不需要的列并返回。 +4. MVCC + Column Filter：对步骤 3 中的数据进行 MVCC 过滤（即依照查询需要的数据版本，根据主键列以及时间戳列筛选出正确的数据版本），同时进行 Column 过滤（即过滤掉查询请求中不需要的列）并返回。 FastScan 通过损失一定的数据一致性来获取更快的查询性能。FastScan 中的 TableScan 流程省略了上述过程中的第 2 步和第 4 步中 MVCC 的部分，从而提高查询性能。 \ No newline at end of file diff --git a/tiflash/use-tiflash-mpp-mode.md b/tiflash/use-tiflash-mpp-mode.md index 30a859d9a119..8dee755abfe2 100644 --- a/tiflash/use-tiflash-mpp-mode.md +++ b/tiflash/use-tiflash-mpp-mode.md @@ -95,10 +95,11 @@ mysql> explain select count(*) from customer c join nation n on c.c_nationkey=n. 在执行计划中，出现了 `ExchangeReceiver` 和 `ExchangeSender` 算子。该执行计划表示 `nation` 表读取完毕后，经过 `ExchangeSender` 算子广播到各个节点中，与 `customer` 表先后进行 `HashJoin` 和 `HashAgg` 操作，再将结果返回至 TiDB 中。 -TiFlash 提供了两个全局/会话变量决定是否选择 Broadcast Hash Join，分别为： +TiFlash 提供了 3 个全局/会话变量决定是否选择 Broadcast Hash Join，分别为： -- [`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_count-从-v50-版本开始引入)，单位为 bytes。如果表大小（字节数）小于该值，则选择 Broadcast Hash Join 算法。否则选择 Shuffled Hash Join 算法。 +- [`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-从-v50-版本开始引入)，单位为 bytes。如果表大小（字节数）小于该值，则选择 Broadcast Hash Join 算法。否则选择 Shuffled Hash Join 算法。 - [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-从-v50-版本开始引入)，单位为行数。如果 join 的对象为子查询，优化器无法估计子查询结果集大小，在这种情况下通过结果集行数判断。如果子查询的行数估计值小于该变量，则选择 Broadcast Hash Join 算法。否则选择 Shuffled Hash Join 算法。 +- [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-从-v710-版本开始引入)，控制是否使用最小网络数据交换策略。使用该策略时，TiDB 会估算 Broadcast Hash Join 和 Shuffled Hash Join 两种算法所需进行网络交换的数据量，并选择网络交换数据量较小的算法。该功能开启后，[`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-从-v50-版本开始引入) 和 [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-从-v50-版本开始引入) 将不再生效。 ## MPP 模式访问分区表 diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 6af3e1f3709e..c2b72bd95c71 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -573,7 +573,7 @@ I/O rate limiter 相关的配置项。 ### `retry-interval` -+ 初始化 PD 连接时的重试间隔。 ++ 设置 PD 连接的重试间隔。 + 默认值：`"300ms"` ### `retry-log-every` @@ -761,8 +761,9 @@ raftstore 相关的配置项。 ### `region-compact-check-step` + 每轮校验人工 compaction 时，一次性检查的 Region 个数。 -+ 默认值：100 -+ 最小值：0 ++ 默认值： + + 当 `storage.engine="raft-kv"` 时，默认值为 100。 + + 当 `storage.engine="partitioned-raft-kv"` 时，默认值为 5。 ### `region-compact-min-tombstones` @@ -777,6 +778,19 @@ raftstore 相关的配置项。 + 最小值：1 + 最大值：100 +### `region-compact-min-redundant-rows` 从 v7.1.0 版本开始引入 + ++ 触发 RocksDB compaction 需要的冗余的 MVCC 数据行数。该配置只对分区 Raft KV (storage.engine="partitioned-raft-kv") 生效。 ++ 默认值：`50000` ++ 最小值：`0` + +### `region-compact-redundant-rows-percent` 从 v7.1.0 版本开始引入 + ++ 触发 RocksDB compaction 需要的冗余的 MVCC 数据行所占比例。该配置只对分区 Raft KV (`storage.engine="partitioned-raft-kv"`) 生效。 ++ 默认值：`20` ++ 最小值：`1` ++ 最大值：`100` + ### `pd-heartbeat-tick-interval` + 触发 Region 对 PD 心跳的时间间隔，0 表示不启用。 @@ -989,10 +1003,10 @@ raftstore 相关的配置项。 + 默认值：1MB + 最小值：0 -### `report-min-resolved-ts-interval` +### `report-min-resolved-ts-interval` 从 v6.0.0 版本开始引入 -+ 设置 PD leader 收到 Resolved TS 的最小间隔时间。如果该值设置为 `0`，表示禁用该功能。 -+ 默认值：`"1s"`，即最小正值 ++ 设置 PD leader 收到 Resolved TS 的间隔时间。如果该值设置为 `0`，表示禁用该功能。 ++ 默认值：在 v6.3.0 之前版本中为 `"0s"`，在 v6.3.0 及之后的版本中为 `"1s"`，即最小正值。 + 最小值：0 + 单位：秒 @@ -1350,6 +1364,12 @@ rocksdb defaultcf、rocksdb writecf 和 rocksdb lockcf 相关的配置项。 + `writecf` 默认值：`false` + `lockcf` 默认值：`false` +### `optimize-filters-for-memory` 从 v7.2.0 版本开始引入 + ++ 控制是否生成能够最小化内存碎片的 Bloom/Ribbon filter。 ++ 只有当 [`format-version`](#format-version-从-v620-版本开始引入) >= 5 时，该配置项才生效。 ++ 默认值：`false` + ### `whole-key-filtering` + 开启将整个 key 放到 bloom filter 中的开关。 @@ -1368,6 +1388,12 @@ rocksdb defaultcf、rocksdb writecf 和 rocksdb lockcf 相关的配置项。 + 开启每个 block 建立 bloom filter 的开关。 + 默认值：false +### `ribbon-filter-above-level` 从 v7.2.0 版本开始引入 + ++ 控制是否对于大于等于该值的 level 使用 Ribbon filter，对于小于该值的 level，使用非 block-based bloom filter。当该配置开启时，[`block-based-bloom-filter`](#block-based-bloom-filter) 将被忽略。 ++ 只有当 [`format-version`](#format-version-从-v620-版本开始引入) >= 5 时，该配置项才生效。 ++ 默认值：`false` + ### `read-amp-bytes-per-bit` + 开启读放大统计的开关，0：不开启，> 0 开启。 @@ -1513,7 +1539,7 @@ rocksdb defaultcf、rocksdb writecf 和 rocksdb lockcf 相关的配置项。 ### `compaction-guard-min-output-file-size` + 设置 compaction guard 启用时 SST 文件大小的最小值，防止 SST 文件过小。 -+ 默认值：8MB ++ 默认值：从 v7.2.0 起，默认值从 8MB 变更为 1MB。 + 单位：KB|MB|GB ### `compaction-guard-max-output-file-size` @@ -1522,6 +1548,30 @@ rocksdb defaultcf、rocksdb writecf 和 rocksdb lockcf 相关的配置项。 + 默认值：128MB + 单位：KB|MB|GB +### `format-version` 从 v6.2.0 版本开始引入 + ++ 设置 SST 文件的格式版本。该配置项只影响新写入的表，对于已经存在的表，版本信息会从 footer 中读取。 ++ 可选值： + - `0`：适用于所有 TiKV 版本。默认 checksum 类型为 CRC32。该版本不支持修改 checksum 类型。 + - `1`：适用于所有 TiKV 版本。支持使用非默认的 checksum 类型，例如 xxHash。只有在 checksum 类型不是 CRC32 时，RocksDB 才会写入数据。（`0` 版本会自动升级） + - `2`：适用于所有 TiKV 版本。更改了压缩块的编码方式，使用 LZ4、BZip2 和 Zlib 压缩。 + - `3`：适用于 TiKV v2.1 及以上版本。更改了索引块中 key 的编码方式。 + - `4`：适用于 TiKV v3.0 及以上版本。更改了索引块中 value 的编码方式。 + - `5`：适用于 TiKV v6.1 及以上版本。全量和分区 filter 采用一种具有不同模式的、更快、更准确的 Bloom filter 实现。 ++ 默认值：`2` + +### `ttl` 从 v7.2.0 版本开始引入 + ++ 设置 SST 文件被自动选中执行 compaction 的 TTL 时间。更新时间超过此值的 SST 文件将被选中并进行 compaction。在执行 compaction 时，这些 SST 文件通常以级联的方式进行压缩，以便被压缩到最底层或最底层的文件中。 ++ 默认值：`30d` ++ 单位：s(second)|h(hour)|d(day) + +### `periodic-compaction-seconds` 从 v7.2.0 版本开始引入 + ++ 设置周期性 compaction 的时间。更新时间超过此值的 SST 文件将被选中进行 compaction，并被重新写入这些 SST 文件所在的层级。 ++ 默认值：`30d` ++ 单位：s(second)|h(hour)|d(day) + ## rocksdb.defaultcf.titan rocksdb defaultcf titan 相关的配置项。 @@ -2233,3 +2283,31 @@ Raft Engine 相关的配置项。 + 是否支持对用户前台的读写请求按照对应的资源组配额做优先级调度。有关 TiDB 资源组和资源管控的信息，请参考 [TiDB 资源管控](/tidb-resource-control.md) + 在 TiDB 侧开启 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-从-v660-版本开始引入) 全局变量的情况下，开启这个配置项才有意义。此配置参数开启后，TiKV 会使用优先级队列对排队的用户前台读写请求做调度，调度的优先级和请求所在资源组已经消费的资源量反相关，和对应资源组的配额正相关。 + 默认值：true（即开启按照资源组配额调度） + +## split + +[Load Base Split](/configure-load-base-split.md) 相关的配置项。 + +### `byte-threshold` 从 v5.0 版本开始引入 + ++ 控制某个 Region 被识别为热点 Region 的流量阈值。 ++ 默认值： + + + 当 [`region-split-size`](#region-split-size) 小于 4 GB 时，默认值为每秒 `30MiB` 流量。 + + 当 [`region-split-size`](#region-split-size) 大于或等于 4 GB 时，默认值为每秒 `100MiB` 流量。 + +### `qps-threshold` + ++ 控制某个 Region 被识别为热点 Region 的 QPS 阈值。 ++ 默认值： + + + 当 [`region-split-size`](#region-split-size) 小于 4 GB 时，默认值为每秒 `3000` QPS。 + + 当 [`region-split-size`](#region-split-size) 大于或等于 4 GB 时，默认值为每秒 `7000` QPS。 + +### `region-cpu-overload-threshold-ratio` 从 v6.2.0 版本开始引入 + ++ 控制某个 Region 被识别为热点 Region 的 CPU 使用率阈值。 ++ 默认值： + + + 当 [`region-split-size`](#region-split-size) 小于 4 GB 时，默认值为 `0.25`。 + + 当 [`region-split-size`](#region-split-size) 大于或等于 4 GB 时，默认值为 `0.75`。 diff --git a/time-to-live.md b/time-to-live.md index 20d2b5fefe5c..df3ca73c6bd8 100644 --- a/time-to-live.md +++ b/time-to-live.md @@ -100,7 +100,7 @@ TTL 可以和[数据类型的默认值](/data-type-default-values.md)一起使 ### TTL 和生成列 -TTL 可以和[生成列](/generated-columns.md)（实验特性）一起使用，用来表达更加复杂的过期规则。例如： +TTL 可以和[生成列](/generated-columns.md)一起使用，用来表达更加复杂的过期规则。例如： ```sql CREATE TABLE message ( @@ -238,7 +238,7 @@ TTL 功能能够与 TiDB 的迁移、备份、恢复工具一同使用。 * 具有 TTL 属性的表不支持作为外键约束的主表被其他表引用。 * 不保证所有过期数据立即被删除，过期数据被删除的时间取决于后台清理任务的调度周期和调度窗口。 * 对于使用[聚簇索引](/clustered-indexes.md)的表，如果主键的类型不是整数类型或二进制字符串类型，TTL 任务将无法被拆分成多个子任务。这将导致 TTL 任务只能在一个 TiDB 节点上按顺序执行。如果表中的数据量较大，TTL 任务的执行可能会变得缓慢。 -* TTL 无法在 TiDB Cloud [Serverless Tier](https://docs.pingcap.com/tidbcloud/select-cluster-tier#serverless-tier-beta) 集群上使用。 +* TTL 无法在 [TiDB Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-serverless-beta) 集群上使用。 ## 常见问题 diff --git a/tispark-overview.md b/tispark-overview.md index aef6b1c86401..0855b91e89f5 100644 --- a/tispark-overview.md +++ b/tispark-overview.md @@ -100,29 +100,29 @@ TiSpark 是 Spark 的第三方 jar 包，提供读写 TiKV 的能力。 你能用以下方式获取 jar 包： -- 从 [maven 中央仓库](https://search.maven.org/)获取，你可以搜索 [![Maven Search](https://img.shields.io/badge/com.pingcap/tispark-green.svg)](http://search.maven.org/#search%7Cga%7C1%7Cpingcap)。 +- 从 [maven 中央仓库](https://search.maven.org/)获取，你可以搜索 [`pingcap`](http://search.maven.org/#search%7Cga%7C1%7Cpingcap) 关键词。 - 从 [TiSpark releases](https://github.com/pingcap/tispark/releases) 获取。 - 通过以下步骤从源码构建： - 1. 下载 TiSpark 源码： - - ``` - git clone https://github.com/pingcap/tispark.git - cd tisapark - ``` - - 2. 在 TiSpark 根目录运行如下命令： - - ``` - // add -Dmaven.test.skip=true to skip the tests - mvn clean install -Dmaven.test.skip=true - // or you can add properties to specify spark version - mvn clean install -Dmaven.test.skip=true -Pspark3.2.1 - ``` - - > **注意：** - > - > 目前，你只能使用 java8 构架 TiSpark。运行 `mvn -version` 来检查 java 版本。 +1. 下载 TiSpark 源码： + + ``` + git clone https://github.com/pingcap/tispark.git + cd tisapark + ``` + +2. 在 TiSpark 根目录运行如下命令： + + ``` + // add -Dmaven.test.skip=true to skip the tests + mvn clean install -Dmaven.test.skip=true + // or you can add properties to specify spark version + mvn clean install -Dmaven.test.skip=true -Pspark3.2.1 + ``` + +> **注意：** +> +> 目前，你只能使用 java8 构架 TiSpark。运行 `mvn -version` 来检查 java 版本。 ### TiSpark jar 包的 artifact ID diff --git a/tiunimanager/tiunimanager-release-1.0.0.md b/tiunimanager/tiunimanager-release-1.0.0.md index 3ebb1bf74077..3717ee0dd850 100644 --- a/tiunimanager/tiunimanager-release-1.0.0.md +++ b/tiunimanager/tiunimanager-release-1.0.0.md @@ -14,7 +14,7 @@ TiDB Enterprise Manager 版本：1.0.0 > - TiDB Enterprise Manager v1.0.0 未开源。若要获取 v1.0.0 的安装包或相关支持，请联系 TiUniManager 团队。 > - 自 v1.0.2 起，TiDB Enterprise Manager 正式更名为 TiUniManager。 -TiDB Enterprise Manager 是一款以 TiDB 数据库为核心的数据库管理平台，帮助用户在私有部署 (on-premises) 或公有云环境中管理 TiDB 集群。 +TiDB Enterprise Manager 是一款以 TiDB 数据库为核心的数据库管理平台，帮助用户在本地部署环境或公有云环境中管理 TiDB 集群。 TiDB Enterprise Manager 不仅提供对 TiDB 集群的全生命周期的可视化管理，也同时一站式提供 TiDB 数据库参数管理、数据库版本升级、克隆集群、主备集群切换、数据导入导出、数据同步、数据备份恢复服务，能有效提高 TiDB 集群运维效率，降低企业运维成本。 diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md index 59dc7a87dc71..165dbf0e7649 100644 --- a/tiup/tiup-cluster-topology-reference.md +++ b/tiup/tiup-cluster-topology-reference.md @@ -251,7 +251,6 @@ tikv_servers: - `host`：指定部署到哪台机器，字段值填 IP 地址，不可省略 - `ssh_port`：指定连接目标机器进行操作的时候使用的 SSH 端口，若不指定，则使用 global 区块中的 `ssh_port` - `tcp_port`：TiFlash TCP 服务的端口，默认 9000 -- `http_port`：TiFlash HTTP 服务的端口，默认 8123 - `flash_service_port`：TiFlash 提供服务的端口，TiDB 通过该端口从 TiFlash 读数据，默认 3930 - `metrics_port`：TiFlash 的状态端口，用于输出 metric 数据，默认 8234 - `flash_proxy_port`：内置 TiKV 的端口，默认 20170 diff --git a/tiup/tiup-cluster.md b/tiup/tiup-cluster.md index be80fe5eedee..e321a1a2589e 100644 --- a/tiup/tiup-cluster.md +++ b/tiup/tiup-cluster.md @@ -16,7 +16,7 @@ tiup cluster ``` ``` -Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.11.3/cluster +Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.12.3/cluster Deploy a TiDB cluster for production Usage: @@ -61,7 +61,7 @@ Flags: tiup cluster deploy [flags] ``` -该命令需要提供集群的名字、集群使用的 TiDB 版本（例如 `v6.5.0`），以及一个集群的拓扑文件。 +该命令需要提供集群的名字、集群使用的 TiDB 版本（例如 `v7.2.0`），以及一个集群的拓扑文件。 拓扑文件的编写可参考[示例](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)。以一个最简单的拓扑为例，将下列文件保存为 `/tmp/topology.yaml`： @@ -118,12 +118,12 @@ tidb_servers: ... ``` -假如我们想要使用 TiDB 的 v7.0.0 版本，集群名字为 `prod-cluster`，则执行以下命令： +假如我们想要使用 TiDB 的 v7.2.0 版本，集群名字为 `prod-cluster`，则执行以下命令： {{< copyable "shell-regular" >}} ```shell -tiup cluster deploy -p prod-cluster v7.0.0 /tmp/topology.yaml +tiup cluster deploy -p prod-cluster v7.2.0 /tmp/topology.yaml ``` 执行过程中会再次确认拓扑结构并提示输入目标机器上的 root 密码（-p 表示使用密码）： @@ -131,7 +131,7 @@ tiup cluster deploy -p prod-cluster v7.0.0 /tmp/topology.yaml ```bash Please confirm your topology: TiDB Cluster: prod-cluster -TiDB Version: v7.0.0 +TiDB Version: v7.2.0 Type Host Ports OS/Arch Directories ---- ---- ----- ------- ----------- pd 172.16.5.134 2379/2380 linux/x86_64 deploy/pd-2379,data/pd-2379 @@ -171,10 +171,10 @@ tiup cluster list ``` ``` -Starting /root/.tiup/components/cluster/v1.11.3/cluster list +Starting /root/.tiup/components/cluster/v1.12.3/cluster list Name User Version Path PrivateKey ---- ---- ------- ---- ---------- -prod-cluster tidb v7.0.0 /root/.tiup/storage/cluster/clusters/prod-cluster /root/.tiup/storage/cluster/clusters/prod-cluster/ssh/id_rsa +prod-cluster tidb v7.2.0 /root/.tiup/storage/cluster/clusters/prod-cluster /root/.tiup/storage/cluster/clusters/prod-cluster/ssh/id_rsa ``` ## 启动集群 @@ -200,9 +200,9 @@ tiup cluster display prod-cluster ``` ``` -Starting /root/.tiup/components/cluster/v1.11.3/cluster display prod-cluster +Starting /root/.tiup/components/cluster/v1.12.3/cluster display prod-cluster TiDB Cluster: prod-cluster -TiDB Version: v7.0.0 +TiDB Version: v7.2.0 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 172.16.5.134:3000 grafana 172.16.5.134 3000 linux/x86_64 Up - deploy/grafana-3000 @@ -268,9 +268,9 @@ tiup cluster display prod-cluster ``` ``` -Starting /root/.tiup/components/cluster/v1.11.3/cluster display prod-cluster +Starting /root/.tiup/components/cluster/v1.12.3/cluster display prod-cluster TiDB Cluster: prod-cluster -TiDB Version: v7.0.0 +TiDB Version: v7.2.0 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 172.16.5.134:3000 grafana 172.16.5.134 3000 linux/x86_64 Up - deploy/grafana-3000 @@ -370,12 +370,12 @@ Global Flags: -y, --yes 跳过所有的确认步骤 ``` -例如，把集群升级到 v7.0.0 的命令为： +例如，把集群升级到 v7.2.0 的命令为： {{< copyable "shell-regular" >}} ```bash -tiup cluster upgrade tidb-test v7.0.0 +tiup cluster upgrade tidb-test v7.2.0 ``` ## 更新配置 @@ -552,14 +552,14 @@ tiup cluster audit ``` ``` -Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.11.3/cluster audit +Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.12.3/cluster audit ID Time Command -- ---- ------- -4BLhr0 2022-03-29T23:55:09+08:00 /home/tidb/.tiup/components/cluster/v1.11.3/cluster deploy test v7.0.0 /tmp/topology.yaml -4BKWjF 2022-03-029T23:36:57+08:00 /home/tidb/.tiup/components/cluster/v1.11.3/cluster deploy test v7.0.0 /tmp/topology.yaml -4BKVwH 2022-03-29T23:02:08+08:00 /home/tidb/.tiup/components/cluster/v1.11.3/cluster deploy test v7.0.0 /tmp/topology.yaml -4BKKH1 2022-03-29T16:39:04+08:00 /home/tidb/.tiup/components/cluster/v1.11.3/cluster destroy test -4BKKDx 2022-03-29T16:36:57+08:00 /home/tidb/.tiup/components/cluster/v1.11.3/cluster deploy test v7.0.0 /tmp/topology.yaml +4BLhr0 2023-06-29T23:55:09+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v7.2.0 /tmp/topology.yaml +4BKWjF 2023-06-29T23:36:57+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v7.2.0 /tmp/topology.yaml +4BKVwH 2023-06-29T23:02:08+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v7.2.0 /tmp/topology.yaml +4BKKH1 2023-06-29T16:39:04+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster destroy test +4BKKDx 2023-06-29T16:36:57+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v7.2.0 /tmp/topology.yaml ``` 第一列为 audit-id，如果想看某个命令的执行日志，则传入这个 audit-id： @@ -673,7 +673,7 @@ tiup cluster check --cluster 此时可以通过命令行参数 `--ssh=system` 启用系统自带命令行： -- 部署集群：`tiup cluster deploy --ssh=system`，其中 `` 为集群名称，`` 为 TiDB 集群版本（例如 `v6.5.0`），`` 为拓扑文件路径 +- 部署集群：`tiup cluster deploy --ssh=system`，其中 `` 为集群名称，`` 为 TiDB 集群版本（例如 `v7.2.0`），`` 为拓扑文件路径 - 启动集群：`tiup cluster start --ssh=system` - 升级集群：`tiup cluster upgrade ... --ssh=system` diff --git a/tiup/tiup-component-cluster-check.md b/tiup/tiup-component-cluster-check.md index 70e715a078a7..437cce99233f 100644 --- a/tiup/tiup-component-cluster-check.md +++ b/tiup/tiup-component-cluster-check.md @@ -150,7 +150,7 @@ tiup cluster check [flags] > `tiup cluster check` 也支持修复已部署集群的扩容拓扑文件，命令格式： > >```shell -> tiup cluster check scale-out.yaml --cluster --apply --user root [-p] [-i /home/root/.ssh/gcp_rsa] +> tiup cluster check scale-out.yml --cluster --apply --user root [-p] [-i /home/root/.ssh/gcp_rsa] >``` ### --cluster @@ -171,7 +171,7 @@ tiup cluster check [flags] > - `tiup cluster check` 也支持检查已部署集群的扩容拓扑文件，命令格式： > > ```shell -> tiup cluster check scale-out.yaml --cluster --user root [-p] [-i /home/root/.ssh/gcp_rsa] +> tiup cluster check scale-out.yml --cluster --user root [-p] [-i /home/root/.ssh/gcp_rsa] > ``` ### -N, --node diff --git a/tiup/tiup-component-cluster-deploy.md b/tiup/tiup-component-cluster-deploy.md index ccca9aba1d29..e2aa9029ee8b 100644 --- a/tiup/tiup-component-cluster-deploy.md +++ b/tiup/tiup-component-cluster-deploy.md @@ -13,7 +13,7 @@ tiup cluster deploy [flags] ``` - `` 表示新集群的名字，不能和现有集群同名 -- `` 为要部署的 TiDB 集群版本号，如 `v7.0.0` +- `` 为要部署的 TiDB 集群版本号，如 `v7.2.0` - `` 为事先编写好的[拓扑文件](/tiup/tiup-cluster-topology-reference.md) ## 选项 diff --git a/tiup/tiup-component-cluster-patch.md b/tiup/tiup-component-cluster-patch.md index 4e562dd9657f..b1b467052a33 100644 --- a/tiup/tiup-component-cluster-patch.md +++ b/tiup/tiup-component-cluster-patch.md @@ -19,15 +19,50 @@ tiup cluster patch [flags] ``` - `` 代表要操作的集群名 -- `` 为用于替换的二进制包，其打包方式如下： - - 确定当前要替换的组件名称 `${component}` (tidb, tikv, pd...) 以及其版本 `${version}` (v4.0.0, v4.0.1 ...)，以及其运行的平台 `${os}` (linux) 和 `${arch}` (amd64, arm64) - - 下载当前的组件包：`wget https://tiup-mirrors.pingcap.com/${component}-${version}-${os}-${arch}.tar.gz -O /tmp/${component}-${version}-${os}-${arch}.tar.gz` - - 建立临时打包目录：`mkdir -p /tmp/package && cd /tmp/package` - - 解压原来的二进制包：`tar xf /tmp/${component}-${version}-${os}-${arch}.tar.gz` - - 查看临时打包目录中的文件结构：`find .` - - 将要替换的二进制文件或配置文件复制到临时目录的对应位置 - - 重新打包 `tar czf /tmp/${component}-hotfix-${os}-${arch}.tar.gz *` - - 通过以上步骤之后，`/tmp/${component}-hotfix-${os}-${arch}.tar.gz` 就可以用于 patch 命令了 +- `` 为用于替换的二进制包路径 + +### 准备二进制包 + +在运行 `tiup cluster patch` 命令之前，你需要打包所需的二进制文件。请按照以下步骤操作： + +1. 确定以下变量的值： + + - `${component}`：需要替换的组件名（例如 `tidb`、`tikv`、`pd`）。 + - `${version}`：组件的版本（例如 `v7.2.0`、`v6.5.2`）。 + - `${os}`：操作系统 (`linux`)。 + - `${arch}`：组件运行的平台 (`amd64`、`arm64`)。 +2. 下载当前的组件包： + + ```shell + wget https://tiup-mirrors.pingcap.com/${component}-${version}-${os}-${arch}.tar.gz -O /tmp/${component}-${version}-${os}-${arch}.tar.gz + ``` + +3. 创建临时打包目录： + + ```shell + mkdir -p /tmp/package && cd /tmp/package + ``` + +4. 解压原来的二进制包： + + ```shell + tar xf /tmp/${component}-${version}-${os}-${arch}.tar.gz + ``` + +5. 查看临时打包目录中的文件结构： + + ```shell + find . + ``` + +6. 将要替换的二进制文件或配置文件复制到临时目录的对应位置。 +7. 将临时目录中的所有文件打包： + + ```shell + tar czf /tmp/${component}-hotfix-${os}-${arch}.tar.gz * + ``` + +完成上述步骤后，你可以在 `tiup cluster patch` 命令中使用 `/tmp/${component}-hotfix-${os}-${arch}.tar.gz` 作为 ``。 ## 选项 @@ -37,7 +72,7 @@ tiup cluster patch [flags] - 数据类型：`BOOLEAN` - 该选项默认关闭，默认值为 `false`。在命令中添加该选项，并传入 `true` 值或不传值，均可开启此功能。 -### --transfer-timeout（uint，默认 300） +### --transfer-timeout（uint，默认 600） 在重启 PD 或 TiKV 时，会先将被重启节点的 leader 迁移到其他节点，迁移过程会需要一定时间，可以通过设置 `--transfer-timeout` 设置最长等待时间（单位为秒），超时之后会跳过等待直接重启服务。 diff --git a/tiup/tiup-component-cluster-reload.md b/tiup/tiup-component-cluster-reload.md index 5a15b087b174..7b8652eaa3ae 100644 --- a/tiup/tiup-component-cluster-reload.md +++ b/tiup/tiup-component-cluster-reload.md @@ -22,7 +22,7 @@ tiup cluster reload [flags] - 数据类型：`BOOLEAN` - 该选项默认关闭，默认值为 `false`。在命令中添加该选项，并传入 `true` 值或不传值，均可开启此功能。 -### --transfer-timeout（uint，默认 300） +### --transfer-timeout（uint，默认 600） 在重启 PD 或 TiKV 时，会先将被重启节点的 leader 迁移到其他节点，迁移过程会需要一定时间，可以通过设置 `--transfer-timeout` 设置最长等待时间（单位为秒），超时之后会跳过等待直接重启服务。 diff --git a/tiup/tiup-component-cluster-scale-in.md b/tiup/tiup-component-cluster-scale-in.md index 1e327e238de8..2ddf4fa65220 100644 --- a/tiup/tiup-component-cluster-scale-in.md +++ b/tiup/tiup-component-cluster-scale-in.md @@ -45,7 +45,7 @@ tiup cluster scale-in [flags] > > 使用该选项强制移除正在服务和下线中的 TiKV / TiFlash 节点时，这些节点会被直接删除，不等待数据调度完成，因此这个场景下，数据丢失风险非常大。不建议对未宕机的节点使用该选项。如果元数据所在的 Region 发生数据丢失，整个集群将不可用且无法恢复。 -### --transfer-timeout（uint，默认 300） +### --transfer-timeout（uint，默认 600） 在缩容 PD 或 TiKV 时，会先将被缩容节点的 leader 迁移到其他节点，迁移过程会需要一定时间，可以通过设置 `--transfer-timeout` 设置最长等待时间（单位为秒），超时之后会跳过等待直接缩容服务。 diff --git a/tiup/tiup-component-cluster-upgrade.md b/tiup/tiup-component-cluster-upgrade.md index 22f3d2d8e0ad..71b3d54fc82d 100644 --- a/tiup/tiup-component-cluster-upgrade.md +++ b/tiup/tiup-component-cluster-upgrade.md @@ -13,7 +13,7 @@ tiup cluster upgrade [flags] ``` - `` 为要操作的集群名字，如果忘记集群名字可通过[集群列表](/tiup/tiup-component-cluster-list.md)查看。 -- `` 为要升级到的目标版本，例如 `v6.5.0`。目前仅允许升级到比当前集群更高的版本，不允许升级到比当前集群更低的版本，即不允许降级。同时也不允许升级成 nightly 版本 +- `` 为要升级到的目标版本，例如 `v7.2.0`。目前仅允许升级到比当前集群更高的版本，不允许升级到比当前集群更低的版本，即不允许降级。同时也不允许升级成 nightly 版本。 ## 选项 @@ -27,7 +27,7 @@ tiup cluster upgrade [flags] > > 对正在提供服务的集群强制升级可能导致集群服务不可用。对于未启动的集群，升级成功后会自动启动集群。 -### --transfer-timeout（uint，默认 300） +### --transfer-timeout（uint，默认 600） 在升级 PD 或 TiKV 时，会先将被升级节点的 leader 迁移到其他节点，迁移过程会需要一定时间，可以通过设置 `--transfer-timeout` 设置最长等待时间（单位为秒），超时之后会跳过等待直接升级服务。 diff --git a/tiup/tiup-component-dm-upgrade.md b/tiup/tiup-component-dm-upgrade.md index 438c4a06a2e4..523a66a41b34 100644 --- a/tiup/tiup-component-dm-upgrade.md +++ b/tiup/tiup-component-dm-upgrade.md @@ -13,7 +13,7 @@ tiup dm upgrade [flags] ``` - `` 为要操作的集群名字，如果忘记集群名字可查看[集群列表](/tiup/tiup-component-dm-list.md)。 -- `` 为要升级到的目标版本，例如 `v6.5.0`。目前仅允许升级到比当前集群更高的版本，不允许升级到比当前集群更低的版本，即不允许降级。同时也不允许升级成 nightly 版本 +- `` 为要升级到的目标版本，例如 `v7.2.0`。目前仅允许升级到比当前集群更高的版本，不允许升级到比当前集群更低的版本，即不允许降级。同时也不允许升级成 nightly 版本。 ## 选项 diff --git a/tiup/tiup-component-management.md b/tiup/tiup-component-management.md index bd31b167f84b..aa4f0819d1af 100644 --- a/tiup/tiup-component-management.md +++ b/tiup/tiup-component-management.md @@ -69,12 +69,12 @@ tiup install tidb tiup install tidb:nightly ``` -示例三：使用 TiUP 安装 v7.0.0 版本的 TiKV +示例三：使用 TiUP 安装 v7.2.0 版本的 TiKV {{< copyable "shell-regular" >}} ```shell -tiup install tikv:v7.0.0 +tiup install tikv:v7.2.0 ``` ## 升级组件 @@ -127,12 +127,12 @@ Flags: 如果想要多次启动同一个组件并复用之前的工作目录，就可以在启动时用 `--tag` 指定相同的名字。指定 tag 后，在实例终止时就*不会自动删除*工作目录，方便下次启动时复用。 -示例一：运行 v7.0.0 版本的 TiDB +示例一：运行 v7.2.0 版本的 TiDB {{< copyable "shell-regular" >}} ```shell -tiup tidb:v7.0.0 +tiup tidb:v7.2.0 ``` 示例二：指定 tag 运行 TiKV @@ -218,12 +218,12 @@ component 为要卸载的组件名称，version 为要卸载的版本，这两 - 若省略版本，加 `--all` 表示卸载该组件所有版本 - 若版本和组件都省略，则加 `--all` 表示卸载所有组件及其所有版本 -示例一：卸载 v7.0.0 版本的 TiDB +示例一：卸载 v7.2.0 版本的 TiDB {{< copyable "shell-regular" >}} ```shell -tiup uninstall tidb:v7.0.0 +tiup uninstall tidb:v7.2.0 ``` 示例二：卸载所有版本的 TiKV diff --git a/tiup/tiup-mirror.md b/tiup/tiup-mirror.md index 01a549b4140a..f9bc57152ca8 100644 --- a/tiup/tiup-mirror.md +++ b/tiup/tiup-mirror.md @@ -86,9 +86,9 @@ tiup mirror clone [global-version] [flags] 如果只想克隆某个组件的某一个版本而不是所有版本，则使用 `--=` 来限定，例如： - - 只想克隆 TiDB 的 v7.0.0 版本，则执行 `tiup mirror clone --tidb v7.0.0` - - 只想克隆 TiDB 的 v7.0.0 版本，以及 TiKV 的所有版本，则执行 `tiup mirror clone --tidb v7.0.0 --tikv all` - - 克隆一个集群的所有组件的 v7.0.0 版本，则执行 `tiup mirror clone v7.0.0` + - 只想克隆 TiDB 的 v7.2.0 版本，则执行 `tiup mirror clone --tidb v7.2.0` + - 只想克隆 TiDB 的 v7.2.0 版本，以及 TiKV 的所有版本，则执行 `tiup mirror clone --tidb v7.2.0 --tikv all` + - 克隆一个集群的所有组件的 v7.2.0 版本，则执行 `tiup mirror clone v7.2.0` 克隆完成后，签名密钥会自动设置。 diff --git a/tiup/tiup-playground.md b/tiup/tiup-playground.md index 566e50569ae6..2a124c647bcc 100644 --- a/tiup/tiup-playground.md +++ b/tiup/tiup-playground.md @@ -17,9 +17,9 @@ tiup playground ${version} [flags] 如果直接执行 `tiup playground` 命令，则 TiUP playground 会使用本地安装的 TiDB/TiKV/PD 组件或者安装这些组件的稳定版本，来启动一个由 1 个 TiKV、1 个 TiDB、1 个 PD 和 1 个 TiFlash 实例构成的集群。该命令实际做了以下事情： -- 因为该命令没有指定 playground 的版本，TiUP 会先查找已安装的 playground 的最新版本，假设已安装的 playground 最新版为 v1.11.3，则该命令相当于 tiup playground:v1.11.3 +- 因为该命令没有指定 playground 的版本，TiUP 会先查找已安装的 playground 的最新版本，假设已安装的 playground 最新版为 v1.12.3，则该命令相当于 tiup playground:v1.12.3 - 如果 playground 从未安装过任何版本的 TiDB/TiKV/PD 组件，TiUP 会先安装这些组件的最新稳定版，然后再启动运行这些组件的实例 -- 因为该命令没有指定 TiDB/PD/TiKV 各组件的版本，默认情况下，它会使用各组件的最新发布版本，假设当前为 v7.0.0，则该命令相当于 tiup playground:1.11.3 v7.0.0 +- 因为该命令没有指定 TiDB/PD/TiKV 各组件的版本，默认情况下，它会使用各组件的最新发布版本，假设当前为 v7.2.0，则该命令相当于 tiup playground:1.12.3 v7.2.0 - 因为该命令也没有指定各组件的个数，默认情况下，它会启动由 1 个 TiDB、1 个 TiKV、1 个 PD 和 1 个 TiFlash 实例构成的最小化集群 - 在依次启动完各个 TiDB 组件后，playground 会提醒集群启动成功，并告诉你一些有用的信息，譬如如何通过 MySQL 客户端连接集群、如何访问 [TiDB Dashboard](/dashboard/dashboard-intro.md) 等 diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 1ba69cb7b1ac..9b24820f6aa8 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -171,3 +171,7 @@ TiDB 的 Coprocessor Cache 功能支持下推计算结果缓存。开启该功 + [TiDB 高并发写入场景最佳实践](/best-practices/high-concurrency-best-practices.md) + [Split Region 使用文档](/sql-statements/sql-statement-split-region.md) + +## 打散读热点 + +在读热点场景中，热点 TiKV 无法及时处理读请求，导致读请求排队。但是，此时并非所有 TiKV 资源都已耗尽。为了降低延迟，TiDB v7.1.0 引入了负载自适应副本读取功能，允许从其他 TiKV 节点读取副本，而无需在热点 TiKV 节点排队等待。你可以通过 [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-从-v700-版本开始引入) 系统变量控制读请求的排队长度。当 leader 节点的预估排队时间超过该阈值时，TiDB 会优先从 follower 节点读取数据。在读热点的情况下，与不打散读热点相比，该功能可提高读取吞吐量 70%～200%。 diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index e1914137556f..a657a8921d99 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -7,35 +7,32 @@ aliases: ['/docs-cn/dev/upgrade-tidb-using-tiup/','/docs-cn/dev/how-to/upgrade/u 本文档适用于以下升级路径： -- 使用 TiUP 从 TiDB 4.0 版本升级至 TiDB 7.0。 -- 使用 TiUP 从 TiDB 5.0-5.4 版本升级至 TiDB 7.0。 -- 使用 TiUP 从 TiDB 6.0 版本升级至 TiDB 7.0。 -- 使用 TiUP 从 TiDB 6.1 版本升级至 TiDB 7.0。 -- 使用 TiUP 从 TiDB 6.2 版本升级至 TiDB 7.0。 -- 使用 TiUP 从 TiDB 6.3 版本升级至 TiDB 7.0。 -- 使用 TiUP 从 TiDB 6.4 版本升级至 TiDB 7.0。 -- 使用 TiUP 从 TiDB 6.5 版本升级至 TiDB 7.0。 -- 使用 TiUP 从 TiDB 6.6 版本升级至 TiDB 7.0。 +- 使用 TiUP 从 TiDB 4.0 版本升级至 TiDB 7.2。 +- 使用 TiUP 从 TiDB 5.0-5.4 版本升级至 TiDB 7.2。 +- 使用 TiUP 从 TiDB 6.0-6.6 版本升级至 TiDB 7.2。 +- 使用 TiUP 从 TiDB 7.0-7.1 版本升级至 TiDB 7.2。 > **警告：** > -> - 不支持将 TiFlash 组件从 5.3 之前的老版本在线升级至 5.3 及之后的版本，只能采用停机升级。如果集群中其他组件（如 tidb，tikv）不能停机升级，参考[不停机升级](#不停机升级)中的注意事项。 -> - 在升级 TiDB 集群的过程中，**请勿执行** DDL 语句，否则可能会出现行为未定义的问题。 -> - 集群中有 DDL 语句正在被执行时（通常为 `ADD INDEX` 和列类型变更等耗时较久的 DDL 语句），**请勿进行**升级操作。在升级前，建议使用 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md) 命令查看集群中是否有正在进行的 DDL Job。如需升级，请等待 DDL 执行完成或使用 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md) 命令取消该 DDL Job 后再进行升级。 +> 1. 不支持将 TiFlash 组件从 5.3 之前的老版本在线升级至 5.3 及之后的版本，只能采用停机升级。如果集群中其他组件（如 tidb，tikv）不能停机升级，参考[不停机升级](#不停机升级)中的注意事项。 +> 2. 在升级 TiDB 集群的过程中，**请勿执行** DDL 语句，否则可能会出现行为未定义的问题。 +> 3. 集群中有 DDL 语句正在被执行时（通常为 `ADD INDEX` 和列类型变更等耗时较久的 DDL 语句），**请勿进行**升级操作。在升级前，建议使用 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md) 命令查看集群中是否有正在进行的 DDL Job。如需升级，请等待 DDL 执行完成或使用 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md) 命令取消该 DDL Job 后再进行升级。 +> +> 从 TiDB v7.1 版本升级至更高的版本时，可以不遵循上面的限制 2 和 3，建议参考[平滑升级 TiDB 的限制](/smooth-upgrade-tidb.md#使用限制)。 > **注意：** > -> 如果原集群是 3.0 或 3.1 或更早的版本，不支持直接升级到 7.0.0 及后续修订版本。你需要先从早期版本升级到 4.0 后，再从 4.0 升级到 7.0.0 及后续修订版本。 +> 如果原集群是 3.0 或 3.1 或更早的版本，不支持直接升级到 v7.2.0 及后续修订版本。你需要先从早期版本升级到 4.0 后，再从 4.0 升级到 v7.2.0 及后续修订版本。 ## 1. 升级兼容性说明 - TiDB 目前暂不支持版本降级或升级后回退。 -- 使用 TiDB Ansible 管理的 4.0 版本集群，需要先按照 [4.0 版本文档的说明](https://docs.pingcap.com/zh/tidb/v4.0/upgrade-tidb-using-tiup)将集群导入到 TiUP (`tiup cluster`) 管理后，再按本文档说明升级到 7.0.0 版本。 -- 若要将 3.0 之前的版本升级至 7.0.0 版本： +- 使用 TiDB Ansible 管理的 4.0 版本集群，需要先按照 [4.0 版本文档的说明](https://docs.pingcap.com/zh/tidb/v4.0/upgrade-tidb-using-tiup)将集群导入到 TiUP (`tiup cluster`) 管理后，再按本文档说明升级到 v7.2.0 版本。 +- 若要将 v3.0 之前的版本升级至 v7.2.0 版本： 1. 首先[通过 TiDB Ansible 升级到 3.0 版本](https://docs.pingcap.com/zh/tidb/v3.0/upgrade-tidb-using-ansible)。 2. 然后按照 [4.0 版本文档的说明](https://docs.pingcap.com/zh/tidb/v4.0/upgrade-tidb-using-tiup)，使用 TiUP (`tiup cluster`) 将 TiDB Ansible 配置导入。 - 3. 将集群升级至 4.0 版本。 - 4. 按本文档说明将集群升级到 7.0.0 版本。 + 3. 将集群升级至 v4.0 版本。 + 4. 按本文档说明将集群升级到 v7.2.0 版本。 - 支持 TiDB Binlog，TiCDC，TiFlash 等组件版本的升级。 - 将 v6.3.0 之前的 TiFlash 升级至 v6.3.0 及之后的版本时，需要特别注意：在 Linux AMD64 架构的硬件平台部署 TiFlash 时，CPU 必须支持 AVX2 指令集。而在 Linux ARM64 架构的硬件平台部署 TiFlash 时，CPU 必须支持 ARMv8 架构。具体请参考 [6.3.0 版本 Release Notes](/releases/release-6.3.0.md#其他) 中的描述。 - 具体不同版本的兼容性说明，请查看各个版本的 [Release Note](/releases/release-notes.md)。请根据各个版本的 Release Note 的兼容性更改调整集群的配置。 @@ -47,7 +44,7 @@ aliases: ['/docs-cn/dev/upgrade-tidb-using-tiup/','/docs-cn/dev/how-to/upgrade/u ### 2.1 查阅兼容性变更 -查阅 TiDB v7.0.0 release notes 中的[兼容性变更](/releases/release-7.0.0.md#兼容性变更)。如果有任何变更影响到了你的升级，请采取相应的措施。 +查阅 TiDB v7.2.0 release notes 中的[兼容性变更](/releases/release-7.2.0.md#兼容性变更)。如果有任何变更影响到了你的升级，请采取相应的措施。 ### 2.2 升级 TiUP 或更新 TiUP 离线镜像 @@ -140,7 +137,7 @@ tiup update cluster > **注意：** > -> 升级到 7.0.0 版本前，请确认已在 4.0 修改的参数在 7.0.0 版本中是兼容的，可参考 [TiKV 配置文件描述](/tikv-configuration-file.md)。 +> 升级到 v7.2.0 版本前，请确认已在 4.0 修改的参数在 v7.2.0 版本中是兼容的，可参考 [TiKV 配置文件描述](/tikv-configuration-file.md)。 ### 2.4 检查当前集群的健康状况 @@ -177,12 +174,12 @@ tiup cluster check --cluster tiup cluster upgrade ``` -以升级到 7.0.0 版本为例： +以升级到 v7.2.0 版本为例： {{< copyable "shell-regular" >}} ``` -tiup cluster upgrade v7.0.0 +tiup cluster upgrade v7.2.0 ``` > **注意：** @@ -206,7 +203,7 @@ tiup cluster upgrade v7.0.0 tiup cluster stop ``` -之后通过 `upgrade` 命令添加 `--offline` 参数来进行停机升级，其中 `` 为集群名，`` 为升级的目标版本，例如 `v6.5.0`。 +之后通过 `upgrade` 命令添加 `--offline` 参数来进行停机升级，其中 `` 为集群名，`` 为升级的目标版本，例如 `v7.2.0`。 {{< copyable "shell-regular" >}} @@ -235,7 +232,7 @@ tiup cluster display ``` Cluster type: tidb Cluster name: -Cluster version: v7.0.0 +Cluster version: v7.2.0 ``` ## 4. 升级 FAQ @@ -266,7 +263,7 @@ Cluster version: v7.0.0 ### 4.2 升级过程中 evict leader 等待时间过长，如何跳过该步骤快速升级 -可以指定 `--force`，升级时会跳过 `PD transfer leader` 和 `TiKV evict leader` 过程，直接重启并升级版本，对线上运行的集群性能影响较大。命令如下，其中 `` 为升级的目标版本，例如 `v6.5.0`： +可以指定 `--force`，升级时会跳过 `PD transfer leader` 和 `TiKV evict leader` 过程，直接重启并升级版本，对线上运行的集群性能影响较大。命令如下，其中 `` 为升级的目标版本，例如 `v7.2.0`： {{< copyable "shell-regular" >}} @@ -281,5 +278,5 @@ tiup cluster upgrade --force {{< copyable "" >}} ``` -tiup install ctl:v7.0.0 +tiup install ctl:v7.2.0 ```