From 90860acf7bd3d2596a92d285ace26d2f4afb1062 Mon Sep 17 00:00:00 2001 From: yikeke Date: Fri, 21 Feb 2020 20:41:29 +0800 Subject: [PATCH] release-3.0 branch: build --- TOC.md | 482 +++++++ _index.md | 12 +- dev/architecture.md => architecture.md | 2 +- .../add-index-with-load.md | 0 {dev/benchmark => benchmark}/dm-v1.0-ga.md | 0 .../how-to-run-sysbench.md | 6 +- .../how-to-run-tpcc.md | 6 +- .../sysbench-in-k8s.md | 0 {v3.0/benchmark => benchmark}/sysbench-v2.md | 0 {v3.0/benchmark => benchmark}/sysbench-v3.md | 0 {v3.0/benchmark => benchmark}/sysbench-v4.md | 0 {v3.0/benchmark => benchmark}/sysbench.md | 0 {dev/benchmark => benchmark}/tpcc.md | 0 {v3.0/benchmark => benchmark}/tpch-v2.md | 0 {v3.0/benchmark => benchmark}/tpch.md | 0 v3.0/contribute.md => contribute.md | 0 dev/TOC.md | 490 ------- dev/_index.md | 63 - dev/benchmark/how-to-run-sysbench.md | 277 ---- dev/benchmark/sysbench-v2.md | 129 -- dev/benchmark/sysbench-v3.md | 142 -- dev/benchmark/sysbench-v4.md | 278 ---- dev/benchmark/sysbench.md | 210 --- dev/benchmark/tpch-v2.md | 105 -- dev/benchmark/tpch.md | 108 -- dev/contribute.md | 31 - dev/faq/tidb-lightning.md | 190 --- dev/faq/tidb.md | 1082 --------------- dev/faq/upgrade.md | 328 ----- dev/how-to/configure/memory-control.md | 67 - dev/how-to/configure/time-zone.md | 111 -- .../deploy/data-migration-with-ansible.md | 570 -------- .../location-awareness.md | 95 -- .../deploy/geographic-redundancy/overview.md | 70 - dev/how-to/deploy/hardware-recommendations.md | 83 -- dev/how-to/deploy/orchestrated/ansible.md | 966 -------------- dev/how-to/deploy/orchestrated/docker.md | 260 ---- .../deploy/orchestrated/offline-ansible.md | 159 --- .../deploy-tidb-from-docker-compose.md | 205 --- dev/how-to/get-started/explore-sql.md | 274 ---- .../get-started/read-historical-data.md | 194 --- dev/how-to/get-started/tidb-binlog.md | 521 -------- dev/how-to/maintain/ansible-operations.md | 46 - .../backup-and-restore/mydumper-lightning.md | 95 -- .../identify-slow-queries.md | 332 ----- dev/how-to/migrate/from-mysql-aurora.md | 208 --- dev/how-to/monitor/monitor-a-cluster.md | 355 ----- dev/how-to/monitor/overview.md | 28 - dev/how-to/scale/horizontally.md | 132 -- dev/how-to/scale/with-ansible.md | 527 -------- .../secure/enable-tls-between-components.md | 131 -- dev/how-to/secure/enable-tls-clients.md | 158 --- .../generate-self-signed-certificates.md | 162 --- dev/how-to/troubleshoot/cluster-setup.md | 149 --- dev/how-to/troubleshoot/tidb-lightning.md | 134 -- dev/how-to/upgrade/from-previous-version.md | 220 ---- dev/key-features.md | 28 - dev/overview.md | 66 - .../best-practices/high-concurrency.md | 203 --- dev/reference/best-practices/java-app.md | 333 ----- .../configuration/pd-server/configuration.md | 120 -- .../tidb-server/configuration-file.md | 444 ------- .../tidb-server/configuration.md | 145 -- .../tidb-server/mysql-variables.md | 200 --- .../tidb-server/tidb-specific-variables.md | 668 ---------- .../tikv-server/configuration-file.md | 1092 --------------- .../tikv-server/configuration.md | 60 - dev/reference/error-codes.md | 120 -- dev/reference/garbage-collection/overview.md | 40 - .../overview-dashboard.md | 87 -- .../key-monitoring-metrics/pd-dashboard.md | 139 -- .../key-monitoring-metrics/tikv-dashboard.md | 429 ------ dev/reference/mysql-compatibility.md | 226 ---- ...eck-cluster-status-using-sql-statements.md | 27 - .../performance/execution-plan-bind.md | 103 -- dev/reference/performance/follower-read.md | 50 - dev/reference/performance/index-merge.md | 99 -- dev/reference/performance/optimizer-hints.md | 268 ---- .../performance/sql-optimizer-overview.md | 26 - dev/reference/performance/statistics.md | 321 ----- dev/reference/performance/tune-tikv.md | 252 ---- .../understanding-the-query-execution-plan.md | 155 --- dev/reference/security/compatibility.md | 16 - dev/reference/security/privilege-system.md | 481 ------- .../security/user-account-management.md | 232 ---- dev/reference/sql/character-set.md | 327 ----- dev/reference/sql/constraints.md | 273 ---- dev/reference/sql/data-types/date-and-time.md | 66 - dev/reference/sql/data-types/overview.md | 15 - .../aggregate-group-by-functions.md | 157 --- .../bit-functions-and-operators.md | 20 - .../cast-functions-and-operators.md | 16 - .../control-flow-functions.md | 15 - .../date-and-time-functions.md | 73 -- .../encryption-and-compression-functions.md | 38 - .../information-functions.md | 32 - .../functions-and-operators/json-functions.md | 84 -- .../miscellaneous-functions.md | 36 - .../numeric-functions-and-operators.md | 55 - .../sql/functions-and-operators/operators.md | 124 -- .../functions-and-operators/precision-math.md | 170 --- .../sql/functions-and-operators/reference.md | 12 - .../string-functions.md | 73 -- .../type-conversion.md | 8 - dev/reference/sql/generated-columns.md | 99 -- .../sql/language-structure/comment-syntax.md | 124 -- .../language-structure/expression-syntax.md | 67 - .../keywords-and-reserved-words.md | 483 ------- .../sql/language-structure/literal-values.md | 283 ---- .../language-structure/schema-object-names.md | 109 -- .../user-defined-variables.md | 245 ---- dev/reference/sql/sql-mode.md | 56 - dev/reference/sql/statements/admin.md | 161 --- dev/reference/sql/statements/create-table.md | 303 ----- dev/reference/sql/statements/desc.md | 9 - dev/reference/sql/statements/describe.md | 9 - dev/reference/sql/statements/explain.md | 223 ---- dev/reference/sql/statements/load-data.md | 72 - dev/reference/sql/statements/prepare.md | 71 - dev/reference/sql/statements/recover-table.md | 109 -- dev/reference/sql/statements/select.md | 131 -- .../sql/statements/show-fields-from.md | 9 - dev/reference/sql/statements/show-index.md | 9 - dev/reference/sql/statements/show-keys.md | 9 - dev/reference/sql/statements/show-schemas.md | 9 - .../sql/statements/show-table-regions.md | 179 --- .../sql/statements/show-variables.md | 134 -- dev/reference/supported-clients.md | 91 -- .../system-databases/information-schema.md | 767 ----------- dev/reference/system-databases/mysql.md | 36 - .../tidb-binlog/binlog-slave-client.md | 148 --- dev/reference/tidb-binlog/deploy.md | 629 --------- dev/reference/tidb-binlog/faq.md | 210 --- dev/reference/tidb-binlog/glossary.md | 27 - dev/reference/tidb-binlog/maintain.md | 258 ---- dev/reference/tidb-binlog/monitor.md | 164 --- dev/reference/tidb-binlog/overview.md | 60 - dev/reference/tidb-binlog/relay-log.md | 55 - dev/reference/tidb-binlog/reparo.md | 111 -- .../tidb-binlog/tidb-binlog-kafka.md | 458 ------- .../tidb-binlog/tidb-binlog-local.md | 287 ---- .../tidb-binlog/troubleshoot/binlog.md | 19 - dev/reference/tidb-binlog/upgrade.md | 83 -- dev/reference/tispark.md | 333 ----- dev/reference/tools/br/br.md | 400 ------ dev/reference/tools/br/use-cases.md | 415 ------ .../data-migration/cluster-operations.md | 489 ------- .../data-migration/configure/overview.md | 37 - .../configure/task-configuration-file.md | 82 -- dev/reference/tools/data-migration/deploy.md | 186 --- .../tools/data-migration/dm-upgrade.md | 161 --- .../tools/data-migration/dm-worker-intro.md | 99 -- dev/reference/tools/data-migration/faq.md | 52 - .../manually-handling-sharding-ddl-locks.md | 540 -------- .../tools/data-migration/features/overview.md | 529 -------- .../data-migration/features/shard-merge.md | 177 --- .../tools/data-migration/from-aurora.md | 206 --- .../tools/data-migration/overview.md | 102 -- .../tools/data-migration/precheck.md | 63 - .../tools/data-migration/query-status.md | 262 ---- .../tools/data-migration/relay-log.md | 176 --- .../tools/data-migration/skip-replace-sqls.md | 663 ---------- .../tools/data-migration/table-selector.md | 44 - .../tools/data-migration/troubleshoot/dm.md | 27 - .../troubleshoot/error-system.md | 114 -- .../usage-scenarios/shard-merge.md | 242 ---- .../usage-scenarios/simple-synchronization.md | 255 ---- dev/reference/tools/download.md | 75 -- .../load-misuse-handling.md | 41 - dev/reference/tools/loader.md | 154 --- dev/reference/tools/mydumper.md | 190 --- dev/reference/tools/pd-control.md | 1143 ---------------- dev/reference/tools/pd-recover.md | 39 - .../tools/sync-diff-inspector/overview.md | 220 ---- dev/reference/tools/syncer.md | 604 --------- .../tools/tidb-lightning/checkpoints.md | 119 -- dev/reference/tools/tidb-lightning/csv.md | 208 --- .../tools/tidb-lightning/deployment.md | 279 ---- .../tools/tidb-lightning/table-filter.md | 131 -- dev/reference/tools/user-guide.md | 185 --- dev/reference/transactions/overview.md | 214 --- .../transactions/transaction-isolation.md | 65 - .../transactions/transaction-optimistic.md | 178 --- .../transactions/transaction-pessimistic.md | 93 -- dev/releases/11alpha.md | 52 - dev/releases/11beta.md | 49 - dev/releases/2.0.10.md | 39 - dev/releases/2.0.11.md | 21 - dev/releases/2.0ga.md | 156 --- dev/releases/2.1.1.md | 46 - dev/releases/2.1.10.md | 60 - dev/releases/2.1.11.md | 45 - dev/releases/2.1.12.md | 43 - dev/releases/2.1.18.md | 76 -- dev/releases/2.1.2.md | 38 - dev/releases/2.1.3.md | 58 - dev/releases/2.1.4.md | 40 - dev/releases/2.1.5.md | 54 - dev/releases/2.1.6.md | 38 - dev/releases/2.1.7.md | 41 - dev/releases/2.1.8.md | 64 - dev/releases/2.1.9.md | 69 - dev/releases/2.1ga.md | 187 --- dev/releases/201.md | 49 - dev/releases/202.md | 30 - dev/releases/203.md | 37 - dev/releases/204.md | 41 - dev/releases/205.md | 40 - dev/releases/206.md | 49 - dev/releases/207.md | 36 - dev/releases/208.md | 29 - dev/releases/209.md | 46 - dev/releases/21beta.md | 85 -- dev/releases/21rc1.md | 155 --- dev/releases/21rc2.md | 119 -- dev/releases/21rc3.md | 63 - dev/releases/21rc4.md | 54 - dev/releases/21rc5.md | 64 - dev/releases/2rc1.md | 39 - dev/releases/2rc3.md | 59 - dev/releases/2rc4.md | 38 - dev/releases/2rc5.md | 48 - dev/releases/3.0-ga.md | 220 ---- dev/releases/3.0.0-beta.1.md | 109 -- dev/releases/3.0.0-rc.1.md | 143 -- dev/releases/3.0.0-rc.2.md | 121 -- dev/releases/3.0.0-rc.3.md | 122 -- dev/releases/3.0.2.md | 144 -- dev/releases/3.0.8.md | 112 -- dev/releases/3.0beta.md | 107 -- dev/releases/3.1.0-beta.1.md | 39 - dev/releases/3.1.0-beta.md | 28 - dev/releases/4.0.0-beta.md | 114 -- dev/releases/ga.md | 277 ---- dev/releases/prega.md | 39 - dev/releases/rc1.md | 41 - dev/releases/rc2.md | 52 - dev/releases/rc3.md | 53 - dev/releases/rc4.md | 48 - dev/releases/rn.md | 95 -- dev/report-issue.md | 17 - dev/roadmap.md | 189 --- dev/support-resources.md | 15 - dev/tidb-in-kubernetes/deploy/access-tidb.md | 62 - .../deploy/alibaba-cloud.md | 352 ----- dev/tidb-in-kubernetes/deploy/aws-eks.md | 531 -------- dev/tidb-in-kubernetes/deploy/gcp-gke.md | 740 ----------- .../deploy/general-kubernetes.md | 80 -- .../deploy/prerequisites.md | 174 --- .../deploy/tidb-operator.md | 132 -- dev/tidb-in-kubernetes/faq.md | 98 -- .../deploy-tidb-from-kubernetes-gke.md | 304 ----- .../deploy-tidb-from-kubernetes-kind.md | 190 --- .../deploy-tidb-from-kubernetes-minikube.md | 298 ----- dev/tidb-in-kubernetes/initialize-cluster.md | 94 -- .../maintain/auto-failover.md | 85 -- .../maintain/backup-and-restore.md | 159 --- .../maintain/backup-and-restore/backup-gcs.md | 204 --- .../maintain/backup-and-restore/backup-s3.md | 267 ---- .../maintain/backup-and-restore/restore.md | 87 -- .../maintain/destroy-tidb-cluster.md | 34 - .../maintain/kubernetes-node.md | 239 ---- .../maintain/log-collecting.md | 90 -- .../monitor/tidb-in-kubernetes.md | 97 -- .../reference/configuration/backup.md | 111 -- .../reference/configuration/storage-class.md | 280 ---- .../reference/tools/in-kubernetes.md | 256 ---- .../reference/tools/tkctl.md | 395 ------ dev/tidb-in-kubernetes/scale-in-kubernetes.md | 72 - .../tidb-operator-overview.md | 76 -- dev/tidb-in-kubernetes/troubleshoot.md | 372 ------ .../upgrade/tidb-cluster.md | 96 -- .../upgrade/tidb-operator.md | 22 - {v3.0/faq => faq}/tidb-lightning.md | 18 +- {v3.0/faq => faq}/tidb.md | 90 +- {v3.0/faq => faq}/upgrade.md | 0 dev/glossary.md => glossary.md | 0 .../configure/memory-control.md | 0 .../how-to => how-to}/configure/time-zone.md | 0 .../deploy/data-migration-with-ansible.md | 2 +- .../deploy/data-migration-with-binary.md | 2 +- .../location-awareness.md | 2 +- .../deploy/geographic-redundancy/overview.md | 0 .../deploy/hardware-recommendations.md | 2 +- .../deploy/orchestrated/ansible.md | 28 +- .../deploy/orchestrated/docker.md | 2 +- .../deploy/orchestrated/offline-ansible.md | 20 +- .../get-started/data-migration.md | 8 +- .../deploy-tidb-from-docker-compose.md | 4 +- .../get-started/explore-sql.md | 2 +- .../get-started/read-historical-data.md | 2 +- .../get-started/tidb-binlog.md | 6 +- .../get-started/tidb-lightning.md | 8 +- {dev/how-to => how-to}/get-started/tispark.md | 2 +- .../maintain/ansible-operations.md | 0 .../maintain/backup-and-restore.md | 14 +- .../identify-aborted-queries.md | 4 +- .../identify-slow-queries.md | 4 +- .../migrate/from-mysql-aurora.md | 6 +- .../monitor/monitor-a-cluster.md | 0 {v3.0/how-to => how-to}/monitor/overview.md | 0 {v3.0/how-to => how-to}/scale/horizontally.md | 4 +- {v3.0/how-to => how-to}/scale/with-ansible.md | 2 +- .../secure/enable-tls-between-components.md | 6 +- .../secure/enable-tls-clients.md | 6 +- .../generate-self-signed-certificates.md | 0 .../troubleshoot/cluster-setup.md | 8 +- .../troubleshoot/tidb-lightning.md | 6 +- .../upgrade/from-previous-version.md | 12 +- v3.0/key-features.md => key-features.md | 0 v3.1/overview.md => overview.md | 20 +- {dev/reference => reference}/alert-rules.md | 2 +- .../best-practices/grafana-monitor.md | 2 +- .../best-practices/haproxy.md | 0 .../best-practices/high-concurrency.md | 12 +- .../best-practices/java-app.md | 0 .../best-practices/massive-regions.md | 4 +- .../best-practices/pd-scheduling.md | 20 +- .../pd-server/configuration-file.md | 2 +- .../configuration/pd-server/configuration.md | 0 .../tidb-server/configuration-file.md | 2 +- .../tidb-server/configuration.md | 2 +- .../tidb-server/mysql-variables.md | 4 +- .../tidb-server/tidb-specific-variables.md | 10 +- .../tikv-server/configuration-file.md | 4 +- .../tikv-server/configuration.md | 0 {v3.0/reference => reference}/error-codes.md | 8 +- .../garbage-collection/configuration.md | 8 +- .../garbage-collection/overview.md | 2 +- .../overview-dashboard.md | 2 +- .../key-monitoring-metrics/pd-dashboard.md | 2 +- .../key-monitoring-metrics/tidb-dashboard.md | 2 +- .../key-monitoring-metrics/tikv-dashboard.md | 2 +- .../mysql-compatibility.md | 16 +- ...eck-cluster-status-using-sql-statements.md | 27 + .../performance/execution-plan-bind.md | 2 +- .../performance/optimizer-hints.md | 0 .../performance/sql-optimizer-overview.md | 0 .../performance/statement-summary.md | 0 .../performance/statistics.md | 0 .../performance/tune-tikv.md | 0 .../understanding-the-query-execution-plan.md | 0 .../security/cert-based-authentication.md | 0 .../security/compatibility.md | 0 .../security/privilege-system.md | 0 .../security/role-based-access-control.md | 12 +- .../security/user-account-management.md | 2 +- .../sql/character-set.md | 0 .../sql/constraints.md | 2 +- .../sql/data-types/date-and-time.md | 0 .../sql/data-types/default-values.md | 0 .../sql/data-types/json.md | 0 .../sql/data-types/numeric.md | 0 .../sql/data-types/overview.md | 2 +- .../sql/data-types/string.md | 0 .../aggregate-group-by-functions.md | 2 +- .../bit-functions-and-operators.md | 0 .../cast-functions-and-operators.md | 0 .../control-flow-functions.md | 0 .../date-and-time-functions.md | 0 .../encryption-and-compression-functions.md | 0 .../expressions-pushed-down.md | 14 +- .../information-functions.md | 0 .../functions-and-operators/json-functions.md | 0 .../miscellaneous-functions.md | 0 .../numeric-functions-and-operators.md | 0 .../sql/functions-and-operators/operators.md | 0 .../functions-and-operators/precision-math.md | 0 .../sql/functions-and-operators/reference.md | 2 +- .../string-functions.md | 0 .../type-conversion.md | 0 .../window-functions.md | 0 .../sql/generated-columns.md | 2 +- .../sql/language-structure/comment-syntax.md | 2 +- .../language-structure/expression-syntax.md | 0 .../keywords-and-reserved-words.md | 2 +- .../sql/language-structure/literal-values.md | 0 .../language-structure/schema-object-names.md | 0 .../user-defined-variables.md | 0 .../sql/partitioning.md | 0 {v3.0/reference => reference}/sql/sql-mode.md | 0 .../sql/statements/add-column.md | 4 +- .../sql/statements/add-index.md | 14 +- .../sql/statements/admin.md | 0 .../sql/statements/alter-database.md | 6 +- .../sql/statements/alter-table.md | 20 +- .../sql/statements/alter-user.md | 8 +- .../sql/statements/analyze-table.md | 4 +- .../sql/statements/begin.md | 8 +- .../sql/statements/change-column.md | 10 +- .../sql/statements/commit.md | 8 +- .../sql/statements/create-database.md | 12 +- .../sql/statements/create-index.md | 16 +- .../sql/statements/create-table-like.md | 6 +- .../sql/statements/create-table.md | 10 +- .../sql/statements/create-user.md | 10 +- .../sql/statements/create-view.md | 6 +- .../sql/statements/deallocate.md | 6 +- .../sql/statements/delete.md | 10 +- reference/sql/statements/desc.md | 9 + reference/sql/statements/describe.md | 9 + .../sql/statements/do.md | 4 +- .../sql/statements/drop-column.md | 6 +- .../sql/statements/drop-database.md | 6 +- .../sql/statements/drop-index.md | 10 +- .../sql/statements/drop-table.md | 8 +- .../sql/statements/drop-user.md | 8 +- .../sql/statements/drop-view.md | 6 +- .../sql/statements/execute.md | 6 +- .../sql/statements/explain-analyze.md | 8 +- .../sql/statements/explain.md | 10 +- .../sql/statements/flush-privileges.md | 8 +- .../sql/statements/flush-status.md | 2 +- .../sql/statements/flush-tables.md | 2 +- .../sql/statements/grant-privileges.md | 6 +- .../sql/statements/insert.md | 10 +- .../sql/statements/kill.md | 4 +- .../sql/statements/load-data.md | 4 +- .../sql/statements/modify-column.md | 12 +- .../sql/statements/prepare.md | 6 +- .../sql/statements/recover-table.md | 4 +- .../sql/statements/rename-index.md | 10 +- .../sql/statements/rename-table.md | 8 +- .../sql/statements/replace.md | 10 +- .../sql/statements/revoke-privileges.md | 8 +- .../sql/statements/rollback.md | 8 +- .../sql/statements/select.md | 12 +- .../sql/statements/set-names.md | 8 +- .../sql/statements/set-password.md | 6 +- .../sql/statements/set-transaction.md | 4 +- .../sql/statements/set-variable.md | 4 +- .../sql/statements/show-character-set.md | 4 +- .../sql/statements/show-collation.md | 2 +- .../sql/statements/show-columns-from.md | 4 +- .../sql/statements/show-create-table.md | 10 +- .../sql/statements/show-create-user.md | 6 +- .../sql/statements/show-databases.md | 8 +- .../sql/statements/show-engines.md | 0 .../sql/statements/show-errors.md | 4 +- reference/sql/statements/show-fields-from.md | 9 + .../sql/statements/show-grants.md | 6 +- reference/sql/statements/show-index.md | 9 + .../sql/statements/show-indexes.md | 8 +- reference/sql/statements/show-keys.md | 9 + .../sql/statements/show-privileges.md | 6 +- .../sql/statements/show-processlist.md | 2 +- reference/sql/statements/show-schemas.md | 9 + .../sql/statements/show-status.md | 2 +- .../sql/statements/show-table-regions.md | 4 +- .../sql/statements/show-table-status.md | 12 +- .../sql/statements/show-tables.md | 8 +- .../sql/statements/show-variables.md | 4 +- .../sql/statements/show-warnings.md | 4 +- .../sql/statements/split-region.md | 2 +- .../sql/statements/start-transaction.md | 8 +- .../sql/statements/trace.md | 2 +- .../sql/statements/truncate.md | 10 +- .../sql/statements/update.md | 10 +- .../sql/statements/use.md | 6 +- {dev/reference => reference}/sql/view.md | 4 +- .../supported-clients.md | 0 .../system-databases/information-schema.md | 4 +- .../system-databases/mysql.md | 0 .../tidb-binlog/binlog-slave-client.md | 0 .../tidb-binlog/deploy.md | 6 +- .../tidb-binlog/faq.md | 6 +- .../tidb-binlog/glossary.md | 0 .../tidb-binlog/maintain.md | 0 .../tidb-binlog/monitor.md | 0 .../tidb-binlog/overview.md | 8 +- .../tidb-binlog/relay-log.md | 0 .../tidb-binlog/reparo.md | 0 .../tidb-binlog/tidb-binlog-kafka.md | 0 .../tidb-binlog/tidb-binlog-local.md | 2 +- .../tidb-binlog/troubleshoot/binlog.md | 6 +- .../troubleshoot/error-handling.md | 2 +- .../tidb-binlog/upgrade.md | 6 +- {v3.0/reference => reference}/tispark.md | 2 +- .../data-migration/cluster-operations.md | 8 +- .../configure/dm-master-configuration-file.md | 0 .../dm-worker-configuration-file-full.md | 0 .../configure/dm-worker-configuration-file.md | 4 +- .../data-migration/configure/overview.md | 12 +- .../configure/task-configuration-file-full.md | 10 +- .../configure/task-configuration-file.md | 8 +- .../tools/data-migration/deploy.md | 6 +- .../tools/data-migration/dm-portal.md | 6 +- .../tools/data-migration/dm-upgrade.md | 2 +- .../tools/data-migration/dm-worker-intro.md | 0 .../tools/data-migration/faq.md | 6 +- .../manually-handling-sharding-ddl-locks.md | 6 +- .../tools/data-migration/features/overview.md | 10 +- .../data-migration/features/shard-merge.md | 4 +- .../tools/data-migration/from-aurora.md | 6 +- .../tools/data-migration/glossary.md | 16 +- .../tools/data-migration/manage-tasks.md | 27 +- .../tools/data-migration/monitor.md | 2 +- .../tools/data-migration/overview.md | 29 +- .../tools/data-migration/precheck.md | 2 +- .../tools/data-migration/query-status.md | 2 +- .../tools/data-migration/relay-log.md | 0 .../tools/data-migration/releases/1.0.2.md | 0 .../tools/data-migration/releases/1.0.3.md | 0 .../tools/data-migration/skip-replace-sqls.md | 6 +- .../tools/data-migration/table-selector.md | 0 .../tools/data-migration/troubleshoot/dm.md | 4 +- .../troubleshoot/error-handling.md | 8 +- .../troubleshoot/error-system.md | 0 .../usage-scenarios/best-practice-dm-shard.md | 12 +- .../usage-scenarios/master-slave-switch.md | 0 .../usage-scenarios/shard-merge.md | 14 +- .../usage-scenarios/simple-synchronization.md | 12 +- .../reference => reference}/tools/download.md | 10 +- .../lightning-misuse-handling.md | 4 +- .../load-misuse-handling.md | 4 +- {v3.0/reference => reference}/tools/loader.md | 2 +- .../reference => reference}/tools/mydumper.md | 4 +- .../tools/pd-control.md | 0 .../tools/pd-recover.md | 0 .../tools/sync-diff-inspector/overview.md | 6 +- .../tools/sync-diff-inspector/route-diff.md | 0 .../tools/sync-diff-inspector/shard-diff.md | 0 .../tools/sync-diff-inspector/tidb-diff.md | 0 {v3.0/reference => reference}/tools/syncer.md | 4 +- .../tools/tidb-control.md | 0 .../tools/tidb-lightning/checkpoints.md | 0 .../tools/tidb-lightning/config.md | 4 +- .../tools/tidb-lightning/csv.md | 0 .../tools/tidb-lightning/deployment.md | 20 +- .../tools/tidb-lightning/glossary.md | 18 +- .../tools/tidb-lightning/monitor.md | 0 .../tools/tidb-lightning/overview.md | 4 +- .../tools/tidb-lightning/table-filter.md | 0 .../tools/tidb-lightning/tidb-backend.md | 4 +- .../tools/tidb-lightning/web.md | 2 +- .../tools/tikv-control.md | 0 .../tools/user-guide.md | 22 +- .../transactions/overview.md | 4 +- .../transactions/transaction-isolation.md | 4 +- .../transactions/transaction-optimistic.md | 8 +- .../transactions/transaction-pessimistic.md | 0 {v3.0/releases => releases}/11alpha.md | 0 {v3.0/releases => releases}/11beta.md | 0 {v3.0/releases => releases}/2.0.10.md | 0 {v3.0/releases => releases}/2.0.11.md | 0 {v3.0/releases => releases}/2.0ga.md | 0 {v3.0/releases => releases}/2.1.1.md | 0 {v3.0/releases => releases}/2.1.10.md | 0 {v3.0/releases => releases}/2.1.11.md | 0 {v3.0/releases => releases}/2.1.12.md | 0 {dev/releases => releases}/2.1.13.md | 0 {dev/releases => releases}/2.1.14.md | 0 {dev/releases => releases}/2.1.15.md | 0 {dev/releases => releases}/2.1.16.md | 0 {dev/releases => releases}/2.1.17.md | 0 {v3.0/releases => releases}/2.1.18.md | 0 {dev/releases => releases}/2.1.19.md | 0 {v3.0/releases => releases}/2.1.2.md | 0 {v3.0/releases => releases}/2.1.3.md | 0 {v3.0/releases => releases}/2.1.4.md | 0 {v3.0/releases => releases}/2.1.5.md | 0 {v3.0/releases => releases}/2.1.6.md | 0 {v3.0/releases => releases}/2.1.7.md | 0 {v3.0/releases => releases}/2.1.8.md | 0 {v3.0/releases => releases}/2.1.9.md | 0 {v3.0/releases => releases}/2.1ga.md | 0 {v3.0/releases => releases}/201.md | 0 {v3.0/releases => releases}/202.md | 0 {v3.0/releases => releases}/203.md | 0 {v3.0/releases => releases}/204.md | 0 {v3.0/releases => releases}/205.md | 0 {v3.0/releases => releases}/206.md | 0 {v3.0/releases => releases}/207.md | 0 {v3.0/releases => releases}/208.md | 0 {v3.0/releases => releases}/209.md | 0 {v3.0/releases => releases}/21beta.md | 0 {v3.0/releases => releases}/21rc1.md | 0 {v3.0/releases => releases}/21rc2.md | 0 {v3.0/releases => releases}/21rc3.md | 0 {v3.0/releases => releases}/21rc4.md | 0 {v3.0/releases => releases}/21rc5.md | 2 +- {v3.0/releases => releases}/2rc1.md | 0 {v3.0/releases => releases}/2rc3.md | 0 {v3.0/releases => releases}/2rc4.md | 0 {v3.0/releases => releases}/2rc5.md | 0 {v2.1/releases => releases}/3.0-ga.md | 0 {v3.0/releases => releases}/3.0.0-beta.1.md | 0 {v3.0/releases => releases}/3.0.0-rc.1.md | 0 {v3.0/releases => releases}/3.0.0-rc.2.md | 0 {v2.1/releases => releases}/3.0.0-rc.3.md | 0 {dev/releases => releases}/3.0.1.md | 0 {dev/releases => releases}/3.0.10.md | 0 {v3.0/releases => releases}/3.0.2.md | 0 {dev/releases => releases}/3.0.3.md | 0 {dev/releases => releases}/3.0.4.md | 0 {dev/releases => releases}/3.0.5.md | 0 {dev/releases => releases}/3.0.6.md | 0 {dev/releases => releases}/3.0.7.md | 0 {v3.1/releases => releases}/3.0.8.md | 1 + {dev/releases => releases}/3.0.9.md | 0 {v3.0/releases => releases}/3.0beta.md | 0 {v3.0/releases => releases}/ga.md | 0 {v3.0/releases => releases}/prega.md | 0 {v3.0/releases => releases}/rc1.md | 0 {v3.0/releases => releases}/rc2.md | 0 {v3.0/releases => releases}/rc3.md | 0 {v3.0/releases => releases}/rc4.md | 0 releases/rn.md | 87 ++ v3.0/report-issue.md => report-issue.md | 0 v2.1/roadmap.md => roadmap.md | 0 ...pport-resources.md => support-resources.md | 0 .../deploy/access-tidb.md | 0 .../deploy/alibaba-cloud.md | 2 +- .../deploy/aws-eks.md | 2 +- .../deploy/gcp-gke.md | 0 .../deploy/general-kubernetes.md | 10 +- .../deploy/prerequisites.md | 2 +- .../deploy/tidb-operator.md | 10 +- .../faq.md | 10 +- .../deploy-tidb-from-kubernetes-gke.md | 2 +- .../deploy-tidb-from-kubernetes-kind.md | 8 +- .../deploy-tidb-from-kubernetes-minikube.md | 2 +- .../initialize-cluster.md | 0 .../maintain/auto-failover.md | 0 .../maintain/backup-and-restore.md | 10 +- .../maintain/destroy-tidb-cluster.md | 0 .../maintain/kubernetes-node.md | 2 +- .../maintain/lightning.md | 2 +- .../maintain/log-collecting.md | 0 .../maintain/restart.md | 0 .../maintain/tidb-binlog.md | 8 +- .../monitor/tidb-in-kubernetes.md | 2 +- .../reference/configuration/backup.md | 2 +- .../reference/configuration/storage-class.md | 2 +- .../reference/configuration/tidb-cluster.md | 8 +- .../reference/configuration/tidb-drainer.md | 2 +- .../reference/tools/in-kubernetes.md | 8 +- .../reference/tools/tkctl.md | 0 .../scale-in-kubernetes.md | 2 +- .../tidb-operator-overview.md | 42 +- .../troubleshoot.md | 4 +- .../upgrade/tidb-cluster.md | 2 +- .../upgrade/tidb-operator.md | 0 v2.1/TOC.md | 397 ------ v2.1/_index.md | 63 - v2.1/architecture.md | 28 - v2.1/benchmark/how-to-run-sysbench.md | 251 ---- v2.1/benchmark/sysbench-v2.md | 129 -- v2.1/benchmark/sysbench-v3.md | 142 -- v2.1/benchmark/sysbench.md | 210 --- v2.1/benchmark/tpch-v2.md | 104 -- v2.1/benchmark/tpch.md | 107 -- v2.1/contribute.md | 31 - v2.1/faq/tidb-lightning.md | 125 -- v2.1/faq/tidb.md | 1068 --------------- v2.1/faq/upgrade.md | 227 ---- v2.1/glossary.md | 78 -- v2.1/how-to/configure/memory-control.md | 49 - v2.1/how-to/configure/time-zone.md | 70 - .../deploy/data-migration-with-ansible.md | 527 -------- .../deploy/data-migration-with-binary.md | 306 ----- .../location-awareness.md | 91 -- .../deploy/geographic-redundancy/overview.md | 70 - .../how-to/deploy/hardware-recommendations.md | 85 -- v2.1/how-to/deploy/orchestrated/ansible.md | 963 -------------- v2.1/how-to/deploy/orchestrated/docker.md | 220 ---- .../deploy/orchestrated/offline-ansible.md | 178 --- v2.1/how-to/get-started/data-migration.md | 459 ------- .../deploy-tidb-from-docker-compose.md | 164 --- v2.1/how-to/get-started/explore-sql.md | 199 --- .../get-started/read-historical-data.md | 142 -- v2.1/how-to/get-started/tidb-binlog.md | 416 ------ v2.1/how-to/get-started/tidb-lightning.md | 120 -- v2.1/how-to/get-started/tispark.md | 173 --- v2.1/how-to/maintain/ansible-operations.md | 38 - v2.1/how-to/maintain/backup-and-restore.md | 175 --- v2.1/how-to/maintain/identify-slow-queries.md | 305 ----- v2.1/how-to/migrate/from-aurora.md | 203 --- v2.1/how-to/migrate/from-mysql.md | 97 -- .../migrate/incrementally-from-mysql.md | 213 --- v2.1/how-to/migrate/overview.md | 53 - v2.1/how-to/monitor/monitor-a-cluster.md | 186 --- v2.1/how-to/monitor/overview.md | 18 - v2.1/how-to/scale/horizontally.md | 117 -- v2.1/how-to/scale/with-ansible.md | 475 ------- .../secure/enable-tls-between-components.md | 123 -- v2.1/how-to/secure/enable-tls-clients.md | 146 --- .../generate-self-signed-certificates.md | 154 --- v2.1/how-to/troubleshoot/cluster-setup.md | 147 --- v2.1/how-to/troubleshoot/tidb-lightning.md | 118 -- v2.1/how-to/upgrade/from-previous-version.md | 154 --- v2.1/key-features.md | 28 - v2.1/overview.md | 63 - v2.1/reference/alert-rules.md | 1168 ----------------- .../best-practices/grafana-monitor.md | 206 --- v2.1/reference/best-practices/haproxy.md | 227 ---- v2.1/reference/best-practices/java-app.md | 333 ----- .../best-practices/massive-regions.md | 133 -- .../reference/best-practices/pd-scheduling.md | 271 ---- .../configuration/pd-server/configuration.md | 104 -- .../tidb-server/configuration-file.md | 334 ----- .../tidb-server/configuration.md | 136 -- .../tidb-server/mysql-variables.md | 121 -- .../tidb-server/tidb-specific-variables.md | 429 ------ .../tikv-server/configuration.md | 60 - v2.1/reference/error-codes.md | 31 - v2.1/reference/garbage-collection.md | 79 -- .../overview-dashboard.md | 87 -- .../key-monitoring-metrics/pd-dashboard.md | 128 -- .../key-monitoring-metrics/tidb-dashboard.md | 94 -- .../key-monitoring-metrics/tikv-dashboard.md | 429 ------ v2.1/reference/mysql-compatibility.md | 192 --- v2.1/reference/performance/optimizer-hints.md | 51 - .../performance/sql-optimizer-overview.md | 26 - v2.1/reference/performance/statistics.md | 203 --- v2.1/reference/performance/tune-tikv.md | 239 ---- .../understanding-the-query-execution-plan.md | 141 -- v2.1/reference/security/compatibility.md | 17 - v2.1/reference/security/privilege-system.md | 481 ------- .../security/user-account-management.md | 232 ---- v2.1/reference/sql/character-set.md | 223 ---- v2.1/reference/sql/constraints.md | 150 --- .../sql/data-types/default-values.md | 26 - v2.1/reference/sql/data-types/json.md | 25 - v2.1/reference/sql/data-types/numeric.md | 200 --- v2.1/reference/sql/data-types/overview.md | 15 - v2.1/reference/sql/data-types/string.md | 200 --- .../aggregate-group-by-functions.md | 124 -- .../bit-functions-and-operators.md | 20 - .../cast-functions-and-operators.md | 17 - .../control-flow-functions.md | 13 - .../date-and-time-functions.md | 73 -- .../encryption-and-compression-functions.md | 28 - .../information-functions.md | 24 - .../functions-and-operators/json-functions.md | 84 -- .../miscellaneous-functions.md | 23 - .../numeric-functions-and-operators.md | 53 - .../sql/functions-and-operators/operators.md | 124 -- .../functions-and-operators/precision-math.md | 142 -- .../sql/functions-and-operators/reference.md | 12 - .../string-functions.md | 71 - .../type-conversion.md | 8 - v2.1/reference/sql/generated-columns.md | 90 -- .../sql/language-structure/comment-syntax.md | 89 -- .../language-structure/expression-syntax.md | 67 - .../keywords-and-reserved-words.md | 445 ------- .../sql/language-structure/literal-values.md | 240 ---- .../language-structure/schema-object-names.md | 77 -- .../user-defined-variables.md | 130 -- v2.1/reference/sql/statements/add-column.md | 82 -- v2.1/reference/sql/statements/add-index.md | 80 -- v2.1/reference/sql/statements/admin.md | 109 -- .../sql/statements/alter-database.md | 26 - v2.1/reference/sql/statements/alter-table.md | 75 -- v2.1/reference/sql/statements/alter-user.md | 59 - .../reference/sql/statements/analyze-table.md | 69 - v2.1/reference/sql/statements/begin.md | 43 - .../reference/sql/statements/change-column.md | 74 -- v2.1/reference/sql/statements/commit.md | 45 - .../sql/statements/create-database.md | 79 -- v2.1/reference/sql/statements/create-index.md | 101 -- .../sql/statements/create-table-like.md | 61 - v2.1/reference/sql/statements/create-table.md | 266 ---- v2.1/reference/sql/statements/create-user.md | 56 - v2.1/reference/sql/statements/deallocate.md | 53 - v2.1/reference/sql/statements/delete.md | 63 - v2.1/reference/sql/statements/desc.md | 9 - v2.1/reference/sql/statements/describe.md | 9 - v2.1/reference/sql/statements/do.md | 49 - v2.1/reference/sql/statements/drop-column.md | 89 -- .../reference/sql/statements/drop-database.md | 64 - v2.1/reference/sql/statements/drop-index.md | 74 -- v2.1/reference/sql/statements/drop-table.md | 56 - v2.1/reference/sql/statements/drop-user.md | 71 - v2.1/reference/sql/statements/execute.md | 49 - .../sql/statements/explain-analyze.md | 62 - v2.1/reference/sql/statements/explain.md | 158 --- .../sql/statements/flush-privileges.md | 40 - v2.1/reference/sql/statements/flush-status.md | 77 -- v2.1/reference/sql/statements/flush-tables.md | 54 - .../sql/statements/grant-privileges.md | 70 - v2.1/reference/sql/statements/insert.md | 100 -- v2.1/reference/sql/statements/kill.md | 41 - v2.1/reference/sql/statements/load-data.md | 51 - .../reference/sql/statements/modify-column.md | 76 -- v2.1/reference/sql/statements/prepare.md | 45 - v2.1/reference/sql/statements/rename-index.md | 62 - v2.1/reference/sql/statements/rename-table.md | 55 - v2.1/reference/sql/statements/replace.md | 76 -- .../sql/statements/revoke-privileges.md | 85 -- v2.1/reference/sql/statements/rollback.md | 44 - v2.1/reference/sql/statements/select.md | 112 -- v2.1/reference/sql/statements/set-names.md | 80 -- v2.1/reference/sql/statements/set-password.md | 64 - .../sql/statements/set-transaction.md | 68 - v2.1/reference/sql/statements/set-variable.md | 73 -- .../sql/statements/show-character-set.md | 47 - .../sql/statements/show-collation.md | 259 ---- .../sql/statements/show-columns-from.md | 124 -- .../sql/statements/show-create-table.md | 47 - .../sql/statements/show-databases.md | 61 - v2.1/reference/sql/statements/show-engines.md | 31 - v2.1/reference/sql/statements/show-errors.md | 59 - .../sql/statements/show-fields-from.md | 9 - v2.1/reference/sql/statements/show-grants.md | 56 - v2.1/reference/sql/statements/show-index.md | 9 - v2.1/reference/sql/statements/show-indexes.md | 75 -- v2.1/reference/sql/statements/show-keys.md | 9 - .../sql/statements/show-privileges.md | 67 - .../sql/statements/show-processlist.md | 40 - v2.1/reference/sql/statements/show-schemas.md | 9 - v2.1/reference/sql/statements/show-status.md | 61 - .../sql/statements/show-table-regions.md | 106 -- .../sql/statements/show-table-status.md | 92 -- v2.1/reference/sql/statements/show-tables.md | 86 -- .../sql/statements/show-variables.md | 103 -- .../reference/sql/statements/show-warnings.md | 87 -- v2.1/reference/sql/statements/split-region.md | 204 --- .../sql/statements/start-transaction.md | 43 - v2.1/reference/sql/statements/trace.md | 143 -- v2.1/reference/sql/statements/truncate.md | 72 - v2.1/reference/sql/statements/update.md | 77 -- v2.1/reference/sql/statements/use.md | 79 -- v2.1/reference/supported-clients.md | 91 -- .../system-databases/information-schema.md | 461 ------- v2.1/reference/system-databases/mysql.md | 36 - .../tidb-binlog/binlog-slave-client.md | 148 --- v2.1/reference/tidb-binlog/deploy.md | 568 -------- v2.1/reference/tidb-binlog/faq.md | 212 --- v2.1/reference/tidb-binlog/maintain.md | 257 ---- v2.1/reference/tidb-binlog/monitor.md | 164 --- v2.1/reference/tidb-binlog/overview.md | 59 - v2.1/reference/tidb-binlog/reparo.md | 110 -- .../tidb-binlog/tidb-binlog-kafka.md | 426 ------ .../tidb-binlog/tidb-binlog-local.md | 283 ---- .../tidb-binlog/troubleshoot/binlog.md | 19 - .../troubleshoot/error-handling.md | 32 - v2.1/reference/tidb-binlog/upgrade.md | 83 -- v2.1/reference/tispark.md | 274 ---- .../data-migration/cluster-operations.md | 412 ------ .../configure/dm-master-configuration-file.md | 47 - .../dm-worker-configuration-file-full.md | 110 -- .../configure/dm-worker-configuration-file.md | 67 - .../data-migration/configure/overview.md | 37 - .../configure/task-configuration-file-full.md | 165 --- .../configure/task-configuration-file.md | 82 -- v2.1/reference/tools/data-migration/deploy.md | 179 --- .../tools/data-migration/dm-portal.md | 220 ---- .../tools/data-migration/dm-upgrade.md | 161 --- .../tools/data-migration/dm-worker-intro.md | 95 -- v2.1/reference/tools/data-migration/faq.md | 52 - .../manually-handling-sharding-ddl-locks.md | 470 ------- .../tools/data-migration/features/overview.md | 503 ------- .../data-migration/features/shard-merge.md | 177 --- .../tools/data-migration/from-aurora.md | 202 --- .../tools/data-migration/glossary.md | 124 -- .../tools/data-migration/manage-tasks.md | 956 -------------- .../reference/tools/data-migration/monitor.md | 119 -- .../tools/data-migration/overview.md | 101 -- .../tools/data-migration/precheck.md | 63 - .../tools/data-migration/query-status.md | 260 ---- .../tools/data-migration/relay-log.md | 155 --- .../tools/data-migration/releases/1.0.2.md | 47 - .../tools/data-migration/releases/1.0.3.md | 38 - .../tools/data-migration/skip-replace-sqls.md | 610 --------- .../tools/data-migration/table-selector.md | 44 - .../tools/data-migration/troubleshoot/dm.md | 27 - .../troubleshoot/error-handling.md | 71 - .../troubleshoot/error-system.md | 113 -- .../usage-scenarios/best-practice-dm-shard.md | 131 -- .../usage-scenarios/master-slave-switch.md | 55 - .../usage-scenarios/shard-merge.md | 228 ---- .../usage-scenarios/simple-synchronization.md | 243 ---- v2.1/reference/tools/download.md | 63 - v2.1/reference/tools/loader.md | 150 --- v2.1/reference/tools/mydumper.md | 189 --- v2.1/reference/tools/pd-control.md | 750 ----------- v2.1/reference/tools/pd-recover.md | 39 - .../tools/sync-diff-inspector/overview.md | 219 ---- .../tools/sync-diff-inspector/route-diff.md | 63 - .../tools/sync-diff-inspector/shard-diff.md | 115 -- .../tools/sync-diff-inspector/tidb-diff.md | 56 - v2.1/reference/tools/syncer.md | 561 -------- v2.1/reference/tools/tidb-control.md | 173 --- .../tools/tidb-lightning/checkpoints.md | 109 -- v2.1/reference/tools/tidb-lightning/config.md | 314 ----- v2.1/reference/tools/tidb-lightning/csv.md | 208 --- .../tools/tidb-lightning/deployment.md | 271 ---- .../tools/tidb-lightning/glossary.md | 187 --- .../reference/tools/tidb-lightning/monitor.md | 301 ----- .../tools/tidb-lightning/overview.md | 40 - .../tools/tidb-lightning/table-filter.md | 127 -- v2.1/reference/tools/tidb-lightning/web.md | 82 -- v2.1/reference/tools/tikv-control.md | 279 ---- .../transactions/transaction-isolation.md | 55 - .../transactions/transaction-optimistic.md | 174 --- v2.1/releases/11alpha.md | 52 - v2.1/releases/11beta.md | 49 - v2.1/releases/2.0.10.md | 39 - v2.1/releases/2.0.11.md | 21 - v2.1/releases/2.0ga.md | 156 --- v2.1/releases/2.1.1.md | 46 - v2.1/releases/2.1.10.md | 60 - v2.1/releases/2.1.11.md | 45 - v2.1/releases/2.1.12.md | 43 - v2.1/releases/2.1.13.md | 38 - v2.1/releases/2.1.14.md | 55 - v2.1/releases/2.1.15.md | 52 - v2.1/releases/2.1.16.md | 66 - v2.1/releases/2.1.17.md | 93 -- v2.1/releases/2.1.18.md | 76 -- v2.1/releases/2.1.19.md | 93 -- v2.1/releases/2.1.2.md | 38 - v2.1/releases/2.1.3.md | 57 - v2.1/releases/2.1.4.md | 40 - v2.1/releases/2.1.5.md | 54 - v2.1/releases/2.1.6.md | 38 - v2.1/releases/2.1.7.md | 41 - v2.1/releases/2.1.8.md | 64 - v2.1/releases/2.1.9.md | 69 - v2.1/releases/2.1ga.md | 187 --- v2.1/releases/201.md | 50 - v2.1/releases/202.md | 30 - v2.1/releases/203.md | 37 - v2.1/releases/204.md | 41 - v2.1/releases/205.md | 40 - v2.1/releases/206.md | 49 - v2.1/releases/207.md | 36 - v2.1/releases/208.md | 29 - v2.1/releases/209.md | 46 - v2.1/releases/21beta.md | 85 -- v2.1/releases/21rc1.md | 155 --- v2.1/releases/21rc2.md | 119 -- v2.1/releases/21rc3.md | 63 - v2.1/releases/21rc4.md | 54 - v2.1/releases/21rc5.md | 63 - v2.1/releases/2rc1.md | 39 - v2.1/releases/2rc3.md | 59 - v2.1/releases/2rc4.md | 38 - v2.1/releases/2rc5.md | 48 - v2.1/releases/3.0.0-beta.1.md | 108 -- v2.1/releases/3.0.0-rc.1.md | 141 -- v2.1/releases/3.0.0-rc.2.md | 121 -- v2.1/releases/3.0.1.md | 91 -- v2.1/releases/3.0beta.md | 107 -- v2.1/releases/ga.md | 277 ---- v2.1/releases/prega.md | 39 - v2.1/releases/rc1.md | 41 - v2.1/releases/rc2.md | 52 - v2.1/releases/rc3.md | 53 - v2.1/releases/rc4.md | 48 - v2.1/releases/rn.md | 77 -- v2.1/report-issue.md | 17 - v2.1/support-resources.md | 15 - .../tispark/tispark-quick-start-guide_v1.x.md | 188 --- v2.1/tispark/tispark-user-guide_v1.x.md | 187 --- v3.0/TOC.md | 482 ------- v3.0/_index.md | 12 +- v3.0/architecture.md | 32 - v3.0/benchmark/add-index-with-load.md | 348 ----- v3.0/benchmark/dm-v1.0-ga.md | 206 --- v3.0/benchmark/how-to-run-tpcc.md | 258 ---- v3.0/benchmark/sysbench-in-k8s.md | 449 ------- v3.0/benchmark/tpcc.md | 97 -- v3.0/glossary.md | 78 -- .../deploy/data-migration-with-binary.md | 306 ----- v3.0/how-to/get-started/data-migration.md | 523 -------- v3.0/how-to/get-started/tidb-lightning.md | 120 -- v3.0/how-to/get-started/tispark.md | 212 --- .../identify-aborted-queries.md | 52 - v3.0/overview.md | 66 - v3.0/reference/alert-rules.md | 1161 ---------------- .../best-practices/grafana-monitor.md | 206 --- v3.0/reference/best-practices/haproxy.md | 227 ---- .../best-practices/massive-regions.md | 143 -- .../reference/best-practices/pd-scheduling.md | 271 ---- .../pd-server/configuration-file.md | 265 ---- .../garbage-collection/configuration.md | 125 -- .../key-monitoring-metrics/tidb-dashboard.md | 139 -- v3.0/reference/mysql-compatibility.md | 226 ---- ...eck-cluster-status-using-sql-statements.md | 27 - .../performance/statement-summary.md | 260 ---- .../security/cert-based-authentication.md | 483 ------- .../security/role-based-access-control.md | 386 ------ .../reference/sql/data-types/date-and-time.md | 64 - .../sql/data-types/default-values.md | 26 - v3.0/reference/sql/data-types/json.md | 25 - v3.0/reference/sql/data-types/numeric.md | 200 --- v3.0/reference/sql/data-types/string.md | 200 --- .../expressions-pushed-down.md | 145 -- .../window-functions.md | 24 - v3.0/reference/sql/partitioning.md | 913 ------------- v3.0/reference/sql/statements/add-column.md | 129 -- v3.0/reference/sql/statements/add-index.md | 113 -- .../sql/statements/alter-database.md | 28 - v3.0/reference/sql/statements/alter-table.md | 108 -- v3.0/reference/sql/statements/alter-user.md | 84 -- .../reference/sql/statements/analyze-table.md | 109 -- v3.0/reference/sql/statements/begin.md | 69 - .../reference/sql/statements/change-column.md | 121 -- v3.0/reference/sql/statements/commit.md | 71 - .../sql/statements/create-database.md | 108 -- v3.0/reference/sql/statements/create-index.md | 148 --- .../sql/statements/create-table-like.md | 94 -- v3.0/reference/sql/statements/create-user.md | 69 - v3.0/reference/sql/statements/create-view.md | 160 --- v3.0/reference/sql/statements/deallocate.md | 79 -- v3.0/reference/sql/statements/delete.md | 96 -- v3.0/reference/sql/statements/desc.md | 9 - v3.0/reference/sql/statements/describe.md | 9 - v3.0/reference/sql/statements/do.md | 68 - v3.0/reference/sql/statements/drop-column.md | 137 -- .../reference/sql/statements/drop-database.md | 83 -- v3.0/reference/sql/statements/drop-index.md | 114 -- v3.0/reference/sql/statements/drop-table.md | 98 -- v3.0/reference/sql/statements/drop-user.md | 133 -- v3.0/reference/sql/statements/drop-view.md | 130 -- v3.0/reference/sql/statements/execute.md | 75 -- .../sql/statements/explain-analyze.md | 88 -- .../sql/statements/flush-privileges.md | 45 - v3.0/reference/sql/statements/flush-status.md | 103 -- v3.0/reference/sql/statements/flush-tables.md | 66 - .../sql/statements/grant-privileges.md | 89 -- v3.0/reference/sql/statements/insert.md | 161 --- v3.0/reference/sql/statements/kill.md | 53 - .../reference/sql/statements/modify-column.md | 125 -- v3.0/reference/sql/statements/rename-index.md | 88 -- v3.0/reference/sql/statements/rename-table.md | 81 -- v3.0/reference/sql/statements/replace.md | 109 -- .../sql/statements/revoke-privileges.md | 132 -- v3.0/reference/sql/statements/rollback.md | 77 -- v3.0/reference/sql/statements/set-names.md | 113 -- v3.0/reference/sql/statements/set-password.md | 110 -- .../sql/statements/set-transaction.md | 101 -- v3.0/reference/sql/statements/set-variable.md | 120 -- .../sql/statements/show-character-set.md | 52 - .../sql/statements/show-collation.md | 264 ---- .../sql/statements/show-columns-from.md | 178 --- .../sql/statements/show-create-table.md | 59 - .../sql/statements/show-create-user.md | 53 - .../sql/statements/show-databases.md | 80 -- v3.0/reference/sql/statements/show-engines.md | 36 - v3.0/reference/sql/statements/show-errors.md | 102 -- .../sql/statements/show-fields-from.md | 9 - v3.0/reference/sql/statements/show-grants.md | 91 -- v3.0/reference/sql/statements/show-index.md | 9 - v3.0/reference/sql/statements/show-indexes.md | 101 -- v3.0/reference/sql/statements/show-keys.md | 9 - .../sql/statements/show-privileges.md | 72 - .../sql/statements/show-processlist.md | 45 - v3.0/reference/sql/statements/show-schemas.md | 9 - v3.0/reference/sql/statements/show-status.md | 73 -- .../sql/statements/show-table-status.md | 125 -- v3.0/reference/sql/statements/show-tables.md | 86 -- .../reference/sql/statements/show-warnings.md | 155 --- v3.0/reference/sql/statements/split-region.md | 200 --- .../sql/statements/start-transaction.md | 69 - v3.0/reference/sql/statements/trace.md | 169 --- v3.0/reference/sql/statements/truncate.md | 119 -- v3.0/reference/sql/statements/update.md | 110 -- v3.0/reference/sql/statements/use.md | 128 -- v3.0/reference/sql/view.md | 108 -- v3.0/reference/tidb-binlog/glossary.md | 29 - .../troubleshoot/error-handling.md | 32 - .../configure/dm-master-configuration-file.md | 47 - .../dm-worker-configuration-file-full.md | 110 -- .../configure/dm-worker-configuration-file.md | 67 - .../configure/task-configuration-file-full.md | 165 --- .../tools/data-migration/dm-portal.md | 220 ---- .../tools/data-migration/glossary.md | 124 -- .../tools/data-migration/manage-tasks.md | 957 -------------- .../reference/tools/data-migration/monitor.md | 119 -- .../tools/data-migration/releases/1.0.2.md | 47 - .../tools/data-migration/releases/1.0.3.md | 38 - .../troubleshoot/error-handling.md | 71 - .../usage-scenarios/best-practice-dm-shard.md | 131 -- .../usage-scenarios/master-slave-switch.md | 55 - .../lightning-misuse-handling.md | 35 - .../tools/sync-diff-inspector/route-diff.md | 62 - .../tools/sync-diff-inspector/shard-diff.md | 115 -- .../tools/sync-diff-inspector/tidb-diff.md | 61 - v3.0/reference/tools/tidb-control.md | 271 ---- v3.0/reference/tools/tidb-lightning/config.md | 326 ----- .../tools/tidb-lightning/glossary.md | 193 --- .../reference/tools/tidb-lightning/monitor.md | 349 ----- .../tools/tidb-lightning/overview.md | 42 - .../tools/tidb-lightning/tidb-backend.md | 208 --- v3.0/reference/tools/tidb-lightning/web.md | 82 -- v3.0/reference/tools/tikv-control.md | 414 ------ v3.0/reference/transactions/overview.md | 214 --- v3.0/releases/2.1.13.md | 38 - v3.0/releases/2.1.14.md | 55 - v3.0/releases/2.1.15.md | 52 - v3.0/releases/2.1.16.md | 66 - v3.0/releases/2.1.17.md | 93 -- v3.0/releases/2.1.19.md | 93 -- v3.0/releases/3.0-ga.md | 219 ---- v3.0/releases/3.0.0-rc.3.md | 122 -- v3.0/releases/3.0.1.md | 91 -- v3.0/releases/3.0.10.md | 70 - v3.0/releases/3.0.3.md | 80 -- v3.0/releases/3.0.4.md | 128 -- v3.0/releases/3.0.5.md | 93 -- v3.0/releases/3.0.6.md | 101 -- v3.0/releases/3.0.7.md | 26 - v3.0/releases/3.0.8.md | 112 -- v3.0/releases/3.0.9.md | 53 - v3.0/releases/rn.md | 87 -- v3.0/roadmap.md | 103 -- v3.0/tidb-in-kubernetes/maintain/lightning.md | 143 -- v3.0/tidb-in-kubernetes/maintain/restart.md | 65 - .../maintain/tidb-binlog.md | 214 --- .../reference/configuration/tidb-cluster.md | 212 --- .../reference/configuration/tidb-drainer.md | 46 - v3.1/TOC.md | 489 ------- v3.1/_index.md | 63 - v3.1/architecture.md | 32 - v3.1/benchmark/add-index-with-load.md | 348 ----- v3.1/benchmark/dm-v1.0-ga.md | 206 --- v3.1/benchmark/how-to-run-sysbench.md | 277 ---- v3.1/benchmark/how-to-run-tpcc.md | 258 ---- v3.1/benchmark/sysbench-in-k8s.md | 449 ------- v3.1/benchmark/sysbench-v2.md | 129 -- v3.1/benchmark/sysbench-v3.md | 142 -- v3.1/benchmark/sysbench-v4.md | 278 ---- v3.1/benchmark/sysbench.md | 210 --- v3.1/benchmark/tpcc.md | 97 -- v3.1/benchmark/tpch-v2.md | 105 -- v3.1/benchmark/tpch.md | 108 -- v3.1/contribute.md | 31 - v3.1/faq/tidb-lightning.md | 190 --- v3.1/faq/tidb.md | 1083 --------------- v3.1/faq/upgrade.md | 328 ----- v3.1/glossary.md | 78 -- v3.1/how-to/configure/memory-control.md | 67 - v3.1/how-to/configure/time-zone.md | 109 -- .../deploy/data-migration-with-ansible.md | 570 -------- .../deploy/data-migration-with-binary.md | 306 ----- .../location-awareness.md | 95 -- .../deploy/geographic-redundancy/overview.md | 70 - .../how-to/deploy/hardware-recommendations.md | 83 -- v3.1/how-to/deploy/orchestrated/ansible.md | 965 -------------- v3.1/how-to/deploy/orchestrated/docker.md | 260 ---- .../deploy/orchestrated/offline-ansible.md | 160 --- v3.1/how-to/get-started/data-migration.md | 523 -------- .../deploy-tidb-from-docker-compose.md | 205 --- v3.1/how-to/get-started/explore-sql.md | 274 ---- .../get-started/read-historical-data.md | 194 --- v3.1/how-to/get-started/tidb-binlog.md | 520 -------- v3.1/how-to/get-started/tidb-lightning.md | 120 -- v3.1/how-to/get-started/tispark.md | 212 --- v3.1/how-to/maintain/ansible-operations.md | 46 - .../backup-and-restore/mydumper-lightning.md | 95 -- .../identify-aborted-queries.md | 52 - .../identify-slow-queries.md | 332 ----- v3.1/how-to/migrate/from-mysql-aurora.md | 208 --- v3.1/how-to/monitor/monitor-a-cluster.md | 355 ----- v3.1/how-to/monitor/overview.md | 28 - v3.1/how-to/scale/horizontally.md | 132 -- v3.1/how-to/scale/with-ansible.md | 527 -------- .../secure/enable-tls-between-components.md | 131 -- v3.1/how-to/secure/enable-tls-clients.md | 158 --- .../generate-self-signed-certificates.md | 162 --- v3.1/how-to/troubleshoot/cluster-setup.md | 149 --- v3.1/how-to/troubleshoot/tidb-lightning.md | 134 -- v3.1/how-to/upgrade/from-previous-version.md | 215 --- v3.1/key-features.md | 28 - v3.1/reference/alert-rules.md | 1161 ---------------- .../best-practices/grafana-monitor.md | 206 --- v3.1/reference/best-practices/haproxy.md | 227 ---- .../best-practices/high-concurrency.md | 203 --- v3.1/reference/best-practices/java-app.md | 332 ----- .../best-practices/massive-regions.md | 143 -- .../reference/best-practices/pd-scheduling.md | 271 ---- .../pd-server/configuration-file.md | 265 ---- .../configuration/pd-server/configuration.md | 120 -- .../tidb-server/configuration-file.md | 422 ------ .../tidb-server/configuration.md | 145 -- .../tidb-server/mysql-variables.md | 201 --- .../tidb-server/tidb-specific-variables.md | 669 ---------- .../tikv-server/configuration-file.md | 1093 --------------- .../tikv-server/configuration.md | 60 - v3.1/reference/error-codes.md | 31 - .../garbage-collection/configuration.md | 125 -- v3.1/reference/garbage-collection/overview.md | 40 - .../overview-dashboard.md | 87 -- .../key-monitoring-metrics/pd-dashboard.md | 139 -- .../key-monitoring-metrics/tidb-dashboard.md | 139 -- .../key-monitoring-metrics/tikv-dashboard.md | 429 ------ ...eck-cluster-status-using-sql-statements.md | 27 - .../performance/execution-plan-bind.md | 77 -- v3.1/reference/performance/follower-read.md | 50 - v3.1/reference/performance/optimizer-hints.md | 236 ---- .../performance/sql-optimizer-overview.md | 26 - .../performance/statement-summary.md | 260 ---- v3.1/reference/performance/statistics.md | 317 ----- v3.1/reference/performance/tune-tikv.md | 252 ---- .../understanding-the-query-execution-plan.md | 155 --- .../security/cert-based-authentication.md | 483 ------- v3.1/reference/security/compatibility.md | 17 - v3.1/reference/security/privilege-system.md | 481 ------- .../security/role-based-access-control.md | 386 ------ .../security/user-account-management.md | 232 ---- v3.1/reference/sql/character-set.md | 327 ----- v3.1/reference/sql/constraints.md | 273 ---- .../reference/sql/data-types/date-and-time.md | 64 - .../sql/data-types/default-values.md | 26 - v3.1/reference/sql/data-types/json.md | 25 - v3.1/reference/sql/data-types/numeric.md | 200 --- v3.1/reference/sql/data-types/overview.md | 15 - v3.1/reference/sql/data-types/string.md | 200 --- .../aggregate-group-by-functions.md | 157 --- .../bit-functions-and-operators.md | 20 - .../cast-functions-and-operators.md | 16 - .../control-flow-functions.md | 15 - .../date-and-time-functions.md | 73 -- .../encryption-and-compression-functions.md | 38 - .../expressions-pushed-down.md | 145 -- .../information-functions.md | 32 - .../functions-and-operators/json-functions.md | 84 -- .../miscellaneous-functions.md | 36 - .../numeric-functions-and-operators.md | 55 - .../sql/functions-and-operators/operators.md | 124 -- .../functions-and-operators/precision-math.md | 170 --- .../sql/functions-and-operators/reference.md | 12 - .../string-functions.md | 73 -- .../type-conversion.md | 8 - .../window-functions.md | 24 - v3.1/reference/sql/generated-columns.md | 99 -- .../sql/language-structure/comment-syntax.md | 124 -- .../language-structure/expression-syntax.md | 67 - .../keywords-and-reserved-words.md | 483 ------- .../sql/language-structure/literal-values.md | 283 ---- .../language-structure/schema-object-names.md | 109 -- .../user-defined-variables.md | 245 ---- v3.1/reference/sql/partitioning.md | 913 ------------- v3.1/reference/sql/sql-mode.md | 56 - v3.1/reference/sql/statements/add-column.md | 129 -- v3.1/reference/sql/statements/add-index.md | 113 -- v3.1/reference/sql/statements/admin.md | 109 -- .../sql/statements/alter-database.md | 28 - v3.1/reference/sql/statements/alter-table.md | 108 -- v3.1/reference/sql/statements/alter-user.md | 84 -- .../reference/sql/statements/analyze-table.md | 109 -- v3.1/reference/sql/statements/begin.md | 69 - .../reference/sql/statements/change-column.md | 121 -- v3.1/reference/sql/statements/commit.md | 71 - .../sql/statements/create-database.md | 108 -- v3.1/reference/sql/statements/create-index.md | 148 --- .../sql/statements/create-table-like.md | 94 -- v3.1/reference/sql/statements/create-table.md | 303 ----- v3.1/reference/sql/statements/create-user.md | 69 - v3.1/reference/sql/statements/create-view.md | 160 --- v3.1/reference/sql/statements/deallocate.md | 79 -- v3.1/reference/sql/statements/delete.md | 96 -- v3.1/reference/sql/statements/desc.md | 9 - v3.1/reference/sql/statements/describe.md | 9 - v3.1/reference/sql/statements/do.md | 68 - v3.1/reference/sql/statements/drop-column.md | 137 -- .../reference/sql/statements/drop-database.md | 83 -- v3.1/reference/sql/statements/drop-index.md | 114 -- v3.1/reference/sql/statements/drop-table.md | 98 -- v3.1/reference/sql/statements/drop-user.md | 133 -- v3.1/reference/sql/statements/drop-view.md | 130 -- v3.1/reference/sql/statements/execute.md | 75 -- .../sql/statements/explain-analyze.md | 88 -- v3.1/reference/sql/statements/explain.md | 223 ---- .../sql/statements/flush-privileges.md | 45 - v3.1/reference/sql/statements/flush-status.md | 103 -- v3.1/reference/sql/statements/flush-tables.md | 66 - .../sql/statements/grant-privileges.md | 89 -- v3.1/reference/sql/statements/insert.md | 161 --- v3.1/reference/sql/statements/kill.md | 53 - v3.1/reference/sql/statements/load-data.md | 62 - .../reference/sql/statements/modify-column.md | 125 -- v3.1/reference/sql/statements/prepare.md | 71 - .../reference/sql/statements/recover-table.md | 109 -- v3.1/reference/sql/statements/rename-index.md | 88 -- v3.1/reference/sql/statements/rename-table.md | 81 -- v3.1/reference/sql/statements/replace.md | 109 -- .../sql/statements/revoke-privileges.md | 132 -- v3.1/reference/sql/statements/rollback.md | 77 -- v3.1/reference/sql/statements/select.md | 131 -- v3.1/reference/sql/statements/set-names.md | 113 -- v3.1/reference/sql/statements/set-password.md | 110 -- .../sql/statements/set-transaction.md | 101 -- v3.1/reference/sql/statements/set-variable.md | 120 -- .../sql/statements/show-character-set.md | 52 - .../sql/statements/show-collation.md | 264 ---- .../sql/statements/show-columns-from.md | 178 --- .../sql/statements/show-create-table.md | 59 - .../sql/statements/show-create-user.md | 53 - .../sql/statements/show-databases.md | 80 -- v3.1/reference/sql/statements/show-engines.md | 36 - v3.1/reference/sql/statements/show-errors.md | 102 -- .../sql/statements/show-fields-from.md | 9 - v3.1/reference/sql/statements/show-grants.md | 91 -- v3.1/reference/sql/statements/show-index.md | 9 - v3.1/reference/sql/statements/show-indexes.md | 101 -- v3.1/reference/sql/statements/show-keys.md | 9 - .../sql/statements/show-privileges.md | 72 - .../sql/statements/show-processlist.md | 45 - v3.1/reference/sql/statements/show-schemas.md | 9 - v3.1/reference/sql/statements/show-status.md | 73 -- .../sql/statements/show-table-regions.md | 119 -- .../sql/statements/show-table-status.md | 125 -- v3.1/reference/sql/statements/show-tables.md | 86 -- .../sql/statements/show-variables.md | 130 -- .../reference/sql/statements/show-warnings.md | 155 --- v3.1/reference/sql/statements/split-region.md | 200 --- .../sql/statements/start-transaction.md | 69 - v3.1/reference/sql/statements/trace.md | 169 --- v3.1/reference/sql/statements/truncate.md | 119 -- v3.1/reference/sql/statements/update.md | 110 -- v3.1/reference/sql/statements/use.md | 128 -- v3.1/reference/sql/view.md | 108 -- v3.1/reference/supported-clients.md | 91 -- .../system-databases/information-schema.md | 756 ----------- v3.1/reference/system-databases/mysql.md | 36 - .../tidb-binlog/binlog-slave-client.md | 147 --- v3.1/reference/tidb-binlog/deploy.md | 627 --------- v3.1/reference/tidb-binlog/faq.md | 209 --- v3.1/reference/tidb-binlog/glossary.md | 29 - v3.1/reference/tidb-binlog/maintain.md | 256 ---- v3.1/reference/tidb-binlog/monitor.md | 163 --- v3.1/reference/tidb-binlog/overview.md | 59 - v3.1/reference/tidb-binlog/relay-log.md | 55 - v3.1/reference/tidb-binlog/reparo.md | 110 -- .../tidb-binlog/tidb-binlog-kafka.md | 457 ------- .../tidb-binlog/tidb-binlog-local.md | 286 ---- .../tidb-binlog/troubleshoot/binlog.md | 19 - .../troubleshoot/error-handling.md | 32 - v3.1/reference/tidb-binlog/upgrade.md | 83 -- v3.1/reference/tispark.md | 333 ----- v3.1/reference/tools/br/br.md | 400 ------ v3.1/reference/tools/br/use-cases.md | 415 ------ .../data-migration/cluster-operations.md | 489 ------- .../configure/dm-master-configuration-file.md | 47 - .../dm-worker-configuration-file-full.md | 110 -- .../configure/dm-worker-configuration-file.md | 67 - .../data-migration/configure/overview.md | 37 - .../configure/task-configuration-file-full.md | 165 --- .../configure/task-configuration-file.md | 82 -- v3.1/reference/tools/data-migration/deploy.md | 186 --- .../tools/data-migration/dm-portal.md | 220 ---- .../tools/data-migration/dm-upgrade.md | 161 --- .../tools/data-migration/dm-worker-intro.md | 99 -- v3.1/reference/tools/data-migration/faq.md | 51 - .../manually-handling-sharding-ddl-locks.md | 540 -------- .../tools/data-migration/features/overview.md | 529 -------- .../data-migration/features/shard-merge.md | 177 --- .../tools/data-migration/from-aurora.md | 206 --- .../tools/data-migration/glossary.md | 124 -- .../tools/data-migration/manage-tasks.md | 956 -------------- .../reference/tools/data-migration/monitor.md | 119 -- .../tools/data-migration/overview.md | 101 -- .../tools/data-migration/precheck.md | 63 - .../tools/data-migration/query-status.md | 259 ---- .../tools/data-migration/relay-log.md | 176 --- .../tools/data-migration/releases/1.0.2.md | 47 - .../tools/data-migration/releases/1.0.3.md | 38 - .../tools/data-migration/skip-replace-sqls.md | 661 ---------- .../tools/data-migration/table-selector.md | 42 - .../tools/data-migration/troubleshoot/dm.md | 26 - .../troubleshoot/error-handling.md | 71 - .../troubleshoot/error-system.md | 113 -- .../usage-scenarios/best-practice-dm-shard.md | 131 -- .../usage-scenarios/master-slave-switch.md | 55 - .../usage-scenarios/shard-merge.md | 242 ---- .../usage-scenarios/simple-synchronization.md | 255 ---- v3.1/reference/tools/download.md | 75 -- .../lightning-misuse-handling.md | 35 - .../load-misuse-handling.md | 41 - v3.1/reference/tools/loader.md | 154 --- v3.1/reference/tools/mydumper.md | 190 --- v3.1/reference/tools/pd-control.md | 1138 ---------------- v3.1/reference/tools/pd-recover.md | 39 - .../tools/sync-diff-inspector/overview.md | 220 ---- .../tools/sync-diff-inspector/route-diff.md | 62 - .../tools/sync-diff-inspector/shard-diff.md | 115 -- .../tools/sync-diff-inspector/tidb-diff.md | 61 - v3.1/reference/tools/syncer.md | 604 --------- v3.1/reference/tools/tidb-control.md | 270 ---- .../tools/tidb-lightning/checkpoints.md | 119 -- v3.1/reference/tools/tidb-lightning/config.md | 326 ----- v3.1/reference/tools/tidb-lightning/csv.md | 208 --- .../tools/tidb-lightning/deployment.md | 280 ---- .../tools/tidb-lightning/glossary.md | 193 --- .../reference/tools/tidb-lightning/monitor.md | 349 ----- .../tools/tidb-lightning/overview.md | 42 - .../tools/tidb-lightning/table-filter.md | 131 -- .../tools/tidb-lightning/tidb-backend.md | 208 --- v3.1/reference/tools/tidb-lightning/web.md | 82 -- v3.1/reference/tools/tikv-control.md | 414 ------ v3.1/reference/tools/user-guide.md | 185 --- v3.1/reference/transactions/overview.md | 214 --- .../transactions/transaction-isolation.md | 55 - .../transactions/transaction-optimistic.md | 178 --- .../transactions/transaction-pessimistic.md | 91 -- v3.1/releases/11alpha.md | 52 - v3.1/releases/11beta.md | 49 - v3.1/releases/2.0.10.md | 39 - v3.1/releases/2.0.11.md | 21 - v3.1/releases/2.0ga.md | 156 --- v3.1/releases/2.1.1.md | 46 - v3.1/releases/2.1.10.md | 60 - v3.1/releases/2.1.11.md | 45 - v3.1/releases/2.1.12.md | 43 - v3.1/releases/2.1.13.md | 38 - v3.1/releases/2.1.14.md | 55 - v3.1/releases/2.1.15.md | 52 - v3.1/releases/2.1.16.md | 66 - v3.1/releases/2.1.17.md | 93 -- v3.1/releases/2.1.18.md | 76 -- v3.1/releases/2.1.19.md | 93 -- v3.1/releases/2.1.2.md | 38 - v3.1/releases/2.1.3.md | 57 - v3.1/releases/2.1.4.md | 40 - v3.1/releases/2.1.5.md | 54 - v3.1/releases/2.1.6.md | 38 - v3.1/releases/2.1.7.md | 41 - v3.1/releases/2.1.8.md | 64 - v3.1/releases/2.1.9.md | 69 - v3.1/releases/2.1ga.md | 187 --- v3.1/releases/201.md | 50 - v3.1/releases/202.md | 30 - v3.1/releases/203.md | 37 - v3.1/releases/204.md | 41 - v3.1/releases/205.md | 40 - v3.1/releases/206.md | 49 - v3.1/releases/207.md | 36 - v3.1/releases/208.md | 29 - v3.1/releases/209.md | 46 - v3.1/releases/21beta.md | 85 -- v3.1/releases/21rc1.md | 155 --- v3.1/releases/21rc2.md | 119 -- v3.1/releases/21rc3.md | 63 - v3.1/releases/21rc4.md | 54 - v3.1/releases/21rc5.md | 64 - v3.1/releases/2rc1.md | 39 - v3.1/releases/2rc3.md | 59 - v3.1/releases/2rc4.md | 38 - v3.1/releases/2rc5.md | 48 - v3.1/releases/3.0-ga.md | 219 ---- v3.1/releases/3.0.0-beta.1.md | 108 -- v3.1/releases/3.0.0-rc.1.md | 141 -- v3.1/releases/3.0.0-rc.2.md | 121 -- v3.1/releases/3.0.0-rc.3.md | 122 -- v3.1/releases/3.0.1.md | 91 -- v3.1/releases/3.0.10.md | 70 - v3.1/releases/3.0.2.md | 144 -- v3.1/releases/3.0.3.md | 80 -- v3.1/releases/3.0.4.md | 128 -- v3.1/releases/3.0.5.md | 93 -- v3.1/releases/3.0.6.md | 101 -- v3.1/releases/3.0.7.md | 26 - v3.1/releases/3.0.9.md | 53 - v3.1/releases/3.0beta.md | 107 -- v3.1/releases/3.1.0-beta.1.md | 39 - v3.1/releases/3.1.0-beta.md | 28 - v3.1/releases/ga.md | 277 ---- v3.1/releases/prega.md | 39 - v3.1/releases/rc1.md | 41 - v3.1/releases/rc2.md | 52 - v3.1/releases/rc3.md | 53 - v3.1/releases/rc4.md | 48 - v3.1/releases/rn.md | 91 -- v3.1/report-issue.md | 17 - v3.1/roadmap.md | 103 -- v3.1/support-resources.md | 15 - v3.1/tidb-in-kubernetes/deploy/access-tidb.md | 62 - .../deploy/alibaba-cloud.md | 352 ----- v3.1/tidb-in-kubernetes/deploy/aws-eks.md | 527 -------- v3.1/tidb-in-kubernetes/deploy/gcp-gke.md | 740 ----------- .../deploy/general-kubernetes.md | 80 -- .../deploy/prerequisites.md | 174 --- .../deploy/tidb-operator.md | 132 -- v3.1/tidb-in-kubernetes/faq.md | 98 -- .../deploy-tidb-from-kubernetes-gke.md | 304 ----- .../deploy-tidb-from-kubernetes-kind.md | 190 --- .../deploy-tidb-from-kubernetes-minikube.md | 298 ----- v3.1/tidb-in-kubernetes/initialize-cluster.md | 94 -- .../maintain/auto-failover.md | 85 -- .../maintain/backup-and-restore.md | 159 --- .../maintain/destroy-tidb-cluster.md | 34 - .../maintain/kubernetes-node.md | 239 ---- v3.1/tidb-in-kubernetes/maintain/lightning.md | 143 -- .../maintain/log-collecting.md | 90 -- v3.1/tidb-in-kubernetes/maintain/restart.md | 65 - .../maintain/tidb-binlog.md | 214 --- .../monitor/tidb-in-kubernetes.md | 97 -- .../reference/configuration/backup.md | 111 -- .../reference/configuration/storage-class.md | 279 ---- .../reference/configuration/tidb-cluster.md | 212 --- .../reference/configuration/tidb-drainer.md | 46 - .../reference/tools/in-kubernetes.md | 256 ---- .../reference/tools/tkctl.md | 395 ------ .../tidb-in-kubernetes/scale-in-kubernetes.md | 72 - .../tidb-operator-overview.md | 76 -- v3.1/tidb-in-kubernetes/troubleshoot.md | 372 ------ .../upgrade/tidb-cluster.md | 96 -- .../upgrade/tidb-operator.md | 22 - 1502 files changed, 1407 insertions(+), 172262 deletions(-) create mode 100644 TOC.md rename dev/architecture.md => architecture.md (97%) rename {dev/benchmark => benchmark}/add-index-with-load.md (100%) rename {dev/benchmark => benchmark}/dm-v1.0-ga.md (100%) rename {v3.0/benchmark => benchmark}/how-to-run-sysbench.md (95%) rename {dev/benchmark => benchmark}/how-to-run-tpcc.md (95%) rename {dev/benchmark => benchmark}/sysbench-in-k8s.md (100%) rename {v3.0/benchmark => benchmark}/sysbench-v2.md (100%) rename {v3.0/benchmark => benchmark}/sysbench-v3.md (100%) rename {v3.0/benchmark => benchmark}/sysbench-v4.md (100%) rename {v3.0/benchmark => benchmark}/sysbench.md (100%) rename {dev/benchmark => benchmark}/tpcc.md (100%) rename {v3.0/benchmark => benchmark}/tpch-v2.md (100%) rename {v3.0/benchmark => benchmark}/tpch.md (100%) rename v3.0/contribute.md => contribute.md (100%) delete mode 100644 dev/TOC.md delete mode 100755 dev/_index.md delete mode 100644 dev/benchmark/how-to-run-sysbench.md delete mode 100644 dev/benchmark/sysbench-v2.md delete mode 100644 dev/benchmark/sysbench-v3.md delete mode 100644 dev/benchmark/sysbench-v4.md delete mode 100644 dev/benchmark/sysbench.md delete mode 100644 dev/benchmark/tpch-v2.md delete mode 100644 dev/benchmark/tpch.md delete mode 100644 dev/contribute.md delete mode 100644 dev/faq/tidb-lightning.md delete mode 100755 dev/faq/tidb.md delete mode 100644 dev/faq/upgrade.md delete mode 100644 dev/how-to/configure/memory-control.md delete mode 100644 dev/how-to/configure/time-zone.md delete mode 100644 dev/how-to/deploy/data-migration-with-ansible.md delete mode 100644 dev/how-to/deploy/geographic-redundancy/location-awareness.md delete mode 100644 dev/how-to/deploy/geographic-redundancy/overview.md delete mode 100644 dev/how-to/deploy/hardware-recommendations.md delete mode 100644 dev/how-to/deploy/orchestrated/ansible.md delete mode 100644 dev/how-to/deploy/orchestrated/docker.md delete mode 100644 dev/how-to/deploy/orchestrated/offline-ansible.md delete mode 100644 dev/how-to/get-started/deploy-tidb-from-docker-compose.md delete mode 100644 dev/how-to/get-started/explore-sql.md delete mode 100644 dev/how-to/get-started/read-historical-data.md delete mode 100644 dev/how-to/get-started/tidb-binlog.md delete mode 100644 dev/how-to/maintain/ansible-operations.md delete mode 100644 dev/how-to/maintain/backup-and-restore/mydumper-lightning.md delete mode 100644 dev/how-to/maintain/identify-abnormal-queries/identify-slow-queries.md delete mode 100644 dev/how-to/migrate/from-mysql-aurora.md delete mode 100644 dev/how-to/monitor/monitor-a-cluster.md delete mode 100644 dev/how-to/monitor/overview.md delete mode 100644 dev/how-to/scale/horizontally.md delete mode 100644 dev/how-to/scale/with-ansible.md delete mode 100644 dev/how-to/secure/enable-tls-between-components.md delete mode 100644 dev/how-to/secure/enable-tls-clients.md delete mode 100644 dev/how-to/secure/generate-self-signed-certificates.md delete mode 100644 dev/how-to/troubleshoot/cluster-setup.md delete mode 100644 dev/how-to/troubleshoot/tidb-lightning.md delete mode 100644 dev/how-to/upgrade/from-previous-version.md delete mode 100644 dev/key-features.md delete mode 100644 dev/overview.md delete mode 100644 dev/reference/best-practices/high-concurrency.md delete mode 100644 dev/reference/best-practices/java-app.md delete mode 100644 dev/reference/configuration/pd-server/configuration.md delete mode 100644 dev/reference/configuration/tidb-server/configuration-file.md delete mode 100644 dev/reference/configuration/tidb-server/configuration.md delete mode 100644 dev/reference/configuration/tidb-server/mysql-variables.md delete mode 100644 dev/reference/configuration/tidb-server/tidb-specific-variables.md delete mode 100644 dev/reference/configuration/tikv-server/configuration-file.md delete mode 100644 dev/reference/configuration/tikv-server/configuration.md delete mode 100644 dev/reference/error-codes.md delete mode 100644 dev/reference/garbage-collection/overview.md delete mode 100644 dev/reference/key-monitoring-metrics/overview-dashboard.md delete mode 100644 dev/reference/key-monitoring-metrics/pd-dashboard.md delete mode 100644 dev/reference/key-monitoring-metrics/tikv-dashboard.md delete mode 100644 dev/reference/mysql-compatibility.md delete mode 100644 dev/reference/performance/check-cluster-status-using-sql-statements.md delete mode 100644 dev/reference/performance/execution-plan-bind.md delete mode 100644 dev/reference/performance/follower-read.md delete mode 100644 dev/reference/performance/index-merge.md delete mode 100644 dev/reference/performance/optimizer-hints.md delete mode 100644 dev/reference/performance/sql-optimizer-overview.md delete mode 100644 dev/reference/performance/statistics.md delete mode 100644 dev/reference/performance/tune-tikv.md delete mode 100644 dev/reference/performance/understanding-the-query-execution-plan.md delete mode 100644 dev/reference/security/compatibility.md delete mode 100644 dev/reference/security/privilege-system.md delete mode 100644 dev/reference/security/user-account-management.md delete mode 100644 dev/reference/sql/character-set.md delete mode 100644 dev/reference/sql/constraints.md delete mode 100644 dev/reference/sql/data-types/date-and-time.md delete mode 100644 dev/reference/sql/data-types/overview.md delete mode 100644 dev/reference/sql/functions-and-operators/aggregate-group-by-functions.md delete mode 100644 dev/reference/sql/functions-and-operators/bit-functions-and-operators.md delete mode 100644 dev/reference/sql/functions-and-operators/cast-functions-and-operators.md delete mode 100644 dev/reference/sql/functions-and-operators/control-flow-functions.md delete mode 100644 dev/reference/sql/functions-and-operators/date-and-time-functions.md delete mode 100644 dev/reference/sql/functions-and-operators/encryption-and-compression-functions.md delete mode 100644 dev/reference/sql/functions-and-operators/information-functions.md delete mode 100644 dev/reference/sql/functions-and-operators/json-functions.md delete mode 100644 dev/reference/sql/functions-and-operators/miscellaneous-functions.md delete mode 100644 dev/reference/sql/functions-and-operators/numeric-functions-and-operators.md delete mode 100644 dev/reference/sql/functions-and-operators/operators.md delete mode 100644 dev/reference/sql/functions-and-operators/precision-math.md delete mode 100644 dev/reference/sql/functions-and-operators/reference.md delete mode 100644 dev/reference/sql/functions-and-operators/string-functions.md delete mode 100644 dev/reference/sql/functions-and-operators/type-conversion.md delete mode 100644 dev/reference/sql/generated-columns.md delete mode 100644 dev/reference/sql/language-structure/comment-syntax.md delete mode 100644 dev/reference/sql/language-structure/expression-syntax.md delete mode 100644 dev/reference/sql/language-structure/keywords-and-reserved-words.md delete mode 100644 dev/reference/sql/language-structure/literal-values.md delete mode 100644 dev/reference/sql/language-structure/schema-object-names.md delete mode 100644 dev/reference/sql/language-structure/user-defined-variables.md delete mode 100644 dev/reference/sql/sql-mode.md delete mode 100644 dev/reference/sql/statements/admin.md delete mode 100644 dev/reference/sql/statements/create-table.md delete mode 100644 dev/reference/sql/statements/desc.md delete mode 100644 dev/reference/sql/statements/describe.md delete mode 100644 dev/reference/sql/statements/explain.md delete mode 100644 dev/reference/sql/statements/load-data.md delete mode 100644 dev/reference/sql/statements/prepare.md delete mode 100644 dev/reference/sql/statements/recover-table.md delete mode 100644 dev/reference/sql/statements/select.md delete mode 100644 dev/reference/sql/statements/show-fields-from.md delete mode 100644 dev/reference/sql/statements/show-index.md delete mode 100644 dev/reference/sql/statements/show-keys.md delete mode 100644 dev/reference/sql/statements/show-schemas.md delete mode 100644 dev/reference/sql/statements/show-table-regions.md delete mode 100644 dev/reference/sql/statements/show-variables.md delete mode 100644 dev/reference/supported-clients.md delete mode 100644 dev/reference/system-databases/information-schema.md delete mode 100644 dev/reference/system-databases/mysql.md delete mode 100644 dev/reference/tidb-binlog/binlog-slave-client.md delete mode 100644 dev/reference/tidb-binlog/deploy.md delete mode 100644 dev/reference/tidb-binlog/faq.md delete mode 100644 dev/reference/tidb-binlog/glossary.md delete mode 100644 dev/reference/tidb-binlog/maintain.md delete mode 100644 dev/reference/tidb-binlog/monitor.md delete mode 100644 dev/reference/tidb-binlog/overview.md delete mode 100644 dev/reference/tidb-binlog/relay-log.md delete mode 100644 dev/reference/tidb-binlog/reparo.md delete mode 100644 dev/reference/tidb-binlog/tidb-binlog-kafka.md delete mode 100644 dev/reference/tidb-binlog/tidb-binlog-local.md delete mode 100644 dev/reference/tidb-binlog/troubleshoot/binlog.md delete mode 100644 dev/reference/tidb-binlog/upgrade.md delete mode 100644 dev/reference/tispark.md delete mode 100644 dev/reference/tools/br/br.md delete mode 100644 dev/reference/tools/br/use-cases.md delete mode 100644 dev/reference/tools/data-migration/cluster-operations.md delete mode 100644 dev/reference/tools/data-migration/configure/overview.md delete mode 100644 dev/reference/tools/data-migration/configure/task-configuration-file.md delete mode 100644 dev/reference/tools/data-migration/deploy.md delete mode 100644 dev/reference/tools/data-migration/dm-upgrade.md delete mode 100644 dev/reference/tools/data-migration/dm-worker-intro.md delete mode 100644 dev/reference/tools/data-migration/faq.md delete mode 100644 dev/reference/tools/data-migration/features/manually-handling-sharding-ddl-locks.md delete mode 100644 dev/reference/tools/data-migration/features/overview.md delete mode 100644 dev/reference/tools/data-migration/features/shard-merge.md delete mode 100644 dev/reference/tools/data-migration/from-aurora.md delete mode 100644 dev/reference/tools/data-migration/overview.md delete mode 100644 dev/reference/tools/data-migration/precheck.md delete mode 100644 dev/reference/tools/data-migration/query-status.md delete mode 100644 dev/reference/tools/data-migration/relay-log.md delete mode 100644 dev/reference/tools/data-migration/skip-replace-sqls.md delete mode 100644 dev/reference/tools/data-migration/table-selector.md delete mode 100644 dev/reference/tools/data-migration/troubleshoot/dm.md delete mode 100644 dev/reference/tools/data-migration/troubleshoot/error-system.md delete mode 100644 dev/reference/tools/data-migration/usage-scenarios/shard-merge.md delete mode 100644 dev/reference/tools/data-migration/usage-scenarios/simple-synchronization.md delete mode 100644 dev/reference/tools/download.md delete mode 100644 dev/reference/tools/error-case-handling/load-misuse-handling.md delete mode 100644 dev/reference/tools/loader.md delete mode 100644 dev/reference/tools/mydumper.md delete mode 100644 dev/reference/tools/pd-control.md delete mode 100644 dev/reference/tools/pd-recover.md delete mode 100644 dev/reference/tools/sync-diff-inspector/overview.md delete mode 100644 dev/reference/tools/syncer.md delete mode 100644 dev/reference/tools/tidb-lightning/checkpoints.md delete mode 100644 dev/reference/tools/tidb-lightning/csv.md delete mode 100644 dev/reference/tools/tidb-lightning/deployment.md delete mode 100644 dev/reference/tools/tidb-lightning/table-filter.md delete mode 100644 dev/reference/tools/user-guide.md delete mode 100644 dev/reference/transactions/overview.md delete mode 100644 dev/reference/transactions/transaction-isolation.md delete mode 100644 dev/reference/transactions/transaction-optimistic.md delete mode 100644 dev/reference/transactions/transaction-pessimistic.md delete mode 100644 dev/releases/11alpha.md delete mode 100644 dev/releases/11beta.md delete mode 100644 dev/releases/2.0.10.md delete mode 100644 dev/releases/2.0.11.md delete mode 100644 dev/releases/2.0ga.md delete mode 100644 dev/releases/2.1.1.md delete mode 100644 dev/releases/2.1.10.md delete mode 100644 dev/releases/2.1.11.md delete mode 100644 dev/releases/2.1.12.md delete mode 100644 dev/releases/2.1.18.md delete mode 100644 dev/releases/2.1.2.md delete mode 100644 dev/releases/2.1.3.md delete mode 100644 dev/releases/2.1.4.md delete mode 100644 dev/releases/2.1.5.md delete mode 100644 dev/releases/2.1.6.md delete mode 100644 dev/releases/2.1.7.md delete mode 100644 dev/releases/2.1.8.md delete mode 100644 dev/releases/2.1.9.md delete mode 100644 dev/releases/2.1ga.md delete mode 100644 dev/releases/201.md delete mode 100644 dev/releases/202.md delete mode 100644 dev/releases/203.md delete mode 100644 dev/releases/204.md delete mode 100644 dev/releases/205.md delete mode 100644 dev/releases/206.md delete mode 100644 dev/releases/207.md delete mode 100644 dev/releases/208.md delete mode 100644 dev/releases/209.md delete mode 100644 dev/releases/21beta.md delete mode 100644 dev/releases/21rc1.md delete mode 100644 dev/releases/21rc2.md delete mode 100644 dev/releases/21rc3.md delete mode 100644 dev/releases/21rc4.md delete mode 100644 dev/releases/21rc5.md delete mode 100644 dev/releases/2rc1.md delete mode 100644 dev/releases/2rc3.md delete mode 100644 dev/releases/2rc4.md delete mode 100644 dev/releases/2rc5.md delete mode 100644 dev/releases/3.0-ga.md delete mode 100644 dev/releases/3.0.0-beta.1.md delete mode 100644 dev/releases/3.0.0-rc.1.md delete mode 100644 dev/releases/3.0.0-rc.2.md delete mode 100644 dev/releases/3.0.0-rc.3.md delete mode 100644 dev/releases/3.0.2.md delete mode 100644 dev/releases/3.0.8.md delete mode 100644 dev/releases/3.0beta.md delete mode 100644 dev/releases/3.1.0-beta.1.md delete mode 100644 dev/releases/3.1.0-beta.md delete mode 100644 dev/releases/4.0.0-beta.md delete mode 100644 dev/releases/ga.md delete mode 100644 dev/releases/prega.md delete mode 100644 dev/releases/rc1.md delete mode 100644 dev/releases/rc2.md delete mode 100644 dev/releases/rc3.md delete mode 100644 dev/releases/rc4.md delete mode 100644 dev/releases/rn.md delete mode 100644 dev/report-issue.md delete mode 100644 dev/roadmap.md delete mode 100644 dev/support-resources.md delete mode 100644 dev/tidb-in-kubernetes/deploy/access-tidb.md delete mode 100644 dev/tidb-in-kubernetes/deploy/alibaba-cloud.md delete mode 100644 dev/tidb-in-kubernetes/deploy/aws-eks.md delete mode 100644 dev/tidb-in-kubernetes/deploy/gcp-gke.md delete mode 100644 dev/tidb-in-kubernetes/deploy/general-kubernetes.md delete mode 100644 dev/tidb-in-kubernetes/deploy/prerequisites.md delete mode 100644 dev/tidb-in-kubernetes/deploy/tidb-operator.md delete mode 100644 dev/tidb-in-kubernetes/faq.md delete mode 100644 dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-gke.md delete mode 100644 dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-kind.md delete mode 100644 dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-minikube.md delete mode 100644 dev/tidb-in-kubernetes/initialize-cluster.md delete mode 100644 dev/tidb-in-kubernetes/maintain/auto-failover.md delete mode 100644 dev/tidb-in-kubernetes/maintain/backup-and-restore.md delete mode 100644 dev/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md delete mode 100644 dev/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md delete mode 100644 dev/tidb-in-kubernetes/maintain/backup-and-restore/restore.md delete mode 100644 dev/tidb-in-kubernetes/maintain/destroy-tidb-cluster.md delete mode 100644 dev/tidb-in-kubernetes/maintain/kubernetes-node.md delete mode 100644 dev/tidb-in-kubernetes/maintain/log-collecting.md delete mode 100644 dev/tidb-in-kubernetes/monitor/tidb-in-kubernetes.md delete mode 100644 dev/tidb-in-kubernetes/reference/configuration/backup.md delete mode 100644 dev/tidb-in-kubernetes/reference/configuration/storage-class.md delete mode 100644 dev/tidb-in-kubernetes/reference/tools/in-kubernetes.md delete mode 100644 dev/tidb-in-kubernetes/reference/tools/tkctl.md delete mode 100644 dev/tidb-in-kubernetes/scale-in-kubernetes.md delete mode 100644 dev/tidb-in-kubernetes/tidb-operator-overview.md delete mode 100644 dev/tidb-in-kubernetes/troubleshoot.md delete mode 100644 dev/tidb-in-kubernetes/upgrade/tidb-cluster.md delete mode 100644 dev/tidb-in-kubernetes/upgrade/tidb-operator.md rename {v3.0/faq => faq}/tidb-lightning.md (87%) rename {v3.0/faq => faq}/tidb.md (92%) rename {v3.0/faq => faq}/upgrade.md (100%) rename dev/glossary.md => glossary.md (100%) rename {v3.0/how-to => how-to}/configure/memory-control.md (100%) rename {v3.0/how-to => how-to}/configure/time-zone.md (100%) rename {v3.0/how-to => how-to}/deploy/data-migration-with-ansible.md (98%) rename {dev/how-to => how-to}/deploy/data-migration-with-binary.md (98%) rename {v3.0/how-to => how-to}/deploy/geographic-redundancy/location-awareness.md (94%) rename {v3.0/how-to => how-to}/deploy/geographic-redundancy/overview.md (100%) rename {v3.0/how-to => how-to}/deploy/hardware-recommendations.md (98%) rename {v3.0/how-to => how-to}/deploy/orchestrated/ansible.md (95%) rename {v3.0/how-to => how-to}/deploy/orchestrated/docker.md (98%) rename {v3.0/how-to => how-to}/deploy/orchestrated/offline-ansible.md (77%) rename {dev/how-to => how-to}/get-started/data-migration.md (97%) rename {v3.0/how-to => how-to}/get-started/deploy-tidb-from-docker-compose.md (97%) rename {v3.0/how-to => how-to}/get-started/explore-sql.md (97%) rename {v3.0/how-to => how-to}/get-started/read-historical-data.md (98%) rename {v3.0/how-to => how-to}/get-started/tidb-binlog.md (97%) rename {dev/how-to => how-to}/get-started/tidb-lightning.md (93%) rename {dev/how-to => how-to}/get-started/tispark.md (96%) rename {v3.0/how-to => how-to}/maintain/ansible-operations.md (100%) rename {v3.0/how-to => how-to}/maintain/backup-and-restore.md (81%) rename {dev/how-to => how-to}/maintain/identify-abnormal-queries/identify-aborted-queries.md (74%) rename {v3.0/how-to => how-to}/maintain/identify-abnormal-queries/identify-slow-queries.md (95%) rename {v3.0/how-to => how-to}/migrate/from-mysql-aurora.md (95%) rename {v3.0/how-to => how-to}/monitor/monitor-a-cluster.md (100%) rename {v3.0/how-to => how-to}/monitor/overview.md (100%) rename {v3.0/how-to => how-to}/scale/horizontally.md (96%) rename {v3.0/how-to => how-to}/scale/with-ansible.md (97%) rename {v3.0/how-to => how-to}/secure/enable-tls-between-components.md (92%) rename {v3.0/how-to => how-to}/secure/enable-tls-clients.md (95%) rename {v3.0/how-to => how-to}/secure/generate-self-signed-certificates.md (100%) rename {v3.0/how-to => how-to}/troubleshoot/cluster-setup.md (91%) rename {v3.0/how-to => how-to}/troubleshoot/tidb-lightning.md (92%) rename {v3.0/how-to => how-to}/upgrade/from-previous-version.md (86%) rename v3.0/key-features.md => key-features.md (100%) rename v3.1/overview.md => overview.md (54%) rename {dev/reference => reference}/alert-rules.md (99%) rename {dev/reference => reference}/best-practices/grafana-monitor.md (95%) rename {dev/reference => reference}/best-practices/haproxy.md (100%) rename {v3.0/reference => reference}/best-practices/high-concurrency.md (89%) rename {v3.0/reference => reference}/best-practices/java-app.md (100%) rename {dev/reference => reference}/best-practices/massive-regions.md (97%) rename {dev/reference => reference}/best-practices/pd-scheduling.md (96%) rename {dev/reference => reference}/configuration/pd-server/configuration-file.md (98%) rename {v3.0/reference => reference}/configuration/pd-server/configuration.md (100%) rename {v3.0/reference => reference}/configuration/tidb-server/configuration-file.md (99%) rename {v3.0/reference => reference}/configuration/tidb-server/configuration.md (98%) rename {v3.0/reference => reference}/configuration/tidb-server/mysql-variables.md (91%) rename {v3.0/reference => reference}/configuration/tidb-server/tidb-specific-variables.md (97%) rename {v3.0/reference => reference}/configuration/tikv-server/configuration-file.md (99%) rename {v3.0/reference => reference}/configuration/tikv-server/configuration.md (100%) rename {v3.0/reference => reference}/error-codes.md (85%) rename {dev/reference => reference}/garbage-collection/configuration.md (87%) rename {v3.0/reference => reference}/garbage-collection/overview.md (97%) rename {v3.0/reference => reference}/key-monitoring-metrics/overview-dashboard.md (99%) rename {v3.0/reference => reference}/key-monitoring-metrics/pd-dashboard.md (99%) rename {dev/reference => reference}/key-monitoring-metrics/tidb-dashboard.md (99%) rename {v3.0/reference => reference}/key-monitoring-metrics/tikv-dashboard.md (99%) rename {v3.1/reference => reference}/mysql-compatibility.md (90%) create mode 100644 reference/performance/check-cluster-status-using-sql-statements.md rename {v3.0/reference => reference}/performance/execution-plan-bind.md (87%) rename {v3.0/reference => reference}/performance/optimizer-hints.md (100%) rename {v3.0/reference => reference}/performance/sql-optimizer-overview.md (100%) rename {dev/reference => reference}/performance/statement-summary.md (100%) rename {v3.0/reference => reference}/performance/statistics.md (100%) rename {v3.0/reference => reference}/performance/tune-tikv.md (100%) rename {v3.0/reference => reference}/performance/understanding-the-query-execution-plan.md (100%) rename {dev/reference => reference}/security/cert-based-authentication.md (100%) rename {v3.0/reference => reference}/security/compatibility.md (100%) rename {v3.0/reference => reference}/security/privilege-system.md (100%) rename {dev/reference => reference}/security/role-based-access-control.md (94%) rename {v3.0/reference => reference}/security/user-account-management.md (98%) rename {v3.0/reference => reference}/sql/character-set.md (100%) rename {v3.0/reference => reference}/sql/constraints.md (95%) rename {v2.1/reference => reference}/sql/data-types/date-and-time.md (100%) rename {dev/reference => reference}/sql/data-types/default-values.md (100%) rename {dev/reference => reference}/sql/data-types/json.md (100%) rename {dev/reference => reference}/sql/data-types/numeric.md (100%) rename {v3.0/reference => reference}/sql/data-types/overview.md (73%) rename {dev/reference => reference}/sql/data-types/string.md (100%) rename {v3.0/reference => reference}/sql/functions-and-operators/aggregate-group-by-functions.md (97%) rename {v3.0/reference => reference}/sql/functions-and-operators/bit-functions-and-operators.md (100%) rename {v3.0/reference => reference}/sql/functions-and-operators/cast-functions-and-operators.md (100%) rename {v3.0/reference => reference}/sql/functions-and-operators/control-flow-functions.md (100%) rename {v3.0/reference => reference}/sql/functions-and-operators/date-and-time-functions.md (100%) rename {v3.0/reference => reference}/sql/functions-and-operators/encryption-and-compression-functions.md (100%) rename {dev/reference => reference}/sql/functions-and-operators/expressions-pushed-down.md (76%) rename {v3.0/reference => reference}/sql/functions-and-operators/information-functions.md (100%) rename {v3.0/reference => reference}/sql/functions-and-operators/json-functions.md (100%) rename {v3.0/reference => reference}/sql/functions-and-operators/miscellaneous-functions.md (100%) rename {v3.0/reference => reference}/sql/functions-and-operators/numeric-functions-and-operators.md (100%) rename {v3.0/reference => reference}/sql/functions-and-operators/operators.md (100%) rename {v3.0/reference => reference}/sql/functions-and-operators/precision-math.md (100%) rename {v3.0/reference => reference}/sql/functions-and-operators/reference.md (83%) rename {v3.0/reference => reference}/sql/functions-and-operators/string-functions.md (100%) rename {v3.0/reference => reference}/sql/functions-and-operators/type-conversion.md (100%) rename {dev/reference => reference}/sql/functions-and-operators/window-functions.md (100%) rename {v3.0/reference => reference}/sql/generated-columns.md (97%) rename {v3.0/reference => reference}/sql/language-structure/comment-syntax.md (95%) rename {v3.0/reference => reference}/sql/language-structure/expression-syntax.md (100%) rename {v3.0/reference => reference}/sql/language-structure/keywords-and-reserved-words.md (97%) rename {v3.0/reference => reference}/sql/language-structure/literal-values.md (100%) rename {v3.0/reference => reference}/sql/language-structure/schema-object-names.md (100%) rename {v3.0/reference => reference}/sql/language-structure/user-defined-variables.md (100%) rename {dev/reference => reference}/sql/partitioning.md (100%) rename {v3.0/reference => reference}/sql/sql-mode.md (100%) rename {dev/reference => reference}/sql/statements/add-column.md (93%) rename {dev/reference => reference}/sql/statements/add-index.md (86%) rename {v3.0/reference => reference}/sql/statements/admin.md (100%) rename {dev/reference => reference}/sql/statements/alter-database.md (74%) rename {dev/reference => reference}/sql/statements/alter-table.md (74%) rename {dev/reference => reference}/sql/statements/alter-user.md (91%) rename {dev/reference => reference}/sql/statements/analyze-table.md (95%) rename {dev/reference => reference}/sql/statements/begin.md (80%) rename {dev/reference => reference}/sql/statements/change-column.md (86%) rename {dev/reference => reference}/sql/statements/commit.md (82%) rename {dev/reference => reference}/sql/statements/create-database.md (82%) rename {dev/reference => reference}/sql/statements/create-index.md (85%) rename {dev/reference => reference}/sql/statements/create-table-like.md (85%) rename {v3.0/reference => reference}/sql/statements/create-table.md (93%) rename {dev/reference => reference}/sql/statements/create-user.md (79%) rename {dev/reference => reference}/sql/statements/create-view.md (92%) rename {dev/reference => reference}/sql/statements/deallocate.md (85%) rename {dev/reference => reference}/sql/statements/delete.md (81%) create mode 100644 reference/sql/statements/desc.md create mode 100644 reference/sql/statements/describe.md rename {dev/reference => reference}/sql/statements/do.md (90%) rename {dev/reference => reference}/sql/statements/drop-column.md (91%) rename {dev/reference => reference}/sql/statements/drop-database.md (86%) rename {dev/reference => reference}/sql/statements/drop-index.md (89%) rename {dev/reference => reference}/sql/statements/drop-table.md (84%) rename {dev/reference => reference}/sql/statements/drop-user.md (89%) rename {dev/reference => reference}/sql/statements/drop-view.md (89%) rename {dev/reference => reference}/sql/statements/execute.md (83%) rename {dev/reference => reference}/sql/statements/explain-analyze.md (89%) rename {v3.0/reference => reference}/sql/statements/explain.md (95%) rename {dev/reference => reference}/sql/statements/flush-privileges.md (75%) rename {dev/reference => reference}/sql/statements/flush-status.md (97%) rename {dev/reference => reference}/sql/statements/flush-tables.md (94%) rename {dev/reference => reference}/sql/statements/grant-privileges.md (89%) rename {dev/reference => reference}/sql/statements/insert.md (87%) rename {dev/reference => reference}/sql/statements/kill.md (85%) rename {v3.0/reference => reference}/sql/statements/load-data.md (92%) rename {dev/reference => reference}/sql/statements/modify-column.md (84%) rename {v3.0/reference => reference}/sql/statements/prepare.md (83%) rename {v3.0/reference => reference}/sql/statements/recover-table.md (94%) rename {dev/reference => reference}/sql/statements/rename-index.md (82%) rename {dev/reference => reference}/sql/statements/rename-table.md (79%) rename {dev/reference => reference}/sql/statements/replace.md (84%) rename {dev/reference => reference}/sql/statements/revoke-privileges.md (88%) rename {dev/reference => reference}/sql/statements/rollback.md (79%) rename {v3.0/reference => reference}/sql/statements/select.md (77%) rename {dev/reference => reference}/sql/statements/set-names.md (93%) rename {dev/reference => reference}/sql/statements/set-password.md (94%) rename {dev/reference => reference}/sql/statements/set-transaction.md (93%) rename {dev/reference => reference}/sql/statements/set-variable.md (96%) rename {dev/reference => reference}/sql/statements/show-character-set.md (89%) rename {dev/reference => reference}/sql/statements/show-collation.md (99%) rename {dev/reference => reference}/sql/statements/show-columns-from.md (98%) rename {dev/reference => reference}/sql/statements/show-create-table.md (79%) rename {dev/reference => reference}/sql/statements/show-create-user.md (90%) rename {dev/reference => reference}/sql/statements/show-databases.md (83%) rename {dev/reference => reference}/sql/statements/show-engines.md (100%) rename {dev/reference => reference}/sql/statements/show-errors.md (95%) create mode 100644 reference/sql/statements/show-fields-from.md rename {dev/reference => reference}/sql/statements/show-grants.md (88%) create mode 100644 reference/sql/statements/show-index.md rename {dev/reference => reference}/sql/statements/show-indexes.md (93%) create mode 100644 reference/sql/statements/show-keys.md rename {dev/reference => reference}/sql/statements/show-privileges.md (96%) rename {dev/reference => reference}/sql/statements/show-processlist.md (95%) create mode 100644 reference/sql/statements/show-schemas.md rename {dev/reference => reference}/sql/statements/show-status.md (97%) rename {v3.0/reference => reference}/sql/statements/show-table-regions.md (98%) rename {dev/reference => reference}/sql/statements/show-table-status.md (84%) rename {dev/reference => reference}/sql/statements/show-tables.md (87%) rename {v3.0/reference => reference}/sql/statements/show-variables.md (98%) rename {dev/reference => reference}/sql/statements/show-warnings.md (94%) rename {dev/reference => reference}/sql/statements/split-region.md (99%) rename {dev/reference => reference}/sql/statements/start-transaction.md (81%) rename {dev/reference => reference}/sql/statements/trace.md (98%) rename {dev/reference => reference}/sql/statements/truncate.md (83%) rename {dev/reference => reference}/sql/statements/update.md (84%) rename {dev/reference => reference}/sql/statements/use.md (90%) rename {dev/reference => reference}/sql/view.md (94%) rename {v3.0/reference => reference}/supported-clients.md (100%) rename {v3.0/reference => reference}/system-databases/information-schema.md (99%) rename {v3.0/reference => reference}/system-databases/mysql.md (100%) rename {v3.0/reference => reference}/tidb-binlog/binlog-slave-client.md (100%) rename {v3.0/reference => reference}/tidb-binlog/deploy.md (98%) rename {v3.0/reference => reference}/tidb-binlog/faq.md (98%) rename {v2.1/reference => reference}/tidb-binlog/glossary.md (100%) rename {v3.0/reference => reference}/tidb-binlog/maintain.md (100%) rename {v3.0/reference => reference}/tidb-binlog/monitor.md (100%) rename {v3.0/reference => reference}/tidb-binlog/overview.md (86%) rename {v3.0/reference => reference}/tidb-binlog/relay-log.md (100%) rename {v3.0/reference => reference}/tidb-binlog/reparo.md (100%) rename {v3.0/reference => reference}/tidb-binlog/tidb-binlog-kafka.md (100%) rename {v3.0/reference => reference}/tidb-binlog/tidb-binlog-local.md (99%) rename {v3.0/reference => reference}/tidb-binlog/troubleshoot/binlog.md (50%) rename {dev/reference => reference}/tidb-binlog/troubleshoot/error-handling.md (75%) rename {v3.0/reference => reference}/tidb-binlog/upgrade.md (84%) rename {v3.0/reference => reference}/tispark.md (98%) rename {v3.0/reference => reference}/tools/data-migration/cluster-operations.md (94%) rename {dev/reference => reference}/tools/data-migration/configure/dm-master-configuration-file.md (100%) rename {dev/reference => reference}/tools/data-migration/configure/dm-worker-configuration-file-full.md (100%) rename {dev/reference => reference}/tools/data-migration/configure/dm-worker-configuration-file.md (90%) rename {v3.0/reference => reference}/tools/data-migration/configure/overview.md (70%) rename {dev/reference => reference}/tools/data-migration/configure/task-configuration-file-full.md (95%) rename {v3.0/reference => reference}/tools/data-migration/configure/task-configuration-file.md (91%) rename {v3.0/reference => reference}/tools/data-migration/deploy.md (92%) rename {dev/reference => reference}/tools/data-migration/dm-portal.md (87%) rename {v3.0/reference => reference}/tools/data-migration/dm-upgrade.md (98%) rename {v3.0/reference => reference}/tools/data-migration/dm-worker-intro.md (100%) rename {v3.0/reference => reference}/tools/data-migration/faq.md (87%) rename {v3.0/reference => reference}/tools/data-migration/features/manually-handling-sharding-ddl-locks.md (97%) rename {v3.0/reference => reference}/tools/data-migration/features/overview.md (95%) rename {v3.0/reference => reference}/tools/data-migration/features/shard-merge.md (96%) rename {v3.0/reference => reference}/tools/data-migration/from-aurora.md (95%) rename {dev/reference => reference}/tools/data-migration/glossary.md (83%) rename {dev/reference => reference}/tools/data-migration/manage-tasks.md (93%) rename {dev/reference => reference}/tools/data-migration/monitor.md (98%) rename {v3.0/reference => reference}/tools/data-migration/overview.md (60%) rename {v3.0/reference => reference}/tools/data-migration/precheck.md (97%) rename {v3.0/reference => reference}/tools/data-migration/query-status.md (98%) rename {v3.0/reference => reference}/tools/data-migration/relay-log.md (100%) rename {dev/reference => reference}/tools/data-migration/releases/1.0.2.md (100%) rename {dev/reference => reference}/tools/data-migration/releases/1.0.3.md (100%) rename {v3.0/reference => reference}/tools/data-migration/skip-replace-sqls.md (98%) rename {v3.0/reference => reference}/tools/data-migration/table-selector.md (100%) rename {v3.0/reference => reference}/tools/data-migration/troubleshoot/dm.md (75%) rename {dev/reference => reference}/tools/data-migration/troubleshoot/error-handling.md (93%) rename {v3.0/reference => reference}/tools/data-migration/troubleshoot/error-system.md (100%) rename {dev/reference => reference}/tools/data-migration/usage-scenarios/best-practice-dm-shard.md (74%) rename {dev/reference => reference}/tools/data-migration/usage-scenarios/master-slave-switch.md (100%) rename {v3.0/reference => reference}/tools/data-migration/usage-scenarios/shard-merge.md (87%) rename {v3.0/reference => reference}/tools/data-migration/usage-scenarios/simple-synchronization.md (88%) rename {v3.0/reference => reference}/tools/download.md (78%) rename {dev/reference => reference}/tools/error-case-handling/lightning-misuse-handling.md (81%) rename {v3.0/reference => reference}/tools/error-case-handling/load-misuse-handling.md (86%) rename {v3.0/reference => reference}/tools/loader.md (96%) rename {v3.0/reference => reference}/tools/mydumper.md (96%) rename {v3.0/reference => reference}/tools/pd-control.md (100%) rename {v3.0/reference => reference}/tools/pd-recover.md (100%) rename {v3.0/reference => reference}/tools/sync-diff-inspector/overview.md (96%) rename {dev/reference => reference}/tools/sync-diff-inspector/route-diff.md (100%) rename {dev/reference => reference}/tools/sync-diff-inspector/shard-diff.md (100%) rename {dev/reference => reference}/tools/sync-diff-inspector/tidb-diff.md (100%) rename {v3.0/reference => reference}/tools/syncer.md (99%) rename {dev/reference => reference}/tools/tidb-control.md (100%) rename {v3.0/reference => reference}/tools/tidb-lightning/checkpoints.md (100%) rename {dev/reference => reference}/tools/tidb-lightning/config.md (97%) rename {v3.0/reference => reference}/tools/tidb-lightning/csv.md (100%) rename {v3.0/reference => reference}/tools/tidb-lightning/deployment.md (86%) rename {dev/reference => reference}/tools/tidb-lightning/glossary.md (84%) rename {dev/reference => reference}/tools/tidb-lightning/monitor.md (100%) rename {dev/reference => reference}/tools/tidb-lightning/overview.md (94%) rename {v3.0/reference => reference}/tools/tidb-lightning/table-filter.md (100%) rename {dev/reference => reference}/tools/tidb-lightning/tidb-backend.md (92%) rename {dev/reference => reference}/tools/tidb-lightning/web.md (94%) rename {dev/reference => reference}/tools/tikv-control.md (100%) rename {v3.0/reference => reference}/tools/user-guide.md (68%) rename {v2.1/reference => reference}/transactions/overview.md (91%) rename {v3.0/reference => reference}/transactions/transaction-isolation.md (92%) rename {v3.0/reference => reference}/transactions/transaction-optimistic.md (91%) rename {v3.0/reference => reference}/transactions/transaction-pessimistic.md (100%) rename {v3.0/releases => releases}/11alpha.md (100%) rename {v3.0/releases => releases}/11beta.md (100%) rename {v3.0/releases => releases}/2.0.10.md (100%) rename {v3.0/releases => releases}/2.0.11.md (100%) rename {v3.0/releases => releases}/2.0ga.md (100%) rename {v3.0/releases => releases}/2.1.1.md (100%) rename {v3.0/releases => releases}/2.1.10.md (100%) rename {v3.0/releases => releases}/2.1.11.md (100%) rename {v3.0/releases => releases}/2.1.12.md (100%) rename {dev/releases => releases}/2.1.13.md (100%) rename {dev/releases => releases}/2.1.14.md (100%) rename {dev/releases => releases}/2.1.15.md (100%) rename {dev/releases => releases}/2.1.16.md (100%) rename {dev/releases => releases}/2.1.17.md (100%) rename {v3.0/releases => releases}/2.1.18.md (100%) rename {dev/releases => releases}/2.1.19.md (100%) rename {v3.0/releases => releases}/2.1.2.md (100%) rename {v3.0/releases => releases}/2.1.3.md (100%) rename {v3.0/releases => releases}/2.1.4.md (100%) rename {v3.0/releases => releases}/2.1.5.md (100%) rename {v3.0/releases => releases}/2.1.6.md (100%) rename {v3.0/releases => releases}/2.1.7.md (100%) rename {v3.0/releases => releases}/2.1.8.md (100%) rename {v3.0/releases => releases}/2.1.9.md (100%) rename {v3.0/releases => releases}/2.1ga.md (100%) rename {v3.0/releases => releases}/201.md (100%) rename {v3.0/releases => releases}/202.md (100%) rename {v3.0/releases => releases}/203.md (100%) rename {v3.0/releases => releases}/204.md (100%) rename {v3.0/releases => releases}/205.md (100%) rename {v3.0/releases => releases}/206.md (100%) rename {v3.0/releases => releases}/207.md (100%) rename {v3.0/releases => releases}/208.md (100%) rename {v3.0/releases => releases}/209.md (100%) rename {v3.0/releases => releases}/21beta.md (100%) rename {v3.0/releases => releases}/21rc1.md (100%) rename {v3.0/releases => releases}/21rc2.md (100%) rename {v3.0/releases => releases}/21rc3.md (100%) rename {v3.0/releases => releases}/21rc4.md (100%) rename {v3.0/releases => releases}/21rc5.md (98%) rename {v3.0/releases => releases}/2rc1.md (100%) rename {v3.0/releases => releases}/2rc3.md (100%) rename {v3.0/releases => releases}/2rc4.md (100%) rename {v3.0/releases => releases}/2rc5.md (100%) rename {v2.1/releases => releases}/3.0-ga.md (100%) rename {v3.0/releases => releases}/3.0.0-beta.1.md (100%) rename {v3.0/releases => releases}/3.0.0-rc.1.md (100%) rename {v3.0/releases => releases}/3.0.0-rc.2.md (100%) rename {v2.1/releases => releases}/3.0.0-rc.3.md (100%) rename {dev/releases => releases}/3.0.1.md (100%) rename {dev/releases => releases}/3.0.10.md (100%) rename {v3.0/releases => releases}/3.0.2.md (100%) rename {dev/releases => releases}/3.0.3.md (100%) rename {dev/releases => releases}/3.0.4.md (100%) rename {dev/releases => releases}/3.0.5.md (100%) rename {dev/releases => releases}/3.0.6.md (100%) rename {dev/releases => releases}/3.0.7.md (100%) rename {v3.1/releases => releases}/3.0.8.md (98%) rename {dev/releases => releases}/3.0.9.md (100%) rename {v3.0/releases => releases}/3.0beta.md (100%) rename {v3.0/releases => releases}/ga.md (100%) rename {v3.0/releases => releases}/prega.md (100%) rename {v3.0/releases => releases}/rc1.md (100%) rename {v3.0/releases => releases}/rc2.md (100%) rename {v3.0/releases => releases}/rc3.md (100%) rename {v3.0/releases => releases}/rc4.md (100%) create mode 100644 releases/rn.md rename v3.0/report-issue.md => report-issue.md (100%) rename v2.1/roadmap.md => roadmap.md (100%) rename v3.0/support-resources.md => support-resources.md (100%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/deploy/access-tidb.md (100%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/deploy/alibaba-cloud.md (99%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/deploy/aws-eks.md (99%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/deploy/gcp-gke.md (100%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/deploy/general-kubernetes.md (88%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/deploy/prerequisites.md (99%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/deploy/tidb-operator.md (91%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/faq.md (91%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/get-started/deploy-tidb-from-kubernetes-gke.md (98%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/get-started/deploy-tidb-from-kubernetes-kind.md (91%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/get-started/deploy-tidb-from-kubernetes-minikube.md (98%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/initialize-cluster.md (100%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/maintain/auto-failover.md (100%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/maintain/backup-and-restore.md (92%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/maintain/destroy-tidb-cluster.md (100%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/maintain/kubernetes-node.md (99%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/maintain/lightning.md (97%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/maintain/log-collecting.md (100%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/maintain/restart.md (100%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/maintain/tidb-binlog.md (95%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/monitor/tidb-in-kubernetes.md (98%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/reference/configuration/backup.md (97%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/reference/configuration/storage-class.md (98%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/reference/configuration/tidb-cluster.md (93%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/reference/configuration/tidb-drainer.md (95%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/reference/tools/in-kubernetes.md (89%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/reference/tools/tkctl.md (100%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/scale-in-kubernetes.md (96%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/tidb-operator-overview.md (51%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/troubleshoot.md (97%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/upgrade/tidb-cluster.md (93%) rename {v3.0/tidb-in-kubernetes => tidb-in-kubernetes}/upgrade/tidb-operator.md (100%) delete mode 100644 v2.1/TOC.md delete mode 100755 v2.1/_index.md delete mode 100644 v2.1/architecture.md delete mode 100644 v2.1/benchmark/how-to-run-sysbench.md delete mode 100644 v2.1/benchmark/sysbench-v2.md delete mode 100644 v2.1/benchmark/sysbench-v3.md delete mode 100644 v2.1/benchmark/sysbench.md delete mode 100644 v2.1/benchmark/tpch-v2.md delete mode 100644 v2.1/benchmark/tpch.md delete mode 100644 v2.1/contribute.md delete mode 100644 v2.1/faq/tidb-lightning.md delete mode 100755 v2.1/faq/tidb.md delete mode 100644 v2.1/faq/upgrade.md delete mode 100644 v2.1/glossary.md delete mode 100644 v2.1/how-to/configure/memory-control.md delete mode 100644 v2.1/how-to/configure/time-zone.md delete mode 100644 v2.1/how-to/deploy/data-migration-with-ansible.md delete mode 100644 v2.1/how-to/deploy/data-migration-with-binary.md delete mode 100644 v2.1/how-to/deploy/geographic-redundancy/location-awareness.md delete mode 100644 v2.1/how-to/deploy/geographic-redundancy/overview.md delete mode 100644 v2.1/how-to/deploy/hardware-recommendations.md delete mode 100644 v2.1/how-to/deploy/orchestrated/ansible.md delete mode 100644 v2.1/how-to/deploy/orchestrated/docker.md delete mode 100644 v2.1/how-to/deploy/orchestrated/offline-ansible.md delete mode 100644 v2.1/how-to/get-started/data-migration.md delete mode 100644 v2.1/how-to/get-started/deploy-tidb-from-docker-compose.md delete mode 100644 v2.1/how-to/get-started/explore-sql.md delete mode 100644 v2.1/how-to/get-started/read-historical-data.md delete mode 100644 v2.1/how-to/get-started/tidb-binlog.md delete mode 100644 v2.1/how-to/get-started/tidb-lightning.md delete mode 100644 v2.1/how-to/get-started/tispark.md delete mode 100644 v2.1/how-to/maintain/ansible-operations.md delete mode 100644 v2.1/how-to/maintain/backup-and-restore.md delete mode 100644 v2.1/how-to/maintain/identify-slow-queries.md delete mode 100644 v2.1/how-to/migrate/from-aurora.md delete mode 100644 v2.1/how-to/migrate/from-mysql.md delete mode 100644 v2.1/how-to/migrate/incrementally-from-mysql.md delete mode 100644 v2.1/how-to/migrate/overview.md delete mode 100644 v2.1/how-to/monitor/monitor-a-cluster.md delete mode 100644 v2.1/how-to/monitor/overview.md delete mode 100644 v2.1/how-to/scale/horizontally.md delete mode 100644 v2.1/how-to/scale/with-ansible.md delete mode 100644 v2.1/how-to/secure/enable-tls-between-components.md delete mode 100644 v2.1/how-to/secure/enable-tls-clients.md delete mode 100644 v2.1/how-to/secure/generate-self-signed-certificates.md delete mode 100644 v2.1/how-to/troubleshoot/cluster-setup.md delete mode 100644 v2.1/how-to/troubleshoot/tidb-lightning.md delete mode 100644 v2.1/how-to/upgrade/from-previous-version.md delete mode 100644 v2.1/key-features.md delete mode 100644 v2.1/overview.md delete mode 100644 v2.1/reference/alert-rules.md delete mode 100644 v2.1/reference/best-practices/grafana-monitor.md delete mode 100644 v2.1/reference/best-practices/haproxy.md delete mode 100644 v2.1/reference/best-practices/java-app.md delete mode 100644 v2.1/reference/best-practices/massive-regions.md delete mode 100644 v2.1/reference/best-practices/pd-scheduling.md delete mode 100644 v2.1/reference/configuration/pd-server/configuration.md delete mode 100644 v2.1/reference/configuration/tidb-server/configuration-file.md delete mode 100644 v2.1/reference/configuration/tidb-server/configuration.md delete mode 100644 v2.1/reference/configuration/tidb-server/mysql-variables.md delete mode 100644 v2.1/reference/configuration/tidb-server/tidb-specific-variables.md delete mode 100644 v2.1/reference/configuration/tikv-server/configuration.md delete mode 100644 v2.1/reference/error-codes.md delete mode 100644 v2.1/reference/garbage-collection.md delete mode 100644 v2.1/reference/key-monitoring-metrics/overview-dashboard.md delete mode 100644 v2.1/reference/key-monitoring-metrics/pd-dashboard.md delete mode 100644 v2.1/reference/key-monitoring-metrics/tidb-dashboard.md delete mode 100644 v2.1/reference/key-monitoring-metrics/tikv-dashboard.md delete mode 100644 v2.1/reference/mysql-compatibility.md delete mode 100644 v2.1/reference/performance/optimizer-hints.md delete mode 100644 v2.1/reference/performance/sql-optimizer-overview.md delete mode 100644 v2.1/reference/performance/statistics.md delete mode 100644 v2.1/reference/performance/tune-tikv.md delete mode 100644 v2.1/reference/performance/understanding-the-query-execution-plan.md delete mode 100644 v2.1/reference/security/compatibility.md delete mode 100644 v2.1/reference/security/privilege-system.md delete mode 100644 v2.1/reference/security/user-account-management.md delete mode 100644 v2.1/reference/sql/character-set.md delete mode 100644 v2.1/reference/sql/constraints.md delete mode 100644 v2.1/reference/sql/data-types/default-values.md delete mode 100644 v2.1/reference/sql/data-types/json.md delete mode 100644 v2.1/reference/sql/data-types/numeric.md delete mode 100644 v2.1/reference/sql/data-types/overview.md delete mode 100644 v2.1/reference/sql/data-types/string.md delete mode 100644 v2.1/reference/sql/functions-and-operators/aggregate-group-by-functions.md delete mode 100644 v2.1/reference/sql/functions-and-operators/bit-functions-and-operators.md delete mode 100644 v2.1/reference/sql/functions-and-operators/cast-functions-and-operators.md delete mode 100644 v2.1/reference/sql/functions-and-operators/control-flow-functions.md delete mode 100644 v2.1/reference/sql/functions-and-operators/date-and-time-functions.md delete mode 100644 v2.1/reference/sql/functions-and-operators/encryption-and-compression-functions.md delete mode 100644 v2.1/reference/sql/functions-and-operators/information-functions.md delete mode 100644 v2.1/reference/sql/functions-and-operators/json-functions.md delete mode 100644 v2.1/reference/sql/functions-and-operators/miscellaneous-functions.md delete mode 100644 v2.1/reference/sql/functions-and-operators/numeric-functions-and-operators.md delete mode 100644 v2.1/reference/sql/functions-and-operators/operators.md delete mode 100644 v2.1/reference/sql/functions-and-operators/precision-math.md delete mode 100644 v2.1/reference/sql/functions-and-operators/reference.md delete mode 100644 v2.1/reference/sql/functions-and-operators/string-functions.md delete mode 100644 v2.1/reference/sql/functions-and-operators/type-conversion.md delete mode 100644 v2.1/reference/sql/generated-columns.md delete mode 100644 v2.1/reference/sql/language-structure/comment-syntax.md delete mode 100644 v2.1/reference/sql/language-structure/expression-syntax.md delete mode 100644 v2.1/reference/sql/language-structure/keywords-and-reserved-words.md delete mode 100644 v2.1/reference/sql/language-structure/literal-values.md delete mode 100644 v2.1/reference/sql/language-structure/schema-object-names.md delete mode 100644 v2.1/reference/sql/language-structure/user-defined-variables.md delete mode 100644 v2.1/reference/sql/statements/add-column.md delete mode 100644 v2.1/reference/sql/statements/add-index.md delete mode 100644 v2.1/reference/sql/statements/admin.md delete mode 100644 v2.1/reference/sql/statements/alter-database.md delete mode 100644 v2.1/reference/sql/statements/alter-table.md delete mode 100644 v2.1/reference/sql/statements/alter-user.md delete mode 100644 v2.1/reference/sql/statements/analyze-table.md delete mode 100644 v2.1/reference/sql/statements/begin.md delete mode 100644 v2.1/reference/sql/statements/change-column.md delete mode 100644 v2.1/reference/sql/statements/commit.md delete mode 100644 v2.1/reference/sql/statements/create-database.md delete mode 100644 v2.1/reference/sql/statements/create-index.md delete mode 100644 v2.1/reference/sql/statements/create-table-like.md delete mode 100644 v2.1/reference/sql/statements/create-table.md delete mode 100644 v2.1/reference/sql/statements/create-user.md delete mode 100644 v2.1/reference/sql/statements/deallocate.md delete mode 100644 v2.1/reference/sql/statements/delete.md delete mode 100644 v2.1/reference/sql/statements/desc.md delete mode 100644 v2.1/reference/sql/statements/describe.md delete mode 100644 v2.1/reference/sql/statements/do.md delete mode 100644 v2.1/reference/sql/statements/drop-column.md delete mode 100644 v2.1/reference/sql/statements/drop-database.md delete mode 100644 v2.1/reference/sql/statements/drop-index.md delete mode 100644 v2.1/reference/sql/statements/drop-table.md delete mode 100644 v2.1/reference/sql/statements/drop-user.md delete mode 100644 v2.1/reference/sql/statements/execute.md delete mode 100644 v2.1/reference/sql/statements/explain-analyze.md delete mode 100644 v2.1/reference/sql/statements/explain.md delete mode 100644 v2.1/reference/sql/statements/flush-privileges.md delete mode 100644 v2.1/reference/sql/statements/flush-status.md delete mode 100644 v2.1/reference/sql/statements/flush-tables.md delete mode 100644 v2.1/reference/sql/statements/grant-privileges.md delete mode 100644 v2.1/reference/sql/statements/insert.md delete mode 100644 v2.1/reference/sql/statements/kill.md delete mode 100644 v2.1/reference/sql/statements/load-data.md delete mode 100644 v2.1/reference/sql/statements/modify-column.md delete mode 100644 v2.1/reference/sql/statements/prepare.md delete mode 100644 v2.1/reference/sql/statements/rename-index.md delete mode 100644 v2.1/reference/sql/statements/rename-table.md delete mode 100644 v2.1/reference/sql/statements/replace.md delete mode 100644 v2.1/reference/sql/statements/revoke-privileges.md delete mode 100644 v2.1/reference/sql/statements/rollback.md delete mode 100644 v2.1/reference/sql/statements/select.md delete mode 100644 v2.1/reference/sql/statements/set-names.md delete mode 100644 v2.1/reference/sql/statements/set-password.md delete mode 100644 v2.1/reference/sql/statements/set-transaction.md delete mode 100644 v2.1/reference/sql/statements/set-variable.md delete mode 100644 v2.1/reference/sql/statements/show-character-set.md delete mode 100644 v2.1/reference/sql/statements/show-collation.md delete mode 100644 v2.1/reference/sql/statements/show-columns-from.md delete mode 100644 v2.1/reference/sql/statements/show-create-table.md delete mode 100644 v2.1/reference/sql/statements/show-databases.md delete mode 100644 v2.1/reference/sql/statements/show-engines.md delete mode 100644 v2.1/reference/sql/statements/show-errors.md delete mode 100644 v2.1/reference/sql/statements/show-fields-from.md delete mode 100644 v2.1/reference/sql/statements/show-grants.md delete mode 100644 v2.1/reference/sql/statements/show-index.md delete mode 100644 v2.1/reference/sql/statements/show-indexes.md delete mode 100644 v2.1/reference/sql/statements/show-keys.md delete mode 100644 v2.1/reference/sql/statements/show-privileges.md delete mode 100644 v2.1/reference/sql/statements/show-processlist.md delete mode 100644 v2.1/reference/sql/statements/show-schemas.md delete mode 100644 v2.1/reference/sql/statements/show-status.md delete mode 100644 v2.1/reference/sql/statements/show-table-regions.md delete mode 100644 v2.1/reference/sql/statements/show-table-status.md delete mode 100644 v2.1/reference/sql/statements/show-tables.md delete mode 100644 v2.1/reference/sql/statements/show-variables.md delete mode 100644 v2.1/reference/sql/statements/show-warnings.md delete mode 100644 v2.1/reference/sql/statements/split-region.md delete mode 100644 v2.1/reference/sql/statements/start-transaction.md delete mode 100644 v2.1/reference/sql/statements/trace.md delete mode 100644 v2.1/reference/sql/statements/truncate.md delete mode 100644 v2.1/reference/sql/statements/update.md delete mode 100644 v2.1/reference/sql/statements/use.md delete mode 100644 v2.1/reference/supported-clients.md delete mode 100644 v2.1/reference/system-databases/information-schema.md delete mode 100644 v2.1/reference/system-databases/mysql.md delete mode 100644 v2.1/reference/tidb-binlog/binlog-slave-client.md delete mode 100644 v2.1/reference/tidb-binlog/deploy.md delete mode 100644 v2.1/reference/tidb-binlog/faq.md delete mode 100644 v2.1/reference/tidb-binlog/maintain.md delete mode 100644 v2.1/reference/tidb-binlog/monitor.md delete mode 100644 v2.1/reference/tidb-binlog/overview.md delete mode 100644 v2.1/reference/tidb-binlog/reparo.md delete mode 100644 v2.1/reference/tidb-binlog/tidb-binlog-kafka.md delete mode 100644 v2.1/reference/tidb-binlog/tidb-binlog-local.md delete mode 100644 v2.1/reference/tidb-binlog/troubleshoot/binlog.md delete mode 100644 v2.1/reference/tidb-binlog/troubleshoot/error-handling.md delete mode 100644 v2.1/reference/tidb-binlog/upgrade.md delete mode 100644 v2.1/reference/tispark.md delete mode 100644 v2.1/reference/tools/data-migration/cluster-operations.md delete mode 100644 v2.1/reference/tools/data-migration/configure/dm-master-configuration-file.md delete mode 100644 v2.1/reference/tools/data-migration/configure/dm-worker-configuration-file-full.md delete mode 100644 v2.1/reference/tools/data-migration/configure/dm-worker-configuration-file.md delete mode 100644 v2.1/reference/tools/data-migration/configure/overview.md delete mode 100644 v2.1/reference/tools/data-migration/configure/task-configuration-file-full.md delete mode 100644 v2.1/reference/tools/data-migration/configure/task-configuration-file.md delete mode 100644 v2.1/reference/tools/data-migration/deploy.md delete mode 100644 v2.1/reference/tools/data-migration/dm-portal.md delete mode 100644 v2.1/reference/tools/data-migration/dm-upgrade.md delete mode 100644 v2.1/reference/tools/data-migration/dm-worker-intro.md delete mode 100644 v2.1/reference/tools/data-migration/faq.md delete mode 100644 v2.1/reference/tools/data-migration/features/manually-handling-sharding-ddl-locks.md delete mode 100644 v2.1/reference/tools/data-migration/features/overview.md delete mode 100644 v2.1/reference/tools/data-migration/features/shard-merge.md delete mode 100644 v2.1/reference/tools/data-migration/from-aurora.md delete mode 100644 v2.1/reference/tools/data-migration/glossary.md delete mode 100644 v2.1/reference/tools/data-migration/manage-tasks.md delete mode 100644 v2.1/reference/tools/data-migration/monitor.md delete mode 100644 v2.1/reference/tools/data-migration/overview.md delete mode 100644 v2.1/reference/tools/data-migration/precheck.md delete mode 100644 v2.1/reference/tools/data-migration/query-status.md delete mode 100644 v2.1/reference/tools/data-migration/relay-log.md delete mode 100644 v2.1/reference/tools/data-migration/releases/1.0.2.md delete mode 100644 v2.1/reference/tools/data-migration/releases/1.0.3.md delete mode 100644 v2.1/reference/tools/data-migration/skip-replace-sqls.md delete mode 100644 v2.1/reference/tools/data-migration/table-selector.md delete mode 100644 v2.1/reference/tools/data-migration/troubleshoot/dm.md delete mode 100644 v2.1/reference/tools/data-migration/troubleshoot/error-handling.md delete mode 100644 v2.1/reference/tools/data-migration/troubleshoot/error-system.md delete mode 100644 v2.1/reference/tools/data-migration/usage-scenarios/best-practice-dm-shard.md delete mode 100644 v2.1/reference/tools/data-migration/usage-scenarios/master-slave-switch.md delete mode 100644 v2.1/reference/tools/data-migration/usage-scenarios/shard-merge.md delete mode 100644 v2.1/reference/tools/data-migration/usage-scenarios/simple-synchronization.md delete mode 100644 v2.1/reference/tools/download.md delete mode 100644 v2.1/reference/tools/loader.md delete mode 100644 v2.1/reference/tools/mydumper.md delete mode 100644 v2.1/reference/tools/pd-control.md delete mode 100644 v2.1/reference/tools/pd-recover.md delete mode 100644 v2.1/reference/tools/sync-diff-inspector/overview.md delete mode 100644 v2.1/reference/tools/sync-diff-inspector/route-diff.md delete mode 100644 v2.1/reference/tools/sync-diff-inspector/shard-diff.md delete mode 100644 v2.1/reference/tools/sync-diff-inspector/tidb-diff.md delete mode 100644 v2.1/reference/tools/syncer.md delete mode 100644 v2.1/reference/tools/tidb-control.md delete mode 100644 v2.1/reference/tools/tidb-lightning/checkpoints.md delete mode 100644 v2.1/reference/tools/tidb-lightning/config.md delete mode 100644 v2.1/reference/tools/tidb-lightning/csv.md delete mode 100644 v2.1/reference/tools/tidb-lightning/deployment.md delete mode 100644 v2.1/reference/tools/tidb-lightning/glossary.md delete mode 100644 v2.1/reference/tools/tidb-lightning/monitor.md delete mode 100644 v2.1/reference/tools/tidb-lightning/overview.md delete mode 100644 v2.1/reference/tools/tidb-lightning/table-filter.md delete mode 100644 v2.1/reference/tools/tidb-lightning/web.md delete mode 100644 v2.1/reference/tools/tikv-control.md delete mode 100644 v2.1/reference/transactions/transaction-isolation.md delete mode 100644 v2.1/reference/transactions/transaction-optimistic.md delete mode 100644 v2.1/releases/11alpha.md delete mode 100644 v2.1/releases/11beta.md delete mode 100644 v2.1/releases/2.0.10.md delete mode 100644 v2.1/releases/2.0.11.md delete mode 100644 v2.1/releases/2.0ga.md delete mode 100644 v2.1/releases/2.1.1.md delete mode 100644 v2.1/releases/2.1.10.md delete mode 100644 v2.1/releases/2.1.11.md delete mode 100644 v2.1/releases/2.1.12.md delete mode 100644 v2.1/releases/2.1.13.md delete mode 100644 v2.1/releases/2.1.14.md delete mode 100644 v2.1/releases/2.1.15.md delete mode 100644 v2.1/releases/2.1.16.md delete mode 100644 v2.1/releases/2.1.17.md delete mode 100644 v2.1/releases/2.1.18.md delete mode 100644 v2.1/releases/2.1.19.md delete mode 100644 v2.1/releases/2.1.2.md delete mode 100644 v2.1/releases/2.1.3.md delete mode 100644 v2.1/releases/2.1.4.md delete mode 100644 v2.1/releases/2.1.5.md delete mode 100644 v2.1/releases/2.1.6.md delete mode 100644 v2.1/releases/2.1.7.md delete mode 100644 v2.1/releases/2.1.8.md delete mode 100644 v2.1/releases/2.1.9.md delete mode 100644 v2.1/releases/2.1ga.md delete mode 100644 v2.1/releases/201.md delete mode 100644 v2.1/releases/202.md delete mode 100644 v2.1/releases/203.md delete mode 100644 v2.1/releases/204.md delete mode 100644 v2.1/releases/205.md delete mode 100644 v2.1/releases/206.md delete mode 100644 v2.1/releases/207.md delete mode 100644 v2.1/releases/208.md delete mode 100644 v2.1/releases/209.md delete mode 100644 v2.1/releases/21beta.md delete mode 100644 v2.1/releases/21rc1.md delete mode 100644 v2.1/releases/21rc2.md delete mode 100644 v2.1/releases/21rc3.md delete mode 100644 v2.1/releases/21rc4.md delete mode 100644 v2.1/releases/21rc5.md delete mode 100644 v2.1/releases/2rc1.md delete mode 100644 v2.1/releases/2rc3.md delete mode 100644 v2.1/releases/2rc4.md delete mode 100644 v2.1/releases/2rc5.md delete mode 100644 v2.1/releases/3.0.0-beta.1.md delete mode 100644 v2.1/releases/3.0.0-rc.1.md delete mode 100644 v2.1/releases/3.0.0-rc.2.md delete mode 100644 v2.1/releases/3.0.1.md delete mode 100644 v2.1/releases/3.0beta.md delete mode 100644 v2.1/releases/ga.md delete mode 100644 v2.1/releases/prega.md delete mode 100644 v2.1/releases/rc1.md delete mode 100644 v2.1/releases/rc2.md delete mode 100644 v2.1/releases/rc3.md delete mode 100644 v2.1/releases/rc4.md delete mode 100644 v2.1/releases/rn.md delete mode 100644 v2.1/report-issue.md delete mode 100644 v2.1/support-resources.md delete mode 100644 v2.1/tispark/tispark-quick-start-guide_v1.x.md delete mode 100644 v2.1/tispark/tispark-user-guide_v1.x.md delete mode 100644 v3.0/TOC.md mode change 100755 => 100644 v3.0/_index.md delete mode 100644 v3.0/architecture.md delete mode 100644 v3.0/benchmark/add-index-with-load.md delete mode 100644 v3.0/benchmark/dm-v1.0-ga.md delete mode 100644 v3.0/benchmark/how-to-run-tpcc.md delete mode 100644 v3.0/benchmark/sysbench-in-k8s.md delete mode 100644 v3.0/benchmark/tpcc.md delete mode 100644 v3.0/glossary.md delete mode 100644 v3.0/how-to/deploy/data-migration-with-binary.md delete mode 100644 v3.0/how-to/get-started/data-migration.md delete mode 100644 v3.0/how-to/get-started/tidb-lightning.md delete mode 100644 v3.0/how-to/get-started/tispark.md delete mode 100644 v3.0/how-to/maintain/identify-abnormal-queries/identify-aborted-queries.md delete mode 100644 v3.0/overview.md delete mode 100644 v3.0/reference/alert-rules.md delete mode 100644 v3.0/reference/best-practices/grafana-monitor.md delete mode 100644 v3.0/reference/best-practices/haproxy.md delete mode 100644 v3.0/reference/best-practices/massive-regions.md delete mode 100644 v3.0/reference/best-practices/pd-scheduling.md delete mode 100644 v3.0/reference/configuration/pd-server/configuration-file.md delete mode 100644 v3.0/reference/garbage-collection/configuration.md delete mode 100644 v3.0/reference/key-monitoring-metrics/tidb-dashboard.md delete mode 100644 v3.0/reference/mysql-compatibility.md delete mode 100644 v3.0/reference/performance/check-cluster-status-using-sql-statements.md delete mode 100644 v3.0/reference/performance/statement-summary.md delete mode 100644 v3.0/reference/security/cert-based-authentication.md delete mode 100644 v3.0/reference/security/role-based-access-control.md delete mode 100644 v3.0/reference/sql/data-types/date-and-time.md delete mode 100644 v3.0/reference/sql/data-types/default-values.md delete mode 100644 v3.0/reference/sql/data-types/json.md delete mode 100644 v3.0/reference/sql/data-types/numeric.md delete mode 100644 v3.0/reference/sql/data-types/string.md delete mode 100644 v3.0/reference/sql/functions-and-operators/expressions-pushed-down.md delete mode 100644 v3.0/reference/sql/functions-and-operators/window-functions.md delete mode 100644 v3.0/reference/sql/partitioning.md delete mode 100644 v3.0/reference/sql/statements/add-column.md delete mode 100644 v3.0/reference/sql/statements/add-index.md delete mode 100644 v3.0/reference/sql/statements/alter-database.md delete mode 100644 v3.0/reference/sql/statements/alter-table.md delete mode 100644 v3.0/reference/sql/statements/alter-user.md delete mode 100644 v3.0/reference/sql/statements/analyze-table.md delete mode 100644 v3.0/reference/sql/statements/begin.md delete mode 100644 v3.0/reference/sql/statements/change-column.md delete mode 100644 v3.0/reference/sql/statements/commit.md delete mode 100644 v3.0/reference/sql/statements/create-database.md delete mode 100644 v3.0/reference/sql/statements/create-index.md delete mode 100644 v3.0/reference/sql/statements/create-table-like.md delete mode 100644 v3.0/reference/sql/statements/create-user.md delete mode 100644 v3.0/reference/sql/statements/create-view.md delete mode 100644 v3.0/reference/sql/statements/deallocate.md delete mode 100644 v3.0/reference/sql/statements/delete.md delete mode 100644 v3.0/reference/sql/statements/desc.md delete mode 100644 v3.0/reference/sql/statements/describe.md delete mode 100644 v3.0/reference/sql/statements/do.md delete mode 100644 v3.0/reference/sql/statements/drop-column.md delete mode 100644 v3.0/reference/sql/statements/drop-database.md delete mode 100644 v3.0/reference/sql/statements/drop-index.md delete mode 100644 v3.0/reference/sql/statements/drop-table.md delete mode 100644 v3.0/reference/sql/statements/drop-user.md delete mode 100644 v3.0/reference/sql/statements/drop-view.md delete mode 100644 v3.0/reference/sql/statements/execute.md delete mode 100644 v3.0/reference/sql/statements/explain-analyze.md delete mode 100644 v3.0/reference/sql/statements/flush-privileges.md delete mode 100644 v3.0/reference/sql/statements/flush-status.md delete mode 100644 v3.0/reference/sql/statements/flush-tables.md delete mode 100644 v3.0/reference/sql/statements/grant-privileges.md delete mode 100644 v3.0/reference/sql/statements/insert.md delete mode 100644 v3.0/reference/sql/statements/kill.md delete mode 100644 v3.0/reference/sql/statements/modify-column.md delete mode 100644 v3.0/reference/sql/statements/rename-index.md delete mode 100644 v3.0/reference/sql/statements/rename-table.md delete mode 100644 v3.0/reference/sql/statements/replace.md delete mode 100644 v3.0/reference/sql/statements/revoke-privileges.md delete mode 100644 v3.0/reference/sql/statements/rollback.md delete mode 100644 v3.0/reference/sql/statements/set-names.md delete mode 100644 v3.0/reference/sql/statements/set-password.md delete mode 100644 v3.0/reference/sql/statements/set-transaction.md delete mode 100644 v3.0/reference/sql/statements/set-variable.md delete mode 100644 v3.0/reference/sql/statements/show-character-set.md delete mode 100644 v3.0/reference/sql/statements/show-collation.md delete mode 100644 v3.0/reference/sql/statements/show-columns-from.md delete mode 100644 v3.0/reference/sql/statements/show-create-table.md delete mode 100644 v3.0/reference/sql/statements/show-create-user.md delete mode 100644 v3.0/reference/sql/statements/show-databases.md delete mode 100644 v3.0/reference/sql/statements/show-engines.md delete mode 100644 v3.0/reference/sql/statements/show-errors.md delete mode 100644 v3.0/reference/sql/statements/show-fields-from.md delete mode 100644 v3.0/reference/sql/statements/show-grants.md delete mode 100644 v3.0/reference/sql/statements/show-index.md delete mode 100644 v3.0/reference/sql/statements/show-indexes.md delete mode 100644 v3.0/reference/sql/statements/show-keys.md delete mode 100644 v3.0/reference/sql/statements/show-privileges.md delete mode 100644 v3.0/reference/sql/statements/show-processlist.md delete mode 100644 v3.0/reference/sql/statements/show-schemas.md delete mode 100644 v3.0/reference/sql/statements/show-status.md delete mode 100644 v3.0/reference/sql/statements/show-table-status.md delete mode 100644 v3.0/reference/sql/statements/show-tables.md delete mode 100644 v3.0/reference/sql/statements/show-warnings.md delete mode 100644 v3.0/reference/sql/statements/split-region.md delete mode 100644 v3.0/reference/sql/statements/start-transaction.md delete mode 100644 v3.0/reference/sql/statements/trace.md delete mode 100644 v3.0/reference/sql/statements/truncate.md delete mode 100644 v3.0/reference/sql/statements/update.md delete mode 100644 v3.0/reference/sql/statements/use.md delete mode 100644 v3.0/reference/sql/view.md delete mode 100644 v3.0/reference/tidb-binlog/glossary.md delete mode 100644 v3.0/reference/tidb-binlog/troubleshoot/error-handling.md delete mode 100644 v3.0/reference/tools/data-migration/configure/dm-master-configuration-file.md delete mode 100644 v3.0/reference/tools/data-migration/configure/dm-worker-configuration-file-full.md delete mode 100644 v3.0/reference/tools/data-migration/configure/dm-worker-configuration-file.md delete mode 100644 v3.0/reference/tools/data-migration/configure/task-configuration-file-full.md delete mode 100644 v3.0/reference/tools/data-migration/dm-portal.md delete mode 100644 v3.0/reference/tools/data-migration/glossary.md delete mode 100644 v3.0/reference/tools/data-migration/manage-tasks.md delete mode 100644 v3.0/reference/tools/data-migration/monitor.md delete mode 100644 v3.0/reference/tools/data-migration/releases/1.0.2.md delete mode 100644 v3.0/reference/tools/data-migration/releases/1.0.3.md delete mode 100644 v3.0/reference/tools/data-migration/troubleshoot/error-handling.md delete mode 100644 v3.0/reference/tools/data-migration/usage-scenarios/best-practice-dm-shard.md delete mode 100644 v3.0/reference/tools/data-migration/usage-scenarios/master-slave-switch.md delete mode 100644 v3.0/reference/tools/error-case-handling/lightning-misuse-handling.md delete mode 100644 v3.0/reference/tools/sync-diff-inspector/route-diff.md delete mode 100644 v3.0/reference/tools/sync-diff-inspector/shard-diff.md delete mode 100644 v3.0/reference/tools/sync-diff-inspector/tidb-diff.md delete mode 100644 v3.0/reference/tools/tidb-control.md delete mode 100644 v3.0/reference/tools/tidb-lightning/config.md delete mode 100644 v3.0/reference/tools/tidb-lightning/glossary.md delete mode 100644 v3.0/reference/tools/tidb-lightning/monitor.md delete mode 100644 v3.0/reference/tools/tidb-lightning/overview.md delete mode 100644 v3.0/reference/tools/tidb-lightning/tidb-backend.md delete mode 100644 v3.0/reference/tools/tidb-lightning/web.md delete mode 100644 v3.0/reference/tools/tikv-control.md delete mode 100644 v3.0/reference/transactions/overview.md delete mode 100644 v3.0/releases/2.1.13.md delete mode 100644 v3.0/releases/2.1.14.md delete mode 100644 v3.0/releases/2.1.15.md delete mode 100644 v3.0/releases/2.1.16.md delete mode 100644 v3.0/releases/2.1.17.md delete mode 100644 v3.0/releases/2.1.19.md delete mode 100644 v3.0/releases/3.0-ga.md delete mode 100644 v3.0/releases/3.0.0-rc.3.md delete mode 100644 v3.0/releases/3.0.1.md delete mode 100644 v3.0/releases/3.0.10.md delete mode 100644 v3.0/releases/3.0.3.md delete mode 100644 v3.0/releases/3.0.4.md delete mode 100644 v3.0/releases/3.0.5.md delete mode 100644 v3.0/releases/3.0.6.md delete mode 100644 v3.0/releases/3.0.7.md delete mode 100644 v3.0/releases/3.0.8.md delete mode 100644 v3.0/releases/3.0.9.md delete mode 100644 v3.0/releases/rn.md delete mode 100644 v3.0/roadmap.md delete mode 100644 v3.0/tidb-in-kubernetes/maintain/lightning.md delete mode 100644 v3.0/tidb-in-kubernetes/maintain/restart.md delete mode 100644 v3.0/tidb-in-kubernetes/maintain/tidb-binlog.md delete mode 100644 v3.0/tidb-in-kubernetes/reference/configuration/tidb-cluster.md delete mode 100644 v3.0/tidb-in-kubernetes/reference/configuration/tidb-drainer.md delete mode 100644 v3.1/TOC.md delete mode 100755 v3.1/_index.md delete mode 100644 v3.1/architecture.md delete mode 100644 v3.1/benchmark/add-index-with-load.md delete mode 100644 v3.1/benchmark/dm-v1.0-ga.md delete mode 100644 v3.1/benchmark/how-to-run-sysbench.md delete mode 100644 v3.1/benchmark/how-to-run-tpcc.md delete mode 100644 v3.1/benchmark/sysbench-in-k8s.md delete mode 100644 v3.1/benchmark/sysbench-v2.md delete mode 100644 v3.1/benchmark/sysbench-v3.md delete mode 100644 v3.1/benchmark/sysbench-v4.md delete mode 100644 v3.1/benchmark/sysbench.md delete mode 100644 v3.1/benchmark/tpcc.md delete mode 100644 v3.1/benchmark/tpch-v2.md delete mode 100644 v3.1/benchmark/tpch.md delete mode 100644 v3.1/contribute.md delete mode 100644 v3.1/faq/tidb-lightning.md delete mode 100755 v3.1/faq/tidb.md delete mode 100644 v3.1/faq/upgrade.md delete mode 100644 v3.1/glossary.md delete mode 100644 v3.1/how-to/configure/memory-control.md delete mode 100644 v3.1/how-to/configure/time-zone.md delete mode 100644 v3.1/how-to/deploy/data-migration-with-ansible.md delete mode 100644 v3.1/how-to/deploy/data-migration-with-binary.md delete mode 100644 v3.1/how-to/deploy/geographic-redundancy/location-awareness.md delete mode 100644 v3.1/how-to/deploy/geographic-redundancy/overview.md delete mode 100644 v3.1/how-to/deploy/hardware-recommendations.md delete mode 100644 v3.1/how-to/deploy/orchestrated/ansible.md delete mode 100644 v3.1/how-to/deploy/orchestrated/docker.md delete mode 100644 v3.1/how-to/deploy/orchestrated/offline-ansible.md delete mode 100644 v3.1/how-to/get-started/data-migration.md delete mode 100644 v3.1/how-to/get-started/deploy-tidb-from-docker-compose.md delete mode 100644 v3.1/how-to/get-started/explore-sql.md delete mode 100644 v3.1/how-to/get-started/read-historical-data.md delete mode 100644 v3.1/how-to/get-started/tidb-binlog.md delete mode 100644 v3.1/how-to/get-started/tidb-lightning.md delete mode 100644 v3.1/how-to/get-started/tispark.md delete mode 100644 v3.1/how-to/maintain/ansible-operations.md delete mode 100644 v3.1/how-to/maintain/backup-and-restore/mydumper-lightning.md delete mode 100644 v3.1/how-to/maintain/identify-abnormal-queries/identify-aborted-queries.md delete mode 100644 v3.1/how-to/maintain/identify-abnormal-queries/identify-slow-queries.md delete mode 100644 v3.1/how-to/migrate/from-mysql-aurora.md delete mode 100644 v3.1/how-to/monitor/monitor-a-cluster.md delete mode 100644 v3.1/how-to/monitor/overview.md delete mode 100644 v3.1/how-to/scale/horizontally.md delete mode 100644 v3.1/how-to/scale/with-ansible.md delete mode 100644 v3.1/how-to/secure/enable-tls-between-components.md delete mode 100644 v3.1/how-to/secure/enable-tls-clients.md delete mode 100644 v3.1/how-to/secure/generate-self-signed-certificates.md delete mode 100644 v3.1/how-to/troubleshoot/cluster-setup.md delete mode 100644 v3.1/how-to/troubleshoot/tidb-lightning.md delete mode 100644 v3.1/how-to/upgrade/from-previous-version.md delete mode 100644 v3.1/key-features.md delete mode 100644 v3.1/reference/alert-rules.md delete mode 100644 v3.1/reference/best-practices/grafana-monitor.md delete mode 100644 v3.1/reference/best-practices/haproxy.md delete mode 100644 v3.1/reference/best-practices/high-concurrency.md delete mode 100644 v3.1/reference/best-practices/java-app.md delete mode 100644 v3.1/reference/best-practices/massive-regions.md delete mode 100644 v3.1/reference/best-practices/pd-scheduling.md delete mode 100644 v3.1/reference/configuration/pd-server/configuration-file.md delete mode 100644 v3.1/reference/configuration/pd-server/configuration.md delete mode 100644 v3.1/reference/configuration/tidb-server/configuration-file.md delete mode 100644 v3.1/reference/configuration/tidb-server/configuration.md delete mode 100644 v3.1/reference/configuration/tidb-server/mysql-variables.md delete mode 100644 v3.1/reference/configuration/tidb-server/tidb-specific-variables.md delete mode 100644 v3.1/reference/configuration/tikv-server/configuration-file.md delete mode 100644 v3.1/reference/configuration/tikv-server/configuration.md delete mode 100644 v3.1/reference/error-codes.md delete mode 100644 v3.1/reference/garbage-collection/configuration.md delete mode 100644 v3.1/reference/garbage-collection/overview.md delete mode 100644 v3.1/reference/key-monitoring-metrics/overview-dashboard.md delete mode 100644 v3.1/reference/key-monitoring-metrics/pd-dashboard.md delete mode 100644 v3.1/reference/key-monitoring-metrics/tidb-dashboard.md delete mode 100644 v3.1/reference/key-monitoring-metrics/tikv-dashboard.md delete mode 100644 v3.1/reference/performance/check-cluster-status-using-sql-statements.md delete mode 100644 v3.1/reference/performance/execution-plan-bind.md delete mode 100644 v3.1/reference/performance/follower-read.md delete mode 100644 v3.1/reference/performance/optimizer-hints.md delete mode 100644 v3.1/reference/performance/sql-optimizer-overview.md delete mode 100644 v3.1/reference/performance/statement-summary.md delete mode 100644 v3.1/reference/performance/statistics.md delete mode 100644 v3.1/reference/performance/tune-tikv.md delete mode 100644 v3.1/reference/performance/understanding-the-query-execution-plan.md delete mode 100644 v3.1/reference/security/cert-based-authentication.md delete mode 100644 v3.1/reference/security/compatibility.md delete mode 100644 v3.1/reference/security/privilege-system.md delete mode 100644 v3.1/reference/security/role-based-access-control.md delete mode 100644 v3.1/reference/security/user-account-management.md delete mode 100644 v3.1/reference/sql/character-set.md delete mode 100644 v3.1/reference/sql/constraints.md delete mode 100644 v3.1/reference/sql/data-types/date-and-time.md delete mode 100644 v3.1/reference/sql/data-types/default-values.md delete mode 100644 v3.1/reference/sql/data-types/json.md delete mode 100644 v3.1/reference/sql/data-types/numeric.md delete mode 100644 v3.1/reference/sql/data-types/overview.md delete mode 100644 v3.1/reference/sql/data-types/string.md delete mode 100644 v3.1/reference/sql/functions-and-operators/aggregate-group-by-functions.md delete mode 100644 v3.1/reference/sql/functions-and-operators/bit-functions-and-operators.md delete mode 100644 v3.1/reference/sql/functions-and-operators/cast-functions-and-operators.md delete mode 100644 v3.1/reference/sql/functions-and-operators/control-flow-functions.md delete mode 100644 v3.1/reference/sql/functions-and-operators/date-and-time-functions.md delete mode 100644 v3.1/reference/sql/functions-and-operators/encryption-and-compression-functions.md delete mode 100644 v3.1/reference/sql/functions-and-operators/expressions-pushed-down.md delete mode 100644 v3.1/reference/sql/functions-and-operators/information-functions.md delete mode 100644 v3.1/reference/sql/functions-and-operators/json-functions.md delete mode 100644 v3.1/reference/sql/functions-and-operators/miscellaneous-functions.md delete mode 100644 v3.1/reference/sql/functions-and-operators/numeric-functions-and-operators.md delete mode 100644 v3.1/reference/sql/functions-and-operators/operators.md delete mode 100644 v3.1/reference/sql/functions-and-operators/precision-math.md delete mode 100644 v3.1/reference/sql/functions-and-operators/reference.md delete mode 100644 v3.1/reference/sql/functions-and-operators/string-functions.md delete mode 100644 v3.1/reference/sql/functions-and-operators/type-conversion.md delete mode 100644 v3.1/reference/sql/functions-and-operators/window-functions.md delete mode 100644 v3.1/reference/sql/generated-columns.md delete mode 100644 v3.1/reference/sql/language-structure/comment-syntax.md delete mode 100644 v3.1/reference/sql/language-structure/expression-syntax.md delete mode 100644 v3.1/reference/sql/language-structure/keywords-and-reserved-words.md delete mode 100644 v3.1/reference/sql/language-structure/literal-values.md delete mode 100644 v3.1/reference/sql/language-structure/schema-object-names.md delete mode 100644 v3.1/reference/sql/language-structure/user-defined-variables.md delete mode 100644 v3.1/reference/sql/partitioning.md delete mode 100644 v3.1/reference/sql/sql-mode.md delete mode 100644 v3.1/reference/sql/statements/add-column.md delete mode 100644 v3.1/reference/sql/statements/add-index.md delete mode 100644 v3.1/reference/sql/statements/admin.md delete mode 100644 v3.1/reference/sql/statements/alter-database.md delete mode 100644 v3.1/reference/sql/statements/alter-table.md delete mode 100644 v3.1/reference/sql/statements/alter-user.md delete mode 100644 v3.1/reference/sql/statements/analyze-table.md delete mode 100644 v3.1/reference/sql/statements/begin.md delete mode 100644 v3.1/reference/sql/statements/change-column.md delete mode 100644 v3.1/reference/sql/statements/commit.md delete mode 100644 v3.1/reference/sql/statements/create-database.md delete mode 100644 v3.1/reference/sql/statements/create-index.md delete mode 100644 v3.1/reference/sql/statements/create-table-like.md delete mode 100644 v3.1/reference/sql/statements/create-table.md delete mode 100644 v3.1/reference/sql/statements/create-user.md delete mode 100644 v3.1/reference/sql/statements/create-view.md delete mode 100644 v3.1/reference/sql/statements/deallocate.md delete mode 100644 v3.1/reference/sql/statements/delete.md delete mode 100644 v3.1/reference/sql/statements/desc.md delete mode 100644 v3.1/reference/sql/statements/describe.md delete mode 100644 v3.1/reference/sql/statements/do.md delete mode 100644 v3.1/reference/sql/statements/drop-column.md delete mode 100644 v3.1/reference/sql/statements/drop-database.md delete mode 100644 v3.1/reference/sql/statements/drop-index.md delete mode 100644 v3.1/reference/sql/statements/drop-table.md delete mode 100644 v3.1/reference/sql/statements/drop-user.md delete mode 100644 v3.1/reference/sql/statements/drop-view.md delete mode 100644 v3.1/reference/sql/statements/execute.md delete mode 100644 v3.1/reference/sql/statements/explain-analyze.md delete mode 100644 v3.1/reference/sql/statements/explain.md delete mode 100644 v3.1/reference/sql/statements/flush-privileges.md delete mode 100644 v3.1/reference/sql/statements/flush-status.md delete mode 100644 v3.1/reference/sql/statements/flush-tables.md delete mode 100644 v3.1/reference/sql/statements/grant-privileges.md delete mode 100644 v3.1/reference/sql/statements/insert.md delete mode 100644 v3.1/reference/sql/statements/kill.md delete mode 100644 v3.1/reference/sql/statements/load-data.md delete mode 100644 v3.1/reference/sql/statements/modify-column.md delete mode 100644 v3.1/reference/sql/statements/prepare.md delete mode 100644 v3.1/reference/sql/statements/recover-table.md delete mode 100644 v3.1/reference/sql/statements/rename-index.md delete mode 100644 v3.1/reference/sql/statements/rename-table.md delete mode 100644 v3.1/reference/sql/statements/replace.md delete mode 100644 v3.1/reference/sql/statements/revoke-privileges.md delete mode 100644 v3.1/reference/sql/statements/rollback.md delete mode 100644 v3.1/reference/sql/statements/select.md delete mode 100644 v3.1/reference/sql/statements/set-names.md delete mode 100644 v3.1/reference/sql/statements/set-password.md delete mode 100644 v3.1/reference/sql/statements/set-transaction.md delete mode 100644 v3.1/reference/sql/statements/set-variable.md delete mode 100644 v3.1/reference/sql/statements/show-character-set.md delete mode 100644 v3.1/reference/sql/statements/show-collation.md delete mode 100644 v3.1/reference/sql/statements/show-columns-from.md delete mode 100644 v3.1/reference/sql/statements/show-create-table.md delete mode 100644 v3.1/reference/sql/statements/show-create-user.md delete mode 100644 v3.1/reference/sql/statements/show-databases.md delete mode 100644 v3.1/reference/sql/statements/show-engines.md delete mode 100644 v3.1/reference/sql/statements/show-errors.md delete mode 100644 v3.1/reference/sql/statements/show-fields-from.md delete mode 100644 v3.1/reference/sql/statements/show-grants.md delete mode 100644 v3.1/reference/sql/statements/show-index.md delete mode 100644 v3.1/reference/sql/statements/show-indexes.md delete mode 100644 v3.1/reference/sql/statements/show-keys.md delete mode 100644 v3.1/reference/sql/statements/show-privileges.md delete mode 100644 v3.1/reference/sql/statements/show-processlist.md delete mode 100644 v3.1/reference/sql/statements/show-schemas.md delete mode 100644 v3.1/reference/sql/statements/show-status.md delete mode 100644 v3.1/reference/sql/statements/show-table-regions.md delete mode 100644 v3.1/reference/sql/statements/show-table-status.md delete mode 100644 v3.1/reference/sql/statements/show-tables.md delete mode 100644 v3.1/reference/sql/statements/show-variables.md delete mode 100644 v3.1/reference/sql/statements/show-warnings.md delete mode 100644 v3.1/reference/sql/statements/split-region.md delete mode 100644 v3.1/reference/sql/statements/start-transaction.md delete mode 100644 v3.1/reference/sql/statements/trace.md delete mode 100644 v3.1/reference/sql/statements/truncate.md delete mode 100644 v3.1/reference/sql/statements/update.md delete mode 100644 v3.1/reference/sql/statements/use.md delete mode 100644 v3.1/reference/sql/view.md delete mode 100644 v3.1/reference/supported-clients.md delete mode 100644 v3.1/reference/system-databases/information-schema.md delete mode 100644 v3.1/reference/system-databases/mysql.md delete mode 100644 v3.1/reference/tidb-binlog/binlog-slave-client.md delete mode 100644 v3.1/reference/tidb-binlog/deploy.md delete mode 100644 v3.1/reference/tidb-binlog/faq.md delete mode 100644 v3.1/reference/tidb-binlog/glossary.md delete mode 100644 v3.1/reference/tidb-binlog/maintain.md delete mode 100644 v3.1/reference/tidb-binlog/monitor.md delete mode 100644 v3.1/reference/tidb-binlog/overview.md delete mode 100644 v3.1/reference/tidb-binlog/relay-log.md delete mode 100644 v3.1/reference/tidb-binlog/reparo.md delete mode 100644 v3.1/reference/tidb-binlog/tidb-binlog-kafka.md delete mode 100644 v3.1/reference/tidb-binlog/tidb-binlog-local.md delete mode 100644 v3.1/reference/tidb-binlog/troubleshoot/binlog.md delete mode 100644 v3.1/reference/tidb-binlog/troubleshoot/error-handling.md delete mode 100644 v3.1/reference/tidb-binlog/upgrade.md delete mode 100644 v3.1/reference/tispark.md delete mode 100644 v3.1/reference/tools/br/br.md delete mode 100644 v3.1/reference/tools/br/use-cases.md delete mode 100644 v3.1/reference/tools/data-migration/cluster-operations.md delete mode 100644 v3.1/reference/tools/data-migration/configure/dm-master-configuration-file.md delete mode 100644 v3.1/reference/tools/data-migration/configure/dm-worker-configuration-file-full.md delete mode 100644 v3.1/reference/tools/data-migration/configure/dm-worker-configuration-file.md delete mode 100644 v3.1/reference/tools/data-migration/configure/overview.md delete mode 100644 v3.1/reference/tools/data-migration/configure/task-configuration-file-full.md delete mode 100644 v3.1/reference/tools/data-migration/configure/task-configuration-file.md delete mode 100644 v3.1/reference/tools/data-migration/deploy.md delete mode 100644 v3.1/reference/tools/data-migration/dm-portal.md delete mode 100644 v3.1/reference/tools/data-migration/dm-upgrade.md delete mode 100644 v3.1/reference/tools/data-migration/dm-worker-intro.md delete mode 100644 v3.1/reference/tools/data-migration/faq.md delete mode 100644 v3.1/reference/tools/data-migration/features/manually-handling-sharding-ddl-locks.md delete mode 100644 v3.1/reference/tools/data-migration/features/overview.md delete mode 100644 v3.1/reference/tools/data-migration/features/shard-merge.md delete mode 100644 v3.1/reference/tools/data-migration/from-aurora.md delete mode 100644 v3.1/reference/tools/data-migration/glossary.md delete mode 100644 v3.1/reference/tools/data-migration/manage-tasks.md delete mode 100644 v3.1/reference/tools/data-migration/monitor.md delete mode 100644 v3.1/reference/tools/data-migration/overview.md delete mode 100644 v3.1/reference/tools/data-migration/precheck.md delete mode 100644 v3.1/reference/tools/data-migration/query-status.md delete mode 100644 v3.1/reference/tools/data-migration/relay-log.md delete mode 100644 v3.1/reference/tools/data-migration/releases/1.0.2.md delete mode 100644 v3.1/reference/tools/data-migration/releases/1.0.3.md delete mode 100644 v3.1/reference/tools/data-migration/skip-replace-sqls.md delete mode 100644 v3.1/reference/tools/data-migration/table-selector.md delete mode 100644 v3.1/reference/tools/data-migration/troubleshoot/dm.md delete mode 100644 v3.1/reference/tools/data-migration/troubleshoot/error-handling.md delete mode 100644 v3.1/reference/tools/data-migration/troubleshoot/error-system.md delete mode 100644 v3.1/reference/tools/data-migration/usage-scenarios/best-practice-dm-shard.md delete mode 100644 v3.1/reference/tools/data-migration/usage-scenarios/master-slave-switch.md delete mode 100644 v3.1/reference/tools/data-migration/usage-scenarios/shard-merge.md delete mode 100644 v3.1/reference/tools/data-migration/usage-scenarios/simple-synchronization.md delete mode 100644 v3.1/reference/tools/download.md delete mode 100644 v3.1/reference/tools/error-case-handling/lightning-misuse-handling.md delete mode 100644 v3.1/reference/tools/error-case-handling/load-misuse-handling.md delete mode 100644 v3.1/reference/tools/loader.md delete mode 100644 v3.1/reference/tools/mydumper.md delete mode 100644 v3.1/reference/tools/pd-control.md delete mode 100644 v3.1/reference/tools/pd-recover.md delete mode 100644 v3.1/reference/tools/sync-diff-inspector/overview.md delete mode 100644 v3.1/reference/tools/sync-diff-inspector/route-diff.md delete mode 100644 v3.1/reference/tools/sync-diff-inspector/shard-diff.md delete mode 100644 v3.1/reference/tools/sync-diff-inspector/tidb-diff.md delete mode 100644 v3.1/reference/tools/syncer.md delete mode 100644 v3.1/reference/tools/tidb-control.md delete mode 100644 v3.1/reference/tools/tidb-lightning/checkpoints.md delete mode 100644 v3.1/reference/tools/tidb-lightning/config.md delete mode 100644 v3.1/reference/tools/tidb-lightning/csv.md delete mode 100644 v3.1/reference/tools/tidb-lightning/deployment.md delete mode 100644 v3.1/reference/tools/tidb-lightning/glossary.md delete mode 100644 v3.1/reference/tools/tidb-lightning/monitor.md delete mode 100644 v3.1/reference/tools/tidb-lightning/overview.md delete mode 100644 v3.1/reference/tools/tidb-lightning/table-filter.md delete mode 100644 v3.1/reference/tools/tidb-lightning/tidb-backend.md delete mode 100644 v3.1/reference/tools/tidb-lightning/web.md delete mode 100644 v3.1/reference/tools/tikv-control.md delete mode 100644 v3.1/reference/tools/user-guide.md delete mode 100644 v3.1/reference/transactions/overview.md delete mode 100644 v3.1/reference/transactions/transaction-isolation.md delete mode 100644 v3.1/reference/transactions/transaction-optimistic.md delete mode 100644 v3.1/reference/transactions/transaction-pessimistic.md delete mode 100644 v3.1/releases/11alpha.md delete mode 100644 v3.1/releases/11beta.md delete mode 100644 v3.1/releases/2.0.10.md delete mode 100644 v3.1/releases/2.0.11.md delete mode 100644 v3.1/releases/2.0ga.md delete mode 100644 v3.1/releases/2.1.1.md delete mode 100644 v3.1/releases/2.1.10.md delete mode 100644 v3.1/releases/2.1.11.md delete mode 100644 v3.1/releases/2.1.12.md delete mode 100644 v3.1/releases/2.1.13.md delete mode 100644 v3.1/releases/2.1.14.md delete mode 100644 v3.1/releases/2.1.15.md delete mode 100644 v3.1/releases/2.1.16.md delete mode 100644 v3.1/releases/2.1.17.md delete mode 100644 v3.1/releases/2.1.18.md delete mode 100644 v3.1/releases/2.1.19.md delete mode 100644 v3.1/releases/2.1.2.md delete mode 100644 v3.1/releases/2.1.3.md delete mode 100644 v3.1/releases/2.1.4.md delete mode 100644 v3.1/releases/2.1.5.md delete mode 100644 v3.1/releases/2.1.6.md delete mode 100644 v3.1/releases/2.1.7.md delete mode 100644 v3.1/releases/2.1.8.md delete mode 100644 v3.1/releases/2.1.9.md delete mode 100644 v3.1/releases/2.1ga.md delete mode 100644 v3.1/releases/201.md delete mode 100644 v3.1/releases/202.md delete mode 100644 v3.1/releases/203.md delete mode 100644 v3.1/releases/204.md delete mode 100644 v3.1/releases/205.md delete mode 100644 v3.1/releases/206.md delete mode 100644 v3.1/releases/207.md delete mode 100644 v3.1/releases/208.md delete mode 100644 v3.1/releases/209.md delete mode 100644 v3.1/releases/21beta.md delete mode 100644 v3.1/releases/21rc1.md delete mode 100644 v3.1/releases/21rc2.md delete mode 100644 v3.1/releases/21rc3.md delete mode 100644 v3.1/releases/21rc4.md delete mode 100644 v3.1/releases/21rc5.md delete mode 100644 v3.1/releases/2rc1.md delete mode 100644 v3.1/releases/2rc3.md delete mode 100644 v3.1/releases/2rc4.md delete mode 100644 v3.1/releases/2rc5.md delete mode 100644 v3.1/releases/3.0-ga.md delete mode 100644 v3.1/releases/3.0.0-beta.1.md delete mode 100644 v3.1/releases/3.0.0-rc.1.md delete mode 100644 v3.1/releases/3.0.0-rc.2.md delete mode 100644 v3.1/releases/3.0.0-rc.3.md delete mode 100644 v3.1/releases/3.0.1.md delete mode 100644 v3.1/releases/3.0.10.md delete mode 100644 v3.1/releases/3.0.2.md delete mode 100644 v3.1/releases/3.0.3.md delete mode 100644 v3.1/releases/3.0.4.md delete mode 100644 v3.1/releases/3.0.5.md delete mode 100644 v3.1/releases/3.0.6.md delete mode 100644 v3.1/releases/3.0.7.md delete mode 100644 v3.1/releases/3.0.9.md delete mode 100644 v3.1/releases/3.0beta.md delete mode 100644 v3.1/releases/3.1.0-beta.1.md delete mode 100644 v3.1/releases/3.1.0-beta.md delete mode 100644 v3.1/releases/ga.md delete mode 100644 v3.1/releases/prega.md delete mode 100644 v3.1/releases/rc1.md delete mode 100644 v3.1/releases/rc2.md delete mode 100644 v3.1/releases/rc3.md delete mode 100644 v3.1/releases/rc4.md delete mode 100644 v3.1/releases/rn.md delete mode 100644 v3.1/report-issue.md delete mode 100644 v3.1/roadmap.md delete mode 100644 v3.1/support-resources.md delete mode 100644 v3.1/tidb-in-kubernetes/deploy/access-tidb.md delete mode 100644 v3.1/tidb-in-kubernetes/deploy/alibaba-cloud.md delete mode 100644 v3.1/tidb-in-kubernetes/deploy/aws-eks.md delete mode 100644 v3.1/tidb-in-kubernetes/deploy/gcp-gke.md delete mode 100644 v3.1/tidb-in-kubernetes/deploy/general-kubernetes.md delete mode 100644 v3.1/tidb-in-kubernetes/deploy/prerequisites.md delete mode 100644 v3.1/tidb-in-kubernetes/deploy/tidb-operator.md delete mode 100644 v3.1/tidb-in-kubernetes/faq.md delete mode 100644 v3.1/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-gke.md delete mode 100644 v3.1/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-kind.md delete mode 100644 v3.1/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-minikube.md delete mode 100644 v3.1/tidb-in-kubernetes/initialize-cluster.md delete mode 100644 v3.1/tidb-in-kubernetes/maintain/auto-failover.md delete mode 100644 v3.1/tidb-in-kubernetes/maintain/backup-and-restore.md delete mode 100644 v3.1/tidb-in-kubernetes/maintain/destroy-tidb-cluster.md delete mode 100644 v3.1/tidb-in-kubernetes/maintain/kubernetes-node.md delete mode 100644 v3.1/tidb-in-kubernetes/maintain/lightning.md delete mode 100644 v3.1/tidb-in-kubernetes/maintain/log-collecting.md delete mode 100644 v3.1/tidb-in-kubernetes/maintain/restart.md delete mode 100644 v3.1/tidb-in-kubernetes/maintain/tidb-binlog.md delete mode 100644 v3.1/tidb-in-kubernetes/monitor/tidb-in-kubernetes.md delete mode 100644 v3.1/tidb-in-kubernetes/reference/configuration/backup.md delete mode 100644 v3.1/tidb-in-kubernetes/reference/configuration/storage-class.md delete mode 100644 v3.1/tidb-in-kubernetes/reference/configuration/tidb-cluster.md delete mode 100644 v3.1/tidb-in-kubernetes/reference/configuration/tidb-drainer.md delete mode 100644 v3.1/tidb-in-kubernetes/reference/tools/in-kubernetes.md delete mode 100644 v3.1/tidb-in-kubernetes/reference/tools/tkctl.md delete mode 100644 v3.1/tidb-in-kubernetes/scale-in-kubernetes.md delete mode 100644 v3.1/tidb-in-kubernetes/tidb-operator-overview.md delete mode 100644 v3.1/tidb-in-kubernetes/troubleshoot.md delete mode 100644 v3.1/tidb-in-kubernetes/upgrade/tidb-cluster.md delete mode 100644 v3.1/tidb-in-kubernetes/upgrade/tidb-operator.md diff --git a/TOC.md b/TOC.md new file mode 100644 index 000000000000..669a82b28477 --- /dev/null +++ b/TOC.md @@ -0,0 +1,482 @@ +# TiDB 中文用户文档 + + + + +## 目录 + ++ 关于 TiDB + - [TiDB 简介](/overview.md) + + Benchmark 测试 + - [如何用 Sysbench 测试 TiDB](/benchmark/how-to-run-sysbench.md) + - [如何对 TiDB 进行 TPC-C 测试](/benchmark/how-to-run-tpcc.md) + - [Sysbench 性能对比 - v3.0 对比 v2.1](/benchmark/sysbench-v4.md) + - [TPC-C 性能对比 - v3.0 对比 v2.1](/benchmark/tpcc.md) + - [线上负载与 `Add Index` 相互影响测试](/benchmark/add-index-with-load.md) + - [TiDB in Kubernetes Sysbench 性能测试](/benchmark/sysbench-in-k8s.md) + - [DM 1.0-GA 性能测试](/benchmark/dm-v1.0-ga.md) ++ 主要概念 + - [整体架构](/architecture.md) + + 核心特性 + - [水平扩展](/key-features.md#水平扩展) + - [高可用](/key-features.md#高可用) ++ 操作指南 + + 快速上手 + + 创建集群 + - [使用 Docker Compose 部署 TiDB 集群](https://pingcap.com/docs-cn/dev/how-to/get-started/deploy-tidb-from-docker-compose/) + - [SQL 基本操作](/how-to/get-started/explore-sql.md) + - [读取历史数据](/how-to/get-started/read-historical-data.md) + - [TiDB Binlog 教程](/how-to/get-started/tidb-binlog.md) + - [TiDB Data Migration 教程](/how-to/get-started/data-migration.md) + - [TiDB Lightning 教程](/how-to/get-started/tidb-lightning.md) + - [TiSpark 教程](/how-to/get-started/tispark.md) + + 部署 + - [软硬件环境需求](/how-to/deploy/hardware-recommendations.md) + + 集群部署方式 + - [使用 Ansible 部署（推荐）](/how-to/deploy/orchestrated/ansible.md) + - [使用 Ansible 离线部署](/how-to/deploy/orchestrated/offline-ansible.md) + - [使用 Docker 部署](/how-to/deploy/orchestrated/docker.md) + + 跨地域冗余 + - [跨数据中心部署方案](/how-to/deploy/geographic-redundancy/overview.md) + - [配置集群拓扑](/how-to/deploy/geographic-redundancy/location-awareness.md) + - [使用 Ansible 部署 DM 集群](/how-to/deploy/data-migration-with-ansible.md) + + 配置 + - [时区](/how-to/configure/time-zone.md) + - [内存控制](/how-to/configure/memory-control.md) + + 安全 + + 安全传输层协议 (TLS) + - [为 MySQL 客户端开启 TLS](/how-to/secure/enable-tls-clients.md) + - [为 TiDB 组件间开启 TLS](/how-to/secure/enable-tls-between-components.md) + - [生成自签名证书](/how-to/secure/generate-self-signed-certificates.md) + + 监控 + - [概述](/how-to/monitor/overview.md) + - [监控 TiDB 集群](/how-to/monitor/monitor-a-cluster.md) + + 迁移 + - [迁移工具使用指南](/reference/tools/user-guide.md) + + 从 MySQL 迁移 + - [以 Amazon Aurora MySQL 为例](/how-to/migrate/from-mysql-aurora.md) + - [从 CSV 迁移](/reference/tools/tidb-lightning/csv.md) + + 运维 + - [Ansible 常见运维操作](/how-to/maintain/ansible-operations.md) + + [备份与恢复](/how-to/maintain/backup-and-restore.md) + + 定位异常查询 + - [定位慢查询](/how-to/maintain/identify-abnormal-queries/identify-slow-queries.md) + - [定位消耗系统资源多的查询](/how-to/maintain/identify-abnormal-queries/identify-aborted-queries.md) + + 扩容缩容 + - [使用 Ansible 扩容缩容](/how-to/scale/with-ansible.md) + + 升级 + - [升级至 TiDB 3.0](/how-to/upgrade/from-previous-version.md) + + 故障诊断 + - [集群配置诊断](/how-to/troubleshoot/cluster-setup.md) + - [TiDB Lightning 故障诊断](/how-to/troubleshoot/tidb-lightning.md) ++ 参考手册 + + SQL + - [与 MySQL 兼容性对比](/reference/mysql-compatibility.md) + + SQL 语言结构 + - [字面值](/reference/sql/language-structure/literal-values.md) + - [Schema 对象名](/reference/sql/language-structure/schema-object-names.md) + - [关键字和保留字](/reference/sql/language-structure/keywords-and-reserved-words.md) + - [用户自定义变量](/reference/sql/language-structure/user-defined-variables.md) + - [表达式语法](/reference/sql/language-structure/expression-syntax.md) + - [注释语法](/reference/sql/language-structure/comment-syntax.md) + + 数据类型 + - [概述](/reference/sql/data-types/overview.md) + - [默认值](/reference/sql/data-types/default-values.md) + + 数值类型 + - [`BIT`](/reference/sql/data-types/numeric.md#bit-类型) + - [`BOOL|BOOLEAN`](/reference/sql/data-types/numeric.md#boolean-类型) + - [`TINYINT`](/reference/sql/data-types/numeric.md#tinyint-类型) + - [`SMALLINT`](/reference/sql/data-types/numeric.md#smallint-类型) + - [`MEDIUMINT`](/reference/sql/data-types/numeric.md#mediumint-类型) + - [`INT|INTEGER`](/reference/sql/data-types/numeric.md#integer-类型) + - [`BIGINT`](/reference/sql/data-types/numeric.md#bigint-类型) + - [`DECIMAL`](/reference/sql/data-types/numeric.md#decimal-类型) + - [`FLOAT`](/reference/sql/data-types/numeric.md#float-类型) + - [`DOUBLE`](/reference/sql/data-types/numeric.md#double-类型) + + 日期和时间类型 + - [`DATE`](/reference/sql/data-types/date-and-time.md#date-类型) + - [`DATETIME`](/reference/sql/data-types/date-and-time.md#datetime-类型) + - [`TIMESTAMP`](/reference/sql/data-types/date-and-time.md#timestamp-类型) + - [`TIME`](/reference/sql/data-types/date-and-time.md#time-类型) + - [`YEAR`](/reference/sql/data-types/date-and-time.md#year-类型) + + 字符串类型 + - [`CHAR`](/reference/sql/data-types/string.md#char-类型) + - [`VARCHAR`](/reference/sql/data-types/string.md#varchar-类型) + - [`TEXT`](/reference/sql/data-types/string.md#text-类型) + - [`LONGTEXT`](/reference/sql/data-types/string.md#longtext-类型) + - [`BINARY`](/reference/sql/data-types/string.md#binary-类型) + - [`VARBINARY`](/reference/sql/data-types/string.md#varbinary-类型) + - [`TINYBLOB`](/reference/sql/data-types/string.md#tinyblob-类型) + - [`BLOB`](/reference/sql/data-types/string.md#blob-类型) + - [`MEDIUMBLOB`](/reference/sql/data-types/string.md#mediumblob-类型) + - [`LONGBLOB`](/reference/sql/data-types/string.md#longblob-类型) + - [`ENUM`](/reference/sql/data-types/string.md#enum-类型) + - [`SET`](/reference/sql/data-types/string.md#set-类型) + - [JSON Type](/reference/sql/data-types/json.md) + + 函数与操作符 + - [函数与操作符概述](/reference/sql/functions-and-operators/reference.md) + - [表达式求值的类型转换](/reference/sql/functions-and-operators/type-conversion.md) + - [操作符](/reference/sql/functions-and-operators/operators.md) + - [控制流程函数](/reference/sql/functions-and-operators/control-flow-functions.md) + - [字符串函数](/reference/sql/functions-and-operators/string-functions.md) + - [数值函数与操作符](/reference/sql/functions-and-operators/numeric-functions-and-operators.md) + - [日期和时间函数](/reference/sql/functions-and-operators/date-and-time-functions.md) + - [位函数和操作符](/reference/sql/functions-and-operators/bit-functions-and-operators.md) + - [Cast 函数和操作符](/reference/sql/functions-and-operators/cast-functions-and-operators.md) + - [加密和压缩函数](/reference/sql/functions-and-operators/encryption-and-compression-functions.md) + - [信息函数](/reference/sql/functions-and-operators/information-functions.md) + - [JSON 函数](/reference/sql/functions-and-operators/json-functions.md) + - [GROUP BY 聚合函数](/reference/sql/functions-and-operators/aggregate-group-by-functions.md) + - [窗口函数](/reference/sql/functions-and-operators/window-functions.md) + - [其它函数](/reference/sql/functions-and-operators/miscellaneous-functions.md) + - [精度数学](/reference/sql/functions-and-operators/precision-math.md) + - [下推到 TiKV 的表达式列表](/reference/sql/functions-and-operators/expressions-pushed-down.md) + + SQL 语句 + - [`ADD COLUMN`](/reference/sql/statements/add-column.md) + - [`ADD INDEX`](/reference/sql/statements/add-index.md) + - [`ADMIN`](/reference/sql/statements/admin.md) + - [`ALTER DATABASE`](/reference/sql/statements/alter-database.md) + - [`ALTER TABLE`](/reference/sql/statements/alter-table.md) + - [`ALTER USER`](/reference/sql/statements/alter-user.md) + - [`ANALYZE TABLE`](/reference/sql/statements/analyze-table.md) + - [`BEGIN`](/reference/sql/statements/begin.md) + - [`COMMIT`](/reference/sql/statements/commit.md) + - [`CREATE DATABASE`](/reference/sql/statements/create-database.md) + - [`CREATE INDEX`](/reference/sql/statements/create-index.md) + - [`CREATE TABLE LIKE`](/reference/sql/statements/create-table-like.md) + - [`CREATE TABLE`](/reference/sql/statements/create-table.md) + - [`CREATE USER`](/reference/sql/statements/create-user.md) + - [`CREATE VIEW`](/reference/sql/statements/create-view.md) + - [`DEALLOCATE`](/reference/sql/statements/deallocate.md) + - [`DELETE`](/reference/sql/statements/delete.md) + - [`DESC`](/reference/sql/statements/desc.md) + - [`DESCRIBE`](/reference/sql/statements/describe.md) + - [`DO`](/reference/sql/statements/do.md) + - [`DROP COLUMN`](/reference/sql/statements/drop-column.md) + - [`DROP DATABASE`](/reference/sql/statements/drop-database.md) + - [`DROP INDEX`](/reference/sql/statements/drop-index.md) + - [`DROP TABLE`](/reference/sql/statements/drop-table.md) + - [`DROP USER`](/reference/sql/statements/drop-user.md) + - [`DROP VIEW`](/reference/sql/statements/drop-view.md) + - [`EXECUTE`](/reference/sql/statements/execute.md) + - [`EXPLAIN ANALYZE`](/reference/sql/statements/explain-analyze.md) + - [`EXPLAIN`](/reference/sql/statements/explain.md) + - [`FLUSH PRIVILEGES`](/reference/sql/statements/flush-privileges.md) + - [`FLUSH STATUS`](/reference/sql/statements/flush-status.md) + - [`FLUSH TABLES`](/reference/sql/statements/flush-tables.md) + - [`GRANT `](/reference/sql/statements/grant-privileges.md) + - [`INSERT`](/reference/sql/statements/insert.md) + - [`KILL [TIDB]`](/reference/sql/statements/kill.md) + - [`LOAD DATA`](/reference/sql/statements/load-data.md) + - [`MODIFY COLUMN`](/reference/sql/statements/modify-column.md) + - [`PREPARE`](/reference/sql/statements/prepare.md) + - [`RECOVER TABLE`](/reference/sql/statements/recover-table.md) + - [`RENAME INDEX`](/reference/sql/statements/rename-index.md) + - [`RENAME TABLE`](/reference/sql/statements/rename-table.md) + - [`REPLACE`](/reference/sql/statements/replace.md) + - [`REVOKE `](/reference/sql/statements/revoke-privileges.md) + - [`ROLLBACK`](/reference/sql/statements/rollback.md) + - [`SELECT`](/reference/sql/statements/select.md) + - [`SET [NAMES|CHARACTER SET]`](/reference/sql/statements/set-names.md) + - [`SET PASSWORD`](/reference/sql/statements/set-password.md) + - [`SET TRANSACTION`](/reference/sql/statements/set-transaction.md) + - [`SET [GLOBAL|SESSION] `](/reference/sql/statements/set-variable.md) + - [`SHOW CHARACTER SET`](/reference/sql/statements/show-character-set.md) + - [`SHOW COLLATION`](/reference/sql/statements/show-collation.md) + - [`SHOW [FULL] COLUMNS FROM`](/reference/sql/statements/show-columns-from.md) + - [`SHOW CREATE TABLE`](/reference/sql/statements/show-create-table.md) + - [`SHOW CREATE USER`](/reference/sql/statements/show-create-user.md) + - [`SHOW DATABASES`](/reference/sql/statements/show-databases.md) + - [`SHOW ENGINES`](/reference/sql/statements/show-engines.md) + - [`SHOW ERRORS`](/reference/sql/statements/show-errors.md) + - [`SHOW [FULL] FIELDS FROM`](/reference/sql/statements/show-fields-from.md) + - [`SHOW GRANTS`](/reference/sql/statements/show-grants.md) + - [`SHOW INDEXES [FROM|IN]`](/reference/sql/statements/show-indexes.md) + - [`SHOW INDEX [FROM|IN]`](/reference/sql/statements/show-index.md) + - [`SHOW KEYS [FROM|IN]`](/reference/sql/statements/show-keys.md) + - [`SHOW PRIVILEGES`](/reference/sql/statements/show-privileges.md) + - [`SHOW [FULL] PROCESSSLIST`](/reference/sql/statements/show-processlist.md) + - [`SHOW SCHEMAS`](/reference/sql/statements/show-schemas.md) + - [`SHOW [FULL] TABLES`](/reference/sql/statements/show-tables.md) + - [`SHOW TABLE REGIONS`](/reference/sql/statements/show-table-regions.md) + - [`SHOW TABLE STATUS`](/reference/sql/statements/show-table-status.md) + - [`SHOW [GLOBAL|SESSION] VARIABLES`](/reference/sql/statements/show-variables.md) + - [`SHOW WARNINGS`](/reference/sql/statements/show-warnings.md) + - [`SPLIT REGION`](/reference/sql/statements/split-region.md) + - [`START TRANSACTION`](/reference/sql/statements/start-transaction.md) + - [`TRACE`](/reference/sql/statements/trace.md) + - [`TRUNCATE`](/reference/sql/statements/truncate.md) + - [`UPDATE`](/reference/sql/statements/update.md) + - [`USE`](/reference/sql/statements/use.md) + - [约束](/reference/sql/constraints.md) + - [生成列](/reference/sql/generated-columns.md) + - [分区表](/reference/sql/partitioning.md) + - [字符集](/reference/sql/character-set.md) + - [SQL 模式](/reference/sql/sql-mode.md) + - [视图](/reference/sql/view.md) + + 配置 + + tidb-server + - [MySQL 系统变量](/reference/configuration/tidb-server/mysql-variables.md) + - [TiDB 特定系统变量](/reference/configuration/tidb-server/tidb-specific-variables.md) + - [配置参数](/reference/configuration/tidb-server/configuration.md) + - [配置文件描述](/reference/configuration/tidb-server/configuration-file.md) + + pd-server + - [配置参数](/reference/configuration/pd-server/configuration.md) + - [配置文件描述](/reference/configuration/pd-server/configuration-file.md) + + tikv-server + - [配置参数](/reference/configuration/tikv-server/configuration.md) + - [配置文件描述](/reference/configuration/tikv-server/configuration-file.md) + + 安全 + - [与 MySQL 的安全特性差异](/reference/security/compatibility.md) + - [TiDB 数据库权限管理](/reference/security/privilege-system.md) + - [TiDB 用户账户管理](/reference/security/user-account-management.md) + - [基于角色的访问控制](/reference/security/role-based-access-control.md) + - [TiDB 证书鉴权使用指南](/reference/security/cert-based-authentication.md) + + 事务 + - [事务概览](/reference/transactions/overview.md) + - [隔离级别](/reference/transactions/transaction-isolation.md) + - [乐观事务](/reference/transactions/transaction-optimistic.md) + - [悲观事务](/reference/transactions/transaction-pessimistic.md) + + 系统数据库 + - [`mysql`](/reference/system-databases/mysql.md) + - [`information_schema`](/reference/system-databases/information-schema.md) + - [错误码](/reference/error-codes.md) + - [支持的连接器和 API](/reference/supported-clients.md) + + 垃圾回收 (GC) + - [GC 机制简介](/reference/garbage-collection/overview.md) + - [GC 配置](/reference/garbage-collection/configuration.md) + + 性能调优 + - [SQL 优化流程](/reference/performance/sql-optimizer-overview.md) + - [理解 TiDB 执行计划](/reference/performance/understanding-the-query-execution-plan.md) + - [执行计划绑定](/reference/performance/execution-plan-bind.md) + - [统计信息概述](/reference/performance/statistics.md) + - [Optimizer Hints](/reference/performance/optimizer-hints.md) + - [使用 SQL 语句检查 TiDB 集群状态](/reference/performance/check-cluster-status-using-sql-statements.md) + - [Statement Summary Table](/reference/performance/statement-summary.md) + - [TiKV 调优](/reference/performance/tune-tikv.md) + - [TiDB 最佳实践](https://pingcap.com/blog-cn/tidb-best-practice/) + + 监控指标 + - [Overview 面板](/reference/key-monitoring-metrics/overview-dashboard.md) + - [TiDB 面板](/reference/key-monitoring-metrics/tidb-dashboard.md) + - [PD 面板](/reference/key-monitoring-metrics/pd-dashboard.md) + - [TiKV 面板](/reference/key-monitoring-metrics/tikv-dashboard.md) + - [报警规则](/reference/alert-rules.md) + + 最佳实践 + - [HAProxy 最佳实践](/reference/best-practices/haproxy.md) + - [Java 应用开发最佳实践](/reference/best-practices/java-app.md) + - [高并发写入场景最佳实践](/reference/best-practices/high-concurrency.md) + - [Grafana 监控最佳实践](/reference/best-practices/grafana-monitor.md) + - [PD 调度策略最佳实践](/reference/best-practices/pd-scheduling.md) + - [海量 Region 集群调优最佳实践](/reference/best-practices/massive-regions.md) + + [TiSpark 使用指南](/reference/tispark.md) + + TiDB Binlog + - [概述](/reference/tidb-binlog/overview.md) + - [部署使用](/reference/tidb-binlog/deploy.md) + - [运维管理](/reference/tidb-binlog/maintain.md) + - [版本升级](/reference/tidb-binlog/upgrade.md) + - [监控告警](/reference/tidb-binlog/monitor.md) + - [增量恢复](/reference/tidb-binlog/reparo.md) + - [Kafka 自定义开发](/reference/tidb-binlog/binlog-slave-client.md) + - [TiDB Binlog Relay Log](/reference/tidb-binlog/relay-log.md) + - [术语表](/reference/tidb-binlog/glossary.md) + + 故障诊断 + - [故障诊断](/reference/tidb-binlog/troubleshoot/binlog.md) + - [常见错误修复](/reference/tidb-binlog/troubleshoot/error-handling.md) + - [FAQ](/reference/tidb-binlog/faq.md) + + 周边工具 + - [工具使用指南](/reference/tools/user-guide.md) + - [Mydumper](/reference/tools/mydumper.md) + - [Loader](/reference/tools/loader.md) + - [Syncer](/reference/tools/syncer.md) + + Data Migration + + 概述 + - [DM 架构](/reference/tools/data-migration/overview.md#dm-架构) + - [同步功能介绍](/reference/tools/data-migration/overview.md#同步功能介绍) + - [使用限制](/reference/tools/data-migration/overview.md#使用限制) + - [DM-worker 简介](/reference/tools/data-migration/dm-worker-intro.md) + - [DM Relay Log](/reference/tools/data-migration/relay-log.md) + + 核心特性 + - [Table Routing](/reference/tools/data-migration/features/overview.md#table-routing) + - [Black & White Lists](/reference/tools/data-migration/features/overview.md#black--white-table-lists) + - [Binlog Event Filter](/reference/tools/data-migration/features/overview.md#binlog-event-filter) + - [同步延迟监控](/reference/tools/data-migration/features/overview.md#同步延迟监控) + + Shard Support + - [简介](/reference/tools/data-migration/features/shard-merge.md) + - [使用限制](/reference/tools/data-migration/features/shard-merge.md#使用限制) + - [手动处理 Sharding DDL Lock](/reference/tools/data-migration/features/manually-handling-sharding-ddl-locks.md) + + 使用场景 + - [简单的从库同步场景](/reference/tools/data-migration/usage-scenarios/simple-synchronization.md) + - [分库分表合并场景](/reference/tools/data-migration/usage-scenarios/shard-merge.md) + - [分表合并数据迁移最佳实践](/reference/tools/data-migration/usage-scenarios/best-practice-dm-shard.md) + - [DM-worker 在上游 MySQL 主从间切换](/reference/tools/data-migration/usage-scenarios/master-slave-switch.md) + + [部署使用](/reference/tools/data-migration/deploy.md) + + 配置 + - [概述](/reference/tools/data-migration/configure/overview.md) + - [DM-master 配置](/reference/tools/data-migration/configure/dm-master-configuration-file.md) + - [DM-worker 配置](/reference/tools/data-migration/configure/dm-worker-configuration-file.md) + - [任务配置](/reference/tools/data-migration/configure/task-configuration-file.md) + + DM 集群管理 + - [集群操作](/reference/tools/data-migration/cluster-operations.md) + - [集群升级](/reference/tools/data-migration/dm-upgrade.md) + + DM 同步任务管理 + - [管理数据同步任务](/reference/tools/data-migration/manage-tasks.md) + - [任务前置检查](/reference/tools/data-migration/precheck.md) + - [任务状态查询](/reference/tools/data-migration/query-status.md) + - [跳过或替代执行异常的 SQL 语句](/reference/tools/data-migration/skip-replace-sqls.md) + - [监控 DM 集群](/reference/tools/data-migration/monitor.md) + + 从与 MySQL 兼容的数据库迁移数据 + - [从 MySQL/Amazon Aurora MySQL 迁移数据](/how-to/migrate/from-mysql-aurora.md) + - [DM Portal](/reference/tools/data-migration/dm-portal.md) + + DM 故障诊断 + - [故障诊断](/reference/tools/data-migration/troubleshoot/dm.md) + - [错误含义](/reference/tools/data-migration/troubleshoot/error-system.md) + - [常见错误修复](/reference/tools/data-migration/troubleshoot/error-handling.md) + - [DM FAQ](/reference/tools/data-migration/faq.md) + + 版本发布历史 + + v1.0 + - [1.0.2](/reference/tools/data-migration/releases/1.0.2.md) + - [1.0.3](/reference/tools/data-migration/releases/1.0.3.md) + - [TiDB DM 术语表](/reference/tools/data-migration/glossary.md) + + TiDB Lightning + - [概述](/reference/tools/tidb-lightning/overview.md) + - [部署执行](/reference/tools/tidb-lightning/deployment.md) + - [参数说明](/reference/tools/tidb-lightning/config.md) + - [断点续传](/reference/tools/tidb-lightning/checkpoints.md) + - [表库过滤](/reference/tools/tidb-lightning/table-filter.md) + - [CSV 支持](/reference/tools/tidb-lightning/csv.md) + - [TiDB-backend](/reference/tools/tidb-lightning/tidb-backend.md) + - [Web 界面](/reference/tools/tidb-lightning/web.md) + - [监控告警](/reference/tools/tidb-lightning/monitor.md) + - [故障诊断](/how-to/troubleshoot/tidb-lightning.md) + - [FAQ](/faq/tidb-lightning.md) + - [术语表](/reference/tools/tidb-lightning/glossary.md) + - [sync-diff-inspector](/reference/tools/sync-diff-inspector/overview.md) + - [PD Control](/reference/tools/pd-control.md) + - [PD Recover](/reference/tools/pd-recover.md) + - [TiKV Control](/reference/tools/tikv-control.md) + - [TiDB Controller](/reference/tools/tidb-control.md) + - [工具下载](/reference/tools/download.md) ++ TiDB in Kubernetes + - [TiDB Operator 简介](/tidb-in-kubernetes/tidb-operator-overview.md) + + 快速上手 + - [kind](/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-kind.md) + - [GKE](/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-gke.md) + - [Minikube](/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-minikube.md) + + 部署 + - [集群环境要求](/tidb-in-kubernetes/deploy/prerequisites.md) + - [部署 TiDB Operator](/tidb-in-kubernetes/deploy/tidb-operator.md) + - [标准 Kubernetes 上的 TiDB 集群](/tidb-in-kubernetes/deploy/general-kubernetes.md) + - [AWS EKS 上的 TiDB 集群](/tidb-in-kubernetes/deploy/aws-eks.md) + - [GCP 上的 TiDB 集群](/tidb-in-kubernetes/deploy/gcp-gke.md) + - [阿里云上的 TiDB 集群](/tidb-in-kubernetes/deploy/alibaba-cloud.md) + - [访问 Kubernetes 上的 TiDB 集群](/tidb-in-kubernetes/deploy/access-tidb.md) + + 配置 + - [初始化集群](/tidb-in-kubernetes/initialize-cluster.md) + - [监控](/tidb-in-kubernetes/monitor/tidb-in-kubernetes.md) + + 运维 + - [销毁 TiDB 集群](/tidb-in-kubernetes/maintain/destroy-tidb-cluster.md) + - [维护 TiDB 集群所在节点](/tidb-in-kubernetes/maintain/kubernetes-node.md) + - [备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore.md) + - [恢复 Kubernetes 上的 TiDB 集群数据](/tidb-in-kubernetes/maintain/lightning.md) + - [收集日志](/tidb-in-kubernetes/maintain/log-collecting.md) + - [集群故障自动转移](/tidb-in-kubernetes/maintain/auto-failover.md) + - [TiDB Binlog](/tidb-in-kubernetes/maintain/tidb-binlog.md) + - [重启 TiDB 集群](/tidb-in-kubernetes/maintain/restart.md) + - [扩缩容](/tidb-in-kubernetes/scale-in-kubernetes.md) + + 升级 + - [TiDB 集群](/tidb-in-kubernetes/upgrade/tidb-cluster.md) + - [TiDB Operator](/tidb-in-kubernetes/upgrade/tidb-operator.md) + + 参考信息 + + 配置 + - [集群配置](/tidb-in-kubernetes/reference/configuration/tidb-cluster.md) + - [备份配置](/tidb-in-kubernetes/reference/configuration/backup.md) + - [PV 配置](/tidb-in-kubernetes/reference/configuration/storage-class.md) + - [TiDB Drainer](/tidb-in-kubernetes/reference/configuration/tidb-drainer.md) + + 工具 + - [tkctl](/tidb-in-kubernetes/reference/tools/tkctl.md) + - [相关工具使用](/tidb-in-kubernetes/reference/tools/in-kubernetes.md) + - [故障诊断](/tidb-in-kubernetes/troubleshoot.md) + - [常见问题](/tidb-in-kubernetes/faq.md) ++ 常见问题 (FAQ) + - [TiDB FAQ](/faq/tidb.md) + - [TiDB Lightning FAQ](/faq/tidb-lightning.md) + - [升级 FAQ](/faq/upgrade.md) ++ 技术支持 + - [支持渠道](/support-resources.md) + - [反馈问题](/report-issue.md) ++ [贡献](/contribute.md) + - [贡献代码](/contribute.md#成为-tidb-的贡献者) + - [改进文档](/contribute.md#改进文档) ++ [TiDB 路线图](/roadmap.md) ++ [版本发布历史](/releases/rn.md) + + v3.0 + - [3.0.10](/releases/3.0.10.md) + - [3.0.9](/releases/3.0.9.md) + - [3.0.8](/releases/3.0.8.md) + - [3.0.7](/releases/3.0.7.md) + - [3.0.6](/releases/3.0.6.md) + - [3.0.5](/releases/3.0.5.md) + - [3.0.4](/releases/3.0.4.md) + - [3.0.3](/releases/3.0.3.md) + - [3.0.2](/releases/3.0.2.md) + - [3.0.1](/releases/3.0.1.md) + - [3.0 GA](/releases/3.0-ga.md) + - [3.0.0-rc.3](/releases/3.0.0-rc.3.md) + - [3.0.0-rc.2](/releases/3.0.0-rc.2.md) + - [3.0.0-rc.1](/releases/3.0.0-rc.1.md) + - [3.0.0-beta.1](/releases/3.0.0-beta.1.md) + - [3.0.0-beta](/releases/3.0beta.md) + + v2.1 + - [2.1.19](/releases/2.1.19.md) + - [2.1.18](/releases/2.1.18.md) + - [2.1.17](/releases/2.1.17.md) + - [2.1.16](/releases/2.1.16.md) + - [2.1.15](/releases/2.1.15.md) + - [2.1.14](/releases/2.1.14.md) + - [2.1.13](/releases/2.1.13.md) + - [2.1.12](/releases/2.1.12.md) + - [2.1.11](/releases/2.1.11.md) + - [2.1.10](/releases/2.1.10.md) + - [2.1.9](/releases/2.1.9.md) + - [2.1.8](/releases/2.1.8.md) + - [2.1.7](/releases/2.1.7.md) + - [2.1.6](/releases/2.1.6.md) + - [2.1.5](/releases/2.1.5.md) + - [2.1.4](/releases/2.1.4.md) + - [2.1.3](/releases/2.1.3.md) + - [2.1.2](/releases/2.1.2.md) + - [2.1.1](/releases/2.1.1.md) + - [2.1 GA](/releases/2.1ga.md) + - [2.1 RC5](/releases/21rc5.md) + - [2.1 RC4](/releases/21rc4.md) + - [2.1 RC3](/releases/21rc3.md) + - [2.1 RC2](/releases/21rc2.md) + - [2.1 RC1](/releases/21rc1.md) + - [2.1 Beta](/releases/21beta.md) + + v2.0 + - [2.0.11](/releases/2.0.11.md) + - [2.0.10](/releases/2.0.10.md) + - [2.0.9](/releases/209.md) + - [2.0.8](/releases/208.md) + - [2.0.7](/releases/207.md) + - [2.0.6](/releases/206.md) + - [2.0.5](/releases/205.md) + - [2.0.4](/releases/204.md) + - [2.0.3](/releases/203.md) + - [2.0.2](/releases/202.md) + - [2.0.1](/releases/201.md) + - [2.0](/releases/2.0ga.md) + - [2.0 RC5](/releases/2rc5.md) + - [2.0 RC4](/releases/2rc4.md) + - [2.0 RC3](/releases/2rc3.md) + - [2.0 RC1](/releases/2rc1.md) + - [1.1 Beta](/releases/11beta.md) + - [1.1 Alpha](/releases/11alpha.md) + + v1.0 + - [1.0](/releases/ga.md) + - [Pre-GA](/releases/prega.md) + - [RC4](/releases/rc4.md) + - [RC3](/releases/rc3.md) + - [RC2](/releases/rc2.md) + - [RC1](/releases/rc1.md) ++ [术语表](/glossary.md) diff --git a/_index.md b/_index.md index a118993c7f76..6711da8b498b 100755 --- a/_index.md +++ b/_index.md @@ -11,7 +11,7 @@ TiDB 具备如下特性： - 高度兼容 MySQL - [大多数情况下](/v3.0/reference/mysql-compatibility.md)，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。 + [大多数情况下](/reference/mysql-compatibility.md)，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。 - 水平弹性扩展 @@ -33,7 +33,7 @@ TiDB 具备如下特性： TiDB 是为云而设计的数据库，支持公有云、私有云和混合云，使部署、配置和维护变得十分简单。 -TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 [TiSpark 项目](/v3.0/reference/tispark.md)来完成。 +TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 [TiSpark 项目](/reference/tispark.md)来完成。 TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力。 @@ -47,10 +47,10 @@ TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间 TiDB 可以部署在本地和云平台上，支持公有云、私有云和混合云。你可以根据实际场景或需求，选择相应的方式来部署 TiDB 集群： -- [使用 Ansible 部署](/v3.0/how-to/deploy/orchestrated/ansible.md)：如果用于生产环境，须使用 Ansible 部署 TiDB 集群。 -- [使用 Ansible 离线部署](/v3.0/how-to/deploy/orchestrated/offline-ansible.md)：如果部署环境无法访问网络，可使用 Ansible 进行离线部署。 -- [使用 Docker Compose 部署](/v3.0/how-to/get-started/deploy-tidb-from-docker-compose.md)：如果你只是想测试 TiDB、体验 TiDB 的特性，或者用于开发环境，可以使用 Docker Compose 在本地快速部署 TiDB 集群。该部署方式不适用于生产环境。 -- [使用 Docker 部署](/v3.0/how-to/deploy/orchestrated/docker.md)：你可以使用 Docker 部署 TiDB 集群，但该部署方式不适用于生产环境。 +- [使用 Ansible 部署](/how-to/deploy/orchestrated/ansible.md)：如果用于生产环境，须使用 Ansible 部署 TiDB 集群。 +- [使用 Ansible 离线部署](/how-to/deploy/orchestrated/offline-ansible.md)：如果部署环境无法访问网络，可使用 Ansible 进行离线部署。 +- [使用 Docker Compose 部署](/how-to/get-started/deploy-tidb-from-docker-compose.md)：如果你只是想测试 TiDB、体验 TiDB 的特性，或者用于开发环境，可以使用 Docker Compose 在本地快速部署 TiDB 集群。该部署方式不适用于生产环境。 +- [使用 Docker 部署](/how-to/deploy/orchestrated/docker.md)：你可以使用 Docker 部署 TiDB 集群，但该部署方式不适用于生产环境。 ## 项目源码 diff --git a/dev/architecture.md b/architecture.md similarity index 97% rename from dev/architecture.md rename to architecture.md index ca3ff2c925b8..7dcbe72f59fe 100644 --- a/dev/architecture.md +++ b/architecture.md @@ -5,7 +5,7 @@ category: introduction # TiDB 整体架构 -要深入了解 TiDB 的水平扩展和高可用特点，首先需要了解 TiDB 的整体架构。TiDB 集群主要包括三个核心组件：TiDB Server，PD Server 和 TiKV Server。此外，还有用于解决用户复杂 OLAP 需求的 [TiSpark](https://github.com/pingcap/tispark/) 组件和简化云上部署管理的 [TiDB Operator](/dev/tidb-in-kubernetes/tidb-operator-overview.md) 组件。 +要深入了解 TiDB 的水平扩展和高可用特点，首先需要了解 TiDB 的整体架构。TiDB 集群主要包括三个核心组件：TiDB Server，PD Server 和 TiKV Server。此外，还有用于解决用户复杂 OLAP 需求的 [TiSpark](https://github.com/pingcap/tispark/) 组件和简化云上部署管理的 [TiDB Operator](/tidb-in-kubernetes/tidb-operator-overview.md) 组件。 ![TiDB Architecture](/media/tidb-architecture.png) diff --git a/dev/benchmark/add-index-with-load.md b/benchmark/add-index-with-load.md similarity index 100% rename from dev/benchmark/add-index-with-load.md rename to benchmark/add-index-with-load.md diff --git a/dev/benchmark/dm-v1.0-ga.md b/benchmark/dm-v1.0-ga.md similarity index 100% rename from dev/benchmark/dm-v1.0-ga.md rename to benchmark/dm-v1.0-ga.md diff --git a/v3.0/benchmark/how-to-run-sysbench.md b/benchmark/how-to-run-sysbench.md similarity index 95% rename from v3.0/benchmark/how-to-run-sysbench.md rename to benchmark/how-to-run-sysbench.md index 14f83278533b..670f3a8bc11a 100644 --- a/v3.0/benchmark/how-to-run-sysbench.md +++ b/benchmark/how-to-run-sysbench.md @@ -10,9 +10,9 @@ aliases: ['/docs-cn/benchmark/how-to-run-sysbench'] ## 测试环境 -- [硬件要求](/v3.0/how-to/deploy/hardware-recommendations.md) +- [硬件要求](/how-to/deploy/hardware-recommendations.md) -- 参考 [TiDB 部署文档](/v3.0/how-to/deploy/orchestrated/ansible.md)部署 TiDB 集群。在 3 台服务器的条件下，建议每台机器部署 1 个 TiDB，1 个 PD，和 1 个 TiKV 实例。关于磁盘，以 32 张表、每张表 10M 行数据为例，建议 TiKV 的数据目录所在的磁盘空间大于 512 GB。 +- 参考 [TiDB 部署文档](/how-to/deploy/orchestrated/ansible.md)部署 TiDB 集群。在 3 台服务器的条件下，建议每台机器部署 1 个 TiDB，1 个 PD，和 1 个 TiKV 实例。关于磁盘，以 32 张表、每张表 10M 行数据为例，建议 TiKV 的数据目录所在的磁盘空间大于 512 GB。 对于单个 TiDB 的并发连接数，建议控制在 500 以内，如需增加整个系统的并发压力，可以增加 TiDB 实例，具体增加的 TiDB 个数视测试压力而定。 IDC 机器： @@ -87,7 +87,7 @@ sync-log = false capacity = "30GB" ``` -更详细的 TiKV 参数调优请参考 [TiKV 性能参数调优](/v3.0/reference/performance/tune-tikv.md)。 +更详细的 TiKV 参数调优请参考 [TiKV 性能参数调优](/reference/performance/tune-tikv.md)。 ## 测试过程 diff --git a/dev/benchmark/how-to-run-tpcc.md b/benchmark/how-to-run-tpcc.md similarity index 95% rename from dev/benchmark/how-to-run-tpcc.md rename to benchmark/how-to-run-tpcc.md index 23389e04b005..449e37363beb 100644 --- a/dev/benchmark/how-to-run-tpcc.md +++ b/benchmark/how-to-run-tpcc.md @@ -106,7 +106,7 @@ enabled = true ### TiKV 配置 -开始可以使用基本的配置，压测运行后可以通过观察 Grafana 并参考 [TiKV 调优说明](/dev/reference/performance/tune-tikv.md)进行调整。 +开始可以使用基本的配置，压测运行后可以通过观察 Grafana 并参考 [TiKV 调优说明](/reference/performance/tune-tikv.md)进行调整。 ### BenchmarkSQL 配置 @@ -183,11 +183,11 @@ fileLocation=/home/user/csv/tpcc. # 存储 csv 文件的目录绝对路径 + #### 通过 Lightning 导入 -通过 Lightning 导入数据请参考 [Lightning 部署执行](/dev/reference/tools/tidb-lightning/deployment.md)章节。这里我们介绍下通过 tidb-ansible 部署 Lightning 导入数据的方法。 +通过 Lightning 导入数据请参考 [Lightning 部署执行](/reference/tools/tidb-lightning/deployment.md)章节。这里我们介绍下通过 tidb-ansible 部署 Lightning 导入数据的方法。 ##### 修改 inventory.ini -这里最好手动指定清楚部署的 IP、端口、目录，避免各种冲突问题带来的异常，其中 import_dir 的磁盘空间参考 [Lightning 部署执行](/dev/reference/tools/tidb-lightning/deployment.md)，data_source_dir 就是存储上一节 csv 数据的目录。 +这里最好手动指定清楚部署的 IP、端口、目录，避免各种冲突问题带来的异常，其中 import_dir 的磁盘空间参考 [Lightning 部署执行](/reference/tools/tidb-lightning/deployment.md)，data_source_dir 就是存储上一节 csv 数据的目录。 ```ini [importer_server] diff --git a/dev/benchmark/sysbench-in-k8s.md b/benchmark/sysbench-in-k8s.md similarity index 100% rename from dev/benchmark/sysbench-in-k8s.md rename to benchmark/sysbench-in-k8s.md diff --git a/v3.0/benchmark/sysbench-v2.md b/benchmark/sysbench-v2.md similarity index 100% rename from v3.0/benchmark/sysbench-v2.md rename to benchmark/sysbench-v2.md diff --git a/v3.0/benchmark/sysbench-v3.md b/benchmark/sysbench-v3.md similarity index 100% rename from v3.0/benchmark/sysbench-v3.md rename to benchmark/sysbench-v3.md diff --git a/v3.0/benchmark/sysbench-v4.md b/benchmark/sysbench-v4.md similarity index 100% rename from v3.0/benchmark/sysbench-v4.md rename to benchmark/sysbench-v4.md diff --git a/v3.0/benchmark/sysbench.md b/benchmark/sysbench.md similarity index 100% rename from v3.0/benchmark/sysbench.md rename to benchmark/sysbench.md diff --git a/dev/benchmark/tpcc.md b/benchmark/tpcc.md similarity index 100% rename from dev/benchmark/tpcc.md rename to benchmark/tpcc.md diff --git a/v3.0/benchmark/tpch-v2.md b/benchmark/tpch-v2.md similarity index 100% rename from v3.0/benchmark/tpch-v2.md rename to benchmark/tpch-v2.md diff --git a/v3.0/benchmark/tpch.md b/benchmark/tpch.md similarity index 100% rename from v3.0/benchmark/tpch.md rename to benchmark/tpch.md diff --git a/v3.0/contribute.md b/contribute.md similarity index 100% rename from v3.0/contribute.md rename to contribute.md diff --git a/dev/TOC.md b/dev/TOC.md deleted file mode 100644 index 5166bc4cef18..000000000000 --- a/dev/TOC.md +++ /dev/null @@ -1,490 +0,0 @@ -# TiDB 中文用户文档 - - - - -## 目录 - -+ 关于 TiDB - - [TiDB 简介](/dev/overview.md) - + Benchmark 测试 - - [如何用 Sysbench 测试 TiDB](/dev/benchmark/how-to-run-sysbench.md) - - [如何对 TiDB 进行 TPC-C 测试](/dev/benchmark/how-to-run-tpcc.md) - - [Sysbench 性能对比 - v3.0 对比 v2.1](/dev/benchmark/sysbench-v4.md) - - [TPC-C 性能对比 - v3.0 对比 v2.1](/dev/benchmark/tpcc.md) - - [线上负载与 `Add Index` 相互影响测试](/dev/benchmark/add-index-with-load.md) - - [TiDB in Kubernetes Sysbench 性能测试](/dev/benchmark/sysbench-in-k8s.md) - - [DM 1.0-GA 性能测试](/dev/benchmark/dm-v1.0-ga.md) -+ 主要概念 - - [整体架构](/dev/architecture.md) - + 核心特性 - - [水平扩展](/dev/key-features.md#水平扩展) - - [高可用](/dev/key-features.md#高可用) -+ 操作指南 - + 快速上手 - - [使用 Docker Compose 部署 TiDB](/dev/how-to/get-started/deploy-tidb-from-docker-compose.md) - - [SQL 基本操作](/dev/how-to/get-started/explore-sql.md) - - [读取历史数据](/dev/how-to/get-started/read-historical-data.md) - - [TiDB Binlog 教程](/dev/how-to/get-started/tidb-binlog.md) - - [TiDB Data Migration 教程](/dev/how-to/get-started/data-migration.md) - - [TiDB Lightning 教程](/dev/how-to/get-started/tidb-lightning.md) - - [TiSpark 教程](/dev/how-to/get-started/tispark.md) - + 部署 - - [软硬件环境需求](/dev/how-to/deploy/hardware-recommendations.md) - + 集群部署方式 - - [使用 Ansible 部署（推荐）](/dev/how-to/deploy/orchestrated/ansible.md) - - [使用 Ansible 离线部署](/dev/how-to/deploy/orchestrated/offline-ansible.md) - - [使用 Docker 部署](/dev/how-to/deploy/orchestrated/docker.md) - + 跨地域冗余 - - [跨数据中心部署方案](/dev/how-to/deploy/geographic-redundancy/overview.md) - - [配置集群拓扑](/dev/how-to/deploy/geographic-redundancy/location-awareness.md) - - [使用 Ansible 部署 DM 集群](/dev/how-to/deploy/data-migration-with-ansible.md) - + 配置 - - [时区](/dev/how-to/configure/time-zone.md) - - [内存控制](/dev/how-to/configure/memory-control.md) - + 安全 - + 安全传输层协议 (TLS) - - [为 MySQL 客户端开启 TLS](/dev/how-to/secure/enable-tls-clients.md) - - [为 TiDB 组件间开启 TLS](/dev/how-to/secure/enable-tls-between-components.md) - - [生成自签名证书](/dev/how-to/secure/generate-self-signed-certificates.md) - + 监控 - - [概述](/dev/how-to/monitor/overview.md) - - [监控 TiDB 集群](/dev/how-to/monitor/monitor-a-cluster.md) - + 迁移 - - [迁移工具使用指南](/dev/reference/tools/user-guide.md) - + 从 MySQL 迁移 - - [以 Amazon Aurora MySQL 为例](/dev/how-to/migrate/from-mysql-aurora.md) - - [从 CSV 迁移](/dev/reference/tools/tidb-lightning/csv.md) - + 运维 - - [Ansible 常见运维操作](/dev/how-to/maintain/ansible-operations.md) - + 备份与恢复 - - [使用 Mydumper/TiDB Lightning 进行备份与恢复](/dev/how-to/maintain/backup-and-restore/mydumper-lightning.md) - - [使用 BR 进行备份与恢复](/dev/reference/tools/br/br.md) - - [BR 备份与恢复场景示例](/dev/reference/tools/br/use-cases.md) - + 定位异常查询 - - [定位慢查询](/dev/how-to/maintain/identify-abnormal-queries/identify-slow-queries.md) - - [定位消耗系统资源多的查询](/dev/how-to/maintain/identify-abnormal-queries/identify-aborted-queries.md) - + 扩容缩容 - - [使用 Ansible 扩容缩容](/dev/how-to/scale/with-ansible.md) - + 升级 - - [升级至最新开发版](/dev/how-to/upgrade/from-previous-version.md) - + 故障诊断 - - [集群配置诊断](/dev/how-to/troubleshoot/cluster-setup.md) - - [TiDB Lightning 故障诊断](/dev/how-to/troubleshoot/tidb-lightning.md) -+ 参考手册 - + SQL - - [与 MySQL 兼容性对比](/dev/reference/mysql-compatibility.md) - + SQL 语言结构 - - [字面值](/dev/reference/sql/language-structure/literal-values.md) - - [Schema 对象名](/dev/reference/sql/language-structure/schema-object-names.md) - - [关键字和保留字](/dev/reference/sql/language-structure/keywords-and-reserved-words.md) - - [用户自定义变量](/dev/reference/sql/language-structure/user-defined-variables.md) - - [表达式语法](/dev/reference/sql/language-structure/expression-syntax.md) - - [注释语法](/dev/reference/sql/language-structure/comment-syntax.md) - + 数据类型 - - [概述](/dev/reference/sql/data-types/overview.md) - - [默认值](/dev/reference/sql/data-types/default-values.md) - + 数值类型 - - [`BIT`](/dev/reference/sql/data-types/numeric.md#bit-类型) - - [`BOOL|BOOLEAN`](/dev/reference/sql/data-types/numeric.md#boolean-类型) - - [`TINYINT`](/dev/reference/sql/data-types/numeric.md#tinyint-类型) - - [`SMALLINT`](/dev/reference/sql/data-types/numeric.md#smallint-类型) - - [`MEDIUMINT`](/dev/reference/sql/data-types/numeric.md#mediumint-类型) - - [`INT|INTEGER`](/dev/reference/sql/data-types/numeric.md#integer-类型) - - [`BIGINT`](/dev/reference/sql/data-types/numeric.md#bigint-类型) - - [`DECIMAL`](/dev/reference/sql/data-types/numeric.md#decimal-类型) - - [`FLOAT`](/dev/reference/sql/data-types/numeric.md#float-类型) - - [`DOUBLE`](/dev/reference/sql/data-types/numeric.md#double-类型) - + 日期和时间类型 - - [`DATE`](/dev/reference/sql/data-types/date-and-time.md#date-类型) - - [`DATETIME`](/dev/reference/sql/data-types/date-and-time.md#datetime-类型) - - [`TIMESTAMP`](/dev/reference/sql/data-types/date-and-time.md#timestamp-类型) - - [`TIME`](/dev/reference/sql/data-types/date-and-time.md#time-类型) - - [`YEAR`](/dev/reference/sql/data-types/date-and-time.md#year-类型) - + 字符串类型 - - [`CHAR`](/dev/reference/sql/data-types/string.md#char-类型) - - [`VARCHAR`](/dev/reference/sql/data-types/string.md#varchar-类型) - - [`TEXT`](/dev/reference/sql/data-types/string.md#text-类型) - - [`LONGTEXT`](/dev/reference/sql/data-types/string.md#longtext-类型) - - [`BINARY`](/dev/reference/sql/data-types/string.md#binary-类型) - - [`VARBINARY`](/dev/reference/sql/data-types/string.md#varbinary-类型) - - [`TINYBLOB`](/dev/reference/sql/data-types/string.md#tinyblob-类型) - - [`BLOB`](/dev/reference/sql/data-types/string.md#blob-类型) - - [`MEDIUMBLOB`](/dev/reference/sql/data-types/string.md#mediumblob-类型) - - [`LONGBLOB`](/dev/reference/sql/data-types/string.md#longblob-类型) - - [`ENUM`](/dev/reference/sql/data-types/string.md#enum-类型) - - [`SET`](/dev/reference/sql/data-types/string.md#set-类型) - - [JSON Type](/dev/reference/sql/data-types/json.md) - + 函数与操作符 - - [函数与操作符概述](/dev/reference/sql/functions-and-operators/reference.md) - - [表达式求值的类型转换](/dev/reference/sql/functions-and-operators/type-conversion.md) - - [操作符](/dev/reference/sql/functions-and-operators/operators.md) - - [控制流程函数](/dev/reference/sql/functions-and-operators/control-flow-functions.md) - - [字符串函数](/dev/reference/sql/functions-and-operators/string-functions.md) - - [数值函数与操作符](/dev/reference/sql/functions-and-operators/numeric-functions-and-operators.md) - - [日期和时间函数](/dev/reference/sql/functions-and-operators/date-and-time-functions.md) - - [位函数和操作符](/dev/reference/sql/functions-and-operators/bit-functions-and-operators.md) - - [Cast 函数和操作符](/dev/reference/sql/functions-and-operators/cast-functions-and-operators.md) - - [加密和压缩函数](/dev/reference/sql/functions-and-operators/encryption-and-compression-functions.md) - - [信息函数](/dev/reference/sql/functions-and-operators/information-functions.md) - - [JSON 函数](/dev/reference/sql/functions-and-operators/json-functions.md) - - [GROUP BY 聚合函数](/dev/reference/sql/functions-and-operators/aggregate-group-by-functions.md) - - [窗口函数](/dev/reference/sql/functions-and-operators/window-functions.md) - - [其它函数](/dev/reference/sql/functions-and-operators/miscellaneous-functions.md) - - [精度数学](/dev/reference/sql/functions-and-operators/precision-math.md) - - [下推到 TiKV 的表达式列表](/dev/reference/sql/functions-and-operators/expressions-pushed-down.md) - + SQL 语句 - - [`ADD COLUMN`](/dev/reference/sql/statements/add-column.md) - - [`ADD INDEX`](/dev/reference/sql/statements/add-index.md) - - [`ADMIN`](/dev/reference/sql/statements/admin.md) - - [`ALTER DATABASE`](/dev/reference/sql/statements/alter-database.md) - - [`ALTER TABLE`](/dev/reference/sql/statements/alter-table.md) - - [`ALTER USER`](/dev/reference/sql/statements/alter-user.md) - - [`ANALYZE TABLE`](/dev/reference/sql/statements/analyze-table.md) - - [`BEGIN`](/dev/reference/sql/statements/begin.md) - - [`COMMIT`](/dev/reference/sql/statements/commit.md) - - [`CREATE DATABASE`](/dev/reference/sql/statements/create-database.md) - - [`CREATE INDEX`](/dev/reference/sql/statements/create-index.md) - - [`CREATE TABLE LIKE`](/dev/reference/sql/statements/create-table-like.md) - - [`CREATE TABLE`](/dev/reference/sql/statements/create-table.md) - - [`CREATE USER`](/dev/reference/sql/statements/create-user.md) - - [`CREATE VIEW`](/dev/reference/sql/statements/create-view.md) - - [`DEALLOCATE`](/dev/reference/sql/statements/deallocate.md) - - [`DELETE`](/dev/reference/sql/statements/delete.md) - - [`DESC`](/dev/reference/sql/statements/desc.md) - - [`DESCRIBE`](/dev/reference/sql/statements/describe.md) - - [`DO`](/dev/reference/sql/statements/do.md) - - [`DROP COLUMN`](/dev/reference/sql/statements/drop-column.md) - - [`DROP DATABASE`](/dev/reference/sql/statements/drop-database.md) - - [`DROP INDEX`](/dev/reference/sql/statements/drop-index.md) - - [`DROP TABLE`](/dev/reference/sql/statements/drop-table.md) - - [`DROP USER`](/dev/reference/sql/statements/drop-user.md) - - [`DROP VIEW`](/dev/reference/sql/statements/drop-view.md) - - [`EXECUTE`](/dev/reference/sql/statements/execute.md) - - [`EXPLAIN ANALYZE`](/dev/reference/sql/statements/explain-analyze.md) - - [`EXPLAIN`](/dev/reference/sql/statements/explain.md) - - [`FLUSH PRIVILEGES`](/dev/reference/sql/statements/flush-privileges.md) - - [`FLUSH STATUS`](/dev/reference/sql/statements/flush-status.md) - - [`FLUSH TABLES`](/dev/reference/sql/statements/flush-tables.md) - - [`GRANT `](/dev/reference/sql/statements/grant-privileges.md) - - [`INSERT`](/dev/reference/sql/statements/insert.md) - - [`KILL [TIDB]`](/dev/reference/sql/statements/kill.md) - - [`LOAD DATA`](/dev/reference/sql/statements/load-data.md) - - [`MODIFY COLUMN`](/dev/reference/sql/statements/modify-column.md) - - [`PREPARE`](/dev/reference/sql/statements/prepare.md) - - [`RECOVER TABLE`](/dev/reference/sql/statements/recover-table.md) - - [`RENAME INDEX`](/dev/reference/sql/statements/rename-index.md) - - [`RENAME TABLE`](/dev/reference/sql/statements/rename-table.md) - - [`REPLACE`](/dev/reference/sql/statements/replace.md) - - [`REVOKE `](/dev/reference/sql/statements/revoke-privileges.md) - - [`ROLLBACK`](/dev/reference/sql/statements/rollback.md) - - [`SELECT`](/dev/reference/sql/statements/select.md) - - [`SET [NAMES|CHARACTER SET]`](/dev/reference/sql/statements/set-names.md) - - [`SET PASSWORD`](/dev/reference/sql/statements/set-password.md) - - [`SET TRANSACTION`](/dev/reference/sql/statements/set-transaction.md) - - [`SET [GLOBAL|SESSION] `](/dev/reference/sql/statements/set-variable.md) - - [`SHOW CHARACTER SET`](/dev/reference/sql/statements/show-character-set.md) - - [`SHOW COLLATION`](/dev/reference/sql/statements/show-collation.md) - - [`SHOW [FULL] COLUMNS FROM`](/dev/reference/sql/statements/show-columns-from.md) - - [`SHOW CREATE TABLE`](/dev/reference/sql/statements/show-create-table.md) - - [`SHOW CREATE USER`](/dev/reference/sql/statements/show-create-user.md) - - [`SHOW DATABASES`](/dev/reference/sql/statements/show-databases.md) - - [`SHOW ENGINES`](/dev/reference/sql/statements/show-engines.md) - - [`SHOW ERRORS`](/dev/reference/sql/statements/show-errors.md) - - [`SHOW [FULL] FIELDS FROM`](/dev/reference/sql/statements/show-fields-from.md) - - [`SHOW GRANTS`](/dev/reference/sql/statements/show-grants.md) - - [`SHOW INDEXES [FROM|IN]`](/dev/reference/sql/statements/show-indexes.md) - - [`SHOW INDEX [FROM|IN]`](/dev/reference/sql/statements/show-index.md) - - [`SHOW KEYS [FROM|IN]`](/dev/reference/sql/statements/show-keys.md) - - [`SHOW PRIVILEGES`](/dev/reference/sql/statements/show-privileges.md) - - [`SHOW [FULL] PROCESSSLIST`](/dev/reference/sql/statements/show-processlist.md) - - [`SHOW SCHEMAS`](/dev/reference/sql/statements/show-schemas.md) - - [`SHOW [FULL] TABLES`](/dev/reference/sql/statements/show-tables.md) - - [`SHOW TABLE REGIONS`](/dev/reference/sql/statements/show-table-regions.md) - - [`SHOW TABLE STATUS`](/dev/reference/sql/statements/show-table-status.md) - - [`SHOW [GLOBAL|SESSION] VARIABLES`](/dev/reference/sql/statements/show-variables.md) - - [`SHOW WARNINGS`](/dev/reference/sql/statements/show-warnings.md) - - [`SPLIT REGION`](/dev/reference/sql/statements/split-region.md) - - [`START TRANSACTION`](/dev/reference/sql/statements/start-transaction.md) - - [`TRACE`](/dev/reference/sql/statements/trace.md) - - [`TRUNCATE`](/dev/reference/sql/statements/truncate.md) - - [`UPDATE`](/dev/reference/sql/statements/update.md) - - [`USE`](/dev/reference/sql/statements/use.md) - - [约束](/dev/reference/sql/constraints.md) - - [生成列](/dev/reference/sql/generated-columns.md) - - [分区表](/dev/reference/sql/partitioning.md) - - [字符集](/dev/reference/sql/character-set.md) - - [SQL 模式](/dev/reference/sql/sql-mode.md) - - [视图](/dev/reference/sql/view.md) - + 配置 - + tidb-server - - [MySQL 系统变量](/dev/reference/configuration/tidb-server/mysql-variables.md) - - [TiDB 特定系统变量](/dev/reference/configuration/tidb-server/tidb-specific-variables.md) - - [配置参数](/dev/reference/configuration/tidb-server/configuration.md) - - [配置文件描述](/dev/reference/configuration/tidb-server/configuration-file.md) - + pd-server - - [配置参数](/dev/reference/configuration/pd-server/configuration.md) - - [配置文件描述](/dev/reference/configuration/pd-server/configuration-file.md) - + tikv-server - - [配置参数](/dev/reference/configuration/tikv-server/configuration.md) - - [配置文件描述](/dev/reference/configuration/tikv-server/configuration-file.md) - + 安全 - - [与 MySQL 的安全特性差异](/dev/reference/security/compatibility.md) - - [TiDB 数据库权限管理](/dev/reference/security/privilege-system.md) - - [TiDB 用户账户管理](/dev/reference/security/user-account-management.md) - - [基于角色的访问控制](/dev/reference/security/role-based-access-control.md) - - [TiDB 证书鉴权使用指南](/dev/reference/security/cert-based-authentication.md) - + 事务 - - [事务概览](/dev/reference/transactions/overview.md) - - [隔离级别](/dev/reference/transactions/transaction-isolation.md) - - [乐观事务](/dev/reference/transactions/transaction-optimistic.md) - - [悲观事务](/dev/reference/transactions/transaction-pessimistic.md) - + 系统数据库 - - [`mysql`](/dev/reference/system-databases/mysql.md) - - [`information_schema`](/dev/reference/system-databases/information-schema.md) - - [错误码](/dev/reference/error-codes.md) - - [支持的连接器和 API](/dev/reference/supported-clients.md) - + 垃圾回收 (GC) - - [GC 机制简介](/dev/reference/garbage-collection/overview.md) - - [GC 配置](/dev/reference/garbage-collection/configuration.md) - + 性能调优 - - [SQL 优化流程](/dev/reference/performance/sql-optimizer-overview.md) - - [理解 TiDB 执行计划](/dev/reference/performance/understanding-the-query-execution-plan.md) - - [执行计划绑定](/dev/reference/performance/execution-plan-bind.md) - - [统计信息概述](/dev/reference/performance/statistics.md) - - [Optimizer Hints](/dev/reference/performance/optimizer-hints.md) - - [Follower Read](/dev/reference/performance/follower-read.md) - - [使用 SQL 语句检查 TiDB 集群状态](/dev/reference/performance/check-cluster-status-using-sql-statements.md) - - [Statement Summary Table](/dev/reference/performance/statement-summary.md) - - [TiKV 调优](/dev/reference/performance/tune-tikv.md) - - [TiDB 最佳实践](https://pingcap.com/blog-cn/tidb-best-practice/) - + 监控指标 - - [Overview 面板](/dev/reference/key-monitoring-metrics/overview-dashboard.md) - - [TiDB 面板](/dev/reference/key-monitoring-metrics/tidb-dashboard.md) - - [PD 面板](/dev/reference/key-monitoring-metrics/pd-dashboard.md) - - [TiKV 面板](/dev/reference/key-monitoring-metrics/tikv-dashboard.md) - - [报警规则](/dev/reference/alert-rules.md) - + 最佳实践 - - [HAProxy 最佳实践](/dev/reference/best-practices/haproxy.md) - - [Java 应用开发最佳实践](/dev/reference/best-practices/java-app.md) - - [高并发写入场景最佳实践](/dev/reference/best-practices/high-concurrency.md) - - [Grafana 监控最佳实践](/dev/reference/best-practices/grafana-monitor.md) - - [PD 调度策略最佳实践](/dev/reference/best-practices/pd-scheduling.md) - - [海量 Region 集群调优最佳实践](/dev/reference/best-practices/massive-regions.md) - + [TiSpark 使用指南](/dev/reference/tispark.md) - + TiDB Binlog - - [概述](/dev/reference/tidb-binlog/overview.md) - - [部署使用](/dev/reference/tidb-binlog/deploy.md) - - [运维管理](/dev/reference/tidb-binlog/maintain.md) - - [版本升级](/dev/reference/tidb-binlog/upgrade.md) - - [监控告警](/dev/reference/tidb-binlog/monitor.md) - - [增量恢复](/dev/reference/tidb-binlog/reparo.md) - - [Kafka 自定义开发](/dev/reference/tidb-binlog/binlog-slave-client.md) - - [TiDB Binlog Relay Log](/dev/reference/tidb-binlog/relay-log.md) - - [术语表](/dev/reference/tidb-binlog/glossary.md) - + 故障诊断 - - [故障诊断](/dev/reference/tidb-binlog/troubleshoot/binlog.md) - - [常见错误修复](/dev/reference/tidb-binlog/troubleshoot/error-handling.md) - - [FAQ](/dev/reference/tidb-binlog/faq.md) - + 周边工具 - - [工具使用指南](/dev/reference/tools/user-guide.md) - - [Mydumper](/dev/reference/tools/mydumper.md) - - [Loader](/dev/reference/tools/loader.md) - - [Syncer](/dev/reference/tools/syncer.md) - + Data Migration - + 概述 - - [DM 架构](/dev/reference/tools/data-migration/overview.md#dm-架构) - - [同步功能介绍](/dev/reference/tools/data-migration/overview.md#同步功能介绍) - - [使用限制](/dev/reference/tools/data-migration/overview.md#使用限制) - - [DM-worker 简介](/dev/reference/tools/data-migration/dm-worker-intro.md) - - [DM Relay Log](/dev/reference/tools/data-migration/relay-log.md) - + 核心特性 - - [Table Routing](/dev/reference/tools/data-migration/features/overview.md#table-routing) - - [Black & White Lists](/dev/reference/tools/data-migration/features/overview.md#black--white-table-lists) - - [Binlog Event Filter](/dev/reference/tools/data-migration/features/overview.md#binlog-event-filter) - - [同步延迟监控](/dev/reference/tools/data-migration/features/overview.md#同步延迟监控) - + Shard Support - - [简介](/dev/reference/tools/data-migration/features/shard-merge.md) - - [使用限制](/dev/reference/tools/data-migration/features/shard-merge.md#使用限制) - - [手动处理 Sharding DDL Lock](/dev/reference/tools/data-migration/features/manually-handling-sharding-ddl-locks.md) - + 使用场景 - - [简单的从库同步场景](/dev/reference/tools/data-migration/usage-scenarios/simple-synchronization.md) - - [分库分表合并场景](/dev/reference/tools/data-migration/usage-scenarios/shard-merge.md) - - [分表合并数据迁移最佳实践](/dev/reference/tools/data-migration/usage-scenarios/best-practice-dm-shard.md) - - [DM-worker 在上游 MySQL 主从间切换](/dev/reference/tools/data-migration/usage-scenarios/master-slave-switch.md) - + [部署使用](/dev/reference/tools/data-migration/deploy.md) - + 配置 - - [概述](/dev/reference/tools/data-migration/configure/overview.md) - - [DM-master 配置](/dev/reference/tools/data-migration/configure/dm-master-configuration-file.md) - - [DM-worker 配置](/dev/reference/tools/data-migration/configure/dm-worker-configuration-file.md) - - [任务配置](/dev/reference/tools/data-migration/configure/task-configuration-file.md) - + DM 集群管理 - - [集群操作](/dev/reference/tools/data-migration/cluster-operations.md) - - [集群升级](/dev/reference/tools/data-migration/dm-upgrade.md) - + DM 同步任务管理 - - [管理数据同步任务](/dev/reference/tools/data-migration/manage-tasks.md) - - [任务前置检查](/dev/reference/tools/data-migration/precheck.md) - - [任务状态查询](/dev/reference/tools/data-migration/query-status.md) - - [跳过或替代执行异常的 SQL 语句](/dev/reference/tools/data-migration/skip-replace-sqls.md) - - [监控 DM 集群](/dev/reference/tools/data-migration/monitor.md) - + 从与 MySQL 兼容的数据库迁移数据 - - [从 MySQL/Amazon Aurora MySQL 迁移数据](/dev/how-to/migrate/from-mysql-aurora.md) - - [DM Portal](/dev/reference/tools/data-migration/dm-portal.md) - + DM 故障诊断 - - [故障诊断](/dev/reference/tools/data-migration/troubleshoot/dm.md) - - [错误含义](/dev/reference/tools/data-migration/troubleshoot/error-system.md) - - [常见错误修复](/dev/reference/tools/data-migration/troubleshoot/error-handling.md) - - [DM FAQ](/dev/reference/tools/data-migration/faq.md) - + 版本发布历史 - + v1.0 - - [1.0.2](/dev/reference/tools/data-migration/releases/1.0.2.md) - - [1.0.3](/dev/reference/tools/data-migration/releases/1.0.3.md) - - [TiDB DM 术语表](/dev/reference/tools/data-migration/glossary.md) - + TiDB Lightning - - [概述](/dev/reference/tools/tidb-lightning/overview.md) - - [部署执行](/dev/reference/tools/tidb-lightning/deployment.md) - - [参数说明](/dev/reference/tools/tidb-lightning/config.md) - - [断点续传](/dev/reference/tools/tidb-lightning/checkpoints.md) - - [表库过滤](/dev/reference/tools/tidb-lightning/table-filter.md) - - [CSV 支持](/dev/reference/tools/tidb-lightning/csv.md) - - [TiDB-backend](/dev/reference/tools/tidb-lightning/tidb-backend.md) - - [Web 界面](/dev/reference/tools/tidb-lightning/web.md) - - [监控告警](/dev/reference/tools/tidb-lightning/monitor.md) - - [故障诊断](/dev/how-to/troubleshoot/tidb-lightning.md) - - [FAQ](/dev/faq/tidb-lightning.md) - - [术语表](/dev/reference/tools/tidb-lightning/glossary.md) - - [sync-diff-inspector](/dev/reference/tools/sync-diff-inspector/overview.md) - - [PD Control](/dev/reference/tools/pd-control.md) - - [PD Recover](/dev/reference/tools/pd-recover.md) - - [TiKV Control](/dev/reference/tools/tikv-control.md) - - [TiDB Controller](/dev/reference/tools/tidb-control.md) - - [工具下载](/dev/reference/tools/download.md) -+ TiDB in Kubernetes - - [TiDB Operator 简介](/dev/tidb-in-kubernetes/tidb-operator-overview.md) - + 快速上手 - - [kind](/dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-kind.md) - - [GKE](/dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-gke.md) - - [Minikube](/dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-minikube.md) - + 部署 - - [集群环境要求](/dev/tidb-in-kubernetes/deploy/prerequisites.md) - - [部署 TiDB Operator](/dev/tidb-in-kubernetes/deploy/tidb-operator.md) - - [标准 Kubernetes 上的 TiDB 集群](/dev/tidb-in-kubernetes/deploy/general-kubernetes.md) - - [AWS EKS 上的 TiDB 集群](/dev/tidb-in-kubernetes/deploy/aws-eks.md) - - [GCP 上的 TiDB 集群](/dev/tidb-in-kubernetes/deploy/gcp-gke.md) - - [阿里云上的 TiDB 集群](/dev/tidb-in-kubernetes/deploy/alibaba-cloud.md) - - [访问 Kubernetes 上的 TiDB 集群](/dev/tidb-in-kubernetes/deploy/access-tidb.md) - + 配置 - - [初始化集群](/dev/tidb-in-kubernetes/initialize-cluster.md) - - [监控](/dev/tidb-in-kubernetes/monitor/tidb-in-kubernetes.md) - + 运维 - - [销毁 TiDB 集群](/dev/tidb-in-kubernetes/maintain/destroy-tidb-cluster.md) - - [维护 TiDB 集群所在节点](/dev/tidb-in-kubernetes/maintain/kubernetes-node.md) - - [备份与恢复](/dev/tidb-in-kubernetes/maintain/backup-and-restore.md) - - [恢复 Kubernetes 上的 TiDB 集群数据](/dev/tidb-in-kubernetes/maintain/lightning.md) - - [收集日志](/dev/tidb-in-kubernetes/maintain/log-collecting.md) - - [集群故障自动转移](/dev/tidb-in-kubernetes/maintain/auto-failover.md) - - [TiDB Binlog](/dev/tidb-in-kubernetes/maintain/tidb-binlog.md) - - [重启 TiDB 集群](/dev/tidb-in-kubernetes/maintain/restart.md) - - [扩缩容](/dev/tidb-in-kubernetes/scale-in-kubernetes.md) - + 升级 - - [TiDB 集群](/dev/tidb-in-kubernetes/upgrade/tidb-cluster.md) - - [TiDB Operator](/dev/tidb-in-kubernetes/upgrade/tidb-operator.md) - + 参考信息 - + 配置 - - [集群配置](/dev/tidb-in-kubernetes/reference/configuration/tidb-cluster.md) - - [备份配置](/dev/tidb-in-kubernetes/reference/configuration/backup.md) - - [PV 配置](/dev/tidb-in-kubernetes/reference/configuration/storage-class.md) - - [TiDB Drainer](/dev/tidb-in-kubernetes/reference/configuration/tidb-drainer.md) - + 工具 - - [tkctl](/dev/tidb-in-kubernetes/reference/tools/tkctl.md) - - [相关工具使用](/dev/tidb-in-kubernetes/reference/tools/in-kubernetes.md) - - [故障诊断](/dev/tidb-in-kubernetes/troubleshoot.md) - - [常见问题](/dev/tidb-in-kubernetes/faq.md) -+ 常见问题 (FAQ) - - [TiDB FAQ](/dev/faq/tidb.md) - - [TiDB Lightning FAQ](/dev/faq/tidb-lightning.md) - - [升级 FAQ](/dev/faq/upgrade.md) -+ 技术支持 - - [支持渠道](/dev/support-resources.md) - - [反馈问题](/dev/report-issue.md) -+ [贡献](/dev/contribute.md) - - [贡献代码](/dev/contribute.md#成为-tidb-的贡献者) - - [改进文档](/dev/contribute.md#改进文档) -+ [TiDB 路线图](/dev/roadmap.md) -+ [版本发布历史](/dev/releases/rn.md) - + v4.0 - - [4.0.0-beta](/dev/releases/4.0.0-beta.md) - + v3.1 - - [3.1.0-beta.1](/dev/releases/3.1.0-beta.1.md) - - [3.1.0-beta](/dev/releases/3.1.0-beta.md) - + v3.0 - - [3.0.10](/dev/releases/3.0.10.md) - - [3.0.9](/dev/releases/3.0.9.md) - - [3.0.8](/dev/releases/3.0.8.md) - - [3.0.7](/dev/releases/3.0.7.md) - - [3.0.6](/dev/releases/3.0.6.md) - - [3.0.5](/dev/releases/3.0.5.md) - - [3.0.4](/dev/releases/3.0.4.md) - - [3.0.3](/dev/releases/3.0.3.md) - - [3.0.2](/dev/releases/3.0.2.md) - - [3.0.1](/dev/releases/3.0.1.md) - - [3.0 GA](/dev/releases/3.0-ga.md) - - [3.0.0-rc.3](/dev/releases/3.0.0-rc.3.md) - - [3.0.0-rc.2](/dev/releases/3.0.0-rc.2.md) - - [3.0.0-rc.1](/dev/releases/3.0.0-rc.1.md) - - [3.0.0-beta.1](/dev/releases/3.0.0-beta.1.md) - - [3.0.0-beta](/dev/releases/3.0beta.md) - + v2.1 - - [2.1.19](/dev/releases/2.1.19.md) - - [2.1.18](/dev/releases/2.1.18.md) - - [2.1.17](/dev/releases/2.1.17.md) - - [2.1.16](/dev/releases/2.1.16.md) - - [2.1.15](/dev/releases/2.1.15.md) - - [2.1.14](/dev/releases/2.1.14.md) - - [2.1.13](/dev/releases/2.1.13.md) - - [2.1.12](/dev/releases/2.1.12.md) - - [2.1.11](/dev/releases/2.1.11.md) - - [2.1.10](/dev/releases/2.1.10.md) - - [2.1.9](/dev/releases/2.1.9.md) - - [2.1.8](/dev/releases/2.1.8.md) - - [2.1.7](/dev/releases/2.1.7.md) - - [2.1.6](/dev/releases/2.1.6.md) - - [2.1.5](/dev/releases/2.1.5.md) - - [2.1.4](/dev/releases/2.1.4.md) - - [2.1.3](/dev/releases/2.1.3.md) - - [2.1.2](/dev/releases/2.1.2.md) - - [2.1.1](/dev/releases/2.1.1.md) - - [2.1 GA](/dev/releases/2.1ga.md) - - [2.1 RC5](/dev/releases/21rc5.md) - - [2.1 RC4](/dev/releases/21rc4.md) - - [2.1 RC3](/dev/releases/21rc3.md) - - [2.1 RC2](/dev/releases/21rc2.md) - - [2.1 RC1](/dev/releases/21rc1.md) - - [2.1 Beta](/dev/releases/21beta.md) - + v2.0 - - [2.0.11](/dev/releases/2.0.11.md) - - [2.0.10](/dev/releases/2.0.10.md) - - [2.0.9](/dev/releases/209.md) - - [2.0.8](/dev/releases/208.md) - - [2.0.7](/dev/releases/207.md) - - [2.0.6](/dev/releases/206.md) - - [2.0.5](/dev/releases/205.md) - - [2.0.4](/dev/releases/204.md) - - [2.0.3](/dev/releases/203.md) - - [2.0.2](/dev/releases/202.md) - - [2.0.1](/dev/releases/201.md) - - [2.0](/dev/releases/2.0ga.md) - - [2.0 RC5](/dev/releases/2rc5.md) - - [2.0 RC4](/dev/releases/2rc4.md) - - [2.0 RC3](/dev/releases/2rc3.md) - - [2.0 RC1](/dev/releases/2rc1.md) - - [1.1 Beta](/dev/releases/11beta.md) - - [1.1 Alpha](/dev/releases/11alpha.md) - + v1.0 - - [1.0](/dev/releases/ga.md) - - [Pre-GA](/dev/releases/prega.md) - - [RC4](/dev/releases/rc4.md) - - [RC3](/dev/releases/rc3.md) - - [RC2](/dev/releases/rc2.md) - - [RC1](/dev/releases/rc1.md) -+ [术语表](/dev/glossary.md) diff --git a/dev/_index.md b/dev/_index.md deleted file mode 100755 index ee1c68515efe..000000000000 --- a/dev/_index.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: TiDB 简介 -category: introduction ---- - -# TiDB 简介 - -TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。 - -TiDB 具备如下特性： - -- 高度兼容 MySQL - - [大多数情况下](/dev/reference/mysql-compatibility.md)，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。 - -- 水平弹性扩展 - - 通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。 - -- 分布式事务 - - TiDB 100% 支持标准的 ACID 事务。 - -- 真正金融级高可用 - - 相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。 - -- 一站式 HTAP 解决方案 - - TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解决方案，一份存储同时处理 OLTP & OLAP，无需传统繁琐的 ETL 过程。 - -- 云原生 SQL 数据库 - - TiDB 是为云而设计的数据库，支持公有云、私有云和混合云，使部署、配置和维护变得十分简单。 - -TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 [TiSpark 项目](/dev/reference/tispark.md)来完成。 - -TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力。 - -三篇文章了解 TiDB 技术内幕： - -- [说存储](https://pingcap.com/blog-cn/tidb-internal-1/) -- [说计算](https://pingcap.com/blog-cn/tidb-internal-2/) -- [谈调度](https://pingcap.com/blog-cn/tidb-internal-3/) - -## 部署方式 - -TiDB 可以部署在本地和云平台上，支持公有云、私有云和混合云。你可以根据实际场景或需求，选择相应的方式来部署 TiDB 集群： - -- [使用 Ansible 部署](/dev/how-to/deploy/orchestrated/ansible.md)：如果用于生产环境，须使用 Ansible 部署 TiDB 集群。 -- [使用 Ansible 离线部署](/dev/how-to/deploy/orchestrated/offline-ansible.md)：如果部署环境无法访问网络，可使用 Ansible 进行离线部署。 -- [使用 Docker Compose 部署](/dev/how-to/get-started/deploy-tidb-from-docker-compose.md)：如果你只是想测试 TiDB、体验 TiDB 的特性，或者用于开发环境，可以使用 Docker Compose 在本地快速部署 TiDB 集群。该部署方式不适用于生产环境。 -- [使用 Docker 部署](/dev/how-to/deploy/orchestrated/docker.md)：你可以使用 Docker 部署 TiDB 集群，但该部署方式不适用于生产环境。 - -## 项目源码 - -TiDB 集群所有组件的源码均可从 GitHub 上直接访问： - -- [TiDB](https://github.com/pingcap/tidb) -- [TiKV](https://github.com/tikv/tikv) -- [PD](https://github.com/pingcap/pd) -- [TiSpark](https://github.com/pingcap/tispark) -- [TiDB Operator](https://github.com/pingcap/tidb-operator) diff --git a/dev/benchmark/how-to-run-sysbench.md b/dev/benchmark/how-to-run-sysbench.md deleted file mode 100644 index faee8da77632..000000000000 --- a/dev/benchmark/how-to-run-sysbench.md +++ /dev/null @@ -1,277 +0,0 @@ ---- -title: 如何用 Sysbench 测试 TiDB -category: benchmark ---- - -# 如何用 Sysbench 测试 TiDB - -本次测试使用的是 TiDB 3.0 Beta 和 Sysbench 1.0.14。建议使用 Sysbench 1.0 或之后的更新版本，可在 [Sysbench Release 1.0.14 页面](https://github.com/akopytov/sysbench/releases/tag/1.0.14)下载。 - -## 测试环境 - -- [硬件要求](/dev/how-to/deploy/hardware-recommendations.md) - -- 参考 [TiDB 部署文档](/dev/how-to/deploy/orchestrated/ansible.md)部署 TiDB 集群。在 3 台服务器的条件下，建议每台机器部署 1 个 TiDB，1 个 PD，和 1 个 TiKV 实例。关于磁盘，以 32 张表、每张表 10M 行数据为例，建议 TiKV 的数据目录所在的磁盘空间大于 512 GB。 - 对于单个 TiDB 的并发连接数，建议控制在 500 以内，如需增加整个系统的并发压力，可以增加 TiDB 实例，具体增加的 TiDB 个数视测试压力而定。 - -IDC 机器： - -| 类别 | 名称 | -|:---- |:---- | -| OS | Linux (CentOS 7.3.1611) | -| CPU | 40 vCPUs, Intel® Xeon® CPU E5-2630 v4 @ 2.20GHz | -| RAM | 128GB | -| DISK | Intel Optane SSD P4800X 375G * 1 | -| NIC | 10Gb Ethernet | - -## 测试方案 - -### TiDB 版本信息 - -| 组件 | GitHash | -|:---- |:---- | -| TiDB | 7a240818d19ae96e4165af9ea35df92466f59ce6 | -| TiKV | e26ceadcdfe94fb6ff83b5abb614ea3115394bcd | -| PD | 5e81548c3c1a1adab056d977e7767307a39ecb70 | - -### 集群拓扑 - -| 机器 IP | 部署实例 | -|:---- |:---- | -| 172.16.30.31 | 3*sysbench | -| 172.16.30.33 | 1\*tidb 1\*pd 1\*tikv | -| 172.16.30.34 | 1\*tidb 1\*pd 1\*tikv | -| 172.16.30.35 | 1\*tidb 1\*pd 1\*tikv | - -### TiDB 配置 - -升高日志级别，可以减少打印日志数量，对 TiDB 的性能有积极影响。开启 TiDB 配置中的 `prepared plan cache`，以减少优化执行计划的开销。具体在 TiDB 配置文件中加入： - -```toml -[log] -level = "error" -[prepared-plan-cache] -enabled = true -``` - -### TiKV 配置 - -升高 TiKV 的日志级别同样有利于提高性能表现。 - -由于 TiKV 是以集群形式部署的，在 Raft 算法的作用下，能保证大多数节点已经写入数据。因此，除了对数据安全极端敏感的场景之外，raftstore 中的 `sync-log` 选项可以关闭。 - -TiKV 集群存在两个 Column Family（Default CF 和 Write CF），主要用于存储不同类型的数据。对于 Sysbench 测试，导入数据的 Column Family 在 TiDB 集群中的比例是固定的。这个比例是： - -Default CF : Write CF = 4 : 1 - -在 TiKV 中需要根据机器内存大小配置 RocksDB 的 block cache，以充分利用内存。以 40 GB 内存的虚拟机部署一个 TiKV 为例，其 block cache 建议配置如下: - -```toml -log-level = "error" -[raftstore] -sync-log = false -[rocksdb.defaultcf] -block-cache-size = "24GB" -[rocksdb.writecf] -block-cache-size = "6GB" -``` - -对于 3.0 及以后的版本，还可以使用共享 block cache 的方式进行设置： - -```toml -log-level = "error" -[raftstore] -sync-log = false -[storage.block-cache] -capacity = "30GB" -``` - -更详细的 TiKV 参数调优请参考 [TiKV 性能参数调优](/dev/reference/performance/tune-tikv.md)。 - -## 测试过程 - -> **注意：** -> -> 此次测试并没有使用如 HAproxy 等负载均衡工具。在 TiDB 单一节点上进行 Sysbench 测试，并把结果相加。负载均衡工具和不同版本参数也会影响性能表现。 - -### Sysbench 配置 - -以下为 Sysbench 配置文件样例： - -```txt -mysql-host={TIDB_HOST} -mysql-port=4000 -mysql-user=root -mysql-password=password -mysql-db=sbtest -time=600 -threads={8, 16, 32, 64, 128, 256} -report-interval=10 -db-driver=mysql -``` - -可根据实际需求调整其参数，其中 `TIDB_HOST` 为 TiDB server 的 IP 地址（配置文件中不能写多个地址），`threads` 为测试中的并发连接数，可在 “8, 16, 32, 64, 128, 256” 中调整，导入数据时，建议设置 threads = 8 或者 16。调整后，将该文件保存为名为 **config** 的文件。 - -**配置文件**参考示例如下： - -```txt -mysql-host=172.16.30.33 -mysql-port=4000 -mysql-user=root -mysql-password=password -mysql-db=sbtest -time=600 -threads=16 -report-interval=10 -db-driver=mysql -``` - -### 数据导入 - -在数据导入前，需要对 TiDB 进行简单设置。在 MySQL 客户端中执行如下命令： - -{{< copyable "sql" >}} - -```sql -set global tidb_disable_txn_auto_retry = off; -``` - -然后退出客户端。TiDB 使用乐观事务模型，当发现并发冲突时，会回滚事务。将 `tidb_disable_txn_auto_retry` 设置为 `off` 会开启事务冲突后的自动重试机制，可以尽可能避免事务冲突报错导致 Sysbench 程序退出的问题。 - -重新启动 MySQL 客户端执行以下 SQL 语句，创建数据库 `sbtest`： - -{{< copyable "sql" >}} - -```sql -create database sbtest; -``` - -调整 Sysbench 脚本创建索引的顺序。Sysbench 按照“建表->插入数据->创建索引”的顺序导入数据。该方式对于 TiDB 需要花费更多的导入时间。用户可以通过调整顺序来加速数据的导入。 - -假设用户使用的 [Sysbench](https://github.com/akopytov/sysbench/tree/1.0.14) 版本。我们可以通过以下两种方式来修改。 - -1. 直接下载为 TiDB 修改好的 [oltp_common.lua](https://raw.githubusercontent.com/pingcap/tidb-bench/master/sysbench/sysbench-patch/oltp_common.lua) 文件，覆盖 `/usr/share/sysbench/oltp_common.lua` 文件。 -2. 将 `/usr/share/sysbench/oltp_common.lua` 的第 [235](https://github.com/akopytov/sysbench/blob/1.0.14/src/lua/oltp_common.lua#L235) 行到第 [240](https://github.com/akopytov/sysbench/blob/1.0.14/src/lua/oltp_common.lua#L240) 行移动到第 198 行以后。 - -> **注意：** -> -> 此操作为可选操作，仅节约了数据导入时间。 - -命令行输入以下命令，开始导入数据，config 文件为上一步中配置的文件： - -{{< copyable "shell-regular" >}} - -```bash -sysbench --config-file=config oltp_point_select --tables=32 --table-size=10000000 prepare -``` - -### 数据预热与统计信息收集 - -数据预热可将磁盘中的数据载入内存的 block cache 中，预热后的数据对系统整体的性能有较大的改善，建议在每次重启集群后进行一次数据预热。 - -Sysbench 1.0.14 没有提供数据预热的功能，因此需要手动进行数据预热。如果使用更新的 Sysbench 版本，可以使用自带的预热功能。 - -以 Sysbench 中某张表 sbtest7 为例，执行如下 SQL 语句 进行数据预热： - -{{< copyable "sql" >}} - -```sql -SELECT COUNT(pad) FROM sbtest7 USE INDEX (k_7); -``` - -统计信息收集有助于优化器选择更为准确的执行计划，可以通过 `analyze` 命令来收集表 sbtest 的统计信息，每个表都需要统计。 - -{{< copyable "sql" >}} - -```sql -ANALYZE TABLE sbtest7; -``` - -### Point select 测试命令 - -{{< copyable "shell-regular" >}} - -```bash -sysbench --config-file=config oltp_point_select --tables=32 --table-size=10000000 run -``` - -### Update index 测试命令 - -{{< copyable "shell-regular" >}} - -```bash -sysbench --config-file=config oltp_update_index --tables=32 --table-size=10000000 run -``` - -### Read-only 测试命令 - -{{< copyable "shell-regular" >}} - -```bash -sysbench --config-file=config oltp_read_only --tables=32 --table-size=10000000 run -``` - -## 测试结果 - -测试了数据 32 表，每表有 10M 数据。 - -对每个 tidb-server 进行了 Sysbench 测试，将结果相加，得出最终结果： - -### oltp_point_select - -| 类型 | Thread | TPS | QPS | avg.latency(ms) | .95.latency(ms) | max.latency(ms) | -|:---- |:---- |:---- |:---- |:----------------|:----------------- |:---- | -| point_select | 3\*8 | 67502.55 | 67502.55 | 0.36 | 0.42 | 141.92 | -| point_select | 3\*16 | 120141.84 | 120141.84 | 0.40 | 0.52 | 20.99 | -| point_select | 3\*32 | 170142.92 | 170142.92 | 0.58 | 0.99 | 28.08 | -| point_select | 3\*64 | 195218.54 | 195218.54 | 0.98 | 2.14 | 21.82 | -| point_select | 3\*128 | 208189.53 | 208189.53 | 1.84 | 4.33 | 31.02 | - -![oltp_point_select](/media/oltp_point_select.png) - -### oltp_update_index - -| 类型 | Thread | TPS | QPS | avg.latency(ms) | .95.latency(ms) | max.latency(ms) | -|:---- |:---- |:---- |:---- |:----------------|:----------------- |:---- | -| oltp_update_index | 3\*8 | 9668.98 | 9668.98 | 2.51 | 3.19 | 103.88| -| oltp_update_index | 3\*16 | 12834.99 | 12834.99 | 3.79 | 5.47 | 176.90 | -| oltp_update_index | 3\*32 | 15955.77 | 15955.77 | 6.07 | 9.39 | 4787.14 | -| oltp_update_index | 3\*64 | 18697.17 | 18697.17 | 10.34 | 17.63 | 4539.04 | -| oltp_update_index | 3\*128 | 20446.81 | 20446.81 | 18.98 | 40.37 | 5394.75 | -| oltp_update_index | 3\*256 | 23563.03 | 23563.03 | 32.86 | 78.60 | 5530.69 | - -![oltp_update_index](/media/oltp_update_index.png) - -### oltp_read_only - -| 类型 | Thread | TPS | QPS | avg.latency(ms) | .95.latency(ms) | max.latency(ms) | -|:---- |:---- |:---- |:---- |:----------------|:----------------- |:---- | -| oltp_read_only | 3\*8 | 2411.00 | 38575.96 | 9.92 | 20.00 | 92.23 | -| oltp_read_only | 3\*16 | 3873.53 | 61976.50 | 12.25 | 16.12 | 56.94 | -| oltp_read_only | 3\*32 | 5066.88 | 81070.16 | 19.42 | 26.20 | 123.41 | -| oltp_read_only | 3\*64 | 5466.36 | 87461.81 | 34.65 | 63.20 | 231.19 | -| oltp_read_only | 3\*128 | 6684.16 | 106946.59 | 57.29 | 97.55 | 180.85 | - -![oltp_read_only](/media/oltp_read_only.png) - -## 常见问题 - -### 在高并发压力下，TiDB、TiKV 的配置都合理，为什么整体性能还是偏低？ - -这种情况可能与使用了 proxy 有关。可以尝试直接对单个 TiDB 加压，将求和后的结果与使用 proxy 的情况进行对比。 - -以 HAproxy 为例。`nbproc` 参数可以增加其最大启动的进程数，较新版本的 HAproxy 还支持 `nbthread` 和 `cpu-map` 等。这些都可以减少对其性能的不利影响。 - -### 在高并发压力下，为什么 TiKV 的 CPU 利用率依然很低？ - -TiKV 虽然整体 CPU 偏低，但部分模块的 CPU 可能已经达到了很高的利用率。 - -TiKV 的其他模块，如 storage readpool、coprocessor 和 gRPC 的最大并发度限制是可以通过 TiKV 的配置文件进行调整的。 - -通过 Grafana 的 TiKV Thread CPU 监控面板可以观察到其实际使用率。如出现多线程模块瓶颈，可以通过增加该模块并发度进行调整。 - -### 在高并发压力下，TiKV 也未达到 CPU 使用瓶颈，为什么 TiDB 的 CPU 利用率依然很低？ - -在某些高端设备上，使用的是 NUMA 架构的 CPU，跨 CPU 访问远端内存将极大降低性能。TiDB 默认将使用服务器所有 CPU，goroutine 的调度不可避免地会出现跨 CPU 内存访问。 - -因此，建议在 NUMA 架构服务器上，部署 *n* 个 TiDB（*n* = NUMA CPU 的个数），同时将 TiDB 的 `max-procs` 变量的值设置为与 NUMA CPU 的核数相同。 diff --git a/dev/benchmark/sysbench-v2.md b/dev/benchmark/sysbench-v2.md deleted file mode 100644 index bce70f8a8400..000000000000 --- a/dev/benchmark/sysbench-v2.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -title: TiDB Sysbench 性能对比测试报告 - v2.0.0 对比 v1.0.0 -category: benchmark ---- - -# TiDB Sysbench 性能对比测试报告 - v2.0.0 对比 v1.0.0 - -## 测试目的 - -对比 TiDB 2.0 版本和 1.0 版本在 OLTP 场景下的性能。 - -## 测试版本、时间、地点 - -TiDB 版本：v1.0.8 Vs v2.0.0-rc6 - -时间：2018 年 4 月 - -地点：北京 - -## 测试环境 - -IDC 机器 - -| 类别 | 名称 | -| :--------: | :---------: | -| OS | Linux (CentOS 7.3.1611) | -| CPU | 40 vCPUs, Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz | -| RAM | 128GB | -| DISK | Optane 500GB SSD * 1 | - -## 测试方案 - -### TiDB 版本信息 - -### v1.0.8 - -| 组件 | GitHash | -| :--------: | :---------: | -| TiDB | 571f0bbd28a0b8155a5ee831992c986b90d21ab7 | -| TiKV | 4ef5889947019e3cb55cc744f487aa63b42540e7 | -| PD | 776bcd940b71d295a2c7ed762582bc3aff7d3c0e | - -### v2.0.0-rc6 - -| 组件 | GitHash | -| :--------: | :---------: | -| TiDB | 82d35f1b7f9047c478f4e1e82aa0002abc8107e7 | -| TiKV | 7ed4f6a91f92cad5cd5323aaebe7d9f04b77cc79 | -| PD | 2c8e7d7e33b38e457169ce5dfb2f461fced82d65 | - -### TiKV 参数配置 - -* v1.0.8 - - ``` - sync-log = false - grpc-concurrency = 8 - grpc-raft-conn-num = 24 - ``` - -* v2.0.0-rc6 - - ``` - sync-log = false - grpc-concurrency = 8 - grpc-raft-conn-num = 24 - use-delete-range: false - ``` - -### 集群拓扑 - -| 机器 IP | 部署实例 | -|--------------|------------| -| 172.16.21.1 | 1*tidb 1*pd 1*sysbench | -| 172.16.21.2 | 1*tidb 1*pd 1*sysbench | -| 172.16.21.3 | 1*tidb 1*pd 1*sysbench | -| 172.16.11.4 | 1*tikv | -| 172.16.11.5 | 1*tikv | -| 172.16.11.6 | 1*tikv | -| 172.16.11.7 | 1*tikv | -| 172.16.11.8 | 1*tikv | -| 172.16.11.9 | 1*tikv | - -## 测试结果 - -### 标准 Select 测试 - -| 版本 | table count | table size | sysbench threads |qps | latency(avg / .95) | -| :---: | :---: | :---: | :---: | :---: | :---: | -| v2.0.0-rc6 | 32 | 1000 万 | 128 * 3 | 201936 | 1.9033 ms / 5.67667 ms | -| v2.0.0-rc6 | 32 | 1000 万 | 256 * 3 | 208130 | 3.69333 ms / 8.90333 ms | -| v2.0.0-rc6 | 32 | 1000 万 | 512 * 3 | 211788 | 7.23333 ms / 15.59 ms | -| v2.0.0-rc6 | 32 | 1000 万 | 1024 * 3 | 212868 | 14.5933 ms / 43.2133 ms | -| v1.0.8 | 32 | 1000 万 | 128 * 3 | 188686 | 2.03667 ms / 5.99 ms | -| v1.0.8 | 32 | 1000 万 | 256 * 3 | 195090 |3.94 ms / 9.12 ms | -| v1.0.8 | 32 | 1000 万 | 512 * 3 | 203012 | 7.57333 ms / 15.3733 ms | -| v1.0.8 | 32 | 1000 万 | 1024 * 3 | 205932 | 14.9267 ms / 40.7633 ms | - -GA2.0 比 GA1.0 在 Select 查询性能上，最高提升了 10% 左右。 - -### 标准 OLTP 测试 - -| 版本 | table count | table size | sysbench threads | tps | qps | latency(avg / .95) | -| :---: | :---: | :---: | :---: | :---: | :---: | :---:| -| v2.0.0-rc6 | 32 | 1000 万 | 128 * 3 | 5404.22 | 108084.4 | 87.2033 ms / 110 ms | -| v2.0.0-rc6 | 32 | 1000 万 | 256 * 3 | 5578.165 | 111563.3 | 167.673 ms / 275.623 ms | -| v2.0.0-rc6 | 32 | 1000 万 | 512 * 3 | 5874.045 | 117480.9 | 315.083 ms / 674.017 ms | -| v2.0.0-rc6 | 32 | 1000 万 | 1024 * 3 | 6290.7 | 125814 | 529.183 ms / 857.007 ms | -| v1.0.8 | 32 | 1000 万 | 128 * 3 | 5523.91 | 110478 | 69.53 ms / 88.6333 ms | -| v1.0.8 | 32 | 1000 万 | 256 * 3 | 5969.43 | 119389 |128.63 ms / 162.58 ms | -| v1.0.8 | 32 | 1000 万 | 512 * 3 | 6308.93 | 126179 | 243.543 ms / 310.913 ms | -| v1.0.8 | 32 | 1000 万 | 1024 * 3 | 6444.25 | 128885 | 476.787ms / 635.143 ms | - -GA2.0 比 GA1.0 在 OLTP 性能上，性能基本一致。 - -### 标准 Insert 测试 - -| 版本 | table count | table size | sysbench threads |qps | latency(avg / .95) | -| :---: | :---: | :---: | :---: | :---: | :---: | -| v2.0.0-rc6 | 32 | 1000 万 | 128 * 3 | 31707.5 | 12.11 ms / 21.1167 ms | -| v2.0.0-rc6 | 32 | 1000 万 | 256 * 3 | 38741.2 | 19.8233 ms / 39.65 ms | -| v2.0.0-rc6 | 32 | 1000 万 | 512 * 3 | 45136.8 | 34.0267 ms / 66.84 ms | -| v2.0.0-rc6 | 32 | 1000 万 | 1024 * 3 | 48667 | 63.1167 ms / 121.08 ms | -| v1.0.8 | 32 | 1000 万 | 128 * 3 | 31125.7 | 12.3367 ms / 19.89 ms | -| v1.0.8 | 32 | 1000 万 | 256 * 3 | 36800 | 20.8667 ms / 35.3767 ms | -| v1.0.8 | 32 | 1000 万 | 512 * 3 | 44123 | 34.8067 ms / 63.32 ms | -| v1.0.8 | 32 | 1000 万 | 1024 * 3 | 48496 | 63.3333 ms / 118.92 ms | - -GA2.0 比 GA1.0 在 Insert 性能上略有提升。 diff --git a/dev/benchmark/sysbench-v3.md b/dev/benchmark/sysbench-v3.md deleted file mode 100644 index 35270f2451c3..000000000000 --- a/dev/benchmark/sysbench-v3.md +++ /dev/null @@ -1,142 +0,0 @@ ---- -title: TiDB Sysbench 性能对比测试报告 - v2.1 对比 v2.0 -category: benchmark ---- - -# TiDB Sysbench 性能对比测试报告 - v2.1 对比 v2.0 - -## 测试目的 - -对比 TiDB 2.1 版本和 2.0 版本在 OLTP 场景下的性能。 - -## 测试版本、时间、地点 - -TiDB 版本：v2.1.0-rc.2 vs. v2.0.6 - -时间：2018 年 9 月 - -地点：北京 - -## 测试环境 - -IDC 机器： - -| 类别 | 名称 | -| :-: | :-: | -| OS | Linux (CentOS 7.3.1611) | -| CPU | 40 vCPUs, Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz | -| RAM | 128GB | -| DISK | Optane 500GB SSD \* 1 | - -Sysbench 版本：1.1.0 - -## 测试方案 - -使用 Sysbench 向集群导入 **16 张表，每张数据 1000 万**。通过 HAProxy 代理，分别以递增并发数向集群发送请求，单次并发测试时间 5 分钟。 - -### TiDB 版本信息 - -### v2.1.0-rc.2 - -| 组件 | GitHash | -| :-: | :-: | -| TiDB | 08e56cd3bae166b2af3c2f52354fbc9818717f62 | -| TiKV | 57e684016dafb17dc8a6837d30224be66cbc7246 | -| PD | 6a7832d2d6e5b2923c79683183e63d030f954563 | - -### v2.0.6 - -| 组件 | GitHash | -| :-: | :-: | -| TiDB | b13bc08462a584a085f377625a7bab0cc0351570 | -| TiKV | 57c83dc4ebc93d38d77dc8f7d66db224760766cc | -| PD | b64716707b7279a4ae822be767085ff17b5f3fea | - -### TiDB 参数配置 - -两版本 TiDB 均使用**默认配置**。 - -### TiKV 参数配置 - -两版本 TiKV 均使用如下配置： - -```txt -[readpool.storage] -normal-concurrency = 8 -[server] -grpc-concurrency = 8 -[raftstore] -sync-log = false -[rocksdb.defaultcf] -block-cache-size = "60GB" -[rocksdb.writecf] -block-cache-size = "20GB" -``` - -### 集群拓扑 - -| 机器 IP | 部署实例 | -| :-: | :-: | -| 172.16.30.31 | 1\*Sysbench 1\*HAProxy | -| 172.16.30.32 | 1\*TiDB 1\*pd 1\*TiKV | -| 172.16.30.33 | 1\*TiDB 1\*TiKV | -| 172.16.30.34 | 1\*TiDB 1\*TiKV | - -## 测试结果 - -### Point Select 测试 - -| 版本 | threads | qps | 95% latency(ms) | -| :-: | :-: | :-: | :-: | -| v2.1 | 64 | 111481.09 | 1.16 | -| v2.1 | 128 | 145102.62 | 2.52 | -| v2.1 | 256 | 161311.9 | 4.57 | -| v2.1 | 512 | 184991.19 | 7.56 | -| v2.1 | 1024 | 230282.74 | 10.84 | -| v2.0 | 64 | 75285.87 | 1.93 | -| v2.0 | 128 | 92141.79 | 3.68 | -| v2.0 | 256 | 107464.93 | 6.67 | -| v2.0 | 512 | 121350.61 | 11.65 | -| v2.0 | 1024 | 150036.31 | 17.32 | - -![point select](/media/sysbench_v3_point_select.png) - -v2.1 比 v2.0 在 Point Select 查询性能上，**提升了 50%**。 - -### Update Non-Index 测试 - -| 版本 | threads | qps | 95% latency(ms) | -| :-: | :-: | :-: | :-: | -| v2.1 | 64 | 18946.09 | 5.77 | -| v2.1 | 128 | 22022.82 | 12.08 | -| v2.1 | 256 | 24679.68 | 25.74 | -| v2.1 | 512 | 25107.1 | 51.94 | -| v2.1 | 1024 | 27144.92 | 106.75 | -| v2.0 | 64 | 16316.85 | 6.91 | -| v2.0 | 128 | 20944.6 | 11.45 | -| v2.0 | 256 | 24017.42 | 23.1 | -| v2.0 | 512 | 25994.33 | 46.63 | -| v2.0 | 1024 | 27917.52 | 92.42 | - -![update non-index](/media/sysbench_v3_update_non_index.png) - -v2.1 与 v2.0 在 Update Non-Index 写入性能上基本一致。 - -### Update Index 测试 - -| 版本 | threads | qps | 95% latency(ms) | -| :-: | :-: | :-: | :-: | -| v2.1 | 64 | 9934.49 | 12.08 | -| v2.1 | 128 | 10505.95 | 25.28 | -| v2.1 | 256 | 11007.7 | 55.82 | -| v2.1 | 512 | 11198.81 | 106.75 | -| v2.1 | 1024 | 11591.89 | 200.47 | -| v2.0 | 64 | 9754.68 | 11.65 | -| v2.0 | 128 | 10603.31 | 24.38 | -| v2.0 | 256 | 11011.71 | 50.11 | -| v2.0 | 512 | 11162.63 | 104.84 | -| v2.0 | 1024 | 12067.63 | 179.94 | - -![update index](/media/sysbench_v3_update_index.png) - -v2.1 与 v2.0 在 Update Index 写入性能上基本一致。 diff --git a/dev/benchmark/sysbench-v4.md b/dev/benchmark/sysbench-v4.md deleted file mode 100644 index 31175bd29a26..000000000000 --- a/dev/benchmark/sysbench-v4.md +++ /dev/null @@ -1,278 +0,0 @@ ---- -title: TiDB Sysbench 性能对比测试报告 - v3.0 对比 v2.1 -category: benchmark ---- - -# TiDB Sysbench 性能对比测试报告 - v3.0 对比 v2.1 - -## 测试目的 - -对比 TiDB 3.0 版本和 2.1 版本在 OLTP 场景下的性能。 - -## 测试版本、时间、地点 - -TiDB 版本：v3.0.0 vs. v2.1.13 - -时间：2019 年 6 月 - -地点：北京 - -## 测试环境 - -测试在 AWS EC2 上进行，使用 CentOS-7.6.1810-Nitro (ami-028946f4cffc8b916) 镜像，各组件实例类型如下： - -| 组件 | 实例类型 | -| :--- | :--------- | -| PD | r5d.xlarge | -| TiKV | c5d.4xlarge | -| TiDB | c5.4xlarge | - -Sysbench 版本：1.0.17 - -## 测试方案 - -使用 Sysbench 向集群导入 **16 张表，每张数据 1000 万**。起 3 个 sysbench 分别向 3 个 TiDB 发压，请求并发数逐步增加，单次测试时间 5 分钟。 - -准备数据命令： - -{{< copyable "shell-regular" >}} - -```sh -sysbench oltp_common \ - --threads=16 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$tidb_host \ - --mysql-port=$tidb_port \ - --mysql-user=root \ - --mysql-password=password \ - prepare --tables=16 --table-size=10000000 -``` - -执行测试命令： - -{{< copyable "shell-regular" >}} - -```sh -sysbench $testname \ - --threads=$threads \ - --time=300 \ - --report-interval=15 \ - --rand-type=uniform \ - --rand-seed=$RANDOM \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$tidb_host \ - --mysql-port=$tidb_port \ - --mysql-user=root \ - --mysql-password=password \ - run --tables=16 --table-size=10000000 -``` - -### TiDB 版本信息 - -### v3.0.0 - -| 组件 | GitHash | -| :--- | :---------------------------------------- | -| TiDB | `8efbe62313e2c1c42fd76d35c6f020087eef22c2` | -| TiKV | `a467f410d235fa9c5b3c355e3b620f81d3ac0e0c` | -| PD | `70aaa5eee830e21068f1ba2d4c9bae59153e5ca3` | - -### v2.1.13 - -| 组件 | GitHash | -| :--- | :---------------------------------------- | -| TiDB | `6b5b1a6802f9b8f5a22d8aab24ac80729331e1bc` | -| TiKV | `b3cf3c8d642534ea6fa93d475a46da285cc6acbf` | -| PD | `886362ebfb26ef0834935afc57bcee8a39c88e54` | - -### TiDB 参数配置 - -2.1 和 3.0 中开启 prepared plan cache (出于优化考虑，2.1 的 point select 与 read write 并未开启)： - -```toml -[prepared-plan-cache] -enabled = true -``` - -并设置全局变量： - -{{< copyable "sql" >}} - -```sql -set global tidb_hashagg_final_concurrency=1; -set global tidb_hashagg_partial_concurrency=1; -set global tidb_disable_txn_auto_retry=0; -``` - -此外 3.0 还做了如下配置： - -```toml -[tikv-client] -max-batch-wait-time = 2000000 -``` - -### TiKV 参数配置 - -2.1 和 3.0 使用如下配置： - -```toml -log-level = "error" -[readpool.storage] -normal-concurrency = 10 -[server] -grpc-concurrency = 6 -[rocksdb.defaultcf] -block-cache-size = "14GB" -[rocksdb.writecf] -block-cache-size = "8GB" -[rocksdb.lockcf] -block-cache-size = "1GB" -``` - -3.0 还做了如下配置： - -```toml -[raftstore] -apply-pool-size = 3 -store-pool-size = 3 -``` - -### 集群拓扑 - -| 机器 IP | 部署实例 | -| :-------------------------------------- | :----------| -| 172.31.8.8 | 3 * Sysbench | -| 172.31.7.80, 172.31.5.163, 172.31.11.123 | PD | -| 172.31.4.172, 172.31.1.155, 172.31.9.210 | TiKV | -| 172.31.7.80, 172.31.5.163, 172.31.11.123 | TiDB | - -## 测试结果 - -### Point Select 测试 - -**v2.1** - -| Threads | QPS | 95% latency(ms) | -| :------- | :-------- | :------------- | -| 150 | 240304.06 | 1.61 | -| 300 | 276635.75 | 2.97 | -| 600 | 307838.06 | 5.18 | -| 900 | 323667.93 | 7.30 | -| 1200 | 330925.73 | 9.39 | -| 1500 | 336250.38 | 11.65 | - - - -**v3.0** - -| Threads | QPS | 95% latency(ms) | -| :------- | :-------- | :-------------- | -| 150 | 334219.04 | 0.64 | -| 300 | 456444.86 | 1.10 | -| 600 | 512177.48 | 2.11 | -| 900 | 525945.13 | 3.13 | -| 1200 | 534577.36 | 4.18 | -| 1500 | 533944.64 | 5.28 | - -![point select](/media/sysbench_v4_point_select.png) - -### Update Non-Index 测试 - -**v2.1** - -| threads | qps | 95% latency(ms) | -| ------- | -------: | --------------: | -| 150 | 21785.37 | 8.58 | -| 300 | 28979.27 | 13.70 | -| 600 | 34629.72 | 24.83 | -| 900 | 36410.06 | 43.39 | -| 1200 | 37174.15 | 62.19 | -| 1500 | 37408.88 | 87.56 | - -**v3.0** - -| threads | qps | 95% latency(ms) | -| ------- | -------: | --------------: | -| 150 | 28045.75 | 6.67 | -| 300 | 39237.77 | 9.91 | -| 600 | 49536.56 | 16.71 | -| 900 | 55963.73 | 22.69 | -| 1200 | 59904.02 | 29.72 | -| 1500 | 62247.95 | 42.61 | - -![update non-index](/media/sysbench_v4_update_non_index.png) - -### Update Index 测试 - -**v2.1** - -| Threads | QPS | 95% latency(ms) | -| :------- | :------- | :-------------- | -| 150 | 14378.24 | 13.22 | -| 300 | 16916.43 | 24.38 | -| 600 | 17636.11 | 57.87 | -| 900 | 17740.92 | 95.81 | -| 1200 | 17929.24 | 130.13 | -| 1500 | 18012.80 | 161.51 | - -**v3.0** - -| Threads | QPS | 95% latency(ms) | -| :------- | :------- | :-------------| -| 150 | 19047.32 | 10.09 | -| 300 | 24467.64 | 16.71 | -| 600 | 28882.66 | 31.94 | -| 900 | 30298.41 | 57.87 | -| 1200 | 30419.40 | 92.42 | -| 1500 | 30643.55 | 125.52 | - -![update index](/media/sysbench_v4_update_index.png) - -### Read Write 测试 - -**v2.1** - -| Threads | QPS | 95% latency(ms) | -| :------- | :-------- | :-------------- | -| 150 | 85140.60 | 44.98 | -| 300 | 96773.01 | 82.96 | -| 600 | 105139.81 | 153.02 | -| 900 | 110041.83 | 215.44 | -| 1200 | 113242.70 | 277.21 | -| 1500 | 114542.19 | 337.94 | - - - -**v3.0** - -| Threads | QPS | 95% latency(ms) | -| :------- | :-------- | :-------------- | -| 150 | 105692.08 | 35.59 | -| 300 | 129769.69 | 58.92 | -| 600 | 141430.86 | 114.72 | -| 900 | 144371.76 | 170.48 | -| 1200 | 143344.37 | 223.34 | -| 1500 | 144567.91 | 277.21 | - -![read write](/media/sysbench_v4_read_write.png) diff --git a/dev/benchmark/sysbench.md b/dev/benchmark/sysbench.md deleted file mode 100644 index 41c6f79e10e0..000000000000 --- a/dev/benchmark/sysbench.md +++ /dev/null @@ -1,210 +0,0 @@ ---- -title: TiDB Sysbench 性能测试报告 - v1.0.0 -category: benchmark -draft: true ---- - -# TiDB Sysbench 性能测试报告 - v1.0.0 - -## 测试目的 - -测试 TiDB 在 OLTP 场景下的性能以及水平扩展能力。 - -> **注意：** -> -> 不同的测试环境可能使测试结果发生改变。 - -## 测试版本、时间、地点 - -TiDB 版本：v1.0.0 -时间：2017 年 10 月 20 日 -地点：北京 - -## 测试环境 - -IDC 机器 - -| 类别 | 名称 | -| :--------: | :---------: | -| OS | linux (CentOS 7.3.1611) | -| CPU | 40 vCPUs, Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz | -| RAM | 128GB | -| DISK | 1.5T SSD \* 2 + Optane SSD \* 1 | - -Sysbench 版本: 1.0.6 - -测试脚本: - -## 测试方案 - -### 场景一：sysbench 标准性能测试 - -测试表结构 - -``` -CREATE TABLE `sbtest` ( - `id` int(10) unsigned NOT NULL AUTO_INCREMENT, - `k` int(10) unsigned NOT NULL DEFAULT '0', - `c` char(120) NOT NULL DEFAULT '', - `pad` char(60) NOT NULL DEFAULT '', - PRIMARY KEY (`id`), - KEY `k_1` (`k`) -) ENGINE=InnoDB -``` - -部署方案以及配置参数 - -``` -// TiDB 部署方案 -172.16.20.4 4*tikv 1*tidb 1*sysbench -172.16.20.6 4*tikv 1*tidb 1*sysbench -172.16.20.7 4*tikv 1*tidb 1*sysbench -172.16.10.8 1*tidb 1*pd 1*sysbench - -// 每个物理节点有三块盘： -data3: 2 tikv (Optane SSD) -data2: 1 tikv -data1: 1 tikv - -// TiKV 参数配置 -sync-log = false -grpc-concurrency = 8 -grpc-raft-conn-num = 24 -[defaultcf] -block-cache-size = "12GB" -[writecf] -block-cache-size = "5GB" -[raftdb.defaultcf] -block-cache-size = "2GB" - -// Mysql 部署方案 -// 分别使用半同步复制和异步复制，部署两副本 -172.16.20.4 master -172.16.20.6 slave -172.16.20.7 slave -172.16.10.8 1*sysbench -Mysql version: 5.6.37 - -// Mysql 参数配置 -thread_cache_size = 64 -innodb_buffer_pool_size = 64G -innodb_file_per_table = 1 -innodb_flush_log_at_trx_commit = 0 -datadir = /data3/mysql -max_connections = 2000 -``` - -* 标准 oltp 测试 - -| - | table count | table size | sysbench threads | tps | qps | latency(avg / .95) | -| :---: | :---: | :---: | :---: | :---: | :---: | :---: | -| TiDB | 32 | 100 万 | 64 * 4 | 3834 | 76692 | 67.04 ms / 110.88 ms | -| TiDB | 32 | 100 万 | 128 * 4 | 4172 | 83459 | 124.00 ms / 194.21 ms | -| TiDB | 32 | 100 万 | 256 * 4 | 4577 | 91547 | 228.36 ms / 334.02 ms | -| TiDB | 32 | 500 万 | 256 * 4 | 4032 | 80657 | 256.62 ms / 443.88 ms | -| TiDB | 32 | 1000 万 | 256 * 4 | 3811 | 76233 | 269.46 ms / 505.20 ms | -| Mysql | 32 | 100 万 | 64 | 2392 | 47845 | 26.75 ms / 73.13 ms | -| Mysql | 32 | 100 万 | 128 | 2493 | 49874 | 51.32 ms / 173.58 ms | -| Mysql | 32 | 100 万 | 256 | 2561 | 51221 | 99.95 ms / 287.38 ms | -| Mysql | 32 | 500 万 | 256 | 1902 | 38045 | 134.56 ms / 363.18 ms | -| Mysql | 32 | 1000 万 | 256 | 1770 | 35416 | 144.55 ms / 383.33 ms | - -![sysbench-01](/media/sysbench-01.png) - -![sysbench-02](/media/sysbench-02.png) - -* 标准 select 测试 - -| - | table count | table size | sysbench threads |qps | latency(avg / .95) | -| :---: | :---: | :---: | :---: | :---: | :---: | -| TiDB | 32 | 100 万 | 64 * 4 | 160299 | 1.61ms / 50.06 ms | -| TiDB | 32 | 100 万 | 128 * 4 | 183347 | 2.85 ms / 8.66 ms | -| TiDB | 32 | 100 万 | 256 * 4 | 196515 | 5.42 ms / 14.43 ms | -| TiDB | 32 | 500 万 | 256 * 4 | 187628 | 5.66 ms / 15.04 ms | -| TiDB | 32 | 1000 万 | 256 * 4 | 187440 | 5.65 ms / 15.37 ms | -| Mysql | 32 | 100 万 | 64 | 359572 | 0.18 ms / 0.45 ms | -| Mysql | 32 | 100 万 | 128 | 410426 |0.31 ms / 0.74 ms | -| Mysql | 32 | 100 万 | 256 | 396867 | 0.64 ms / 1.58 ms | -| Mysql | 32 | 500 万 | 256 | 386866 | 0.66 ms / 1.64 ms | -| Mysql | 32 | 1000 万 | 256 | 388273 | 0.66 ms / 1.64 ms | - -![sysbench-03](/media/sysbench-03.png) - -![sysbench-04](/media/sysbench-04.png) - -* 标准 insert 测试 - -| - | table count | table size | sysbench threads | qps | latency(avg / .95) | -| :---: | :---: | :---: | :---: | :---: | :---: | -| TiDB | 32 | 100 万 | 64 * 4 | 25308 | 10.12 ms / 25.40 ms | -| TiDB | 32 | 100 万 | 128 * 4 | 28773 | 17.80 ms / 44.58 ms | -| TiDB | 32 | 100 万 | 256 * 4 | 32641 | 31.38 ms / 73.47 ms | -| TiDB | 32 | 500 万 | 256 * 4 | 30430 | 33.65 ms / 79.32 ms | -| TiDB | 32 | 1000 万 | 256 * 4 | 28925 | 35.41 ms / 78.96 ms | -| Mysql | 32 | 100 万 | 64 | 14806 | 4.32 ms / 9.39 ms | -| Mysql | 32 | 100 万 | 128 | 14884 | 8.58 ms / 21.11 ms | -| Mysql | 32 | 100 万 | 256 | 14508 | 17.64 ms / 44.98 ms | -| Mysql | 32 | 500 万 | 256 | 10593 | 24.16 ms / 82.96 ms | -| Mysql | 32 | 1000 万 | 256 | 9813 | 26.08 ms / 94.10 ms | - -![sysbench-05](/media/sysbench-05.png) - -![sysbench-06](/media/sysbench-06.png) - -### 场景二：TiDB 水平扩展能力测试 - -部署方案以及配置参数 - -``` -// TiDB 部署方案 -172.16.20.3 4*tikv -172.16.10.2 1*tidb 1*pd 1*sysbench - -每个物理节点有三块盘： -data3: 2 tikv (Optane SSD) -data2: 1 tikv -data1: 1 tikv - -// TiKV 参数配置 -sync-log = false -grpc-concurrency = 8 -grpc-raft-conn-num = 24 -[defaultcf] -block-cache-size = "12GB" -[writecf] -block-cache-size = "5GB" -[raftdb.defaultcf] -block-cache-size = "2GB" -``` - -* 标准 oltp 测试 - -| - | table count | table size | sysbench threads | tps | qps | latency(avg / .95) | -| :---: | :---: | :---: | :---: | :---: | :---: | :---: | -| 1 物理节点 TiDB | 32 | 100 万 | 256 * 1 | 2495 | 49902 | 102.42 ms / 125.52 ms | -| 2 物理节点 TiDB | 32 | 100 万 | 256 * 2 | 5007 | 100153 | 102.23 ms / 125.52 ms | -| 4 物理节点 TiDB | 32 | 100 万 | 256 * 4 | 8984 | 179692 | 114.96 ms / 176.73 ms | -| 6 物理节点 TiDB | 32 | 500 万 | 256 * 6 | 12953 | 259072 | 117.80 ms / 200.47 ms | - -![sysbench-07](/media/sysbench-07.png) - -* 标准 select 测试 - -| - | table count | table size | sysbench threads | qps | latency(avg / .95) | -| :---: | :---: | :---: | :---: | :---: | :---: | -| 1 物理节点 TiDB | 32 | 100 万 | 256 * 1 | 71841 | 3.56 ms / 8.74 ms | -| 2 物理节点 TiDB | 32 | 100 万 | 256 * 2 | 146615 | 3.49 ms / 8.74 ms | -| 4 物理节点 TiDB | 32 | 100 万 | 256 * 4 | 289933 | 3.53 ms / 8.74 ms | -| 6 物理节点 TiDB | 32 | 500 万 | 256 * 6 | 435313 | 3.55 ms / 9.17 ms | - -![sysbench-08](/media/sysbench-08.png) - -* 标准 insert 测试 - -| - | table count | table size | sysbench threads | qps | latency(avg / .95) | -| :---: | :---: | :---: | :---: | :---: | :---: | -| 3 物理节点 TiKV | 32 | 100 万 |256 * 3 | 40547 | 18.93 ms / 38.25 ms | -| 5 物理节点 TiKV | 32 | 100 万 | 256 * 3 | 60689 | 37.96 ms / 29.9 ms | -| 7 物理节点 TiKV | 32 | 100 万 | 256 * 3 | 80087 | 9.62 ms / 21.37 ms | - -![sysbench-09](/media/sysbench-09.png) diff --git a/dev/benchmark/tpch-v2.md b/dev/benchmark/tpch-v2.md deleted file mode 100644 index 688a9d0a7e26..000000000000 --- a/dev/benchmark/tpch-v2.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -title: TiDB TPC-H 50G 性能测试报告 -category: benchmark ---- - -# TiDB TPC-H 50G 性能测试报告 - -## 测试目的 - -测试 TiDB 在 OLAP 场景下 2.0 和 2.1 版本的性能对比。 - -> **注意：** -> -> 不同的测试环境可能使测试结果发生改变。 - -## 测试环境 - -### 测试机器信息 - -1. 系统信息 - - | 机器 IP | 操作系统 | 内核版本 | 文件系统类型 | - |--------------|------------------------|------------------------------|--------------| - | 10.0.1.4 | CentOS 7.5.1804 64bit | 3.10.0-862.3.3.el7.x86\_64 | ext4 | - | 10.0.1.5 | CentOS 7.5.1804 64bit | 3.10.0-862.3.3.el7.x86\_64 | ext4 | - | 10.0.1.6 | CentOS 7.5.1804 64bit | 3.10.0-862.3.3.el7.x86\_64 | ext4 | - | 10.0.1.7 | CentOS 7.5.1804 64bit | 3.10.0-862.3.3.el7.x86\_64 | ext4 | - | 10.0.1.8 | CentOS 7.5.1804 64bit | 3.10.0-862.3.3.el7.x86\_64 | ext4 | - | 10.0.1.9 | CentOS 7.5.1804 64bit | 3.10.0-862.3.3.el7.x86\_64 | ext4 | - -2. 硬件信息 - - | 类别 | 10.0.1.4 | 10.0.1.5, 10.0.1.6, 10.0.1.7, 10.0.1.8, 10.0.1.9 | - |------------|------------------------------------------------------|------------------------------------------------------| - | CPU | 16 vCPUs, Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz | 8 vCPUs, Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz | - | 内存 | 110G | 55G | - | 磁盘 | 221G SSD | 111G SSD | - | 网卡 | 万兆网卡, 10000Mb/s | 万兆网卡, 10000Mb/s | - -### TPC-H - -[tidb-bench/tpch](https://github.com/pingcap/tidb-bench/tree/master/tpch) - -### 集群拓扑 - -| 机器 IP | 部署的实例 | -|----------|------------| -| 10.0.1.5 | TiKV \* 1 | -| 10.0.1.6 | TiKV \* 1 | -| 10.0.1.7 | TiKV \* 1 | -| 10.0.1.8 | TiKV \* 1 | -| 10.0.1.9 | TiKV \* 1 | -| 10.0.1.4 | PD \* 1 | -| 10.0.1.4 | TiDB \* 1 | - -### TiDB 版本信息 - -TiDB 2.0： - -| 组件名 | 版本号 | commit hash | -|--------|-------------|--------------------------------------------| -| TiDB | v2.0.7 | 29ec059cb3b7d14b6f52c2f219f94a89570162bc | -| TiKV | v2.0.7 | d0b8cd7c7f62f06e7ef456837bd32a47da1ca4cd | -| PD | v2.0.5 | b64716707b7279a4ae822be767085ff17b5f3fea | - -TiDB 2.1： - -| 组件名 | 版本号 | commit hash | -|--------|-------------|--------------------------------------------| -| TiDB | v2.1.0-rc.2 | 16864f95b47f859ed6104555ccff0387abdc2429 | -| TiKV | v2.1.0-rc.2 | 8458ce53ebbd434c48baac6373fe0f0a43a54005 | -| PD | v2.1.0-rc.2 | 55db505e8f35e8ab4e00efd202beb27a8ecc40fb | - -## 测试结果 - -| Query ID | TiDB 2.0 | TiDB 2.1 | -|-----------|----------------|----------------| -| 1 | 121.550595999s | 91.4755480289s | -| 2 | 53.0638680458s | 23.1186130047s | -| 3 | 75.7236940861s | 61.790802002s | -| 4 | 30.2647120953s | 26.3483440876s | -| 6 | 51.4850790501s | 34.6432199478s | -| 7 | 216.787364006s | 94.9856910706s | -| 8 | 188.717588902s | 181.852752209s | -| 9 | 546.438174009s | 414.462754965s | -| 10 | 109.978317022s | 37.0369961262s | -| 11 | 42.9398438931s | 37.6951580048s | -| 12 | 60.455039978s | 40.2236878872s | -| 13 | 230.278712988s | 70.2887151241s | -| 14 | 61.2673521042s | 35.8372960091s | -| 16 | 30.2539310455s | 18.5897550583s | -| 17 | 3200.70173788s | 263.095014811s | -| 18 | 1035.59847498s | 296.360667944s | -| 19 | 54.3732938766s | 40.4523630142s | -| 20 | 105.094577074s | 53.2429068089s | -| 21 | 389.883709908s | 361.034544945s | -| 22 | 64.0494630337s | 65.7153418064s | - -![TPC-H Query Result](/media/tpch-query-result-v2.png) - -说明： - -- 图中橙色为 Release 2.1，蓝色为 Release 2.0，纵坐标是 Query 的处理时间，越低越好 -- Query 15 因为 2.1 和 2.0 都还未支持视图，所以未列出结果 -- Query 5 因为 Join Order 问题长时间未跑出结果来，所以未列出结果 diff --git a/dev/benchmark/tpch.md b/dev/benchmark/tpch.md deleted file mode 100644 index 3852e4774adc..000000000000 --- a/dev/benchmark/tpch.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -title: TiDB TPC-H 50G 性能测试报告 -category: benchmark ---- - -# TiDB TPC-H 50G 性能测试报告 - -## 测试目的 - -测试 TiDB 在 OLAP 场景下 1.0 和 2.0 版本的性能对比。 - -> **注意：** -> -> 不同的测试环境可能使测试结果发生改变。 - -## 测试环境 - -### 测试机器信息 - -1. 系统信息 - - | 机器 IP | 操作系统 | 内核版本 | 文件系统类型 | - |--------------|------------------------|------------------------------|--------------| - | 172.16.31.2 | Ubuntu 17.10 64bit | 4.13.0-16-generic | ext4 | - | 172.16.31.3 | Ubuntu 17.10 64bit | 4.13.0-16-generic | ext4 | - | 172.16.31.4 | Ubuntu 17.10 64bit | 4.13.0-16-generic | ext4 | - | 172.16.31.6 | CentOS 7.4.1708 64bit | 3.10.0-693.11.6.el7.x86\_64 | ext4 | - | 172.16.31.8 | CentOS 7.4.1708 64bit | 3.10.0-693.11.6.el7.x86\_64 | ext4 | - | 172.16.31.10 | CentOS 7.4.1708 64bit | 3.10.0-693.11.6.el7.x86\_64 | ext4 | - -2. 硬件信息 - - | 类别 | 名称 | - |------------|------------------------------------------------------| - | CPU | 40 vCPUs, Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz | - | 内存 | 128GB, 8条16GB RDIMM, 2400MT/s, 双列, x8 带宽 | - | 磁盘 | 2 块 Intel P4500 系列 4T SSD 硬盘 | - | 网卡 | 万兆网卡 | - -### TPC-H - -[tidb-bench/tpch](https://github.com/pingcap/tidb-bench/tree/master/tpch) - -### 集群拓扑 - -| 机器 IP | 部署的实例 | -|--------------|------------| -| 172.16.31.2 | TiKV \* 2 | -| 172.16.31.3 | TiKV \* 2 | -| 172.16.31.6 | TiKV \* 2 | -| 172.16.31.8 | TiKV \* 2 | -| 172.16.31.10 | TiKV \* 2 | -| 172.16.31.10 | PD \* 1 | -| 172.16.31.4 | TiDB \* 1 | - -### TiDB 版本信息 - -TiDB 1.0： - -| 组件名 | 版本号 | commit hash | -|--------|-------------|--------------------------------------------| -| TiDB | v1.0.9 | 4c7ee3580cd0a69319b2c0c08abdc59900df7344 | -| TiKV | v1.0.8 | 2bb923a4cd23dbf68f0d16169fd526dc5c1a9f4a | -| PD | v1.0.8 | 137fa734472a76c509fbfd9cb9bc6d0dc804a3b7 | - -TiDB 2.0： - -| 组件名 | 版本号 | commit hash | -|--------|-------------|--------------------------------------------| -| TiDB | v2.0.0-rc.6 | 82d35f1b7f9047c478f4e1e82aa0002abc8107e7 | -| TiKV | v2.0.0-rc.6 | 8bd5c54966c6ef42578a27519bce4915c5b0c81f | -| PD | v2.0.0-rc.6 | 9b824d288126173a61ce7d51a71fc4cb12360201 | - -## 测试结果 - -| Query ID | TiDB 2.0 | TiDB 1.0 | -|-----------|--------------------|------------------| -| 1 | 33.915s | 215.305s | -| 2 | 25.575s | NaN | -| 3 | 59.631s | 196.003s | -| 4 | 30.234s | 249.919s | -| 5 | 31.666s | OOM | -| 6 | 13.111s | 118.709s | -| 7 | 31.710s | OOM | -| 8 | 31.734s | 800.546s | -| 9 | 34.211s | 630.639s | -| 10 | 30.774s | 133.547s | -| 11 | 27.692s | 78.026s | -| 12 | 27.962s | 124.641s | -| 13 | 27.676s | 174.695s | -| 14 | 19.676s | 110.602s | -| 15 | View Required | View Required | -| 16 | 24.890s | 40.529s | -| 17 | 245.796s | NaN | -| 18 | 91.256s | OOM | -| 19 | 37.615s | NaN | -| 20 | 44.167s | 212.201s | -| 21 | 31.466s | OOM | -| 22 | 31.539s | 125.471s | - -![TPC-H Query Result](/media/tpch-query-result.png) - -说明： - -- 图中橙色为 Release 1.0，蓝色为 Release 2.0，纵坐标是 Query 的处理时间，越低越好 -- Query 15 因为 1.0 和 2.0 都还未支持视图，所以结果标记为 "View Required" -- Query 2, 17, 19 因为 TiDB 1.0 长时间未跑出结果，所以结果标记为 "Nan" -- Query 5, 7, 18, 21 因为 TiDB 1.0 在跑的过程中内存占用过多被 oom-killer 杀死，所以结果标记为 "OOM" diff --git a/dev/contribute.md b/dev/contribute.md deleted file mode 100644 index 9747814f9cc9..000000000000 --- a/dev/contribute.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: 成为贡献者 -category: contribute ---- - -# 成为贡献者 - -## 成为 TiDB 的贡献者 - -我们推荐您先尝试解决带 [help-wanted](https://github.com/pingcap/tidb/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) 标签的现有 Issue，这些问题非常适合新的贡献者。 - -一旦您提交给 [TiDB/TiKV/TiSpark/PD/TiDB Operator/Docs/Docs-cn](https://github.com/pingcap) 项目的 PR (Pull Request) 被批准且合并，您即成为 TiDB 的贡献者。 - -在提交 PR 之前，请先签署 [CLA](https://cla-assistant.io/pingcap/tidb?pullRequest=5567)。 - -如果您想实践一个影响范围相对较小的新想法，请遵循以下步骤： - -1. 提交新 Issue，描述您对相关仓库的更改建议。 -2. 相关仓库的负责人将及时回复您的 Issue。 -3. 如果您的更改建议被接受，您需要先签署 [CLA](https://cla-assistant.io/pingcap/tidb?pullRequest=5567)，便可以在您的克隆仓库 (fork) 里开始工作了。 -4. 在测试过所做的更改后，您便可以提交[包含更改的 PR](https://github.com/pingcap/tidb/pull/3113) 了。 - -我们欢迎并非常感谢您的贡献。有关提交补丁和贡献流程的详细信息，请参阅[贡献者指南](https://github.com/pingcap/tidb/blob/master/CONTRIBUTING.md)。 - -## 改进文档 - -我们欢迎更多贡献者来帮助改进文档！ - -TiDB 文档使用 Markdown 语言，并参考了 [Google 开发者文档风格指南](https://developers.google.com/style/)进行编写。如果这些概念对您来说比较陌生，请不要担心，我们很乐意为您提供指导。 - -如要对文档仓库进行贡献，请先 fork [docs-cn 仓库](https://github.com/pingcap/docs-cn)，再提交您的 PR。 diff --git a/dev/faq/tidb-lightning.md b/dev/faq/tidb-lightning.md deleted file mode 100644 index 1e6b7ac7ad94..000000000000 --- a/dev/faq/tidb-lightning.md +++ /dev/null @@ -1,190 +0,0 @@ ---- -title: TiDB Lightning 常见问题 -category: FAQ ---- - -# TiDB Lightning 常见问题 - -本文列出了一些使用 TiDB Lightning 时可能会遇到的问题与解决办法。 - ->**注意：** -> -> 使用 TiDB Lightning 的过程中如遇错误，参考 [TiDB Lightning 故障诊断](/dev/how-to/troubleshoot/tidb-lightning.md)进行排查。 - -## TiDB Lightning 对 TiDB/TiKV/PD 的最低版本要求是多少？ - -TiDB Lightning 的版本应与集群相同。最低版本要求是 2.0.9，但建议使用最新的稳定版本 3.0。 - -## TiDB Lightning 支持导入多个库吗？ - -支持。 - -## TiDB Lightning 对下游数据库的账号权限要求是怎样的？ - -TiDB Lightning 需要以下权限： - -* SELECT -* UPDATE -* ALTER -* CREATE -* DROP - -如果选择 [TiDB-backend](/dev/reference/tools/tidb-lightning/tidb-backend.md) 模式，或目标数据库用于存储断点，则 TiBD Lightning 额外需要以下权限： - -* INSERT -* DELETE - -+Importer-backend 无需以上两个权限，因为数据直接被 Ingest 到 TiKV 中，所以绕过了 TiDB 的权限系统。只要 TiKV、TiKV Importer 和 TiDB Lightning 的端口在集群之外不可访问，就可以保证安全。 - -如果 TiDB Lightning 配置项 `checksum = true`，则 TiDB Lightning 需要有下游 TiDB admin 用户权限。 - -## TiDB Lightning 在导数据过程中某个表报错了，会影响其他表吗？进程会马上退出吗？ - -如果只是个别表报错，不会影响整体。报错的那个表会停止处理，继续处理其他的表。 - -## 如何正确重启 TiDB Lightning？ - -根据 `tikv-importer` 的状态，重启 TiDB Lightning 的基本顺序如下： - -如果 `tikv-importer` 仍在运行： - -1. [结束 `tidb-lightning` 进程](#如何正确结束-tidb-lightning-进程)。 -2. 执行修改操作（如修复数据源、更改设置、更换硬件等）。 -3. 如果上面的修改操作更改了任何表，你还需要[清除对应的断点](/dev/reference/tools/tidb-lightning/checkpoints.md#--checkpoint-remove)。 -4. 重启 `tidb-lightning`。 - -如果 `tikv-importer` 需要重启： - -1. [结束 `tidb-lightning` 进程](#如何正确结束-tidb-lightning-进程)。 -2. [结束 `tikv-importer` 进程](#如何正确结束-tikv-importer-进程)。 -3. 执行修改操作（如修复数据源、更改设置、更换硬件等）。 -4. 重启 `tikv-importer`。 -5. 重启 `tidb-lightning` 并等待，**直到程序因校验和错误（如果有的话）而失败**。 - * 重启 `tikv-importer` 将清除所有仍在写入的引擎文件，但是 `tidb-lightning` 并不会感知到该操作。从 v3.0 开始，最简单的方法是让 `tidb-lightning` 继续，然后再重试。 -6. [清除失败的表及断点](/dev/how-to/troubleshoot/tidb-lightning.md#checkpoint-for--has-invalid-status错误码)。 -7. 再次重启 `tidb-lightning`。 - -## 如何校验导入的数据的正确性？ - -TiDB Lightning 默认会对导入数据计算校验和 (checksum)，如果校验和不一致就会停止导入该表。可以在日志看到相关的信息。 - -TiDB 也支持从 MySQL 命令行运行 `ADMIN CHECKSUM TABLE` 指令来计算校验和。 - -{{< copyable "sql" >}} - -```sql -ADMIN CHECKSUM TABLE `schema`.`table`; -``` - -``` -+---------+------------+---------------------+-----------+-------------+ -| Db_name | Table_name | Checksum_crc64_xor | Total_kvs | Total_bytes | -+---------+------------+---------------------+-----------+-------------+ -| schema | table | 5505282386844578743 | 3 | 96 | -+---------+------------+---------------------+-----------+-------------+ -1 row in set (0.01 sec) -``` - -## TiDB Lightning 支持哪些格式的数据源？ - -TiDB Lightning 只支持两种格式的数据源： - -1. [Mydumper](/dev/reference/tools/mydumper.md) 生成的 SQL dump -2. 储存在本地文件系统的 [CSV](/dev/reference/tools/tidb-lightning/csv.md) 文件 - -## 我已经在下游创建好库和表了，TiDB Lightning 可以忽略建库建表操作吗？ - -可以。在配置文档中的 `[mydumper]` 部分将 `no-schema` 设置为 `true` 即可。`no-schema=true` 会默认下游已经创建好所需的数据库和表，如果没有创建，会报错。 - -## 有些不合法的数据，能否通过关掉严格 SQL 模式 (Strict SQL Mode) 来导入？ - -可以。Lightning 默认的 [`sql_mode`](https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html) 为 `"STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"`。 - -这个设置不允许一些非法的数值，例如 `1970-00-00` 这样的日期。可以修改配置文件 `[tidb]` 下的 `sql-mode` 值。 - -```toml -... -[tidb] -sql-mode = "" -... -``` - -## 可以启用一个 `tikv-importer`，同时有多个 `tidb-lightning` 进程导入数据吗？ - -只要每个 Lightning 操作的表互不相同就可以。 - -## 如何正确结束 `tikv-importer` 进程？ - -根据部署方式，选择相应操作结束进程 - -- 使用 TiDB Ansible 部署：在 Importer 的服务器上运行 `scripts/stop_importer.sh`。 - -- 手动部署：如果 `tikv-importer` 正在前台运行，可直接按 Ctrl+C 退出。否则，可通过 `ps aux | grep tikv-importer` 获取进程 ID，然后通过 `kill «pid»` 结束进程。 - -## 如何正确结束 `tidb-lightning` 进程？ - -根据部署方式，选择相应操作结束进程 - -- 使用 TiDB Ansible 部署：在 Lightning 的服务器上运行 `scripts/stop_lightning.sh`。 - -- 手动部署：如果 `tidb-lightning` 正在前台运行，可直接按 Ctrl+C 退出。否则，可通过 `ps aux | grep tidb-lightning` 获取进程 ID，然后通过 `kill -2 «pid»` 结束进程。 - -## `tidb-lightning` 在服务器上运行，进程莫名其妙地退出了，是怎么回事呢？ - -这种情况可能是启动方式不正确，导致收到 SIGHUP 信号而退出。此时 `tidb-lightning.log` 通常有如下日志： - -``` -[2018/08/10 07:29:08.310 +08:00] [INFO] [main.go:41] ["got signal to exit"] [signal=hangup] -``` - -不推荐在命令行中直接使用 `nohup` 启动进程，推荐[使用脚本启动 `tidb-lightning`](/dev/reference/tools/tidb-lightning/deployment.md)。 - -## 为什么用过 TiDB Lightning 之后，TiDB 集群变得又慢又耗 CPU？ - -如果 `tidb-lightning` 曾经异常退出，集群可能仍留在“导入模式” (import mode)，不适合在生产环境工作。此时需要强制切换回“普通模式” (normal mode)： - -{{< copyable "shell-regular" >}} - -```sh -tidb-lightning-ctl --switch-mode=normal -``` - -## TiDB Lightning 可以使用千兆网卡吗？ - -使用 TiDB Lightning 建议配置万兆网卡。**不推荐**使用千兆网卡，尤其是在部署 `tikv-importer` 的机器上。 - -千兆网卡的总带宽只有 120 MB/s，而且需要与整个 TiKV 集群共享。在使用 TiDB Lightning 导入时，极易用尽所有带宽，继而因 PD 无法联络集群使集群断连。为了避免这种情况，你可以在 [`tikv-importer` 的配置文件](/dev/reference/tools/tidb-lightning/config.md#tikv-importer-配置参数)中**限制上传速度**。 - -```toml -[import] -# Importer 上传至 TiKV 的最大速度（字节/秒）。 -# 建议将该速度设为 100 MB/s 或更小。 -upload-speed-limit = "100MB" -``` - -## 为什么 TiDB Lightning 需要在 TiKV 集群预留这么多空间？ - -当使用默认的 3 副本设置时，TiDB Lightning 需要 TiKV 集群预留数据源大小 6 倍的空间。多出来的 2 倍是算上下列没储存在数据源的因素的保守估计： - -- 索引会占据额外的空间 -- RocksDB 的空间放大效应 - -## TiDB Lightning 使用过程中是否可以重启 TiKV Importer？ - -不能，Importer 会在内存中存储一些引擎文件，Importer 重启后，`tidb-lightning` 会因连接失败而停止。此时，你需要[清除失败的断点](/dev/reference/tools/tidb-lightning/checkpoints.md#--checkpoint-error-destroy)，因为这些 Importer 特有的信息丢失了。你可以在之后[重启 Lightning](#如何正确重启-tidb-lightning)。 - -## 如何清除所有与 TiDB Lightning 相关的中间数据？ - -1. 删除断点文件。 - - {{< copyable "shell-regular" >}} - - ```sh - tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-remove=all - ``` - - 如果出于某些原因而无法运行该命令，你可以尝试手动删除 `/tmp/tidb_lightning_checkpoint.pb` 文件。 - -2. 删除 `tikv-importer` 所在机器上的整个 “import” 文件目录。 - -3. 如果需要的话，删除 TiDB 集群上创建的所有表和库。 diff --git a/dev/faq/tidb.md b/dev/faq/tidb.md deleted file mode 100755 index 69658c01255a..000000000000 --- a/dev/faq/tidb.md +++ /dev/null @@ -1,1082 +0,0 @@ ---- -title: TiDB FAQ -category: FAQ ---- - -# FAQ - -## 一、 TiDB 介绍、架构、原理 - -### 1.1 TiDB 介绍及整体架构 - -#### 1.1.1 TiDB 整体架构 - -[TiDB 简介](/dev/overview.md#tidb-简介) - -#### 1.1.2 TiDB 是什么？ - -TiDB 是一个分布式 NewSQL 数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。 - -#### 1.1.3 TiDB 是基于 MySQL 开发的吗？ - -不是，虽然 TiDB 支持 MySQL 语法和协议，但是 TiDB 是由 PingCAP 团队完全自主开发的产品。 - -#### 1.1.4 TiDB、TiKV、Placement Driver (PD) 主要作用？ - -- TiDB 是 Server 计算层，主要负责 SQL 的解析、制定查询计划、生成执行器。 -- TiKV 是分布式 Key-Value 存储引擎，用来存储真正的数据，简而言之，TiKV 是 TiDB 的存储引擎。 -- PD 是 TiDB 集群的管理组件，负责存储 TiKV 的元数据，同时也负责分配时间戳以及对 TiKV 做负载均衡调度。 - -#### 1.1.5 TiDB 易用性如何？ - -TiDB 使用起来很简单，可以将 TiDB 集群当成 MySQL 来用，你可以将 TiDB 用在任何以 MySQL 作为后台存储服务的应用中，并且基本上不需要修改应用代码，同时你可以用大部分流行的 MySQL 管理工具来管理 TiDB。 - -#### 1.1.6 TiDB 和 MySQL 兼容性如何？ - -TiDB 目前还不支持触发器、存储过程、自定义函数、外键，除此之外，TiDB 支持绝大部分 MySQL 5.7 的语法。 - -详情参见[与 MySQL 兼容性对比](/dev/reference/mysql-compatibility.md)。 - -#### 1.1.7 TiDB 具备高可用的特性吗？ - -TiDB 天然具备高可用特性，TiDB、TiKV、PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。具体见 [TiDB 高可用性](/dev/key-features.md#高可用)。 - -#### 1.1.8 TiDB 数据是强一致的吗？ - -TiDB 实现了快照隔离 (Snapshot Isolation) 级别的一致性。为与 MySQL 保持一致，又称其为“可重复读”。通过使用 [Raft 一致性算法](https://raft.github.io/)，数据在各 TiKV 节点间复制为多副本，以确保某个节点挂掉时数据的安全性。 - -在底层，TiKV 使用复制日志 + 状态机 (State Machine) 的模型来复制数据。对于写入请求，数据被写入 Leader，然后 Leader 以日志的形式将命令复制到它的 Follower 中。当集群中的大多数节点收到此日志时，日志会被提交，状态机会相应作出变更。 - -#### 1.1.9 TiDB 支持分布式事务吗？ - -支持。无论是一个地方的几个节点，还是[跨多个数据中心的多个节点](/dev/how-to/deploy/geographic-redundancy/overview.md)，TiDB 均支持 ACID 分布式事务。 - -TiDB 事务模型灵感源自 Google Percolator 模型，主体是一个两阶段提交协议，并进行了一些实用的优化。该模型依赖于一个时间戳分配器，为每个事务分配单调递增的时间戳，这样就检测到事务冲突。在 TiDB 集群中，[PD](/dev/architecture.md#pd-server) 承担时间戳分配器的角色。 - -#### 1.1.10 TiDB 支持哪些编程语言？ - -只要支持 MySQL Client/Driver 的编程语言，都可以直接使用 TiDB。 - -#### 1.1.11 TiDB 是否支持其他存储引擎？ - -是的，除了 TiKV 之外，TiDB 还支持一些流行的单机存储引擎，比如 GolevelDB、RocksDB、BoltDB 等。如果一个存储引擎是支持事务的 KV 引擎，并且能提供一个满足 TiDB 接口要求的 Client，即可接入 TiDB。 - -#### 1.1.12 官方有没有三中心跨机房多活部署的推荐方案？ - -从 TiDB 架构来讲，支持真正意义上的跨中心异地多活，从操作层面讲，依赖数据中心之间的网络延迟和稳定性，一般建议延迟在 5ms 以下，目前我们已经有相似客户方案，具体请咨询官方 [info@pingcap.com](mailto:info@pingcap.com)。 - -#### 1.1.13 除了官方文档，有没有其他 TiDB 知识获取途径？ - -目前[官方文档](/dev/overview.md#tidb-简介)是获取 TiDB 相关知识最主要、最及时的发布途径。除此之外，我们也有一些技术沟通群，如有需求可发邮件至 [info@pingcap.com](mailto:info@pingcap.com) 获取。 - -#### 1.1.14 TiDB 对哪些 MySQL variables 兼容？ - -详细可参考[系统变量](/dev/reference/configuration/tidb-server/mysql-variables.md)。 - -#### 1.1.15 TiDB 是否支持 select for update？ - -支持，但语义上和 MySQL 有区别，TiDB 是分布式数据库，采用的乐观锁机制，也就说 select for update 不在事务开启就锁住数据，而是其他事务在提交的时候进行冲突检查，如有冲突，会进行回滚。 - -#### 1.1.16 TiDB 的 codec 能保证 UTF8 的字符串是 memcomparable 的吗？我们的 key 需要支持 UTF8，有什么编码建议吗？ - -TiDB 字符集默认就是 UTF8 而且目前只支持 UTF8，字符串就是 memcomparable 格式的。 - -#### 1.1.17 TiDB 用户名长度限制？ - -在 TiDB 中用户名最长为 32 字符。 - -#### 1.1.18 一个事务中的语句数量最大是多少？ - -一个事务中的语句数量，默认限制最大为 5000 条。 - -#### 1.1.19 TiDB 是否支持 XA？ - -虽然 TiDB 的 JDBC 驱动用的就是 MySQL JDBC（Connector / J），但是当使用 Atomikos 的时候，数据源要配置成类似这样的配置：`type="com.mysql.jdbc.jdbc2.optional.MysqlXADataSource"`。MySQL JDBC XADataSource 连接 TiDB 的模式目前是不支持的。MySQL JDBC 中配置好的 XADataSource 模式，只对 MySQL 数据库起作用（DML 去修改 redo 等）。 - -Atomikos 配好两个数据源后，JDBC 驱动都要设置成 XA 模式，然后 Atomikos 在操作 TM 和 RM（DB）的时候，会通过数据源的配置，发起带有 XA 指令到 JDBC 层，JDBC 层 XA 模式启用的情况下，会对 InnoDB（如果是 MySQL 的话）下发操作一连串 XA 逻辑的动作，包括 DML 去变更 redo log 等，就是两阶段递交的那些操作。TiDB 目前的引擎版本中，没有对上层应用层 JTA / XA 的支持，不解析这些 Atomikos 发过来的 XA 类型的操作。 - -MySQL 是单机数据库，只能通过 XA 来满足跨数据库事务，而 TiDB 本身就通过 Google 的 Percolator 事务模型支持分布式事务，性能稳定性比 XA 要高出很多，所以不会也不需要支持 XA。 - -#### 1.1.20 show processlist 是否显示系统进程号？ - -TiDB 的 `show processlist` 与 MySQL 的 `show processlist` 显示内容基本一样，不会显示系统进程号，而 ID 表示当前的 session ID。其中 TiDB 的 `show processlist` 和 MySQL 的 `show processlist` 区别如下： - -1）由于 TiDB 是分布式数据库，tidb-server 实例是无状态的 SQL 解析和执行引擎（详情可参考 [TiDB 整体架构](/dev/overview.md#tidb-整体架构)），用户使用 MySQL 客户端登录的是哪个 tidb-server，`show processlist` 就会显示当前连接的这个 tidb-server 中执行的 session 列表，不是整个集群中运行的全部 session 列表；而 MySQL 是单机数据库，`show processlist` 列出的是当前整个 MySQL 数据库的全部执行 SQL 列表。 - -2）TiDB 的 `show processlist` 显示内容比起 MySQL 来讲，多了一个当前 session 使用内存的估算值（单位 Byte）。 - -#### 1.1.21 如何修改用户名密码和权限？ - -TiDB 作为分布式数据库，在 TiDB 中修改用户密码建议使用 `set password for 'root'@'%' = '0101001';` 或 `alter` 方法，不推荐使用 `update mysql.user` 的方法进行，这种方法可能会造成其它节点刷新不及时的情况。修改权限也一样，都建议采用官方的标准语法。详情可参考 [TiDB 用户账户管理](/dev/reference/security/user-account-management.md)。 - -#### 1.1.22 TiDB 中，为什么出现后插入数据的自增 ID 反而小？ - -TiDB 的自增 ID (`AUTO_INCREMENT`) 只保证自增且唯一，并不保证连续分配。TiDB 目前采用批量分配的方式，所以如果在多台 TiDB 上同时插入数据，分配的自增 ID 会不连续。当多个线程并发往不同的 tidb-server 插入数据的时候，有可能会出现后插入的数据自增 ID 小的情况。此外，TiDB允许给整型类型的字段指定 AUTO_INCREMENT，且一个表只允许一个属性为 `AUTO_INCREMENT` 的字段。详情可参考[CREATE TABLE 语法](/dev/reference/mysql-compatibility.md#自增-id)。 - -#### 1.1.23 sql_mode 默认除了通过命令 set 修改，配置文件怎么修改？ - -TiDB 的 sql_mode 与 MySQL 的 sql_mode 设置方法有一些差别，TiDB 不支持配置文件配置设置数据库的 sql\_mode，而只能使用 set 命令去设置，具体方法为：`set @@global.sql_mode = 'STRICT_TRANS_TABLES';`。 - -#### 1.1.24 TiDB 支持哪些认证协议，过程是怎样的？ - -这一层跟 MySQL 一样，走的 SASL 认证协议，用于用户登录认证，对密码的处理流程。 - -客户端连接 TiDB 的时候，走的是 challenge-response（挑战-应答）的认证模式，过程如下： - -第一步：客户端连接服务器； - -第二步：服务器发送随机字符串 challenge 给客户端； - -第三步：客户端发送 username + response 给服务器； - -第四步：服务器验证 response。 - -### 1.2 TiDB 原理 - -#### 1.2.1 存储 TiKV - -##### 1.2.1.1 TiKV 详细解读 - -[三篇文章了解 TiDB 技术内幕 - 说存储](http://t.cn/RTKRRWv) - -#### 1.2.2 计算 TiDB - -##### 1.2.2.1 TiDB 详细解读 - -[三篇文章了解 TiDB 技术内幕 - 说计算](http://t.cn/RTKRkBh) - -#### 1.2.3 调度 PD - -##### 1.2.3.1 PD 详细解读 - -[三篇文章了解 TiDB 技术内幕 - 谈调度](http://t.cn/RTKEZ0U) - -## 二、安装部署升级 - -### 2.1 环境准备 - -#### 2.1.1 操作系统版本要求 - -| **Linux 操作系统平台** | **版本** | -| --- | --- | -| Red Hat Enterprise Linux | 7.3 及以上 | -| CentOS | 7.3 及以上 | -| Oracle Enterprise Linux | 7.3 及以上 | - -##### 2.1.1.1 为什么要在 CentOS 7 上部署 TiDB 集群？ - -TiDB 作为一款开源分布式 NewSQL 数据库，可以很好的部署和运行在 Intel 架构服务器环境及主流虚拟化环境，并支持绝大多数的主流硬件网络，作为一款高性能数据库系统，TiDB 支持主流的 Linux 操作系统环境，具体可以参考 TiDB 的[官方部署要求](/dev/how-to/deploy/hardware-recommendations.md)。其中 TiDB 在 CentOS 7.3 的环境下进行大量的测试，同时也有很多这个操作系统的部署最佳实践，因此，我们推荐客户在部署 TiDB 的时候使用 CentOS 7.3+ 以上的Linux 操作系统。 - -#### 2.1.2 硬件要求 - -TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器平台。对于开发，测试，及生产环境的服务器硬件配置有以下要求和建议： - -##### 2.1.2.1 开发及测试环境 - -| **组件** | **CPU** | **内存** | **本地存储** | **网络** | **实例数量(最低要求)** | -| --- | --- | --- | --- | --- | --- | -| TiDB | 8核+ | 16 GB+ | SAS, 200 GB+ | 千兆网卡 | 1（可与 PD 同机器） | -| PD | 8核+ | 16 GB+ | SAS, 200 GB+ | 千兆网卡 | 1（可与 TiDB 同机器） | -| TiKV | 8核+ | 32 GB+ | SSD, 200 GB+ | 千兆网卡 | 3 | -| | | | | 服务器总计 | 4 | - -##### 2.1.2.2 线上环境 - -| **组件** | **CPU** | **内存** | **硬盘类型** | **网络** | **实例数量(最低要求)** | -| --- | --- | --- | --- | --- | --- | -| TiDB | 16核+ | 48 GB+ | SAS | 万兆网卡（2块最佳） | 2 | -| PD | 8核+ | 16 GB+ | SSD | 万兆网卡（2块最佳） | 3 | -| TiKV | 16核+ | 48 GB+ | SSD | 万兆网卡（2块最佳） | 3 | -| 监控 | 8核+ | 16 GB+ | SAS | 千兆网卡 | 1 | -| | | | | 服务器总计 | 9 | - -##### 2.1.2.3 2 块网卡的目的是？万兆的目的是？ - -作为一个分布式集群，TiDB 对时间的要求还是比较高的，尤其是 PD 需要分发唯一的时间戳，如果 PD 时间不统一，如果有 PD 切换，将会等待更长的时间。2 块网卡可以做 bond，保证数据传输的稳定，万兆可以保证数据传输的速度，千兆网卡容易出现瓶颈，我们强烈建议使用万兆网卡。 - -##### 2.1.2.4 SSD 不做 RAID 是否可行？ - -资源可接受的话，我们建议做 RAID 10，如果资源有限，也可以不做 RAID。 - -##### 2.1.2.5 TiDB 集群各个组件的配置推荐？ - -- TiDB 需要 CPU 和内存比较好的机器，参考官网配置要求，如果后期需要开启 Binlog，根据业务量的评估和 GC 时间的要求，也需要本地磁盘大一点，不要求 SSD 磁盘； -- PD 里面存了集群元信息，会有频繁的读写请求，对磁盘 I/O 要求相对比较高，磁盘太差会影响整个集群性能，推荐 SSD 磁盘，空间不用太大。另外集群 Region 数量越多对 CPU、内存的要求越高； -- TiKV 对 CPU、内存、磁盘要求都比较高，一定要用 SSD 磁盘。 - -详情可参考 [TiDB 软硬件环境需求](/dev/how-to/deploy/hardware-recommendations.md)。 - -### 2.2 安装部署 - -#### 2.2.1 Ansible 部署方式（强烈推荐） - -详细可参考[使用 TiDB Ansible 部署 TiDB 集群](/dev/how-to/deploy/orchestrated/ansible.md)。 - -##### 2.2.1.1 为什么修改了 TiKV/PD 的 toml 配置文件，却没有生效？ - -这种情况一般是因为没有使用 `--config` 参数来指定配置文件（目前只会出现在 binary 部署的场景），TiKV/PD 会按默认值来设置。如果要使用配置文件，请设置 TiKV/PD 的 `--config` 参数。对于 TiKV 组件，修改配置后重启服务即可；对于 PD 组件，只会在第一次启动时读取配置文件，之后可以使用 pd-ctl 的方式来修改配置，详情可参考 [PD 配置参数](/dev/reference/configuration/pd-server/configuration.md)。 - -##### 2.2.1.2 TiDB 监控框架 Prometheus + Grafana 监控机器建议单独还是多台部署？ - -监控机建议单独部署。建议 CPU 8 core，内存 16 GB 以上，硬盘 500 GB 以上。 - -##### 2.2.1.3 有一部分监控信息显示不出来？ - -查看访问监控的机器时间跟集群内机器的时间差，如果比较大，更正时间后即可显示正常。 - -##### 2.2.1.4 supervise/svc/svstat 服务具体起什么作用？ - -- supervise 守护进程 -- svc 启停服务 -- svstat 查看进程状态 - -##### 2.2.1.5 inventory.ini 变量参数解读 - -| **变量** | **含义** | -| --- | --- | -| cluster_name | 集群名称，可调整 | -| tidb_version | TiDB 版本，TiDB Ansible 各分支默认已配置 | -| deployment_method | 部署方式，默认为 binary，可选 docker | -| process_supervision | 进程监管方式，默认为 systemd，可选 supervise | -| timezone | 修改部署目标机器时区，默认为 Asia/Shanghai, 可调整，与set_timezone 变量结合使用 | -| set_timezone | 默认为 True，即修改部署目标机器时区，关闭可修改为 False | -| enable_elk | 目前不支持，请忽略 | -| enable_firewalld | 开启防火墙，默认不开启 | -| enable_ntpd | 检测部署目标机器 NTP 服务，默认为 True，请勿关闭 | -| machine_benchmark | 检测部署目标机器磁盘 IOPS，默认为 True，请勿关闭 | -| set_hostname | 根据 IP 修改部署目标机器主机名，默认为 False | -| enable_binlog | 是否部署 pump 并开启 binlog，默认为 False，依赖 Kafka 集群，参见 zookeeper_addrs 变量 | -| zookeeper_addrs | binlog Kafka 集群的 zookeeper 地址 | -| enable_slow_query_log | TiDB 慢查询日志记录到单独文件({{ deploy_dir }}/log/tidb_slow_query.log)，默认为 False，记录到 tidb 日志 | -| deploy_without_tidb | KV 模式，不部署 TiDB 服务，仅部署 PD、TiKV 及监控服务，请将 inventory.ini 文件中 tidb_servers 主机组 IP 设置为空。 | - -#### 2.2.2 TiDB 离线 Ansible 部署方案 - -首先这不是我们建议的方式，如果中控机没有外网，也可以通过离线 Ansible 部署方式，详情可参考[离线 TiDB Ansible 部署方案](/dev/how-to/deploy/orchestrated/offline-ansible.md)。 - -#### 2.2.3 Docker Compose 快速构建集群（单机部署） - -使用 docker-compose 在本地一键拉起一个集群，包括集群监控，还可以根据需求自定义各个组件的软件版本和实例个数，以及自定义配置文件，这种只限于开发环境，详细可参考[官方文档](/dev/how-to/get-started/deploy-tidb-from-docker-compose.md)。 - -#### 2.2.4 如何单独记录 TiDB 中的慢查询日志，如何定位慢查询 SQL？ - -1）TiDB 中，对慢查询的定义在 tidb-ansible 的 `conf/tidb.yml` 配置文件中，`slow-threshold: 300`，这个参数是配置慢查询记录阈值的，单位是 ms。 - -慢查询日志默认记录到 tidb.log 中，如果希望生成单独的慢查询日志文件，修改 inventory.ini 配置文件的参数 `enable_slow_query_log` 为 True。 - -如上配置修改之后，需要执行 `ansible-playbook rolling_update.yml --tags=tidb`，对 tidb-server 实例进行滚动升级，升级完成后，tidb-server 将在 `tidb_slow_query.log` -文件中记录慢查询日志。 - -2）如果出现了慢查询，可以从 Grafana 监控定位到出现慢查询的 tidb-server 以及时间点，然后在对应节点查找日志中记录的 SQL 信息。 - -3）除了日志，还可以通过 `admin show slow` 命令查看，详情可参考 [`admin show slow` 命令](/dev/how-to/maintain/identify-abnormal-queries/identify-slow-queries.md#admin-show-slow-命令)。 - -#### 2.2.5 首次部署 TiDB 集群时，没有配置 tikv 的 Label 信息，在后续如何添加配置 Label？ - -TiDB 的 Label 设置是与集群的部署架构相关的，是集群部署中的重要内容，是 PD 进行全局管理和调度的依据。如果集群在初期部署过程中没有设置 Label，需要在后期对部署结构进行调整，就需要手动通过 PD 的管理工具 pd-ctl 来添加 location-labels 信息，例如：`config set location-labels "zone,rack,host"`（根据实际的 label 层级名字配置）。 - -pd-ctl 的使用参考 [PD Control 使用说明](/dev/reference/tools/pd-control.md)。 - -#### 2.2.6 为什么测试磁盘的 dd 命令用 oflag=direct 这个选项？ - -Direct 模式就是把写入请求直接封装成 I/O 指令发到磁盘，这样是为了绕开文件系统的缓存，可以直接测试磁盘的真实的 I/O 读写能力。 - -#### 2.2.7 如何用 fio 命令测试 TiKV 实例的磁盘性能？ - -- 随机读测试： - - {{< copyable "shell-regular" >}} - - ```bash - ./fio -ioengine=psync -bs=32k -fdatasync=1 -thread -rw=randread -size=10G -filename=fio_randread_test.txt -name='fio randread test' -iodepth=4 -runtime=60 -numjobs=4 -group_reporting --output-format=json --output=fio_randread_result.json - ``` - -- 顺序写和随机读混合测试： - - {{< copyable "shell-regular" >}} - - ```bash - ./fio -ioengine=psync -bs=32k -fdatasync=1 -thread -rw=randrw -percentage_random=100,0 -size=10G -filename=fio_randread_write_test.txt -name='fio mixed randread and sequential write test' -iodepth=4 -runtime=60 -numjobs=4 -group_reporting --output-format=json --output=fio_randread_write_test.json - ``` - -#### 2.2.8 使用 TiDB Ansible 部署 TiDB 集群的时候，遇到 `UNREACHABLE! "msg": "Failed to connect to the host via ssh: "` 报错是什么原因？ - -有两种可能性： - -- ssh 互信的准备工作未做好，建议严格参照我们的[官方文档步骤](/dev/how-to/deploy/orchestrated/ansible.md)配置互信，并使用命令 `ansible -i inventory.ini all -m shell -a 'whoami' -b` 来验证互信配置是否成功。 - -- 如果涉及到单服务器分配了多角色的场景，例如多组件混合部署或单台服务器部署了多个 TiKV 实例，可能是由于 ssh 复用的机制引起这个报错，可以使用 `ansible … -f 1` 的选项来规避这个报错。 - -### 2.3 升级 - -#### 2.3.1 如何使用 Ansible 滚动升级？ - -滚动升级 TiKV 节点( 只升级单独服务 ) - -`ansible-playbook rolling_update.yml --tags=tikv` - -滚动升级所有服务 - -`ansible-playbook rolling_update.yml` - -#### 2.3.2 滚动升级有那些影响? - -滚动升级 TiDB 服务，滚动升级期间不影响业务运行，需要配置最小集群拓扑（TiDB \* 2、PD \* 3、TiKV \* 3），如果集群环境中有 Pump/Drainer 服务，建议先停止 Drainer 后滚动升级（升级 TiDB 时会升级 Pump）。 - -#### 2.3.3 Binary 如何升级？ - -Binary 不是我们建议的安装方式，对升级支持也不友好，建议换成 Ansible 部署。 - -#### 2.3.4 一般升级选择升级 TiKV 还是所有组件都升级？ - -常规需要一起升，因为整个版本都是一起测试的，单独升级只限当发生一个紧急故障时，需要单独对一个有问题的角色做升级。 - -#### 2.3.5 启动集群或者升级集群过程中出现 “Timeout when waiting for search string 200 OK” 是什么原因？如何处理？ - -可能有以下几种原因：进程没有正常启动；端口被占用；进程没有正常停掉；停掉集群的情况下使用 rolling_update.yml 来升级集群（操作错误）。 - -处理方式：登录到相应节点查看进程或者端口的状态；纠正错误的操作步骤。 - -## 三、集群管理 - -### 3.1 集群日常管理 - -#### 3.1.1 Ansible 常见运维操作有那些？ - -| **任务** | **Playbook** | -| --- | --- | -| 启动集群 | ansible-playbook start.yml | -| 停止集群 | ansible-playbook stop.yml | -| 销毁集群 | ansible-playbook unsafe\_cleanup.yml (若部署目录为挂载点，会报错，可忽略） | -| 清除数据(测试用) | ansible-playbook cleanup\_data.yml | -| 滚动升级 | ansible-playbook rolling\_update.yml | -| 滚动升级 TiKV | ansible-playbook rolling\_update.yml --tags=tikv | -| 滚动升级除 PD 外模块 | ansible-playbook rolling\_update.yml --skip-tags=pd | -| 滚动升级监控组件 | ansible-playbook rolling\_update\_monitor.yml | - -#### 3.1.2 TiDB 如何登录？ - -和 MySQL 登录方式一样，可以按照下面例子进行登录。 - -`mysql -h 127.0.0.1 -uroot -P4000` - -#### 3.1.3 TiDB 如何修改数据库系统变量？ - -和 MySQL 一样，TiDB 也分为静态参数和固态参数，静态参数可以直接通过`set global xxx = n`的方式进行修改，不过新参数值只限于该实例生命周期有效。 - -#### 3.1.4 TiDB (TiKV) 有哪些数据目录？ - -默认在 [`--data-dir`](/dev/reference/configuration/tikv-server/configuration.md#--data-dir) 目录下，其中包括 backup、db、raft、snap 四个目录，分别存储备份、数据、raft 数据及镜像数据。 - -#### 3.1.5 TiDB 有哪些系统表？ - -和 MySQL 类似，TiDB 中也有系统表，用于存放数据库运行时所需信息，具体信息参考 [TiDB 系统数据库](/dev/reference/system-databases/mysql.md)文档。 - -#### 3.1.6 TiDB 各节点服务器下是否有日志文件，如何管理？ - -默认情况下各节点服务器会在日志中输出标准错误，如果启动的时候通过 `--log-file` 参数指定了日志文件，那么日志会输出到指定的文件中，并且按天做 rotation。 - -#### 3.1.7 如何规范停止 TiDB？ - -如果是用 Ansible 部署的，可以使用 `ansible-playbook stop.yml` 命令停止 TiDB 集群。如果不是 Ansible 部署的，可以直接 kill 掉所有服务。如果使用 kill 命令，TiDB 的组件会做 graceful 的 shutdown。 - -#### 3.1.8 TiDB 里面可以执行 kill 命令吗？ - -- 可以 kill DML 语句，首先使用 `show processlist`，找到对应 session 的 id，然后执行 `kill tidb [session id]`。 -- 可以 kill DDL 语句，首先使用 `admin show ddl jobs`，查找需要 kill 的 DDL job ID，然后执行 `admin cancel ddl jobs 'job_id' [, 'job_id'] ...`。具体可以参考 [admin 操作](/dev/reference/sql/statements/admin.md)。 - -#### 3.1.9 TiDB 是否支持会话超时？ - -TiDB 暂不支持数据库层面的会话超时，目前想要实现超时，在没 LB（Load Balancing）的时候，需要应用侧记录发起的 Session 的 ID，通过应用自定义超时，超时以后需要到发起 Query 的节点上用 `kill tidb [session id]` 来杀掉 SQL。目前建议使用应用程序来实现会话超时，当达到超时时间，应用层就会抛出异常继续执行后续的程序段。 - -#### 3.1.10 TiDB 生产环境的版本管理策略是怎么样的？如何尽可能避免频繁升级？ - -TiDB 版本目前逐步标准化，每次 Release 都包含详细的 Change log，版本功能[变化详情](https://github.com/pingcap/TiDB/releases)，生产环境是否有必要升级取决于业务系统，建议升级之前详细了解前后版本的功能差异。 - -版本号说明参考：Release Version: `v1.0.3-1-ga80e796` - -- `v1.0.3` 表示 GA 标准版 -- `1` 表示该版本 commit 1 次 -- `ga80e796` 代表版本的 `git-hash` - -#### 3.1.11 分不清 TiDB master 版本之间的区别，经常用错 TiDB Ansible 版本? - -TiDB 目前社区非常活跃，在 1.0 GA 版本发布后，还在不断的优化和修改 BUG，因此 TiDB 的版本更新周期比较快，会不定期有新版本发布，请关注我们的[新版本发布官方网站](https://pingcap.com/weekly/)。此外 TiDB 安装推荐使用 TiDB Ansible 进行安装，TiDB Ansible 的版本也会随着 TiDB 的版本发布进行更新，因此建议用户在安装升级新版本的时候使用最新的 TiDB Ansible 安装包版本进行安装。此外，在 TiDB 1.0 GA 版本后，对 TiDB 的版本号进行了统一管理，TiDB 的版本可以通过以下两种方式进行查看： - -- 通过 `select tidb_version()` 进行查看 -- 通过执行 `tidb-server -V` 进行查看 - -#### 3.1.12 有没有图形化部署 TiDB 的工具？ - -暂时没有。 - -#### 3.1.13 TiDB 如何进行水平扩展？ - -当您的业务不断增长时，数据库可能会面临三方面瓶颈，第一是存储空间，第二是计算资源，第三是读写容量，这时可以对 TiDB 集群做水平扩展。 - -- 如果是存储资源不够，可以通过添加 TiKV Server 节点来解决，新节点启动后，PD 会自动将其他节点的部分数据迁移过去，无需人工介入。 -- 如果是计算资源不够，可以查看 TiDB Server 和 TiKV Server 节点的 CPU 消耗情况，再考虑添加 TiDB Server 节点或者是 TiKV Server 节点来解决，如添加 TiDB Server 节点，将其添加到前端 Load Balancer 配置之中即可。 -- 如果是容量跟不上，一般可以考虑同时增加 TiDB Server 和 TiKV Server 节点。 - -#### 3.1.14 Percolator 用了分布式锁，crash 的客户端会保持锁，会造成锁没有 release？ - -详细可参考 [Percolator 和 TiDB 事务算法](https://pingcap.com/blog-cn/percolator-and-txn/)。 - -#### 3.1.15 TiDB 为什么选用 gRPC 而不选用 Thrift，是因为 Google 在用吗？ - -不只是因为 Google 在用，有一些比较好的特性我们需要，比如流控、加密还有 Streaming。 - -#### 3.1.16 like(bindo.customers.name, jason%, 92) 这个92代表什么？ - -那个是转义字符，默认是 (ASCII 92)。 - -#### 3.1.17 为什么 `information_schema.tables.data_length` 记录的大小和 TiKV 监控面板上的 store size 不一样？ - -这是因为两者计算的角度不一样。`information_schema.tables.data_length` 是通过统计信息（平均每行的大小）得到的估算值。TiKV 监控面板上的 store size 是单个 TiKV 实例的数据文件（RocksDB 的 SST 文件）的大小总和。由于多版本和 TiKV 会压缩数据，所以两者显示的大小不一样。 - -### 3.2 PD 管理 - -#### 3.2.1 访问 PD 报错：TiKV cluster is not bootstrapped - -PD 的大部分 API 需要在初始化 TiKV 集群以后才能使用，如果在部署新集群的时候只启动了 PD，还没有启动 TiKV，这时候访问 PD 就会报这个错误。遇到这个错误应该先把要部署的 TiKV 启动起来，TiKV 会自动完成初始化工作，然后就可以正常访问 PD。 - -#### 3.2.2 PD 启动报错：etcd cluster ID mismatch - -PD 启动参数中的 `--initial-cluster` 包含了某个不属于该集群的成员。遇到这个错误时请检查各个成员的所属集群，剔除错误的成员后即可正常启动。 - -#### 3.2.3 PD 能容忍的时间同步误差是多少？ - -理论上，时间同步误差越小越好。PD 可容忍任意时长的误差，但是，时间同步误差越大意味着 PD 分配的时间戳与真实的物理时间相差越大，这个差距会影响读历史版本等功能。 - -#### 3.2.4 Client 连接是如何寻找 PD 的？ - -Client 连接只能通过 TiDB 访问集群，TiDB 负责连接 PD 与 TiKV，PD 与 TiKV 对 Client 透明。当 TiDB 连接任意一台 PD 的时候，PD 会告知 TiDB 当前的 leader 是谁，如果此台 PD 不是 leader，TiDB 将会重新连接至 leader PD。 - -#### 3.2.5 PD 参数中 leader-schedule-limit 和 region-schedule-limit 调度有什么区别？ - -- leader-schedule-limit 调度是用来均衡不同 TiKV 的 leader 数，影响处理查询的负载。 -- region-schedule-limit 调度是均衡不同 TiKV 的副本数，影响不同节点的数据量。 - -#### 3.2.6 每个 region 的 replica 数量可配置吗？调整的方法是？ - -可以，目前只能调整全局的 replica 数量。首次启动时 PD 会读配置文件（conf/pd.yml），使用其中的 max-replicas 配置，之后修改需要使用 pd-ctl 配置命令 `config set max-replicas $num`，配置后可通过 `config show all` 来查看已生效的配置。调整的时候，不会影响业务，会在后台添加，注意总 TiKV 实例数总是要大于等于设置的副本数，例如 3 副本需要至少 3 个 TiKV。增加副本数量之前需要预估额外的存储需求。pd-ctl 的详细用法可参考 [PD Control 使用说明](/dev/reference/tools/pd-control.md)。 - -#### 3.2.7 缺少命令行集群管理工具，整个集群的健康度当前是否正常，不好确认？ - -可以通过 pd-ctl 等工具来判断集群大概的状态，详细的集群状态还是需要通过监控来确认。 - -#### 3.2.8 集群下线节点后，怎么删除老集群节点监控信息？ - -下线节点一般指 TiKV 节点通过 pd-ctl 或者监控判断节点是否下线完成。节点下线完成后，手动停止下线节点上相关的服务。从 Prometheus 配置文件中删除对应节点的 node_exporter 信息。从 Ansible inventory.ini 中删除对应节点的信息。 - -#### 3.2.9 使用 PD Control 连接 PD Server 时，为什么只能通过本机 IP 连接，不能通过 127.0.0.1 连接？ - -因为使用 TiDB Ansible 部署的集群，PD 对外服务端口不会绑定到 127.0.0.1，所以 PD Control 不会识别 127.0.0.1。 - -### 3.3 TiDB server 管理 - -#### 3.3.1 TiDB 的 lease 参数应该如何设置？ - -启动 TiDB Server 时，需要通过命令行参数设置 lease 参数（--lease=60），其值会影响 DDL 的速度（只会影响当前执行 DDL 的 session，其他的 session 不会受影响）。在测试阶段，lease 的值可以设为 1s，加快测试进度；在生产环境下，我们推荐这个值设为分钟级（一般可以设为 60），这样可以保证 DDL 操作的安全。 - -#### 3.3.2 DDL 在正常情况下的耗时是多少？ - -一般情况下处理一个 DDL 操作（之前没有其他 DDL 操作在处理）的耗时基本可以分如下为三种： - -- add index 操作，且此操作对应表数据行数比较少，耗时约为 3s。 -- add index 操作，且此操作对应表数据行数比较多，耗时具体由表中数据行数和当时 QPS 情况定（add index 操作优先级比一般 SQL 低）。 -- 其他 DDL 操作耗时约为 1s。 - -此外，如果接收 DDL 请求的 TiDB 和 DDL owner 所处的 TiDB 是一台，那么上面列举的第一和第三种可能的耗时应该在几十到几百毫秒。 - -#### 3.3.3 为什么有的时候执行 DDL 会很慢？ - -可能原因如下： - -- 多个 DDL 语句一起执行的时候，后面的几个 DDL 语句会比较慢。原因是当前 TiDB 集群中 DDL 操作是串行执行的。 -- 在正常集群启动后，第一个 DDL 操作的执行时间可能会比较久，一般在 30s 左右，这个原因是刚启动时 TiDB 在竞选处理 DDL 的 leader。 -- 由于停 TiDB 时不能与 PD 正常通信（包括停电情况）或者用 `kill -9` 指令停 TiDB 导致 TiDB 没有及时从 PD 清理注册数据，那么会影响 TiDB 启动后 10min 内的 DDL 语句处理时间。这段时间内运行 DDL 语句时，每个 DDL 状态变化都需要等待 2 * lease（默认 lease = 45s）。 -- 当集群中某个 TiDB 与 PD 之间发生通信问题，即 TiDB 不能从 PD 及时获取或更新版本信息，那么这时候 DDL 操作的每个状态处理需要等待 2 * lease。 - -#### 3.3.4 TiDB 可以使用 S3 作为后端存储吗？ - -不可以，目前 TiDB 只支持分布式存储引擎和 GolevelDB/RocksDB/BoltDB 引擎。 - -#### 3.3.5 Information_schema 能否支持更多真实信息？ - -Information_schema 库里面的表主要是为了兼容 MySQL 而存在，有些第三方软件会查询里面的信息。在目前 TiDB 的实现中，里面大部分只是一些空表。后续随着 TiDB 的升级，会提供更多的参数信息。当前 TiDB 支持的 Information\_schema 请参考 [TiDB 系统数据库说明文档](/dev/reference/system-databases/information-schema.md)。 - -#### 3.3.6 TiDB Backoff type 主要原因? - -TiDB-server 与 TiKV-server 随时进行通信，在进行大量数据操作过程中，会出现 `Server is busy` 或者 `backoff.maxsleep 20000ms` 的日志提示信息，这是由于 TiKV-server 在处理过程中系统比较忙而出现的提示信息，通常这时候可以通过系统资源监控到 TiKV 主机系统资源使用率比较高的情况出现。如果这种情况出现，可以根据资源使用情况进行相应的扩容操作。 - -#### 3.3.7 TiDB TiClient type 主要原因？ - -TiClient Region Error 该指标描述的是在 TiDB-server 作为客户端通过 KV 接口访问 TiKV-server 进行数据操作过程中，TiDB-server 操作 TiKV-server 中的 Region 数据出现的错误类型与 metric 指标，错误类型包括 not_leader、stale_epoch。出现这些错误的情况是当 TiDB-server 根据自己的缓存信息去操作 Region leader 数据的时候，Region leader 发生了迁移或者 TiKV 当前的 Region 信息与 TiDB 缓存的路由信息不一致而出现的错误提示。一般这种情况下，TiDB-server 都会自动重新从 PD 获取最新的路由数据，重做之前的操作。 - -#### 3.3.8 TiDB 同时支持的最大并发连接数？ - -当前版本 TiDB 没有最大连接数的限制，如果并发过大导致响应时间增加，可以通过增加 TiDB 节点进行扩容。 - -#### 3.3.9 如何查看某张表创建的时间？ - -information_schema 库中的 tables 表里的 create_time 即为表的真实创建时间。 - -#### 3.3.9 TiDB 的日志中 EXPENSIVE_QUERY 是什么意思？ - -TiDB 在执行 SQL 时，预估出来每个 operator 处理了超过 10000 条数据就认为这条 query 是 expensive query。可以通过修改 tidb-server 配置参数来对这个门限值进行调整，调整后需要重新启动 tidb-server。 - -#### 3.3.10 在 TiDB 中如何控制或改变 SQL 提交的执行优先级？ - -TiDB 支持改变 [per-session](/dev/reference/configuration/tidb-server/tidb-specific-variables.md#tidb_force_priority)、[全局](/dev/reference/configuration/tidb-server/configuration-file.md#force-priority)或单个语句的优先级。优先级包括： - -- HIGH_PRIORITY：该语句为高优先级语句，TiDB 在执行阶段会优先处理这条语句 -- LOW_PRIORITY：该语句为低优先级语句，TiDB 在执行阶段会降低这条语句的优先级 - -以上两种参数可以结合 TiDB 的 DML 语言进行使用，使用方法举例如下： - -1. 通过在数据库中写 SQL 的方式来调整优先级： - - {{< copyable "sql" >}} - - ```sql - select HIGH_PRIORITY | LOW_PRIORITY count(*) from table_name; - insert HIGH_PRIORITY | LOW_PRIORITY into table_name insert_values; - delete HIGH_PRIORITY | LOW_PRIORITY from table_name; - update HIGH_PRIORITY | LOW_PRIORITY table_reference set assignment_list where where_condition; - replace HIGH_PRIORITY | LOW_PRIORITY into table_name; - ``` - -2. 全表扫会自动调整为低优先级，analyze 也是默认低优先级。 - -#### 3.3.11 在 TiDB 中 auto analyze 的触发策略是怎样的？ - -触发策略：新表达到 1000 条，并且在 1 分钟内没有写入，会自动触发。 - -当表的（修改数/当前总行数）大于 `tidb_auto_analyze_ratio` 的时候，会自动触发 `analyze` 语句。`tidb_auto_analyze_ratio` 的默认值为 0.5，即默认开启此功能。为了保险起见，在开启此功能的时候，保证了其最小值为 0.3。但是不能大于等于 `pseudo-estimate-ratio`（默认值为 0.8），否则会有一段时间使用 pseudo 统计信息，建议设置值为 0.5。 - -#### 3.3.12 SQL 中如何通过 hint 使用一个具体的 index？ - -同 MySQL 的用法一致，例如： -`select column_name from table_name use index（index_name）where where_condition;` - -#### 3.3.13 触发 Information schema is changed 错误的原因？ - -TiDB 在执行 SQL 语句时，会使用当时的 `schema` 来处理该 SQL 语句，而且 TiDB 支持在线异步变更 DDL。那么，在执行 DML 的时候可能有 DDL 语句也在执行，而你需要确保每个 SQL 语句在同一个 `schema` 上执行。所以当执行 DML 时，遇到正在执行中的 DDL 操作就可能会报 `Information schema is changed` 的错误。为了避免太多的 DML 语句报错，已做了一些优化。 - -现在会报此错的可能原因如下（后两个报错原因与表无关）： - -- 执行的 DML 语句中涉及的表和集群中正在执行的 DDL 的表有相同的，那么这个 DML 语句就会报此错。 -- 这个 DML 执行时间很久，而这段时间内执行了很多 DDL 语句，导致中间 `schema` 版本变更次数超过 1024 （此为默认值，可以通过 `tidb_max_delta_schema_count` 变量修改）。 -- 接受 DML 请求的 TiDB 长时间不能加载到 `schema information`（TiDB 与 PD 或 TiKV 之间的网络连接故障等会导致此问题），而这段时间内执行了很多 DDL 语句，导致中间 `schema` 版本变更次数超过 100。 - -> **注意：** -> -> + 目前 TiDB 未缓存所有的 `schema` 版本信息。 -> + 对于每个 DDL 操作，`schema` 版本变更的数量与对应 `schema state` 变更的次数一致。 -> + 不同的 DDL 操作版本变更次数不一样。例如，`create table` 操作会有 1 次 `schema` 版本变更；`add column` 操作有 4 次 `schema` 版本变更。 - -#### 3.3.14 触发 Information schema is out of date 错误的原因？ - -当执行 DML 时，TiDB 超过一个 DDL lease 时间（默认 45s）没能加载到最新的 schema 就可能会报 `Information schema is out of date` 的错误。遇到此错的可能原因如下： - -- 执行此 DML 的 TiDB 被 kill 后准备退出，且此 DML 对应的事务执行时间超过一个 DDL lease，在事务提交时会报这个错误。 -- TiDB 在执行此 DML 时，有一段时间内连不上 PD 或者 TiKV，导致 TiDB 超过一个 DDL lease 时间没有 load schema，或者导致 TiDB 断开与 PD 之间带 keep alive 设置的连接。 - -#### 3.3.15 高并发情况下执行 DDL 时报错的原因？ - -高并发情况下执行 DDL（比如批量建表）时，极少部分 DDL 可能会由于并发执行时 key 冲突而执行失败。 - -并发执行 DDL 时，建议将 DDL 数量保持在 20 以下，否则你需要在应用端重试失败的 DDL 语句。 - -### 3.4 TiKV 管理 - -#### 3.4.1 TiKV 集群副本建议配置数量是多少，是不是最小高可用配置（3个）最好？ - -如果是测试环境 3 副本足够；在生产环境中，不可让集群副本数低于 3，需根据架构特点、业务系统及恢复能力的需求，适当增加副本数。值得注意的是，副本升高，性能会有下降，但是安全性更高。 - -#### 3.4.2 TiKV 启动报错：cluster ID mismatch - -TiKV 本地存储的 cluster ID 和指定的 PD 的 cluster ID 不一致。在部署新的 PD 集群的时候，PD 会随机生成一个 cluster ID，TiKV 第一次初始化的时候会从 PD 获取 cluster ID 存储在本地，下次启动的时候会检查本地的 cluster ID 与 PD 的 cluster ID 是否一致，如果不一致则会报错并退出。出现这个错误一个常见的原因是，用户原先部署了一个集群，后来把 PD 的数据删除了并且重新部署了新的 PD，但是 TiKV 还是使用旧的数据重启连到新的 PD 上，就会报这个错误。 - -#### 3.4.3 TiKV 启动报错：duplicated store address - -启动参数中的地址已经被其他的 TiKV 注册在 PD 集群中了。造成该错误的常见情况：TiKV `--data-dir` 指定的路径下没有数据文件夹（删除或移动后没有更新 --data-dir），用之前参数重新启动该 TiKV。请尝试用 pd-ctl 的 [store delete](https://github.com/pingcap/pd/tree/55db505e8f35e8ab4e00efd202beb27a8ecc40fb/tools/pd-ctl#store-delete--label--weight-store_id----jqquery-string) 功能，删除之前的 store，然后重新启动 TiKV 即可。 - -#### 3.4.4 TiKV master 和 slave 用的是一样的压缩算法，为什么效果不一样? - -目前来看 master 有些文件的压缩率会高一些，这个取决于底层数据的分布和 RocksDB 的实现，数据大小偶尔有些波动是正常的，底层存储引擎会根据需要调整数据。 - -#### 3.4.5 TiKV block cache 有哪些特性？ - -TiKV 使用了 RocksDB 的 Column Family (CF) 特性，KV 数据最终存储在默认 RocksDB 内部的 default、write、lock 3 个 CF 内。 - -- default CF 存储的是真正的数据，与其对应的参数位于 `[rocksdb.defaultcf]` 项中。 -- write CF 存储的是数据的版本信息（MVCC）、索引、小表相关的数据，相关的参数位于 `[rocksdb.writecf]` 项中。 -- lock CF 存储的是锁信息，系统使用默认参数。 -- Raft RocksDB 实例存储 Raft log。default CF 主要存储的是 Raft log，与其对应的参数位于 `[raftdb.defaultcf]` 项中。 -- 所有 CF 共享一个 Block-cache，用于缓存数据块，加速 RocksDB 的读取速度，Block-cache 的大小通过参数 `block-cache-size` 控制，`block-cache-size` 越大，能够缓存的热点数据越多，对读取操作越有利，同时占用的系统内存也会越多。 -- 每个 CF 有各自的 Write-buffer，大小通过 `write-buffer-size` 控制。 - -#### 3.4.6 TiKV channel full 是什么原因？ - -- Raftstore 线程太忙，或者因 I/O 而卡住。可以看一下 Raftstore 的 CPU 使用情况。 -- TiKV 过忙（CPU、磁盘 I/O 等），请求处理不过来。 - -#### 3.4.7 TiKV 频繁切换 Region leader 是什么原因？ - -- 网络问题导致节点间通信卡了，查看 Report failures 监控。 -- 原主 Leader 的节点卡了，导致没有及时给 Follower 发送消息。 -- Raftstore 线程卡了。 - -#### 3.4.8 如果一个节点挂了会影响服务吗？影响会持续多久？ - -TiDB 使用 Raft 在多个副本之间做数据同步（默认为每个 Region 3 个副本）。当一份备份出现问题时，其他的副本能保证数据的安全。根据 Raft 协议，当某个节点挂掉导致该节点里的 Leader 失效时，在最大 2 * lease time（leasetime 是 10 秒）时间后，通过 Raft 协议会很快将一个另外一个节点里的 Follower 选为新的 Region Leader 来提供服务。 - -#### 3.4.9 TiKV 在分别在那些场景下占用大量 IO、内存、CPU（超过参数配置的多倍）？ - -在大量写入、读取的场景中会占用大量的磁盘 IO、内存、CPU。在执行很复杂的查询，比如会产生很大中间结果集的情况下，会消耗很多的内存和 CPU 资源。 - -#### 3.4.10 TiKV 是否可以使用 SAS/SATA 盘或者进行 SSD/SAS 混合部署？ - -不可以使用，TiDB 在进行 OLTP 场景中，数据访问和操作需要高 IO 磁盘的支持，TiDB 作为强一致的分布式数据库，存在一定的写放大，如副本复制、存储底层 Compaction，因此，TiDB 部署的最佳实践中推荐用户使用 NVMe SSD 磁盘作为数据存储磁盘。另外，TiKV 与 PD 不能混合部署。 - -#### 3.4.11 数据表 Key 的 Range 范围划分是在数据接入之前就已经划分好了吗？ - -不是的，这个和 MySQL 分表规则不一样，需要提前设置好，TiKV 是根据 Region 的大小动态分裂的。 - -#### 3.4.12 Region 是如何进行分裂的？ - -Region 不是前期划分好的，但确实有 Region 分裂机制。当 Region 的大小超过参数 `region-max-size` 或 `region-max-keys` 的值时，就会触发分裂，分裂后的信息会汇报给 PD。 - -#### 3.4.13 TiKV 是否有类似 MySQL 的 `innodb_flush_log_trx_commit` 参数，来保证提交数据不丢失？ - -是的，TiKV 单机的存储引擎目前使用两个 RocksDB 实例，其中一个存储 raft-log，TiKV 有个 sync-log 参数，在 ture 的情况下，每次提交都会强制刷盘到 raft-log，如果发生 crash 后，通过 raft-log 进行 KV 数据的恢复。 - -#### 3.4.14 对 WAL 存储有什么推荐的硬件配置，例如 SSD，RAID 级别，RAID 卡 cache 策略，NUMA 设置，文件系统选择，操作系统的 IO 调度策略等？ - -WAL 属于顺序写，目前我们并没有单独对他进行配置，建议 SSD，RAID 如果允许的话，最好是 RAID 10，RAID 卡 cache、操作系统 I/O 调度目前没有针对性的最佳实践，Linux 7 以上默认配置即可，NUMA 没有特别建议，NUMA 内存分配策略可以尝试使用 `interleave = all`，文件系统建议 ext4。 - -#### 3.4.15 在最严格的 `sync-log = true` 数据可用模式下，写入性能如何？ - -一般来说，开启 `sync-log` 会让性能损耗 30% 左右。关闭 `sync-log` 时的性能表现，请参见 [TiDB Sysbench 性能测试报告](https://github.com/pingcap/docs-cn/blob/master/dev/benchmark/sysbench-v4.md)。 - -#### 3.4.16 是否可以利用 TiKV 的 Raft + 多副本达到完全的数据可靠，单机存储引擎是否需要最严格模式？ - -通过使用 [Raft 一致性算法](https://raft.github.io/)，数据在各 TiKV 节点间复制为多副本，以确保某个节点挂掉时数据的安全性。只有当数据已写入超过 50% 的副本时，应用才返回 ACK（三副本中的两副本）。但理论上两个节点也可能同时发生故障，所以除非是对性能要求高于数据安全的场景，一般都强烈推荐开启 `sync-log`。 - -另外，还有一种 `sync-log` 的替代方案，即在 Raft group 中用五个副本而非三个。这将允许两个副本同时发生故障，而仍然能保证数据安全性。 - -对于单机存储引擎也同样推荐打开 `sync-log` 模式。否则如果节点宕机可能会丢失最后一次写入数据。 - -#### 3.4.17 使用 Raft 协议，数据写入会有多次网络的 roundtrip，实际写入延迟如何？ - -理论上，和单机数据库相比，数据写入会多四个网络延迟。 - -#### 3.4.18 有没有类似 MySQL 的 InnoDB Memcached plugin，可以直接使用 KV 接口，可以不需要独立的 Cache？ - -TiKV 支持单独进行接口调用，理论上也可以起个实例做为 Cache，但 TiDB 最大的价值是分布式关系型数据库，我们原则上不对 TiKV 单独进行支持。 - -#### 3.4.19 Coprocessor 组件的主要作用？ - -- 减少 TiDB 与 TiKV 之间的数据传输。 -- 计算下推，充分利用 TiKV 的分布式计算资源。 - -#### 3.4.20 IO error: No space left on device While appending to file - -这是磁盘空间不足导致的，需要加节点或者扩大磁盘空间。 - -#### 3.4.21 为什么 TiKV 容易出现 OOM？ - -TiKV 的内存占用主要来自于 RocksDB 的 block-cache，默认为系统总内存的 40%。当 TiKV 容易出现 OOM 时，检查 `block-cache-size` 配置是否过高。还需要注意，当单机部署了多个 TiKV 实例时，需要显式地配置该参数，以防止多个实例占用过多系统内存导致 OOM。 - -#### 3.4.22 TiDB 数据和 RawKV 数据可存储于同一个 TiKV 集群里吗？ - -不可以。TiDB 数据（或使用其他事务 API 生成的数据）依赖于一种特殊的键值格式，和 RawKV API 数据（或其他基于 RawKV 的服务生成的数据）并不兼容。 - -### 3.5 TiDB 测试 - -#### 3.5.1 TiDB Sysbench 基准测试结果如何？ - -很多用户在接触 TiDB 都习惯做一个基准测试或者 TiDB 与 MySQL 的对比测试，官方也做了一个类似测试，汇总很多测试结果后，我们发现虽然测试的数据有一定的偏差，但结论或者方向基本一致，由于 TiDB 与 MySQL 由于架构上的差别非常大，很多方面是很难找到一个基准点，所以官方的建议两点： - -- 大家不要用过多精力纠结这类基准测试上，应该更多关注 TiDB 的场景上的区别。 -- 大家可以直接参考 [TiDB Sysbench 性能测试报告](https://github.com/pingcap/docs-cn/blob/master/dev/benchmark/sysbench-v4.md)。 - -#### 3.5.2 TiDB 集群容量 QPS 与节点数之间关系如何，和 MySQL 对比如何？ - -- 在 10 节点内，TiDB 写入能力（Insert TPS）和节点数量基本成 40% 线性递增，MySQL 由于是单节点写入，所以不具备写入扩展能力。 -- MySQL 读扩容可以通过添加从库进行扩展，但写流量无法扩展，只能通过分库分表，而分库分表有很多问题，具体参考[方案虽好，成本先行：数据库 Sharding+Proxy 实践解析](http://t.cn/RTD18qV)。 -- TiDB 不管是读流量、还是写流量都可以通过添加节点快速方便的进行扩展。 - -#### 3.5.3 我们的 DBA 测试过 MySQL 性能，单台 TiDB 的性能没有 MySQL 性能那么好？ - -TiDB 设计的目标就是针对 MySQL 单台容量限制而被迫做的分库分表的场景，或者需要强一致性和完整分布式事务的场景。它的优势是通过尽量下推到存储节点进行并行计算。对于小表（比如千万级以下），不适合 TiDB，因为数据量少，Region 有限，发挥不了并行的优势，最极端的就是计数器表，几行记录高频更新，这几行在 TiDB 里，会变成存储引擎上的几个 KV，然后只落在一个 Region 里，而这个 Region 只落在一个节点上。加上后台强一致性复制的开销，TiDB 引擎到 TiKV 引擎的开销，最后表现出来的就是没有单个 MySQL 好。 - -### 3.6 TiDB 备份恢复 - -#### 3.6.1 TiDB 主要备份方式？ - -目前，推荐的备份方式是使用 [PingCAP fork 的 Mydumper](/dev/reference/tools/mydumper.md)。尽管 TiDB 也支持使用 MySQL 官方工具 `mysqldump` 进行数据备份、恢复，但其性能低于 [`mydumper`](/dev/reference/tools/mydumper.md)/[`loader`](/dev/reference/tools/loader.md)，并且该工具备份、恢复大量数量时，要耗费更多时间。 - -使用 Mydumper 导出来的数据文件尽可能的小, 最好不要超过 64M, 可以设置参数 -F 64； - -loader 的 -t 参数可以根据 TiKV 的实例个数以及负载进行评估调整，例如 3 个 TiKV 的场景， 此值可以设为 3 * (1 ～ n)，当 TiKV 负载过高，loader 以及 TiDB 日志中出现大量 `backoffer.maxSleep 15000ms is exceeded` 可以适当调小该值，当 TiKV 负载不是太高的时候，可以适当调大该值。 - -## 四、数据、流量迁移 - -### 4.1 全量数据导出导入 - -#### 4.1.1 Mydumper - -参见 [Mydumper 使用文档](/dev/reference/tools/mydumper.md)。 - -#### 4.1.2 Loader - -参见 [Loader 使用文档](/dev/reference/tools/loader.md)。 - -#### 4.1.3 如何将一个运行在 MySQL 上的应用迁移到 TiDB 上？ - -TiDB 支持绝大多数 MySQL 语法，一般不需要修改代码。 - -#### 4.1.4 不小心把 MySQL 的 user 表导入到 TiDB 了，或者忘记密码，无法登录，如何处理？ - -重启 TiDB 服务，配置文件中增加 `-skip-grant-table=true` 参数，无密码登录集群后，可以根据情况重建用户，或者重建 mysql.user 表，具体表结构搜索官网。 - -#### 4.1.5 在 Loader 运行的过程中，TiDB 可以对外提供服务吗？ - -该操作进行逻辑插入，TiDB 仍可对外提供服务，但不要执行相关 DDL 操作。 - -#### 4.1.6 如何导出 TiDB 数据？ - -TiDB 目前暂时不支持 `select into outfile`，可以通过以下方式导出 TiDB 数据：参考 [MySQL 使用 mysqldump 导出某个表的部分数据](https://blog.csdn.net/xin_yu_xin/article/details/7574662)，使用 mysqldump 加 where 条件导出，使用 MySQL client 将 select 的结果输出到一个文件。 - -#### 4.1.7 如何从 DB2、Oracle 数据库迁移到 TiDB？ - -DB2、Oracle 到 TiDB 数据迁移（增量+全量），通常做法有： - -- 使用 Oracle 官方迁移工具，如 OGG、Gateway（透明网关）、CDC（Change Data Capture）。 -- 自研数据导出导入程序实现。 -- 导出（Spool）成文本文件，然后通过 Load infile 进行导入。 -- 使用第三方数据迁移工具。 - -目前看来 OGG 最为合适。 - -#### 4.1.8 用 Sqoop 批量写入 TiDB 数据，虽然配置了 `--batch` 选项，但还是会遇到 `java.sql.BatchUpdateExecption:statement count 5001 exceeds the transaction limitation` 的错误，该如何解决？ - -- 在 Sqoop 中，`--batch` 是指每个批次提交 100 条 statement，但是默认每个 statement 包含 100 条 SQL 语句，所以此时 100 * 100 = 10000 条 SQL 语句，超出了 TiDB 的事务限制 5000 条，可以增加选项 `-Dsqoop.export.records.per.statement=10` 来解决这个问题，完整的用法如下： - - {{< copyable "shell-regular" >}} - - ```bash - sqoop export \ - -Dsqoop.export.records.per.statement=10 \ - --connect jdbc:mysql://mysql.example.com/sqoop \ - --username sqoop ${user} \ - --password ${passwd} \ - --table ${tab_name} \ - --export-dir ${dir} \ - --batch - ``` - -- 也可以选择增大 tidb 的单个事物语句数量限制，不过这个会导致内存上涨。 - -#### 4.1.9 TiDB 有像 Oracle 那样的 Flashback Query 功能么，DDL 支持么？ - -有，也支持 DDL。详细参考 [TiDB 历史数据回溯](/dev/how-to/get-started/read-historical-data.md)。 - -### 4.2 在线数据同步 - -#### 4.2.1 Syncer 架构 - -详细参考 [解析 TiDB 在线数据同步工具 Syncer](https://pingcap.com/blog-cn/tidb-syncer/)。 - -##### 4.2.1.1 Syncer 使用文档 - -详细参考 [Syncer 使用文档](/dev/reference/tools/syncer.md)。 - -##### 4.2.1.2 如何配置监控 Syncer 运行情况？ - -下载 [Syncer Json](https://github.com/pingcap/tidb-ansible/blob/master/scripts/syncer.json) 导入到 Grafana，修改 Prometheus 配置文件，添加以下内容： - -- job_name: 'syncer_ops' // 任务名字 - static_configs: -- targets: ['10.10.1.1:10096'] //Syncer 监听地址与端口，通知 prometheus 拉取 Syncer 的数据。 - -重启 Prometheus 即可。 - -##### 4.2.1.3 有没有现成的同步方案，可以将数据同步到 Hbase、Elasticsearh 等其他存储？ - -没有，目前依赖程序自行实现。 - -##### 4.2.1.4 利用 Syncer 做数据同步的时候是否支持只同步部分表？ - -支持，具体参考 Syncer 使用手册 [Syncer 使用文档](/dev/reference/tools/syncer.md) - -##### 4.2.1.5 频繁的执行 DDL 会影响 Syncer 同步速度吗？ - -频繁执行 DDL 对同步速度会有影响。对于 Sycner 来说，DDL 是串行执行的，当同步遇到了 DDL，就会以串行的方式执行，所以这种场景就会导致同步速度下降。 - -##### 4.2.1.6 使用 Syncer gtid 的方式同步时，同步过程中会不断更新 syncer.meta 文件，如果 Syncer 所在的机器坏了，导致 syncer.meta 文件所在的目录丢失，该如何处理？ - -当前 Syncer 版本的没有进行高可用设计，Syncer 目前的配置信息 syncer.meta 直接存储在硬盘上，其存储方式类似于其他 MySQL 生态工具，比如 Mydumper。因此，要解决这个问题当前可以有两个方法： - -1）把 syncer.meta 数据放到比较安全的磁盘上，例如磁盘做好 raid1； - -2）可以根据 Syncer 定期上报到 Prometheus 的监控信息来还原出历史同步的位置信息，该方法的位置信息在大量同步数据时由于延迟会可能不准确。 - -##### 4.2.1.7 Syncer 下游 TiDB 数据和 MySQL 数据不一致，DML 会退出么？ - -- 上游 MySQL 中存在数据，下游 TiDB 中该数据不存在，上游 MySQL 执行 `UPDATE` 或 `DELETE`（更新/删除）该条数据的操作时，Syncer 同步过程即不会报错退出也没有该条数据。 -- 下游有主键索引或是唯一索引冲突时，执行 `UPDATE` 会退出，执行 `INSERT` 不会退出。 - -### 4.3 业务流量迁入 - -#### 4.3.1 如何快速迁移业务流量？ - -我们建议通过 Syncer 工具搭建成多源 MySQL -> TiDB 实时同步环境，读写流量可以按照需求分阶段通过修改网络配置进行流量迁移，建议 DB 上层部署一个稳定的网络 LB（HAproxy、LVS、F5、DNS 等），这样直接修改网络配置就能实现无缝流量迁移。 - -#### 4.3.2 TiDB 总读写流量有限制吗？ - -TiDB 读流量可以通过增加 TiDB server 进行扩展，总读容量无限制，写流量可以通过增加 TiKV 节点进行扩容，基本上写容量也没有限制。 - -#### 4.3.3 Transaction too large 是什么原因，怎么解决？ - -由于分布式事务要做两阶段提交，并且底层还需要做 Raft 复制，如果一个事务非常大，会使得提交过程非常慢，并且会卡住下面的 Raft 复制流程。为了避免系统出现被卡住的情况，我们对事务的大小做了限制： - -- 单个事务包含的 SQL 语句不超过 5000 条（默认） -- 单条 KV entry 不超过 6MB -- KV entry 的总大小不超过 100MB - -在 Google 的 Cloud Spanner 上面，也有类似的[限制](https://cloud.google.com/spanner/docs/limits)。 - -#### 4.3.4 如何批量导入？ - -导入数据的时候，可以分批插入，每批最好不要超过 1w 行。 - -#### 4.3.5 TiDB 中删除数据后会立即释放空间吗？ - -DELETE，TRUNCATE 和 DROP 都不会立即释放空间。对于 TRUNCATE 和 DROP 操作，在达到 TiDB 的 GC (garbage collection) 时间后（默认 10 分钟），TiDB 的 GC 机制会删除数据并释放空间。对于 DELETE 操作 TiDB 的 GC 机制会删除数据，但不会释放空间，而是当后续数据写入 RocksDB 且进行 compact 时对空间重新利用。 - -#### 4.3.6 Load 数据时可以对目标表执行 DDL 操作吗？ - -不可以，加载数据期间不能对目标表执行任何 DDL 操作，这会导致数据加载失败。 - -#### 4.3.7 TiDB 是否支持 replace into 语法？ - -支持，但是 load data 不支持 replace into 语法。 - -#### 4.3.8 数据删除后查询速度为何会变慢？ - -大量删除数据后，会有很多无用的 key 存在，影响查询效率。目前正在开发 Region Merge 功能，完善之后可以解决这个问题，具体看参考[最佳实践](https://pingcap.com/blog-cn/tidb-best-practice/)中的删除数据部分。 - -#### 4.3.9 数据删除最高效最快的方式？ - -在删除大量数据的时候，建议使用 `Delete * from t where xx limit 5000`（xx 建议在满足业务过滤逻辑下，尽量加上强过滤索引列或者直接使用主键选定范围，如 `id >= 5000*n+m and id <= 5000*(n+1)+m` 这样的方案，通过循环来删除，用 `Affected Rows == 0` 作为循环结束条件，这样避免遇到事务大小的限制。如果一次删除的数据量非常大，这种循环的方式会越来越慢，因为每次删除都是从前向后遍历，前面的删除之后，短时间内会残留不少删除标记（后续会被 GC 掉），影响后面的 Delete 语句。如果有可能，建议把 Where 条件细化。可以参考官网[最佳实践](https://pingcap.com/blog-cn/tidb-best-practice/)。 - -#### 4.3.10 TiDB 如何提高数据加载速度？ - -主要有两个方面： - -- 目前已开发分布式导入工具 [Lightning](/dev/reference/tools/tidb-lightning/overview.md)，需要注意的是数据导入过程中为了性能考虑，不会执行完整的事务流程，所以没办法保证导入过程中正在导入的数据的 ACID 约束，只能保证整个导入过程结束以后导入数据的 ACID 约束。因此适用场景主要为新数据的导入（比如新的表或者新的索引），或者是全量的备份恢复（先 Truncate 原表再导入）。 -- TiDB 的数据加载与磁盘以及整体集群状态相关，加载数据时应关注该主机的磁盘利用率，TiClient Error/Backoff/Thread CPU 等相关 metric，可以分析相应瓶颈。 - -#### 4.3.11 对数据做删除操作之后，空间回收比较慢，如何处理？ - -可以设置并行 GC，加快对空间的回收速度。默认并发为 1，最大可调整为 tikv 实例数量的 50%。可使用 `update mysql.tidb set VARIABLE_VALUE="3" where VARIABLE_NAME="tikv_gc_concurrency";` 命令来调整。 - -## 五、SQL 优化 - -### 5.1 TiDB 执行计划解读 - -详细解读 [理解 TiDB 执行计划](/dev/reference/performance/understanding-the-query-execution-plan.md)。 - -#### 5.1.1 统计信息收集 - -详细解读 [统计信息](/dev/reference/performance/statistics.md)。 - -#### 5.1.2 Count 如何加速？ - -Count 就是暴力扫表，提高并发度能显著的提升速度，修改并发度可以参考 `tidb_distsql_scan_concurrency` 变量，但是也要看 CPU 和 I/O 资源。TiDB 每次查询都要访问 TiKV，在数据量小的情况下，MySQL 都在内存里，TiDB 还需要进行一次网络访问。 - -提升建议： - -- 建议提升硬件配置，可以参考[部署建议](/dev/how-to/deploy/hardware-recommendations.md)。 -- 提升并发度，默认是 10，可以提升到 50 试试，但是一般提升在 2-4 倍之间。 -- 测试大数据量的 count。 -- 调优 TiKV 配置，可以参考[性能调优](/dev/reference/performance/tune-tikv.md)。 - -#### 5.1.3 查看当前 DDL 的进度？ - -通过 `admin show ddl` 查看当前 job 进度。操作如下： - -{{< copyable "sql" >}} - -```sql -admin show ddl; -``` - -``` -*************************** 1. row *************************** - SCHEMA_VER: 140 - OWNER: 1a1c4174-0fcd-4ba0-add9-12d08c4077dc -RUNNING_JOBS: ID:121, Type:add index, State:running, SchemaState:write reorganization, SchemaID:1, TableID:118, RowCount:77312, ArgLen:0, start time: 2018-12-05 16:26:10.652 +0800 CST, Err:, ErrCount:0, SnapshotVersion:404749908941733890 - SELF_ID: 1a1c4174-0fcd-4ba0-add9-12d08c4077dc -``` - -从上面操作结果可知，当前正在处理的是 `add index` 操作。且从 `RUNNING_JOBS` 列的 `RowCount` 字段可以知道当前 `add index` 操作已经添加了 77312 行索引。 - -#### 5.1.4 如何查看 DDL job？ - -可以使用 `admin show ddl` 语句查看正在运行的 DDL 作业。 - -- `admin show ddl jobs`：用于查看当前 DDL 作业队列中的所有结果（包括正在运行以及等待运行的任务）以及已执行完成的 DDL 作业队列中的最近十条结果。 -- `admin show ddl job queries 'job_id' [, 'job_id'] ...`：用于显示 `job_id` 对应的 DDL 任务的原始 SQL 语句。此 `job_id` 只搜索正在执行中的任务以及 DDL 历史作业队列中的最近十条结果。 - -#### 5.1.5 TiDB 是否支持基于 COST 的优化（CBO），如果支持，实现到什么程度？ - -是的，TiDB 使用的基于成本的优化器（CBO），我们有一个小组单独会对代价模型、统计信息持续优化，除此之外，我们支持 hash join、soft merge 等关联算法。 - -#### 5.1.6 如何确定某张表是否需要做 analyze ？ - -可以通过 `show stats_healthy` 来查看 Healthy 字段，一般小于等于 60 的表需要做 analyze。 - -#### 5.1.7 SQL 的执行计划展开成了树，ID 的序号有什么规律吗？这棵树的执行顺序会是怎么样的？ - -ID 没什么规律，只要是唯一就行，不过生成的时候，是有一个计数器，生成一个 plan 就加一，执行的顺序和序号无关，整个执行计划是一颗树，执行时从根节点开始，不断地向上返回数据。执行计划的理解，请参考[理解 TiDB 执行计划](/dev/reference/performance/understanding-the-query-execution-plan.md)。 - -#### 5.1.8 TiDB 执行计划中，task cop 在一个 root 下，这个是并行的么？ - -目前 TiDB 的计算任务隶属于两种不同的 task：cop task 和 root task。cop task 是指被下推到 KV 端分布式执行的计算任务，root task 是指在 TiDB 端单点执行的计算任务。一般来讲 root task 的输入数据是来自于 cop task 的；但是 root task 在处理数据的时候，TiKV 上的 cop task 也可以同时处理数据，等待 TiDB 的 root task 拉取，所以从这个观点上来看，他们是并行的；但是存在数据上下游关系；在执行的过程中，某些时间段其实也是并行的，第一个 cop task 在处理 [100, 200] 的数据，第二个 cop task 在处理 [1, 100] 的数据。执行计划的理解，请参考[理解 TiDB 执行计划](/dev/reference/performance/understanding-the-query-execution-plan.md)。 - -## 六、数据库优化 - -### 6.1 TiDB - -#### 6.1.1 TiDB 参数及调整 - -详情参考 [TiDB 配置参数](/dev/reference/configuration/tidb-server/configuration.md)。 - -#### 6.1.2 如何打散热点 - -TiDB 中以 Region 分片来管理数据库，通常来讲，TiDB 的热点指的是 Region 的读写访问热点。而 TiDB 中对于 PK 非整数或没有 PK 的表，可以通过设置 `SHARD_ROW_ID_BITS` 来适度分解 Region 分片，以达到打散 Region 热点的效果。详情可参考官网 [TiDB 专用系统变量和语法](/dev/reference/configuration/tidb-server/tidb-specific-variables.md#shard_row_id_bits)中 `SHARD_ROW_ID_BITS` 的介绍。 - -### 6.2 TiKV - -#### 6.2.1 TiKV 性能参数调优 - -详情参考 [TiKV 性能参数调优](/dev/reference/performance/tune-tikv.md)。 - -## 七、监控 - -### 7.1 Prometheus 监控框架 - -详细参考 [TiDB 监控框架概述](/dev/how-to/monitor/overview.md)。 - -### 7.2 监控指标解读 - -详细参考 [重要监控指标详解](/dev/reference/key-monitoring-metrics/overview-dashboard.md)。 - -#### 7.2.1 目前的监控使用方式及主要监控指标，有没有更好看的监控？ - -TiDB 使用 Prometheus + Grafana 组成 TiDB 数据库系统的监控系统，用户在 Grafana 上通过 dashboard 可以监控到 TiDB 的各类运行指标，包括系统资源的监控指标，包括客户端连接与 SQL 运行的指标，包括内部通信和 Region 调度的指标，通过这些指标，可以让数据库管理员更好的了解到系统的运行状态，运行瓶颈等内容。在监控指标的过程中，我们按照 TiDB 不同的模块，分别列出了各个模块重要的指标项，一般用户只需要关注这些常见的指标项。具体指标请参见[官方文档](/dev/reference/key-monitoring-metrics/overview-dashboard.md)。 - -#### 7.2.2 Prometheus 监控数据默认 15 天自动清除一次，可以自己设定成 2 个月或者手动删除吗？ - -可以的，在 Prometheus 启动的机器上，找到启动脚本，然后修改启动参数，然后重启 Prometheus 生效。 - -```config ---storage.tsdb.retention="60d" -``` - -#### 7.2.3 Region Health 监控项 - -TiDB-2.0 版本中，PD metric 监控页面中，对 Region 健康度进行了监控，其中 Region Health 监控项是对所有 Region 副本状况的一些统计。其中 miss 是缺副本，extra 是多副本。同时也增加了按 Label 统计的隔离级别，level-1 表示这些 Region 的副本在第一级 Label 下是物理隔离的，没有配置 location label 时所有 Region 都在 level-0。 - -#### 7.2.4 Statement Count 监控项中的 selectsimplefull 是什么意思？ - -代表全表扫，但是可能是很小的系统表。 - -#### 7.2.5 监控上的 QPS 和 Statement OPS 有什么区别？ - -QPS 会统计执行的所有 SQL 命令，包括 use database、load data、begin、commit、set、show、insert、select 等。 - -Statement OPS 只统计 select、update、insert 等业务相关的，所以 Statement OPS 的统计和业务比较相符。 - -## 八、Cloud TiDB - -### 8.1 腾讯云 - -#### 8.1.1 目前 Cloud TiDB 都有那些云厂商？ - -Cloud TiDB 目前已经在腾讯云、UCloud 上线，都是数据库一级入口，欢迎大家使用。 - -## 九、故障排除 - -### 9.1 TiDB 自定义报错汇总 - -#### 9.1.1 ERROR 8005 (HY000) : Write Conflict, txnStartTS is stale - -可以检查 `tidb_disable_txn_auto_retry` 是否为 on。如是，将其设置为 off；如已经是 off，将 `tidb_retry_limit` 调大到不再发生该错误。 - -#### 9.1.2 ERROR 9001 (HY000) : PD Server Timeout - -请求 PD 超时，请检查 PD Server 状态/监控/日志以及 TiDB Server 与 PD Server 之间的网络。 - -#### 9.1.3 ERROR 9002 (HY000) : TiKV Server Timeout - -请求 TiKV 超时，请检查 TiKV Server 状态/监控/日志以及 TiDB Server 与 TiKV Server 之间的网络。 - -#### 9.1.4 ERROR 9003 (HY000) : TiKV Server is Busy - -TiKV 操作繁忙，一般出现在数据库负载比较高时，请检查 TiKV Server 状态/监控/日志。 - -#### 9.1.5 ERROR 9004 (HY000) : Resolve Lock Timeout - -清理锁超时，当数据库上承载的业务存在大量的事务冲突时，会遇到这种错误，请检查业务代码是否有锁争用。 - -#### 9.1.6 ERROR 9005 (HY000) : Region is unavailable - -访问的 Region 不可用，某个 Raft Group 不可用，如副本数目不足，出现在 TiKV 比较繁忙或者是 TiKV 节点停机的时候，请检查 TiKV Server 状态/监控/日志。 - -#### 9.1.7 ERROR 9006 (HY000) : GC life time is shorter than transaction duration - -`GC Life Time` 间隔时间过短，长事务本应读到的数据可能被清理了，可使用如下命令增加 `GC Life Time`： - -{{< copyable "sql" >}} - -```sql -update mysql.tidb set variable_value='30m' where variable_name='tikv_gc_life_time'; -``` - -其中 30m 代表仅清理 30 分钟前的数据，这可能会额外占用一定的存储空间。 - -#### 9.1.8 ERROR 9007 (HY000) : Write Conflict - -可以检查 `tidb_disable_txn_auto_retry` 是否为 on。如是，将其设置为 off；如已经是 off，将 `tidb_retry_limit` 调大到不再发生该错误。 - -### 9.2 MySQL 原生报错汇总 - -#### 9.2.1 ERROR 2013 (HY000): Lost connection to MySQL server during query 问题的排查方法？ - -- log 中是否有 panic -- dmesg 中是否有 oom，命令：`dmesg -T | grep -i oom` -- 长时间没有访问，也会收到这个报错，一般是 tcp 超时导致的，tcp 长时间不用, 会被操作系统 kill。 - -#### 9.2.2 ERROR 1105 (HY000): other error: unknown error Wire Error(InvalidEnumValue(4004)) 是什么意思？ - -这类问题一般是 TiDB 和 TiKV 版本不匹配，在升级过程尽量一起升级，避免版本 mismatch。 - -#### 9.2.3 ERROR 1148 (42000): the used command is not allowed with this TiDB version 问题的处理方法？ - -这个问题是因为在执行 `LOAD DATA LOCAL` 语句的时候，MySQL 客户端不允许执行此语句（即 `local_infile` 选项为 0）。解决方法是在启动 MySQL 客户端时，用 `--local-infile=1` 选项。具体启动指令类似：`mysql --local-infile=1 -u root -h 127.0.0.1 -P 4000`。有些 MySQL 客户端需要设置而有些不需要设置，原因是不同版本的 MySQL 客户端对 `local-infile` 的默认值不同。 - -#### 9.2.4 ERROR 9001 (HY000): PD server timeout start timestamp may fall behind safe point - -这个报错一般是 TiDB 访问 PD 出了问题，TiDB 后台有个 worker 会不断地从 PD 查询 safepoint，如果超过 100s 查不成功就会报这个错。一般是因为 PD 磁盘操作过忙、反应过慢，或者 TiDB 和 PD 之间的网络有问题。TiDB 常见错误码请参考[错误码与故障诊断](/dev/reference/error-codes.md)。 - -### 9.3 TiDB 日志中的报错信息 - -#### 9.3.1 EOF - -当客户端或者 proxy 断开连接时，TiDB 不会立刻察觉连接已断开，而是等到开始往连接返回数据时，才发现连接已断开，此时日志会打印 EOF 错误。 diff --git a/dev/faq/upgrade.md b/dev/faq/upgrade.md deleted file mode 100644 index 5e333f4a41a6..000000000000 --- a/dev/faq/upgrade.md +++ /dev/null @@ -1,328 +0,0 @@ ---- -title: 升级后常见问题 -category: FAQ ---- - -# 升级后常见问题 - -本文列出了一些升级后可能会遇到的问题与解决办法。 - -## 执行 DDL 操作时遇到的字符集 (charset) 问题 - -TiDB 在 v2.1.0 以及之前版本（包括 v2.0 所有版本）中，默认字符集是 UTF8。从 v2.1.1 开始，默认字符集变更为 UTF8MB4。如果在 v2.1.0 及之前版本中，建表时显式指定了 table 的 charset 为 UTF8，那么升级到 v2.1.1 之后，执行 DDL 操作可能会失败。 - -要避免该问题，需注意以下两个要点： - -1. 在 v2.1.3 之前，TiDB 不支持修改 column 的 charset。所以，执行 DDL 操作时，新 column 的 charset 需要和旧 column 的 charset 保持一致。 - -2. 在 v2.1.3 之前，即使 column 的 charset 和 table 的 charset 不一样，`show create table` 也不会显示 column 的 charset，但可以通过 HTTP API 获取 table 的元信息来查看 column 的 charset，下文提供了示例。 - -### 问题 1：`unsupported modify column charset utf8mb4 not match origin utf8` - -- 升级前：v2.1.0 及之前版本 - - {{< copyable "sql" >}} - - ```sql - create table t(a varchar(10)) charset=utf8; - ``` - - ``` - Query OK, 0 rows affected - Time: 0.106s - ``` - - {{< copyable "sql" >}} - - ```sql - show create table t - ``` - - ``` - +-------+-------------------------------------------------------+ - | Table | Create Table | - +-------+-------------------------------------------------------+ - | t | CREATE TABLE `t` ( | - | | `a` varchar(10) DEFAULT NULL | - | | ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin | - +-------+-------------------------------------------------------+ - 1 row in set - Time: 0.006s - ``` - -- 升级后：v2.1.1、v2.1.2 会出现下面的问题，v2.1.3 以及之后版本不会出现下面的问题。 - - {{< copyable "sql" >}} - - ```sql - alter table t change column a a varchar(20); - ``` - - ``` - ERROR 1105 (HY000): unsupported modify column charset utf8mb4 not match origin utf8 - ``` - -解决方案：显式指定 column charset，保持和原来的 charset 一致即可。 - -{{< copyable "sql" >}} - -```sql -alter table t change column a a varchar(22) character set utf8; -``` - -- 根据要点 1，此处如果不指定 column 的 charset，会用默认的 UTF8MB4，所以需要指定 column charset 保持和原来一致。 - -- 根据要点 2，用 HTTP API 获取 table 元信息，然后根据 column 名字和 Charset 关键字搜索即可找到 column 的 charset。 - - {{< copyable "shell-regular" >}} - - ```sh - curl "http://$IP:10080/schema/test/t" | python -m json.tool - ``` - - 这里用了 python 的格式化 json的工具，也可以不加，此处只是为了方便注释。 - - ```json - { - "ShardRowIDBits": 0, - "auto_inc_id": 0, - "charset": "utf8", # table 的 charset - "collate": "", - "cols": [ # 从这里开始列举 column 的相关信息 - { - ... - "id": 1, - "name": { - "L": "a", - "O": "a" # column 的名字 - }, - "offset": 0, - "origin_default": null, - "state": 5, - "type": { - "Charset": "utf8", # column a 的 charset - "Collate": "utf8_bin", - "Decimal": 0, - "Elems": null, - "Flag": 0, - "Flen": 10, - "Tp": 15 - } - } - ], - ... - } - ``` - -### 问题 2：`unsupported modify charset from utf8mb4 to utf8` - -- 升级前：v2.1.1，v2.1.2 - - {{< copyable "sql" >}} - - ```sql - create table t(a varchar(10)) charset=utf8; - ``` - - ``` - Query OK, 0 rows affected - Time: 0.109s - ``` - - {{< copyable "sql" >}} - - ```sql - show create table t; - ``` - - ``` - +-------+-------------------------------------------------------+ - | Table | Create Table | - +-------+-------------------------------------------------------+ - | t | CREATE TABLE `t` ( | - | | `a` varchar(10) DEFAULT NULL | - | | ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin | - +-------+-------------------------------------------------------+ - ``` - - 上面 `show create table` 只显示出了 table 的 charset，但其实 column 的 charset 是 UTF8MB4，这可以通过 HTTP API 获取 schema 来确认。这是一个 bug，即此处建表时 column 的 charset 应该要和 table 保持一致为 UTF8，该问题在 v2.1.3 中已经修复。 - -- 升级后：v2.1.3 及之后版本 - - {{< copyable "sql" >}} - - ```sql - show create table t; - ``` - - ``` - +-------+--------------------------------------------------------------------+ - | Table | Create Table | - +-------+--------------------------------------------------------------------+ - | t | CREATE TABLE `t` ( | - | | `a` varchar(10) CHARSET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL | - | | ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin | - +-------+--------------------------------------------------------------------+ - 1 row in set - Time: 0.007s - ``` - - {{< copyable "sql" >}} - - ```sql - alter table t change column a a varchar(20); - ``` - - ``` - ERROR 1105 (HY000): unsupported modify charset from utf8mb4 to utf8 - ``` - -解决方案： - -- 因为在 v2.1.3 之后，TiDB 支持修改 column 和 table 的 charset，所以这里推荐修改 table 的 charset 为 UTF8MB4。 - - {{< copyable "sql" >}} - - ```sql - alter table t convert to character set utf8mb4; - ``` - -- 也可以像问题 1 一样指定 column 的 charset，保持和 column 原来的 charset (UTF8MB4) 一致即可。 - - {{< copyable "sql" >}} - - ```sql - alter table t change column a a varchar(20) character set utf8mb4; - ``` - -### 问题 3：`ERROR 1366 (HY000): incorrect utf8 value f09f8c80(🌀) for column a` - -TiDB 在 v2.1.1 及之前版本中，如果 charset 是 UTF8，没有对 4-byte 的插入数据进行 UTF8 Unicode encoding 检查。在v2.1.2 及之后版本中，添加了该检查。 - -- 升级前：v2.1.1 及之前版本 - - {{< copyable "sql" >}} - - ```sql - create table t(a varchar(100) charset utf8); - ``` - - ``` - Query OK, 0 rows affected - ``` - - {{< copyable "sql" >}} - - ```sql - insert t values (unhex('f09f8c80')); - ``` - - ``` - Query OK, 1 row affected - ``` - -- 升级后：v2.1.2 及之后版本 - - {{< copyable "sql" >}} - - ```sql - insert t values (unhex('f09f8c80')); - ``` - - ``` - ERROR 1366 (HY000): incorrect utf8 value f09f8c80(🌀) for column a - ``` - -解决方案： - -- v2.1.2 版本：该版本不支持修改 column charset，所以只能跳过 UTF8 的检查。 - - {{< copyable "sql" >}} - - ```sql - set @@session.tidb_skip_utf8_check=1; - ``` - - ``` - Query OK, 0 rows affected - ``` - - {{< copyable "sql" >}} - - ```sql - insert t values (unhex('f09f8c80')); - ``` - - ``` - Query OK, 1 row affected - ``` - -- v2.1.3 及之后版本：建议修改 column 的 charset 为 UTF8MB4。或者也可以设置 `tidb_skip_utf8_check` 变量跳过 UTF8 的检查。如果跳过 UTF8 的检查，在需要将数据从 TiDB 同步回 MySQL 的时候，可能会失败，因为 MySQL 会执行该检查。 - - {{< copyable "sql" >}} - - ```sql - alter table t change column a a varchar(100) character set utf8mb4; - ``` - - ``` - Query OK, 0 rows affected - ``` - - {{< copyable "sql" >}} - - ```sql - insert t values (unhex('f09f8c80')); - ``` - - ``` - Query OK, 1 row affected - ``` - - 关于 `tidb_skip_utf8_check` 变量，具体来说是指跳过 UTF8 和 UTF8MB4 类型对数据的合法性检查。如果跳过这个检查，在需要将数据从 TiDB 同步回 MySQL 的时候，可能会失败，因为 MySQL 执行该检查。如果只想跳过 UTF8 类型的检查，可以设置 `tidb_check_mb4_value_in_utf8` 变量。 - - `tidb_check_mb4_value_in_utf8` 在 v2.1.3 版本加入 `config.toml` 文件，可以修改配置文件里面的 `check-mb4-value-in-utf8` 后重启集群生效。 - - `tidb_check_mb4_value_in_utf8` 在 v2.1.5 版本开始可以用 HTTP API 来设置，也可以用 session 变量来设置。 - - * HTTP API（HTTP API 只在单台服务器上生效） - - * 执行下列命令启用 HTTP API： - - {{< copyable "shell-regular" >}} - - ```sh - curl -X POST -d "check_mb4_value_in_utf8=1" http://{TiDBIP}:10080/settings - ``` - - * 执行下列命令禁用 HTTP API： - - {{< copyable "shell-regular" >}} - - ```sh - curl -X POST -d "check_mb4_value_in_utf8=0" http://{TiDBIP}:10080/settings - ``` - - * Session 变量 - - * 执行下列命令启用 Session 变量： - - {{< copyable "sql" >}} - - ```sql - set @@session.tidb_check_mb4_value_in_utf8 = 1; - ``` - - * 执行下列命令禁用 Session 变量： - - {{< copyable "sql" >}} - - ```sql - set @@session.tidb_check_mb4_value_in_utf8 = 0; - ``` - -- v2.1.7 及之后版本，如果对表和 column 的字符集没有严格要求为 UTF8，也不想修改客户端代码去跳过 UTF8 检查或者手动修改 column 的 charset，可以在配置文件中把 `treat-old-version-utf8-as-utf8mb4` 打开。该配置的作用是自动把 v2.1.7 版本之前创建的旧版本的表和 column 的 UTF8 字符集转成 UTF8MB4。这个转换是在 TiDB load schema 时在内存中将 UTF8 转成 UTF8MB4，不会对实际存储的数据做任何修改。在配置文件中关闭 `treat-old-version-utf8-as-utf8mb4` 并重启 TiDB 后，以前字符集为 UTF8 的表和 column 的字符集仍然还是 UTF8。 - - > **注意：** - > - > `treat-old-version-utf8-as-utf8mb4` 参数默认打开，如果客户端强制需要用 UTF8 而不用 UTF8MB4，需要在配置文件中关闭。 diff --git a/dev/how-to/configure/memory-control.md b/dev/how-to/configure/memory-control.md deleted file mode 100644 index 6616a180cfcf..000000000000 --- a/dev/how-to/configure/memory-control.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: TiDB 内存控制文档 -category: how-to ---- - -# TiDB 内存控制文档 - -目前 TiDB 已经能够做到追踪单条 SQL 查询过程中的内存使用情况，当内存使用超过一定阈值后也能采取一些操作来预防 OOM 或者排查 OOM 原因。在 TiDB 的配置文件中，我们可以使用如下配置来控制内存使用超阈值时 TiDB 的行为： - -{{< copyable "" >}} - -``` -# Valid options: ["log", "cancel"] -oom-action = "log" -``` - -- 如果上面的配置项使用的是 "log"，那么当一条 SQL 的内存使用超过一定阈值（由 session 变量 `tidb_mem_quota_query` 来控制）后，TiDB 会在 log 文件中打印一条 LOG，然后这条 SQL 继续执行，之后如果发生了 OOM 可以在 LOG 中找到对应的 SQL。 -- 如果上面的配置项使用的是 "cancel"，那么当一条 SQL 的内存使用超过一定阈值后，TiDB 会立即中断这条 SQL 的执行并给客户端返回一个 error，error 信息中会详细写明这条 SQL 执行过程中各个占用内存比较多的物理执行算子的内存使用情况。 - -## 如何配置一条 SQL 执行过程中的内存使用阈值 - -可以在配置文件中设置每个 Query 默认的 Memory Quota，例如将其设置为 32GB： - -{{< copyable "" >}} - -``` -mem-quota-query = 34359738368 -``` - -此外还可通过如下几个 session 变量来控制一条 Query 中的内存使用，大多数用户只需要设置 `tidb_mem_quota_query` 即可，其他变量是高级配置，大多数用户不需要关心： - -| 变量名 | 作用 | 单位 | 默认值 | -|:-----------------------------------|:---------------------------------------------------|:-------|:-----------| -| tidb_mem_quota_query | 配置整条 SQL 的内存使用阈值 | Byte | 32 << 30 | -| tidb_mem_quota_hashjoin | 配置 Hash Join 的内存使用阈值 | Byte | 32 << 30 | -| tidb_mem_quota_mergejoin | 配置 Merge Join 的内存使用阈值 | Byte | 32 << 30 | -| tidb_mem_quota_sort | 配置 Sort 的内存使用阈值 | Byte | 32 << 30 | -| tidb_mem_quota_topn | 配置 TopN 的内存使用阈值 | Byte | 32 << 30 | -| tidb_mem_quota_indexlookupreader | 配置 Index Lookup Reader 的内存使用阈值 | Byte | 32 << 30 | -| tidb_mem_quota_indexlookupjoin | 配置 Index Lookup Join 的内存使用阈值 | Byte | 32 << 30 | -| tidb_mem_quota_nestedloopapply | 配置 Nested Loop Apply 的内存使用阈值 | Byte | 32 << 30 | - -几个使用例子： - -配置整条 SQL 的内存使用阈值为 8GB： - -{{< copyable "sql" >}} - -```sql -set @@tidb_mem_quota_query = 8 << 30; -``` - -配置整条 SQL 的内存使用阈值为 8MB： - -{{< copyable "sql" >}} - -```sql -set @@tidb_mem_quota_query = 8 << 20; -``` - -配置整条 SQL 的内存使用阈值为 8KB： - -{{< copyable "sql" >}} - -```sql -set @@tidb_mem_quota_query = 8 << 10; -``` diff --git a/dev/how-to/configure/time-zone.md b/dev/how-to/configure/time-zone.md deleted file mode 100644 index 9c515419adde..000000000000 --- a/dev/how-to/configure/time-zone.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -title: 时区支持 -category: how-to ---- - -# 时区支持 - -TiDB 使用的时区由 `time_zone` 全局变量和 session 变量决定。`time_zone` 的默认值是 `System`，`System` 对应的实际时区在 `TiDB` 集群 bootstrap 初始化时设置。具体逻辑如下: - -* 优先使用 `TZ` 环境变量 -* 如果失败，则从 `/etc/localtime` 的实际软链地址提取。 -* 如果上面两种都失败则使用 `UTC` 作为系统时区。 - -在运行过程中可以修改全局时区： - -{{< copyable "sql" >}} - -```sql -SET GLOBAL time_zone = timezone; -``` - -TiDB 还可以通过设置 session 变量 `time_zone` 为每个连接维护各自的时区。默认条件下，这个值取的是全局变量 `time_zone` 的值。修改 session 使用的时区： - -{{< copyable "sql" >}} - -```sql -SET time_zone = timezone; -``` - -查看当前使用的时区的值： - -{{< copyable "sql" >}} - -```sql -SELECT @@global.time_zone, @@session.time_zone; -``` - -设置 `time_zone` 的值的格式： - -* 'SYSTEM' 表明使用系统时间 -* 相对于 UTC 时间的偏移，比如 '+10:00' 或者 '-6:00' -* 某个时区的名字，比如 'Europe/Helsinki'， 'US/Eastern' 或 'MET' - -`NOW()` 和 `CURTIME()` 的返回值都受到时区设置的影响。 - -> **注意：** -> -> 只有 Timestamp 数据类型的值是受时区影响的。可以理解为，Timestamp 数据类型的实际表示使用的是 (字面值 + 时区信息)。其它时间和日期类型，比如 Datetime/Date/Time 是不包含时区信息的，所以也不受到时区变化的影响。 - -{{< copyable "sql" >}} - -{{< copyable "sql" >}} - -```sql -create table t (ts timestamp, dt datetime); -``` - -``` -Query OK, 0 rows affected (0.02 sec) -``` - -{{< copyable "sql" >}} - -```sql -set @@time_zone = 'UTC'; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -insert into t values ('2017-09-30 11:11:11', '2017-09-30 11:11:11'); -``` - -``` -Query OK, 1 row affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -set @@time_zone = '+8:00'; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -select * from t; -``` - -``` -+---------------------|---------------------+ -| ts | dt | -+---------------------|---------------------+ -| 2017-09-30 19:11:11 | 2017-09-30 11:11:11 | -+---------------------|---------------------+ -1 row in set (0.00 sec) -``` - -上面的例子中，无论怎么调整时区的值，Datetime 类型字段的值是不受影响的，而 Timestamp 则随着时区改变，显示的值会发生变化。其实 Timestamp 持久化到存储的值始终没有变化过，只是根据时区的不同显示值不同。 - -Timestamp 类型和 Datetime 等类型的值，两者相互转换的过程中，会涉及到时区。这种情况一律基于 session 的当前 `time_zone` 时区处理。 - -另外，用户在导数据的过程中，也要需注意主库和从库之间的时区设定是否一致。 diff --git a/dev/how-to/deploy/data-migration-with-ansible.md b/dev/how-to/deploy/data-migration-with-ansible.md deleted file mode 100644 index bdb3bdaef8e1..000000000000 --- a/dev/how-to/deploy/data-migration-with-ansible.md +++ /dev/null @@ -1,570 +0,0 @@ ---- -title: 使用 DM-Ansible 部署 DM 集群 -category: how-to ---- - -# 使用 DM-Ansible 部署 DM 集群 - -DM-Ansible 是 PingCAP 基于 [Ansible](https://docs.ansible.com/ansible/latest/index.html) 的 [Playbooks](https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html#about-playbooks) 研发的 DM (Data Migration) 集群部署工具。本文将介绍如何使用 DM-Ansible 快速部署 DM 集群。 - -## 准备工作 - -在开始之前，先确保您准备好了以下配置的机器： - -1. 部署目标机器若干，配置如下： - - - CentOS 7.3 (64-bit) 或更高版本，x86_64 架构（AMD64） - - 机器之间内网互通 - - 关闭防火墙，或开放服务端口 - -2. 一台中控机，配置如下： - - - 包含 Python 2.7 的 CentOS 7.3（64-bit）或更高版本 - - Ansible 2.5 或更高版本 - - 互联网访问 - -## 第 1 步：在中控机上安装依赖包 - -> **注意：** -> -> 请确保使用 `root` 账户登录中控机。 - -根据中控机的操作系统版本，运行相应命令如下： - -- CentOS 7： - - {{< copyable "shell-root" >}} - - ```bash - yum -y install epel-release git curl sshpass && - yum -y install python-pip - ``` - -- Ubuntu： - - {{< copyable "shell-root" >}} - - ```bash - apt-get -y install git curl sshpass python-pip - ``` - -## 第 2 步：在中控机上创建 `tidb` 用户，并生成 SSH 密钥 - -> **注意：** -> -> 请确保使用 `root` 账户登录中控机。 - -1. 创建 `tidb` 用户。 - - {{< copyable "shell-root" >}} - - ```bash - useradd -m -d /home/tidb tidb - ``` - -2. 为 `tidb` 用户设置密码。 - - {{< copyable "shell-root" >}} - - ```bash - passwd tidb - ``` - -3. 在 sudo 文件尾部加上 `tidb ALL=(ALL) NOPASSWD: ALL`，为 `tidb` 用户设置免密使用 sudo。 - - {{< copyable "shell-root" >}} - - ```bash - visudo - ``` - - ``` - tidb ALL=(ALL) NOPASSWD: ALL - ``` - -4. 生成 SSH 密钥。 - - 执行以下 `su` 命令，将登录用户从 `root` 切换至 `tidb`。 - - {{< copyable "shell-root" >}} - - ```bash - su - tidb - ``` - - 为 `tidb` 用户创建 SSH 密钥。当提示 `Enter passphrase` 时，按 Enter 键。命令成功执行后，生成的 SSH 私钥文件为 `/home/tidb/.ssh/id_rsa`，SSH 公钥文件为`/home/tidb/.ssh/id_rsa.pub`。 - - {{< copyable "shell-regular" >}} - - ```bash - ssh-keygen -t rsa - ``` - - ``` - Generating public/private rsa key pair. - Enter file in which to save the key (/home/tidb/.ssh/id_rsa): - Created directory '/home/tidb/.ssh'. - Enter passphrase (empty for no passphrase): - Enter same passphrase again: - Your identification has been saved in /home/tidb/.ssh/id_rsa. - Your public key has been saved in /home/tidb/.ssh/id_rsa.pub. - The key fingerprint is: - SHA256:eIBykszR1KyECA/h0d7PRKz4fhAeli7IrVphhte7/So tidb@172.16.10.49 - The key's randomart image is: - +---[RSA 2048]----+ - |=+o+.o. | - |o=o+o.oo | - | .O.=.= | - | . B.B + | - |o B * B S | - | * + * + | - | o + . | - | o E+ . | - |o ..+o. | - +----[SHA256]-----+ - ``` - -## 第 3 步：下载 DM-Ansible 至中控机 - -> **注意：** -> -> 请确保使用 `tidb` 账户登录中控机。 - -1. 打开 `/home/tidb` 目录。 -2. 执行以下命令下载 DM-Ansible。 - - {{< copyable "shell-regular" >}} - - ```bash - wget https://download.pingcap.org/dm-ansible-{version}.tar.gz - ``` - - `{version}` 为期望下载的 DM 版本，如 `v1.0.1`、`v1.0.2` 等， - 可以通过 [DM Release](https://github.com/pingcap/dm/releases) 查看当前已发布版本。也可以使用 `latest` 替代 `{version}` 来下载最新的未发布版本。 - -## 第 4 步：安装 DM-Ansible 及其依赖至中控机 - -> **注意：** -> -> - 请确保使用 `tidb` 账户登录中控机。 -> - 您需要使用 `pip` 方式下载安装 Ansible 及其依赖，否则可能会遇到兼容性问题。 DM-Ansible 当前与 Ansible 2.5 或更高版本兼容。 - -1. 在中控机上安装 DM-Ansible 及其依赖包： - - {{< copyable "shell-regular" >}} - - ```bash - tar -xzvf dm-ansible-{version}.tar.gz && - mv dm-ansible-{version} dm-ansible && - cd /home/tidb/dm-ansible && - sudo pip install -r ./requirements.txt - ``` - - Ansible 和相关依赖包含于 `dm-ansible/requirements.txt` 文件中。 - -2. 查看 Ansible 版本： - - {{< copyable "shell-regular" >}} - - ```bash - ansible --version - ``` - - ``` - ansible 2.5.0 - ``` - -## 第 5 步：在中控机上配置 SSH 互信和 sudo 规则 - -> **注意：** -> -> 请确保使用 `tidb` 账户登录至中控机。 - -1. 将您部署的目标机器的 IP 地址加至 `hosts.ini` 文件中的 `[servers]` 部分。 - - {{< copyable "shell-regular" >}} - - ```bash - cd /home/tidb/dm-ansible && - vi hosts.ini - ``` - - ``` - [servers] - 172.16.10.71 - 172.16.10.72 - 172.16.10.73 - - [all:vars] - username = tidb - ``` - -2. 运行如下命令，然后输入部署目标机器的 `root` 用户密码。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook -i hosts.ini create_users.yml -u root -k - ``` - - 该步骤将在部署目标机器上创建 `tidb` 用户，创建 sudo 规则，并为中控机和部署目标机器之间配置 SSH 互信。 - -## 第 6 步：下载 DM 及监控组件安装包至中控机 - -> **注意：** -> -> 请确保中控机接入互联网。 - -在中控机上，运行如下命令： - -{{< copyable "shell-regular" >}} - -```bash -ansible-playbook local_prepare.yml -``` - -## 第 7 步：编辑 `inventory.ini` 配置文件 - -> **注意：** -> -> 请确保使用 `tidb` 账户登录中控机。 - -打开并编辑 `/home/tidb/dm-ansible/inventory.ini` 文件如下，以管控 DM 集群。 - -```ini -dm_worker1 ansible_host=172.16.10.72 server_id=101 source_id="mysql-replica-01" mysql_host=172.16.10.81 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 -``` - -根据场景需要，您可以在以下两种集群拓扑中任选一种： - -- [单节点上单个 DM-worker 实例的集群拓扑](#选项-1使用单节点上单个-dm-worker-实例的集群拓扑) -- [单节点上多个 DM-worker 实例的集群拓扑](#选项-2使用单节点上多个-dm-worker-实例的集群拓扑) - -通常情况下，我们推荐每个节点上部署单个 DM-Worker 实例。但如果您的机器拥有性能远超 [TiDB 软件和硬件环境要求](/dev/how-to/deploy/hardware-recommendations.md)中推荐配置的 CPU 和内存，并且每个节点配置 2 块以上的硬盘或大于 2T 的 SSD，您可以在单个节点上部署不超过 2 个 DM-Worker 实例。 - -### 选项 1：使用单节点上单个 DM-Worker 实例的集群拓扑 - -| 节点 | 主机 IP | 服务 | -| ---- | ------- | -------- | -| node1 | 172.16.10.71 | DM-master, Prometheus, Grafana, Alertmanager, DM Portal | -| node2 | 172.16.10.72 | DM-worker1 | -| node3 | 172.16.10.73 | DM-worker2 | -| mysql-replica-01| 172.16.10.81 | MySQL | -| mysql-replica-02| 172.16.10.82 | MySQL | - -```ini -# DM 模块 -[dm_master_servers] -dm_master ansible_host=172.16.10.71 - -[dm_worker_servers] -dm_worker1 ansible_host=172.16.10.72 server_id=101 source_id="mysql-replica-01" mysql_host=172.16.10.81 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 - -dm_worker2 ansible_host=172.16.10.73 server_id=102 source_id="mysql-replica-02" mysql_host=172.16.10.82 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 - -[dm_portal_servers] -dm_portal ansible_host=172.16.10.71 - -# 监控模块 -[prometheus_servers] -prometheus ansible_host=172.16.10.71 - -[grafana_servers] -grafana ansible_host=172.16.10.71 - -[alertmanager_servers] -alertmanager ansible_host=172.16.10.71 - -# 全局变量 -[all:vars] -cluster_name = test-cluster - -ansible_user = tidb - -dm_version = {version} - -deploy_dir = /data1/dm - -grafana_admin_user = "admin" -grafana_admin_password = "admin" -``` - -`{version}` 为当前 DM-Ansible 对应的版本号。关于 DM-worker 参数的更多信息，请参考 [DM-worker 配置及参数描述](#dm-worker-配置及参数描述)。 - -### 选项 2：使用单节点上多个 DM-worker 实例的集群拓扑 - -| 节点 | 主机 IP | 服务 | -| ---- | ------- | -------- | -| node1 | 172.16.10.71 | DM-master, Prometheus, Grafana, Alertmanager, DM Portal | -| node2 | 172.16.10.72 | DM-worker1-1, DM-worker1-2 | -| node3 | 172.16.10.73 | DM-worker2-1, DM-worker2-2 | - -编辑 `inventory.ini` 文件时，请注意区分这些变量：`server_id`，`deploy_dir`，和 `dm_worker_port`。 - -```ini -# DM 模块 -[dm_master_servers] -dm_master ansible_host=172.16.10.71 - -[dm_worker_servers] -dm_worker1_1 ansible_host=172.16.10.72 server_id=101 deploy_dir=/data1/dm_worker dm_worker_port=8262 mysql_host=172.16.10.81 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 -dm_worker1_2 ansible_host=172.16.10.72 server_id=102 deploy_dir=/data2/dm_worker dm_worker_port=8263 mysql_host=172.16.10.82 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 - -dm_worker2_1 ansible_host=172.16.10.73 server_id=103 deploy_dir=/data1/dm_worker dm_worker_port=8262 mysql_host=172.16.10.83 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 -dm_worker2_2 ansible_host=172.16.10.73 server_id=104 deploy_dir=/data2/dm_worker dm_worker_port=8263 mysql_host=172.16.10.84 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 - -[dm_portal_servers] -dm_portal ansible_host=172.16.10.71 - -# 监控模块 -[prometheus_servers] -prometheus ansible_host=172.16.10.71 - -[grafana_servers] -grafana ansible_host=172.16.10.71 - -[alertmanager_servers] -alertmanager ansible_host=172.16.10.71 - -# 全局变量 -[all:vars] -cluster_name = test-cluster - -ansible_user = tidb - -dm_version = {version} - -deploy_dir = /data1/dm - -grafana_admin_user = "admin" -grafana_admin_password = "admin" -``` - -`{version}` 为当前 DM-Ansible 对应的版本号。 - -### DM-worker 配置及参数描述 - -| 变量名称 | 描述 | -| ------------- | ------- -| source_id | DM-worker 绑定到的一个数据库实例或是具有主从架构的复制组。当发生主从切换的时候，只需要更新 `mysql_host` 或 `mysql_port` 而不用更改该 ID 标识。 | -| server_id | DM-worker 伪装成一个 MySQL slave，该变量即为这个 slave 的 server ID，在 MySQL 集群中需保持全局唯一。取值范围 0 ~ 4294967295。v1.0.2 及以上版本的 DM 会自动生成，不需要手动配置。 | -| mysql_host | 上游 MySQL 主机。 | -| mysql_user | 上游 MySQL 用户名，默认值为 “root”。| -| mysql_password | 上游 MySQL 用户密码，需使用 `dmctl` 工具加密。请参考[使用 dmctl 加密上游 MySQL 用户密码](#使用-dmctl-加密上游-mysql-用户密码)。 | -| mysql_port | 上游 MySQL 端口， 默认 3306。 | -| enable_gtid | DM-worker 是否使用全局事务标识符（GTID）拉取 binlog。使用前提是在上游 MySQL 已开启 GTID 模式。 | -| relay_binlog_name | DM-worker 是否从指定 binlog 文件位置开始拉取 binlog。仅适用于本地无有效 relay log 的情况。v1.0.2 及以上版本的 DM 会默认从最新位置开始拉取 binlog，一般情况下不需要手动配置。| -| relay_binlog_gtid | DM-worker 是否从指定 GTID 位置开始拉取 binlog。仅适用于本地无有效 relay log，且 `enable_gtid` 设置为 true 的情况。v1.0.2 及以上版本的 DM 会默认从最新位置开始拉取 binlog，一般情况下不需要手动配置。 | -| flavor | 代表 MySQL 的版本发布类型。 如果是官方版本，Percona 版，或 Cloud MySQL 版，其值为 “mysql”。 如果是 MariaDB，其值为 "mariadb"。默认值是 "mysql"。v1.0.2 及以上版本的 DM 会自动判断上游版本，不需要手动配置。 | - -关于 `deploy_dir` 配置的更多信息，请参考[配置部署目录](#配置部署目录)。 - -### 使用 dmctl 加密上游 MySQL 用户密码 - -假定上游 MySQL 的用户密码为 `123456`，运行以下命令，并将生成的字符串添加至 DM-worker 的 `mysql_password` 变量。 - -{{< copyable "shell-regular" >}} - -```bash -cd /home/tidb/dm-ansible/resources/bin && -./dmctl -encrypt 123456 -``` - -``` -VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU= -``` - -## 第 8 步：编辑 `inventory.ini` 文件中的变量 - -此步介绍如何编辑部署目录中的变量，如何配置 relay log 同步位置以及 relay log GTID 的同步模式。此外，还会描述 `inventory.ini` 中的全局变量。 - -### 配置部署目录 - -编辑 `deploy_dir` 变量以配置部署目录。 - -- 全局变量默认设为 `/home/tidb/deploy`，适用于所有服务。如果数据盘挂载于 `/data1` 目录，您可以通过以下修改将其变更至 `/data1/dm`。 - - ```ini - ## Global variables. - [all:vars] - deploy_dir = /data1/dm - ``` - -- 如果需要为某个服务创建单独的部署目录，您可以在 `inventory.ini` 中配置服务主机列表的同时设置 host 变量。此操作需要您添加第一列别名，以避免在混合服务部署场景下产生混淆。 - - ```ini - dm-master ansible_host=172.16.10.71 deploy_dir=/data1/deploy - ``` - -### 配置 relay log 同步位置 - -首次启动 DM-worker 时，您需要配置 `relay_binlog_name` 变量以指定 DM-worker 拉取上游 MySQL 或 MariaDB binlog 的起始位置。 - -```yaml -[dm_worker_servers] -dm-worker1 ansible_host=172.16.10.72 source_id="mysql-replica-01" server_id=101 relay_binlog_name="binlog.000011" mysql_host=172.16.10.81 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 - -dm-worker2 ansible_host=172.16.10.73 source_id="mysql-replica-02" server_id=102 relay_binlog_name="binlog.000002" mysql_host=172.16.10.82 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 -``` - -> **注意：** -> -> 如未设定 `relay_binlog_name`，v1.0.2 之前版本的 DM-worker 将从上游 MySQL 或 MariaDB 现有最早时间点的 binlog 文件开始拉取 binlog，拉取到数据同步任务需要的最新 binlog 可能需要很长时间；v1.0.2 及之后版本的 DM-worker 将从最新时间点的 binlog 文件开始拉取 binlog，一般情况下不需要手动配置。 - -### 开启 relay log GTID 同步模式 - -在 DM 集群中，DM-worker 的 relay log 处理单元负责与上游 MySQL 或 MariaDB 通信，从而将 binlog 拉取至本地文件系统。 - -DM 目前支持 MySQL GTID 和 MariaDB GTID。您可以通过配置以下项目开启 relay log GTID 同步模式： - -- `enable_gtid`：打开 relay log GTID 同步模式以处理 master 和 slave 易位的场景 - -- `relay_binlog_gtid`：指定 DM-worker 开始拉取对应上游 MySQL 或 MariaDB binlog 的起始位置 - -示例配置如下： - -```yaml -[dm_worker_servers] -dm-worker1 ansible_host=172.16.10.72 source_id="mysql-replica-01" server_id=101 enable_gtid=true relay_binlog_gtid="aae3683d-f77b-11e7-9e3b-02a495f8993c:1-282967971,cc97fa93-f5cf-11e7-ae19-02915c68ee2e:1-284361339" mysql_host=172.16.10.81 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 - -dm-worker2 ansible_host=172.16.10.73 source_id="mysql-replica-02" server_id=102 relay_binlog_name=binlog.000002 mysql_host=172.16.10.82 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 -``` - -### 全局变量 - -| 变量名称 | 描述 | -| --------------- | ---------------------------------------------------------- | -| cluster_name | 集群名称，可调整 | -| dm_version | DM 版本，默认已配置 | -| grafana_admin_user | Grafana 管理员用户名称，默认值 `admin` | -| grafana_admin_password | Grafana 管理员账户的密码，用于通过 Ansible 导入 Dashboard。默认值为 `admin`。如果您在 Grafana 网页端修改了密码，请更新此变量。 | - -## 第 9 步：部署 DM 集群 - -使用 `ansible-playbook` 运行 Playbook，默认并发数量是 5。如果部署目标机器较多，您可以使用 `-f` 参数增加并发数量，例如，`ansible-playbook deploy.yml -f 10`。 - -以下部署操作示例使用中运行服务的用户为 `tidb`： - -1. 编辑 `dm-ansible/inventory.ini` 文件，确保 `ansible_user = tidb`。 - - ```ini - ansible_user = tidb - ``` - - > **注意：** - > - > 请勿将 `ansible_user` 设为 `root`，因为 `tidb-ansible` 限制服务需以普通用户运行。 - - 运行以下命令。如果所有服务都返回 `tidb`，则 SSH 互信配置成功。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible -i inventory.ini all -m shell -a 'whoami' - ``` - - 运行以下命令。如果所有服务都返回 `root`，则 `tidb` 用户免密 sudo 操作配置成功。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible -i inventory.ini all -m shell -a 'whoami' -b - ``` - -2. 修改内核参数，并部署 DM 集群组件和监控组件。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook deploy.yml - ``` - -3. 启动 DM 集群。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook start.yml - ``` - - 此操作会按顺序启动 DM 集群的所有组件，包括 DM-master，DM-worker，以及监控组件。当一个 DM 集群被关闭后，您可以使用该命令将其开启。 - -## 第 10 步：关闭 DM 集群 - -如果您需要关闭一个 DM 集群，运行以下命令： - -{{< copyable "shell-regular" >}} - -```bash -ansible-playbook stop.yml -``` - -该操作会按顺序关闭整个 DM 集群中的所有组件，包括 DM-master，DM-worker，以及监控组件。 - -## 常见部署问题 - -### 默认服务端口 - -| 组件 | 端口变量 | 默认端口 | 描述 | -| :-- | :-- | :-- | :-- | -| DM-master | `dm_master_port` | 8261 | DM-master 服务交流端口 | -| DM-worker | `dm_worker_port` | 8262 | DM-worker 服务交流端口 | -| Prometheus | `prometheus_port` | 9090 | Prometheus 服务交流端口 | -| Grafana | `grafana_port` | 3000 | 外部 Web 监控服务及客户端（浏览器）访问端口 | -| Alertmanager | `alertmanager_port` | 9093 | Alertmanager 服务交流端口 | - -### 自定义端口 - -编辑 `inventory.ini` 文件，将服务端口的相关主机变量添加在对应服务 IP 地址后： - -```ini -dm_master ansible_host=172.16.10.71 dm_master_port=18261 -``` - -### 更新 DM-Ansible - -1. 使用 `tidb` 账户登录至中控机，进入 `/home/tidb` 目录，然后备份`dm-ansible` 文件夹。 - - {{< copyable "shell-regular" >}} - - ```bash - cd /home/tidb && \ - mv dm-ansible dm-ansible-bak - ``` - -2. 下载指定版本 DM-Ansible，解压。 - - {{< copyable "shell-regular" >}} - - ```bash - cd /home/tidb && \ - wget https://download.pingcap.org/dm-ansible-{version}.tar.gz && \ - tar -xzvf dm-ansible-{version}.tar.gz && \ - mv dm-ansible-{version} dm-ansible - ``` - -3. 迁移 `inventory.ini` 配置文件。 - - {{< copyable "shell-regular" >}} - - ```bash - cd /home/tidb && \ - cp dm-ansible-bak/inventory.ini dm-ansible/inventory.ini - ``` - -4. 迁移 `dmctl` 配置。 - - {{< copyable "shell-regular" >}} - - ```bash - cd /home/tidb/dm-ansible-bak/dmctl && \ - cp * /home/tidb/dm-ansible/dmctl/ - ``` - -5. 用 Playbook 下载最新的 DM 二进制文件。此文件会自动替换 `/home/tidb/dm-ansible/resource/bin/` 目录下的二进制文件。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook local_prepare.yml - ``` diff --git a/dev/how-to/deploy/geographic-redundancy/location-awareness.md b/dev/how-to/deploy/geographic-redundancy/location-awareness.md deleted file mode 100644 index 9047a34424a7..000000000000 --- a/dev/how-to/deploy/geographic-redundancy/location-awareness.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: 集群拓扑信息配置 -category: how-to ---- - -# 集群拓扑信息配置 - -## 概述 - -PD 能够根据 TiKV 集群的拓扑结构进行调度，使得 TiKV 的容灾能力最大化。 - -阅读本章前，请先确保阅读 [Ansible 部署方案](/dev/how-to/deploy/orchestrated/ansible.md) 和 [Docker 部署方案](/dev/how-to/deploy/orchestrated/docker.md)。 - -## TiKV 上报拓扑信息 - -可以通过 TiKV 的启动参数或者配置文件来让 TiKV 上报拓扑信息给 PD。 - -假设拓扑结构分为三级：zone > rack > host，可以通过 labels 来指定这些信息。 - -启动参数： - -``` -tikv-server --labels zone=,rack=,host= -``` - -配置文件： - -{{< copyable "" >}} - -```toml -[server] -labels = "zone=,rack=,host=" -``` - -## PD 理解 TiKV 拓扑结构 - -可以通过 PD 的配置文件让 PD 理解 TiKV 集群的拓扑结构。 - -{{< copyable "" >}} - -```toml -[replication] -max-replicas = 3 -location-labels = ["zone", "rack", "host"] -``` - -其中 `location-labels` 需要与 TiKV 的 `labels` 名字对应，这样 PD 才能知道这些 `labels` 代表了 TiKV 的拓扑结构。 - -> **注意：** -> -> 必须同时配置 PD 的 `location-labels` 和 TiKV 的 `labels` 参数，否则 `labels` 不会生效。 - -## PD 基于 TiKV 拓扑结构进行调度 - -PD 能够根据我们提供的拓扑信息作出最优的调度，我们只需要关心什么样的拓扑结构能够达到我们想要的效果。 - -假设我们使用三副本，并且希望一个数据中心挂掉的情况下，还能继续保持 TiDB 集群的高可用状态，我们至少需要四个数据中心。 - -假设我们有四个数据中心 (zone)，每个数据中心有两个机架 (rack)，每个机架上有两个主机 (host)。 -每个主机上面启动一个 TiKV 实例： - -``` -# zone=z1 -tikv-server --labels zone=z1,rack=r1,host=h1 -tikv-server --labels zone=z1,rack=r1,host=h2 -tikv-server --labels zone=z1,rack=r2,host=h1 -tikv-server --labels zone=z1,rack=r2,host=h2 - -# zone=z2 -tikv-server --labels zone=z2,rack=r1,host=h1 -tikv-server --labels zone=z2,rack=r1,host=h2 -tikv-server --labels zone=z2,rack=r2,host=h1 -tikv-server --labels zone=z2,rack=r2,host=h2 - -# zone=z3 -tikv-server --labels zone=z3,rack=r1,host=h1 -tikv-server --labels zone=z3,rack=r1,host=h2 -tikv-server --labels zone=z3,rack=r2,host=h1 -tikv-server --labels zone=z3,rack=r2,host=h2 - -# zone=z4 -tikv-server --labels zone=z4,rack=r1,host=h1 -tikv-server --labels zone=z4,rack=r1,host=h2 -tikv-server --labels zone=z4,rack=r2,host=h1 -tikv-server --labels zone=z4,rack=r2,host=h2 -``` - -也就是说，我们有 16 个 TiKV 实例，分布在 4 个不同的数据中心，8 个不同的机架，16 个不同的机器。 - -在这种拓扑结构下，PD 会优先把每一份数据的不同副本调度到不同的数据中心。 -这时候如果其中一个数据中心挂了，不会影响 TiDB 集群的高可用状态。 -如果这个数据中心一段时间内恢复不了，PD 会把这个数据中心的副本迁移出去。 - -总的来说，PD 能够根据当前的拓扑结构使得集群容灾能力最大化，所以如果我们希望达到某个级别的容灾能力， -就需要根据拓扑机构在不同的地理位置提供多于备份数 (`max-replicas`) 的机器。 diff --git a/dev/how-to/deploy/geographic-redundancy/overview.md b/dev/how-to/deploy/geographic-redundancy/overview.md deleted file mode 100644 index 80daae48a75e..000000000000 --- a/dev/how-to/deploy/geographic-redundancy/overview.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: 跨数据中心部署方案 -category: how-to ---- - -# 跨数据中心部署方案 - -作为 NewSQL 数据库，TiDB 兼顾了传统关系型数据库的优秀特性以及 NoSQL 数据库可扩展性，以及跨数据中心（下文简称“中心”）场景下的高可用。本文档旨在介绍跨数据中心部署的不同解决方案。 - -## 三中心部署方案 - -TiDB, TiKV, PD 分别分布在 3 个不同的中心，这是最常规，可用性最高的方案。 - -![三中心部署](/media/deploy-3dc.png) - -### 优点 - -所有数据的副本分布在三个数据中心，任何一个数据中心失效后，另外两个数据中心会自动发起 leader election，并在合理长的时间内（通常情况 20s 以内）恢复服务，并且不会产生数据丢失。 - -![三中心部署容灾](/media/deploy-3dc-dr.png) - -### 缺点 - -性能受网络延迟影响。 - -- 对于写入的场景，所有写入的数据需要同步复制到至少 2 个数据中心，由于 TiDB 写入过程使用两阶段提交，故写入延迟至少需要 2 倍数据中心间的延迟。 -- 对于读请求来说，如果数据 leader 与发起读取的 TiDB 节点不在同一个数据中心，也会受网络延迟影响。 -- TiDB 中的每个事务都需要向 PD leader 获取 TSO，当 TiDB 与 PD leader 不在同一个数据中心时，它上面运行的事务也会因此受网络延迟影响，每个有写入的事务会获取两次 TSO。 - -### 读性能优化 - -如果不需要每个数据中心同时对外提供服务，可以将业务流量全部派发到一个数据中心，并通过调度策略把 Region leader 和 PD leader 都迁移到同一个数据中心（我们在上文所述的测试中也做了这个优化）。这样一来，不管是从 PD 获取 TSO 还是读取 Region 都不受数据中心间网络的影响。当该数据中心失效后，PD leader 和 Region leader 会自动在其它数据中心选出，只需要把业务流量转移至其他存活的数据中心即可。 - -![三中心部署读性能优化](/media/deploy-3dc-optimize.png) - -## 两地三中心部署方案 - -两地三中心的方案与三数据中心类似，算是三机房方案根据业务特点进行的优化，区别是其中有两个数据中心距离很近（通常在同一个城市），网络延迟相对很小。这种场景下，我们可以把业务流量同时派发到同城的两个数据中心，同时控制 Region leader 和 PD leader 也分布在同城的两个数据中心。 - -![两地三中心部署方案](/media/deploy-2city3dc.png) - -与三数据中心方案相比，两地三中心有以下优势： - -- 写入速度更优 -- 两中心同时提供服务资源利用率更高 -- 依然能保证任何一个数据中心失效后保持可用并且不发生数据丢失 - -但是，缺陷是如果同城的两个数据中心同时失效（理论上讲要高于异地三数据中心损失 2 个的概率），将会导致不可用以及部分数据丢失。 - -## 两数据中心 + binlog 同步方案 - -两数据中心 + binlog 同步类似于传统的 MySQL 中 master/slave 方案。两个数据中心分别部署一套完整的 TiDB 集群，我们称之为主集群和从集群。正常情况下所有的请求都在主集群，写入的数据通过 binlog 异步同步至从集群并写入。 - -![binlog 同步部署方案](/media/deploy-binlog.png) - -当主集群整个数据中心失效后，业务可以切换至从集群，与 MySQL 类似，这种情况下会有一些数据缺失。对比 MySQL，这个方案的优势是数据中心内的 HA -- 少部分节点故障时，通过重新选举 leader 自动恢复服务，不需要人工干预。 - -![两中心 binlog 相互备份方案](/media/deploy-backup.png) - -另外部分用户采用这种方式做双数据中心多活，两个数据中心各有一个集群，将业务分为两个库，每个库服务一部分数据，每个数据中心的业务只会访问一个库，两个集群之间通过 binlog 将本数据中心业务所涉及的库中的数据变更同步到对端机房，形成环状备份。 - -> **注意：** -> -> 在两数据中心 + binlog 同步部署方案中，数据中心之间只有 binlog 异步复制。在数据中心间的延迟较高的情况下，从集群落后主集群的数据量会增大。当主集群故障后（DR），会造成数据丢失，丢失的数据量受网络延迟等因素影响。 - -## 高可用和容灾分析 - -对于三数据中心方案和两地三中心方案，我们能得到的保障是任意一个数据中心故障时，集群能自动恢复服务，不需要人工介入，并能保证数据一致性。注意各种调度策略都是用于帮助性能优化的，当发生故障时调度机制总是第一优先考虑可用性而不是性能。 - -对于两数据中心 + binlog 同步的方案，主集群内少量节点故障时也能自动恢复服务，不需要人工介入，并能保证数据一致性。当整个主集群故障时，需要人工切换至从集群，并可能发生一些数据丢失，数据丢失的数量取决于同步延迟，和网络条件有关。 diff --git a/dev/how-to/deploy/hardware-recommendations.md b/dev/how-to/deploy/hardware-recommendations.md deleted file mode 100644 index 335f609f8dc2..000000000000 --- a/dev/how-to/deploy/hardware-recommendations.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: TiDB 软件和硬件环境建议配置 -category: how-to ---- - -# TiDB 软件和硬件环境建议配置 - -TiDB 作为一款开源分布式 NewSQL 数据库，可以很好的部署和运行在 Intel 架构服务器环境及主流虚拟化环境，并支持绝大多数的主流硬件网络。作为一款高性能数据库系统，TiDB 支持主流的 Linux 操作系统环境。 - -## Linux 操作系统版本要求 - -| Linux 操作系统平台 | 版本 | -| :----------------------- | :----------: | -| Red Hat Enterprise Linux | 7.3 及以上 | -| CentOS | 7.3 及以上 | -| Oracle Enterprise Linux | 7.3 及以上 | -| Ubuntu LTS | 16.04 及以上 | - -> **注意：** -> -> - TiDB 只支持 Red Hat 兼容内核 (RHCK) 的 Oracle Enterprise Linux，不支持 Oracle Enterprise Linux 提供的 Unbreakable Enterprise Kernel。 -> - TiDB 在 CentOS 7.3 的环境下进行过大量的测试，同时社区也有很多该操作系统部署的最佳实践，因此，建议使用 CentOS 7.3 以上的 Linux 操作系统来部署 TiDB。 -> - 以上 Linux 操作系统可运行在物理服务器以及 VMware、KVM、XEN 主流虚拟化环境上。 - -## 服务器建议配置 - -TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器平台。对于开发，测试，及生产环境的服务器硬件配置有以下要求和建议： - -### 开发及测试环境 - -| **组件** | **CPU** | **内存** | **本地存储** | **网络** | **实例数量(最低要求)** | -| --- | --- | --- | --- | --- | --- | -| TiDB | 8核+ | 16 GB+ | 无特殊要求 | 千兆网卡 | 1（可与 PD 同机器） | -| PD | 4核+ | 8 GB+ | SAS, 200 GB+ | 千兆网卡 | 1（可与 TiDB 同机器） | -| TiKV | 8核+ | 32 GB+ | SSD, 200 GB+ | 千兆网卡 | 3 | - -> **注意：** -> -> - 验证测试环境中的 TiDB 和 PD 可以部署在同一台服务器上。 -> - 如进行性能相关的测试，避免采用低性能存储和网络硬件配置，防止对测试结果的正确性产生干扰。 -> - TiKV 的 SSD 盘推荐使用 NVME 接口以保证读写更快。 -> - 如果仅验证功能，建议使用 [Docker Compose 部署方案](/dev/how-to/get-started/deploy-tidb-from-docker-compose.md)单机进行测试。 -> - TiDB 对于磁盘的使用以存放日志为主，因此在测试环境中对于磁盘类型和容量并无特殊要求。 - -### 生产环境 - -| **组件** | **CPU** | **内存** | **硬盘类型** | **网络** | **实例数量(最低要求)** | -| --- | --- | --- | --- | --- | --- | -| TiDB | 16核+ | 32 GB+ | SAS | 万兆网卡（2块最佳） | 2 | -| PD | 4核+ | 8 GB+ | SSD | 万兆网卡（2块最佳） | 3 | -| TiKV | 16核+ | 32 GB+ | SSD | 万兆网卡（2块最佳） | 3 | -| 监控 | 8核+ | 16 GB+ | SAS | 千兆网卡 | 1 | - -> **注意：** -> -> - 生产环境中的 TiDB 和 PD 可以部署和运行在同服务器上，如对性能和可靠性有更高的要求，应尽可能分开部署。 -> - 生产环境强烈推荐使用更高的配置。 -> - TiKV 硬盘大小配置建议 PCI-E SSD 不超过 2 TB，普通 SSD 不超过 1.5 TB。 - -## 网络要求 - -TiDB 作为开源分布式 NewSQL 数据库，其正常运行需要网络环境提供如下的网络端口配置要求，管理员可根据实际环境中 TiDB 组件部署的方案，在网络侧和主机侧开放相关端口： - -| 组件 | 默认端口 | 说明 | -| :-- | :-- | :-- | -| TiDB | 4000 | 应用及 DBA 工具访问通信端口 | -| TiDB | 10080 | TiDB 状态信息上报通信端口 | -| TiKV | 20160 | TiKV 通信端口 | -| PD | 2379 | 提供 TiDB 和 PD 通信端口 | -| PD | 2380 | PD 集群节点间通信端口 | -| Pump | 8250 | Pump 通信端口 | -| Drainer | 8249 | Drainer 通信端口 | -| Prometheus | 9090 | Prometheus 服务通信端口 | -| Pushgateway | 9091 | TiDB，TiKV，PD 监控聚合和上报端口 | -| Node_exporter | 9100 | TiDB 集群每个节点的系统信息上报通信端口 | -| Blackbox_exporter | 9115 | Blackbox_exporter 通信端口，用于 TiDB 集群端口监控 | -| Grafana | 3000 | Web 监控服务对外服务和客户端(浏览器)访问端口 | -| Grafana | 8686 | grafana_collector 通信端口，用于将 Dashboard 导出为 PDF 格式 | -| Kafka_exporter | 9308 | Kafka_exporter 通信端口，用于监控 binlog kafka 集群 | - -## 客户端 Web 浏览器要求 - -TiDB 提供了基于 [Grafana](https://grafana.com/) 的技术平台，对数据库集群的各项指标进行可视化展现。采用支持 Javascript 的微软 IE、Google Chrome、Mozilla Firefox 的较新版本即可访问监控入口。 diff --git a/dev/how-to/deploy/orchestrated/ansible.md b/dev/how-to/deploy/orchestrated/ansible.md deleted file mode 100644 index eb40e6ca1633..000000000000 --- a/dev/how-to/deploy/orchestrated/ansible.md +++ /dev/null @@ -1,966 +0,0 @@ ---- -title: 使用 TiDB Ansible 部署 TiDB 集群 -category: how-to ---- - -# 使用 TiDB Ansible 部署 TiDB 集群 - -## 概述 - -Ansible 是一款自动化运维工具，[TiDB Ansible](https://github.com/pingcap/tidb-ansible) 是 PingCAP 基于 Ansible playbook 功能编写的集群部署工具。本文档介绍如何使用 TiDB Ansible 部署一个完整的 TiDB 集群。 - -本部署工具可以通过配置文件设置集群拓扑，完成以下各项运维工作： - -- 初始化操作系统参数 -- 部署 TiDB 集群（包括 PD、TiDB、TiKV 等组件和监控组件） -- [启动集群](/dev/how-to/maintain/ansible-operations.md#启动集群) -- [关闭集群](/dev/how-to/maintain/ansible-operations.md#关闭集群) -- [变更组件配置](/dev/how-to/upgrade/from-previous-version.md#编辑-tidb-集群组件配置文件) -- [集群扩容缩容](/dev/how-to/scale/with-ansible.md) -- [升级组件版本](/dev/how-to/upgrade/from-previous-version.md#滚动升级-tidb-集群组件) -- [集群开启 binlog](/dev/reference/tidb-binlog/overview.md) -- [清除集群数据](/dev/how-to/maintain/ansible-operations.md#清除集群数据) -- [销毁集群](/dev/how-to/maintain/ansible-operations.md#销毁集群) - -> **注意：** -> -> 对于生产环境，须使用 TiDB Ansible 部署 TiDB 集群。如果只是用于测试 TiDB 或体验 TiDB 的特性，建议[使用 Docker Compose 在单机上快速部署 TiDB 集群](/dev/how-to/get-started/deploy-tidb-from-docker-compose.md)。 - -## 准备机器 - -1. 部署目标机器若干 - - - 建议 4 台及以上，TiKV 至少 3 实例，且与 TiDB、PD 模块不位于同一主机，详见[部署建议](/dev/how-to/deploy/hardware-recommendations.md)。 - - 推荐安装 CentOS 7.3 及以上版本 Linux 操作系统，x86_64 架构 (amd64)。 - - 机器之间内网互通。 - - > **注意：** - > - > 使用 Ansible 方式部署时，TiKV 及 PD 节点数据目录所在磁盘请使用 SSD 磁盘，否则无法通过检测。** 如果仅验证功能，建议使用 [Docker Compose 部署方案](/dev/how-to/get-started/deploy-tidb-from-docker-compose.md)单机进行测试。 - -2. 部署中控机一台 - - - 中控机可以是部署目标机器中的某一台。 - - 推荐安装 CentOS 7.3 及以上版本 Linux 操作系统（默认包含 Python 2.7）。 - - 该机器需开放外网访问，用于下载 TiDB 及相关软件安装包。 - -## 第 1 步：在中控机上安装系统依赖包 - -以 `root` 用户登录中控机，然后根据操作系统类型执行相应的安装命令。 - -- 如果中控机使用的是 CentOS 7 系统，执行以下命令： - - {{< copyable "shell-root" >}} - - ```bash - yum -y install epel-release git curl sshpass && \ - yum -y install python2-pip - ``` - -- 如果中控机使用的是 Ubuntu 系统，执行以下命令： - - {{< copyable "shell-root" >}} - - ```bash - apt-get -y install git curl sshpass python-pip - ``` - -## 第 2 步：在中控机上创建 `tidb` 用户，并生成 SSH key - -以 `root` 用户登录中控机，执行以下步骤： - -1. 创建 `tidb` 用户。 - - {{< copyable "shell-root" >}} - - ```bash - useradd -m -d /home/tidb tidb - ``` - -2. 设置 `tidb` 用户密码。 - - {{< copyable "shell-root" >}} - - ```bash - passwd tidb - ``` - -3. 配置 `tidb` 用户 sudo 免密码，将 `tidb ALL=(ALL) NOPASSWD: ALL` 添加到文件末尾即可。 - - {{< copyable "shell-root" >}} - - ```bash - visudo - ``` - - ``` - tidb ALL=(ALL) NOPASSWD: ALL - ``` - -4. 生成 SSH key。 - - 执行 `su` 命令，从 `root` 用户切换到 `tidb` 用户下。 - - {{< copyable "shell-root" >}} - - ```bash - su - tidb - ``` - - 创建 `tidb` 用户 SSH key，提示 `Enter passphrase` 时直接回车即可。执行成功后，SSH 私钥文件为 `/home/tidb/.ssh/id_rsa`，SSH 公钥文件为 `/home/tidb/.ssh/id_rsa.pub`。 - - {{< copyable "shell-regular" >}} - - ```bash - ssh-keygen -t rsa - ``` - - ``` - Generating public/private rsa key pair. - Enter file in which to save the key (/home/tidb/.ssh/id_rsa): - Created directory '/home/tidb/.ssh'. - Enter passphrase (empty for no passphrase): - Enter same passphrase again: - Your identification has been saved in /home/tidb/.ssh/id_rsa. - Your public key has been saved in /home/tidb/.ssh/id_rsa.pub. - The key fingerprint is: - SHA256:eIBykszR1KyECA/h0d7PRKz4fhAeli7IrVphhte7/So tidb@172.16.10.49 - The key's randomart image is: - +---[RSA 2048]----+ - |=+o+.o. | - |o=o+o.oo | - | .O.=.= | - | . B.B + | - |o B * B S | - | * + * + | - | o + . | - | o E+ . | - |o ..+o. | - +----[SHA256]-----+ - ``` - -## 第 3 步：在中控机器上下载 TiDB Ansible - -以 `tidb` 用户登录中控机并进入 `/home/tidb` 目录。使用以下命令从 [TiDB Ansible 项目](https://github.com/pingcap/tidb-ansible)上下载 master 分支的 TiDB Ansible，默认的文件夹名称为 `tidb-ansible`。 - -{{< copyable "shell-regular" >}} - -```bash -git clone https://github.com/pingcap/tidb-ansible.git -``` - -> **注意：** -> -> - 部署和升级 TiDB 集群需使用对应的 tidb-ansible 版本，通过改 `inventory.ini` 文件中的版本来混用可能会产生一些错误。 -> - 请务必按文档操作，将 `tidb-ansible` 下载到 `/home/tidb` 目录下，权限为 `tidb` 用户，不要下载到 `/root` 下，否则会遇到权限问题。 - -## 第 4 步：在中控机器上安装 Ansible 及其依赖 - -以 `tidb` 用户登录中控机，请务必按以下方式通过 `pip` 安装 Ansible 及其相关依赖的指定版本，否则会有兼容问题。目前，TiDB release-2.0、release-2.1、release-3.0、release-3.1 以及最新开发版本兼容 Ansible 2.4 ~ 2.7.11 (2.4 ≤ Ansible ≤ 2.7.11)。 - -1. 在中控机器上安装 Ansible 及其依赖。 - - {{< copyable "shell-regular" >}} - - ```bash - cd /home/tidb/tidb-ansible && \ - sudo pip install -r ./requirements.txt - ``` - - Ansible 及相关依赖的版本信息记录在 `tidb-ansible/requirements.txt` 文件中。 - -2. 查看 Ansible 的版本。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible --version - ``` - - ``` - ansible 2.7.11 - ``` - -## 第 5 步：在中控机上配置部署机器 SSH 互信及 sudo 规则 - -以 `tidb` 用户登录中控机，然后执行以下步骤： - -1. 将你的部署目标机器 IP 添加到 `hosts.ini` 文件的 `[servers]` 区块下。 - - {{< copyable "shell-regular" >}} - - ```bash - cd /home/tidb/tidb-ansible && \ - vi hosts.ini - ``` - - ```ini - [servers] - 172.16.10.1 - 172.16.10.2 - 172.16.10.3 - 172.16.10.4 - 172.16.10.5 - 172.16.10.6 - - [all:vars] - username = tidb - ntp_server = pool.ntp.org - ``` - -2. 执行以下命令，按提示输入部署目标机器的 `root` 用户密码。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook -i hosts.ini create_users.yml -u root -k - ``` - - 该步骤将在部署目标机器上创建 `tidb` 用户，并配置 sudo 规则，配置中控机与部署目标机器之间的 SSH 互信。 - -如果要手工配置 SSH 互信及 sudo 免密码，可参考[如何手工配置 ssh 互信及 sudo 免密码](#如何手工配置-ssh-互信及-sudo-免密码)。 - -## 第 6 步：在部署目标机器上安装 NTP 服务 - -> **注意：** -> -> 如果你的部署目标机器时间、时区设置一致，已开启 NTP 服务且在正常同步时间，此步骤可忽略。可参考[如何检测 NTP 服务是否正常](#如何检测-ntp-服务是否正常)。 - -以 `tidb` 用户登录中控机，执行以下命令： - -{{< copyable "shell-regular" >}} - -```bash -cd /home/tidb/tidb-ansible && \ -ansible-playbook -i hosts.ini deploy_ntp.yml -u tidb -b -``` - -该步骤将在部署目标机器上使用系统自带软件源联网安装并启动 NTP 服务，服务使用安装包默认的 NTP server 列表，见配置文件 `/etc/ntp.conf` 中 server 参数。如果使用默认的 NTP server，你的机器需要连接外网。 - -为了让 NTP 尽快开始同步，启动 NTP 服务前，系统会执行 `ntpdate` 命令，与用户在 `hosts.ini` 文件中指定的 `ntp_server` 同步日期与时间。默认的服务器为 `pool.ntp.org`，也可替换为你的 NTP server。 - -## 第 7 步：在部署目标机器上配置 CPUfreq 调节器模式 - -为了让 CPU 发挥最大性能，请将 CPUfreq 调节器模式设置为 `performance` 模式。如需了解 CPUfreq 的更多信息，可查看[使用 CPUFREQ 调控器](https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/7/html/power_management_guide/cpufreq_governors#cpufreq_setup)文档。 - -### 查看系统支持的调节器模式 - -执行以下 `cpupower` 命令，可查看系统支持的调节器模式： - -{{< copyable "shell-root" >}} - -```bash -cpupower frequency-info --governors -``` - -``` -analyzing CPU 0: - available cpufreq governors: performance powersave -``` - -> **注意：** -> -> 本例中系统支持设置 `performance` 和 `powersave` 模式。如果返回 `Not Available`，表示当前系统不支持配置 CPUfreq，跳过该步骤即可。 - -{{< copyable "shell-root" >}} - -```bash -cpupower frequency-info --governors -``` - -``` -analyzing CPU 0: - available cpufreq governors: Not Available -``` - -### 查看系统当前的 CPUfreq 调节器模式 - -执行以下 `cpupower` 命令，可查看系统当前的 CPUfreq 调节器模式： - -{{< copyable "shell-root" >}} - -```bash -cpupower frequency-info --policy -``` - -``` -analyzing CPU 0: - current policy: frequency should be within 1.20 GHz and 3.20 GHz. - The governor "powersave" may decide which speed to use - within this range. -``` - -如上述代码所示，本例中的当前配置是 `powersave` 模式。 - -### 修改调节器模式 - -你可以通过以下两种方法来修改调节器模式。本例中，当前调节器模式为 `powersave`，以下命令会将模式变更为 `performance`。 - -- 使用 `cpupower frequency-set --governor` 命令来修改。 - - {{< copyable "shell-root" >}} - - ```bash - cpupower frequency-set --governor performance - ``` - -- 使用以下命令在部署目标机器上批量设置。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible -i hosts.ini all -m shell -a "cpupower frequency-set --governor performance" -u tidb -b - ``` - -## 第 8 步：在部署目标机器上添加数据盘 ext4 文件系统挂载参数 - -使用 `root` 用户登录目标机器，将部署目标机器数据盘格式化成 ext4 文件系统，挂载时添加 `nodelalloc` 和 `noatime` 挂载参数。`nodelalloc` 是必选参数，否则 Ansible 安装时检测无法通过；`noatime` 是可选建议参数。 - -> **注意：** -> -> 如果你的数据盘已经格式化成 ext4 并挂载了磁盘，可先执行 `umount /dev/nvme0n1p1` 命令卸载，从编辑 `/etc/fstab` 文件步骤开始执行，添加挂载参数重新挂载即可。 - -以 `/dev/nvme0n1` 数据盘为例，具体操作步骤如下： - -1. 查看数据盘。 - - {{< copyable "shell-root" >}} - - ```bash - fdisk -l - ``` - - ``` - Disk /dev/nvme0n1: 1000 GB - ``` - -2. 创建分区表。 - - {{< copyable "shell-root" >}} - - ```bash - parted -s -a optimal /dev/nvme0n1 mklabel gpt -- mkpart primary ext4 1 -1 - ``` - - > **注意：** - > - > 使用 `lsblk` 命令查看分区的设备号：对于 nvme 磁盘，生成的分区设备号一般为 `nvme0n1p1`；对于普通磁盘（例如 `/dev/sdb`），生成的的分区设备号一般为 `sdb1`。 - -3. 格式化文件系统。 - - {{< copyable "shell-root" >}} - - ```bash - mkfs.ext4 /dev/nvme0n1p1 - ``` - -4. 查看数据盘分区 UUID。 - - 本例中 `nvme0n1p1` 的 UUID 为 `c51eb23b-195c-4061-92a9-3fad812cc12f`。 - - {{< copyable "shell-root" >}} - - ```bash - lsblk -f - ``` - - ``` - NAME FSTYPE LABEL UUID MOUNTPOINT - sda - ├─sda1 ext4 237b634b-a565-477b-8371-6dff0c41f5ab /boot - ├─sda2 swap f414c5c0-f823-4bb1-8fdf-e531173a72ed - └─sda3 ext4 547909c1-398d-4696-94c6-03e43e317b60 / - sr0 - nvme0n1 - └─nvme0n1p1 ext4 c51eb23b-195c-4061-92a9-3fad812cc12f - ``` - -5. 编辑 `/etc/fstab` 文件，添加 `nodelalloc` 挂载参数。 - - {{< copyable "shell-root" >}} - - ```bash - vi /etc/fstab - ``` - - ``` - UUID=c51eb23b-195c-4061-92a9-3fad812cc12f /data1 ext4 defaults,nodelalloc,noatime 0 2 - ``` - -6. 挂载数据盘。 - - {{< copyable "shell-root" >}} - - ```bash - mkdir /data1 && \ - mount -a - ``` - -7. 执行以下命令，如果文件系统为 ext4，并且挂载参数中包含 `nodelalloc`，则表示已生效。 - - {{< copyable "shell-root" >}} - - ```bash - mount -t ext4 - ``` - - ``` - /dev/nvme0n1p1 on /data1 type ext4 (rw,noatime,nodelalloc,data=ordered) - ``` - -## 第 9 步：编辑 `inventory.ini` 文件，分配机器资源 - -以 `tidb` 用户登录中控机，编辑 `/home/tidb/tidb-ansible/inventory.ini` 文件为 TiDB 集群分配机器资源。一个标准的 TiDB 集群需要 6 台机器：2 个 TiDB 实例，3 个 PD 实例，3 个 TiKV 实例。 - -- 至少需部署 3 个 TiKV 实例。 -- 不要将 TiKV 实例与 TiDB 或 PD 实例混合部署在同一台机器上。 -- 将第一台 TiDB 机器同时用作监控机。 - -> **注意：** -> -> 请使用内网 IP 来部署集群，如果部署目标机器 SSH 端口非默认的 22 端口，需添加 `ansible_port` 变量，如 `TiDB1 ansible_host=172.16.10.1 ansible_port=5555`。 - -你可以根据实际场景从以下两种集群拓扑中选择一种： - -- [单机单 TiKV 实例集群拓扑](#单机单-tikv-实例集群拓扑) - - 默认情况下，建议在每个 TiKV 节点上仅部署一个 TiKV 实例，以提高性能。但是，如果你的 TiKV 部署机器的 CPU 和内存配置是[部署建议](/dev/how-to/deploy/hardware-recommendations.md)的两倍或以上，并且一个节点拥有两块 SSD 硬盘或者单块 SSD 硬盘的容量大于 2 TB，则可以考虑部署两实例，但不建议部署两个以上实例。 - -- [单机多 TiKV 实例集群拓扑](#单机多-tikv-实例集群拓扑) - -### 单机单 TiKV 实例集群拓扑 - -| Name | Host IP | Services | -| :---- | :------- | :-------- | -| node1 | 172.16.10.1 | PD1, TiDB1 | -| node2 | 172.16.10.2 | PD2, TiDB2 | -| node3 | 172.16.10.3 | PD3 | -| node4 | 172.16.10.4 | TiKV1 | -| node5 | 172.16.10.5 | TiKV2 | -| node6 | 172.16.10.6 | TiKV3 | - -```ini -[tidb_servers] -172.16.10.1 -172.16.10.2 - -[pd_servers] -172.16.10.1 -172.16.10.2 -172.16.10.3 - -[tikv_servers] -172.16.10.4 -172.16.10.5 -172.16.10.6 - -[monitoring_servers] -172.16.10.1 - -[grafana_servers] -172.16.10.1 - -[monitored_servers] -172.16.10.1 -172.16.10.2 -172.16.10.3 -172.16.10.4 -172.16.10.5 -172.16.10.6 -``` - -### 单机多 TiKV 实例集群拓扑 - -以两实例为例： - -| Name | Host IP | Services | -| :---- | :------- | :-------- | -| node1 | 172.16.10.1 | PD1, TiDB1 | -| node2 | 172.16.10.2 | PD2, TiDB2 | -| node3 | 172.16.10.3 | PD3 | -| node4 | 172.16.10.4 | TiKV1-1, TiKV1-2 | -| node5 | 172.16.10.5 | TiKV2-1, TiKV2-2 | -| node6 | 172.16.10.6 | TiKV3-1, TiKV3-2 | - -```ini -[tidb_servers] -172.16.10.1 -172.16.10.2 - -[pd_servers] -172.16.10.1 -172.16.10.2 -172.16.10.3 - -# 注意：要使用 TiKV 的 labels，必须同时配置 PD 的 location_labels 参数，否则 labels 设置不生效。 -[tikv_servers] -TiKV1-1 ansible_host=172.16.10.4 deploy_dir=/data1/deploy tikv_port=20171 labels="host=tikv1" -TiKV1-2 ansible_host=172.16.10.4 deploy_dir=/data2/deploy tikv_port=20172 labels="host=tikv1" -TiKV2-1 ansible_host=172.16.10.5 deploy_dir=/data1/deploy tikv_port=20171 labels="host=tikv2" -TiKV2-2 ansible_host=172.16.10.5 deploy_dir=/data2/deploy tikv_port=20172 labels="host=tikv2" -TiKV3-1 ansible_host=172.16.10.6 deploy_dir=/data1/deploy tikv_port=20171 labels="host=tikv3" -TiKV3-2 ansible_host=172.16.10.6 deploy_dir=/data2/deploy tikv_port=20172 labels="host=tikv3" - -# 部署 3.0 版本的 TiDB 集群时，多实例场景需要额外配置 status 端口，示例如下： -# TiKV1-1 ansible_host=172.16.10.4 deploy_dir=/data1/deploy tikv_port=20171 tikv_status_port=20181 labels="host=tikv1" -# TiKV1-2 ansible_host=172.16.10.4 deploy_dir=/data2/deploy tikv_port=20172 tikv_status_port=20182 labels="host=tikv1" -# TiKV2-1 ansible_host=172.16.10.5 deploy_dir=/data1/deploy tikv_port=20171 tikv_status_port=20181 labels="host=tikv2" -# TiKV2-2 ansible_host=172.16.10.5 deploy_dir=/data2/deploy tikv_port=20172 tikv_status_port=20182 labels="host=tikv2" -# TiKV3-1 ansible_host=172.16.10.6 deploy_dir=/data1/deploy tikv_port=20171 tikv_status_port=20181 labels="host=tikv3" -# TiKV3-2 ansible_host=172.16.10.6 deploy_dir=/data2/deploy tikv_port=20172 tikv_status_port=20182 labels="host=tikv3" - -[monitoring_servers] -172.16.10.1 - -[grafana_servers] -172.16.10.1 - -[monitored_servers] -172.16.10.1 -172.16.10.2 -172.16.10.3 -172.16.10.4 -172.16.10.5 -172.16.10.6 - -# 注意：为使 TiKV 的 labels 设置生效，部署集群时必须设置 PD 的 location_labels 参数。 -[pd_servers:vars] -location_labels = ["host"] -``` - -- 服务配置文件参数调整 - - 1. 多实例情况下，需要修改 `tidb-ansible/conf/tikv.yml` 中 `block-cache-size` 下面的 `capacity` 参数： - - ```yaml - storage: - block-cache: - capacity: "1GB" - ``` - - > **注意：** - > - > TiKV 实例数量指每个服务器上 TiKV 的进程数量。 - > - > 推荐设置：`capacity` = MEM_TOTAL * 0.5 / TiKV 实例数量 - - 2. 多实例情况下，需要修改 `tidb-ansible/conf/tikv.yml` 中 `high-concurrency`、`normal-concurrency` 和 `low-concurrency` 三个参数： - - ```yaml - readpool: - coprocessor: - # Notice: if CPU_NUM > 8, default thread pool size for coprocessors - # will be set to CPU_NUM * 0.8. - # high-concurrency: 8 - # normal-concurrency: 8 - # low-concurrency: 8 - ``` - - > **注意：** - > - > 推荐设置：TiKV 实例数量 \* 参数值 = CPU 核心数量 \* 0.8 - - 3. 如果多个 TiKV 实例部署在同一块物理磁盘上，需要修改 `conf/tikv.yml` 中的 `capacity` 参数： - - ```yaml - raftstore: - capacity: 0 - ``` - - > **注意：** - > - > 推荐配置：`capacity` = 磁盘总容量 / TiKV 实例数量 - > - > 例如：`capacity: "100GB"` - -## 第 10 步：调整 `inventory.ini` 文件中的变量 - -本小节介绍如何编辑部署目录的变量和 `inventory.ini` 文件中的其它变量。 - -### 调整部署目录 - -部署目录通过 `deploy_dir` 变量控制，默认全局变量已设置为 `/home/tidb/deploy`，对所有服务生效。如数据盘挂载目录为 `/data1`，可设置为 `/data1/deploy`，样例如下： - -```ini -## Global variables -[all:vars] -deploy_dir = /data1/deploy -``` - -如为某一服务单独设置部署目录，可在配置服务主机列表时配置主机变量，以 TiKV 节点为例，其他服务类推，请务必添加第一列别名，以免服务混布时混淆。 - -```ini -TiKV1-1 ansible_host=172.16.10.4 deploy_dir=/data1/deploy -``` - -### 调整其它变量（可选） - -> **注意：** -> -> 以下控制变量开启请使用首字母大写 `True`，关闭请使用首字母大写 `False`。 - -| 变量 | 含义 | -| :--------------- | :-------------------------------------------------------- | -| `cluster_name` | 集群名称，可调整 | -| `tidb_version` | TiDB 版本，TiDB Ansible 各分支默认已配置 | -| `process_supervision` | 进程监管方式，默认为 `systemd`，可选 `supervise` | -| `timezone` | 新安装 TiDB 集群第一次启动 bootstrap（初始化）时，将 TiDB 全局默认时区设置为该值。TiDB 使用的时区后续可通过 `time_zone` 全局变量和 session 变量来修改，参考[时区支持](/dev/how-to/configure/time-zone.md)。默认为 `Asia/Shanghai`，可选值参考 [timzone 列表](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)。 | -| `enable_firewalld` | 开启防火墙，默认不开启，如需开启，请将[部署建议-网络要求](/dev/how-to/deploy/hardware-recommendations.md#网络要求) 中的端口加入白名单 | -| `enable_ntpd` | 检测部署目标机器 NTP 服务，默认为 `True`，请勿关闭 | -| `set_hostname` | 根据 IP 修改部署目标机器主机名，默认为 `False` | -| `enable_binlog` | 是否部署 Pump 并开启 binlog，默认为 `False`，依赖 Kafka 集群，参见 `zookeeper_addrs` 变量 | -| `zookeeper_addrs` | binlog Kafka 集群的 zookeeper 地址 | -| `deploy_without_tidb` | KV 模式，不部署 TiDB 服务，仅部署 PD、TiKV 及监控服务，请将 `inventory.ini` 文件中 `tidb_servers` 主机组 IP 设置为空。| -| `alertmanager_target` | 可选：如果你已单独部署 alertmanager，可配置该变量，格式：`alertmanager_host:alertmanager_port` | -| `grafana_admin_user` | Grafana 管理员帐号用户名，默认为 admin | -| `grafana_admin_password` | Grafana 管理员帐号密码，默认为 admin，用于 Ansible 导入 Dashboard 和创建 API Key，如后期通过 grafana web 修改了密码，请更新此变量 | -| `collect_log_recent_hours` | 采集日志时，采集最近几个小时的日志，默认为 2 小时 | -| `enable_bandwidth_limit` | 在中控机上从部署目标机器拉取诊断数据时，是否限速，默认为 `True`，与 `collect_bandwidth_limit` 变量结合使用 | -| `collect_bandwidth_limit` | 在中控机上从部署目标机器拉取诊断数据时限速多少，单位: Kbit/s，默认 10000，即 10Mb/s，如果是单机多 TiKV 实例部署方式，需除以单机实例个数 | -| `prometheus_storage_retention` | Prometheus 监控数据的保留时间（默认为 30 天）；2.1.7、3.0 以及之后的 tidb-ansible 版本中，`group_vars/monitoring_servers.yml` 文件里新增的配置 | - -## 第 11 步：部署 TiDB 集群 - -`ansible-playbook` 执行 Playbook 时，默认并发为 5。部署目标机器较多时，可添加 `-f` 参数指定并发数，例如 `ansible-playbook deploy.yml -f 10`。以下示例使用 `tidb` 用户作为服务运行用户： - -1. 在 `tidb-ansible/inventory.ini` 文件中，确认 `ansible_user = tidb`。 - - ```ini - ## Connection - # ssh via normal user - ansible_user = tidb - ``` - - > **注意：** - > - > 不要将 `ansible_user` 设置为 `root` 用户，因为 `tidb-ansible` 限制了服务以普通用户运行。 - - 执行以下命令，如果所有 server 均返回 `tidb`，表示 SSH 互信配置成功： - - {{< copyable "shell-regular" >}} - - ```bash - ansible -i inventory.ini all -m shell -a 'whoami' - ``` - - 执行以下命令，如果所有 server 均返回 `root`，表示 `tidb` 用户 sudo 免密码配置成功。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible -i inventory.ini all -m shell -a 'whoami' -b - ``` - -2. 执行 `local_prepare.yml` playbook，联网下载 TiDB binary 至中控机。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook local_prepare.yml - ``` - -3. 初始化系统环境，修改内核参数。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook bootstrap.yml - ``` - -4. 部署 TiDB 集群软件。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook deploy.yml - ``` - - > **注意：** - > - > Grafana Dashboard 上的 **Report** 按钮可用来生成 PDF 文件，此功能依赖 `fontconfig` 包和英文字体。如需使用该功能，登录 **grafana_servers** 机器，用以下命令安装： - > - > {{< copyable "shell-regular" >}} - > - > ```bash - > sudo yum install fontconfig open-sans-fonts - > ``` - -5. 启动 TiDB 集群。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook start.yml - ``` - -## 测试集群 - -TiDB 兼容 MySQL，因此可使用 MySQL 客户端直接连接 TiDB。推荐配置负载均衡以提供统一的 SQL 接口。 - -1. 使用 MySQL 客户端连接 TiDB 集群。TiDB 服务的默认端口为 `4000`。 - - {{< copyable "sql" >}} - - ```sql - mysql -u root -h 172.16.10.1 -P 4000 - ``` - -2. 通过浏览器访问监控平台。 - - - 地址： - - 默认帐号与密码：`admin`；`admin` - -## 常见部署问题 - -本小节介绍使用 Ansible 部署 TiDB 集群过程中的常见问题与解决方案。 - -### 如何自定义端口 - -修改 `inventory.ini` 文件，在相应服务 IP 后添加以下主机变量即可： - -| 组件 | 端口变量 | 默认端口 | 说明 | -| :-- | :-- | :-- | :-- | -| TiDB | tidb_port | 4000 | 应用及 DBA 工具访问通信端口 | -| TiDB | tidb_status_port | 10080 | TiDB 状态信息上报通信端口 | -| TiKV | tikv_port | 20160 | TiKV 通信端口 | -| TiKV | tikv_status_port | 20180 | 上报 TiKV 状态的通信端口 | -| PD | pd_client_port | 2379 | 提供 TiDB 和 PD 通信端口 | -| PD | pd_peer_port | 2380 | PD 集群节点间通信端口 | -| Pump | pump_port | 8250 | Pump 通信端口 | -| Prometheus | prometheus_port | 9090 | Prometheus 服务通信端口 | -| Pushgateway | pushgateway_port | 9091 | TiDB， TiKV， PD 监控聚合和上报端口 | -| Node_exporter | node_exporter_port | 9100 | TiDB 集群每个节点的系统信息上报通信端口 | -| Blackbox_exporter | blackbox_exporter_port | 9115 | Blackbox_exporter 通信端口，用于 TiDB 集群端口监控 | -| Grafana | grafana_port | 3000 | Web 监控服务对外服务和客户端(浏览器)访问端口 | -| Grafana | grafana_collector_port | 8686 | grafana_collector 通信端口，用于将 Dashboard 导出为 PDF 格式 | -| Kafka_exporter | kafka_exporter_port | 9308 | Kafka_exporter 通信端口，用于监控 binlog Kafka 集群 | - -### 如何自定义部署目录 - -修改 `inventory.ini` 文件，在相应服务 IP 后添加以下主机变量即可： - -| 组件 | 目录变量 | 默认目录 | 说明 | -| :-- | :-- | :-- | :-- | -| 全局 | deploy_dir | /home/tidb/deploy | 部署目录 | -| TiDB | tidb_log_dir | {{ deploy_dir }}/log | 日志目录 | -| TiKV | tikv_log_dir | {{ deploy_dir }}/log | 日志目录 | -| TiKV | tikv_data_dir | {{ deploy_dir }}/data | 数据目录 | -| TiKV | wal_dir | "" | rocksdb write-ahead 日志目录，为空时与 TiKV 数据目录一致 | -| TiKV | raftdb_path | "" | raftdb 目录，为空时为 tikv_data_dir/raft | -| PD | pd_log_dir | {{ deploy_dir }}/log | 日志目录 | -| PD | pd_data_dir | {{ deploy_dir }}/data.pd | 数据目录 | -| pump | pump_log_dir | {{ deploy_dir }}/log | 日志目录 | -| pump | pump_data_dir | {{ deploy_dir }}/data.pump | 数据目录 | -| prometheus | prometheus_log_dir | {{ deploy_dir }}/log | 日志目录 | -| prometheus | prometheus_data_dir | {{ deploy_dir }}/data.metrics | 数据目录 | -| pushgateway | pushgateway_log_dir | {{ deploy_dir }}/log | 日志目录 | -| node_exporter | node_exporter_log_dir | {{ deploy_dir }}/log | 日志目录 | -| grafana | grafana_log_dir | {{ deploy_dir }}/log | 日志目录 | -| grafana | grafana_data_dir | {{ deploy_dir }}/data.grafana | 数据目录 | - -### 如何检测 NTP 服务是否正常 - -1. 执行以下命令，如果输出 `running` 表示 NTP 服务正在运行： - - {{< copyable "shell-regular" >}} - - ```bash - sudo systemctl status ntpd.service - ``` - - ``` - ntpd.service - Network Time Service - Loaded: loaded (/usr/lib/systemd/system/ntpd.service; disabled; vendor preset: disabled) - Active: active (running) since 一 2017-12-18 13:13:19 CST; 3s ago - ``` - -2. 执行 `ntpstat` 命令，如果输出 `synchronised to NTP server`（正在与 NTP server 同步），表示在正常同步： - - {{< copyable "shell-regular" >}} - - ```bash - ntpstat - ``` - - ``` - synchronised to NTP server (85.199.214.101) at stratum 2 - time correct to within 91 ms - polling server every 1024 s - ``` - -> **注意：** -> -> Ubuntu 系统需安装 `ntpstat` 软件包。 - -- 以下情况表示 NTP 服务未正常同步： - - {{< copyable "shell-regular" >}} - - ```bash - ntpstat - ``` - - ``` - unsynchronised - ``` - -- 以下情况表示 NTP 服务未正常运行： - - {{< copyable "shell-regular" >}} - - ```bash - ntpstat - ``` - - ``` - Unable to talk to NTP daemon. Is it running? - ``` - -- 如果要使 NTP 服务尽快开始同步，执行以下命令。可以将 `pool.ntp.org` 替换为你的 NTP server： - - {{< copyable "shell-regular" >}} - - ```bash - sudo systemctl stop ntpd.service && \ - sudo ntpdate pool.ntp.org && \ - sudo systemctl start ntpd.service - ``` - -- 如果要在 CentOS 7 系统上手动安装 NTP 服务，可执行以下命令： - - {{< copyable "shell-regular" >}} - - ```bash - sudo yum install ntp ntpdate && \ - sudo systemctl start ntpd.service && \ - sudo systemctl enable ntpd.service - ``` - -### 如何调整进程监管方式从 supervise 到 systemd - -{{< copyable "shell-root" >}} - -```shell -process supervision, [systemd, supervise] -``` - -``` -process_supervision = systemd -``` - -TiDB Anisble 在 TiDB v1.0.4 版本之前进程监管方式默认为 `supervise`。之前安装的集群可保持不变，如需更新为 `systemd`，需关闭集群，按以下方式变更： - -{{< copyable "shell-regular" >}} - -```bash -ansible-playbook stop.yml && \ -ansible-playbook deploy.yml -D && \ -ansible-playbook start.yml -``` - -### 如何手工配置 SSH 互信及 sudo 免密码 - -1. 以 `root` 用户依次登录到部署目标机器创建 `tidb` 用户并设置登录密码。 - - {{< copyable "shell-root" >}} - - ```bash - useradd tidb && \ - passwd tidb - ``` - -2. 执行以下命令，将 `tidb ALL=(ALL) NOPASSWD: ALL` 添加到文件末尾，即配置好 sudo 免密码。 - - {{< copyable "shell-root" >}} - - ```bash - visudo - ``` - - ``` - tidb ALL=(ALL) NOPASSWD: ALL - ``` - -3. 以 `tidb` 用户登录到中控机，执行以下命令。将 `172.16.10.61` 替换成你的部署目标机器 IP，按提示输入部署目标机器 `tidb` 用户密码，执行成功后即创建好 SSH 互信，其他机器同理。 - - {{< copyable "shell-regular" >}} - - ```bash - ssh-copy-id -i ~/.ssh/id_rsa.pub 172.16.10.61 - ``` - -4. 以 `tidb` 用户登录中控机，通过 `ssh` 的方式登录目标机器 IP。如果不需要输入密码并登录成功，即表示 SSH 互信配置成功。 - - {{< copyable "shell-regular" >}} - - ```bash - ssh 172.16.10.61 - ``` - - ``` - [tidb@172.16.10.61 ~]$ - ``` - -5. 以 `tidb` 用户登录到部署目标机器后，执行以下命令，不需要输入密码并切换到 `root` 用户，表示 `tidb` 用户 sudo 免密码配置成功。 - - {{< copyable "shell-regular" >}} - - ```bash - sudo -su root - ``` - - ``` - [root@172.16.10.61 tidb]# - ``` - -### You need to install jmespath prior to running json_query filter 报错 - -1. 请参照[在中控机器上安装 Ansible 及其依赖](#在中控机器上安装-ansible-及其依赖) 在中控机上通过 `pip` 安装 Ansible 及相关依赖的指定版本，默认会安装 `jmespath`。 - -2. 执行以下命令，验证 `jmespath` 是否安装成功： - - {{< copyable "shell-regular" >}} - - ```bash - pip show jmespath - ``` - - ``` - Name: jmespath - Version: 0.9.0 - ``` - -3. 在中控机上 Python 交互窗口里执行 `import jmespath`。 - - - 如果没有报错，表示依赖安装成功。 - - 如果有 `ImportError: No module named jmespath` 报错，表示未成功安装 Python `jmespath` 模块。 - - {{< copyable "shell-regular" >}} - - ```bash - python - ``` - - ``` - Python 2.7.5 (default, Nov 6 2016, 00:28:07) - [GCC 4.8.5 20150623 (Red Hat 4.8.5-11)] on linux2 - Type "help", "copyright", "credits" or "license" for more information. - ``` - - {{< copyable "shell-regular" >}} - - ```shell - import jmespath - ``` - -### 启动 Pump/Drainer 报 `zk: node does not exist` 错误 - -请检查 `inventory.ini` 里的 `zookeeper_addrs` 参数配置与 Kafka 集群内的配置是否相同、是否填写了命名空间。关于命名空间的配置说明如下： - -```ini -# ZooKeeper connection string (see ZooKeeper docs for details). -# ZooKeeper address of Kafka cluster, example: -# zookeeper_addrs = "192.168.0.11:2181,192.168.0.12:2181,192.168.0.13:2181" -# You can also append an optional chroot string to the URLs to specify the root directory for all Kafka znodes. Example: -# zookeeper_addrs = "192.168.0.11:2181,192.168.0.12:2181,192.168.0.13:2181/kafka/123" -``` diff --git a/dev/how-to/deploy/orchestrated/docker.md b/dev/how-to/deploy/orchestrated/docker.md deleted file mode 100644 index ccf8ee40f616..000000000000 --- a/dev/how-to/deploy/orchestrated/docker.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -title: TiDB Docker 部署方案 -category: how-to ---- - -# TiDB Docker 部署方案 - -本文介绍如何使用 Docker 部署一个多节点的 TiDB 集群。 - -> **警告：** -> -> 对于生产环境，不要使用 Docker 进行部署，而应[使用 Ansible 部署 TiDB 集群](/dev/how-to/deploy/orchestrated/ansible.md)。 - -## 环境准备 - -### 安装 Docker - -Docker 可以方便地在 Linux / Mac OS / Windows 平台安装，安装方法请参考 [Docker 官方文档](https://www.docker.com/products/docker)。 - -### 拉取 TiDB 的 Docker 镜像 - -部署 TiDB 集群主要包括 3 个服务组件: - -- TiDB -- TiKV -- PD - -对应的最新 Docker 镜像可以通过 [Docker 官方镜像仓库](https://hub.docker.com/u/pingcap) 获取： - -{{< copyable "shell-regular" >}} - -```bash -docker pull pingcap/tidb:latest -``` - -{{< copyable "shell-regular" >}} - -```bash -docker pull pingcap/tikv:latest -``` - -{{< copyable "shell-regular" >}} - -```bash -docker pull pingcap/pd:latest -``` - -## 部署一个多节点集群 - -假设我们打算在 6 台主机上部署一个 TiDB 集群: - -| 主机名 | IP | 部署服务 | 数据盘挂载 | -| --------- | ------------- | ---------- | ----- | -| host1 | 192.168.1.101 | PD1 & TiDB | /data | -| host2 | 192.168.1.102 | PD2 | /data | -| host3 | 192.168.1.103 | PD3 | /data | -| host4 | 192.168.1.104 | TiKV1 | /data | -| host5 | 192.168.1.105 | TiKV2 | /data | -| host6 | 192.168.1.106 | TiKV3 | /data | - -### 启动 PD - -登录 **host1** 执行： - -{{< copyable "shell-regular" >}} - -```bash -docker run -d --name pd1 \ - -p 2379:2379 \ - -p 2380:2380 \ - -v /etc/localtime:/etc/localtime:ro \ - -v /data:/data \ - pingcap/pd:latest \ - --name="pd1" \ - --data-dir="/data/pd1" \ - --client-urls="http://0.0.0.0:2379" \ - --advertise-client-urls="http://192.168.1.101:2379" \ - --peer-urls="http://0.0.0.0:2380" \ - --advertise-peer-urls="http://192.168.1.101:2380" \ - --initial-cluster="pd1=http://192.168.1.101:2380,pd2=http://192.168.1.102:2380,pd3=http://192.168.1.103:2380" -``` - -登录 **host2** 执行： - -{{< copyable "shell-regular" >}} - -```bash -docker run -d --name pd2 \ - -p 2379:2379 \ - -p 2380:2380 \ - -v /etc/localtime:/etc/localtime:ro \ - -v /data:/data \ - pingcap/pd:latest \ - --name="pd2" \ - --data-dir="/data/pd2" \ - --client-urls="http://0.0.0.0:2379" \ - --advertise-client-urls="http://192.168.1.102:2379" \ - --peer-urls="http://0.0.0.0:2380" \ - --advertise-peer-urls="http://192.168.1.102:2380" \ - --initial-cluster="pd1=http://192.168.1.101:2380,pd2=http://192.168.1.102:2380,pd3=http://192.168.1.103:2380" -``` - -登录 **host3** 执行： - -{{< copyable "shell-regular" >}} - -```bash -docker run -d --name pd3 \ - -p 2379:2379 \ - -p 2380:2380 \ - -v /etc/localtime:/etc/localtime:ro \ - -v /data:/data \ - pingcap/pd:latest \ - --name="pd3" \ - --data-dir="/data/pd3" \ - --client-urls="http://0.0.0.0:2379" \ - --advertise-client-urls="http://192.168.1.103:2379" \ - --peer-urls="http://0.0.0.0:2380" \ - --advertise-peer-urls="http://192.168.1.103:2380" \ - --initial-cluster="pd1=http://192.168.1.101:2380,pd2=http://192.168.1.102:2380,pd3=http://192.168.1.103:2380" -``` - -### 启动 TiKV - -登录 **host4** 执行： - -{{< copyable "shell-regular" >}} - -```bash -docker run -d --name tikv1 \ - -p 20160:20160 \ - --ulimit nofile=1000000:1000000 \ - -v /etc/localtime:/etc/localtime:ro \ - -v /data:/data \ - pingcap/tikv:latest \ - --addr="0.0.0.0:20160" \ - --advertise-addr="192.168.1.104:20160" \ - --data-dir="/data/tikv1" \ - --pd="192.168.1.101:2379,192.168.1.102:2379,192.168.1.103:2379" -``` - -登录 **host5** 执行： - -{{< copyable "shell-regular" >}} - -```bash -docker run -d --name tikv2 \ - -p 20160:20160 \ - --ulimit nofile=1000000:1000000 \ - -v /etc/localtime:/etc/localtime:ro \ - -v /data:/data \ - pingcap/tikv:latest \ - --addr="0.0.0.0:20160" \ - --advertise-addr="192.168.1.105:20160" \ - --data-dir="/data/tikv2" \ - --pd="192.168.1.101:2379,192.168.1.102:2379,192.168.1.103:2379" -``` - -登录 **host6** 执行： - -{{< copyable "shell-regular" >}} - -```bash -docker run -d --name tikv3 \ - -p 20160:20160 \ - --ulimit nofile=1000000:1000000 \ - -v /etc/localtime:/etc/localtime:ro \ - -v /data:/data \ - pingcap/tikv:latest \ - --addr="0.0.0.0:20160" \ - --advertise-addr="192.168.1.106:20160" \ - --data-dir="/data/tikv3" \ - --pd="192.168.1.101:2379,192.168.1.102:2379,192.168.1.103:2379" -``` - -### 启动 TiDB - -登录 **host1** 执行： - -{{< copyable "shell-regular" >}} - -```bash -docker run -d --name tidb \ - -p 4000:4000 \ - -p 10080:10080 \ - -v /etc/localtime:/etc/localtime:ro \ - pingcap/tidb:latest \ - --store=tikv \ - --path="192.168.1.101:2379,192.168.1.102:2379,192.168.1.103:2379" -``` - -### 使用 MySQL 标准客户端连接 TiDB 测试 - -登录 **host1** 并确保已安装 [MySQL 命令行客户端](http://dev.mysql.com/downloads/mysql/)，执行： - -{{< copyable "shell-regular" >}} - -```bash -mysql -h 127.0.0.1 -P 4000 -u root -D test -``` - -{{< copyable "sql" >}} - -```sql -show databases; -``` - -``` -+--------------------+ -| Database | -+--------------------+ -| INFORMATION_SCHEMA | -| PERFORMANCE_SCHEMA | -| mysql | -| test | -+--------------------+ -4 rows in set (0.00 sec) -``` - -### 如何自定义配置文件 - -TiKV 和 PD 可以通过指定配置文件的方式来加载更加丰富的启动参数，用于性能调优。 - -假定配置文件在宿主机上的存放路径 `/path/to/config/pd.toml` 和 `/path/to/config/tikv.toml`。启动 Docker 时需要调整相应的启动参数，以 tikv1 和 pd1 为例： - -{{< copyable "shell-regular" >}} - -```bash -docker run -d --name tikv1 \ - -p 20160:20160 \ - -v /etc/localtime:/etc/localtime:ro \ - -v /data:/data \ - -v /path/to/config/tikv.toml:/tikv.toml:ro \ - pingcap/tikv:latest \ - --addr="0.0.0.0:20160" \ - --advertise-addr="192.168.1.104:20160" \ - --data-dir="/data/tikv1" \ - --pd="192.168.1.101:2379,192.168.1.102:2379,192.168.1.103:2379" \ - --config="/tikv.toml" -``` - -{{< copyable "shell-regular" >}} - -```bash -docker run -d --name pd1 \ - -p 2379:2379 \ - -p 2380:2380 \ - -v /etc/localtime:/etc/localtime:ro \ - -v /data:/data \ - -v /path/to/config/pd.toml:/pd.toml:ro \ - pingcap/pd:latest \ - --name="pd1" \ - --data-dir="/data/pd1" \ - --client-urls="http://0.0.0.0:2379" \ - --advertise-client-urls="http://192.168.1.101:2379" \ - --peer-urls="http://0.0.0.0:2380" \ - --advertise-peer-urls="http://192.168.1.101:2380" \ - --initial-cluster="pd1=http://192.168.1.101:2380,pd2=http://192.168.1.102:2380,pd3=http://192.168.1.103:2380" \ - --config="/pd.toml" -``` diff --git a/dev/how-to/deploy/orchestrated/offline-ansible.md b/dev/how-to/deploy/orchestrated/offline-ansible.md deleted file mode 100644 index cc1fad9acc7c..000000000000 --- a/dev/how-to/deploy/orchestrated/offline-ansible.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -title: 离线 TiDB Ansible 部署方案 -category: how-to ---- - -# 离线 TiDB Ansible 部署方案 - -## 准备机器 - -1. 下载机一台 - - - 该机器需开放外网访问，用于下载 TiDB Ansible、TiDB 及相关软件安装包。 - - 推荐安装 CentOS 7.3 及以上版本 Linux 操作系统。 - -2. 部署目标机器若干及部署中控机一台 - - - 系统要求及配置参考[准备机器](/dev/how-to/deploy/orchestrated/ansible.md#准备机器)。 - - 可以无法访问外网。 - -## 在中控机上安装系统依赖包 - -1. 在下载机上下载[系统依赖离线安装包](https://download.pingcap.org/ansible-system-rpms.el7.tar.gz)，然后上传至中控机。该离线包仅支持 CentOS 7 系统，包含 `pip` 及 `sshpass`。 - -2. 在中控机上安装系统依赖包： - - {{< copyable "shell-root" >}} - - ```bash - tar -xzvf ansible-system-rpms.el7.tar.gz && - cd ansible-system-rpms.el7 && - chmod u+x install_ansible_system_rpms.sh && - ./install_ansible_system_rpms.sh - ``` - -3. 安装完成后，可通过 `pip -V` 验证 pip 是否安装成功： - - {{< copyable "shell-root" >}} - - ```bash - pip -V - ``` - - ``` - pip 8.1.2 from /usr/lib/python2.7/site-packages (python 2.7) - ``` - -> **注意：** -> -> 如果你的系统已安装 pip，请确认版本 >= 8.1.2，否则离线安装 ansible 及其依赖时，会有兼容问题。 - -## 在中控机上创建 tidb 用户，并生成 ssh key - -参考[在中控机上创建 tidb 用户，并生成 ssh key](/dev/how-to/deploy/orchestrated/ansible.md#第-2-步在中控机上创建-tidb-用户并生成-ssh-key) 即可。 - -## 在中控机器上离线安装 Ansible 及其依赖 - -以下是 CentOS 7 系统 Ansible 离线安装方式： - -建议使用 Ansible 2.4 至 2.7.11 版本，Ansible 及相关依赖版本记录在 `tidb-ansible/requirements.txt` 文件中。下面步骤以安装 Ansible 2.5 为例。 - -1. 在下载机上下载 [Ansible 2.5 离线安装包](https://download.pingcap.org/ansible-2.5.0-pip.tar.gz)，然后上传至中控机。 - -2. 离线安装 Ansible 及相关依赖： - - {{< copyable "shell-root" >}} - - ```bash - tar -xzvf ansible-2.5.0-pip.tar.gz && - cd ansible-2.5.0-pip/ && - chmod u+x install_ansible.sh && - ./install_ansible.sh - ``` - -3. 安装完成后，可通过 `ansible --version` 查看版本： - - {{< copyable "shell-root" >}} - - ```bash - ansible --version - ``` - - ``` - ansible 2.5.0 - ``` - -## 在下载机上下载 TiDB Ansible 及 TiDB 安装包 - -1. 在下载机上安装 Ansible： - - 请按以下方式在 CentOS 7 系统的下载机上在线安装 Ansible。安装完成后，可通过 `ansible --version` 查看版本，请务必确认是 **Ansible 2.5.0** 版本，否则会有兼容问题。 - - {{< copyable "shell-root" >}} - - ```bash - yum install epel-release && - yum install ansible curl && - ansible --version - ``` - - ``` - ansible 2.5.0 - ``` - -2. 下载 tidb-ansible： - - 使用以下命令从 Github [TiDB Ansible 项目](https://github.com/pingcap/tidb-ansible)上下载 TiDB Ansible 相应版本，默认的文件夹名称为 `tidb-ansible`。 - - {{< copyable "shell-regular" >}} - - ```bash - git clone https://github.com/pingcap/tidb-ansible.git - ``` - - > **注意：** - > - > 部署和升级 TiDB 集群需使用对应的 tidb-ansible 版本，通过改 `inventory.ini` 文件中的版本来混用可能会产生一些错误。 - -3. 执行 `local_prepare.yml` playbook，联网下载 TiDB binary 到下载机： - - {{< copyable "shell-regular" >}} - - ```bash - cd tidb-ansible && - ansible-playbook local_prepare.yml - ``` - -4. 将执行完以上命令之后的 `tidb-ansible` 文件夹拷贝到中控机 `/home/tidb` 目录下，文件属主权限需是 `tidb` 用户。 - -## 在中控机上配置部署机器 SSH 互信及 sudo 规则 - -参考[在中控机上配置部署机器 SSH 互信及 sudo 规则](/dev/how-to/deploy/orchestrated/ansible.md#第-5-步在中控机上配置部署机器-ssh-互信及-sudo-规则)即可。 - -## 在部署目标机器上安装 NTP 服务 - -如果你的部署目标机器时间、时区设置一致，已开启 NTP 服务且在正常同步时间，此步骤可忽略，可参考[如何检测 NTP 服务是否正常](/dev/how-to/deploy/orchestrated/ansible.md#如何检测-ntp-服务是否正常)。 - -参考[在部署目标机器上安装 NTP 服务](/dev/how-to/deploy/orchestrated/ansible.md#第-6-步在部署目标机器上安装-ntp-服务)即可。 - -## 在部署目标机器上配置 CPUfreq 调节器模式 - -参考[在部署目标机器上配置 CPUfreq 调节器模式](/dev/how-to/deploy/orchestrated/ansible.md#第-7-步在部署目标机器上配置-cpufreq-调节器模式)即可。 - -## 在部署目标机器上添加数据盘 ext4 文件系统挂载参数 - -参考[在部署目标机器上添加数据盘 ext4 文件系统挂载参数](/dev/how-to/deploy/orchestrated/ansible.md#第-8-步在部署目标机器上添加数据盘-ext4-文件系统挂载参数)即可。 - -## 分配机器资源，编辑 inventory.ini 文件 - -参考[分配机器资源，编辑 inventory.ini 文件](/dev/how-to/deploy/orchestrated/ansible.md#第-9-步编辑-inventoryini-文件分配机器资源)即可。 - -## 部署任务 - -1. `ansible-playbook local_prepare.yml` 该 playbook 不需要再执行。 - -2. 参考[部署任务](/dev/how-to/deploy/orchestrated/ansible.md#第-11-步部署-tidb-集群)即可。 - -## 测试集群 - -参考[测试集群](/dev/how-to/deploy/orchestrated/ansible.md#测试集群)即可。 diff --git a/dev/how-to/get-started/deploy-tidb-from-docker-compose.md b/dev/how-to/get-started/deploy-tidb-from-docker-compose.md deleted file mode 100644 index 16d3971fd1b1..000000000000 --- a/dev/how-to/get-started/deploy-tidb-from-docker-compose.md +++ /dev/null @@ -1,205 +0,0 @@ ---- -title: 使用 Docker Compose 快速构建 TiDB 集群 -category: how-to ---- - -# 使用 Docker Compose 快速构建 TiDB 集群 - -本文档介绍如何在单机上通过 Docker Compose 快速一键部署一套 TiDB 测试集群。[Docker Compose](https://docs.docker.com/compose/overview) 可以通过一个 YAML 文件定义多个容器的应用服务，然后一键启动或停止。 - -> **警告：** -> -> 对于生产环境，不要使用 Docker Compose 进行部署，而应[使用 Ansible 部署 TiDB 集群](/dev/how-to/deploy/orchestrated/ansible.md)。 - -## 准备环境 - -确保你的机器上已安装： - -- Docker（17.06.0 及以上版本） -- Docker Compose -- Git - -## 快速部署 - -1. 下载 `tidb-docker-compose` - - {{< copyable "shell-regular" >}} - - ```bash - git clone https://github.com/pingcap/tidb-docker-compose.git - ``` - -2. 创建并启动集群 - - 获取最新 Docker 镜像： - - {{< copyable "shell-regular" >}} - - ```bash - cd tidb-docker-compose && docker-compose pull && docker-compose up -d - ``` - -3. 访问集群 - - {{< copyable "shell-regular" >}} - - ```bash - mysql -h 127.0.0.1 -P 4000 -u root - ``` - - 访问集群 Grafana 监控页面： 默认用户名和密码均为 admin。 - - [集群数据可视化](https://github.com/pingcap/tidb-vision)： - -## 自定义集群 - -在完成快速部署后，以下组件已默认部署：3 个 PD，3 个 TiKV，1 个 TiDB 和监控组件 Prometheus，Pushgateway，Grafana 以及 tidb-vision。 - -如果想自定义集群，可以直接修改 `docker-compose.yml`，但是手动修改比较繁琐而且容易出错，强烈建议使用 [Helm](https://helm.sh) 模板引擎生成 `docker-compose.yml` 文件。 - -1. 安装 Helm - - [Helm](https://helm.sh) 可以用作模板渲染引擎，只需要下载其 binary 文件即可以使用。 - - {{< copyable "shell-regular" >}} - - ```bash - curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash - ``` - - 如果是 Mac 系统，也可以通过 Homebrew 安装： - - {{< copyable "shell-regular" >}} - - ```bash - brew install kubernetes-helm - ``` - -2. 下载 `tidb-docker-compose` - - {{< copyable "shell-regular" >}} - - ```bash - git clone https://github.com/pingcap/tidb-docker-compose.git - ``` - -3. 自定义集群 - - {{< copyable "shell-regular" >}} - - ```bash - cd tidb-docker-compose && - cp compose/values.yaml values.yaml && - vim values.yaml - ``` - - 修改 `values.yaml` 里面的配置，例如集群规模，TiDB 镜像版本等。 - - [tidb-vision](https://github.com/pingcap/tidb-vision) 是 TiDB 集群可视化页面，可以可视化地显示 PD 对 TiKV 数据的调度。如果不想部署该组件，可以将 `tidbVision` 项留空。 - - PD，TiKV，TiDB 和 tidb-vision 支持从 GitHub 源码或本地文件构建 Docker 镜像，供开发测试使用。 - - - 如果希望从本地已编译好的 binary 文件构建 PD，TiKV 或 TiDB 镜像，需要将其 `image` 字段留空，并将已编译好的 binary 拷贝到对应的 `pd/bin/pd-server`，`tikv/bin/tikv-server`，`tidb/bin/tidb-server`。 - - - 如果希望从本地构建 tidb-vision 镜像，需要将其 `image` 字段留空，并将 tidb-vision 项目拷贝到 `tidb-vision/tidb-vision`。 - -4. 生成 `docker-compose.yml` 文件 - - {{< copyable "shell-regular" >}} - - ```bash - helm template -f values.yaml compose > generated-docker-compose.yml - ``` - -5. 使用生成的 `docker-compose.yml` 创建并启动集群 - - 获取最新 Docker 镜像： - - {{< copyable "shell-regular" >}} - - ```bash - docker-compose -f generated-docker-compose.yml pull - ``` - - {{< copyable "shell-regular" >}} - - ```bash - docker-compose -f generated-docker-compose.yml up -d - ``` - -6. 访问集群 - - {{< copyable "shell-regular" >}} - - ```bash - mysql -h 127.0.0.1 -P 4000 -u root - ``` - - 访问集群 Grafana 监控页面： 默认用户名和密码均为 admin。 - - 如果启用了 tidb-vision，可以通过 查看。 - -## 访问 Spark shell 并加载 TiSpark - -向 TiDB 集群中插入一些样本数据： - -{{< copyable "shell-regular" >}} - -```bash -docker-compose exec tispark-master bash && -cd /opt/spark/data/tispark-sample-data && -mysql -h tidb -P 4000 -u root < dss.ddl -``` - -当样本数据加载到 TiDB 集群之后，可以使用 `docker-compose exec tispark-master /opt/spark/bin/spark-shell` 来访问 Spark shell。 - -{{< copyable "shell-regular" >}} - -```bash -docker-compose exec tispark-master /opt/spark/bin/spark-shell -``` - -``` -... -Spark context available as 'sc' (master = local[*], app id = local-1527045927617). -Spark session available as 'spark'. -Welcome to - ____ __ - / __/__ ___ _____/ /__ - _\ \/ _ \/ _ `/ __/ '_/ - /___/ .__/\_,_/_/ /_/\_\ version 2.1.1 - /_/ - -Using Scala version 2.11.8 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_172) -Type in expressions to have them evaluated. -Type :help for more information. -``` - -```shell -scala> import org.apache.spark.sql.TiContext -... -scala> val ti = new TiContext(spark) -... -scala> ti.tidbMapDatabase("TPCH_001") -... -scala> spark.sql("select count(*) from lineitem").show -``` - -``` -+--------+ -|count(1)| -+--------+ -| 60175| -+--------+ -``` - -你也可以通过 Python 或 R 来访问 Spark： - -{{< copyable "shell-regular" >}} - -```bash -docker-compose exec tispark-master /opt/spark/bin/pyspark && -docker-compose exec tispark-master /opt/spark/bin/sparkR -``` - -更多关于 TiSpark 的信息，参见 [TiSpark 的详细文档](/dev/how-to/get-started/tispark.md)。 diff --git a/dev/how-to/get-started/explore-sql.md b/dev/how-to/get-started/explore-sql.md deleted file mode 100644 index b88da0235dc1..000000000000 --- a/dev/how-to/get-started/explore-sql.md +++ /dev/null @@ -1,274 +0,0 @@ ---- -title: TiDB 中的基本 SQL 操作 -category: how-to ---- - -# TiDB 中的基本 SQL 操作 - -成功部署 TiDB 集群之后，便可以在 TiDB 中执行 SQL 语句了。因为 TiDB 兼容 MySQL，你可以使用 MySQL 客户端连接 TiDB，并且[大多数情况下](/dev/reference/mysql-compatibility.md)可以直接执行 MySQL 语句。 - -本文介绍 CRUD 操作等基本的 SQL 语句。完整的 SQL 语句列表，参见 [TiDB SQL 语法详解](https://pingcap.github.io/sqlgram/)。 - -## 创建、查看和删除数据库 - -使用 `CREATE DATABASE` 语句创建数据库。语法如下： - -{{< copyable "sql" >}} - -```sql -CREATE DATABASE db_name [options]; -``` - -例如，要创建一个名为 `samp_db` 的数据库，可使用以下语句： - -{{< copyable "sql" >}} - -```sql -CREATE DATABASE IF NOT EXISTS samp_db; -``` - -使用 `SHOW DATABASES` 语句查看数据库： - -{{< copyable "sql" >}} - -```sql -SHOW DATABASES; -``` - -使用 `DROP DATABASE` 语句删除数据库，例如： - -{{< copyable "sql" >}} - -```sql -DROP DATABASE samp_db; -``` - -## 创建、查看和删除表 - -使用 `CREATE TABLE` 语句创建表。语法如下： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE table_name column_name data_type constraint; -``` - -例如： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE person ( - number INT(11), - name VARCHAR(255), - birthday DATE - ); -``` - -如果表已存在，添加 `IF NOT EXISTS` 可防止发生错误： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE IF NOT EXISTS person ( - number INT(11), - name VARCHAR(255), - birthday DATE -); -``` - -使用 `SHOW CREATE` 语句查看建表语句。例如： - -{{< copyable "sql" >}} - -```sql -SHOW CREATE table person; -``` - -使用 `SHOW FULL COLUMNS` 语句查看表的列。 例如： - -{{< copyable "sql" >}} - -```sql -SHOW FULL COLUMNS FROM person; -``` - -使用 `DROP TABLE` 语句删除表。例如： - -{{< copyable "sql" >}} - -```sql -DROP TABLE person; -``` - -或者 - -{{< copyable "sql" >}} - -```sql -DROP TABLE IF EXISTS person; -``` - -使用 `SHOW TABLES` 语句查看数据库中的所有表。例如： - -{{< copyable "sql" >}} - -```sql -SHOW TABLES FROM samp_db; -``` - -## 创建、查看和删除索引 - -对于值不唯一的列，可使用 `CREATE INDEX` 或 `ALTER TABLE` 语句。例如： - -{{< copyable "sql" >}} - -```sql -CREATE INDEX person_num ON person (number); -``` - -或者 - -{{< copyable "sql" >}} - -```sql -ALTER TABLE person ADD INDEX person_num (number); -``` - -对于值唯一的列，可以创建唯一索引。例如： - -{{< copyable "sql" >}} - -```sql -CREATE UNIQUE INDEX person_num ON person (number); -``` - -或者 - -{{< copyable "sql" >}} - -```sql -ALTER TABLE person ADD UNIQUE person_num (number); -``` - -使用 `SHOW INDEX` 语句查看表内所有索引： - -{{< copyable "sql" >}} - -```sql -SHOW INDEX from person; -``` - -使用 `ALTER TABLE` 或 `DROP INDEX` 语句来删除索引。与 `CREATE INDEX` 语句类似，`DROP INDEX` 也可以嵌入 `ALTER TABLE` 语句。例如： - -{{< copyable "sql" >}} - -```sql -DROP INDEX person_num ON person; -``` - -{{< copyable "sql" >}} - -```sql -ALTER TABLE person DROP INDEX person_num; -``` - -## 增删改查数据 - -使用 `INSERT` 语句向表内插入数据。例如： - -{{< copyable "sql" >}} - -```sql -INSERT INTO person VALUES("1","tom","20170912"); -``` - -使用 `SELECT` 语句检索表内数据。例如： - -{{< copyable "sql" >}} - -```sql -SELECT * FROM person; -``` - -``` -+--------+------+------------+ -| number | name | birthday | -+--------+------+------------+ -| 1 | tom | 2017-09-12 | -+--------+------+------------+ -``` - -使用 `UPDATE` 语句修改表内数据。例如： - -{{< copyable "sql" >}} - -```sql -UPDATE person SET birthday='20171010' WHERE name='tom'; -``` - -{{< copyable "sql" >}} - -```sql -SELECT * FROM person; -``` - -``` -+--------+------+------------+ -| number | name | birthday | -+--------+------+------------+ -| 1 | tom | 2017-10-10 | -+--------+------+------------+ -``` - -使用 `DELETE` 语句删除表内数据： - -{{< copyable "sql" >}} - -```sql -DELETE FROM person WHERE number=1; -``` - -{{< copyable "sql" >}} - -```sql -SELECT * FROM person; -``` - -``` -Empty set (0.00 sec) -``` - -## 创建、授权和删除用户 - -使用 `CREATE USER` 语句创建一个用户 `tiuser`，密码为 `123456`： - -{{< copyable "sql" >}} - -```sql -CREATE USER 'tiuser'@'localhost' IDENTIFIED BY '123456'; -``` - -授权用户 `tiuser` 可检索数据库 `samp_db` 内的表： - -{{< copyable "sql" >}} - -```sql -GRANT SELECT ON samp_db.* TO 'tiuser'@'localhost'; -``` - -查询用户 `tiuser` 的权限： - -{{< copyable "sql" >}} - -```sql -SHOW GRANTS for tiuser@localhost; -``` - -删除用户 `tiuser`： - -{{< copyable "sql" >}} - -```sql -DROP USER 'tiuser'@'localhost'; -``` diff --git a/dev/how-to/get-started/read-historical-data.md b/dev/how-to/get-started/read-historical-data.md deleted file mode 100644 index 4918803e5c69..000000000000 --- a/dev/how-to/get-started/read-historical-data.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -title: 读取历史数据 -category: how-to ---- - -# 读取历史数据 - -本文档介绍 TiDB 如何读取历史版本数据，包括具体的操作流程以及历史数据的保存策略。 - -## 功能说明 - -TiDB 实现了通过标准 SQL 接口读取历史数据功能，无需特殊的 client 或者 driver。当数据被更新、删除后，依然可以通过 SQL 接口将更新/删除前的数据读取出来。 - -另外即使在更新数据之后，表结构发生了变化，TiDB 依旧能用旧的表结构将数据读取出来。 - -## 操作流程 - -为支持读取历史版本数据， 引入了一个新的 system variable: tidb_snapshot ，这个变量是 Session 范围有效，可以通过标准的 Set 语句修改其值。其值为文本，能够存储 TSO 和日期时间。TSO 即是全局授时的时间戳，是从 PD 端获取的; 日期时间的格式可以为： -“2016-10-08 16:45:26.999”，一般来说可以只写到秒，比如”2016-10-08 16:45:26”。 -当这个变量被设置时，TiDB 会用这个时间戳建立 Snapshot（没有开销，只是创建数据结构），随后所有的 Select 操作都会在这个 Snapshot 上读取数据。 - -> **注意：** -> -> TiDB 的事务是通过 PD 进行全局授时，所以存储的数据版本也是以 PD 所授时间戳作为版本号。在生成 Snapshot 时，是以 tidb_snapshot 变量的值作为版本号，如果 TiDB Server 所在机器和 PD Server 所在机器的本地时间相差较大，需要以 PD 的时间为准。 - -当读取历史版本操作结束后，可以结束当前 Session 或者是通过 Set 语句将 tidb_snapshot 变量的值设为 ""，即可读取最新版本的数据。 - -## 历史数据保留策略 - -TiDB 使用 MVCC 管理版本，当更新/删除数据时，不会做真正的数据删除，只会添加一个新版本数据，所以可以保留历史数据。历史数据不会全部保留，超过一定时间的历史数据会被彻底删除，以减小空间占用以及避免历史版本过多引入的性能开销。 - -TiDB 使用周期性运行的 GC（Garbage Collection，垃圾回收）来进行清理，关于 GC 的详细介绍参见 [TiDB 垃圾回收 (GC)](/dev/reference/garbage-collection/overview.md)。 - -这里需要重点关注的是 `tikv_gc_life_time` 和 `tikv_gc_safe_point` 这条。`tikv_gc_life_time` 用于配置历史版本保留时间，可以手动修改；`tikv_gc_safe_point` 记录了当前的 safePoint，用户可以安全地使用大于 safePoint 的时间戳创建 snapshot 读取历史版本。safePoint 在每次 GC 开始运行时自动更新。 - -## 示例 - -1. 初始化阶段，创建一个表，并插入几行数据： - - {{< copyable "sql" >}} - - ```sql - create table t (c int); - ``` - - ``` - Query OK, 0 rows affected (0.01 sec) - ``` - - {{< copyable "sql" >}} - - ```sql - insert into t values (1), (2), (3); - ``` - - ``` - Query OK, 3 rows affected (0.00 sec) - ``` - -2. 查看表中的数据： - - {{< copyable "sql" >}} - - ```sql - select * from t; - ``` - - ``` - +------+ - | c | - +------+ - | 1 | - | 2 | - | 3 | - +------+ - 3 rows in set (0.00 sec) - ``` - -3. 查看当前时间： - - {{< copyable "sql" >}} - - ```sql - select now(); - ``` - - ``` - +---------------------+ - | now() | - +---------------------+ - | 2016-10-08 16:45:26 | - +---------------------+ - 1 row in set (0.00 sec) - ``` - -4. 更新某一行数据： - - {{< copyable "sql" >}} - - ```sql - update t set c=22 where c=2; - ``` - - ``` - Query OK, 1 row affected (0.00 sec) - ``` - -5. 确认数据已经被更新： - - {{< copyable "sql" >}} - - ```sql - select * from t; - ``` - - ``` - +------+ - | c | - +------+ - | 1 | - | 22 | - | 3 | - +------+ - 3 rows in set (0.00 sec) - ``` - -6. 设置一个特殊的环境变量，这个是一个 session scope 的变量，其意义为读取这个时间之前的最新的一个版本。 - - {{< copyable "sql" >}} - - ```sql - set @@tidb_snapshot="2016-10-08 16:45:26"; - ``` - - ``` - Query OK, 0 rows affected (0.00 sec) - ``` - - > **注意：** - > - > - 这里的时间设置的是 update 语句之前的那个时间。 - > - 在 `tidb_snapshot` 前须使用 `@@` 而非 `@`，因为 `@@` 表示系统变量，`@` 表示用户变量。 - - 这里读取到的内容即为 update 之前的内容，也就是历史版本： - - {{< copyable "sql" >}} - - ```sql - select * from t; - ``` - - ``` - +------+ - | c | - +------+ - | 1 | - | 2 | - | 3 | - +------+ - 3 rows in set (0.00 sec) - ``` - -7. 清空这个变量后，即可读取最新版本数据： - - {{< copyable "sql" >}} - - ```sql - set @@tidb_snapshot=""; - ``` - - ``` - Query OK, 0 rows affected (0.00 sec) - ``` - - {{< copyable "sql" >}} - - ```sql - select * from t; - ``` - - ``` - +------+ - | c | - +------+ - | 1 | - | 22 | - | 3 | - +------+ - 3 rows in set (0.00 sec) - ``` - - > **注意：** - > - > 在 `tidb_snapshot` 前须使用 `@@` 而非 `@`，因为 `@@` 表示系统变量，`@` 表示用户变量。 diff --git a/dev/how-to/get-started/tidb-binlog.md b/dev/how-to/get-started/tidb-binlog.md deleted file mode 100644 index e9b7f3c8f8c8..000000000000 --- a/dev/how-to/get-started/tidb-binlog.md +++ /dev/null @@ -1,521 +0,0 @@ ---- -title: TiDB Binlog 教程 -category: how-to ---- - -# TiDB Binlog 教程 - -本文档主要介绍如何使用 TiDB Binlog 将数据从 TiDB 推送到 MariaDB 实例。文中的 TiDB Binlog 集群包含 Pump 和 Drainer 的单个节点，TiDB 集群包含 TiDB、TiKV 和 Placement Driver (PD) 各组件的单个节点。 - -希望上手实践 TiDB Binlog 工具的用户需要对 [TiDB 架构](/dev/architecture.md)有一定的了解，最好有创建过 TiDB 集群的经验。该文档也有助于简单快速了解 TiDB Binlog 架构以及相关概念。 - -> **警告：** -> -> 该文档中部署 TiDB 的操作指导**不适用于**在生产或研发环境中部署 TiDB 的情况。 - -该文档假设用户使用的是现代 Linux 发行版本中的 x86-64。示例中使用的是 VMware 中运行的 CentOS 7 最小化安装。建议在一开始就进行清洁安装，以避免受现有环境中未知情况的影响。如果不想使用本地虚拟环境，也可以使用云服务启动 CentOS 7 VM。 - -## TiDB Binlog 简介 - -TiDB Binlog 用于收集 TiDB 中二进制日志数据、提供实时数据备份和同步以及将 TiDB 集群的数据增量同步到下游。 - -TiDB Binlog 支持以下功能场景： - -- 增量备份，将 TiDB 集群中的数据增量同步到另一个集群，或通过 Kafka 增量同步到选择的下游。 -- 当使用 TiDB DM (Data Migration) 将数据从上游 MySQL 或者 MariaDB 迁移到 TiDB 集群时，可使用 TiDB Binlog 保持 TiDB 集群与其一个独立下游 MySQL 或 MariaDB 实例或集群同步。当 TiDB 集群上游数据迁移过程中出现问题，下游数据同步过程中可使用 TiDB Binlog 恢复数据到原先的状态。 - -更多信息参考 [TiDB Binlog Cluster 版本用户文档](/dev/reference/tidb-binlog/overview.md)。 - -## 架构 - -TiDB Binlog 集群由 **Pump** 和 **Drainer** 两个组件组成。一个 Pump 集群中有若干个 Pump 节点。TiDB 实例连接到各个 Pump 节点并发送 binlog 数据到 Pump 节点。Pump 集群连接到 Drainer 节点，Drainer 将接收到的更新数据转换到某个特定下游（例如 Kafka、另一个 TiDB 集群或 MySQL 或 MariaDB Server）指定的正确格式。 - -![TiDB Binlog architecture](/media/tidb_binlog_cluster_architecture.png) - -Pump 的集群架构能确保 TiDB 或 Pump 集群中有新的实例加入或退出时更新数据不会丢失。 - -## 安装 - -由于 RHEL/CentOS 7 的默认包装库中包括 MariaDB Server，本示例选择的是 MariaDB Server。后续除了安装服务器，也需要安装客户端。安装指令如下： - -{{< copyable "shell-regular" >}} - -```bash -sudo yum install -y mariadb-server -``` - -{{< copyable "shell-regular" >}} - -```bash -curl -LO https://download.pingcap.org/tidb-latest-linux-amd64.tar.gz | tar xzf - && -cd tidb-latest-linux-amd64 -``` - -预期输出： - -``` - % Total % Received % Xferd Average Speed Time Time Time Current - Dload Upload Total Spent Left Speed -100 368M 100 368M 0 0 8394k 0 0:00:44 0:00:44 --:--:-- 11.1M -``` - -## 配置 - -通过执行以下步骤配置一个 TiDB 集群，该集群包括 `pd-server`、`tikv-server` 和 `tidb-server` 各组件的单个实例。 - -1. 填充配置文件： - - {{< copyable "shell-regular" >}} - - ```bash - printf > pd.toml %s\\n 'log-file="pd.log"' 'data-dir="pd.data"' && - printf > tikv.toml %s\\n 'log-file="tikv.log"' '[storage]' 'data-dir="tikv.data"' '[pd]' 'endpoints=["127.0.0.1:2379"]' '[rocksdb]' max-open-files=1024 '[raftdb]' max-open-files=1024 && - printf > pump.toml %s\\n 'log-file="pump.log"' 'data-dir="pump.data"' 'addr="127.0.0.1:8250"' 'advertise-addr="127.0.0.1:8250"' 'pd-urls="http://127.0.0.1:2379"' && - printf > tidb.toml %s\\n 'store="tikv"' 'path="127.0.0.1:2379"' '[log.file]' 'filename="tidb.log"' '[binlog]' 'enable=true' && - printf > drainer.toml %s\\n 'log-file="drainer.log"' '[syncer]' 'db-type="mysql"' '[syncer.to]' 'host="127.0.0.1"' 'user="root"' 'password=""' 'port=3306' - ``` - -2. 查看配置细节： - - {{< copyable "shell-regular" >}} - - ```bash - for f in *.toml; do echo "$f:"; cat "$f"; echo; done - ``` - - 预期输出： - - ``` - drainer.toml: - log-file="drainer.log" - [syncer] - db-type="mysql" - [syncer.to] - host="127.0.0.1" - user="root" - password="" - port=3306 - - pd.toml: - log-file="pd.log" - data-dir="pd.data" - - pump.toml: - log-file="pump.log" - data-dir="pump.data" - addr="127.0.0.1:8250" - advertise-addr="127.0.0.1:8250" - pd-urls="http://127.0.0.1:2379" - - tidb.toml: - store="tikv" - path="127.0.0.1:2379" - [log.file] - filename="tidb.log" - [binlog] - enable=true - - tikv.toml: - log-file="tikv.log" - [storage] - data-dir="tikv.data" - [pd] - endpoints=["127.0.0.1:2379"] - [rocksdb] - max-open-files=1024 - [raftdb] - max-open-files=1024 - ``` - -## 启动程序 - -现在可启动各个组件。推荐启动顺序依次为 Placement Driver (PD)、TiKV、Pump（TiDB 发送 binlog 日志必须连接 Pump 服务）、TiDB。 - -1. 启动所有服务： - - {{< copyable "shell-regular" >}} - - ```bash - ./bin/pd-server --config=pd.toml &>pd.out & - ``` - - ``` - [1] 20935 - ``` - - {{< copyable "shell-regular" >}} - - ```bash - ./bin/tikv-server --config=tikv.toml &>tikv.out & - ``` - - ``` - [2] 20944 - ``` - - {{< copyable "shell-regular" >}} - - ```bash - ./bin/pump --config=pump.toml &>pump.out & - ``` - - ``` - [3] 21050 - ``` - - {{< copyable "shell-regular" >}} - - ```bash - sleep 3 && - ./bin/tidb-server --config=tidb.toml &>tidb.out & - ``` - - ``` - [4] 21058 - ``` - -2. 如果执行 `jobs`，可以看到后台正在运行的程序，列表如下： - - {{< copyable "shell-regular" >}} - - ```bash - jobs - ``` - - ``` - [1] Running ./bin/pd-server --config=pd.toml &>pd.out & - [2] Running ./bin/tikv-server --config=tikv.toml &>tikv.out & - [3]- Running ./bin/pump --config=pump.toml &>pump.out & - [4]+ Running ./bin/tidb-server --config=tidb.toml &>tidb.out & - ``` - - 如果有服务启动失败（例如出现 “`Exit 1`” 而不是 “`Running`”），尝试重启单个组件。 - -## 连接 - -按以上步骤操作后，TiDB 的 4 个组件开始运行。接下来可以使用以下 MariaDB 或 MySQL 命令行客户端，通过 4000 端口连接到 TiDB 服务： - -{{< copyable "shell-regular" >}} - -```bash -mysql -h 127.0.0.1 -P 4000 -u root -e 'select tidb_version();' -``` - -预期输出： - -``` -*************************** 1. row *************************** -tidb_version(): Release Version: v3.0.0-beta.1-154-gd5afff70c -Git Commit Hash: d5afff70cdd825d5fab125c8e52e686cc5fb9a6e -Git Branch: master -UTC Build Time: 2019-04-24 03:10:00 -GoVersion: go version go1.12 linux/amd64 -Race Enabled: false -TiKV Min Version: 2.1.0-alpha.1-ff3dd160846b7d1aed9079c389fc188f7f5ea13e -Check Table Before Drop: false -``` - -连接后TiDB 集群已开始运行，`pump` 读取集群中的 binlog 数据，并在其数据目录中将 binlog 数据存储为 relay log。下一步是启动一个可供 `drainer` 写入的 MariaDB Server。 - -1. 启动 `drainer`： - - {{< copyable "shell-regular" >}} - - ```bash - sudo systemctl start mariadb && - ./bin/drainer --config=drainer.toml &>drainer.out & - ``` - - 如果你的操作系统更易于安装 MySQL，只需保证监听 3306 端口。另外，可使用密码为空的 "root" 用户连接到 MySQL，或调整 `drainer.toml` 连接到 MySQL。 - - {{< copyable "shell-regular" >}} - - ```bash - mysql -h 127.0.0.1 -P 3306 -u root - ``` - - 预期输出： - - ``` - Welcome to the MariaDB monitor. Commands end with ; or \g. - Your MariaDB connection id is 20 - Server version: 5.5.60-MariaDB MariaDB Server - - Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. - - Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. - - MariaDB [(none)]> - ``` - - {{< copyable "sql" >}} - - ```sql - show databases; - ``` - - 预期输出： - - ``` - +--------------------+ - | Database | - +--------------------+ - | information_schema | - | mysql | - | performance_schema | - | test | - | tidb_binlog | - +--------------------+ - 5 rows in set (0.01 sec) - ``` - - 如下表格是包含 `checkpoint` 表格的 `tidb_binlog` 数据库。`drainer` 使用 `checkpoint` 表格，记录 TiDB 集群中的 binlog 已经更新到了哪个位置。 - - {{< copyable "sql" >}} - - ```sql - use tidb_binlog; - ``` - - ``` - Database changed - ``` - - {{< copyable "sql" >}} - - ```sql - select * from checkpoint; - ``` - - ``` - +---------------------+---------------------------------------------+ - | clusterID | checkPoint | - +---------------------+---------------------------------------------+ - | 6678715361817107733 | {"commitTS":407637466476445697,"ts-map":{}} | - +---------------------+---------------------------------------------+ - 1 row in set (0.00 sec) - ``` - - 打开另一个连接到 TiDB 的客户端，创建一个表格并插入几行数据。建议在 GNU Screen 软件中操作，从而同时打开多个客户端。 - - {{< copyable "shell-regular" >}} - - ```bash - mysql -h 127.0.0.1 -P 4000 --prompt='TiDB [\d]> ' -u root - ``` - - {{< copyable "sql" >}} - - ```sql - create database tidbtest; - ``` - - ``` - Query OK, 0 rows affected (0.12 sec) - ``` - - {{< copyable "sql" >}} - - ```sql - use tidbtest; - ``` - - ``` - Database changed - ``` - - {{< copyable "sql" >}} - - ```sql - create table t1 (id int unsigned not null AUTO_INCREMENT primary key); - ``` - - ``` - Query OK, 0 rows affected (0.11 sec) - ``` - - {{< copyable "sql" >}} - - ```sql - insert into t1 () values (),(),(),(),(); - ``` - - ``` - Query OK, 5 rows affected (0.01 sec) - Records: 5 Duplicates: 0 Warnings: 0 - ``` - - {{< copyable "sql" >}} - - ```sql - select * from t1; - ``` - - ``` - +----+ - | id | - +----+ - | 1 | - | 2 | - | 3 | - | 4 | - | 5 | - +----+ - 5 rows in set (0.00 sec) - ``` - - 切换回 MariaDB 客户端可看到新的数据库、新的表格和最近插入的行数据。 - - {{< copyable "sql" >}} - - ```sql - use tidbtest; - ``` - - ``` - Reading table information for completion of table and column names - You can turn off this feature to get a quicker startup with -A - - Database changed - ``` - - {{< copyable "sql" >}} - - ```sql - show tables; - ``` - - ``` - +--------------------+ - | Tables_in_tidbtest | - +--------------------+ - | t1 | - +--------------------+ - 1 row in set (0.00 sec) - ``` - - {{< copyable "sql" >}} - - ```sql - select * from t1; - ``` - - ``` - +----+ - | id | - +----+ - | 1 | - | 2 | - | 3 | - | 4 | - | 5 | - +----+ - 5 rows in set (0.00 sec) - ``` - - 可看到查询 MariaDB 时插入到 TiDB 相同的行数据，表明 TiDB Binlog 安装成功。 - -## binlogctl - -加入到集群的 Pump 和 Drainer 的数据存储在 Placement Driver (PD) 中。binlogctl 可用于查询和修改状态信息。更多信息请参考 [binlogctl guide](/dev/reference/tidb-binlog/maintain.md#binlogctl-工具)。 - -使用 `binlogctl` 查看集群中 Pump 和 Drainer 的当前状态： - -{{< copyable "shell-regular" >}} - -```bash -./bin/binlogctl -cmd drainers -``` - -``` -[2019/04/11 17:44:10.861 -04:00] [INFO] [nodes.go:47] ["query node"] [type=drainer] [node="{NodeID: localhost.localdomain:8249, Addr: 192.168.236.128:8249, State: online, MaxCommitTS: 407638907719778305, UpdateTime: 2019-04-11 17:44:10 -0400 EDT}"] -``` - -{{< copyable "shell-regular" >}} - -```bash -./bin/binlogctl -cmd pumps -``` - -``` -[2019/04/11 17:44:13.904 -04:00] [INFO] [nodes.go:47] ["query node"] [type=pump] [node="{NodeID: localhost.localdomain:8250, Addr: 192.168.236.128:8250, State: online, MaxCommitTS: 407638914024079361, UpdateTime: 2019-04-11 17:44:13 -0400 EDT}"] -``` - -如果结束 Drainer 进程，集群会改进程设置“已暂停（即集群等待 Drainer 重新加入）”的状态。 - -{{< copyable "shell-regular" >}} - -```bash -pkill drainer && -./bin/binlogctl -cmd drainers -``` - -预期输出： - -``` -[2019/04/11 17:44:22.640 -04:00] [INFO] [nodes.go:47] ["query node"] [type=drainer] [node="{NodeID: localhost.localdomain:8249, Addr: 192.168.236.128:8249, State: paused, MaxCommitTS: 407638915597467649, UpdateTime: 2019-04-11 17:44:18 -0400 EDT}"] -``` - -使用 binlogctl 的 "NodeIDs" 可控制单个对应节点。在该情况下，Drainer 的节点 ID 是 "localhost.localdomain:8249"，Pump 的节点 ID 是 "localhost.localdomain:8250"。 - -本文档中的 binlogctl 主要用于集群重启。如果在 TiDB 集群中终止并尝试重启所有的进程，由于 Pump 无法连接 Drainer 且认为 Drainer 依旧“在线”，Pump 会拒绝启动。这里的进程并不包括下游的 MySQL 或 MariaDB 或 Drainer。 - -以下有三个方案可解决上述问题： - -- 使用 binlogctl 停止 Drainer，而不是结束进程： - - ```bash - ./bin/binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=drainers && - ./bin/binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=pause-drainer --node-id=localhost.localdomain:8249 - ``` - -- 在启动 Pump **之前**先启动 Drainer。 - -- 在启动 PD 之后但在启动 Drainer 和 Pump 之前，使用 binlogctl 更新已暂定 Drainer 的状态。 - - ```bash - ./bin/binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=update-drainer --node-id=localhost.localdomain:8249 --state=paused - ``` - -## 清理 - -在 shell 终端里可启动创建集群的所有进程（`pd-server` 、`tikv-server`、`pump`、`tidb-server`、`drainer`）。可通过在 shell 终端中执行 `pkill -P $$` 停止 TiDB 集群服务和 TiDB Binlog 进程。按一定的顺序停止这些进程有利于留出足够的时间彻底关闭每个组件。 - -{{< copyable "shell-regular" >}} - -```bash -for p in tidb-server drainer pump tikv-server pd-server; do pkill "$p"; sleep 1; done -``` - -预期输出： - -``` -[4]- Done ./bin/tidb-server --config=tidb.toml &>tidb.out -[5]+ Done ./bin/drainer --config=drainer.toml &>drainer.out -[3]+ Done ./bin/pump --config=pump.toml &>pump.out -[2]+ Done ./bin/tikv-server --config=tikv.toml &>tikv.out -[1]+ Done ./bin/pd-server --config=pd.toml &>pd.out -``` - -如果需要所有服务退出后重启集群，可以使用一开始启动服务的命令。如以上 [`binlogctl`](#binlogctl) 部分所述，需要先启动 Drainer 再启动 Pump，最后启动 `tidb-server`。 - -{{< copyable "shell-regular" >}} - -```bash -./bin/pd-server --config=pd.toml &>pd.out & -./bin/tikv-server --config=tikv.toml &>tikv.out & -./bin/drainer --config=drainer.toml &>drainer.out & -sleep 3 -./bin/pump --config=pump.toml &>pump.out & -sleep 3 -./bin/tidb-server --config=tidb.toml &>tidb.out & -``` - -如果有组件启动失败，请尝试单独重启该组件。 - -## 总结 - -本文档介绍了如何通过设置 TiDB Binlog，使用单个 Pump 和 Drainer 组成的集群同步 TiDB 集群数据到下游的 MariaDB。可以发现，TiDB Binlog 是用于获取处理 TiDB 集群中更新数据的综合性平台工具。 - -在更稳健的开发、测试或生产部署环境中，可以使用多个 TiDB 服务以实现高可用性和扩展性。使用多个 Pump 实例可以避免 Pump 集群中的问题影响发送到 TiDB 实例的应用流量。或者可以使用增加的 Drainer 实例同步数据到不同的下游或实现数据增量备份。 -binlog \ No newline at end of file diff --git a/dev/how-to/maintain/ansible-operations.md b/dev/how-to/maintain/ansible-operations.md deleted file mode 100644 index 6e79a18ab33c..000000000000 --- a/dev/how-to/maintain/ansible-operations.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: TiDB Ansible 常见运维操作 -category: how-to ---- - -# TiDB Ansible 常见运维操作 - -## 启动集群 - -此操作会按顺序启动整个 TiDB 集群所有组件（包括 PD、TiDB、TiKV 等组件和监控组件）。 - -{{< copyable "shell-regular" >}} - -```bash -ansible-playbook start.yml -``` - -## 关闭集群 - -此操作会按顺序关闭整个 TiDB 集群所有组件（包括 PD、TiDB、TiKV 等组件和监控组件）。 - -{{< copyable "shell-regular" >}} - -```bash -ansible-playbook stop.yml -``` - -## 清除集群数据 - -此操作会关闭 TiDB、Pump、TiKV、PD 服务，并清空 Pump、TiKV、PD 数据目录。 - -{{< copyable "shell-regular" >}} - -```bash -ansible-playbook unsafe_cleanup_data.yml -``` - -## 销毁集群 - -此操作会关闭集群，并清空部署目录，若部署目录为挂载点，会报错，可忽略。 - -{{< copyable "shell-regular" >}} - -```bash -ansible-playbook unsafe_cleanup.yml -``` diff --git a/dev/how-to/maintain/backup-and-restore/mydumper-lightning.md b/dev/how-to/maintain/backup-and-restore/mydumper-lightning.md deleted file mode 100644 index ac8a54e2bed9..000000000000 --- a/dev/how-to/maintain/backup-and-restore/mydumper-lightning.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: 使用 Mydumper/TiDB Lightning 进行备份与恢复 -category: how-to -aliases: ['/docs-cn/dev/how-to/maintain/backup-and-restore/'] ---- - -# 使用 Mydumper/TiDB Lightning 进行备份与恢复 - -本文档将详细介绍如何使用 Mydumper/TiDB Lightning 对 TiDB 进行全量备份与恢复。增量备份与恢复可使用 [TiDB Binlog](/dev/reference/tidb-binlog/overview.md)。 - -这里假定 TiDB 服务信息如下： - -|Name|Address|Port|User|Password| -|----|-------|----|----|--------| -|TiDB|127.0.0.1|4000|root|*| - -在这个备份恢复过程中，会用到下面的工具： - -- [Mydumper](/dev/reference/tools/mydumper.md) 从 TiDB 导出数据 -- [TiDB Lightning](/dev/reference/tools/tidb-lightning/overview.md) 导入数据到 TiDB - -## 使用 Mydumper/TiDB Lightning 全量备份恢复数据 - -`mydumper` 是一个强大的数据备份工具，具体可以参考 [`maxbube/mydumper`](https://github.com/maxbube/mydumper)。 - -可使用 [Mydumper](/dev/reference/tools/mydumper.md) 从 TiDB 导出数据进行备份，然后用 [TiDB Lightning](/dev/reference/tools/tidb-lightning/overview.md) 将其导入到 TiDB 里面进行恢复。 - -> **注意：** -> -> PingCAP 研发团队对 `mydumper` 进行了针对 TiDB 的适配性改造，建议使用 PingCAP 官方提供的 [Mydumper](/dev/reference/tools/mydumper.md)。由于使用 `mysqldump` 进行数据备份和恢复都要耗费许多时间，这里也并不推荐。 - -### Mydumper/TiDB Lightning 全量备份恢复最佳实践 - -为了快速地备份恢复数据 (特别是数据量巨大的库)，可以参考以下建议： - -* 导出来的数据文件应当尽可能的小，可以通过设置参数 `-F` 来控制导出来的文件大小。如果后续使用 TiDB Lightning 对备份文件进行恢复，建议把 `mydumper` -F 参数的值设置为 `256`（单位 MB）；如果使用 `loader` 恢复，则建议设置为 `64`（单位 MB）。 - -## 从 TiDB 备份数据 - -我们使用 `mydumper` 从 TiDB 备份数据，如下: - -{{< copyable "shell-regular" >}} - -```bash -./bin/mydumper -h 127.0.0.1 -P 4000 -u root -t 32 -F 256 -B test -T t1,t2 --skip-tz-utc -o ./var/test -``` - -上面，我们使用 `-B test` 表明是对 `test` 这个 database 操作，然后用 `-T t1,t2` 表明只导出 `t1`，`t2` 两张表。 - -`-t 32` 表明使用 32 个线程去导出数据。`-F 256` 是将实际的表切分成一定大小的 chunk，这里的 chunk 大小为 256MB。 - -添加 `--skip-tz-utc` 参数后，会忽略掉 TiDB 与导数据的机器之间时区设置不一致的情况，禁止自动转换。 - -如果 `mydumper` 出现以下报错： - -``` -** (mydumper:27528): CRITICAL **: 13:25:09.081: Could not read data from testSchema.testTable: GC life time is shorter than transaction duration, transaction starts at 2019-08-05 21:10:01.451 +0800 CST, GC safe point is 2019-08-05 21:14:53.801 +0800 CST -``` - -就再执行两步命令： - -1. 执行 `mydumper` 命令前，查询 TiDB 集群的 [GC](/dev/reference/garbage-collection/overview.md) 值并使用 MySQL 客户端将其调整为合适的值： - - {{< copyable "sql" >}} - - ```sql - SELECT * FROM mysql.tidb WHERE VARIABLE_NAME = 'tikv_gc_life_time'; - ``` - - ``` - +-----------------------+------------------------------------------------------------------------------------------------+ - | VARIABLE_NAME | VARIABLE_VALUE | - +-----------------------+------------------------------------------------------------------------------------------------+ - | tikv_gc_life_time | 10m0s | - +-----------------------+------------------------------------------------------------------------------------------------+ - 1 rows in set (0.02 sec) - ``` - - {{< copyable "sql" >}} - - ```sql - update mysql.tidb set VARIABLE_VALUE = '720h' where VARIABLE_NAME = 'tikv_gc_life_time'; - ``` - -2. 执行 `mydumper` 命令后，将 TiDB 集群的 GC 值恢复到第 1 步中的初始值： - - {{< copyable "sql" >}} - - ```sql - update mysql.tidb set VARIABLE_VALUE = '10m' where VARIABLE_NAME = 'tikv_gc_life_time'; - ``` - -## 向 TiDB 恢复数据 - -使用 TiDB Lightning 将之前导出的数据导入到 TiDB，完成恢复操作。具体的使用方法见 [TiDB Lightning 使用文档](/dev/reference/tools/tidb-lightning/tidb-backend.md) diff --git a/dev/how-to/maintain/identify-abnormal-queries/identify-slow-queries.md b/dev/how-to/maintain/identify-abnormal-queries/identify-slow-queries.md deleted file mode 100644 index c1bd188e1bc1..000000000000 --- a/dev/how-to/maintain/identify-abnormal-queries/identify-slow-queries.md +++ /dev/null @@ -1,332 +0,0 @@ ---- -title: 慢查询日志 -category: how-to -aliases: ['/docs-cn/sql/slow-query/','/docs-cn/dev/how-to/maintain/identify-slow-queries/'] ---- - -# 慢查询日志 - -TiDB 会将执行时间超过 [slow-threshold](/dev/reference/configuration/tidb-server/configuration-file.md#slow-threshold)（默认值为 300 毫秒）的语句输出到 [slow-query-file](/dev/reference/configuration/tidb-server/configuration-file.md#slow-query-file)（默认值："tidb-slow.log"）日志文件中，用于帮助用户定位慢查询语句，分析和解决 SQL 执行的性能问题。 - -## 日志示例 - -```sql -# Time: 2019-08-14T09:26:59.487776265+08:00 -# Txn_start_ts: 410450924122144769 -# User: root@127.0.0.1 -# Conn_ID: 3086 -# Query_time: 1.527627037 -# Parse_time: 0.000054933 -# Compile_time: 0.000129729 -# Process_time: 0.07 Request_count: 1 Total_keys: 131073 Process_keys: 131072 Prewrite_time: 0.335415029 Commit_time: 0.032175429 Get_commit_ts_time: 0.000177098 Local_latch_wait_time: 0.106869448 Write_keys: 131072 Write_size: 3538944 Prewrite_region: 1 -# DB: test -# Is_internal: false -# Digest: 50a2e32d2abbd6c1764b1b7f2058d428ef2712b029282b776beb9506a365c0f1 -# Stats: t:pseudo -# Num_cop_tasks: 1 -# Cop_proc_avg: 0.07 Cop_proc_p90: 0.07 Cop_proc_max: 0.07 Cop_proc_addr: 172.16.5.87:20171 -# Cop_wait_avg: 0 Cop_wait_p90: 0 Cop_wait_max: 0 Cop_wait_addr: 172.16.5.87:20171 -# Mem_max: 525211 -# Succ: true -# Plan: tidb_decode_plan('ZJAwCTMyXzcJMAkyMAlkYXRhOlRhYmxlU2Nhbl82CjEJMTBfNgkxAR0AdAEY1Dp0LCByYW5nZTpbLWluZiwraW5mXSwga2VlcCBvcmRlcjpmYWxzZSwgc3RhdHM6cHNldWRvCg==') -insert into t select * from t; -``` - -## 字段含义说明 - -> **注意：** -> -> 慢查询日志中所有时间相关字段的单位都是 **“秒”** - -Slow Query 基础信息： - -* `Time`：表示日志打印时间。 -* `Query_time`：表示执行这个语句花费的时间。 -* `Parse_time`：表示这个语句在语法解析阶段花费的时间。 -* `Compile_time`：表示这个语句在查询优化阶段花费的时间。 -* `Query`：表示 SQL 语句。慢日志里面不会打印 `Query`，但映射到内存表后，对应的字段叫 `Query`。 -* `Digest`：表示 SQL 语句的指纹。 -* `Txn_start_ts`：表示事务的开始时间戳，也是事务的唯一 ID，可以用这个值在 TiDB 日志中查找事务相关的其他日志。 -* `Is_internal`：表示是否为 TiDB 内部的 SQL 语句。`true` 表示 TiDB 系统内部执行的 SQL 语句，`false` 表示用户执行的 SQL 语句。 -* `Index_ids`：表示语句涉及到的索引的 ID。 -* `Succ`：表示语句是否执行成功。 -* `Backoff_time`：表示语句遇到需要重试的错误时在重试前等待的时间，常见的需要重试的错误有以下几种：遇到了 lock、Region 分裂、`tikv server is busy`。 -* `Plan`：表示语句的执行计划，用 `select tidb_decode_plan('xxx...')` SQL 语句可以解析出具体的执行计划。 - -和事务执行相关的字段： - -* `Prewrite_time`：表示事务两阶段提交中第一阶段（prewrite 阶段）的耗时。 -* `Commit_time`：表示事务两阶段提交中第二阶段（commit 阶段）的耗时。 -* `Get_commit_ts_time`：表示事务两阶段提交中第二阶段（commit 阶段）获取 commit 时间戳的耗时。 -* `Local_latch_wait_time`：表示事务两阶段提交中第二阶段（commit 阶段）发起前在 TiDB 侧等锁的耗时。 -* `Write_keys`：表示该事务向 TiKV 的 Write CF 写入 Key 的数量。 -* `Write_size`：表示事务提交时写 key 或 value 的总大小。 -* `Prewrite_region`：表示事务两阶段提交中第一阶段（prewrite 阶段）涉及的 TiKV Region 数量。每个 Region 会触发一次远程过程调用。 - -和内存使用相关的字段： - -* `Memory_max`：表示执行期间 TiDB 使用的最大内存空间，单位为 byte。 - -和 SQL 执行的用户相关的字段： - -* `User`：表示执行语句的用户名。 -* `Conn_ID`：表示用户的链接 ID，可以用类似 `con:3` 的关键字在 TiDB 日志中查找该链接相关的其他日志。 -* `DB`：表示执行语句时使用的 database。 - -和 TiKV Coprocessor Task 相关的字段： - -* `Request_count`：表示这个语句发送的 Coprocessor 请求的数量。 -* `Total_keys`：表示 Coprocessor 扫过的 key 的数量。 -* `Process_time`：执行 SQL 在 TiKV 的处理时间之和，因为数据会并行的发到 TiKV 执行，这个值可能会超过 `Query_time`。 -* `Wait_time`：表示这个语句在 TiKV 的等待时间之和，因为 TiKV 的 Coprocessor 线程数是有限的，当所有的 Coprocessor 线程都在工作的时候，请求会排队；当队列中有某些请求耗时很长的时候，后面的请求的等待时间都会增加。 -* `Process_keys`：表示 Coprocessor 处理的 key 的数量。相比 total_keys，processed_keys 不包含 MVCC 的旧版本。如果 processed_keys 和 total_keys 相差很大，说明旧版本比较多。 -* `Cop_proc_avg`：cop-task 的平均执行时间。 -* `Cop_proc_p90`：cop-task 的 P90 分位执行时间。 -* `Cop_proc_max`：cop-task 的最大执行时间。 -* `Cop_proc_addr`：执行时间最长的 cop-task 所在地址。 -* `Cop_wait_avg`：cop-task 的平均等待时间。 -* `Cop_wait_p90`：cop-task 的 P90 分位等待时间。 -* `Cop_wait_max`：cop-task 的最大等待时间。 -* `Cop_wait_addr`：等待时间最长的 cop-task 所在地址。 - -## 慢日志内存映射表 - -用户可通过查询 `INFORMATION_SCHEMA.SLOW_QUERY` 表来查询慢查询日志中的内容，表中列名和慢日志中字段名一一对应，表结构可查看 [Information Schema](/dev/reference/system-databases/information-schema.md#information-schema) 中关于 `SLOW_QUERY` 表的介绍。 - -> **注意：** -> -> 每次查询 `SLOW_QUERY` 表时，TiDB 都会去读取和解析一次当前的慢查询日志。 - -## 查询 `SLOW_QUERY` 示例 - -### 搜索 Top N 的慢查询 - -查询 Top 2 的用户慢查询。`is_internal=false` 表示排除 TiDB 内部的慢查询，只看用户的慢查询： - -{{< copyable "sql" >}} - -```sql -select query_time, query -from information_schema.slow_query -where is_internal = false -- 排除 TiDB 内部的慢查询 SQL -order by query_time desc -limit 2; -``` - -输出样例： - -``` -+--------------+------------------------------------------------------------------+ -| query_time | query | -+--------------+------------------------------------------------------------------+ -| 12.77583857 | select * from t_slim, t_wide where t_slim.c0=t_wide.c0; | -| 0.734982725 | select t0.c0, t1.c1 from t_slim t0, t_wide t1 where t0.c0=t1.c0; | -+--------------+------------------------------------------------------------------+ -``` - -### 搜索某个用户的 Top N 慢查询 - -下面例子中搜索 test 用户执行的慢查询 SQL，且按执行消耗时间逆序排序显式前 2 条： - -{{< copyable "sql" >}} - -```sql -select query_time, query, user -from information_schema.slow_query -where is_internal = false -- 排除 TiDB 内部的慢查询 SQL - and user = "test" -- 查找的用户名 -order by query_time desc -limit 2; -``` - -输出样例： - -``` -+-------------+------------------------------------------------------------------+----------------+ -| Query_time | query | user | -+-------------+------------------------------------------------------------------+----------------+ -| 0.676408014 | select t0.c0, t1.c1 from t_slim t0, t_wide t1 where t0.c0=t1.c1; | test | -+-------------+------------------------------------------------------------------+----------------+ -``` - -### 根据 SQL 指纹搜索同类慢查询 - -在得到 Top N 的慢查询 SQL 后，可通过 SQL 指纹继续搜索同类慢查询 SQL。 - -先获取 Top N 的慢查询和对应的 SQL 指纹： - -{{< copyable "sql" >}} - -```sql -select query_time, query, digest -from information_schema.slow_query -where is_internal = false -order by query_time desc -limit 1; -``` - -输出样例： - -``` -+-------------+-----------------------------+------------------------------------------------------------------+ -| query_time | query | digest | -+-------------+-----------------------------+------------------------------------------------------------------+ -| 0.302558006 | select * from t1 where a=1; | 4751cb6008fda383e22dacb601fde85425dc8f8cf669338d55d944bafb46a6fa | -+-------------+-----------------------------+------------------------------------------------------------------+ -``` - -再根据 SQL 指纹搜索同类慢查询： - -{{< copyable "sql" >}} - -```sql -select query, query_time -from information_schema.slow_query -where digest = "4751cb6008fda383e22dacb601fde85425dc8f8cf669338d55d944bafb46a6fa"; -``` - -输出样例： - -``` -+-----------------------------+-------------+ -| query | query_time | -+-----------------------------+-------------+ -| select * from t1 where a=1; | 0.302558006 | -| select * from t1 where a=2; | 0.401313532 | -+-----------------------------+-------------+ -``` - -### 搜索统计信息为 pseudo 的慢查询 SQL 语句 - -{{< copyable "sql" >}} - -```sql -select query, query_time, stats -from information_schema.slow_query -where is_internal = false - and stats like '%pseudo%'; -``` - -输出样例： - -``` -+-----------------------------+-------------+---------------------------------+ -| query | query_time | stats | -+-----------------------------+-------------+---------------------------------+ -| select * from t1 where a=1; | 0.302558006 | t1:pseudo | -| select * from t1 where a=2; | 0.401313532 | t1:pseudo | -| select * from t1 where a>2; | 0.602011247 | t1:pseudo | -| select * from t1 where a>3; | 0.50077719 | t1:pseudo | -| select * from t1 join t2; | 0.931260518 | t1:407872303825682445,t2:pseudo | -+-----------------------------+-------------+---------------------------------+ -``` - -## 解析其他的 TiDB 慢日志文件 - -TiDB 通过 session 变量 `tidb_slow_query_file` 控制查询 `INFORMATION_SCHEMA.SLOW_QUERY` 时要读取和解析的文件，可通过修改改 session 变量的值来查询其他慢查询日志文件的内容： - -{{< copyable "sql" >}} - -```sql -set tidb_slow_query_file = "/path-to-log/tidb-slow.log" -``` - -## 用 `pt-query-digest` 工具分析 TiDB 慢日志 - -可以用 `pt-query-digest` 工具分析 TiDB 慢日志。 - -> **注意：** -> -> 建议使用 pt-query-digest 3.0.13 及以上版本。 - -示例如下： - -{{< copyable "shell" >}} - -```shell -pt-query-digest --report tidb-slow.log -``` - -输出样例： - -``` -# 320ms user time, 20ms system time, 27.00M rss, 221.32M vsz -# Current date: Mon Mar 18 13:18:51 2019 -# Hostname: localhost.localdomain -# Files: tidb-slow.log -# Overall: 1.02k total, 21 unique, 0 QPS, 0x concurrency _________________ -# Time range: 2019-03-18-12:22:16 to 2019-03-18-13:08:52 -# Attribute total min max avg 95% stddev median -# ============ ======= ======= ======= ======= ======= ======= ======= -# Exec time 218s 10ms 13s 213ms 30ms 1s 19ms -# Query size 175.37k 9 2.01k 175.89 158.58 122.36 158.58 -# Commit time 46ms 2ms 7ms 3ms 7ms 1ms 3ms -# Conn ID 71 1 16 8.88 15.25 4.06 9.83 -# Process keys 581.87k 2 103.15k 596.43 400.73 3.91k 400.73 -# Process time 31s 1ms 10s 32ms 19ms 334ms 16ms -# Request coun 1.97k 1 10 2.02 1.96 0.33 1.96 -# Total keys 636.43k 2 103.16k 652.35 793.42 3.97k 400.73 -# Txn start ts 374.38E 0 16.00E 375.48P 1.25P 89.05T 1.25P -# Wait time 943ms 1ms 19ms 1ms 2ms 1ms 972us -. -. -. -``` - -### 定位问题语句的方法 - -并不是所有 SLOW_QUERY 的语句都是有问题的。会造成集群整体压力增大的，是那些 process_time 很大的语句。wait_time 很大，但 process_time 很小的语句通常不是问题语句，是因为被问题语句阻塞，在执行队列等待造成的响应时间过长。 - -## `admin show slow` 命令 - -除了获取 TiDB 日志，还有一种定位慢查询的方式是通过 `admin show slow` SQL 命令： - -{{< copyable "sql" >}} - -```sql -admin show slow recent N; -``` - -{{< copyable "sql" >}} - -```sql -admin show slow top [internal | all] N; -``` - -`recent N` 会显示最近的 N 条慢查询记录，例如： - -{{< copyable "sql" >}} - -```sql -admin show slow recent 10; -``` - -`top N` 则显示最近一段时间（大约几天）内，最慢的查询记录。如果指定 `internal` 选项，则返回查询系统内部 SQL 的慢查询记录；如果指定 `all` 选项，返回系统内部和用户 SQL 汇总以后的慢查询记录；默认只返回用户 SQL 中的慢查询记录。 - -{{< copyable "sql" >}} - -```sql -admin show slow top 3; -admin show slow top internal 3; -admin show slow top all 5; -``` - -由于内存限制，保留的慢查询记录的条数是有限的。当命令查询的 `N` 大于记录条数时，返回的结果记录条数会小于 `N`。 - -输出内容详细说明，如下： - -| 列名 | 描述 | -|:------|:---- | -| start | SQL 语句执行开始时间 | -| duration | SQL 语句执行持续时间 | -| details | 执行语句的详细信息 | -| succ | SQL 语句执行是否成功，1: 成功，0: 失败 | -| conn_id | session 连接 ID | -| transcation_ts | 事务提交的 commit ts | -| user | 执行该语句的用户名 | -| db | 执行该 SQL 涉及到 database | -| table_ids | 执行该 SQL 涉及到表的 ID | -| index_ids | 执行该 SQL 涉及到索引 ID | -| internal | 表示为 TiDB 内部的 SQL 语句 | -| digest | 表示 SQL 语句的指纹 | -| sql | 执行的 SQL 语句 | diff --git a/dev/how-to/migrate/from-mysql-aurora.md b/dev/how-to/migrate/from-mysql-aurora.md deleted file mode 100644 index cb321c508b87..000000000000 --- a/dev/how-to/migrate/from-mysql-aurora.md +++ /dev/null @@ -1,208 +0,0 @@ ---- -title: 从 MySQL 迁移数据 —— 以 Amazon Aurora MySQL 为例 -summary: 使用 DM 从 MySQL/Amazon Aurora MySQL 迁移数据。 -category: how-to -aliases: ['/docs-cn/dev/how-to/migrate/from-aurora/'] ---- - -# 从 MySQL 迁移数据 —— 以 Amazon Aurora MySQL 为例 - -本文以 [Amazon Aurora MySQL](https://aws.amazon.com/cn/rds/aurora/details/mysql-details/) 为例介绍如何使用 DM 从 MySQL 协议数据库迁移数据到 TiDB。 - -## 第 1 步：在 Aurora 集群中启用 binlog - -假设有两个 Aurora 集群需要迁移数据到 TiDB，其集群信息如下，其中 Aurora-1 包含一个独立的读取器节点。 - -| 集群 | 终端节点 | 端口 | 角色 | -|:-------- |:--- | :--- | :--- | -| Aurora-1 | pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com | 3306 | 写入器 | -| Aurora-1 | pingcap-1-us-east-2a.h8emfqdptyc4.us-east-2.rds.amazonaws.com | 3306 | 读取器 | -| Aurora-2 | pingcap-2.h8emfqdptyc4.us-east-2.rds.amazonaws.com | 3306 | 写入器 | - -DM 在增量同步阶段依赖 `ROW` 格式的 binlog，如果未启用 binlog 及设置正确的 binlog 格式，则不能正常使用 DM 进行数据同步，具体可参见[检查内容](/dev/reference/tools/data-migration/precheck.md#检查内容)。 - -> **注意：** -> -> Aurora 读取器不能开启 binlog，因此不能作为 DM 数据迁移时的上游 master server。 - -如果需要基于 GTID 进行数据迁移，还需要为 Aurora 集群启用 GTID 支持。 - -> **注意：** -> -> 基于 GTID 的数据迁移需要 MySQL 5.7 (Aurora 2.04.1) 或更高版本。 - -### 为 Aurora 集群修改 binlog 相关参数 - -在 Aurora 集群中，binlog 相关参数是**集群参数组中的集群级参数**，有关如何为 Aurora 集群启用 binlog 支持，请参考[在复制主实例上启用二进制日志记录](https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html#AuroraMySQL.Replication.MySQL.EnableBinlog)。在使用 DM 进行数据迁移时，需要将 `binlog_format` 参数设置为 `ROW`。 - -如果需要基于 GTID 进行数据迁移，需要将 `gtid-mode` 与 `enforce_gtid_consistency` 均设置为 `ON`。有关如何为 Aurora 集群启用基于 GTID 的数据迁移支持，请参考 [Configuring GTID-Based Replication for an Aurora MySQL Cluster](https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/mysql-replication-gtid.html#mysql-replication-gtid.configuring-aurora)。 - -> **注意：** -> -> 在 Aurora 管理后台中，`gtid_mode` 参数表示为 `gtid-mode`。 - -## 第 2 步：部署 DM 集群 - -目前推荐使用 DM-Ansible 部署 DM 集群，具体部署方法参照[使用 DM-Ansible 部署 DM 集群](/dev/how-to/deploy/data-migration-with-ansible.md)。 - -> **注意：** -> -> - 在 DM 所有的配置文件中，数据库的密码要使用 dmctl 加密后的密文。如果数据库密码为空，则不需要加密。关于如何使用 dmctl 加密明文密码，参考[使用 dmctl 加密上游 MySQL 用户密码](/dev/how-to/deploy/data-migration-with-ansible.md#使用-dmctl-加密上游-mysql-用户密码)。 -> - 上下游数据库用户必须拥有相应的读写权限。 - -## 第 3 步：检查集群信息 - -使用 DM-Ansible 部署 DM 集群后，相关配置信息如下： - -- DM 集群相关组件配置信息 - - | 组件 | 主机 | 端口 | - |:------|:---- |:---- | - | dm_worker1 | 172.16.10.72 | 8262 | - | dm_worker2 | 172.16.10.73 | 8262 | - | dm_master | 172.16.10.71 | 8261 | - -- 上下游数据库实例相关信息 - - | 数据库实例 | 主机 | 端口 | 用户名 | 加密密码 | - |:-------- |:--- | :--- | :--- | :--- | - | 上游 Aurora-1 | pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com | 3306 | root | VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU= | - | 上游 Aurora-2 | pingcap-2.h8emfqdptyc4.us-east-2.rds.amazonaws.com | 3306 | root | VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU= | - | 下游 TiDB | 172.16.10.83 | 4000 | root | | - -- dm-master 进程配置文件 `{ansible deploy}/conf/dm-master.toml` 中的配置 - - ```toml - # Master 配置。 - - [[deploy]] - source-id = "mysql-replica-01" - dm-worker = "172.16.10.72:8262" - - [[deploy]] - source-id = "mysql-replica-02" - dm-worker = "172.16.10.73:8262" - ``` - -## 第 4 步：配置任务 - -假设需要将 Aurora-1 和 Aurora-2 实例的 `test_db` 库的 `test_table` 表以**全量+增量**的模式同步到下游 TiDB 的 `test_db` 库的 `test_table` 表。 - -复制并编辑 `{ansible deploy}/conf/task.yaml.example`，生成如下任务配置文件 `task.yaml`： - -```yaml -# 任务名，多个同时运行的任务不能重名。 -name: "test" -# 全量+增量 (all) 同步模式。 -task-mode: "all" -# 下游 TiDB 配置信息。 -target-database: - host: "172.16.10.83" - port: 4000 - user: "root" - password: "" - -# 当前数据同步任务需要的全部上游 MySQL 实例配置。 -mysql-instances: -- - # 上游实例或者复制组 ID，参考 `inventory.ini` 的 `source_id` 或者 `dm-master.toml` 的 `source-id 配置`。 - source-id: "mysql-replica-01" - # 需要同步的库名或表名的黑白名单的配置项名称，用于引用全局的黑白名单配置，全局配置见下面的 `black-white-list` 的配置。 - black-white-list: "global" - # Mydumper 的配置项名称，用于引用全局的 Mydumper 配置。 - mydumper-config-name: "global" - -- - source-id: "mysql-replica-02" - black-white-list: "global" - mydumper-config-name: "global" - -# 黑白名单全局配置，各实例通过配置项名引用。 -black-white-list: - global: - do-tables: # 需要同步的上游表的白名单。 - - db-name: "test_db" # 需要同步的表的库名。 - tbl-name: "test_table" # 需要同步的表的名称。 - -# Mydumper 全局配置，各实例通过配置项名引用。 -mydumpers: - global: - extra-args: "-B test_db -T test_table" # mydumper 的其他参数，从 DM 1.0.2 版本开始，DM 会自动生成 table-list 配置，在其之前的版本仍然需要人工配置。 -``` - -## 第 5 步：启动任务 - -1. 进入 dmctl 目录 `/home/tidb/dm-ansible/resources/bin/` - -2. 执行以下命令启动 dmctl - - {{< copyable "shell-regular" >}} - - ```bash - ./dmctl --master-addr 172.16.10.71:8261 - ``` - -3. 执行以下命令启动数据同步任务（`task.yaml` 是之前编辑的配置文件） - - {{< copyable "shell-regular" >}} - - ```bash - start-task ./task.yaml - ``` - - - 如果执行命令后的返回结果中不包含错误信息，则表明任务已经成功启动 - - 如果包含以下错误信息，则表明上游 Aurora 用户可能拥有 TiDB 不支持的权限类型 - - ```json - { - "id": 4, - "name": "source db dump privilege chcker", - "desc": "check dump privileges of source DB", - "state": "fail", - "errorMsg": "line 1 column 285 near \"LOAD FROM S3, SELECT INTO S3 ON *.* TO 'root'@'%' WITH GRANT OPTION\" ...", - "instruction": "", - "extra": "address of db instance - pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com" - }, - { - "id": 5, - "name": "source db replication privilege chcker", - "desc": "check replication privileges of source DB", - "state": "fail", - "errorMsg": "line 1 column 285 near \"LOAD FROM S3, SELECT INTO S3 ON *.* TO 'root'@'%' WITH GRANT OPTION\" ...", - "instruction": "", - "extra": "address of db instance - pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com" - } - ``` - - 此时可以选择以下两种处理方法中的任意一种进行处理后，再使用 `start-task` 尝试重新启动任务： - - 1. 为用于进行数据迁移的 Aurora 用户移除不被 TiDB 支持的不必要的权限 - 2. 如果能确保 Aurora 用户拥有 DM 所需要的权限，可以在 `task.yaml` 配置文件中添加如下顶级配置项以跳过启用任务时的前置权限检查 - - ```yaml - ignore-checking-items: ["dump_privilege", "replication_privilege"] - ``` - -## 第 6 步：查询任务 - -如需了解 DM 集群中是否存在正在运行的同步任务及任务状态等信息，可在 dmctl 内使用以下命令进行查询： - -{{< copyable "shell-regular" >}} - -```bash -query-status -``` - -> **注意：** -> -> 如果查询命令的返回结果中包含以下错误信息，则表明在全量同步的 dump 阶段不能获得相应的 lock： -> -> ``` -> Couldn't acquire global lock, snapshots will not be consistent: Access denied for user 'root'@'%' (using password: YES) -> ``` -> -> 此时如果能接受不使用 FTWL 来确保 dump 文件与 metadata 的一致或上游能暂时停止写入，可以通过为 `mydumpers` 下的 `extra-args` 添加 `--no-locks` 参数来进行绕过，具体方法为： -> -> 1. 使用 `stop-task` 停止当前由于不能正常 dump 而已经转为 paused 的任务 -> 2. 将原 `task.yaml` 中的 `extra-args: "-B test_db -T test_table"` 更新为 `extra-args: "-B test_db -T test_table --no-locks"` -> 3. 使用 `start-task` 重新启动任务 diff --git a/dev/how-to/monitor/monitor-a-cluster.md b/dev/how-to/monitor/monitor-a-cluster.md deleted file mode 100644 index afafe8423dee..000000000000 --- a/dev/how-to/monitor/monitor-a-cluster.md +++ /dev/null @@ -1,355 +0,0 @@ ---- -title: TiDB 集群监控 -category: how-to ---- - -# TiDB 集群监控 - -TiDB 提供了以下两种接口来监控集群状态： - -- [状态接口](#使用状态接口)：通过 HTTP 接口对外汇报组件的信息。 -- [Metrics 接口](#使用-metrics-接口)：使用 Prometheus 记录组件中各种操作的详细信息，使用 Grafana 进行可视化展示。 - -## 使用状态接口 - -状态接口用于监控组件的一些基本信息，并且可以作为 keepalive 的监测接口。另外，通过 PD 的状态接口可以看到整个 TiKV 集群的详细信息。 - -### TiDB Server - -- TiDB API 地址：`http://${host}:${port}` -- 默认端口：10080 -- 各类 `api_name` 详细信息：参见 [TiDB API 文档](https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md) - -以下示例中，通过访问 `http://${host}:${port}/status` 获取当前 TiDB Server 的状态，并判断该 TiDB Server 是否存活。结果以 **JSON** 格式返回： - -{{< copyable "shell-regular" >}} - -```bash -curl http://127.0.0.1:10080/status -``` - -``` -{ - connections: 0, # 当前 TiDB Server 上的客户端连接数 - version: "5.7.25-TiDB-v3.0.0-beta-250-g778c3f4a5", # TiDB 版本号 - git_hash: "778c3f4a5a716880bcd1d71b257c8165685f0d70" # TiDB 当前代码的 Git Hash -} -``` - -### PD Server - -- PD API 地址：`http://${host}:${port}/pd/api/v1/${api_name}` -- 默认端口：2379 -- 各类 `api_name` 详细信息：参见 [PD API Doc](https://download.pingcap.com/pd-api-doc.html) - -通过该接口可以获取当前所有 TiKV 节点的状态以及负载均衡信息。下面以一个单节点的 TiKV 集群为例，说明用户需要了解的信息： - -{{< copyable "shell-regular" >}} - -```bash -curl http://127.0.0.1:2379/pd/api/v1/stores -``` - -``` -{ - "count": 1, # TiKV 节点数量 - "stores": [ # TiKV 节点的列表 - # 集群中单个 TiKV 节点的信息 - { - "store": { - "id": 1, - "address": "127.0.0.1:20160", - "version": "3.0.0-beta", - "state_name": "Up" - }, - "status": { - "capacity": "20 GiB", # 存储总容量 - "available": "16 GiB", # 存储剩余容量 - "leader_count": 17, - "leader_weight": 1, - "leader_score": 17, - "leader_size": 17, - "region_count": 17, - "region_weight": 1, - "region_score": 17, - "region_size": 17, - "start_ts": "2019-03-21T14:09:32+08:00", # 启动时间 - "last_heartbeat_ts": "2019-03-21T14:14:22.961171958+08:00", # 最后一次心跳的时间 - "uptime": "4m50.961171958s" - } - } - ] -``` - -## 使用 metrics 接口 - -Metrics 接口用于监控整个集群的状态和性能。 - -- 如果使用 TiDB Ansible 部署 TiDB 集群，监控系统（Prometheus 和 Grafana）会同时部署。 -- 如果使用其他方式部署 TiDB 集群，在使用 metrics 接口前，需先[部署 Prometheus 和 Grafana](#部署-prometheus-和-grafana)。 - -成功部署 Prometheus 和 Grafana 之后，[配置 Grafana](#配置-grafana)。 - -### 部署 Prometheus 和 Grafana - -假设 TiDB 的拓扑结构如下： - -| 节点 | 主机 IP | 服务 | -| :-- | :-- | :-------------- | -| Node1 | 192.168.199.113| PD1, TiDB, node_export, Prometheus, Grafana | -| Node2 | 192.168.199.114| PD2, node_export | -| Node3 | 192.168.199.115| PD3, node_export | -| Node4 | 192.168.199.116| TiKV1, node_export | -| Node5 | 192.168.199.117| TiKV2, node_export | -| Node6 | 192.168.199.118| TiKV3, node_export | - -#### 第 1 步：下载二进制包 - -下载二进制包： - -{{< copyable "shell-regular" >}} - -```bash -wget https://github.com/prometheus/prometheus/releases/download/v2.2.1/prometheus-2.2.1.linux-amd64.tar.gz && -wget https://github.com/prometheus/node_exporter/releases/download/v0.15.2/node_exporter-0.15.2.linux-amd64.tar.gz && -wget https://s3-us-west-2.amazonaws.com/grafana-releases/release/grafana-4.6.3.linux-x64.tar.gz -``` - -解压二进制包： - -{{< copyable "shell-regular" >}} - -```bash -tar -xzf prometheus-2.2.1.linux-amd64.tar.gz && -tar -xzf node_exporter-0.15.2.linux-amd64.tar.gz && -tar -xzf grafana-4.6.3.linux-x64.tar.gz -``` - -#### 第 2 步：在 Node1，Node2，Node3，Node4 上启动 `node_exporter` - -{{< copyable "shell-regular" >}} - -```bash -cd node_exporter-0.15.2.linux-amd64 -``` - -启动 node_exporter 服务： - -{{< copyable "shell-regular" >}} - -```bash -./node_exporter --web.listen-address=":9100" \ - --log.level="info" & -``` - -#### 第 3 步：在 Node1 上启动 Prometheus - -编辑 Prometheus 的配置文件： - -{{< copyable "shell-regular" >}} - -```bash -cd prometheus-2.2.1.linux-amd64 && -vi prometheus.yml -``` - -```ini -... - -global: - scrape_interval: 15s - evaluation_interval: 15s - # scrape_timeout 设置为全局默认值 (10s) - external_labels: - cluster: 'test-cluster' - monitor: "prometheus" - -scrape_configs: - - job_name: 'overwritten-nodes' - honor_labels: true # 不要覆盖 job 和实例的 label - static_configs: - - targets: - - '192.168.199.113:9100' - - '192.168.199.114:9100' - - '192.168.199.115:9100' - - '192.168.199.116:9100' - - '192.168.199.117:9100' - - '192.168.199.118:9100' - - - job_name: 'tidb' - honor_labels: true # 不要覆盖 job 和实例的 label - static_configs: - - targets: - - '192.168.199.113:10080' - - - job_name: 'pd' - honor_labels: true # 不要覆盖 job 和实例的 label - static_configs: - - targets: - - '192.168.199.113:2379' - - '192.168.199.114:2379' - - '192.168.199.115:2379' - - - job_name: 'tikv' - honor_labels: true # 不要覆盖 job 和实例的 label - static_configs: - - targets: - - '192.168.199.116:20180' - - '192.168.199.117:20180' - - '192.168.199.118:20180' - -... -``` - -启动 Prometheus 服务： - -{{< copyable "shell-regular" >}} - -```bash -./prometheus \ - --config.file="./prometheus.yml" \ - --web.listen-address=":9090" \ - --web.external-url="http://192.168.199.113:9090/" \ - --web.enable-admin-api \ - --log.level="info" \ - --storage.tsdb.path="./data.metrics" \ - --storage.tsdb.retention="15d" & -``` - -#### 第 4 步：在 Node1 上启动 Grafana - -编辑 Grafana 的配置文件： - -```bash -cd grafana-4.6.3 && -vi conf/grafana.ini -``` - -```ini -... - -[paths] -data = ./data -logs = ./data/log -plugins = ./data/plugins -[server] -http_port = 3000 -domain = 192.168.199.113 -[database] -[session] -[analytics] -check_for_updates = true -[security] -admin_user = admin -admin_password = admin -[snapshots] -[users] -[auth.anonymous] -[auth.basic] -[auth.ldap] -[smtp] -[emails] -[log] -mode = file -[log.console] -[log.file] -level = info -format = text -[log.syslog] -[event_publisher] -[dashboards.json] -enabled = false -path = ./data/dashboards -[metrics] -[grafana_net] -url = https://grafana.net - -... - -``` - -启动 Grafana 服务： - -{{< copyable "shell-regular" >}} - -```bash -./bin/grafana-server \ - --config="./conf/grafana.ini" & -``` - -### 配置 Grafana - -本小节介绍如何配置 Grafana。 - -#### 第 1 步：添加 Prometheus 数据源 - -1. 登录 Grafana 界面。 - - - 默认地址：`http://localhost:3000` - - 默认账户：admin - - 默认密码：admin - -2. 点击 Grafana 图标打开侧边栏。 - -3. 在侧边栏菜单中，点击 **Data Source**。 - -4. 点击 **Add data source**。 - -5. 指定数据源的相关信息： - - - 在 **Name** 处，为数据源指定一个名称。 - - 在 **Type** 处，选择 **Prometheus**。 - - 在 **URL** 处，指定 Prometheus 的 IP 地址。 - - 根据需求指定其它字段。 - -6. 点击 **Add** 保存新的数据源。 - -#### 第 2 步：导入 Grafana 面板 - -执行以下步骤，为 PD Server、TiKV Server 和 TiDB Server 分别导入 Grafana 面板： - -1. 点击侧边栏的 Grafana 图标。 - -2. 在侧边栏菜单中，依次点击 **Dashboards** > **Import** 打开 **Import Dashboard** 窗口。 - -3. 点击 **Upload .json File** 上传对应的 JSON 文件（下载 [TiDB Grafana 配置文件](https://github.com/pingcap/tidb-ansible/tree/master/scripts))。 - - > **注意：** - > - > TiKV、PD 和 TiDB 面板对应的 JSON 文件分别为 `tikv_summary.json`，`tikv_details.json`，`tikv_trouble_shooting.json`，`pd.json`，`tidb.json`，`tidb_summary.json`。 - -4. 点击 **Load**。 - -5. 选择一个 Prometheus 数据源。 - -6. 点击 **Import**，Prometheus 面板即导入成功。 - -### 查看组件 metrics - -在顶部菜单中，点击 **New dashboard**，选择要查看的面板。 - -![view dashboard](/media/view-dashboard.png) - -可查看以下集群组件信息： - -+ **TiDB Server：** - + query 处理时间，可以看到延迟和吞吐 - + ddl 过程监控 - + TiKV client 相关的监控 - + PD client 相关的监控 - -+ **PD Server：** - + 命令执行的总次数 - + 某个命令执行失败的总次数 - + 某个命令执行成功的耗时统计 - + 某个命令执行失败的耗时统计 - + 某个命令执行完成并返回结果的耗时统计 - -+ **TiKV Server：** - + GC 监控 - + 执行 KV 命令的总次数 - + Scheduler 执行命令的耗时统计 - + Raft propose 命令的总次数 - + Raft 执行命令的耗时统计 - + Raft 执行命令失败的总次数 - + Raft 处理 ready 状态的总次数 diff --git a/dev/how-to/monitor/overview.md b/dev/how-to/monitor/overview.md deleted file mode 100644 index a23871517f14..000000000000 --- a/dev/how-to/monitor/overview.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: TiDB 监控框架概述 -category: how-to ---- - -# TiDB 监控框架概述 - -TiDB 使用开源时序数据库 [Prometheus](https://prometheus.io) 作为监控和性能指标信息存储方案，使用 [Grafana](https://grafana.com/grafana) 作为可视化组件进行展示。 - -## Prometheus 在 TiDB 中的应用 - -Prometheus 是一个拥有多维度数据模型的、灵活的查询语句的时序数据库。Prometheus 作为热门的开源项目，拥有活跃的社区及众多的成功案例。 - -Prometheus 提供了多个组件供用户使用。目前，TiDB 使用了以下组件： - -- Prometheus Server：用于收集和存储时间序列数据。 -- Client 代码库：用于定制程序中需要的 Metric。 -- Alertmanager：用于实现报警机制。 - -其结构如下图所示： - -![Prometheus in TiDB](/media/prometheus-in-tidb.png) - -## Grafana 在 TiDB 中的应用 - -Grafana 是一个开源的 metric 分析及可视化系统。TiDB 使用 Grafana 来展示 TiDB 的各项性能指标。如下图所示： - -![Grafana in TiDB](/media/grafana-screenshot.png) diff --git a/dev/how-to/scale/horizontally.md b/dev/how-to/scale/horizontally.md deleted file mode 100644 index cb4e9d38865a..000000000000 --- a/dev/how-to/scale/horizontally.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -title: TiDB 集群扩容缩容方案 -category: how-to ---- - -# TiDB 集群扩容缩容方案 - -TiDB 集群可以在不影响线上服务的情况下动态进行扩容和缩容。 - -> **注意：** -> -> 如果使用 Ansible 部署 TiDB 集群，请参考[使用 Ansible 扩容缩容](/dev/how-to/scale/with-ansible.md)。 - -下面分别介绍如何增加或者删除 PD，TiKV 以及 TiDB 的节点。 - -下面用到的 pd-ctl 文档可以参考 [pd-control](/dev/reference/tools/pd-control.md)。 - -## PD - -假设现在我们有三个 PD 服务，详细信息如下： - -|Name|ClientUrls|PeerUrls| -|----|----------|--------| -|pd1|`http://host1:2379`|`http://host1:2380`| -|pd2|`http://host2:2379`|`http://host2:2380`| -|pd3|`http://host3:2379`|`http://host3:2380`| - -我们可以通过 pd-ctl 来查看当前所有 PD 节点的信息： - -{{< copyable "shell-regular" >}} - -```bash -./pd-ctl -u http://host1:2379 -i ->> member -``` - -### 动态添加节点 - -我们可以使用 `join` 参数，将一个新的 PD 服务加入到现有的 PD 集群里面。 -如果我们需要添加 `pd4`，只需要在 `--join` 参数里面填入当前 PD 集群任意一个 PD 服务的 client url，比如： - -{{< copyable "shell-regular" >}} - -```bash -./bin/pd-server --name=pd4 \ - --client-urls="http://host4:2379" \ - --peer-urls="http://host4:2380" \ - --join="http://host1:2379" -``` - -### 动态删除节点 - -如果我们需要删除 `pd4`，可以通过 pd-ctl 来完成： - -{{< copyable "shell-regular" >}} - -```bash -./pd-ctl -u http://host1:2379 ->> member delete name pd4 -``` - -### 动态迁移节点 - -如果想把现有的 PD 节点迁移到新的机器上，我们可以先在新的机器上添加节点，然后把旧的机器上的节点删除掉。迁移过程中应该一个节点一个节点逐个迁移，每完成一个步骤可以先查看一下当前的所有节点信息来进行确认。 - -## TiKV - -我们可以通过 pd-ctl 来查看当前所有 TiKV 节点的信息： - -{{< copyable "shell-regular" >}} - -```bash -./pd-ctl -u http://host1:2379 ->> store -``` - -### 动态添加节点 - -动态添加一个新的 TiKV 服务非常容易，只需要在新的机器上启动一个 TiKV 服务，不需要其他特殊操作。 -新启动的 TiKV 服务会自动注册到现有集群的 PD 中，PD 会自动做负载均衡，逐步地把一部分数据迁移到新的TiKV 服务中，从而降低现有 TiKV 服务的压力。 - -### 动态删除节点 - -安全地删除（下线）一个 TiKV 服务需要先告诉 PD，这样 PD 可以先把这个 TiKV 服务上面的数据迁移到其他 TiKV 服务上，保证数据有足够的副本数。 - -假设我们需要删除 store id 为 1 的 TiKV 服务，可以通过 pd-ctl 来完成： - -{{< copyable "shell-regular" >}} - -```bash -./pd-ctl -u http://host1:2379 ->> store delete 1 -``` - -然后可以查看这个 TiKV 服务的状态： - -{{< copyable "shell-regular" >}} - -```bash -./pd-ctl -u http://host1:2379 ->> store 1 -``` - -``` -{ - "store": { - "id": 1, - "address": "127.0.0.1:21060", - "state": 1, - "state_name": "Offline" - }, - "status": { - ... - } -} -``` - -我们可以通过这个 store 的 state_name 来确定这个 store 的状态： - -- Up：这个 store 正常服务 -- Disconnected：当前没有检测到这个 store 的心跳，可能是故障或网络连接中断 -- Down：超过一小时（可通过 `max-down-time` 配置）没有收到 store 心跳，此时 PD 会为这个 store 上的数据添加副本 -- Offline：这个 store 正在将其中的 Region 转移到其他节点，此时这个 store 仍在服务中 -- Tombstone：这个 store 已经完成下线，此时 store 上已经没有数据，可以关闭实例 - -### 动态迁移节点 - -迁移 TiKV 服务也是通过先在新的机器上添加节点，然后把旧的机器上的节点下线来完成。迁移过程中可以先把新集群的机器全部添加到已有的集群中，然后再把旧的节点一个一个地下线。可以通过查看正在下线的节点的状态信息来确定这个节点是否已经完成下线，确认完成以后再下线下一个节点。 - -## TiDB - -TiDB 是一个无状态的服务，这也就意味着我们能直接添加和删除 TiDB。需要注意的是，如果我们在 TiDB 的服务的前面搭建了一个 proxy（譬如 HAProxy），则需要更新 proxy 的配置并重新载入。 diff --git a/dev/how-to/scale/with-ansible.md b/dev/how-to/scale/with-ansible.md deleted file mode 100644 index 5eb3eda0644f..000000000000 --- a/dev/how-to/scale/with-ansible.md +++ /dev/null @@ -1,527 +0,0 @@ ---- -title: 使用 TiDB Ansible 扩容缩容 TiDB 集群 -category: how-to ---- - -# 使用 TiDB Ansible 扩容缩容 TiDB 集群 - -TiDB 集群可以在不影响线上服务的情况下进行扩容和缩容。 - -> **注意：** -> -> 以下缩容示例中，被移除的节点没有混合部署其他服务；如果混合部署了其他服务，不能按如下操作。 - -假设拓扑结构如下所示： - -| Name | Host IP | Services | -| ---- | ------- | -------- | -| node1 | 172.16.10.1 | PD1 | -| node2 | 172.16.10.2 | PD2 | -| node3 | 172.16.10.3 | PD3, Monitor | -| node4 | 172.16.10.4 | TiDB1 | -| node5 | 172.16.10.5 | TiDB2 | -| node6 | 172.16.10.6 | TiKV1 | -| node7 | 172.16.10.7 | TiKV2 | -| node8 | 172.16.10.8 | TiKV3 | -| node9 | 172.16.10.9 | TiKV4 | - -## 扩容 TiDB/TiKV 节点 - -例如，如果要添加两个 TiDB 节点（node101、node102），IP 地址为 172.16.10.101、172.16.10.102，可以进行如下操作： - -1. 编辑 `inventory.ini` 文件，添加节点信息： - - ```ini - [tidb_servers] - 172.16.10.4 - 172.16.10.5 - 172.16.10.101 - 172.16.10.102 - - [pd_servers] - 172.16.10.1 - 172.16.10.2 - 172.16.10.3 - - [tikv_servers] - 172.16.10.6 - 172.16.10.7 - 172.16.10.8 - 172.16.10.9 - - [monitored_servers] - 172.16.10.1 - 172.16.10.2 - 172.16.10.3 - 172.16.10.4 - 172.16.10.5 - 172.16.10.6 - 172.16.10.7 - 172.16.10.8 - 172.16.10.9 - 172.16.10.101 - 172.16.10.102 - - [monitoring_servers] - 172.16.10.3 - - [grafana_servers] - 172.16.10.3 - ``` - - 现在拓扑结构如下所示： - - | Name | Host IP | Services | - | ---- | ------- | -------- | - | node1 | 172.16.10.1 | PD1 | - | node2 | 172.16.10.2 | PD2 | - | node3 | 172.16.10.3 | PD3, Monitor | - | node4 | 172.16.10.4 | TiDB1 | - | node5 | 172.16.10.5 | TiDB2 | - | **node101** | **172.16.10.101**|**TiDB3** | - | **node102** | **172.16.10.102**|**TiDB4** | - | node6 | 172.16.10.6 | TiKV1 | - | node7 | 172.16.10.7 | TiKV2 | - | node8 | 172.16.10.8 | TiKV3 | - | node9 | 172.16.10.9 | TiKV4 | - -2. 初始化新增节点： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook bootstrap.yml -l 172.16.10.101,172.16.10.102 - ``` - - > **注意：** - > - > 如果 `inventory.ini` 中为节点配置了别名，如 `node101 ansible_host=172.16.10.101`，执行 ansible-playbook 时 -l 请指定别名，以下步骤类似。例如：`ansible-playbook bootstrap.yml -l node101,node102` - -3. 部署新增节点： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook deploy.yml -l 172.16.10.101,172.16.10.102 - ``` - -4. 启动新节点服务： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook start.yml -l 172.16.10.101,172.16.10.102 - ``` - -5. 更新 Prometheus 配置并重启： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update_monitor.yml --tags=prometheus - ``` - -6. 打开浏览器访问监控平台：`http://172.16.10.3:3000`，监控整个集群和新增节点的状态。 - - 可使用同样的步骤添加 TiKV 节点。但如果要添加 PD 节点，则需手动更新一些配置文件。 - -## 扩容 PD 节点 - -例如，如果要添加一个 PD 节点（node103），IP 地址为 172.16.10.103，可以进行如下操作： - -1. 编辑 `inventory.ini` 文件，添加节点信息置于 `[pd_servers]` 主机组最后一行： - - ```ini - [tidb_servers] - 172.16.10.4 - 172.16.10.5 - - [pd_servers] - 172.16.10.1 - 172.16.10.2 - 172.16.10.3 - 172.16.10.103 - - [tikv_servers] - 172.16.10.6 - 172.16.10.7 - 172.16.10.8 - 172.16.10.9 - - [monitored_servers] - 172.16.10.4 - 172.16.10.5 - 172.16.10.1 - 172.16.10.2 - 172.16.10.3 - 172.16.10.103 - 172.16.10.6 - 172.16.10.7 - 172.16.10.8 - 172.16.10.9 - - [monitoring_servers] - 172.16.10.3 - - [grafana_servers] - 172.16.10.3 - ``` - - 现在拓扑结构如下所示： - - | Name | Host IP | Services | - | ---- | ------- | -------- | - | node1 | 172.16.10.1 | PD1 | - | node2 | 172.16.10.2 | PD2 | - | node3 | 172.16.10.3 | PD3, Monitor | - | **node103** | **172.16.10.103** | **PD4** | - | node4 | 172.16.10.4 | TiDB1 | - | node5 | 172.16.10.5 | TiDB2 | - | node6 | 172.16.10.6 | TiKV1 | - | node7 | 172.16.10.7 | TiKV2 | - | node8 | 172.16.10.8 | TiKV3 | - | node9 | 172.16.10.9 | TiKV4 | - -2. 初始化新增节点： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook bootstrap.yml -l 172.16.10.103 - ``` - -3. 部署新增节点： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook deploy.yml -l 172.16.10.103 - ``` - -4. 登录新增的 PD 节点，编辑启动脚本：`{deploy_dir}/scripts/run_pd.sh` - - 1. 移除 `--initial-cluster="xxxx" \` 配置，注意这里不能在行开头加注释符 #。 - - 2. 添加 `--join="http://172.16.10.1:2379" \`，IP 地址 （172.16.10.1） 可以是集群内现有 PD IP 地址中的任意一个。 - - 3. 在新增 PD 节点中手动启动 PD 服务： - - {{< copyable "shell-regular" >}} - - ```bash - {deploy_dir}/scripts/start_pd.sh - ``` - - > **注意：** - > - > 启动前，需要通过 [PD Control](/dev/reference/tools/pd-control.md) 工具确认当前 PD 节点的 `health` 状态均为 "true"，否则 PD 服务会启动失败，同时日志中报错 `["join meet error"] [error="etcdserver: unhealthy cluster"]`。 - - 4. 使用 `pd-ctl` 检查新节点是否添加成功： - - {{< copyable "shell-regular" >}} - - ```bash - /home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d member - ``` - -5. 滚动升级整个集群： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update.yml - ``` - -6. 启动监控服务： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook start.yml -l 172.16.10.103 - ``` - -7. 更新 Prometheus 配置并重启： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update_monitor.yml --tags=prometheus - ``` - -8. 打开浏览器访问监控平台：`http://172.16.10.3:3000`，监控整个集群和新增节点的状态。 - -## 缩容 TiDB 节点 - -例如，如果要移除一个 TiDB 节点（node5），IP 地址为 172.16.10.5，可以进行如下操作： - -1. 停止 node5 节点上的服务： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook stop.yml -l 172.16.10.5 - ``` - -2. 编辑 `inventory.ini` 文件，移除节点信息： - - ```ini - [tidb_servers] - 172.16.10.4 - #172.16.10.5 # 注释被移除节点 - - [pd_servers] - 172.16.10.1 - 172.16.10.2 - 172.16.10.3 - - [tikv_servers] - 172.16.10.6 - 172.16.10.7 - 172.16.10.8 - 172.16.10.9 - - [monitored_servers] - 172.16.10.4 - #172.16.10.5 # 注释被移除节点 - 172.16.10.1 - 172.16.10.2 - 172.16.10.3 - 172.16.10.6 - 172.16.10.7 - 172.16.10.8 - 172.16.10.9 - - [monitoring_servers] - 172.16.10.3 - - [grafana_servers] - 172.16.10.3 - ``` - - 现在拓扑结构如下所示： - - | Name | Host IP | Services | - | ---- | ------- | -------- | - | node1 | 172.16.10.1 | PD1 | - | node2 | 172.16.10.2 | PD2 | - | node3 | 172.16.10.3 | PD3, Monitor | - | node4 | 172.16.10.4 | TiDB1 | - | **node5** | **172.16.10.5** | **TiDB2 已删除** | - | node6 | 172.16.10.6 | TiKV1 | - | node7 | 172.16.10.7 | TiKV2 | - | node8 | 172.16.10.8 | TiKV3 | - | node9 | 172.16.10.9 | TiKV4 | - -3. 更新 Prometheus 配置并重启： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update_monitor.yml --tags=prometheus - ``` - -4. 打开浏览器访问监控平台：`http://172.16.10.3:3000`，监控整个集群的状态。 - -## 缩容 TiKV 节点 - -例如，如果要移除一个 TiKV 节点（node9），IP 地址为 172.16.10.9，可以进行如下操作： - -1. 使用 `pd-ctl` 从集群中移除节点： - - 1. 查看 node9 节点的 store id： - - {{< copyable "shell-regular" >}} - - ```bash - /home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d store - ``` - - 2. 从集群中移除 node9，假如 store id 为 10： - - {{< copyable "shell-regular" >}} - - ```bash - /home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d store delete 10 - ``` - -2. 使用 Grafana 或者 `pd-ctl` 检查节点是否下线成功（下线需要一定时间，下线节点的状态变为 Tombstone 就说明下线成功了）： - - {{< copyable "shell-regular" >}} - - ```bash - /home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d store 10 - ``` - -3. 下线成功后，停止 node9 上的服务： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook stop.yml -l 172.16.10.9 - ``` - -4. 编辑 `inventory.ini` 文件，移除节点信息： - - ```ini - [tidb_servers] - 172.16.10.4 - 172.16.10.5 - - [pd_servers] - 172.16.10.1 - 172.16.10.2 - 172.16.10.3 - - [tikv_servers] - 172.16.10.6 - 172.16.10.7 - 172.16.10.8 - #172.16.10.9 # 注释被移除节点 - - [monitored_servers] - 172.16.10.4 - 172.16.10.5 - 172.16.10.1 - 172.16.10.2 - 172.16.10.3 - 172.16.10.6 - 172.16.10.7 - 172.16.10.8 - #172.16.10.9 # 注释被移除节点 - - [monitoring_servers] - 172.16.10.3 - - [grafana_servers] - 172.16.10.3 - ``` - - 现在拓扑结构如下所示： - - | Name | Host IP | Services | - | ---- | ------- | -------- | - | node1 | 172.16.10.1 | PD1 | - | node2 | 172.16.10.2 | PD2 | - | node3 | 172.16.10.3 | PD3, Monitor | - | node4 | 172.16.10.4 | TiDB1 | - | node5 | 172.16.10.5 | TiDB2 | - | node6 | 172.16.10.6 | TiKV1 | - | node7 | 172.16.10.7 | TiKV2 | - | node8 | 172.16.10.8 | TiKV3 | - | **node9** | **172.16.10.9** | **TiKV4 已删除** | - -5. 更新 Prometheus 配置并重启： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update_monitor.yml --tags=prometheus - ``` - -6. 打开浏览器访问监控平台：`http://172.16.10.3:3000`，监控整个集群的状态。 - -## 缩容 PD 节点 - -例如，如果要移除一个 PD 节点（node2），IP 地址为 172.16.10.2，可以进行如下操作： - -1. 使用 `pd-ctl` 从集群中移除节点： - - 1. 查看 node2 节点的 name： - - {{< copyable "shell-regular" >}} - - ```bash - /home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d member - ``` - - 2. 从集群中移除 node2，假如 name 为 pd2： - - {{< copyable "shell-regular" >}} - - ```bash - /home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d member delete name pd2 - ``` - -2. 使用 `pd-ctl` 检查节点是否下线成功（PD 下线会很快，结果中没有 node2 节点信息即为下线成功）： - - {{< copyable "shell-regular" >}} - - ```bash - /home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d member - ``` - -3. 下线成功后，停止 node2 上的服务： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook stop.yml -l 172.16.10.2 - ``` - -4. 编辑 `inventory.ini` 文件，移除节点信息： - - ```ini - [tidb_servers] - 172.16.10.4 - 172.16.10.5 - - [pd_servers] - 172.16.10.1 - #172.16.10.2 # 注释被移除节点 - 172.16.10.3 - - [tikv_servers] - 172.16.10.6 - 172.16.10.7 - 172.16.10.8 - 172.16.10.9 - - [monitored_servers] - 172.16.10.4 - 172.16.10.5 - 172.16.10.1 - #172.16.10.2 # 注释被移除节点 - 172.16.10.3 - 172.16.10.6 - 172.16.10.7 - 172.16.10.8 - 172.16.10.9 - - [monitoring_servers] - 172.16.10.3 - - [grafana_servers] - 172.16.10.3 - ``` - - 现在拓扑结构如下所示： - - | Name | Host IP | Services | - | ---- | ------- | -------- | - | node1 | 172.16.10.1 | PD1 | - | **node2** | **172.16.10.2** | **PD2 已删除** | - | node3 | 172.16.10.3 | PD3, Monitor | - | node4 | 172.16.10.4 | TiDB1 | - | node5 | 172.16.10.5 | TiDB2 | - | node6 | 172.16.10.6 | TiKV1 | - | node7 | 172.16.10.7 | TiKV2 | - | node8 | 172.16.10.8 | TiKV3 | - | node9 | 172.16.10.9 | TiKV4 | - -5. 滚动升级整个集群： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update.yml - ``` - -6. 更新 Prometheus 配置并重启： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update_monitor.yml --tags=prometheus - ``` - -7. 打开浏览器访问监控平台：`http://172.16.10.3:3000`，监控整个集群的状态。 diff --git a/dev/how-to/secure/enable-tls-between-components.md b/dev/how-to/secure/enable-tls-between-components.md deleted file mode 100644 index 0aca650377c2..000000000000 --- a/dev/how-to/secure/enable-tls-between-components.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -title: 为 TiDB 组件间开启 TLS 和数据加密存储 -category: how-to ---- - -# 为 TiDB 组件间开启 TLS 和数据加密存储 - -本文档介绍 TiDB 集群如何开启 TLS 验证和数据加密存储。 - -## 开启 TLS 验证 - -本部分介绍 TiDB 集群如何开启 TLS 验证，TLS 验证支持： - -- TiDB 组件之间的双向验证，包括 TiDB、TiKV、PD 相互之间，TiKV Control 与 TiKV、PD Control 与 PD 的双向认证，以及 TiKV peer 之间、PD peer 之间。一旦开启，所有组件之间均使用验证，不支持只开启某一部分的验证。 -- MySQL Client 与 TiDB 之间的客户端对服务器身份的单向验证以及双向验证。 - -MySQL Client 与 TiDB 之间使用一套证书，TiDB 集群组件之间使用另外一套证书。 - -### TiDB 集群组件间开启 TLS（双向认证） - -1. 准备证书。 - - 推荐为 TiDB、TiKV、PD 分别准备一个 server 证书，并保证可以相互验证，而它们的各种客户端共用 client 证书。 - - 有多种工具可以生成自签名证书，如 `openssl`，`easy-rsa`，`cfssl`。 - - 这里提供一个使用 `cfssl` 生成证书的示例：[生成自签名证书](/dev/how-to/secure/generate-self-signed-certificates.md)。 - -2. 配置证书。 - - - TiDB - - 在 `config` 文件或命令行参数中设置： - - ```toml - [security] - # Path of file that contains list of trusted SSL CAs for connection with cluster components. - cluster-ssl-ca = "/path/to/ca.pem" - # Path of file that contains X509 certificate in PEM format for connection with cluster components. - cluster-ssl-cert = "/path/to/tidb-server.pem" - # Path of file that contains X509 key in PEM format for connection with cluster components. - cluster-ssl-key = "/path/to/tidb-server-key.pem" - ``` - - - TiKV - - 在 `config` 文件或命令行参数中设置，并设置相应的 URL 为 https： - - ```toml - [security] - # set the path for certificates. Empty string means disabling secure connectoins. - ca-path = "/path/to/ca.pem" - cert-path = "/path/to/tikv-server.pem" - key-path = "/path/to/tikv-server-key.pem" - ``` - - - PD - - 在 `config` 文件或命令行参数中设置，并设置相应的 URL 为 https： - - ```toml - [security] - # Path of file that contains list of trusted SSL CAs. if set, following four settings shouldn't be empty - cacert-path = "/path/to/ca.pem" - # Path of file that contains X509 certificate in PEM format. - cert-path = "/path/to/pd-server.pem" - # Path of file that contains X509 key in PEM format. - key-path = "/path/to/pd-server-key.pem" - ``` - - 此时 TiDB 集群各个组件间已开启双向验证。 - - > **注意：** - > - > 若 TiDB 集群各个组件间已开启 TLS，在使用 tikv-ctl 或 pd-ctl 工具连接集群时，需要指定 client 证书，示例： - - {{< copyable "shell-regular" >}} - - ```bash - ./pd-ctl -u https://127.0.0.1:2379 --cacert /path/to/ca.pem --cert /path/to/client.pem --key /path/to/client-key.pem - ``` - - {{< copyable "shell-regular" >}} - - ```bash - ./tikv-ctl --host="127.0.0.1:20160" --ca-path="/path/to/ca.pem" --cert-path="/path/to/client.pem" --key-path="/path/to/clinet-key.pem" - ``` - -### MySQL 与 TiDB 间开启 TLS - -请参考 [使用加密连接](/dev/how-to/secure/enable-tls-clients.md)。 - -## 开启数据加密存储 - -在 TiDB 集群中，用户的数据都存储在 TiKV 中，配置了 TiKV 数据加密存储功能，就代表 TiDB 集群已经加密存储了用户的数据。本部分主要介绍如何配置 TiKV 的加密存储功能。 - -### 操作流程 - -1. 生成 token 文件。 - - token 文件存储的是密钥，用于对用户数据进行加密，以及对已加密的数据进行解密。 - - {{< copyable "shell-regular" >}} - - ```bash - ./tikv-ctl random-hex --len 256 > cipher-file-256 - ``` - - > **注意：** - > - > TiKV 只接受 hex 格式的 token 文件，文件的长度必须是 2^n，并且小于等于 1024。 - -2. 配置 TiKV。 - - ```toml - [security] - # Cipher file 的存储路径 - cipher-file = "/path/to/cipher-file-256" - ``` - -> **注意：** -> -> 若使用 [Lightning](/dev/reference/tools/tidb-lightning/overview.md) 向集群导入数据，如果目标集群开启了加密功能，Lightning 生成的 sst 文件也必须是加密的格式。 - -### 使用限制 - -目前 TiKV 数据加密存储存在以下限制： - -- 对之前没有开启加密存储的集群，不支持开启该功能。 -- 已经开启加密功能的集群，不允许关闭加密存储功能。 -- 同一集群内部，不允许部分 TiKV 实例开启该功能，部分 TiKV 实例不开启该功能。对于加密存储功能，所有 TiKV 实例要么都开启该功能，要么都不开启该功能。这是由于 TiKV 实例之间会有数据迁移，如果开启了加密存储功能，迁移过程中数据也是加密的。 diff --git a/dev/how-to/secure/enable-tls-clients.md b/dev/how-to/secure/enable-tls-clients.md deleted file mode 100644 index 9f4486082d9b..000000000000 --- a/dev/how-to/secure/enable-tls-clients.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -title: 使用加密连接 -category: how-to ---- - -# 使用加密连接 - -TiDB 服务端默认采用非加密连接，因而具备监视信道流量能力的第三方可以知悉 TiDB 服务端与客户端之间发送和接受的数据，包括但不限于查询语句内容、查询结果等。若信道是不可信的，例如客户端是通过公网连接到 TiDB 服务端的，则非加密连接容易造成信息泄露，建议使用加密连接确保安全性。 - -TiDB 服务端支持启用基于 TLS（传输层安全）协议的加密连接，协议与 MySQL 加密连接一致，现有 MySQL 客户端如 MySQL 运维工具和 MySQL 驱动等能直接支持。TLS 的前身是 SSL，因而 TLS 有时也被称为 SSL，但由于 SSL 协议有已知安全漏洞，TiDB 实际上并未支持。TiDB 支持的 TLS/SSL 协议版本为 TLS 1.0、TLS 1.1、TLS 1.2。 - -使用加密连接后，连接将具有以下安全性质： - -- 保密性：流量明文无法被窃听； -- 完整性：流量明文无法被篡改； -- 身份验证（可选）：客户端和服务端能验证双方身份，避免中间人攻击。 - -TiDB 的加密连接支持默认是关闭的，必须在 TiDB 服务端通过配置开启加密连接的支持后，才能在客户端中使用加密连接。另外，与 MySQL 一致，TiDB 加密连接是以单个连接为单位的，并且是可选的，因而对于开启了加密连接支持的 TiDB 服务端，客户端既可以选择通过加密连接安全地连接到该 TiDB 服务端，也可以选择使用普通的非加密连接。大部分 MySQL 客户端默认不采用加密连接，因此一般还要显式地要求客户端使用加密连接。 - -简单来说，要使用加密连接必须同时满足以下两个条件： - -1. TiDB 服务端配置开启加密连接的支持 -2. 客户端指定使用加密连接 - -## 配置 TiDB 启用加密连接支持 - -在启动 TiDB 时，至少需要在配置文件中同时指定 `ssl-cert` 和 `ssl-key` 参数，才能使 TiDB 服务端接受加密连接。还可以指定 `ssl-ca` 参数进行客户端身份验证（请参见[配置启用身份验证](#配置启用身份验证)章节）。 - -- [`ssl-cert`](/dev/reference/configuration/tidb-server/configuration-file.md#ssl-cert)：指定 SSL 证书文件路径 -- [`ssl-key`](/dev/reference/configuration/tidb-server/configuration-file.md#ssl-key)：指定证书文件对应的私钥 -- [`ssl-ca`](/dev/reference/configuration/tidb-server/configuration-file.md#ssl-ca)：可选，指定受信任的 CA 证书文件路径 - -参数指定的文件都为 PEM 格式。另外目前 TiDB 尚不支持加载有密码保护的私钥，因此必须提供一个没有密码的私钥文件。若提供的证书或私钥无效，则 TiDB 服务端将照常启动，但并不支持客户端加密连接到 TiDB 服务端。 - -上述证书及密钥可以使用 OpenSSL 签发和生成，也可以使用 MySQL 自带的工具 `mysql_ssl_rsa_setup` 快捷生成： - -{{< copyable "shell-regular" >}} - -```bash -mysql_ssl_rsa_setup --datadir=./certs -``` - -以上命令将在 `certs` 目录下生成以下文件： - -``` -certs -├── ca-key.pem -├── ca.pem -├── client-cert.pem -├── client-key.pem -├── private_key.pem -├── public_key.pem -├── server-cert.pem -└── server-key.pem -``` - -对应的 TiDB 配置文件参数为： - -```toml -[security] -ssl-cert = "certs/server-cert.pem" -ssl-key = "certs/server-key.pem" -``` - -若证书参数无误，则 TiDB 在启动时将会输出 `Secure connection is enabled`，否则 TiDB 会输出 `Secure connection is NOT ENABLED`。 - -## 配置 MySQL 客户端使用加密连接 - -MySQL 5.7 及以上版本自带的客户端默认尝试使用安全连接，若服务端不支持安全连接则自动退回到使用非安全连接；MySQL 5.7 以下版本自带的客户端默认采用非安全连接。 - -可以通过命令行参数修改客户端的连接行为，包括： - -- 强制使用安全连接，若服务端不支持安全连接则连接失败 (`--ssl-mode=REQUIRED`) -- 尝试使用安全连接，若服务端不支持安全连接则退回使用不安全连接 -- 使用不安全连接 (`--ssl-mode=DISABLED`) - -详细信息请参阅 MySQL 文档中关于[客户端配置安全连接](https://dev.mysql.com/doc/refman/5.7/en/using-encrypted-connections.html#using-encrypted-connections-client-side-configuration)的部分。 - -## 配置启用身份验证 - -若在 TiDB 服务端或 MySQL 客户端中未指定 `ssl-ca` 参数，则默认不会进行客户端或服务端身份验证，无法抵御中间人攻击，例如客户端可能会“安全地”连接到了一个伪装的服务端。可以在服务端和客户端中配置 `ssl-ca` 参数进行身份验证。一般情况下只需验证服务端身份，但也可以验证客户端身份进一步增强安全性。 - -- 若要使 MySQL 客户端验证 TiDB 服务端身份，TiDB 服务端需至少配置 `ssl-cert` 和 `ssl-key` 参数，客户端需至少指定 `--ssl-ca` 参数，且 `--ssl-mode` 至少为 `VERIFY_CA`。必须确保 TiDB 服务端配置的证书（`ssl-cert`）是由客户端 `--ssl-ca` 参数所指定的 CA 所签发的，否则身份验证失败。 -- 若要使 TiDB 服务端验证 MySQL 客户端身份，TiDB 服务端需配置 `ssl-cert`、`ssl-key`、`ssl-ca` 参数，客户端需至少指定 `--ssl-cert`、`--ssl-key` 参数。必须确保服务端配置的证书和客户端配置的证书都是由服务端配置指定的 `ssl-ca` 签发的。 -- 若要进行双向身份验证，请同时满足上述要求。 - -> **注意：** -> -> 目前 TiDB 尚不支持强制验证客户端身份，即服务端对客户端的身份验证是可选的。若客户端在 TLS 握手时未出示自己的身份证书，也能正常建立 TLS 连接。 - -## 检查当前连接是否是加密连接 - -可以通过 `SHOW STATUS LIKE "%Ssl%";` 了解当前连接的详细情况，包括是否使用了安全连接、安全连接采用的加密协议、TLS 版本号等。 - -以下是一个安全连接中执行该语句的结果。由于客户端支持的 TLS 版本号和加密协议会有所不同，执行结果相应地也会有所变化。 - -{{< copyable "sql" >}} - -```sql -SHOW STATUS LIKE "%Ssl%"; -``` - -``` -...... -| Ssl_verify_mode | 5 | -| Ssl_version | TLSv1.2 | -| Ssl_cipher | ECDHE-RSA-AES128-GCM-SHA256 | -...... -``` - -除此以外，对于 MySQL 自带客户端，还可以使用 `STATUS` 或 `\s` 语句查看连接情况： - -{{< copyable "sql" >}} - -```sql -\s -``` - -``` -... -SSL: Cipher in use is ECDHE-RSA-AES128-GCM-SHA256 -... -``` - -## 支持的 TLS 版本及密钥交换协议和加密算法 - -TiDB 支持的 TLS 版本及密钥交换协议和加密算法由 Golang 官方库决定。 - -### 支持的 TLS 版本 - -- TLS 1.0 -- TLS 1.1 -- TLS 1.2 - -### 支持的密钥交换协议及加密算法 - -- TLS\_RSA\_WITH\_RC4\_128\_SHA -- TLS\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA -- TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA -- TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA -- TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256 -- TLS\_RSA\_WITH\_AES\_128\_GCM\_SHA256 -- TLS\_RSA\_WITH\_AES\_256\_GCM\_SHA384 -- TLS\_ECDHE\_ECDSA\_WITH\_RC4\_128\_SHA -- TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA -- TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA -- TLS\_ECDHE\_RSA\_WITH\_RC4\_128\_SHA -- TLS\_ECDHE\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA -- TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA -- TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA -- TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA256 -- TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA256 -- TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256 -- TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256 -- TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 -- TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384 -- TLS\_ECDHE\_RSA\_WITH\_CHACHA20\_POLY1305 -- TLS\_ECDHE\_ECDSA\_WITH\_CHACHA20\_POLY1305 diff --git a/dev/how-to/secure/generate-self-signed-certificates.md b/dev/how-to/secure/generate-self-signed-certificates.md deleted file mode 100644 index 4280b63d2d2f..000000000000 --- a/dev/how-to/secure/generate-self-signed-certificates.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -title: 生成自签名证书 -category: how-to ---- - -# 生成自签名证书 - -## 概述 - -本文档提供使用 `cfssl` 生成自签名证书的示例。 - -假设实例集群拓扑如下： - -| Name | Host IP | Services | -| ----- | ----------- | ---------- | -| node1 | 172.16.10.1 | PD1, TiDB1 | -| node2 | 172.16.10.2 | PD2, TiDB2 | -| node3 | 172.16.10.3 | PD3 | -| node4 | 172.16.10.4 | TiKV1 | -| node5 | 172.16.10.5 | TiKV2 | -| node6 | 172.16.10.6 | TiKV3 | - -## 下载 cfssl - -假设使用 x86_64 Linux 主机： - -{{< copyable "shell-regular" >}} - -```bash -mkdir ~/bin && -curl -s -L -o ~/bin/cfssl https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 && -curl -s -L -o ~/bin/cfssljson https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 && -chmod +x ~/bin/{cfssl,cfssljson} && -export PATH=$PATH:~/bin -``` - -## 初始化证书颁发机构 - -生成 cfssl 的默认配置，以便于之后修改： - -```bash -mkdir ~/cfssl && -cd ~/cfssl && -cfssl print-defaults config > ca-config.json && -cfssl print-defaults csr > ca-csr.json -``` - -## 生成证书 - -### 证书介绍 - -- tidb-server certificate 由 TiDB 使用，为其他组件和客户端验证 TiDB 身份。 -- tikv-server certificate 由 TiKV 使用，为其他组件和客户端验证 TiKV 身份。 -- pd-server certificate 由 PD 使用，为其他组件和客户端验证 PD 身份。 -- client certificate 用于通过 PD、TiKV、TiDB 验证客户端。例如 `pd-ctl`，`tikv-ctl`，`pd-recover`。 - -### 配置 CA 选项 - -根据实际需求修改 `ca-config.json`： - -```json -{ - "signing": { - "default": { - "expiry": "43800h" - }, - "profiles": { - "server": { - "expiry": "43800h", - "usages": [ - "signing", - "key encipherment", - "server auth", - "client auth" - ] - }, - "client": { - "expiry": "43800h", - "usages": [ - "signing", - "key encipherment", - "client auth" - ] - } - } - } -} -``` - -根据实际需求修改 `ca-csr.json` ： - -```json -{ - "CN": "My own CA", - "key": { - "algo": "rsa", - "size": 2048 - }, - "names": [ - { - "C": "CN", - "L": "Beijing", - "O": "PingCAP", - "ST": "Beijing" - } - ] -} -``` - -### 生成 CA 证书 - -{{< copyable "shell-regular" >}} - -```bash -cfssl gencert -initca ca-csr.json | cfssljson -bare ca - -``` - -将会生成以下几个文件： - -``` -ca-key.pem -ca.csr -ca.pem -``` - -### 生成服务器端证书 - -`hostname` 中为各组件的 IP 地址，以及 `127.0.0.1` - -{{< copyable "shell-regular" >}} - -```bash -echo '{"CN":"tidb-server","hosts":[""],"key":{"algo":"rsa","size":2048}}' | cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server -hostname="172.16.10.1,172.16.10.2,127.0.0.1" - | cfssljson -bare tidb-server && - -echo '{"CN":"tikv-server","hosts":[""],"key":{"algo":"rsa","size":2048}}' | cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server -hostname="172.16.10.4,172.16.10.5,172.16.10.6,127.0.0.1" - | cfssljson -bare tikv-server && - -echo '{"CN":"pd-server","hosts":[""],"key":{"algo":"rsa","size":2048}}' | cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server -hostname="172.16.10.1,172.16.10.2,172.16.10.3,127.0.0.1" - | cfssljson -bare pd-server -``` - -将会生成以下几个文件： - -``` -tidb-server-key.pem tikv-server-key.pem pd-server-key.pem -tidb-server.csr tikv-server.csr pd-server.csr -tidb-server.pem tikv-server.pem pd-server.pem -``` - -### 生成客户端证书 - -{{< copyable "shell-regular" >}} - -```bash -echo '{"CN":"client","hosts":[""],"key":{"algo":"rsa","size":2048}}' | cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client -hostname="" - | cfssljson -bare client -``` - -将会生成以下几个文件： - -``` -client-key.pem -client.csr -client.pem -``` diff --git a/dev/how-to/troubleshoot/cluster-setup.md b/dev/how-to/troubleshoot/cluster-setup.md deleted file mode 100644 index a480f8c62ca5..000000000000 --- a/dev/how-to/troubleshoot/cluster-setup.md +++ /dev/null @@ -1,149 +0,0 @@ ---- -title: TiDB 集群故障诊断 -category: how-to ---- - -# TiDB 集群故障诊断 - -当试用 TiDB 遇到问题时，请先参考本篇文档。如果问题未解决，请按文档要求收集必要的信息通过 Github [提供给 TiDB 开发者](https://github.com/pingcap/tidb/issues/new/choose)。 - -## 如何给 TiDB 开发者报告错误 - -当使用 TiDB 遇到问题并且通过后面所列信息无法解决时，请收集以下信息并[创建新 Issue](https://github.com/pingcap/tidb/issues/new/choose): - -+ 具体的出错信息以及正在执行的操作 -+ 当前所有组件的状态 -+ 出问题组件 log 中的 error/fatal/panic 信息 -+ 机器配置以及部署拓扑 -+ dmesg 中 TiDB 组件相关的问题 - -## 数据库连接不上 - -首先请确认集群的各项服务是否已经启动，包括 tidb-server、pd-server、tikv-server。请用 ps 命令查看所有进程是否在。如果某个组件的进程已经不在了，请参考对应的章节排查错误。 - -如果所有的进程都在，请查看 tidb-server 的日志，看是否有报错？常见的错误包括： - -+ InformationSchema is out of date - - 无法连接 tikv-server，请检查 pd-server 以及 tikv-server 的状态和日志。 - -+ panic - - 程序有错误，请将具体的 panic log [提供给 TiDB 开发者](https://github.com/pingcap/tidb/issues/new/choose)。 - - 如果是清空数据并重新部署服务，请确认以下信息： - -+ pd-server、tikv-server 数据都已清空 - - tikv-server 存储具体的数据，pd-server 存储 tikv-server 中数据的的元信息。如果只清空 pd-server 或只清空 tikv-server 的数据，会导致两边数据不匹配。 - -+ 清空 pd-server 和 tikv-server 的数据并重启后，也需要重启 tidb-server - - 集群 ID 是由 pd-server 在集群初始化时随机分配，所以重新部署集群后，集群 ID 会发生变化。tidb-server 业务需要重启以获取新的集群 ID。 - -## tidb-server 启动报错 - -tidb-server 无法启动的常见情况包括： - -+ 启动参数错误 - - 请参考 [TiDB 命令行参数](/dev/reference/configuration/tidb-server/configuration.md)。 - -+ 端口被占用：`lsof -i:port` - - 请确保 tidb-server 启动所需要的端口未被占用。 - -+ 无法连接 pd-server - - 首先检查 pd-server 的进程状态和日志，确保 pd-server 成功启动，对应端口已打开：`lsof -i:port`。 - - 若 pd-server 正常，则需要检查 tidb-server 机器和 pd-server 对应端口之间的连通性， - 确保网段连通且对应服务端口已添加到防火墙白名单中，可通过 nc 或 curl 工具检查。 - - 例如，假设 tidb 服务位于 `192.168.1.100`，无法连接的 pd 位于 `192.168.1.101`，且 2379 为其 client port， - 则可以在 tidb 机器上执行 `nc -v -z 192.168.1.101 2379`，测试是否可以访问端口。 - 或使用 `curl -v 192.168.1.101:2379/pd/api/v1/leader` 直接检查 pd 是否正常服务。 - -## tikv-server 启动报错 - -+ 启动参数错误 - - 请参考 [TiKV 启动参数](/dev/reference/configuration/tikv-server/configuration.md)文档。 - -+ 端口被占用：`lsof -i:port` - - 请确保 tikv-server 启动所需要的端口未被占用：`lsof -i:port`。 -+ 无法连接 pd-server - - 首先检查 pd-server 的进程状态和日志。确保 pd-server 成功启动，对应端口已打开：`lsof -i:port`。 - - 若 pd-server 正常，则需要检查 tikv-server 机器和 pd-server 对应端口之间的连通性， - 确保网段连通且对应服务端口已添加到防火墙白名单中，可通过 nc 或 curl 工具检查。具体命令参考上一节。 - -+ 文件被占用 - - 不要在一个数据库文件目录上打开两个 tikv。 - -## pd-server 启动报错 - -+ 启动参数错误 - - 请参考 [PD 命令行参数](/dev/reference/configuration/pd-server/configuration.md)文档。 - -+ 端口被占用：`lsof -i:port` - - 请确保 pd-server 启动所需要的端口未被占用：`lsof -i:port`。 - -## TiDB/TiKV/PD 进程异常退出 - -+ 进程是否是启动在前台 - - 当前终端退出给其所有子进程发送 HUP 信号，从而导致进程退出。 - -+ 是否是在命令行用过 `nohup+&` 方式直接运行 - - 这样依然可能导致进程因终端连接突然中断，作为终端 SHELL 的子进程被杀掉。 - - 推荐将启动命令写在脚本中，通过脚本运行（相当于二次 fork 启动）。 - -## TiKV 进程异常重启 - -+ 检查 dmesg 或者 syslog 里面是否有 OOM 信息 - - 如果有 OOM 信息并且杀掉的进程为 TiKV，请减少 TiKV 的 RocksDB 的各个 CF 的 `block-cache-size` 值。 - -+ 检查 TiKV 日志是否有 panic 的 log - - 提交 Issue 并附上 panic 的 log。 - -## TiDB panic - -请提供 panic 的 log。 - -## 连接被拒绝 - -+ 请确保操作系统的网络参数正确，包括但不限于 - - 连接字符串中的端口和 tidb-server 启动的端口需要一致 - - 请保证防火墙的配置正确 - -## Too many open files - -在启动进程之前，请确保 `ulimit -n` 的结果足够大，推荐设为 unlimited 或者是大于 1000000。 - -## 数据库访问超时，系统负载高 - -首先检查 [SLOW-QUERY](/dev/how-to/maintain/identify-abnormal-queries/identify-slow-queries.md) 日志，判断是否是因为某条 SQL 语句导致。如果未能解决，请提供如下信息： - -+ 部署的拓扑结构 - - tidb-server/pd-server/tikv-server 部署了几个实例 - - 这些实例在机器上是如何分布的 -+ 机器的硬件配置 - - CPU 核数 - - 内存大小 - - 硬盘类型（SSD 还是机械硬盘） - - 是实体机还是虚拟机 -+ 机器上除了 TiDB 集群之外是否还有其他服务 -+ pd-server 和 tikv-server 是否分开部署 -+ 目前正在进行什么操作 -+ 用 `top -H` 命令查看当前占用 CPU 的线程名 -+ 最近一段时间的网络/IO 监控数据是否有异常 diff --git a/dev/how-to/troubleshoot/tidb-lightning.md b/dev/how-to/troubleshoot/tidb-lightning.md deleted file mode 100644 index 0a7e274623b1..000000000000 --- a/dev/how-to/troubleshoot/tidb-lightning.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -title: TiDB Lightning 故障诊断 -category: reference ---- - -# TiDB Lightning 故障诊断 - -当 Lightning 遇到不可恢复的错误时便会异常退出，并在日志中记下错误原因。一般可在日志底部找到，也可以搜索 `[error]` 字符串找出中间发生的错误。本文主要描述一些常见的错误及其解决方法。 - -## 导入速度太慢 - -TiDB Lightning 的正常速度为每条线程每 2 分钟导入一个 256 MB 的数据文件，如果速度远慢于这个数值就是有问题。导入的速度可以检查日志提及 `restore chunk … takes` 的记录，或者观察 Grafana 的监控信息。 - -导入速度太慢一般有几个原因： - -**原因 1**：`region-concurrency` 设定太高，线程间争用资源反而减低了效率。 - -1. 从日志的开头搜寻 `region-concurrency` 能知道 Lightning 读到的参数是多少。 -2. 如果 Lightning 与其他服务（如 Importer）共用一台服务器，必需**手动**将 `region-concurrency` 设为该服务器 CPU 数量的 75%。 -3. 如果 CPU 设有限额（例如从 Kubernetes 指定的上限），Lightning 可能无法自动判断出来，此时亦需要**手动**调整 `region-concurrency`。 - -**原因 2**：表结构太复杂。 - -每条索引都会额外增加键值对。如果有 N 条索引，实际导入的大小就差不多是 Mydumper 文件的 N+1 倍。如果索引不太重要，可以考虑先从 schema 去掉，待导入完成后再使用 `CREATE INDEX` 加回去。 - -**原因 3**：Lightning 版本太旧。 - -试试最新的版本吧！可能会有改善。 - -## checksum failed: checksum mismatched remote vs local - -**原因**：本地数据源跟目标数据库某个表的校验和不一致。这通常有更深层的原因： - -1. 这张表可能本身已有数据，影响最终结果。 -2. 如果目标数据库的校验和全是 0，表示没有发生任何导入，有可能是集群太忙无法接收任何数据。 -3. 如果数据源是由机器生成而不是从 Mydumper 备份的，需确保数据符合表的限制，例如： - - * 自增 (AUTO_INCREMENT) 的列需要为正数，不能为 0。 - * 唯一键和主键 (UNIQUE and PRIMARY KEYs) 不能有重复的值。 -4. 如果 TiDB Lightning 之前失败停机过，但没有正确重启，可能会因为数据不同步而出现校验和不一致。 - -**解决办法**： - -1. 使用 `tidb-lightning-ctl` 把出错的表删除，然后重启 Lightning 重新导入那些表。 - - {{< copyable "shell-regular" >}} - - ```sh - tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy=all - ``` - -2. 把断点存放在外部数据库（修改 `[checkpoint] dsn`），减轻目标集群压力。 - -3. 参考[如何正确重启 TiDB Lightning](/dev/faq/tidb-lightning.md#如何正确重启-tidb-lightning)中的解决办法。 - -## Checkpoint for … has invalid status:（错误码） - -**原因**：[断点续传](/dev/reference/tools/tidb-lightning/checkpoints.md)已启用。Lightning 或 Importer 之前发生了异常退出。为了防止数据意外损坏，Lightning 在错误解决以前不会启动。 - -错误码是小于 25 的整数，可能的取值是 0、3、6、9、12、14、15、17、18、20、21。整数越大，表示异常退出所发生的步骤在导入流程中越晚。 - -**解决办法**： - -如果错误原因是非法数据源，使用 `tidb-lightning-ctl` 删除已导入数据，并重启 Lightning。 - -{{< copyable "shell-regular" >}} - -```sh -tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy=all -``` - -其他解决方法请参考[断点续传的控制](/dev/reference/tools/tidb-lightning/checkpoints.md#断点续传的控制)。 - -## ResourceTemporarilyUnavailable("Too many open engines …: …") - -**原因**：并行打开的引擎文件 (engine files) 超出 `tikv-importer` 里的限制。这可能由配置错误引起。即使配置没问题，如果 `tidb-lightning` 曾经异常退出，也有可能令引擎文件残留在打开的状态，占据可用的数量。 - -**解决办法**： - -1. 提高 `tikv-importer.toml` 内 `max-open-engines` 的值。这个设置主要由内存决定，计算公式为： - - 最大内存使用量 ≈ `max-open-engines` × `write-buffer-size` × `max-write-buffer-number` - -2. 降低 `table-concurrency` + `index-concurrency`，使之低于 `max-open-engines`。 - -3. 重启 `tikv-importer` 来强制移除所有引擎文件 (默认值为 `./data.import/`)。这样也会丢弃导入了一半的表，所以启动 Lightning 前必须清除过期的断点记录： - - {{< copyable "shell-regular" >}} - - ```sh - tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy=all - ``` - -## cannot guess encoding for input file, please convert to UTF-8 manually - -**原因**：Lightning 只支持 UTF-8 和 GB-18030 编码的表架构。此错误代表数据源不是这里任一个编码。也有可能是文件中混合了不同的编码，例如，因为在不同的环境运行过 `ALTER TABLE`，使表架构同时出现 UTF-8 和 GB-18030 的字符。 - -**解决办法**： - -1. 编辑数据源，保存为纯 UTF-8 或 GB-18030 的文件。 -2. 手动在目标数量库创建所有的表，然后设置 `[mydumper] no-schema = true` 跳过创建表的步骤。 -3. 设置 `[mydumper] character-set = "binary"` 跳过这个检查。但是这样可能使数据库出现乱码。 - -## [sql2kv] sql encode error = [types:1292]invalid time format: '{1970 1 1 …}' - -**原因**: 一个 `timestamp` 类型的时间戳记录了不存在的时间值。时间值不存在是由于夏时制切换或超出支持的范围（1970 年 1 月 1 日至 2038 年 1 月 19 日）。 - -**解决办法**: - -1. 确保 Lightning 与数据源时区一致。 - - * 使用 Ansible 部署的话，修正 [`inventory.ini`] 下的 `timezone` 变量。 - - ```ini - # inventory.ini - [all:vars] - timezone = Asia/Shanghai - ``` - - * 手动部署的话，通过设定 `$TZ` 环境变量强制时区设定。 - - 强制使用 Asia/Shanghai 时区： - - {{< copyable "shell-regular" >}} - - ```sh - TZ='Asia/Shanghai' bin/tidb-lightning -config tidb-lightning.toml - ``` - -2. 导出数据时，必须加上 `--skip-tz-utc` 选项。 - -3. 确保整个集群使用的是同一最新版本的 `tzdata` (2018i 或更高版本)。 - - 如果你使用的是 CentOS 机器，你可以运行 `yum info tzdata` 命令查看 `tzdata` 的版本及是否有更新。然后运行 `yum upgrade tzdata` 命令升级 `tzdata`。 diff --git a/dev/how-to/upgrade/from-previous-version.md b/dev/how-to/upgrade/from-previous-version.md deleted file mode 100644 index a59bcf2a416d..000000000000 --- a/dev/how-to/upgrade/from-previous-version.md +++ /dev/null @@ -1,220 +0,0 @@ ---- -title: TiDB 最新开发版升级操作指南 -category: how-to -aliases: ['/docs-cn/dev/how-to/upgrade/to-tidb-3.0/','/docs-cn/dev/how-to/upgrade/rolling-updates-with-ansible/'] ---- - -# TiDB 最新开发版升级操作指南 - -本文档适用于从 TiDB 2.0、2.1、3.0、3.1 版本升级至 TiDB 最新开发版 (latest) 以及从开发版的较低版本升级至最新版本。目前，TiDB 最新开发版兼容 [TiDB Binlog Cluster 版本](/dev/reference/tidb-binlog/overview.md)。 - -> **警告：** -> -> TiDB 最新开发版为非稳定版本，不建议用于生产环境。 - -## 升级兼容性说明 - -- 不支持在升级后回退至 2.1.x 或更旧版本 -- 从 2.0.6 之前的版本升级到 latest 之前，需要确认集群中是否存在正在运行中的 DDL 操作，特别是耗时的 `Add Index` 操作，等 DDL 操作完成后再执行升级操作 -- 2.1 及之后版本启用了并行 DDL，早于 2.0.1 版本的集群，无法滚动升级到 latest 版本，可以选择下面两种方案： - - 停机升级，直接从早于 2.0.1 的 TiDB 版本升级到 latest 版本 - - 先滚动升级到 2.0.1 或者之后的 2.0.x 版本，再滚动升级到 latest 版本 - -> **注意：** -> -> 在升级的过程中不要执行 DDL 请求，否则可能会出现行为未定义的问题。 - -## 在中控机器上安装 Ansible 及其依赖 - -> **注意：** -> -> 如果已经安装了 Ansible 及其依赖，可跳过该步骤。 - -TiDB Ansible 最新开发版依赖 2.4.2 及以上但不高于 2.7.11 的 Ansible 版本（`2.4.2 ≦ ansible ≦ 2.7.11`，建议 2.7.11 版本），另依赖 Python 模块：`jinja2 ≧ 2.9.6` 和 `jmespath ≧ 0.9.0`。为方便管理依赖，建议使用 `pip` 安装 Ansible 及其依赖，可参照[在中控机器上安装 Ansible 及其依赖](/dev/how-to/deploy/orchestrated/ansible.md#在中控机器上安装-ansible-及其依赖) 进行安装。离线环境参照[在中控机器上离线安装 Ansible 及其依赖](/dev/how-to/deploy/orchestrated/offline-ansible.md#在中控机器上离线安装-ansible-及其依赖)。 - -安装完成后，可通过以下命令查看版本： - -{{< copyable "shell-regular" >}} - -```bash -ansible --version -``` - -``` -ansible 2.7.11 -``` - -{{< copyable "shell-regular" >}} - -```bash -pip show jinja2 -``` - -``` -Name: Jinja2 -Version: 2.10 -``` - -{{< copyable "shell-regular" >}} - -```bash -pip show jmespath -``` - -``` -Name: jmespath -Version: 0.9.0 -``` - -> **注意：** -> -> 请务必按以上文档安装 Ansible 及其依赖。确认 Jinja2 版本是否正确，否则启动 Grafana 时会报错。确认 jmespath 版本是否正确，否则滚动升级 TiKV 时会报错。 - -## 在中控机器上下载 TiDB Ansible - -以 `tidb` 用户登录中控机并进入 `/home/tidb` 目录，备份 TiDB 2.0、2.1、3.0 或其他低版本的 tidb-ansible 文件夹： - -{{< copyable "shell-regular" >}} - -```bash -mv tidb-ansible tidb-ansible-bak -``` - -下载 TiDB latest 版本对应的 tidb-ansible [**下载 TiDB Ansible**](/dev/how-to/deploy/orchestrated/ansible.md#在中控机器上下载-tidb-ansible)，默认的文件夹名称为 `tidb-ansible`。 - -{{< copyable "shell-regular" >}} - -```bash -git clone https://github.com/pingcap/tidb-ansible.git -``` - -## 编辑 inventory.ini 文件和配置文件 - -以 `tidb` 用户登录中控机并进入 `/home/tidb/tidb-ansible` 目录。 - -### 编辑 `inventory.ini` 文件 - -编辑 `inventory.ini` 文件，IP 信息参照备份文件 `/home/tidb/tidb-ansible-bak/inventory.ini`。 - -以下变量配置，需要重点确认，变量含义可参考 [inventory.ini 变量调整](/dev/how-to/deploy/orchestrated/ansible.md#调整其它变量可选)。 - -1. 请确认 `ansible_user` 配置的是普通用户。为统一权限管理，不再支持使用 root 用户远程安装。默认配置中使用 `tidb` 用户作为 SSH 远程用户及程序运行用户。 - - ``` - ## Connection - # ssh via normal user - ansible_user = tidb - ``` - - 可参考[如何配置 SSH 互信及 sudo 规则](/dev/how-to/deploy/orchestrated/ansible.md#第-5-步在中控机上配置部署机器-ssh-互信及-sudo-规则)自动配置主机间互信。 - -2. `process_supervision` 变量请与之前版本保持一致，默认推荐使用 `systemd`。 - - ``` - # process supervision, [systemd, supervise] - process_supervision = systemd - ``` - - 如需变更，可参考[如何调整进程监管方式从 supervise 到 systemd](/dev/how-to/deploy/orchestrated/ansible.md#如何调整进程监管方式从-supervise-到-systemd)，先使用备份 `/home/tidb/tidb-ansible-bak/` 分支变更进程监管方式再升级。 - -### 编辑 TiDB 集群组件配置文件 - -如之前自定义过 TiDB 集群组件配置文件，请参照备份文件修改 `/home/tidb/tidb-ansible/conf` 下对应配置文件。 - -**注意以下参数变更：** - -- TiKV 配置中 `end-point-concurrency` 变更为 `high-concurrency`、`normal-concurrency` 和 `low-concurrency` 三个参数： - - ``` - readpool: - coprocessor: - # Notice: if CPU_NUM > 8, default thread pool size for coprocessors - # will be set to CPU_NUM * 0.8. - # high-concurrency: 8 - # normal-concurrency: 8 - # low-concurrency: 8 - ``` - - > **注意：** - > - > 2.0 版本升级且单机多 TiKV 实例（进程）情况下，需要修改这三个参数。 - > - > 推荐设置：TiKV 实例数量 \* 参数值 = CPU 核心数量 \* 0.8 - -- TiKV 配置中不同 CF 中的 `block-cache-size` 参数变更为 `block-cache`： - - ``` - storage: - block-cache: - capacity: "1GB" - ``` - - > **注意：** - > - > 单机多 TiKV 实例（进程）情况下，需要修改 `capacity` 参数。 - > - > 推荐设置：`capacity` = (MEM_TOTAL * 0.5 / TiKV 实例数量) - -- TiKV 配置中单机多实例场景需要额外配置 `tikv_status_port` 端口： - - ``` - [tikv_servers] - TiKV1-1 ansible_host=172.16.10.4 deploy_dir=/data1/deploy tikv_port=20171 tikv_status_port=20181 labels="host=tikv1" - TiKV1-2 ansible_host=172.16.10.4 deploy_dir=/data2/deploy tikv_port=20172 tikv_status_port=20182 labels="host=tikv1" - TiKV2-1 ansible_host=172.16.10.5 deploy_dir=/data1/deploy tikv_port=20171 tikv_status_port=20181 labels="host=tikv2" - TiKV2-2 ansible_host=172.16.10.5 deploy_dir=/data2/deploy tikv_port=20172 tikv_status_port=20182 labels="host=tikv2" - TiKV3-1 ansible_host=172.16.10.6 deploy_dir=/data1/deploy tikv_port=20171 tikv_status_port=20181 labels="host=tikv3" - TiKV3-2 ansible_host=172.16.10.6 deploy_dir=/data2/deploy tikv_port=20172 tikv_status_port=20182 labels="host=tikv3" - ``` - - > **注意：** - > - > 最新开发版单机多 TiKV 实例（进程）情况下，需要添加 `tikv_status_port` 参数。 - > - > 配置前，注意检查端口是否有冲突。 - -## 下载 TiDB latest binary 到中控机 - -确认 `tidb-ansible/inventory.ini` 文件中 `tidb_version = latest`，然后执行以下命令下载 TiDB latest binary 到中控机。 - -{{< copyable "shell-regular" >}} - -```bash -ansible-playbook local_prepare.yml -``` - -## 滚动升级 TiDB 集群组件 - -- 如果 `process_supervision` 变量使用默认的 `systemd` 参数： - - - 当前集群版本 < 3.0，则通过 `excessive_rolling_update.yml` 滚动升级 TiDB 集群。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook excessive_rolling_update.yml - ``` - - - 当前集群版本 ≥ 3.0.0，滚动升级及日常滚动重启 TiDB 集群，使用 `rolling_update.yml`。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update.yml - ``` - -- 如果 `process_supervision` 变量使用的是 `supervise` 参数，无论当前集群为哪个版本，均通过 `rolling_update.yml` 来滚动升级 TiDB 集群。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update.yml - ``` - -## 滚动升级 TiDB 监控组件 - -{{< copyable "shell-regular" >}} - -```bash -ansible-playbook rolling_update_monitor.yml -``` diff --git a/dev/key-features.md b/dev/key-features.md deleted file mode 100644 index 4d739c036396..000000000000 --- a/dev/key-features.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: TiDB 核心特性 -category: introduction ---- - -# TiDB 核心特性 - -本文详细介绍 TiDB 的两大核心特性：水平扩展与高可用。 - -## 水平扩展 - -无限水平扩展是 TiDB 的一大特点，这里说的水平扩展包括两方面：计算能力和存储能力。TiDB Server 负责处理 SQL 请求，随着业务的增长，可以简单的添加 TiDB Server 节点，提高整体的处理能力，提供更高的吞吐。TiKV 负责存储数据，随着数据量的增长，可以部署更多的 TiKV Server 节点解决数据 Scale 的问题。PD 会在 TiKV 节点之间以 Region 为单位做调度，将部分数据迁移到新加的节点上。所以在业务的早期，可以只部署少量的服务实例（推荐至少部署 3 个 TiKV， 3 个 PD，2 个 TiDB），随着业务量的增长，按照需求添加 TiKV 或者 TiDB 实例。 - -## 高可用 - -高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。 - -- TiDB - - TiDB 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，会影响正在这个实例上进行的 Session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。 - -- PD - - PD 是一个集群，通过 Raft 协议保持数据的一致性，单个实例失效时，如果这个实例不是 Raft 的 leader，那么服务完全不受影响；如果这个实例是 Raft 的 leader，会重新选出新的 Raft leader，自动恢复服务。PD 在选举的过程中无法对外提供服务，这个时间大约是3秒钟。推荐至少部署三个 PD 实例，单个实例失效后，重启这个实例或者添加新的实例。 - -- TiKV - - TiKV 是一个集群，通过 Raft 协议保持数据的一致性（副本数量可配置，默认保存三副本），并通过 PD 做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有 Region。对于 Region 中的 Leader 节点，会中断服务，等待重新选举；对于 Region 中的 Follower 节点，不会影响服务。当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上。 diff --git a/dev/overview.md b/dev/overview.md deleted file mode 100644 index acfb689d4c3b..000000000000 --- a/dev/overview.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: TiDB 简介 -category: introduction ---- - -# TiDB 简介 - -TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。 - -TiDB 具备如下特性： - -- 高度兼容 MySQL - - [大多数情况下](/dev/reference/mysql-compatibility.md)，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。 - -- 水平弹性扩展 - - 通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。 - -- 分布式事务 - - TiDB 100% 支持标准的 ACID 事务。 - -- 真正金融级高可用 - - 相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。 - -- 一站式 HTAP 解决方案 - - TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解决方案，一份存储同时处理 OLTP & OLAP，无需传统繁琐的 ETL 过程。 - -- 云原生 SQL 数据库 - - TiDB 是为云而设计的数据库，支持公有云、私有云和混合云，配合 [TiDB Operator 项目](/dev/tidb-in-kubernetes/tidb-operator-overview.md) 可实现自动化运维，使部署、配置和维护变得十分简单。 - -TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 [TiSpark 项目](/dev/reference/tispark.md)来完成。 - -TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力。 - -三篇文章了解 TiDB 技术内幕： - -- [说存储](https://pingcap.com/blog-cn/tidb-internal-1/) -- [说计算](https://pingcap.com/blog-cn/tidb-internal-2/) -- [谈调度](https://pingcap.com/blog-cn/tidb-internal-3/) - -## 部署方式 - -TiDB 可以部署在本地和云平台上，支持公有云、私有云和混合云。你可以根据实际场景或需求，选择相应的方式来部署 TiDB 集群： - -- [使用 Ansible 部署](/dev/how-to/deploy/orchestrated/ansible.md)：如果用于生产环境，推荐使用 Ansible 部署 TiDB 集群。 -- [使用 Ansible 离线部署](/dev/how-to/deploy/orchestrated/offline-ansible.md)：如果部署环境无法访问网络，可使用 Ansible 进行离线部署。 -- [使用 TiDB Operator 部署](/dev/tidb-in-kubernetes/deploy/tidb-operator.md)：使用 TiDB Operator 在 Kubernetes 集群上部署生产就绪的 TiDB 集群，支持[部署到 AWS EKS](/dev/tidb-in-kubernetes/deploy/aws-eks.md)、[部署到谷歌云 GKE (beta)](/dev/tidb-in-kubernetes/deploy/gcp-gke.md)、[部署到阿里云 ACK](/dev/tidb-in-kubernetes/deploy/alibaba-cloud.md) 等。 -- [使用 Docker Compose 部署](/dev/how-to/get-started/deploy-tidb-from-docker-compose.md)：如果你只是想测试 TiDB、体验 TiDB 的特性，或者用于开发环境，可以使用 Docker Compose 在本地快速部署 TiDB 集群。该部署方式不适用于生产环境。 -- [使用 Docker 部署](/dev/how-to/deploy/orchestrated/docker.md)：你可以使用 Docker 部署 TiDB 集群，但该部署方式不适用于生产环境。 -- [使用 TiDB Operator 部署到 Minikube](/dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-minikube.md)：你可以使用 TiDB Opeartor 将 TiDB 集群部署到本地 Minikube 启动的 Kubernetes 集群中。该部署方式不适用于生产环境。 -- [使用 TiDB Operator 部署到 kind](/dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-kind.md)：你可以使用 TiDB Operator 将 TiDB 集群部署到以 kind 方式启动的 Kubernetes 本地集群中。该部署方式不适用于生产环境。 - -## 项目源码 - -TiDB 集群所有组件的源码均可从 GitHub 上直接访问： - -- [TiDB](https://github.com/pingcap/tidb) -- [TiKV](https://github.com/tikv/tikv) -- [PD](https://github.com/pingcap/pd) -- [TiSpark](https://github.com/pingcap/tispark) -- [TiDB Operator](https://github.com/pingcap/tidb-operator) diff --git a/dev/reference/best-practices/high-concurrency.md b/dev/reference/best-practices/high-concurrency.md deleted file mode 100644 index aecbb59f5c9b..000000000000 --- a/dev/reference/best-practices/high-concurrency.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -title: TiDB 高并发写入场景最佳实践 -summary: 了解 TiDB 在高并发写入场景下的最佳实践。 -category: reference ---- - -# TiDB 高并发写入场景最佳实践 - -在 TiDB 的使用过程中，一个典型场景是高并发批量写入数据到 TiDB。本文阐述了该场景中的常见问题，旨在给出一个业务的最佳实践，帮助读者避免因使用 TiDB 不当而影响业务开发。 - -## 目标读者 - -本文假设你已对 TiDB 有一定的了解，推荐先阅读 TiDB 原理相关的三篇文章（[讲存储](https://pingcap.com/blog-cn/tidb-internal-1/)，[说计算](https://pingcap.com/blog-cn/tidb-internal-2/)，[谈调度](https://pingcap.com/blog-cn/tidb-internal-3/)），以及 [TiDB Best Practice](https://pingcap.com/blog-cn/tidb-best-practice/)。 - -## 高并发批量插入场景 - -高并发批量插入的场景通常出现在业务系统的批量任务中，例如清算以及结算等业务。此类场景存在以下特点： - -- 数据量大 -- 需要短时间内将历史数据入库 -- 需要短时间内读取大量数据 - -这就对 TiDB 提出了以下挑战： - -- 写入/读取能力是否可以线性水平扩展 -- 随着数据持续大并发写入，数据库性能是否稳定不衰减 - -对于分布式数据库来说，除了本身的基础性能外，最重要的就是充分利用所有节点能力，避免让单个节点成为瓶颈。 - -## TiDB 数据分布原理 - -如果要解决以上挑战，需要从 TiDB 数据切分以及调度的原理开始讲起。这里只作简单说明，详情可参阅[谈调度](https://pingcap.com/blog-cn/tidb-internal-3/)。 - -TiDB 以 Region 为单位对数据进行切分，每个 Region 有大小限制（默认 96M）。Region 的切分方式是范围切分。每个 Region 会有多副本，每一组副本，称为一个 Raft Group。每个 Raft Group 中由 Leader 负责执行这块数据的读 & 写（TiDB 即将支持 [Follower-Read](https://zhuanlan.zhihu.com/p/78164196)）。Leader 会自动地被 PD 组件均匀调度在不同的物理节点上，用以均分读写压力。 - -![TiDB 数据概览](/media/best-practices/tidb-data-overview.png) - -只要业务的写入没有 `AUTO_INCREMENT` 的主键，或没有单调递增的索引（即没有业务上的写入热点，更多细节可参阅 [TiDB 正确使用方式](https://zhuanlan.zhihu.com/p/25574778)），从原理上来说，TiDB 依靠这个架构可具备线性扩展的读写能力，并且可以充分利用分布式资源。从这一点看，TiDB 尤其适合高并发批量写入场景的业务。 - -但理论场景和实际情况往往存在不同。以下实例说明了热点是如何产生的。 - -## 热点产生的实例 - -以下为一张示例表： - -```sql -CREATE TABLE IF NOT EXISTS TEST_HOTSPOT( - id BIGINT PRIMARY KEY, - age INT, - user_name VARCHAR(32), - email VARCHAR(128) -) -``` - -这个表的结构非常简单，除了 `id` 为主键以外，没有额外的二级索引。将数据写入该表的语句如下，`id` 通过随机数离散生成： - -{{< copyable "sql" >}} - -```sql -INSERT INTO TEST_HOTSPOT(id, age, user_name, email) values(%v, %v, '%v', '%v'); -``` - -负载是短时间内密集地执行以上写入语句。 - -以上操作看似符合理论场景中的 TiDB 最佳实践，业务上没有热点产生。只要有足够的机器，就可以充分利用 TiDB 的分布式能力。要验证是否真的符合最佳实践，可以在实验环境中进行测试。 - -部署拓扑 2 个 TiDB 节点，3 个 PD 节点，6 个 TiKV 节点。请忽略 QPS，因为测试只是为了阐述原理，并非 benchmark。 - -![QPS1](/media/best-practices/QPS1.png) - -客户端在短时间内发起了“密集”的写入，TiDB 收到的请求是 3K QPS。理论上，压力应该均摊给 6 个 TiKV 节点。但是从 TiKV 节点的 CPU 使用情况上看，存在明显的写入倾斜（tikv - 3 节点是写入热点）： - -![QPS2](/media/best-practices/QPS2.png) - -![QPS3](/media/best-practices/QPS3.png) - -[Raft store CPU](/dev/reference/key-monitoring-metrics/tikv-dashboard.md) 为 `raftstore` 线程的 CPU 使用率，通常代表写入的负载。在这个场景下 tikv-3 为 Raft Leader，tikv-0 和 tikv-1 是 Raft 的 Follower，其他的 TiKV 节点的负载几乎为空。 - -从 PD 的监控中也可以证明热点的产生： - -![QPS4](/media/best-practices/QPS4.png) - -## 热点问题产生的原因 - -以上测试并未达到理论场景中最佳实践，因为刚创建表的时候，这个表在 TiKV 中只会对应为一个 Region，范围是： - -``` -[CommonPrefix + TableID, CommonPrefix + TableID + 1) -``` - -短时间内大量数据会持续写入到同一个 Region 上。 - -![TiKV Region 分裂流程](/media/best-practices/tikv-Region-split.png) - -上图简单描述了这个过程，随着数据持续写入，TiKV 会将一个 Region 切分为多个。但因为首先发起选举的是原 Leader 所在的 Store，所以新切分好的两个 Region 的 Leader 很可能还会在原 Store 上。新切分好的 Region 2，3 上，也会重复之前发生在 Region 1 上的过程。也就是压力会密集地集中在 TiKV-Node 1 上。 - -在持续写入的过程中，PD 发现 Node 1 中产生了热点，会将 Leader 均分到其他的 Node 上。如果 TiKV 的节点数多于副本数的话，TiKV 会尽可能将 Region 迁移到空闲的节点上。这两个操作在数据插入的过程中，也能在 PD 监控中得到印证： - -![QPS5](/media/best-practices/QPS5.png) - -在持续写入一段时间后，整个集群会被 PD 自动地调度成一个压力均匀的状态，到那个时候整个集群的能力才会真正被利用起来。在大多数情况下，以上热点产生的过程是没有问题的，这个阶段属于表 Region 的预热阶段。 - -但是对于高并发批量密集写入场景来说，应该避免这个阶段。 - -## 热点问题的规避方法 - -为了达到场景理论中的最佳性能，可跳过这个预热阶段，直接将 Region 切分为预期的数量，提前调度到集群的各个节点中。 - -TiDB 在 v3.0.x 以及 v2.1.13 后支持一个叫 [Split Region](/dev/reference/sql/statements/split-region.md) 的新特性。这个特性提供了新的语法： - -{{< copyable "sql" >}} - -```sql -SPLIT TABLE table_name [INDEX index_name] BETWEEN (lower_value) AND (upper_value) REGIONS region_num -``` - -{{< copyable "sql" >}} - -```sql -SPLIT TABLE table_name [INDEX index_name] BY (value_list) [, (value_list)] -``` - -但是 TiDB 并不会自动提前完成这个切分操作。原因如下： - -![Table Region Range](/media/best-practices/table-Region-range.png) - -从上图可知，根据行数据 key 的编码规则，行 ID (rowID) 是行数据中唯一可变的部分。在 TiDB 中，rowID 是一个 Int64 整形。但是用户不一定能将 Int64 整形范围均匀切分成需要的份数，然后均匀分布在不同的节点上，还需要结合实际情况。 - -如果行 ID 的写入是完全离散的，那么上述方式是可行的。如果行 ID 或者索引有固定的范围或者前缀（例如，只在 `[2000w, 5000w)` 的范围内离散插入数据），这种写入依然在业务上不产生热点，但是如果按上面的方式进行切分，那么有可能一开始数据仍只写入到某个 Region 上。 - -作为一款通用数据库，TiDB 并不对数据的分布作假设，所以开始只用一个 Region 来对应一个表。等到真实数据插入进来以后，TiDB 自动根据数据的分布来作切分。这种方式是较通用的。 - -所以 TiDB 提供了 `Split Region` 语法，专门针对短时批量写入场景作优化。基于以上案例，下面尝试用 `Split Region` 语法提前切散 Region，再观察负载情况。 - -由于测试的写入数据在正数范围内完全离散，所以用以下语句，在 Int64 空间内提前将表切分为 128 个 Region： - -{{< copyable "sql" >}} - -```sql -SPLIT TABLE TEST_HOTSPOT BETWEEN (0) AND (9223372036854775807) REGIONS 128; -``` - -切分完成以后，可以通过 `SHOW TABLE test_hotspot REGIONS;` 语句查看打散的情况。如果 `SCATTERING` 列值全部为 `0`，代表调度成功。 - -也可以通过 [table-regions.py](https://github.com/pingcap/tidb-ansible/blob/dabf60baba5e740a4bee9faf95e77563d8084be1/scripts/table-regions.py) 脚本，查看 Region 的分布。目前分布已经比较均匀了： - -``` -[root@172.16.4.4 scripts]# python table-regions.py --host 172.16.4.3 --port 31453 test test_hotspot -[RECORD - test.test_hotspot] - Leaders Distribution: - total leader count: 127 - store: 1, num_leaders: 21, percentage: 16.54% - store: 4, num_leaders: 20, percentage: 15.75% - store: 6, num_leaders: 21, percentage: 16.54% - store: 46, num_leaders: 21, percentage: 16.54% - store: 82, num_leaders: 23, percentage: 18.11% - store: 62, num_leaders: 21, percentage: 16.54% -``` - -再重新运行写入负载： - -![QPS6](/media/best-practices/QPS6.png) - -![QPS7](/media/best-practices/QPS7.png) - -![QPS8](/media/best-practices/QPS8.png) - -可以看到已经消除了明显的热点问题了。 - -本示例仅为一个简单的表，还有索引热点的问题需要考虑。读者可参阅 [Split Region](/dev/reference/sql/statements/split-region.md) 文档来了解如何预先切散索引相关的 Region。 - -### 更复杂的热点问题 - -如果表没有主键或者主键不是 Int 类型，而且用户也不想自己生成一个随机分布的主键 ID 的话，TiDB 内部有一个隐式的 `_tidb_rowid` 列作为行 ID。在不使用 `SHARD_ROW_ID_BITS` 的情况下，`_tidb_rowid` 列的值基本也为单调递增，此时也会有写热点存在（参阅 [`SHARD_ROW_ID_BITS` 的详细说明](/dev/reference/configuration/tidb-server/tidb-specific-variables.md#shard_row_id_bits)）。 - -要避免由 `_tidb_rowid` 带来的写入热点问题，可以在建表时，使用 `SHARD_ROW_ID_BITS` 和 `PRE_SPLIT_REGIONS` 这两个建表选项（参阅 [`PRE_SPLIT_REGIONS` 的详细说明](/dev/reference/sql/statements/split-region.md#pre_split_regions)）。 - -`SHARD_ROW_ID_BITS` 用于将 `_tidb_rowid` 列生成的行 ID 随机打散。`pre_split_regions` 用于在建完表后预先进行 Split region。 - -> **注意：** -> -> `pre_split_regions` 必须小于或等于 `shard_row_id_bits`。 - -示例： - -{{< copyable "sql" >}} - -```sql -create table t (a int, b int) shard_row_id_bits = 4 pre_split_regions=·3; -``` - -- `SHARD_ROW_ID_BITS = 4` 表示 tidb_rowid 的值会随机分布成 16 （16=2^4） 个范围区间。 -- `pre_split_regions=3` 表示建完表后提前切分出 8 (2^3) 个 Region。 - -开始写数据进表 t 后，数据会被写入提前切分好的 8 个 Region 中，这样也避免了刚开始建表完后因为只有一个 Region 而存在的写热点问题。 - -## 参数配置 - -TiDB 2.1 版本中在 SQL 层引入了 [latch 机制](/dev/reference/configuration/tidb-server/configuration-file.md#txn-local-latches)，用于在写入冲突比较频繁的场景中提前发现事务冲突，减少 TiDB 和 TiKV 事务提交时写写冲突导致的重试。通常，跑批场景使用的是存量数据，所以并不存在事务的写入冲突。可以把 TiDB 的 latch 功能关闭，以减少为细小对象分配内存： - -``` -[txn-local-latches] -enabled = false -``` diff --git a/dev/reference/best-practices/java-app.md b/dev/reference/best-practices/java-app.md deleted file mode 100644 index 7891a1c27894..000000000000 --- a/dev/reference/best-practices/java-app.md +++ /dev/null @@ -1,333 +0,0 @@ ---- -title: 开发 Java 应用使用 TiDB 的最佳实践 -category: reference -aliases: ['/docs-cn/dev/reference/best-practices/using-tidb-in-java/'] ---- - -# 开发 Java 应用使用 TiDB 的最佳实践 - -本文主要介绍如何开发 Java 应用程序以更好地使用 TiDB，包括开发中的常见问题与最佳实践。 - -## Java 应用中的数据库相关组件 - -通常 Java 应用中和数据库相关的常用组件有： - -- 网络协议：客户端通过标准 [MySQL 协议](https://dev.mysql.com/doc/internals/en/client-server-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/)) 的封装来进一步简化和管理数据库访问操作。 -- 业务实现：业务逻辑控制着何时发送和发送什么指令到数据库，其中有些业务会使用 [Spring Transaction](https://docs.spring.io/spring/docs/4.2.x/spring-framework-reference/html/transaction.html) 切面来控制管理事务的开始和提交逻辑。 - -![Java Component](/media/java-practice-1.png) - -如上图所示，应用可能使用 Spring Transaction 来管理控制事务非手工启停，通过类似 MyBatis 的数据访问框架管理生成和执行 SQL，通过连接池获取已池化的长连接，最后通过 JDBC 接口调用实现通过 MySQL 协议和 TiDB 完成交互。 - -接下来将分别介绍使用各个组件时可能需要关注的问题。 - -## JDBC - -Java 应用尽管可以选择在不同的框架中封装，但在最底层一般会通过调用 JDBC 来与数据库服务器进行交互。对于 JDBC，需要关注的主要有：API 的使用选择和 API Implementer 的参数配置。 - -### JDBC API - -对于基本的 JDBC API 使用可以参考 [JDBC 官方教程](https://docs.oracle.com/javase/tutorial/jdbc/)，本文主要强调几个比较重要的 API 选择。 - -#### 使用 Prepare API - -对于 OLTP 场景，程序发送给数据库的 SQL 语句在去除参数变化后都是可穷举的某几类，因此建议使用[预处理语句 (Prepared Statements)](https://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html) 代替普通的[文本执行](https://docs.oracle.com/javase/tutorial/jdbc/basics/processingsqlstatements.html#executing_queries)，并复用预处理语句来直接执行，从而避免 TiDB 重复解析和生成 SQL 执行计划的开销。 - -目前多数上层框架都会调用 Prepare API 进行 SQL 执行，如果直接使用 JDBC API 进行开发，注意选择使用 Prepare API。 - -另外需要注意 MySQL Connector/J 实现中默认只会做客户端的语句预处理，会将 `?` 在客户端替换后以文本形式发送到服务端，所以除了要使用 Prepare API，还需要在 JDBC 连接参数中配置 `useServerPrepStmts = true`，才能在 TiDB 服务器端进行语句预处理（下面参数配置章节有详细介绍）。 - -#### 使用 Batch 批量插入更新 - -对于批量插入更新，如果插入记录较多，可以选择使用 [addBatch/executeBatch API](https://www.tutorialspoint.com/jdbc/jdbc-batch-processing)。通过 addBatch 的方式将多条 SQL 的插入更新记录先缓存在客户端，然后在 executeBatch 时一起发送到数据库服务器。 - -> **注意：** -> -> 对于 MySQL Connector/J 实现，默认 Batch 只是将多次 addBatch 的 SQL 发送时机延迟到调用 executeBatch 的时候，但实际网络发送还是会一条条的发送，通常不会降低与数据库服务器的网络交互次数。 -> -> 如果希望 Batch 网络发送，需要在 JDBC 连接参数中配置 `rewriteBatchedStatements = true`（下面参数配置章节有详细介绍）。 - -#### 使用 StreamingResult 流式获取执行结果 - -一般情况下，为提升执行效率，JDBC 会默认提前获取查询结果并将其保存在客户端内存中。但在查询返回超大结果集的场景中，客户端会希望数据库服务器减少向客户端一次返回的记录数，等客户端在有限内存处理完一部分后再去向服务器要下一批。 - -在 JDBC 中通常有以下两种处理方式： - -- 设置 [`FetchSize` 为 `Integer.MIN_VALUE`](https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-implementation-notes.html#ResultSet) 让客户端不缓存，客户端通过 StreamingResult 的方式从网络连接上流式读取执行结果。 -- 使用 Cursor Fetch，首先需[设置 `FetchSize`](http://makejavafaster.blogspot.com/2015/06/jdbc-fetch-size-performance.html) 为正整数，且在 JDBC URL 中配置 `useCursorFetch = true`。 - -TiDB 中同时支持两种方式，但更推荐使用第一种将 `FetchSize` 设置为 `Integer.MIN_VALUE` 的方式，比第二种功能实现更简单且执行效率更高。 - -### MySQL JDBC 参数 - -JDBC 实现通常通过 JDBC URL 参数的形式来提供实现相关的配置。这里以 MySQL 官方的 Connector/J 来介绍[参数配置](https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-configuration-properties.html)（如果使用的是 MariaDB，可以参考 [MariaDB 的类似配置](https://mariadb.com/kb/en/library/about-mariadb-connector-j/#optional-url-parameters)）。因为配置项较多，这里主要关注几个可能影响到性能的参数。 - -#### Prepare 相关参数 - -##### `useServerPrepStmts` - -默认情况下，`useServerPrepStmts` 的值为 `false`，即尽管使用了 Prepare API，也只会在客户端做 “prepare”。因此为了避免服务器重复解析的开销，如果同一条 SQL 语句需要多次使用 Prepare API，则建议设置该选项为 `true`。 - -在 TiDB 监控中可以通过 **Query Summary** > **QPS By Instance** 查看请求命令类型，如果请求中 `COM_QUERY` 被 `COM_STMT_EXECUTE` 或 `COM_STMT_PREPARE` 代替即生效。 - -##### `cachePrepStmts` - -虽然 `useServerPrepStmts = true` 能让服务端执行预处理语句，但默认情况下客户端每次执行完后会 close 预处理语句，并不会复用，这样预处理的效率甚至不如文本执行。所以建议开启 `useServerPrepStmts = true` 后同时配置 `cachePrepStmts = true`，这会让客户端缓存预处理语句。 - -在 TiDB 监控中可以通过 **Query Summary** > **QPS By Instance** 查看请求命令类型，如果类似下图，请求中 `COM_STMT_EXECUTE` 数目远远多于 `COM_STMT_PREPARE` 即生效。 - -![QPS By Instance](/media/java-practice-2.png) - -另外，通过 `useConfigs = maxPerformance` 配置会同时配置多个参数，其中也包括 `cachePrepStmts = true`。 - -##### `prepStmtCacheSqlLimit` - -在配置 `cachePrepStmts` 后还需要注意 `prepStmtCacheSqlLimit` 配置（默认为 `256`），该配置控制客户端缓存预处理语句的最大长度，超过该长度将不会被缓存。 - -在一些场景 SQL 的长度可能超过该配置，导致预处理 SQL 不能复用，建议根据应用 SQL 长度情况决定是否需要调大该值。 - -在 TiDB 监控中通过 **Query Summary** > **QPS by Instance** 查看请求命令类型，如果已经配置了 `cachePrepStmts = true`，但 `COM_STMT_PREPARE` 还是和 `COM_STMT_EXECUTE` 基本相等且有 `COM_STMT_CLOSE`，需要检查这个配置项是否设置得太小。 - -##### `prepStmtCacheSize` - -`prepStmtCacheSize` 控制缓存的预处理语句数目（默认为 `25`），如果应用需要预处理的 SQL 种类很多且希望复用预处理语句，可以调大该值。 - -和上一条类似，在监控中通过 **Query Summary** > **QPS by Instance** 查看请求中 `COM_STMT_EXECUTE` 数目是否远远多于 `COM_STMT_PREPARE` 来确认是否正常。 - -#### Batch 相关参数 - -在进行 batch 写入处理时推荐配置 `rewriteBatchedStatements = true`，在已经使用 `addBatch` 或 `executeBatch` 后默认 JDBC 还是会一条条 SQL 发送，例如： - -```java -pstmt = prepare(“insert into t (a) values(?)”); -pstmt.setInt(1, 10); -pstmt.addBatch(); -pstmt.setInt(1, 11); -pstmt.addBatch(); -pstmt.setInt(1, 12); -pstmt.executeBatch(); -``` - -虽然使用了 batch 但发送到 TiDB 语句还是单独的多条 insert： - -{{< copyable "sql" >}} - -```sql -insert into t(a) values(10); -insert into t(a) values(11); -insert into t(a) values(12); -``` - -如果设置 `rewriteBatchedStatements = true`，发送到 TiDB 的 SQL 将是： - -{{< copyable "sql" >}} - -```sql -insert into t(a) values(10),(11),(12); -``` - -需要注意的是，insert 语句的改写，只能将多个 values 后的值拼接成一整条 SQL，insert 语句如果有其他差异将无法被改写。 -例如： - -{{< copyable "sql" >}} - -```sql -insert into t (a) values (10) on duplicate key update a = 10; -insert into t (a) values (11) on duplicate key update a = 11; -insert into t (a) values (12) on duplicate key update a = 12; -``` - -上述 insert 语句将无法被改写成一条语句。该例子中，如果将 SQL 改写成如下形式： - -{{< copyable "sql" >}} - -```sql -insert into t (a) values (10) on duplicate key update a = values(a); -insert into t (a) values (11) on duplicate key update a = values(a); -insert into t (a) values (12) on duplicate key update a = values(a); -``` - -即可满足改写条件，最终被改写成： - -{{< copyable "sql" >}} - -```sql -insert into t (a) values (10), (11), (12) on duplicate key update a = values(a); -``` - -批量更新时如果有 3 处或 3 处以上更新，则 SQL 语句会改写为 multiple-queries 的形式并发送，这样可以有效减少客户端到服务器的请求开销，但副作用是会产生较大的 SQL 语句，例如这样： - -{{< copyable "sql" >}} - -```sql -update t set a = 10 where id = 1; update t set a = 11 where id = 2; update t set a = 12 where id = 3; -``` - -另外，因为一个[客户端 bug](https://bugs.mysql.com/bug.php?id=96623)，批量更新时如果要配置 `rewriteBatchedStatements = true` 和 `useServerPrepStmts = true`，推荐同时配置 `allowMultiQueries = true` 参数来避免这个 bug。 - -#### 执行前检查参数 - -通过监控可能会发现，虽然业务只向集群进行 insert 操作，却看到有很多多余的 select 语句。通常这是因为 JDBC 发送了一些查询设置类的 SQL 语句（例如 `select @@session.transaction_read_only`）。这些 SQL 对 TiDB 无用，推荐配置 `useConfigs = maxPerformance` 来避免额外开销。 - -`useConfigs = maxPerformance` 会包含一组配置： - -```ini -cacheServerConfiguration = true -useLocalSessionState = true -elideSetAutoCommits = true -alwaysSendSetIsolation = false -enableQueryTimeouts = false -``` - -配置后查看监控，可以看到多余语句减少。 - -## 连接池 - -TiDB (MySQL) 连接建立是比较昂贵的操作（至少对于 OLTP），除了建立 TCP 连接外还需要进行连接鉴权操作，所以客户端通常会把 TiDB (MySQL) 连接保存到连接池中进行复用。 - -Java 的连接池实现很多 ([HikariCP](https://github.com/brettwooldridge/HikariCP), [tomcat-jdbc](https://tomcat.apache.org/tomcat-7.0-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 不会限定使用的连接池，应用可以根据业务特点自行选择连接池实现。 - -### 连接数配置 - -比较常见的是应用需要根据自身情况配置合适的连接池大小，以 HikariCP 为例： - -- `maximumPoolSize`：连接池最大连接数，配置过大会导致 TiDB 消耗资源维护无用连接，配置过小则会导致应用获取连接变慢，所以需根据应用自身特点配置合适的值，可参考[这篇文章](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)。 -- `minimumIdle`：连接池最小空闲连接数，主要用于在应用空闲时存留一些连接以应对突发请求，同样是需要根据业务情况进行配置。 - -应用在使用连接池时，需要注意连接使用完成后归还连接，推荐应用使用对应的连接池相关监控（如 `metricRegistry`），通过监控能及时定位连接池问题。 - -### 探活配置 - -连接池维护到 TiDB 的长连接，TiDB 默认不会主动关闭客户端连接（除非报错），但一般客户端到 TiDB 之间还会有 LVS 或 HAProxy 之类的网络代理，它们通常会在连接空闲一定时间后主动清理连接。除了注意代理的 idle 配置外，连接池还需要进行保活或探测连接。 - -如果常在 Java 应用中看到以下错误： - -``` -The last packet sent successfully to the server was 3600000 milliseconds ago. The driver has not received any packets from the server. com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure -``` - -如果 `n milliseconds ago` 中的 `n` 如果是 0 或很小的值，则通常是执行的 SQL 导致 TiDB 异常退出引起的报错，推荐查看 TiDB stderr 日志；如果 n 是一个非常大的值（比如这里的 3600000），很可能是因为这个连接空闲太久然后被中间 proxy 关闭了，通常解决方式除了调大 proxy 的 idle 配置，还可以让连接池执行以下操作： - -- 每次使用连接前检查连接是否可用。 -- 使用单独线程定期检查连接是否可用。 -- 定期发送 test query 保活连接。 - -不同的连接池实现可能会支持其中一种或多种方式，可以查看所使用的连接池文档来寻找对应配置。 - -## 数据访问框架 - -业务应用通常会使用某种数据访问框架来简化数据库的访问。 - -### MyBatis - -[MyBatis](http://www.mybatis.org/mybatis-3/) 是目前比较流行的 Java 数据访问框架，主要用于管理 SQL 并完成结果集和 Java 对象的来回映射工作。MyBatis 和 TiDB 兼容性很好，从历史 issue 可以看出 MyBatis 很少出现问题。这里主要关注如下几个配置。 - -#### Mapper 参数 - -MyBatis 的 Mapper 中支持两种参数： - -- `select 1 from t where id = #{param1}` 会作为预处理语句，被转换为 `select 1 from t where id = ?` 进行预处理，并使用实际参数来复用执行，通过配合前面的 Prepare 连接参数能获得最佳性能。 -- `select 1 from t where id = ${param2}` 会做文本替换为 `select 1 from t where id = 1` 执行，如果这条语句被预处理为不同参数，可能会导致 TiDB 缓存大量的预处理语句，并且以这种方式执行 SQL 有注入安全风险。 - -#### 动态 SQL Batch - -[动态 SQL - foreach](http://www.mybatis.org/mybatis-3/dynamic-sql.html#foreach) - -要支持将多条 insert 语句自动重写为 `insert ... values(...), (...), ...` 的形式，除了前面所说的在 JDBC 配置 `rewriteBatchedStatements = true` 外，MyBatis 还可以使用动态 SQL 来半自动生成 batch insert。比如下面的 mapper: - -```xml - - insert into test - (id, v1, v2) - values - - ( - #{item.id}, #{item.v1}, #{item.v2} - ) - - on duplicate key update v2 = v1 + values(v1) - -``` - -会生成一个 `insert on duplicate key update` 语句，values 后面的 `(?, ?, ?)` 数目是根据传入的 list 个数决定，最终效果和使用 `rewriteBatchStatements = true` 类似，可以有效减少客户端和 TiDB 的网络交互次数，同样需要注意预处理后超过 `prepStmtCacheSqlLimit` 限制导致不缓存预处理语句的问题。 - -#### Streaming 结果 - -前面介绍了在 JDBC 中如何使用流式读取结果，除了 JDBC 相应的配置外，在 MyBatis 中如果希望读取超大结果集合也需要注意： - -- 可以通过在 mapper 配置中对单独一条 SQL 设置 `fetchSize`（见上一段代码段），效果等同于调用 JDBC `setFetchSize` -- 可以使用带 `ResultHandler` 的查询接口来避免一次获取整个结果集 -- 可以使用 `Cursor` 类来进行流式读取 - -对于使用 xml 配置映射，可以通过在映射 ` - select * from post; - -``` - -而使用代码配置映射，则可以使用 `@Options(fetchSize = Integer.MIN_VALUE)` 并返回 `Cursor` 从而让 SQL 结果能被流式读取。 - -```java -@Select("select * from post") -@Options(fetchSize = Integer.MIN_VALUE) -Cursor queryAllPost(); -``` - -### `ExecutorType` - -在 `openSession` 的时候可以选择 `ExecutorType`，MyBatis 支持三种 executor： - -- Simple：每次执行都会向 JDBC 进行预处理语句的调用（如果 JDBC 配置有开启 `cachePrepStmts`，重复的预处理语句会复用）。 -- Reuse：在 `executor` 中缓存预处理语句，这样不用 JDBC 的 `cachePrepStmts` 也能减少重复预处理语句的调用。 -- Batch：每次更新只有在 `addBatch` 到 query 或 commit 时才会调用 `executeBatch` 执行，如果 JDBC 层开启了 `rewriteBatchStatements`，则会尝试改写，没有开启则会一条条发送。 - -通常默认值是 `Simple`，需要在调用 `openSession` 时改变 `ExecutorType`。如果是 Batch 执行，会遇到事务中前面的 update 或 insert 都非常快，而在读数据或 commit 事务时比较慢的情况，这实际上是正常的，在排查慢 SQL 时需要注意。 - -## Spring Transaction - -在应用代码中业务可能会通过使用 [Spring Transaction](https://docs.spring.io/spring/docs/4.2.x/spring-framework-reference/html/transaction.html) 和 AOP 切面的方式来启停事务。 - -通过在方法定义上添加 `@Transactional` 注解标记方法，AOP 将会在方法前开启事务，方法返回结果前 commit 事务。如果遇到类似业务，可以通过查找代码 `@Transactional` 来确定事务的开启和关闭时机。需要特别注意有内嵌的情况，如果发生内嵌，Spring 会根据 [Propagation](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/Propagation.html) 配置使用不同的行为，因为 TiDB 未支持 savepoint，所以不支持嵌套事务。 - -## 其他 - -### 排查工具 - -在 Java 应用发生问题并且不知道业务逻辑情况下，使用 JVM 强大的排查工具会比较有用。这里简单介绍几个常用工具： - -#### jstack - -[jstack](https://docs.oracle.com/javase/7/docs/technotes/tools/share/jstack.html) 对应于 Go 中的 pprof/goroutine，可以比较方便地排查进程卡死的问题。 - -通过执行 `jstack pid`，即可输出目标进程中所有线程的线程 id 和堆栈信息。输出中默认只有 Java 堆栈，如果希望同时输出 JVM 中的 C++ 堆栈，需要加 `-m` 选项。 - -通过多次 jstack 可以方便地发现卡死问题（比如：都通过 Mybatis BatchExecutor flush 调用 update）或死锁问题（比如：测试程序都在抢占应用中某把锁导致没发送 SQL） - -另外，`top -p $PID -H` 或者 Java swiss knife 都是常用的查看线程 ID 的方法。通过 `printf "%x\n" pid` 把线程 ID 转换成 16 进制，然后去 jstack 输出结果中找对应线程的栈信息，可以定位”某个线程占用 CPU 比较高，不知道它在执行什么”的问题。 - -#### jmap & mat - -和 Go 中的 pprof/heap 不同，[jmap](https://docs.oracle.com/javase/7/docs/technotes/tools/share/jmap.html) 会将整个进程的内存快照 dump 下来（go 是分配器的采样），然后可以通过另一个工具 [mat](https://www.eclipse.org/mat/) 做分析。 - -通过 mat 可以看到进程中所有对象的关联信息和属性，还可以观察线程运行的状态。比如：我们可以通过 mat 找到当前应用中有多少 MySQL 连接对象，每个连接对象的地址和状态信息是什么。 - -需要注意 mat 默认只会处理 reachable objects，如果要排查 young gc 问题可以在 mat 配置中设置查看 unreachable objects。另外对于调查 young gc 问题（或者大量生命周期较短的对象）的内存分配，用 Java Flight Recorder 比较方便。 - -#### trace - -线上应用通常无法修改代码，又希望在 Java 中做动态插桩来定位问题，推荐使用 btrace 或 arthas trace。它们可以在不重启进程的情况下动态插入 trace 代码。 - -#### 火焰图 - -Java 应用中获取火焰图较繁琐，可参阅 [Java Flame Graphs Introduction: Fire For Everyone!](http://psy-lob-saw.blogspot.com/2017/02/flamegraphs-intro-fire-for-everyone.html) 来手动获取。 - -## 总结 - -本文从常用的和数据库交互的 Java 组件的角度，阐述了开发 Java 应用程序使用 TiDB 的常见问题与解决办法。TiDB 是高度兼容 MySQL 协议的数据库，基于 MySQL 开发的 Java 应用的最佳实践也多适用于 TiDB。 - -欢迎大家在 [ASK TUG](https://asktug.com/) 踊跃发言，和我们一起分享讨论 Java 应用使用 TiDB 的实践技巧或遇到的问题。 diff --git a/dev/reference/configuration/pd-server/configuration.md b/dev/reference/configuration/pd-server/configuration.md deleted file mode 100644 index 5bfa9f606a12..000000000000 --- a/dev/reference/configuration/pd-server/configuration.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -title: PD 配置参数 -category: reference ---- - -# PD 配置参数 - -PD 可以通过命令行参数或环境变量配置。 - -## `--advertise-client-urls` - -+ 对外客户端访问 URL 列表。 -+ 默认：`${client-urls}` -+ 在某些情况下，譬如 docker，或者 NAT 网络环境，客户端并不能通过 PD 自己监听的 client URLs 来访问到 PD，这时候，你就可以设置 advertise urls 来让客户端访问 -+ 例如，docker 内部 IP 地址为 172.17.0.1，而宿主机的 IP 地址为 192.168.100.113 并且设置了端口映射 `-p 2379:2379`，那么可以设置为 `--advertise-client-urls="http://192.168.100.113:2379"`，客户端可以通过 `http://192.168.100.113:2379` 来找到这个服务。 - -## `--advertise-peer-urls` - -+ 对外其他 PD 节点访问 URL 列表。 -+ 默认：`${peer-urls}` -+ 在某些情况下，譬如 docker，或者 NAT 网络环境，其他节点并不能通过 PD 自己监听的 peer URLs 来访问到 PD，这时候，你就可以设置 advertise urls 来让其他节点访问 -+ 例如，docker 内部 IP 地址为 172.17.0.1，而宿主机的 IP 地址为 192.168.100.113 并且设置了端口映射 `-p 2380:2380`，那么可以设置为 `--advertise-peer-urls="http://192.168.100.113:2380"`，其他 PD 节点可以通过 `http://192.168.100.113:2380` 来找到这个服务。 - -## `--client-urls` - -+ 处理客户端请求监听 URL 列表。 -+ 默认：`http://127.0.0.1:2379` -+ 如果部署一个集群，\-\-client-urls 必须指定当前主机的 IP 地址，例如 `http://192.168.100.113:2379"`，如果是运行在 docker 则需要指定为 `http://0.0.0.0:2379`。 - -## `--peer-urls` - -+ 处理其他 PD 节点请求监听 URL 列表。 -+ default: `http://127.0.0.1:2380` -+ 如果部署一个集群，\-\-peer-urls 必须指定当前主机的 IP 地址，例如 `http://192.168.100.113:2380`，如果是运行在 docker 则需要指定为 `http://0.0.0.0:2380`。 - -## `--config` - -+ 配置文件。 -+ 默认："" -+ 如果你指定了配置文件，PD 会首先读取配置文件的配置。然后如果对应的配置在命令行参数里面也存在，PD 就会使用命令行参数的配置来覆盖配置文件里面的。 - -## `--data-dir` - -+ PD 存储数据路径。 -+ 默认：`default.${name}` - -## `--initial-cluster` - -+ 初始化 PD 集群配置。 -+ 默认：`"{name}=http://{advertise-peer-url}"` -+ 例如，如果 name 是 "pd", 并且 `advertise-peer-urls` 是 `http://192.168.100.113:2380`, 那么 `initial-cluster` 就是 `pd=http://192.168.100.113:2380`。 -+ 如果你需要启动三台 PD，那么 `initial-cluster` 可能就是 - `pd1=http://192.168.100.113:2380, pd2=http://192.168.100.114:2380, pd3=192.168.100.115:2380`。 - -## `--join` - -+ 动态加入 PD 集群。 -+ 默认："" -+ 如果你想动态将一台 PD 加入集群，你可以使用 `--join="${advertise-client-urls}"`， `advertise-client-url` 是当前集群里面任意 PD 的 `advertise-client-url`，你也可以使用多个 PD 的，需要用逗号分隔。 - -## `-L` - -+ Log 级别。 -+ 默认："info" -+ 我们能选择 debug, info, warn, error 或者 fatal。 - -## `--log-file` - -+ Log 文件。 -+ 默认："" -+ 如果没设置这个参数，log 会默认输出到 "stderr"，如果设置了，log 就会输出到对应的文件里面，在每天凌晨，log 会自动轮转使用一个新的文件，并且将以前的文件改名备份。 - -## `--log-rotate` - -+ 是否开启日志切割。 -+ 默认：true -+ 当值为 true 时,按照 PD 配置文件中 `[log.file]` 信息执行。 - -## `--name` - -+ 当前 PD 的名字。 -+ 默认："pd" -+ 如果你需要启动多个 PD，一定要给 PD 使用不同的名字 - -## `--cacert` - -+ CA 文件路径，用于开启 TLS。 -+ 默认："" - -## `--cert` - -+ 包含 X509 证书的 PEM 文件路径，用户开启 TLS。 -+ 默认："" - -## `--key` - -+ 包含 X509 key 的 PEM 文件路径，用于开启 TLS。 -+ 默认："" - -## `--namespace-classifier` - -+ 指定 PD 使用的 namespace 分类器。 -+ 默认："table" -+ 如果 TiKV 不与 TiDB 集群配合运行，建议配置为 'default'。 - -## `--metrics-addr` - -+ 指定 Prometheus Pushgateway 的地址。 -+ 默认："" -+ 如果留空，则不开启 Prometheus Push。 - -## `--force-new-cluster` - -+ 强制使用当前节点创建新的集群。 -+ 默认：false -+ 仅用于在 PD 丢失多数副本的情况下恢复服务，可能会产生部分数据丢失。 - -## `-V`, `--version` - -+ 输出版本信息并退出。 diff --git a/dev/reference/configuration/tidb-server/configuration-file.md b/dev/reference/configuration/tidb-server/configuration-file.md deleted file mode 100644 index 73a81a629ca6..000000000000 --- a/dev/reference/configuration/tidb-server/configuration-file.md +++ /dev/null @@ -1,444 +0,0 @@ ---- -title: TiDB 配置文件描述 -category: reference ---- - - - -# TiDB 配置文件描述 - -TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/config.toml.example](https://github.com/pingcap/tidb/blob/master/config/config.toml.example) 找到默认值的配置文件，重命名为 `config.toml` 即可。本文档只介绍未包含在[命令行参数](https://pingcap.com/docs-cn/dev/reference/configuration/tidb-server/configuration)中的参数。 - -### `split-table` - -+ 为每个 table 建立单独的 Region。 -+ 默认值：true -+ 如果需要创建大量的表，我们建议把这个参数设置为 false。 - -### `oom-action` - -+ 指定 TiDB 发生 out-of-memory 错误时的操作。 -+ 默认值："log" -+ 现在合法的选项是 ["log", "cancel"]，如果为 "log"，仅仅是打印日志，不作实质处理。如果为 "cancel"，我们会取消执行这个操作，并且输出日志。 - -### `mem-quota-query` - -+ 单条 SQL 语句可以占用的最大内存阈值。 -+ 默认值：34359738368 -+ 超过该值的请求会被 `oom-action` 定义的行为所处理。 - -### `enable-streaming` - -+ 开启 coprocessor 的 streaming 获取数据模式。 -+ 默认值：false - -### `lower-case-table-names` - -+ 这个选项可以设置 TiDB 的系统变量 `lower_case_table_names` 的值。 -+ 默认值：2 -+ 具体可以查看 MySQL 关于这个变量的[描述](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_lower_case_table_names) - -> **注意：** -> -> 目前 TiDB 只支持将该选项的值设为 2，即按照大小写来保存表名，按照小写来比较（不区分大小写）。 - -### `lease` - -+ DDL 租约超时时间。 -+ 默认值：45s -+ 单位：秒 - -### `compatible-kill-query` - -+ 设置 `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`。 - -### `check-mb4-value-in-utf8` - -+ 开启检查 utf8mb4 字符的开关，如果开启此功能，字符集是 utf8，且在 utf8 插入 mb4 字符，系统将会报错。 -+ 默认值：true - -### `treat-old-version-utf8-as-utf8mb4` - -+ 将旧表中的 utf8 字符集当成 utf8mb4的开关。 -+ 默认值：true - -### `alter-primary-key` - -+ 用于控制添加或者删除主键功能。 -+ 默认值：false -+ 默认情况下，不支持增删主键。将此变量被设置为 true 后，支持增删主键功能。不过对在此开关开启前已经存在的表，且主键是整型类型时，即使之后开启此开关也不支持对此列表删除主键。 - -### `repair-mode` - -+ 用于开启非可信修复模式，启动该模式后，可以过滤 `repair-table-list` 名单中坏表的加载。 -+ 默认值：false -+ 默认情况下，不支持修复语法，默认启动时会加载所有表信息。 - -### `repair-table-list` - -+ 配合 `repair-mode` 为 true 时使用，用于列出实例中需要修复的坏表的名单，该名单的写法为 ["db.table1","db.table2"...]。 -+ 默认值：[] -+ 默认情况下，该 list 名单为空，表示没有所需修复的坏表信息。 - -## log - -日志相关的配置项。 - -### `format` - -+ 指定日志输出的格式，可选项为 [json, text, console]。 -+ 默认值："text" - -### `enable-timestamp` - -+ 是否在日志中输出时间戳。 -+ 默认值：true -+ 如果设置为 false，那么日志里面将不会输出时间戳。 - -> **注意：** -> -> 考虑后向兼容性，原来的配置项 `disable-timestamp` 仍然有效，但如果和 `enable-timestamp` 配置的值在语义上冲突（例如在配置中把 `enable-timestamp` 和 `disable-timestamp` 同时设置为 `true`），则 TiDB 会忽略 `disable-timestamp` 的值。在未来的版本中，`disable-timestamp` 配置项将被彻底移除，请废弃 `disable-timestamp` 的用法，使用语义上更易于理解的 `enable-timestamp`。 - -### `slow-query-file` - -+ 慢查询日志的文件名。 -+ 默认值："tidb-slow.log"，注：由于 TiDB V2.1.8 更新了慢日志格式，所以将慢日志单独输出到了慢日志文件。V2.1.8 之前的版本，该变量的默认值是 ""。 -+ 设置后，慢查询日志会单独输出到该文件。 - -### `slow-threshold` - -+ 输出慢日志的耗时阈值。 -+ 默认值：300ms -+ 当查询大于这个值，就会当做是一个慢查询，输出到慢查询日志。 - -### `expensive-threshold` - -+ 输出 `expensive` 操作的行数阈值。 -+ 默认值：10000 -+ 当查询的行数（包括中间结果，基于统计信息）大于这个值，我们就会当成是一个 `expensive` 的操作，输出一个前缀带有 `[EXPENSIVE_QUERY]` 的日志。 - -### `query-log-max-len` - -+ 最长的 SQL 输出长度。 -+ 默认值：2048 -+ 当语句的长度大于 `query-log-max-len`，将会被截断输出。 - -### `max-server-connections` - -+ TiDB 中同时允许的最大客户端连接数，用于资源控制。 -+ 默认值：4096 -+ 当客户端连接数到达 `max-server-connections` 时，TiDB 服务端将会拒绝新的客户端连接。 - -## log.file - -日志文件相关的配置项。 - -#### `filename` - -+ 一般日志文件名字。 -+ 默认值："" -+ 如果设置，会输出一般日志到这个文件。 - -#### `max-size` - -+ 日志文件的大小限制。 -+ 默认值：300MB -+ 最大设置上限为 4GB。 - -#### `max-days` - -+ 日志最大保留的天数。 -+ 默认值：0 -+ 默认不清理；如果设置了参数值，在 `max-days` 之后 TiDB 会清理过期的日志文件。 - -#### `max-backups` - -+ 保留的日志的最大数量。 -+ 默认值：0 -+ 默认全部保存；如果设置为 7，会最多保留 7 个老的日志文件。 - -#### `log-rotate` - -+ 是否每日创建一个新的日志文件。 -+ 默认值：true -+ 如果设置为 true，每天会新建新的日志文件，如果设置为 false，那么只会输出到一个日志文件。 - -## security - -安全相关配置。 - -### `ssl-ca` - -+ PEM 格式的受信任 CA 的证书文件路径。 -+ 默认值："" -+ 当同时设置了该选项和 `--ssl-cert`、`--ssl-key` 选项时，TiDB 将在客户端出示证书的情况下根据该选项指定的受信任的 CA 列表验证客户端证书。若验证失败，则连接会被终止。 -+ 即使设置了该选项，若客户端没有出示证书，则安全连接仍然继续，不会进行客户端证书验证。 - -### `ssl-cert` - -+ PEM 格式的 SSL 证书文件路径。 -+ 默认值："" -+ 当同时设置了该选项和 `--ssl-key` 选项时，TiDB 将接受（但不强制）客户端使用 TLS 安全地连接到 TiDB。 -+ 若指定的证书或私钥无效，则 TiDB 会照常启动，但无法接受安全连接。 - -### `ssl-key` - -+ PEM 格式的 SSL 证书密钥文件路径，即 `--ssl-cert` 所指定的证书的私钥。 -+ 默认值："" -+ 目前 TiDB 不支持加载由密码保护的私钥。 - -### `cluster-ssl-ca` - -+ CA 根证书，用于用 tls 连接 TiKV/PD -+ 默认值："" - -### `cluster-ssl-cert` - -+ ssl 证书文件路径，用于用 tls 连接 TiKV/PD -+ 默认值："" - -### `cluster-ssl-key` - -+ ssl 私钥文件路径，用于用 tls 连接 TiKV/PD -+ 默认值："" - -### `skip-grant-table` - -+ 是否跳过权限检查 -+ 默认值：false - -## performance - -性能相关配置。 - -### `max-procs` - -+ TiDB 的 CPU 使用数量。 -+ 默认值：0 -+ 默认值为 0 表示使用机器上所有的 CPU；如果设置成 n，那么 TiDB 会使用 n 个 CPU 数量。 - -### `max-memory` - -+ Prepare cache LRU 使用的最大内存限制，超过 performance.max-memory * (1 - prepared-plan-cache.memory-guard-ratio)会 剔除 LRU 中的元素。 -+ 默认值：0 -+ 这个配置只有在 prepared-plan-cache.enabled 为 true 的情况才会生效。在 LRU 的 size 大于 prepared-plan-cache.capacity 的情况下，也会剔除 LRU 中的元素。 - -### `stmt-count-limit` - -+ TiDB 一个事务允许的最大语句条数限制。 -+ 默认值：5000 -+ 在一个事务中，超过 `stmt-count-limit` 条语句后还没有 rollback 或者 commit，TiDB 将会返回 `statement count 5001 exceeds the transaction limitation, autocommit = false` 错误。 - -### `tcp-keep-alive` - -+ TiDB 在 TCP 层开启 keepalive。 -+ 默认值：false - -### `cross-join` - -+ 默认值：true -+ 默认可以执行在做 join 时两边表没有任何条件（where 字段）的语句；如果设置为 false，则有这样的 join 语句出现时，server 会拒绝执行 - -### `stats-lease` - -+ TiDB 重载统计信息，更新表行数，检查是否需要自动 analyze，利用 feedback 更新统计信息以及加载列的统计信息的时间间隔。 -+ 默认值：3s - - 每隔 `stats-lease` 时间，TiDB 会检查统计信息是否有更新，如果有会将其更新到内存中 - - 每隔 `20 * stats-lease` 时间，TiDB 会将 DML 产生的总行数以及修改的行数变化更新到系统表中 - - 每隔 `stats-lease` 时间，TiDB 会检查是否有表或者索引需要自动 analyze - - 每隔 `stats-lease` 时间，TiDB 会检查是否有列的统计信息需要被加载到内存中 - - 每隔 `200 * stats-lease` 时间，TiDB 会将内存中缓存的 feedback 写入系统表中 - - 每隔 `5 * stats-lease` 时间，TiDB 会读取系统表中的 feedback，更新内存中缓存的统计信息 -+ 当 `stats-lease` 为 0 时，TiDB 会以 3s 的时间间隔周期性的读取系统表中的统计信息并更新内存中缓存的统计信息。但不会自动修改统计信息相关系统表，具体来说，TiDB 不再自动修改这些表： - - `mysql.stats_meta`：TiDB 不再自动记录事务中对某张表的修改行数，也不会更新到这个系统表中 - - `mysql.stats_histograms`/`mysql.stats_buckets` 和 `mysql.stats_top_n`：TiDB 不再自动 analyze 和主动更新统计信息 - - `mysql.stats_feedback`：TiDB 不再根据被查询的数据反馈的部分统计信息更新表和索引的统计信息 - -### `run-auto-analyze` - -+ TiDB 是否做自动的 Analyze。 -+ 默认值：true - -### `feedback-probability` - -+ TiDB 对查询收集统计信息反馈的概率。 -+ 默认值：0.05 -+ 对于每一个查询，TiDB 会以 `feedback-probability` 的概率收集查询的反馈，用于更新统计信息。 - -### `query-feedback-limit` - -+ 在内存中缓存的最大 Query Feedback 数量，超过这个数量的 Feedback 会被丢弃。 -+ 默认值：1024 - -### `pseudo-estimate-ratio` - -+ 修改过的行数/表的总行数的比值，超过该值时系统会认为统计信息已经过期，会采用 pseudo 的统计信息。 -+ 默认值：0.8 -+ 最小值为 0；最大值为 1。 - -### `force-priority` - -+ 把所有的语句优先级设置为 force-priority 的值。 -+ 默认值：NO_PRIORITY -+ 可选值：NO_PRIORITY, LOW_PRIORITY, HIGH_PRIORITY, DELAYED。 - -## prepared-plan-cache - -prepare 语句的 Plan cache 设置。 - -### `enabled` - -+ 开启 prepare 语句的 plan cache。 -+ 默认值：false - -### `capacity` - -+ 缓存语句的数量。 -+ 默认值：100 - -### `memory-guard-ratio` - -+ 用于防止超过 performance.max-memory, 超过 max-proc * (1 - prepared-plan-cache.memory-guard-ratio)会剔除 LRU 中的元素。 -+ 默认值：0.1 -+ 最小值为 0；最大值为 1。 - -## tikv-client - -### `grpc-connection-count` - -+ 跟每个 TiKV 之间建立的最大连接数。 -+ 默认值：16 - -### `grpc-keepalive-time` - -+ TiDB 与 TiKV 节点之间 rpc 连接 keepalive 时间间隔，如果超过该值没有网络包，grpc client 会 ping 一下 TiKV 查看是否存活。 -+ 默认值：10 -+ 单位：秒 - -### `grpc-keepalive-timeout` - -+ TiDB 与 TiKV 节点 rpc keepalive 检查的超时时间 -+ 默认值：3 -+ 单位：秒 - -### `commit-timeout` - -+ 执行事务提交时，最大的超时时间。 -+ 默认值：41s -+ 这个值必须是大于两倍 Raft 选举的超时时间。 - -### `max-txn-time-use` - -+ 单个事务允许的最大执行时间。 -+ 默认值：590 -+ 单位：秒 - -### `max-batch-size` - -+ 批量发送 rpc 封包的最大数量，如果不为 0，将使用 BatchCommands api 发送请求到 TiKV，可以在并发度高的情况降低 rpc 的延迟，推荐不修改该值。 -+ 默认值：128 - -### `max-batch-wait-time` - -+ 等待 `max-batch-wait-time` 纳秒批量将此期间的数据包封装成一个大包发送给 TiKV 节点，仅在 `tikv-client.max-batch-size` 值大于 0 时有效，不推荐修改该值。 -+ 默认值：0 -+ 单位：纳秒 - -### `batch-wait-size` - -+ 批量向 TiKV 发送的封包最大数量，不推荐修改该值。 -+ 默认值：8 -+ 若此值为 0 表示关闭此功能。 - -### `overload-threshold` - -+ TiKV 的负载阈值，如果超过此阈值，会收集更多的 batch 封包，来减轻 TiKV 的压力。仅在 `tikv-client.max-batch-size` 值大于 0 时有效，不推荐修改该值。 -+ 默认值：200 - -## txn-local-latches - -事务内存锁相关配置，当本地事务冲突比较多时建议开启。 - -### `enable` - -+ 开启或关闭事务内存锁 -+ 默认值：false - -### `capacity` - -+ Hash 对应的 slot 数，会自动向上调整为 2 的指数倍。每个 slot 占 32 Bytes 内存。当写入数据的范围比较广时（如导数据），设置过小会导致变慢，性能下降。 -+ 默认值：2048000 - -## binlog - -TiDB Binlog 相关配置。 - -### `enable` - -+ binlog 开关。 -+ 默认值：false - -### `write-timeout` - -+ 写 binlog 的超时时间，推荐不修改该值。 -+ 默认值：15s -+ 单位：秒 - -### `ignore-error` - -+ 忽略写 binlog 发生的错误时处理开关，推荐不修改该值。 -+ 默认值：false -+ 如果设置为 `true`，发生错误时，TiDB 会停止写入 binlog，并且在监控项 `tidb_server_critical_error_total` 上计数加 1；如果设置为 `false`，写入 binlog 失败，会停止整个 TiDB 的服务。 - -### `binlog-socket` - -+ binlog 输出网络地址。 -+ 默认值："" - -### `strategy` - -+ binlog 输出时选择 pump 的策略，仅支持 hash，range 方法。 -+ 默认值："range" - -## status - -TiDB 服务状态相关配置。 - -### `report-status` - -+ 开启 HTTP API 服务的开关。 -+ 默认值：true - -### `record-db-qps` - -+ 输与 database 相关的 QPS metrics 到 Prometheus 的开关。 -+ 默认值：false - -## stmt-summary 从 v3.0.4 版本开始引入 - -系统表 `events_statement_summary_by_digest` 的相关配置。 - -### max-stmt-count - -+ `events_statement_summary_by_digest` 表中保存的 SQL 种类的最大数量。 -+ 默认值：100 - -### max-sql-length - -+ `events_statement_summary_by_digest` 表中`DIGEST_TEXT` 和 `QUERY_SAMPLE_TEXT` 列的最大显示长度。 -+ 默认值：4096 - -## pessimistic-txn - -### enable - -+ 开启悲观事务支持，悲观事务使用方法请参考 [TiDB 悲观事务模式](/dev/reference/transactions/transaction-pessimistic.md)。 -+ 默认值：true - -### max-retry-count - -+ 悲观事务中每个语句最大重试次数，超出该限制将会报错。 -+ 默认值：256 diff --git a/dev/reference/configuration/tidb-server/configuration.md b/dev/reference/configuration/tidb-server/configuration.md deleted file mode 100644 index 8235a306537b..000000000000 --- a/dev/reference/configuration/tidb-server/configuration.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -title: TiDB 配置参数 -category: reference ---- - -# TiDB 配置参数 - -在启动 TiDB 时，你可以使用命令行参数或环境变量来配置 TiDB。本文将详细介绍 TiDB 的命令行启动参数。TiDB 的默认端口为 4000（客户端请求）与 10080（状态报告）。 - -## `--advertise-address` - -+ 登录 TiDB 的 IP 地址 -+ 默认："" -+ 必须确保用户和集群中的其他机器都能够访问到该 IP 地址 - -## `--binlog-socket` - -+ TiDB 服务使用 unix socket file 方式接受内部连接，如 Pump 服务 -+ 默认："" -+ 例如，可以使用 "/tmp/pump.sock" 来接受 Pump unix socket file 通信 - -## `--config` - -+ 配置文件 -+ 默认："" -+ 如果你指定了配置文件，TiDB 会首先读取配置文件的配置。如果对应的配置在命令行参数里面也存在，TiDB 就会使用命令行参数的配置来覆盖配置文件中的配置。详细的配置项请参阅 [TiDB 配置文件描述](/dev/reference/configuration/tidb-server/configuration-file.md)。 - -## `--cors` - -+ 用于设置 TiDB HTTP 状态服务的 Access-Control-Allow-Origin -+ 默认："" - -## `--host` - -+ TiDB 服务监听的 host -+ 默认："0.0.0.0" -+ 0.0.0.0 默认会监听所有的网卡地址。如果有多块网卡，可以指定对外提供服务的网卡，如 192.168.100.113 - -## `-L` - -+ Log 级别 -+ 默认："info" -+ 可选项为：debug、info、warn、error、fatal - -## `--log-file` - -+ Log 文件 -+ 默认："" -+ 如果未设置该参数，log 会默认输出到 "stderr"；如果设置了该参数，log 会输出到对应的文件中。每天凌晨，log 会自动轮转使用一个新的文件，并且将以前的文件改名备份 - -## `--log-slow-query` - -+ 慢查询日志文件路径 -+ 默认："" -+ 如果未设置该参数，log 会默认输出到 `--log-file` 指定的文件中 - -## `--metrics-addr` - -+ Prometheus Pushgateway 地址 -+ 默认："" -+ 如果该参数为空，TiDB 不会将统计信息推送给 Pushgateway。参数格式示例：`--metrics-addr=192.168.100.115:9091` - -## `--metrics-interval` - -+ 推送统计信息到 Prometheus Pushgateway 的时间间隔 -+ 默认：15s -+ 设置为 0 表示不推送统计信息给 Pushgateway。示例：`--metrics-interval=2` 指每两秒推送到 Pushgateway - -## `-P` - -+ TiDB 服务监听端口 -+ 默认："4000" -+ TiDB 服务会使用该端口接受 MySQL 客户端发来的请求 - -## `--path` - -+ 对于本地存储引擎 "mocktikv" 来说，path 指定的是实际的数据存放路径 -+ 当 `--store = tikv` 时，必须指定 path；当 `--store = mocktikv` 时，如果不指定 path，会使用默认值。 -+ 对于 "TiKV" 存储引擎来说，path 指定的是实际的 PD 地址。假如在 192.168.100.113:2379、192.168.100.114:2379 和 192.168.100.115:2379 上面部署了 PD，那么 path 为 "192.168.100.113:2379, 192.168.100.114:2379, 192.168.100.115:2379" -+ 默认："/tmp/tidb" -+ 可以通过 `tidb-server --store=mocktikv --path=""` 来启动一个纯内存引擎的 TiDB - -## `--proxy-protocol-networks` - -+ PROXY Protocol 允许的代理服务器地址列表。如需配置多个地址，用 `,` 分隔。 -+ 默认："" -+ 如果该参数为空，TiDB 会禁用 PROXY Protocol 功能。地址可以使用 IP 地址 (192.168.1.50) 或者 CIDR (192.168.1.0/24)，`*` 代表所有地址。 - -## `--proxy-protocol-header-timeout` - -+ PROXY Protocol 请求头读取超时时间 -+ 默认：5 -+ 单位：秒 - -> **注意：** -> -> 不要将该参数配置为 `0`。除非特殊情况，一般使用默认值即可。 - -## `--report-status` - -+ 用于打开或者关闭服务状态监听端口 -+ 默认：true -+ 将参数值设置为 `true` 表明开启状态监听端口；设置为 `false` 表明关闭状态监听端口 - -## `--run-ddl` - -+ tidb-server 是否运行 DDL 语句，集群内至少需要有一台 tidb-server 设置该参数 -+ 默认：true -+ 值可以为 `true` 或者 `false`。设置为 `true` 表明自身会运行 DDL；设置为 `false` 表明自身不会运行 DDL - -## `--socket string` - -+ TiDB 服务使用 unix socket file 方式接受外部连接 -+ 默认："" -+ 例如可以使用 "/tmp/tidb.sock" 来打开 unix socket file - -## `--status` - -+ TiDB 服务状态监听端口 -+ 默认："10080" -+ 该端口用于展示 TiDB 内部数据，包括 [prometheus 统计](https://prometheus.io/) 和 [pprof](https://golang.org/pkg/net/http/pprof/) -+ Prometheus 统计可以通过 `http://host:status_port/metrics` 访问 -+ pprof 数据可以通过 `http://host:status_port/debug/pprof` 访问 - -## `--status-host` - -+ TiDB 服务状态监听 host -+ 默认："0.0.0.0" - -## `--store` - -+ 用来指定 TiDB 底层使用的存储引擎 -+ 默认："mocktikv" -+ 可以选择 "mocktikv"（本地存储引擎）或者 "tikv"（分布式存储引擎） - -## `--token-limit` - -+ TiDB 中同时允许运行的 Session 数量，用于流量控制 -+ 默认：1000 -+ 如果当前运行的连接多于该 token-limit，那么请求会阻塞，等待已经完成的操作释放 Token - -## `-V` - -+ 输出 TiDB 的版本 -+ 默认："" diff --git a/dev/reference/configuration/tidb-server/mysql-variables.md b/dev/reference/configuration/tidb-server/mysql-variables.md deleted file mode 100644 index 6e3efe90095a..000000000000 --- a/dev/reference/configuration/tidb-server/mysql-variables.md +++ /dev/null @@ -1,200 +0,0 @@ ---- -title: 系统变量 -category: reference ---- - -# 系统变量 - -MySQL 系统变量 (System Variables) 是一些系统参数，用于调整数据库运行时的行为，根据变量的作用范围分为全局范围有效（Global Scope）以及会话级别有效（Session Scope）。TiDB 支持 MySQL5.7 的所有系统变量，大部分变量仅仅是为了兼容性而支持，不会影响运行时行为。 - -## 设置系统变量 - -通过 [`SET` 语句](/dev/reference/sql/statements/admin.md#set-语句)可以修改系统变量的值。进行修改时，还要考虑变量可修改的范围，不是所有的变量都能在全局/会话范围内进行修改。具体的可修改范围参考 [MySQL 动态变量文档](https://dev.mysql.com/doc/refman/5.7/en/dynamic-system-variables.html)。 - -### 全局范围值 - -* 在变量名前加 `GLOBAL` 关键词或者是使用 `@@global.` 作为修饰符: - - {{< copyable "sql" >}} - - ```sql - SET GLOBAL autocommit = 1; - ``` - - {{< copyable "sql" >}} - - ```sql - SET @@global.autocommit = 1; - ``` - -> **注意：** -> -> 在分布式 TiDB 中，`GLOBAL` 变量的设置会持久化到存储层中，单个 TiDB 实例每 2 秒会主动进行一次全变量的获取并形成 `gvc` (global variables cache) 缓存，该缓存有效时间最多可持续 2 秒。在设置 `GLOBAL` 变量之后，为了保证新会话的有效性，请确保两个操作之间的间隔大于 2 秒。相关细节可以查看 [Issue #14531](https://github.com/pingcap/tidb/issues/14531)。 - -### 会话范围值 - -* 在变量名前加 `SESSION` 关键词或者是使用 `@@session.` 作为修饰符，或者是不加任何修饰符: - - {{< copyable "sql" >}} - - ```sql - SET SESSION autocommit = 1; - ``` - - {{< copyable "sql" >}} - - ```sql - SET @@session.autocommit = 1; - ``` - - {{< copyable "sql" >}} - - ```sql - SET @@autocommit = 1; - ``` - -* `LOCAL` 以及 `@@local.` 是 `SESSION` 以及 `@@session.` 的同义词 - -### 系统变量的作用机制 - -* 会话范围的系统变量仅仅会在创建会话时才会根据全局范围系统变量初始化自己的值。更改全局范围的系统变量不会改变已经创建的会话正在使用的系统变量的值。 - - {{< copyable "sql" >}} - - ```sql - SELECT @@GLOBAL.autocommit; - ``` - - ``` - +---------------------+ - | @@GLOBAL.autocommit | - +---------------------+ - | ON | - +---------------------+ - 1 row in set (0.00 sec) - ``` - - {{< copyable "sql" >}} - - ```sql - SELECT @@SESSION.autocommit; - ``` - - ``` - +----------------------+ - | @@SESSION.autocommit | - +----------------------+ - | ON | - +----------------------+ - 1 row in set (0.00 sec) - ``` - - {{< copyable "sql" >}} - - ```sql - SET GLOBAL autocommit = OFF; - ``` - - ``` - Query OK, 0 rows affected (0.01 sec) - ``` - - 会话范围的系统变量不会改变，会话中执行的事务依旧是以自动提交的形式来进行： - - {{< copyable "sql" >}} - - ```sql - SELECT @@SESSION.autocommit; - ``` - - ``` - +----------------------+ - | @@SESSION.autocommit | - +----------------------+ - | ON | - +----------------------+ - 1 row in set (0.00 sec) - ``` - - {{< copyable "sql" >}} - - ```sql - SELECT @@GLOBAL.autocommit; - ``` - - ``` - +---------------------+ - | @@GLOBAL.autocommit | - +---------------------+ - | OFF | - +---------------------+ - 1 row in set (0.00 sec) - ``` - - {{< copyable "sql" >}} - - ```sql - exit - ``` - - ``` - Bye - ``` - - {{< copyable "shell-regular" >}} - - ```shell - mysql -h 127.0.0.1 -P 4000 -u root -D test - ``` - - ``` - Welcome to the MySQL monitor. Commands end with ; or \g. - Your MySQL connection id is 3 - Server version: 5.7.25-TiDB-None MySQL Community Server (Apache License 2.0) - - Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved. - - Oracle is a registered trademark of Oracle Corporation and/or its - affiliates. Other names may be trademarks of their respective - owners. - - Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. - - mysql> - ``` - - 新建的会话会使用新的全局变量： - - ```sql - SELECT @@SESSION.autocommit; - ``` - - ``` - +----------------------+ - | @@SESSION.autocommit | - +----------------------+ - | OFF | - +----------------------+ - 1 row in set (0.00 sec) - ``` - -## TiDB 支持的 MySQL 系统变量 - -下列系统变量是 TiDB 真正支持并且行为和 MySQL 一致： - -| 变量名 | 作用域 | 说明 | -| ---------------- | -------- | -------------------------------------------------- | -| autocommit | GLOBAL \| SESSION | 是否自动 Commit 事务 | -| sql_mode | GLOBAL \| SESSION | 支持部分 MySQL SQL mode，| -| time_zone | GLOBAL \| SESSION | 数据库所使用的时区 | -| tx_isolation | GLOBAL \| SESSION | 事务隔离级别 | -| max\_execution\_time | GLOBAL \| SESSION | 语句超时时间，单位为毫秒 | -| innodb\_lock\_wait\_timeout | GLOBAL \| SESSION | 悲观事务语句等锁时间，单位为秒 | - -> **注意：** -> -> `max_execution_time` 目前对所有类型的 `statement` 生效，并非只对 `SELECT` 语句生效。实际精度在 100ms 级别，而非更准确的毫秒级别。 - -## TiDB 特有的系统变量 - -参见 [TiDB 专用系统变量](/dev/reference/configuration/tidb-server/tidb-specific-variables.md)。 diff --git a/dev/reference/configuration/tidb-server/tidb-specific-variables.md b/dev/reference/configuration/tidb-server/tidb-specific-variables.md deleted file mode 100644 index c37ee6f13e00..000000000000 --- a/dev/reference/configuration/tidb-server/tidb-specific-variables.md +++ /dev/null @@ -1,668 +0,0 @@ ---- -title: TiDB 专用系统变量和语法 -category: reference ---- - -# TiDB 专用系统变量和语法 - -TiDB 在 MySQL 的基础上，定义了一些专用的系统变量和语法用来优化性能。 - -## 系统变量 - -变量可以通过 SET 语句设置，例如 - -{{< copyable "sql" >}} - -```sql -set @@tidb_distsql_scan_concurrency = 10; -``` - -如果需要设置全局变量，执行 - -{{< copyable "sql" >}} - -```sql -set @@global.tidb_distsql_scan_concurrency = 10; -``` - -### tidb_snapshot - -作用域：SESSION - -默认值：空字符串 - -这个变量用来设置当前会话期待读取的历史数据所处时刻。比如当设置为 "2017-11-11 20:20:20" 时或者一个 TSO 数字 "400036290571534337"，当前会话将能读取到该时刻的数据。 - -### tidb_import_data - -作用域：SESSION - -默认值：0 - -这个变量用来表示当前状态是否为从 dump 文件中导入数据。 -当这个变量被设置为 1 时，唯一索引约束不被检查以加速导入速度。 -这个变量不对外用，只是给 lightning 使用，请用户不要自行修改。 - -### tidb_opt_agg_push_down - -作用域：SESSION - -默认值：0 - -这个变量用来设置优化器是否执行聚合函数下推到 Join 之前的优化操作。 -当查询中聚合操作执行很慢时，可以尝试设置该变量为 1。 - -### tidb_auto_analyze_ratio - -作用域：GLOBAL - -默认值：0.5 - -这个变量用来设置自动 ANALYZE 更新的阈值。当某个表 `tbl` 的修改行数与总行数的比值大于 tidb_auto_analyze_ratio，并且当前时间在 tidb_auto_analyze_start_time 和 tidb_auto_analyze_end_time 之间时，TiDB 会在后台执行 `ANALYZE TABLE tbl` 语句以自动更新该表的统计信息。注意：只有在 TiDB 的启动配置文件中开启了 run-auto-analyze 选项，该 TiDB 才会触发 auto_analyze。 - -### tidb_auto_analyze_start_time - -作用域：GLOBAL - -默认值：00:00 +0000 - -这个变量用来设置一天中允许自动 ANALYZE 更新的开始时间。 - -### tidb_auto_analyze_end_time - -作用域：GLOBAL - -默认值：23:59 +0000 - -这个变量用来设置一天中允许自动 ANALYZE 更新的结束时间。 - -### tidb_build_stats_concurrency - -作用域：SESSION - -默认值：4 - -这个变量用来设置 ANALYZE 语句执行时并发度。 -当这个变量被设置得更大时，会对其它的查询语句执行性能产生一定影响。 - -### tidb_checksum_table_concurrency - -作用域：SESSION - -默认值：4 - -这个变量用来设置 ADMIN CHECKSUM TABLE 语句执行时扫描索引的并发度。 -当这个变量被设置得更大时，会对其它的查询语句执行性能产生一定影响。 - -### tidb_current_ts - -作用域：SESSION - -默认值：0 - -这个变量是一个只读变量，用来获取当前事务的时间戳。 - -### tidb_config - -作用域：SESSION - -默认值：空字符串 - -这个变量是一个只读变量，用来获取当前 TiDB Server 的配置信息。 - -### tidb_distsql_scan_concurrency - -作用域：SESSION | GLOBAL - -默认值：15 - -这个变量用来设置 scan 操作的并发度，AP 类应用适合较大的值，TP 类应用适合较小的值。 -对于 AP 类应用，最大值建议不要超过所有 TiKV 节点的 CPU 核数。 - -### tidb_index_lookup_size - -作用域：SESSION | GLOBAL - -默认值：20000 - -这个变量用来设置 index lookup 操作的 batch 大小，AP 类应用适合较大的值，TP 类应用适合较小的值。 - -### tidb_index_lookup_concurrency - -作用域：SESSION | GLOBAL - -默认值：4 - -这个变量用来设置 index lookup 操作的并发度，AP 类应用适合较大的值，TP 类应用适合较小的值。 - -### tidb_index_lookup_join_concurrency - -作用域：SESSION | GLOBAL - -默认值：4 - -这个变量用来设置 index lookup join 算法的并发度。 - -### tidb_hash_join_concurrency - -作用域：SESSION | GLOBAL - -默认值：5 - -这个变量用来设置 hash join 算法的并发度。 - -### tidb_index_serial_scan_concurrency - -作用域：SESSION | GLOBAL - -默认值：1 - -这个变量用来设置顺序 scan 操作的并发度，AP 类应用适合较大的值，TP 类应用适合较小的值。 - -### tidb_projection_concurrency - -作用域：SESSION | GLOBAL - -默认值：4 - -这个变量用来设置 Projection 算子的并发度。 - -### tidb_hashagg_partial_concurrency - -作用域：SESSION | GLOBAL - -默认值：4 - -这个变量用来设置并行 hash aggregation 算法 partial 阶段的执行并发度。对于聚合函数参数不为 distinct 的情况，HashAgg 分为 partial 和 final 阶段分别并行执行。 - -### tidb_hashagg_final_concurrency - -作用域：SESSION | GLOBAL - -默认值：4 - -这个变量用来设置并行 hash aggregation 算法 final 阶段的执行并发度。对于聚合函数参数不为 distinct 的情况，HashAgg 分为 partial 和 final 阶段分别并行执行。 - -### tidb_index_join_batch_size - -作用域：SESSION | GLOBAL - -默认值：25000 - -这个变量用来设置 index lookup join 操作的 batch 大小，AP 类应用适合较大的值，TP 类应用适合较小的值。 - -### tidb_skip_utf8_check - -作用域：SESSION | GLOBAL - -默认值：0 - -这个变量用来设置是否跳过 UTF-8 字符的验证。 -验证 UTF-8 字符需要消耗一定的性能，当可以确认输入的字符串为有效的 UTF-8 字符时，可以将其设置为 1。 - -### tidb_init_chunk_size - -作用域：SESSION | GLOBAL - -默认值：32 - -这个变量用来设置执行过程中初始 chunk 的行数。默认值是 32。 - -### tidb_max_chunk_size - -作用域：SESSION | GLOBAL - -默认值：1024 - -这个变量用来设置执行过程中一个 chunk 最大的行数。 - -### tidb_mem_quota_query - -作用域：SESSION - -默认值：32 GB - -这个变量用来设置一条查询语句的内存使用阈值。 -如果一条查询语句执行过程中使用的内存空间超过该阈值，会触发 TiDB 启动配置文件中 OOMAction 项所指定的行为。 - -### tidb_mem_quota_hashjoin - -作用域：SESSION - -默认值：32 GB - -这个变量用来设置 HashJoin 算子的内存使用阈值。 -如果 HashJoin 算子执行过程中使用的内存空间超过该阈值，会触发 TiDB 启动配置文件中 OOMAction 项所指定的行为。 - -### tidb_mem_quota_mergejoin - -作用域：SESSION - -默认值：32 GB - -这个变量用来设置 MergeJoin 算子的内存使用阈值。 -如果 MergeJoin 算子执行过程中使用的内存空间超过该阈值，会触发 TiDB 启动配置文件中 OOMAction 项所指定的行为。 - -### tidb_mem_quota_sort - -作用域：SESSION - -默认值：32 GB - -这个变量用来设置 Sort 算子的内存使用阈值。 -如果 Sort 算子执行过程中使用的内存空间超过该阈值，会触发 TiDB 启动配置文件中 OOMAction 项所指定的行为。 - -### tidb_mem_quota_topn - -作用域：SESSION - -默认值：32 GB - -这个变量用来设置 TopN 算子的内存使用阈值。 -如果 TopN 算子执行过程中使用的内存空间超过该阈值，会触发 TiDB 启动配置文件中 OOMAction 项所指定的行为。 - -### tidb_mem_quota_indexlookupreader - -作用域：SESSION - -默认值：32 GB - -这个变量用来设置 IndexLookupReader 算子的内存使用阈值。 - -如果 IndexLookupReader 算子执行过程中使用的内存空间超过该阈值，会触发 TiDB 启动配置文件中 OOMAction 项所指定的行为。 - -### tidb_mem_quota_indexlookupjoin - -作用域：SESSION - -默认值：32 GB - -这个变量用来设置 IndexLookupJoin 算子的内存使用阈值。 -如果 IndexLookupJoin 算子执行过程中使用的内存空间超过该阈值，会触发 TiDB 启动配置文件中 OOMAction 项所指定的行为。 - -### tidb_mem_quota_nestedloopapply - -作用域：SESSION - -默认值：32 GB - -这个变量用来设置 NestedLoopApply 算子的内存使用阈值。 -如果 NestedLoopApply 算子执行过程中使用的内存空间超过该阈值，会触发 TiDB 启动配置文件中 OOMAction 项所指定的行为。 - -### tidb_general_log - -作用域：SERVER - -默认值：0 - -这个变量用来设置是否在日志里记录所有的 SQL 语句。 - -### tidb_enable_streaming - -作用域：SESSION - -默认值：0 - -这个变量用来设置是否启用 Streaming。 - -### tidb_retry_limit - -作用域：SESSION | GLOBAL - -默认值：10 - -这个变量用来设置最大重试次数。一个事务执行中遇到可重试的错误（例如事务冲突、事务提交过慢或表结构变更）时，会根据该变量的设置进行重试。注意当 `tidb_retry_limit = 0` 时，也会禁用自动重试。 - -### tidb_disable_txn_auto_retry - -作用域：SESSION | GLOBAL - -默认值：on - -这个变量用来设置是否禁用显式事务自动重试，设置为 `on` 时，不会自动重试，如果遇到事务冲突需要在应用层重试。 - -如果将该变量的值设为 `off`，TiDB 将会自动重试事务，这样在事务提交时遇到的错误更少。需要注意的是，这样可能会导致数据更新丢失。 - -这个变量不会影响自动提交的隐式事务和 TiDB 内部执行的事务，它们依旧会根据 `tidb_retry_limit` 的值来决定最大重试次数。 - -是否需要禁用自动重试，请参考[重试的局限性](/dev/reference/transactions/transaction-optimistic.md#重试的局限性)。 - -### tidb_backoff_weight - -作用域：SESSION | GLOBAL - -默认值：2 - -这个变量用来给 TiDB 的 `backoff` 最大时间增加权重，即内部遇到网络或其他组件（TiKV、PD）故障等时，发送重试请求的最大重试时间。可以通过这个变量来调整最大重试时间，最小值为 1。 - -例如，TiDB 向 PD 取 TSO 的基础超时时间是 15 秒，当 `tidb_backoff_weight = 2` 时，取 TSO 的最大超时时间为：基础时间 * 2 等于 30 秒。 - -在网络环境较差的情况下，适当增大该变量值可以有效缓解因为超时而向应用端报错的情况；而如果应用端希望更快地接到报错信息，则应该尽量减小该变量的值。 - -### tidb_enable_table_partition - -作用域：SESSION - -默认值："auto" - -这个变量用来设置是否开启 TABLE PARTITION 特性。默认值 `auto` 表示开启 range partition 和 hash partion。`off` 表示关闭 TABLE PARTITION 的特性，此时语法还是会依旧兼容，只是建立的 partition table 实际上并不是真正的 partition table，而是和普通的 table 一样。`on` 表示开启，目前的作用和 `auto` 一样。 - -注意，目前 TiDB 只支持 range partition 和 hash partition。 - -### tidb_backoff_lock_fast - -作用域：SESSION | GLOBAL - -默认值：100 - -这个变量用来设置读请求遇到锁的 backoff 时间。 - -### tidb_ddl_reorg_worker_cnt - -作用域：GLOBAL - -默认值：16 - -这个变量用来设置 DDL 操作 re-organize 阶段的并发度。 - -### tidb_ddl_reorg_batch_size - -作用域：GLOBAL - -默认值：1024 - -这个变量用来设置 DDL 操作 re-organize 阶段的 batch size。比如 Add Index 操作，需要回填索引数据，通过并发 tidb_ddl_reorg_worker_cnt 个 worker 一起回填数据，每个 worker 以 batch 为单位进行回填。如果 Add Index 时有较多 Update 操作或者 Replace 等更新操作，batch size 越大，事务冲突的概率也会越大，此时建议调小 batch size 的值，最小值是 32。在没有事务冲突的情况下，batch size 可设为较大值，最大值是 10240，这样回填数据的速度更快，但是 TiKV 的写入压力也会变大。 - -### tidb_ddl_reorg_priority - -作用域：SESSION | GLOBAL - -默认值：PRIORITY_LOW - -这个变量用来设置 `ADD INDEX` 操作 re-organize 阶段的执行优先级，可设置为 PRIORITY_LOW/PRIORITY_NORMAL/PRIORITY_HIGH。 - -### tidb_ddl_error_count_limit - -作用域：GLOBAL - -默认值：512 - -这个变量用来控制 DDL 操作失败重试的次数。失败重试次数超过该参数的值后，会取消出错的 DDL 操作。 - -### tidb_max_delta_schema_count - -作用域：GLOBAL - -默认值：1024 - -这个变量用来设置缓存 schema 版本信息（对应版本修改的相关 table IDs）的个数限制，可设置的范围 100 - 16384。此变量在 2.1.18 及之后版本支持。 - -### tidb_force_priority - -作用域：SESSION - -默认值：`NO_PRIORITY` - -这个变量用于改变 TiDB server 上执行的语句的默认优先级。例如，你可以通过设置该变量来确保正在执行 OLAP 查询的用户优先级低于正在执行 OLTP 查询的用户。 - -可设置为 `NO_PRIORITY`、`LOW_PRIORITY`、`DELAYED` 或 `HIGH_PRIORITY`。 - -### tidb_opt_write_row_id - -作用域：SESSION - -默认值：0 - -这个变量用来设置是否允许 insert、replace 和 update 操作 `_tidb_rowid` 列，默认是不允许操作。该选项仅用于 TiDB 工具导数据时使用。 - -### SHARD_ROW_ID_BITS - -对于 PK 非整数或没有 PK 的表，TiDB 会使用一个隐式的自增 rowid，大量 `INSERT` 时会把数据集中写入单个 Region，造成写入热点。 - -通过设置 `SHARD_ROW_ID_BITS`，可以把 rowid 打散写入多个不同的 Region，缓解写入热点问题。但是设置的过大会造成 RPC 请求数放大，增加 CPU 和网络开销。 - -- `SHARD_ROW_ID_BITS = 4` 表示 16 个分片 -- `SHARD_ROW_ID_BITS = 6` 表示 64 个分片 -- `SHARD_ROW_ID_BITS = 0` 表示默认值 1 个分片 - -语句示例： - -- `CREATE TABLE`：`CREATE TABLE t (c int) SHARD_ROW_ID_BITS = 4;` -- `ALTER TABLE`：`ALTER TABLE t SHARD_ROW_ID_BITS = 4;` - -### tidb_slow_log_threshold - -作用域：SESSION - -默认值：300 - -输出慢日志的耗时阈值。当查询大于这个值，就会当做是一个慢查询，输出到慢查询日志。默认为 300ms。 - -示例： - -{{< copyable "sql" >}} - -```sql -set tidb_slow_log_threshold = 200; -``` - -### tidb_query_log_max_len - -作用域：SESSION - -默认值：2048 (bytes) - -最长的 SQL 输出长度。当语句的长度大于 query-log-max-len，将会被截断输出。 - -示例： - -{{< copyable "sql" >}} - -```sql -set tidb_query_log_max_len = 20; -``` - -### tidb_txn_mode - -作用域：SESSION | GLOBAL - -默认值："pessimistic" - -这个变量用于设置事务模式。TiDB v3.0 支持了悲观事务，自 v3.0.8 开始，默认使用[悲观事务模式](/dev/reference/transactions/transaction-pessimistic.md)。 - -但如果从 3.0.7 及之前的版本升级到 >= 3.0.8 的版本，不会改变默认事务模型，即**只有新创建的集群才会默认使用悲观事务模型**。 - -将该变量设置为 "optimistic" 或 "" 时，将会使用[乐观事务模式](/dev/reference/transactions/transaction-optimistic.md)。 - -### tidb_constraint_check_in_place - -作用域：SESSION | GLOBAL - -默认值：0 - -TiDB 支持乐观事务模型，即在执行写入时，假设不存在冲突。冲突检查是在最后 commit 提交时才去检查。这里的检查指 unique key 检查。 - -这个变量用来控制是否每次写入一行时就执行一次唯一性检查。注意，开启该变量后，在大批量写入场景下，对性能会有影响。 - -示例： - -默认关闭 tidb_constraint_check_in_place 时的行为： - -{{< copyable "sql" >}} - -```sql -create table t (i int key); -insert into t values (1); -begin; -insert into t values (1); -``` - -``` -Query OK, 1 row affected -``` - -commit 时才去做检查： - -{{< copyable "sql" >}} - -```sql -commit; -``` - -``` -ERROR 1062 : Duplicate entry '1' for key 'PRIMARY' -``` - -打开 tidb_constraint_check_in_place 后： - -{{< copyable "sql" >}} - -```sql -set @@tidb_constraint_check_in_place=1; -begin; -insert into t values (1); -``` - -``` -ERROR 1062 : Duplicate entry '1' for key 'PRIMARY' -``` - -### tidb_check_mb4_value_in_utf8 - -作用域：SERVER - -默认值：1 - -这个变量用来设置是否开启对字符集为 UTF8 类型的数据做合法性检查，默认值 `1` 表示开启检查。这个默认行为和 MySQL 是兼容的。 - -注意，如果是旧版本升级时，可能需要关闭该选项，否则由于旧版本（v2.1.1 以及之前）没有对数据做合法性检查，所以旧版本写入非法字符串是可以写入成功的，但是新版本加入合法性检查后会报写入失败。具体可以参考[升级后常见问题](/dev/faq/upgrade.md)。 - -### tidb_opt_insubq_to_join_and_agg - -作用域：SESSION | GLOBAL - -默认值：1 - -这个用来设置是否开启优化规则：将子查询转成 join 和 aggregation。 - -示例： - -打开这个优化规则后，会将下面子查询做如下变化： - -{{< copyable "sql" >}} - -```sql -select * from t where t.a in (select aa from t1); -``` - -将子查询转成 join 如下： - -{{< copyable "sql" >}} - -```sql -select * from t, (select aa from t1 group by aa) tmp_t where t.a = tmp_t.aa; -``` - -如果 t1 在列 aa 上有 unique 且 not null 的限制，可以直接改写为如下，不需要添加 aggregation。 - -{{< copyable "sql" >}} - -```sql -select * from t, t1 where t.a=t1.a; -``` - -### tidb_opt_correlation_threshold - -作用域：SESSION | GLOBAL - -默认值：0.9 - -这个变量用来设置优化器启用交叉估算 row count 方法的阈值。如果列和 handle 列之间的顺序相关性超过这个阈值，就会启用交叉估算方法。 - -交叉估算方法可以简单理解为，利用这个列的直方图来估算 handle 列需要扫的行数。 - -### tidb_opt_correlation_exp_factor - -作用域：SESSION | GLOBAL - -默认值：1 - -当交叉估算方法不可用时，会采用启发式估算方法。这个变量用来控制启发式方法的行为。当值为 0 时不用启发式估算方法，大于 0 时，该变量值越大，启发式估算方法越倾向 index scan，越小越倾向 table scan。 - -### tidb_enable_window_function - -作用域：SESSION | GLOBAL - -默认值：1 - -这个变量用来控制是否开启窗口函数的支持。默认值 1 代表开启窗口函数的功能。 - -由于窗口函数会使用一些保留关键字，可能导致原先可以正常执行的 SQL 语句在升级 TiDB 后无法被解析语法，此时可以将 `tidb_enable_window_function` 设置为 `0`。 - -### tidb_slow_query_file - -作用域：SESSION - -默认值："" - -查询 `INFORMATION_SCHEMA.SLOW_QUERY` 只会解析配置文件中 `slow-query-file` 设置的慢日志文件名，默认是 "tidb-slow.log"。但如果想要解析其他的日志文件，可以通过设置 session 变量 `tidb_slow_query_file` 为具体的文件路径，然后查询 `INFORMATION_SCHEMA.SLOW_QUERY` 就会按照设置的路径去解析慢日志文件。更多详情可以参考 [SLOW_QUERY 文档](/dev/how-to/maintain/identify-abnormal-queries/identify-slow-queries.md)。 - -### tidb_enable_fast_analyze - -作用域：SESSION | GLOBAL - -默认值：0 - -这个变量用来控制是否启用统计信息快速分析功能。默认值 0 表示不开启。 - -快速分析功能开启后，TiDB 会随机采样约 10000 行的数据来构建统计信息。因此在数据分布不均匀或者数据量比较少的情况下，统计信息的准确度会比较低。这可能导致执行计划不优，比如选错索引。如果可以接受普通 `ANALYZE` 语句的执行时间，则推荐关闭快速分析功能。 - -### tidb_expensive_query_time_threshold - -作用域：SERVER - -默认值：60 - -这个变量用来控制打印 expensive query 日志的阈值时间，单位是秒，默认值是 60 秒。expensive query 日志和慢日志的差别是，慢日志是在语句执行完后才打印，expensive query 日志可以把正在执行中的语句且执行时间超过阈值的语句及其相关信息打印出来。 - -### tidb_wait_split_region_finish - -作用域：SESSION - -默认值：1 - -由于打散 region 的时间可能比较长，主要由 PD 调度以及 TiKV 的负载情况所决定。这个变量用来设置在执行 `SPLIT REGION` 语句时，是否同步等待所有 region 都打散完成后再返回结果给客户端。默认 1 代表等待打散完成后再返回结果。0 代表不等待 Region 打散完成就返回。 - -需要注意的是，在 region 打散期间，对正在打散 region 上的写入和读取的性能会有一定影响，对于批量写入，导数据等场景，还是建议等待 region 打散完成后再开始导数据。 - -### tidb_wait_split_region_timeout - -作用域：SESSION - -默认值：300 - -这个变量用来设置 `SPLIT REGION` 语句的执行超时时间，单位是秒，默认值是 300 秒，如果超时还未完成，就返回一个超时错误。 - -### tidb_scatter_region - -作用域：GLOBAL - -默认值：0 - -TiDB 默认会在建表时为新表分裂 Region。开启该变量后，会在建表语句执行时，同步打散刚分裂出的 Region。适用于批量建表后紧接着批量写入数据，能让刚分裂出的 Region 先在 TiKV 分散而不用等待 PD 进行调度。为了保证后续批量写入数据的稳定性，建表语句会等待打散 Region 完成后再返回建表成功，建表语句执行时间会是关闭该变量的数倍。 - -### tidb_allow_remove_auto_inc 从 v2.1.18 和 v3.0.4 版本开始引入 - -作用域：SESSION - -默认值：0 - -这个变量用来控制是否允许通过 `ALTER TABLE MODIFY` 或 `ALTER TABLE CHANGE` 来移除某个列的 `AUTO_INCREMENT` 属性。默认为不允许。 - -### tidb_enable_stmt_summary 从 v3.0.4 版本开始引入 - -作用域：SESSION | GLOBAL - -默认值：0 - -这个变量用来控制是否开启 statement summary 功能。如果开启，SQL 的耗时等执行信息将被记录到系统表 `performance_schema.events_statements_summary_by_digest` 中，用于定位和排查 SQL 性能问题。 diff --git a/dev/reference/configuration/tikv-server/configuration-file.md b/dev/reference/configuration/tikv-server/configuration-file.md deleted file mode 100644 index 77cfd2555a35..000000000000 --- a/dev/reference/configuration/tikv-server/configuration-file.md +++ /dev/null @@ -1,1092 +0,0 @@ ---- -title: TiKV 配置文件描述 -category: reference ---- - -# TiKV 配置文件描述 - -TiKV 配置文件比命令行参数支持更多的选项。你可以在 [etc/config-template.toml](https://github.com/tikv/tikv/blob/master/etc/config-template.toml) 找到默认值的配置文件，重命名为 config.toml 即可。 - -本文档只阐述未包含在命令行参数中的参数，命令行参数参见 [TiKV 配置参数](/dev/reference/configuration/tikv-server/configuration.md)。 - - -### `status-thread-pool-size` - -+ Http API 服务的工作线程数量。 -+ 默认值：1 -+ 最小值：1 - -### `grpc-compression-type` - -+ gRPC 消息的压缩算法，取值：none， deflate， gzip。 -+ 默认值：none - -### `grpc-concurrency` - -+ gRPC 工作线程的数量。 -+ 默认值：4 -+ 最小值：1 - -### `grpc-concurrent-stream` - -+ 一个 gRPC 链接中最多允许的并发请求数量。 -+ 默认值：1024 -+ 最小值：1 - -### `server.grpc-raft-conn-num` - -+ tikv 节点之间用于 raft 通讯的链接最大数量。 -+ 默认值：10 -+ 最小值：1 - -### `server.grpc-stream-initial-window-size` - -+ gRPC stream 的 window 大小。 -+ 默认值：2MB -+ 单位：KB|MB|GB -+ 最小值：1KB - -### `server.grpc-keepalive-time` - -+ gRPC 发送 keep alive ping 消息的间隔时长。 -+ 默认值：10s -+ 最小值：1s - -### `server.grpc-keepalive-timeout` - -+ 关闭 gRPC 链接的超时时长。 -+ 默认值：3s -+ 最小值：1s - -### `server.concurrent-send-snap-limit` - -+ 同时发送 snapshot 的最大个数，默认值：32 -+ 默认值：32 -+ 最小值：1 - -### `server.concurrent-recv-snap-limit` - -+ 同时接受 snapshot 的最大个数，默认值：32 -+ 默认值：32 -+ 最小值：1 - -### `server.end-point-recursion-limit` - -+ endpoint 下推查询请求解码消息时，最多允许的递归层数。 -+ 默认值：1000 -+ 最小值：1 - -### `server.end-point-request-max-handle-duration` - -+ endpoint 下推查询请求处理任务最长允许的时长。 -+ 默认值：60s -+ 最小值：1s - -### `server.snap-max-write-bytes-per-sec` - -+ 处理 snapshot 时最大允许使用的磁盘带宽 -+ 默认值：1000MB -+ 单位：KB|MB|GB -+ 最小值：1KB - -## readpool.storage - -存储线程池相关的配置项。 - -### `high-concurrency` - -+ 处理高优先级读请求的线程池线程数量。 -+ 默认值：4 -+ 最小值：1 - -### `normal-concurrency` - -+ 处理普通优先级读请求的线程池线程数量。 -+ 默认值：4 -+ 最小值：1 - -### `low-concurrency` - -+ 处理低优先级读请求的线程池线程数量。 -+ 默认值：4 -+ 最小值：1 - -### `max-tasks-per-worker-high` - -+ 高优先级线程池中单个线程允许积压的最大任务数量，超出后会返回 Server Is Busy。 -+ 默认值：2000 -+ 最小值：2 - -### `max-tasks-per-worker-normal` - -+ 普通优先级线程池中单个线程允许积压的最大任务数量，超出后会返回 Server Is Busy。 -+ 默认值：2000 -+ 最小值：2 - -### `max-tasks-per-worker-low` - -+ 低优先级线程池中单个线程允许积压的最大任务数量，超出后会返回 Server Is Busy。 -+ 默认值：2000 -+ 最小值：2 - -### `stack-size` - -+ Storage 读线程池中线程的栈大小。 -+ 默认值：10MB -+ 单位：KB|MB|GB -+ 最小值：2MB - -## readpool.coprocessor - -协处理器线程池相关的配置项。 - -### `high-concurrency` - -+ 处理高优先级 Coprocessor 请求（如点查）的线程池线程数量。 -+ 默认值：CPU * 0.8 -+ 最小值：1 - -### `normal-concurrency` - -+ 处理普通优先级 Coprocessor 请求的线程池线程数量。 -+ 默认值：CPU * 0.8 -+ 最小值：1 - -### `low-concurrency` - -+ 处理低优先级 Coprocessor 请求（如扫表）的线程池线程数量。 -+ 默认值：CPU * 0.8 -+ 最小值：1 - -### `max-tasks-per-worker-high` - -+ 高优先级线程池中单个线程允许积压的任务数量，超出后会返回 Server Is Busy。 -+ 默认值：2000 -+ 最小值：2 - -### `max-tasks-per-worker-normal` - -+ 普通优先级线程池中单个线程允许积压的任务数量，超出后会返回 Server Is Busy。 -+ 默认值：2000 -+ 最小值：2 - -### `max-tasks-per-worker-low` - -+ 低优先级线程池中单个线程允许积压的任务数量，超出后会返回 Server Is Busy。 -+ 默认值：2000 -+ 最小值：2 - -### `stack-size` - -Coprocessor 线程池中线程的栈大小，默认值：10，单位：KiB|MiB|GiB。 - -+ 默认值：10MB -+ 单位：KB|MB|GB -+ 最小值：2MB - -## storage - -存储相关的配置项。 - -### `scheduler-notify-capacity` - -+ scheduler 一次获取最大消息个数 -+ 默认值：10240 -+ 最小值：1 - -### `scheduler-concurrency` - -+ scheduler 内置一个内存锁机制，防止同时对一个 key 进行操作。每个 key hash 到不同的槽。 -+ 默认值：2048000 -+ 最小值：1 - -### `scheduler-worker-pool-size` - -+ scheduler 线程个数，主要负责写入之前的事务一致性检查工作。 -+ 默认值：4 -+ 最小值：1 - -### `scheduler-pending-write-threshold` - -+ 写入数据队列的最大值，超过该值之后对于新的写入 TiKV 会返回 Server Is Busy 错误。 -+ 默认值：100MB -+ 单位: MB|GB - -## raftstore - -raftstore 相关的配置项。 - -### `sync-log` - -+ 数据、log 落盘是否 sync，注意：设置成 false 可能会丢数据。 -+ 默认值：true - -### `prevote` - -+ 开启 Prevote 的开关，开启有助于减少隔离恢复后对系统造成的抖动。 -+ 默认值：true - -### `raftdb-path` - -+ raft 库的路径，默认存储在 storage.data-dir/raft 下。 -+ 默认值："" - -### `raft-base-tick-interval` - -+ 状态机 tick 一次的间隔时间。 -+ 默认值：1s -+ 最小值：大于 0 - -### `raft-heartbeat-ticks` - -+ 发送心跳时经过的 tick 个数，即每隔 raft-base-tick-interval * raft-heartbeat-ticks 时间发送一次心跳。 -+ 默认值：2 -+ 最小值：大于 0 - -### `raft-election-timeout-ticks` - -+ 发起选举时经过的 tick 个数，即如果处于无主状态，大约经过 raft-base-tick-interval * raft-election-timeout-ticks 时间以后发起选举。 -+ 默认值：10 -+ 最小值：raft-heartbeat-ticks - -### `raft-min-election-timeout-ticks` - -+ 发起选举时至少经过的 tick 个数，如果为 0，则表示使用 raft-election-timeout-ticks，不能比 raft-election-timeout-ticks 小。 -+ 默认值：0 -+ 最小值：0 - -### `raft-max-election-timeout-ticks` - -+ 发起选举时最多经过的 tick 个数，如果为 0，则表示使用 raft-election-timeout-ticks * 2。 -+ 默认值：0 -+ 最小值：0 - -### `raft-max-size-per-message` - -+ 产生的单个消息包的大小限制，软限制。 -+ 默认值：1MB -+ 最小值：0 -+ 单位：MB - -### `raft-max-inflight-msgs` - -+ 待确认日志个数的数量，如果超过这个数量将会减缓发送日志的个数。 -+ 默认值：256 -+ 最小值：大于0 - -### `raft-entry-max-size` - -+ 单个日志最大大小，硬限制。 -+ 默认值：8MB -+ 最小值：0 -+ 单位：MB|GB - -### `raft-log-gc-tick-interval` - -+ 删除 raft 日志的轮询任务调度间隔时间，0 表示不启用。 -+ 默认值：10s -+ 最小值：0 - -### `raft-log-gc-threshold` - -+ 允许残余的 raft 日志个数，这是一个软限制。 -+ 默认值：50 -+ 最小值：1 - -### `raft-log-gc-count-limit` - -+ 允许残余的 raft 日志个数，这是一个硬限制。默认值为按照每个日志 1MB 而计算出来的 3/4 region 大小所能容纳的日志个数。 -+ 最小值：0 - -### `raft-log-gc-size-limit` - -+ 允许残余的 raft 日志大小，这是一个硬限制，默认为 region 大小的 3/4。 -+ 最小值：大于 0 - -### `raft-entry-cache-life-time` - -+ 内存中日志 cache 允许的最长残留时间。 -+ 默认值：30s -+ 最小值：0 - -### `raft-reject-transfer-leader-duration` - -+ 新节点保护时间，控制迁移 leader 到新加节点的最小时间，设置过小容易导致迁移 leader 失败。 -+ 默认值：3s -+ 最小值：0 - -### `raftstore.hibernate-regions` (**实验特性**) - -+ 打开或关闭静默 Region。打开后，如果 Region 长时间处于非活跃状态，即被自动设置为静默状态。静默状态的 Region 可以降低 Leader 和 Follower 之间心跳信息的系统开销。可以通过 `raftstore.peer-stale-state-check-interval` 调整 Leader 和 Follower 之间的心跳间隔。 -+ 默认值：true - -### `raftstore.peer-stale-state-check-interval` - -+ 修改对 Region 的状态检查间隔时间。 -+ 默认值：5 min - -### `split-region-check-tick-interval` - -+ 检查 region 是否需要分裂的时间间隔，0 表示不启用。 -+ 默认值：10s -+ 最小值：0 - -### `region-split-check-diff` - -+ 允许 region 数据超过指定大小的最大值，默认为 region 大小的 1/16。 -+ 最小值：0 - -### `region-compact-check-interval` - -+ 检查是否需要人工触发 rocksdb compaction 的时间间隔，0 表示不启用。 -+ 默认值：5m -+ 最小值：0 - -### `clean-stale-peer-delay` - -+ 延迟删除过期副本数据的时间。 -+ 默认值：10m -+ 最小值：0 - -### `region-compact-check-step` - -+ 每轮校验人工 compaction 时，一次性检查的 region 个数。 -+ 默认值：100 -+ 最小值：0 - -### `region-compact-min-tombstones` - -+ 触发 rocksdb compaction 需要的 tombstone 个数。 -+ 默认值：10000 -+ 最小值：0 - -### `region-compact-tombstones-percent` - -+ 触发 rocksdb compaction 需要的 tombstone 所占比例。 -+ 默认值：30 -+ 最小值：1 -+ 最大值：100 - -### `pd-heartbeat-tick-interval` - -+ 触发 region 对 PD 心跳的时间间隔，0 表示不启用。 -+ 默认值：1m -+ 最小值：0 - -### `pd-store-heartbeat-tick-interval` - -+ 触发 store 对 PD 心跳的时间间隔，0 表示不启用。 -+ 默认值：10s -+ 最小值：0 - -### `snap-mgr-gc-tick-interval` - -+ 触发回收过期 snapshot 文件的时间间隔，0 表示不启用。 -+ 默认值：5s -+ 最小值：0 - -### `snap-gc-timeout` - -+ snapshot 文件的最长保存时间。 -+ 默认值：4h -+ 最小值：0 - -### `lock-cf-compact-interval` - -+ 触发对 lock CF compact 检查的时间间隔。 -+ 默认值：10m -+ 最小值：0 - -### `lock-cf-compact-bytes-threshold` - -+ 触发对 lock CF 进行 compact 的大小。 -+ 默认值：256MB -+ 最小值：0 -+ 单位：MB - -### `notify-capacity` - -+ region 消息队列的最长长度。 -+ 默认值：40960 -+ 最小值：0 - -### `messages-per-tick` - -+ 每轮处理的消息最大个数。 -+ 默认值：4096 -+ 最小值：0 - -### `max-peer-down-duration` - -+ 副本允许的最长未响应时间，超过将被标记为 down，后续 PD 会尝试将其删掉。 -+ 默认值：5m -+ 最小值：0 - -### `max-leader-missing-duration` - -+ 允许副本处于无主状态的最长时间，超过将会向 PD 校验自己是否已经被删除。 -+ 默认值：2h -+ 最小值：> abnormal-leader-missing-duration - -### `abnormal-leader-missing-duration` - -+ 允许副本处于无主状态的时间，超过将视为异常，标记在 metrics 和日志中。 -+ 默认值：10m -+ 最小值：> peer-stale-state-check-interval - -### `peer-stale-state-check-interval` - -+ 触发检验副本是否处于无主状态的时间间隔。 -+ 默认值：5m -+ 最小值：> 2 * election-timeout - -### `leader-transfer-max-log-lag` - -+ 尝试转移领导权时被转移者允许的最大日志缺失个数。 -+ 默认值：10 -+ 最小值：10 - -### `snap-apply-batch-size` - -+ 当导入 snapshot 文件需要写数据时，内存写缓存的大小 -+ 默认值：10MB -+ 最小值：0 -+ 单位：MB - -### `consistency-check-interval` - -+ 触发一致性检查的时间间隔, 0 表示不启用。 -+ 默认值：0s -+ 最小值：0 - -### `raft-store-max-leader-lease` - -+ region 主可信任期的最长时间。 -+ 默认值：9s -+ 最小值：0 - -### `right-derive-when-split` - -+ 为 true 时，以最大分裂 key 为起点的 region 复用原 region 的 key；否则以原 region 起点 key 作为起点的 region 复用原 region 的 key。 -+ 默认值：true - -### `allow-remove-leader` - -+ 允许删除主开关。 -+ 默认值：false - -### `merge-max-log-gap` - -+ 进行 merge 时，允许的最大日志缺失个数。 -+ 默认值：10 -+ 最小值：> raft-log-gc-count-limit - -### `merge-check-tick-interval` - -+ 触发 merge 完成检查的时间间隔。 -+ 默认值：10s -+ 最小值：大于 0 - -### `use-delete-range` - -+ 开启 rocksdb delete_range 接口删除数据的开关。 -+ 默认值：false - -### `cleanup-import-sst-interval` - -+ 触发检查过期 SST 文件的时间间隔，0 表示不启用。 -+ 默认值：10m -+ 最小值：0 - -### `local-read-batch-size` - -+ 一轮处理读请求的最大个数。 -+ 默认值：1024 -+ 最小值：大于 0 - -### `apply-max-batch-size` - -+ 一轮处理数据落盘的最大请求个数。 -+ 默认值：1024 -+ 最小值：大于 0 - -### `apply-pool-size` - -+ 处理数据落盘的线程池线程数。 -+ 默认值：2 -+ 最小值：大于 0 - -### `store-max-batch-size` - -+ 一轮处理的最大请求个数。 -+ 默认值：1024 -+ 最小值：大于 0 - -### `store-pool-size` - -+ 处理 raft 的线程池线程数。 -+ 默认值：2 -+ 最小值：大于 0 - -### `future-poll-size` - -+ 驱动 future 的线程池线程数。 -+ 默认值：1 -+ 最小值：大于 0 - -## coprocessor - -协处理器相关的配置项。 - -### `split-region-on-table` - -+ 开启按 table 分裂 Region的开关，建议仅在 TiDB 模式下使用。 -+ 默认值：true - -### `batch-split-limit` - -+ 批量分裂 Region 的阈值，调大该值可加速分裂 Region。 -+ 默认值：10 -+ 最小值：1 - -### `region-max-size` - -+ Region 容量空间最大值，超过时系统分裂成多个 Region。 -+ 默认值：144MB -+ 单位：KB|MB|GB - -### `region-split-size` - -+ 分裂后新 Region 的大小，此值属于估算值。 -+ 默认值：96MB -+ 单位：KB|MB|GB - -### `region-max-keys` - -+ Region 最多允许的 key 的个数，超过时系统分裂成多个 Region。 -+ 默认值：1440000 - -### `region-split-keys` - -+ 分裂后新 Region 的 key 的个数，此值属于估算值。 -+ 默认值：960000 - -## rocksdb - -rocksdb 相关的配置项。 - -### `max-background-jobs` - -+ RocksDB 后台线程个数。 -+ 默认值：8 -+ 最小值：1 - -### `max-sub-compactions` - -+ RocksDB 进行 subcompaction 的并发个数。 -+ 默认值：1 -+ 最小值：1 - -### `max-open-files` - -+ RocksDB 可以打开的文件总数。 -+ 默认值：40960 -+ 最小值：-1 - -### `max-manifest-file-size` - -+ RocksDB Manifest 文件最大大小。 -+ 默认值：128MB -+ 最小值：0 -+ 单位：B|KB|MB|GB - -### `create-if-missing` - -+ 自动创建 DB 开关。 -+ 默认值：true - -### `wal-recovery-mode` - -+ WAL 恢复模式，取值：0（TolerateCorruptedTailRecords），1（AbsoluteConsistency），2（PointInTimeRecovery），3（SkipAnyCorruptedRecords）。 -+ 默认值：2 -+ 最小值：0 -+ 最大值：3 - -### `wal-dir` - -+ WAL 存储目录，默认：“tmp/tikv/store”。 -+ 默认值：/tmp/tikv/store - -### `wal-ttl-seconds` - -+ 归档 WAL 生存周期，超过该值时，系统会删除相关 WAL。 -+ 默认值：0 -+ 最小值：0 -+ 单位：秒 - -### `wal-size-limit` - -+ 归档 WAL 大小限制，超过该值时，系统会删除相关 WAL。 -+ 默认值：0 -+ 最小值：0 -+ 单位：B|KB|MB|GB - -### `enable-statistics` - -+ 开启自动优化 Rate LImiter 的配置的开关。 -+ 默认值：false - -### `stats-dump-period` - -+ 开启 Pipelined Write 的开关。 -+ 默认值：true - -### `compaction-readahead-size` - -+ 异步 Sync 限速速率。 -+ 默认值：0 -+ 最小值：0 -+ 单位：B|KB|MB|GB - -### `writable-file-max-buffer-size` - -+ WritableFileWrite 所使用的最大的 buffer 大小。 -+ 默认值：1MB -+ 最小值：0 -+ 单位：B|KB|MB|GB - -### `use-direct-io-for-flush-and-compaction` - -+ flush 或者 compaction 开启 DirectIO 的开关。 -+ 默认值：false - -### `rate-bytes-per-sec` - -+ Rate Limiter 限制速率。 -+ 默认值：0 -+ 最小值：0 -+ 单位：Bytes - -### `rate-limiter-mode` - -+ Rate LImiter 模式，取值：1（ReadOnly），2（WriteOnly），3（AllIo）。 -+ 默认值：2 -+ 最小值：1 -+ 最大值：3 - -### `auto-tuned` - -+ 开启自动优化 Rate LImiter 的配置的开关。 -+ 默认值：false - -### `enable-pipelined-write` - -+ 开启 Pipelined Write 的开关。 -+ 默认值：true - -### `bytes-per-sync` - -+ 异步 Sync 限速速率。 -+ 默认值：1MB -+ 最小值：0 -+ 单位：B|KB|MB|GB - -### `wal-bytes-per-sync` - -+ WAL Sync 限速速率，默认：512KB。 -+ 默认值：512KB -+ 最小值：0 -+ 单位：B|KB|MB|GB - -### `info-log-max-size` - -+ Info 日志的最大大小。 -+ 默认值：1GB -+ 最小值：0 -+ 单位：B|KB|MB|GB - -### `info-log-roll-time` - -+ 日志截断间隔时间，如果为0则不截断。 -+ 默认值：0 - -### `info-log-keep-log-file-num` - -+ 保留日志文件最大个数。 -+ 默认值：10 -+ 最小值：0 - -### `info-log-dir` - -+ 日志存储目录。 -+ 默认值："" - -## rocksdb.titan - -Titan 相关的配置项。 - -### `enabled` - -+ 开启 Titan 开关。 -+ 默认值：false - -### `dirname` - -+ Titan Blob 文件存储目录。 -+ 默认值：titandb - -### `disable-gc` - -+ 关闭 Titan 对 Blob 文件的 GC 的开关。 -+ 默认值：false - -### `max-background-gc` - -+ Titan 后台 GC 的线程个数。 -+ 默认值：1 -+ 最小值：1 - -## rocksdb.defaultcf - -rocksdb defaultcf 相关的配置项。 - -### `block-size` - -+ rocksdb block size。 -+ 默认值：64KB -+ 最小值：1KB -+ 单位：KB|MB|GB - -### `block-cache-size` - -+ rocksdb block cache size。 -+ 默认值：机器总内存 / 4 -+ 最小值：0 -+ 单位：KB|MB|GB - -### `disable-block-cache` - -+ 开启 block cache 开关。 -+ 默认值：false - -### `cache-index-and-filter-blocks` - -+ 开启 缓存 index 和 filter 的开关。 -+ 默认值：true - -### `pin-l0-filter-and-index-blocks` - -+ 是否 pin 住 L0 的 index 和 filter。 -+ 默认值：true - -### `use-bloom-filter` - -+ 开启 bloom filter 的开关。 -+ 默认值：true - -### `optimize-filters-for-hits` - -+ 开启优化 filter 的命中率的开关。 -+ 默认值：true - -### `whole_key_filtering` - -+ 开启将整个 key 放到 bloom filter 中的开关。 -+ 默认值：true - -### `bloom-filter-bits-per-key` - -bloom filter 为每个 key 预留的长度。 - -+ 默认值：10 -+ 单位：字节 - -### `block-based-bloom-filter` - -+ 开启每个 block 建立 bloom filter 的开关。 -+ 默认值：false - -### `read-amp-bytes-per-bit` - -+ 开启读放大统计的开关，0：不开启，> 0 开启。 -+ 默认值：0 -+ 最小值：0 - -### `compression-per-level` - -+ 每一层默认压缩算法，默认：前两层为 No，后面 5 层为 lz4。 -+ 默认值：["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"] - -### `write-buffer-size` - -+ memtable 大小。 -+ 默认值：128MB -+ 最小值：0 -+ 单位：KB|MB|GB - -### `max-write-buffer-number` - -+ 最大 memtable 个数。 -+ 默认值：5 -+ 最小值：0 - -### `min-write-buffer-number-to-merge` - -+ 触发 flush 的最小 memtable 个数。 -+ 默认值：1 -+ 最小值：0 - -### `max-bytes-for-level-base` - -+ base level (L1) 最大字节数，一般设置为 memtable 大小 4 倍。 -+ 默认值：512MB -+ 最小值：0 -+ 单位：KB|MB|GB - -### `target-file-size-base` - -+ base level 的目标文件大小。 -+ 默认值：8MB -+ 最小值：0 -+ 单位：KB|MB|GB - -### `level0-file-num-compaction-trigger` - -+ 触发 compaction 的 L0 文件最大个数。 -+ 默认值：4 -+ 最小值：0 - -### `level0-slowdown-writes-trigger` - -+ 触发 write stall 的 L0 文件最大个数。 -+ 默认值：20 -+ 最小值：0 - -### `level0-stop-writes-trigger` - -+ 完全阻停写入的 L0 文件最大个数。 -+ 默认值：36 -+ 最小值：0 - -### `max-compaction-bytes` - -+ 一次 compaction 最大写入字节数，默认 2GB。 -+ 默认值：2GB -+ 最小值：0 -+ 单位：KB|MB|GB - -### `compaction-pri` - -Compaction 优先类型，默认：3（MinOverlappingRatio），0（ByCompensatedSize）， -1（OldestLargestSeqFirst），2（OldestSmallestSeqFirst）。 - -+ 默认值：3 - -### `dynamic-level-bytes` - -+ 开启 dynamic level bytes 优化的开关。 -+ 默认值：true - -### `num-levels` - -+ RocksDB 文件最大层数。 -+ 默认值：7 - -### `max-bytes-for-level-multiplier` - -+ 每一层的默认放大倍数。 -+ 默认值：10 - -### `rocksdb.defaultcf.compaction-style` - -+ Compaction 方法，可选值为 level，universal。 -+ 默认值：level - -### `disable-auto-compactions` - -+ 开启自动 compaction 的开关。 -+ 默认值：false - -### `soft-pending-compaction-bytes-limit` - -+ pending compaction bytes 的软限制。 -+ 默认值：64GB -+ 单位：KB|MB|GB - -### `hard-pending-compaction-bytes-limit` - -+ pending compaction bytes 的硬限制。 -+ 默认值：256GB -+ 单位：KB|MB|GB - -## rocksdb.defaultcf.titan - -rocksdb defaultcf titan 相关的配置项。 - -### `min-blob-size` - -+ 最小存储在 Blob 文件中 value 大小，低于该值的 value 还是存在 LSM-Tree 中。 -+ 默认值：1KB -+ 最小值：0 -+ 单位：KB|MB|GB - -### `blob-file-compression` - -+ Blob 文件所使用的压缩算法，可选值：no, snappy, zlib, bzip2, lz4, lz4hc, zstd。 -+ 默认值：lz4 - -### `blob-cache-size` - -+ Blob 文件的 cache 大小，默认：0GB。 -+ 默认值：0GB -+ 最小值：0 -+ 单位：KB|MB|GB - -### `min-gc-batch-size` - -+ 做一次 GC 所要求的最低 Blob 文件大小总和。 -+ 默认值：16MB -+ 最小值：0 -+ 单位：KB|MB|GB - -### `max-gc-batch-size` - -+ 做一次 GC 所要求的最高 Blob 文件大小总和。 -+ 默认值：64MB -+ 最小值：0 -+ 单位：KB|MB|GB - -### `discardable-ratio` - -+ Blob 文件 GC 的触发比例，如果某 Blob 文件中的失效 value 的比例高于该值才可能被 GC 选中。 -+ 默认值：0.5 -+ 最小值：0 -+ 最大值：1 - -### `sample-ratio` - -+ 进行 GC 时，对 Blob 文件进行采样时读取数据占整个文件的比例。 -+ 默认值：0.1 -+ 最小值：0 -+ 最大值：1 - -### `merge-small-file-threshold` - -+ Blob 文件的大小小于该值时，无视 discardable-ratio 仍可能被 GC 选中。 -+ 默认值：8MB -+ 最小值：0 -+ 单位：KB|MB|GB - -## rocksdb.writecf - -rocksdb writecf 相关的配置项。 - -### `block-cache-size` - -+ block cache size。 -+ 默认值：机器总内存 * 15% -+ 单位：MB|GB - -### `optimize-filters-for-hits` - -+ 开启优化 filter 的命中率的开关。 -+ 默认值：false - -### `whole-key-filtering` - -+ 开启将整个 key 放到 bloom filter 中的开关。 -+ 默认值：false - -## rocksdb.lockcf - -rocksdb lockcf 相关配置项。 - -### `block-cache-size` - -+ block cache size。 -+ 默认值：机器总内存 * 2% -+ 单位：MB|GB - -### `optimize-filters-for-hits` - -+ 开启优化 filter 的命中率的开关。 -+ 默认值：false - -### `level0-file-num-compaction-trigger` - -+ 触发 compaction 的 L0 文件个数。 -+ 默认值：1 - -## raftdb - -raftdb 相关配置项。 - -### `max-background-jobs` - -+ RocksDB 后台线程个数。 -+ 默认值：2 -+ 最小值：1 - -### `max-sub-compactions` - -+ RocksDB 进行 subcompaction 的并发数。 -+ 默认值：1 -+ 最小值：1 - -### `wal-dir` - -+ WAL 存储目录。 -+ 默认值：/tmp/tikv/store - -## security - -安全相关配置项。 - -### `ca-path` - -+ CA 文件路径 -+ 默认值："" - -### `cert-path` - -+ 包含 X509 证书的 PEM 文件路径 -+ 默认值："" - -### `key-path` - -+ 包含 X509 key 的 PEM 文件路径 -+ 默认值："" - -## import - -import 相关的配置项。 - -### `num-threads` - -+ 处理 RPC 请求线程数。 -+ 默认值：8 -+ 最小值：1 - -### `num-import-jobs` - -+ 并发导入工作任务数。 -+ 默认值：8 -+ 最小值：1 - -## pessimistic-txn - -### `enabled` - -+ 开启悲观事务支持，悲观事务使用方法请参考 [TiDB 悲观事务模式](/dev/reference/transactions/transaction-pessimistic.md)。 -+ 默认值：true - -### `wait-for-lock-timeout` - -+ 悲观事务在 TiKV 中等待其他事务释放锁的最长时间，单位为毫秒。若超时则会返回错误给 TiDB 并由 TiDB 重试加锁，语句最长等锁时间由 `innodb_lock_wait_timeout` 控制。 -+ 默认值：1000 -+ 最小值：1 - -### `wait-up-delay-duration` - -+ 悲观事务释放锁时，只会唤醒等锁事务中 start ts 最小的事务，其他事务将会延迟 `wake-up-delay-duration` 毫秒之后被唤醒。 -+ 默认值：20 diff --git a/dev/reference/configuration/tikv-server/configuration.md b/dev/reference/configuration/tikv-server/configuration.md deleted file mode 100644 index df545c42883e..000000000000 --- a/dev/reference/configuration/tikv-server/configuration.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: TiKV 配置参数 -category: reference ---- - -# TiKV 配置参数 - -TiKV 的命令行参数支持一些可读性好的单位转换。 - -+ 文件大小（以 bytes 为单位）：KB, MB, GB, TB, PB（也可以全小写） -+ 时间（以毫秒为单位）：ms, s, m, h - -## `-A, --addr` - -+ TiKV 监听地址 -+ 默认："127.0.0.1:20160" -+ 如果部署一个集群，\-\-addr 必须指定当前主机的 IP 地址，例如 "192.168.100.113:20160"，如果是运行在 docker 则需要指定为 "0.0.0.0:20160" - -## `--advertise-addr` - -+ TiKV 对外访问地址。 -+ 默认：${addr} -+ 在某些情况下，譬如 docker，或者 NAT 网络环境，客户端并不能通过 TiKV 自己监听的地址来访问到 TiKV，这时候，你就可以设置 advertise addr 来让 客户端访问 -+ 例如，docker 内部 IP 地址为 172.17.0.1，而宿主机的 IP 地址为 192.168.100.113 并且设置了端口映射 -p 20160:20160，那么可以设置为 \-\-advertise-addr="192.168.100.113:20160"，客户端可以通过 192.168.100.113:20160 来找到这个服务 - -## `-C, --config` - -+ 配置文件 -+ 默认："" -+ 如果你指定了配置文件，TiKV 会首先读取配置文件的配置。然后如果对应的配置在命令行参数里面也存在，TiKV 就会使用命令行参数的配置来覆盖配置文件里面的 - -## `--capacity` - -+ TiKV 存储数据的容量 -+ 默认：0 (无限) -+ PD 需要使用这个值来对整个集群做 balance 操作。（提示：你可以使用 10GB 来替代 10737418240，从而简化参数的传递） - -## `--data-dir` - -+ TiKV 数据存储路径 -+ 默认："/tmp/tikv/store" - -## `-L, --log` - -+ Log 级别 -+ 默认："info" -+ 我们能选择 trace, debug, info, warn, error, 或者 off - -## `--log-file` - -+ Log 文件 -+ 默认："" -+ 如果没设置这个参数，log 会默认输出到 "stderr"，如果设置了，log 就会输出到对应的文件里面，在每天凌晨，log 会自动轮转使用一个新的文件，并且将以前的文件改名备份 - -## `--pd` - -+ PD 地址列表。 -+ 默认："" -+ TiKV 必须使用这个值连接 PD，才能正常工作。使用逗号来分隔多个 PD 地址，例如： - 192.168.100.113:2379, 192.168.100.114:2379, 192.168.100.115:2379 diff --git a/dev/reference/error-codes.md b/dev/reference/error-codes.md deleted file mode 100644 index b55a14b651be..000000000000 --- a/dev/reference/error-codes.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -title: 错误码与故障诊断 -category: reference ---- - -# 错误码与故障诊断 - -本篇文档描述在使用 TiDB 过程中会遇到的问题以及解决方法。 - -## 错误码 - -TiDB 兼容 MySQL 的错误码，在大多数情况下，返回和 MySQL 一样的错误码。另外还有一些特有的错误码： - -| 错误码 | 说明 | -| --------------------- | -------------------------------------------------- | -| 8001 | 请求使用的内存超过 TiDB 内存使用的阈值限制 | -| 8002 | 带有 `SELECT FOR UPDATE` 语句的事务，在遇到写入冲突时，为保证一致性无法进行重试，事务将进行回滚并返回该错误 | -| 8003 | `ADMIN CHECK TABLE` 命令在遇到行数据跟索引不一致的时候返回该错误 | -| 8004 | 单个事务过大，原因及解决方法请参考[这里](/dev/faq/tidb.md#433-transaction-too-large-是什么原因怎么解决) | -| 8005 | 事务在 TiDB 中遇到了写入冲突，原因及解决方法请参考[这里](/dev/faq/tidb.md#九故障排除) | -| 8018 | 插件无法重新载入，原因是没有载入过 | -| 8019 | 重新载入的插件版本与之前不同，无法重新载入 | -| 8020 | 表被锁 | -| 8021 | key 不存在 | -| 8022 | 事务提交失败，但可以进行重试 | -| 8023 | 不能设置空值 | -| 8024 | 非法的事务 | -| 8025 | 写入的单条键值对过大 | -| 8026 | 没有实现的接口 | -| 8027 | 表结构版本过期 | -| 8028 | 表结构发生了变化 | -| 8029 | 错误值 | -| 8030 | 转变为带符号正整数时发生了越界，显示为负数 | -| 8031 | 负数转变为无符号数时，被转变为正数 | -| 8032 | 非法的 year 格式 | -| 8033 | 非法的 year 值 | -| 8034 | 不正确的 datetime 值 | -| 8036 | 非法的 time 格式 | -| 8037 | 非法的 week 格式 | -| 8038 | 字段无法获取到默认值 | -| 8039 | 索引的偏移量超出范围 | -| 8042 | 表结构的状态为不存在 | -| 8043 | 列信息的状态为不存在 | -| 8044 | 索引的状态为不存在 | -| 8045 | 非法的表数据 | -| 8046 | 列信息的状态为不可见 | -| 8047 | 设置了不支持的系统变量值，通常在用户设置了数据库不支持的变量值后的告警信息里出现 | -| 8048 | 设置了不支持的数据库隔离级别 | -| 8049 | 载入权限相关表失败 | -| 8050 | 设置了不支持的权限类型 | -| 8051 | 未知的字段类型 | -| 8052 | 来自客户端的数据包的序列号错误 | -| 8053 | 获取到了非法的自增列值 | -| 8055 | 当前快照过旧，数据可能已经被 GC | -| 8056 | 非法的表 ID | -| 8057 | 非法的字段类型 | -| 8058 | 申请了不存在的自动变量类型 | -| 8059 | 获取自动随机量失败 | -| 8060 | 非法的自增列偏移量 | -| 8061 | 不支持的 SQL Hint | -| 8062 | SQL Hint 中使用了非法的 token，与 Hint 的保留字冲突 | -| 8063 | SQL Hint 中限制内存使用量超过系统设置的上限，设置被忽略 | -| 8064 | 解析 SQL Hint 失败 | -| 8065 | SQL Hint 中使用了非法的整数 | -| 8066 | JSON_OBJECTAGG 函数的第二个参数是非法参数 | -| 8101 | 插件 ID 格式错误，正确的格式是 `[name]-[version]` 并且 name 和 version 中不能带有 '-' | -| 8102 | 无法读取插件定义信息 | -| 8103 | 插件名称错误 | -| 8104 | 插件版本不匹配 | -| 8105 | 插件被重复载入 | -| 8106 | 插件定义的系统变量名称没有以插件名作为开头 | -| 8107 | 载入的插件未指定版本或指定的版本过低 | -| 8108 | 不支持的执行计划类型 | -| 8109 | analyze 索引时找不到指定的索引 | -| 8110 | 不能进行笛卡尔积运算，需要将配置文件里的 `cross-join` 设置为 `true` | -| 8111 | execute 语句执行时找不到对应的 prepare 语句 | -| 8112 | execute 语句的参数个数与 prepare 语句不符合 | -| 8113 | execute 语句涉及的表结构在 prepare 语句执行后发生了变化 | -| 8114 | 未知的执行计划类型 | -| 8115 | 不支持 prepare 多行语句 | -| 8116 | 不支持 prepare DDL 语句 | -| 8118 | 构建执行器失败 | -| 8120 | 获取不到事务的 start tso | -| 8121 | 权限检查失败 | -| 8122 | 指定了通配符，但是找不到对应的表名 | -| 8123 | 带聚合函数的 SQL 中返回非聚合的列，违反了 only_full_group_by 模式 | -| 8200 | 尚不支持的 DDL 语法 | -| 8201 | 当前 TiDB 不是 DDL owner | -| 8202 | 不能对该索引解码 | -| 8203 | 非法的 DDL worker | -| 8204 | 非法的 DDL job | -| 8205 | 非法的 DDL job 标志 | -| 8206 | DDL 的 Reorg 阶段执行超时 | -| 8207 | 非法的存储节点 | -| 8210 | 非法的 DDL 状态 | -| 8211 | DDL 的 Reorg 阶段发生了 panic | -| 8212 | 非法的 region 切分范围 | -| 8213 | 非法的 DDL job 版本 | -| 8214 | DDL 操作被终止 | -| 8215 | Admin Repair 表失败 | -| 8216 | 非法的自动随机列 | -| 8221 | Key 编码错误 | -| 8222 | 索引 Key 编码错误 | -| 8223 | 检测出数据与索引不一致的错误 | -| 8224 | 找不到 DDL job | -| 8225 | DDL 已经完成，无法被取消 | -| 8226 | DDL 几乎要完成了，无法被取消 | -| 8227 | 创建 Sequence 时使用了不支持的选项 | -| 9001 | 请求 PD 超时，请检查 PD Server 状态/监控/日志以及 TiDB Server 与 PD Server 之间的网络 | -| 9002 | 请求 TiKV 超时，请检查 TiKV Server 状态/监控/日志以及 TiDB Server 与 TiKV Server 之间的网络 | -| 9003 | TiKV 操作繁忙，一般出现在数据库负载比较高时，请检查 TiKV Server 状态/监控/日志 | -| 9004 | 当数据库上承载的业务存在大量的事务冲突时，会遇到这种错误，请检查业务代码 | -| 9005 | 某个 Raft Group 不可用，如副本数目不足，出现在 TiKV 比较繁忙或者是 TiKV 节点停机的时候，请检查 TiKV Server 状态/监控/日志 | -| 9006 | GC Life Time 间隔时间过短，长事务本应读到的数据可能被清理了，应增加 GC Life Time | -| 9007 | 事务在 TiKV 中遇到了写入冲突，原因及解决方法请参考[这里](/dev/faq/tidb.md#九故障排除) | -| 9008 | 同时向 TiKV 发送的请求过多，超过了限制 | - -## 故障诊断 - -参见[故障诊断文档](/dev/how-to/troubleshoot/cluster-setup.md)以及 [FAQ](/dev/faq/tidb.md)。 diff --git a/dev/reference/garbage-collection/overview.md b/dev/reference/garbage-collection/overview.md deleted file mode 100644 index 00c86883f616..000000000000 --- a/dev/reference/garbage-collection/overview.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: GC 机制简介 -category: reference ---- - -# GC 机制简介 - -TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新写入的数据覆盖旧的数据时，旧的数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本。GC 的任务便是清理不再需要的旧数据。 - -## 整体流程 - -一个 TiDB 集群中会有一个 TiDB 实例被选举为 GC leader，GC 的运行由 GC leader 来控制。 - -GC 会被定期触发，默认情况下每 10 分钟一次。每次 GC 时，首先，TiDB 会计算一个称为 safe point 的时间戳（默认为当前时间减去 10 分钟），接下来 TiDB 会在保证 safe point 之后的快照全部拥有正确数据的前提下，删除更早的过期数据。具体而言，分为以下三个步骤： - -1. Resolve Locks -2. Delete Ranges -3. Do GC - -### Resolve Locks - -TiDB 的事务是基于 [Google Percolator](https://ai.google/research/pubs/pub36726) 模型实现的，事务的提交是一个两阶段提交的过程。第一阶段完成时，所有涉及的 key 会加上一个锁，其中一个锁会被设定为 Primary，其余的锁（Secondary）则会指向 Primary；第二阶段会将 Primary 锁所在的 key 加上一个 Write 记录，并去除锁。这里的 Write 记录就是历史上对该 key 进行写入或删除，或者该 key 上发生事务回滚的记录。Primary 锁被替换为何种 Write 记录标志着该事务提交成功与否。接下来，所有 Secondary 锁也会被依次替换。如果替换这些 Secondary 锁的线程死掉了，锁就残留了下来。 - -Resolve Locks 这一步的任务即对 safe point 之前的锁进行回滚或提交，取决于其 Primary 是否被提交。如果一个 Primary 锁也残留了下来，那么该事务应当视为超时并进行回滚。这一步是必不可少的，因为如果其 Primary 的 Write 记录由于太老而被 GC 清除掉了，那么就再也无法知道该事务是否成功。如果该事务存在残留的 Secondary 锁，那么也无法知道它应当被回滚还是提交，也就无法保证一致性。 - -Resolve Locks 的执行方式是由 GC leader 对所有的 Region 发送请求进行处理。从 3.0 起，这个过程默认会并行地执行，并发数量默认与 TiKV 节点个数相同。 - -### Delete Ranges - -在执行 `DROP TABLE/INDEX` 等操作时，会有大量连续的数据被删除。如果对每个 key 都进行删除操作、再对每个 key 进行 GC 的话，那么执行效率和空间回收速度都可能非常的低下。事实上，这种时候 TiDB 并不会对每个 key 进行删除操作，而是将这些待删除的区间及删除操作的时间戳记录下来。Delete Ranges 会将这些时间戳在 safe point 之前的区间进行快速的物理删除。 - -### Do GC - -这一步即删除所有 key 的过期版本。为了保证 safe point 之后的任何时间戳都具有一致的快照，这一步删除 safe point 之前提交的数据，但是会保留 safe point 前的最后一次写入（除非最后一次写入是删除）。 - -TiDB 2.1 及更早版本使用的 GC 方式是由 GC leader 向所有 Region 发送 GC 请求。从 3.0 起，GC leader 只需将 safe point 上传至 PD。每个 TiKV 节点都会各自从 PD 获取 safe point。当 TiKV 发现 safe point 发生更新时，便会对当前节点上所有作为 leader 的 Region 进行 GC。与此同时，GC leader 可以继续触发下一轮 GC。 - -> **注意：** -> -> 通过修改配置可以继续使用旧的 GC 方式，详情请参考 [GC 配置](/dev/reference/garbage-collection/configuration.md)。 diff --git a/dev/reference/key-monitoring-metrics/overview-dashboard.md b/dev/reference/key-monitoring-metrics/overview-dashboard.md deleted file mode 100644 index d5ff54a8d647..000000000000 --- a/dev/reference/key-monitoring-metrics/overview-dashboard.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Overview 面板重要监控指标详解 -category: reference ---- - -# Overview 面板重要监控指标详解 - -使用 Ansible 部署 TiDB 集群时，一键部署监控系统 (Prometheus/Grafana)，监控架构请看 [TiDB 监控框架概述](/dev/how-to/monitor/overview.md)。 - -目前 Grafana Dashboard 整体分为 PD、TiDB、TiKV、Node\_exporter、Overview 等。 - -对于日常运维，我们单独挑选出重要的 Metrics 放在 Overview 页面，方便日常运维人员观察集群组件 (PD, TiDB, TiKV) 使用状态以及集群使用状态。 - -以下为 Overview Dashboard 监控说明： - -## Services Port Status - -- Services Online：各服务在线节点数量 -- Services Offline：各服务 Down 掉节点数量 - -## PD - -- Storage Capacity：TiDB 集群总可用数据库空间大小 -- Current Storage Size：TiDB 集群目前已用数据库空间大小 -- Number of Regions：当前集群的 Region 总量 -- Leader Balance Ratio：Leader 数量最多和最少节点相差的百分比，一般小于 5%，节点重启时会有比较大的波动 -- Region Balance Ratio：Region 数量最多和最少节点相差的百分比，一般小于 5%，新增/下线节点时相差比较大 -- Store Status：集群 TiKV 节点的状态 - - Up Stores：正常运行的 TiKV 节点数量 - - Disconnect Stores：短时间内通信异常的 TiKV 节点数量 - - LowSpace Stores：剩余可用空间小于 20% 的 TiKV 节点数量 - - Down Stores：停止工作的 TiKV 节点数量，如果大于 0，说明有节点不正常 - - Offline Stores：正在下线的 TiKV 节点数量（正在下线的 TiKV 节点还在提供服务） - - Tombstone Stores：下线成功的 TiKV 节点数量 -- 99% completed\_cmds\_duration\_seconds：单位时间内，99% 的 pd-server 请求执行时间小于监控曲线的值，一般 <= 5ms -- handle\_requests\_duration\_seconds：PD 发送请求的网络耗时 - -## TiDB - -- Statement OPS：SQL 执行数量统计（包含 select、insert、update 等） -- Duration：SQL 执行的时间 -- QPS By Instance：每个 TiDB 上的 QPS -- Failed Query OPM：失败 SQL 的统计，例如语法错误、主键冲突等 -- Connection count：每个 TiDB 的连接数 -- Heap Memory Usage：每个 TiDB 使用的堆内存大小 -- Transaction OPS：事务执行数量统计 -- Transaction Duration：事务执行的时间 -- KV Cmd OPS：KV 命令执行数量统计 -- KV Cmd Duration 99：KV 命令执行的时间 -- PD TSO OPS：TiDB 从 PD 获取 TSO 的数量 -- PD TSO Wait Duration：TiDB 从 PD 获取 TS 的时间 -- TiClient Region Error OPS：TiKV 返回 Region 相关错误信息的数量 -- Lock Resolve OPS：事务冲突相关的数量 -- Load Schema Duration：TiDB 从 TiKV 获取 Schema 的时间 -- KV Backoff OPS：TiKV 返回错误信息的数量（事务冲突等） - -## TiKV - -- leader：各个 TiKV 节点上 Leader 的数量分布 -- region：各个 TiKV 节点上 Region 的数量分布 -- CPU：各个 TiKV 节点的 CPU 使用率 -- Memory：各个 TiKV 节点的内存使用量 -- store size：各个 TiKV 节点存储的数据量 -- cf size：集群不同 CF 存储的数据量 -- channel full：正常情况显示 No data，如果有了监控值，说明对应 TiKV 节点的消息处理不过来了 -- server report failures：正常情况显示 No data，如果出现了 Unreachable，说明 TiKV 之间通信有问题 -- scheduler pending commands：写入堆积的数量，偶尔出现峰值属于正常现象 -- coprocessor pending requests：正常情况监控为 0 或者数量很少 -- coprocessor executor count：不同类型的查询操作数量 -- coprocessor request duration：TiKV 中查询消耗的时间 -- raft store CPU：raftstore 线程的 CPU 使用率，线程数量默认为 2 (通过 `raftstore.store-pool-size` 配置)。如果单个线程使用率超过 80%，说明使用率很高 -- Coprocessor CPU：TiKV 查询线程的 CPU 使用率，和业务相关，复杂查询会使用大量的 CPU 资源 - -## System Info - -- Vcores：CPU 核心数量 -- Memory：内存总大小 -- CPU Usage：CPU 使用率，最大为 100% -- Load [1m]：1 分钟的负载情况 -- Memory Available：剩余内存大小 -- Network Traffic：网卡流量统计 -- TCP Retrans：网络监控，TCP 相关信息统计 -- IO Util：磁盘使用率，最高为 100%，一般到 80% - 90% 就需要考虑加节点 - -## 图例 - -![overview](/media/overview.png) diff --git a/dev/reference/key-monitoring-metrics/pd-dashboard.md b/dev/reference/key-monitoring-metrics/pd-dashboard.md deleted file mode 100644 index 7c93efdfaf64..000000000000 --- a/dev/reference/key-monitoring-metrics/pd-dashboard.md +++ /dev/null @@ -1,139 +0,0 @@ ---- -title: PD 重要监控指标详解 -category: reference ---- - -# PD 重要监控指标详解 - -使用 Ansible 部署 TiDB 集群时，一键部署监控系统 (Prometheus/Grafana)，监控架构请看 [TiDB 监控框架概述](/dev/how-to/monitor/overview.md)。 - -目前 Grafana Dashboard 整体分为 PD、TiDB、TiKV、Node\_exporter、Overview 等。 - -对于日常运维，我们通过观察 PD 面板上的 Metrics，可以了解 PD 当前的状态。 - -以下为 PD Dashboard 监控说明： - -## Cluster - -- PD role：当前 PD 的角色 -- Storage capacity：TiDB 集群总可用数据库空间大小 -- Current storage size：TiDB 集群目前已用数据库空间大小 -- Current storage usage：TiDB 集群存储空间的使用率 -- Normal stores：处于正常状态的节点数目 -- Number of Regions：当前集群的 Region 总量 -- PD scheduler config：PD 调度配置列表 -- Region label isolation level：不同 label 所在的 level 的 Region 数量 -- Label distribution：集群中 TiKV 节点的 label 分布情况 -- Abnormal stores：处于异常状态的节点数目，正常情况应当为 0 -- pd_cluster_metadata：记录集群 ID，时间戳和生成的 ID -- Current peer count：当前集群 peer 的总量 -- Region health：每个 Region 的状态，通常情况下，pending 的 peer 应该少于 100，miss 的 peer 不能一直大于 0 - -![PD Dashboard - Cluster metrics](/media/pd-dashboard-cluster-v2.png) - -## Operator - -- Schedule operator create：新创建的不同 operator 的数量 -- Schedule operator check：已检查的 operator 的数量，主要检查是否当前步骤已经执行完成，如果是，则执行下一个步骤 -- Schedule operator finish：已完成调度的 operator 的数量 -- Schedule operator timeout：已超时的 operator 的数量 -- Schedule operator replaced or canceled：已取消或者被替换的 operator 的数量 -- Schedule operators count by state：不同状态的 operator 的数量 -- 99% Operator finish duration：99% 已完成 operator 所花费的最长时间 -- 50% Operator finish duration：50% 已完成 operator 所花费的最长时间 -- 99% Operator step duration：99% 已完成的 operator 步骤所花费的最长时间 -- 50% Operator step duration：50% 已完成的 operator 步骤所花费的最长时间 - -![PD Dashboard - Operator metrics](/media/pd-dashboard-operator-v2.png) - -## Statistics - Balance - -- Store capacity：每个 TiKV 实例的总的空间大小 -- Store available：每个 TiKV 实例的可用空间大小 -- Store used：每个 TiKV 实例的已使用空间大小 -- Size amplification：每个 TiKV 实例的空间放大比率 -- Size available ratio：每个 TiKV 实例的可用空间比率 -- Store leader score：每个 TiKV 实例的 leader 分数 -- Store Region score：每个 TiKV 实例的 Region 分数 -- Store leader size：每个 TiKV 实例上所有 leader 的大小 -- Store Region size：每个 TiKV 实例上所有 Region 的大小 -- Store leader count：每个 TiKV 实例上所有 leader 的数量 -- Store Region count：每个 TiKV 实例上所有 Region 的数量 - -![PD Dashboard - Balance metrics](/media/pd-dashboard-balance-v2.png) - -## Statistics - hotspot - -- Hot write Region's leader distribution：每个 TiKV 实例上是写入热点的 leader 的数量 -- Hot write Region's peer distribution：每个 TiKV 实例上是写入热点的 peer 的数量 -- Hot write Region's leader written bytes：每个 TiKV 实例上热点的 leader 的写入大小 -- Hot write Region's peer written bytes：每个 TiKV 实例上热点的 peer 的写入大小 -- Hot read Region's leader distribution：每个 TiKV 实例上是读取热点的 leader 的数量 -- Hot read Region's peer distribution：每个 TiKV 实例上是读取热点的 peer 的数量 -- Hot read Region's leader read bytes：每个 TiKV 实例上热点的 leader 的读取大小 -- Hot read Region's peer read bytes：每个 TiKV 实例上热点的 peer 的读取字节数 - -![PD Dashboard - Hotspot metrics](/media/pd-dashboard-hotspot.png) - -## Scheduler - -- Scheduler is running：所有正在运行的 scheduler -- Balance leader movement：leader 移动的详细情况 -- Balance Region movement：Region 移动的详细情况 -- Balance leader event：balance leader 的事件数量 -- Balance Region event：balance Region 的事件数量 -- Balance leader scheduler：balance-leader scheduler 的状态 -- Balance Region scheduler：balance-region scheduler 的状态 -- Namespace checker：namespace checker 的状态 -- Replica checker：replica checker 的状态 -- Region merge checker：merge checker 的状态 -- Filter target：尝试选择 Store 作为调度 taget 时没有通过 Filter 的计数 -- Filter source：尝试选择 Store 作为调度 source 时没有通过 Filter 的计数 -- Balance Direction：Store 被选作调度 target 或 source 的次数 -- Store Limit：Store 的调度限流状态 - -![PD Dashboard - Scheduler metrics](/media/pd-dashboard-scheduler-v2.png) - -## gRPC - -- Completed commands rate：gRPC 命令的完成速率 -- 99% Completed commands duration：99% 命令的最长消耗时间 - -![PD Dashboard - gRPC metrics](/media/pd-dashboard-grpc-v2.png) - -## etcd - -- Handle transactions count：etcd 的事务个数 -- 99% Handle transactions duration：99% 的情况下，处理 etcd 事务所需花费的时间 -- 99% WAL fsync duration：99% 的情况下，持久化 WAL 所需花费的时间，这个值通常应该小于 1s -- 99% Peer round trip time seconds：99% 的情况下，etcd 的网络延时，这个值通常应该小于 1s -- etcd disk WAL fsync rate：etcd 持久化 WAL 的速率 -- Raft term：当前 Raft 的 term -- Raft committed index：最后一次 commit 的 Raft index -- Raft applied index：最后一次 apply 的 Raft index - -![PD Dashboard - etcd metrics](/media/pd-dashboard-etcd-v2.png) - -## TiDB - -- Handle requests count：TiDB 的请求数量 -- Handle requests duration：每个请求所花费的时间，99% 的情况下，应该小于 100ms - -![PD Dashboard - TiDB metrics](/media/pd-dashboard-tidb-v2.png) - -## Heartbeat - -- Region heartbeat report：TiKV 向 PD 发送的心跳个数 -- Region heartbeat report error：TiKV 向 PD 发送的异常的心跳个数 -- Region heartbeat report active：TiKV 向 PD 发送的正常的心跳个数 -- Region schedule push：PD 向 TiKV 发送的调度命令的个数 -- 99% Region heartbeat latency：99% 的情况下，心跳的延迟 - -![PD Dashboard - Heartbeat metrics](/media/pd-dashboard-heartbeat-v2.png) - -## Region storage - -- Syncer Index：Leader 记录 Region 变更历史的最大 index -- history last index：Follower 成功同步的 Region 变更历史的 index - -![PD Dashboard - Region storage](/media/pd-dashboard-region-storage.png) diff --git a/dev/reference/key-monitoring-metrics/tikv-dashboard.md b/dev/reference/key-monitoring-metrics/tikv-dashboard.md deleted file mode 100644 index 887d27c7a072..000000000000 --- a/dev/reference/key-monitoring-metrics/tikv-dashboard.md +++ /dev/null @@ -1,429 +0,0 @@ ---- -title: TiKV 重要监控指标详解 -category: reference ---- - -# TiKV 重要监控指标详解 - -使用 Ansible 部署 TiDB 集群时，一键部署监控系统 (Prometheus/Grafana)，监控架构请看 [TiDB 监控框架概述](/dev/how-to/monitor/overview.md)。 - -目前 Grafana Dashboard 整体分为 PD、TiDB、TiKV、Node\_exporter、Overview 等。 - -对于日常运维，我们通过观察 TiKV 面板上的 Metrics，可以了解 TiKV 当前的状态。 - -以下为 TiKV Dashboard 监控说明： - -## Cluster - -- Store size：每个 TiKV 实例的使用的存储空间的大小 -- Available size：每个 TiKV 实例的可用的存储空间的大小 -- Capacity size：每个 TiKV 实例的存储容量的大小 -- CPU：每个 TiKV 实例 CPU 的使用率 -- Memory：每个 TiKV 实例内存的使用情况 -- IO utilization：每个 TiKV 实例 IO 的使用率 -- MBps：每个 TiKV 实例写入和读取的数据量大小 -- QPS：每个 TiKV 实例上各种命令的 QPS -- Errps：每个 TiKV 实例上 gRPC 消息失败的个数 -- leader：每个 TiKV 实例 leader 的个数 -- Region：每个 TiKV 实例 Region 的个数 - -![TiKV Dashboard - Cluster metrics](/media/tikv-dashboard-cluster.png) - -## Errors - -- Server is busy：各种会导致 server 繁忙的事件个数，如 write stall，channel full 等，正常情况下应当为 0 -- Server report failures：server 报错的消息个数，正常情况下应当为 0 -- Raftstore error：每个 TiKV 实例上 raftstore 发生错误的个数 -- Scheduler error：每个 TiKV 实例上 scheduler 发生错误的个数 -- Coprocessor error：每个 TiKV 实例上 coprocessor 发生错误的个数 -- gRPC message error：每个 TiKV 实例上 gRPC 消息发生错误的个数 -- Leader drop：每个 TiKV 实例上 drop leader 的个数 -- Leader missing：每个 TiKV 实例上 missing leader 的个数 - -![TiKV Dashboard - Errors metrics](/media/tikv-dashboard-errors.png) - -## Server - -- Leader：每个 TiKV 实例 leader 的个数 -- Region：每个 TiKV 实例 Region 的个数 -- CF size：每个 CF 的大小 -- Store size：每个 TiKV 实例的使用的存储空间的大小 -- Channel full：每个 TiKV 实例上 channel full 错误的数量，正常情况下应当为 0 -- Server report failures：server 报错的消息个数，正常情况下应当为 0 -- Region average written keys：每个 TiKV 实例上所有 Region 的平均 key 写入个数 -- Region average written bytes：每个 TiKV 实例上所有 Region 的平均写入大小 -- Active written leaders：每个 TiKV 实例上有效的 leader 个数 -- Approximate Region size：每个 Region 近似的大小 - -![TiKV Dashboard - Server metrics](/media/tikv-dashboard-server.png) - -## Raft IO - -- Apply log duration：Raft apply 日志所花费的时间 -- Apply log duration per server：每个 TiKV 实例上 Raft apply 日志所花费的时间 -- Append log duration：Raft append 日志所花费的时间 -- Append log duration per server：每个 TiKV 实例上 Raft append 日志所花费的时间 - -![TiKV Dashboard - Raft IO metrics](/media/tikv-dashboard-raftio.png) - -## Raft process - -- Ready handled：Raft 中不同 ready 类型的个数 -- Process ready duration per server：每个 TiKV 实例处理 ready 所花费的时间，99.99% 的情况下，应该小于 2s -- Process tick duration per server：每个 TiKV 实例处理 tick 所花费的时间 -- 0.99 Duration of Raft store events：99% 的 raftstore 事件所花费的时间 - -![TiKV Dashboard - Raft process metrics](/media/tikv-dashboard-raft-process.png) - -## Raft message - -- Sent messages per server：每个 TiKV 实例发送 Raft 消息的个数 -- Flush messages per server：每个 TiKV 实例持久化 Raft 消息的个数 -- Receive messages per server：每个 TiKV 实例接受 Raft 消息的个数 -- Messages：发送不同类型的 Raft 消息的个数 -- Vote：Raft 投票消息发送的个数 -- Raft dropped messages：丢弃不同类型的 Raft 消息的个数 - -![TiKV Dashboard - Raft message metrics](/media/tikv-dashboard-raft-message.png) - -## Raft propose - -- Raft proposals per ready：在一个 mio tick 内，所有 Region proposal 的个数 -- Raft read/write proposals：不同类型的 proposal 的个数 -- Raft read proposals per server：每个 TiKV 实例发起读 proposal 的个数 -- Raft write proposals per server：每个 TiKV 实例发起写 proposal 的个数 -- Propose wait duration：每个 proposal 的等待时间 -- Propose wait duration per server：每个 TiKV 实例上每个 proposal 的等待时间 -- Raft log speed：peer propose 日志的速度 - -![TiKV Dashboard - Raft propose metrics](/media/tikv-dashboard-raft-propose.png) - -## Raft admin - -- Admin proposals：admin proposal 的个数 -- Admin apply：apply 命令的个数 -- Check split：split check 命令的个数 -- 99.99% Check split duration：99.99% 的情况下，split check 所需花费的时间 - -![TiKV Dashboard - Raft admin metrics](/media/tikv-dashboard-raft-admin.png) - -## Local reader - -- Local reader requests：所有请求的总数以及 local read 线程拒绝的请求数量 -- Local read requests duration：local read 请求的等待时间 -- Local read requests batch size：local read 请求的批量大小 - -![TiKV Dashboard - Local reader metrics](/media/tikv-dashboard-local-reader.png) - -## Storage - -- Storage command total：收到不同命令的个数 -- Storage async request error：异步请求出错的个数 -- Storage async snapshot duration：异步处理 snapshot 所花费的时间，99% 的情况下，应该小于 1s -- Storage async write duration：异步写所花费的时间，99% 的情况下，应该小于 1s - -![TiKV Dashboard - Storage metrics](/media/tikv-dashboard-storage.png) - -## Scheduler - -- Scheduler stage total：每种命令不同阶段的个数，正常情况下，不会在短时间内出现大量的错误 -- Scheduler priority commands：不同优先级命令的个数 -- Scheduler pending commands：每个 TiKV 实例上 pending 命令的个数 - -![TiKV Dashboard - Scheduler metrics](/media/tikv-dashboard-scheduler.png) - -## Scheduler - batch_get - -- Scheduler stage total：batch_get 中每个命令所处不同阶段的个数，正常情况下，不会在短时间内出现大量的错误 -- Scheduler command duration：执行 batch_get 命令所需花费的时间，正常情况下，应该小于 1s -- Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s -- Scheduler keys read：batch_get 命令读取 key 的个数 -- Scheduler keys written：batch_get 命令写入 key 的个数 -- Scheduler scan details：执行 batch_get 命令时，扫描每个 CF 中 key 的详细情况 -- Scheduler scan details：执行 batch_get 命令时，扫描每个 lock CF 中 key 的详细情况 -- Scheduler scan details [write]：执行 batch_get 命令时，扫描每个 write CF 中 key 的详细情况 -- Scheduler scan details [default]：执行 batch_get 命令时，扫描每个 default CF 中 key 的详细情况 - -![TiKV Dashboard - Scheduler - batch_get metrics](/media/tikv-dashboard-scheduler-batch-get.png) - -## Scheduler - cleanup - -- Scheduler stage total：cleanup 中每个命令所处不同阶段的个数，正常情况下，不会在短时间内出现大量的错误 -- Scheduler command duration：执行 cleanup 命令所需花费的时间，正常情况下，应该小于 1s -- Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s -- Scheduler keys read：cleanup 命令读取 key 的个数 -- Scheduler keys written：cleanup 命令写入 key 的个数 -- Scheduler scan details：执行 cleanup 命令时，扫描每个 CF 中 key 的详细情况 -- Scheduler scan details [lock]：执行 cleanup 命令时，扫描每个 lock CF 中 key 的详细情况 -- Scheduler scan details [write]：执行 cleanup 命令时，扫描每个 write CF 中 key 的详细情况 -- Scheduler scan details [default]：执行 cleanup 命令时，扫描每个 default CF 中 key 的详细情况 - -![TiKV Dashboard - Scheduler - cleanup metrics](/media/tikv-dashboard-scheduler-cleanup.png) - -## Scheduler - commit - -- Scheduler stage total：commit 中每个命令所处不同阶段的个数，正常情况下，不会在短时间内出现大量的错误 -- Scheduler command duration：执行 commit 命令所需花费的时间，正常情况下，应该小于 1s -- Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s -- Scheduler keys read：commit 命令读取 key 的个数 -- Scheduler keys written：commit 命令写入 key 的个数 -- Scheduler scan details：执行 commit 命令时，扫描每个 CF 中 key 的详细情况 -- Scheduler scan details [lock]：执行 commit 命令时，扫描每个 lock CF 中 key 的详细情况 -- Scheduler scan details [write]：执行 commit 命令时，扫描每个 write CF 中 key 的详细情况 -- Scheduler scan details [default]：执行 commit 命令时，扫描每个 default CF 中 key 的详细情况 - -![TiKV Dashboard - Scheduler commit metrics](/media/tikv-dashboard-scheduler-commit.png) - -## Scheduler - gc - -- Scheduler stage total：gc 中每个命令所处不同阶段的个数，正常情况下，不会在短时间内出现大量的错误 -- Scheduler command duration：执行 gc 命令所需花费的时间，正常情况下，应该小于 1s -- Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s -- Scheduler keys read：gc 命令读取 key 的个数 -- Scheduler keys written：gc 命令写入 key 的个数 -- Scheduler scan details：执行 gc 命令时，扫描每个 CF 中 key 的详细情况 -- Scheduler scan details [lock]：执行 gc 命令时，扫描每个 lock CF 中 key 的详细情况 -- Scheduler scan details [write]：执行 gc 命令时，扫描每个 write CF 中 key 的详细情况 -- Scheduler scan details [default]：执行 gc 命令时，扫描每个 default CF 中 key 的详细情况 - -## Scheduler - get - -- Scheduler stage total：get 中每个命令所处不同阶段的个数，正常情况下，不会在短时间内出现大量的错误 -- Scheduler command duration：执行 get 命令所需花费的时间，正常情况下，应该小于 1s -- Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s -- Scheduler keys read：get 命令读取 key 的个数 -- Scheduler keys written：get 命令写入 key 的个数 -- Scheduler scan details：执行 get 命令时，扫描每个 CF 中 key 的详细情况 -- Scheduler scan details [lock]：执行 get 命令时，扫描每个 lock CF 中 key 的详细情况 -- Scheduler scan details [write]：执行 get 命令时，扫描每个 write CF 中 key 的详细情况 -- Scheduler scan details [default]：执行 get 命令时，扫描每个 default CF 中 key 的详细情况 - -## Scheduler - key_mvcc - -- Scheduler stage total：key_mvcc 中每个命令所处不同阶段的个数，正常情况下，不会在短时间内出现大量的错误 -- Scheduler command duration：执行 key_mvcc 命令所需花费的时间，正常情况下，应该小于 1s -- Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s -- Scheduler keys read：key_mvcc 命令读取 key 的个数 -- Scheduler keys written：key_mvcc 命令写入 key 的个数 -- Scheduler scan details：执行 key_mvcc 命令时，扫描每个 CF 中 key 的详细情况 -- Scheduler scan details [lock]：执行 key_mvcc 命令时，扫描每个 lock CF 中 key 的详细情况 -- Scheduler scan details [write]：执行 key_mvcc 命令时，扫描每个 write CF 中 key 的详细情况 -- Scheduler scan details [default]：执行 key_mvcc 命令时，扫描每个 default CF 中 key 的详细情况 - -## Scheduler - prewrite - -- Scheduler stage total：prewrite 中每个命令所处不同阶段的个数，正常情况下，不会在短时间内出现大量的错误 -- Scheduler command duration：执行 prewrite 命令所需花费的时间，正常情况下，应该小于 1s -- Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s -- Scheduler keys read：prewrite 命令读取 key 的个数 -- Scheduler keys written：prewrite 命令写入 key 的个数 -- Scheduler scan details：执行 prewrite 命令时，扫描每个 CF 中 key 的详细情况 -- Scheduler scan details [lock]：执行 prewrite 命令时，扫描每个 lock CF 中 key 的详细情况 -- Scheduler scan details [write]：执行 prewrite 命令时，扫描每个 write CF 中 key 的详细情况 -- Scheduler scan details [default]：执行 prewrite 命令时，扫描每个 default CF 中 key 的详细情况 - -## Scheduler - resolve_lock - -- Scheduler stage total：resolve_lock 中每个命令所处不同阶段的个数，正常情况下，不会在短时间内出现大量的错误 -- Scheduler command duration：执行 resolve_lock 命令所需花费的时间，正常情况下，应该小于 1s -- Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s -- Scheduler keys read：resolve_lock 命令读取 key 的个数 -- Scheduler keys written：resolve_lock 命令写入 key 的个数 -- Scheduler scan details：执行 resolve_lock 命令时，扫描每个 CF 中 key 的详细情况 -- Scheduler scan details [lock]：执行 resolve_lock 命令时，扫描每个 lock CF 中 key 的详细情况 -- Scheduler scan details [write]：执行 resolve_lock 命令时，扫描每个 write CF 中 key 的详细情况 -- Scheduler scan details [default]：执行 resolve_lock 命令时，扫描每个 default CF 中 key 的详细情况 - -## Scheduler - scan - -- Scheduler stage total：scan 中每个命令所处不同阶段的个数，正常情况下，不会在短时间内出现大量的错误 -- Scheduler command duration：执行 scan 命令所需花费的时间，正常情况下，应该小于 1s -- Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s -- Scheduler keys read：scan 命令读取 key 的个数 -- Scheduler keys written：scan 命令写入 key 的个数 -- Scheduler scan details：执行 scan 命令时，扫描每个 CF 中 key 的详细情况 -- Scheduler scan details [lock]：执行 scan 命令时，扫描每个 lock CF 中 key 的详细情况 -- Scheduler scan details [write]：执行 scan 命令时，扫描每个 write CF 中 key 的详细情况 -- Scheduler scan details [default]：执行 scan 命令时，扫描每个 default CF 中 key 的详细情况 - -## Scheduler - scan_lock - -- Scheduler stage total：scan_lock 中每个命令所处不同阶段的个数，正常情况下，不会在短时间内出现大量的错误 -- Scheduler command duration：执行 scan_lock 命令所需花费的时间，正常情况下，应该小于 1s -- Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s -- Scheduler keys read：scan_lock 命令读取 key 的个数 -- Scheduler keys written：scan_lock 命令写入 key 的个数 -- Scheduler scan details：执行 scan_lock 命令时，扫描每个 CF 中 key 的详细情况 -- Scheduler scan details [lock]：执行 scan_lock 命令时，扫描每个 lock CF 中 key 的详细情况 -- Scheduler scan details [write]：执行 scan_lock 命令时，扫描每个 write CF 中 key 的详细情况 -- Scheduler scan details [default]：执行 scan_lock 命令时，扫描每个 default CF 中 key 的详细情况 - -## Scheduler - start_ts_mvcc - -- Scheduler stage total：start_ts_mvcc 中每个命令所处不同阶段的个数，正常情况下，不会在短时间内出现大量的错误 -- Scheduler command duration：执行 start_ts_mvcc 命令所需花费的时间，正常情况下，应该小于 1s -- Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s -- Scheduler keys read：start_ts_mvcc 命令读取 key 的个数 -- Scheduler keys written：start_ts_mvcc 命令写入 key 的个数 -- Scheduler scan details：执行 start_ts_mvcc 命令时，扫描每个 CF 中 key 的详细情况 -- Scheduler scan details [lock]：执行 start_ts_mvcc 命令时，扫描每个 lock CF 中 key 的详细情况 -- Scheduler scan details [write]：执行 start_ts_mvcc 命令时，扫描每个 write CF 中 key 的详细情况 -- Scheduler scan details [default]：执行 start_ts_mvcc 命令时，扫描每个 default CF 中 key 的详细情况 - -## Scheduler - unsafe_destroy_range - -- Scheduler stage total：unsafe_destroy_range 中每个命令所处不同阶段的个数，正常情况下，不会在短时间内出现大量的错误 -- Scheduler command duration：执行 unsafe_destroy_range 命令所需花费的时间，正常情况下，应该小于 1s -- Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s -- Scheduler keys read：unsafe_destroy_range 命令读取 key 的个数 -- Scheduler keys written：unsafe_destroy_range 命令写入 key 的个数 -- Scheduler scan details：执行 unsafe_destroy_range 命令时，扫描每个 CF 中 key 的详细情况 -- Scheduler scan details [lock]：执行 unsafe_destroy_range 命令时，扫描每个 lock CF 中 key 的详细情况 -- Scheduler scan details [write]：执行 unsafe_destroy_range 命令时，扫描每个 write CF 中 key 的详细情况 -- Scheduler scan details [default]：执行 unsafe_destroy_range 命令时，扫描每个 default CF 中 key 的详细情况 - -## Coprocessor - -- Request duration：处理 coprocessor 读请求所花费的时间 -- Wait duration：coprocessor 请求的等待时间，99.99% 的情况下，应该小于 10s -- Handle duration：处理 coprocessor 请求所花费的时间 -- 95% Request duration by store：95% 的情况下，每个 TiKV 实例处理 coprocessor 读请求所花费的时间 -- 95% Wait duration by store：95% 的情况下，每个 TiKV 实例上 coprocessor 请求的等待时间 -- 95% Handle duration by store：95% 的情况下，每个 TiKV 实例处理 coprocessor 请求所花费的时间 -- Request errors：下推的请求发生错误的个数，正常情况下，短时间内不应该有大量的错误 -- DAG executors：DAG executor 的个数 -- Scan keys：每个请求 scan key 的个数 -- Scan details：scan 每个 CF 的详细情况 -- Table Scan - Details by CF：table scan 针对每个 CF 的详细情况 -- Index Scan - Details by CF：index scan 针对每个 CF 的详细情况 -- Table Scan - Perf Statistics：执行 table sacn 的时候，根据 perf 统计的 RocksDB 内部 operation 的个数 -- Index Scan - Perf Statistics：执行 index sacn 的时候，根据 perf 统计的 RocksDB 内部 operation 的个数 - -## GC - -- MVCC versions：每个 key 的版本个数 -- MVCC delete versions：GC 删除掉的每个 key 的版本个数 -- GC tasks：由 gc_worker 处理的 GC 任务的个数 -- GC tasks Duration：执行 GC 任务时所花费的时间 -- GC keys (write CF)：在 GC 过程中，write CF 中 受影响的 key 的个数 -- TiDB GC actions result：TiDB Region 层面的 GC 结果 -- TiDB GC worker actions：TiDB GC worker 的不同 action 的个数 -- TiDB GC seconds：TiDB 执行 GC 花费的时间 -- TiDB GC failure：TiDB GC job 失败的个数 -- GC lifetime：TiDB 设置的 GC lifetime -- GC interval：TiDB 设置的 GC 间隔 - -## Snapshot - -- Rate snapshot message：发送 Raft snapshot 消息的速率 -- 99% Handle snapshot duration：99% 的情况下，处理 snapshot 所需花费的时间 -- Snapshot state count：不同状态的 snapshot 的个数 -- 99.99% Snapshot size：99.99% 的 snapshot 的大小 -- 99.99% Snapshot KV count：99.99% 的 snapshot 包含的 key 的个数 - -## Task - -- Worker handled tasks：worker 处理的任务个数 -- Worker pending tasks：当前 worker 中，pending 和 running 的任务个数，正常情况下，应该小于 1000 -- FuturePool handled tasks：future pool 处理的任务个数 -- FuturePool pending tasks：当前 future pool 中，pending 和 running 的任务个数 - -## Thread CPU - -- Raft store CPU：raftstore 线程的 CPU 使用率，通常应低于 80% -- Async apply CPU：async apply 线程的 CPU 使用率，通常应低于 90% -- Scheduler CPU：scheduler 线程的 CPU 使用率，通常应低于 80% -- Scheduler worker CPU：scheduler worker 线程的 CPU 使用率 -- Storage ReadPool CPU：Readpool 线程的 CPU 使用率 -- Coprocessor CPU：coprocessor 线程的 CPU 使用率 -- Snapshot worker CPU：snapshot worker 线程的 CPU 使用率 -- Split check CPU：split check 线程的 CPU 使用率 -- RocksDB CPU：RocksDB 线程的 CPU 使用率 -- gRPC poll CPU：gRPC 线程的 CPU 使用率，通常应低于 80% - -## RocksDB - kv - -- Get operations：get 操作的个数 -- Get duration：get 操作的耗时 -- Seek operations：seek 操作的个数 -- Seek duration：seek 操作的耗时 -- Write operations：write 操作的个数 -- Write duration：write 操作的耗时 -- WAL sync operations：sync WAL 操作的个数 -- WAL sync duration：sync WAL 操作的耗时 -- Compaction operations：compaction 和 flush 操作的个数 -- Compaction duration：compaction 和 flush 操作的耗时 -- SST read duration：读取 SST 所需的时间 -- Write stall duration：由于 write stall 造成的时间开销，正常情况下应为 0 -- Memtable size：每个 CF 的 memtable 的大小 -- Memtable hit：memtable 的命中率 -- Block cache size：block cache 的大小。如果将 `shared block cache` 禁用，即为每个 CF 的 block cache 的大小 -- Block cache hit：block cache 的命中率 -- Block cache flow：不同 block cache 操作的流量 -- Block cache operations 不同 block cache 操作的个数 -- Keys flow：不同操作造成的 key 的流量 -- Total keys：每个 CF 中 key 的个数 -- Read flow：不同读操作的流量 -- Bytes / Read：每次读的大小 -- Write flow：不同写操作的流量 -- Bytes / Write：每次写的大小 -- Compaction flow：compaction 相关的流量 -- Compaction pending bytes：等待 compaction 的大小 -- Read amplification：每个 TiKV 实例的读放大 -- Compression ratio：每一层的压缩比 -- Number of snapshots：每个 TiKV 的 snapshot 的数量 -- Oldest snapshots duration：最旧的 snapshot 保留的时间 -- Number files at each level：每一层的文件个数 -- Ingest SST duration seconds：ingest SST 所花费的时间 -- Stall conditions changed of each CF：每个 CF stall 的原因 - -## RocksDB - raft - -- Get operations：get 操作的个数 -- Get duration：get 操作的耗时 -- Seek operations：seek 操作的个数 -- Seek duration：seek 操作的耗时 -- Write operations：write 操作的个数 -- Write duration：write 操作的耗时 -- WAL sync operations：sync WAL 操作的个数 -- WAL sync duration：sync WAL 操作的耗时 -- Compaction operations：compaction 和 flush 操作的个数 -- Compaction duration：compaction 和 flush 操作的耗时 -- SST read duration：读取 SST 所需的时间 -- Write stall duration：由于 write stall 造成的时间开销，正常情况下应为 0 -- Memtable size：每个 CF 的 memtable 的大小 -- Memtable hit：memtable 的命中率 -- Block cache size：block cache 的大小。如果将 `shared block cache` 禁用，即为每个 CF 的 block cache 的大小 -- Block cache hit：block cache 的命中率 -- Block cache flow：不同 block cache 操作的流量 -- Block cache operations 不同 block cache 操作的个数 -- Keys flow：不同操作造成的 key 的流量 -- Total keys：每个 CF 中 key 的个数 -- Read flow：不同读操作的流量 -- Bytes / Read：每次读的大小 -- Write flow：不同写操作的流量 -- Bytes / Write：每次写的大小 -- Compaction flow：compaction 相关的流量 -- Compaction pending bytes：等待 compaction 的大小 -- Read amplification：每个 TiKV 实例的读放大 -- Compression ratio：每一层的压缩比 -- Number of snapshots：每个 TiKV 的 snapshot 的数量 -- Oldest snapshots duration：最旧的 snapshot 保留的时间 -- Number files at each level：每一层的文件个数 -- Ingest SST duration seconds：ingest SST 所花费的时间 -- Stall conditions changed of each CF：每个 CF stall 的原因 - -## gRPC - -- gRPC message count：每种 gRPC 消息的个数 -- gRPC message failed：失败的 gRPC 消息的个数 -- 99% gRPC message duration：在 99% gRPC 消息的执行时间 -- gRPC GC message count：gRPC GC 消息的个数 -- 99% gRPC KV GC message duration：在 99% 情况下，gRPC GC 消息的执行时间 - -## PD - -- PD requests：TiKV 发送给 PD 的请求个数 -- PD request duration (average)：TiKV 发送给 PD 的请求所需的平均时间 -- PD heartbeats：发送给 PD 的心跳个数 -- PD validate peers：通过 PD 验证 TiKV 的 peer 有效的个数 diff --git a/dev/reference/mysql-compatibility.md b/dev/reference/mysql-compatibility.md deleted file mode 100644 index 5e2e30fd442d..000000000000 --- a/dev/reference/mysql-compatibility.md +++ /dev/null @@ -1,226 +0,0 @@ ---- -title: 与 MySQL 兼容性对比 -category: reference ---- - -# 与 MySQL 兼容性对比 - -TiDB 支持 MySQL 传输协议及其绝大多数的语法。这意味着您现有的 MySQL 连接器和客户端都可以继续使用。大多数情况下您现有的应用都可以迁移至 TiDB，无需任何代码修改。 - -当前 TiDB 服务器官方支持的版本为 MySQL 5.7。大部分 MySQL 运维工具（如 PHPMyAdmin, Navicat, MySQL Workbench 等），以及备份恢复工具（如 mysqldump, Mydumper/myloader）等都可以直接使用。 - -不过一些特性由于在分布式环境下没法很好的实现，目前暂时不支持或者是表现与 MySQL 有差异。一些 MySQL 语法在 TiDB 中可以解析通过，但是不会做任何后续的处理，例如 `Create Table` 语句中 `Engine`，是解析并忽略。 - -> **注意：** -> -> 本页内容仅涉及 MySQL 与 TiDB 的总体差异。关于[安全特性](/dev/reference/security/compatibility.md)、[悲观事务模型](/dev/reference/transactions/transaction-pessimistic.md#和-mysql-innodb-的差异)的兼容信息请查看各自具体页面。 - -## 不支持的特性 - -* 存储过程与函数 -* 触发器 -* 事件 -* 自定义函数 -* 外键约束 -* 全文/空间函数与索引 -* 非 `ascii`/`latin1`/`binary`/`utf8`/`utf8mb4` 的字符集 -* `BINARY` 之外的排序规则 -* 增加/删除主键 -* SYS schema -* MySQL 追踪优化器 -* XML 函数 -* X Protocol -* Savepoints -* 列级权限 -* `XA` 语法（TiDB 内部使用两阶段提交，但并没有通过 SQL 接口公开） -* `CREATE TABLE tblName AS SELECT stmt` 语法 -* `CREATE TEMPORARY TABLE` 语法 -* `CHECK TABLE` 语法 -* `CHECKSUM TABLE` 语法 -* `SELECT INTO FILE` 语法 - -## 与 MySQL 有差异的特性 - -### 自增 ID - -TiDB 中，自增列只保证自增且唯一，并不保证连续分配。TiDB 目前采用批量分配 ID 的方式，所以如果在多台 TiDB 上同时插入数据，分配的自增 ID 会不连续。 - -在集群中有多个 tidb-server 实例时，如果表结构中有自增 ID，建议不要混用缺省值和自定义值，否则在如下情况下会遇到问题。 - -假设有这样一个带有自增 ID 的表： - -{{< copyable "sql" >}} - -```sql -create table t(id int unique key AUTO_INCREMENT, c int); -``` - -TiDB 实现自增 ID 的原理是每个 tidb-server 实例缓存一段 ID 值用于分配（目前会缓存 30000 个 ID），用完这段值再去取下一段。 - -假设集群中有两个 tidb-server 实例 A 和 B（A 缓存 [1,30000] 的自增 ID，B 缓存 [30001,60000] 的自增 ID），依次执行如下操作： - -1. 客户端向 B 插入一条将 `id` 设置为 1 的语句 `insert into t values (1, 1)`，并执行成功。 -2. 客户端向 A 发送 Insert 语句 `insert into t (c) (1)`，这条语句中没有指定 `id` 的值，所以会由 A 分配，当前 A 缓存了 [1, 30000] 这段 ID，所以会分配 1 为自增 ID 的值，并把本地计数器加 1。而此时数据库中已经存在 `id` 为 1 的数据，最终返回 `Duplicated Error` 错误。 - -另外，从 TiDB 2.1.18 和 3.0.4 版本开始，TiDB 将通过系统变量 `@@tidb_allow_remove_auto_inc` 控制是否允许通过 `alter table modify` 或 `alter table change` 来移除列的 `AUTO_INCREMENT` 属性，默认是不允许移除。 - -### Performance schema - -Performance schema 表在 TiDB 中返回结果为空。TiDB 使用 [Prometheus 和 Grafana](/dev/how-to/monitor/monitor-a-cluster.md) 来监测性能指标。 - -从 TiDB 3.0.4 版本开始，TiDB 支持 `events_statements_summary_by_digest`，参见 [Statement Summary Table](/dev/reference/performance/statement-summary.md)。 - -### 查询计划 - -TiDB 的查询计划（`EXPLAIN`/`EXPLAIN FOR`）输出格式与 MySQL 差别较大，同时 `EXPLAIN FOR` 的输出内容与权限设置与 MySQL 不一致，参见[理解 TiDB 执行计划](/dev/reference/performance/understanding-the-query-execution-plan.md)。 - -### 内建函数 - -TiDB 支持常用的 MySQL 内建函数，但是不是所有的函数都已经支持，具体请参考[语法文档](https://pingcap.github.io/sqlgram/#functioncallkeyword)。 - -### DDL - -在 TiDB 中，运行的 DDL 操作不会影响对表的读取或写入。但是，目前 DDL 变更有如下一些限制： - -+ Add Index - - 不支持同时创建多个索引 - - 不支持 `VISIBLE/INVISIBLE` 的索引 - - 不支持通过 `ALTER TABLE` 在所生成的列上添加索引 - - 其他类型的 Index Type (HASH/BTREE/RTREE) 只有语法支持，功能不支持 -+ Add Column - - 不支持同时创建多个列 - - 不支持将新创建的列设为主键或唯一索引，也不支持将此列设成 AUTO_INCREMENT 属性 -+ Drop Column: 不支持删除主键列或索引列 -+ Change/Modify Column - - 不支持有损变更，比如从 `BIGINT` 变为 `INTEGER`，或者从 `VARCHAR(255)` 变为 `VARCHAR(10)` - - 不支持修改 `DECIMAL` 类型的精度 - - 不支持更改 `UNSIGNED` 属性 - - 只支持将 `CHARACTER SET` 属性从 `utf8` 更改为 `utf8mb4` -+ Alter Database - - 只支持将 `CHARACTER SET` 属性从 `utf8` 更改为 `utf8mb4` -+ `LOCK [=] {DEFAULT|NONE|SHARED|EXCLUSIVE}`: TiDB 支持的语法，但是在 TiDB 中不会生效。所有支持的 DDL 变更都不会锁表。 -+ `ALGORITHM [=] {DEFAULT|INSTANT|INPLACE|COPY}`: TiDB 完全支持 `ALGORITHM=INSTANT` 和 `ALGORITHM=INPLACE` 语法，但运行过程与 MySQL 有所不同，因为 MySQL 中的一些 `INPLACE` 操作实际上是 TiDB 中的 `INSTANT` 操作。`ALGORITHM=COPY` 语法在 TiDB 中不会生效，会返回警告信息。 -+ Table Option 不支持以下语法 - - `WITH/WITHOUT VALIDATION` - - `SECONDARY_LOAD/SECONDARY_UNLOAD` - - `CHECK/DROP CHECK` - - `STATS_AUTO_RECALC/STATS_SAMPLE_PAGES` - - `SECONDARY_ENGINE` - - `ENCRYPTION` -+ Table Partition 不支持以下语法 - - `PARTITION BY LIST` - - `PARTITION BY KEY` - - `SUBPARTITION` - - `{CHECK|EXCHANGE|TRUNCATE|OPTIMIZE|REPAIR|IMPORT|DISCARD|REBUILD|REORGANIZE} PARTITION` - -### `ANALYZE TABLE` - -- [`ANALYZE TABLE`](/dev/reference/performance/statistics.md#手动收集) 语句在 TiDB 和 MySQL 中表现不同。在 MySQL/InnoDB 中，它是一个轻量级语句，执行过程较短；而在 TiDB 中，它会完全重构表的统计数据，语句执行过程较长。 - -### 视图 - -目前 TiDB 不支持对视图进行 `UPDATE`、`INSERT`、`DELETE` 等写入操作。 - -### 存储引擎 - -出于兼容性原因，TiDB 支持使用备用存储引擎创建表的语法。元数据命令将表描述为 InnoDB 存储引擎： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE t1 (a INT) ENGINE=MyISAM; -``` - -``` -Query OK, 0 rows affected (0.14 sec) -``` - -{{< copyable "sql" >}} - -```sql -SHOW CREATE TABLE t1; -``` - -``` -*************************** 1. row *************************** - Table: t1 -Create Table: CREATE TABLE `t1` ( - `a` int(11) DEFAULT NULL -) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin -1 row in set (0.00 sec) -``` - -从架构上讲，TiDB 确实支持类似 MySQL 的存储引擎抽象，在启动 TiDB（通常是 `tikv`）时 [`--store`](/dev/reference/configuration/tidb-server/configuration.md#store) 选项指定的引擎中创建用户表。 - -### SQL 模式 - -TiDB 支持 MySQL 5.7 中 **绝大多数的 SQL 模式**，以下几种模式除外： - -- TiDB 不支持兼容模式（例如 `ORACLE` 和 `POSTGRESQL`）。MySQL 5.7 已弃用兼容模式，MySQL 8.0 已移除兼容模式。 -- TiDB 中的 `ONLY_FULL_GROUP_BY` 与 MySQL 5.7 相比有细微的[语义差别](/dev/reference/sql/functions-and-operators/aggregate-group-by-functions.md#与-mysql-的区别)，此问题日后将予以解决。 -- `NO_DIR_IN_CREATE` 和 `NO_ENGINE_SUBSTITUTION` 这两种 SQL 模式用于解决兼容问题，但并不适用于 TiDB。 - -### 默认设置的区别 - -+ 默认字符集与 MySQL 不同： - + TiDB 中为 `utf8mb4` - + MySQL 5.7 中为 `latin1`，MySQL 8.0 中修改为 `utf8mb4` -+ 默认排序规则不同： - + TiDB 中，`utf8mb4` 的默认排序规则为 `utf8mb4_bin` - + MySQL 5.7 中，`utf8mb4` 的默认排序规则为 `utf8mb4_general_ci`，MySQL 8.0 中修改为 `utf8mb4_0900_ai_ci` - + 请使用 [`SHOW CHARACTER SET`](/dev/reference/sql/statements/show-character-set.md) 语句查看所有字符集的默认排序规则 -+ `foreign_key_checks` 的默认值不同： - + TiDB 中该值默认为 `OFF`，并且目前 TiDB 只支持设置该值为 `OFF`。 - + MySQL 5.7 中该值默认为 `ON`。 -+ 默认 SQL mode 与 MySQL 5.7 相同，与 MySQL 8.0 不同： - + TiDB 中为 `ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION` - + MySQL 中默认设置： - + MySQL 5.7 的默认 SQL mode 与 TiDB 相同 - + MySQL 8.0 中为 `ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION` -+ `lower_case_table_names` 的默认值不同： - + TiDB 中该值默认为 2，并且目前 TiDB 只支持设置该值为 2 - + MySQL 中默认设置： - + Linux 系统中该值为 0 - + Windows 系统中该值为 1 - + macOS 系统中该值为 2 -+ `explicit_defaults_for_timestamp` 的默认值不同： - + TiDB 中该值默认为 `ON`，并且目前 TiDB 只支持设置该值为 `ON` - + MySQL 中默认设置： - + MySQL 5.7：`OFF` - + MySQL 8.0：`ON` - -### 日期时间处理的区别 - -#### 时区 - -MySQL 默认使用本地时区，依赖于系统内置的当前的时区规则（例如什么时候开始夏令时等）进行计算；且在未[导入时区表数据](https://dev.mysql.com/doc/refman/8.0/en/time-zone-support.html#time-zone-installation)的情况下不能通过时区名称来指定时区。 - -TiDB 不需要导入时区表数据也能使用所有时区名称，采用系统当前安装的所有时区规则进行计算（一般为 `tzdata` 包），且无法通过导入时区表数据的形式修改计算规则。 - -> **注意：** -> -> 能下推到 TiKV 的时间相关表达式会由 TiKV 进行计算。TiKV 总是采用 TiKV 内置时区规则计算，而不依赖于系统所安装的时区规则。若系统安装的时区规则与 TiKV 内置的时区规则版本不匹配，则在少数情况下可能发生能插入的时间数据无法再读出来的问题。例如，若系统上安装了 tzdata 2018a 时区规则，则在时区设置为 Asia/Shanghai 或时区设置为本地时区且本地时区为 Asia/Shanghai 的情况下，时间 `1988-04-17 02:00:00` 可以被正常插入 TiDB 3.0 RC.1，但该记录对于特定类型 SQL 则无法再读出来，原因是 TiKV 3.0 RC.1 依据的 tzdata 2018i 规则中该时间在 Asia/Shanghai 时区中不存在（夏令时时间后移一小时）。 -> -> TiKV 各个版本内置的时区规则如下： -> -> - 3.0.0 RC.1 及以后：[tzdata 2018i](https://github.com/eggert/tz/tree/2018i) -> - 2.1.0 RC.1 及以后：[tzdata 2018e](https://github.com/eggert/tz/tree/2018e) - -#### 零月和零日 - -目前 TiDB 尚不能完整支持月为 `0` 或日为 `0`（但年不为 `0`）的日期。在非严格模式下，此类日期时间能被正常插入。但对于特定类型的 SQL 语句，可能出现无法读出来的情况。 - -#### 字符串类型行末空格的处理 - -目前 TiDB 在进行数据插入时，对于 `VARCHAR` 类型会保留行末空格，对于 `CHAR` 类型会插入截断空格后的数据。在没有索引的情况下，TiDB 和 MySQL 行为保持一致。如果 `VARCHAR` 类型上有 `UNIQUE` 索引，MySQL 在判断是否重复的时候，和处理 `CHAR` 类型一样，先截断 `VARCHAR` 数据末行空格再作判断；TiDB 则是按照保留空格的情况处理。 - -在做比较时，MySQL 会先截去常量和 Column 的末尾空格再作比较，而 TiDB 则是保留常量和 Column 的末尾空格来做精确比较。 - -### 类型系统的区别 - -以下的列类型 MySQL 支持，但 TiDB 不支持： - -+ FLOAT4/FLOAT8 -+ FIXED (alias for DECIMAL) -+ SERIAL (alias for BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE) -+ SQL_TSI_* （包括 SQL_TSI_YEAR、SQL_TSI_MONTH、SQL_TSI_WEEK、SQL_TSI_DAY、SQL_TSI_HOUR、SQL_TSI_MINUTE 和 SQL_TSI_SECOND） diff --git a/dev/reference/performance/check-cluster-status-using-sql-statements.md b/dev/reference/performance/check-cluster-status-using-sql-statements.md deleted file mode 100644 index 9fe477c2fb53..000000000000 --- a/dev/reference/performance/check-cluster-status-using-sql-statements.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: 使用 SQL 语句检查 TiDB 集群状态 -category: reference ---- - -# 使用 SQL 语句检查 TiDB 集群状态 - -为了方便排查问题，TiDB 提供了一些 SQL 语句和系统表以查询一些有用的信息。 - -`INFORMATION_SCHEMA` 中提供了如下几个系统表，用于查询集群状态，诊断常见的集群问题。 - -- [`TABLES`](/dev/reference/system-databases/information-schema.md#tables-表) -- [`TIDB_INDEXES`](/dev/reference/system-databases/information-schema.md#tidb_indexes-表) -- [`ANALYZE_STATUS`](/dev/reference/system-databases/information-schema.md#analyze_status-表) -- [`TIDB_HOT_REGIONS`](/dev/reference/system-databases/information-schema.md#tidb_hot_regions-表) -- [`TIKV_STORE_STATUS`](/dev/reference/system-databases/information-schema.md#tikv_store_status-表) -- [`TIKV_REGION_STATUS`](/dev/reference/system-databases/information-schema.md#tikv_region_status-表) -- [`TIKV_REGION_PEERS`](/dev/reference/system-databases/information-schema.md#tikv_region_peers-表) - -除此之外，执行下列语句也可获得对排查问题或查询集群状态有用的信息： - -- `ADMIN SHOW DDL` 可以获得是 `DDL owner` 角色的 TiDB 的 ID 及 `IP:PORT` 等具体信息。 -- `SHOW ANALYZE STATUS` 和 [`ANALYZE_STATUS`](/dev/reference/system-databases/information-schema.md#analyze_status-表) 表的功能相同。 -- 特殊的 `EXPLAIN` 语句： - - `EXPLAIN ANALYZE` 语句可以获得一个 SQL 语句执行中的一些具体信息。 - - `EXPLAIN FOR CONNECTION` 可以获得一个连接中最后执行的查询的执行计划。可以配合 `SHOW PROCESSLIST` 使用。 - - 关于 `EXPLAIN` 相关的更具体的信息，参考文档[理解 TiDB 执行计划](/dev/reference/performance/understanding-the-query-execution-plan.md)。 diff --git a/dev/reference/performance/execution-plan-bind.md b/dev/reference/performance/execution-plan-bind.md deleted file mode 100644 index 1683b8e1bc71..000000000000 --- a/dev/reference/performance/execution-plan-bind.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: 执行计划绑定 -category: reference ---- - -# 执行计划绑定 - -在[优化器 Hints](/dev/reference/performance/optimizer-hints.md) 中介绍了可以通过 Hint 的方式选择指定的执行计划，但有的时候需要在不修改 SQL 语句的情况下干预执行计划的选择。执行计划绑定提供了一系列功能使得可以在不修改 SQL 语句的情况下选择指定的执行计划。 - -## 语法 - -### 创建绑定 - -{{< copyable "sql" >}} - -```sql -CREATE [GLOBAL | SESSION] BINDING FOR SelectStmt USING SelectStmt; -``` - -该语句可以在 GLOBAL 或者 SESSION 作用域内为 SQL 绑定执行计划。在不指定作用域时，隐式作用域为 SESSION。被绑定的 SQL 会被参数化后存储到系统表中。在处理 SQL 查询时，只要参数化后的 SQL 和系统表中某个被绑定的 SQL 语句一致，并且系统变量 `tidb_use_plan_baselines` 的值为 `on`（其默认值为 `on`），即可使用相应的优化器 Hint。如果存在多个可匹配的执行计划，优化器会从中选择代价最小的一个进行绑定。 - -`参数化`：把 SQL 中的常量变成变量参数，并对 SQL 中的空格和换行符等做标准化处理。例如： - -```sql -select * from t where a > 1 --- 参数化后： -select * from t where a > ？ -``` - -需要注意的是原始 SQL 和绑定 SQL 在参数化以及去掉 Hint 后文本必须相同，否则创建会失败，例如： - -{{< copyable "sql" >}} - -```sql -CREATE BINDING FOR SELECT * FROM t WHERE a > 1 USING SELECT * FROM t use index(idx) WHERE a > 2; -``` - -可以创建成功，因为原始 SQL 和绑定 SQL 在参数化以及去掉 Hint 后文本都是 `select * from t where a > ?`，而 - -{{< copyable "sql" >}} - -```sql -CREATE BINDING FOR SELECT * FROM t WHERE a > 1 USING SELECT * FROM t use index(idx) WHERE b > 2; -``` - -则不可以创建成功，因为原始 SQL 在经过处理后是 `select * from t where a > ?`，而绑定 SQL 在经过处理后是 `select * from t where b > ?`。 - -### 删除绑定 - -{{< copyable "sql" >}} - -```sql -DROP [GLOBAL | SESSION] BINDING FOR SelectStmt; -``` - -该语句可以在 GLOBAL 或者 SESSION 作用域内删除指定的执行计划绑定，在不指定作用域时默认作用域为 SESSION。 - -### 查看绑定 - -{{< copyable "sql" >}} - -```sql -SHOW [GLOBAL | SESSION] BINDINGS [ShowLikeOrWhere]; -``` - -该语句会输出 GLOBAL 或者 SESSION 作用域内的执行计划绑定，在不指定作用域时默认作用域为 SESSION。目前 `SHOW BINDINGS` 会输出 8 列，具体如下： - -| 列名 | 说明 | -| -------- | ------------- | -| original_sql | 参数化后的原始 SQL | -| bind_sql | 带 Hint 的绑定 SQL | -| default_db | 默认数据库名 | -| status | 状态，包括 using（正在使用）、deleted（已删除）和 invalid（无效） | -| create_time | 创建时间 | -| update_time | 更新时间 | -| charset | 字符集 | -| collation | 排序规则 | - -### 自动创建绑定 - -通过将 `tidb_capture_plan_baselines` 的值设置为 `on`（其默认值为 `off`）可以打开自动创建绑定功能。 - -> **注意：** -> -> 自动绑定功能依赖于 [Statement Summary](/dev/reference/performance/statement-summary.md)，因此在使用自动绑定之前需打开 Statement Summary 开关。 - -开启自动绑定功能后，每隔 `bind-info-lease`（默认值为 `3s`）会遍历一次 Statement Summary 中的历史 SQL 语句，并为至少出现两次的 SQL 语句自动创建绑定。 - -### 自动演进绑定 - -随着数据的变更，有可能原先绑定的执行计划已经不是最优的了，自动演进绑定功能可以自动优化已经绑定的执行计划。 - -{{< copyable "sql" >}} - -```sql -set global tidb_evolve_plan_baselines = on; -``` - -`tidb_evolve_plan_baselines` 的默认值为 `off`。 - -在打开自动演进功能后，如果优化器选出的最优执行计划不在之前绑定的执行计划之中，会将其记录为待验证的执行计划。每隔 `bind-info-lease`（默认值为 `3s`），会选出一个待验证的执行计划，将其和已经绑定的执行计划中代价最小的比较实际运行时间。如果待验证的运行时间更优的话，会将其标记为可使用的绑定。 - -为了减少自动演进对集群的影响，可以通过 `tidb_evolve_plan_task_max_time` 来限制每个执行计划运行的最长时间，其默认值为 `600s`；通过 `tidb_evolve_plan_task_start_time` 和 `tidb_evolve_plan_task_end_time` 可以限制运行演进任务的时间窗口，默认值分别为 `00:00 +0000` 和 `23:59 +0000`。 diff --git a/dev/reference/performance/follower-read.md b/dev/reference/performance/follower-read.md deleted file mode 100644 index 48ea4ef91bec..000000000000 --- a/dev/reference/performance/follower-read.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: Follower Read -summary: 了解 Follower Read 的使用与实现。 -category: reference ---- - -# Follower Read - -当系统中存在读取热点 Region 导致 leader 资源紧张成为整个系统读取瓶颈时，启用 Follower Read 功能可明显降低 leader 的负担，并且通过在多个 follower 之间均衡负载，显著地提升整体系统的吞吐能力。本文主要介绍 Follower Read 的使用方法与实现机制。 - -## 概述 - -Follower Read 功能是指在强一致性读的前提下使用 Region 的 follower 副本来承载数据读取的任务，从而提升 TiDB 集群的吞吐能力并降低 leader 负载。Follower Read 包含一系列将 TiKV 读取负载从 Region 的 leader 副本上 offload 到 follower 副本的负载均衡机制。TiKV 的 Follower Read 可以保证数据读取的线性一致性，配合 TiDB Snapshot Isolation 事务隔离级别，可以为用户提供强一致的数据读取能力。 - -> **注意：** -> -> 为了获得强一致读取的能力，在当前的实现中，follower 节点需要额外付出 `ReadIndex` 开销，因此目前 Follower Read 的主要益处是隔离集群的读写请求以及提升整体读取吞吐。从单个请求的 latency 角度看，会比传统的 leader 读取多付出一次与 Raft `ReadIndex` 的交互开销。 - -## 使用方式 - -要开启 TiDB 的 Follower Read 功能，将 SESSION 变量 `tidb_replica_read` 的值设置为 `follower` 即可： - -{{< copyable "sql" >}} - -```sql -set @@tidb_replica_read = 'follower'; -``` - -作用域：SESSION - -默认值：leader - -该变量用于设置当前会话期待的数据读取方式。 - -- 当设定为默认值 `leader` 或者空字符串时，TiDB 会维持原有行为方式，将所有的读取操作都发送给 leader 副本处理。 -- 当设置为 `follower` 时，TiDB 会选择 Region 的 follower 副本完成所有的数据读取操作。 - -## 实现机制 - -在 Follower Read 功能出现之前，TiDB 采用 strong leader 策略将所有的读写操作全部提交到 Region 的 leader 节点上完成。虽然 TiKV 能够很均匀地将 Region 分散到多个物理节点上，但是对于每一个 Region 来说，只有 leader 副本能够对外提供服务，另外的 follower 除了时刻同步数据准备着 failover 时投票切换成为 leader 外，没有办法对 TiDB 的请求提供任何帮助。 - -为了允许在 TiKV 的 follower 节点进行数据读取，同时又不破坏线性一致性和 Snapshot Isolation 的事务隔离，Region 的 follower 节点需要使用 Raft `ReadIndex` 协议确保当前读请求可以读到当前 leader 上已经 commit 的最新数据。在 TiDB 层面，Follower Read 只需根据负载均衡策略将某个 Region 的读取请求发送到 follower 节点。 - -### Follower 强一致读 - -TiKV follower 节点处理读取请求时，首先使用 Raft `ReadIndex` 协议与 Region 当前的 leader 进行一次交互，来获取当前 Raft group 最新的 commit index。本地 apply 到所获取的 leader 最新 commit index 后，便可以开始正常的读取请求处理流程。 - -### Follower 副本选择策略 - -由于 TiKV 的 Follower Read 可以保证线性一致性，不会破坏 TiDB 的 Snapshot Isolation 事务隔离级别，因此 TiDB 选择 follower 的策略可以采用 round robin 的方式。虽然 TiKV 可以选择任意的 follower 处理任意读取请求，但考虑到多个 follower 间复制速度不同，如果负载均衡的粒度过细，可能会导致明显的 latency 波动。目前，Follower Read 负载均衡策略粒度是连接级别的，对于一个 TiDB 的客户端连接在某个具体的 Region 上会固定使用同一个 follower，只有在选中的 follower 发生故障或者因调度策略发生调整的情况下才会进行切换。 diff --git a/dev/reference/performance/index-merge.md b/dev/reference/performance/index-merge.md deleted file mode 100644 index 667f9f839b0f..000000000000 --- a/dev/reference/performance/index-merge.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: 使用 Index Merge 方式访问表 -category: reference ---- - -# 使用 Index Merge 方式访问表 - -`IndexMerge` 是在 TiDB 4.0 引入的一种对表的新访问方式。在 `IndexMerge` 访问方式下，优化器可以选择对一张表使用多个索引，并将每个索引的返回结果进行合并。在某些场景下，这种访问方式能够减少大量不必要的数据扫描，提升查询的执行效率。 - -本文介绍了 `IndexMerge` 的适用场景、实际用例以及开启方法。 - -## 适用场景 - -对于 SQL 查询中涉及的每一张表，以前的 TiDB 优化器在物理优化阶段，会根据代价估算从以下三种表访问方式中选择一种： - -- `TableScan`：以 `_tidb_rowid` 为 key 对表数据进行扫描； -- `IndexScan`：以索引列的值为 key 对索引数据进行扫描； -- `IndexLookUp`：先用索引列的值为 key 从索引获取到 `_tidb_rowid` 集合，再回表取出对应的数据行； - -这三种方式对每张表最多只能使用一个索引，在有些情况下选出的执行计划并不是最优的，比如： - -{{< copyable "sql" >}} - -```sql -create table t(a int, b int, c int, unique key(a), unique key(b)); -explain select * from t where a = 1 or b = 1; -``` - -由于查询的过滤条件是一个通过 `OR` 连接的表达式，我们在只能对每张表使用一个索引的限制下，无法将 `a = 1` 下推到索引 `a` 上，或将 `b = 1` 下推到索引 `b` 上，因此为了保证结果正确性，对这个查询只能生成 `TableScan` 的执行计划： - -``` -+---------------------+----------+-----------+------------------------------------------------------------+ -| id | count | task | operator info | -+---------------------+----------+-----------+------------------------------------------------------------+ -| TableReader_7 | 8000.00 | root | data:Selection_6 | -| └─Selection_6 | 8000.00 | cop[tikv] | or(eq(test.t.a, 1), eq(test.t.b, 1)) | -| └─TableScan_5 | 10000.00 | cop[tikv] | table:t, range:[-inf,+inf], keep order:false, stats:pseudo | -+---------------------+----------+-----------+------------------------------------------------------------+ -``` - -当 `t` 的数据量很大时，全表扫描的效率会很低，但这条查询最多却只会返回两行记录。针对这类场景，TiDB 引入了对表的新访问方式 `IndexMerge`。 - -## 实际用例 - -在 `IndexMerge` 访问方式下，优化器可以选择对一张表使用多个索引，并将每个索引的返回结果进行集合并操作。以上面查询为例，生成的执行计划将会变为： - -``` -+--------------------+-------+-----------+---------------------------------------------------------------+ -| id | count | task | operator info | -+--------------------+-------+-----------+---------------------------------------------------------------+ -| IndexMerge_11 | 2.00 | root | | -| ├─IndexScan_8 | 1.00 | cop[tikv] | table:t, index:a, range:[1,1], keep order:false, stats:pseudo | -| ├─IndexScan_9 | 1.00 | cop[tikv] | table:t, index:b, range:[1,1], keep order:false, stats:pseudo | -| └─TableScan_10 | 2.00 | cop[tikv] | table:t, keep order:false, stats:pseudo | -+--------------------+-------+-----------+---------------------------------------------------------------+ -``` - -`IndexMerge` 执行计划的结构和 `IndexLookUp` 很接近，都可以分为索引扫描和全表扫描两部分，只是 `IndexMerge` 的索引扫描部分可以包含多个 `IndexScan`，当表的主键索引是整数类型时，索引扫描部分甚至可能包含一个 `TableScan`，比如： - -{{< copyable "sql" >}} - -```sql -create table t(a int primary key, b int, c int, unique key(b)); -``` - -``` -Query OK, 0 rows affected (0.01 sec) -``` - -{{< copyable "sql" >}} - -```sql -explain select * from t where a = 1 or b = 1; -``` - -``` -+--------------------+-------+-----------+---------------------------------------------------------------+ -| id | count | task | operator info | -+--------------------+-------+-----------+---------------------------------------------------------------+ -| IndexMerge_11 | 2.00 | root | | -| ├─TableScan_8 | 1.00 | cop[tikv] | table:t, range:[1,1], keep order:false, stats:pseudo | -| ├─IndexScan_9 | 1.00 | cop[tikv] | table:t, index:b, range:[1,1], keep order:false, stats:pseudo | -| └─TableScan_10 | 2.00 | cop[tikv] | table:t, keep order:false, stats:pseudo | -+--------------------+-------+-----------+---------------------------------------------------------------+ -4 rows in set (0.01 sec) -``` - -值得注意的是，目前 `IndexMerge` 被限定为只在无法使用单个索引时候才会被考虑，假如上述查询中的条件变为 `a = 1 and b = 1`，优化器只会考虑使用索引 `a` 或 `b` 访问，而不会选择 `IndexMerge`。 - -## 开启方法 - -默认设置下，`IndexMerge` 是关闭的，开启的方法有两种： - -- 设置系统变量 `tidb_enable_index_merge` 为 1； -- 在查询中使用 SQL Hint [`USE_INDEX_MERGE`](/dev/reference/performance/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)； - - > **注意：** - > - > SQL Hint 的优先级高于系统变量。 diff --git a/dev/reference/performance/optimizer-hints.md b/dev/reference/performance/optimizer-hints.md deleted file mode 100644 index ca36499ef30b..000000000000 --- a/dev/reference/performance/optimizer-hints.md +++ /dev/null @@ -1,268 +0,0 @@ ---- -title: Optimizer Hints -category: reference ---- - -# Optimizer Hints - -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`。 - -## 语法 - -Optimizer Hints 通过 `/*+ ... */` 注释的形式跟在 `SELECT`、`UPDATE` 或 `DELETE` 关键字的后面，常见形式如 `/*+ HINT_NAME([t1_name [, t2_name] ...]) */`。Hint 名称不区分大小写，多个不同的 Hint 之间需用逗号隔开。例如： - -{{< copyable "sql" >}} - -```sql -select /*+ USE_INDEX(t1, idx1), HASH_AGG(), HASH_JOIN(t1) */ count(*) from t t1, t t2 where t1.a = t2.b; -``` - -TiDB 目前支持两类 Hint，具体用法上有一些差别。第一类 Hint 用于控制优化器的行为，例如 [`/*+ HASH_AGG() */`](#hash_agg)。第二类 Hint 用于对单条查询设置一些运行参数，例如 [`/*+ MEMORY_QUOTA(1024 MB)*/`](#memory_quotan)。 - -## 优化器相关 Hint 语法 - -用于控制优化器行为的 Hint 跟在语句中**任意** `SELECT`、`UPDATE` 或 `DELETE` 关键字的后面。Hint 的生效范围以及 Hint 中使用的表的生效范围可通过 [Query Block](#query-block) 来指定，若不显式地指定 Query Block， Hint 的默认生效范围为当前 Query Block。 - -### Query Block - -一条语句中每一个查询和子查询都对应着一个不同的 Query Block，每个 Query Block 有自己对应的 `QB_NAME`。以下面这条语句为例： - -{{< copyable "sql" >}} - -```sql -select * from (select * from t) t1, (select * from t) t2; -``` - -该查询语句有 3 个 Query Block，最外面一层 `SELECT` 所在的 Query Block 的 `QB_NAME` 为 `sel_1`，两个 `SELECT` 子查询的 `QB_NAME` 依次为 `sel_2` 和 `sel_3`。其中数字序号根据 `SELECT` 出现的位置从左到右计数。如果分别用 `DELETE` 和 `UPDATE` 查询替代第一个 `SELECT` 查询，则对应的 `QB_NAME` 分别为 `del_1` 和 `upd_1`。 - -### QB_NAME - -你可以为当前 Query Block 的 `QB_NAME` 指定新的值，同时原本默认的 `QB_NAME` 值仍然有效。例如： - -{{< copyable "sql" >}} - -```sql -select /*+ QB_NAME(QB1) */ * from (select * from t) t1, (select * from t) t2; -``` - -这条 Hint 将 `SELECT` 查询的 `QB_NAME` 设为 `QB1`，此时 `QB1` 和默认名称 `sel_1` 对于这个 Query Block 来说都是有效的。 - -> **注意：** -> -> 上述例子中，如果指定的 `QB_NAME` 为 `sel_2`，并且不给原本 `sel_2` 对应的第二个 Query Block 指定新的 `QB_NAME`，则第二个 Query Block 的 `QB_NAME` 默认值 `sel_2` 会失效。 - -### `@QB_NAME` 参数 - -除 `QB_NAME` 外，其余优化器相关的 Hint 都可以通过可选参数 `@QB_NAME` 来指定该 Hint 的生效范围。该参数需写在最前面，与其他参数用空格隔开。同时，你也可以在参数中的每一个表名后面加 `@QB_NAME` 来指定是哪个 Query Block 中的表。例如： - -{{< copyable "sql" >}} - -```sql -select /*+ HASH_JOIN(@sel_1 t1@sel_1, t3) */ * from (select t1.a, t1.b from t t1, t t2 where t1.a = t2.a) t1, t t3 where t1.b = t3.b; -``` - -### SM_JOIN(t1_name [, tl_name ...]) - -`SM_JOIN(t1_name [, tl_name ...])` 提示优化器对指定表使用 Sort Merge Join 算法。这个算法通常会占用更少的内存，但执行时间会更久。当数据量太大，或系统内存不足时，建议尝试使用。例如： - -{{< copyable "sql" >}} - -```sql -select /*+ SM_JOIN(t1, t2) */ * from t1，t2 where t1.id = t2.id; -``` - -> **注意：** -> -> `SM_JOIN` 的别名是 `TIDB_SMJ`，在 3.0.x 及之前版本仅支持使用该别名；之后的版本同时支持使用这两种名称。 - -### INL_JOIN(t1_name [, tl_name ...]) - -`INL_JOIN(t1_name [, tl_name ...])` 提示优化器对指定表使用 Index Nested Loop Join 算法。这个算法可能会在某些场景更快，消耗更少系统资源，有的场景会更慢，消耗更多系统资源。对于外表经过 WHERE 条件过滤后结果集较小（小于 1 万行）的场景，可以尝试使用。例如： - -{{< copyable "sql" >}} - -```sql -select /*+ INL_JOIN(t1, t2) */ * from t1，t2 where t1.id = t2.id; -``` - -`INL_JOIN()` 中的参数是建立查询计划时内表的候选表，比如 `INL_JOIN(t1)` 只会考虑使用 t1 作为内表构建查询计划。表如果指定了别名，就只能使用表的别名作为 `INL_JOIN()` 的参数；如果没有指定别名，则用表的本名作为其参数。比如在 `select /*+ INL_JOIN(t1) */ * from t t1, t t2 where t1.a = t2.b;` 中，`INL_JOIN()` 的参数只能使用 t 的别名 t1 或 t2，不能用 t。 - -> **注意：** -> -> `INL_JOIN` 的别名是 `TIDB_INLJ`，在 3.0.x 及之前版本仅支持使用该别名；之后的版本同时支持使用这两种名称。 - -### INL_HASH_JOIN - -`INL_HASH_JOIN(t1_name [, tl_name])` 提示优化器使用 Index Nested Loop Hash Join 算法。该算法与 Index Nested Loop Join 使用条件完全一样，但在某些场景下会更为节省内存资源。 - -### INL_MERGE_JOIN - -`INL_MERGE_JOIN(t1_name [, tl_name])` 提示优化器使用 Index Nested Loop Merge Join 算法。该算法相比于 `INL_JOIN` 会更节省内存。该算法使用条件包含 `INL_JOIN` 的所有使用条件，但还需要添加一条：join keys 中的内表列集合是内表使用的 index 的前缀，或内表使用的 index 是 join keys 中的内表列集合的前缀。 - -### HASH_JOIN(t1_name [, tl_name ...]) - -`HASH_JOIN(t1_name [, tl_name ...])` 提示优化器对指定表使用 Hash Join 算法。这个算法多线程并发执行，执行速度较快，但会消耗较多内存。例如： - -{{< copyable "sql" >}} - -```sql -select /*+ HASH_JOIN(t1, t2) */ * from t1，t2 where t1.id = t2.id; -``` - -> **注意：** -> -> `HASH_JOIN` 的别名是 `TIDB_HJ`，在 3.0.x 及之前版本仅支持使用该别名；之后的版本同时支持使用这两种名称。 - -### HASH_AGG() - -`HASH_AGG()` 提示优化器使用 Hash Aggregation 算法。这个算法多线程并发执行，执行速度较快，但会消耗较多内存。例如： - -{{< copyable "sql" >}} - -```sql -select /*+ HASH_AGG() */ count(*) from t1，t2 where t1.a > 10 group by t1.id; -``` - -### STREAM_AGG() - -`STREAM_AGG()` 提示优化器使用 Stream Aggregation 算法。这个算法通常会占用更少的内存，但执行时间会更久。数据量太大，或系统内存不足时，建议尝试使用。例如： - -{{< copyable "sql" >}} - -```sql -select /*+ STREAM_AGG() */ count(*) from t1，t2 where t1.a > 10 group by t1.id; -``` - -### USE_INDEX(t1_name, idx1_name [, idx2_name ...]) - -`USE_INDEX(t1_name, idx1_name [, idx2_name ...])` 提示优化器对指定表仅使用给出的索引。 - -下面例子的效果等价于 `select * from t t1 use index(idx1, idx2);`： - -{{< copyable "sql" >}} - -```sql -select /*+ USE_INDEX(t1, idx1, idx2) */ * from t t1; -``` - -### IGNORE_INDEX(t1_name, idx1_name [, idx2_name ...]) - -`IGNORE_INDEX(t1_name, idx1_name [, idx2_name ...])` 提示优化器对指定表忽略给出的索引。 - -下面例子的效果等价于 `select * from t t1 ignore index(idx1, idx2);`： - -{{< copyable "sql" >}} - -```sql -select /*+ IGNORE_INDEX(t1, idx1, idx2) */ * from t t1; -``` - -### AGG_TO_COP() - -`AGG_TO_COP()` 提示优化器将聚合操作下推到 coprocessor。如果优化器没有下推某些适合下推的聚合函数，建议尝试使用。例如： - -{{< copyable "sql" >}} - -```sql -select /*+ AGG_TO_COP() */ sum(t1.a) from t t1; -``` - -### READ_FROM_STORAGE(TIFLASH[t1_name [, tl_name ...]], TIKV[t2_name [, tl_name ...]]) - -`READ_FROM_STORAGE(TIFLASH[t1_name [, tl_name ...]], TIKV[t2_name [, tl_name ...]])` 提示优化器从指定的存储引擎来读取指定的表，目前支持的存储引擎参数有 `TIKV` 和 `TIFLASH`。例如： - -{{< copyable "sql" >}} - -```sql -select /*+ READ_FROM_STORAGE(TIFLASH[t1], TIKV[t2]) */ t1.a from t t1, t t2 where t1.a = t2.a; -``` - -### USE_INDEX_MERGE(t1_name, idx1_name [, idx2_name ...]) - -`USE_INDEX_MERGE(t1_name, idx1_name [, idx2_name ...])` 提示优化器通过 index merge 的方式来访问指定的表，其中索引列表为可选参数。若显式地指出索引列表，会尝试在索引列表中选取索引来构建 index merge。若不给出索引列表，会尝试在所有可用的索引中选取索引来构建 index merge。例如： - -{{< copyable "sql" >}} - -```sql -select /*+ USE_INDEX_MERGE(t1, idx_a, idx_b, idx_c) */ * from t t1 where t1.a > 10 or t1.b > 10; -``` - -## 运行参数相关 Hint 语法 - -运行参数相关的 Hint 只能跟在语句中**第一个** `SELECT`、`UPDATE` 或 `DELETE` 关键字的后面，对当前的这条查询的相关运行参数进行修改。 - -其优先级高于默认设置以及环境变量。 - -### MAX_EXECUTION_TIME(N) - -`MAX_EXECUTION_TIME(N)` 把语句的执行时间限制在 `N` 毫秒以内，超时后服务器会终止这条语句的执行。 - -下面的 Hint 设置了 1000 毫秒（即 1 秒）超时： - -{{< copyable "sql" >}} - -```sql -select /*+ MAX_EXECUTION_TIME(1000) */ * from t1 inner join t2 where t1.id = t2.id; -``` - -除了 Hint 之外，环境变量 `global.max_execution_time` 也能对语句执行时间进行限制。 - -### MEMORY_QUOTA(N) - -`MEMORY_QUOTA(N)` 用于限制语句执行时的内存使用。该 Hint 支持 MB 和 GB 两种单位。内存使用超过该限制时会根据当前设置的内存超限行为来打出一条 log 或者终止语句的执行。 - -下面的 Hint 设置了 1024 MB 的内存限制： - -{{< copyable "sql" >}} - -```sql -select /*+ MEMORY_QUOTA(1024 MB) */ * from t; -``` - -除了 Hint 外，环境变量 `tidb_mem_quota_query` 也能限制语句执行的内存使用。 - -### READ_FROM_REPLICA() - -`READ_FROM_REPLICA()` 会开启从数据一致的 TiKV follower 节点读取数据的特性。 - -下面的例子会从 follower 节点读取数据： - -{{< copyable "sql" >}} - -```sql -select /*+ READ_FROM_REPLICA() */ * from t; -``` - -除了 Hint 外，环境变量 `tidb_replica_read` 设为 `'follower'` 或者 `'leader'` 也能决定是否开启该特性。 - -### NO_INDEX_MERGE() - -`NO_INDEX_MERGE()` 会关闭优化器的 index merge 功能。 - -下面的例子不会使用 index merge： - -{{< copyable "sql" >}} - -```sql -select /*+ NO_INDEX_MERGE() */ * from t where t.a > 0 or t.b > 0; -``` - -除了 Hint 外，环境变量 `tidb_enable_index_merge` 也能决定是否开启该功能。 - -### USE_TOJA(boolean_value) - -参数 `boolean_value` 可以是 `TRUE` 或者 `FALSE`。`USE_TOJA(TRUE)` 会开启优化器尝试将 in (subquery) 条件转换为 join 和 aggregation 的功能。相对地，`USE_TOJA(FALSE)` 会关闭该功能。 - -下面的例子会将 `in (select t2.a from t2) subq` 转换为等价的 join 和 aggregation： - -{{< copyable "sql" >}} - -```sql -select /*+ USE_TOJA(TRUE) */ t1.a, t1.b from t1 where t1.a in (select t2.a from t2) subq; -``` - -除了 Hint 外，环境变量 `tidb_opt_insubq_to_join_and_agg` 也能决定是否开启该功能。 diff --git a/dev/reference/performance/sql-optimizer-overview.md b/dev/reference/performance/sql-optimizer-overview.md deleted file mode 100644 index 5d922ce54720..000000000000 --- a/dev/reference/performance/sql-optimizer-overview.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: SQL 优化流程简介 -category: reference ---- - -# SQL 优化流程简介 - -在 TiDB 中，SQL 优化过程分为逻辑优化和物理优化两个阶段。 - -## 逻辑优化简介 - -逻辑优化是基于规则的优化，对输入的逻辑执行计划按顺序应用一些优化规则，从而使整个逻辑执行计划变得更好。这些优化规则包括： - -- 列裁剪 -- 投影消除 -- 关联子查询去关联 -- Max/Min 消除 -- 谓词下推 -- 分区裁剪 -- TopN 和 Limit 下推 - -## 物理优化简介 - -物理优化是基于代价的优化，为上一阶段产生的逻辑执行计划制定物理执行计划。这一阶段中，优化器会为逻辑执行计划中的每个算子选择具体的物理实现。逻辑算子的不同物理实现有着不同的时间复杂度、资源消耗和物理属性等。在这个过程中，优化器会根据数据的统计信息来确定不同物理实现的代价，并选择整体代价最小的物理执行计划。 - -逻辑执行计划是一个树形结构，每个节点对应 SQL 中的一个逻辑算子。同样的，物理执行计划也是一个树形结构，每个节点对应 SQL 中的一个物理算子。逻辑算子只描述这个算子的功能，而物理算子则描述了完成这个功能的具体算法。对于同一个逻辑算子，可能有多个物理算子实现，比如 `LogicalAggregate`，它的实现可以是采用哈希算法的 `HashAggregate`，也可以是流式的 `StreamAggregate`。不同的物理算子具有不同的物理属性，也对其子节点有着不同的物理属性的要求。物理属性包括数据的顺序和分布等。TiDB 中现在只考虑了数据的顺序。 diff --git a/dev/reference/performance/statistics.md b/dev/reference/performance/statistics.md deleted file mode 100644 index fdfb144ee076..000000000000 --- a/dev/reference/performance/statistics.md +++ /dev/null @@ -1,321 +0,0 @@ ---- -title: 统计信息简介 -category: reference ---- - -# 统计信息简介 - -TiDB 优化器会根据统计信息来选择最优的执行计划。统计信息收集了表级别和列级别的信息，表的统计信息包括总行数和修改的行数。列的统计信息包括不同值的数量、NULL 的数量、直方图、列上出现次数最多的值 TOPN 以及该列的 Count-Min Sketch 信息。 - -## 统计信息的收集 - -### 手动收集 - -可以通过执行 `ANALYZE` 语句来收集统计信息。 - -#### 全量收集 - -> **注意：** -> -> 在 TiDB 中执行 `ANALYZE TABLE` 语句比在 MySQL 或 InnoDB 中耗时更长。InnoDB 采样的只是少量页面，但 TiDB 会完全重构一系列统计信息。适用于 MySQL 的脚本会误以为执行 `ANALYZE TABLE` 耗时较短。 -> -> 如需更快的分析速度，可将 `tidb_enable_fast_analyze` 设置为 `1` 来打开快速分析功能。该参数的默认值为 `0`。 -> -> 快速分析功能开启后，TiDB 会随机采样约 10000 行的数据来构建统计信息。因此在数据分布不均匀或者数据量比较少的情况下，统计信息的准确度会比较差。可能导致执行计划不优，比如选错索引。如果可以接受普通 `ANALYZE` 语句的执行时间，则推荐关闭快速分析功能。 - -可以通过以下几种语法进行全量收集。 - -收集 TableNameList 中所有表的统计信息： - -{{< copyable "sql" >}} - -```sql -ANALYZE TABLE TableNameList [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH|SAMPLES]; -``` - -- `WITH NUM BUCKETS` 用于指定生成直方图的桶数量上限。 -- `WITH NUM TOPN` 用于指定生成 TOPN 数目的上限。 -- `WITH NUM CMSKETCH DEPTH` 用于指定 CM Sketch 的长。 -- `WITH CMSKETCH WIDTH` 用于指定 CM Sketch 的宽。 -- `WITH NUM SAMPLES` 用于指定采样的数目。 - -收集 TableName 中所有的 IndexNameList 中的索引列的统计信息： - -{{< copyable "sql" >}} - -```sql -ANALYZE TABLE TableName INDEX [IndexNameList] [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH|SAMPLES]; -``` - -IndexNameList 为空时会收集所有索引列的统计信息。 - -收集 TableName 中所有的 PartitionNameList 中分区的统计信息： - -{{< copyable "sql" >}} - -```sql -ANALYZE TABLE TableName PARTITION PartitionNameList [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH|SAMPLES]; -``` - -收集 TableName 中所有的 PartitionNameList 中分区的索引列统计信息： - -{{< copyable "sql" >}} - -```sql -ANALYZE TABLE TableName PARTITION PartitionNameList [IndexNameList] [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH|SAMPLES]; -``` - -#### 增量收集 - -对于类似时间列这样的单调不减列，在进行全量收集后，可以使用增量收集来单独分析新增的部分，以提高分析的速度。 - -> **注意：** -> -> 1. 目前只有索引提供了增量收集的功能 -> 2. 使用增量收集时，必须保证表上只有插入操作，且应用方需要保证索引列上新插入的值是单调不减的，否则会导致统计信息不准，影响 TiDB 优化器选择合适的执行计划 - -可以通过以下几种语法进行增量收集。 - -增量收集 TableName 中所有的 IndexNameList 中的索引列的统计信息： - -{{< copyable "sql" >}} - -```sql -ANALYZE INCREMENTAL TABLE TableName INDEX [IndexNameList] [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH|SAMPLES]; -``` - -增量收集 TableName 中所有的 PartitionNameList 中分区的索引列统计信息： - -{{< copyable "sql" >}} - -```sql -ANALYZE INCREMENTAL TABLE TableName PARTITION PartitionNameList INDEX [IndexNameList] [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH|SAMPLES]; -``` - -### 自动更新 - -在发生增加，删除以及修改语句时，TiDB 会自动更新表的总行数以及修改的行数。这些信息会定期持久化下来， -更新的周期是 20 * `stats-lease`，`stats-lease` 的默认值是 3s，如果将其指定为 0，那么将不会自动更新。 - -和统计信息自动更新相关的三个系统变量如下： - -| 系统变量名 | 默认值 | 功能 | -|---|---|---| -| `tidb_auto_analyze_ratio`| 0.5 | 自动更新阈值 | -| `tidb_auto_analyze_start_time` | `00:00 +0000` | 一天中能够进行自动更新的开始时间 | -| `tidb_auto_analyze_end_time` | `23:59 +0000` | 一天中能够进行自动更新的结束时间 | - -当某个表 `tbl` 的修改行数与总行数的比值大于 `tidb_auto_analyze_ratio`，并且当前时间在 `tidb_auto_analyze_start_time` 和 `tidb_auto_analyze_end_time` 之间时，TiDB 会在后台执行 `ANALYZE TABLE tbl` 语句自动更新这个表的统计信息。 - -在查询语句执行时，TiDB 会以 `feedback-probability` 的概率收集反馈信息，并将其用于更新直方图和 Count-Min Sketch。`feedback-probability` 可通过配置文件修改，其默认值是 `0.0`。 - -### 控制 ANALYZE 并发度 - -执行 ANALYZE 语句的时候，你可以通过一些参数来调整并发度，以控制对系统的影响。 - -#### tidb_build_stats_concurrency - -目前 ANALYZE 执行的时候会被切分成一个个小的任务，每个任务只负责某一个列或者索引。`tidb_build_stats_concurrency` 可以控制同时执行的任务的数量，其默认值是 4。 - -#### tidb_distsql_scan_concurrency - -在执行分析普通列任务的时候，`tidb_distsql_scan_concurrency` 可以用于控制一次读取的 Region 数量，其默认值是 15。 - -#### tidb_index_serial_scan_concurrency - -在执行分析索引列任务的时候，`tidb_index_serial_scan_concurrency` 可以用于控制一次读取的 Region 数量，其默认值是 1。 - -### 查看 ANALYZE 状态 - -在执行 `ANALYZE` 时，可以通过 SQL 语句来查看当前 `ANALYZE` 的状态。 - -语法如下： - -{{< copyable "sql" >}} - -```sql -SHOW ANALYZE STATUS [ShowLikeOrWhere]; -``` - -该语句会输出 `ANALYZE` 的状态，可以通过使用 `ShowLikeOrWhere` 来筛选需要的信息。 - -目前 `SHOW ANALYZE STATUS` 会输出 7 列，具体如下： - -| 语法元素 | 说明 | -| -------- | ------------- | -| table_schema | 数据库名 | -| table_name | 表名 | -| partition_name| 分区名 | -| job_info | 任务具体信息。如果分析索引则会包含索引名 | -| row_count | 已经分析的行数 | -| start_time | 任务开始执行的时间 | -| state | 任务状态，包括 pending（等待）、running（正在执行）、finished（执行成功）和 failed（执行失败）| - -## 统计信息的查看 - -你可以通过一些语句来查看统计信息的状态。 - -### 表的元信息 - -你可以通过 `SHOW STATS_META` 来查看表的总行数以及修改的行数等信息。 - -语法如下： - -{{< copyable "sql" >}} - -```sql -SHOW STATS_META [ShowLikeOrWhere]; -``` - -该语句会输出所有表的总行数以及修改行数等信息，你可以通过 ShowLikeOrWhere 来筛选需要的信息。 - -目前 `SHOW STATS_META` 会输出 6 列，具体如下： - -| 语法元素 | 说明 | -| -------- | ------------- | -| db_name | 数据库名 | -| table_name | 表名 | -| partition_name| 分区名 | -| update_time | 更新时间 | -| modify_count | 修改的行数 | -| row_count | 总行数 | - -> **注意：** -> -> 在 TiDB 根据 DML 语句自动更新总行数以及修改的行数时，`update_time` 也会被更新，因此并不能认为 `update_time` 是最近一次发生 Analyze 的时间。 - -### 表的健康度信息 - -通过 `SHOW STATS_HEALTHY` 可以查看表的统计信息健康度，并粗略估计表上统计信息的准确度。当 `modify_count` >= `row_count` 时，健康度为 0；当 `modify_count` < `row_count` 时，健康度为 (1 - `modify_count`/`row_count`) * 100。 - -通过以下命令来查看表的统计信息健康度，你可以通过 `ShowLikeOrWhere` 来筛选需要的信息： - -{{< copyable "sql" >}} - -```sql -SHOW STATS_HEALTHY [ShowLikeOrWhere]; -``` - -目前，`SHOW STATS_HEALTHY` 会输出 4 列，具体如下： - -| 语法元素 | 说明 | -| :-------- | :------------- | -| db_name | 数据库名 | -| table_name | 表名 | -| partition_name| 分区名 | -| healthy | 健康度 | - -### 列的元信息 - -你可以通过 `SHOW STATS_HISTOGRAMS` 来查看列的不同值数量以及 NULL 数量等信息。 - -语法如下： - -{{< copyable "sql" >}} - -```sql -SHOW STATS_HISTOGRAMS [ShowLikeOrWhere]; -``` - -该语句会输出所有列的不同值数量以及 NULL 数量等信息，你可以通过 ShowLikeOrWhere 来筛选需要的信息。 - -目前 `SHOW STATS_HISTOGRAMS` 会输出 8 列，具体如下： - -| 语法元素 | 说明 | -| -------- | ------------- | -| db_name | 数据库名 | -| table_name | 表名 | -| partition_name | 分区名 | -| column_name | 根据 is_index 来变化：is_index 为 0 时是列名，为 1 时是索引名 | -| is_index | 是否是索引列 | -| update_time | 更新时间 | -| distinct_count | 不同值数量 | -| null_count | NULL 的数量 | -| avg_col_size | 列平均长度 | - -### 直方图桶的信息 - -你可以通过 `SHOW STATS_BUCKETS` 来查看直方图每个桶的信息。 - -语法如下： - -{{< copyable "sql" >}} - -```sql -SHOW STATS_BUCKETS [ShowLikeOrWhere]; -``` - -该语句会输出所有桶的信息，你可以通过 ShowLikeOrWhere 来筛选需要的信息。 - -目前 `SHOW STATS_BUCKETS` 会输出 10 列，具体如下： - -| 语法元素 | 说明 | -| -------- | ------------- | -| db_name | 数据库名 | -| table_name | 表名 | -| partition_name | 分区名 | -| column_name | 根据 is_index 来变化：is_index 为 0 时是列名，为 1 时是索引名 | -| is_index | 是否是索引列 | -| bucket_id | 桶的编号 | -| count | 所有落在这个桶及之前桶中值的数量 | -| repeats | 最大值出现的次数 | -| lower_bound | 最小值 | -| upper_bound | 最大值 | - -## 删除统计信息 - -可以通过执行 `DROP STATS` 语句来删除统计信息。 - -语法如下： - -{{< copyable "sql" >}} - -```sql -DROP STATS TableName; -``` - -该语句会删除 TableName 中所有的统计信息。 - -## 统计信息的导入导出 - -### 导出统计信息 - -统计信息的导出接口如下。 - -通过以下接口可以获取数据库 `${db_name}` 中的表 `${table_name}` 的 json 格式的统计信息： - -{{< copyable "" >}} - -``` -http://${tidb-server-ip}:${tidb-server-status-port}/stats/dump/${db_name}/${table_name} -``` - -通过以下接口可以获取数据库 `${db_name}` 中的表 `${table_name}` 在指定时间上的 json 格式统计信息。指定的时间应在 GC SafePoint 之后。 - -{{< copyable "" >}} - -``` -http://${tidb-server-ip}:${tidb-server-status-port}/stats/dump/${db_name}/${table_name}/${yyyyMMddHHmmss} -``` - -通过以下接口可以获取数据库 `${db_name}` 中的表 `${table_name}` 在指定时间上的 json 格式统计信息。指定的时间应在 GC SafePoint 之后。 - -{{< copyable "" >}} - -``` -http://${tidb-server-ip}:${tidb-server-status-port}/stats/dump/${db_name}/${table_name}/${yyyy-MM-dd HH:mm:ss} -``` - -### 导入统计信息 - -导入的统计信息一般是通过统计信息导出接口得到的 json 文件。 - -语法如下： - -{{< copyable "sql" >}} - -```sql -LOAD STATS 'file_name'; -``` - -`file_name` 为要导入的统计信息的文件名。 diff --git a/dev/reference/performance/tune-tikv.md b/dev/reference/performance/tune-tikv.md deleted file mode 100644 index c83b2544e103..000000000000 --- a/dev/reference/performance/tune-tikv.md +++ /dev/null @@ -1,252 +0,0 @@ ---- -title: TiKV 性能参数调优 -category: reference ---- - -# TiKV 性能参数调优 - -本文档用于描述如何根据机器配置情况来调整 TiKV 的参数，使 TiKV 的性能达到最优。 - -TiKV 最底层使用的是 RocksDB 做为持久化存储，所以 TiKV 的很多性能相关的参数都是与 RocksDB 相关的。TiKV 使用了两个 RocksDB 实例，默认 RocksDB 实例存储 KV 数据，Raft RocksDB 实例（简称 RaftDB）存储 Raft 数据。 - -TiKV 使用了 RocksDB 的 `Column Families` (CF) 特性。 - -- 默认 RocksDB 实例将 KV 数据存储在内部的 `default`、`write` 和 `lock` 3 个 CF 内。 - - - `default` CF 存储的是真正的数据，与其对应的参数位于 `[rocksdb.defaultcf]` 项中； - - `write` CF 存储的是数据的版本信息 (MVCC) 以及索引相关的数据，相关的参数位于 `[rocksdb.writecf]` 项中； - - `lock` CF 存储的是锁信息，系统使用默认参数。 - -- Raft RocksDB 实例存储 Raft log。 - - - `default` CF 主要存储的是 Raft log，与其对应的参数位于 `[raftdb.defaultcf]` 项中。 - -所有的 CF 默认共同使用一个 block cache 实例。通过在 `[storage.block-cache]` 下设置 `capacity` 参数，你可以配置该 block cache 的大小。block cache 越大，能够缓存的热点数据越多，读取数据越容易，同时占用的系统内存也越多。如果要为每个 CF 使用单独的 block cache 实例，需要在 `[storage.block-cache]` 下设置 `shared=false`，并为每个 CF 配置单独的 block cache 大小。例如，可以在 `[rocksdb.writecf]` 下设置 `block-cache-size` 参数来配置 `write` CF 的大小。 - -> **注意：** -> -> 在 TiKV 3.0 之前的版本中，不支持使用 `shared block cache`，需要为每个 CF 单独配置 block cache。 - -每个 CF 有各自的 `write-buffer`，大小通过 `write-buffer-size` 控制。 - -## 参数说明 - -```toml -# 日志级别，可选值为：trace，debug，info，warn，error，off -log-level = "info" - -[server] -# 监听地址 -# addr = "127.0.0.1:20160" - -# gRPC 线程池大小 -# grpc-concurrency = 4 -# TiKV 每个实例之间的 gRPC 连接数 -# grpc-raft-conn-num = 10 - -# TiDB 过来的大部分读请求都会发送到 TiKV 的 Coprocessor 进行处理，该参数用于设置 -# coprocessor 线程的个数，如果业务是读请求比较多，增加 coprocessor 的线程数，但应比系统的 -# CPU 核数小。例如：TiKV 所在的机器有 32 core，在重读的场景下甚至可以将该参数设置为 30。在没有 -# 设置该参数的情况下，TiKV 会自动将该值设置为 CPU 总核数乘以 0.8。 -# end-point-concurrency = 8 - -# 可以给 TiKV 实例打标签，用于副本的调度 -# labels = {zone = "cn-east-1", host = "118", disk = "ssd"} - -[storage] -# 数据目录 -# data-dir = "/tmp/tikv/store" - -# 通常情况下使用默认值就可以了。在导数据的情况下建议将该参数设置为 1024000。 -# scheduler-concurrency = 102400 -# 该参数控制写入线程的个数，当写入操作比较频繁的时候，需要把该参数调大。使用 top -H -p tikv-pid -# 发现名称为 sched-worker-pool 的线程都特别忙，这个时候就需要将 scheduler-worker-pool-size -# 参数调大，增加写线程的个数。 -# scheduler-worker-pool-size = 4 - -[storage.block-cache] -## 是否为 RocksDB 的所有 CF 都创建一个 `shared block cache`。 -## -## RocksDB 使用 block cache 来缓存未压缩的数据块。较大的 block cache 可以加快读取速度。 -## 推荐开启 `shared block cache` 参数。这样只需要设置全部缓存大小，使配置过程更加方便。 -## 在大多数情况下，可以通过 LRU 算法在各 CF 间自动平衡缓存用量。 -## -## `storage.block-cache` 会话中的其余配置仅在开启 `shared block cache` 时起作用。 -# shared = true -## `shared block cache` 的大小。正常情况下应设置为系统全部内存的 30%-50%。 -## 如果未设置该参数，则由以下字段或其默认值的总和决定。 -## -## * rocksdb.defaultcf.block-cache-size 或系统全部内存的 25% -## * rocksdb.writecf.block-cache-size 或系统全部内存的 15% -## * rocksdb.lockcf.block-cache-size 或系统全部内存的 2% -## * raftdb.defaultcf.block-cache-size 或系统全部内存的 2% -## -## 要在单个物理机上部署多个 TiKV 节点，需要显式配置该参数。 -## 否则，TiKV 中可能会出现 OOM 错误。 -# capacity = "1GB" - -[pd] -# pd 的地址 -# endpoints = ["127.0.0.1:2379","127.0.0.2:2379","127.0.0.3:2379"] - -[metric] -# 将 metrics 推送给 Prometheus pushgateway 的时间间隔 -interval = "15s" -# Prometheus pushgateway 的地址 -address = "" -job = "tikv" - -[raftstore] -# 默认为 true，表示强制将数据刷到磁盘上。如果是非金融安全级别的业务场景，建议设置成 false， -# 以便获得更高的性能。 -sync-log = true - -# Raft RocksDB 目录。默认值是 [storage.data-dir] 的 raft 子目录。 -# 如果机器上有多块磁盘，可以将 Raft RocksDB 的数据放在不同的盘上，提高 TiKV 的性能。 -# raftdb-dir = "/tmp/tikv/store/raft" - -region-max-size = "384MB" -# Region 分裂阈值 -region-split-size = "256MB" -# 当 Region 写入的数据量超过该阈值的时候，TiKV 会检查该 Region 是否需要分裂。为了减少检查过程 -# 中扫描数据的成本，数据过程中可以将该值设置为32MB，正常运行状态下使用默认值即可。 -region-split-check-diff = "32MB" - -[rocksdb] -# RocksDB 进行后台任务的最大线程数，后台任务包括 compaction 和 flush。具体 RocksDB 为什么需要进行 compaction， -# 请参考 RocksDB 的相关资料。在写流量比较大的时候（例如导数据），建议开启更多的线程， -# 但应小于 CPU 的核数。例如在导数据的时候，32 核 CPU 的机器，可以设置成 28。 -# max-background-jobs = 8 - -# RocksDB 能够打开的最大文件句柄数。 -# max-open-files = 40960 - -# RocksDB MANIFEST 文件的大小限制.
# 更详细的信息请参考：https://github.com/facebook/rocksdb/wiki/MANIFEST -max-manifest-file-size = "20MB" - -# RocksDB write-ahead logs 目录。如果机器上有两块盘，可以将 RocksDB 的数据和 WAL 日志放在 -# 不同的盘上，提高 TiKV 的性能。 -# wal-dir = "/tmp/tikv/store" - -# 下面两个参数用于怎样处理 RocksDB 归档 WAL。 -# 更多详细信息请参考：https://github.com/facebook/rocksdb/wiki/How-to-persist-in-memory-RocksDB-database%3F -# wal-ttl-seconds = 0 -# wal-size-limit = 0 - -# RocksDB WAL 日志的最大总大小，通常情况下使用默认值就可以了。 -# max-total-wal-size = "4GB" - -# 可以通过该参数打开或者关闭 RocksDB 的统计信息。 -# enable-statistics = true - -# 开启 RocksDB compaction 过程中的预读功能，如果使用的是机械磁盘，建议该值至少为2MB。 -# compaction-readahead-size = "2MB" - -[rocksdb.defaultcf] -# 数据块大小。RocksDB 是按照 block 为单元对数据进行压缩的，同时 block 也是缓存在 block-cache -# 中的最小单元（类似其他数据库的 page 概念）。 -block-size = "64KB" - -# RocksDB 每一层数据的压缩方式，可选的值为：no,snappy,zlib,bzip2,lz4,lz4hc,zstd。 -# no:no:lz4:lz4:lz4:zstd:zstd 表示 level0 和 level1 不压缩，level2 到 level4 采用 lz4 压缩算法, -# level5 和 level6 采用 zstd 压缩算法,。 -# no 表示没有压缩，lz4 是速度和压缩比较为中庸的压缩算法，zlib 的压缩比很高，对存储空间比较友 -# 好，但是压缩速度比较慢，压缩的时候需要占用较多的 CPU 资源。不同的机器需要根据 CPU 以及 I/O 资 -# 源情况来配置怎样的压缩方式。例如：如果采用的压缩方式为"no:no:lz4:lz4:lz4:zstd:zstd"，在大量 -# 写入数据的情况下（导数据），发现系统的 I/O 压力很大（使用 iostat 发现 %util 持续 100% 或者使 -# 用 top 命令发现 iowait 特别多），而 CPU 的资源还比较充裕，这个时候可以考虑将 level0 和 -# level1 开启压缩，用 CPU 资源换取 I/O 资源。如果采用的压缩方式 -# 为"no:no:lz4:lz4:lz4:zstd:zstd"，在大量写入数据的情况下，发现系统的 I/O 压力不大，但是 CPU -# 资源已经吃光了，top -H 发现有大量的 bg 开头的线程（RocksDB 的 compaction 线程）在运行，这 -# 个时候可以考虑用 I/O 资源换取 CPU 资源，将压缩方式改成"no:no:no:lz4:lz4:zstd:zstd"。总之，目 -# 的是为了最大限度地利用系统的现有资源，使 TiKV 的性能在现有的资源情况下充分发挥。 -compression-per-level = ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"] - -# RocksDB memtable 的大小。 -write-buffer-size = "128MB" - -# 最多允许几个 memtable 存在。写入到 RocksDB 的数据首先会记录到 WAL 日志里面，然后会插入到 -# memtable 里面，当 memtable 的大小到达了 write-buffer-size 限定的大小的时候，当前的 -# memtable 会变成只读的，然后生成一个新的 memtable 接收新的写入。只读的 memtable 会被 -# RocksDB 的 flush 线程（max-background-flushes 参数能够控制 flush 线程的最大个数） -# flush 到磁盘，成为 level0 的一个 sst 文件。当 flush 线程忙不过来，导致等待 flush 到磁盘的 -# memtable 的数量到达 max-write-buffer-number 限定的个数的时候，RocksDB 会将新的写入 -# stall 住，stall 是 RocksDB 的一种流控机制。在导数据的时候可以将 max-write-buffer-number -# 的值设置的更大一点，例如 10。 -max-write-buffer-number = 5 - -# 当 level0 的 sst 文件个数到达 level0-slowdown-writes-trigger 指定的限度的时候， -# RocksDB 会尝试减慢写入的速度。因为 level0 的 sst 太多会导致 RocksDB 的读放大上升。 -# level0-slowdown-writes-trigger 和 level0-stop-writes-trigger 是 RocksDB 进行流控的 -# 另一个表现。当 level0 的 sst 的文件个数到达 4（默认值），level0 的 sst 文件会和 level1 中 -# 有 overlap 的 sst 文件进行 compaction，缓解读放大的问题。 -level0-slowdown-writes-trigger = 20 - -# 当 level0 的 sst 文件个数到达 level0-stop-writes-trigger 指定的限度的时候，RocksDB 会 -# stall 住新的写入。 -level0-stop-writes-trigger = 36 - -# 当 level1 的数据量大小达到 max-bytes-for-level-base 限定的值的时候，会触发 level1 的 -# sst 和 level2 种有 overlap 的 sst 进行 compaction。 -# 黄金定律：max-bytes-for-level-base 的设置的第一参考原则就是保证和 level0 的数据量大致相 -# 等，这样能够减少不必要的 compaction。例如压缩方式为"no:no:lz4:lz4:lz4:lz4:lz4"，那么 -# max-bytes-for-level-base 的值应该是 write-buffer-size 的大小乘以 4，因为 level0 和 -# level1 都没有压缩，而且 level0 触发 compaction 的条件是 sst 的个数到达 4（默认值）。在 -# level0 和 level1 都采取了压缩的情况下，就需要分析下 RocksDB 的日志，看一个 memtable 的压 -# 缩成一个 sst 文件的大小大概是多少，例如 32MB，那么 max-bytes-for-level-base 的建议值就应 -# 该是 32MB * 4 = 128MB。 -max-bytes-for-level-base = "512MB" - -# sst 文件的大小。level0 的 sst 文件的大小受 write-buffer-size 和 level0 采用的压缩算法的 -# 影响，target-file-size-base 参数用于控制 level1-level6 单个 sst 文件的大小。 -target-file-size-base = "32MB" - -[rocksdb.writecf] -# 保持和 rocksdb.defaultcf.compression-per-level 一致。 -compression-per-level = ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"] - -# 保持和 rocksdb.defaultcf.write-buffer-size 一致。 -write-buffer-size = "128MB" -max-write-buffer-number = 5 -min-write-buffer-number-to-merge = 1 - -# 保持和 rocksdb.defaultcf.max-bytes-for-level-base 一致。 -max-bytes-for-level-base = "512MB" -target-file-size-base = "32MB" - -[raftdb] -# RaftDB 能够打开的最大文件句柄数。 -# max-open-files = 40960 - -# 可以通过该参数打开或者关闭 RaftDB 的统计信息。 -# enable-statistics = true - -# 开启 RaftDB compaction 过程中的预读功能，如果使用的是机械磁盘，建议该值至少为2MB。 -# compaction-readahead-size = "2MB" - -[raftdb.defaultcf] -# 保持和 rocksdb.defaultcf.compression-per-level 一致。 -compression-per-level = ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"] - -# 保持和 rocksdb.defaultcf.write-buffer-size 一致。 -write-buffer-size = "128MB" -max-write-buffer-number = 5 -min-write-buffer-number-to-merge = 1 - -# 保持和 rocksdb.defaultcf.max-bytes-for-level-base 一致。 -max-bytes-for-level-base = "512MB" -target-file-size-base = "32MB" -``` - -## TiKV 内存使用情况 - -除了以上列出的 `block-cache` 以及 `write-buffer` 会占用系统内存外： - -1. 需预留一些内存作为系统的 page cache -2. TiKV 在处理大的查询的时候（例如 `select * from ...`）会读取数据然后在内存中生成对应的数据结构返回给 TiDB，这个过程中 TiKV 会占用一部分内存 - -## TiKV 机器配置推荐 - -1. 生产环境中，不建议将 TiKV 部署在 CPU 核数小于 8 或内存低于 32GB 的机器上 -2. 如果对写入吞吐要求比较高，建议使用吞吐能力比较好的磁盘 -3. 如果对读写的延迟要求非常高，建议使用 IOPS 比较高的 SSD 盘 diff --git a/dev/reference/performance/understanding-the-query-execution-plan.md b/dev/reference/performance/understanding-the-query-execution-plan.md deleted file mode 100644 index 70035dc14edc..000000000000 --- a/dev/reference/performance/understanding-the-query-execution-plan.md +++ /dev/null @@ -1,155 +0,0 @@ ---- -title: 理解 TiDB 执行计划 -category: reference ---- - -# 理解 TiDB 执行计划 - -TiDB 优化器会根据当前数据表的实际情况来选择最优的执行计划，执行计划由一系列的算子构成。本文将详细解释 TiDB 中 `EXPLAIN` 语句返回的执行计划信息。 - -## 使用 `EXPLAIN` 来优化 SQL 语句 - -`EXPLAIN` 语句的返回结果提供了 TiDB 执行 SQL 查询的详细信息： - -- `EXPLAIN` 可以和 `SELECT`，`DELETE` 语句一起使用； -- 执行 `EXPLAIN`，TiDB 会返回被 `EXPLAIN` 的 SQL 语句经过优化器后的最终物理执行计划。也就是说，`EXPLAIN` 展示了 TiDB 执行该 SQL 语句的完整信息，比如以什么样的顺序，什么方式 JOIN 两个表，表达式树长什么样等等。详见 [`EXPLAIN` 输出格式](#explain-输出格式)； -- TiDB 支持 `EXPLAIN [options] FOR CONNECTION connection_id`，但与 MySQL 的 `EXPLAIN FOR` 有一些区别，请参见 [`EXPLAIN FOR CONNECTION`](#explain-for-connection)。 - -通过观察 `EXPLAIN` 的结果，你可以知道如何给数据表添加索引使得执行计划使用索引从而加速 SQL 语句的执行速度；你也可以使用 `EXPLAIN` 来检查优化器是否选择了最优的顺序来 JOIN 数据表。 - -## `EXPLAIN` 输出格式 - -目前 TiDB 的 `EXPLAIN` 会输出 4 列，分别是：id，count，task，operator info。执行计划中每个算子都由这 4 列属性来描述，`EXPLAIN` 结果中每一行描述一个算子。每个属性的具体含义如下： - -| 属性名 | 含义 | -|:----------------|:--------------------------------------------------------------------------------------------------------------------------------------------| -| id | 算子的 ID，在整个执行计划中唯一的标识一个算子。在 TiDB 2.1 中，id 会格式化显示算子的树状结构。数据从 child 流向 parent，每个 算子的 parent 有且仅有一个。 | -| count | 预计当前算子将会输出的数据条数，基于统计信息以及算子的执行逻辑估算而来。 | -| task | 当前这个算子属于什么 task。目前的执行计划分成为两种 task，一种叫 **root** task，在 tidb-server 上执行，一种叫 **cop** task，并行的在 TiKV 上执行。当前的执行计划在 task 级别的拓扑关系是一个 root task 后面可以跟许多 cop task，root task 使用 cop task 的输出结果作为输入。cop task 中执行的也即是 TiDB 下推到 TiKV 上的任务，每个 cop task 分散在 TiKV 集群中，由多个进程共同执行。 | -| operator info | 每个算子的详细信息。各个算子的 operator info 各有不同，详见 [Operator Info](#operator-info)。 | - -## `EXPLAIN ANALYZE` 输出格式 - -作为 `EXPLAIN` 语句的扩展，`EXPLAIN ANALYZE` 语句执行查询并在 `execution info` 列中提供额外的执行统计信息。具体如下： - -* `time` 显示从进入算子到离开算子的全部 wall time，包括所有子算子操作的全部执行时间。如果该算子被父算子多次调用 (`loops`)，这个时间就是累积的时间。 -* `loops` 是当前算子被父算子调用的次数。 -* `rows` 是当前算子返回的行的总数。例如，可以将 `count` 列的精度和 `execution_info` 列中的 `rows`/`loops` 值进行对比，据此评定查询优化器估算的精确度。 - -### 用例 - -使用 [bikeshare example database](https://github.com/pingcap/docs/blob/master/dev/how-to/get-started/import-example-database.md): - -{{< copyable "sql" >}} - -```sql -EXPLAIN SELECT count(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00' AND '2017-07-01 23:59:59'; -``` - -``` -+--------------------------+-------------+------+------------------------------------------------------------------------------------------------------------------------+ -| id | count | task | operator info | -+--------------------------+-------------+------+------------------------------------------------------------------------------------------------------------------------+ -| StreamAgg_20 | 1.00 | root | funcs:count(col_0) | -| └─TableReader_21 | 1.00 | root | data:StreamAgg_9 | -| └─StreamAgg_9 | 1.00 | cop | funcs:count(1) | -| └─Selection_19 | 8166.73 | cop | ge(bikeshare.trips.start_date, 2017-07-01 00:00:00.000000), le(bikeshare.trips.start_date, 2017-07-01 23:59:59.000000) | -| └─TableScan_18 | 19117643.00 | cop | table:trips, range:[-inf,+inf], keep order:false | -+--------------------------+-------------+------+------------------------------------------------------------------------------------------------------------------------+ -5 rows in set (0.00 sec) -``` - -在上面的例子中，coprocessor 上读取 `trips` 表上的数据（`TableScan_18`），寻找满足 `start_date BETWEEN '2017-07-01 00:00:00' AND '2017-07-01 23:59:59'` 条件的数据（`Selection_19`），然后计算满足条件的数据行数（`StreamAgg_9`），最后把结果返回给 TiDB。TiDB 汇总各个 coprocessor 返回的结果（`TableReader_21`），并进一步计算所有数据的行数（`StreamAgg_20`），最终把结果返回给客户端。在上面这个查询中，TiDB 根据 `trips` 表的统计信息估算出 `TableScan_18` 的输出结果行数为 19117643.00，满足条件 `start_date BETWEEN '2017-07-01 00:00:00' AND '2017-07-01 23:59:59'` 的有 `8166.73` 条，经过聚合运算后，只有 1 条结果。 - -上述查询中，虽然大部分计算逻辑都下推到了 TiKV 的 coprocessor 上，但是其执行效率还是不够高，可以添加适当的索引来消除 `TableScan_18` 对 `trips` 的全表扫，进一步加速查询的执行： - -{{< copyable "sql" >}} - -```sql -ALTER TABLE trips ADD INDEX (start_date); -``` - -{{< copyable "sql" >}} - -```sql -EXPLAIN SELECT count(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00' AND '2017-07-01 23:59:59'; -``` - -``` -+------------------------+---------+------+--------------------------------------------------------------------------------------------------+ -| id | count | task | operator info | -+------------------------+---------+------+--------------------------------------------------------------------------------------------------+ -| StreamAgg_25 | 1.00 | root | funcs:count(col_0) | -| └─IndexReader_26 | 1.00 | root | index:StreamAgg_9 | -| └─StreamAgg_9 | 1.00 | cop | funcs:count(1) | -| └─IndexScan_24 | 8166.73 | cop | table:trips, index:start_date, range:[2017-07-01 00:00:00,2017-07-01 23:59:59], keep order:false | -+------------------------+---------+------+--------------------------------------------------------------------------------------------------+ -4 rows in set (0.01 sec) -``` - -在添加完索引后的新执行计划中，使用 `IndexScan_24` 直接读取满足条件 `start_date BETWEEN '2017-07-01 00:00:00' AND '2017-07-01 23:59:59'` 的数据，可以看到，估算的要扫描的数据行数从之前的 `19117643.00` 降到了现在的 `8166.73`。在测试环境中显示，这个查询的执行时间从 50.41 秒降到了 0.01 秒！ - -## `EXPLAIN FOR CONNECTION` - -`EXPLAIN FOR CONNECTION` 用于获得一个连接中最后执行的查询的执行计划，其输出格式与 `EXPLAIN` 完全一致。但 TiDB 中的实现与 MySQL 不同，除了输出格式之外，还有以下区别： - -- MySQL 返回的是**正在执行**的查询计划，而 TiDB 返回的是**最后执行**的查询计划。 -- MySQL 的文档中指出，MySQL 要求登录用户与被查询的连接相同，或者拥有 `PROCESS` 权限，而 TiDB 则要求登录用户与被查询的连接相同，或者拥有 `SUPER` 权限。 - -## 概述 - -### Task 简介 - -目前 TiDB 的计算任务隶属于两种不同的 task：cop task 和 root task。cop task 是指使用 TiKV 中的 coprocessor 执行的计算任务，root task 是指在 TiDB 中执行的计算任务。 - -SQL 优化的目标之一是将计算尽可能地下推到 TiKV 中执行。TiKV 中的 coprocessor 能支持大部分 SQL 内建函数（包括聚合函数和标量函数）、SQL `LIMIT` 操作、索引扫描和表扫描。但是，所有的 Join 操作都只能作为 root task 在 TiDB 上执行。 - -### 表数据和索引数据 - -TiDB 的表数据是指一张表的原始数据，存放在 TiKV 中。对于每行表数据，它的 key 是一个 64 位整数，称为 Handle ID。如果一张表存在 int 类型的主键，TiDB 会把主键的值当作表数据的 Handle ID，否则由系统自动生成 Handle ID。表数据的 value 由这一行的所有数据编码而成。在读取表数据的时候，可以按照 Handle ID 递增的顺序返回。 - -TiDB 的索引数据和表数据一样，也存放在 TiKV 中。它的 key 是由索引列编码的有序 bytes，value 是这一行索引数据对应的 Handle ID，通过 Handle ID 可以读取这一行的非索引列。在读取索引数据的时候，TiKV 会按照索引列递增的顺序返回，如果有多个索引列，首先保证第 1 列递增，并且在第 i 列相等的情况下，保证第 i + 1 列递增。 - -### 范围查询 - -在 WHERE/HAVING/ON 条件中，TiDB 优化器会分析主键或索引键的查询返回。如数字、日期类型的比较符，如大于、小于、等于以及大于等于、小于等于，字符类型的 LIKE 符号等。 - -值得注意的是，TiDB 目前只支持比较符一端是列，另一端是常量，或可以计算成某一常量的情况，类似 `year(birth_day) < 1992` 的查询条件是不能利用索引的。还要注意应尽可能使用同一类型进行比较，以避免引入额外的 cast 操作而导致不能利用索引，如 `user_id = 123456`，如果 `user_id` 是字符串，需要将 `123456` 也写成字符串常量的形式。 - -针对同一列的范围查询条件使用 `AND` 和 `OR` 组合后，等于对范围求交集或者并集。对于多维组合索引，可以写多个列的条件。例如对组合索引`(a, b, c)`，当 a 为等值查询时，可以继续求 b 的查询范围，当 b 也为等值查询时，可以继续求 c 的查询范围，反之如果 a 为非等值查询，则只能求 a 的范围。 - -## Operator Info - -### TableReader 和 TableScan - -TableScan 表示在 KV 端对表数据进行扫描，TableReader 表示在 TiDB 端从 TiKV 端读取，属于同一功能的两个算子。table 表示 SQL 语句中的表名，如果表名被重命名，则显示重命名。range 表示扫描的数据范围，如果在查询中不指定 WHERE/HAVING/ON 条件，则会选择全表扫描，如果在 int 类型的主键上有范围查询条件，会选择范围查询。keep order 表示 table scan 是否按顺序返回。 - -### IndexReader 和 IndexLookUp - -Index 在 TiDB 端的读取方式有两种：IndexReader 表示直接从索引中读取索引列，适用于 SQL 语句中仅引用了该索引相关的列或主键；IndexLookUp 表示从索引中过滤部分数据，仅返回这些数据的 Handle ID，通过 Handle ID 再次查找表数据，这种方式需要两次从 TiKV 获取数据。Index 的读取方式是由优化器自动选择的。 - -IndexScan 是 KV 端读取索引数据的算子，和 TableScan 功能类似。table 表示 SQL 语句中的表名，如果表名被重命名，则显示重命名。index 表示索引名。range 表示扫描的数据范围。out of order 表示 index scan 是否按照顺序返回。注意在 TiDB 中，多列或者非 int 列构成的主键是当作唯一索引处理的。 - -### Selection - -Selection 表示 SQL 语句中的选择条件，通常出现在 WHERE/HAVING/ON 子句中。 - -### Projection - -Projection 对应 SQL 语句中的 SELECT 列表，功能是将每一条输入数据映射成新的输出数据。 - -### Aggregation - -Aggregation 对应 SQL 语句中的 Group By 语句或者没有 Group By 语句但是存在聚合函数，例如 count 或 sum 函数等。TiDB 支持两种聚合算法：Hash Aggregation 以及 Stream Aggregation（待补充）。Hash Aggregation 是基于哈希的聚合算法，如果 Hash Aggregation 紧邻 Table 或者 Index 的读取算子，则聚合算子会在 TiKV 端进行预聚合，以提高计算的并行度和减少网络开销。 - -### Join - -TiDB 支持 Inner Join 以及 Left/Right Outer Join，并会自动将可以化简的外连接转换为 Inner Join。 - -TiDB 支持三种 Join 算法：Hash Join，Sort Merge Join 和 Index Look up Join。Hash Join 的原理是将参与连接的小表预先装载到内存中，读取大表的所有数据进行连接。Sort Merge Join 会利用输入数据的有序信息，同时读取两张表的数据并依次进行比较。Index Look Up Join 会读取外表的数据，并对内表进行主键或索引键查询。 - -### Apply - -Apply 是 TiDB 用来描述子查询的一种算子，行为类似于 Nested Loop，即每次从外表中取一条数据，带入到内表的关联列中，并执行，最后根据 Apply 内联的 Join 算法进行连接计算。 - -值得注意的是，Apply 一般会被查询优化器自动转换为 Join 操作。用户在编写 SQL 的过程中应尽量避免 Apply 算子的出现。 diff --git a/dev/reference/security/compatibility.md b/dev/reference/security/compatibility.md deleted file mode 100644 index c9caaaef1781..000000000000 --- a/dev/reference/security/compatibility.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: 与 MySQL 安全特性差异 -category: reference ---- - -# 与 MySQL 安全特性差异 - -除以下功能外，TiDB 支持与 MySQL 5.7 类似的安全特性。 - -- 仅支持 `mysql_native_password` 身份验证方案。 -- 不支持外部身份验证方式（如 LDAP）。 -- 不支持列级别权限设置。 -- 不支持密码过期，最后一次密码变更记录以及密码生存期。[#9709](https://github.com/pingcap/tidb/issues/9709) -- 不支持权限属性 `max_questions`，`max_updated`，`max_connections` 以及 `max_user_connections`。 -- 不支持密码验证。[#9741](https://github.com/pingcap/tidb/issues/9741) -- 不支持透明数据加密（TDE）。 diff --git a/dev/reference/security/privilege-system.md b/dev/reference/security/privilege-system.md deleted file mode 100644 index 155707bac6ca..000000000000 --- a/dev/reference/security/privilege-system.md +++ /dev/null @@ -1,481 +0,0 @@ ---- -title: 权限管理 -category: reference ---- - -# 权限管理 - -TiDB 的权限管理系统按照 MySQL 的权限管理进行实现，TiDB 支持大部分的 MySQL 的语法和权限类型。 - -本文档主要介绍 TiDB 权限相关操作、各项操作需要的权限以及权限系统的实现。 - -## 权限相关操作 - -### 授予权限 - -授予 `xxx` 用户对数据库 `test` 的读权限： - -{{< copyable "sql" >}} - -```sql -GRANT SELECT ON test.* TO 'xxx'@'%'; -``` - -为 `xxx` 用户授予所有数据库，全部权限： - -{{< copyable "sql" >}} - -```sql -GRANT ALL PRIVILEGES ON *.* TO 'xxx'@'%'; -``` - -`GRANT` 为一个不存在的用户授予权限时，默认并不会自动创建用户。该行为受 SQL Mode 中的 `NO_AUTO_CREATE_USER` 控制。 -如果从 SQL Mode 中去掉 `NO_AUTO_CREATE_USER`，当 `GRANT` 的目标用户不存在时，TiDB 会自动创建用户。 - -{{< copyable "sql" >}} - -```sql -select @@sql_mode; -``` - -```+-------------------------------------------------------------------------------------------------------------------------------------------+ -| @@sql_mode | -+-------------------------------------------------------------------------------------------------------------------------------------------+ -| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION | -+-------------------------------------------------------------------------------------------------------------------------------------------+ -1 row in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -set @@sql_mode='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION'; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT * FROM mysql.user WHERE user='xxxx'; -``` - -``` -Empty set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -GRANT ALL PRIVILEGES ON test.* TO 'xxxx'@'%' IDENTIFIED BY 'yyyyy'; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT user,host FROM mysql.user WHERE user='xxxx'; -``` - -``` -+------|------+ -| user | host | -+------|------+ -| xxxx | % | -+------|------+ -1 row in set (0.00 sec) -``` - -上述示例中，`xxxx@%` 即自动添加的用户。 - -`GRANT` 对于数据库或者表的授权，不检查数据库或表是否存在。 - -{{< copyable "sql" >}} - -```sql -SELECT * FROM test.xxxx; -``` - -``` -ERROR 1146 (42S02): Table 'test.xxxx' doesn't exist -``` - -{{< copyable "sql" >}} - -```sql -GRANT ALL PRIVILEGES ON test.xxxx TO xxxx; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT user,host FROM mysql.tables_priv WHERE user='xxxx'; -``` - -``` -+------|------+ -| user | host | -+------|------+ -| xxxx | % | -+------|------+ -1 row in set (0.00 sec) -``` - -`GRANT` 可以模糊匹配地授予数据库和表： - -{{< copyable "sql" >}} - -```sql -GRANT ALL PRIVILEGES ON `te%`.* TO genius; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT user,host,db FROM mysql.db WHERE user='genius'; -``` - -``` -+--------|------|-----+ -| user | host | db | -+--------|------|-----+ -| genius | % | te% | -+--------|------|-----+ -1 row in set (0.00 sec) -``` - -这个例子中通过 `%` 模糊匹配，所有 `te` 开头的数据库，都被授予了权限。 - -### 收回权限 - -`REVOKE` 语句与 `GRANT` 对应： - -{{< copyable "sql" >}} - -```sql -REVOKE ALL PRIVILEGES ON `test`.* FROM 'genius'@'localhost'; -``` - -> **注意：** -> -> `REVOKE` 收回权限时只做精确匹配，若找不到记录则报错。而 `GRANT` 授予权限时可以使用模糊匹配。 - -{{< copyable "sql" >}} - -```sql -REVOKE ALL PRIVILEGES ON `te%`.* FROM 'genius'@'%'; -``` - -``` -ERROR 1141 (42000): There is no such grant defined for user 'genius' on host '%' -``` - -关于模糊匹配和转义，字符串和 identifier： - -{{< copyable "sql" >}} - -```sql -GRANT ALL PRIVILEGES ON `te\%`.* TO 'genius'@'localhost'; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -上述例子是精确匹配名为 `te%` 的数据库，注意使用 `\` 转义字符。 - -以单引号包含的部分，是一个字符串。以反引号包含的部分，是一个 identifier。注意下面的区别： - -{{< copyable "sql" >}} - -```sql -GRANT ALL PRIVILEGES ON 'test'.* TO 'genius'@'localhost'; -``` - -``` -ERROR 1064 (42000): You have an error in your SQL syntax; check the -manual that corresponds to your MySQL server version for the right -syntax to use near ''test'.* to 'genius'@'localhost'' at line 1 -``` - -{{< copyable "sql" >}} - -```sql -GRANT ALL PRIVILEGES ON `test`.* TO 'genius'@'localhost'; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -如果想将一些特殊的关键字做为表名，可以用反引号包含起来。比如： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE `select` (id int); -``` - -``` -Query OK, 0 rows affected (0.27 sec) -``` - -### 查看为用户分配的权限 - -`SHOW GRANTS` 语句可以查看为用户分配了哪些权限。例如： - -查看当前用户的权限： - -{{< copyable "sql" >}} - -```sql -SHOW GRANTS; -``` - -查看某个特定用户的权限： - -{{< copyable "sql" >}} - -```sql -SHOW GRANTS for 'root'@'%'; -``` - -更精确的方式，可以通过直接查看授权表的数据实现。比如想知道，名为 `test@%` 的用户是否拥有对 `db1.t` 的 `Insert` 权限： - -1. 先查看该用户是否拥有全局 `Insert` 权限： - - {{< copyable "sql" >}} - - ```sql - SELECT Insert_priv FROM mysql.user WHERE user='test' AND host='%'; - ``` - -2. 如果没有，再查看该用户是否拥有 `db1` 数据库级别的 `Insert` 权限： - - {{< copyable "sql" >}} - - ```sql - SELECT Insert_priv FROM mysql.db WHERE user='test' AND host='%'; - ``` - -3. 如果仍然没有，则继续判断是否拥有 `db1.t` 这张表的 `Insert` 权限： - - {{< copyable "sql" >}} - - ```sql - SELECT table_priv FROM mysql.tables_priv WHERE user='test' AND host='%' AND db='db1'; - ``` - -## TiDB 各操作需要的权限 - -TiDB 用户目前拥有的权限可以在 `INFORMATION_SCHEMA.USER_PRIVILEGES` 表中查找到。 - -| 权限类型 | 权限变量名 | 权限简述 | -| :------------ | :------------ | :---------------------- | -| ALL | AllPriv | 所有权限 | -| Drop | DropPriv | 删除 schema/table | -| Index | IndexPriv | 创建/删除 index | -| Alter | AlterPriv | 执行 `ALTER` 语句 | -| Super | SuperPriv | 所有权限 | -| Grant | GrantPriv | 授予其他用户权限 | -| Create | CreatePriv | 创建 schema/table | -| Select | SelectPriv | 读取表内容 | -| Insert | InsertPriv | 插入数据到表 | -| Update | UpdatePriv | 更新表中数据 | -| Delete | DeletePriv | 删除表中数据 | -| Trigger | TriggerPriv | 尚未使用 | -| Process | ProcessPriv | 显示正在运行的任务 | -| Execute | ExecutePriv | 执行 execute 语句 | -| Drop Role | DropRolePriv | 执行 drop role | -| Show View | ShowViewPriv | 执行 show create view | -| References | ReferencesPriv | 尚未使用 | -| Create View | CreateViewPriv | 创建视图 | -| Create User | CreateUserPriv | 创建用户 | -| Create Role | CreateRolePriv | 执行 create role | -| Show Databases | ShowDBPriv | 显示 database 内的表情况 | - -### ALTER - -- 对于所有的 `ALTER` 语句，均需要用户对所操作的表拥有 `ALTER` 权限。 -- 除 `ALTER...DROP` 和 `ALTER...RENAME TO` 外，均需要对所操作表拥有 `INSERT` 和 `CREATE` 权限。 -- 对于 `ALTER...DROP` 语句，需要对表拥有 `DROP` 权限。 -- 对于 `ALTER...RENAME TO` 语句，需要对重命名前的表拥有 `DROP` 权限，对重命名后的表拥有 `CREATE` 和 `INSERT` 权限。 - -> **注意：** -> -> 根据 MySQL 5.7 文档中的说明，对表进行 `ALTER` 操作需要 `INSERT` 和 `CREATE` 权限，但在 MySQL 5.7.25 版本实际情况中，该操作仅需要 `ALTER` 权限。目前，TiDB 中的 `ALTER` 权限与 MySQL 实际行为保持一致。 - -### CREATE DATABASE - -需要对数据库拥有 `CREATE` 权限。 - -### CREATE INDEX - -需要对所操作的表拥有 `INDEX` 权限。 - -### CREATE TABLE - -需要对所操作的表拥有 `CREATE` 权限；若使用 `CREATE TABLE...LIKE...` 需要对相关的表拥有 `SELECT` 权限。 - -### CREATE VIEW - -需要拥有 `CREATE VIEW` 权限。 - -> **注意：** -> -> 如果当前登录用户与创建视图的用户不同，除需要 `CREATE VIEW` 权限外，还需要 `SUPER` 权限。 - -### DROP DATABASE - -需要对数据库拥有 `DROP` 权限。 - -### DROP INDEX - -需要对所操作的表拥有 `INDEX` 权限。 - -### DROP TABLES - -需要对所操作的表拥有 `DROP` 权限。 - -### TRUNCATE TABLE - -需要对所操作的表拥有 `DROP` 权限。 - -### RENAME TABLE - -需要对重命名前的表拥有 `ALTER` 和 `DROP` 权限，对重命名后的表拥有 `CREATE` 和 `INSERT` 权限。 - -### ANALYZE TABLE - -需要对所操作的表拥有 `INSERT` 和 `SELECT` 权限。 - -### SHOW - -`SHOW CREATE TABLE` 需要任意一种权限。 - -`SHOW CREATE VIEW` 需要 `SHOW VIEW` 权限。 - -### CREATE ROLE/USER - -`CREATE ROLE` 需要 `CREATE ROLE` 权限。 - -`CREATE USER` 需要 `CREATE USER` 权限 - -### DROP ROLE/USER - -`DROP ROLE` 需要 `DROPROLE` 权限。 - -`DROP USER` 需要 `CREATEUSER` 权限 - -### ALTER USER - -`ALTER USER` 需要 `CREATEUSER` 权限。 - -### GRANT - -`GRANT` 需要 `GRANT` 权限并且拥有 `GRANT` 所赋予的权限。 - -### REVOKE - -`REVOKE` 需要 `SUPER` 权限。 - -## 权限系统的实现 - -### 授权表 - -以下几张系统表是非常特殊的表，权限相关的数据全部存储在这几张表内。 - -- `mysql.user`：用户账户，全局权限 -- `mysql.db`：数据库级别的权限 -- `mysql.tables_priv`：表级别的权限 -- `mysql.columns_priv`：列级别的权限，当前暂不支持 - -这几张表包含了数据的生效范围和权限信息。例如，`mysql.user` 表的部分数据： - -{{< copyable "sql" >}} - -```sql -SELECT User,Host,Select_priv,Insert_priv FROM mysql.user LIMIT 1; -``` - -``` -+------|------|-------------|-------------+ -| User | Host | Select_priv | Insert_priv | -+------|------|-------------|-------------+ -| root | % | Y | Y | -+------|------|-------------|-------------+ -1 row in set (0.00 sec) -``` - -这条记录中，`Host` 和 `User` 决定了 root 用户从任意主机 (%) 发送过来的连接请求可以被接受，而 `Select_priv` 和 `Insert_priv` 表示用户拥有全局的 `Select` 和 `Insert` 权限。`mysql.user` 这张表里面的生效范围是全局的。 - -`mysql.db` 表里面包含的 `Host` 和 `User` 决定了用户可以访问哪些数据库，权限列的生效范围是数据库。 - -理论上，所有权限管理相关的操作，都可以通过直接对授权表的 CRUD 操作完成。 - -实现层面其实也只是包装了一层语法糖。例如删除用户会执行： - -{{< copyable "sql" >}} - -```sql -DELETE FROM mysql.user WHERE user='test'; -``` - -但是，不推荐手动修改授权表，建议使用 `DROP USER` 语句： - -{{< copyable "sql" >}} - -```sql -DROP USER 'test'; -``` - -### 连接验证 - -当客户端发送连接请求时，TiDB 服务器会对登录操作进行验证。验证过程先检查 `mysql.user` 表，当某条记录的 `User` 和 `Host` 和连接请求匹配上了，再去验证 Password。用户身份基于两部分信息，发起连接的客户端的 `Host`，以及用户名 `User`。如果 `User` 不为空，则用户名必须精确匹配。 - -User+Host 可能会匹配 `user` 表里面多行，为了处理这种情况，`user` 表的行是排序过的，客户端连接时会依次去匹配，并使用首次匹配到的那一行做权限验证。排序是按 `Host` 在前，`User` 在后。 - -### 请求验证 - -连接成功之后，请求验证会检测执行操作是否拥有足够的权限。 - -对于数据库相关请求 (`INSERT`，`UPDATE`)，先检查 `mysql.user` 表里面的用户全局权限，如果权限够，则直接可以访问。如果全局权限不足，则再检查 `mysql.db` 表。 - -`user` 表的权限是全局的，并且不管默认数据库是哪一个。比如 `user` 里面有 `DELETE` 权限，任何一行，任何的表，任何的数据库。 - -`db`表里面，User 为空是匹配匿名用户，User 里面不能有通配符。Host 和 Db 列里面可以有 `%` 和 `_`，可以模式匹配。 - -`user` 和 `db` 读到内存也是排序的。 - -`tables_priv` 和 `columns_priv` 中使用 `%` 是类似的，但是在`Db`, `Table_name`, `Column_name` 这些列不能包含 `%`。加载进来时排序也是类似的。 - -### 生效时机 - -TiDB 启动时，将一些权限检查的表加载到内存，之后使用缓存的数据来验证权限。系统会周期性的将授权表从数据库同步到缓存，生效则是由同步的周期决定，目前这个值设定的是 5 分钟。 - -修改了授权表，如果需要立即生效，可以手动调用： - -{{< copyable "sql" >}} - -```sql -FLUSH PRIVILEGES; -``` - -### 限制和约束 - -一些使用频率偏低的权限当前版本的实现中还未做检查，比如 `FILE`/`USAGE`/`SHUTDOWN`/`EXECUTE`/`PROCESS`/`INDEX` 等等，未来会陆续完善。 - -现阶段对权限的支持还没有做到 column 级别。 diff --git a/dev/reference/security/user-account-management.md b/dev/reference/security/user-account-management.md deleted file mode 100644 index 145d7f95b0e0..000000000000 --- a/dev/reference/security/user-account-management.md +++ /dev/null @@ -1,232 +0,0 @@ ---- -title: TiDB 用户账户管理 -category: reference ---- - -# TiDB 用户账户管理 - -本文档主要介绍如何管理 TiDB 用户账户。 - -## 用户名和密码 - -TiDB 将用户账户存储在 `mysql.user` 系统表里面。每个账户由用户名和 host 作为标识。每个账户可以设置一个密码。 - -通过 MySQL 客户端连接到 TiDB 服务器，通过指定的账户和密码登录： - -{{< copyable "shell-regular" >}} - -``` -mysql --port 4000 --user xxx --password -``` - -使用缩写的命令行参数则是： - -{{< copyable "shell-regular" >}} - -``` -mysql -P 4000 -u xxx -p -``` - -## 添加用户 - -添加用户有两种方式： - -* 通过标准的用户管理的 SQL 语句创建用户以及授予权限，比如 `CREATE USER` 和 `GRANT`。 -* 直接通过 `INSERT`、`UPDATE` 和 `DELETE` 操作授权表。 - -推荐使用第一种方式。第二种方式修改容易导致一些不完整的修改，因此不推荐。还有另一种可选方式是使用第三方工具的图形化界面工具。 - -{{< copyable "sql" >}} - -```sql -CREATE USER [IF NOT EXISTS] - user [auth_spec] [, user [auth_spec]] ... -``` - -{{< copyable "sql" >}} - -```sql -auth_spec: { - IDENTIFIED BY 'auth_string' - | IDENTIFIED BY PASSWORD 'hash_string' -} -``` - -* `IDENTIFIED BY 'auth_string'`：设置登录密码时，`auth_string` 会被 TiDB 经过加密存储在 `mysql.user` 表中。 -* `IDENTIFIED BY PASSWORD 'hash_string'`：设置登录密码，`hash_string` 是一个类似于 `*EBE2869D7542FCE37D1C9BBC724B97BDE54428F1` 的 41 位字符串，会被 TiDB 直接存储在 `mysql.user` 表中，该字符串可以通过 `SELECT password('auth_string')` 加密得到。 - -{{< copyable "sql" >}} - -```sql -CREATE USER 'test'@'127.0.0.1' IDENTIFIED BY 'xxx'; -``` - -TiDB 的用户账户名由一个用户名和一个主机名组成。账户名的语法为 `'user_name'@'host_name'`。 - -- `user_name` 大小写敏感。 -- `host_name` 可以是一个主机名或 IP 地址。主机名或 IP 地址中允许使用通配符 `%` 和 `_`。例如，名为 `'%'` 的主机名可以匹配所有主机，`'192.168.1.%'` 可以匹配子网中的所有主机。 - -host 支持模糊匹配，比如： - -{{< copyable "sql" >}} - -```sql -CREATE USER 'test'@'192.168.10.%'; -``` - -允许 `test` 用户从 `192.168.10` 子网的任何一个主机登录。 - -如果没有指定 host，则默认是所有 IP 均可登录。如果没有指定密码，默认为空： - -{{< copyable "sql" >}} - -```sql -CREATE USER 'test'; -``` - -等价于： - -{{< copyable "sql" >}} - -```sql -CREATE USER 'test'@'%' IDENTIFIED BY ''; -``` - -下面的例子用 `CREATE USER` 和 `GRANT` 语句创建了四个账户： - -{{< copyable "sql" >}} - -```sql -CREATE USER 'finley'@'localhost' IDENTIFIED BY 'some_pass'; -``` - -{{< copyable "sql" >}} - -```sql -GRANT ALL PRIVILEGES ON *.* TO 'finley'@'localhost' WITH GRANT OPTION; -``` - -{{< copyable "sql" >}} - -```sql -CREATE USER 'finley'@'%' IDENTIFIED BY 'some_pass'; -``` - -{{< copyable "sql" >}} - -```sql -GRANT ALL PRIVILEGES ON *.* TO 'finley'@'%' WITH GRANT OPTION; -``` - -{{< copyable "sql" >}} - -```sql -CREATE USER 'admin'@'localhost' IDENTIFIED BY 'admin_pass'; -``` - -{{< copyable "sql" >}} - -```sql -GRANT RELOAD,PROCESS ON *.* TO 'admin'@'localhost'; -``` - -{{< copyable "sql" >}} - -```sql -CREATE USER 'dummy'@'localhost'; -``` - -使用 `SHOW GRANTS` 可以看到为一个用户授予的权限： - -{{< copyable "sql" >}} - -```sql -SHOW GRANTS FOR 'admin'@'localhost'; -``` - -``` -+-----------------------------------------------------+ -| Grants for admin@localhost | -+-----------------------------------------------------+ -| GRANT RELOAD, PROCESS ON *.* TO 'admin'@'localhost' | -+-----------------------------------------------------+ -``` - -## 删除用户 - -使用 `DROP USER` 语句可以删除用户，例如： - -{{< copyable "sql" >}} - -```sql -DROP USER 'test'@'localhost'; -``` - -这个操作会清除用户在 `mysql.user` 表里面的记录项，并且清除在授权表里面的相关记录。 - -## 保留用户账户 - -TiDB 在数据库初始化时会生成一个 `'root'@'%'` 的默认账户。 - -## 设置资源限制 - -暂不支持。 - -## 设置密码 - -TiDB 将密码存在 `mysql.user` 系统数据库里面。只有拥有 `CREATE USER` 权限，或者拥有 `mysql` 数据库权限（`INSERT` 权限用于创建，`UPDATE` 权限用于更新）的用户才能够设置或修改密码。 - -- 在 `CREATE USER` 创建用户时可以通过 `IDENTIFIED BY` 指定密码： - - {{< copyable "sql" >}} - - ```sql - CREATE USER 'test'@'localhost' IDENTIFIED BY 'mypass'; - ``` - -- 为一个已存在的账户修改密码，可以通过 `SET PASSWORD FOR` 或者 `ALTER USER` 语句完成： - - {{< copyable "sql" >}} - - ```sql - SET PASSWORD FOR 'root'@'%' = 'xxx'; - ``` - - 或者： - - {{< copyable "sql" >}} - - ```sql - ALTER USER 'test'@'localhost' IDENTIFIED BY 'mypass'; - ``` - -## 忘记 `root` 密码 - -1. 修改配置文件，在 `security` 部分添加 `skip-grant-table`： - - {{< copyable "" >}} - - ``` - [security] - skip-grant-table = true - ``` - -2. 然后使用 `root` 登录后修改密码： - - {{< copyable "shell-regular" >}} - - ```bash - mysql -h 127.0.0.1 -P 4000 -u root - ``` - -## `FLUSH PRIVILEGES` - -如果授权表已被直接修改，运行如下命令可使改动立即生效： - -{{< copyable "sql" >}} - -```sql -FLUSH PRIVILEGES; -``` - -详情参见[权限管理](/dev/reference/security/privilege-system.md)。 diff --git a/dev/reference/sql/character-set.md b/dev/reference/sql/character-set.md deleted file mode 100644 index 0537b208a809..000000000000 --- a/dev/reference/sql/character-set.md +++ /dev/null @@ -1,327 +0,0 @@ ---- -title: 字符集支持 -category: reference ---- - -# 字符集支持 - -名词解释，下面的阐述中会交错使用中文或者英文，请互相对照： - -* Character Set：字符集 -* Collation：排序规则 - -目前 `TiDB` 支持以下字符集： - -{{< copyable "sql" >}} - -```sql -SHOW CHARACTER SET; -``` - -``` -+---------|---------------|-------------------|--------+ -| Charset | Description | Default collation | Maxlen | -+---------|---------------|-------------------|--------+ -| utf8 | UTF-8 Unicode | utf8_bin | 3 | -| utf8mb4 | UTF-8 Unicode | utf8mb4_bin | 4 | -| ascii | US ASCII | ascii_bin | 1 | -| latin1 | Latin1 | latin1_bin | 1 | -| binary | binary | binary | 1 | -+---------|---------------|-------------------|--------+ -5 rows in set (0.00 sec) -``` - -> **注意：** -> -> - 在 `TiDB` 中 `utf8` 被当做成了 `utf8mb4` 来处理。 -> - 每种字符集都对应一个默认的 Collation，当前有且仅有一个。 - -对于字符集来说，至少会有一个 Collation（排序规则）与之对应。而大部分字符集实际上会有多个 Collation。利用以下的语句可以查看： - -{{< copyable "sql" >}} - -```sql -SHOW COLLATION WHERE Charset = 'latin1'; -``` - -``` -+-------------------|---------|------|---------|----------|---------+ -| Collation | Charset | Id | Default | Compiled | Sortlen | -+-------------------|---------|------|---------|----------|---------+ -| latin1_german1_ci | latin1 | 5 | | Yes | 1 | -| latin1_swedish_ci | latin1 | 8 | Yes | Yes | 1 | -| latin1_danish_ci | latin1 | 15 | | Yes | 1 | -| latin1_german2_ci | latin1 | 31 | | Yes | 1 | -| latin1_bin | latin1 | 47 | | Yes | 1 | -| latin1_general_ci | latin1 | 48 | | Yes | 1 | -| latin1_general_cs | latin1 | 49 | | Yes | 1 | -| latin1_spanish_ci | latin1 | 94 | | Yes | 1 | -+-------------------|---------|------|---------|----------|---------+ -8 rows in set (0.00 sec) -``` - -`latin1` Collation（排序规则）分别有以下含义： - -| Collation | 含义 | -|:------------------|:----------------------------------| -| latin1_bin | latin1 编码的二进制表示 | -| latin1_danish_ci | 丹麦语/挪威语，不区分大小写 | -| latin1_general_ci | 多种语言的 (西欧)，不区分大小写 | -| latin1_general_cs | 多种语言的 (ISO 西欧)，区分大小写 | -| latin1_german1_ci | 德国 DIN-1 (字典序)，不区分大小写 | -| latin1_german2_ci | 德国 DIN-2，不区分大小写 | -| latin1_spanish_ci | 现代西班牙语，不区分大小写 | -| latin1_swedish_ci | 瑞典语/芬兰语，不区分大小写 | - -每一个字符集，都有一个默认的 Collation，例如 `utf8` 的默认 Collation 就为 `utf8_bin`。 - -> **注意：** -> -> `TiDB` 目前的 Collation 只支持区分大小写的比较排序规则。 - -## Collation 命名规则 - -`TiDB` 的 Collation 遵循着如下的命名规则： - -* Collation 的前缀是它相应的字符集，通常之后会跟着一个或者更多的后缀来表名其他的排序规则， 例如：utf8_general_ci 和 lation1_swedish_ci 是 utf8 - 和 latin1 字符集的 Collation。但是 binary 字符集只有一个 Collation，就是 binary。 -* 一个语言对应的 Collation 会包含语言的名字，例如 utf8_turkish_ci 和 utf8_hungarian_ci 是依据 Turkish(土耳其语) 和 Hungarian(匈牙利语) 的排序规则来排序。 -* Collation 的后缀表示了 Collation 是否区分大小写和是否区分口音。下面的表展示了这些特性： - -| 后缀 | 含义 | -|:-----|:---------------------------------| -| \_ai | 口音不敏感（Accent insensitive） | -| \_as | 口音敏感 （Accent sensitive） | -| \_ci | 大小写不敏感 | -| \_cs | 大小写敏感 | - -> **注意：** -> -> 目前为止 TiDB 只支持部分以上提到的 Collation。 - -## 集群 Character Set 和 Collation - -暂不支持 - -## 数据库 Character Set 和 Collation - -每个数据库都有相应的 Character Set 和 Collation，数据库的 Character Set 和 Collation 可以通过以下语句来设置： - -```sql -CREATE DATABASE db_name - [[DEFAULT] CHARACTER SET charset_name] - [[DEFAULT] COLLATE collation_name] - -ALTER DATABASE db_name - [[DEFAULT] CHARACTER SET charset_name] - [[DEFAULT] COLLATE collation_name] -``` - -在这里 `DATABASE` 可以跟 `SCHEMA` 互换使用。 - -不同的数据库之间可以使用不一样的字符集和排序规则。 - -通过系统变量 `character_set_database` 和 `collation_database` 可以查看到当前数据库的字符集以及排序规则： - -{{< copyable "sql" >}} - -```sql -create schema test1 character set utf8 COLLATE uft8_general_ci; -``` - -``` -Query OK, 0 rows affected (0.09 sec) -``` - -{{< copyable "sql" >}} - -```sql -use test1; -``` - -``` -Database changed -``` - -{{< copyable "sql" >}} - -```sql -SELECT @@character_set_database, @@collation_database; -``` - -``` -+--------------------------|----------------------+ -| @@character_set_database | @@collation_database | -+--------------------------|----------------------+ -| utf8 | uft8_general_ci | -+--------------------------|----------------------+ -1 row in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -create schema test2 character set latin1 COLLATE latin1_general_ci; -``` - -``` -Query OK, 0 rows affected (0.09 sec) -``` - -{{< copyable "sql" >}} - -```sql -use test2; -``` - -``` -Database changed -``` - -{{< copyable "sql" >}} - -```sql -SELECT @@character_set_database, @@collation_database; -``` - -``` -+--------------------------|----------------------+ -| @@character_set_database | @@collation_database | -+--------------------------|----------------------+ -| latin1 | latin1_general_ci | -+--------------------------|----------------------+ -1 row in set (0.00 sec) -``` - -在 INFORMATION_SCHEMA 中也可以查看到这两个值： - -{{< copyable "sql" >}} - -```sql -SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME -FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = 'db_name'; -``` - -## 表的 Character Set 和 Collation - -表的 Character Set 和 Collation 可以通过以下语句来设置： - -```sql -CREATE TABLE tbl_name (column_list) - [[DEFAULT] CHARACTER SET charset_name] - [COLLATE collation_name]] - -ALTER TABLE tbl_name - [[DEFAULT] CHARACTER SET charset_name] - [COLLATE collation_name] -``` - -例如： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE t1(a int) CHARACTER SET utf8 COLLATE utf8_general_ci; -``` - -``` -Query OK, 0 rows affected (0.08 sec) -``` - -如果表的字符集和排序规则没有设置，那么数据库的字符集和排序规则就作为其默认值。 - -## 列的 Character Set 和 Collation - -列的 Character Set 和 Collation 的语法如下： - -```sql -col_name {CHAR | VARCHAR | TEXT} (col_length) - [CHARACTER SET charset_name] - [COLLATE collation_name] - -col_name {ENUM | SET} (val_list) - [CHARACTER SET charset_name] - [COLLATE collation_name] -``` - -如果列的字符集和排序规则没有设置，那么表的字符集和排序规则就作为其默认值。 - -## 字符串 Character Sets 和 Collation - -每一字符串字符文字有一个字符集和一个比较排序规则，在使用字符串时指，此选项可选，如下： - -```sql -[_charset_name]'string' [COLLATE collation_name] -``` - -示例，如下： - -{{< copyable "sql" >}} - -```sql -SELECT 'string'; -SELECT _latin1'string'; -SELECT _latin1'string' COLLATE latin1_danish_ci; -``` - -规则，如下： - -* 规则1： 指定 CHARACTER SET charset_name 和 COLLATE collation_name，则直接使用 CHARACTER SET charset_name 和COLLATE collation_name。 -* 规则2: 指定 CHARACTER SET charset_name 且未指定 COLLATE collation_name，则使用 CHARACTER SET charset_name 和 CHARACTER SET charset_name 默认的排序比较规则。 -* 规则3: CHARACTER SET charset_name 和 COLLATE collation_name 都未指定，则使用 character_set_connection 和 collation_connection 系统变量给出的字符集和比较排序规则。 - -## 客户端连接的 Character Sets 和 Collations - -* 服务器的字符集和排序规则可以通过系统变量 `character_set_server` 和 `collation_server` 获取。 -* 数据库的字符集和排序规则可以通过环境变量 `character_set_database` 和 `collation_database` 获取。 - -对于每一个客户端的连接，也有相应的变量表示字符集和排序规则：`character_set_connection` 和 `collation_connection`。 - -`character_set_client` 代表客户端的字符集。在返回结果前，服务端会把结果根据 `character_set_results` 转换成对应的字符集。包括结果的元信息等。 - -可以用以下的语句来影响这些跟客户端相关的字符集变量： - -* `SET NAMES 'charset_name' [COLLATE 'collation_name']` - -`SET NAMES` 用来设定客户端会在之后的请求中使用的字符集。`SET NAMES utf8` 表示客户端会在接下来的请求中，都使用 utf8 字符集。服务端也会在之后返回结果的时候使用 utf8 字符集。 -`SET NAMES 'charset_name'` 语句其实等于下面语句的组合： - -{{< copyable "sql" >}} - -```sql -SET character_set_client = charset_name; -SET character_set_results = charset_name; -SET character_set_connection = charset_name; -``` - -`COLLATE` 是可选的，如果没有提供，将会用 charset_name 默认的 Collation。 - -* `SET CHARACTER SET 'charset_name'` - -跟 `SET NAMES` 类似，等价于下面语句的组合： - -{{< copyable "sql" >}} - -```sql -SET character_set_client = charset_name; -SET character_set_results = charset_name; -SET collation_connection = @@collation_database; -``` - -## 集群，服务器，数据库，表，列，字符串 Character Sets 和 Collation 优化级 - -字符串 => 列 => 表 => 数据库 => 服务器 => 集群 - -## Character Sets 和 Collation 通用选择规则 - -* 规则1： 指定 CHARACTER SET charset_name 和 COLLATE collation_name，则直接使用 CHARACTER SET charset_name 和COLLATE collation_name。 -* 规则2: 指定 CHARACTER SET charset_name 且未指定 COLLATE collation_name，则使用 CHARACTER SET charset_name 和 CHARACTER SET charset_name 默认的排序比较规则。 -* 规则3: CHARACTER SET charset_name 和 COLLATE collation_name 都未指定，则使用更高优化级给出的字符集和排序比较规则。 - -## 字符合法性检查 - -当指定的字符集为 utf8 或 utf8mb4 时，TiDB 仅支持合法的 utf8 字符。对于不合法的字符，会报错：`incorrect utf8 value`。该字符合法性检查与 MySQL 8.0 兼容，与 MySQL 5.7 及以下版本不兼容。 - -如果不希望报错，可以通过 `set @@tidb_skip_utf8_check=1;` 跳过字符检查。 - -更多细节，参考 [Connection Character Sets and Collations](https://dev.mysql.com/doc/refman/5.7/en/charset-connection.html)。 diff --git a/dev/reference/sql/constraints.md b/dev/reference/sql/constraints.md deleted file mode 100644 index 69c7e603fc69..000000000000 --- a/dev/reference/sql/constraints.md +++ /dev/null @@ -1,273 +0,0 @@ ---- -title: 约束 -category: reference ---- - -# 约束 - -TiDB 支持的基本约束与 MySQL 的基本相同，但有以下区别： - -- 默认对唯一约束进行[惰性检查](/dev/reference/transactions/overview.md#事务的惰性检查)。通过在事务提交时再进行批量检查，TiDB 能够减少网络开销、提升性能。您可通过设置 `tidb_constraint_check_in_place` 为 `TRUE` 改变此行为。 - -- TiDB 支持创建外键约束，但不会在 DML 语句中对外键进行约束（即外键约束不生效）。 - -## 外键约束 - -目前，TiDB 支持创建外键。例如： - -```sql -CREATE TABLE users ( - id INT NOT NULL PRIMARY KEY AUTO_INCREMENT, - doc JSON -); -CREATE TABLE orders ( - id INT NOT NULL PRIMARY KEY AUTO_INCREMENT, - user_id INT NOT NULL, - doc JSON, - FOREIGN KEY fk_user_id (user_id) REFERENCES users(id) -); -``` - -{{< copyable "sql" >}} - -```sql -SELECT table_name, column_name, constraint_name, referenced_table_name, referenced_column_name -FROM information_schema.key_column_usage WHERE table_name IN ('users', 'orders'); -``` - -``` -+------------+-------------+-----------------+-----------------------+------------------------+ -| table_name | column_name | constraint_name | referenced_table_name | referenced_column_name | -+------------+-------------+-----------------+-----------------------+------------------------+ -| users | id | PRIMARY | NULL | NULL | -| orders | id | PRIMARY | NULL | NULL | -| orders | user_id | fk_user_id | users | id | -+------------+-------------+-----------------+-----------------------+------------------------+ -3 rows in set (0.00 sec) -``` - -TiDB 也支持使用 `ALTER TABLE` 命令来删除外键（`DROP FOREIGN KEY`）和添加外键（`ADD FOREIGN KEY`）： - -{{< copyable "sql" >}} - -```sql -ALTER TABLE orders DROP FOREIGN KEY fk_user_id; -ALTER TABLE orders ADD FOREIGN KEY fk_user_id (user_id) REFERENCES users(id); -``` - -### 注意 - -* TiDB 支持外键是为了在将其他数据库迁移到 TiDB 时，不会因为此语法报错。但是，TiDB 不会在 DML 语句中对外键进行约束。例如，即使 `users` 表中不存在 `id=123` 的记录，下列事务也能提交成功： - - ``` - START TRANSACTION; - INSERT INTO orders (user_id, doc) VALUES (123, NULL); - COMMIT; - ``` - -* TiDB 在执行 `SHOW CREATE TABLE` 语句的结果中不显示外键信息。 - -## 非空约束 - -TiDB 支持的非空约束规则与 MySQL 支持的一致。例如： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE users ( - id INT NOT NULL PRIMARY KEY AUTO_INCREMENT, - age INT NOT NULL, - last_login TIMESTAMP -); -``` - -{{< copyable "sql" >}} - -```sql -INSERT INTO users (id,age,last_login) VALUES (NULL,123,NOW()); -``` - -``` -Query OK, 1 row affected (0.02 sec) -``` - -{{< copyable "sql" >}} - -```sql -INSERT INTO users (id,age,last_login) VALUES (NULL,NULL,NOW()); -``` - -``` -ERROR 1048 (23000): Column 'age' cannot be null -``` - -{{< copyable "sql" >}} - -```sql -INSERT INTO users (id,age,last_login) VALUES (NULL,123,NULL); -``` - -``` -Query OK, 1 row affected (0.03 sec) -``` - -* 第一条 `INSERT` 语句成功，因为对于定义为 `AUTO_INCREMENT` 的列，允许 `NULL` 作为其特殊值。TiDB 将为其分配下一个自动值。 - -* 第二条 `INSERT` 语句失败，因为 `age` 列被定义为 `NOT NULL`。 - -* 第三条 `INSERT` 语句成功，因为 `last_login` 列没有被明确地指定为 `NOT NULL`。默认允许 `NULL` 值。 - -## 主键约束 - -TiDB 支持的主键约束规则与 MySQL 支持的相似。例如： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE t1 (a INT NOT NULL PRIMARY KEY); -``` - -``` -Query OK, 0 rows affected (0.12 sec) -``` - -{{< copyable "sql" >}} - -```sql -CREATE TABLE t2 (a INT NULL PRIMARY KEY); -``` - -``` -ERROR 1171 (42000): All parts of a PRIMARY KEY must be NOT NULL; if you need NULL in a key, use UNIQUE instead -``` - -{{< copyable "sql" >}} - -```sql -CREATE TABLE t3 (a INT NOT NULL PRIMARY KEY, b INT NOT NULL PRIMARY KEY); -``` - -``` -ERROR 1068 (42000): Multiple primary key defined -``` - -{{< copyable "sql" >}} - -```sql -CREATE TABLE t4 (a INT NOT NULL, b INT NOT NULL, PRIMARY KEY (a,b)); -``` - -``` -Query OK, 0 rows affected (0.10 sec) -``` - -* 表 `t2` 创建失败，因为定义为主键的列 `a` 不能允许 `NULL` 值。 -* 表 `t3` 创建失败，因为一张表只能有一个主键。 -* 表 `t4` 创建成功，因为虽然只能有一个主键，但 TiDB 支持定义一个多列组合作为复合主键。 - -除上述规则外，TiDB 还强加了另一个限制，即一旦一张表创建成功，其主键就不能再改变。 - -## 唯一约束 - -在 TiDB 中，默认会对唯一约束进行惰性检查。通过直到事务提交时才进行批量检查，TiDB 能够减少网络通信开销。例如： - -{{< copyable "sql" >}} - -```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) -); -INSERT INTO users (username) VALUES ('dave'), ('sarah'), ('bill'); -``` - -{{< copyable "sql" >}} - -```sql -START TRANSACTION; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -INSERT INTO users (username) VALUES ('jane'), ('chris'), ('bill'); -``` - -``` -Query OK, 3 rows affected (0.00 sec) -Records: 3 Duplicates: 0 Warnings: 0 -``` - -{{< copyable "sql" >}} - -```sql -INSERT INTO users (username) VALUES ('steve'),('elizabeth'); -``` - -``` -Query OK, 2 rows affected (0.00 sec) -Records: 2 Duplicates: 0 Warnings: 0 -``` - -{{< copyable "sql" >}} - -```sql -COMMIT; -``` - -``` -ERROR 1062 (23000): Duplicate entry 'bill' for key 'username' -``` - -* 第一条 `INSERT` 语句不会导致重复键错误，这同 MySQL 的规则一致。该检查将推迟到事务提交时才会进行。 - -如果将 `tidb_constraint_check_in_place` 更改为 `TRUE`，则会在执行语句时就对唯一约束进行检查。例如： - -```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) -); -INSERT INTO users (username) VALUES ('dave'), ('sarah'), ('bill'); -``` - -{{< copyable "sql" >}} - -```sql -SET tidb_constraint_check_in_place = TRUE; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -START TRANSACTION; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -INSERT INTO users (username) VALUES ('jane'), ('chris'), ('bill'); -``` - -``` -ERROR 1062 (23000): Duplicate entry 'bill' for key 'username' -.. -``` - -* 第一条 `INSERT` 语句导致了重复键错误。这会造成额外的网络通信开销，并可能降低插入操作的吞吐量。 diff --git a/dev/reference/sql/data-types/date-and-time.md b/dev/reference/sql/data-types/date-and-time.md deleted file mode 100644 index b3a493bcad45..000000000000 --- a/dev/reference/sql/data-types/date-and-time.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: 日期和时间类型 -category: reference ---- - -# 日期和时间类型 - -TiDB 支持 MySQL 所有的日期和时间类型，包括 DATE、DATETIME、TIMESTAMP、TIME 以及 YEAR，完整信息参考[这篇](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-types.html)文档。 - - - -## 类型定义 - -### `DATE` 类型 - -`DATE` 类型的格式为 `YYYY-MM-DD`，支持的范围是 `1000-01-01` 到 `9999-12-31`。 - -{{< copyable "sql" >}} - -```sql -DATE -``` - -### `TIME` 类型 - -`TIME` 类型的格式为 `HH:MM:SS[.fraction]`，支持的范围是 `-838:59:59.000000` 到 `838:59:59.000000`。`TIME` 不仅可用于指示一天内的时间，还可用于指两个事件之间的时间间隔。`fsp` 参数表示秒精度，取值范围为：0 ~ 6，默认值为 0。 - -{{< copyable "sql" >}} - -```sql -TIME[(fsp)] -``` - -> **注意：** -> -> 注意 `TIME` 的缩写形式。例如，'11:12' 表示 '11:12:00' 而不是 '00:11:12'。但是，'1112' 表示 '00:11:12'。这些差异取决于 `:` 字符的存在与否。 - -### `DATETIME` 类型 - -`DATETIME` 类型是日期和时间的组合，格式为 `YYYY-MM-DD HH:MM:SS[.fraction]`。支持的范围是 `1000-01-01 00:00:00.000000` 到 `9999-12-31 23:59:59.000000`。`fsp` 参数表示秒精度，取值范围为 0~6，默认值为 0。 - -{{< copyable "sql" >}} - -```sql -DATETIME[(fsp)] -``` - -### `TIMESTAMP` 类型 - -`TIMESTAMP` 类型包含日期和时间，支持的范围是 `1970-01-01 00:00:01.000000` 到 `2038-01-19 03:14:07.999999`。`fsp` 参数表示秒精度，取值范围为 0~6，默认值为 0。在 `TIMESTAMP` 中，不允许零出现在月份部分或日期部分，唯一的例外是零值本身 '0000-00-00 00:00:00'。 - -{{< copyable "sql" >}} - -```sql -TIMESTAMP[(fsp)] -``` - -### `YEAR` 类型 - -`YEAR` 类型的格式为 'YYYY'，支持的值范围是 1901 到 2155，或零值 0000。 - -{{< copyable "sql" >}} - -```sql -YEAR[(4)] -``` diff --git a/dev/reference/sql/data-types/overview.md b/dev/reference/sql/data-types/overview.md deleted file mode 100644 index 23a9df9e8272..000000000000 --- a/dev/reference/sql/data-types/overview.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: 数据类型概述 -category: reference ---- - -# 数据类型概述 - -TiDB 支持除空间类型 (`SPATIAL`) 之外的所有 MySQL 数据类型，包括[数值型类型](/dev/reference/sql/data-types/numeric.md)、[字符串类型](/dev/reference/sql/data-types/string.md)、[时间和日期类型](/dev/reference/sql/data-types/date-and-time.md)、[JSON 类型](/dev/reference/sql/data-types/json.md)。 - -数据类型定义一般为 `T(M[, D])`，其中： - -* `T` 表示具体的类型。 -* `M` 在整数类型中表示最大显示长度；在浮点数或者定点数中表示精度；在字符类型中表示最大长度。`M` 的最大值取决于具体的类型。 -* `D` 表示浮点数、定点数的小数位长度。 -* `fsp` 在时间和日期类型里的 `TIME`、`DATETIME` 以及 `TIMESTAMP` 中表示秒的精度，其取值范围是 0 到 6。值为 0 表示没有小数部分。如果省略，则默认精度为 0。 diff --git a/dev/reference/sql/functions-and-operators/aggregate-group-by-functions.md b/dev/reference/sql/functions-and-operators/aggregate-group-by-functions.md deleted file mode 100644 index 4a6fb637dfc9..000000000000 --- a/dev/reference/sql/functions-and-operators/aggregate-group-by-functions.md +++ /dev/null @@ -1,157 +0,0 @@ ---- -title: GROUP BY 聚合函数 -category: reference ---- - -# GROUP BY 聚合函数 - -本文将详细介绍 TiDB 支持的聚合函数。 - -## TiDB 支持的聚合函数 - -TiDB 支持的 MySQL GROUP BY 聚合函数如下所示： - -| 函数名 | 功能描述 | -|:---------|:--------------------| -| [`COUNT()`](https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_count) | 返回检索到的行的数目| -| [`COUNT(DISTINCT)`](https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_count-distinct) | 返回不同值的数目 | -| [`SUM()`](https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_sum) | 返回和 | -| [`AVG()`](https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_avg) | 返回平均值 | -| [`MAX()`](https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_max) | 返回最大值 | -| [`MIN()`](https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_min) | 返回最小值 | -| [`GROUP_CONCAT()`](https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_group-concat) | 返回连接的字符串 | - -> **注意：** -> -> - 除非另有说明，否则聚合函数默认忽略 `NULL` 值。 -> - 如果在不包含 `GROUP BY` 子句的语句中使用聚合函数，则相当于对所有行进行分组。 - -## GROUP BY 修饰符 - -TiDB 目前不支持 `GROUP BY` 修饰符，例如 `WITH ROLLUP`，将来会提供支持。详情参阅 [#4250](https://github.com/pingcap/tidb/issues/4250)。 - -## 对 SQL 模式的支持 - -TiDB 支持 SQL 模式 `ONLY_FULL_GROUP_BY`，当启用该模式时，TiDB 拒绝不明确的非聚合列的查询。例如，以下查询在启用 `ONLY_FULL_GROUP_BY` 时是不合规的，因为 `SELECT` 列表中的非聚合列 "b" 在 `GROUP BY` 语句中不显示： - -{{< copyable "sql" >}} - -```sql -drop table if exists t; -create table t(a bigint, b bigint, c bigint); -insert into t values(1, 2, 3), (2, 2, 3), (3, 2, 3); -``` - -{{< copyable "sql" >}} - -```sql -select a, b, sum(c) from t group by a; -``` - -``` -+------+------+--------+ -| a | b | sum(c) | -+------+------+--------+ -| 1 | 2 | 3 | -| 2 | 2 | 3 | -| 3 | 2 | 3 | -+------+------+--------+ -3 rows in set (0.01 sec) -``` - -{{< copyable "sql" >}} - -```sql -set sql_mode = 'ONLY_FULL_GROUP_BY'; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -select a, b, sum(c) from t group by a; -``` - -``` -ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'b' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by -``` - -目前，TiDB 默认开启 SQL 模式 [`ONLY_FULL_GROUP_BY`](/dev/reference/mysql-compatibility.md#默认设置的区别)。 - -### 与 MySQL 的区别 - -TiDB 目前实现的 `ONLY_FULL_GROUP_BY` 没有 MySQL 5.7 严格。例如，假设我们执行以下查询，希望结果按 "c" 排序： - -{{< copyable "sql" >}} - -```sql -drop table if exists t; -create table t(a bigint, b bigint, c bigint); -insert into t values(1, 2, 1), (1, 2, 2), (1, 3, 1), (1, 3, 2); -select distinct a, b from t order by c; -``` - -要对结果进行排序，必须先清除重复。但选择保留哪一行会影响 `c` 的保留值，也会影响排序，并使其具有任意性。 - -在 MySQL 中，`ORDER BY` 表达式需至少满足以下条件之一，否则 `DISTINCT` 和 `ORDER BY` 查询将因不合规而被拒绝： - -- 表达式等同于 `SELECT` 列表中的一个。 -- 表达式引用并属于查询选择表的所有列都是 `SELECT` 列表的元素。 - -但是在 TiDB 中，上述查询是合规的，详情参阅 [#4254](https://github.com/pingcap/tidb/issues/4254)。 - -TiDB 中另一个标准 SQL 的扩展允许 `HAVING` 子句中的引用使用 `SELECT` 列表中的别名表达式。例如：以下查询返回在 `orders` 中只出现一次的 `name` 值： - -{{< copyable "sql" >}} - -```sql -select name, count(name) from orders -group by name -having count(name) = 1; -``` - -这个 TiDB 扩展允许在聚合列的 `HAVING` 子句中使用别名： - -{{< copyable "sql" >}} - -```sql -select name, count(name) as c from orders -group by name -having c = 1; -``` - -标准 SQL 只支持 `GROUP BY` 子句中的列表达式，以下语句不合规，因为 `FLOOR(value/100)` 是一个非列表达式： - -{{< copyable "sql" >}} - -```sql -select id, floor(value/100) -from tbl_name -group by id, floor(value/100); -``` - -TiDB 对标准 SQL 的扩展支持 `GROUP BY` 子句中非列表达式，认为上述语句合规。 - -标准 SQL 也不支持 `GROUP BY` 子句中使用别名。TiDB 对标准 SQL 的扩展支持使用别名，查询的另一种写法如下： - -{{< copyable "sql" >}} - -```sql -select id, floor(value/100) as val -from tbl_name -group by id, val; -``` - -## TiDB 不支持的聚合函数 - -TiDB 目前不支持的聚合函数如下所示，相关进展参阅 [TiDB #7623](https://github.com/pingcap/tidb/issues/7623)。 - -- `STD`, `STDDEV`, `STDDEV_POP` -- `STDDEV_SAMP` -- `VARIANCE`, `VAR_POP` -- `VAR_SAMP` -- `JSON_ARRAYAGG` -- `JSON_OBJECTAGG` diff --git a/dev/reference/sql/functions-and-operators/bit-functions-and-operators.md b/dev/reference/sql/functions-and-operators/bit-functions-and-operators.md deleted file mode 100644 index 9d44c9caf9af..000000000000 --- a/dev/reference/sql/functions-and-operators/bit-functions-and-operators.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: 位函数和操作符 -category: reference ---- - -# 位函数和操作符 - -TiDB 支持使用 MySQL 5.7 中提供的所有[位函数和操作符](https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html)。 - -**位函数和操作符表** - -| 函数和操作符名 | 功能描述 | -| -------------- | ------------------------------------- | -| [`BIT_COUNT()`](https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html#function_bit-count) | 返回参数二进制表示中为 1 的个数 | -| [&](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) | 右移 | diff --git a/dev/reference/sql/functions-and-operators/cast-functions-and-operators.md b/dev/reference/sql/functions-and-operators/cast-functions-and-operators.md deleted file mode 100644 index 8a6efeacdb27..000000000000 --- a/dev/reference/sql/functions-and-operators/cast-functions-and-operators.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Cast 函数和操作符 -category: reference ---- - -# Cast 函数和操作符 - -Cast 函数和操作符用于将某种数据类型的值转换为另一种数据类型。TiDB 支持使用 MySQL 5.7 中提供的所有 [Cast 函数和操作符](https://dev.mysql.com/doc/refman/5.7/en/cast-functions.html)。 - -## 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) | 将一个值转换成一个确定类型 | diff --git a/dev/reference/sql/functions-and-operators/control-flow-functions.md b/dev/reference/sql/functions-and-operators/control-flow-functions.md deleted file mode 100644 index 407a57690777..000000000000 --- a/dev/reference/sql/functions-and-operators/control-flow-functions.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: 控制流程函数 -category: reference ---- - -# 控制流程函数 - -TiDB 支持使用 MySQL 5.7 中提供的所有[控制流程函数](https://dev.mysql.com/doc/refman/5.7/en/control-flow-functions.html)。 - -| 函数名 | 功能描述 | -|:--------------------------------------------------------------------------------------------------|:----------------------------------| -| [`CASE`](https://dev.mysql.com/doc/refman/5.7/en/control-flow-functions.html#operator_case) | Case 操作符 | -| [`IF()`](https://dev.mysql.com/doc/refman/5.7/en/control-flow-functions.html#function_if) | 构建 if/else | -| [`IFNULL()`](https://dev.mysql.com/doc/refman/5.7/en/control-flow-functions.html#function_ifnull) | 构建 Null if/else | -| [`NULLIF()`](https://dev.mysql.com/doc/refman/5.7/en/control-flow-functions.html#function_nullif) | 如果 expr1 = expr2，返回 `NULL` | diff --git a/dev/reference/sql/functions-and-operators/date-and-time-functions.md b/dev/reference/sql/functions-and-operators/date-and-time-functions.md deleted file mode 100644 index e9bf3ab4b279..000000000000 --- a/dev/reference/sql/functions-and-operators/date-and-time-functions.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: 日期和时间函数 -category: reference ---- - -# 日期和时间函数 - -TiDB 支持使用 MySQL 5.7 中提供的所有[日期和时间函数](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html)。 - -## 日期时间函数表 - -| 函数名 | 功能描述 | -| ------ | ---------------------------------------- | -| [`ADDDATE()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_adddate) | 将时间间隔添加到日期上 | -| [`ADDTIME()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_addtime) | 时间数值相加 | -| [`CONVERT_TZ()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_convert-tz) | 转换时区 | -| [`CURDATE()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_curdate) | 返回当前日期 | -| [`CURRENT_DATE()`, `CURRENT_DATE`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_current-date) | 与 CURDATE() 同义 | -| [`CURRENT_TIME()`, `CURRENT_TIME`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_current-time) | 与 CURTIME() 同义 | -| [`CURRENT_TIMESTAMP()`, `CURRENT_TIMESTAMP`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_current-timestamp) | 与 NOW() 同义 | -| [`CURTIME()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_curtime) | 返回当前时间 | -| [`DATE()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_date) | 从日期或日期/时间表达式中提取日期部分| -| [`DATE_ADD()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_date-add) | 将时间间隔添加到日期上| -| [`DATE_FORMAT()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_date-format) | 返回满足指定格式的日期/时间 | -| [`DATE_SUB()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_date-sub) | 从日期减去指定的时间间隔 | -| [`DATEDIFF()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_datediff) | 返回两个日期间隔的天数| -| [`DAY()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_day) | 与 DAYOFMONTH() 同义| -| [`DAYNAME()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_dayname) | 返回星期名称 | -| [`DAYOFMONTH()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_dayofmonth) | 返回参数对应的天数部分(1-31)| -| [`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) | 返回参数代表一年的哪一天 (1-366) | -| [`EXTRACT()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_extract) | 提取日期/时间中的单独部分| -| [`FROM_DAYS()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_from-days) | 将天数转化为日期 | -| [`FROM_UNIXTIME()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_from-unixtime) | 将 Unix 时间戳格式化为日期 | -| [`GET_FORMAT()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_get-format) | 返回满足日期格式的字符串 | -| [`HOUR()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_hour) | 提取日期/时间表达式中的小时部分 | -| [`LAST_DAY`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_last-day) | 返回参数中月份的最后一天 | -| [`LOCALTIME()`, `LOCALTIME`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_localtime) | 与 NOW() 同义 | -| [`LOCALTIMESTAMP`, `LOCALTIMESTAMP()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_localtimestamp) | 与 NOW() 同义 | -| [`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) | 返回参数的月份名称| -| [`NOW()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_now) | 返回当前日期和时间| -| [`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) | 返回间隔的月数| -| [`QUARTER()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_quarter) | 返回参数对应的季度(1-4) | -| [`SEC_TO_TIME()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_sec-to-time) | 将秒数转化为 'HH:MM:SS' 的格式| -| [`SECOND()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_second) | 返回秒数(0-59) | -| [`STR_TO_DATE()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_str-to-date) | 将字符串转化为日期| -| [`SUBDATE()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_subdate) | 当传入三个参数时作为 DATE_SUB() 的同义| -| [`SUBTIME()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_subtime) | 从一个时间中减去一段时间 | -| [`SYSDATE()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_sysdate) | 返回该方法执行时的时间| -| [`TIME()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_time) | 返回参数的时间表达式部分 | -| [`TIME_FORMAT()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_time-format) | 格式化时间| -| [`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) | 返回时间间隔 | -| [`TIMESTAMP()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_timestamp) | 传入一个参数时候,该方法返回日期或日期/时间表达式, 传入两个参数时候, 返回参数的和 | -| [`TIMESTAMPADD()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_timestampadd) | 在日期/时间表达式上增加一段时间间隔 | -| [`TIMESTAMPDIFF()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_timestampdiff) | 从日期/时间表达式中减去一段时间间隔 | -| [`TO_DAYS()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_to-days) | 将参数转化对应的天数(从第 0 年开始) | -| [`TO_SECONDS()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_to-seconds) | 将日期或日期/时间参数转化为秒数(从第 0 年开始) | -| [`UNIX_TIMESTAMP()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_unix-timestamp) | 返回一个 Unix 时间戳| -| [`UTC_DATE()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_utc-date) | 返回当前的 UTC 日期 | -| [`UTC_TIME()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_utc-time) | 返回当前的 UTC 时间 | -| [`UTC_TIMESTAMP()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_utc-timestamp) | 返回当前的 UTC 日期和时间| -| [`WEEK()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_week) | 返回参数所在的一年中的星期数 | -| [`WEEKDAY()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_weekday) | 返回星期下标 | -| [`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) | 返回参数对应的年数| -| [`YEARWEEK()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_yearweek) | 返回年数和星期数 | diff --git a/dev/reference/sql/functions-and-operators/encryption-and-compression-functions.md b/dev/reference/sql/functions-and-operators/encryption-and-compression-functions.md deleted file mode 100644 index 34b2a6bbd8fa..000000000000 --- a/dev/reference/sql/functions-and-operators/encryption-and-compression-functions.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: 加密和压缩函数 -category: reference ---- - -# 加密和压缩函数 - -TiDB 支持使用 MySQL 5.7 中提供的大部分[加密和压缩函数](https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html)。 - -## 支持的函数 - -| 函数名 | 功能描述 | -|:-----------|:----------------------------| -| [`MD5()`](https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_md5)                                                             | 计算字符串的 MD5 校验和       | -| [`PASSWORD()`](https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_password) | 计算并返回密码字符串 | -| [`RANDOM_BYTES()`](https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_random-bytes) | 返回随机字节向量 | -| [`SHA1()`, `SHA()`](https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_sha1)                                                   | 计算 SHA-1 160 位校验和               | -| [`SHA2()`](https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_sha2)                                                           | 计算 SHA-2 校验和                       | -| [`AES_DECRYPT()`](https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_aes-decrypt) | 使用 AES 解密 | -| [`AES_ENCRYPT()`](https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_aes-encrypt) | 使用 AES 加密 | -| [`COMPRESS()`](https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_compress) | 返回经过压缩的二进制字符串 | -| [`UNCOMPRESS()`](https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_uncompress) | 解压缩字符串 | -| [`UNCOMPRESSED_LENGTH()`](https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_uncompressed-length)                             | 返回字符串解压后的长度 | -| [`CREATE_ASYMMETRIC_PRIV_KEY()`](https://dev.mysql.com/doc/refman/5.7/en/enterprise-encryption-functions.html#function_create-asymmetric-priv-key) | 创建私钥 | -| [`CREATE_ASYMMETRIC_PUB_KEY()`](https://dev.mysql.com/doc/refman/5.7/en/enterprise-encryption-functions.html#function_create-asymmetric-pub-key) | 创建公钥 | -| [`CREATE_DH_PARAMETERS()`](https://dev.mysql.com/doc/refman/5.7/en/enterprise-encryption-functions.html#function_create-dh-parameters) | 创建 DH 共享密钥 | -| [`CREATE_DIGEST()`](https://dev.mysql.com/doc/refman/5.7/en/enterprise-encryption-functions.html#function_create-digest) | 从字符串创建摘要 | -| [`ASYMMETRIC_DECRYPT()`](https://dev.mysql.com/doc/refman/5.7/en/enterprise-encryption-functions.html#function_asymmetric-decrypt) | 使用公钥或私钥解密密文 | -| [`ASYMMETRIC_DERIVE()`](https://dev.mysql.com/doc/refman/5.7/en/enterprise-encryption-functions.html#function_asymmetric-derive) | 从非对称密钥导出对称密钥 | -| [`ASYMMETRIC_ENCRYPT()`](https://dev.mysql.com/doc/refman/5.7/en/enterprise-encryption-functions.html#function_asymmetric-encrypt) | 使用公钥或私钥加密明文 | -| [`ASYMMETRIC_SIGN()`](https://dev.mysql.com/doc/refman/5.7/en/enterprise-encryption-functions.html#function_asymmetric-sign) | 从摘要创建签名 | -| [`ASYMMETRIC_VERIFY()`](https://dev.mysql.com/doc/refman/5.7/en/enterprise-encryption-functions.html#function_asymmetric-verify) | 验证签名字符串是否匹配摘要字符串 | - -## 不支持的函数 - -* `DES_DECRYPT()`、`DES_ENCRYPT()`、`OLD_PASSWORD()` 和 `ENCRYPT()`：这些函数在 MySQL 5.7 中被废弃，并且已在 MySQL 8.0 中移除。 -* `VALIDATE_PASSWORD_STRENGTH()` 函数。 -* 只在 MySQL 企业版中支持的函数。见 [Issue #2632](https://github.com/pingcap/tidb/issues/2632)。 \ No newline at end of file diff --git a/dev/reference/sql/functions-and-operators/information-functions.md b/dev/reference/sql/functions-and-operators/information-functions.md deleted file mode 100644 index b3ec39c0d40a..000000000000 --- a/dev/reference/sql/functions-and-operators/information-functions.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: 信息函数 -category: reference ---- - -# 信息函数 - -TiDB 支持使用 MySQL 5.7 中提供的大部分[信息函数](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html)。 - -## 支持的函数 - -| 函数名 | 功能描述 | -| ------ | ---------------------------------------- | -| [`BENCHMARK()`](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_benchmark) | 循环执行一个表达式 | -| [`CONNECTION_ID()`](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_connection-id) | 返回当前连接的连接 ID (线程 ID) | -| [`CURRENT_USER()`, `CURRENT_USER`](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_current-user) | 返回当前用户的用户名和主机名 | -| [`DATABASE()`](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_database) | 返回默认(当前)的数据库名 | -| [`FOUND_ROWS()`](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_found-rows) | 该函数返回对于一个包含 LIMIT 的 SELECT 查询语句，在不包含 LIMIT 的情况下回返回的记录数 | -| [`LAST_INSERT_ID()`](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_last-insert-id) | 返回最后一条 INSERT 语句中自增列的值 | -| [`ROW_COUNT()`](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_row-count) | 影响的行数 | -| [`SCHEMA()`](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_schema) | 与 DATABASE() 同义 | -| [`SESSION_USER()`](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_session-user) | 与 USER() 同义 | -| [`SYSTEM_USER()`](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_system-user) | 与 USER() 同义 | -| [`USER()`](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_user) | 返回客户端提供的用户名和主机名 | -| [`VERSION()`](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_version) | 返回当前 MySQL 服务器的版本信息 | -| `TIDB_VERSION()` | 返回当前 TiDB 服务器的版本信息 | - -## 不支持的函数 - -* `CHARSET()` -* `COERCIBILITY()` -* `COLLATION()` diff --git a/dev/reference/sql/functions-and-operators/json-functions.md b/dev/reference/sql/functions-and-operators/json-functions.md deleted file mode 100644 index d23f5e6f2b82..000000000000 --- a/dev/reference/sql/functions-and-operators/json-functions.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: JSON 函数及语法糖 -category: reference ---- - -# JSON 函数及语法糖 - -TiDB 支持 MySQL 5.7 GA 版本发布的大多数 JSON 函数。MySQL 5.7 发布后，又增加了更多 JSON 函数，TiDB 并未支持所有这些函数（参见[未支持的函数](#未支持的函数)）。 - -## 创建 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 值的函数 - -| 函数及语法糖 | 功能描述 | -| ------------------------------------------------------------------ | ---------------------------------------------------------- | -| [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 值的函数 - -| 函数及语法糖 | 功能描述 | -| --------------------------------- | ----------- | -| [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_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 值属性的函数 - -| 函数及语法糖 | 功能描述 | -| --------------------------------- | ----------- | -| [JSON_DEPTH(json_doc)][json_depth] | 返回 JSON 文档的最大深度 | -| [JSON_LENGTH(json_doc[, path])][json_length] | 返回 JSON 文档的长度；如果路径参数已定，则返回该路径下值的长度 | -| [JSON_TYPE(json_val)][json_type] | 检查某 JSON 文档内部内容的类型 | - -## 未支持的函数 - -TiDB 暂未支持以下 JSON 函数。相关进展参见 [TiDB #7546](https://github.com/pingcap/tidb/issues/7546): - -* `JSON_APPEND` 及其别名 `JSON_ARRAY_APPEND` -* `JSON_ARRAY_INSERT` -* `JSON_DEPTH` -* `JSON_MERGE_PATCH` -* `JSON_PRETTY` -* `JSON_SEARCH` -* `JSON_STORAGE_SIZE` -* `JSON_VALID` -* `JSON_ARRAYAGG` -* `JSON_OBJECTAGG` - -[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_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/group-by-functions.html#function_json-arrayagg -[json_depth]: https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-depth diff --git a/dev/reference/sql/functions-and-operators/miscellaneous-functions.md b/dev/reference/sql/functions-and-operators/miscellaneous-functions.md deleted file mode 100644 index 6d6c68fd6fc2..000000000000 --- a/dev/reference/sql/functions-and-operators/miscellaneous-functions.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: 其他函数 -category: reference ---- - -# 其他函数 - -TiDB 支持使用 MySQL 5.7 中提供的大部分[其他函数](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html)。 - -## 支持的函数 - -| 函数名 | 功能描述 | -|:------|:-----------| -| [`ANY_VALUE()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_any-value) | 在 `ONLY_FULL_GROUP_BY` 模式下，防止带有 `GROUP BY` 的语句报错 | -| [`DEFAULT()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_default) | 返回表的某一列的默认值 | -| [`INET_ATON()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_inet-aton) | 将 IP 地址转换为数值 | -| [`INET_NTOA()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_inet-ntoa) | 将数值转换为 IP 地址 | -| [`INET6_ATON()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_inet6-aton) | 将 IPv6 地址转换为数值 | -| [`INET6_NTOA()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_inet6-ntoa) | 将数值转换为 IPv6 地址 | -| [`IS_IPV4()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_is-ipv4) | 判断参数是否为 IPv4 地址 | -| [`IS_IPV4_COMPAT()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_is-ipv4-compat) | 判断参数是否为兼容 IPv4 的地址 | -| [`IS_IPV4_MAPPED()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_is-ipv4-mapped) | 判断参数是否为 IPv4 映射的地址 | -| [`IS_IPV6()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_is-ipv6) | 判断参数是否为 IPv6 地址 | -| [`NAME_CONST()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_name-const) | 可以用于重命名列名 | -| [`SLEEP()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_sleep) | 让语句暂停执行几秒时间 | -| [`UUID()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_uuid) | 返回一个通用唯一识别码 (UUID) | -| [`VALUES()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_values) | 定义 `INSERT` 语句使用的值 | - -## 不支持的函数 - -| 函数名 | 功能描述 | -|:------|:-----------| -| [`GET_LOCK()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_get-lock) | 获取命名锁，详见 [TiDB #10929](https://github.com/pingcap/tidb/issues/10929) | -| [`RELEASE_LOCK()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_release-lock) | 释放命名锁，详见 [TiDB #10929](https://github.com/pingcap/tidb/issues/10929) | -| [`UUID_SHORT()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_uuid-short) | 基于特定假设提供唯一的 UUID，目前这些假设在 TiDB 中不存在，详见 [TiDB #4620](https://github.com/pingcap/tidb/issues/4620) | -| [`MASTER_WAIT_POS()`](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_master-pos-wait) | 与 MySQL 同步相关 | \ No newline at end of file diff --git a/dev/reference/sql/functions-and-operators/numeric-functions-and-operators.md b/dev/reference/sql/functions-and-operators/numeric-functions-and-operators.md deleted file mode 100644 index afd6772b2ad4..000000000000 --- a/dev/reference/sql/functions-and-operators/numeric-functions-and-operators.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: 数值函数与操作符 -category: reference ---- - -# 数值函数与操作符 - -TiDB 支持使用 MySQL 5.7 中提供的所有[数值函数与操作符](https://dev.mysql.com/doc/refman/5.7/en/numeric-functions.html)。 - -## 算术操作符 - -| 操作符名 | 功能描述 | -|:-------------|:--------------------------------| -| [`+`](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) | 更改参数符号 | - -## 数学函数 - -| 函数名 | 功能描述 | -|:----------------------------------------------------------------------------------------------------------|:------------------------------------------------------------------| -| [`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) | 返回参数的指定乘方的结果值 | -| [`EXP()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_exp) | 返回 e（自然对数的底）的指定乘方后的值 | -| [`SQRT()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_sqrt) | 返回非负数的二次方根 | -| [`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) | 返回第一个参数的自然对数 | -| [`LOG2()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_log2) | 返回参数以 2 为底的对数 | -| [`LOG10()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_log10) | 返回参数以 10 为底的对数 | -| [`PI()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_pi) | 返回 pi 的值 | -| [`TAN()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_tan) | 返回参数的正切值 | -| [`COT()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_cot) | 返回参数的余切值 | -| [`SIN()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_sin) | 返回参数的正弦值 | -| [`COS()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_cos) | 返回参数的余弦值 | -| [`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) | 返回两个参数的反正切值 | -| [`ASIN()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_asin) | 返回参数的反正弦值 | -| [`ACOS()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_acos) | 返回参数的反余弦值 | -| [`RADIANS()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_radians) | 返回由度转化为弧度的参数 | -| [`DEGREES()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_degrees) | 返回由弧度转化为度的参数 | -| [`MOD()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_mod) | 返回余数 | -| [`ABS()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_abs) | 返回参数的绝对值 | -| [`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) | 返回不小于参数的最小整数值 | -| [`FLOOR()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_floor) | 返回不大于参数的最大整数值 | -| [`ROUND()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_round) | 返回参数最近似的整数或指定小数位数的数值 | -| [`RAND()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_rand) | 返回一个随机浮点值 | -| [`SIGN()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_sign) | 返回参数的符号 | -| [`CONV()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_conv) | 不同数基间转换数字，返回数字的字符串表示 | -| [`TRUNCATE()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_truncate) | 返回被舍位至指定小数位数的数字 | -| [`CRC32()`](https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_crc32)           | 计算循环冗余码校验值并返回一个 32 位无符号值                     | diff --git a/dev/reference/sql/functions-and-operators/operators.md b/dev/reference/sql/functions-and-operators/operators.md deleted file mode 100644 index 5873bd446bf4..000000000000 --- a/dev/reference/sql/functions-and-operators/operators.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -title: 操作符 -category: reference ---- - -# 操作符 - -| 操作符名 | 功能描述 | -| ------- | -------------------------------- | -| [`AND`, &&](https://dev.mysql.com/doc/refman/5.7/en/logical-operators.html#operator_and) | 逻辑与 | -| [`=`](https://dev.mysql.com/doc/refman/5.7/en/assignment-operators.html#operator_assign-equal) | 赋值 (可用于 [`SET`](https://dev.mysql.com/doc/refman/5.7/en/set-variable.html) 语句中, 或用于 [`UPDATE`](https://dev.mysql.com/doc/refman/5.7/en/update.html) 语句的 `SET` 中 ) | -| [`:=`](https://dev.mysql.com/doc/refman/5.7/en/assignment-operators.html#operator_assign-value) | 赋值 | -| [`BETWEEN ... AND ...`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_between) | 判断值满足范围 | -| [`BINARY`](https://dev.mysql.com/doc/refman/5.7/en/cast-functions.html#operator_binary) | 将一个字符串转换为一个二进制字符串 | -| [&](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) | 按位异或 | -| [`CASE`](https://dev.mysql.com/doc/refman/5.7/en/control-flow-functions.html#operator_case) | case 操作符 | -| [`DIV`](https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_div) | 整数除 | -| [`/`](https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_divide) | 除法 | -| [`=`](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_equal-to) | 空值安全型相等比较 | -| [`>`](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) | 大于或等于 | -| [`IS`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is) | 判断一个值是否等于一个布尔值 | -| [`IS NOT`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is-not) | 判断一个值是否不等于一个布尔值 | -| [`IS NOT NULL`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is-not-null) | 非空判断 | -| [`IS NULL`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is-null) | 空值判断 | -| [`<<`](https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html#operator_left-shift) | 左移 | -| [`<`](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) | 简单模式匹配 | -| [`-`](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) | 取反 | -| [`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 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) | 不符合正则表达式模式匹配 | -| [`\|\|`, `OR`](https://dev.mysql.com/doc/refman/5.7/en/logical-operators.html#operator_or) | 逻辑或 | -| [`+`](https://dev.mysql.com/doc/refman/5.7/en/arithmetic-functions.html#operator_plus) | 加 | -| [`REGEXP`](https://dev.mysql.com/doc/refman/5.7/en/regexp.html#operator_regexp) | 使用正则表达式进行模式匹配 | -| [`>>`](https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html#operator_right-shift) | 右移 | -| [`RLIKE`](https://dev.mysql.com/doc/refman/5.7/en/regexp.html#operator_regexp) | REGEXP 同义词 | -| [`*`](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_unary-minus) | 取反符号 | -| [`XOR`](https://dev.mysql.com/doc/refman/5.7/en/logical-operators.html#operator_xor) | 逻辑亦或 | - -## 操作符优先级 - -操作符优先级显示在以下列表中，从最高优先级到最低优先级。同一行显示的操作符具有相同的优先级。 - -```sql -INTERVAL -BINARY -! -- (unary minus), ~ (unary bit inversion) -^ -*, /, DIV, %, MOD --, + -<<, >> -& -| -= (comparison), <=>, >=, >, <=, <, <>, !=, IS, LIKE, REGEXP, IN -BETWEEN, CASE, WHEN, THEN, ELSE -NOT -AND, && -XOR -OR, || -= (assignment), := -``` - -详情参见 [这里](https://dev.mysql.com/doc/refman/5.7/en/operator-precedence.html). - -## 比较方法和操作符 - -| 操作符名 | 功能描述 | -| ------- | -------------------------------- | -| [`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) | 返回第一个非空值 | -| [`=`](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_equal-to) | 空值安全型相等比较 | -| [`>`](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) | 大于或等于 | -| [`GREATEST()`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#function_greatest) | 返回最大值 | -| [`IN()`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#function_in) | 判断值是否在一个值的集合内 | -| [`INTERVAL()`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#function_interval) | 返回一个小于第一个参数的参数的下标 | -| [`IS`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is) | 判断是否等于一个布尔值 | -| [`IS NOT`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is-not) | 判断是否不等于一个布尔值 | -| [`IS NOT NULL`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is-not-null) | 非空判断 | -| [`IS NULL`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_is-null) | 空值判断 | -| [`ISNULL()`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#function_isnull) | 判断参数是否为空 | -| [`LEAST()`](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#function_least) | 返回最小值 | -| [`<`](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) | 简单模式匹配 | -| [`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#function_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) | 比较两个字符串 | - -详情参见 [这里](https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html). - -## 逻辑操作符 - -| 操作符名 | 功能描述 | -| ------- | -------------------------------- | -| [`AND`, &&](https://dev.mysql.com/doc/refman/5.7/en/logical-operators.html#operator_and) | 逻辑与 | -| [`NOT`, `!`](https://dev.mysql.com/doc/refman/5.7/en/logical-operators.html#operator_not) | 逻辑非 | -| [`\|\|`, `OR`](https://dev.mysql.com/doc/refman/5.7/en/logical-operators.html#operator_or) | 逻辑或 | -| [`XOR`](https://dev.mysql.com/doc/refman/5.7/en/logical-operators.html#operator_xor) | 逻辑亦或 | - -详情参见 [这里](https://dev.mysql.com/doc/refman/5.7/en/group-by-handling.html). - -## 赋值操作符 - -| 操作符名 | 功能描述 | -| ------- | -------------------------------- | -| [`=`](https://dev.mysql.com/doc/refman/5.7/en/assignment-operators.html#operator_assign-equal) | 赋值 (可用于 [`SET`](https://dev.mysql.com/doc/refman/5.7/en/set-variable.html) 语句中, 或用于 [`UPDATE`](https://dev.mysql.com/doc/refman/5.7/en/update.html) 语句的 `SET` 中 ) | -| [`:=`](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). diff --git a/dev/reference/sql/functions-and-operators/precision-math.md b/dev/reference/sql/functions-and-operators/precision-math.md deleted file mode 100644 index dc6953bb5a23..000000000000 --- a/dev/reference/sql/functions-and-operators/precision-math.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -title: 精度数学 -category: reference ---- - -# 精度数学 - -TiDB 中精度数学计算与 MySQL 中基本一致, 详情请参见: [Precision Math](https://dev.mysql.com/doc/refman/5.7/en/precision-math.html). - -- 数值类型 -- DECIMAL 数据类型的特性 - -## 数值类型 - -精确数值运算的范围包括精确值数据类型(整型和 DECIMAL 类型), 以及精确值数字字面量. 近似值数据类型和近似值数字字面量被作为浮点数来处理. - -精确值数字字面量包含整数部分或小数部分, 或二者都包含. 精确值数字字面量可以包含符号位. 例如: 1, .2, 3.4, -5, -6.78, +9.10. - -近似值数字字面量以一个包含尾数和指数的科学计数法表示(基数为 10). 其中尾数和指数可以分别或同时带有符号位. 例如: 1.2E3, 1.2E-3, -1.2E3, -1.2E-3. - -两个看起来相似的数字可能会被以不同的方式进行处理. 例如, 2.34 是精确值(定点数), 而 2.3E0 是近似值(浮点数). - -DECIMAL 数据类型是定点数类型, 其运算是精确计算. FLOAT 和 DOUBLE 数据类型是浮点类型, 其运算是近似计算. - -## DECIMAL 数据类型的特性 - -本节讨论 DECIMAL 数据类型的特性, 主要涉及以下几点: - -1. 最大位数 -2. 存储格式 -3. 存储要求 - -DECIMAL 列的声明语法为 DECIMAL(M, D). 其中参数值意义及其范围如下: - -- M 表示最大的数字位数 (精度). 1<= M <= 65. -- D 表示小数点右边数字的位数 (标度). 1 <= D <= 30 且 不大于 M. - -M 的最大值 65 表示 DECIMAL 值的计算精确到 65 位数字. 该精度同样适用于其精确值字面量. - -DECIMAL 列的值采用二进制进行存储, 其将每 9 位十进制数字包装成 4 个字节. 其中整数和小数部分分别确定所需的存储空间. 如果数字位数为 9 的倍数, 则每 9 位十进制数字各采用 4 个字节进行存储, 对于剩余不足 9 位的数字, 所需的存储空间如下表所示. - -| 剩余数字位数 | 存储所需字节数 | -| --- | --- | -| 0 | 0 | -| 1–2 | 1 | -| 3–4 | 2 | -| 5–6 | 3 | -| 7–9 | 4 | - -例如, 定义类型为 DECIMAL(18, 9) 的列, 其小数点两侧均各包含 9 位十进制数字, 因此, 分别需要 4 个字节的存储空间. 定义类型为 DECIMAL(20, 6) 的列, 其小数部分包含 6 位十进制数字, 整数部分包含 14 位十进制数字. 整数部分中 9 位数字需要 4 个字节进行存储, 其余 5 位数字需要 3 个字节进行存储. 小数部分 6 位数字需要 3 个字节进行存储. - -DECIMAL 列不存储前导的字符 `+` 或字符 `-` 或数字 `0`. 如果将 +0003.1 插入到 DECIMAL(5, 1) 列中, 则将其存储为3.1. 对于负数, 不存储字符 `-` 的字面值. - -DECIMAL 列不允许插入大于列定义的隐含范围的值. 例如, DECIMAL(3, 0) 列范围为 -999 到 999. DECIMAL(M, D) 列小数点左边部分最多支持 M-D 位数字. - -有关 DECIMAL 值的内部格式完整说明, 请参阅 TiDB 源码文件 [types/mydecimal.go](https://github.com/pingcap/tidb/blob/master/types/mydecimal.go). - -## 表达式计算 - -在涉及精度数学计算的表达式中，TiDB 会尽可能不做任何修改的使用每个输入的数值。比如：在计算比较函数时，参与运算的数字将不做任何改变。在严格 SQL 模式下，向一个数据列插入一个值时，如果该值处于这一列的值域范围内，这个值将直接不做任何修改的直接插入进去，提取这个值的时候，取得的值和插入的值将会是同一个值。当处于非严格 SQL 模式时，TiDB 会允许数据插入过程中发生的数据截断。 - -处理数值类型表达式取决于这个表达式参数的具体值： - -* 当表达式参数中包含近似值时，这个表达式的结果也是近似值，TiDB 会使用浮点数对应的计算逻辑返回一个浮点数的结果 -* 当表达式参数中不包含任何近似值时（也就是说表达式的参数全部是精确值），如果某个精确值包含小数部分，TIDB 会对这个表达式使用 `DECIMAL` 对应的计算逻辑，返回一个 `DECIMAL` 的结果，精确到 65 位数字 -* 其他情况下，表达式只会包含整数参数，这个表达式的结果也是精确的，TiDB 会使用整数对应的计算逻辑返回一个整数结果，精度和 `BIGINT` 保持一致（64位） - -如果数值类型表达式中包含字符串参数，这些字符串参数将被转换成双精度浮点数，这个表达式的计算结果将是个近似值。 - -向一个数值类型列插入数据的具体行为会受到 SQL 模式的影响。接下来的讨论将围绕严格模式以及 `ERROR_FOR_DIVISION_BY_ZERO` 模式展开，如果要打开所有的限制，可以简单的使用 `TRADITIONAL` 模式，这个模式将同时使用严格模式以及 `ERROR_FOR_DIVISION_BY_ZERO` 模式： - -{{< copyable "sql" >}} - -```sql -SET sql_mode = 'TRADITIONAL'; -``` - -向一个具有精确值类型（`DECIMAL` 或者整数类型）的列插入数据时，如果插入的数据位于该列的值域范围内将使用该数据的精确值。如果该数据的小数部分太长，将会发生数值修约，这时会有 warning 产生，具体内容可以看"数值修约"。 - -如果该数据整数部分太长： - -* 如果没有开启严格模式，这个值会被截断并产生一个 warning -* 如果开启了严格模式，将会产生一个数据溢出的 error - -如果向一个数值类型列插入字符串，如果该字符串中包含非数值部分，TiDB 将这样做类型转换： - -* 在严格模式下，没有以数字开头的字符串（即使是一个空字符串）不能被被用作数字值并会返回一个 error 或者是 warning； -* 以数字开头的字符串可以被转换，不过末尾的非数字部分会被截断。如果被截断的部分包含的不全是空格，在严格模式下这回产生一个 error 或者 warning - -默认情况下，如果计算的过程中发生了除数是 0 的现象将会得到一个 `NULL` 结果，并且不会有 warning 产生。通过设置适当的 SQL 模式，除以 0 的操作可以被限制：当设置 `ERROR_FOR_DIVISION_BY_ZERO` SQL 模式时，TiDB 的行为是： - -* 如果设置了严格 SQL 模式，`INSERT` 和 `UPDATE` 的过程中如果发生了除以 0 的操作，正在进行的 `INSERT` 或者 `UPDATE` 操作会被禁止，并且会返回一个 error -* 如果没有设置严格 SQL 模式，除以 0 的操作仅会返回一个 warning - -假设我们有如下的 SQL 语句： - -{{< copyable "sql" >}} - -```sql -INSERT INTO t SET i = 1/0; -``` - -不同的 SQL 模式将会导致不同的结果如下： - -| `sql_mode` 的值 | 结果 | -| :--- | :--- | -| '' | 没有 warning，没有 error，i 被设为 NULL | -| strict | 没有 warning，没有 error，i 被设为 NULL | -| `ERROR_FOR_DIVISION_BY_ZERO` | 有 warning，没有 error，i 被设为 NULL | -| strict, `ERROR_FOR_DIVISION_BY_ZERO` | 有 error，插入失败 | - -## 数值修约 - -`round()` 函数的结果取决于他的参数是否是精确值： - -* 如果参数是精确值，`round()` 函数将使用四舍五入的规则 -* 如果参数是一个近似值，`round()` 表达式的结果可能和 MySQL 不太一样 - -{{< copyable "sql" >}} - -```sql -SELECT ROUND(2.5), ROUND(25E-1); -``` - -``` -+------------+--------------+ -| ROUND(2.5) | ROUND(25E-1) | -+------------+--------------+ -| 3 | 3 | -+------------+--------------+ -1 row in set (0.00 sec) -``` - -向一个 `DECIMAL` 或者整数类型列插入数据时，round 的规则将采用 [round half away from zero](https://en.wikipedia.org/wiki/Rounding#Round_half_away_from_zero) 的方式： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE t (d DECIMAL(10,0)); -``` - -``` -Query OK, 0 rows affected (0.01 sec) -``` - -{{< copyable "sql" >}} - -```sql -INSERT INTO t VALUES(2.5),(2.5E0); -``` - -``` -Query OK, 2 rows affected, 2 warnings (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT d FROM t; -``` - -``` -+------+ -| d | -+------+ -| 3 | -| 3 | -+------+ -2 rows in set (0.00 sec) -``` diff --git a/dev/reference/sql/functions-and-operators/reference.md b/dev/reference/sql/functions-and-operators/reference.md deleted file mode 100644 index fbd7d93c241d..000000000000 --- a/dev/reference/sql/functions-and-operators/reference.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: 函数和操作符概述 -category: reference ---- - -# 函数和操作符概述 - -TiDB 中函数和操作符使用方法与 MySQL 基本一致，详情参见: [Functions and Operators](https://dev.mysql.com/doc/refman/5.7/en/functions.html)。 - -在 SQL 语句中，表达式可用于诸如 `SELECT` 语句的 `ORDER BY` 或 `HAVING` 子句，`SELECT`/`DELETE`/`UPDATE` 语句的 `WHERE` 子句，或 `SET` 语句之类的地方。 - -可使用字面值，列名，NULL，内置函数，操作符等来书写表达式。其中有些表达式下推到 TiKV 上执行，详见[下推到 TiKV 的表达式列表](/dev/reference/sql/functions-and-operators/expressions-pushed-down.md)。 diff --git a/dev/reference/sql/functions-and-operators/string-functions.md b/dev/reference/sql/functions-and-operators/string-functions.md deleted file mode 100644 index 6ebc49116845..000000000000 --- a/dev/reference/sql/functions-and-operators/string-functions.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: 字符串函数 -category: reference ---- - -# 字符串函数 - -TiDB 支持使用 MySQL 5.7 中提供的大部分[字符串函数](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html)。 - -## 支持的函数 - -| 函数名 | 功能描述 | -|:----------|:-----------------------| -| [`ASCII()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_ascii) | 返回最左字符的数值 | -| [`BIN()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_bin) | 返回一个数的二进制值的字符串表示 | -| [`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) | 返回字符串的字符长度 | -| [`CHARACTER_LENGTH()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_character-length) | 与 `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) | 返回指定位置的字符串 | -| [`EXPORT_SET()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_export-set) | 返回一个字符串，其中值位中设置的每个位，可以得到一个 on 字符串，而每个未设置的位，可以得到一个 off 字符串 | -| [`FIELD()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_field) | 返回参数在后续参数中出现的第一个位置 | -| [`FIND_IN_SET()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_find-in-set) | 返回第一个参数在第二个参数中出现的位置 | -| [`FORMAT()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_format) | 返回指定小数位数格式的数字 | -| [`FROM_BASE64()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_from-base64) | 解码 base-64 表示的字符串，并返回结果 | -| [`HEX()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_hex) | 返回一个十进制数或字符串值的 16 进制表示 | -| [`INSERT()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_insert) | 在指定位置插入一个子字符串，最多不超过指定字符数 | -| [`INSTR()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_instr) | 返回第一次出现的子字符串的索引 | -| [`LCASE()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_lcase) | 与 `LOWER()` 功能相同 | -| [`LEFT()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_left) | 返回最左侧指定长度的字符 | -| [`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) | 进行简单模式匹配 | -| [`LOCATE()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_locate) | 返回第一次出现的子字符串的位置 | -| [`LOWER()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_lower) | 返回全小写的参数 | -| [`LPAD()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_lpad) | 返回字符串参数，左侧添加指定字符串 | -| [`LTRIM()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_ltrim) | 去掉前缀空格 | -| [`MAKE_SET()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_make-set) | 返回一组用逗号分隔的字符串，这些字符串的位数与给定的 bits 参数对应 | -| [`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` 的否定形式 | -| [`OCT()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_oct) | 返回一个数值的八进制表示，形式为字符串 | -| [`OCTET_LENGTH()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_octet-length) | 与 `LENGTH()` 功能相同 | -| [`ORD()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_ord) | 返回该参数最左侧字符的字符编码 | -| [`POSITION()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_position) | 与 `LOCATE()` 功能相同 | -| [`QUOTE()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_quote) | 使参数逃逸，为了在 SQL 语句中使用 | -| [`REGEXP`](https://dev.mysql.com/doc/refman/5.7/en/regexp.html#operator_regexp) | 使用正则表达式匹配模式 | -| [`REPEAT()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_repeat) | 以指定次数重复一个字符串 | -| [`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) | 返回指定数量的最右侧的字符 | -| [`RLIKE`](https://dev.mysql.com/doc/refman/5.7/en/regexp.html#operator_regexp) | 与 `REGEXP` 功能相同 | -| [`RPAD()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_rpad) | 以指定次数添加字符串 | -| [`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) | 返回指定的子字符串 | -| [`SUBSTRING_INDEX()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_substring-index) | 从一个字符串中返回指定出现次数的定界符之前的子字符串 | -| [`TO_BASE64()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_to-base64) | 返回转化为 base-64 表示的字符串参数 | -| [`TRIM()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_trim) | 去掉前缀和后缀空格 | -| [`UCASE()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_ucase) | 与 `UPPER()` 功能相同 | -| [`UNHEX()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_unhex) | 返回一个数的十六进制表示，形式为字符串 | -| [`UPPER()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_upper) | 参数转换为大写形式 | - -## 不支持的函数 - -* `LOAD_FILE()` -* `MATCH` -* `SOUNDEX()` -* `SOUNDS LIKE` -* `WEIGHT_STRING()` diff --git a/dev/reference/sql/functions-and-operators/type-conversion.md b/dev/reference/sql/functions-and-operators/type-conversion.md deleted file mode 100644 index 1a88da5de4da..000000000000 --- a/dev/reference/sql/functions-and-operators/type-conversion.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: 表达式求值的类型转换 -category: reference ---- - -# 表达式求值的类型转换 - -TiDB 中表达式求值的类型转换与 MySQL 基本一致，详情参见 [MySQL 表达式求值的类型转换](https://dev.mysql.com/doc/refman/5.7/en/type-conversion.html)。 diff --git a/dev/reference/sql/generated-columns.md b/dev/reference/sql/generated-columns.md deleted file mode 100644 index 10796fc678a9..000000000000 --- a/dev/reference/sql/generated-columns.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: 生成列 -category: reference ---- - -# 生成列 - -为了在功能上兼容 MySQL 5.7，TiDB 支持生成列 (generated column)。生成列的主要的作用之一：从 JSON 数据类型中解出数据，并为该数据建立索引。 - -## 使用 generated column 对 JSON 建索引 - -MySQL 5.7 及 TiDB 都不能直接为 JSON 类型的列添加索引，即**不支持**如下表结构： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE person ( - id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, - name VARCHAR(255) NOT NULL, - address_info JSON, - KEY (address_info) -); -``` - -为 JSON 列添加索引之前，首先必须抽取该列为 generated column。 - -以 `city` generated stored column 为例，你可以添加索引： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE person ( - id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, - name VARCHAR(255) NOT NULL, - address_info JSON, - city VARCHAR(64) AS (JSON_UNQUOTE(JSON_EXTRACT(address_info, '$.city'))) STORED, - KEY (city) -); -``` - -该表中，`city` 列是一个 **generated stored column**。顾名思义，此列由该表的其他列生成，对此列进行插入或更新操作时，并不能对之赋值。此列按其定义的表达式生成，并存储在数据库中，这样在读取此列时，就可以直接读取，不用再读取其依赖的 `address_info` 列后再计算得到。`city` 列的索引**存储在数据库中**，并使用和 `varchar(64)` 类的其他索引相同的结构。 - -可使用 generated stored column 的索引，以提高如下语句的执行速度： - -{{< copyable "sql" >}} - -```sql -SELECT name, id FROM person WHERE city = 'Beijing'; -``` - -如果 `$.city` 路径中无数据，则 `JSON_EXTRACT` 返回 `NULL`。如果想增加约束，`city` 列必须是 `NOT NULL`，则可按照以下方式定义 virtual column： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE person ( - id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, - name VARCHAR(255) NOT NULL, - address_info JSON, - city VARCHAR(64) AS (JSON_UNQUOTE(JSON_EXTRACT(address_info, '$.city'))) STORED NOT NULL, - KEY (city) -); -``` - -`INSERT` 和 `UPDATE` 语句都会检查 virtual column 的定义。未通过有效性检测的行会返回错误： - -{{< copyable "sql" >}} - -```sql -INSERT INTO person (name, address_info) VALUES ('Morgan', JSON_OBJECT('Country', 'Canada')); -``` - -``` -ERROR 1048 (23000): Column 'city' cannot be null -``` - -## 使用 generated virtual column - -TiDB 也支持 generated virtual column，和 generated store column 不同的是，此列按需生成，并不存储在数据库中，也不占用内存空间，因而是**虚拟的**。 - -{{< copyable "sql" >}} - -```sql -CREATE TABLE person ( - id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, - name VARCHAR(255) NOT NULL, - address_info JSON, - city VARCHAR(64) AS (JSON_UNQUOTE(JSON_EXTRACT(address_info, '$.city'))) VIRTUAL -); -``` - -## 局限性 - -目前 JSON and generated column 有以下局限性： - -- 不能通过 `ALTER TABLE` 增加 `STORED` 存储方式的 generated column； -- 不能通过 `ALTER TABLE` 将 generated stored column 转换为普通列，也不能将普通列转换成 generated stored column； -- 不能通过 `ALTER TABLE` 修改 generated stored column 的**生成列表达式**； -- 并未支持所有的 [JSON 函数](/dev/reference/sql/functions-and-operators/json-functions.md)。 \ No newline at end of file diff --git a/dev/reference/sql/language-structure/comment-syntax.md b/dev/reference/sql/language-structure/comment-syntax.md deleted file mode 100644 index 8c67a32a3196..000000000000 --- a/dev/reference/sql/language-structure/comment-syntax.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -title: 注释语法 -category: reference ---- - -# 注释语法 - -TiDB 支持三种注释风格： - -* 用 `#` 注释一行 -* 用 `--` 注释一行，用 `--` 注释必须要在其之后留出至少一个空格。 -* 用 `/* */` 注释一块，可以注释多行。 - -例： - -{{< copyable "sql" >}} - -```sql -SELECT 1+1; # 注释文字 -``` - -``` -+------+ -| 1+1 | -+------+ -| 2 | -+------+ -1 row in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT 1+1; -- 注释文字 -``` - -``` -+------+ -| 1+1 | -+------+ -| 2 | -+------+ -1 row in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT 1 /* 这是行内注释文字 */ + 1; -``` - -``` -+--------+ -| 1 + 1 | -+--------+ -| 2 | -+--------+ -1 row in set (0.01 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT 1+ - -> /* - /*> 这是一条 - /*> 多行注释 - /*> */ - -> 1; -``` - -``` -+-------+ -| 1+ - -1 | -+-------+ -| 2 | -+-------+ -1 row in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT 1+1--1; -``` - -``` -+--------+ -| 1+1--1 | -+--------+ -| 3 | -+--------+ -1 row in set (0.01 sec) -``` - -TiDB 也跟 MySQL 保持一致，支持一种 C 风格注释的变体： - -``` -/*! Specific code */ -``` - -在这种格式中，TiDB 会执行注释中的语句，这个语法是为了让这些 SQL 在其他的数据库中被忽略，而在 TiDB 中被执行。 - -例如：`SELECT /*! STRAIGHT_JOIN */ col1 FROM table1,table2 WHERE ...` - -在 TiDB 中，这种写法等价于 `SELECT STRAIGHT_JOIN col1 FROM table1,table2 WHERE ...` - -如果注释中指定了 Server 版本号，例如 `/*!50110 KEY_BLOCK_SIZE=1024 */`，在 MySQL 中表示只有 MySQL 的版本大于等于 5.1.10 才会处理这个 comment 中的内容。但是在 TiDB 中，这个版本号不会起作用，所有的 comment 都会处理。 - -还有一种注释会被当做是优化器 Hint 特殊对待： - -{{< copyable "sql" >}} - -```sql -SELECT /*+ hint */ FROM ...; -``` - -由于 hint 包含在类似 /*+ xxx */ 的 comment 里，MySQL 客户端在 5.7.7 之前，会默认把 comment 清除掉，如果需要在旧的客户端使用 hint，需要在启动客户端时加上 --comments 选项，例如 mysql -h 127.0.0.1 -P 4000 -uroot --comments - -TiDB 支持的相关优化器 hint 详见 [Optimizer Hints](/dev/reference/performance/optimizer-hints.md)。 - -更多[细节](https://dev.mysql.com/doc/refman/5.7/en/comments.html)。 diff --git a/dev/reference/sql/language-structure/expression-syntax.md b/dev/reference/sql/language-structure/expression-syntax.md deleted file mode 100644 index d11a4ad8cf16..000000000000 --- a/dev/reference/sql/language-structure/expression-syntax.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: 表达式语法 -category: reference ---- - -# 表达式语法 (Expression Syntax) - -在 TiDB 中，以下规则是表达式的语法，你可以在 `parser/parser.y` 中找到定义。TiDB 的语法解析是基于 yacc 的。 - -``` -Expression: - singleAtIdentifier assignmentEq Expression - | Expression logOr Expression - | Expression "XOR" Expression - | Expression logAnd Expression - | "NOT" Expression - | Factor IsOrNotOp trueKwd - | Factor IsOrNotOp falseKwd - | Factor IsOrNotOp "UNKNOWN" - | Factor - -Factor: - Factor IsOrNotOp "NULL" - | Factor CompareOp PredicateExpr - | Factor CompareOp singleAtIdentifier assignmentEq PredicateExpr - | Factor CompareOp AnyOrAll SubSelect - | PredicateExpr - -PredicateExpr: - PrimaryFactor InOrNotOp '(' ExpressionList ')' - | PrimaryFactor InOrNotOp SubSelect - | PrimaryFactor BetweenOrNotOp PrimaryFactor "AND" PredicateExpr - | PrimaryFactor LikeOrNotOp PrimaryExpression LikeEscapeOpt - | PrimaryFactor RegexpOrNotOp PrimaryExpression - | PrimaryFactor - -PrimaryFactor: - PrimaryFactor '|' PrimaryFactor - | PrimaryFactor '&' PrimaryFactor - | PrimaryFactor "<<" PrimaryFactor - | PrimaryFactor ">>" PrimaryFactor - | PrimaryFactor '+' PrimaryFactor - | PrimaryFactor '-' PrimaryFactor - | PrimaryFactor '*' PrimaryFactor - | PrimaryFactor '/' PrimaryFactor - | PrimaryFactor '%' PrimaryFactor - | PrimaryFactor "DIV" PrimaryFactor - | PrimaryFactor "MOD" PrimaryFactor - | PrimaryFactor '^' PrimaryFactor - | PrimaryExpression - -PrimaryExpression: - Operand - | FunctionCallKeyword - | FunctionCallNonKeyword - | FunctionCallAgg - | FunctionCallGeneric - | Identifier jss stringLit - | Identifier juss stringLit - | SubSelect - | '!' PrimaryExpression - | '~' PrimaryExpression - | '-' PrimaryExpression - | '+' PrimaryExpression - | "BINARY" PrimaryExpression - | PrimaryExpression "COLLATE" StringName -``` diff --git a/dev/reference/sql/language-structure/keywords-and-reserved-words.md b/dev/reference/sql/language-structure/keywords-and-reserved-words.md deleted file mode 100644 index 30aa376fa563..000000000000 --- a/dev/reference/sql/language-structure/keywords-and-reserved-words.md +++ /dev/null @@ -1,483 +0,0 @@ ---- -title: 关键字和保留字 -category: reference ---- - -# 关键字和保留字 - -关键字在 SQL 中有特殊的意义， 例如 `SELECT`，`UPDATE`，`DELETE`，在作为表名跟函数名的时候，需要特殊对待，例如作为表名，保留字需要被反引号包住： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE select (a INT); -``` - -``` -ERROR 1105 (HY000): line 0 column 19 near " (a INT)" (total length 27) -``` - -{{< copyable "sql" >}} - -```sql -CREATE TABLE `select` (a INT); -``` - -``` -Query OK, 0 rows affected (0.09 sec) -``` - -`BEGIN` 和 `END` 是关键字， 但不是保留字，所以不需要反引号： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE `select` (BEGIN int, END int); -``` - -``` -Query OK, 0 rows affected (0.09 sec) -``` - -有一种特殊情况， 如果使用了限定符 `.`，那么也不需要用反引号： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE test.select (BEGIN int, END int); -``` - -``` -Query OK, 0 rows affected (0.08 sec) -``` - -下表列出了 TiDB 中的关键字和保留字。保留字用 `(R)` 来标识。[窗口函数](/dev/reference/sql/functions-and-operators/window-functions.md)的保留字用 `(R-Window)` 来标识： - -{{< tabs-panel "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" "Q" "R" "S" "T" "U" "V" "W" "X" "Y" "Z" >}} - -A - -- ACTION -- ADD (R) -- ADDDATE -- ADMIN -- AFTER -- ALL (R) -- ALTER (R) -- ALWAYS -- ANALYZE(R) -- AND (R) -- ANY -- AS (R) -- ASC (R) -- ASCII -- AUTO_INCREMENT -- AVG -- AVG_ROW_LENGTH - -B - -- BEGIN -- BETWEEN (R) -- BIGINT (R) -- BINARY (R) -- BINLOG -- BIT -- BIT_XOR -- BLOB (R) -- BOOL -- BOOLEAN -- BOTH (R) -- BTREE -- BY (R) -- BYTE - -C - -- CASCADE (R) -- CASE (R) -- CAST -- CHANGE (R) -- CHAR (R) -- CHARACTER (R) -- CHARSET -- CHECK (R) -- CHECKSUM -- COALESCE -- COLLATE (R) -- COLLATION -- COLUMN (R) -- COLUMNS -- COMMENT -- COMMIT -- COMMITTED -- COMPACT -- COMPRESSED -- COMPRESSION -- CONNECTION -- CONSISTENT -- CONSTRAINT (R) -- CONVERT (R) -- COUNT -- CREATE (R) -- CROSS (R) -- CUME_DIST (R-Window) -- CURRENT_DATE (R) -- CURRENT_TIME (R) -- CURRENT_TIMESTAMP (R) -- CURRENT_USER (R) -- CURTIME - -D - -- DATA -- DATABASE (R) -- DATABASES (R) -- DATE -- DATE_ADD -- DATE_SUB -- DATETIME -- DAY -- DAY_HOUR (R) -- DAY_MICROSECOND (R) -- DAY_MINUTE (R) -- DAY_SECOND (R) -- DDL -- DEALLOCATE -- DEC -- DECIMAL (R) -- DEFAULT (R) -- DELAY_KEY_WRITE -- DELAYED (R) -- DELETE (R) -- DENSE_RANK (R-Window) -- DESC (R) -- DESCRIBE (R) -- DISABLE -- DISTINCT (R) -- DISTINCTROW (R) -- DIV (R) -- DO -- DOUBLE (R) -- DROP (R) -- DUAL (R) -- DUPLICATE -- DYNAMIC - -E - -- ELSE (R) -- ENABLE -- ENCLOSED -- END -- ENGINE -- ENGINES -- ENUM -- ESCAPE -- ESCAPED -- EVENTS -- EXCLUSIVE -- EXECUTE -- EXISTS -- EXPLAIN (R) -- EXTRACT - -F - -- FALSE (R) -- FIELDS -- FIRST -- FIRST_VALUE (R-Window) -- FIXED -- FLOAT (R) -- FLUSH -- FOR (R) -- FORCE (R) -- FOREIGN (R) -- FORMAT -- FROM (R) -- FULL -- FULLTEXT (R) -- FUNCTION - -G - -- GENERATED (R) -- GET_FORMAT -- GLOBAL -- GRANT (R) -- GRANTS -- GROUP (R) -- GROUP_CONCAT -- GROUPS (R-Window) - -H - -- HASH -- HAVING (R) -- HIGH_PRIORITY (R) -- HOUR -- HOUR_MICROSECOND (R) -- HOUR_MINUTE (R) -- HOUR_SECOND (R) - -I - -- IDENTIFIED -- IF (R) -- IGNORE (R) -- IN (R) -- INDEX (R) -- INDEXES -- INFILE (R) -- INNER (R) -- INSERT (R) -- INT (R) -- INTEGER (R) -- INTERVAL (R) -- INTO (R) -- IS (R) -- ISOLATION - -J - -- JOBS -- JOIN (R) -- JSON - -K - -- KEY (R) -- KEY_BLOCK_SIZE -- KEYS (R) -- KILL (R) - -L - -- LAG (R-Window) -- LAST_VALUE (R-Window) -- LEAD (R-Window) -- LEADING (R) -- LEFT (R) -- LESS -- LEVEL -- LIKE (R) -- LIMIT (R) -- LINES (R) -- LOAD (R) -- LOCAL -- LOCALTIME (R) -- LOCALTIMESTAMP (R) -- LOCK (R) -- LONGBLOB (R) -- LONGTEXT (R) -- LOW_PRIORITY (R) - -M - -- MAX -- MAX_ROWS -- MAXVALUE (R) -- MEDIUMBLOB (R) -- MEDIUMINT (R) -- MEDIUMTEXT (R) -- MICROSECOND -- MIN -- MIN_ROWS -- MINUTE -- MINUTE_MICROSECOND (R) -- MINUTE_SECOND (R) -- MIN -- MIN_ROWS -- MINUTE -- MINUTE_MICROSECOND -- MINUTE_SECOND -- MOD (R) -- MODE -- MODIRY -- MONTH - -N - -- NAMES -- NATIONAL -- NATURAL (R) -- NO -- NO_WRITE_TO_BINLOG (R) -- NONE -- NOT (R) -- NOW -- NTH_VALUE (R-Window) -- NTILE (R-Window) -- NULL (R) -- NUMERIC (R) -- NVARCHAR (R) - -O - -- OFFSET -- ON (R) -- ONLY -- OPTION (R) -- OR (R) -- ORDER (R) -- OUTER (R) -- OVER (R-Window) - -P - -- PARTITION (R) -- PARTITIONS -- PASSWORD -- PERCENT_RANK (R-Window) -- PLUGINS -- POSITION -- PRECISION (R) -- PREPARE -- PRIMARY (R) -- PRIVILEGES -- PROCEDURE (R) -- PROCESS -- PROCESSLIST - -Q - -- QUARTER -- QUERY -- QUICK - -R - -- RANGE (R) -- RANK (R-Window) -- READ (R) -- REAL (R) -- REDUNDANT -- REFERENCES (R) -- REGEXP (R) -- RENAME (R) -- REPEAT (R) -- REPEATABLE -- REPLACE (R) -- RESTRICT (R) -- REVERSE -- REVOKE (R) -- RIGHT (R) -- RLIKE (R) -- ROLLBACK -- ROW -- ROW_COUNT -- ROW_FORMAT -- ROW_NUMBER (R-Window) -- ROWS (R-Window) - -S - -- SCHEMA -- SCHEMAS -- SECOND -- SECOND_MICROSECOND (R) -- SELECT (R) -- SERIALIZABLE -- SESSION -- SET (R) -- SHARE -- SHARED -- SHOW (R) -- SIGNED -- SMALLINT (R) -- SNAPSHOT -- SOME -- SQL_CACHE -- SQL_CALC_FOUND_ROWS (R) -- SQL_NO_CACHE -- START -- STARTING (R) -- STATS -- STATS_BUCKETS -- STATS_HISTOGRAMS -- STATS_META -- STATS_PERSISTENT -- STATUS -- STORED (R) -- SUBDATE -- SUBSTR -- SUBSTRING -- SUM -- SUPER - -T - -- TABLE (R) -- TABLES -- TERMINATED (R) -- TEXT -- THAN -- THEN (R) -- TIDB -- TIDB_INLJ -- TIDB_SMJ -- TIME -- TIMESTAMP -- TIMESTAMPADD -- TIMESTAMPDIFF -- TINYBLOB (R) -- TINYINT (R) -- TINYTEXT (R) -- TO (R) -- TRAILING (R) -- TRANSACTION -- TRIGGER (R) -- TRIGGERS -- TRIM -- TRUE (R) -- TRUNCATE - -U - -- UNCOMMITTED -- UNION (R) -- UNIQUE (R) -- UNKNOWN -- UNLOCK (R) -- UNSIGNED (R) -- UPDATE (R) -- USE (R) -- USER -- USING (R) -- UTC_DATE (R) -- UTC_TIME (R) -- UTC_TIMESTAMP (R) - -V - -- VALUE -- VALUES (R) -- VARBINARY (R) -- VARCHAR (R) -- VARIABLES -- VIEW -- VIRTUAL (R) - -W - -- WARNINGS -- WEEK -- WHEN (R) -- WHERE (R) -- WINDOW (R-Window) -- WITH (R) -- WRITE (R) - -X - -- XOR (R) - -Y - -- YEAR -- YEAR_MONTH (R) - -Z - -- ZEROFILL (R) diff --git a/dev/reference/sql/language-structure/literal-values.md b/dev/reference/sql/language-structure/literal-values.md deleted file mode 100644 index c4d5c89bd5ab..000000000000 --- a/dev/reference/sql/language-structure/literal-values.md +++ /dev/null @@ -1,283 +0,0 @@ ---- -title: 字面值 -category: reference ---- - -# 字面值 - -## String Literals - -String Literals 是一个 bytes 或者 characters 的序列，两端被单引号 `'` 或者双引号 `"` 包围，例如： - -``` -'example string' -"example string" -``` - -如果字符串是连续的，会被合并为一个独立的 string。以下表示是一样的： - -``` -'a string' -'a' ' ' 'string' -"a" ' ' "string" -``` - -如果 `ANSI_QUOTES` SQL MODE 开启了，那么只有单引号内的会被认为是 String Literals，对于双引号内的字符串，会被认为是一个 identifier。 - -binary string 是一串 bytes 组成的字符串，每一个 binary string 有一个叫做 `binary` 的 character set 和 collation。一个非二进制的字符串是一个由字符组成的字符串，它有除 `binary` 外的 character set和与之兼容的 collation。 - -对于两种字符串类型，比较都是基于每个字符的数值。对于 binary string 而言，比较单元就是字节，对于非二进制的字符串，那么单元就是字符，而有的字符集支持多字节字符。 - -一个 String Literal 可以拥有一个可选的 `character set introducer` 和 `COLLATE clause`，可以用来指派特定的字符集跟 collation（TiDB 对此只是做了语法上的兼容，并不实质做处理)。 - -``` -[_charset_name]'string' [COLLATE collation_name] -``` - -例如： - -{{< copyable "sql" >}} - -```sql -SELECT _latin1'string'; -SELECT _binary'string'; -SELECT _utf8'string' COLLATE utf8_bin; -``` - -你可以使用 N'literal' 或者 n'literal' 来创建使用 national character set 的字符串，下列语句是一样的： - -{{< copyable "sql" >}} - -```sql -SELECT N'some text'; -SELECT n'some text'; -SELECT _utf8'some text'; -``` - -转义字符： - -- \\0: ASCII NUL (X'00') 字符 -- \\': 单引号 -- \\": 双引号 -- \\b: 退格符号 -- \\n: 换行符 -- \\r: 回车符 -- \\t: tab 符（制表符） -- \\z: ASCII 26 (Ctrl + Z) -- \\\\: 反斜杠 \\ -- \\%: \% -- \\_: \_ - -如果要在 string literal 中使用 `'` 或者 `"`，有以下几种办法： - -* 在 `'` 引用的字符串中，可以用 `''` 来表示单引号。 -* 在 `"` 引用的字符串中，可以用 `""` 来表示双引号。 -* 前面接转义符`\`。 -* 在 `'` 中表示 `"` 或者在 `"` 中表示 `'` 都不需要特别的处理。 - -更多[细节](https://dev.mysql.com/doc/refman/5.7/en/string-literals.html)。 - -## Numeric Literals - -数值字面值包括 integer 跟 Decimal 类型跟浮点数字面值。 - -integer 可以包括 `.` 作为小数点分隔，数字前可以有 `-` 或者 `+` 来表示正数或者负数。 - -精确数值字面值可以表示为如下格式：`1, .2, 3.4, -5, -6.78, +9.10`. - -科学记数法也是被允许的，表示为如下格式：`1.2E3, 1.2E-3, -1.2E3, -1.2E-3`。 - -更多[细节](https://dev.mysql.com/doc/refman/5.7/en/number-literals.html)。 - -## NULL Values - -`NULL` 代表数据为空，它是大小写不敏感的，与 `\N`(大小写敏感) 同义。 - -> **注意：** -> -> `NULL` 跟 `0` 并不一样，跟空字符串 `''` 也不一样。 - -## Hexadecimal Literals - -十六进制字面值是有 `X` 和 `0x` 前缀的字符串，后接表示十六进制的数字。注意 `0x` 是大小写敏感的，不能表示为 `0X`。 - -例: - -``` -X'ac12' -X'12AC' -x'ac12' -x'12AC' -0xac12 -0x12AC -``` - -以下是不合法的十六进制字面值： - -``` -X'1z' (z 不是合法的十六进制值) -0X12AC (0X 必须用小写的 0x) -``` - -对于使用 `X'val'` 格式的十六进制字面值，`val` 必须要有一个数字，可以在前面补一个 0 来避免语法错误。 - -{{< copyable "sql" >}} - -```sql -select X'aff'; -``` - -``` -ERROR 1105 (HY000): line 0 column 13 near ""hex literal: invalid hexadecimal format, must even numbers, but 3 (total length 13) -``` - -{{< copyable "sql" >}} - -```sql -select X'0aff'; -``` - -``` -+---------+ -| X'0aff' | -+---------+ -| - | -+---------+ -1 row in set (0.00 sec) -``` - -默认情况，十六进制字面值是一个二进制字符串。 - -如果需要将一个字符串或者数字转换为十六进制字面值，可以使用内建函数 `HEX()`： - -{{< copyable "sql" >}} - -```sql -SELECT HEX('TiDB'); -``` - -``` -+-------------+ -| HEX('TiDB') | -+-------------+ -| 54694442 | -+-------------+ -1 row in set (0.01 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT X'54694442'; -``` - -``` -+-------------+ -| X'54694442' | -+-------------+ -| TiDB | -+-------------+ -1 row in set (0.00 sec) -``` - -## Date and Time Literals - -Date 跟 Time 字面值有几种格式，例如用字符串表示，或者直接用数字表示。在 TiDB 里面，当 TiDB 期望一个 Date 的时候，它会把 `'2017-08-24'`， `'20170824'`，`20170824` 当做是 Date。 - -TiDB 的 Date 值有以下几种格式： - -* `'YYYY-MM-DD'` 或者 `'YY-MM-DD'`，这里的 `-` 分隔符并不是严格的，可以是任意的标点符号。比如 `'2017-08-24'`，`'2017&08&24'`， `'2012@12^31'` 都是一样的。唯一需要特别对待的是 '.' 号，它被当做是小数点，用于分隔整数和小数部分。 - Date 和 Time 部分可以被 'T' 分隔，它的作用跟空格符是一样的，例如 `2017-8-24 10:42:00` 跟 `2017-8-24T10:42:00` 是一样的。 -* `'YYYYMMDDHHMMSS'` 或者 `'YYMMDDHHMMSS'`，例如 `'20170824104520'` 和 `'170824104520'` 被当做是 `'2017-08-24 10:45:20'`，但是如果你提供了一个超过范围的值，例如`'170824304520'`，那这就不是一个有效的 Date 字面值。 -* `YYYYMMDDHHMMSS` 或者 `YYMMDDHHMMSS` 注意这里没有单引号或者双引号，是一个数字。例如 `20170824104520`表示为 `'2017-08-24 10:45:20'`。 - -DATETIME 或者 TIMESTAMP 值可以接一个小数部分，用来表示微秒（精度最多到小数点后 6 位），用小数点 `.` 分隔。 - -Dates 如果 year 部分只有两个数字，这是有歧义的（推荐使用四个数字的格式），TiDB 会尝试用以下的规则来解释： - -* year 值如果在 `70-99` 范围，那么被转换成 `1970-1999`。 -* year 值如果在 `00-69` 范围，那么被转换成 `2000-2069`。 - -对于小于 10 的 month 或者 day 值，`'2017-8-4'` 跟 `'2017-08-04'` 是一样的。对于 Time 也是一样，比如 `'2017-08-24 1:2:3'` 跟 `'2017-08-24 01:02:03'`是一样的。 - -在需要 Date 或者 Time 的语境下, 对于数值，TiDB 会根据数值的长度来选定指定的格式： - -* 6 个数字，会被解释为 `YYMMDD`。 -* 12 个数字，会被解释为 `YYMMDDHHMMSS`。 -* 8 个数字，会解释为 `YYYYMMDD`。 -* 14 个数字，会被解释为 `YYYYMMDDHHMMSS`。 - -对于 Time 类型，TiDB 用以下格式来表示： - -* `'D HH:MM:SS'`，或者 `'HH:MM:SS'`，`'HH:MM'`，`'D HH:MM'`，`'D HH'`，`'SS'`，这里的 D 表示 days，合法的范围是 `0-34`。 -* 数值 `HHMMSS`，例如 `231010` 被解释为`'23:10:10'`。 -* 数值 `SS`，`MMSS`，`HHMMSS` 都是可以被当做 Time。 - -Time 类型的小数点也是 `.`，精度最多小数点后 6 位。 - -更多[细节](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-literals.html)。 - -## Boolean Literals - -常量 `TRUE` 和 `FALSE` 等于 1 和 0，它是大小写不敏感的。 - -{{< copyable "sql" >}} - -```sql -SELECT TRUE, true, tRuE, FALSE, FaLsE, false; -``` - -``` -+------+------+------+-------+-------+-------+ -| TRUE | true | tRuE | FALSE | FaLsE | false | -+------+------+------+-------+-------+-------+ -| 1 | 1 | 1 | 0 | 0 | 0 | -+------+------+------+-------+-------+-------+ -1 row in set (0.00 sec) -``` - -## Bit-Value Literals - -位值字面值用 `b` 或者 `0b` 做前缀，后接以 0 跟 1 组成的二进制数字。其中 `0b` 是区分大小写的，`0B` 是会报错的。 - -合法的 Bit-value： - -* b'01' -* B'01' -* 0b01 - -非法的 Bit-value： - -* b'2' (2 不是二进制数值, 必须为 0 或 1) -* 0B01 (0B 必须是小写 0b) - -默认情况，位值字面值是一个二进制字符串。 - -Bit-value 是作为二进制返回的，所以输出到 MySQL Client 可能会显示不出来，如果要转换为可打印的字符，可以使用内建函数 `BIN()` 或者 `HEX()`： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE t (b BIT(8)); -INSERT INTO t SET b = b'00010011'; -INSERT INTO t SET b = b'1110'; -INSERT INTO t SET b = b'100101'; -``` - -{{< copyable "sql" >}} - -```sql -SELECT b+0, BIN(b), HEX(b) FROM t; -``` - -``` -+------+--------+--------+ -| b+0 | BIN(b) | HEX(b) | -+------+--------+--------+ -| 19 | 10011 | 13 | -| 14 | 1110 | E | -| 37 | 100101 | 25 | -+------+--------+--------+ -3 rows in set (0.00 sec) -``` diff --git a/dev/reference/sql/language-structure/schema-object-names.md b/dev/reference/sql/language-structure/schema-object-names.md deleted file mode 100644 index 07a2a7d519c4..000000000000 --- a/dev/reference/sql/language-structure/schema-object-names.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: Schema Object Names -category: reference ---- - -# Schema Object Names - -在 TiDB 中，包括 database，table，index，column，alias 等等都被认为是 identifier (标识符，之后阐述用英文). - -在 TiDB 中，identifier可以被反引号 (\`) 包裹，为了阐述方便，我们叫这种情况为 `被引用`。identifier 也可以不被 \` 包裹。但是如果一个 identifier 存在一个特殊符号或者是一个保留关键字，那么你必须要 `引用` 它。 - -{{< copyable "sql" >}} - -```sql -SELECT * FROM `table` WHERE `table`.id = 20; -``` - -如果`ANSI_QUOTES` sql mode 被设置了，那么我们认为被双引号 `"` 包裹的字符串为 identifier。 - -{{< copyable "sql" >}} - -```sql -CREATE TABLE "test" (a varchar(10)); -``` - -``` -ERROR 1105 (HY000): line 0 column 19 near " (a varchar(10))" (total length 35) -``` - -{{< copyable "sql" >}} - -```sql -SET SESSION sql_mode='ANSI_QUOTES'; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -CREATE TABLE "test" (a varchar(10)); -``` - -``` -Query OK, 0 rows affected (0.09 sec) -``` - -如果你需要在被引用的 identifier 中使用反引号这个字符，那你需要重复两次，例如你需要创建一个表为 a`b： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE `a``b` (a int); -``` - -在 select 语句中，alias 语句可以用 identifier 或者字符串： - -{{< copyable "sql" >}} - -```sql -SELECT 1 AS `identifier`, 2 AS 'string'; -``` - -``` -+------------+--------+ -| identifier | string | -+------------+--------+ -| 1 | 2 | -+------------+--------+ -1 row in set (0.00 sec) -``` - -更多[细节](https://dev.mysql.com/doc/refman/5.7/en/identifiers.html) - -## Identifier Qualifiers - -Object Names (对象名字) 可以被限定也可以不用。例如你可以在创建表的时候不指定 database names： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE t (i int); -``` - -但是如果你之前没有设定过默认的数据库，会报 `ERROR 1046 (3D000): No database selected` 错误。当然你也可以指定数据库限定名： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE test.t (i int); -``` - -对于 `.` 左右两端可以出现空格，`table_name.col_name` 等于 `table_name . col_name`。 - -如果你要引用这个 identifier，那么请使用： - -``` -`table_name`.`col_name` -``` - -而不是： - -``` -`table_name.col_name` -``` - -更多[细节](https://dev.mysql.com/doc/refman/5.7/en/identifier-qualifiers.html) diff --git a/dev/reference/sql/language-structure/user-defined-variables.md b/dev/reference/sql/language-structure/user-defined-variables.md deleted file mode 100644 index 3e47672a1af8..000000000000 --- a/dev/reference/sql/language-structure/user-defined-variables.md +++ /dev/null @@ -1,245 +0,0 @@ ---- -title: 用户自定义变量 -category: reference ---- - -# 用户自定义变量 - -用户自定义变量格式为 `@var_name`。`var_name` 目前只支持字母，数字，`_$`组成。用户自定义变量是大小写不敏感的。 - -用户自定义变量是跟 session 绑定的，也就是说只有当前连接可以看见设置的用户变量，其他客户端连接无法查看到。 - -用 `SET` 语句可以设置用户自定义变量： - -{{< copyable "sql" >}} - -```sql -SET @var_name = expr [, @var_name = expr] ...; -``` - -或 - -{{< copyable "sql" >}} - -```sql -SET @var_name := expr; -``` - -对于 `SET` 语句，赋值操作符可以是 `=` 也可以是 `:=` - -例： - -{{< copyable "sql" >}} - -```sql -SET @a1=1, @a2=2, @a3:=4; -``` - -{{< copyable "sql" >}} - -```sql -SELECT @a1, @a2, @t3, @a4 := @a1+@a2+@a3; -``` - -``` -+------+------+------+--------------------+ -| @a1 | @a2 | @a3 | @a4 := @a1+@a2+@a3 | -+------+------+------+--------------------+ -| 1 | 2 | 4 | 7 | -+------+------+------+--------------------+ -``` - -如果设置用户变量用了 `HEX` 或者 `BIT` 值，TiDB会把它当成二进制字符串。如果你要将其设置成数字，那么需要手动加上 `CAST转换`: `CAST(.. AS UNSIGNED)`： - -{{< copyable "sql" >}} - -```sql -SELECT @v1, @v2, @v3; -``` - -``` -+------+------+------+ -| @v1 | @v2 | @v3 | -+------+------+------+ -| A | 65 | 65 | -+------+------+------+ -1 row in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SET @v1 = b'1000001'; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SET @v2 = b'1000001'+0; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SET @v3 = CAST(b'1000001' AS UNSIGNED); -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT @v1, @v2, @v3; -``` - -``` -+------+------+------+ -| @v1 | @v2 | @v3 | -+------+------+------+ -| A | 65 | 65 | -+------+------+------+ -1 row in set (0.00 sec) -``` - -如果获取一个没有设置过的变量，会返回一个 NULL： - -{{< copyable "sql" >}} - -```sql -select @not_exist; -``` - -``` -+------------+ -| @not_exist | -+------------+ -| NULL | -+------------+ -1 row in set (0.00 sec) -``` - -用户自定义变量不能直接在 SQL 语句中被当成 identifier，例： - -{{< copyable "sql" >}} - -```sql -select * from t; -``` - -``` -+------+ -| a | -+------+ -| 1 | -+------+ -1 row in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SET @col = "a"; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT @col FROM t; -``` - -``` -+------+ -| @col | -+------+ -| a | -+------+ -1 row in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT `@col` FROM t; -``` - -``` -ERROR 1054 (42S22): Unknown column '@col' in 'field list' -``` - -{{< copyable "sql" >}} - -```sql -SET @col = "`a`"; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT @col FROM t; -``` - -``` -+------+ -| @col | -+------+ -| `a` | -+------+ -1 row in set (0.01 sec) -``` - -但是有一个例外是如果你在 PREPARE 语句中使用它，是可以的： - -{{< copyable "sql" >}} - -```sql -PREPARE stmt FROM "SELECT @c FROM t"; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -EXECUTE stmt; -``` - -``` -+------+ -| @c | -+------+ -| a | -+------+ -1 row in set (0.01 sec) -``` - -{{< copyable "sql" >}} - -```sql -DEALLOCATE PREPARE stmt; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -更多[细节](https://dev.mysql.com/doc/refman/5.7/en/user-variables.html)。 diff --git a/dev/reference/sql/sql-mode.md b/dev/reference/sql/sql-mode.md deleted file mode 100644 index 7b4493b7c19c..000000000000 --- a/dev/reference/sql/sql-mode.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: SQL Mode -category: reference ---- - -# SQL 模式 - -TiDB 服务器采用不同 SQL 模式来操作，且不同客户端可以应用不同模式。SQL 模式定义 TiDB 支持哪些 SQL 语法及执行哪种数据验证检查. - -TiDB 启动之前采用修改 `--sql-mode="modes"` 配项设置 SQL 模式。 - -TiDB 启动之后采用 `SET [ SESSION | GLOBAL ] sql_mode='modes'`设置 SQL 模式。设置 GLOBAL 级别的 SQL 模式时用户需要有 SUPER 权限，并且只会影响到从设置 SQL 模式开始后续新建立的连接（注：老连接不受影响)。 SESSION 级别的 SQL 模式的变化只会影响当前的客户端。 - -Modes 是用逗号 (',') 间隔开的一系列不同的模式。使用 `SELECT @@sql_mode` 语句查询当前 SQL 模式，SQL 模式默认值：`ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION`。 - -## 重要的 sql_mode 值 - -* ANSI: 符合标准 SQL ，对数据进行校验，如果不符合定义类型或长度，对数据类型调整或截断保存，且返回warning警告。 -* STRICT_TRANS_TABLES: 严格模式，对数据进严格校验，但数据出现错误时，插入到表中，并且返回错误。 -* TRADITIONAL: 采用此模式使 TiDB 的行为象 "传统" SQL 数据库系统，当在列中插入不正确的值时“给出错误而不是警告”，一旦发现错误立即放弃INSERT/UPDATE。 - -## SQL mode 列表，如下 - -| 名称 | 含义 | -| --- | --- | -| PIPES_AS_CONCAT | 将 "\|\|" 视为字符串连接操作符（＋）(同CONCAT())，而不视为OR（支持) | -| ANSI_QUOTES | 将 `"` 视为识别符，如果启用 ANSI_QUOTES，只单引号内的会被认为是 String Literals，双引号被解释为识别符，因此不能用双引号来引用字符串（支持）| -| IGNORE_SPACE | 若开启该模式，系统忽略空格。例如：“user” 和 “user “ 是相同的（支持）| -| ONLY_FULL_GROUP_BY | 如果 GROUP BY 出现的列并没有在 SELECT，HAVING，ORDER BY 中出现，此 SQL 不合法，因为不在 GROUP BY 中的列被查询展示出来不符合正常现象 （支持) | -| NO_UNSIGNED_SUBTRACTION | 在减运算中，如果某个操作数没有符号，不要将结果标记为UNSIGNED （支持）| -| NO_DIR_IN_CREATE | 创建表时，忽视所有 INDEX DIRECTORY 和 DATA DIRECTORY 指令，该选项仅对从复制服务器有用 （仅语法支持）| -| NO_KEY_OPTIONS | 使用 SHOW CREATE TABLE 时不会输出 MySQL 特有的语法部分，如 ENGINE ，使用 mysqldump 跨DB种类迁移的时需要考虑此选项（仅语法支持）| -| NO_FIELD_OPTIONS | 使用 SHOW CREATE TABLE 时不会输出 MySQL 特有的语法部分，如 ENGINE ，使用 mysqldump 跨DB种类迁移的时需要考虑此选项（仅语法支持）| -| NO_TABLE_OPTIONS | 使用 SHOW CREATE TABLE 时不会输出 MySQL 特有的语法部分，如 ENGINE ，使用 mysqldump 跨DB种类迁移的时需要考虑此选项（仅语法支持）| -| NO_AUTO_VALUE_ON_ZERO | 若启用该模式，在AUTO_INCREMENT列的处理传入的值是 0 或者具体数值时系统直接将该值写入此列，传入 NULL 时系统自动生成下一个序列号（支持）| -| NO_BACKSLASH_ESCAPES | 若启用该模式，`\` 反斜杠符号仅代表它自己（支持）| -| STRICT_TRANS_TABLES | 对于事务存储引擎启用严格模式，insert非法值之后，回滚整条语句（支持）| -| STRICT_ALL_TABLES | 对于事务型表，写入非法值之后，回滚整个事务语句（支持）| -| NO_ZERO_IN_DATE | 在严格模式，不接受月或日部分为0的日期。如果使用IGNORE选项，我们为类似的日期插入'0000-00-00'。在非严格模式，可以接受该日期，但会生成警告 （支持） -| NO_ZERO_DATE | 在严格模式，不要将 '0000-00-00'做为合法日期。你仍然可以用IGNORE选项插入零日期。在非严格模式，可以接受该日期，但会生成警告 （支持）| -| ALLOW_INVALID_DATES | 不检查全部日期的合法性，仅检查月份值在 1 到 12 及 日期值在 1 到31 之间，仅适用于 DATE 和 DATATIME 列，TIMESTAMP 列需要全部检查其合法性 （支持）| -| ERROR_FOR_DIVISION_BY_ZERO | 若启用该模式，在 INSERT 或 UPDATE 过程中，被除数为 0 值时，系统产生错误
若未启用该模式，被除数为 0 值时，系统产生警告，并用 NULL 代替 （支持） | -| NO_AUTO_CREATE_USER | 防止GRANT自动创建新用户，但指定密码除外 （支持）| -| HIGH_NOT_PRECEDENCE | NOT 操作符的优先级是表达式。例如： NOT a BETWEEN b AND c 被解释为 NOT (a BETWEEN b AND c)。在部份旧版本MySQL中， 表达式被解释为(NOT a) BETWEEN b AND c (支持) | -| NO_ENGINE_SUBSTITUTION | 如果需要的存储引擎被禁用或未编译，可以防止自动替换存储引擎 （仅语法支持）| -| PAD_CHAR_TO_FULL_LENGTH | 若启用该模式，系统对于 CHAR 类型不会截断尾部空格（支持）| -| REAL_AS_FLOAT | 将REAL视为FLOAT的同义词，而不是DOUBLE的同义词 （支持）| -| POSTGRESQL | 等同于 PIPES_AS_CONCAT、ANSI_QUOTES、IGNORE_SPACE、NO_KEY_OPTIONS、NO_TABLE_OPTIONS、NO_FIELD_OPTIONS （支持）| -| MSSQL | 等同于 PIPES_AS_CONCAT、ANSI_QUOTES、IGNORE_SPACE、NO_KEY_OPTIONS、NO_TABLE_OPTIONS、 NO_FIELD_OPTIONS （支持）| -| DB2 | 等同于 PIPES_AS_CONCAT、ANSI_QUOTES、IGNORE_SPACE、NO_KEY_OPTIONS、NO_TABLE_OPTIONS、NO_FIELD_OPTIONS （支持）| -| MAXDB | 等同于 PIPES_AS_CONCAT、ANSI_QUOTES、IGNORE_SPACE、NO_KEY_OPTIONS、NO_TABLE_OPTIONS、NO_FIELD_OPTIONS、NO_AUTO_CREATE_USER （支持）| -| MySQL323 | 等同于 NO_FIELD_OPTIONS、HIGH_NOT_PRECEDENCE (支持)| -| MYSQL40 | 等同于 NO_FIELD_OPTIONS、HIGH_NOT_PRECEDENCE （支持）| -| ANSI | 等同于 REAL_AS_FLOAT、PIPES_AS_CONCAT、ANSI_QUOTES、IGNORE_SPACE （支持）| -| TRADITIONAL | 等同于 STRICT_TRANS_TABLES、STRICT_ALL_TABLES、NO_ZERO_IN_DATE、NO_ZERO_DATE、ERROR_FOR_DIVISION_BY_ZERO、NO_AUTO_CREATE_USER(支持) | -| ORACLE | 等同于 PIPES_AS_CONCAT、ANSI_QUOTES、IGNORE_SPACE、NO_KEY_OPTIONS、NO_TABLE_OPTIONS、NO_FIELD_OPTIONS、NO_AUTO_CREATE_USER （支持）| diff --git a/dev/reference/sql/statements/admin.md b/dev/reference/sql/statements/admin.md deleted file mode 100644 index 653f2b02e0be..000000000000 --- a/dev/reference/sql/statements/admin.md +++ /dev/null @@ -1,161 +0,0 @@ ---- -title: ADMIN -category: reference ---- - -# ADMIN - -`ADMIN` 语句是 TiDB 扩展语法，用于查看 TiDB 自身的状态，并对 TiDB 中的表数据进行校验。示例如下。 - -{{< copyable "sql" >}} - -```sql -ADMIN SHOW DDL; -``` - -`ADMIN SHOW DDL` 用于查看当前正在执行的 DDL 作业。 - -{{< copyable "sql" >}} - -```sql -ADMIN SHOW DDL JOBS [NUM] [WHERE where_condition]; -``` - -* `NUM`：查看已经执行完成的 DDL 作业队列中最近 `NUM` 条结果，未指定时，默认值为 10。 -* `WHERE`：`WHERE` 子句，可以添加过滤条件。 - -`ADMIN SHOW DDL JOBS` 用于查看当前 DDL 作业队列中的所有结果（包括正在运行以及等待运行的任务）以及已执行完成的 DDL 作业队列中的最近十条结果。 - -{{< copyable "sql" >}} - -```sql -ADMIN SHOW DDL JOB QUERIES job_id [, job_id] ...; -``` - -{{< copyable "sql" >}} - -```sql -ADMIN CANCEL DDL JOBS job_id [, job_id] ...; -``` - -{{< copyable "sql" >}} - -```sql -ADMIN CHECK TABLE tbl_name [, tbl_name] ...; -``` - -{{< copyable "sql" >}} - -```sql -ADMIN REPAIR TABLE tbl_name CREATE TABLE STATEMENT; -``` - -## 语句概览 - -**AdminStmt**： - -![AdminStmt](/media/sqlgram/AdminStmt.png) - -## 使用示例 - -执行以下命令，可查看正在执行的 DDL 任务中最近 10 条已经完成的 DDL 任务。未指定 `NUM` 时，默认只显示最近 10 条已经执行完的 DDL 任务。 - -{{< copyable "sql" >}} - -```sql -admin show ddl jobs; -``` - -``` -+--------+---------+------------+---------------------+----------------+-----------+----------+-----------+-----------------------------------+-----------------------------------+---------------+ -| JOB_ID | DB_NAME | TABLE_NAME | JOB_TYPE | SCHEMA_STATE | SCHEMA_ID | TABLE_ID | ROW_COUNT | START_TIME | END_TIME | STATE | -+--------+---------+------------+---------------------+----------------+-----------+----------+-----------+-----------------------------------+-----------------------------------+---------------+ -| 45 | test | t1 | add index | write reorganization | 32 | 37 | 0 | 2019-01-10 12:38:36.501 +0800 CST | | running | -| 44 | test | t1 | add index | none | 32 | 37 | 0 | 2019-01-10 12:36:55.18 +0800 CST | 2019-01-10 12:36:55.852 +0800 CST | rollback done | -| 43 | test | t1 | add index | public | 32 | 37 | 6 | 2019-01-10 12:35:13.66 +0800 CST | 2019-01-10 12:35:14.925 +0800 CST | synced | -| 42 | test | t1 | drop index | none | 32 | 37 | 0 | 2019-01-10 12:34:35.204 +0800 CST | 2019-01-10 12:34:36.958 +0800 CST | synced | -| 41 | test | t1 | add index | public | 32 | 37 | 0 | 2019-01-10 12:33:22.62 +0800 CST | 2019-01-10 12:33:24.625 +0800 CST | synced | -| 40 | test | t1 | drop column | none | 32 | 37 | 0 | 2019-01-10 12:33:08.212 +0800 CST | 2019-01-10 12:33:09.78 +0800 CST | synced | -| 39 | test | t1 | add column | public | 32 | 37 | 0 | 2019-01-10 12:32:55.42 +0800 CST | 2019-01-10 12:32:56.24 +0800 CST | synced | -| 38 | test | t1 | create table | public | 32 | 37 | 0 | 2019-01-10 12:32:41.956 +0800 CST | 2019-01-10 12:32:43.956 +0800 CST | synced | -| 36 | test | | drop table | none | 32 | 34 | 0 | 2019-01-10 11:29:59.982 +0800 CST | 2019-01-10 11:30:00.45 +0800 CST | synced | -| 35 | test | | create table | public | 32 | 34 | 0 | 2019-01-10 11:29:40.741 +0800 CST | 2019-01-10 11:29:41.682 +0800 CST | synced | -| 33 | test | | create schema | public | 32 | 0 | 0 | 2019-01-10 11:29:22.813 +0800 CST | 2019-01-10 11:29:23.954 +0800 CST | synced | -+--------+---------+------------+---------------------+----------------+-----------+----------+-----------+-----------------------------------+-----------------------------------+---------------+ -``` - -执行以下命令，可查看正在执行的 DDL 任务中最近 5 条已经执行完的 DDL 任务： - -{{< copyable "sql" >}} - -```sql -admin show ddl jobs 5; -``` - -``` -+--------+---------+------------+---------------------+----------------+-----------+----------+-----------+-----------------------------------+-----------------------------------+---------------+ -| JOB_ID | DB_NAME | TABLE_NAME | JOB_TYPE | SCHEMA_STATE | SCHEMA_ID | TABLE_ID | ROW_COUNT | START_TIME | END_TIME | STATE | -+--------+---------+------------+---------------------+----------------+-----------+----------+-----------+-----------------------------------+-----------------------------------+---------------+ -| 45 | test | t1 | add index | write reorganization | 32 | 37 | 0 | 2019-01-10 12:38:36.501 +0800 CST | | running | -| 44 | test | t1 | add index | none | 32 | 37 | 0 | 2019-01-10 12:36:55.18 +0800 CST | 2019-01-10 12:36:55.852 +0800 CST | rollback done | -| 43 | test | t1 | add index | public | 32 | 37 | 6 | 2019-01-10 12:35:13.66 +0800 CST | 2019-01-10 12:35:14.925 +0800 CST | synced | -| 42 | test | t1 | drop index | none | 32 | 37 | 0 | 2019-01-10 12:34:35.204 +0800 CST | 2019-01-10 12:34:36.958 +0800 CST | synced | -| 41 | test | t1 | add index | public | 32 | 37 | 0 | 2019-01-10 12:33:22.62 +0800 CST | 2019-01-10 12:33:24.625 +0800 CST | synced | -| 40 | test | t1 | drop column | none | 32 | 37 | 0 | 2019-01-10 12:33:08.212 +0800 CST | 2019-01-10 12:33:09.78 +0800 CST | synced | -+--------+---------+------------+---------------------+----------------+-----------+----------+-----------+-----------------------------------+-----------------------------------+---------------+ -``` - -执行以下命令，可查看 test 数据库中未执行完成的 DDL 任务，包括正在执行中以及最近 5 条已经执行完但是执行失败的 DDL 任务。 - -{{< copyable "sql" >}} - -```sql -admin show ddl jobs 5 where state!='synced' and db_name='test'; -``` - -``` -+--------+---------+------------+---------------------+----------------+-----------+----------+-----------+-----------------------------------+-----------------------------------+---------------+ -| JOB_ID | DB_NAME | TABLE_NAME | JOB_TYPE | SCHEMA_STATE | SCHEMA_ID | TABLE_ID | ROW_COUNT | START_TIME | END_TIME | STATE | -+--------+---------+------------+---------------------+----------------+-----------+----------+-----------+-----------------------------------+-----------------------------------+---------------+ -| 45 | test | t1 | add index | write reorganization | 32 | 37 | 0 | 2019-01-10 12:38:36.501 +0800 CST | | running | -| 44 | test | t1 | add index | none | 32 | 37 | 0 | 2019-01-10 12:36:55.18 +0800 CST | 2019-01-10 12:36:55.852 +0800 CST | rollback done | -+--------+---------+------------+---------------------+----------------+-----------+----------+-----------+-----------------------------------+-----------------------------------+---------------+ -``` - -* `JOB_ID`：每个 DDL 操作对应一个 DDL 作业，`JOB_ID` 全局唯一。 -* `DB_NAME`：执行 DDL 操作的数据库的名称。 -* `TABLE_NAME`：执行 DDL 操作的表的名称。 -* `JOB_TYPE`：DDL 操作的类型。 -* `SCHEMA_STATE`：schema 的当前状态。如果 `JOB_TYPE` 是 `add index`，则为 index 的状态；如果是 `add column`，则为 column 的状态，如果是 `create table`，则为 table 的状态。常见的状态有以下几种： - * `none`：表示不存在。一般 `drop` 操作或者 `create` 操作失败回滚后，会变为 `none` 状态。 - * `delete only`、`write only`、`delete reorganization`、`write reorganization`：这四种状态是中间状态，在[Online, Asynchronous Schema Change in F1](http://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/41376.pdf) 论文中有详细说明，在此不再赘述。由于中间状态转换很快，一般操作中看不到这几种状态，只有执行 `add index` 操作时能看到处于 `write reorganization` 状态，表示正在添加索引数据。 - * `public`：表示存在且可用。一般 `create table` 和 `add index/column` 等操作完成后，会变为 `public` 状态，表示新建的 table/column/index 可以正常读写了。 -* `SCHEMA_ID`：执行 DDL 操作的数据库的 ID。 -* `TABLE_ID`：执行 DDL 操作的表的 ID。 -* `ROW_COUNT`：执行 `add index` 操作时，当前已经添加完成的数据行数。 -* `START_TIME`：DDL 操作的开始时间。 -* `END_TIME`：DDL 操作的结束时间。 -* `STATE`：DDL 操作的状态。常见的状态有以下几种： - * `none`：表示该操作任务已经进入 DDL 作业队列中，但尚未执行，因为还在排队等待前面的 DDL 作业完成。另一种原因可能是执行 `drop` 操作后，会变为 `none` 状态，但是很快会更新为 `synced` 状态，表示所有 TiDB 实例都已经同步到该状态。 - * `running`：表示该操作正在执行。 - * `synced`：表示该操作已经执行成功，且所有 TiDB 实例都已经同步该状态。 - * `rollback done`：表示该操作执行失败，回滚完成。 - * `rollingback`：表示该操作执行失败，正在回滚。 - * `cancelling`：表示正在取消该操作。这个状态只有在用 `ADMIN CANCEL DDL JOBS` 命令取消 DDL 作业时才会出现。 - -- `ADMIN SHOW DDL JOB QUERIES job_id [, job_id] ...`：用于查看 `job_id` 对应的 DDL 任务的原始 SQL 语句。这个 `job_id` 只会搜索正在运行中的 DDL 作业以及 DDL 历史作业队列中最近的十条结果。 -- `ADMIN CANCEL DDL JOBS job_id [, job_id] ...`：用于取消当前正在运行的 DDL 作业，并返回对应作业是否取消成功。如果取消失败，会显示失败的具体原因。 - - > **注意：** - > - > - 只有该操作可以取消 DDL 作业，其他所有的操作和环境变更（例如机器重启、集群重启）都不会取消 DDL 作业。 - > - 该操作可以同时取消多个 DDL 作业。可以通过 `ADMIN SHOW DDL JOBS` 语句来获取 DDL 作业的 ID。 - > - 如果希望取消的作业已经完成，则取消操作将会失败。 - -- `ADMIN CHECK TABLE tbl_name [, tbl_name] ...`：用于对给定表中的所有数据和对应索引进行一致性校验，若通过校验，则返回空的查询结果；否则返回数据不一致的错误信息。 - -- `ADMIN REPAIR TABLE tbl_name CREATE TABLE STATEMENT`：在极端情况下，用于对存储层中的表的元信息进行非可信的覆盖，“非可信”是指需要人为保证原表的元信息可以完全由 `CREATE TABLE STATEMENT` 提供。该语句需要打开配置文件项中的 [`repair-mode`](/dev/reference/configuration/tidb-server/configuration-file.md#repair-mode) 开关，并且需要确保所修复的表名在 [`repair-table-list`](/dev/reference/configuration/tidb-server/configuration-file.md#repair-table-list) 名单中。 - -## MySQL 兼容性 - -ADMIN 语句是 TiDB 对于 MySQL 语法的扩展。 diff --git a/dev/reference/sql/statements/create-table.md b/dev/reference/sql/statements/create-table.md deleted file mode 100644 index d1bc93424d8b..000000000000 --- a/dev/reference/sql/statements/create-table.md +++ /dev/null @@ -1,303 +0,0 @@ ---- -title: CREATE TABLE -summary: TiDB 数据库中 CREATE TABLE 的使用概况 -category: reference ---- - -# CREATE TABLE - -`CREATE TABLE` 语句用于在当前所选数据库中创建新表。另可参阅单独的 `CREATE TABLE LIKE` 文档。 - -## 语法图 - -**CreateTableStmt:** - -![CreateTableStmt](/media/sqlgram/CreateTableStmt.png) - -**IfNotExists:** - -![IfNotExists](/media/sqlgram/IfNotExists.png) - -**TableName:** - -![TableName](/media/sqlgram/TableName.png) - -**TableElementListOpt:** - -![TableElementListOpt](/media/sqlgram/TableElementListOpt.png) - -**TableElement:** - -![TableElement](/media/sqlgram/TableElement.png) - -**PartitionOpt:** - -![PartitionOpt](/media/sqlgram/PartitionOpt.png) - -**ColumnDef:** - -![ColumnDef](/media/sqlgram/ColumnDef.png) - -**ColumnName:** - -![ColumnName](/media/sqlgram/ColumnName.png) - -**Type:** - -![Type](/media/sqlgram/Type.png) - -**ColumnOptionListOpt:** - -![ColumnOptionListOpt](/media/sqlgram/ColumnOptionListOpt.png) - -**TableOptionListOpt:** - -![TableOptionListOpt](/media/sqlgram/TableOptionListOpt.png) - -## 语法说明 - -`CREATE TABLE` 用于创建一个表。目前不支持临时表，不支持 `CHECK` 约束，不支持创建表的同时从其它表导入数据功能。在语法上也支持一些 `Partition_options`，但是并不完全，就不做列举了。 - -以下是 `CREATE TABLE` 相关的语法说明： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE [IF NOT EXISTS] tbl_name - (create_definition,...) - [table_options] -``` - -使用 `IF NOT EXIST` 时，即使创建的表已经存在，也不会报错，如果不指定时，则报错。 - -{{< copyable "sql" >}} - -```sql -CREATE TABLE [IF NOT EXISTS] tbl_name - { LIKE old_tbl_name | (LIKE old_tbl_name) } -``` - -使用 `LIKE` 基于一个表的定义创建一个空表，包括这个表中的列属性和索引属性。 - -```sql -create_definition: - col_name column_definition - | [CONSTRAINT [symbol]] PRIMARY KEY [index_type] (index_col_name,...) - [index_option] ... - | {INDEX|KEY} [index_name] [index_type] (index_col_name,...) - [index_option] ... - | [CONSTRAINT [symbol]] UNIQUE [INDEX|KEY] - [index_name] [index_type] (index_col_name,...) - [index_option] ... - | {FULLTEXT} [INDEX|KEY] [index_name] (index_col_name,...) - [index_option] ... - | [CONSTRAINT [symbol]] FOREIGN KEY - [index_name] (index_col_name,...) reference_definition -``` - -`create_definition` 中 `FULLTEXT` 和 `FOREIGN KEY` 目前只是语法上支持。 - -```sql -column_definition: - data_type [NOT NULL | NULL] [DEFAULT default_value] - [AUTO_INCREMENT] [UNIQUE [KEY] | [PRIMARY] KEY] - [COMMENT 'string'] - [reference_definition] - | data_type [GENERATED ALWAYS] AS (expression) - [VIRTUAL | STORED] [UNIQUE [KEY]] [COMMENT comment] - [NOT NULL | NULL] [[PRIMARY] KEY] - -data_type: - BIT[(length)] - | TINYINT[(length)] [UNSIGNED] [ZEROFILL] - | SMALLINT[(length)] [UNSIGNED] [ZEROFILL] - | MEDIUMINT[(length)] [UNSIGNED] [ZEROFILL] - | INT[(length)] [UNSIGNED] [ZEROFILL] - | INTEGER[(length)] [UNSIGNED] [ZEROFILL] - | BIGINT[(length)] [UNSIGNED] [ZEROFILL] - | REAL[(length,decimals)] [UNSIGNED] [ZEROFILL] - | DOUBLE[(length,decimals)] [UNSIGNED] [ZEROFILL] - | FLOAT[(length,decimals)] [UNSIGNED] [ZEROFILL] - | DECIMAL[(length[,decimals])] [UNSIGNED] [ZEROFILL] - | NUMERIC[(length[,decimals])] [UNSIGNED] [ZEROFILL] - | DATE - | TIME[(fsp)] - | TIMESTAMP[(fsp)] - | DATETIME[(fsp)] - | YEAR - | CHAR[(length)] [BINARY] - [CHARACTER SET charset_name] [COLLATE collation_name] - | VARCHAR(length) [BINARY] - [CHARACTER SET charset_name] [COLLATE collation_name] - | BINARY[(length)] - | VARBINARY(length) - | TINYBLOB - | BLOB - | MEDIUMBLOB - | LONGBLOB - | TINYTEXT [BINARY] - [CHARACTER SET charset_name] [COLLATE collation_name] - | TEXT [BINARY] - [CHARACTER SET charset_name] [COLLATE collation_name] - | MEDIUMTEXT [BINARY] - [CHARACTER SET charset_name] [COLLATE collation_name] - | LONGTEXT [BINARY] - [CHARACTER SET charset_name] [COLLATE collation_name] - | ENUM(value1,value2,value3,...) - [CHARACTER SET charset_name] [COLLATE collation_name] - | SET(value1,value2,value3,...) - [CHARACTER SET charset_name] [COLLATE collation_name] - | JSON -``` - -`data_type` 请参考[数据类型](/dev/reference/sql/data-types/overview.md)章节。 - -```sql -index_col_name: - col_name [(length)] [ASC | DESC] -``` - -`index_col_name` 中 `[ASC | DESC]` 目前只是语法上支持。 - -```sql -index_type: - USING {BTREE | HASH} -``` - -`index_type` 目前只是语法上支持。 - -```sql -index_option: - KEY_BLOCK_SIZE [=] value - | index_type - | COMMENT 'string' -``` - -`index_option` 中 `KEY_BLOCK_SIZE` 目前只是语法上支持。 - -```sql -reference_definition: - REFERENCES tbl_name (index_col_name,...) - [MATCH FULL | MATCH PARTIAL | MATCH SIMPLE] - [ON DELETE reference_option] - [ON UPDATE reference_option] - -reference_option: - RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT -``` - -```sql -table_options: - table_option [[,] table_option] ... - -table_option: - AUTO_INCREMENT [=] value - | AVG_ROW_LENGTH [=] value - | SHARD_ROW_ID_BITS [=] value - | PRE_SPLIT_REGIONS [=] value - | [DEFAULT] CHARACTER SET [=] charset_name - | CHECKSUM [=] {0 | 1} - | [DEFAULT] COLLATE [=] collation_name - | COMMENT [=] 'string' - | COMPRESSION [=] {'ZLIB'|'LZ4'|'NONE'} - | CONNECTION [=] 'connect_string' - | DELAY_KEY_WRITE [=] {0 | 1} - | ENGINE [=] engine_name - | KEY_BLOCK_SIZE [=] value - | MAX_ROWS [=] value - | MIN_ROWS [=] value - | ROW_FORMAT [=] {DEFAULT|DYNAMIC|FIXED|COMPRESSED|REDUNDANT|COMPACT} - | STATS_PERSISTENT [=] {DEFAULT|0|1} -``` - -`table_option` 目前支持的只有 `AUTO_INCREMENT`、`SHARD_ROW_ID_BITS`（详情介绍请参考 [TiDB 专用系统变量和语法](/dev/reference/configuration/tidb-server/tidb-specific-variables.md#shard_row_id_bits)）、`PRE_SPLIT_REGIONS`、`CHARACTER SET`、`COLLATE` 和 `COMMENT`，其它只是语法上支持。具体内容参考下表，各个子句之间用逗号隔开。 - -| 参数 |含义 |举例 | -|----------------|--------------------------------------|----------------------------| -|`AUTO_INCREMENT`|自增字段初始值 |`AUTO_INCREMENT` = 5| -|`SHARD_ROW_ID_BITS`|用来设置隐式 _tidb_rowid 的分片数量的 bit 位数 |`SHARD_ROW_ID_BITS` = 4| -|`PRE_SPLIT_REGIONS`|用来在建表时预先均匀切分 `2^(PRE_SPLIT_REGIONS)` 个 Region |`PRE_SPLIT_REGIONS` = 4| -|`CHARACTER SET` |指定该表所使用的字符集 | `CHARACTER SET` = 'utf8mb4'| -|`COLLATE` |指定该表所使用的字符集排序规则 | `COLLATE` = 'utf8mb4_bin'| -|`COMMENT` |注释信息 | `COMMENT` = 'comment info'| - -`split-table` 配置项默认情况下会开启，在此配置项开启时，建表操作会为每个表建立单独的 Region。 - -## 示例 - -{{< copyable "sql" >}} - -```sql -CREATE TABLE t1 (a int); -``` - -``` -Query OK, 0 rows affected (0.11 sec) -``` - -{{< copyable "sql" >}} - -```sql -CREATE TABLE t2 LIKE t1; -``` - -``` -Query OK, 0 rows affected (0.10 sec) -``` - -{{< copyable "sql" >}} - -```sql -DESC t1; -``` - -``` -+-------+---------+------+------+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+-------+---------+------+------+---------+-------+ -| a | int(11) | YES | | NULL | | -+-------+---------+------+------+---------+-------+ -1 row in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -INSERT INTO t1 VALUES (1); -``` - -``` -Query OK, 1 row affected (0.02 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT * FROM t1; -``` - -``` -+------+ -| a | -+------+ -| 1 | -+------+ -1 row in set (0.00 sec) -``` - -## MySQL 兼容性 - -* TiDB 不支持 `CREATE TEMPORARY TABLE` 语法。 -* 支持除空间类型以外的所有数据类型。 -* 不支持 `FULLTEXT`，`HASH` 和 `SPATIAL` 索引。 -* `KEY_BLOCK_SIZE` 和 `ENGINE` 属性可被解析，但会被忽略。 -* `index_col_name` 属性支持 length 选项，最大长度限制为 3072 字节。此长度限制不会更改，具体取决于存储引擎和建表时使用的字符集。 -* `index_col_name` 属性支持 `ASC` 和 `DESC` 的索引排序选项。 -* `COMMENT` 属性最多支持 1024 个字符，不支持 `WITH PARSER` 选项。 -* TiDB 在单个表中最多支持 512 列。InnoDB 中相应的数量限制为 1017，MySQL 中的硬限制为 4096。 - -## 另请参阅 - -* [DROP TABLE](/dev/reference/sql/statements/drop-table.md) -* [CREATE TABLE LIKE](/dev/reference/sql/statements/create-table-like.md) -* [SHOW CREATE TABLE](/dev/reference/sql/statements/show-create-table.md) diff --git a/dev/reference/sql/statements/desc.md b/dev/reference/sql/statements/desc.md deleted file mode 100644 index 138016dda9c3..000000000000 --- a/dev/reference/sql/statements/desc.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: DESC -summary: TiDB 数据库中 DESC 的使用概况。 -category: reference ---- - -# DESC - -`DESC` 语句是 [`EXPLAIN`](/dev/reference/sql/statements/explain.md) 的别名。包含该语句提供了 MySQL 兼容性。 diff --git a/dev/reference/sql/statements/describe.md b/dev/reference/sql/statements/describe.md deleted file mode 100644 index 75b481b55056..000000000000 --- a/dev/reference/sql/statements/describe.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: DESCRIBE -summary: TiDB 数据库中 DESCRIBE 的使用概况。 -category: reference ---- - -# DESCRIBE - -`DESCRIBE` 语句为 [`EXPLAIN`](/dev/reference/sql/statements/explain.md) 的别名。包含该语句提供了 MySQL 兼容性。 diff --git a/dev/reference/sql/statements/explain.md b/dev/reference/sql/statements/explain.md deleted file mode 100644 index b158e8359ff6..000000000000 --- a/dev/reference/sql/statements/explain.md +++ /dev/null @@ -1,223 +0,0 @@ ---- -title: EXPLAIN -summary: TiDB 数据库中 EXPLAIN 的使用概况。 -category: reference ---- - -# EXPLAIN - -`EXPLAIN` 语句仅用于显示查询的执行计划，而不执行查询。`EXPLAIN ANALYZE` 可执行查询，补充 `EXPLAIN` 语句。如果 `EXPLAIN` 的输出与预期结果不匹配，可考虑在查询的每个表上执行 `ANALYZE TABLE`。 - -语句 `DESC` 和 `DESCRIBE` 是 `EXPLAIN` 的别名。`EXPLAIN ` 的替代用法记录在 [`SHOW [FULL] COLUMNS FROM`](/dev/reference/sql/statements/show-columns-from.md) 下。 - -## 语法图 - -**ExplainSym:** - -![ExplainSym](/media/sqlgram/ExplainSym.png) - -**ExplainStmt:** - -![ExplainStmt](/media/sqlgram/ExplainStmt.png) - -**ExplainableStmt:** - -![ExplainableStmt](/media/sqlgram/ExplainableStmt.png) - -## 示例 - -{{< copyable "sql" >}} - -```sql -EXPLAIN SELECT 1; -``` - -``` -+-------------------+-------+------+---------------+ -| id | count | task | operator info | -+-------------------+-------+------+---------------+ -| Projection_3 | 1.00 | root | 1 | -| └─TableDual_4 | 1.00 | root | rows:1 | -+-------------------+-------+------+---------------+ -2 rows in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -CREATE TABLE t1 (id INT NOT NULL PRIMARY KEY AUTO_INCREMENT, c1 INT NOT NULL); -``` - -``` -Query OK, 0 rows affected (0.10 sec) -``` - -{{< copyable "sql" >}} - -```sql -INSERT INTO t1 (c1) VALUES (1), (2), (3); -``` - -``` -Query OK, 3 rows affected (0.02 sec) -Records: 3 Duplicates: 0 Warnings: 0 -``` - -{{< copyable "sql" >}} - -```sql -EXPLAIN SELECT * FROM t1 WHERE id = 1; -``` - -``` -+-------------+-------+------+--------------------+ -| id | count | task | operator info | -+-------------+-------+------+--------------------+ -| Point_Get_1 | 1.00 | root | table:t1, handle:1 | -+-------------+-------+------+--------------------+ -1 row in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -DESC SELECT * FROM t1 WHERE id = 1; -``` - -``` -+-------------+-------+------+--------------------+ -| id | count | task | operator info | -+-------------+-------+------+--------------------+ -| Point_Get_1 | 1.00 | root | table:t1, handle:1 | -+-------------+-------+------+--------------------+ -1 row in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -DESCRIBE SELECT * FROM t1 WHERE id = 1; -``` - -``` -+-------------+-------+------+--------------------+ -| id | count | task | operator info | -+-------------+-------+------+--------------------+ -| Point_Get_1 | 1.00 | root | table:t1, handle:1 | -+-------------+-------+------+--------------------+ -1 row in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -EXPLAIN INSERT INTO t1 (c1) VALUES (4); -``` - -``` -ERROR 1105 (HY000): Unsupported type *core.Insert -``` - -{{< copyable "sql" >}} - -```sql -EXPLAIN UPDATE t1 SET c1=5 WHERE c1=3; -``` - -``` -+---------------------+----------+------+-------------------------------------------------------------+ -| id | count | task | operator info | -+---------------------+----------+------+-------------------------------------------------------------+ -| TableReader_6 | 10.00 | root | data:Selection_5 | -| └─Selection_5 | 10.00 | cop | eq(test.t1.c1, 3) | -| └─TableScan_4 | 10000.00 | cop | table:t1, range:[-inf,+inf], keep order:false, stats:pseudo | -+---------------------+----------+------+-------------------------------------------------------------+ -3 rows in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -EXPLAIN DELETE FROM t1 WHERE c1=3; -``` - -``` -+---------------------+----------+------+-------------------------------------------------------------+ -| id | count | task | operator info | -+---------------------+----------+------+-------------------------------------------------------------+ -| TableReader_6 | 10.00 | root | data:Selection_5 | -| └─Selection_5 | 10.00 | cop | eq(test.t1.c1, 3) | -| └─TableScan_4 | 10000.00 | cop | table:t1, range:[-inf,+inf], keep order:false, stats:pseudo | -+---------------------+----------+------+-------------------------------------------------------------+ -3 rows in set (0.00 sec) -``` - -如果未指定 `FORMAT`，或未指定 `FORMAT ="row"`，那么 `EXPLAIN` 语句将以表格格式输出结果。更多信息，可参阅 [Understand the Query Execution Plan](https://pingcap.com/docs/dev/reference/performance/understanding-the-query-execution-plan/)。 - -除 MySQL 标准结果格式外，TiDB 还支持 DotGraph。需按照下列所示指定 `FORMAT ="dot"`： - -{{< copyable "sql" >}} - -```sql -create table t(a bigint, b bigint); -desc format = "dot" select A.a, B.b from t A join t B on A.a > B.b where A.a < 10; -``` - -```+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| dot contents | -+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| -digraph HashRightJoin_7 { -subgraph cluster7{ -node [style=filled, color=lightgrey] -color=black -label = "root" -"HashRightJoin_7" -> "TableReader_10" -"HashRightJoin_7" -> "TableReader_12" -} -subgraph cluster9{ -node [style=filled, color=lightgrey] -color=black -label = "cop" -"Selection_9" -> "TableScan_8" -} -subgraph cluster11{ -node [style=filled, color=lightgrey] -color=black -label = "cop" -"TableScan_11" -} -"TableReader_10" -> "Selection_9" -"TableReader_12" -> "TableScan_11" -} - | -+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -1 row in set (0.00 sec) -``` - -如果你的计算机上安装了 `dot` 程序（在 `graphviz` 包中），可使用以下方法生成 PNG 文件： - -{{< copyable "shell-regular" >}} - -```bash -dot xx.dot -T png -O -``` - -The `xx.dot` is the result returned by the above statement. - -如果你的计算机上未安装 `dot` 程序，可将结果复制到 [本网站](http://www.webgraphviz.com/) 以获取树形图： - -![Explain Dot](/media/explain_dot.png) - -## MySQL 兼容性 - -* `EXPLAIN` 的格式和 TiDB 中潜在的执行计划都与 MySQL 有很大不同。 -* TiDB 不像 MySQL 那样支持 `EXPLAIN FORMAT = JSON`。 -* TiDB 目前不支持插入语句的 `EXPLAIN`。 - -## 另请参阅 - -* [Understanding the Query Execution Plan](/dev/reference/performance/understanding-the-query-execution-plan.md) -* [EXPLAIN ANALYZE](/dev/reference/sql/statements/explain-analyze.md) -* [ANALYZE TABLE](/dev/reference/sql/statements/analyze-table.md) -* [TRACE](/dev/reference/sql/statements/trace.md) diff --git a/dev/reference/sql/statements/load-data.md b/dev/reference/sql/statements/load-data.md deleted file mode 100644 index 94a27adaaa63..000000000000 --- a/dev/reference/sql/statements/load-data.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: LOAD DATA -summary: TiDB 数据库中 LOAD DATA 的使用概况。 -category: reference ---- - -# LOAD DATA - -`LOAD DATA` 语句用于将数据批量加载到 TiDB 表中。 - -## 语法图 - -**LoadDataStmt:** - -![LoadDataStmt](/media/sqlgram/LoadDataStmt.png) - -## 示例 - -{{< copyable "sql" >}} - -```sql -CREATE TABLE trips ( - -> trip_id bigint NOT NULL PRIMARY KEY AUTO_INCREMENT, - -> duration integer not null, - -> start_date datetime, - -> end_date datetime, - -> start_station_number integer, - -> start_station varchar(255), - -> end_station_number integer, - -> end_station varchar(255), - -> bike_number varchar(255), - -> member_type varchar(255) - -> ); -``` - -``` -Query OK, 0 rows affected (0.14 sec) -``` - -{{< copyable "sql" >}} - -```sql -LOAD DATA LOCAL INFILE '/mnt/evo970/data-sets/bikeshare-data/2017Q4-capitalbikeshare-tripdata.csv' INTO TABLE trips FIELDS TERMINATED BY ',' ENCLOSED BY '\"' LINES TERMINATED BY '\r\n' IGNORE 1 LINES (duration, start_date, end_date, start_station_number, start_station, end_station_number, end_station, bike_number, member_type); -``` - -``` -Query OK, 815264 rows affected (39.63 sec) -Records: 815264 Deleted: 0 Skipped: 0 Warnings: 0 -``` - -`LOAD DATA` 也支持使用十六进制 ASCII 字符表达式或二进制 ASCII 字符表达式作为 `FIELDS ENCLOSED BY` 和 `FIELDS TERMINATED BY` 的参数。示例如下： - -{{< copyable "sql" >}} - -```sql -LOAD DATA LOCAL INFILE '/mnt/evo970/data-sets/bikeshare-data/2017Q4-capitalbikeshare-tripdata.csv' INTO TABLE trips FIELDS TERMINATED BY x'2c' ENCLOSED BY b'100010' LINES TERMINATED BY '\r\n' IGNORE 1 LINES (duration, start_date, end_date, start_station_number, start_station, end_station_number, end_station, bike_number, member_type); -``` - -以上示例中 `x'2c'` 是字符 `,` 的十六进制表示，`b'100010'` 是字符 `"` 的二进制表示。 - -## MySQL 兼容性 - -* 默认情况下，TiDB 每 20,000 行会进行一次提交。这类似于 MySQL NDB Cluster，但并非 InnoDB 存储引擎的默认配置。 - -> **注意：** -> -> 这种拆分事务提交的方式是以打破事务的原子性和隔离性为代价的，使用该特性时，使用者需要保证没有其他对正在处理的表的**任何**操作，并且在出现报错时，需要及时**人工介入，检查数据的一致性和完整性**。因此，不建议在生产环境中使用。 - -## 另请参阅 - -* [INSERT](/dev/reference/sql/statements/insert.md) -* [乐观事务模型](/dev/reference/transactions/transaction-optimistic.md) diff --git a/dev/reference/sql/statements/prepare.md b/dev/reference/sql/statements/prepare.md deleted file mode 100644 index 47fa7a8f84b4..000000000000 --- a/dev/reference/sql/statements/prepare.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: PREPARE -summary: TiDB 数据库中 PREPARE 的使用概况。 -category: reference ---- - -# PREPARE - -`PREPARE` 语句为服务器端预处理语句提供 SQL 接口。 - -## 语法图 - -**PreparedStmt:** - -![PreparedStmt](/media/sqlgram/PreparedStmt.png) - -## 示例 - -{{< copyable "sql" >}} - -```sql -PREPARE mystmt FROM 'SELECT ? as num FROM DUAL'; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SET @number = 5; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -EXECUTE mystmt USING @number; -``` - -``` -+------+ -| num | -+------+ -| 5 | -+------+ -1 row in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -DEALLOCATE PREPARE mystmt; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -## MySQL 兼容性 - -`PREPARE` 语句与 MySQL 完全兼容。如有任何兼容性差异，请在 GitHub 上提交 [issue](/dev/report-issue.md)。 - -## 另请参阅 - -* [EXECUTE](/dev/reference/sql/statements/execute.md) -* [DEALLOCATE](/dev/reference/sql/statements/deallocate.md) diff --git a/dev/reference/sql/statements/recover-table.md b/dev/reference/sql/statements/recover-table.md deleted file mode 100644 index 4069bfddbe8f..000000000000 --- a/dev/reference/sql/statements/recover-table.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: RECOVER TABLE -category: reference ---- - -# RECOVER TABLE - -`RECOVER TABLE` 的功能是恢复被删除的表及其数据。在 `DROP TABLE` 后，在 GC life time 时间内，可以用 `RECOVER TABLE` 语句恢复被删除的表以及其数据。 - -## 语法 - -{{< copyable "sql" >}} - -```sql -RECOVER TABLE table_name -``` - -{{< copyable "sql" >}} - -```sql -RECOVER TABLE BY JOB ddl_job_id -``` - -## 注意事项 - -如果删除表后并过了 GC lifetime，就不能再用 `RECOVER TABLE` 来恢复被删除的表了，执行 `RECOVER TABLE` 语句会返回类似错误：`snapshot is older than GC safe point 2019-07-10 13:45:57 +0800 CST`。 - -对于 3.0.0 及之后的 TiDB 版本，不推荐在使用 TiDB Binlog 的情况下使用 `RECOVER TABLE` 功能。 - -TiDB Binlog 在 3.0.1 支持 `RECOVER TABLE` 后，可在下面的情况下使用 `RECOVER TABLE`： - -* 3.0.1+ 版本的 TiDB Binlog -* 主从集群都使用 TiDB 3.0 -* 从集群 GC lifetime 一定要长于主集群（不过由于上下游同步的延迟，可能也会造成下游 recover 失败） - -### TiDB Binlog 同步错误处理 - -当使用 TiDB Binlog 同步工具时，上游 TiDB 使用 `RECOVER TABLE` 后，TiDB Binlog 可能会因为下面几个原因造成同步中断： - -* 下游数据库不支持 `RECOVER TABLE` 语句。类似错误：`check the manual that corresponds to your MySQL server version for the right syntax to use near 'RECOVER TABLE table_name'`。 - -* 上下游数据库的 GC lifetime 不一样。类似错误：`snapshot is older than GC safe point 2019-07-10 13:45:57 +0800 CST`。 - -* 上下游数据库的同步延迟。类似错误：`snapshot is older than GC safe point 2019-07-10 13:45:57 +0800 CST`。 - -只能通过重新[全量导入被删除的表](/dev/reference/tools/user-guide.md#tidb-集群数据的全量备份及恢复-1)来恢复 TiDB Binlog 的数据同步。 - -## 示例 - -- 根据表名恢复被删除的表。 - - {{< copyable "sql" >}} - - ```sql - DROP TABLE t; - ``` - - {{< copyable "sql" >}} - - ```sql - RECOVER TABLE t; - ``` - - 根据表名恢复被删除的表需满足以下条件： - - - 最近 DDL JOB 历史中找到的第一个 `DROP TABLE` 操作，且 - - `DROP TABLE` 所删除的表的名称与 `RECOVER TABLE` 语句指定表名相同 - -- 根据删除表时的 DDL JOB ID 恢复被删除的表。 - - 如果第一次删除表 t 后，又新建了一个表 t，然后又把新建的表 t 删除了，此时如果想恢复最开始删除的表 t, 就需要用到指定 DDL JOB ID 的语法了。 - - {{< copyable "sql" >}} - - ```sql - DROP TABLE t; - ``` - - {{< copyable "sql" >}} - - ```sql - ADMIN SHOW DDL JOBS 1; - ``` - - 上面这个语句用来查找删除表 t 时的 DDL JOB ID，这里是 53： - - ``` - +--------+---------+------------+------------+--------------+-----------+----------+-----------+-----------------------------------+--------+ - | JOB_ID | DB_NAME | TABLE_NAME | JOB_TYPE | SCHEMA_STATE | SCHEMA_ID | TABLE_ID | ROW_COUNT | START_TIME | STATE | - +--------+---------+------------+------------+--------------+-----------+----------+-----------+-----------------------------------+--------+ - | 53 | test | | drop table | none | 1 | 41 | 0 | 2019-07-10 13:23:18.277 +0800 CST | synced | - +--------+---------+------------+------------+--------------+-----------+----------+-----------+-----------------------------------+--------+ - ``` - - {{< copyable "sql" >}} - - ```sql - RECOVER TABLE BY JOB 53; - ``` - - 根据删除表时的 DDL JOB ID 恢复被删除的表，会直接用 DDL JOB ID 找到被删除表进行恢复。如果指定的 DDL JOB ID 的 DDL JOB 不是 `DROP TABLE` 类型，会报错。 - -## 原理 - -TiDB 在删除表时，实际上只删除了表的元信息，并将需要删除的表数据（行数据和索引数据）写一条数据到 `mysql.gc_delete_range` 表。TiDB 后台的 GC Worker 会定期从 `mysql.gc_delete_range` 表中取出超过 GC lifetime 相关范围的 key 进行删除。 - -所以，RECOVER TABLE 只需要在 GC Worker 还没删除表数据前，恢复表的元信息并删除 `mysql.gc_delete_range` 表中相应的行记录就可以了。恢复表的元信息可以用 TiDB 的快照读实现。具体的快照读内容可以参考[读取历史数据](/dev/how-to/get-started/read-historical-data.md)文档。 - -TiDB 中表的恢复是通过快照读获取表的元信息后，再走一次类似于 `CREATE TABLE` 的建表流程，所以 `RECOVER TABLE` 实际上也是一种 DDL。 diff --git a/dev/reference/sql/statements/select.md b/dev/reference/sql/statements/select.md deleted file mode 100644 index e8b83945c812..000000000000 --- a/dev/reference/sql/statements/select.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -title: SELECT -summary: TiDB 数据库中 SELECT 的使用概况。 -category: reference ---- - -# SELECT - -`SELECT` 语句用于从 TiDB 读取数据。 - -## 语法图 - -**SelectStmt:** - -![SelectStmt](/media/sqlgram/SelectStmt.png) - -**FromDual:** - -![FromDual](/media/sqlgram/FromDual.png) - -**WhereClauseOptional:** - -![WhereClauseOptional](/media/sqlgram/WhereClauseOptional.png) - -**SelectStmtOpts:** - -![SelectStmtOpts](/media/sqlgram/SelectStmtOpts.png) - -**SelectStmtFieldList:** - -![SelectStmtFieldList](/media/sqlgram/SelectStmtFieldList.png) - -**TableRefsClause:** - -![TableRefsClause](/media/sqlgram/TableRefsClause.png) - -**WhereClauseOptional:** - -![WhereClauseOptional](/media/sqlgram/WhereClauseOptional.png) - -**SelectStmtGroup:** - -![SelectStmtGroup](/media/sqlgram/SelectStmtGroup.png) - -**HavingClause:** - -![HavingClause](/media/sqlgram/HavingClause.png) - -**OrderByOptional:** - -![OrderByOptional](/media/sqlgram/OrderByOptional.png) - -**SelectStmtLimit:** - -![SelectStmtLimit](/media/sqlgram/SelectStmtLimit.png) - -**SelectLockOpt:** - -![SelectLockOpt](/media/sqlgram/SelectLockOpt.png) - -## 语法元素说明 - -|语法元素 | 说明 | -| --------------------- | -------------------------------------------------- | -|`ALL`、`DISTINCT`、`DISTINCTROW` | 查询结果集中可能会包含重复值。指定 DISTINCT/DISTINCTROW 则在查询结果中过滤掉重复的行；指定 ALL 则列出所有的行。默认为 ALL。| -|`HIGH_PRIORITY` | 该语句为高优先级语句，TiDB 在执行阶段会优先处理这条语句| -|`SQL_CALC_FOUND_ROWS` | TiDB 出于兼容性解析这个语法，但是不做任何处理| -|`SQL_CACHE`、`SQL_NO_CACHE` | 是否把请求结果缓存到 TiKV (RocksDB) 的 `BlockCache` 中。对于一次性的大数据量的查询，比如 `count(*)` 查询，为了避免冲掉 `BlockCache` 中用户的热点数据，建议填上 `SQL_NO_CACHE` | -|`STRAIGHT_JOIN`|`STRAIGHT_JOIN` 会强制优化器按照 `FROM` 子句中所使用的表的顺序做联合查询。当优化器选择的 Join 顺序并不优秀时，你可以使用这个语法来加速查询的执行| -|`select_expr` | 投影操作列表，一般包括列名、表达式，或者是用 '\*' 表示全部列| -|`FROM table_references` | 表示数据来源，数据来源可以是一个表（`select * from t;`）或者是多个表 (`select * from t1 join t2;`) 或者是0个表 (`select 1+1 from dual;`, 等价于 `select 1+1;`)| -|`WHERE where_condition` | Where 子句用于设置过滤条件，查询结果中只会包含满足条件的数据| -|`GROUP BY` | GroupBy 子句用于对查询结果集进行分组| -|`HAVING where_condition` | Having 子句与 Where 子句作用类似，Having 子句可以让过滤 GroupBy 后的各种数据，Where 子句用于在聚合前过滤记录。| -|`ORDER BY` | OrderBy 子句用于指定结果排序顺序，可以按照列、表达式或者是 `select_expr` 列表中某个位置的字段进行排序。| -|`LIMIT` | Limit 子句用于限制结果条数。Limit 接受一个或两个数字参数，如果只有一个参数，那么表示返回数据的最大行数；如果是两个参数，那么第一个参数表示返回数据的第一行的偏移量（第一行数据的偏移量是 0），第二个参数指定返回数据的最大条目数。| -|`FOR UPDATE` | 对查询结果集所有行上锁（对于在查询条件内，但是不在结果集的行，将不会加锁，如事务启动后由其他事务写入的行），以监测其他事务对这些的并发修改。使用[乐观事务模型](/dev/reference/transactions/transaction-optimistic.md)时，语句执行期间不会检测锁，因此，不会像 PostgreSQL 之类的数据库一样，在当前事务结束前阻止其他事务执行 `UPDATE`、`DELETE` 和 `SELECT FOR UPDATE`。在事务的提交阶段 `SELECT FOR UPDATE` 读到的行，也会进行两阶段提交，因此，它们也可以参与事务冲突检测。如发生写入冲突，那么包含 `SELECT FOR UPDATE` 语句的事务会提交失败。如果没有冲突，事务将成功提交，当提交结束时，这些被加锁的行，会产生一个新版本，可以让其他尚未提交的事务，在将来提交时发现写入冲突。若使用悲观事务，则行为与其他数据库基本相同，不一致之处参考[和 MySQL InnoDB 的差异](/dev/reference/transactions/transaction-pessimistic.md#和-mysql-innodb-的差异)。 | -|`LOCK IN SHARE MODE` | TiDB 出于兼容性解析这个语法，但是不做任何处理| - -## 示例 - -{{< copyable "sql" >}} - -```sql -CREATE TABLE t1 (id INT NOT NULL PRIMARY KEY AUTO_INCREMENT, c1 INT NOT NULL); -``` - -``` -Query OK, 0 rows affected (0.11 sec) -``` - -{{< copyable "sql" >}} - -```sql -INSERT INTO t1 (c1) VALUES (1),(2),(3),(4),(5); -``` - -``` -Query OK, 5 rows affected (0.03 sec) -Records: 5 Duplicates: 0 Warnings: 0 -``` - -{{< copyable "sql" >}} - -```sql -SELECT * FROM t1; -``` - -``` -+----+----+ -| id | c1 | -+----+----+ -| 1 | 1 | -| 2 | 2 | -| 3 | 3 | -| 4 | 4 | -| 5 | 5 | -+----+----+ -5 rows in set (0.00 sec) -``` - -## MySQL 兼容性 - -`SELECT` 语句与 MySQL 完全兼容。如有任何兼容性差异，请在 GitHub 上提交 [issue](/dev/report-issue.md)。 - -## 另请参阅 - -* [INSERT](/dev/reference/sql/statements/insert.md) -* [DELETE](/dev/reference/sql/statements/delete.md) -* [UPDATE](/dev/reference/sql/statements/update.md) -* [REPLACE](/dev/reference/sql/statements/replace.md) diff --git a/dev/reference/sql/statements/show-fields-from.md b/dev/reference/sql/statements/show-fields-from.md deleted file mode 100644 index 75f2ff268250..000000000000 --- a/dev/reference/sql/statements/show-fields-from.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: SHOW [FULL] FIELDS FROM -summary: TiDB 数据库中 SHOW [FULL] FIELDS FROM 的使用概况。 -category: reference ---- - -# SHOW [FULL] FIELDS FROM - -`SHOW [FULL] FIELDS FROM` 是 [`SHOW [FULL] COLUMNS FROM`](/dev/reference/sql/statements/show-columns-from.md) 的别名。包含该语句提供了 MySQL 兼容性。 diff --git a/dev/reference/sql/statements/show-index.md b/dev/reference/sql/statements/show-index.md deleted file mode 100644 index a22b9bf576be..000000000000 --- a/dev/reference/sql/statements/show-index.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: SHOW INDEX [FROM|IN] -summary: TiDB 数据库中 SHOW INDEX [FROM|IN] 的使用概况。 -category: reference ---- - -# SHOW INDEX [FROM|IN] - -`SHOW INDEX [FROM|IN]` 语句是 [`SHOW INDEXES [FROM|IN]`](/dev/reference/sql/statements/show-indexes.md) 的别名。包含该语句提供了 MySQL 兼容性。 diff --git a/dev/reference/sql/statements/show-keys.md b/dev/reference/sql/statements/show-keys.md deleted file mode 100644 index 531445ca1807..000000000000 --- a/dev/reference/sql/statements/show-keys.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: SHOW KEYS [FROM|IN] -summary: TiDB 数据库中 SHOW KEYS [FROM|IN] 的使用概况。 -category: reference ---- - -# SHOW KEYS [FROM|IN] - -`SHOW KEYS [FROM|IN]` 语句是 [`SHOW INDEXES [FROM|IN]`](/dev/reference/sql/statements/show-indexes.md) 语句的别名。包含该语句提供了 MySQL 兼容性。。 diff --git a/dev/reference/sql/statements/show-schemas.md b/dev/reference/sql/statements/show-schemas.md deleted file mode 100644 index b07d9096c189..000000000000 --- a/dev/reference/sql/statements/show-schemas.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: SHOW SCHEMAS -summary: TiDB 数据库中 SHOW SCHEMAS 的使用概况。 -category: reference ---- - -# SHOW SCHEMAS - -`SHOW SCHEMAS` 语句是 [`SHOW DATABASES`](/dev/reference/sql/statements/show-databases.md) 的别名。包含该语句提供了 MySQL 兼容性。。 diff --git a/dev/reference/sql/statements/show-table-regions.md b/dev/reference/sql/statements/show-table-regions.md deleted file mode 100644 index a2bba5757798..000000000000 --- a/dev/reference/sql/statements/show-table-regions.md +++ /dev/null @@ -1,179 +0,0 @@ ---- -title: SHOW TABLE REGIONS -summary: 了解如何使用 TiDB 数据库中的 SHOW TABLE REGIONS。 -category: reference ---- - -# SHOW TABLE REGIONS - -`SHOW TABLE REGIONS` 语句用于显示 TiDB 中某个表的 Region 信息。 - -## 语法图 - -```sql -SHOW TABLE [table_name] REGIONS [WhereClauseOptional]; - -SHOW TABLE [table_name] INDEX [index_name] REGIONS [WhereClauseOptional]; -``` - -`SHOW TABLE REGIONS` 会返回如下列： - -* `REGION_ID`：Region 的 ID。 -* `START_KEY`：Region 的 Start key。 -* `END_KEY`：Region 的 End key。 -* `LEADER_ID`：Region 的 Leader ID。 -* `LEADER_STORE_ID`：Region leader 所在的 store (TiKV) ID。 -* `PEERS`：Region 所有副本的 ID。 -* `SCATTERING`：Region 是否正在调度中。1 表示正在调度。 -* `WRITTEN_BYTES`：估算的 Region 在 1 个心跳周期内的写入数据量大小，单位是 byte。 -* `READ_BYTES`：估算的 Region 在 1 个心跳周期内的读数据量大小，单位是 byte。 -* `APPROXIMATE_SIZE(MB)`：估算的 Region 的数据量大小，单位是 MB。 -* `APPROXIMATE_KEYS`：估算的 Region 内 Key 的个数。 - -> **注意：** -> -> `WRITTEN_BYTES`，`READ_BYTES`，`APPROXIMATE_SIZE(MB)`，`APPROXIMATE_KEYS` 的值是 PD 根据 Region 的心跳汇报信息统计，估算出来的数据，所以不是精确的数据。 - -## 示例 - -{{< copyable "sql" >}} - -```sql -create table t (id int key,name varchar(50), index (name)); -``` - -``` -Query OK, 0 rows affected -``` - -默认新建表后会单独 split 出一个 Region 来存放该表的数据，开始时行数据和索引数据都会写到这个 Region。 - -{{< copyable "sql" >}} - -```sql -show table t regions; -``` - -``` -+-----------+-----------+---------+-----------+-----------------+-----------+------------+---------------+------------+----------------------+------------------+ -| REGION_ID | START_KEY | END_KEY | LEADER_ID | LEADER_STORE_ID | PEERS | SCATTERING | WRITTEN_BYTES | READ_BYTES | APPROXIMATE_SIZE(MB) | APPROXIMATE_KEYS | -+-----------+-----------+---------+-----------+-----------------+-----------+------------+---------------+------------+----------------------+------------------+ -| 3 | t_43_ | | 73 | 9 | 5, 73, 93 | 0 | 35 | 0 | 1 | 0 | -+-----------+-----------+---------+-----------+-----------------+-----------+------------+---------------+------------+----------------------+------------------+ -1 row in set -``` - -解释： - -- 上面 START_KEY 列的值 t_43_ 中，t 是表数据的前缀，43 是表 t 的 table ID。 -- END_KEY 列的值为空（""）表示无穷大。 - -用 `SPLIT TABLE REGION` 语法切分行数据的 Region，下面语法把表 t 的行数据切分成 5 个 Region。 - -{{< copyable "sql" >}} - -```sql -split table t between (0) and (100000) regions 5; -``` - -``` -+--------------------+----------------------+ -| TOTAL_SPLIT_REGION | SCATTER_FINISH_RATIO | -+--------------------+----------------------+ -| 5 | 1.0 | -+--------------------+----------------------+ -1 row in set -``` - -解释： - -- TOTAL_SPLIT_REGION 表示新切的 region 数量，这是新切了 5 个 region. -- SCATTER_FINISH_RATIO 表示新切的 region 的打散成功率，1.0 表示都已经打散了。 - -表 t 现在一共有 6 个 Region，其中 102、106、110、114、3 用来存行数据，Region 98 用来存索引数据。 - -{{< copyable "sql" >}} - -```sql -show table t regions; -``` - -``` -+-----------+--------------+--------------+-----------+-----------------+---------------+------------+---------------+------------+----------------------+------------------+ -| REGION_ID | START_KEY | END_KEY | LEADER_ID | LEADER_STORE_ID | PEERS | SCATTERING | WRITTEN_BYTES | READ_BYTES | APPROXIMATE_SIZE(MB) | APPROXIMATE_KEYS | -+-----------+--------------+--------------+-----------+-----------------+---------------+------------+---------------+------------+----------------------+------------------+ -| 102 | t_43_r | t_43_r_20000 | 118 | 7 | 105, 118, 119 | 0 | 0 | 0 | 1 | 0 | -| 106 | t_43_r_20000 | t_43_r_40000 | 120 | 7 | 107, 108, 120 | 0 | 23 | 0 | 1 | 0 | -| 110 | t_43_r_40000 | t_43_r_60000 | 112 | 9 | 112, 113, 121 | 0 | 0 | 0 | 1 | 0 | -| 114 | t_43_r_60000 | t_43_r_80000 | 122 | 7 | 115, 122, 123 | 0 | 35 | 0 | 1 | 0 | -| 3 | t_43_r_80000 | | 93 | 8 | 5, 73, 93 | 0 | 0 | 0 | 1 | 0 | -| 98 | t_43_ | t_43_r | 99 | 1 | 99, 100, 101 | 0 | 0 | 0 | 1 | 0 | -+-----------+--------------+--------------+-----------+-----------------+---------------+------------+---------------+------------+----------------------+------------------+ -6 rows in set -``` - -解释： - -- Region 102 的 START_KEY 和 END_KEY 中，t_43 是表数据前缀和 table ID，_r 是表 t record 数据的前缀，索引数据的前缀是 _i，所以 Region 102 的 START_KEY 和 END_KEY 表示用来存储 [-inf, 20000) 之前的 record 数据。其他 Region (103, 109, 113, 2) 的存储范围依次类推。 -- Region 98 用来存储索引数据存储。表 t 索引数据的起始 key 是 t_43_i，处于 Region 98 的存储范围内。 - -查看表 t 在 store 1 上的 region，用 where 条件过滤。 - -{{< copyable "sql" >}} - -```sql -show table t regions where leader_store_id =1; -``` - -``` -+-----------+-----------+---------+-----------+-----------------+--------------+------------+---------------+------------+----------------------+------------------+ -| REGION_ID | START_KEY | END_KEY | LEADER_ID | LEADER_STORE_ID | PEERS | SCATTERING | WRITTEN_BYTES | READ_BYTES | APPROXIMATE_SIZE(MB) | APPROXIMATE_KEYS | -+-----------+-----------+---------+-----------+-----------------+--------------+------------+---------------+------------+----------------------+------------------+ -| 98 | t_43_ | t_43_r | 99 | 1 | 99, 100, 101 | 0 | 0 | 0 | 1 | 0 | -+-----------+-----------+---------+-----------+-----------------+--------------+------------+---------------+------------+----------------------+------------------+ -``` - -用 `SPLIT TABLE REGION` 语法切分索引数据的 Region，下面语法把表 t 的索引 name 数据在 [a,z] 范围内切分成 2 个 Region。 - -{{< copyable "sql" >}} - -```sql -split table t index name between ("a") and ("z") regions 2; -``` - -``` -+--------------------+----------------------+ -| TOTAL_SPLIT_REGION | SCATTER_FINISH_RATIO | -+--------------------+----------------------+ -| 2 | 1.0 | -+--------------------+----------------------+ -1 row in set -``` - -现在表 t 一共有 7 个 Region，其中 5 个 Region (102, 106, 110, 114, 3) 用来存表 t 的 record 数据，另外 2 个 Region (135, 98) 用来存 name 索引的数据。 - -{{< copyable "sql" >}} - -```sql -show table t regions; -``` - -``` -+-----------+-----------------------------+-----------------------------+-----------+-----------------+---------------+------------+---------------+------------+----------------------+------------------+ -| REGION_ID | START_KEY | END_KEY | LEADER_ID | LEADER_STORE_ID | PEERS | SCATTERING | WRITTEN_BYTES | READ_BYTES | APPROXIMATE_SIZE(MB) | APPROXIMATE_KEYS | -+-----------+-----------------------------+-----------------------------+-----------+-----------------+---------------+------------+---------------+------------+----------------------+------------------+ -| 102 | t_43_r | t_43_r_20000 | 118 | 7 | 105, 118, 119 | 0 | 0 | 0 | 1 | 0 | -| 106 | t_43_r_20000 | t_43_r_40000 | 120 | 7 | 108, 120, 126 | 0 | 0 | 0 | 1 | 0 | -| 110 | t_43_r_40000 | t_43_r_60000 | 112 | 9 | 112, 113, 121 | 0 | 0 | 0 | 1 | 0 | -| 114 | t_43_r_60000 | t_43_r_80000 | 122 | 7 | 115, 122, 123 | 0 | 35 | 0 | 1 | 0 | -| 3 | t_43_r_80000 | | 93 | 8 | 73, 93, 128 | 0 | 0 | 0 | 1 | 0 | -| 135 | t_43_i_1_ | t_43_i_1_016d80000000000000 | 139 | 2 | 138, 139, 140 | 0 | 35 | 0 | 1 | 0 | -| 98 | t_43_i_1_016d80000000000000 | t_43_r | 99 | 1 | 99, 100, 101 | 0 | 0 | 0 | 1 | 0 | -+-----------+-----------------------------+-----------------------------+-----------+-----------------+---------------+------------+---------------+------------+----------------------+------------------+ -7 rows in set -``` - -## 另请参阅 - -* [SPLIT REGION](/dev/reference/sql/statements/split-region.md) -* [CREATE TABLE](/dev/reference/sql/statements/create-table.md) diff --git a/dev/reference/sql/statements/show-variables.md b/dev/reference/sql/statements/show-variables.md deleted file mode 100644 index 2320601b808e..000000000000 --- a/dev/reference/sql/statements/show-variables.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -title: SHOW [GLOBAL|SESSION] VARIABLES -summary: TiDB 数据库中 SHOW [GLOBAL|SESSION] VARIABLES 的使用概况。 -category: reference ---- - -# SHOW [GLOBAL|SESSION] VARIABLES - -`SHOW [GLOBAL|SESSION] VARIABLES` 语句用于显示 `GLOBAL` 或 `SESSION` 范围的变量列表。如果未指定范围，则应用默认范围 `SESSION`。 - -## 语法图 - -**ShowStmt:** - -![ShowStmt](/media/sqlgram/ShowStmt.png) - -**ShowTargetFilterable:** - -![ShowTargetFilterable](/media/sqlgram/ShowTargetFilterable.png) - -**GlobalScope:** - -![GlobalScope](/media/sqlgram/GlobalScope.png) - -## 示例 - -{{< copyable "sql" >}} - -```sql -SHOW GLOBAL VARIABLES LIKE 'tidb%'; -``` - -``` -+-------------------------------------+---------------+ -| Variable_name | Value | -+-------------------------------------+---------------+ -| tidb_ddl_error_count_limit | 512 | -| tidb_dml_batch_size | 20000 | -| tidb_force_priority | NO_PRIORITY | -| tidb_batch_insert | 0 | -| tidb_skip_utf8_check | 0 | -| tidb_backoff_lock_fast | 100 | -| tidb_opt_join_reorder_threshold | 0 | -| tidb_auto_analyze_end_time | 23:59 +0000 | -| tidb_slow_log_threshold | 300 | -| tidb_opt_correlation_exp_factor | 1 | -| tidb_mem_quota_sort | 34359738368 | -| tidb_current_ts | 0 | -| tidb_ddl_reorg_batch_size | 256 | -| tidb_checksum_table_concurrency | 4 | -| tidb_check_mb4_value_in_utf8 | 1 | -| tidb_distsql_scan_concurrency | 15 | -| tidb_optimizer_selectivity_level | 0 | -| tidb_opt_agg_push_down | 0 | -| tidb_max_chunk_size | 1024 | -| tidb_low_resolution_tso | 0 | -| tidb_index_lookup_size | 20000 | -| tidb_skip_isolation_level_check | 0 | -| tidb_opt_write_row_id | 0 | -| tidb_wait_split_region_finish | 1 | -| tidb_index_lookup_join_concurrency | 4 | -| tidb_mem_quota_indexlookupjoin | 34359738368 | -| tidb_replica_read | leader | -| tidb_ddl_reorg_priority | PRIORITY_LOW | -| tidb_batch_commit | 0 | -| tidb_mem_quota_mergejoin | 34359738368 | -| tidb_mem_quota_query | 34359738368 | -| tidb_batch_delete | 0 | -| tidb_build_stats_concurrency | 4 | -| tidb_enable_index_merge | 0 | -| tidb_enable_radix_join | 0 | -| tidb_retry_limit | 10 | -| tidb_query_log_max_len | 2048 | -| tidb_config | | -| tidb_ddl_reorg_worker_cnt | 4 | -| tidb_opt_insubq_to_join_and_agg | 1 | -| tidb_enable_vectorized_expression | 1 | -| tidb_mem_quota_hashjoin | 34359738368 | -| tidb_disable_txn_auto_retry | 1 | -| tidb_enable_window_function | 1 | -| tidb_init_chunk_size | 32 | -| tidb_constraint_check_in_place | 0 | -| tidb_wait_split_region_timeout | 300 | -| tidb_hash_join_concurrency | 5 | -| tidb_enable_fast_analyze | 0 | -| tidb_enable_cascades_planner | 0 | -| tidb_txn_mode | | -| tidb_index_serial_scan_concurrency | 1 | -| tidb_projection_concurrency | 4 | -| tidb_enable_noop_functions | 0 | -| tidb_index_lookup_concurrency | 4 | -| tidb_hashagg_partial_concurrency | 4 | -| tidb_general_log | 0 | -| tidb_enable_streaming | 0 | -| tidb_backoff_weight | 2 | -| tidb_mem_quota_topn | 34359738368 | -| tidb_scatter_region | 0 | -| tidb_index_join_batch_size | 25000 | -| tidb_snapshot | | -| tidb_expensive_query_time_threshold | 60 | -| tidb_slow_query_file | tidb-slow.log | -| tidb_auto_analyze_ratio | 0.5 | -| tidb_enable_table_partition | auto | -| tidb_auto_analyze_start_time | 00:00 +0000 | -| tidb_mem_quota_nestedloopapply | 34359738368 | -| tidb_mem_quota_indexlookupreader | 34359738368 | -| tidb_hashagg_final_concurrency | 4 | -| tidb_opt_correlation_threshold | 0.9 | -+-------------------------------------+---------------+ -68 rows in set (0.01 sec) -``` - -{{< copyable "sql" >}} - -```sql -SHOW GLOBAL VARIABLES LIKE 'time_zone%'; -``` - -``` -+---------------+--------+ -| Variable_name | Value | -+---------------+--------+ -| time_zone | SYSTEM | -+---------------+--------+ -1 row in set (0.00 sec) -``` - -## MySQL 兼容性 - -`SHOW [GLOBAL|SESSION] VARIABLES` 语句与 MySQL 完全兼容。如有任何兼容性差异，请在 GitHub 上提交 [issue](/dev/report-issue.md)。 - -## 另请参阅 - -* [SET](/dev/reference/sql/statements/set-variable.md) diff --git a/dev/reference/supported-clients.md b/dev/reference/supported-clients.md deleted file mode 100644 index f749c8ca066a..000000000000 --- a/dev/reference/supported-clients.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: 连接器和 API -category: reference ---- - -# 连接器和 API - -数据库连接器为客户端提供了连接数据库服务端的方式，APIs 提供了使用 MySQL 协议和资源的底层接口。无论是连接器还是 API，都可以用来在不同的语言和环境内连接服务器并执行 sql 语句，包括 odbc、java(jdbc)、Perl、Python、PHP、Ruby 和 C。 - -TiDB 兼容 MySQL(5.6、5.7) 的所有连接器和 API，包括： - -+ [MySQL Connector/C++](https://dev.mysql.com/doc/refman/5.7/en/connector-cpp-info.html) -+ [MySQL Connector/J](https://dev.mysql.com/doc/refman/5.7/en/connector-j-info.html) -+ [MySQL Connector/Net](https://dev.mysql.com/doc/refman/5.7/en/connector-net-info.html) -+ [MySQL Connector/ODBC](https://dev.mysql.com/doc/refman/5.7/en/connector-odbc-info.html) -+ [MySQL Connector/Python](https://dev.mysql.com/doc/refman/5.7/en/connector-python-info.html) -+ [MySQL C API](https://dev.mysql.com/doc/refman/5.7/en/c-api.html) -+ [MySQL PHP API](https://dev.mysql.com/doc/refman/5.7/en/apis-php-info.html) -+ [MySQL Perl API](https://dev.mysql.com/doc/refman/5.7/en/apis-perl.html) -+ [MySQL Python API](https://dev.mysql.com/doc/refman/5.7/en/apis-python.html) -+ [MySQL Ruby APIs](https://dev.mysql.com/doc/refman/5.7/en/apis-ruby.html) -+ [MySQL Tcl API](https://dev.mysql.com/doc/refman/5.7/en/apis-tcl.html) -+ [MySQL Eiffel Wrapper](https://dev.mysql.com/doc/refman/5.7/en/apis-eiffel.html) -+ [Mysql Go API](https://github.com/go-sql-driver/mysql) - -## 使用 MySQL 连接器连接 TiDB - -Oracle 官方提供了以下 API，TiDB 可以兼容所有这些 API。 - -+ [MySQL Connector/C++](https://dev.mysql.com/doc/refman/5.7/en/connector-cpp-info.html)：C++ 语言的客户端库 -+ [MySQL Connector/J](https://dev.mysql.com/doc/refman/5.7/en/connector-j-info.html)：Java 语言的客户端库，基于标准 JDBC 接口 -+ [MySQL Connector/Net](https://dev.mysql.com/doc/refman/5.7/en/connector-net-info.html)：.Net 语言的客户端库，[MySQL for Visual Studio](https://dev.mysql.com/doc/visual-studio/en/)使用这个库，支持 Microsoft Visual Studio 2012，2013，2015和2017版本 -+ [MySQL Connector/ODBC](https://dev.mysql.com/doc/refman/5.7/en/connector-odbc-info.html)：标准的 ODBC 接口，支持 Windows，Unix 和 OS X -+ [MySQL Connector/Python](https://dev.mysql.com/doc/refman/5.7/en/connector-python-info.html)：Python 语言的客户端包，和 [Python DB API version 2.0](http://www.python.org/dev/peps/pep-0249/) 一致 - -## 使用 MySQL C API 连接 TiDB - -如果使用 C 语言程序直接连接 TiDB，可以直接链接 libmysqlclient 库，使用 MySQL 的 [C API](https://dev.mysql.com/doc/refman/5.7/en/c-api.html)，这是最主要的一种 C 语言连接方式，被各种客户端和 API 广泛使用，包括 Connector/C。 - -## 使用 MySQL 第三方 API 连接 TiDB - -第三方 API 非 Oracle 官方提供，下表列出了常用的第三方 API： - -| Environment | API | Type | Notes | -| -------------- | ---------------------------------------- | -------------------------------- | ---------------------------------------- | -| Ada | GNU Ada MySQL Bindings | `libmysqlclient` | See [MySQL Bindings for GNU Ada](http://gnade.sourceforge.net/) | -| C | C API | `libmysqlclient` | See [Section 27.8, “MySQL C API”](https://dev.mysql.com/doc/refman/5.7/en/c-api.html). | -| C++ | Connector/C++ | `libmysqlclient` | See [MySQL Connector/C++ Developer Guide](https://dev.mysql.com/doc/connector-cpp/en/). | -| | MySQL++ | `libmysqlclient` | See [MySQL++ Web site](http://tangentsoft.net/mysql++/doc/). | -| | MySQL wrapped | `libmysqlclient` | See [MySQL wrapped](http://www.alhem.net/project/mysql/). | -| Go | go-sql-driver | Native Driver | See [Mysql Go API](https://github.com/go-sql-driver/mysql) | -| Cocoa | MySQL-Cocoa | `libmysqlclient` | Compatible with the Objective-C Cocoa environment. See | -| D | MySQL for D | `libmysqlclient` | See [MySQL for D](https://github.com/mysql-d/mysql-native). | -| Eiffel | Eiffel MySQL | `libmysqlclient` | See [Section 27.14, “MySQL Eiffel Wrapper”](https://dev.mysql.com/doc/refman/5.7/en/apis-eiffel.html). | -| Erlang | `erlang-mysql-driver` | `libmysqlclient` | See [`erlang-mysql-driver`.](http://code.google.com/p/erlang-mysql-driver/) | -| Haskell | Haskell MySQL Bindings | Native Driver | See [Brian O'Sullivan's pure Haskell MySQL bindings](http://www.serpentine.com/blog/software/mysql/). | -| | `hsql-mysql` | `libmysqlclient` | See [MySQL driver for Haskell](http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsql-mysql-1.7). | -| Java/JDBC | Connector/J | Native Driver | See [MySQL Connector/J 5.1 Developer Guide](https://dev.mysql.com/doc/connector-j/5.1/en/). | -| Lua | LuaSQL | `libmysqlclient` | See [LuaSQL](http://keplerproject.github.io/luasql/manual.html). | -| .NET/Mono | Connector/Net | Native Driver | See [MySQL Connector/Net Developer Guide](https://dev.mysql.com/doc/connector-net/en/). | -| Objective Caml | OBjective Caml MySQL Bindings | `libmysqlclient` | See [MySQL Bindings for Objective Caml](http://raevnos.pennmush.org/code/ocaml-mysql/). | -| Octave | Database bindings for GNU Octave | `libmysqlclient` | See [Database bindings for GNU Octave](http://octave.sourceforge.net/database/index.html). | -| ODBC | Connector/ODBC | `libmysqlclient` | See [MySQL Connector/ODBC Developer Guide](https://dev.mysql.com/doc/connector-odbc/en/). | -| Perl | `DBI`/`DBD::mysql` | `libmysqlclient` | See [Section 27.10, “MySQL Perl API”](https://dev.mysql.com/doc/refman/5.7/en/apis-perl.html). | -| | `Net::MySQL` | Native Driver | See [`Net::MySQL`](http://search.cpan.org/dist/Net-MySQL/MySQL.pm) at CPAN | -| PHP | `mysql`, `ext/mysql`interface (deprecated) | `libmysqlclient` | See [Original MySQL API](https://dev.mysql.com/doc/apis-php/en/apis-php-mysql.html). | -| | `mysqli`, `ext/mysqli`interface | `libmysqlclient` | See [MySQL Improved Extension](https://dev.mysql.com/doc/apis-php/en/apis-php-mysqli.html). | -| | `PDO_MYSQL` | `libmysqlclient` | See [MySQL Functions (PDO_MYSQL)](https://dev.mysql.com/doc/apis-php/en/apis-php-pdo-mysql.html). | -| | PDO mysqlnd | Native Driver | | -| Python | Connector/Python | Native Driver | See [MySQL Connector/Python Developer Guide](https://dev.mysql.com/doc/connector-python/en/). | -| Python | Connector/Python C Extension | `libmysqlclient` | See [MySQL Connector/Python Developer Guide](https://dev.mysql.com/doc/connector-python/en/). | -| | MySQLdb | `libmysqlclient` | See [Section 27.11, “MySQL Python API”](https://dev.mysql.com/doc/refman/5.7/en/apis-python.html). | -| Ruby | MySQL/Ruby | `libmysqlclient` | Uses `libmysqlclient`. See [Section 27.12.1, “The MySQL/Ruby API”](https://dev.mysql.com/doc/refman/5.7/en/apis-ruby-mysqlruby.html). | -| | Ruby/MySQL | Native Driver | See [Section 27.12.2, “The Ruby/MySQL API”](https://dev.mysql.com/doc/refman/5.7/en/apis-ruby-rubymysql.html). | -| Scheme | `Myscsh` | `libmysqlclient` | See [`Myscsh`](https://github.com/aehrisch/myscsh). | -| SPL | `sql_mysql` | `libmysqlclient` | See [`sql_mysql` for SPL](http://www.clifford.at/spl/spldoc/sql_mysql.html). | -| Tcl | MySQLtcl | `libmysqlclient` | See [Section 27.13, “MySQL Tcl API”](https://dev.mysql.com/doc/refman/5.7/en/apis-tcl.html). | - -## TiDB 支持的连接器版本 - -| Connector | Connector version | -| ---------------- | ---------------------------- | -| Connector/C | 6.1.0 GA | -| Connector/C++ | 1.0.5 GA | -| Connector/J | 5.1.8 | -| Connector/Net | 6.9.9 GA | -| Connector/Net | 6.8.8 GA | -| Connector/ODBC | 5.1 | -| Connector/ODBC | 3.51 (Unicode not supported) | -| Connector/Python | 2.0 | -| Connector/Python | 1.2 | diff --git a/dev/reference/system-databases/information-schema.md b/dev/reference/system-databases/information-schema.md deleted file mode 100644 index 77bf530a1fcb..000000000000 --- a/dev/reference/system-databases/information-schema.md +++ /dev/null @@ -1,767 +0,0 @@ ---- -title: Information Schema -category: reference ---- - -# Information Schema - -为了和 MySQL 保持兼容，TiDB 支持很多 `INFORMATION_SCHEMA` 表，其中有不少表都支持相应的 `SHOW` 命令。查询 `INFORMATION_SCHEMA` 表也为表的连接操作提供了可能。 - -## ANALYZE_STATUS 表 - -`ANALYZE_STATUS` 表提供正在执行的收集统计信息的任务以及有限条历史任务记录。 - -{{< copyable "sql" >}} - -```sql -select * from `ANALYZE_STATUS`; -``` - -``` -+--------------+------------+----------------+-------------------+----------------+---------------------+----------+ -| TABLE_SCHEMA | TABLE_NAME | PARTITION_NAME | JOB_INFO | PROCESSED_ROWS | START_TIME | STATE | -+--------------+------------+----------------+-------------------+----------------+---------------------+----------+ -| test | t | | analyze index idx | 2 | 2019-06-21 19:51:14 | finished | -| test | t | | analyze columns | 2 | 2019-06-21 19:51:14 | finished | -| test | t1 | p0 | analyze columns | 0 | 2019-06-21 19:51:15 | finished | -| test | t1 | p3 | analyze columns | 0 | 2019-06-21 19:51:15 | finished | -| test | t1 | p1 | analyze columns | 0 | 2019-06-21 19:51:15 | finished | -| test | t1 | p2 | analyze columns | 1 | 2019-06-21 19:51:15 | finished | -+--------------+------------+----------------+-------------------+----------------+---------------------+----------+ -6 rows in set -``` - -## CHARACTER_SETS 表 - -`CHARACTER_SETS` 表提供[字符集](/dev/reference/sql/character-set.md)相关的信息。TiDB 目前仅支持部分字符集。 - -{{< copyable "sql" >}} - -```sql -SELECT * FROM character_sets; -``` - -``` -+--------------------+----------------------+---------------+--------+ -| CHARACTER_SET_NAME | DEFAULT_COLLATE_NAME | DESCRIPTION | MAXLEN | -+--------------------+----------------------+---------------+--------+ -| utf8 | utf8_bin | UTF-8 Unicode | 3 | -| utf8mb4 | utf8mb4_bin | UTF-8 Unicode | 4 | -| ascii | ascii_bin | US ASCII | 1 | -| latin1 | latin1_bin | Latin1 | 1 | -| binary | binary | binary | 1 | -+--------------------+----------------------+---------------+--------+ -5 rows in set (0.00 sec) -``` - -## COLLATIONS 表 - -`COLLATIONS` 表提供了 `CHARACTER_SETS` 表中字符集对应的排序规则列表。TiDB 当前仅支持二进制排序规则，包含该表仅为兼容 MySQL。 - -{{< copyable "sql" >}} - -```sql -SELECT * FROM collations WHERE character_set_name='utf8mb4'; -``` - -``` -+------------------------+--------------------+------+------------+-------------+---------+ -| COLLATION_NAME | CHARACTER_SET_NAME | ID | IS_DEFAULT | IS_COMPILED | SORTLEN | -+------------------------+--------------------+------+------------+-------------+---------+ -| utf8mb4_general_ci | utf8mb4 | 45 | Yes | Yes | 1 | -| utf8mb4_bin | utf8mb4 | 46 | | Yes | 1 | -| utf8mb4_unicode_ci | utf8mb4 | 224 | | Yes | 1 | -| utf8mb4_icelandic_ci | utf8mb4 | 225 | | Yes | 1 | -| utf8mb4_latvian_ci | utf8mb4 | 226 | | Yes | 1 | -| utf8mb4_romanian_ci | utf8mb4 | 227 | | Yes | 1 | -| utf8mb4_slovenian_ci | utf8mb4 | 228 | | Yes | 1 | -| utf8mb4_polish_ci | utf8mb4 | 229 | | Yes | 1 | -| utf8mb4_estonian_ci | utf8mb4 | 230 | | Yes | 1 | -| utf8mb4_spanish_ci | utf8mb4 | 231 | | Yes | 1 | -| utf8mb4_swedish_ci | utf8mb4 | 232 | | Yes | 1 | -| utf8mb4_turkish_ci | utf8mb4 | 233 | | Yes | 1 | -| utf8mb4_czech_ci | utf8mb4 | 234 | | Yes | 1 | -| utf8mb4_danish_ci | utf8mb4 | 235 | | Yes | 1 | -| utf8mb4_lithuanian_ci | utf8mb4 | 236 | | Yes | 1 | -| utf8mb4_slovak_ci | utf8mb4 | 237 | | Yes | 1 | -| utf8mb4_spanish2_ci | utf8mb4 | 238 | | Yes | 1 | -| utf8mb4_roman_ci | utf8mb4 | 239 | | Yes | 1 | -| utf8mb4_persian_ci | utf8mb4 | 240 | | Yes | 1 | -| utf8mb4_esperanto_ci | utf8mb4 | 241 | | Yes | 1 | -| utf8mb4_hungarian_ci | utf8mb4 | 242 | | Yes | 1 | -| utf8mb4_sinhala_ci | utf8mb4 | 243 | | Yes | 1 | -| utf8mb4_german2_ci | utf8mb4 | 244 | | Yes | 1 | -| utf8mb4_croatian_ci | utf8mb4 | 245 | | Yes | 1 | -| utf8mb4_unicode_520_ci | utf8mb4 | 246 | | Yes | 1 | -| utf8mb4_vietnamese_ci | utf8mb4 | 247 | | Yes | 1 | -+------------------------+--------------------+------+------------+-------------+---------+ -26 rows in set (0.00 sec) -``` - -## COLLATION_CHARACTER_SET_APPLICABILITY 表 - -`COLLATION_CHARACTER_SET_APPLICABILITY` 表将排序规则映射至适用的字符集名称。和 `COLLATIONS` 表一样，包含此表也是为了兼容 MySQL。 - -{{< copyable "sql" >}} - -```sql -SELECT * FROM collation_character_set_applicability WHERE character_set_name='utf8mb4'; -``` - -``` -+------------------------+--------------------+ -| COLLATION_NAME | CHARACTER_SET_NAME | -+------------------------+--------------------+ -| utf8mb4_general_ci | utf8mb4 | -| utf8mb4_bin | utf8mb4 | -| utf8mb4_unicode_ci | utf8mb4 | -| utf8mb4_icelandic_ci | utf8mb4 | -| utf8mb4_latvian_ci | utf8mb4 | -| utf8mb4_romanian_ci | utf8mb4 | -| utf8mb4_slovenian_ci | utf8mb4 | -| utf8mb4_polish_ci | utf8mb4 | -| utf8mb4_estonian_ci | utf8mb4 | -| utf8mb4_spanish_ci | utf8mb4 | -| utf8mb4_swedish_ci | utf8mb4 | -| utf8mb4_turkish_ci | utf8mb4 | -| utf8mb4_czech_ci | utf8mb4 | -| utf8mb4_danish_ci | utf8mb4 | -| utf8mb4_lithuanian_ci | utf8mb4 | -| utf8mb4_slovak_ci | utf8mb4 | -| utf8mb4_spanish2_ci | utf8mb4 | -| utf8mb4_roman_ci | utf8mb4 | -| utf8mb4_persian_ci | utf8mb4 | -| utf8mb4_esperanto_ci | utf8mb4 | -| utf8mb4_hungarian_ci | utf8mb4 | -| utf8mb4_sinhala_ci | utf8mb4 | -| utf8mb4_german2_ci | utf8mb4 | -| utf8mb4_croatian_ci | utf8mb4 | -| utf8mb4_unicode_520_ci | utf8mb4 | -| utf8mb4_vietnamese_ci | utf8mb4 | -+------------------------+--------------------+ -26 rows in set (0.00 sec) -``` - -## COLUMNS 表 - -`COLUMNS` 表提供了表的所有列的信息。 - -{{< copyable "sql" >}} - -```sql -CREATE TABLE test.t1 (a int); -``` - -``` -1 row in set (0.01 sec) -``` - -{{< copyable "sql" >}} - -```sql -SELECT * FROM information_schema.columns WHERE table_schema='test' AND TABLE_NAME='t1'; -``` - -``` -*************************** 1. row *************************** - TABLE_CATALOG: def - TABLE_SCHEMA: test - TABLE_NAME: t1 - COLUMN_NAME: a - ORDINAL_POSITION: 1 - COLUMN_DEFAULT: NULL - IS_NULLABLE: YES - DATA_TYPE: int -CHARACTER_MAXIMUM_LENGTH: NULL - CHARACTER_OCTET_LENGTH: NULL - NUMERIC_PRECISION: 11 - NUMERIC_SCALE: 0 - DATETIME_PRECISION: NULL - CHARACTER_SET_NAME: NULL - COLLATION_NAME: NULL - COLUMN_TYPE: int(11) - COLUMN_KEY: - EXTRA: - PRIVILEGES: select,insert,update,references - COLUMN_COMMENT: - GENERATION_EXPRESSION: -1 row in set (0.01 sec) -``` - -对应的 `SHOW` 语句如下： - -{{< copyable "sql" >}} - -```sql -SHOW COLUMNS FROM t1 FROM test; -``` - -``` -+-------+---------+------+------+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+-------+---------+------+------+---------+-------+ -| a | int(11) | YES | | NULL | | -+-------+---------+------+------+---------+-------+ -1 row in set (0.00 sec) -``` - -## ENGINES 表 - -`ENGINES` 表提供了关于存储引擎的信息。从和 MySQL 兼容性上考虑，TiDB 会一直将 InnoDB 描述为唯一支持的引擎。 - -{{< copyable "sql" >}} - -```sql -SELECT * FROM engines; -``` - -``` -*************************** 1. row *************************** - ENGINE: InnoDB - SUPPORT: DEFAULT - COMMENT: Supports transactions, row-level locking, and foreign keys -TRANSACTIONS: YES - XA: YES - SAVEPOINTS: YES -1 row in set (0.00 sec) -``` - -## KEY_COLUMN_USAGE 表 - -`KEY_COLUMN_USAGE` 表描述了列的键约束，比如主键约束。 - -{{< copyable "sql" >}} - -```sql -SELECT * FROM key_column_usage WHERE table_schema='mysql' and table_name='user'; -``` - -``` -*************************** 1. row *************************** - CONSTRAINT_CATALOG: def - CONSTRAINT_SCHEMA: mysql - CONSTRAINT_NAME: PRIMARY - TABLE_CATALOG: def - TABLE_SCHEMA: mysql - TABLE_NAME: user - COLUMN_NAME: Host - ORDINAL_POSITION: 1 -POSITION_IN_UNIQUE_CONSTRAINT: NULL - REFERENCED_TABLE_SCHEMA: NULL - REFERENCED_TABLE_NAME: NULL - REFERENCED_COLUMN_NAME: NULL -*************************** 2. row *************************** - CONSTRAINT_CATALOG: def - CONSTRAINT_SCHEMA: mysql - CONSTRAINT_NAME: PRIMARY - TABLE_CATALOG: def - TABLE_SCHEMA: mysql - TABLE_NAME: user - COLUMN_NAME: User - ORDINAL_POSITION: 2 -POSITION_IN_UNIQUE_CONSTRAINT: NULL - REFERENCED_TABLE_SCHEMA: NULL - REFERENCED_TABLE_NAME: NULL - REFERENCED_COLUMN_NAME: NULL -2 rows in set (0.00 sec) -``` - -## PROCESSLIST 表 - -`PROCESSLIST` 和 `show processlist` 的功能一样，都是查看当前正在处理的请求。 - -`PROCESSLIST` 表会比 `show processlist` 多一个 `MEM` 列，`MEM` 是指正在处理的请求已使用的内存，单位是 byte。 - -```sql -+----+------+------+--------------------+---------+------+-------+---------------------------+-----+ -| ID | USER | HOST | DB | COMMAND | TIME | STATE | INFO | MEM | -+----+------+------+--------------------+---------+------+-------+---------------------------+-----+ -| 1 | root | ::1 | INFORMATION_SCHEMA | Query | 0 | 2 | select * from PROCESSLIST | 0 | -+----+------+------+--------------------+---------+------+-------+---------------------------+-----+ -``` - -## SCHEMATA 表 - -`SCHEMATA` 表提供了关于数据库的信息。表中的数据与 `SHOW DATABASES` 语句的执行结果等价。 - -{{< copyable "sql" >}} - -```sql -SELECT * FROM schemata; -``` - -``` -+--------------+--------------------+----------------------------+------------------------+----------+ -| CATALOG_NAME | SCHEMA_NAME | DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME | SQL_PATH | -+--------------+--------------------+----------------------------+------------------------+----------+ -| def | INFORMATION_SCHEMA | utf8mb4 | utf8mb4_bin | NULL | -| def | mynewdb | utf8mb4 | utf8mb4_bin | NULL | -| def | mysql | utf8mb4 | utf8mb4_bin | NULL | -| def | PERFORMANCE_SCHEMA | utf8mb4 | utf8mb4_bin | NULL | -| def | test | utf8mb4 | utf8mb4_bin | NULL | -+--------------+--------------------+----------------------------+------------------------+----------+ -5 rows in set (0.00 sec) -``` - -## SESSION_VARIABLES 表 - -`SESSION_VARIABLES` 表提供了关于 session 变量的信息。表中的数据跟 `SHOW SESSION VARIABLES` 语句执行结果类似。 - -{{< copyable "sql" >}} - -```sql -SELECT * FROM session_variables LIMIT 10; -``` - -``` -+----------------------------------+----------------------+ -| VARIABLE_NAME | VARIABLE_VALUE | -+----------------------------------+----------------------+ -| max_write_lock_count | 18446744073709551615 | -| server_id_bits | 32 | -| net_read_timeout | 30 | -| innodb_online_alter_log_max_size | 134217728 | -| innodb_optimize_fulltext_only | OFF | -| max_join_size | 18446744073709551615 | -| innodb_read_io_threads | 4 | -| session_track_gtids | OFF | -| have_ssl | DISABLED | -| max_binlog_cache_size | 18446744073709547520 | -+----------------------------------+----------------------+ -10 rows in set (0.00 sec) -``` - -## SLOW_QUERY 表 - -`SLOW_QUERY` 表中提供了慢查询相关的信息，其内容通过解析 TiDB 慢查询日志而来，列名和慢日志中的字段名是一一对应。关于如何使用该表调查和改善慢查询请参考[慢查询日志文档](/dev/how-to/maintain/identify-abnormal-queries/identify-slow-queries.md)。 - -```sql -mysql> desc information_schema.slow_query; -+---------------+---------------------+------+------+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+---------------+---------------------+------+------+---------+-------+ -| Time | timestamp unsigned | YES | | NULL | | -| Txn_start_ts | bigint(20) unsigned | YES | | NULL | | -| User | varchar(64) | YES | | NULL | | -| Host | varchar(64) | YES | | NULL | | -| Conn_ID | bigint(20) unsigned | YES | | NULL | | -| Query_time | double unsigned | YES | | NULL | | -| Process_time | double unsigned | YES | | NULL | | -| Wait_time | double unsigned | YES | | NULL | | -| Backoff_time | double unsigned | YES | | NULL | | -| Request_count | bigint(20) unsigned | YES | | NULL | | -| Total_keys | bigint(20) unsigned | YES | | NULL | | -| Process_keys | bigint(20) unsigned | YES | | NULL | | -| DB | varchar(64) | YES | | NULL | | -| Index_ids | varchar(100) | YES | | NULL | | -| Is_internal | tinyint(1) unsigned | YES | | NULL | | -| Digest | varchar(64) | YES | | NULL | | -| Stats | varchar(512) | YES | | NULL | | -| Cop_proc_avg | double unsigned | YES | | NULL | | -| Cop_proc_p90 | double unsigned | YES | | NULL | | -| Cop_proc_max | double unsigned | YES | | NULL | | -| Cop_proc_addr | varchar(64) | YES | | NULL | | -| Cop_wait_avg | double unsigned | YES | | NULL | | -| Cop_wait_p90 | double unsigned | YES | | NULL | | -| Cop_wait_max | double unsigned | YES | | NULL | | -| Cop_wait_addr | varchar(64) | YES | | NULL | | -| Mem_max | bigint(20) unsigned | YES | | NULL | | -| Succ | tinyint(1) unsigned | YES | | NULL | | -| Query | longblob unsigned | YES | | NULL | | -+---------------+---------------------+------+------+---------+-------+ -``` - -## STATISTICS 表 - -`STATISTICS` 表提供了关于表索引的信息。 - -{{< copyable "sql" >}} - -```sql -desc statistics; -``` - -``` -+---------------|---------------------|------|------|---------|-------+ -| Field | Type | Null | Key | Default | Extra | -+---------------|---------------------|------|------|---------|-------+ -| TABLE_CATALOG | varchar(512) | YES | | NULL | | -| TABLE_SCHEMA | varchar(64) | YES | | NULL | | -| TABLE_NAME | varchar(64) | YES | | NULL | | -| NON_UNIQUE | varchar(1) | YES | | NULL | | -| INDEX_SCHEMA | varchar(64) | YES | | NULL | | -| INDEX_NAME | varchar(64) | YES | | NULL | | -| SEQ_IN_INDEX | bigint(2) UNSIGNED | YES | | NULL | | -| COLUMN_NAME | varchar(21) | YES | | NULL | | -| COLLATION | varchar(1) | YES | | NULL | | -| CARDINALITY | bigint(21) UNSIGNED | YES | | NULL | | -| SUB_PART | bigint(3) UNSIGNED | YES | | NULL | | -| PACKED | varchar(10) | YES | | NULL | | -| NULLABLE | varchar(3) | YES | | NULL | | -| INDEX_TYPE | varchar(16) | YES | | NULL | | -| COMMENT | varchar(16) | YES | | NULL | | -| INDEX_COMMENT | varchar(1024) | YES | | NULL | | -+---------------|---------------------|------|------|---------|-------+ -``` - -下列语句是等价的： - -{{< copyable "sql" >}} - -```sql -SELECT * FROM INFORMATION_SCHEMA.STATISTICS - WHERE table_name = 'tbl_name' - AND table_schema = 'db_name' -``` - -{{< copyable "sql" >}} - -```sql -SHOW INDEX - FROM tbl_name - FROM db_name -``` - -## TABLES 表 - -`TABLES` 表提供了数据库里面关于表的信息。 - -{{< copyable "sql" >}} - -```sql -SELECT * FROM tables WHERE table_schema='mysql' AND table_name='user'; -``` - -``` -*************************** 1. row *************************** - TABLE_CATALOG: def - TABLE_SCHEMA: mysql - TABLE_NAME: user - TABLE_TYPE: BASE TABLE - ENGINE: InnoDB - VERSION: 10 - ROW_FORMAT: Compact - TABLE_ROWS: 0 - AVG_ROW_LENGTH: 0 - DATA_LENGTH: 0 - MAX_DATA_LENGTH: 0 - INDEX_LENGTH: 0 - DATA_FREE: 0 - AUTO_INCREMENT: 0 - CREATE_TIME: 2019-03-29 09:17:27 - UPDATE_TIME: NULL - CHECK_TIME: NULL - TABLE_COLLATION: utf8mb4_bin - CHECKSUM: NULL - CREATE_OPTIONS: - TABLE_COMMENT: - TIDB_TABLE_ID: 5 -TIDB_ROW_ID_SHARDING_INFO: NULL -1 row in set (0.00 sec) -``` - -以下操作是等价的： - -{{< copyable "sql" >}} - -```sql -SELECT table_name FROM INFORMATION_SCHEMA.TABLES - WHERE table_schema = 'db_name' - [AND table_name LIKE 'wild'] -``` - -{{< copyable "sql" >}} - -```sql -SHOW TABLES - FROM db_name - [LIKE 'wild'] -``` - -表中的信息大部分定义自 MySQL，此外有两列是 TiDB 新增的： - -* `TIDB_TABLE_ID`：标识表的内部 ID，该 ID 在一个 TiDB 集群内部唯一。 -* `TIDB_ROW_ID_SHARDING_INFO`：标识表的 Sharding 类型，可能的值为： - - `"NOT_SHARDED"`：表未被 Shard。 - - `"NOT_SHARDED(PK_IS_HANDLE)"`：一个定义了整型主键的表未被 Shard。 - - `"PK_AUTO_RANDOM_BITS={bit_number}"`：一个定义了整型主键的表由于定义了 `AUTO_RANDOM` 而被 Shard。 - - `"SHARD_BITS={bit_number}"`：表使用 `SHARD_ROW_ID_BITS={bit_number}` 进行了 Shard。 - - NULL：表属于系统表或 View，无法被 Shard。 - -## TABLE_CONSTRAINTS 表 - -`TABLE_CONSTRAINTS` 表记录了表的约束信息。 - -{{< copyable "sql" >}} - -```sql -SELECT * FROM table_constraints WHERE constraint_type='UNIQUE'; -``` - -``` -*************************** 1. row *************************** -CONSTRAINT_CATALOG: def - CONSTRAINT_SCHEMA: mysql - CONSTRAINT_NAME: name - TABLE_SCHEMA: mysql - TABLE_NAME: help_topic - CONSTRAINT_TYPE: UNIQUE -*************************** 2. row *************************** -CONSTRAINT_CATALOG: def - CONSTRAINT_SCHEMA: mysql - CONSTRAINT_NAME: tbl - TABLE_SCHEMA: mysql - TABLE_NAME: stats_meta - CONSTRAINT_TYPE: UNIQUE -*************************** 3. row *************************** -CONSTRAINT_CATALOG: def - CONSTRAINT_SCHEMA: mysql - CONSTRAINT_NAME: tbl - TABLE_SCHEMA: mysql - TABLE_NAME: stats_histograms - CONSTRAINT_TYPE: UNIQUE -*************************** 4. row *************************** -CONSTRAINT_CATALOG: def - CONSTRAINT_SCHEMA: mysql - CONSTRAINT_NAME: tbl - TABLE_SCHEMA: mysql - TABLE_NAME: stats_buckets - CONSTRAINT_TYPE: UNIQUE -*************************** 5. row *************************** -CONSTRAINT_CATALOG: def - CONSTRAINT_SCHEMA: mysql - CONSTRAINT_NAME: delete_range_index - TABLE_SCHEMA: mysql - TABLE_NAME: gc_delete_range - CONSTRAINT_TYPE: UNIQUE -*************************** 6. row *************************** -CONSTRAINT_CATALOG: def - CONSTRAINT_SCHEMA: mysql - CONSTRAINT_NAME: delete_range_done_index - TABLE_SCHEMA: mysql - TABLE_NAME: gc_delete_range_done - CONSTRAINT_TYPE: UNIQUE -6 rows in set (0.00 sec) -``` - -其中： - -* `CONSTRAINT_TYPE` 的取值可以是 `UNIQUE`，`PRIMARY KEY`，或者 `FOREIGN KEY`。 -* `UNIQUE` 和 `PRIMARY KEY` 信息与 `SHOW INDEX` 语句的执行结果类似。 - -## TIDB_HOT_REGIONS 表 - -`TIDB_HOT_REGIONS` 表提供了关于热点 REGION 的相关信息。 - -{{< copyable "sql" >}} - -```sql -desc TIDB_HOT_REGIONS; -``` - -``` -+----------------+---------------------+------+-----+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+----------------+---------------------+------+-----+---------+-------+ -| TABLE_ID | bigint(21) unsigned | YES | | | | -| INDEX_ID | bigint(21) unsigned | YES | | | | -| DB_NAME | varchar(64) | YES | | | | -| TABLE_NAME | varchar(64) | YES | | | | -| INDEX_NAME | varchar(64) | YES | | | | -| TYPE | varchar(64) | YES | | | | -| MAX_HOT_DEGREE | bigint(21) unsigned | YES | | | | -| REGION_COUNT | bigint(21) unsigned | YES | | | | -| FLOW_BYTES | bigint(21) unsigned | YES | | | | -+----------------+---------------------+------+-----+---------+-------+ -``` - -## TIDB_INDEXES 表 - -`TIDB_INDEXES` 记录了所有表中的 INDEX 信息。 - -{{< copyable "sql" >}} - -```sql -desc TIDB_INDEXES; -``` - -``` -+---------------+---------------------+------+-----+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+---------------+---------------------+------+-----+---------+-------+ -| TABLE_SCHEMA | varchar(64) | YES | | | | -| TABLE_NAME | varchar(64) | YES | | | | -| NON_UNIQUE | bigint(21) unsigned | YES | | | | -| KEY_NAME | varchar(64) | YES | | | | -| SEQ_IN_INDEX | bigint(21) unsigned | YES | | | | -| COLUMN_NAME | varchar(64) | YES | | | | -| SUB_PART | bigint(21) unsigned | YES | | | | -| INDEX_COMMENT | varchar(2048) | YES | | | | -| INDEX_ID | bigint(21) unsigned | YES | | | | -+---------------+---------------------+------+-----+---------+-------+ -``` - -## TIKV_REGION_PEERS 表 - -`TIKV_REGION_PEERS` 表提供了所有 REGION 的 peer 信息。 - -{{< copyable "sql" >}} - -```sql -desc TIKV_REGION_PEERS; -``` - -``` -+--------------+---------------------+------+-----+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+--------------+---------------------+------+-----+---------+-------+ -| REGION_ID | bigint(21) unsigned | YES | | | | -| PEER_ID | bigint(21) unsigned | YES | | | | -| STORE_ID | bigint(21) unsigned | YES | | | | -| IS_LEARNER | tinyint(1) unsigned | YES | | | | -| IS_LEADER | tinyint(1) unsigned | YES | | | | -| STATUS | varchar(10) | YES | | | | -| DOWN_SECONDS | bigint(21) unsigned | YES | | | | -+--------------+---------------------+------+-----+---------+-------+ -``` - -## TIKV_REGION_STATUS 表 - -`TIKV_REGION_STATUS` 表提供了所有 REGION 的状态信息。 - -{{< copyable "sql" >}} - -```sql -desc TIKV_REGION_STATUS; -``` - -``` -+------------------+---------------------+------+-----+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+------------------+---------------------+------+-----+---------+-------+ -| REGION_ID | bigint(21) unsigned | YES | | | | -| START_KEY | text | YES | | | | -| END_KEY | text | YES | | | | -| EPOCH_CONF_VER | bigint(21) unsigned | YES | | | | -| EPOCH_VERSION | bigint(21) unsigned | YES | | | | -| WRITTEN_BYTES | bigint(21) unsigned | YES | | | | -| READ_BYTES | bigint(21) unsigned | YES | | | | -| APPROXIMATE_SIZE | bigint(21) unsigned | YES | | | | -| APPROXIMATE_KEYS | bigint(21) unsigned | YES | | | | -+------------------+---------------------+------+-----+---------+-------+ -``` - -## TIKV_STORE_STATUS 表 - -`TIKV_STORE_STATUS` 表提供了所有 TiKV Store 的状态信息。 - -{{< copyable "sql" >}} - -```sql -desc TIKV_STORE_STATUS; -``` - -``` -+-------------------+---------------------+------+-----+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+-------------------+---------------------+------+-----+---------+-------+ -| STORE_ID | bigint(21) unsigned | YES | | | | -| ADDRESS | varchar(64) | YES | | | | -| STORE_STATE | bigint(21) unsigned | YES | | | | -| STORE_STATE_NAME | varchar(64) | YES | | | | -| LABEL | json unsigned | YES | | | | -| VERSION | varchar(64) | YES | | | | -| CAPACITY | varchar(64) | YES | | | | -| AVAILABLE | varchar(64) | YES | | | | -| LEADER_COUNT | bigint(21) unsigned | YES | | | | -| LEADER_WEIGHT | bigint(21) unsigned | YES | | | | -| LEADER_SCORE | bigint(21) unsigned | YES | | | | -| LEADER_SIZE | bigint(21) unsigned | YES | | | | -| REGION_COUNT | bigint(21) unsigned | YES | | | | -| REGION_WEIGHT | bigint(21) unsigned | YES | | | | -| REGION_SCORE | bigint(21) unsigned | YES | | | | -| REGION_SIZE | bigint(21) unsigned | YES | | | | -| START_TS | datetime unsigned | YES | | | | -| LAST_HEARTBEAT_TS | datetime unsigned | YES | | | | -| UPTIME | varchar(64) | YES | | | | -+-------------------+---------------------+------+-----+---------+-------+ -``` - -## USER_PRIVILEGES 表 - -`USER_PRIVILEGES` 表提供了关于全局权限的信息。该表的数据根据 `mysql.user` 系统表生成。 - -{{< copyable "sql" >}} - -```sql -desc USER_PRIVILEGES; -``` - -``` -+----------------|--------------|------|------|---------|-------+ -| Field | Type | Null | Key | Default | Extra | -+----------------|--------------|------|------|---------|-------+ -| GRANTEE | varchar(81) | YES | | NULL | | -| TABLE_CATALOG | varchar(512) | YES | | NULL | | -| PRIVILEGE_TYPE | varchar(64) | YES | | NULL | | -| IS_GRANTABLE | varchar(3) | YES | | NULL | | -+----------------|--------------|------|------|---------|-------+ -4 rows in set (0.00 sec) -``` - -## VIEWS 表 - -`VIEWS` 表提供了关于 SQL 视图的信息。 - -{{< copyable "sql" >}} - -```sql -create view test.v1 as select 1; -``` - -``` -Query OK, 0 rows affected (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -select * from views; -``` - -``` -*************************** 1. row *************************** - TABLE_CATALOG: def - TABLE_SCHEMA: test - TABLE_NAME: v1 - VIEW_DEFINITION: select 1 - CHECK_OPTION: CASCADED - IS_UPDATABLE: NO - DEFINER: root@127.0.0.1 - SECURITY_TYPE: DEFINER -CHARACTER_SET_CLIENT: utf8 -COLLATION_CONNECTION: utf8_general_ci -1 row in set (0.00 sec) -``` - -## 不支持的 Information Schema 表 - -TiDB 包含以下 `INFORMATION_SCHEMA` 表，但仅会返回空行： - -* `COLUMN_PRIVILEGES` -* `EVENTS` -* `FILES` -* `GLOBAL_STATUS` -* `GLOBAL_VARIABLES` -* `OPTIMIZER_TRACE` -* `PARAMETERS` -* `PARTITIONS` -* `PLUGINS` -* `PROFILING` -* `REFERENTIAL_CONSTRAINTS` -* `ROUTINES` -* `SCHEMA_PRIVILEGES` -* `SESSION_STATUS` -* `TABLESPACES` -* `TABLE_PRIVILEGES` -* `TRIGGERS` diff --git a/dev/reference/system-databases/mysql.md b/dev/reference/system-databases/mysql.md deleted file mode 100644 index 57e26eb07952..000000000000 --- a/dev/reference/system-databases/mysql.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: TiDB 系统表 -category: reference ---- - -# TiDB 系统表 - -本文档主要介绍 TiDB 支持的系统表。 - -## 权限系统表 - -这些系统表里面包含了用户账户以及相应的授权信息： - -* `user` 用户账户，全局权限，以及其它一些非权限的列 -* `db` 数据库级别的权限 -* `tables_priv` 表级的权限 -* `columns_priv` 列级的权限 - -## 服务端帮助信息系统表 - -* `help_topic` 目前为空 - -## 统计信息相关系统表 - -* `stats_buckets` 统计信息的桶 -* `stats_histograms` 统计信息的直方图 -* `stats_meta` 表的元信息，比如总行数和修改数 - -## GC Worker 相关系统表 - -* `gc_delete_range` - -## 其它系统表 - -* `GLOBAL_VARIABLES` 全局系统变量表 -* `tidb` 用于 TiDB 在 bootstrap 的时候记录相关版本信息 diff --git a/dev/reference/tidb-binlog/binlog-slave-client.md b/dev/reference/tidb-binlog/binlog-slave-client.md deleted file mode 100644 index b0e46856c570..000000000000 --- a/dev/reference/tidb-binlog/binlog-slave-client.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -title: Binlog Slave Client 用户文档 -category: reference -aliases: ['/docs-cn/dev/reference/tools/tidb-binlog/binlog-slave-client/'] ---- - -# Binlog Slave Client 用户文档 - -目前 Drainer 提供了多种输出方式，包括 MySQL、TiDB、file 等。但是用户往往有一些自定义的需求，比如输出到 Elasticsearch、Hive 等，这些需求 Drainer 现在还没有实现，因此 Drainer 增加了输出到 Kafka 的功能，将 binlog 数据解析后按一定的格式再输出到 Kafka 中，用户编写代码从 Kafka 中读出数据再进行处理。 - -## 配置 Kafka Drainer - -修改 Drainer 的配置文件，设置输出为 Kafka，相关配置如下： - -``` -[syncer] -db-type = "kafka" - -[syncer.to] -# Kafka 地址 -kafka-addrs = "127.0.0.1:9092" -# Kafka 版本号 -kafka-version = "0.8.2.0" -``` - -## 自定义开发 - -### 数据格式 - -首先需要了解 Drainer 写入到 Kafka 中的数据格式： - -``` -// Column 保存列的数据，针对数据的类型，保存在对应的变量中 -message Column { - // 数据是否为 null - optional bool is_null = 1 [ default = false ]; - // 保存 int 类型的数据 - optional int64 int64_value = 2; - // 保存 uint、enum, set 类型的数据 - optional uint64 uint64_value = 3; - // 保存 float、double 类型的数据 - optional double double_value = 4; - // 保存 bit、blob、binary、json 类型的数据 - optional bytes bytes_value = 5; - // 保存 date、time、decimal、text、char 类型的数据 - optional string string_value = 6; -} - -// ColumnInfo 保存列的信息，包括列名、类型、是否为主键 -message ColumnInfo { - optional string name = 1 [ (gogoproto.nullable) = false ]; - // MySQL 中小写的列字段类型 - // https://dev.mysql.com/doc/refman/8.0/en/data-types.html - // numeric 类型：int bigint smallint tinyint float double decimal bit - // string 类型：text longtext mediumtext char tinytext varchar - // blob longblob mediumblob binary tinyblob varbinary - // enum set - // json 类型：json - optional string mysql_type = 2 [ (gogoproto.nullable) = false ]; - optional bool is_primary_key = 3 [ (gogoproto.nullable) = false ]; -} - -// Row 保存一行的具体数据 -message Row { repeated Column columns = 1; } - -// MutationType 表示 DML 的类型 -enum MutationType { - Insert = 0; - Update = 1; - Delete = 2; -} - -// Table 包含一个表的数据变更 -message Table { - optional string schema_name = 1; - optional string table_name = 2; - repeated ColumnInfo column_info = 3; - repeated TableMutation mutations = 4; -} - -// TableMutation 保存一行数据的变更 -message TableMutation { - required MutationType type = 1; - // 修改后的数据 - required Row row = 2; - // 修改前的数据，只对 Update MutationType 有效 - optional Row change_row = 3; -} - -// DMLData 保存一个事务所有的 DML 造成的数据变更 -message DMLData { - // `tables` 包含事务中所有表的数据变更 - repeated Table tables = 1; -} - -// DDLData 保存 DDL 的信息 -message DDLData { - // 当前使用的数据库 - optional string schema_name = 1; - // 相关表 - optional string table_name = 2; - // `ddl_query` 是原始的 DDL 语句 query - optional bytes ddl_query = 3; -} - -// BinlogType 为 Binlog 的类型，分为 DML 和 DDL -enum BinlogType { - DML = 0; // Has `dml_data` - DDL = 1; // Has `ddl_query` -} - -// Binlog 保存一个事务所有的变更，Kafka 中保存的数据为该结构数据序列化后的结果 -message Binlog { - optional BinlogType type = 1 [ (gogoproto.nullable) = false ]; - optional int64 commit_ts = 2 [ (gogoproto.nullable) = false ]; - optional DMLData dml_data = 3; - optional DDLData ddl_data = 4; -} -``` - -查看数据格式的具体定义，参见 [binlog.proto](https://github.com/pingcap/tidb-tools/blob/master/tidb-binlog/slave_binlog_proto/proto/binlog.proto)。 - -### Driver - -TiDB-Tools 项目提供了用于读取 Kafka 中 binlog 数据的 Driver，具有如下功能： - -* 读取 Kafka 的数据 -* 根据 commit ts 查找 binlog 在 kafka 中的储存位置 - -使用该 Driver 时，用户需要配置如下信息： - -* KafkaAddr：Kafka 集群的地址 -* CommitTS：从哪个 commit ts 开始读取 binlog -* Offset：从 Kafka 哪个 offset 开始读取，如果设置了 CommitTS 就不用配置该参数 -* ClusterID：TiDB 集群的 cluster ID -* Topic: Kafka Topic 名称，如果 Topic 名称为空，将会使用 drainer _obinlog 中的默认名称 - -用户以包的形式引用 Driver 的代码即可使用，可以参考 Driver 中提供的示例代码来学习如何使用 Driver 以及 binlog 数据的解析，目前提供了两个例子： - -* 使用该 Driver 将数据同步到 MySQL，该示例包含将 binlog 转化为 SQL 的具体方法 -* 使用该 Driver 将数据打印出来 - -Driver 项目地址：[Binlog Slave Driver](https://github.com/pingcap/tidb-tools/tree/master/tidb-binlog/driver)。 - -> **注意：** -> -> - 示例代码仅仅用于示范如何使用 Driver，如果需要用于生产环境需要优化代码。 -> - 目前仅提供了 golang 版本的 Driver 以及示例代码。如果需要使用其他语言，用户需要根据 binlog 的 proto 文件生成相应语言的代码文件，并自行开发程序读取 Kafka 中的 binlog 数据、解析数据、输出到下游。也欢迎用户优化 example 代码，以及提交其他语言的示例代码到 [TiDB-Tools](https://github.com/pingcap/tidb-tools)。 diff --git a/dev/reference/tidb-binlog/deploy.md b/dev/reference/tidb-binlog/deploy.md deleted file mode 100644 index 5a0806b4c40c..000000000000 --- a/dev/reference/tidb-binlog/deploy.md +++ /dev/null @@ -1,629 +0,0 @@ ---- -title: TiDB Binlog 集群部署 -category: reference -aliases: ['/docs-cn/dev/how-to/deploy/tidb-binlog/','/docs-cn/dev/reference/tools/tidb-binlog/deploy/'] ---- - -# TiDB Binlog 集群部署 - -## 服务器要求 - -Pump 和 Drainer 均可部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器平台上。在开发、测试和生产环境下，对服务器硬件配置的要求和建议如下： - -| 服务 | 部署数量 | CPU | 磁盘 | 内存 | -| :-------- | :-------- | :--------| :--------------- | :------ | -| Pump | 3 | 8核+ | SSD, 200 GB+ | 16G | -| Drainer | 1 | 8核+ | SAS, 100 GB+ （如果输出 binlog 为本地文件，磁盘大小视保留数据天数而定） | 16G | - -## 使用 TiDB Ansible 部署 TiDB Binlog - -### 第 1 步：下载 TiDB Ansible - -1. 以 TiDB 用户登录中控机并进入 `/home/tidb` 目录。以下为 TiDB Ansible 分支与 TiDB 版本的对应关系，版本选择可咨询官方 info@pingcap.com。 - - | TiDB Ansible 分支 | TiDB 版本 | 备注 | - | ---------------- | --------- | --- | - | master | master 版本 | 包含最新特性，每日更新。 | - -2. 使用以下命令从 GitHub [TiDB Ansible 项目](https://github.com/pingcap/tidb-ansible)上下载 TiDB Ansible 相应分支，默认的文件夹名称为 `tidb-ansible`。 - - - 下载 master 版本： - - {{< copyable "shell-regular" >}} - - ```bash - git clone https://github.com/pingcap/tidb-ansible.git - ``` - -### 第 2 步：部署 Pump - -1. 修改 tidb-ansible/inventory.ini 文件 - - 1. 设置 `enable_binlog = True`，表示 TiDB 集群开启 binlog。 - - ```ini - ## binlog trigger - enable_binlog = True - ``` - - 2. 为 `pump_servers` 主机组添加部署机器 IP。 - - ```ini - ## Binlog Part - [pump_servers] - 172.16.10.72 - 172.16.10.73 - 172.16.10.74 - ``` - - 默认 Pump 保留 7 天数据，如需修改可修改 `tidb-ansible/conf/pump.yml`（TiDB 3.0.0~3.0.2 版本中为 `tidb-ansible/conf/pump-cluster.yml`）文件中 `gc` 变量值，并取消注释。 - - {{< copyable "" >}} - - ```yaml - global: - # an integer value to control the expiry date of the binlog data, which indicates for how long (in days) the binlog data would be stored - # must be bigger than 0 - # gc: 7 - ``` - - 请确保部署目录有足够空间存储 binlog，详见[调整部署目录](/dev/how-to/deploy/orchestrated/ansible.md#调整部署目录)，也可为 Pump 设置单独的部署目录。 - - ```ini - ## Binlog Part - [pump_servers] - pump1 ansible_host=172.16.10.72 deploy_dir=/data1/pump - pump2 ansible_host=172.16.10.73 deploy_dir=/data2/pump - pump3 ansible_host=172.16.10.74 deploy_dir=/data3/pump - ``` - -2. 部署并启动含 Pump 组件的 TiDB 集群 - - 参照上文配置完 `inventory.ini` 文件后，从以下两种方式中选择一种进行部署。 - - **方式一**：在已有的 TiDB 集群上增加 Pump 组件，需按以下步骤逐步进行。 - - 1. 部署 pump_servers 和 node_exporters - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook deploy.yml --tags=pump -l ${pump1_ip},${pump2_ip},[${alias1_name},${alias2_name}] - ``` - - > **注意：** - > - > 以上命令中，逗号后不要加空格，否则会报错。 - - 2. 启动 pump_servers - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook start.yml --tags=pump - ``` - - 3. 更新并重启 tidb_servers - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update.yml --tags=tidb - ``` - - 4. 更新监控信息 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update_monitor.yml --tags=prometheus - ``` - - **方式二**：从零开始部署含 Pump 组件的 TiDB 集群 - - 使用 Ansible 部署 TiDB 集群，方法参考 [使用 TiDB Ansible 部署 TiDB 集群](/dev/how-to/deploy/orchestrated/ansible.md)。 - -3. 查看 Pump 服务状态 - - 使用 binlogctl 查看 Pump 服务状态，pd-urls 参数请替换为集群 PD 地址，结果 State 为 online 表示 Pump 启动成功。 - - {{< copyable "shell-regular" >}} - - ```bash - cd /home/tidb/tidb-ansible && - resources/bin/binlogctl -pd-urls=http://172.16.10.72:2379 -cmd pumps - ``` - - ``` - INFO[0000] pump: {NodeID: ip-172-16-10-72:8250, Addr: 172.16.10.72:8250, State: online, MaxCommitTS: 403051525690884099, UpdateTime: 2018-12-25 14:23:37 +0800 CST} - INFO[0000] pump: {NodeID: ip-172-16-10-73:8250, Addr: 172.16.10.73:8250, State: online, MaxCommitTS: 403051525703991299, UpdateTime: 2018-12-25 14:23:36 +0800 CST} - INFO[0000] pump: {NodeID: ip-172-16-10-74:8250, Addr: 172.16.10.74:8250, State: online, MaxCommitTS: 403051525717360643, UpdateTime: 2018-12-25 14:23:35 +0800 CST} - ``` - -### 第 3 步：部署 Drainer - -1. 获取 initial_commit_ts 的值 - - Drainer 初次启动时需要获取 initial_commit_ts 这个时间戳信息。 - - - 如果从最近的时间点开始同步，initial_commit_ts 使用 `-1` 即可。 - - - 如果下游为 MySQL 或 TiDB，为了保证数据的完整性，需要进行全量数据的备份与恢复。此时 initial_commit_ts 的值必须是全量备份的时间戳。 - - 如果使用 mydumper 进行全量备份，可以在导出目录中找到 metadata 文件，其中的 `Pos` 字段值即全量备份的时间戳。metadata 文件示例如下： - - ``` - Started dump at: 2019-12-30 13:25:41 - SHOW MASTER STATUS: - Log: tidb-binlog - Pos: 413580274257362947 - GTID: - - Finished dump at: 2019-12-30 13:25:41 - ``` - -2. 修改 `tidb-ansible/inventory.ini` 文件 - - 为 `drainer_servers` 主机组添加部署机器 IP，initial_commit_ts 请设置为获取的 initial_commit_ts，仅用于 Drainer 第一次启动。 - - - 以下游为 MySQL 为例，别名为 `drainer_mysql`。 - - ```ini - [drainer_servers] - drainer_mysql ansible_host=172.16.10.71 initial_commit_ts="402899541671542785" - ``` - - - 以下游为 file 为例，别名为 `drainer_file`。 - - ```ini - [drainer_servers] - drainer_file ansible_host=172.16.10.71 initial_commit_ts="402899541671542785" - ``` - -3. 修改配置文件 - - - 以下游为 MySQL 为例 - - {{< copyable "shell-regular" >}} - - ```bash - cd /home/tidb/tidb-ansible/conf && - cp drainer.toml drainer_mysql_drainer.toml && - vi drainer_mysql_drainer.toml - ``` - - > **注意：** - > - > 配置文件名命名规则为 `别名_drainer.toml`，否则部署时无法找到自定义配置文件。 - - db-type 设置为 "mysql"， 配置下游 MySQL 信息。 - - {{< copyable "" >}} - - ```toml - [syncer] - # downstream storage, equal to --dest-db-type - # Valid values are "mysql", "file", "tidb", "kafka". - db-type = "mysql" - - # the downstream MySQL protocol database - [syncer.to] - host = "172.16.10.72" - user = "root" - password = "123456" - port = 3306 - ``` - - - 以下游为增量备份文件为例 - - {{< copyable "shell-regular" >}} - - ```bash - cd /home/tidb/tidb-ansible/conf && - cp drainer.toml drainer_file_drainer.toml && - vi drainer_file_drainer.toml - ``` - - db-type 设置为 "file"。 - - {{< copyable "" >}} - - ```toml - [syncer] - # downstream storage, equal to --dest-db-type - # Valid values are "mysql", "file", "tidb", "kafka". - db-type = "file" - - # Uncomment this if you want to use "file" as "db-type". - [syncer.to] - # default data directory: "{{ deploy_dir }}/data.drainer" - dir = "data.drainer" - ``` - -4. 部署 Drainer - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook deploy_drainer.yml - ``` - -5. 启动 Drainer - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook start_drainer.yml - ``` - -## 使用 Binary 部署 TiDB Binlog - -### 下载官方 Binary - -{{< copyable "shell-regular" >}} - -```bash -wget https://download.pingcap.org/tidb-{version}-linux-amd64.tar.gz && -wget https://download.pingcap.org/tidb-{version}-linux-amd64.sha256 -``` - -检查文件完整性，返回 ok 则正确： - -{{< copyable "shell-regular" >}} - -```bash -sha256sum -c tidb-{version}-linux-amd64.sha256 -``` - -对于 v2.1.0 GA 及以上版本，Pump 和 Drainer 已经包含在 TiDB 的下载包中，其他版本需要单独下载 Pump 和 Drainer: - -{{< copyable "shell-regular" >}} - -```bash -wget https://download.pingcap.org/tidb-binlog-latest-linux-amd64.tar.gz && -wget https://download.pingcap.org/tidb-binlog-latest-linux-amd64.sha256 -``` - -检查文件完整性，返回 ok 则正确： - -{{< copyable "shell-regular" >}} - -```bash -sha256sum -c tidb-binlog-latest-linux-amd64.sha256 -``` - -### 使用样例 - -假设有三个 PD，一个 TiDB，另外有两台机器用于部署 Pump，一台机器用于部署 Drainer。各个节点信息如下： - -``` -TiDB="192.168.0.10" -PD1="192.168.0.16" -PD2="192.168.0.15" -PD3="192.168.0.14" -Pump="192.168.0.11" -Pump="192.168.0.12" -Drainer="192.168.0.13" -``` - -下面以此为例，说明 Pump/Drainer 的使用。 - -1. 使用 binary 部署 Pump - - - Pump 命令行参数说明（以在 “192.168.0.11” 上部署为例） - - ```bash - Usage of Pump: - -L string - 日志输出信息等级设置：debug，info，warn，error，fatal (默认 "info") - -V - 打印版本信息 - -addr string - Pump 提供服务的 RPC 地址(-addr="192.168.0.11:8250") - -advertise-addr string - Pump 对外提供服务的 RPC 地址(-advertise-addr="192.168.0.11:8250") - -config string - 配置文件路径，如果你指定了配置文件，Pump 会首先读取配置文件的配置; - 如果对应的配置在命令行参数里面也存在，Pump 就会使用命令行参数的配置来覆盖配置文件里的配置。 - -data-dir string - Pump 数据存储位置路径 - -gc int - Pump 只保留多少天以内的数据 (默认 7) - -heartbeat-interval int - Pump 向 PD 发送心跳间隔 (单位 秒) - -log-file string - log 文件路径 - -log-rotate string - log 文件切换频率，hour/day - -metrics-addr string - Prometheus Pushgateway 地址，不设置则禁止上报监控信息 - -metrics-interval int - 监控信息上报频率 (默认 15，单位 秒) - -node-id string - Pump 节点的唯一识别 ID，如果不指定，程序会根据主机名和监听端口自动生成 - -pd-urls string - PD 集群节点的地址 (-pd-urls="http://192.168.0.16:2379,http://192.168.0.15:2379,http://192.168.0.14:2379") - -fake-binlog-interval int - Pump 节点生成 fake binlog 的频率 (默认 3，单位 秒) - ``` - - - Pump 配置文件（以在 “192.168.0.11” 上部署为例） - - ```toml - # Pump Configuration - - # Pump 绑定的地址 - addr = "192.168.0.11:8250" - - # Pump 对外提供服务的地址 - advertise-addr = "192.168.0.11:8250" - - # Pump 只保留多少天以内的数据 (默认 7) - gc = 7 - - # Pump 数据存储位置路径 - data-dir = "data.pump" - - # Pump 向 PD 发送心跳的间隔 (单位 秒) - heartbeat-interval = 2 - - # PD 集群节点的地址 (英文逗号分割，中间不加空格) - pd-urls = "http://192.168.0.16:2379,http://192.168.0.15:2379,http://192.168.0.14:2379" - - # [security] - # 如无特殊安全设置需要，该部分一般都注解掉 - # 包含与集群连接的受信任 SSL CA 列表的文件路径 - # ssl-ca = "/path/to/ca.pem" - # 包含与集群连接的 PEM 形式的 X509 certificate 的路径 - # ssl-cert = "/path/to/drainer.pem" - # 包含与集群链接的 PEM 形式的 X509 key 的路径 - # ssl-key = "/path/to/drainer-key.pem" - - # [storage] - # 设置为 true（默认值）来保证可靠性，确保 binlog 数据刷新到磁盘 - # sync-log = true - - # 当可用磁盘容量小于该设置值时，Pump 将停止写入数据 - # 42 MB -> 42000000, 42 mib -> 44040192 - # default: 10 gib - # stop-write-at-available-space = "10 gib" - - # Pump 内嵌的 LSM DB 设置，除非对该部分很了解，否则一般注解掉 - # [storage.kv] - # block-cache-capacity = 8388608 - # block-restart-interval = 16 - # block-size = 4096 - # compaction-L0-trigger = 8 - # compaction-table-size = 67108864 - # compaction-total-size = 536870912 - # compaction-total-size-multiplier = 8.0 - # write-buffer = 67108864 - # write-L0-pause-trigger = 24 - # write-L0-slowdown-trigger = 17 - ``` - - - 启动示例 - - {{< copyable "shell-regular" >}} - - ```bash - ./bin/pump -config pump.toml - ``` - - 如果命令行参数与配置文件中的参数重合，则使用命令行设置的参数的值。 - -2. 使用 binary 部署 Drainer - - - Drainer 命令行参数说明（以在 “192.168.0.13” 上部署为例） - - ```bash - Usage of Drainer - -L string - 日志输出信息等级设置：debug，info，warn，error，fatal (默认 "info") - -V - 打印版本信息 - -addr string - Drainer 提供服务的地址(-addr="192.168.0.13:8249") - -c int - 同步下游的并发数，该值设置越高同步的吞吐性能越好 (default 1) - -cache-binlog-count int - 缓存中的 binlog 数目限制（默认 8） - 如果上游的单个 binlog 较大导致 Drainer 出现 OOM 时，可尝试调小该值减少内存使用 - -config string - 配置文件路径，Drainer 会首先读取配置文件的配置； - 如果对应的配置在命令行参数里面也存在，Drainer 就会使用命令行参数的配置来覆盖配置文件里面的配置 - -data-dir string - Drainer 数据存储位置路径 (默认 "data.drainer") - -dest-db-type string - Drainer 下游服务类型 (默认为 mysql，支持 tidb、kafka、file) - -detect-interval int - 向 PD 查询在线 Pump 的时间间隔 (默认 10，单位 秒) - -disable-detect - 是否禁用冲突监测 - -disable-dispatch - 是否禁用拆分单个 binlog 的 SQL 的功能，如果设置为 true，则每个 binlog - 按顺序依次还原成单个事务进行同步（下游服务类型为 MySQL，该项设置为 False） - -ignore-schemas string - db 过滤列表 (默认 "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql,test")， - 不支持对 ignore schemas 的 table 进行 rename DDL 操作 - -initial-commit-ts（默认为 `-1`） - 如果 Drainer 没有相关的断点信息，可以通过该项来设置相关的断点信息 - 该参数值为 `-1` 时，Drainer 会自动从 PD 获取一个最新的时间戳 - -log-file string - log 文件路径 - -log-rotate string - log 文件切换频率，hour/day - -metrics-addr string - Prometheus Pushgateway 地址，不设置则禁止上报监控信息 - -metrics-interval int - 监控信息上报频率（默认 15，单位：秒） - -node-id string - drainer 节点的唯一识别 ID，如果不指定，程序会根据主机名和监听端口自动生成 - -pd-urls string - PD 集群节点的地址 (-pd-urls="http://192.168.0.16:2379,http://192.168.0.15:2379,http://192.168.0.14:2379") - -safe-mode - 是否开启安全模式使得下游 MySQL/TiDB 可被重复写入 - 即将 insert 语句换为 replace 语句，将 update 语句拆分为 delete + replace 语句 - -txn-batch int - 输出到下游数据库一个事务的 SQL 数量（默认 1） - ``` - - - Drainer 配置文件（以在 “192.168.0.13” 上部署为例） - - ```toml - # Drainer Configuration. - - # Drainer 提供服务的地址("192.168.0.13:8249") - addr = "192.168.0.13:8249" - - # Drainer 对外提供服务的地址 - advertise-addr = "192.168.0.13:8249" - - # 向 PD 查询在线 Pump 的时间间隔 (默认 10，单位 秒) - detect-interval = 10 - - # Drainer 数据存储位置路径 (默认 "data.drainer") - data-dir = "data.drainer" - - # PD 集群节点的地址 (英文逗号分割，中间不加空格) - pd-urls = "http://192.168.0.16:2379,http://192.168.0.15:2379,http://192.168.0.14:2379" - - # log 文件路径 - log-file = "drainer.log" - - # Drainer 从 Pump 获取 binlog 时对数据进行压缩，值可以为 "gzip"，如果不配置则不进行压缩 - # compressor = "gzip" - - # [security] - # 如无特殊安全设置需要，该部分一般都注解掉 - # 包含与集群连接的受信任 SSL CA 列表的文件路径 - # ssl-ca = "/path/to/ca.pem" - # 包含与集群连接的 PEM 形式的 X509 certificate 的路径 - # ssl-cert = "/path/to/pump.pem" - # 包含与集群链接的 PEM 形式的 X509 key 的路径 - # ssl-key = "/path/to/pump-key.pem" - - # Syncer Configuration - [syncer] - # 如果设置了该项，会使用该 sql-mode 解析 DDL 语句，此时如果下游是 MySQL 或 TiDB 则 - # 下游的 sql-mode 也会被设置为该值 - # sql-mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION" - - # 输出到下游数据库一个事务的 SQL 语句数量 (默认 20) - txn-batch = 20 - - # 同步下游的并发数，该值设置越高同步的吞吐性能越好 (默认 16) - worker-count = 16 - - # 是否禁用拆分单个 binlog 的 SQL 的功能，如果设置为 true，则按照每个 binlog - # 顺序依次还原成单个事务进行同步（下游服务类型为 MySQL, 该项设置为 False） - disable-dispatch = false - - # safe mode 会使写下游 MySQL/TiDB 可被重复写入 - # 会用 replace 替换 insert 语句，用 delete + replace 替换 update 语句 - safe-mode = false - - # Drainer 下游服务类型（默认为 mysql） - # 参数有效值为 "mysql"，"tidb"，"file"，"kafka" - db-type = "mysql" - - # 事务的 commit ts 若在该列表中，则该事务将被过滤，不会同步至下游 - ignore-txn-commit-ts = [] - - # db 过滤列表 (默认 "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql,test")， - # 不支持对 ignore schemas 的 table 进行 rename DDL 操作 - ignore-schemas = "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql" - - # replicate-do-db 配置的优先级高于 replicate-do-table。如果配置了相同的库名，支持使用正则表达式进行配置。 - # 以 '~' 开始声明使用正则表达式 - - # replicate-do-db = ["~^b.*","s1"] - - # [syncer.relay] - # 保存 relay log 的目录，空值表示不开启。 - # 只有下游是 TiDB 或 MySQL 时该配置才生效。 - # log-dir = "" - # 每个文件的大小上限 - # max-file-size = 10485760 - - # [[syncer.replicate-do-table]] - # db-name ="test" - # tbl-name = "log" - - # [[syncer.replicate-do-table]] - # db-name ="test" - # tbl-name = "~^a.*" - - # 忽略同步某些表 - # [[syncer.ignore-table]] - # db-name = "test" - # tbl-name = "log" - - # db-type 设置为 mysql 时，下游数据库服务器参数 - [syncer.to] - host = "192.168.0.13" - user = "root" - password = "" - # 使用 `./binlogctl -cmd encrypt -text string` 加密的密码 - # encrypted_password 非空时 password 会被忽略 - encrypted_password = "" - port = 3306 - - [syncer.to.checkpoint] - # 当 checkpoint type 是 mysql 或 tidb 时可以开启该选项，以改变保存 checkpoint 的数据库 - # schema = "tidb_binlog" - # 目前只支持 mysql 或者 tidb 类型。可以去掉注释来控制 checkpoint 保存的位置。 - # db-type 默认的 checkpoint 保存方式是: - # mysql/tidb -> 对应的下游 mysql/tidb - # file/kafka -> file in `data-dir` - # type = "mysql" - # host = "127.0.0.1" - # user = "root" - # password = "" - # 使用 `./binlogctl -cmd encrypt -text string` 加密的密码 - # encrypted_password 非空时 password 会被忽略 - # encrypted_password = "" - # port = 3306 - - - # db-type 设置为 file 时，存放 binlog 文件的目录 - # [syncer.to] - # dir = "data.drainer" - - # db-type 设置为 kafka 时，Kafka 相关配置 - # [syncer.to] - # kafka-addrs 和 zookeeper-addrs 只需要一个，两者都有时程序会优先用 zookeeper 中的 kafka 地址 - # zookeeper-addrs = "127.0.0.1:2181" - # kafka-addrs = "127.0.0.1:9092" - # kafka-version = "0.8.2.0" - # kafka-max-messages = 1024 - - # 保存 binlog 数据的 Kafka 集群的 topic 名称，默认值为 _obinlog - # 如果运行多个 Drainer 同步数据到同一个 Kafka 集群，每个 Drainer 的 topic-name 需要设置不同的名称 - # topic-name = "" - ``` - - - 启动示例 - - > **注意：** - > - > 如果下游为 MySQL/TiDB，为了保证数据的完整性，在 Drainer 初次启动前需要获取 `initial-commit-ts` 的值，并进行全量数据的备份与恢复。详细信息参见[部署 Drainer](#第-3-步部署-drainer)。 - - 初次启动时使用参数 `initial-commit-ts`， 命令如下： - - {{< copyable "shell-regular" >}} - - ```bash - ./bin/drainer -config drainer.toml -initial-commit-ts {initial-commit-ts} - ``` - - 如果命令行参数与配置文件中的参数重合，则使用命令行设置的参数的值。 - -> **注意：** -> -> - 在运行 TiDB 时，需要保证至少一个 Pump 正常运行。 -> - 通过给 TiDB 增加启动参数 `enable-binlog` 来开启 binlog 服务。尽量保证同一集群的所有 TiDB 都开启了 binlog 服务，否则在同步数据时可能会导致上下游数据不一致。如果要临时运行一个不开启 binlog 服务的 TiDB 实例，需要在 TiDB 的配置文件中设置 `run_ddl= false`。 -> - Drainer 不支持对 ignore schemas（在过滤列表中的 schemas）的 table 进行 rename DDL 操作。 -> - 在已有的 TiDB 集群中启动 Drainer，一般需要全量备份并且获取**快照时间戳**，然后导入全量备份，最后启动 Drainer 从对应的快照时间戳开始同步增量数据。 -> - 下游使用 MySQL 或 TiDB 时应当保证上下游数据库的 sql_mode 具有一致性，即下游数据库同步每条 SQL 语句时的 sql_mode 应当与上游数据库执行该条 SQL 语句时的 sql_mode 保持一致。可以在上下游分别执行 `select @@sql_mode;` 进行查询和比对。 -> - 如果存在上游 TiDB 能运行但下游 MySQL 不支持的 DDL 语句时（例如下游 MySQL 使用 InnoDB 引擎时同步语句 `CREATE TABLE t1(a INT) ROW_FORMAT=FIXED;`），Drainer 也会同步失败，此时可以在 Drainer 配置中跳过该事务，同时在下游手动执行兼容的语句，详见[跳过事务](/dev/reference/tidb-binlog/faq.md#同步时出现上游数据库支持但是下游数据库执行会出错的-ddl应该怎么办)。 diff --git a/dev/reference/tidb-binlog/faq.md b/dev/reference/tidb-binlog/faq.md deleted file mode 100644 index 1a25fd54e9ff..000000000000 --- a/dev/reference/tidb-binlog/faq.md +++ /dev/null @@ -1,210 +0,0 @@ ---- -title: TiDB Binlog 常见问题 -category: FAQ -aliases: ['/docs-cn/dev/faq/tidb-binlog/','/docs-cn/dev/reference/tools/tidb-binlog/faq/'] ---- - -# TiDB Binlog 常见问题 - -本文介绍 TiDB Binlog 使用过程中的常见问题及解决方案。 - -## 开启 binog 对 TiDB 的性能有何影响？ - -- 对于查询无影响。 - -- 对于有写入或更新数据的事务有一点性能影响。延迟上，在 Prewrite 阶段要并发写一条 p-binlog 成功后才可以提交事务，一般写 binlog 比 KV Prewrite 快，所以不会增加延迟。可以在 Pump 的监控面板看到写 binlog 的响应时间。 - -## Drainer 同步下游 TiDB/MySQL 的帐号需要哪些权限？ - -Drainer 同步帐号需要有如下权限： - -* Insert -* Update -* Delete -* Create -* Drop -* Alter -* Execute -* Index -* Select - -## Pump 磁盘快满了怎么办？ - -确认 GC 正常： - -- 确认 pump 监控面板 **gc_tso** 时间是否与配置一致。 - -如 gc 正常以下调整可以降低单个 pump 需要的空间大小： - -- 调整 pump **GC** 参数减少保留数据天数。 -- 添加 pump 结点。 - -## Drainer 同步中断怎么办？ - -使用以下 binlogctl 命令查看 Pump 状态是否正常，以及是否全部非 `offline` 状态的 Pump 都在正常运行。 - -{{< copyable "shell-regular" >}} - -```bash -binlogctl -cmd pumps -``` - -查看 Drainer 监控与日志是否有对应报错，根据具体问题进行处理。 - -## Drainer 同步下游 TiDB/MySQL 慢怎么办？ - -特别关注以下监控项： - -- 通过 Drainer 监控 **drainer event**，可以看到 Drainer 当前每秒同步 Insert/Update/Delete 事件到下游的速度。 -- 通过 Drainer 监控 **sql query time**，可以看到 Drainer 在下游执行 SQL 的响应时间。 - -同步慢的可能原因与解决方案： - -- 同步的数据库包含没有主键或者唯一索引的表，需要给表加上主键。 -- Drainer 与下游之间延迟大，可以调大 Drainer `worker-count` 参数（跨机房同步建议将 Drainer 部署在下游）。 -- 下游负载不高，可以尝试调大 Drainer `worker-count` 参数。 - -## 假如有一个 Pump crash 了会怎样？ - -Drainer 会因为获取不到这个 Pump 的数据没法同步数据到下游。如果这个 Pump 能恢复，Drainer 就能恢复同步。 - -如果 Pump 没法恢复，可采用以下方式进行处理： - -1. 使用 [binlogctl 将该 Pump 状态修改为 `offline`](/dev/reference/tidb-binlog/maintain.md)（丢失这个 Pump 的数据） -2. Drainer 获取到的数据会丢失这个 Pump 上的数据，下游跟上游数据会不一致，需要重新做全量 + 增量同步。具体步骤如下： - 1. 停止当前 Drainer。 - 2. 上游做全量备份。 - 3. 清理掉下游数据，包括 checkpoint 表 `tidb_binlog.checkpoint`。 - 4. 使用上游的全量备份恢复下游数据。 - 5. 部署 Drainer，使用 `initialCommitTs`= {从全量备份获取快照的时间戳}。 - -## 什么是 checkpoint？ - -Checkpoint 记录了 Drainer 同步到下游的 commit-ts，Drainer 重启时可以读取 checkpoint 接着从对应 commit-ts 同步数据到下游。 -Drainer 日志 `["write save point"] [ts=411222863322546177]` 表示保存对应时间戳的 checkpoint。 - -下游类型不同，checkpoint 的保存方式也不同： - -- 下游 MySQL/TiDB 保存在 `tidb_binlog.checkpoint` 表。 -- 下游 kafka/file 保存在对应配置目录里的文件。 - -因为 kafka/file 的数据内容包含了 commit-ts，所以如果 checkpoint 丢失，可以消费下游最新的一条数据看写到下游数据的最新 commit-ts。 - -Drainer 启动的时候会去读取 checkpoint，如果读取不到，就会使用配置的 `initial-commit-ts` 做为初次启动开始的同步时间点。 - -## Drainer 机器发生故障，下游数据还在，如何在新机器上重新部署 Drainer？ - -如果下游数据还在，只要保证能从对应 checkpoint 接着同步即可。 - -假如 checkpoint 还在，可采用以下方式进行处理： - -1. 部署新的 Drainer 并启动即可（参考 checkpoint 介绍，Drainer 可以读取 checkpoint 接着同步）。 -2. 使用 [binlogctl 将老的 Drainer 状态修改成 `offline`](/dev/reference/tidb-binlog/maintain.md)。 - -假如 checkpoint 不在，可以如下处理： - -1. 获取之前 Drainer 的 checkpoint `commit-ts`，做为新部署 Drainer 的 `initial-commit-ts` 配置来部署新的 Drainer。 -2. 使用 [binlogctl 将老的 Drainer 状态修改成 `offline`](/dev/reference/tidb-binlog/maintain.md)。 - -## 如何用全量 + binlog 备份文件来恢复一个集群？ - -1. 清理集群数据并使用全部备份恢复数据。 -2. 使用 reparo 设置 `start-tso` = {全量备份文件快照时间戳+1}，`end-ts` = 0（或者指定时间点），恢复到备份文件最新的数据。 - -## 主从同步开启 `ignore-error` 触发 critical error 后如何重新部署？ - -TiDB 配置开启 `ignore-error` 写 binlog 失败后触发 critical error 告警，后续都不会再写 binlog，所以会有 binlog 数据丢失。如果要恢复同步，需要如下处理： - -1. 停止当前 Drainer。 -2. 重启触发 critical error 的 `tidb-server` 实例重新开始写 binlog（触发 critical error 后不会再写 binlog 到 pump）。 -3. 上游做全量备份。 -4. 清理掉下游数据包括 checkpoint 表 `tidb_binlog.checkpoint`。 -5. 使用上游的全量备份恢复下游。 -6. 部署 Drainer，使用 `initialCommitTs`= {从全量备份获取快照的时间戳}。 - -## 同步时出现上游数据库支持但是下游数据库执行会出错的 DDL，应该怎么办？ - -1. 查看 drainer.log 日志，查找 `exec failed` 找到 Drainer 退出前最后一条执行失败的 DDL。 -2. 将 DDL 改为下游兼容支持的版本，在下游数据库中手动执行。 -3. 查看 drainer.log 日志，查找执行失败的 DDL 语句，可以查询到该 DDL 的 commit-ts。 -4. 编辑 `drainer.toml` 配置文件，在 `ignore-txn-commit-ts` 项中添加该 commit-ts，重启 Drainer。 - -在绝大部分情况下，TiDB 和 MySQL 的语句都是兼容的。用户需要注意的是上下游的 `sql_mode` 应当保持一致。 - -## 在什么情况下暂停和下线 Pump/Drainer？ - -首先需要通过以下内容来了解 Pump/Drainer 的状态定义和启动、退出的流程。 - -暂停主要针对临时需要停止服务的场景，例如： - -- 版本升级：停止进程后使用新的 binary 启动服务。 -- 服务器维护：需要对服务器进行停机维护。退出进程，等维护完成后重启服务。 - -下线主要针对永久（或长时间）不再使用该服务的场景，例如： - -- Pump 缩容：不再需要那么多 Pump 服务了，所以下线部分服务。 -- 同步任务取消：不再需要将数据同步到某个下游，所以下线对应的 Drainer。 -- 服务器迁移：需要将服务迁移到其他服务器。下线服务，在新的服务器上重新部署。 - -## 可以通过哪些方式暂停 Pump/Drainer？ - -- 直接 kill 进程。 - - >**注意：** - > - > 不能使用 `kill -9` 命令，否则 Pump/Drainer 无法对信号进行处理。 - -- 如果 Pump/Drainer 运行在前台，则可以通过按下 Ctrl+C 来暂停。 -- 使用 binlogctl 的 `pause-pump` 或 `pause-drainer` 命令。 - -## 可以使用 binlogctl 的 `update-pump`/`update-drainer` 命令来下线 Pump/Drainer 服务吗？ - -不可以。使用 `update-pump`/`update-drainer` 命令会直接修改 PD 中保存的状态信息，并且不会通知 Pump/Drainer 做相应的操作。使用不当时，可能会干扰数据同步，某些情况下还可能会造成**数据不一致**的严重后果。例如： - -- 当 Pump 正常运行或者处于暂停状态时，如果使用 `update-pump` 将该 Pump 设置为 `offline`，那么 Drainer 会放弃获取处于 `offline` 状态的 Pump 的 binlog 数据，导致该 Pump 最新的 binlog 数据没有同步到 Drainer，造成上下游数据不一致。 -- 当 Drainer 正常运行时，使用 `update-drainer` 命令将该 Drainer 设置为 `offline`。如果这时启动一个 Pump 节点，Pump 只会通知 `online` 状态的 Drainer，导致该 Drainer 没有及时获取到该 Pump 的 binlog 数据，造成上下游数据不一致。 - -## 可以使用 binlogctl 的 `update-pump`/`update-drainer` 命令来暂停 Pump/Drainer 服务吗？ - -不可以。`update-pump`/`update-drainer` 命令直接修改 PD 中保存的状态信息。执行这个命令并不会通知 Pump/Drainer 做相应的操作，**而且使用不当会使数据同步中断，甚至造成数据丢失。** - -## 什么情况下使用 binlogctl 的 `update-pump` 命令设置 Pump 状态为 `paused`？ - -在某些异常情况下，Pump 没有正确维护自己的状态，实际上状态应该为 `paused`。这时可以使用 `update-pump` 对状态进行修正，例如： - -- Pump 异常退出（可能由 panic 或者误操作执行 `kill -9` 命令直接 kill 掉进程导致），Pump 保存在 PD 中的状态仍然为 `online`。如果暂时不需要重启 Pump 恢复服务，可以使用 `update-pump` 把该 Pump 状态设置为 `paused`，避免对 TiDB 写 binlog 和 Drainer 获取 binlog 造成干扰。 - -## 什么情况下使用 binlogctl 的 `update-drainer` 命令设置 Drainer 状态为 `paused`？ - -在某些异常情况下，Drainer 没有正确维护自己的状态，，对数据同步造成了影响，实际上状态应该为 `paused`。这时可以使用 `update-drainer` 对状态进行修正，例如： - -- Drainer 异常退出（出现 panic 直接退出进程，或者误操作执行 `kill -9` 命令直接 kill 掉进程），Drainer 保存在 PD 中的状态仍然为 `online`。当 Pump 启动时无法正常通知该 Drainer（报错 `notify drainer ...`），导致 Pump 无法正常运行。这个时候可以使用 `update-drainer` 将 Drainer 状态更新为 `paused`，再启动 Pump。 - -## 可以通过哪些方式下线 Pump/Drainer？ - -目前只可以使用 binlogctl 的 `offline-pump` 和 `offline-drainer` 命令来下线 Pump 和 Drainer。 - -## 什么情况下使用 binlogctl 的 `update-pump` 命令设置 Pump 状态为 `offline`? - -> **警告：** -> -> 仅在可以容忍 binlog **数据丢失、上下游数据不一致**或者确认不再需要使用该 Pump 存储的 binlog 数据的情况下，才能使用 `update-pump` 修改 Pump 状态为 `offline`。 - -可以使用 `update-pump` 修改 Pump 状态为 `offline` 的情况有： - -- 在某些情况下，Pump 异常退出进程，且无法恢复服务，同步就会中断。如果希望恢复同步且可以容忍部分 binlog 数据丢失，可以使用 `update-pump` 命令将该 Pump 状态设置为 `offline`，则 Drainer 会放弃拉取该 Pump 的 binlog 然后继续同步数据。 -- 有从历史任务遗留下来且不再使用的 Pump 且进程已经退出（例如测试使用的服务），之后不再需要使用该服务，使用 `update-pump` 将该 Pump 设置为 `offline`。 - -在其他情况下一定要使用 `offline-pump` 命令让 Pump 走正常的下线处理流程。 - -## Pump 进程已经退出，且状态为 `paused`，现在不想使用这个 Pump 节点了，能否用 binlogctl 的 `update-pump` 命令设置节点状态为 `offline`？ - -Pump 以 `paused` 状态退出进程时，不保证所有 binlog 数据被下游 Drainer 消费。所以这样做会有上下游数据不一致的风险。正确的做法是重新启动 Pump，然后使用 `offline-pump` 下线该 Pump。 - -## 什么情况下使用 binlogctl 的 `update-drainer` 命令设置 Drainer 状态为 `offline`？ - -- 有从历史任务遗留下来且不再使用的 Drainer 且进程已经退出（例如测试使用的服务），之后不再需要使用该服务，使用 `update-drainer` 将该 Drainer 设置为 `offline`。 - -## 可以使用 `change pump`、`change drainer` 等 SQL 操作来暂停或者下线 Pump/Drainer 服务吗？ - -目前还不支持。这种 SQL 操作会直接修改 PD 中保存的状态，在功能上等同于使用 binlogctl 的 `update-pump`、`update-drainer` 命令。如果需要暂停或者下线，仍然要使用 binlogctl。 diff --git a/dev/reference/tidb-binlog/glossary.md b/dev/reference/tidb-binlog/glossary.md deleted file mode 100644 index 99acfd127a7a..000000000000 --- a/dev/reference/tidb-binlog/glossary.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: TiDB Binlog 术语表 -summary: 学习 TiDB Binlog 相关术语 -category: glossary ---- - -# TiDB Binlog 术语表 - -本文档介绍 TiDB Binlog 相关术语。 - -## Binlog - -在 TiDB Binlog 中，Binlog 通常指 TiDB 写的二进制日志数据，也指 Drainer 写到 Kafka 或者文件的二进制日志数据，前者与后者的格式不同。此外，TiDB 的 binlog 格式与 MySQL 的 binlog 格式也不同。 - -## Binlog event - -TiDB 写的 DML Binlog 有 3 种 event，分别为：`INSERT`、`UPDATE` 和 `DELETE`。在 Drainer 监控面板上可以看到同步数据对应的不同 event 的个数。 - -## Checkpoint - -Checkpoint 指保存的断点信息，记录了 Drainer 同步到下游的 commit-ts。Drainer 重启时可以读取 checkpoint，并从对应的 commit-ts 开始同步数据到下游。 - -## Safe mode - -Safe mode 指增量复制过程中，当表结构中存在主键或唯一索引时，用于支持幂等导入 DML 的模式。 - -该模式将来自上游的 `INSERT` 改写为 `REPLACE`，将 `UPDATE` 改写为 `DELETE` 与 `REPLACE`，然后再向下游执行。在 Drainer 启动的前 5 分钟，会自动启动 Safe mode；另外也可以在配置文件中通过 `safe-mode` 参数手动开启，但该配置仅在下游是 MySQL 或 TiDB 时有效。 diff --git a/dev/reference/tidb-binlog/maintain.md b/dev/reference/tidb-binlog/maintain.md deleted file mode 100644 index d96e3882616a..000000000000 --- a/dev/reference/tidb-binlog/maintain.md +++ /dev/null @@ -1,258 +0,0 @@ ---- -title: TiDB Binlog 集群运维 -category: reference -aliases: ['/docs-cn/dev/how-to/maintain/tidb-binlog/','/docs-cn/dev/reference/tools/tidb-binlog/maintain/'] ---- - -# TiDB Binlog 集群运维 - -本文首先介绍 Pump 和 Drainer 的状态及启动、退出的内部处理流程，然后说明如何通过 binlogctl 工具或者直接在 TiDB 执行 SQL 操作来管理 binlog 集群，最后的 FAQ 部分会介绍一些常见问题以及处理方法。 - -## Pump/Drainer 的状态 - -Pump/Drainer 中状态的定义： - -* online：正常运行中 -* pausing：暂停中 -* paused：已暂停 -* closing：下线中 -* offline：已下线 - -这些状态由 Pump/Drainer 服务自身进行维护，并定时将状态信息更新到 PD 中。 - -## Pump/Drainer 的启动、退出流程 - -### Pump - -* 启动：Pump 启动时会通知所有 online 状态的 Drainer，如果通知成功，则 Pump 将状态设置为 online，否则 Pump 将报错，然后将状态设置为 paused 并退出进程。 -* 退出：Pump 进程正常退出前要选择进入暂停或者下线状态；非正常退出（kill -9、进程 panic、宕机）都依然保持 online 状态。 - - * 暂停：使用 kill（非 kill -9）、Ctrl+C 或者使用 binlogctl 的 pause-pump 命令都可以暂停 Pump。接收到暂停指令后，Pump 会变更状态为 pausing，并停止接受 binlog 的写请求，也停止向 Drainer 提供 binlog 数据。安全退出所有线程后，更新状态为 paused 然后退出进程。 - * 下线：仅在使用 binlogctl 的 offline-pump 命令的情况下才会下线 Pump。接收到下线指令后，Pump 会变更状态为 closing，并停止接受 binlog 的写请求。Pump 继续向 Drainer 提供 binlog，等待所有 binlog 数据都被 Drainer 消费后再将状态设置为 offline 并退出进程。 - -### Drainer - -* 启动：Drainer 启动时将状态设置为 online，并尝试从所有非 offline 状态的 Pump 获取 binlog，如果获取 binlog 失败，会不断尝试重新获取。 -* 退出：Drainer 进程正常退出前要选择进入暂停或者下线状态；非正常退出（kill -9 、进程 panic、宕机）都依然保持 online 状态。 - - * 暂停：使用 kill（非 kill -9）、Ctrl+C 或者使用 binlogctl 的 pause-drainer 命令都可以暂停 Drainer。接收到指令后，Drainer 会变更状态为 pausing，并停止从 Pump 获取 binlog。安全退出所有线程后，更新状态为 paused 然后退出进程。 - * 下线：仅在使用 binlogctl 的 offline-drainer 命令的情况下才会下线 Drainer。接收到下线指令后，Drainer 变更状态为 closing，并停止从 Pump 获取 binlog。安全退出所有线程后，更新状态为 offline 然后退出进程。 - -关于 Pump/Drainer 暂停、下线、状态查询、状态修改等具体的操作方法，参考如下 binlogctl 工具的使用方法介绍。 - -## binlogctl 工具 - -支持如下这些功能： - -* 查看 Pump/Drainer 状态 -* 暂停/下线 Pump/Drainer -* Pump/Drainer 异常状态处理 - -使用 binlogctl 的场景： - -* 同步出现故障/检查运行情况，需要查看 Pump/Drainer 的状态 -* 维护集群，需要暂停/下线 Pump/Drainer -* Pump/Drainer 异常退出，状态没有更新，或者状态不符合预期，对业务造成影响 - -binlogctl 下载链接： - -{{< copyable "shell-regular" >}} - -```bash -wget https://download.pingcap.org/tidb-{version}-linux-amd64.tar.gz && -wget https://download.pingcap.org/tidb-{version}-linux-amd64.sha256 -``` - -检查文件完整性，返回 ok 则正确： - -{{< copyable "shell-regular" >}} - -```bash -sha256sum -c tidb-{version}-linux-amd64.sha256 -``` - -对于 v2.1.0 GA 及以上版本，binlogctl 已经包含在 TiDB 的下载包中，其他版本需要单独下载 binlogctl: - -{{< copyable "shell-regular" >}} - -```bash -wget https://download.pingcap.org/tidb-enterprise-tools-latest-linux-amd64.tar.gz && -wget https://download.pingcap.org/tidb-enterprise-tools-latest-linux-amd64.sha256 -``` - -检查文件完整性，返回 ok 则正确： - -{{< copyable "shell-regular" >}} - -```bash -sha256sum -c tidb-enterprise-tools-latest-linux-amd64.sha256 -``` - -binlogctl 使用说明： - -命令行参数： - -```bash -Usage of binlogctl: --V -输出 binlogctl 的版本信息 --cmd string - 命令模式，包括 "generate_meta"（已废弃）, "pumps", "drainers", "update-pump" ,"update-drainer", "pause-pump", "pause-drainer", "offline-pump", "offline-drainer" --data-dir string - 保存 Drainer 的 checkpoint 的文件的路径 (默认 "binlog_position")（已废弃） --node-id string - Pump/Drainer 的 ID --pd-urls string - PD 的地址，如果有多个，则用"," 连接 (默认 "http://127.0.0.1:2379") --ssl-ca string - SSL CAs 文件的路径 --ssl-cert string - PEM 格式的 X509 认证文件的路径 --ssl-key string - PEM 格式的 X509 key 文件的路径 --time-zone string - 如果设置时区，在 "generate_meta" 模式下会打印出获取到的 tso 对应的时间。例如 "Asia/Shanghai" 为 CST 时区，"Local" 为本地时区 --show-offline-nodes - 在用 `-cmd pumps` 或 `-cmd drainers` 命令时使用，这两个命令默认不显示 offline 的节点，仅当明确指定 `-show-offline-nodes` 时会显示 - -``` - -命令示例： - -- 查询所有的 Pump/Drainer 的状态： - - 设置 `cmd` 为 `pumps` 或者 `drainers` 来查看所有 Pump 或者 Drainer 的状态。例如： - - {{< copyable "shell-regular" >}} - - ```bash - bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd pumps - ``` - - ``` - [2019/04/28 09:29:59.016 +00:00] [INFO] [nodes.go:48] ["query node"] [type=pump] [node="{NodeID: 1.1.1.1:8250, Addr: pump:8250, State: online, MaxCommitTS: 408012403141509121, UpdateTime: 2019-04-28 09:29:57 +0000 UTC}"] - ``` - - {{< copyable "shell-regular" >}} - - ```bash - bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd drainers - ``` - - ``` - [2019/04/28 09:29:59.016 +00:00] [INFO] [nodes.go:48] ["query node"] [type=drainer] [node="{NodeID: 1.1.1.1:8249, Addr: 1.1.1.1:8249, State: online, MaxCommitTS: 408012403141509121, UpdateTime: 2019-04-28 09:29:57 +0000 UTC}"] - ``` - -- 暂停/下线 Pump/Drainer - - binlogctl 提供以下命令暂停/下线服务： - - | cmd | 说明 | 示例 | - | --------------- | ------------- | ------------------------------------------------------------------------------------------------| - | pause-pump | 暂停 Pump | `bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd pause-pump -node-id ip-127-0-0-1:8250` | - | pause-drainer | 暂停 Drainer | `bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd pause-drainer -node-id ip-127-0-0-1:8249` | - | offline-pump | 下线 Pump | `bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd offline-pump -node-id ip-127-0-0-1:8250` | - | offline-drainer | 下线 Drainer | `bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd offline-drainer -node-id ip-127-0-0-1:8249` | - - binlogctl 会发送 HTTP 请求给 Pump/Drainer，Pump/Drainer 收到命令后会主动执行对应的退出流程。 - -- 异常情况下修改 Pump/Drainer 的状态 - - 在服务正常运行以及符合流程的暂停、下线过程中，Pump/Drainer 的状态都是可以正确的。但是在一些异常情况下 Pump/Drainer 无法正确维护自己的状态，可能会影响数据同步任务，在这种情况下需要使用 binlogctl 修复状态信息。 - - 设置 `cmd` 为 `update-pump` 或者 `update-drainer` 来更新 Pump 或者 Drainer 的状态。Pump 和 Drainer 的状态可以为 paused 或者 offline。例如： - - {{< copyable "shell-regular" >}} - - ```bash - bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd update-pump -node-id ip-127-0-0-1:8250 -state paused - ``` - - > **注意：** - > - > Pump/Drainer 在正常运行过程中会定期在 PD 中更新自己的状态，而这条命令是直接去修改 Pump/Drainer 保存在 PD 中的状态，所以在 Pump/Drainer 服务正常的情况下使用这些命令是没有意义的。仅在 Pump/Drainer 服务异常的情况下使用，具体哪些场景下使用这条命令可以参考 FAQ。 - -## 使用 TiDB SQL 管理 Pump/Drainer - -要查看和管理 binlog 相关的状态，可在 TiDB 中执行相应的 SQL 语句。 - -- 查看 TiDB 是否开启 binlog - - {{< copyable "sql" >}} - - ```sql - show variables like "log_bin"; - ``` - - ``` - +---------------+-------+ - | Variable_name | Value | - +---------------+-------+ - | log_bin | ON | - +---------------+-------+ - ``` - - 值为 `ON` 时表示 TiDB 开启了 binlog。 - -- 查看 Pump/Drainer 状态 - - {{< copyable "sql" >}} - - ```sql - show pump status; - ``` - - ``` - +--------|----------------|--------|--------------------|---------------------| - | NodeID | Address | State | Max_Commit_Ts | Update_Time | - +--------|----------------|--------|--------------------|---------------------| - | pump1 | 127.0.0.1:8250 | Online | 408553768673342237 | 2019-05-01 00:00:01 | - +--------|----------------|--------|--------------------|---------------------| - | pump2 | 127.0.0.2:8250 | Online | 408553768673342335 | 2019-05-01 00:00:02 | - +--------|----------------|--------|--------------------|---------------------| - ``` - - {{< copyable "sql" >}} - - ```sql - show drainer status; - ``` - - ``` - +----------|----------------|--------|--------------------|---------------------| - | NodeID | Address | State | Max_Commit_Ts | Update_Time | - +----------|----------------|--------|--------------------|---------------------| - | drainer1 | 127.0.0.3:8249 | Online | 408553768673342532 | 2019-05-01 00:00:03 | - +----------|----------------|--------|--------------------|---------------------| - | drainer2 | 127.0.0.4:8249 | Online | 408553768673345531 | 2019-05-01 00:00:04 | - +----------|----------------|--------|--------------------|---------------------| - ``` - -- 异常情况下修改 Pump/Drainer 状态 - - {{< copyable "sql" >}} - - ```sql - change pump to node_state ='paused' for node_id 'pump1'; - ``` - - ``` - Query OK, 0 rows affected (0.01 sec) - ``` - - {{< copyable "sql" >}} - - ```sql - change drainer to node_state ='paused' for node_id 'drainer1'; - ``` - - ``` - Query OK, 0 rows affected (0.01 sec) - ``` - - 该 SQL 的功能和 binlogctl 中的 update-pump 和 update-drainer 命令的功能一样，因此也只有在 Pump/Drainer 异常的情况下使用。 - -> **注意：** -> -> 1. 查看 binlog 开启状态以及 Pump/Drainer 状态的功能在 TiDB v2.1.7 及以上版本中支持。 -> 2. 修改 Pump/Drainer 状态的功能在 TiDB v3.0.0-rc.1 及以上版本中支持。该功能只修改 PD 中存储的 Pump/Drainer 状态，如果需要暂停/下线节点，仍然需要使用 `binlogctl`。 diff --git a/dev/reference/tidb-binlog/monitor.md b/dev/reference/tidb-binlog/monitor.md deleted file mode 100644 index 09e0d397403b..000000000000 --- a/dev/reference/tidb-binlog/monitor.md +++ /dev/null @@ -1,164 +0,0 @@ ---- -title: TiDB Binlog 集群监控 -category: reference -aliases: ['/docs-cn/dev/how-to/monitor/tidb-binlog-monitor/','/docs-cn/dev/reference/tools/tidb-binlog/monitor/','/docs-cn/dev/how-to/monitor/tidb-binlog/'] ---- - -# TiDB Binlog 集群监控 - -使用 Ansible 成功部署 TiDB Binlog 集群后，可以进入 Grafana Web 界面（默认地址: ，默认账号：admin，密码：admin）查看 Pump 和 Drainer 的运行状态。 - -## 监控指标 - -### Pump - -| metric 名称 | 说明 | -|:----|:------------| -| Storage Size | 记录磁盘的总空间大小 (capacity)，以及可用磁盘空间大小 (available) | -| Metadata | 记录每个 Pump 的可删除 binlog 的最大 tso (gc_tso)，以及保存的 binlog 的最大的 commit tso (max_commit_tso)。 | -| Write Binlog QPS by Instance | 每个 Pump 接收到的写 binlog 请求的 QPS | -| Write Binlog Latency | 记录每个 Pump 写 binlog 的延迟时间 | -| Storage Write Binlog Size | Pump 写 binlog 数据的大小 | -| Storage Write Binlog Latency | Pump 中的 storage 模块写 binlog 数据的延迟 | -| Pump Storage Error By Type | Pump 遇到的 error 数量，按照 error 的类型进行统计 | -| Query TiKV | Pump 通过 TiKV 查询事务状态的次数 | - -### Drainer - -| metric 名称 | 说明 | -|:----|:------------| -| Checkpoint TSO | Drainer 已经同步到下游的 binlog 的最大 TSO 对应的时间。可以通过该指标估算同步延迟时间 | -| Pump Handle TSO | 记录 Drainer 从各个 Pump 获取到的 binlog 的最大 TSO 对应的时间 | | Pull Binlog QPS by Pump NodeID | Drainer 从每个 Pump 获取 binlog 的 QPS | -| 95% Binlog Reach Duration By Pump | 记录 binlog 从写入 Pump 到被 Drainer 获取到这个过程的延迟时间 | -| Error By Type | Drainer 遇到的 error 数量，按照 error 的类型进行统计 | -| SQL Query Time| Drainer 在下游执行 SQL 的耗时 | -| Drainer Event | 各种类型 event 的数量，event 包括 ddl、insert、delete、update、flush、savepoint | -| Execute Time | 写入 binlog 到同步下游模块所消耗的时间 | -| 95% Binlog Size | Drainer 从各个 Pump 获取到 binlog 数据的大小 | -| DL Job Count | Drainer 处理的 DDL 的数量| -| Queue Size | Drainer 内部工作队列大小 | - -## 监控报警规则 - -本节介绍了 TiDB Binlog 组件的报警项及相应的报警规则。根据严重级别，报警项可分为三类，按照严重程度由高到低依次为：紧急级别 (Emergency)、重要级别 (Critical)、警告级别 (Warning)。 - -### 紧急级别报警项 - -紧急级别的报警通常由于服务停止或节点故障导致，此时需要马上进行人工干预操作。 - -#### `binlog_pump_storage_error_count` - -* 报警规则： - - `changes(binlog_pump_storage_error_count[1m]) > 0` - -* 规则描述： - - Pump 写 binlog 到本地存储时失败。 - -* 处理方法： - - 确认 `pump_storage_error` 监控是否存在错误，查看 Pump 日志确认原因。 - -### 重要级别报警项 - -对于重要级别的报警，需要密切关注异常指标。 - -#### `binlog_drainer_checkpoint_high_delay` - -* 报警规则： - - `(time() - binlog_drainer_checkpoint_tso / 1000) > 3600` - -* 规则描述： - - Drainer 同步落后延迟超过 1 个小时。 - -* 处理方法： - - * 判断从 Pump 获取数据是否太慢： - - 监控 Pump handle tso 可以看每个 Pump 最近一条消息的时间，是不是有延迟特别大的 Pump，确认对应 Pump 正常运行。 - - * 根据 Drainer event 和 Drainer execute latency 来判断是否下游同步太慢： - - * 如果 Drainer execute time 过大，则检查到目标库网络带宽和延迟，以及目标库状态。 - * 如果 Drainer execute time 不大，Drainer event 过小，则增加 work count 和 batch 进行重试。 - - * 如果上面都不满足或者操作后没有改观，则报备开发人员 [support@pingcap.com](mailto:support@pingcap.com) 进行处理。 - -### 警告级别报警项 - -警告级别的报警是对某一问题或错误的提醒。 - -#### `binlog_pump_write_binlog_rpc_duration_seconds_bucket` - -* 报警规则： - - `histogram_quantile(0.9, rate(binlog_pump_rpc_duration_seconds_bucket{method="WriteBinlog"}[5m])) > 1` - -* 规则描述： - - Pump 处理 TiDB 写 Binlog 请求耗时过大。 - -* 处理方法： - - * 确认磁盘性能压力，通过 `node exported` 查看 disk performance 监控。 - * 如果 `disk latency` 和 `util` 都很低，那么报备开发人员 [support@pingcap.com](mailto:support@pingcap.com) 进行处理。 - -#### `binlog_pump_storage_write_binlog_duration_time_bucket` - -* 报警规则： - - `histogram_quantile(0.9, rate(binlog_pump_storage_write_binlog_duration_time_bucket{type="batch"}[5m])) > 1` - -* 规则描述： - - Pump 写本地 binlog 到本地盘的耗时。 - -* 处理方法： - - 确认 Pump 本地盘情况，进行修复。 - -#### `binlog_pump_storage_available_size_less_than_20G` - -* 报警规则： - - `binlog_pump_storage_storage_size_bytes{type="available"} < 20 * 1024 * 1024 * 1024` - -* 规则描述： - - Pump 剩余可用磁盘空间不足 20 G。 - -* 处理方法： - - 监控确认 Pump 的 `gc_tso` 是否正常。如果不正常，调整 Pump 的 GC 时间配置或者下线对应 Pump。 - -#### `binlog_drainer_checkpoint_tso_no_change_for_1m` - -* 报警规则： - - `changes(binlog_drainer_checkpoint_tso[1m]) < 1` - -* 规则描述： - - Drainer 的 `checkpoint` 在 1 分钟内没有更新。 - -* 处理方法： - - 确认所有非下线的 Pump 是否正常运行。 - -#### `binlog_drainer_execute_duration_time_more_than_10s` - -* 报警规则： - - `histogram_quantile(0.9, rate(binlog_drainer_execute_duration_time_bucket[1m])) > 10` - -* 规则描述： - - Drainer 同步到 TiDB 的事务耗时。如果这个值过大，会影响 Drainer 同步。 - -* 处理方法： - - * 查看 TiDB 集群的状态。 - * 查看 Drainer 日志或监控，如果是 DDL 操作导致了该问题，则忽略。 diff --git a/dev/reference/tidb-binlog/overview.md b/dev/reference/tidb-binlog/overview.md deleted file mode 100644 index 3f8b4d8f0a46..000000000000 --- a/dev/reference/tidb-binlog/overview.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: TiDB Binlog 简介 -category: reference -aliases: ['/docs-cn/dev/reference/tidb-binlog-overview/','/docs-cn/dev/reference/tools/tidb-binlog/overview/'] ---- - -# TiDB Binlog 简介 - -TiDB Binlog 是一个用于收集 TiDB 的 binlog，并提供准实时备份和同步功能的商业工具。 - -TiDB Binlog 支持以下功能场景： - -- **数据同步**：同步 TiDB 集群数据到其他数据库 -- **实时备份和恢复**：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复 - -## TiDB Binlog 整体架构 - -![TiDB Binlog 架构](/media/tidb_binlog_cluster_architecture.png) - -TiDB Binlog 集群主要分为 Pump 和 Drainer 两个组件，以及 binlogctl 工具： - -### Pump - -[Pump](https://github.com/pingcap/tidb-binlog/blob/master/pump) 用于实时记录 TiDB 产生的 Binlog，并将 Binlog 按照事务的提交时间进行排序，再提供给 Drainer 进行消费。 - -### Drainer - -[Drainer](https://github.com/pingcap/tidb-binlog/tree/master/drainer) 从各个 Pump 中收集 Binlog 进行归并，再将 Binlog 转化成 SQL 或者指定格式的数据，最终同步到下游。 - -### binlogctl 工具 - -[`binlogctl`](https://github.com/pingcap/tidb-binlog/tree/master/binlogctl) 是一个 TiDB Binlog 配套的运维工具，具有如下功能： - -* 获取 TiDB 集群当前的 TSO -* 查看 Pump/Drainer 状态 -* 修改 Pump/Drainer 状态 -* 暂停/下线 Pump/Drainer - -## 主要特性 - -* 多个 Pump 形成一个集群，可以水平扩容。 -* TiDB 通过内置的 Pump Client 将 Binlog 分发到各个 Pump。 -* Pump 负责存储 Binlog，并将 Binlog 按顺序提供给 Drainer。 -* Drainer 负责读取各个 Pump 的 Binlog，归并排序后发送到下游。 -* Drainer 支持 [relay log](/dev/reference/tidb-binlog/relay-log.md) 功能，通过 relay log 保证下游集群的一致性状态。 - -## 注意事项 - -* 需要使用 TiDB v2.0.8-binlog、v2.1.0-rc.5 及以上版本，否则不兼容该版本的 TiDB Binlog。 - -* Drainer 支持将 Binlog 同步到 MySQL、TiDB、Kafka 或者本地文件。如果需要将 Binlog 同步到其他 Drainer 不支持的类型的系统中，可以设置 Drainer 将 Binlog 同步到 Kafka，然后根据 binlog slave protocol 进行定制处理，参考 [binlog slave client 用户文档](/dev/reference/tidb-binlog/binlog-slave-client.md)。 - -* 如果 TiDB Binlog 用于增量恢复，可以设置配置项 `db-type="file"`，Drainer 会将 binlog 转化为指定的 [proto buffer 格式](https://github.com/pingcap/tidb-binlog/blob/master/proto/binlog.proto)的数据，再写入到本地文件中。这样就可以使用 [Reparo](/dev/reference/tidb-binlog/reparo.md) 恢复增量数据。 - - 关于 `db-type` 的取值，应注意： - - - 如果 TiDB 版本 < 2.1.9，则 `db-type="pb"`。 - - 如果 TiDB 版本 > = 2.1.9，则 `db-type="file"` 或 `db-type="pb"`。 - -* 如果下游为 MySQL/TiDB，数据同步后可以使用 [sync-diff-inspector](/dev/reference/tools/sync-diff-inspector/overview.md) 进行数据校验。 diff --git a/dev/reference/tidb-binlog/relay-log.md b/dev/reference/tidb-binlog/relay-log.md deleted file mode 100644 index b272ceb5d57b..000000000000 --- a/dev/reference/tidb-binlog/relay-log.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: TiDB Binlog Relay Log -category: reference -aliases: ['/docs-cn/dev/reference/tools/tidb-binlog/relay-log/'] ---- - -# TiDB Binlog Relay Log - -Drainer 同步 binlog 时会拆分上游的事务，并将拆分的事务并发同步到下游。在极端情况下，上游集群不可用并且 Drainer 异常退出后，下游集群（MySQL 或 TiDB）可能处于数据不一致的中间状态。在此场景下，Drainer 借助 relay log 可以确保将下游集群同步到一个一致的状态。 - -## Drainer 同步时的一致性状态 - -下游集群达到一致的状态是指：下游集群的数据等同于上游设置了 `tidb_snapshot = ts` 的快照。 - -checkpoint 状态一致性是指：Drainer checkpoint 通过 `consistent` 保存了同步的一致性状态。Drainer 运行时 `consistent` 为 `false`，Drainer 正常退出后 `consistent` 更新为 `true`。 - -查询下游 checkpoint 表的示例如下： - -``` -mysql> select * from tidb_binlog.checkpoint; -+---------------------+----------------------------------------------------------------+ -| clusterID | checkPoint | -+---------------------+----------------------------------------------------------------+ -| 6791641053252586769 | {"consistent":false,"commitTS":414529105591271429,"ts-map":{}} | -+---------------------+----------------------------------------------------------------+ -``` - -## 工作原理 - -Drainer 开启 relay log 后会先将 binlog event 写到磁盘上，然后再同步给下游集群。如果上游集群不可用，Drainer 可以通过读取 relay log 把下游集群恢复到一个一致的状态。 - -> **注意：** -> -> 若同时丢失 relay log 数据，该方法将不可用，不过这是概率极小的事件。此外可以使用 NFS 等网络文件系统来保证 relay log 的数据安全。 - -### Drainer 从 relay log 消费 binlog 的触发场景 - -如果 Drainer 启动时无法连接到上游集群的 PD，并且探测到 checkpoint 的 `consistent = false`，此时会尝试读取 relay log，并将下游集群恢复到一致的状态。然后 Drainer 进程将 checkpoint 的 `status` 设置为 `0` 后主动退出。 - -### Relay log 的清理（GC）机制 - -Drainer 在运行时，如果确认已经将一个 relay log 文件的全部数据都成功同步到下游了，就会马上删除这个文件，所以 relay log 不会占用过多空间。一个 relay log 文件大小达到 10MB（默认）时就会做切分，数据开始写入新的 relay log 文件。 - -## 配置 - -在 Drainer 中添加以下配置来开启 relay log 功能： - -{{< copyable "" >}} - -``` -[syncer.relay] -# 保存 relay log 的目录，空值表示不开启。 -# 只有下游是 TiDB 或 MySQL 时该配置才有生效。 -log-dir = "/dir/to/save/log" -``` diff --git a/dev/reference/tidb-binlog/reparo.md b/dev/reference/tidb-binlog/reparo.md deleted file mode 100644 index c0a19ce4b66a..000000000000 --- a/dev/reference/tidb-binlog/reparo.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -title: Reparo 使用文档 -category: reference -aliases: ['/docs-cn/dev/reference/tools/tidb-binlog/reparo/'] ---- - -# Reparo 使用文档 - -Reparo 是 TiDB Binlog 的一个配套工具，用于增量的恢复。使用 TiDB Binlog 中的 Drainer 将 binlog 按照 protobuf 格式输出到文件，通过这种方式来备份增量数据。当需要恢复增量数据时，使用 Reparo 解析文件中的 binlog，并将其应用到 TiDB／MySQL 中。 - -下载链接：[tidb-binlog-cluster-latest-linux-amd64.tar.gz](https://download.pingcap.org/tidb-binlog-cluster-latest-linux-amd64.tar.gz) - -## Reparo 使用 - -### 命令行参数说明 - -``` -Usage of Reparo: --L string - 日志输出信息等级设置：debug, info, warn, error, fatal（默认值：info）。 --V 打印版本信息。 --c int - 同步下游的并发数，该值设置越高同步的吞吐性能越好（默认 16）。 --config string - 配置文件路径，如果指定了配置文件，Reparo 会首先读取配置文件的配置；如果对应的配置在命令行参数里面也存在，Reparo 就会使用命令行参数的配置来覆盖配置文件里面的。 --data-dir string - Drainer 输出的 protobuf 格式 binlog 文件的存储路径 (默认值： data.drainer)。 --dest-type string - 下游服务类型。 取值为 print, mysql（默认值：print）。当值为 print 时，只做解析打印到标准输出，不执行 SQL；如果为 mysql，则需要在配置文件内配置 host、port、user、password 等信息。 --log-file string - log 文件路径。 --log-rotate string - log 文件切换频率，取值为 hour、day。 --start-datetime string - 用于指定开始恢复的时间点，格式为 “2006-01-02 15:04:05”。如果不设置该参数则从最早的 binlog 文件开始恢复。 --stop-datetime string - 用于指定结束恢复的时间点，格式同上。如果不设置该参数则恢复到最后一个 binlog 文件。 --safe-mode bool - 指定是否开启安全模式，开启后可支持反复同步。 --txn-batch int - 输出到下游数据库一个事务的 SQL 语句数量（默认 20）。 -``` - -### 配置文件说明 - -```toml -# Drainer 输出的 protobuf 格式 binlog 文件的存储路径。 -data-dir = "./data.drainer" - -# 使用索引文件来搜索 ts 的位置，当设置了 `start-ts` 时设置该参数，文件的路径为 {data-dir}/{index-name}。 -# index-name = "binlog.index" -# log-file = "" -# log-rotate = "hour" - -# 日志输出信息等级设置：debug, info, warn, error, fatal (默认值：info)。 -log-level = "info" - -# 使用 start-datetime 和 stop-datetime 来选择恢复指定时间范围内的 binlog，格式为 “2006-01-02 15:04:05”。 -# start-datetime = "" -# stop-datetime = "" - -# start-tso、stop-tso 分别对应 start-datetime 和 stop-datetime，也是用于恢复指定时间范围内的 binlog，用 tso 的值来设置。如果已经设置了 start-datetime 和 stop-datetime，就不需要再设置 start-tso 和 stop-tso。 -# start-tso = 0 -# stop-tso = 0 - -# 下游服务类型。 取值为 print, mysql（默认值：print）。当值为 print 时，只做解析打印到标准输出，不执行 SQL；如果为 mysql，则需要在 [dest-db] 中配置 host、port、user、password 等信息。 -dest-type = "mysql" - -# 输出到下游数据库一个事务的 SQL 语句数量（默认 20）。 -txn-batch = 20 - -# 同步下游的并发数，该值设置越高同步的吞吐性能越好（默认 16）。 -worker-count = 16 - -# 安全模式配置。取值为 true 或 false（默认值：false）。当值为 true 时，Reparo 会将 update 语句拆分为 delete + replace 语句。 -safe-mode = false - -# replicate-do-db 和 replicate-do-table 用于指定恢复的库和表，replicate-do-db 的优先级高于 replicate-do-table。支持使用正则表达式来配置，需要以 '~' 开始声明使用正则表达式。 -# 注：replicate-do-db 和 replicate-do-table 使用方式与 Drainer 的使用方式一致。 -# replicate-do-db = ["~^b.*","s1"] -# [[replicate-do-table]] -# db-name ="test" -# tbl-name = "log" -# [[replicate-do-table]] -# db-name ="test" -# tbl-name = "~^a.*" - -# 如果 dest-type 设置为 mysql, 需要配置 dest-db。 -[dest-db] -host = "127.0.0.1" -port = 3309 -user = "root" -password = "" -``` - -### 启动示例 - -{{< copyable "shell-regular" >}} - -```bash -./bin/reparo -config reparo.toml -``` - -> **注意：** -> -> - data-dir 用于指定 Drainer 输出的 binlog 文件目录。 -> - start-datatime 和 start-tso 效果一样，只是时间格式上的区别，用于指定开始恢复的时间点；如果不指定，则默认在第一个 binlog 文件开始恢复。 -> - stop-datetime 和 stop-tso 效果一样，只是时间格式上的区别，用于指定结束恢复的时间点；如果不指定，则恢复到最后一个 binlog 文件的结尾。 -> - dest-type 指定目标类型，取值为 `mysql`、`print`。 当值为 `mysql` 时，可以恢复到 MySQL/TiDB 等使用或兼容 MySQL 协议的数据库，需要在配置下面的 [dest-db] 填写数据库信息；当取值为 `print` 的时候，只是打印 binlog 信息，通常用于 debug，以及查看 binlog 的内容，此时不需要填写 `[dest-db]`。 -> - replicate-do-db 用于指定恢复的库，不指定的话，则全部都恢复。 -> - replicate-do-table 用于指定要恢复的表，不指定的话，则全部都恢复。 diff --git a/dev/reference/tidb-binlog/tidb-binlog-kafka.md b/dev/reference/tidb-binlog/tidb-binlog-kafka.md deleted file mode 100644 index b70a951acc07..000000000000 --- a/dev/reference/tidb-binlog/tidb-binlog-kafka.md +++ /dev/null @@ -1,458 +0,0 @@ ---- -title: TiDB Binlog kafka 部署方案 -category: reference -aliases: ['/docs-cn/dev/reference/tools/tidb-binlog/tidb-binlog-kafka/'] ---- - -# TiDB Binlog Kafka 部署方案 - -本文档介绍如何部署 Kafka 版本的 TiDB Binlog。 - -## TiDB Binlog 简介 - -TiDB Binlog 是用于收集 TiDB 的 Binlog，并提供实时备份和同步功能的商业工具。 - -TiDB Binlog 支持以下功能场景: - -- **数据同步**：同步 TiDB 集群数据到其他数据库 -- **实时备份和恢复**：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复 - -## TiDB Binlog Kafka 架构 - -首先介绍 TiDB Binlog 的整体架构。 - -![TiDB Binlog 架构](/media/tidb_binlog_kafka_architecture.png) - -TiDB Binlog 集群主要分为三个组件： - -### Pump - -Pump 是一个守护进程，在每个 TiDB 主机的后台运行。其主要功能是实时记录 TiDB 产生的 Binlog 并顺序写入 Kafka 中。 - -### Drainer - -Drainer 从 Kafka 中收集 Binlog，并按照 TiDB 中事务的提交顺序转化为指定数据库兼容的 SQL 语句，最后同步到目的数据库或者写到顺序文件。 - -### Kafka & ZooKeeper - -Kafka 集群用来存储由 Pump 写入的 Binlog 数据，并提供给 Drainer 进行读取。 - -> **注意：** -> -> Local 版本将 Binlog 存储在文件中，Kafka 版本则使用 Kafka 存储。 - -## TiDB Binlog 安装 - -以下为 TiDB Ansible 分支与 TiDB 版本的对应关系，版本选择可咨询官方 info@pingcap.com。 - -| TiDB Ansible 分支 | TiDB 版本 | 备注 | -|:----|:----|:----| -| release-2.0 | 2.0 版本 | 最新 2.0 稳定版本，可用于生产环境。 | - -### 下载官方 Binary - -环境：CentOS 7+ - -下载压缩包： - -{{< copyable "shell-regular" >}} - -```bash -wget https://download.pingcap.org/tidb-binlog-kafka-linux-amd64.tar.gz && -wget https://download.pingcap.org/tidb-binlog-kafka-linux-amd64.sha256 -``` - -检查文件完整性，返回 ok 则正确： - -{{< copyable "shell-regular" >}} - -```bash -sha256sum -c tidb-binlog-kafka-linux-amd64.sha256 -``` - -解开压缩包： - -{{< copyable "shell-regular" >}} - -```bash -tar -xzf tidb-binlog-kafka-linux-amd64.tar.gz && -cd tidb-binlog-kafka-linux-amd64 -``` - -### TiDB Binlog 部署 - -#### 注意事项 - -* 需要为一个 TiDB 集群中的每台 TiDB server 部署一个 Pump，目前 TiDB server 只支持以 unix socket 的方式输出 Binlog。 - -* 手动部署时，启动顺序为：Pump > TiDB。停止顺序为 TiDB > Pump。 - - 设置 TiDB 启动参数 `binlog-socket` 为对应的 Pump 参数 `socket` 所指定的 unix socket 文件路径，最终部署结构如下图所示： - - ![TiDB pump 模块部署结构](/media/tidb-pump-deployment.png) - -* Drainer 不支持对 ignore schemas（在过滤列表中的 schemas）的 table 进行 rename DDL 操作。 - -* 在已有的 TiDB 集群中启动 Drainer，一般需要全量备份并且获取 savepoint，然后导入全量备份，最后启动 Drainer 从 savepoint 开始同步。 - - 为了保证数据的完整性，在 Pump 运行 10 分钟左右后按顺序进行如下操作： - - * 使用 [tidb-tools](https://github.com/pingcap/tidb-tools) 项目中的 [binlogctl](https://github.com/pingcap/tidb-tools/tree/binlog-kafka/tidb_binlog/binlogctl) 工具生成 Drainer 初次启动所需的 position - * 全量备份，例如 Mydumper 备份 TiDB - * 全量导入备份到目标系统 - * Kafka 版本 Drainer 启动的 savepoint 默认保存在下游 database tidb_binlog 下的 checkpoint 表中，如果 checkpoint 表中没有有效的数据，可以通过设置 `initial-commit-ts` 启动 Drainer 从指定位置开始消费 - `bin/drainer --config=conf/drainer.toml --initial-commit-ts=${position}` - -* Drainer 输出为 pb，要在配置文件中设置如下参数： - - ```toml - [syncer] - db-type = "pb" - disable-dispatch = true - - [syncer.to] - dir = "/path/pb-dir" - ``` - -* Drainer 输出为 kafka，要在配置文件中设置如下参数： - - ```toml - [syncer] - db-type = "kafka" - - # when db-type is kafka, you need to use this to config the down stream kafka, or it will be the same kafka addrs where drainer pull binlog from. - [syncer.to] - kafka-addrs = "127.0.0.1:9092" - kafka-version = "0.8.2.0" - ``` - - 输出到 kafka 的数据为按 ts 排好序的 protobuf 定义 binlog 格式，可以参考 [driver](https://github.com/pingcap/tidb-tools/tree/master/tidb-binlog/driver) 获取数据同步到下游。 - -* Kafka 和 ZooKeeper 集群需要在部署 TiDB Binlog 之前部署好。Kafka 需要 0.9 及以上版本。 - -#### Kafka 集群配置推荐 - -|名字|数量|内存|CPU|硬盘| -|:---:|:---:|:---:|:---:|:---:| -|Kafka|3+|16G|8+|2+ 1TB| -|ZooKeeper|3+|8G|4+|2+ 300G| - -#### Kafka 配置参数推荐 - -- `auto.create.topics.enable = true`：如果还没有创建 topic，Kafka 会在 broker 上自动创建 topic -- `broker.id`：用来标识 Kafka 集群的必备参数，不能重复，如 `broker.id = 1` -- `fs.file-max = 1000000`：Kafka 会使用大量文件和网络 socket，建议修改成 1000000，通过 `vi /etc/sysctl.conf` 进行修改 -- 修改以下配置为1G, 否则很容易出现事务修改数据较多导致单个消息过大写 kafka 失败 - - * `message.max.bytes=1073741824` - * `replica.fetch.max.bytes=1073741824` - * `fetch.message.max.bytes=1073741824` - -#### 使用 TiDB Ansible 部署 Pump - -- 如无 Kafka 集群，可使用 [kafka-ansible](https://github.com/pingcap/thirdparty-ops/tree/master/kafka-ansible) 部署 Kafka 集群。 -- 使用 [tidb-ansible](https://github.com/pingcap/tidb-ansible) 部署 TiDB 集群时，修改 `tidb-ansible/inventory.ini` 文件，设置 `enable_binlog = True`，并配置 `zookeeper_addrs` 变量为 Kafka 集群的 ZooKeeper 地址，这样部署 TiDB 集群时会部署 Pump。 - -配置样例: - -```ini -# binlog trigger -enable_binlog = True -# ZooKeeper address of Kafka cluster, example: -# zookeeper_addrs = "192.168.0.11:2181,192.168.0.12:2181,192.168.0.13:2181" -# You can also append an optional chroot string to the URLs to specify the root directory for all Kafka znodes, example: -# zookeeper_addrs = "192.168.0.11:2181,192.168.0.12:2181,192.168.0.13:2181/kafka/123" -zookeeper_addrs = "192.168.0.11:2181,192.168.0.12:2181,192.168.0.13:2181" -``` - -#### 使用 Binary 部署 Pump - -使用样例： - -假设我们有三个 PD，三个 ZooKeeper，一个 TiDB，各个节点信息如下： - -```ini -TiDB="192.168.0.10" -PD1="192.168.0.16" -PD2="192.168.0.15" -PD3="192.168.0.14" -ZK1="192.168.0.13" -ZK2="192.168.0.12" -ZK3="192.168.0.11" -``` - -在 ip="192.168.0.10" 的机器上面部署 Drainer/Pump。 - -对应的 PD 集群的 ip="192.168.0.16,192.168.0.15,192.168.0.14"。 - -对应的 Kafka 集群的 ZooKeeper 的 ip="192.168.0.13,192.168.0.12,192.168.0.11"。以此为例，说明 Pump/Drainer 的使用。 - -1. Pump 命令行参数说明 - - ``` - Usage of Pump: - -L string - 日志输出信息等级设置: debug, info, warn, error, fatal (默认 "info") - -V - 打印版本信息 - -addr string - Pump 提供服务的 RPC 地址(-addr="192.168.0.10:8250") - -advertise-addr string - Pump 对外提供服务的 RPC 地址(-advertise-addr="192.168.0.10:8250") - -config string - 配置文件路径，如果你指定了配置文件，Pump 会首先读取配置文件的配置； - 如果对应的配置在命令行参数里面也存在，Pump 就会使用命令行参数的配置来覆盖配置文件里面的。 - -data-dir string - Pump 数据存储位置路径 - -enable-tolerant - 开启 tolerant 后，如果 binlog 写入失败，Pump 不会报错（默认开启） - -zookeeper-addrs string (-zookeeper_addrs = "192.168.0.11:2181,192.168.0.12:2181,192.168.0.13:2181") - ZooKeeper 地址，该选项从 ZooKeeper 中获取 Kafka 地址，需要和 Kafka 中配置相同 - -gc int - 日志最大保留天数 (默认 7)，设置为 0 可永久保存 - -heartbeat-interval int - Pump 向 PD 发送心跳间隔 (单位 秒) - -log-file string - log 文件路径 - -log-rotate string - log 文件切换频率，hour/day - -metrics-addr string - Prometheus pushgateway 地址，不设置则禁止上报监控信息 - -metrics-interval int - 监控信息上报频率 (默认 15，单位 秒) - -pd-urls string - PD 集群节点的地址 (-pd-urls="http://192.168.0.16:2379,http://192.168.0.15:2379,http://192.168.0.14:2379") - -socket string - unix socket 模式服务监听地址（默认 unix:///tmp/pump.sock） - ``` - -2. Pump 配置文件 - - ```toml - # Pump Configuration. - - # Pump 提供服务的 RPC 地址("192.168.0.10:8250") - addr = "192.168.0.10:8250" - - # Pump 对外提供服务的 RPC 地址("192.168.0.10:8250") - advertise-addr = "" - - # binlog 最大保留天数 (默认 7)，设置为 0 可永久保存 - gc = 7 - - # Pump 数据存储位置路径 - data-dir = "data.pump" - - # ZooKeeper 地址，该选项从 ZooKeeper 中获取 Kafka 地址，若 Kafka 中配置了命名空间，则此处需同样配置 - # zookeeper-addrs = "192.168.0.11:2181,192.168.0.12:2181,192.168.0.13:2181" - # 配置了命令空间的 ZooKeeper 地址配置示例 - # zookeeper-addrs = "192.168.0.11:2181,192.168.0.12:2181,192.168.0.13:2181/kafka/123" - - # Pump 向 PD 发送心跳的间隔 (单位 秒) - heartbeat-interval = 3 - - # PD 集群节点的地址 - pd-urls = "http://192.168.0.16:2379,http://192.168.0.15:2379,http://192.168.0.14:2379" - - # unix socket 模式服务监听地址 (默认 unix:///tmp/pump.sock) - socket = "unix:///tmp/pump.sock" - ``` - -3. 启动示例 - - {{< copyable "shell-regular" >}} - - ```bash - ./bin/pump -config pump.toml - ``` - -#### 使用 Binary 部署 Drainer - -1. Drainer 命令行参数说明 - - ``` - Usage of Drainer: - -L string - 日志输出信息等级设置：debug, info, warn, error, fatal (默认 "info") - -V - 打印版本信息 - -addr string - Drainer 提供服务的地址(-addr="192.168.0.10:8249") - -c int - 同步下游的并发数，该值设置越高同步的吞吐性能越好 (default 1) - -config string - 配置文件路径，Drainer 会首先读取配置文件的配置； - 如果对应的配置在命令行参数里面也存在，Drainer 就会使用命令行参数的配置来覆盖配置文件里面的 - -data-dir string - Drainer 数据存储位置路径 (默认 "data.drainer") - -zookeeper-addrs string (-zookeeper-addrs="192.168.0.11:2181,192.168.0.12:2181,192.168.0.13:2181") - ZooKeeper 地址，该选项从 ZooKeeper 中获取 Kafka 地址，需要和 Kafka 中配置相同 - -dest-db-type string - Drainer 下游服务类型 (默认为 mysql) - -detect-interval int - 向 PD 查询在线 Pump 的时间间隔 (默认 10，单位 秒) - -disable-dispatch - 是否禁用拆分单个 binlog 的 sqls 的功能，如果设置为 true，则按照每个 binlog - 顺序依次还原成单个事务进行同步（下游服务类型为 mysql，该项设置为 False） - -ignore-schemas string - db 过滤列表 (默认 "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql,test")， - 不支持对 ignore schemas 的 table 进行 rename DDL 操作 - -initial-commit-ts (默认为 0) - 如果 Drainer 没有相关的断点信息，可以通过该项来设置相关的断点信息 - -log-file string - log 文件路径 - -log-rotate string - log 文件切换频率，hour/day - -metrics-addr string - Prometheus pushgateway 地址，不设置则禁止上报监控信息 - -metrics-interval int - 监控信息上报频率（默认 15，单位 秒） - -pd-urls string - PD 集群节点的地址 (-pd-urls="http://192.168.0.16:2379,http://192.168.0.15:2379,http://192.168.0.14:2379") - -txn-batch int - 输出到下游数据库一个事务的 SQL 数量（默认 1） - ``` - -2. Drainer 配置文件 - - ```toml - # Drainer Configuration. - - # Drainer 提供服务的地址("192.168.0.10:8249") - addr = "192.168.0.10:8249" - - # 向 PD 查询在线 Pump 的时间间隔 (默认 10，单位 秒) - detect-interval = 10 - - # Drainer 数据存储位置路径 (默认 "data.drainer") - data-dir = "data.drainer" - - # ZooKeeper 地址，该选项从 ZooKeeper 中获取 Kafka 地址，若 Kafka 中配置了命名空间，则此处需同样配置 - # zookeeper-addrs = "192.168.0.11:2181,192.168.0.12:2181,192.168.0.13:2181" - # 配置了命令空间的 ZooKeeper 地址配置示例 - # zookeeper-addrs = "192.168.0.11:2181,192.168.0.12:2181,192.168.0.13:2181/kafka/123" - - # PD 集群节点的地址 - pd-urls = "http://192.168.0.16:2379,http://192.168.0.15:2379,http://192.168.0.14:2379" - - # log 文件路径 - log-file = "drainer.log" - - # Syncer Configuration. - [syncer] - - ## db 过滤列表 (默认 "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql,test"), - ## 不支持对 ignore schemas 的 table 进行 rename DDL 操作 - ignore-schemas = "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql" - - # 输出到下游数据库一个事务的 SQL 数量 (default 1) - txn-batch = 1 - - # 同步下游的并发数，该值设置越高同步的吞吐性能越好 (default 1) - worker-count = 1 - - # 是否禁用拆分单个 binlog 的 sqls 的功能，如果设置为 true，则按照每个 binlog - # 顺序依次还原成单个事务进行同步（下游服务类型为 mysql, 该项设置为 False） - disable-dispatch = false - - # Drainer 下游服务类型（默认为 mysql） - # 参数有效值为 "mysql", "pb" - db-type = "mysql" - - # replicate-do-db prioritizes over replicate-do-table when they have the same db name - # and we support regex expressions, - # 以 '~' 开始声明使用正则表达式 - - #replicate-do-db = ["~^b.*","s1"] - - #[[syncer.replicate-do-table]] - #db-name ="test" - #tbl-name = "log" - - #[[syncer.replicate-do-table]] - #db-name ="test" - #tbl-name = "~^a.*" - - # db-type 设置为 mysql 时，下游数据库服务器参数 - [syncer.to] - host = "192.168.0.10" - user = "root" - password = "" - port = 3306 - - # db-type 设置为 pb 时，存放 binlog 文件的目录 - # [syncer.to] - # dir = "data.drainer" - ``` - -3. 启动示例 - - {{< copyable "shell-regular" >}} - - ```bash - ./bin/drainer -config drainer.toml - ``` - -## 下载 PbReader 工具 (Linux) - -PbReader 用于解析 Drainer 生成的 Pb 文件，并翻译成对应的 SQL 语句。 - -环境：CentOS 7+ - -下载 PbReader 压缩包： - -{{< copyable "shell-regular" >}} - -```bash -wget https://download.pingcap.org/pb_reader-latest-linux-amd64.tar.gz && -wget https://download.pingcap.org/pb_reader-latest-linux-amd64.sha256 -``` - -检查文件完整性，返回 ok 则正确： - -{{< copyable "shell-regular" >}} - -```bash -sha256sum -c pb_reader-latest-linux-amd64.sha256 -``` - -解开压缩包： - -{{< copyable "shell-regular" >}} - -```bash -tar -xzf pb_reader-latest-linux-amd64.tar.gz && -cd pb_reader-latest-linux-amd64 -``` - -PbReader 使用示例： - -{{< copyable "shell-regular" >}} - -```bash -./bin/pbReader -binlog-file=${path}/binlog-0000000000000000 -``` - -## TiDB Binlog 监控 - -本部分主要介绍如何对 TiDB Binlog 的状态、性能做监控，并通过 Prometheus + Grafana 展现 metrics 数据。 - -### Pump/Drainer 配置 - -使用 Ansible 部署的 Pump 服务已经在启动参数设置 metrics。启动 Drainer 时可以设置以下两个参数： - -- `--metrics-addr`：设为 Push Gateway 的地址 -- `--metrics-interval`：设为 push 的频率，单位为秒，默认值为 15 - -### Grafana 配置 - -+ 进入 Grafana Web 界面（默认地址: `http://localhost:3000`，默认账号：admin，密码：admin） - - 点击 Grafana Logo -> 点击 Data Sources -> 点击 Add data source -> 填写 data source 信息 - - > **注意：** - > - > Type 选 Prometheus，URL 为 Prometheus 地址，根据实际情况添加/填写。 - -+ 导入 dashboard 配置文件 - - 点击 Grafana Logo -> 点击 Dashboards -> 点击 Import -> 选择需要的 [dashboard 配置文件](https://github.com/pingcap/tidb-ansible/blob/master/scripts/syncer.json)上传 -> 选择对应的 data source diff --git a/dev/reference/tidb-binlog/tidb-binlog-local.md b/dev/reference/tidb-binlog/tidb-binlog-local.md deleted file mode 100644 index 5d34a452cc78..000000000000 --- a/dev/reference/tidb-binlog/tidb-binlog-local.md +++ /dev/null @@ -1,287 +0,0 @@ ---- -title: TiDB Binlog Local 部署方案 -category: reference -aliases: ['/docs-cn/dev/reference/tools/tidb-binlog/tidb-binlog-local/'] ---- - -# TiDB Binlog Local 部署方案 - -## TiDB Binlog Local 简介 - -TiDB Binlog 是用于收集 TiDB 的 Binlog，并提供实时备份和同步功能的商业工具。 - -TiDB Binlog 支持以下功能场景: - -* **数据同步**：同步 TiDB 集群数据到其他数据库。 -* **实时备份和恢复**：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复。 - -## TiDB Binlog Local 架构 - -下图为 TiDB Binlog Local的整体架构。 - -![TiDB Binlog 架构](/media/architecture.jpeg) - -TiDB Binlog Local 主要分为两个组件： - -- **Pump** 是一个守护进程，在每个 TiDB 的主机上后台运行。他的主要功能是实时记录 TiDB 产生的 Binlog 并顺序写入磁盘文件 - -- **Drainer** 从各个 Pump 节点收集 Binlog，并按照在 TiDB 中事务的提交顺序转化为指定数据库兼容的 SQL 语句，最后同步到目的数据库或者写到顺序文件 - -## TiDB Binlog Local 安装 - -### TiDB Binlog Local 下载 - -TiDB Binlog 包含在 tidb-enterprise-tools 安装包中，可[在此下载](/dev/reference/tools/download.md)。 - -### TiDB Binlog Local 部署 - -#### 注意 - -* 需要为一个 TiDB 集群中的每台 TiDB server 部署一个 Pump，目前 TiDB server 只支持以 unix socket 方式的输出 binlog。 -* 手动部署时， 启动顺序为： Pump > TiDB，停止顺序为 TiDB > Pump - - 我们设置 TiDB 启动参数 binlog-socket 为对应的 Pump 的参数 socket 所指定的 unix socket 文件路径，最终部署结构如下图所示： - - ![TiDB pump 模块部署结构](/media/tidb-pump-deployment.png) - -* drainer 不支持对 ignore schemas（在过滤列表中的 schemas） 的 table 进行 rename DDL 操作 - -* 在已有的 TiDB 集群中启动 drainer，一般需要全量备份 并且获取 savepoint，然后导入全量备份，最后启动 drainer 从 savepoint 开始同步。 - - 为了保证数据的完整性，在 pump 运行 10 分钟左右后按顺序进行下面的操作 - - * 以 gen-savepoint model 运行 drainer 生成 drainer savepint 文件，`bin/drainer -gen-savepoint --data-dir= ${drainer_savepoint_dir} --pd-urls=${pd_urls}` - * 全量备份，例如 Mydumper 备份 tidb - * 全量导入备份到目标系统 - * 设置 savepoint 文件路径，然后启动 drainer，`bin/drainer --config=conf/drainer.toml --data-dir=${drainer_savepoint_dir}` - -* drainer 输出的 pb, 需要在配置文件设置下面的参数 - - ```toml - [syncer] - db-type = "pb" - disable-dispatch = true - - [syncer.to] - dir = "/path/pb-dir" - ``` - -#### 使用 TiDB Ansible 部署 Pump (推荐) - -* 搭建全新的 TiDB Cluster，启动顺序 pd-server -> tikv-server -> pump -> tidb-server -> drainer - * 修改 tidb-ansible inventory.ini 文件 - * enable_binlog = True - * 执行 ansible-playbook deploy.yml - * 执行 ansible-playbook start.yml - * drainer 目前需要手动部署 - -* 对已有的 TiDB Cluster 部署 binlog - * 修改 tidb-ansible inventory.ini 文件 - * enable_binlog = True - * 执行 ansible-playbook rolling_update.yml --tags=tidb - * drainer 目前需要手动部署 - -#### 使用 Binary 部署 Pump - -1. PUMP 命令行参数说明 - - ``` - Usage of pump: - -L string - 日志输出信息等级设置: debug, info, warn, error, fatal (默认 "info") - -V - 打印版本信息 - -addr string - pump 提供服务的 rpc 地址(默认 "127.0.0.1:8250") - -advertise-addr string - pump 对外提供服务的 rpc 地址(默认 "127.0.0.1:8250") - -config string - 配置文件路径,如果你指定了配置文件，pump 会首先读取配置文件的配置 - 如果对应的配置在命令行参数里面也存在，pump 就会使用命令行参数的配置来覆盖配置文件里面的 - -data-dir string - pump 数据存储位置路径 - -gc int - 日志最大保留天数 (默认 7)， 设置为 0 可永久保存 - -heartbeat-interval uint - pump 向 pd 发送心跳间隔 (单位 秒) - -log-file string - log 文件路径 - -log-rotate string - log 文件切换频率, hour/day - -metrics-addr string - prometheus Pushgateway 地址，不设置则禁止上报监控信息 - -metrics-interval int - 监控信息上报频率 (默认 15，单位 秒) - -pd-urls string - pd 集群节点的地址 (默认 "http://127.0.0.1:2379") - -socket string - unix socket 模式服务监听地址 (默认 unix:///tmp/pump.sock) - ``` - - 2. PUMP 配置文件 - - ```toml - # pump Configuration. - # pump 提供服务的 rpc 地址(默认 "127.0.0.1:8250") - addr = "127.0.0.1:8250" - # pump 对外提供服务的 rpc 地址(默认 "127.0.0.1:8250") - advertise-addr = "" - # binlog 最大保留天数 (默认 7)， 设置为 0 可永久保存 - gc = 7 - # pump 数据存储位置路径 - data-dir = "data.pump" - # pump 向 pd 发送心跳间隔 (单位 秒) - heartbeat-interval = 3 - # pd 集群节点的地址 (默认 "http://127.0.0.1:2379") - pd-urls = "http://127.0.0.1:2379" - # unix socket 模式服务监听地址 (默认 unix:///tmp/pump.sock) - socket = "unix:///tmp/pump.sock" - ``` - -3. 启动示例 - - {{< copyable "shell-regular" >}} - - ```bash - ./bin/pump -config pump.toml - ``` - -#### 使用 Binary 部署 Drainer - -1. Drainer 命令行参数说明 - - ``` - Usage of drainer: - -L string - 日志输出信息等级设置: debug, info, warn, error, fatal (默认 "info") - -V - 打印版本信息 - -addr string - drainer 提供服务的地址(默认 "127.0.0.1:8249") - -c int - 同步下游的并发数，该值设置越高同步的吞吐性能越好 (default 1) - -config string - 配置文件路径, drainer 会首先读取配置文件的配置 - 如果对应的配置在命令行参数里面也存在，drainer 就会使用命令行参数的配置来覆盖配置文件里面的 - -data-dir string - drainer 数据存储位置路径 (默认 "data.drainer") - -dest-db-type string - drainer 下游服务类型 (默认为 mysql) - -detect-interval int - 向 pd 查询在线 Pump 的时间间隔 (默认 10，单位 秒) - -disable-dispatch - 是否禁用拆分单个 binlog 的 sqls 的功能，如果设置为 true，则按照每个 binlog - 顺序依次还原成单个事务进行同步( 下游服务类型为 mysql, 该项设置为 False ) - -gen-savepoint - 如果设置为 true, 则只生成 drainer 的 savepoint meta 文件, 可以配合 Mydumper 使用 - -ignore-schemas string - db 过滤列表 (默认 "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql,test"), - 不支持对 ignore schemas 的 table 进行 rename DDL 操作 - -log-file string - log 文件路径 - -log-rotate string - log 文件切换频率, hour/day - -metrics-addr string - Prometheus Pushgateway 地址，不设置则禁止上报监控信息 - -metrics-interval int - 监控信息上报频率 (默认 15，单位 秒) - -pd-urls string - pd 集群节点的地址 (默认 "http://127.0.0.1:2379") - -txn-batch int - 输出到下游数据库一个事务的 sql 数量 (default 1) - ``` - -2. Drainer 配置文件 - - ```toml - # drainer Configuration. - - # drainer 提供服务的地址(默认 "127.0.0.1:8249") - addr = "127.0.0.1:8249" - - # 向 pd 查询在线 pump 的时间间隔 (默认 10，单位 秒) - detect-interval = 10 - - # drainer 数据存储位置路径 (默认 "data.drainer") - data-dir = "data.drainer" - - # pd 集群节点的地址 (默认 "http://127.0.0.1:2379") - pd-urls = "http://127.0.0.1:2379" - - # log 文件路径 - log-file = "drainer.log" - - # Syncer Configuration. - [syncer] - - ## db 过滤列表 (默认 "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql,test"), - ## 不支持对 ignore schemas 的 table 进行 rename DDL 操作 - ignore-schemas = "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql" - - # 输出到下游数据库一个事务的 sql 数量 (default 1) - txn-batch = 1 - - # 同步下游的并发数，该值设置越高同步的吞吐性能越好 (default 1) - worker-count = 1 - - # 是否禁用拆分单个 binlog 的 sqls 的功能，如果设置为 true，则按照每个 binlog - # 顺序依次还原成单个事务进行同步( 下游服务类型为 mysql, 该项设置为 False ) - disable-dispatch = false - - # drainer 下游服务类型 (默认为 mysql) - # 参数有效值为 "mysql", "pb" - db-type = "mysql" - - # replicate-do-db priority over replicate-do-table if have same db name - # and we support regex expression , - # 以 '~' 开始声明使用正则表达式 - - #replicate-do-db = ["~^b.*","s1"] - - #[[syncer.replicate-do-table]] - #db-name ="test" - #tbl-name = "log" - - #[[syncer.replicate-do-table]] - #db-name ="test" - #tbl-name = "~^a.*" - - # db-type 设置为 mysql 时，下游数据库服务器参数 - [syncer.to] - host = "127.0.0.1" - user = "root" - password = "" - port = 3306 - - # db-type 设置为 pb 时,存放 binlog 文件的目录 - # [syncer.to] - # dir = "data.drainer" - ``` - -3. 启动示例 - - {{< copyable "shell-regular" >}} - - ```bash - ./bin/drainer -config drainer.toml - ``` - -## TiDB Binlog Local 监控 - -这部分主要对 TiDB Binlog 的状态、性能做监控，通过 Prometheus + Grafana 展现 metrics 数据， - -### pump/drainer 配置 - -使用 ansible 部署的 pump 服务，已经在启动参数设置 metrics 。 - -drainer 启动时可以设置 `--metrics-addr` 和 `--metrics-interval` 两个参数，其中 metrics-addr 设为 Push Gateway 的地址，metrics-interval 为 push 的频率，单位为秒，默认值为15 - -### Grafana 配置 - -+ 进入 Grafana Web 界面（默认地址: `http://localhost:3000`，默认账号: admin 密码: admin） - - 点击 Grafana Logo -> 点击 Data Sources -> 点击 Add data source -> 填写 data source 信息 ( 注: Type 选 Prometheus，Url 为 Prometheus 地址，根据实际情况 添加/填写 ） - -+ 导入 dashboard 配置文件 - - 点击 Grafana Logo -> 点击 Dashboards -> 点击 Import -> 选择需要的 [dashboard 配置文件](https://github.com/pingcap/tidb-ansible/blob/master/scripts/binlog.json)上传 -> 选择对应的 data source diff --git a/dev/reference/tidb-binlog/troubleshoot/binlog.md b/dev/reference/tidb-binlog/troubleshoot/binlog.md deleted file mode 100644 index 9e30262f815d..000000000000 --- a/dev/reference/tidb-binlog/troubleshoot/binlog.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: TiDB Binlog 故障诊断 -category: reference -aliases: ['/docs-cn/dev/how-to/troubleshoot/tidb-binlog/'] ---- - -# TiDB Binlog 故障诊断 - -本文总结了在 TiDB Binlog 的使用过程中遇到问题的诊断流程，并指引用户通过监控、状态、日志等信息查找相应的解决方案。 - -如果你在使用 TiDB Binlog 时出现了异常，请尝试以下方式排查问题： - -1. 查看各个监控指标是否异常，参见[TiDB Binlog 集群监控](/dev/reference/tidb-binlog/monitor.md)。 - -2. 使用 [binlogctl 工具](/dev/reference/tidb-binlog/maintain.md#binlogctl-工具)查看各个 Pump、Drainer 的状态是否有异常。 - -3. 查看 Pump、Drainer 日志中是否有 `ERROR`、`WARN`，并根据详细的日志信息初步判断问题原因。 - -通过以上方式定位到问题后，在 [FAQ](/dev/reference/tidb-binlog/faq.md) 以及 [常见错误及修复](/dev/reference/tidb-binlog/troubleshoot/error-handling.md) 中查找解决方案，如果没有查找到解决方案或者提供的解决方案无法解决问题，请提交 [issue](https://github.com/pingcap/tidb-binlog/issues) 或者联系相关技术支持人员。 diff --git a/dev/reference/tidb-binlog/upgrade.md b/dev/reference/tidb-binlog/upgrade.md deleted file mode 100644 index 18a8d410c78a..000000000000 --- a/dev/reference/tidb-binlog/upgrade.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: TiDB Binlog 版本升级方法 -category: reference -aliases: ['/docs-cn/dev/how-to/upgrade/tidb-binlog/','/docs-cn/dev/reference/tools/tidb-binlog/upgrade/'] ---- - -# TiDB Binlog 版本升级方法 - -如未特别指明，文中出现的 TiDB Binlog 均指最新的 [Cluster](/dev/reference/tidb-binlog/overview.md) 版本。 - -本文会分 Ansible 部署和手动部署两种情况介绍 TiDB Binlog 版本升级的方法，另外有一小节介绍如何从更早的不兼容版本（Kafka/Local 版本）升级到最新版本。 - -## Ansible 部署 - -本节适用于使用 [TiDB Ansible Playbook](https://github.com/pingcap/tidb-ansible) 部署的情况。 - -### 升级 Pump - -1. 将新版本的二进制文件 `pump` 复制到 `{{ resources_dir }}/bin` 目录中 -2. 执行 `ansible-playbook rolling_update.yml --tags=pump` 命令来滚动升级 Pump - -### 升级 Drainer - -1. 将新版本的二进制文件 `drainer` 复制到 `{{ resources_dir }}/bin` 目录中 -2. 执行 `ansible-playbook stop_drainer.yml --tags=drainer` 命令 -3. 执行 `ansible-playbook start_drainer.yml --tags=drainer` 命令 - -## 手动部署 - -### 升级 Pump - -对集群里的每个 Pump 逐一升级，确保集群中总有 Pump 可以接收 TiDB 发来的 Binlog。 - -1. 用新版本的 `pump` 替换原来的文件 -2. 重启 Pump 进程 - -### 升级 Drainer - -1. 用新版本的 `drainer` 替换原来的文件 -2. 重启 Drainer 进程 - -## 从 Kafka/Local 版本升级到 Cluster 版本 - -新版本的 TiDB（v2.0.8-binlog、v2.1.0-rc.5 及以上版本）不兼容 [Kafka 版本](/dev/reference/tidb-binlog/tidb-binlog-kafka.md)以及 [Local 版本](/dev/reference/tidb-binlog/tidb-binlog-local.md)的 TiDB Binlog，集群升级到新版本后只能使用 Cluster 版本的 TiDB Binlog。如果在升级前已经使用了 Kafka／Local 版本的 TiDB Binlog，必须将其升级到 Cluster 版本。 - -TiDB Binlog 版本与 TiDB 版本的对应关系如下： - -| TiDB Binlog 版本 | TiDB 版本 | 说明 | -|---|---|---| -| Local | TiDB 1.0 及更低版本 || -| Kafka | TiDB 1.0 ~ TiDB 2.1 RC5 | TiDB 1.0 支持 local 版本和 Kafka 版本的 TiDB Binlog。 | -| Cluster | TiDB v2.0.8-binlog，TiDB 2.1 RC5 及更高版本 | TiDB v2.0.8-binlog 是一个支持 Cluster 版本 TiDB Binlog 的 2.0 特殊版本。 | - -### 升级流程 - -> **注意：** -> -> 如果能接受重新导全量数据，则可以直接废弃老版本，按 [TiDB Binlog 集群部署](/dev/reference/tidb-binlog/deploy.md)中的步骤重新部署。 - -如果想从原来的 checkpoint 继续同步，使用以下升级流程： - -1. 部署新版本 Pump。 -2. 暂停 TiDB 集群业务。 -3. 更新 TiDB 以及配置，写 Binlog 到新的 Pump Cluster。 -4. TiDB 集群重新接入业务。 -5. 确认老版本的 Drainer 已经将老版本的 Pump 的数据完全同步到下游。 - - 查询 Drainer 的 `status` 接口，示例命令如下： - - {{< copyable "shell-regular" >}} - - ```bash - curl 'http://172.16.10.49:8249/status' - ``` - - ``` - {"PumpPos":{"172.16.10.49:8250":{"offset":32686}},"Synced": true ,"DepositWindow":{"Upper":398907800202772481,"Lower":398907799455662081}} - ``` - - 如果返回的 `Synced` 为 true，则可以认为 Binlog 数据已经全部同步到了下游。 - -6. 启动新版本 Drainer； -7. 下线老版本的 Pump、Drainer 以及依赖的 Kafka 和 ZookeSeper。 diff --git a/dev/reference/tispark.md b/dev/reference/tispark.md deleted file mode 100644 index 7be75ed13ec0..000000000000 --- a/dev/reference/tispark.md +++ /dev/null @@ -1,333 +0,0 @@ ---- -title: TiSpark 用户指南 -category: reference ---- - -# TiSpark 用户指南 - -TiSpark 是 PingCAP 为解决用户复杂 OLAP 需求而推出的产品。它借助 Spark 平台，同时融合 TiKV 分布式集群的优势，和 TiDB 一起为用户一站式解决 HTAP (Hybrid Transactional/Analytical Processing) 的需求。TiSpark 依赖于 TiKV 集群和 Placement Driver (PD)，也需要你搭建一个 Spark 集群。 - -本文简单介绍如何部署和使用 TiSpark。本文假设你对 Spark 有基本认知。你可以参阅 [Apache Spark 官网](https://spark.apache.org/docs/latest/index.html) 了解 Spark 的相关信息。 - -## 概述 - -TiSpark 是将 Spark SQL 直接运行在分布式存储引擎 TiKV 上的 OLAP 解决方案。其架构图如下： - -![TiSpark Architecture](/media/tispark-architecture.png) - -+ TiSpark 深度整合了 Spark Catalyst 引擎, 可以对计算提供精确的控制，使 Spark 能够高效的读取 TiKV 中的数据，提供索引支持以实现高速的点查。 -+ 通过多种计算下推减少 Spark SQL 需要处理的数据大小，以加速查询；利用 TiDB 的内建的统计信息选择更优的查询计划。 -+ 从数据集群的角度看，TiSpark + TiDB 可以让用户无需进行脆弱和难以维护的 ETL，直接在同一个平台进行事务和分析两种工作，简化了系统架构和运维。 -+ 除此之外，用户借助 TiSpark 项目可以在 TiDB 上使用 Spark 生态圈提供的多种工具进行数据处理。例如，使用 TiSpark 进行数据分析和 ETL；使用 TiKV 作为机器学习的数据源；借助调度系统产生定时报表等等。 - -## 环境准备 - -现有 TiSpark 2.x 版本支持 Spark 2.3.x 和 Spark 2.4.x。如果你希望使用 Spark 2.1.x 版本，需使用 TiSpark 1.x。 - -TiSpark 需要 JDK 1.8+ 以及 Scala 2.11（Spark2.0+ 默认 Scala 版本）。 - -TiSpark 可以在 YARN，Mesos，Standalone 等任意 Spark 模式下运行。 - -## 推荐配置 - -本部分描述了 TiKV 与 TiSpark 集群分开部署、Spark 与 TiSpark 集群独立部署，以及TiSpark 与 TiKV 集群混合部署的建议配置。 - -### TiKV 与 TiSpark 集群分开部署的配置 - -对于 TiKV 与 TiSpark 分开部署的场景，可以参考如下建议配置： - -+ 硬件配置建议 - - 普通场景可以参考 [TiDB 和 TiKV 硬件配置建议](/dev/how-to/deploy/hardware-recommendations.md)，但是如果是偏重分析的场景，可以将 TiKV 节点增加到至少 64G 内存。 - -### Spark 与 TiSpark 集群独立部署的配置 - -关于 Spark 的详细硬件推荐配置请参考[官网](https://spark.apache.org/docs/latest/hardware-provisioning.html)，如下是 TiSpark 所需环境的简单描述： - -Spark 推荐 32G 内存以上的配额。请在配置中预留 25% 的内存给操作系统。 - -Spark 推荐每台计算节点配备 CPU 累计 8 到 16 核以上。你可以初始设定分配所有 CPU 核给 Spark。 - -Spark 的具体配置方式也请参考[官方说明](https://spark.apache.org/docs/latest/spark-standalone.html)。以下为根据 `spark-env.sh` 配置的范例： - -{{< copyable "" >}} - -``` -SPARK_EXECUTOR_CORES: 5 -SPARK_EXECUTOR_MEMORY: 10g -SPARK_WORKER_CORES: 5 -SPARK_WORKER_MEMORY: 10g -``` - -在 `spark-defaults.conf` 中，增加如下配置： - -{{< copyable "" >}} - -``` -spark.tispark.pd.addresses $your_pd_servers -spark.sql.extensions org.apache.spark.sql.TiExtensions -``` - -`your_pd_servers` 是用逗号分隔的 PD 地址，每个地址使用 `地址:端口` 的格式。 - -例如你有一组 PD 在`10.16.20.1`，`10.16.20.2`，`10.16.20.3`，那么 PD 配置格式是`10.16.20.1:2379,10.16.20.2:2379,10.16.20.3:2379`。 - -### TiSpark 与 TiKV 集群混合部署的配置 - -对于 TiKV 与 TiSpark 混合部署的场景，需在原有 TiKV 预留资源之外累加 Spark 所需部分，并分配 25% 的内存作为系统本身占用。 - -## 部署 TiSpark - -TiSpark 的 jar 包可以在 [TiSpark Releases 页面](https://github.com/pingcap/tispark/releases)下载对应版本的 jar 包并拷贝到合适的目录。 - -### 已有 Spark 集群的部署方式 - -如果在已有 Spark 集群上运行 TiSpark，无需重启集群。可以使用 Spark 的 `--jars` 参数将 TiSpark 作为依赖引入： - -{{< copyable "shell-regular" >}} - -```shell -spark-shell --jars $TISPARK_FOLDER/tispark-${name_with_version}.jar -``` - -### 没有 Spark 集群的部署方式 - -如果没有使用中的 Spark 集群，推荐使用 Saprk Standalone 方式部署。这里简单介绍下 Standalone 部署方式。如果遇到问题，可以去官网寻求[帮助](https://spark.apache.org/docs/latest/spark-standalone.html)；也欢迎在我们的 GitHub 上提 [issue](https://github.com/pingcap/tispark/issues/new)。 - -#### 下载安装包并安装 - -你可以在 [Download Apache Spark™ 页面](https://spark.apache.org/downloads.html)下载 Apache Spark。 - -对于 Standalone 模式且无需 Hadoop 支持，则选择 Spark 2.3.x 或者 Spark 2.4.x 且带有 Hadoop 依赖的 Pre-build with Apache Hadoop 2.x 任意版本。如有需要配合使用的 Hadoop 集群，则选择对应的 Hadoop 版本号。你也可以选择从源代码[自行构建](https://spark.apache.org/docs/latest/building-spark.html)以配合官方 Hadoop 2.x 之前的版本。 - -如果你已经有了 Spark 二进制文件，并且当前 PATH 为 SPARKPATH，需将 TiSpark jar 包拷贝到 `${SPARKPATH}/jars` 目录下。 - -#### 启动 Master - -在选中的 Spark Master 节点执行如下命令： - -{{< copyable "shell-regular" >}} - -```bash -cd $SPARKPATH -``` - -{{< copyable "shell-regular" >}} - -```bash -./sbin/start-master.sh -``` - -在这步完成以后，屏幕上会打印出一个 log 文件。检查 log 文件确认 Spark-Master 是否启动成功。你可以打开 查看集群信息（如果你没有改动 Spark-Master 默认 Port Numebr）。在启动 Spark-Slave 的时候，也可以通过这个面板来确认 Slave 是否已经加入集群。 - -#### 启动 Slave - -类似地，可以用如下命令启动 Spark-Slave 节点： - -{{< copyable "shell-regular" >}} - -```bash -./sbin/start-slave.sh spark://spark-master-hostname:7077 -``` - -命令返回以后，即可通过刚才的面板查看这个 Slave 是否已经正确地加入了 Spark 集群。在所有 Slave 节点重复刚才的命令。确认所有的 Slave 都可以正确连接 Master，这样你就拥有了一个 Standalone 模式的 Spark 集群。 - -#### Spark SQL shell 和 JDBC 服务器 - -当前版本的 TiSpark 可以直接使用 `spark-sql` 和 Spark 的 ThriftServer JDBC 服务器。 - -## 一个使用范例 - -假设你已经按照上述步骤成功启动了 TiSpark 集群，下面简单介绍如何使用 Spark SQL 来做 OLAP 分析。这里我们用名为 tpch 数据库中的 lineitem 表作为范例。 - -假设你的 PD 节点位于 192.168.1.100，端口为 2379，在 `$SPARK_HOME/conf/spark-defaults.conf` 加入： - -{{< copyable "" >}} - -``` -spark.tispark.pd.addresses 192.168.1.100:2379 -``` - -{{< copyable "" >}} - -``` -spark.sql.extensions org.apache.spark.sql.TiExtensions -``` - -然后在 Spark-Shell 里像原生 Spark 一样输入下面的命令： - -{{< copyable "" >}} - -```scala -spark.sql("use tpch") -``` - -{{< copyable "" >}} - -```scala -spark.sql("select count(*) from lineitem").show -``` - -结果为： - -``` -+-------------+ -| Count (1) | -+-------------+ -| 600000000 | -+-------------+ -``` - -Spark SQL 交互 Shell 和原生 Spark 一致： - -{{< copyable "" >}} - -```shell -spark-sql> use tpch; -``` - -``` -Time taken: 0.015 seconds -``` - -{{< copyable "" >}} - -```shell -spark-sql> select count(*) from lineitem; -``` - -``` -2000 -Time taken: 0.673 seconds, Fetched 1 row(s) -``` - -SQuirreLSQL 和 hive-beeline 可以使用 JDBC 连接 Thrift 服务器。 -例如，使用 beeline 连接： - -{{< copyable "shell-regular" >}} - -```shell -./beeline -``` - -``` -Beeline version 1.2.2 by Apache Hive -``` - -{{< copyable "" >}} - -```shell -beeline> !connect jdbc:hive2://localhost:10000 -``` - -{{< copyable "" >}} - -```shell -1: jdbc:hive2://localhost:10000> use testdb; -``` - -``` -+---------+--+ -| Result | -+---------+--+ -+---------+--+ -No rows selected (0.013 seconds) -``` - -{{< copyable "sql" >}} - -```sql -select count(*) from account; -``` - -``` -+-----------+--+ -| count(1) | -+-----------+--+ -| 1000000 | -+-----------+--+ -1 row selected (1.97 seconds) -``` - -## 和 Hive 一起使用 TiSpark - -TiSpark 可以和 Hive 混合使用。 -在启动 Spark 之前，需要添加 HADOOP_CONF_DIR 环境变量指向 Hadoop 配置目录并且将 `hive-site.xml` 拷贝到 `$SPARK_HOME/conf` 目录下。 - -``` -val tisparkDF = spark.sql("select * from tispark_table").toDF -tisparkDF.write.saveAsTable("hive_table") // save table to hive -spark.sql("select * from hive_table a, tispark_table b where a.col1 = b.col1").show // join table across Hive and Tispark -``` - -## 通过 JDBC 将 DataFrame 写入 TiDB - -暂时 TiSpark 不支持直接将数据写入 TiDB 集群，但可以使用 Spark 原生的 JDBC 支持进行写入： - -```scala -import org.apache.spark.sql.execution.datasources.jdbc.JDBCOptions - -val customer = spark.sql("select * from customer limit 100000") -// you might repartition source to make it balance across nodes -// and increase concurrency -val df = customer.repartition(32) -df.write -.mode(saveMode = "append") -.format("jdbc") -.option("driver", "com.mysql.jdbc.Driver") - // replace host and port as your and be sure to use rewrite batch -.option("url", "jdbc:mysql://127.0.0.1:4000/test?rewriteBatchedStatements=true") -.option("useSSL", "false") -// As tested, 150 is good practice -.option(JDBCOptions.JDBC_BATCH_INSERT_SIZE, 150) -.option("dbtable", s"cust_test_select") // database name and table name here -.option("isolationLevel", "NONE") // recommended to set isolationLevel to NONE if you have a large DF to load. -.option("user", "root") // TiDB user here -.save() -``` - -推荐将 `isolationLevel` 设置为 `NONE`，否则单一大事务有可能造成 TiDB 服务器内存溢出。 - -## 统计信息 - -TiSpark 可以使用 TiDB 的统计信息： - -1. 选择代价最低的索引或扫表访问 -2. 估算数据大小以决定是否进行广播优化 - -如果希望使用统计信息支持，需要确保所涉及的表已经被分析。请阅读[这份文档](https://pingcap.com/docs-cn/dev/reference/performance/statistics/)了解如何进行表分析。 - -从 TiSpark 2.0 开始，统计信息将会默认被读取。 - -统计信息将在 Spark Driver 进行缓存，请确定 Driver 内存足够缓存统计信息。 -可以在`spark-defaults.conf`中开启或关闭统计信息读取： - -| Property Name | Default | Description -| -------- | -----: | :----: | -| spark.tispark.statistics.auto_load | true | 是否默认进行统计信息读取 | - -## TiSpark FAQ - -- Q. 是独立部署还是和现有 Spark／Hadoop 集群共用资源？ - - A. 可以利用现有 Spark 集群无需单独部署，但是如果现有集群繁忙，TiSpark 将无法达到理想速度。 - -- Q. 是否可以和 TiKV 混合部署？ - - A. 如果 TiDB 以及 TiKV 负载较高且运行关键的线上任务，请考虑单独部署 TiSpark；并且考虑使用不同的网卡保证 OLTP 的网络资源不被侵占而影响线上业务。如果线上业务要求不高或者机器负载不大，可以考虑与 TiKV 混合部署。 - -- Q. Spark 执行中报 warning：WARN ObjectStore:568 - Failed to get database - - A. Warning 忽略即可，原因是 Spark 找不到对应的 hive 库，因为这个库是在 TIKV 中，而不是在 hive 中。可以考虑调整 [log4j 日志](https://github.com/pingcap/tidb-docker-compose/blob/master/tispark/conf/log4j.properties#L43)，将该参数添加到 spark 下 conf 里 log4j 文件(如果后缀是 template 那先 mv 成后缀 properties)。 - -- Q. Spark 执行中报 java.sql.BatchUpdateException: Data Truncated - - A. 写入的数据长度超过了数据库定义的数据类型的长度，可以确认 target table 的字段长度，进行调整。 - -- Q. TiSpark 任务是否默认读取 Hive 的元数据？ - - A. TiSpark 通过读取 hive-site 里的 meta 来搜寻 hive 的库。如果搜寻不到，就通过读取 tidb meta 搜寻 tidb 库。如果不需要该行为，可不在 hive site 中配置 hive 的 meta。 - -- Q. TiSpark 执行 Spark 任务时报：Error：java.io.InvalidClassException: com.pingcap.tikv.region.TiRegion; local class incompatible: stream classdesc serialVersionUID ... - - A. 该报错日志中显示 serialVersionUID 冲突，说明存在不同版本的 class 和 TiRegion。因为 TiRegion 是 TiSpark 独有的，所以可能存在多个版本的 TiSpark 包。要解决该报错，请确保集群中各节点的 TiSpark 依赖包版本一致。 diff --git a/dev/reference/tools/br/br.md b/dev/reference/tools/br/br.md deleted file mode 100644 index 9454f93ee557..000000000000 --- a/dev/reference/tools/br/br.md +++ /dev/null @@ -1,400 +0,0 @@ ---- -title: 使用 BR 进行备份与恢复 -summary: 了解如何使用 BR 工具进行集群数据备份和恢复。 -category: how-to -aliases: ['/docs-cn/dev/how-to/maintain/backup-and-restore/br/'] ---- - -# 使用 BR 进行备份与恢复 - -Backup & Restore（以下简称 BR）是 TiDB 分布式备份恢复的命令行工具，用于对 TiDB 集群进行数据备份和恢复。相比 [`mydumper`/`loader`](/dev/how-to/maintain/backup-and-restore/mydumper-lightning.md)，BR 更适合大数据量的场景。本文档介绍了 BR 的使用限制、工作原理、命令行描述、备份恢复用例以及最佳实践。 - -## 使用限制 - -- BR 只支持 TiDB v3.1 及以上版本。 -- 目前只支持在全新的集群上执行恢复操作。 -- BR 备份最好串行执行，否则不同备份任务之间会相互影响。 - -## 推荐部署配置 - -- 推荐 BR 部署在 PD 节点上。 -- 推荐使用一块高性能 SSD 网盘，挂载到 BR 节点和所有 TiKV 节点上，网盘推荐万兆网卡，否则带宽有可能成为备份恢复时的性能瓶颈。 - -## 下载 Binary - -详见[下载链接](/dev/reference/tools/download.md#快速备份和恢复br)。 - -## 工作原理 - -BR 是分布式备份恢复的工具，它将备份或恢复操作命令下发到各个 TiKV 节点。TiKV 收到命令后执行相应的备份或恢复操作。在一次备份或恢复中，各个 TiKV 节点都会有一个对应的备份路径，TiKV 备份时产生的备份文件将会保存在该路径下，恢复时也会从该路径读取相应的备份文件。 - -### 备份原理 - -BR 执行备份操作时，会先从 PD 获取到以下信息： - -- 当前的 TS 作为备份快照的时间点 -- 当前集群的 TiKV 节点信息 - -然后 BR 根据这些信息，在内部启动一个 TiDB 实例，获取对应 TS 的数据库或表信息，同时过滤掉系统库 (`information_schema`，`performance_schema`，`mysql`)。 - -此时根据备份子命令，会有两种备份逻辑： - -- 全量备份：BR 遍历全部库表，并且根据每一张表构建需要备份的 KV Range -- 单表备份：BR 根据该表构建需要备份的 KV Range - -最后，BR 将需要备份的 KV Range 收集后，构造完整的备份请求分发给集群内的 TiKV 节点。 - -该请求的主要结构如下： - -``` -BackupRequest{ - ClusterId, // 集群 ID - StartKey, // 备份起始点，startKey 会被备份 - EndKey, // 备份结束点，endKey 不会被备份 - EndVersion, // 备份快照时间点 - StorageBackend, // 备份文件存储地址 - RateLimit, // 备份速度 (MB/s) - Concurrency, // 执行备份操作的线程数（默认为 4） -} -``` - -TiKV 节点收到备份请求后，会遍历节点上所有的 Region Leader，找到和请求中 KV Range 有重叠范围的 Region，将该范围下的部分或者全部数据进行备份，在备份路径下生成对应的 SST 文件。 - -TiKV 节点在备份完对应 Region Leader 的数据后将元信息返回给 BR。BR 将这些元信息收集并存储进 `backupmeta` 文件中，等待恢复时使用。 - -如果执行命令时开启了 checksum，那么 BR 在最后会对备份的每一张表计算 checksum 用于校验。 - -#### 备份文件类型 - -备份路径下会生成以下两种类型文件： - -- SST 文件：存储 TiKV 备份下来的数据信息 -- `backupmeta` 文件：存储本次备份的元信息，包括备份文件数、备份文件的 Key 区间、备份文件大小和备份文件 Hash (sha256) 值 - -#### SST 文件命名格式 - -SST 文件以 `storeID_regionID_regionEpoch_keyHash_cf` 的格式命名。格式名的解释如下： - -- storeID：TiKV 节点编号 -- regionID：Region 编号 -- regionEpoch：Region 版本号 -- keyHash：Range startKey 的 Hash (sha256) 值，确保唯一性 -- cf：RocksDB 的 ColumnFamily（默认为 `default` 或 `write`） - -### 恢复原理 - -BR 执行恢复操作时，会按顺序执行以下任务： - -1. 解析备份路径下的 backupMeta 文件，根据解析出来的库表信息，在内部启动一个 TiDB 实例在新集群创建对应的库表。 - -2. 把解析出来的 SST 文件，根据表进行聚合。 - -3. 根据 SST 文件的 Key Range 进行预切分 Region，使得每个 Region 至少对应一个 SST 文件。 - -4. 遍历要恢复的每一张表，以及这个表对应的 SST 文件。 - -5. 找到该文件对应的 Region，发送下载文件的请求到对应的 TiKV 节点，并在下载成功后，发送加载请求。 - -TiKV 收到加载 SST 文件的请求后，利用 Raft 机制保证加载 SST 数据的强一致性。在加载成功后，下载下来的 SST 文件会被异步删除。 - -在执行完恢复操作后，BR 会对恢复后的数据进行 checksum 计算，用于和备份下来的数据进行对比。 - -![br-arch](/media/br-arch.png) - -## BR 命令行描述 - -一条 `br` 命令是由子命令、选项和参数组成的。子命令即不带 `-` 或者 `--` 的字符。选项即以 `-` 或者 `--` 开头的字符。参数即子命令或选项字符后紧跟的、并传递给命令和选项的字符。 - -以下是一条完整的 `br` 命令行： - -`br backup full --pd "${PDIP}:2379" -s "local:///tmp/backup"` - -命令行各部分的解释如下： - -* `backup`：`br` 的子命令 -* `full`：`backup` 的子命令 -* `-s` 或 `--storage`：备份保存的路径 -* `"local:///tmp/backup"`：`-s` 的参数，保存的路径为本地磁盘的 `/tmp/backup` -* `--pd`：PD 服务地址 -* `"${PDIP}:2379"`：`--pd` 的参数 - -### 命令和子命令 - -BR 由多层命令组成。目前，BR 包含 `backup`、`restore` 和 `version` 三个子命令: - -* `br backup` 用于备份 TiDB 集群 -* `br restore` 用于恢复 TiDB 集群 -* `br version` 用于查看 BR 工具版本信息 - -以上三个子命令可能还包含这些子命令： - -* `full`：可用于备份或恢复全部数据。 -* `db`：可用于备份或恢复集群中的指定数据库。 -* `table`：可用于备份或恢复集群指定数据库中的单张表。 - -### 常用选项 - -* `--pd`：用于连接的选项，表示 PD 服务地址，例如 `"${PDIP}:2379"`。 -* `-h`/`--help`：获取所有命令和子命令的使用帮助。例如 `br backup --help`。 -* `--ca`：指定 PEM 格式的受信任 CA 的证书文件路径。 -* `--cert`：指定 PEM 格式的 SSL 证书文件路径。 -* `--key`：指定 PEM 格式的 SSL 证书密钥文件路径。 -* `--status-addr`：BR 向 Prometheus 提供统计数据的监听地址。 - -## 备份集群数据 - -使用 `br backup` 命令来备份集群数据。可选择添加 `full` 或 `table` 子命令来指定备份的范围：全部集群数据或单张表的数据。 - -如果备份时间可能超过设定的 [`tikv_gc_life_time`](/dev/reference/garbage-collection/configuration.md#tikv_gc_life_time)（默认 `10m0s`），则需要将该参数调大。 - -例如，将 `tikv_gc_life_time` 调整为 `720h`： - -{{< copyable "sql" >}} - -```sql -mysql -h${TiDBIP} -P4000 -u${TIDB_USER} ${password_str} -Nse \ - "update mysql.tidb set variable_value='720h' where variable_name='tikv_gc_life_time'"; -``` - -### 备份全部集群数据 - -要备份全部集群数据，可使用 `br backup full` 命令。该命令的使用帮助可以通过 `br backup full -h` 或 `br backup full --help` 来获取。 - -用例：将所有集群数据备份到各个 TiKV 节点的 `/tmp/backup` 路径，同时也会将备份的元信息文件 `backupmeta` 写到该路径下。 - -{{< copyable "shell-regular" >}} - -```shell -br backup full \ - --pd "${PDIP}:2379" \ - --storage "local:///tmp/backup" \ - --ratelimit 120 \ - --concurrency 4 \ - --log-file backupfull.log -``` - -以上命令中，`--ratelimit` 和 `--concurrency` 选项限制了**每个 TiKV** 执行备份任务的速度上限（单位 MiB/s）和并发数上限。`--log-file` 选项指定把 BR 的 log 写到 `backupfull.log` 文件中。 - -备份期间有进度条在终端中显示。当进度条前进到 100% 时，说明备份已完成。在完成备份后，BR 为了确保数据安全性，还会校验备份数据。进度条效果如下： - -```shell -br backup full \ - --pd "${PDIP}:2379" \ - --storage "local:///tmp/backup" \ - --ratelimit 120 \ - --concurrency 4 \ - --log-file backupfull.log -Full Backup <---------/................................................> 17.12%. -``` - -### 备份单个数据库的数据 - -要备份集群中指定单个数据库的数据，可使用 `br backup db` 命令。同样可通过 `br backup db -h` 或 `br backup db --help` 来获取子命令 `db` 的使用帮助。 - -用例：将数据库 `test` 备份到各个 TiKV 节点的 `/tmp/backup` 路径，同时也会将备份的元信息文件 `backupmeta` 写到该路径下。 - -{{< copyable "shell-regular" >}} - -```shell -br backup db \ - --pd "${PDIP}:2379" \ - --db test \ - --storage "local:///tmp/backup" \ - --ratelimit 120 \ - --concurrency 4 \ - --log-file backuptable.log -``` - -`db` 子命令的选项为 `--db`，用来指定数据库名。其他选项的含义与[备份全部集群数据](#备份全部集群数据)相同。 - -备份期间有进度条在终端中显示。当进度条前进到 100% 时，说明备份已完成。在完成备份后，BR 为了确保数据安全性，还会校验备份数据。 - -### 备份单张表的数据 - -要备份集群中指定单张表的数据，可使用 `br backup table` 命令。同样可通过 `br backup table -h` 或 `br backup table --help` 来获取子命令 `table` 的使用帮助。 - -用例：将表 `test.usertable` 备份到各个 TiKV 节点的 `/tmp/backup` 路径，同时也会将备份的元信息文件 `backupmeta` 写到该路径下。 - -{{< copyable "shell-regular" >}} - -```shell -br backup table \ - --pd "${PDIP}:2379" \ - --db test \ - --table usertable \ - --storage "local:///tmp/backup" \ - --ratelimit 120 \ - --concurrency 4 \ - --log-file backuptable.log -``` - -`table` 子命令有 `--db` 和 `--table` 两个选项，分别用来指定数据库名和表名。其他选项的含义与[备份全部集群数据](#备份全部集群数据)相同。 - -备份期间有进度条在终端中显示。当进度条前进到 100% 时，说明备份已完成。在完成备份后，BR 为了确保数据安全性，还会校验备份数据。 - -## 恢复集群数据 - -使用 `br restore` 命令来恢复备份数据。可选择添加 `full`、`db` 或 `table` 子命令来指定恢复操作的范围：全部集群数据、某个数据库或某张数据表。 - -> **注意：** -> -> 如果备份的集群没有网络存储，在恢复前需要将所有备份的 SST 文件拷贝到各个 TiKV 节点上 `--storage` 指定的目录下。 - -### 恢复全部备份数据 - -要将全部备份数据恢复到集群中来，可使用 `br restore full` 命令。该命令的使用帮助可以通过 `br restore full -h` 或 `br restore full --help` 来获取。 - -用例：将 `/tmp/backup` 路径中的全部备份数据恢复到集群中。 - -{{< copyable "shell-regular" >}} - -```shell -br restore full \ - --pd "${PDIP}:2379" \ - --storage "local:///tmp/backup" \ - --concurrency 128 \ - --log-file restorefull.log -``` - -`--concurrency` 指定了该恢复任务内部的子任务的并发数。`--log-file` 选项指定把 BR 的 log 写到 `restorefull.log` 文件中。 - -恢复期间还有进度条会在终端中显示，当进度条前进到 100% 时，说明恢复已完成。在完成恢复后，BR 为了确保数据安全性，还会校验恢复数据。进度条效果如下： - -```shell -br restore full \ - --pd "${PDIP}:2379" \ - --storage "local:///tmp/backup" \ - --log-file restorefull.log -Full Restore <---------/...............................................> 17.12%. -``` - -### 恢复单个数据库的数据 - -要将备份数据中的某个数据库恢复到集群中，可以使用 `br restore db` 命令。该命令的使用帮助可以通过 `br restore db -h` 或 `br restore db --help` 来获取。 - -用例：将 `/tmp/backup` 路径中备份数据中的某个数据库恢复到集群中。 - -{{< copyable "shell-regular" >}} - -```shell -br restore db \ - --pd "${PDIP}:2379" \ - --db "test" \ - --storage "local:///tmp/backup" \ - --log-file restorefull.log -``` - -以上命令中 `--db` 选项指定了需要恢复的数据库名字。其余选项的含义与[恢复全部备份数据](#恢复全部备份数据)相同。 - -### 恢复单张表的数据 - -要将备份数据中的某张数据表恢复到集群中，可以使用 `br restore table` 命令。该命令的使用帮助可通过 `br restore table -h` 或 `br restore table --help` 来获取。 - -用例：将 `/tmp/backup` 路径下的备份数据中的某个数据表恢复到集群中。 - -{{< copyable "shell-regular" >}} - -```shell -br restore table \ - --pd "${PDIP}:2379" \ - --db "test" \ - --table "usertable" \ - --storage "local:///tmp/backup" \ - --log-file restorefull.log -``` - -以上命令中 `--table` 选项指定了需要恢复的表名。其余选项的含义与[恢复某个数据库](#恢复某个数据库)相同。 - -## 最佳实践 - -- 推荐在 `-s` 指定的备份路径上挂载一个共享存储，例如 NFS。这样能方便收集和管理备份文件。 -- 在使用共享存储时，推荐使用高吞吐的存储硬件，因为存储的吞吐会限制备份或恢复的速度。 -- 推荐在业务低峰时执行备份操作，这样能最大程度地减少对业务的影响。 - -更多最佳实践内容，参见 [BR 备份与恢复场景示例](/dev/reference/tools/br/use-cases.md)。 - -## 备份和恢复示例 - -本示例展示如何对已有的集群数据进行备份和恢复操作。可以根据机器性能、配置、数据规模来预估一下备份和恢复的性能。 - -### 数据规模和机器配置 - -假设对 TiKV 集群中的 10 张表进行备份和恢复。每张表有 500 万行数据，数据总量为 35 GB。 - -```sql -MySQL [sbtest]> show tables; -+------------------+ -| Tables_in_sbtest | -+------------------+ -| sbtest1 | -| sbtest10 | -| sbtest2 | -| sbtest3 | -| sbtest4 | -| sbtest5 | -| sbtest6 | -| sbtest7 | -| sbtest8 | -| sbtest9 | -+------------------+ - -MySQL [sbtest]> select count(*) from sbtest1; -+----------+ -| count(*) | -+----------+ -| 5000000 | -+----------+ -1 row in set (1.04 sec) -``` - -表结构如下： - -```sql -CREATE TABLE `sbtest1` ( - `id` int(11) NOT NULL AUTO_INCREMENT, - `k` int(11) NOT NULL DEFAULT '0', - `c` char(120) NOT NULL DEFAULT '', - `pad` char(60) NOT NULL DEFAULT '', - PRIMARY KEY (`id`), - KEY `k_1` (`k`) -) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=5138499 -``` - -示例假设有 4 个 TiKV 节点，每个节点配置如下： - -| CPU | 内存 | 磁盘 | 副本数 | -| :--- | :--- | :--- | :--- | -| 16 核 | 32 GB | SSD | 3 | - -### 备份示例 - -- 备份前需确认已将 GC 时间调长，确保备份期间不会因为数据丢失导致中断 -- 备份前需确认 TiDB 集群没有执行 DDL 操作 - -执行以下命令对集群中的全部数据进行备份： - -{{< copyable "shell-regular" >}} - -``` -bin/br backup full -s local:///tmp/backup --pd "${PDIP}:2379" --log-file backup.log -``` - -``` -[INFO] [collector.go:165] ["Full backup summary: total backup ranges: 2, total success: 2, total failed: 0, total take(s): 0.00, total kv: 4, total size(Byte): 133, avg speed(Byte/s): 27293.78"] ["backup total regions"=2] ["backup checksum"=1.640969ms] ["backup fast checksum"=227.885µs] -``` - -### 恢复示例 - -恢复操作前，需确认待恢复的 TiKV 集群是全新的集群。 - -执行以下命令对全部数据进行恢复： - -{{< copyable "shell-regular" >}} - -``` -bin/br restore full -s local:///tmp/backup --pd "${PDIP}:2379" --log-file restore.log -``` - -``` -[INFO] [collector.go:165] ["Full Restore summary: total restore tables: 1, total success: 1, total failed: 0, total take(s): 0.26, total kv: 20000, total size(MB): 10.98, avg speed(MB/s): 41.95"] ["restore files"=3] ["restore ranges"=2] ["split region"=0.562369381s] ["restore checksum"=36.072769ms] -``` diff --git a/dev/reference/tools/br/use-cases.md b/dev/reference/tools/br/use-cases.md deleted file mode 100644 index fff5ac6d99f7..000000000000 --- a/dev/reference/tools/br/use-cases.md +++ /dev/null @@ -1,415 +0,0 @@ ---- -title: BR 备份与恢复场景示例 -category: reference -aliases: ['/docs-cn/dev/how-to/maintain/backup-and-restore/br-best-practices/','/docs-cn/dev/reference/tools/br/br-best-practices/'] ---- - -# BR 备份与恢复场景示例 - -[Backup & Restore](/dev/reference/tools/br/br.md)（下文简称 BR）一款分布式的快速备份和恢复工具。本文展示了[四种备份和恢复场景](#使用场景)下的 BR 操作过程，以帮助读者达到以下目标： - -* 正确使用网络盘或本地盘进行备份或恢复 -* 通过相关监控指标了解备份或恢复的状态 -* 了解在备份或恢复时如何调优性能 -* 处理备份时可能发生的异常 - -> **注意：** -> -> 使用 BR 时应注意[使用限制](/dev/reference/tools/br/br.md#使用限制)。 - -## 目标读者 - -读者需要对 TiDB 和 TiKV 有一定的了解。在阅读本文前，推荐先阅读[使用 BR 进行备份与恢复](/dev/reference/tools/br/br.md)。 - -## 环境准备 - -本部分介绍推荐的 TiDB 的部署方式、示例中的集群版本、TiKV 集群硬件信息和集群配置。读者可根据自己的硬件和配置来预估备份恢复的性能。 - -### 部署方式 - -推荐使用 [TiDB Ansible](/dev/how-to/deploy/orchestrated/ansible.md) 部署 TiDB 集群，再下载 [TiDB Toolkit](/dev/reference/tools/download.md#快速备份和恢复br) 获取 BR 应用。 - -### 集群版本 - -* TiKV: v3.1.0-beta.1 -* PD: v3.1.0-beta.1 -* br: v3.1.0-beta.1 - -### TiKV 集群硬件信息 - -* 操作系统：CentOS Linux release 7.6.1810 (Core) -* CPU：16-Core Common KVM processor -* RAM：32GB -* 硬盘：500G SSD * 2 -* 网卡：10000MB/s - -### 配置 - -BR 可以直接将命令下发到 TiKV 集群来执行备份和恢复，不依赖 TiDB server 组件，因此无需对 TiDB server 进行配置。 - -* TiKV: 默认配置 -* PD : 默认配置 - -## 使用场景 - -本文描述以下四种使用场景： - -* [将单表数据备份到网络盘（推荐）](#将单表数据备份到网络盘推荐) -* [从网络磁盘恢复备份数据（推荐）](#从网络磁盘恢复备份数据推荐) -* [将单表数据备份到本地磁盘](#将单表数据备份到本地磁盘) -* [从本地磁盘恢复备份数据](#从本地磁盘恢复备份数据) - -推荐使用网络盘来进行备份和恢复操作，这样可以省去收集备份数据文件的繁琐步骤。尤其在 TiKV 集群规模较大的情况下，使用网络盘可以大幅提升操作效率。 - -> **注意：** -> -> 在进行备份或恢复操作前，需要先进行备份或恢复的准备工作。 - -### 备份前的准备工作 - -`br backup` 命令的详细使用方法请参考 [BR 命令行描述](/dev/reference/tools/br/br.md#br-命令行描述)。 - -1. 运行 `br backup` 命令前，查询 TiDB 集群的 [`tikv_gc_life_time`](/dev/reference/garbage-collection/configuration.md#tikv_gc_life_time) 配置项的值，并使用 MySQL 客户端将该项调整至合适的值，确保备份期间不会发生 [Garbage Collection](/dev/reference/garbage-collection/overview.md) (GC)。 - - {{< copyable "sql" >}} - - ```sql - SELECT * FROM mysql.tidb WHERE VARIABLE_NAME = 'tikv_gc_life_time'; - UPDATE mysql.tidb SET VARIABLE_VALUE = '720h' WHERE VARIABLE_NAME = 'tikv_gc_life_time'; - ``` - -2. 在备份完成后，将该参数调回原来的值。 - - {{< copyable "sql" >}} - - ```sql - update mysql.tidb set VARIABLE_VALUE = '10m' where VARIABLE_NAME = 'tikv_gc_life_time'; - ``` - -### 恢复前的准备工作 - -`br restore` 命令的详细使用方法请参考 [BR 命令行描述](/dev/reference/tools/br/br.md#br-命令行描述)。 - -> **注意：** -> -> 运行 `br restore` 前检查新集群确保没有同名的表。 - -### 将单表数据备份到网络盘（推荐） - -使用 `br backup` 命令，将单表数据 `--db batchmark --table order_line` 备份到指定的网络盘路径 `local:///br_data` 下。 - -#### 前置要求 - -* 配置一台高性能 SSD 硬盘主机为 NFS server 存储数据。其他所有 BR 节点和 TiKV 节点为 NFS client，挂载相同的路径（例如 `/br_data`）到 NFS server 上以访问 NFS server。 -* NFS server 和 NFS client 间的数据传输速率至少要达到备份集群的 `TiKV 实例数 * 150MB/s`。否则网络 I/O 有可能成为性能瓶颈。 - -#### 部署拓扑 - -部署拓扑如下图所示： - -![img](/media/br/backup-nfs-deploy.png) - -#### 运行备份 - -备份操作前，在 TiDB 中使用 `admin checksum table order_line` 命令获得备份目标表 `--db batchmark --table order_line` 的统计信息。统计信息示例如下： - -![img](/media/br/total-data.png) - -运行 BR 备份命令： - -{{< copyable "shell-regular" >}} - -```shell -bin/br backup table --db batchmark --table order_line -s local:///br_data --pd 172.16.5.198:2379 --log-file backup-nfs.log -``` - -#### 备份过程中的运行指标 - -在 BR 备份过程中，需关注以下监控面版中的运行指标来了解备份的状态。 - -**Backup CPU Utilization**：参与备份的 TiKV 节点（例如 backup-worker 和 backup-endpoint）的 CPU 使用率。 - -![img](/media/br/backup-cpu.png) - -**IO Utilization**：参与备份的 TiKV 节点的 I/O 使用率。 - -![img](/media/br/backup-io.png) - -**BackupSST Generation Throughput**：参与备份的 TiKV 节点生成 backupSST 文件的吞吐。正常时单个 TiKV 节点的吞吐在 150MB/s 左右。 - -![img](/media/br/backup-throughput.png) - -**One Backup Range Duration**：备份一个 range 的操作耗时，包括扫描耗时 (scan KV) 和保存耗时（保存为 backupSST 文件）。 - -![img](/media/br/backup-range-duration.png) - -**One Backup Subtask Duration**： 一次备份任务会被拆分成多个子任务。该监控项显示子任务的耗时。 - -> **注意：** -> -> * 虽然本次任务是备份单表，但因为表中有 3 个索引，所以正常会拆分成 4 个子任务。 -> * 下图中有 13 个点，说明有 9 次 (13-4) 重试。备份过程中可能发生 Region 调度行为，少量重试是正常的。 - -![img](/media/br/backup-subtask-duration.png) - -**Backup Errors**：备份过程中的错误。正常时无错误。即使出现少量错误，备份操作也有重试机制，可能会导致备份时间增加，但不会影响备份的正确性。 - -![img](/media/br/backup-errors.png) - -**Checksum Request Duration**：对备份集群执行 admin checksum 的耗时统计。 - -![img](/media/br/checksum-duration.png) - -#### 结果解读 - -使用 BR 前已设置日志的存放路径。从路径下存放的日志中可以获取此次备份的相关统计信息。在日志中搜关键字 "summary"，可以看到以下信息： - -``` -["Table backup summary: total backup ranges: 4, total success: 4, total failed: 0, total take(s): 986.43, total kv: 5659888624, total size(MB): 353227.18, avg speed(MB/s): 358.09"] ["backup total regions"=7196] ["backup checksum"=6m28.291772955s] ["backup fast checksum"=24.950298ms] -``` - -以上日志信息中包含以下内容： - -* 备份耗时：`total take(s): 986.43` -* 数据大小：`total size(MB): 353227.18` -* 备份吞吐：`avg speed(MB/s): 358.09` -* 校验耗时：`take=6m28.29s` - -通过以上数据可以计算得到单个 TiKV 实例的吞吐为：`avg speed(MB/s)`/`tikv_count` = `89`。 - -#### 性能调优 - -如果 TiKV 的资源使用没有出现明显的瓶颈（例如[备份过程中的运行指标](#备份过程中的运行指标)中的 **Backup CPU Utilization** 最高为 `1500%` 左右，**IO Utilization** 普遍低于 `30%`），可以尝试调大 `--concurrency` 参数以进行性能调优。该方法不适用于存在许多小表的场景。 - -示例如下： - -{{< copyable "shell-regular" >}} - -```shell -bin/br backup table --db batchmark --table order_line -s local:///br_data/ --pd 172.16.5.198:2379 --log-file backup-nfs.log --concurrency 16 -``` - -![img](/media/br/backup-diff.png) - -![img](/media/br/backup-diff2.png) - -性能调优后的结果如下所示（保持数据大小不变）： - -* 备份耗时：`total take(s)` 从 `986.43` 减少到 `535.53` -* 数据大小：`total size(MB): 353227.18` -* 备份吞吐：`avg speed(MB/s)` 从 `358.09` 提升到 `659.59` -* 单个 TiKV 实例的吞吐：`avg speed(MB/s)/tikv_count` 从 `89` 提升到 `164.89` - -### 从网络磁盘恢复备份数据（推荐） - -使用 `br restore` 命令，将一份完整的备份数据恢复到一个离线集群。暂不支持恢复到在线集群。 - -#### 前置要求 - -无 - -#### 部署拓扑 - -部署拓扑如下图所示： - -![img](/media/br/restore-nfs-deploy.png) - -#### 运行恢复 - -运行 `br restore` 命令： - -{{< copyable "shell-regular" >}} - -```shell -bin/br restore table --db batchmark --table order_line -s local:///br_data --pd 172.16.5.198:2379 --log-file restore-nfs.log -``` - -#### 恢复过程中的运行指标 - -在 BR 恢复过程中，需关注以下监控面版中的运行指标来了解恢复的状态。 - -**CPU Utilization**：参与恢复的 TiKV 节点 CPU 使用率。 - -![img](/media/br/restore-cpu.png) - -**IO Utilization**：参与恢复的 TiKV 节点的 I/O 使用率。 - -![img](/media/br/restore-io.png) - -**Region** 分布：Region 分布越均匀，说明恢复资源利用越充分。 - -![img](/media/br/restore-region.png) - -**Process SST Duration**：处理 SST 文件的延迟。恢复一张表时时，如果 `tableID` 发生了变化，需要对 `tableID` 进行 `rewrite`，否则会进行 `rename`。通常 `rewrite` 延迟要高于 `rename` 的延迟。 - -![img](/media/br/restore-process-sst.png) - -**DownLoad SST Throughput**：从 External Storage 下载 SST 文件的吞吐。 - -![img](/media/br/restore-download-sst.png) - -**Restore Errors**：恢复过程中的错误。 - -![img](/media/br/restore-errors.png) - -**Checksum Request duration**：对恢复集群执行 admin checksum 的耗时统计，会比备份时的 checksum 延迟高。 - -![img](/media/br/restore-checksum.png) - -#### 结果解读 - -使用 BR 前已设置日志的存放路径。从路径下存放的日志中可以获取此次恢复的相关统计信息。在日志中搜关键字 "summary"，可以看到以下信息： - -``` -["Table Restore summary: total restore tables: 1, total success: 1, total failed: 0, total take(s): 961.37, total kv: 5659888624, total size(MB): 353227.18, avg speed(MB/s): 367.42"] ["restore files"=9263] ["restore ranges"=6888] ["split region"=49.049182743s] ["restore checksum"=6m34.879439498s] -``` - -以上日志信息中包含以下内容： - -* 恢复耗时：`total take(s):961.37` -* 数据大小：`total size(MB): 353227.18` -* 恢复吞吐：`avg speed(MB/s): 367.42` -* `Region Split` 耗时：`take=49.049182743s` -* 校验耗时：`take=6m34.879439498s` - -根据上表数据可以计算得到： - -* 单个 TiKV 吞吐：`avg speed(MB/s)`/`tikv_count` = `91.8` -* 单个 TiKV 平均恢复速度：`total size(MB)`/(`split time` + `restore time`)/`tikv_count` = `87.4` - -#### 性能调优 - -如果 TiKV 资源使用没有明显的瓶颈，可以尝试调大 `--concurrency` 参数（默认为 `128`），示例如下： - -{{< copyable "shell-regular" >}} - -```shell -bin/br restore table --db batchmark --table order_line -s local:///br_data/ --pd 172.16.5.198:2379 --log-file restore-concurrency.log --concurrency 1024 -``` - -性能调优后的结果如下表所示（保持数据大小不变）： - -* 恢复耗时：`total take(s)` 从 `961.37` 减少到 `443.49` -* 恢复吞吐：`avg speed(MB/s)` 从 `367.42` 提升到 `796.47` -* 单个 TiKV 实例的吞吐：`avg speed(MB/s)`/`tikv_count` 从 `91.8` 提升到 `199.1` -* 单个 TiKV 实例的平均恢复速度：`total size(MB)`/(`split time` + `restore time`)/`tikv_count` 从 `87.4` 提升到 `162.3` - -### 将单表数据备份到本地磁盘 - -使用 `br backup 命令`，将单表数据 `--db batchmark --table order_line` 备份到指定的本地磁盘路径 `local:///home/tidb/backup_local` 下。 - -#### 前置要求 - -* 各个 TiKV 节点有单独的磁盘用来存放 backupSST 数据。 -* `backup_endpoint` 节点有单独的磁盘用来存放备份的 `backupmeta` 文件。 -* TiKV 和 `backup_endpoint` 节点需要有相同的备份目录，例如 `/home/tidb/backup_local`。 - -#### 部署拓扑 - -![img](/media/br/backup-local-deploy.png) - -#### 运行备份 - -备份前在 TiDB 里通过 `admin checksum table order_line` 获得备份的目标表 `--db batchmark --table order_line` 的统计信息。统计信息示例如下： - -![img](/media/br/total-data.png) - -运行 `br backup` 命令： - -{{< copyable "shell-regular" >}} - -```shell -bin/br backup table --db batchmark --table order_line -s local:///home/tidb/backup_local/ --pd 172.16.5.198:2379 --log-file backup_local.log -``` - -运行备份时，参考[备份过程中的运行指标](#备份过程中的运行指标)对相关指标进行监控，以了解备份状态。 - -#### 结果解读 - -使用 BR 前已设置日志的存放路径。从该路径下存放的日志获取此次备份的相关统计信息。在日志中搜关键字 "summary"，可以看到以下信息： - -``` -["Table backup summary: total backup ranges: 4, total success: 4, total failed: 0, total take(s): 551.31, total kv: 5659888624, total size(MB): 353227.18, avg speed(MB/s): 640.71"] ["backup total regions"=6795] ["backup checksum"=6m33.962719217s] ["backup fast checksum"=22.995552ms] -``` - -以上日志信息中包含以下内容： - -* 备份耗时：`total take(s): 551.31` -* 数据大小：`total size(MB): 353227.18` -* 备份吞吐：`avg speed(MB/s): 640.71` -* 校验耗时：`take=6m33.962719217s` - -根据上表数据可以计算得到单个 TiKV 实例的吞吐：`avg speed(MB/s)`/`tikv_count` = `160`。 - -### 从本地磁盘恢复备份数据 - -使用 `br restore` 命令，将一份完整的备份数据恢复到一个离线集群。暂不支持恢复到在线集群。 - -#### 前置要求 - -* 集群中没有与备份数据相同的库表。目前 BR 不支持 table route。 -* 集群中各个 TiKV 节点有单独的磁盘用来存放要恢复的 backupSST 数据。 -* `restore_endpoint` 节点有单独的磁盘用来存放要恢复的 `backupmeta` 文件。 -* 集群中 TiKV 和 `restore_endpoint` 节点需要有相同的备份目录，例如 `/home/tidb/backup_local/`。 - -如果备份数据存放在本地磁盘，那么需要执行以下的步骤： - -1. 汇总所有 backupSST 文件到一个统一的目录下。 -2. 将汇总后的 backupSST 文件到复制到集群的所有 TiKV 节点下。 -3. 将 `backupmeta` 文件复制到到 `restore endpoint` 节点下。 - -#### 部署拓扑 - -![img](/media/br/restore-local-deploy.png) - -#### 运行恢复 - -运行 `br restore` 命令： - -{{< copyable "shell-regular" >}} - -```shell -bin/br restore table --db batchmark --table order_line -s local:///home/tidb/backup_local/ --pd 172.16.5.198:2379 --log-file restore_local.log -``` - -运行恢复时，参考[恢复过程中的运行指标](#恢复过程中的运行指标)对相关指标进行监控，以了解恢复状态。 - -#### 结果解读 - -使用 BR 前已设置日志的存放路径。从该日志中可以获取此次恢复的相关统计信息。在日志中搜关键字 "summary"，可以看到以下信息： - -``` -["Table Restore summary: total restore tables: 1, total success: 1, total failed: 0, total take(s): 908.42, total kv: 5659888624, total size(MB): 353227.18, avg speed(MB/s): 388.84"] ["restore files"=9263] ["restore ranges"=6888] ["split region"=58.7885518s] ["restore checksum"=6m19.349067937s] -``` - -以上日志信息中包含以下内容： - -* 恢复耗时：`total take(s): 908.42` -* 数据大小：`total size(MB): 353227.18` -* 恢复吞吐：`avg speed(MB/s): 388.84` -* `Region Split` 耗时：`take=58.7885518s` -* 校验耗时：`take=6m19.349067937s` - -根据上表数据可以计算得到： - -* 单个 TiKV 实例的吞吐：`avg speed(MB/s)`/`tikv_count` = `97.2` -* 单个 TiKV 实例的平均恢复速度：`total size(MB)`/(`split time` + `restore time`)/`tikv_count` = `92.4` - -### 异常处理 - -本部分介绍如何处理备份过程中出现的常见错误。 - -#### 备份日志中出现 `key locked Error` - -日志中的错误消息：`log - ["backup occur kv error"][error="{\"KvError\":{\"locked\":` - -如果在备份过程中遇到 key 被锁住，目前 BR 会尝试清锁。少量报错不会影响备份的正确性。 - -#### 备份失败 - -日志中的错误消息：`log - Error: msg:"Io(Custom { kind: AlreadyExists, error: \"[5_5359_42_123_default.sst] is already exists in /dir/backup_local/\" })"` - -若备份失败并出现以上错误消息，采取以下其中一种操作后再重新备份： - -* 更换备份数据目录。例如将 `/dir/backup-2020-01-01/` 改为 `/dir/backup_local/`。 -* 删除所有 TiKV 和 BR 节点的备份目录。 diff --git a/dev/reference/tools/data-migration/cluster-operations.md b/dev/reference/tools/data-migration/cluster-operations.md deleted file mode 100644 index 6694d731a1c1..000000000000 --- a/dev/reference/tools/data-migration/cluster-operations.md +++ /dev/null @@ -1,489 +0,0 @@ ---- -title: DM 集群操作 -category: reference ---- - -# DM 集群操作 - -本文介绍 DM 集群操作以及使用 DM-Ansible 管理 DM 集群时需要注意的事项。 - -## 启动集群 - -运行以下命令以启动整个集群的所有组件（包括 DM-master、DM-worker 和监控组件）： - -{{< copyable "shell-regular" >}} - -```bash -ansible-playbook start.yml -``` - -## 下线集群 - -运行以下命令以下线整个集群的所有组件（包括 DM-master、DM-worker 和监控组件）： - -{{< copyable "shell-regular" >}} - -```bash -ansible-playbook stop.yml -``` - -## 重启集群组件 - -在以下情况下，需要更新 DM 集群组件： - -- 您想要[更新组件版本](#更新组件版本)。 -- 发生了严重的错误，您需要重启组件完成临时恢复。 -- DM 集群所在的机器由于某种原因重启。 - -### 重启注意事项 - -该部分描述重启 DM 各组件时需要了解的事项。 - -#### DM-worker 重启事项 - -**全量数据导入过程中：** - -对于全量数据导入时的 SQL 文件，DM 使用下游数据库记录断点信息，DM-worker 会在本地 meta 文件记录子任务信息。DM-worker 重启时会检查断点信息和本地记录的子任务信息，重启前处于运行中状态的任务会自动恢复数据同步。 - -**增量数据同步过程中：** - -对于增量数据导入过程中的 binlog，DM 使用下游数据库记录断点信息，并会在同步任务开始或恢复后的第一个五分钟之内开启安全模式。 - -+ 未启用 sharding DDL 同步 - - 如果 DM-worker 上运行的任务未启用 sharding DDL 同步功能，DM-worker 重启时会检查断点信息和本地记录的子任务信息，重启前处于运行中状态的任务会自动恢复数据同步。 - -+ 已启用 sharding DDL 同步 - - - DM 同步 sharding DDL 语句时，如果 DM-worker 成功执行（或跳过）sharding DDL 的 binlog event，与 DM-worker 中的 sharding DDL 语句相关的所有表的断点信息都会被更新至 DDL 语句对应的 binlog event 之后的位置。 - - - 当 DM-worker 重启发生在 sharding DDL 语句同步开始前或完成后，DM-worker 会根据断点信息和本地记录的子任务信息自动恢复数据同步。 - - - 当 DM-worker 重启发生在 sharding DDL 语句同步过程中，可能会出现作为 DDL lock owner 的 DM-worker 实例已执行了 DDL 语句并成功变更了下游数据库表结构，但其他 DM-worker 实例重启而无法跳过 DDL 语句也无法更新断点的情况。 - - 此时 DM 会再次尝试同步这些未跳过执行的 DDL 语句。然而，由于未重启的 DM-worker 实例已经执行到了此 DDL 对应的 binlog event 之后，重启的 DM-worker 实例会被阻滞在重启前 DDL binlog event 对应的位置。 - - 要解决这个问题，请按照[手动处理 Sharding DDL Lock](/dev/reference/tools/data-migration/features/manually-handling-sharding-ddl-locks.md#场景二unlock-过程中部分-dm-worker-重启) 中描述的步骤操作。 - -**总结**：尽量避免在 sharding DDL 同步过程中重启 DM-worker。 - -#### DM-master 重启事项 - -由 DM-master 维护的信息包括以下两种。重启 DM-master 不会持久化保存这些信息的相关数据。 - -- 任务信息 -- Sharding DDL lock 信息 - -DM-master 重启时会自动向每个 DM-worker 实例请求任务信息，重建任务与 DM-worker 之间的对应关系，并从每个 DM-worker 实例获取 sharding DDL 信息。这样，就可以准确重建相应的 DDL lock，也可以自动解除 sharding DDL lock。 - -### 重启 DM-worker - -> **注意：** -> -> 尽量避免在 sharding DDL 同步过程中重启 DM-worker。 - -使用以下两种方法中任一种重启 DM-worker 组件： - -- 对 DM-worker 执行滚动升级。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update.yml --tags=dm-worker - ``` - -- 先停止 DM-worker，然后重启。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook stop.yml --tags=dm-worker && - ansible-playbook start.yml --tags=dm-worker - ``` - -### 重启 DM-master - -在以下两种方法中任选一种，重启 DM-master 组件： - -- 对 DM-master 执行滚动升级。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update.yml --tags=dm-master - ``` - -- 停止 DM-master，然后重启。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook stop.yml --tags=dm-master && - ansible-playbook start.yml --tags=dm-master - ``` - -## 更新组件版本 - -1. 下载 DM 二进制文件。 - - 1. 从 `downloads` 目录删除已有文件。 - - {{< copyable "shell-regular" >}} - - ```bash - cd /home/tidb/dm-ansible && - rm -rf downloads - ``` - - 2. 用 Playbook 下载 inventory.ini 文件中指定版本的最新 DM 二进制文件。这会自动替换 `/home/tidb/dm-ansible/resource/bin/` 中已有文件。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook local_prepare.yml - ``` - -2. 使用 Ansible 执行滚动升级。 - - 1. 对 DM-worker 实例执行滚动升级： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update.yml --tags=dm-worker - ``` - - 2. 对 DM-master 实例执行滚动升级： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update.yml --tags=dm-master - ``` - - 3. 升级 dmctl： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update.yml --tags=dmctl - ``` - - 4. 对 DM-worker， DM-master， 以及 dmctl 整体执行滚动升级： - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update.yml - ``` - -## 创建 DM-worker 实例 - -假设您想要在机器 `172.16.10.74` 上创建一个名为 `dm_worker3` 的 DM-worker 实例，按以下步骤操作： - -1. 为中控机设置 SSH 互信以及 sudo 规则。 - - 1. 参考[在中控机上配置 SSH 互信和 sudo 规则](/dev/how-to/deploy/data-migration-with-ansible.md#第-5-步在中控机上配置-ssh-互信和-sudo-规则)，使用 `tidb` 用户登录至中控机，并将 `172.16.10.74` 添加至 `hosts.ini` 文件中的 `[servers]` 部分。 - - {{< copyable "shell-regular" >}} - - ```bash - cd /home/tidb/dm-ansible && - vi hosts.ini - ``` - - ``` - [servers] - 172.16.10.74 - - [all:vars] - username = tidb - ``` - - 2. 运行以下命令。根据屏幕提示，输入 `root` 用户密码以部署 `172.16.10.74`。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook -i hosts.ini create_users.yml -u root -k - ``` - - 该步在 `172.16.10.74` 机器上创建了一个 `tidb` 用户，设置了 sudo 规则，并为中控机与该机器配置了 SSH 互信。 - -2. 修改 `inventory.ini` 文件，创建新 DM-worker 实例 `dm_worker3`。 - - ```ini - [dm_worker_servers] - dm_worker1 source_id="mysql-replica-01" ansible_host=172.16.10.72 server_id=101 mysql_host=172.16.10.81 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 - - dm_worker2 source_id="mysql-replica-02" ansible_host=172.16.10.73 server_id=102 mysql_host=172.16.10.82 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 - - dm_worker3 source_id="mysql-replica-03" ansible_host=172.16.10.74 server_id=103 mysql_host=172.16.10.83 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 - ``` - -3. 部署新 DM-worker 实例。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook deploy.yml --tags=dm-worker -l dm_worker3 - ``` - -4. 启用新 DM-worker 实例。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook start.yml --tags=dm-worker -l dm_worker3 - ``` - -5. 配置并重启 DM-master 服务。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update.yml --tags=dm-master - ``` - -6. 配置并重启 Prometheus 服务。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update_monitor.yml --tags=prometheus - ``` - -## 下线 DM-worker 实例 - -假设您想要下线的 DM-worker 实例为 `dm_worker3`。按以下步骤操作： - -1. 关闭您想要下线的 DM-worker 实例。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook stop.yml --tags=dm-worker -l dm_worker3 - ``` - -2. 修改 `inventory.ini` 文件，注释或删除 `dm_worker3` 实例所在行。 - - ```ini - [dm_worker_servers] - dm_worker1 source_id="mysql-replica-01" ansible_host=172.16.10.72 server_id=101 mysql_host=172.16.10.81 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 - - dm_worker2 source_id="mysql-replica-02" ansible_host=172.16.10.73 server_id=102 mysql_host=172.16.10.82 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 - - # dm_worker3 source_id="mysql-replica-03" ansible_host=172.16.10.74 server_id=103 mysql_host=172.16.10.83 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 # Comment or delete this line - ``` - -3. 配置并重启 DM-master 服务。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update.yml --tags=dm-master - ``` - -4. 配置并重启 Prometheus 服务。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update_monitor.yml --tags=prometheus - ``` - -## 替换/迁移 DM-master 实例 - -假设机器 `172.16.10.71` 需要进行维护或者已崩溃，需要将 DM-master 实例从 `172.16.10.71` 迁移至 `172.16.10.80`。按以下步骤操作： - -1. 为中控机设置 SSH 互信以及 sudo 规则。 - - 1. 参考[在中控机上配置 SSH 互信和 sudo 规则](/dev/how-to/deploy/data-migration-with-ansible.md#第-5-步在中控机上配置-ssh-互信和-sudo-规则)，使用 `tidb` 账户登录至中控机，并将 `172.16.10.80` 添加至 `hosts.ini` 文件中的 `[servers]` 部分。 - - {{< copyable "shell-regular" >}} - - ```bash - cd /home/tidb/dm-ansible && - vi hosts.ini - ``` - - ``` - [servers] - 172.16.10.80 - - [all:vars] - username = tidb - ``` - - 2. 运行以下命令。根据屏幕提示，输入 `root` 用户密码以部署 `172.16.10.80`。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook -i hosts.ini create_users.yml -u root -k - ``` - - 该步在 `172.16.10.80` 机器上创建了一个 `tidb` 用户，设置了 sudo 规则，并为中控机与该机器配置了 SSH 互信。 - -2. 关闭待替换的 DM-master 实例。 - - > **注意：** - > - > 如果机器 `172.16.10.71` 宕机，无法通过 SSH 登录，请忽略此步。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook stop.yml --tags=dm-master - ``` - -3. 修改 `inventory.ini` 文件。注释或删除待替换实例所在行，同时为新 DM-master 实例添加相关信息。 - - ```ini - [dm_master_servers] - # dm_master ansible_host=172.16.10.71 - dm_master ansible_host=172.16.10.80 - ``` - -4. 部署新 DM-master 实例。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook deploy.yml --tags=dm-master - ``` - -5. 启用新 DM-master 实例。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook start.yml --tags=dm-master - ``` - -6. 更新 dmctl 配置文件。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update.yml --tags=dmctl - ``` - -## 替换/迁移 DM-worker 实例 - -假设机器 `172.16.10.72` 需要进行维护或者已崩溃，您需要将 `dm_worker1` 实例从 `172.16.10.72` 迁移至 `172.16.10.75`。按以下步骤操作： - -1. 为中控机设置 SSH 互信以及 sudo 规则。 - - 1. 参考[在中控机上配置 SSH 互信和 sudo 规则](/dev/how-to/deploy/data-migration-with-ansible.md#第-5-步在中控机上配置-ssh-互信和-sudo-规则)，使用 `tidb` 账户登录至中控机，并将 `172.16.10.75` 添加至 `hosts.ini` 文件中的 `[servers]` 部分。 - - {{< copyable "shell-regular" >}} - - ```bash - cd /home/tidb/dm-ansible && - vi hosts.ini - ``` - - ``` - [servers] - 172.16.10.75 - - [all:vars] - username = tidb - ``` - - 2. 运行以下命令。根据屏幕提示，输入 `root` 用户密码以部署 `172.16.10.85`。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook -i hosts.ini create_users.yml -u root -k - ``` - - 该步在 `172.16.10.75` 上创建了一个 `tidb` 用户，设置了 sudo 规则，并为中控机与该机器配置了 SSH 互信。 - -2. 下线待替换 DM-worker 实例。 - - > **注意：** - > - > 如果机器 `172.16.10.71` 宕机，无法通过 SSH 登录，请忽略此步。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook stop.yml --tags=dm-worker -l dm_worker1 - ``` - -3. 修改 `inventory.ini` 文件，为新 DM-worker 实例添加相关信息。 - - 修改 `inventory.ini` 文件。注释或删除旧 `dm_worker1` 实例所在行；同时为新 `dm_worker1` 实例添加相关信息。 - - 如果希望从不同的 binlog position 或 GTID Sets 拉取 relay log，则也需要更新对应的 `{relay_binlog_name}` 或 `{relay_binlog_gtid}`。 - - ```ini - [dm_worker_servers] - dm_worker1 source_id="mysql-replica-01" ansible_host=172.16.10.75 server_id=101 mysql_host=172.16.10.81 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 - # dm_worker1 source_id="mysql-replica-01" ansible_host=172.16.10.72 server_id=101 mysql_host=172.16.10.81 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 - - dm_worker2 source_id="mysql-replica-02" ansible_host=172.16.10.73 server_id=102 mysql_host=172.16.10.82 mysql_user=root mysql_password='VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=' mysql_port=3306 - ``` - -4. 部署新 DM-worker 实例。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook deploy.yml --tags=dm-worker -l dm_worker1 - ``` - -5. 迁移 relay log 数据。 - - - 如果待替换 DM-worker 实例所在机器仍能访问，则可直接将该实例的 `{dm_worker_relay_dir}` 目录下的所有数据复制到新 DM-worker 实例的对应目录。 - - - 如果待替换 DM-worker 实例所在机器已无法访问，可能需在第 9 步中手动恢复 relay log 目录等信息。 - -6. 启动新 DM-worker 实例。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook start.yml --tags=dm-worker -l dm_worker1 - ``` - -7. 配置并重启 DM-master 服务。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update.yml --tags=dm-master - ``` - -8. 配置并重启 Prometheus 服务。 - - {{< copyable "shell-regular" >}} - - ```bash - ansible-playbook rolling_update_monitor.yml --tags=prometheus - ``` - -9. 启动并验证数据迁移任务。 - - 使用 `start-task` 命令启动数据迁移任务，如果任务运行正常，则表示 DM-worker 迁移顺利完成；如果报类似如下错误，则需要对 relay log 目录进行手动修复。 - - ```log - fail to initial unit Sync of subtask test-task : UUID suffix 000002 with UUIDs [1ddbf6d3-d3b2-11e9-a4e9-0242ac140003.000001] not found - ``` - - 如果待替换 DM-worker 所连接的上游 MySQL 已发生过切换，则会产生如上错误。此时可通过如下步骤手动修复： - - 1. 使用 `stop-task` 命令停止数据迁移任务。 - - 2. 通过 `$ ansible-playbook stop.yml --tags=dm-worker -l dm_worker1` 停止 DM-worker 实例。 - - 3. 更新 relay log 子目录的后缀，例如将 `1ddbf6d3-d3b2-11e9-a4e9-0242ac140003.000001` 重命名为 `1ddbf6d3-d3b2-11e9-a4e9-0242ac140003.000002`。 - - 4. 更新 relay log 子目录索引文件 `server-uuid.index`，例如将其中的内容由 `1ddbf6d3-d3b2-11e9-a4e9-0242ac140003.000001` 变更为 `1ddbf6d3-d3b2-11e9-a4e9-0242ac140003.000002`。 - - 5. 通过 `$ ansible-playbook start.yml --tags=dm-worker -l dm_worker1` 启动 DM-worker 实例。 - - 6. 再次启动并验证数据迁移任务。 diff --git a/dev/reference/tools/data-migration/configure/overview.md b/dev/reference/tools/data-migration/configure/overview.md deleted file mode 100644 index 0bcd1bf94866..000000000000 --- a/dev/reference/tools/data-migration/configure/overview.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: DM 配置简介 -category: reference ---- - -# DM 配置简介 - -本文档简要介绍 DM (Data Migration) 的配置文件和数据同步任务的配置。 - -## 配置文件 - -- `inventory.ini`：使用 DM-Ansible 部署 DM 集群的配置文件。需要根据所选用的集群拓扑来进行编辑。详见[编辑 `inventory.ini` 配置文件](/dev/how-to/deploy/data-migration-with-ansible.md#第-7-步编辑-inventoryini-配置文件)。 -- `dm-master.toml`：DM-master 进程的配置文件，包括 DM 集群的拓扑信息、MySQL 实例与 DM-worker 之间的关系（必须为一对一的关系）。使用 DM-Ansible 部署 DM 集群时，会自动生成 `dm-master.toml` 文件，各项配置说明详见 [DM-master 配置文件介绍](/dev/reference/tools/data-migration/configure/dm-master-configuration-file.md) -- `dm-worker.toml`：DM-worker 进程的配置文件，包括上游 MySQL 实例的配置和 relay log 的配置。使用 DM-Ansible 部署 DM 集群时，会自动生成 `dm-worker.toml` 文件，各项配置说明详见 [DM-worker 配置文件介绍](/dev/reference/tools/data-migration/configure/dm-worker-configuration-file.md) - -## 同步任务配置 - -### 任务配置文件 - -使用 DM-Ansible 部署 DM 集群时，`/conf` 中提供了任务配置文件模板：`task.yaml.exmaple` 文件。该文件是 DM 同步任务配置的标准文件，每一个具体的任务对应一个 `task.yaml` 文件。关于该配置文件的详细介绍，参见 [任务配置文件](/dev/reference/tools/data-migration/configure/task-configuration-file.md)。 - -### 创建数据同步任务 - -你可以基于 `task.yaml.example` 文件来创建数据同步任务，具体步骤如下： - -1. 复制 `task.yaml.example` 为 `your_task.yaml`。 -2. 参考[任务配置文件](/dev/reference/tools/data-migration/configure/task-configuration-file.md)来修改 `your_task.yaml` 文件。 -3. [使用 dmctl 创建数据同步任务](/dev/reference/tools/data-migration/manage-tasks.md#创建数据同步任务)。 - -### 关键概念 - -DM 配置的关键概念如下： - -| 概念 | 解释 | 配置文件 | -| :------------ | :------------ | :------------------ | -| source-id | 唯一确定一个 MySQL 或 MariaDB 实例，或者一个具有主从结构的复制组，字符串长度不大于 32 | `inventory.ini` 的 `source_id`；
`dm-master.toml` 的 `source-id`；
`task.yaml` 的 `source-id` | -| DM-worker ID | 唯一确定一个 DM-worker（取值于 `dm-worker.toml` 的 `worker-addr` 参数） | `dm-worker.toml` 的 `worker-addr`；
dmctl 命令行的 `-worker` / `-w` flag | diff --git a/dev/reference/tools/data-migration/configure/task-configuration-file.md b/dev/reference/tools/data-migration/configure/task-configuration-file.md deleted file mode 100644 index 1fcbc162521f..000000000000 --- a/dev/reference/tools/data-migration/configure/task-configuration-file.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: DM 任务配置文件介绍 -category: reference ---- - -# DM 任务配置文件介绍 - -本文档主要介绍 Data Migration (DM) 的任务基础配置文件 [`task_basic.yaml`](https://github.com/pingcap/dm/blob/master/dm/master/task_basic.yaml)，包含[全局配置](#全局配置)和[实例配置](#实例配置)两部分。 - -完整的任务配置参见 [DM 任务完整配置文件介绍](/dev/reference/tools/data-migration/configure/task-configuration-file-full.md) - -关于各配置项的功能和配置，请参阅[数据同步功能](/dev/reference/tools/data-migration/features/overview.md)。 - -## 关键概念 - -关于包括 `source-id` 和 DM-worker ID 在内的关键概念的介绍，请参阅[关键概念](/dev/reference/tools/data-migration/configure/overview.md#关键概念)。 - -## 基础配置文件示例 - -下面是一个基础的配置文件示例，通过该示例可以完成简单的数据同步功能。 - -```yaml ---- - -# ----------- 全局配置 ----------- -## ********* 基本信息配置 ********* -name: test # 任务名称，需要全局唯一 -task-mode: all # 任务模式，可设为 "full"、"incremental"、"all" - -target-database: # 下游数据库实例配置 - host: "127.0.0.1" - port: 4000 - user: "root" - password: "" # 如果不为空则需经过 dmctl 加密 - -## ******** 功能配置集 ********** -black-white-list: # 上游数据库实例匹配的表的 black & white list 过滤规则集 - bw-rule-1: # 黑白名单配置的名称 - do-dbs: ["all_mode"] # 同步哪些库 - -# ----------- 实例配置 ----------- -mysql-instances: - - source-id: "mysql-replica-01" # 上游实例或者复制组 ID，参考 `dm-master.toml` 的 `source-id` 配置 - black-white-list: "bw-rule-1" # 黑白名单配置名称 - mydumper-thread: 4 # mydumper 用于导出数据的线程数量，在 v1.0.2 版本引入 - loader-thread: 16 # loader 用于导入数据的线程数量，在 v1.0.2 版本引入 - syncer-thread: 16 # syncer 用于同步增量数据的线程数量，在 v1.0.2 版本引入 - - - source-id: "mysql-replica-02" # 上游实例或者复制组 ID，参考 `dm-master.toml` 的 `source-id` 配置 - black-white-list: "bw-rule-1" # 黑白名单配置名称 - mydumper-thread: 4 # mydumper 用于导出数据的线程数量，在 v1.0.2 版本引入 - loader-thread: 16 # loader 用于导入数据的线程数量，在 v1.0.2 版本引入 - syncer-thread: 16 # syncer 用于同步增量数据的线程数量，在 v1.0.2 版本引入 -``` - -## 配置顺序 - -通过上面的配置文件示例，可以看出配置文件总共分为两个部分：`全局配置`和`实例配置`，其中`全局配置`又分为`基础信息配置`和`功能配置集`，配置顺序如下： - -1. 编辑[全局配置](#全局配置)。 -2. 根据全局配置编辑[实例配置](#实例配置)。 - -## 全局配置 - -### 任务基本信息配置 - -配置任务的基本信息，配置项的说明参见以上示例配置文件中的注释。关于 `task-mode` 的特殊说明如下： - -- 描述：任务模式，可以通过任务模式来指定需要执行的数据迁移工作。 -- 值为字符串（`full`，`incremental` 或 `all`）。 - - `full`：只全量备份上游数据库，然后将数据全量导入到下游数据库。 - - `incremental`：只通过 binlog 把上游数据库的增量修改同步到下游数据库, 可以设置实例配置的 `meta` 配置项来指定增量同步开始的位置。 - - `all`：`full` + `incremental`。先全量备份上游数据库，将数据全量导入到下游数据库，然后从全量数据备份时导出的位置信息 (binlog position) 开始通过 binlog 增量同步数据到下游数据库。 - -### 功能配置集 - -对于一般的业务场景，只需要配置黑白名单过滤规则集，配置说明参见以上示例配置文件中 `black-white-list` 的注释以及 [Black & white table lists](/dev/reference/tools/data-migration/features/overview.md#black--white-table-lists) - -## 实例配置 - -本小节定义具体的数据同步子任务，DM 支持从单个或者多个上游 MySQL 实例同步数据到同一个下游数据库实例。 -配置项说明参见以上示例配置文件中 `mysql-instances` 的注释。 diff --git a/dev/reference/tools/data-migration/deploy.md b/dev/reference/tools/data-migration/deploy.md deleted file mode 100644 index d33fa6ecfd1b..000000000000 --- a/dev/reference/tools/data-migration/deploy.md +++ /dev/null @@ -1,186 +0,0 @@ ---- -title: 使用 DM 同步数据 -category: reference ---- - -# 使用 DM 同步数据 - -本文介绍如何使用 DM (Data Migration) 同步数据。 - -## 第 1 步：部署 DM 集群 - -目前推荐使用 DM-Ansible 部署 DM 集群，具体部署方法参照 [使用 DM-Ansible 部署 DM 集群](/dev/how-to/deploy/data-migration-with-ansible.md)；也可以使用 binary 部署 DM 集群用于体验或者测试，具体部署方法参照[使用 DM binary 部署 DM 集群](/dev/how-to/deploy/data-migration-with-binary.md)。 - -> **注意：** -> -> - 在 DM 所有的配置文件中，数据库的密码要使用 dmctl 加密后的密文。如果数据库密码为空，则不需要加密。关于如何使用 dmctl 加密明文密码，参考[使用 dmctl 加密上游 MySQL 用户密码](/dev/how-to/deploy/data-migration-with-ansible.md#使用-dmctl-加密上游-mysql-用户密码)。 -> - 上下游数据库用户必须拥有相应的读写权限。 - -## 第 2 步：检查集群信息 - -使用 DM-Ansible 部署 DM 集群后，相关配置信息如下： - -- DM 集群相关组件配置信息 - - | 组件 | 主机 | 端口 | - |:------|:---- |:---- | - | dm_worker1 | 172.16.10.72 | 8262 | - | dm_worker2 | 172.16.10.73 | 8262 | - | dm_master | 172.16.10.71 | 8261 | - -- 上下游数据库实例相关信息 - - | 数据库实例 | 主机 | 端口 | 用户名 | 加密密码 | - |:-------- |:--- | :--- | :--- | :--- | - | 上游 MySQL-1 | 172.16.10.81 | 3306 | root | VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU= | - | 上游 MySQL-2 | 172.16.10.82 | 3306 | root | VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU= | - | 下游 TiDB | 172.16.10.83 | 4000 | root | | - -- dm-master 进程配置文件 `{ansible deploy}/conf/dm-master.toml` 中的配置 - - ```toml - # Master 配置 - - [[deploy]] - source-id = "mysql-replica-01" - dm-worker = "172.16.10.72:8262" - - [[deploy]] - source-id = "mysql-replica-02" - dm-worker = "172.16.10.73:8262" - ``` - - > **注意：** - > - > `{ansible deploy}/conf/dm-master.toml` 中的 `{ansible deploy}` 表示使用 DM-Ansible 部署 DM 时通过 `deploy_dir` 参数指定的目录。 - -## 第 3 步：配置任务 - -假设需要将 MySQL-1 和 MySQL-2 实例的 `test_db` 库的 `test_table` 表以**全量+增量**的模式同步到下游 TiDB 的 `test_db` 库的 `test_table` 表。 - -复制并编辑 `{ansible deploy}/conf/task.yaml.example`，生成如下任务配置文件 `task.yaml`： - -```yaml -# 任务名，多个同时运行的任务不能重名。 -name: "test" -# 全量+增量 (all) 同步模式。 -task-mode: "all" -# 下游 TiDB 配置信息。 -target-database: - host: "172.16.10.83" - port: 4000 - user: "root" - password: "" - -# 当前数据同步任务需要的全部上游 MySQL 实例配置。 -mysql-instances: -- - # 上游实例或者复制组 ID，参考 `inventory.ini` 的 `source_id` 或者 `dm-master.toml` 的 `source-id 配置`。 - source-id: "mysql-replica-01" - # 需要同步的库名或表名的黑白名单的配置项名称，用于引用全局的黑白名单配置，全局配置见下面的 `black-white-list` 的配置。 - black-white-list: "global" - # Mydumper 的配置项名称，用于引用全局的 Mydumper 配置。 - mydumper-config-name: "global" - -- - source-id: "mysql-replica-02" - black-white-list: "global" - mydumper-config-name: "global" - -# 黑白名单全局配置，各实例通过配置项名引用。 -black-white-list: - global: - do-tables: # 需要同步的上游表的白名单。 - - db-name: "test_db" # 需要同步的表的库名。 - tbl-name: "test_table" # 需要同步的表的名称。 - -# Mydumper 全局配置，各实例通过配置项名引用。 -mydumpers: - global: - mydumper-path: "./bin/mydumper" # Mydumper 二进制文件的路径。 - extra-args: "-B test_db -T test_table" # mydumper 的其他参数，从 DM 1.0.2 版本开始，DM 会自动生成 table-list 配置，在其之前的版本仍然需要人工配置。 -``` - -## 第 4 步：启动任务 - -为了提前发现数据同步任务的一些配置错误，DM 中增加了[前置检查](/dev/reference/tools/data-migration/precheck.md)功能： - -- 启动数据同步任务时，DM 自动检查相应的权限和配置。 -- 也可使用 `check-task` 命令手动前置检查上游的 MySQL 实例配置是否符合 DM 的配置要求。 - -> **注意：** -> -> 第一次启动数据同步任务时，必须确保上游数据库已配置。否则，启动任务时会报错。 - -1. 进入 dmctl 目录 `/home/tidb/dm-ansible/resources/bin/`。 - -2. 执行以下命令启动 dmctl。 - - {{< copyable "shell-regular" >}} - - ```bash - ./dmctl --master-addr 172.16.10.71:8261 - ``` - -3. 执行以下命令启动数据同步任务。其中，`task.yaml` 是之前编辑的配置文件。 - - {{< copyable "" >}} - - ```bash - » start-task ./task.yaml - ``` - - - 如果执行该命令后返回的结果如下，则表明任务已成功启动。 - - ```json - { - "result": true, - "msg": "", - "workers": [ - { - "result": true, - "worker": "172.16.10.72:8262", - "msg": "" - }, - { - "result": true, - "worker": "172.16.10.73:8262", - "msg": "" - } - ] - } - ``` - - - 如果任务启动失败，可根据返回结果的提示进行配置变更后执行 `start-task task.yaml` 命令重新启动任务。 - -## 第 5 步：查询任务 - -如需了解 DM 集群中是否存在正在运行的同步任务及任务状态等信息，可在 dmctl 内使用以下命令进行查询： - -{{< copyable "" >}} - -```bash -» query-status -``` - -## 第 6 步：停止任务 - -如果不再需要进行数据同步，可以在 dmctl 内使用以下命令停止同步任务： - -{{< copyable "" >}} - -```bash -» stop-task test -``` - -其中的 `test` 是 `task.yaml` 配置文件中 `name` 配置项设置的任务名。 - -## 第 7 步：监控任务与查看日志 - -如果使用 DM-Ansible 部署 DM 集群时，正确部署了 Prometheus 与 Grafana，且 Grafana 的地址为 `172.16.10.71`，可在浏览器中打开 进入 Grafana，选择 DM 的 dashboard 即可查看 DM 相关监控项。 - -DM 在运行过程中，DM-worker, DM-master 及 dmctl 都会通过日志输出相关信息。各组件的日志目录如下： - -- DM-master 日志目录：通过 DM-master 进程参数 `--log-file` 设置。如果使用 DM-Ansible 部署 DM，则日志目录位于 DM-master 节点的 `{ansible deploy}/log/dm-master.log`。 -- DM-worker 日志目录：通过 DM-worker 进程参数 `--log-file` 设置。如果使用 DM-Ansible 部署 DM，则日志目录位于 DM-worker 节点的 `{ansible deploy}/log/dm-worker.log`。 -- dmctl 日志目录：与其二进制文件目录相同。 diff --git a/dev/reference/tools/data-migration/dm-upgrade.md b/dev/reference/tools/data-migration/dm-upgrade.md deleted file mode 100644 index 0f08bc0856eb..000000000000 --- a/dev/reference/tools/data-migration/dm-upgrade.md +++ /dev/null @@ -1,161 +0,0 @@ ---- -title: DM 版本升级 -category: reference ---- - -# DM 版本升级 - -本文档主要介绍各 DM (Data Migration) 版本间的升级操作步骤。 - -> **注意：** -> -> - 若无特殊说明，各版本的升级操作均为从前一个有升级指引的版本向当前版本升级。 -> - 若无特殊说明，各升级操作示例均假定已经下载了对应版本的 DM 和 DM-Ansible 且 DM binary 存在于 DM-Ansible 的相应目录中（下载 DM binary 可以参考[更新组件版本](/dev/reference/tools/data-migration/cluster-operations.md#更新组件版本)）。 -> - 若无特殊说明，各升级操作示例均假定升级前已停止所有同步任务，升级完成后手动重新启动所有同步任务。 -> - 以下版本升级指引逆序展示。 - -## 升级到 v1.0.3 - -### 版本信息 - -```bash -Release Version: v1.0.3 -Git Commit Hash: 41426af6cffcff9a325697a3bdebeadc9baa8aa6 -Git Branch: release-1.0 -UTC Build Time: 2019-12-13 07:04:53 -Go Version: go version go1.13 linux/amd64 -``` - -### 主要变更 - -- dmctl 支持命令式使用 -- 支持同步 `ALTER DATABASE` DDL 语句 -- 优化 DM 错误提示信息 -- 修复全量导入模块在暂停或退出时 data race 导致 panic 的问题 -- 修复对下游进行重试操作时，`stop-task` 和 `pause-task` 可能不生效的问题 - -### 升级操作示例 - -1. 下载新版本 DM-Ansible，确认 `inventory.ini` 文件中 `dm_version = v1.0.3` -2. 执行 `ansible-playbook local_prepare.yml` 下载新的 DM binary 到本地 -3. 执行 `ansible-playbook rolling_update.yml` 滚动升级 DM 集群组件 -4. 执行 `ansible-playbook rolling_update_monitor.yml` 滚动升级 DM 监控组件 - -> **注意：** -> -> 更新至 DM 1.0.3 版本时，需要确保 DM 所有组件 (dmctl/DM-master/DM-worker) 同时升级。不支持部分组件升级使用。 - -## 升级到 v1.0.2 - -### 版本信息 - -```bash -Release Version: v1.0.2 -Git Commit Hash: affc6546c0d9810b0630e85502d60ed5c800bf25 -Git Branch: release-1.0 -UTC Build Time: 2019-10-30 05:08:50 -Go Version: go version go1.12 linux/amd64 -``` - -### 主要变更 - -- 支持自动为 DM-worker 生成部分配置项，减少人工配置成本 -- 支持自动生成 mydumper 库表参数，减少人工配置成本 -- 优化 `query-status` 默认输出，突出重点信息 -- 直接管理到下游的 DB 连接而不是使用内置连接池，优化 SQL 错误处理与重试 -- 修复 DM-worker 进程启动时、执行 DML 失败时可能 panic 的 bug -- 修复执行 sharding DDL（如 `ADD INDEX`）超时后可能造成后续 sharding DDL 无法正确协调的 bug -- 修复了有部分 DM-worker 不可访问时无法 `start-task` 的 bug -- 完善了对 1105 错误的自动重试策略 - -### 升级操作示例 - -1. 下载新版本 DM-Ansible, 确认 `inventory.ini` 文件中 `dm_version = v1.0.2` -2. 执行 `ansible-playbook local_prepare.yml` 下载新的 DM binary 到本地 -3. 执行 `ansible-playbook rolling_update.yml` 滚动升级 DM 集群组件 -4. 执行 `ansible-playbook rolling_update_monitor.yml` 滚动升级 DM 监控组件 - -> **注意：** -> -> 更新至 DM 1.0.2 版本时，需要确保 DM 所有组件 (dmctl/DM-master/DM-worker) 同时升级。不支持部分组件升级使用。 - -## 升级到 v1.0.1 - -### 版本信息 - -```bash -Release Version: v1.0.1 -Git Commit Hash: e63c6cdebea0edcf2ef8c91d84cff4aaa5fc2df7 -Git Branch: release-1.0 -UTC Build Time: 2019-09-10 06:15:05 -Go Version: go version go1.12 linux/amd64 -``` - -### 主要变更 - -- 修复某些情况下 DM 会频繁重建数据库连接的问题 -- 修复使用 `query-status` 时潜在的 panic 问题 - -### 升级操作示例 - -1. 下载新版本 DM-Ansible, 确认 `inventory.ini` 文件中 `dm_version = v1.0.1` -2. 执行 `ansible-playbook local_prepare.yml` 下载新的 DM binary 到本地 -3. 执行 `ansible-playbook rolling_update.yml` 滚动升级 DM 集群组件 -4. 执行 `ansible-playbook rolling_update_monitor.yml` 滚动升级 DM 监控组件 - -> **注意：** -> -> 更新至 DM 1.0.1 版本时，需要确保 DM 所有组件 (dmctl/DM-master/DM-worker) 同时升级。不支持部分组件升级使用。 - -## 升级到 v1.0.0-10-geb2889c9 (1.0 GA) - -### 版本信息 - -```bash -Release Version: v1.0.0-10-geb2889c9 -Git Commit Hash: eb2889c9dcfbff6653be9c8720a32998b4627db9 -Git Branch: release-1.0 -UTC Build Time: 2019-09-06 03:18:48 -Go Version: go version go1.12 linux/amd64 -``` - -### 主要变更 - -- 常见的异常场景支持自动尝试恢复同步任务 -- 提升 DDL 语法兼容性 -- 修复上游数据库连接异常时可能丢失数据的 bug - -### 升级操作示例 - -1. 下载新版本 DM-Ansible, 确认 `inventory.ini` 文件中 `dm_version = v1.0.0` -2. 执行 `ansible-playbook local_prepare.yml` 下载新的 DM binary 到本地 -3. 执行 `ansible-playbook rolling_update.yml` 滚动升级 DM 集群组件 -4. 执行 `ansible-playbook rolling_update_monitor.yml` 滚动升级 DM 监控组件 - -> **注意：** -> -> 更新至 DM 1.0 GA 版本时，需要确保 DM 所有组件 (dmctl/DM-master/DM-worker) 同时升级。不支持部分组件升级使用。 - -## 升级到 v1.0.0-rc.1-12-gaa39ff9 - -### 版本信息 - -```bash -Release Version: v1.0.0-rc.1-12-gaa39ff9 -Git Commit Hash: aa39ff981dfb3e8c0fa4180127246b253604cc34 -Git Branch: dm-master -UTC Build Time: 2019-07-24 02:26:08 -Go Version: go version go1.11.2 linux/amd64 -``` - -### 主要变更 - -从此版本开始，将对所有的配置进行严格检查，遇到无法识别的配置会报错，以确保用户始终准确地了解自己的配置。 - -### 升级操作示例 - -启动 DM-master 或 DM-worker 前，必须确保已经删除废弃的配置信息，且没有多余的配置项，否则会启动失败。可根据失败信息删除多余的配置。 -可能遗留的废弃配置： - -- `dm-worker.toml` 中的 `meta-file` -- `task.yaml` 中的 `mysql-instances` 中的 `server-id` diff --git a/dev/reference/tools/data-migration/dm-worker-intro.md b/dev/reference/tools/data-migration/dm-worker-intro.md deleted file mode 100644 index 2cdeb0c22b7a..000000000000 --- a/dev/reference/tools/data-migration/dm-worker-intro.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: DM-worker 简介 -category: reference ---- - -# DM-worker 简介 - -DM-worker 是 DM (Data Migration) 的一个组件，负责执行具体的数据同步任务。 - -其主要功能如下： - -- 注册为一台 MySQL 或 MariaDB 服务器的 slave。 -- 读取 MySQL 或 MariaDB 的 binlog event，并将这些 event 持久化保存在本地 (relay log)。 -- 单个 DM-worker 支持同步一个 MySQL 或 MariaDB 实例的数据到下游的多个 TiDB 实例。 -- 多个 DM-Worker 支持同步多个 MySQL 或 MariaDB 实例的数据到下游的一个 TiDB 实例。 - -## DM-worker 处理单元 - -DM-worker 任务包含如下多个逻辑处理单元。 - -### Relay log - -Relay log 持久化保存从上游 MySQL 或 MariaDB 读取的 binlog，并对 binlog replication 处理单元提供读取 binlog event 的功能。 - -其原理和功能与 MySQL slave relay log 类似，详见 [Slave Relay Log](https://dev.mysql.com/doc/refman/5.7/en/slave-logs-relaylog.html)。 - -### Dumper - -Dumper 从上游 MySQL 或 MariaDB 导出全量数据到本地磁盘。 - -### Loader - -Loader 读取 dumper 处理单元的数据文件，然后加载到下游 TiDB。 - -### Binlog replication/Syncer - -Binlog replication/Syncer 读取 relay log 处理单元的 binlog event，将这些 event 转化为 SQL 语句，再将这些 SQL 语句应用到下游 TiDB。 - -## DM-worker 所需权限 - -本小节主要介绍使用 DM-worker 时所需的上下游数据库用户权限以及各处理单元所需的用户权限。 - -### 上游数据库用户权限 - -上游数据库 (MySQL/MariaDB) 用户必须拥有以下权限： - -| 权限 | 作用域 | -|:----|:----| -| `SELECT` | Tables | -| `RELOAD` | Global | -| `REPLICATION SLAVE` | Global | -| `REPLICATION CLIENT` | Global | - -如果要同步 `db1` 的数据到 TiDB，可执行如下的 `GRANT` 语句： - -{{< copyable "sql" >}} - -```sql -GRANT RELOAD,REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'your_user'@'your_wildcard_of_host' -GRANT SELECT ON db1.* TO 'your_user'@'your_wildcard_of_host'; -``` - -如果还要同步其他数据库的数据到 TiDB, 请确保已赋予这些库跟 `db1` 一样的权限。 - -### 下游数据库用户权限 - -下游数据库 (TiDB) 用户必须拥有以下权限： - -| 权限 | 作用域 | -|:----|:----| -| `SELECT` | Tables | -| `INSERT` | Tables | -| `UPDATE`| Tables | -| `DELETE` | Tables | -| `CREATE` | Databases，tables | -| `DROP` | Databases，tables | -| `ALTER` | Tables | -| `INDEX` | Tables | - -对要执行同步操作的数据库或表执行下面的 `GRANT` 语句： - -{{< copyable "sql" >}} - -```sql -GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER,INDEX ON db.table TO 'your_user'@'your_wildcard_of_host'; -``` - -### 处理单元所需的最小权限 - -| 处理单元 | 最小上游 (MySQL/MariaDB) 权限 | 最小下游 (TiDB) 权限 | 最小系统权限 | -|:----|:--------------------|:------------|:----| -| Relay log | `REPLICATION SLAVE` (读取 binlog）
`REPLICATION CLIENT` (`show master status`, `show slave status`) | 无 | 本地读/写磁盘 | -| Dumper | `SELECT`
`RELOAD`（获取读锁将表数据刷到磁盘，进行一些操作后，再释放读锁对表进行解锁）| 无 | 本地写磁盘 | -| Loader | 无 | `SELECT`（查询 checkpoint 历史）
`CREATE`（创建数据库或表）
`DELETE`（删除 checkpoint）
`INSERT`（插入 dump 数据）| 读/写本地文件 | -| Binlog replication | `REPLICATION SLAVE`（读 binlog）
`REPLICATION CLIENT` (`show master status`, `show slave status`) | `SELECT`（显示索引和列）
`INSERT` (DML)
`UPDATE` (DML)
`DELETE` (DML)
`CREATE`（创建数据库或表）
`DROP`（删除数据库或表）
`ALTER`（修改表）
`INDEX`（创建或删除索引）| 本地读/写磁盘 | - -> **注意：** -> -> 这些权限并非一成不变。随着需求改变，这些权限也可能会改变。 diff --git a/dev/reference/tools/data-migration/faq.md b/dev/reference/tools/data-migration/faq.md deleted file mode 100644 index 0604ed09d127..000000000000 --- a/dev/reference/tools/data-migration/faq.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: Data Migration 常见问题 -category: reference -aliases: ['/docs-cn/dev/faq/data-migration/'] ---- - -# Data Migration 常见问题 - -## DM 是否支持同步阿里 RDS 以及其他云数据库的数据？ - -DM 仅支持解析标准版本的 MySQL/MariaDB 的 binlog，对于阿里云 RDS 以及其他云数据库没有进行过测试，如果确认其 binlog 为标准格式，则可以支持。 - -## task 配置中的黑白名单的正则表达式是否支持`非获取匹配`（?!）？ - -目前不支持，DM 仅支持 golang 标准库的正则，可以通过 [re2-syntax](https://github.com/google/re2/wiki/Syntax) 了解 golang 支持的正则表达式。 - -## 如果在上游执行的一个 statement 包含多个 DDL 操作，DM 是否支持同步？ - -DM 会尝试将包含多个 DDL 变更操作的单条语句拆分成只包含一个 DDL 操作的多条语句，但是可能没有覆盖所有的场景。建议在上游执行的一条 statement 中只包含一个 DDL 操作，或者在测试环境中验证一下，如果不支持，可以给 DM 提 [issue](https://github.com/pingcap/dm/issues)。 - -## 如何处理不兼容的 DDL 语句？ - -你需要使用 dmctl 手动处理 TiDB 不兼容的 DDL 语句（包括手动跳过该 DDL 语句或使用用户指定的 DDL 语句替换原 DDL 语句，详见[跳过 (skip) 或替代执行 (replace) 异常的 SQL 语句](/dev/reference/tools/data-migration/skip-replace-sqls.md)）。 - -> **注意：** -> -> TiDB 目前并不兼容 MySQL 支持的所有 DDL 语句。 - -## 如何重置数据同步任务？ - -在以下情况中，你需要重置整个数据同步任务： - -- 上游数据库中人为执行了 `RESET MASTER`，造成 relay log 同步出错 - -- relay log 或上游 binlog event 损坏或者丢失 - -此时，relay 处理单元通常会发生错误而退出，且无法优雅地自动恢复，因此需要通过手动方式恢复数据同步： - -1. 使用 `stop-task` 命令停止当前正在运行的所有同步任务。 - -2. 使用 Ansible [停止整个 DM 集群](/dev/how-to/deploy/data-migration-with-ansible.md#第-10-步关闭-dm-集群)。 - -3. 手动清理掉与 binlog event 被重置的 MySQL master 相对应的 DM-worker 的 relay log 目录。 - - - 如果是使用 Ansible 部署，relay log 目录即 `/relay_log` 目录。 - - 如果是使用二进制文件手动部署，relay log 目录即 relay-dir 参数设置的目录。 - -4. 清理掉下游已同步的数据。 - -5. 使用 Ansible [启动整个 DM 集群](/dev/how-to/deploy/data-migration-with-ansible.md#第-9-步部署-dm-集群)。 - -6. 以新的任务名重启数据同步任务，或设置 `remove-meta` 为 `true` 且 `task-mode` 为 `all`。 diff --git a/dev/reference/tools/data-migration/features/manually-handling-sharding-ddl-locks.md b/dev/reference/tools/data-migration/features/manually-handling-sharding-ddl-locks.md deleted file mode 100644 index 93504f66abb6..000000000000 --- a/dev/reference/tools/data-migration/features/manually-handling-sharding-ddl-locks.md +++ /dev/null @@ -1,540 +0,0 @@ ---- -title: 手动处理 Sharding DDL Lock -category: reference ---- - -# 手动处理 Sharding DDL Lock - -DM (Data Migration) 使用 sharding DDL lock 来确保分库分表的 DDL 操作可以正确执行。绝大多数情况下，该锁定机制可自动完成；但在部分异常情况发生时，需要使用 `unlock-ddl-lock`/`break-ddl-lock` 手动处理异常的 DDL lock。 - -> **注意：** -> -> - 不要轻易使用 `unlock-ddl-lock`/`break-ddl-lock` 命令，除非完全明确当前场景下使用这些命令可能会造成的影响，并能接受这些影响。 -> - 在手动处理异常的 DDL lock 前，请确保已经了解 DM 的[分库分表合并同步原理](/dev/reference/tools/data-migration/usage-scenarios/shard-merge.md#实现原理)。 - -## 命令介绍 - -### `show-ddl-locks` - -该命令用于查询当前 DM-master 上存在的 DDL lock 信息。 - -#### 命令示例 - -{{< copyable "shell-regular" >}} - -```bash -show-ddl-locks [--worker=127.0.0.1:8262] [task-name] -``` - -#### 参数解释 - -+ `worker`： - - flag 参数，string，`--worker`，可选 - - 不指定时，查询所有 DM-worker 相关的 lock 信息；指定时，仅查询与这组 DM-worker 相关的 lock 信息，可重复多次指定 - -+ `task-name`： - - 非 flag 参数，string，可选 - - 不指定时，查询与所有任务相关的 lock 信息；指定时，仅查询特定任务相关的 lock 信息 - -#### 返回结果示例 - -{{< copyable "shell-regular" >}} - -```bash -show-ddl-locks test -``` - -``` -{ - "result": true, # 查询 lock 操作本身是否成功 - "msg": "", # 查询 lock 操作失败时的原因或其它描述信息（如不存在任务 lock） - "locks": [ # DM-master 上存在的 lock 信息列表 - { - "ID": "test-`shard_db`.`shard_table`", # lock 的 ID 标识，当前由任务名与 DDL 对应的 schema/table 信息组成 - "task": "test", # lock 所属的任务名 - "owner": "127.0.0.1:8262", # lock 的 owner（第一个遇到该 DDL 的 DM-worker） - "DDLs": [ # lock 对应的 DDL 列表 - "USE `shard_db`; ALTER TABLE `shard_db`.`shard_table` DROP COLUMN `c2`;" - ], - "synced": [ # 已经收到对应 MySQL 实例内所有分表 DDL 的 DM-worker 列表 - "127.0.0.1:8262" - ], - "unsynced": [ # 尚未收到对应 MySQL 实例内所有分表 DDL 的 DM-worker 列表 - "127.0.0.1:8263" - ] - } - ] -} -``` - -### `unlock-ddl-lock` - -该命令用于主动请求 DM-master 解除指定的 DDL lock，包括的操作：请求 owner 执行 DDL 操作，请求其他非 owner 的 DM-worker 跳过 DDL 操作，移除 DM-master 上的 lock 信息。 - -#### 命令示例 - -{{< copyable "shell-regular" >}} - -```bash -unlock-ddl-lock [--worker=127.0.0.1:8262] [--owner] [--force-remove] -``` - -#### 参数解释 - -+ `worker`： - - flag 参数，string，`--worker`，可选 - - 不指定时，对所有已经在等待该 lock 的 DM-worker 发起跳过 DDL 操作请求；指定时，仅对这组 DM-worker 发起跳过 DDL 操作请求，可重复多次指定 - -+ `owner`： - - flag 参数，string，`--owner`，可选 - - 不指定时，请求默认的 owner（`show-ddl-locks` 返回结果中的 `owner`）执行 DDL 操作；指定时，请求该 DM-worker（替代默认的 owner）执行 DDL 操作 - -+ `force-remove`： - - flag 参数，boolean，`--force-remove`，可选 - - 不指定时，仅在 owner 执行 DDL 成功时移除 lock 信息；指定时，即使 owner 执行 DDL 失败也强制移除 lock 信息（此后将无法再次查询或操作该 lock） - -+ `lock-ID`： - - 非 flag 参数，string，必选 - - 指定需要执行 unlock 操作的 DDL lock ID（即 `show-ddl-locks` 返回结果中的 `ID`） - -#### 返回结果示例 - -{{< copyable "shell-regular" >}} - -```bash -unlock-ddl-lock test-`shard_db`.`shard_table` -``` - -``` -{ - "result": true, # unlock lock 操作是否成功 - "msg": "", # unlock lock 操作失败时的原因 - "workers": [ # 各 DM-worker 执行/跳过 DDL 操作结果信息列表 - { - "result": true, # 该 DM-worker 执行/跳过 DDL 操作是否成功 - "worker": "127.0.0.1:8262", # DM-worker 地址 (DM-worker ID) - "msg": "" # DM-worker 执行/跳过 DDL 失败时的原因 - } - ] -} -``` - -### break-ddl-lock - -该命令用于主动请求 DM-worker 强制打破当前正在等待 unlock 的 DDL lock，包括请求 DM-worker 执行或跳过 DDL 操作、移除该 DM-worker 上的 DDL lock 信息。 - -#### 命令示例 - -{{< copyable "shell-regular" >}} - -```bash -break-ddl-lock <--worker=127.0.0.1:8262> [--remove-id] [--exec] [--skip] -``` - -#### 参数解释 - -+ `worker`： - - flag 参数，string，`--worker`，必选 - - 指定需要执行 break 操作的 DM-worker - -+ `remove-id`：已废弃 - -+ `exec`： - - flag 参数，boolean，`--exec`，可选 - - 不可与 `--skip` 参数同时指定 - - 指定时，请求该 DM-worker 执行（execute）当前 lock 对应的 DDL - -+ `skip`： - - flag 参数，boolean，`--skip`，可选 - - 不可与 `--exec` 参数同时指定 - - 指定时，请求该 DM-worker 跳过（skip）当前 lock 对应的 DDL - -+ `task-name`： - - 非 flag 参数，string，必选 - - 指定要执行 break 操作的 lock 所在的 task 名称（要查看各 task 上是否存在 lock，可通过 [query-status](/dev/reference/tools/data-migration/query-status.md) 获得） - -#### 返回结果示例 - -{{< copyable "shell-regular" >}} - -```bash -break-ddl-lock -w 127.0.0.1:8262 --exec test -``` - -``` -{ - "result": true, # break lock 操作是否成功 - "msg": "", # break lock 操作失败时的原因 - "workers": [ # 执行 break lock 操作的 DM-worker 列表（当前单次操作仅支持对一个 DM-worker 执行 break lock） - { - "result": false, # 该 DM-worker break lock 操作是否成功 - "worker": "127.0.0.1:8262", # 该 DM-worker 地址 (DM-worker ID) - "msg": "" # DM-worker break lock 失败时的原因 - } - ] -} -``` - -## 支持场景 - -目前，使用 `unlock-ddl-lock`/`break-ddl-lock` 命令仅支持处理以下三种 sharding DDL lock 异常情况。 - -### 场景一：部分 DM-worker 下线 - -#### Lock 异常原因 - -在 DM-master 尝试自动 unlock sharding DDL lock 之前，需要等待所有 DM-worker 的 sharding DDL events 全部到达（详见[分库分表合并同步原理](/dev/reference/tools/data-migration/usage-scenarios/shard-merge.md#实现原理)）。如果 sharding DDL 已经在同步过程中，且有部分 DM-worker 下线，并且不再计划重启它们（按业务需求移除了这部分 DM-worker），则会由于永远无法等齐所有的 DDL 而造成 lock 无法自动 unlock。 - -#### 手动处理示例 - -假设上游有 MySQL-1 和 MySQL-2 两个实例，其中 MySQL-1 中有 `shard_db_1`.`shard_table_1` 和 `shard_db_1`.`shard_table_2` 两个表，MySQL-2 中有 `shard_db_2`.`shard_table_1` 和 `shard_db_2`.`shard_table_2` 两个表。现在需要将这 4 个表合并后同步到下游 TiDB 的 `shard_db`.`shard_table` 表中。 - -初始表结构如下： - -{{< copyable "sql" >}} - -```sql -SHOW CREATE TABLE shard_db_1.shard_table_1; -``` - -``` -+---------------+------------------------------------------+ -| Table | Create Table | -+---------------+------------------------------------------+ -| shard_table_1 | CREATE TABLE `shard_table_1` ( - `c1` int(11) NOT NULL, - PRIMARY KEY (`c1`) -) ENGINE=InnoDB DEFAULT CHARSET=latin1 | -+---------------+------------------------------------------+ -``` - -上游分表将执行以下 DDL 语句变更表结构： - -{{< copyable "sql" >}} - -```sql -ALTER TABLE shard_db_*.shard_table_* ADD COLUMN c2 INT; -``` - -MySQL 及 DM 操作与处理流程如下： - -1. MySQL-1 对应的 DM-worker-1 的两个分表执行了对应的 DDL 操作进行表结构变更。 - - {{< copyable "sql" >}} - - ```sql - ALTER TABLE shard_db_1.shard_table_1 ADD COLUMN c2 INT; - ``` - - {{< copyable "sql" >}} - - ```sql - ALTER TABLE shard_db_1.shard_table_2 ADD COLUMN c2 INT; - ``` - -2. DM-worker-1 接受到两个分表的 DDL 之后，将对应 MySQL-1 相关的 DDL 信息发送给 DM-master，DM-master 创建相应的 DDL lock。 -3. 使用 `show-ddl-lock` 查看当前的 DDL lock 信息。 - - {{< copyable "shell-regular" >}} - - ```bash - show-ddl-locks test - ``` - - ``` - { - "result": true, - "msg": "", - "locks": [ - { - "ID": "test-`shard_db`.`shard_table`", - "task": "test", - "owner": "127.0.0.1:8262", - "DDLs": [ - "USE `shard_db`; ALTER TABLE `shard_db`.`shard_table` ADD COLUMN `c2` int(11);" - ], - "synced": [ - "127.0.0.1:8262" - ], - "unsynced": [ - "127.0.0.1:8263" - ] - } - ] - } - ``` - -4. 由于业务需要，DM-worker-2 对应的 MySQL-2 的数据不再需要同步到下游 TiDB，对 DM-worker-2 执行了下线处理。 -5. DM-master 上 ID 为 ```test-`shard_db`.`shard_table` ``` 的 lock 无法等到 DM-worker-2 的 DDL 操作信息。 - - `show-ddl-locks` 返回的 `unsynced` 中一直包含 DM-worker-2 的信息（`127.0.0.1:8263`）。 - -6. 使用 `unlock-dll-lock` 来请求 DM-master 主动 unlock 该 DDL lock。 - - - 如果 DDL lock 的 owner 也已经下线，可以使用 `--owner` 参数指定其他 DM-worker 作为新 owner 来执行 DDL。 - - 当存在任意 DM-worker 报错时，`result` 将为 `false`，此时请仔细检查各 DM-worker 的错误是否是预期可接受的。 - - 已下线的 DM-worker 会返回 `rpc error: code = Unavailable` 错误属于预期行为，可以忽略。 - - 如果其它未下线的 DM-worker 返回错误，则需要根据情况额外处理。 - - {{< copyable "shell-regular" >}} - - ```bash - unlock-ddl-lock test-`shard_db`.`shard_table` - ``` - - ``` - { - "result": false, - "msg": "github.com/pingcap/tidb-enterprise-tools/dm/master/server.go:1472: DDL lock test-`shard_db`.`shard_table` owner ExecuteDDL successfully, so DDL lock removed. but some dm-workers ExecuteDDL fail, you should to handle dm-worker directly", - "workers": [ - { - "result": true, - "worker": "127.0.0.1:8262", - "msg": "" - }, - { - "result": false, - "worker": "127.0.0.1:8263", - "msg": "rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = \"transport: Error while dialing dial tcp 127.0.0.1:8263: connect: connection refused\"" - } - ] - } - ``` - -7. 使用 `show-dd-locks` 确认 DDL lock 是否被成功 unlock。 - - ```bash - show-ddl-locks test - ``` - - ``` - { - "result": true, - "msg": "no DDL lock exists", - "locks": [ - ] - } - ``` - -8. 查看下游 TiDB 中的表结构是否变更成功。 - - {{< copyable "sql" >}} - - ```sql - SHOW CREATE TABLE shard_db.shard_table; - ``` - - ``` - +-------------+--------------------------------------------------+ - | Table | Create Table | - +-------------+--------------------------------------------------+ - | shard_table | CREATE TABLE `shard_table` ( - `c1` int(11) NOT NULL, - `c2` int(11) DEFAULT NULL, - PRIMARY KEY (`c1`) - ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin | - +-------------+--------------------------------------------------+ - ``` - -9. 使用 `query-status` 确认同步任务是否正常。 - -#### 手动处理后的影响 - -使用 `unlock-ddl-lock` 手动执行 unlock 操作后，由于该任务的配置信息中仍然包含了已下线的 DM-worker，如果不进行处理，则当下次 sharding DDL 到达时，仍会出现 lock 无法自动完成同步的情况。 - -因此，在手动解锁 DDL lock 后，需要再执行以下操作： - -1. 使用 `stop-task` 停止运行中的任务。 -2. 更新任务配置文件，将已下线 DM-worker 对应的信息从配置文件中移除。 -3. 使用 `start-task` 及新任务配置文件重新启动任务。 - -> **注意：** -> -> 在 `unlock-ddl-lock` 之后，如果已下线的 DM-worker 重新上线并尝试对其中的分表进行数据同步，则会由于数据与下游的表结构不匹配而发生错误。 - -### 场景二：unlock 过程中部分 DM-worker 重启 - -#### Lock 异常原因 - -在 DM-master 收到所有 DM-worker 的 DDL 信息后，执行自动 unlock DDL lock 的操作主要包括以下步骤： - -1. 请求 lock owner 执行 DDL 操作，并更新对应分表的 checkpoint。 -2. 在 owner 执行 DDL 操作成功后，移除 DM-master 上保存的 DDL lock 信息。 -3. 在 owner 执行 DDL 操作成功后，请求其他所有 DM-worker 跳过 DDL 操作并更新对应分表的 checkpoint。 - -上述 unlock DDL lock 的操作不是原子的，当 owner 执行 DDL 操作成功后，请求其他 DM-worker 跳过 DDL 操作时，如果该 DM-worker 发生了重启，则会造成该 DM-worker 跳过 DDL 操作失败。 - -此时 DM-master 上的 lock 信息被移除，但该 DM-worker 重启后将尝试继续重新同步该 DDL 操作。但是，由于其他 DM-worker（包括原 owner）已经同步完该 DDL 操作，并已经在继续后续的同步，该 DM-worker 将永远无法等待该 DDL 操作对应 lock 的自动 unlock。 - -#### 手动处理示例 - -仍然假设是 [部分 DM-worker 下线](#场景一部分-dm-worker-下线) 示例中的上下游表结构及合表同步需求。 - -当在 DM-master 自动执行 unlock 操作的过程中，owner (DM-worker-1) 成功执行了 DDL 操作且开始继续进行后续同步，并移除了 DM-master 上的 DDL lock 信息；但在请求 DM-worker-2 跳过 DDL 操作的过程中，由于 DM-worker-2 发生了重启而跳过 DDL 操作失败。 - -DM-worker-2 重启后，将尝试重新同步重启前已经在等待的 DDL lock。此时将在 DM-master 上创建一个新的 lock，并且该 DM-worker 将成为 lock 的 owner（其他 DM-worker 此时已经执行或跳过 DDL 操作并在进行后续同步）。 - -处理流程如下： - -1. 使用 `show-ddl-locks` 确认 DM-master 上存在该 DDL 操作对应的 lock。 - - 应该仅有该重启的 DM-worker（`127.0.0.1:8263`）处于 `syned` 状态： - - {{< copyable "shell-regular" >}} - - ```bash - show-ddl-locks - ``` - - ``` - { - "result": true, - "msg": "", - "locks": [ - { - "ID": "test-`shard_db`.`shard_table`", - "task": "test", - "owner": "127.0.0.1:8263", - "DDLs": [ - "USE `shard_db`; ALTER TABLE `shard_db`.`shard_table` ADD COLUMN `c2` int(11);" - ], - "synced": [ - "127.0.0.1:8263" - ], - "unsynced": [ - "127.0.0.1:8262" - ] - } - ] - } - ``` - -2. 使用 `unlock-ddl-lock` 请求 DM-master unlock 该 lock。 - - - 使用 `--worker` 参数限定操作仅针对该重启的 DM-worker（`127.0.0.1:8263`）。 - - Lock 过程中该 DM-worker 会尝试再次向下游执行该 DDL 操作（重启前的原 owner 已向下游执行过该 DDL 操作），需要确保该 DDL 操作可被多次执行。 - - {{< copyable "shell-regular" >}} - - ```bash - unlock-ddl-lock --worker=127.0.0.1:8263 test-`shard_db`.`shard_table` - ``` - - ``` - { - "result": true, - "msg": "", - "workers": [ - { - "result": true, - "worker": "127.0.0.1:8263", - "msg": "" - } - ] - } - ``` - -3. 使用 `show-ddl-locks` 确认 DDL lock 是否被成功 unlock。 -4. 使用 `query-status` 确认同步任务是否正常。 - -#### 手动处理后的影响 - -手动 unlock sharding DDL lock 后，后续的 sharding DDL 将可以自动正常同步。 - -### 场景三：unlock 过程中部分 DM-worker 临时不可达 - -#### Lock 异常原因 - -与 [unlock 过程中部分 DM-worker 重启](#场景二unlock-过程中部分-dm-worker-重启) 造成 lock 异常的原因类似。当请求 DM-worker 跳过 DDL 操作时，如果该 DM-worker 临时不可达，则会造成该 DM-worker 跳过 DDL 操作失败。此时 DM-master 上的 lock 信息被移除，但该 DM-worker 将处于等待一个不再存在的 DDL lock 的状态。 - -场景三与[场景二](#场景二unlock-过程中部分-dm-worker-重启)的区别在于，场景三中 DM-master 没有 lock，而场景二中 DM-master 有一个新的 lock。 - -#### 手动处理示例 - -仍然假设是 [部分 DM-worker 下线](#场景一部分-dm-worker-下线) 示例中的上下游表结构及合表同步需求。 - -在 DM-master 自动执行 unlock 操作的过程中，owner (DM-worker-1) 成功执行了 DDL 操作且开始继续进行后续同步，并移除了 DM-master 上的 DDL lock 信息，但在请求 DM-worker-2 跳过 DDL 操作的过程中，由于网络原因等临时不可达而跳过 DDL 操作失败。 - -处理流程如下： - -1. 使用 `show-ddl-locks` 确认 DM-master 上不再存在该 DDL 操作对应的 lock。 -2. 使用 `query-status` 确认 DM-worker 仍在等待 lock 同步。 - - {{< copyable "shell-regular" >}} - - ```bash - query-status test - ``` - - ``` - { - "result": true, - "msg": "", - "workers": [ - ... - { - ... - "worker": "127.0.0.1:8263", - "subTaskStatus": [ - { - ... - "unresolvedDDLLockID": "test-`shard_db`.`shard_table`", - "sync": { - ... - "blockingDDLs": [ - "USE `shard_db`; ALTER TABLE `shard_db`.`shard_table` ADD COLUMN `c2` int(11);" - ], - "unresolvedGroups": [ - { - "target": "`shard_db`.`shard_table`", - "DDLs": [ - "USE `shard_db`; ALTER TABLE `shard_db`.`shard_table` ADD COLUMN `c2` int(11);" - ], - "firstPos": "(mysql-bin|000001.000003, 1752)", - "synced": [ - "`shard_db_2`.`shard_table_1`", - "`shard_db_2`.`shard_table_2`" - ], - "unsynced": [ - ] - } - ], - "synced": false - } - } - ] - ... - } - ] - } - ``` - -3. 使用 `break-ddl-lock` 请求强制 break 该 DM-worker 当前正在等待的 DDL lock。 - - 由于 owner 已经向下游执行了 DDL 操作，因此在 break 时使用 `--skip` 参数。 - - {{< copyable "shell-regular" >}} - - ```bash - break-ddl-lock --worker=127.0.0.1:8263 --skip test - ``` - - ``` - { - "result": true, - "msg": "", - "workers": [ - { - "result": true, - "worker": "127.0.0.1:8263", - "msg": "" - } - ] - } - ``` - -4. 使用 `query-status` 确认同步任务是否正常且不再处于等待 lock 的状态。 - -#### 手动处理后的影响 - -手动强制 break lock 后，后续 sharding DDL 将可以自动正常同步。 diff --git a/dev/reference/tools/data-migration/features/overview.md b/dev/reference/tools/data-migration/features/overview.md deleted file mode 100644 index 898ca9ddffd0..000000000000 --- a/dev/reference/tools/data-migration/features/overview.md +++ /dev/null @@ -1,529 +0,0 @@ ---- -title: 数据同步功能 -summary: DM 提供的功能及其配置介绍 -category: reference ---- - -# 数据同步功能 - -本文将详细介绍 DM 提供的数据同步功能，以及相关的配置选项。 - -## Table routing - -Table routing 提供将上游 MySQL/MariaDB 实例的某些表同步到下游指定表的功能。 - -> **注意：** -> -> - 不支持对同一个表设置多个不同的路由规则。 -> - Schema 的匹配规则需要单独设置，用来同步 `create/drop schema xx`，例如下面[参数配置](#参数配置)中的 rule-2。 - -### 参数配置 - -{{< copyable "" >}} - -```yaml -routes: - rule-1: - schema-pattern: "test_*" - table-pattern: "t_*" - target-schema: "test" - target-table: "t" - rule-2: - schema-pattern: "test_*" - target-schema: "test" -``` - -### 参数解释 - -将根据 [`schema-pattern`/`table-pattern`](/dev/reference/tools/data-migration/table-selector.md) 匹配上该规则的上游 MySQL/MariaDB 实例的表同步到下游的 `target-schema`/`target-table`。 - -### 使用示例 - -下面展示了三个不同场景下的配置示例。 - -#### 分库分表合并 - -假设存在分库分表场景，需要将上游两个 MySQL 实例的表 `test_{1,2,3...}`.`t_{1,2,3...}` 同步到下游 TiDB 的一张表 `test`.`t`。 - -为了同步到下游实例的表 `test`.`t` 需要创建两个 table routing 规则： - -- `rule-1` 用来同步匹配上 `schema-pattern: "test_*"` 和 `table-pattern: "t_*"` 的表的 DML/DDL 语句到下游的 `test`.`t`。 -- `rule-2` 用来同步匹配上 `schema-pattern: "test_*"` 的库的 DDL 语句，例如 `create/drop schema xx`。 - -> **注意：** -> -> - 如果下游 TiDB `schema: test` 已经存在， 并且不会被删除，则可以省略 `rule-2`。 -> - 如果下游 TiDB `schema: test` 不存在，只设置了 `rule_1`，则同步会报错 `schema test doesn't exist`。 - -{{< copyable "" >}} - -```yaml - rule-1: - schema-pattern: "test_*" - table-pattern: "t_*" - target-schema: "test" - target-table: "t" - rule-2: - schema-pattern: "test_*" - target-schema: "test" -``` - -#### 分库合并 - -假设存在分库场景，将上游两个 MySQL 实例 `test_{1,2,3...}`.`t_{1,2,3...}` 同步到下游 TiDB 的 `test`.`t_{1,2,3...}`，创建一条路由规则即可： - -{{< copyable "" >}} - -```yaml - rule-1: - schema-pattern: "test_*" - target-schema: "test" -``` - -#### 错误的 table routing - -假设存在下面两个路由规则，`test_1_bak`.`t_1_bak` 可以匹配上 `rule-1` 和 `rule-2`，违反 table 路由的限制而报错。 - -{{< copyable "" >}} - -```yaml - rule-0: - schema-pattern: "test_*" - target-schema: "test" - rule-1: - schema-pattern: "test_*" - table-pattern: "t_*" - target-schema: "test" - target-table: "t" - rule-2: - schema-pattern: "test_1_bak" - table-pattern: "t_1_bak" - target-schema: "test" - target-table: "t_bak" -``` - -## Black & white table lists - -上游数据库实例表的黑白名单过滤规则，可以用来过滤或者只同步某些 `database/table` 的所有操作。 - -### 参数配置 - -{{< copyable "" >}} - -```yaml -black-white-list: - rule-1: - do-dbs: ["~^test.*"] # 以 ~ 字符开头，表示规则是正则表达式 -​ ignore-dbs: ["mysql"] - do-tables: - - db-name: "~^test.*" - tbl-name: "~^t.*" - - db-name: "test" - tbl-name: "t" - ignore-tables: - - db-name: "test" - tbl-name: "log" -``` - -### 参数解释 - -- `do-dbs`：要同步的库的白名单，类似于 MySQL 中的 [`replicate-do-db`](https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#option_mysqld_replicate-do-db)。 -- `ignore-dbs`：要同步的库的黑名单，类似于 MySQL 中的 [`replicate-ignore-db`](https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#option_mysqld_replicate-ignore-db)。 -- `do-tables`：要同步的表的白名单，类似于 MySQL 中的 [`replicate-do-table`](https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#option_mysqld_replicate-do-table)。 -- `ignore-tables`：要同步的表的黑名单，类似于 MySQL 中的 [`replicate-ignore-table`](https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#option_mysqld_replicate-ignore-table)。 - -以上参数值以 `~` 开头时均支持使用[正则表达式](https://golang.org/pkg/regexp/syntax/#hdr-syntax)来匹配库名、表名。 - -### 过滤规则 - -`do-dbs` 与 `ignore-dbs` 对应的过滤规则与 MySQL 中的 [Evaluation of Database-Level Replication and Binary Logging Options](https://dev.mysql.com/doc/refman/5.7/en/replication-rules-db-options.html) 类似，`do-tables` 与 `ignore-tables` 对应的过滤规则与 MySQL 中的 [Evaluation of Table-Level Replication Options](https://dev.mysql.com/doc/refman/5.7/en/replication-rules-table-options.html) 类似。 - -> **注意：** -> -> DM 中黑白名单过滤规则与 MySQL 中相应规则存在以下区别： -> -> - MySQL 中存在 [`replicate-wild-do-table`](https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#option_mysqld_replicate-wild-do-table) 与 [`replicate-wild-ignore-table`](https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#option_mysqld_replicate-wild-ignore-table) 用于支持通配符，DM 中各配置参数直接支持以 `~` 字符开头的正则表达式。 -> - DM 当前只支持 `ROW` 格式的 binlog，不支持 `STATEMENT`/`MIXED` 格式的 binlog，因此应与 MySQL 中 `ROW` 格式下的规则对应。 -> - 对于 DDL，MySQL 仅依据默认的 database 名称（`USE` 语句显式指定的 database）进行判断，而 DM 优先依据 DDL 中的 database 名称部分进行判断，并当 DDL 中不包含 database 名称时再依据 `USE` 部分进行判断。假设需要判断的 SQL 为 `USE test_db_2; CREATE TABLE test_db_1.test_table (c1 INT PRIMARY KEY)`，且 MySQL 配置了 `replicate-do-db=test_db_1`、DM 配置了 `do-dbs: ["test_db_1"]`，则对于 MySQL 该规则不会生效，而对于 DM 该规则会生效。 - -判断 table `test`.`t` 是否应该被过滤的过滤流程如下： - -1. 首先 **schema 过滤判断** - - - 如果 `do-dbs` 不为空，判断 `do-dbs` 中是否存在一个匹配的 schema。 - - - 如果存在，则进入 **table 过滤判断**。 - - 如果不存在，则过滤 `test`.`t`。 - - - 如果 `do-dbs` 为空并且 `ignore-dbs` 不为空，判断 `ignore-dbs` 中是否存在一个匹配的 schema。 - - - 如果存在，则过滤 `test`.`t`。 - - 如果不存在，则进入 **table 过滤判断**。 - - - 如果 `do-dbs` 和 `ignore-dbs` 都为空，则进入 **table 过滤判断**。 - -2. 进行 **table 过滤判断** - - 1. 如果 `do-tables` 不为空，判断 `do-tables` 中是否存在一个匹配的 table。 - - - 如果存在，则同步 `test`.`t`。 - - 如果不存在，则过滤 `test`.`t`。 - - 2. 如果 `ignore-tables` 不为空，判断 `ignore-tables` 中是否存在一个匹配的 table。 - - - 如果存在，则过滤 `test`.`t`. - - 如果不存在，则同步 `test`.`t`。 - - 3. 如果 `do-tables` 和 `ignore-tables` 都为空，则同步 `test`.`t`。 - -> **注意：** -> -> 判断 schema `test` 是否被过滤，只进行 **schema 过滤判断** - -### 使用示例 - -假设上游 MySQL 实例包含以下表： - -``` -`logs`.`messages_2016` -`logs`.`messages_2017` -`logs`.`messages_2018` -`forum`.`users` -`forum`.`messages` -`forum_backup_2016`.`messages` -`forum_backup_2017`.`messages` -`forum_backup_2018`.`messages` -``` - -配置如下： - -{{< copyable "" >}} - -```yaml -black-white-list: - bw-rule: - do-dbs: ["forum_backup_2018", "forum"] - ignore-dbs: ["~^forum_backup_"] - do-tables: - - db-name: "logs" - tbl-name: "~_2018$" - - db-name: "~^forum.*" -​ tbl-name: "messages" - ignore-tables: - - db-name: "~.*" -​ tbl-name: "^messages.*" -``` - -应用 `bw-rule` 规则后： - -| table | 是否过滤| 过滤的原因 | -|:----|:----|:--------------| -| `logs`.`messages_2016` | 是 | schema `logs` 没有匹配到 `do-dbs` 任意一项 | -| `logs`.`messages_2017` | 是 | schema `logs` 没有匹配到 `do-dbs` 任意一项 | -| `logs`.`messages_2018` | 是 | schema `logs` 没有匹配到 `do-dbs` 任意一项 | -| `forum_backup_2016`.`messages` | 是 | schema `forum_backup_2016` 没有匹配到 `do-dbs` 任意一项 | -| `forum_backup_2017`.`messages` | 是 | schema `forum_backup_2017` 没有匹配到 `do-dbs` 任意一项 | -| `forum`.`users` | 是 | 1. schema `forum` 匹配到 `do-dbs` 进入 table 过滤
2. schema 和 table 没有匹配到 `do-tables` 和 `ignore-tables` 中任意一项，并且 `do-tables` 不为空，因此过滤 | -| `forum`.`messages` | 否 | 1. schema `forum` 匹配到 `do-dbs` 进入 table 过滤
2. schema 和 table 匹配到 `do-tables` 的 `db-name: "~^forum.*",tbl-name: "messages"` | -| `forum_backup_2018`.`messages` | 否 | 1. schema `forum_backup_2018` 匹配到 `do-dbs` 进入 table 过滤
2. schema 和 table 匹配到 `do-tables` 的 `db-name: "~^forum.*",tbl-name: "messages"` | - -## Binlog event filter - -Binlog event filter 是比同步表黑白名单更加细粒度的过滤规则，可以指定只同步或者过滤掉某些 `schema / table` 的指定类型 binlog，比如 `INSERT`，`TRUNCATE TABLE`。 - -> **注意：** -> -> 同一个表匹配上多个规则，将会顺序应用这些规则，并且黑名单的优先级高于白名单，即如果同时存在规则 `Ignore` 和 `Do` 应用在某个 table 上，那么 `Ignore` 生效。 - -### 参数配置 - -{{< copyable "" >}} - -```yaml -filters: - rule-1: - schema-pattern: "test_*" - ​table-pattern: "t_*" - ​events: ["truncate table", "drop table"] - sql-pattern: ["^DROP\\s+PROCEDURE", "^CREATE\\s+PROCEDURE"] - ​action: Ignore -``` - -### 参数解释 - -- [`schema-pattern`/`table-pattern`](/dev/reference/tools/data-migration/table-selector.md)：对匹配上的上游 MySQL/MariaDB 实例的表的 binlog events 或者 DDL SQL 语句进行以下规则过滤。 - -- `events`：binlog events 数组。 - - | Event | 分类 | 解释 | - | --------------- | ---- | ----------------------------- | - | all | | 代表包含下面所有的 events | - | all dml | | 代表包含下面所有 DML events | - | all ddl | | 代表包含下面所有 DDL events | - | none | | 代表不包含下面所有 events | - | none ddl | | 代表不包含下面所有 DDL events | - | none dml | | 代表不包含下面所有 DML events | - | insert | DML | insert DML event | - | update | DML | update DML event | - | delete | DML | delete DML event | - | create database | DDL | create database event | - | drop database | DDL | drop database event | - | create table | DDL | create table event | - | create index | DDL | create index event | - | drop table | DDL | drop table event | - | truncate table | DDL | truncate table event | - | rename table | DDL | rename table event | - | drop index | DDL | drop index event | - | alter table | DDL | alter table event | - -- `sql-pattern`：用于过滤指定的 DDL SQL 语句，支持正则表达式匹配，例如上面示例 `"^DROP\\s+PROCEDURE"`。 - -- `action`：string(`Do` / `Ignore`)；进行下面规则判断，满足其中之一则过滤，否则不过滤。 - - - `Do`：白名单。binlog event 如果满足下面两个条件之一就会被过滤掉： - - 不在该 rule 的 `events` 中。 - - 如果规则的 `sql-pattern` 不为空的话，对应的 SQL 没有匹配上 `sql-pattern` 中任意一项。 - - `Ignore`：黑名单。如果满足下面两个条件之一就会被过滤掉： - - 在该 rule 的 `events` 中。 - - 如果规则的 `sql-pattern` 不为空的话，对应的 SQL 可以匹配上 `sql-pattern` 中任意一项。 - -### 使用示例 - -#### 过滤分库分表的所有删除操作 - -需要设置下面两个 `Binlog event filter rule` 来过滤掉所有的删除操作： - -- `filter-table-rule` 过滤掉所有匹配到 pattern `test_*`.`t_*` 的 table 的 `turncate table`、`drop table`、`delete statement` 操作。 -- `filter-schema-rule` 过滤掉所有匹配到 pattern `test_*` 的 schema 的 `drop database` 操作。 - -{{< copyable "" >}} - -```yaml -filters: - filter-table-rule: - schema-pattern: "test_*" - table-pattern: "t_*" - events: ["truncate table", "drop table", "delete"] - action: Ignore - filter-schema-rule: - schema-pattern: "test_*" - events: ["drop database"] - action: Ignore -``` - -#### 只同步分库分表的 DML 操作 - -需要设置下面两个 `Binlog event filter rule` 只同步 DML 操作： - -- `do-table-rule` 只同步所有匹配到 pattern `test_*`.`t_*` 的 table 的 `create table`、`insert`、`update`、`delete` 操作。 -- `do-schema-rule` 只同步所有匹配到 pattern `test_*` 的 schema 的 `create database` 操作。 - -> **注意：** -> -> 同步 `create database/table` 的原因是创建库和表后才能同步 `DML`。 - -{{< copyable "" >}} - -```yaml -filters: - do-table-rule: - schema-pattern: "test_*" - table-pattern: "t_*" - events: ["create table", "all dml"] - action: Do - do-schema-rule: - schema-pattern: "test_*" - events: ["create database"] - action: Do -``` - -#### 过滤 TiDB 不支持的 SQL 语句 - -可设置如下规则过滤 TiDB 不支持的 `PROCEDURE` 语句： - -{{< copyable "" >}} - -```yaml -filters: - filter-procedure-rule: - schema-pattern: "test_*" - table-pattern: "t_*" - sql-pattern: ["^DROP\\s+PROCEDURE", "^CREATE\\s+PROCEDURE"] - action: Ignore -``` - -#### 过滤 TiDB parser 不支持的 SQL 语句 - -对于 TiDB parser 不支持的 SQL 语句，DM 无法解析获得 `schema`/`table` 信息，因此需要使用全局过滤规则：`schema-pattern: "*"`。 - -> **注意：** -> -> 全局过滤规则的设置必须尽可能严格，以避免预期之外地过滤掉需要同步的数据。 - -可设置如下规则过滤 TiDB parser 不支持的 `PARTITION` 语句： - -{{< copyable "" >}} - -```yaml -filters: - filter-partition-rule: - schema-pattern: "*" - sql-pattern: ["ALTER\\s+TABLE[\\s\\S]*ADD\\s+PARTITION", "ALTER\\s+TABLE[\\s\\S]*DROP\\s+PARTITION"] - action: Ignore -``` - -## Column mapping - -> **注意：** -> -> 由于 Column mapping 的使用限制较多，我们不推荐使用 Column mapping 功能作为首选方案。我们优先推荐的方案请参考 [自增主键冲突处理](/dev/reference/tools/data-migration/usage-scenarios/best-practice-dm-shard.md#自增主键冲突处理)。 - -Column mapping 提供对表的列值进行修改的功能。可以根据不同的表达式对表的指定列做不同的修改操作，目前只支持 DM 提供的内置表达式。 - -> **注意：** -> -> - 不支持修改 column 的类型和表结构。 -> - 不支持对同一个表设置多个不同的列值转换规则。 - -### 参数配置 - -{{< copyable "" >}} - -```yaml -column-mappings: - rule-1: -​ schema-pattern: "test_*" -​ table-pattern: "t_*" -​ expression: "partition id" -​ source-column: "id" -​ target-column: "id" -​ arguments: ["1", "test", "t", "_"] - rule-2: -​ schema-pattern: "test_*" -​ table-pattern: "t_*" -​ expression: "partition id" -​ source-column: "id" -​ target-column: "id" -​ arguments: ["2", "test", "t", "_"] -``` - -### 参数解释 - -- [`schema-pattern`/`table-pattern`](/dev/reference/tools/data-migration/table-selector.md)：对匹配上该规则的上游 MySQL/MariaDB 实例的表按照指定 `expression` 进行列值修改操作。 -- `source-column`，`target-column`：对 `source-column` 列的值按照指定 `expression` 进行修改，将修改后的值赋值给 `target-column`。 -- `expression`：对数据进行转换的表达式，目前只支持下面的内置计算表达式。 - -#### `partition id` 表达式 - -`partition id` 目的是为了解决分库分表合并同步的自增主键的冲突。 - -**`partition id` 限制** - -注意下面的限制： - -- 只支持类型为 bigint 的列，通常为自增主键，联合主键或者联合唯一索引的其中一列 -- 如果 `schema 前缀` 不为空，则库名的组成必须为 `schema 前缀` 或者 `schema 前缀 + 分隔符 + 数字（即 schema ID）`，例如：支持 `s` 和 `s_1`，不支持 `s_a` -- 如果 `table 前缀` 不为空，则表名的组成必须为 `table 前缀` 或者 `table 前缀 + 分隔符 + 数字（即 table ID）` -- 如果库名/表名不包含 `… + 分隔符 + 数字` 部分，则对应的 ID 默认为 0 -- 对分库分表的规模支持限制如下 - - 支持最多 16 个 MySQL/MariaDB 实例，且需要满足 0 <= instance ID <= 15。 - - 每个实例支持最多 128 个 schema，且需要满足 0 <= schema ID <= 127。 - - 每个实例的每个 schema 支持最多 256 个 table，且需要满足 0 <= table ID <= 255。 - - 进行 Column mapping 的列的范围需要满足 0 <= ID <= 17592186044415。 - - `{instance ID, schema ID, table ID}` 组合需要保持唯一。 -- 目前该功能是定制功能，如果需要调整请联系相关开发人员进行调整 - -**`partition id` 参数配置** - -用户需要在 arguments 里面按顺序设置以下三个或四个参数： - -- `instance_id`：客户指定的上游分库分表的 MySQL/MariaDB instance ID（0 <= instance ID <= 15） -- `schema 前缀`：用来解析库名并获取 `schema ID` -- `table 前缀`：用来解释表名并获取 `table ID` -- 分隔符：用来分隔前缀与 ID，可省略，省略时分隔符默认为空字符串 - -`instance_id`、`schema 前缀` 和 `table 前缀` 这三个参数均可被设置为空字符串（`""`），表示对应的部分不会被编码进 `partition id`。 - -**`partition id` 表达式规则** - -`partition id` 会用 arguments 里面的数字来填充自增主键 ID 的首个比特位，计算出来一个 int64（即 MySQL bigint）类型的值，具体规则如下： - -| instance_id | schema 前缀 | table 前缀 | 编码 | -|:------------|:--------------|:-------------|---------:| -| ☑ 已定义 | ☑ 已定义 | ☑ 已定义 | [`S`: 1 比特位] [`I`: 4 比特位] [`D`: 7 比特位] [`T`: 8 比特位] [`P`: 44 比特位] | -| ☐ 空 | ☑ 已定义 | ☑ 已定义 | [`S`: 1 比特位] [`D`: 7 比特位] [`T`: 8 比特位] [`P`: 48 比特位] | -| ☑ 已定义 | ☐ 空 | ☑ 已定义 | [`S`: 1 比特位] [`I`: 4 比特位] [`T`: 8 比特位] [`P`: 51 比特位] | -| ☑ 已定义 | ☑ 已定义 | ☐ 空 | [`S`: 1 比特位] [`I`: 4 比特位] [`D`: 7 比特位] [`P`: 52 比特位] | -| ☐ 空 | ☐ 空 | ☑ 已定义 | [`S`: 1 比特位] [`T`: 8 比特位] [`P`: 55 比特位] | -| ☐ 空 | ☑ 已定义 | ☐ 空 | [`S`: 1 比特位] [`D`: 7 比特位] [`P`: 56 比特位] | -| ☑ 已定义 | ☐ 空 | ☐ 空 | [`S`: 1 比特位] [`I`: 4 比特位] [`P`: 59 比特位] | - -- `S`：符号位，保留 -- `I`：instance ID，默认 4 比特位 -- `D`：schema ID，默认 7 比特位 -- `T`：table ID，默认 8 比特位 -- `P`：自增主键 ID，占据剩下的比特位（≥44 比特位） - -### 使用示例 - -假设存在分库分表场景：将上游两个 MySQL 实例的 `test_{1,2,3...}`.`t_{1,2,3...}` 同步到下游 TiDB 的 `test`.`t`，并且这些表都有自增主键。 - -需要设置下面两个规则： - -{{< copyable "" >}} - -```yaml -column-mappings: - rule-1: -​ schema-pattern: "test_*" -​ table-pattern: "t_*" -​ expression: "partition id" -​ source-column: "id" -​ target-column: "id" -​ arguments: ["1", "test", "t", "_"] - rule-2: -​ schema-pattern: "test_*" -​ table-pattern: "t_*" -​ expression: "partition id" -​ source-column: "id" -​ target-column: "id" -​ arguments: ["2", "test", "t", "_"] -``` - -- MySQL instance 1 的表 `test_1`.`t_1` 的 `ID = 1` 的行经过转换后 ID = 1 变为 `1 << (64-1-4) | 1 << (64-1-4-7) | 1 << 44 | 1 = 580981944116838401` -- MySQL instance 2 的表 `test_1`.`t_2` 的 `ID = 1` 的行经过转换后 ID = 2 变为 `2 << (64-1-4) | 1 << (64-1-4-7) | 2 << 44 | 2 = 1157460288606306306` - -## 同步延迟监控 - -DM 支持通过 heartbeat 真实同步数据来计算每个同步任务与 MySQL/MariaDB 的实时同步延迟。 - -> **注意：** -> -> - 同步延迟的估算的精度在秒级别。 -> - heartbeat 相关的 binlog 不会同步到下游，在计算延迟后会被丢弃。 - -### 系统权限 - -如果开启 heartbeat 功能，需要上游 MySQL/MariaDB 实例提供下面的权限： - -- SELECT -- INSERT -- CREATE (databases, tables) - -### 参数配置 - -在 task 的配置文件中设置： - -``` -enable-heartbeat: true -``` - -### 原理介绍 - -- DM-worker 在对应的上游 MySQL/MariaDB 创建库 `dm_heartbeat`（当前不可配置） -- DM-worker 在对应的上游 MySQL/MariaDB 创建表 `heartbeat`（当前不可配置） -- DM-worker 每秒钟（当前不可配置）在对应的上游 MySQL/MariaDB 的 `dm_heartbeat`.`heartbeat` 表中，利用 `replace statement` 更新当前时间戳 `TS_master` -- DM-worker 每个任务拿到 `dm_heartbeat`.`heartbeat` 的 binlog 后，更新自己的同步时间 `TS_slave_task` -- DM-worker 每 10 秒在对应的上游 MySQL/MariaDB 的 `dm_heartbeat`.`heartbeat` 查询当前的 `TS_master`，并且对每个任务计算 `task_lag` = `TS_master` - `TS_slave_task` - -可以在 metrics 的 [binlog replication](/dev/reference/tools/data-migration/monitor.md#binlog-replication) 处理单元找到 replicate lag 监控项。 diff --git a/dev/reference/tools/data-migration/features/shard-merge.md b/dev/reference/tools/data-migration/features/shard-merge.md deleted file mode 100644 index fa33669463c3..000000000000 --- a/dev/reference/tools/data-migration/features/shard-merge.md +++ /dev/null @@ -1,177 +0,0 @@ ---- -title: 分库分表合并同步 -category: reference ---- - -# 分库分表合并同步 - -本文介绍了 DM 提供的分库分表合并同步功能。此功能用于将上游 MySQL/MariaDB 实例中结构相同的表同步到下游 TiDB 的同一个表中。DM 不仅支持同步上游的 DML 数据，也支持协调同步多个上游分表的 DDL 表结构变更。 - -> **注意：** -> -> 要执行分库分表合并同步任务，必须在任务配置文件中设置 `is-sharding: true`。 - -## 使用限制 - -DM 进行分表 DDL 的同步有以下几点使用限制： - -- 在一个逻辑 sharding group（需要合并同步到下游同一个表的所有分表组成的 group）内，所有上游分表必须以相同的顺序执行相同的 DDL 语句（库名和表名可以不同），并且只有在所有分表执行完当前一条 DDL 语句后，下一条 DDL 语句才能执行。 - - - 比如，如果在 table_1 表中先增加列 a 后再增加列 b，则在 table_2 表中就不能先增加列 b 后再增加列 a，因为 DM 不支持以不同的顺序来执行相同的 DDL 语句。 - -- 对于每个逻辑 sharding group，推荐使用一个独立的任务进行同步。 - - - 如果一个任务内存在多个 sharding group，则必须等待一个 sharding group 的 DDL 语句同步完成后，才能开始对其他 sharding group 执行 DDL 语句。 - -- 在一个逻辑 sharding group 内，所有上游分表都应该执行对应的 DDL 语句。 - - - 比如，若 DM-worker-2 对应的一个或多个上游分表未执行 DDL 语句，则其他已执行 DDL 语句的 DM-worker 都会暂停同步任务，直到等到 DM-worker-2 收到上游对应的 DDL 语句。 - -- sharding group 数据同步任务不支持 `DROP DATABASE/TABLE` 语句。 - - - DM-worker 中的 binlog 同步单元（sync）会自动忽略掉上游分表的 `DROP DATABASE` 和 `DROP TABLE` 语句。 - -- sharding group 数据同步任务支持 `RENAME TABLE` 语句，但有如下限制（online DDL 中的 `RENAME` 有特殊方案进行支持）： - - - 只支持 `RENAME TABLE` 到一个不存在的表。 - - 一条 `RENAME TABLE` 语句只能包含一个 `RENAME` 操作。 - -- 增量同步任务需要确认开始同步的 binlog position 上各分表的表结构必须一致，才能确保来自不同分表的 DML 语句能够同步到表结构确定的下游，并且后续各分表的 DDL 语句能够正确匹配与同步。 - -- 如果需要变更 [table routing 规则](/dev/reference/tools/data-migration/features/overview.md#table-routing)，必须先等所有 sharding DDL 语句同步完成。 - - - 在 sharding DDL 语句同步过程中，使用 dmctl 尝试变更 router-rules 会报错。 - -- 如果需要创建新表加入到一个正在执行 DDL 语句的 sharding group 中，则必须保持新表结构和最新更改的表结构一致。 - - - 比如，原 table_1, table_2 表初始时有 (a, b) 两列，sharding DDL 语句执行后有 (a, b, c) 三列，则同步完成后新创建的表也应当有 (a, b, c) 三列。 - -- 由于已经收到 DDL 语句的 DM-worker 会暂停任务以等待其他 DM-worker 收到对应的 DDL 语句，因此数据同步延迟会增加。 - -## 背景 - -目前，DM 使用 ROW 格式的 binlog 进行数据同步，且 binlog 中不包含表结构信息。在 ROW 格式的 binlog 同步过程中，如果不需要将多个上游表合并同步到下游的同一个表，则只存在一个上游表的 DDL 语句会更新对应下游表结构。ROW 格式的 binlog 可以认为是具有 self-description 属性。 - -分库分表合并同步过程中，可以根据 column values 及下游的表结构构造出相应的 DML 语句，但此时若上游的分表执行 DDL 语句进行了表结构变更，则必须对该 DDL 语句进行额外同步处理，以避免因为表结构和 binlog 数据不一致而造成同步出错的问题。 - -以下是一个简化后的例子： - -![shard-ddl-example-1](/media/shard-ddl-example-1.png) - -在上图的例子中，分表的合库合表过程简化成了上游只有两个 MySQL 实例，每个实例内只有一个表。假设在数据同步开始时，将两个分表的表结构版本记为 schema V1，将 DDL 语句执行完后的表结构版本记为 schema V2。 - -现在，假设数据同步过程中，DM-worker 内的 binlog 同步单元（sync）从两个上游分表收到的 binlog 数据有如下时序： - -1. 开始同步时，sync 从两个分表收到的都是 schema V1 版本的 DML 语句。 - -2. 在 t1 时刻，sync 收到实例 1 上分表的 DDL 语句。 - -3. 从 t2 时刻开始，sync 从实例 1 收到的是 schema V2 版本的 DML 语句；但从实例 2 收到的仍是 schema V1 版本的 DML 语句。 - -4. 在 t3 时刻，sync 收到实例 2 上分表的 DDL 语句。 - -5. 从 t4 时刻开始，sync 从实例 2 收到的也是 schema V2 版本的 DML 语句。 - -假设在数据同步过程中，不对分表的 DDL 语句进行额外处理。当实例 1 的 DDL 语句同步到下游后，下游的表结构会变更成为 schema V2 版本。但在 t2 到 t3 这段时间内，sync 从实例 2 上收到的仍是 schema V1 版本的 DML 语句。当尝试把这些 schema V1 版本的 DML 语句同步到下游时，就会由于 DML 语句与表结构的不一致而发生错误，从而无法正确同步数据。 - -## 实现原理 - -基于上述例子，本部分介绍了 DM 在合库合表过程中进行 DDL 同步的实现原理。 - -![shard-ddl-flow](/media/shard-ddl-flow.png) - -在这个例子中，DM-worker-1 负责同步来自 MySQL 实例 1 的数据，DM-worker-2 负责同步来自 MySQL 实例 2 的数据，DM-master 负责协调多个 DM-worker 间的 DDL 同步。 - -从 DM-worker-1 收到 DDL 语句开始，简化后的 DDL 同步流程为： - -1. 在 t1 时刻，DM-worker-1 收到来自 MySQL 实例 1 的 DDL 语句，自身暂停该 DDL 语句对应任务的 DDL 及 DML 数据同步，并将 DDL 相关信息发送给 DM-master。 - -2. DM-master 根据收到的 DDL 信息判断得知需要协调该 DDL 语句的同步，于是为该 DDL 语句创建一个锁，并将 DDL 锁信息发回给 DM-worker-1，同时将 DM-worker-1 标记为这个锁的 owner。 - -3. DM-worker-2 继续进行 DML 语句的同步，直到在 t3 时刻收到来自 MySQL 实例 2 的 DDL 语句，自身暂停该 DDL 语句对应任务的数据同步，并将 DDL 相关信息发送给 DM-master。 - -4. DM-master 根据收到的 DDL 信息判断得知该 DDL 语句对应的锁信息已经存在，于是直接将对应锁信息发回给 DM-worker-2。 - -5. 根据任务启动时的配置信息、上游 MySQL 实例分表信息、部署拓扑信息等，DM-master 判断得知自身已经收到了来自待合表的所有上游分表的 DDL 语句，于是请求 DDL 锁的 owner（DM-worker-1）向下游同步执行该 DDL。 - -6. DM-worker-1 根据第二步收到的 DDL 锁信息验证 DDL 语句执行请求；向下游执行 DDL，并将执行结果反馈给 DM-master；若 DDL 语句执行成功，则自身开始继续同步后续的（从 t2 时刻对应的 binlog 开始的）DML 语句。 - -7. DM-master 收到来自 owner 执行 DDL 语句成功的响应，于是请求在等待该 DDL 锁的所有其他 DM-worker（DM-worker-2）忽略该 DDL 语句，直接继续同步后续的（从 t4 时刻对应的 binlog 开始的）DML 语句。 - -根据上面的流程，可以归纳出 DM 协调多个 DM-worker 间 sharding DDL 同步的特点： - -- 根据任务配置与 DM 集群部署拓扑信息，DM-master 内部也会建立一个逻辑 sharding group 来协调 DDL 同步，group 中的成员为负责处理该同步任务拆解后的各子任务的 DM-worker。 - -- 各 DM-worker 从 binlog event 中收到 DDL 语句后，会将 DDL 信息发送给 DM-master。 - -- DM-master 根据来自 DM-worker 的 DDL 信息及 sharding group 信息创建或更新 DDL 锁。 - -- 如果 sharding group 的所有成员都收到了某一条相同的 DDL 语句，则表明上游分表在该 DDL 执行前的 DML 语句都已经同步完成，此时可以执行该 DDL 语句，并继续后续的 DML 同步。 - -- 上游所有分表的 DDL 在经过 [table router](/dev/reference/tools/data-migration/features/overview.md#table-routing) 转换后需要保持一致，因此仅需 DDL 锁的 owner 执行一次该 DDL 语句即可，其他 DM-worker 可直接忽略对应的 DDL 语句。 - -在上面的示例中，每个 DM-worker 对应的上游 MySQL 实例中只有一个待合并的分表。但在实际场景下，一个 MySQL 实例可能有多个分库内的多个分表需要进行合并，这种情况下，sharding DDL 的协调同步过程将更加复杂。 - -假设同一个 MySQL 实例中有 table_1 和 table_2 两个分表需要进行合并： - -![shard-ddl-example-2](/media/shard-ddl-example-2.png) - -在这个例子中，由于数据来自同一个 MySQL 实例，因此所有数据都是从同一个 binlog 流中获得，时序如下： - -1. 开始同步时，DM-worker 内的 sync 从两个分表收到的数据都是 schema V1 版本的 DML 语句。 - -2. 在 t1 时刻，sync 收到 table_1 分表的 DDL 语句。 - -3. 从 t2 到 t3 时刻，sync 收到的数据同时包含 table_1 的 DML 语句（schema V2 版本）及 table_2 的 DML 语句（schema V1 版本）。 - -4. 在 t3 时刻，sync 收到 table_2 分表的 DDL 语句。 - -5. 从 t4 时刻开始，sync 从两个分表收到的数据都是 schema V2 版本的 DML 语句。 - -假设在数据同步过程中，不对分表的 DDL 语句进行额外处理。当 table_1 的 DDL 语句同步到下游从而变更下游表结构后，table_2 的 DML 语句（schema V1 版本）将无法正常同步。因此，在单个 DM-worker 内部，我们也构造了与 DM-master 内类似的逻辑 sharding group，但 group 的成员是同一个上游 MySQL 实例的不同分表。 - -DM-worker 内协调处理 sharding group 的同步与 DM-master 处理 DM-worker 之间的同步不完全一致，主要原因包括： - -- 当 DM-worker 收到 table_1 分表的 DDL 语句时，同步不能暂停，需要继续解析 binlog 才能获得后续 table_2 分表的 DDL 语句，即需要从 t2 时刻继续解析直到 t3 时刻。 - -- 在继续解析 t2 到 t3 时刻的 binlog 的过程中，table_1 分表的 DML 语句（schema V2 版本）不能向下游同步；但当 sharding DDL 同步并执行成功后，这些 DML 语句则需要同步到下游。 - -DM-worker 内部 sharding DDL 同步的简化流程为： - -1. 在 t1 时刻，DM-worker 收到 table_1 的 DDL 语句，并记录 DDL 信息及此时的 binlog 位置点信息。 - -2. DM-worker 继续向前解析 t2 到 t3 时刻的 binlog。 - -3. 对于 table_1 的 DML 语句（schema V2 版本），忽略；对于 table_2 的 DML 语句（schema V1 版本），正常同步到下游。 - -4. 在 t3 时刻，DM-worker 收到 table_2 的 DDL 语句，并记录 DDL 信息及此时的 binlog 位置点信息。 - -5. 根据同步任务配置信息、上游库表信息等，DM-worker 判断得知该 MySQL 实例上所有分表的 DDL 语句都已收到；于是将该 DDL 语句同步到下游执行并变更下游表结构。 - -6. DM-worker 设置 binlog 流的新解析起始位置点为第一步时保存的位置点。 - -7. DM-worker 重新开始解析从 t2 到 t3 时刻的 binlog。 - -8. 对于 table_1 的 DML 语句（schema V2 版本），正常同步到下游；对于 table_2 的 DML 语句（schema V1 版本），忽略。 - -9. 解析到达第四步时保存的 binlog 位置点，可得知在第三步时被忽略的所有 DML 语句都已经重新同步到下游。 - -10. DM-worker 继续从 t4 时刻对应的 binlog 位置点开始正常同步。 - -综上可知，DM 在处理 sharding DDL 同步时，主要通过两级 sharding group 来进行协调控制，简化的流程为： - -1. 各 DM-worker 独立地协调对应上游 MySQL 实例内多个分表组成的 sharding group 的 DDL 同步。 - -2. 当 DM-worker 收到所有分表的 DDL 语句时，向 DM-master 发送 DDL 相关信息。 - -3. DM-master 根据 DM-worker 发来的 DDL 信息，协调由各 DM-worker 组成的 sharing group 的 DDL 同步。 - -4. 当 DM-master 收到所有 DM-worker 的 DDL 信息时，请求 DDL 锁的 owner（某个 DM-worker） 执行该 DDL 语句。 - -5. DDL 锁的 owner 执行 DDL 语句，并将结果反馈给 DM-master；自身开始重新同步在内部协调 DDL 同步过程中被忽略的 DML 语句。 - -6. 当 DM-master 收到 owner 执行 DDL 成功的消息后，请求其他所有 DM-worker 继续开始同步。 - -7. 其他所有 DM-worker 各自开始重新同步在内部协调 DDL 同步过程中被忽略的 DML 语句。 - -8. 在完成被忽略的 DML 语句的重新同步后，所有 DM-worker 继续正常同步。 diff --git a/dev/reference/tools/data-migration/from-aurora.md b/dev/reference/tools/data-migration/from-aurora.md deleted file mode 100644 index 15d6fbb259bb..000000000000 --- a/dev/reference/tools/data-migration/from-aurora.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -title: 从 AWS Aurora MySQL 迁移数据 -summary: 使用 DM 从 AWS Aurora MySQL 迁移数据。 -category: reference ---- - -# 从 AWS Aurora MySQL 迁移数据 - -本文介绍如何使用 DM 从 [AWS Aurora MySQL](https://aws.amazon.com/cn/rds/aurora/details/mysql-details/) 迁移数据到 TiDB。 - -## 第 1 步：在 Aurora 集群中启用 binlog - -假设有两个 Aurora 集群需要迁移数据到 TiDB，其集群信息如下，其中 Aurora-1 包含一个独立的读取器节点。 - -| 集群 | 终端节点 | 端口 | 角色 | -|:-------- |:--- | :--- | :--- | -| Aurora-1 | pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com | 3306 | 写入器 | -| Aurora-1 | pingcap-1-us-east-2a.h8emfqdptyc4.us-east-2.rds.amazonaws.com | 3306 | 读取器 | -| Aurora-2 | pingcap-2.h8emfqdptyc4.us-east-2.rds.amazonaws.com | 3306 | 写入器 | - -DM 在增量同步阶段依赖 `ROW` 格式的 binlog，如果未启用 binlog 及设置正确的 binlog 格式，则不能正常使用 DM 进行数据同步，具体可参见[检查内容](/dev/reference/tools/data-migration/precheck.md#检查内容)。 - -> **注意：** -> -> Aurora 读取器不能开启 binlog，因此不能作为 DM 数据迁移时的上游 master server。 - -如果需要基于 GTID 进行数据迁移，还需要为 Aurora 集群启用 GTID 支持。 - -> **注意：** -> -> 基于 GTID 的数据迁移需要 MySQL 5.7 (Aurora 2.04.1) 或更高版本。 - -### 为 Aurora 集群修改 binlog 相关参数 - -在 Aurora 集群中，binlog 相关参数是**集群参数组中的集群级参数**，有关如何为 Aurora 集群启用 binlog 支持，请参考[在复制主实例上启用二进制日志记录](https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html#AuroraMySQL.Replication.MySQL.EnableBinlog)。在使用 DM 进行数据迁移时，需要将 `binlog_format` 参数设置为 `ROW`。 - -如果需要基于 GTID 进行数据迁移，需要将 `gtid-mode` 与 `enforce_gtid_consistency` 均设置为 `ON`。有关如何为 Aurora 集群启用基于 GTID 的数据迁移支持，请参考 [Configuring GTID-Based Replication for an Aurora MySQL Cluster](https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/mysql-replication-gtid.html#mysql-replication-gtid.configuring-aurora)。 - -> **注意：** -> -> 在 Aurora 管理后台中，`gtid_mode` 参数表示为 `gtid-mode`。 - -## 第 2 步：部署 DM 集群 - -目前推荐使用 DM-Ansible 部署 DM 集群，具体部署方法参照[使用 DM-Ansible 部署 DM 集群](/dev/how-to/deploy/data-migration-with-ansible.md)。 - -> **注意：** -> -> - 在 DM 所有的配置文件中，数据库的密码要使用 dmctl 加密后的密文。如果数据库密码为空，则不需要加密。关于如何使用 dmctl 加密明文密码，参考[使用 dmctl 加密上游 MySQL 用户密码](/dev/how-to/deploy/data-migration-with-ansible.md#使用-dmctl-加密上游-mysql-用户密码)。 -> - 上下游数据库用户必须拥有相应的读写权限。 - -## 第 3 步：检查集群信息 - -使用 DM-Ansible 部署 DM 集群后，相关配置信息如下： - -- DM 集群相关组件配置信息 - - | 组件 | 主机 | 端口 | - |:------|:---- |:---- | - | dm_worker1 | 172.16.10.72 | 8262 | - | dm_worker2 | 172.16.10.73 | 8262 | - | dm_master | 172.16.10.71 | 8261 | - -- 上下游数据库实例相关信息 - - | 数据库实例 | 主机 | 端口 | 用户名 | 加密密码 | - |:-------- |:--- | :--- | :--- | :--- | - | 上游 Aurora-1 | pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com | 3306 | root | VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU= | - | 上游 Aurora-2 | pingcap-2.h8emfqdptyc4.us-east-2.rds.amazonaws.com | 3306 | root | VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU= | - | 下游 TiDB | 172.16.10.83 | 4000 | root | | - -- dm-master 进程配置文件 `{ansible deploy}/conf/dm-master.toml` 中的配置 - - ```toml - # Master 配置。 - - [[deploy]] - source-id = "mysql-replica-01" - dm-worker = "172.16.10.72:8262" - - [[deploy]] - source-id = "mysql-replica-02" - dm-worker = "172.16.10.73:8262" - ``` - -## 第 4 步：配置任务 - -假设需要将 Aurora-1 和 Aurora-2 实例的 `test_db` 库的 `test_table` 表以**全量+增量**的模式同步到下游 TiDB 的 `test_db` 库的 `test_table` 表。 - -复制并编辑 `{ansible deploy}/conf/task.yaml.example`，生成如下任务配置文件 `task.yaml`： - -```yaml -# 任务名，多个同时运行的任务不能重名。 -name: "test" -# 全量+增量 (all) 同步模式。 -task-mode: "all" -# 下游 TiDB 配置信息。 -target-database: - host: "172.16.10.83" - port: 4000 - user: "root" - password: "" - -# 当前数据同步任务需要的全部上游 MySQL 实例配置。 -mysql-instances: -- - # 上游实例或者复制组 ID，参考 `inventory.ini` 的 `source_id` 或者 `dm-master.toml` 的 `source-id 配置`。 - source-id: "mysql-replica-01" - # 需要同步的库名或表名的黑白名单的配置项名称，用于引用全局的黑白名单配置，全局配置见下面的 `black-white-list` 的配置。 - black-white-list: "global" - # Mydumper 的配置项名称，用于引用全局的 Mydumper 配置。 - mydumper-config-name: "global" - -- - source-id: "mysql-replica-02" - black-white-list: "global" - mydumper-config-name: "global" - -# 黑白名单全局配置，各实例通过配置项名引用。 -black-white-list: - global: - do-tables: # 需要同步的上游表的白名单。 - - db-name: "test_db" # 需要同步的表的库名。 - tbl-name: "test_table" # 需要同步的表的名称。 - -# Mydumper 全局配置，各实例通过配置项名引用。 -mydumpers: - global: - extra-args: "-B test_db -T test_table" # mydumper 的其他参数，从 DM 1.0.2 版本开始，DM 会自动生成 table-list 配置，在其之前的版本仍然需要人工配置。 -``` - -## 第 5 步：启动任务 - -1. 进入 dmctl 目录 `/home/tidb/dm-ansible/resources/bin/` - -2. 执行以下命令启动 dmctl - - {{< copyable "shell-regular" >}} - - ```bash - ./dmctl --master-addr 172.16.10.71:8261 - ``` - -3. 执行以下命令启动数据同步任务，其中，`task.yaml` 是之前编辑的配置文件 - - {{< copyable "" >}} - - ```bash - » start-task ./task.yaml - ``` - - - 如果执行命令后的返回结果中不包含错误信息，则表明任务已经成功启动 - - 如果包含以下错误信息，则表明上游 Aurora 用户可能拥有 TiDB 不支持的权限类型 - - ```json - { - "id": 4, - "name": "source db dump privilege chcker", - "desc": "check dump privileges of source DB", - "state": "fail", - "errorMsg": "line 1 column 285 near \"LOAD FROM S3, SELECT INTO S3 ON *.* TO 'root'@'%' WITH GRANT OPTION\" ...", - "instruction": "", - "extra": "address of db instance - pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com" - }, - { - "id": 5, - "name": "source db replication privilege chcker", - "desc": "check replication privileges of source DB", - "state": "fail", - "errorMsg": "line 1 column 285 near \"LOAD FROM S3, SELECT INTO S3 ON *.* TO 'root'@'%' WITH GRANT OPTION\" ...", - "instruction": "", - "extra": "address of db instance - pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com" - } - ``` - - 此时可以选择以下两种处理方法中的任意一种进行处理后，再使用 `start-task` 尝试重新启动任务： - 1. 为用于进行数据迁移的 Aurora 用户移除不被 TiDB 支持的不必要的权限 - 2. 如果能确保 Aurora 用户拥有 DM 所需要的权限，可以在 `task.yaml` 配置文件中添加如下顶级配置项以跳过启用任务时的前置权限检查 - - ```yaml - ignore-checking-items: ["dump_privilege", "replication_privilege"] - ``` - -## 第 6 步：查询任务 - -如需了解 DM 集群中是否存在正在运行的同步任务及任务状态等信息，可在 dmctl 内使用以下命令进行查询： - -{{< copyable "" >}} - -```bash -» query-status -``` - -> **注意：** -> -> 如果查询命令的返回结果中包含以下错误信息，则表明在全量同步的 dump 阶段不能获得相应的 lock： -> -> ```bash -> Couldn't acquire global lock, snapshots will not be consistent: Access denied for user 'root'@'%' (using password: YES) -> ``` -> -> 此时如果能接受不使用 FTWL 来确保 dump 文件与 metadata 的一致或上游能暂时停止写入，可以通过为 `mydumpers` 下的 `extra-args` 添加 `--no-locks` 参数来进行绕过，具体方法为： -> -> 1. 使用 `stop-task` 停止当前由于不能正常 dump 而已经转为 paused 的任务 -> 2. 将原 task.yaml 中的 `extra-args: "-B test_db -T test_table"` 更新为 `extra-args: "-B test_db -T test_table --no-locks"` -> 3. 使用 `start-task` 重新启动任务 diff --git a/dev/reference/tools/data-migration/overview.md b/dev/reference/tools/data-migration/overview.md deleted file mode 100644 index 8f3a3b5ea6bb..000000000000 --- a/dev/reference/tools/data-migration/overview.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: Data Migration 简介 -category: reference ---- - -# Data Migration 简介 - -[DM](https://github.com/pingcap/dm) (Data Migration) 是一体化的数据同步任务管理平台，支持从 MySQL 或 MariaDB 到 TiDB 的全量数据迁移和增量数据同步。使用 DM 工具有利于简化错误处理流程，降低运维成本。 - -## DM 架构 - -DM 主要包括三个组件：DM-master，DM-worker 和 dmctl。 - -![Data Migration architecture](/media/dm-architecture.png) - -### DM-master - -DM-master 负责管理和调度数据同步任务的各项操作。 - -- 保存 DM 集群的拓扑信息 -- 监控 DM-worker 进程的运行状态 -- 监控数据同步任务的运行状态 -- 提供数据同步任务管理的统一入口 -- 协调分库分表场景下各个实例分表的 DDL 同步 - -### DM-worker - -DM-worker 负责执行具体的数据同步任务。 - -- 将 binlog 数据持久化保存在本地 -- 保存数据同步子任务的配置信息 -- 编排数据同步子任务的运行 -- 监控数据同步子任务的运行状态 - -DM-worker 启动后，会自动同步上游 binlog 至本地配置目录（如果使用 DM-Ansible 部署 DM 集群，默认的同步目录为 `/relay_log`）。关于 DM-worker，详见 [DM-worker 简介](/dev/reference/tools/data-migration/dm-worker-intro.md)。关于 relay log，详见 [DM Relay Log](/dev/reference/tools/data-migration/relay-log.md)。 - -### dmctl - -dmctl 是用来控制 DM 集群的命令行工具。 - -- 创建、更新或删除数据同步任务 -- 查看数据同步任务状态 -- 处理数据同步任务错误 -- 校验数据同步任务配置的正确性 - -## 同步功能介绍 - -下面简单介绍 DM 数据同步功能的核心特性。 - -### Table routing - -[Table routing](/dev/reference/tools/data-migration/features/overview.md#table-routing) 是指将上游 MySQL 或 MariaDB 实例的某些表同步到下游指定表的路由功能，可以用于分库分表的合并同步。 - -### Black & white table lists - -[Black & white table lists](/dev/reference/tools/data-migration/features/overview.md#black--white-table-lists) 是指上游数据库实例表的黑白名单过滤规则。其过滤规则类似于 MySQL `replication-rules-db`/`replication-rules-table`，可以用来过滤或只同步某些数据库或某些表的所有操作。 - -### Binlog event filter - -[Binlog event filter](/dev/reference/tools/data-migration/features/overview.md#binlog-event-filter) 是比库表同步黑白名单更加细粒度的过滤规则，可以指定只同步或者过滤掉某些 `schema`/`table` 的指定类型的 binlog events，比如 `INSERT`，`TRUNCATE TABLE`。 - -### Shard support - -DM 支持对原分库分表进行合库合表操作，但需要满足一些[使用限制](/dev/reference/tools/data-migration/features/shard-merge.md#使用限制)。 - -## 使用限制 - -在使用 DM 工具之前，需了解以下限制： - -+ 数据库版本 - - - 5.5 < MySQL 版本 < 8.0 - - MariaDB 版本 >= 10.1.2 - - > **注意：** - > - > 如果上游 MySQL/MariaDB server 间构成主从复制结构，则 - > - > - 5.7.1 < MySQL 版本 < 8.0 - > - MariaDB 版本 >= 10.1.3 - - 在使用 dmctl 启动任务时，DM 会自动对任务上下游数据库的配置、权限等进行[前置检查](/dev/reference/tools/data-migration/precheck.md)。 - -+ DDL 语法 - - - 目前，TiDB 部分兼容 MySQL 支持的 DDL 语句。因为 DM 使用 TiDB parser 来解析处理 DDL 语句，所以目前仅支持 TiDB parser 支持的 DDL 语法。详见 [TiDB DDL 语法支持](/dev/reference/mysql-compatibility.md#ddl)。 - - - DM 遇到不兼容的 DDL 语句时会报错。要解决此报错，需要使用 dmctl 手动处理，要么跳过该 DDL 语句，要么用指定的 DDL 语句来替换它。详见[如何处理不兼容的 DDL 语句](/dev/reference/tools/data-migration/faq.md#如何处理不兼容的-ddl-语句)。 - -+ 分库分表 - - - 如果业务分库分表之间存在数据冲突，可以参考[自增主键冲突处理](/dev/reference/tools/data-migration/usage-scenarios/best-practice-dm-shard.md#自增主键冲突处理)来解决；否则不推荐使用 DM 进行同步，如果进行同步则有冲突的数据会相互覆盖造成数据丢失。 - - 关于分库分表合并场景的其它限制，参见[使用限制](/dev/reference/tools/data-migration/features/shard-merge.md#使用限制)。 - -+ 操作限制 - - - DM-worker 重启后不能自动恢复数据同步任务，需要使用 dmctl 手动执行 `start-task`。详见[管理数据同步任务](/dev/reference/tools/data-migration/manage-tasks.md)。 - - 在一些情况下，DM-worker 重启后不能自动恢复 DDL lock 同步，需要手动处理。详见[手动处理 Sharding DDL Lock](/dev/reference/tools/data-migration/features/manually-handling-sharding-ddl-locks.md)。 - -+ DM-worker 切换 MySQL - - - 当 DM-worker 通过虚拟 IP（VIP）连接到 MySQL 且要切换 VIP 指向的 MySQL 实例时，DM 内部不同的 connection 可能会同时连接到切换前后不同的 MySQL 实例，造成 DM 拉取的 binlog 与从上游获取到的其他状态不一致，从而导致难以预期的异常行为甚至数据损坏。如需切换 VIP 指向的 MySQL 实例，请参考[虚拟 IP 环境下的上游主从切换](/dev/reference/tools/data-migration/usage-scenarios/master-slave-switch.md#虚拟-ip-环境下切换-dm-worker-与-mysql-实例的连接)对 DM 手动执行变更。 diff --git a/dev/reference/tools/data-migration/precheck.md b/dev/reference/tools/data-migration/precheck.md deleted file mode 100644 index 4e02cc8abb52..000000000000 --- a/dev/reference/tools/data-migration/precheck.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: 上游 MySQL 实例配置前置检查 -category: reference ---- - -# 上游 MySQL 实例配置前置检查 - -本文介绍了 DM 提供的前置检查功能，此功能用于在数据同步任务启动时提前检测出上游 MySQL 实例配置中可能存在的一些错误。 - -## 使用命令 - -`check-task` 命令用于对上游 MySQL 实例配置是否满足 DM 要求进行前置检查。 - -## 检查内容 - -上下游数据库用户必须具备相应读写权限。当数据同步任务启动时，DM 会自动检查下列权限和配置： - -+ 数据库版本 - - - 5.5 < MySQL 版本 < 8.0 - - MariaDB 版本 >= 10.1.2 - -+ MySQL binlog 配置 - - - binlog 是否开启（DM 要求 binlog 必须开启） - - 是否有 `binlog_format=ROW`（DM 只支持 ROW 格式的 binlog 同步） - - 是否有 `binlog_row_image=FULL`（DM 只支持 `binlog_row_image=FULL`） - -+ 上游 MySQL 实例用户的权限 - - DM 配置中的 MySQL 用户至少需要具备以下权限： - - - REPLICATION SLAVE - - REPLICATION CLIENT - - RELOAD - - SELECT - -+ 上游 MySQL 表结构的兼容性 - - TiDB 和 MySQL 的兼容性存在以下一些区别： - - - TiDB 不支持外键 - - 字符集的兼容性不同，详见 [TiDB 支持的字符集](/dev/reference/sql/character-set.md) - -+ 上游 MySQL 多实例分库分表的一致性 - - + 所有分表的表结构是否一致，检查内容包括： - - - Column 数量 - - Column 名称 - - Column 位置 - - Column 类型 - - 主键 - - 唯一索引 - - + 分表中自增主键冲突检查 - - - 在两种情况下会造成检查失败： - - - 分表存在自增主键，且自增主键 column 类型不为 bigint - - 分表存在自增主键，自增主键 column 类型为 bigint，但没有为其配置列值转换 - - - 其他情况下检查将成功 diff --git a/dev/reference/tools/data-migration/query-status.md b/dev/reference/tools/data-migration/query-status.md deleted file mode 100644 index d733ae930068..000000000000 --- a/dev/reference/tools/data-migration/query-status.md +++ /dev/null @@ -1,262 +0,0 @@ ---- -title: DM 查询状态 -category: reference ---- - -# DM 查询状态 - -本文介绍 DM（Data Migration）`query-status` 命令的查询结果、任务状态与子任务状态。 - -## 查询结果 - -{{< copyable "" >}} - -```bash -» query-status -``` - -``` -{ - "result": true, # 查询是否成功。 - "msg": "", # 查询失败原因描述。 - "tasks": [ # 迁移 task 列表 - { - "taskName": "test-1", # 任务名称 - "taskStatus": "Running", # 任务运行状态，包括 “New”，“Running”，“Paused”，“Stopped”，“Finished” 以及 “Error”。 - "workers": [ # 该任务所使用的 DM-workers 列表 - "127.0.0.1:8262" - ] - }, - { - "taskName": "test-2", - "taskStatus": "Error - Some error occurred in subtask", # 该任务的子任务存在运行错误并暂停的现象 - "workers": [ - "127.0.0.1:8262", - "127.0.0.1:8263" - ] - }, - { - "taskName": "test-3", - "taskStatus": "Error - Relay status is Error", # 该任务的某个处于 Sync 阶段的子任务对应的 Relay 处理单元出错 - "workers": [ - "127.0.0.1:8263", - "127.0.0.1:8264" - ] - } - ] -} -``` - -关于 tasks 下的 taskStatus 状态的详细定义，请参阅[任务状态](#任务状态)。 - -推荐的 `query-status` 使用方法是： - -1. 首先使用 query-status 查看各个 task 的运行状态是否正常。 -2. 如果发现其中某一 task 状态有问题，通过 `query-status <出错任务的 taskName>` 来得到更详细的错误信息。 - -## 任务状态 - -DM 的迁移任务状态取决于其分配到 DM-worker 上的[子任务状态](#子任务状态)，定义见下表： - -| 任务对应的所有子任务的状态 | 任务状态 | -| :--- | :--- | -| 任一子任务处于 “Paused” 状态且返回结果有错误信息 | Error - Some error occurred in subtask | -| 任一处于 Sync 阶段的子任务处于 “Running” 状态但其 Relay 处理单元未运行（处于 Error/Paused/Stopped 状态） | Error - Relay status is Error/Paused/Stopped | -| 任一子任务处于 “Paused” 状态且返回结果没有错误信息 | Paused | -| 所有子任务处于 “New” 状态 | New | -| 所有子任务处于 “Finished” 状态 | Finished | -| 所有子任务处于 “Stopped” 状态 | Stopped | -| 其他情况 | Running | - -## 详情查询结果 - -{{< copyable "" >}} - -```bash -» query-status test -``` - -``` -{ - "result": true, # 查询是否成功。 - "msg": "", # 查询失败原因描述。 - "workers": [ # DM-worker 列表。 - { - "result": true, - "worker": "172.17.0.2:8262", # DM-worker ID。 - "msg": "", - "subTaskStatus": [ # DM-worker 所有子任务的信息。 - { - "name": "test", # 子任务名称。 - "stage": "Running", # 子任务运行状态，包括 “New”，“Running”，“Paused”，“Stopped” 以及 “Finished”。 - "unit": "Sync", # DM 的处理单元，包括 “Check”，“Dump“，“Load” 以及 “Sync”。 - "result": null, # 子任务失败时显示错误信息。 - "unresolvedDDLLockID": "test-`test`.`t_target`", # sharding DDL lock ID，可用于异常情况下手动处理 sharding DDL lock。 - "sync": { # 当前 `Sync` 处理单元的同步信息。 - "totalEvents": "12", # 该子任务中同步的 binlog event 总数。 - "totalTps": "1", # 该子任务中每秒同步的 binlog event 数量。 - "recentTps": "1", # 该子任务中最后一秒同步的 binlog event 数量。 - "masterBinlog": "(bin.000001, 3234)", # 上游数据库当前的 binlog position。 - "masterBinlogGtid": "c0149e17-dff1-11e8-b6a8-0242ac110004:1-14", # 上游数据库当前的 GTID 信息。 - "syncerBinlog": "(bin.000001, 2525)", # 已被 `Sync` 处理单元同步的 binlog position。 - "syncerBinlogGtid": "", # 当前版本总是为空（因为 `Sync` 处理单元暂不使用 GTID 同步数据）。 - "blockingDDLs": [ # 当前被阻塞的 DDL 列表。该项仅在当前 DM-worker 所有上游表都处于 “synced“ 状态时才有数值，此时该列表包含的是待执行或待跳过的 sharding DDL 语句. - "USE `test`; ALTER TABLE `test`.`t_target` DROP COLUMN `age`;" - ], - "unresolvedGroups": [ # 没有被解决的 sharding group 信息。 - { - "target": "`test`.`t_target`", # 待同步的下游表。 - "DDLs": [ - "USE `test`; ALTER TABLE `test`.`t_target` DROP COLUMN `age`;" - ], - "firstPos": "(bin|000001.000001, 3130)", # sharding DDL 语句起始 binlog position。 - "synced": [ # `Sync` 处理单元已经读到该 sharding DDL 的上游分表。 - "`test`.`t2`" - "`test`.`t3`" - "`test`.`t1`" - ], - "unsynced": [ # `Sync` 处理单元未读到该 sharding DDL 的上游分表。如有上游分表未完成同步，`blockingDDLs` 为空。 - ] - } - ], - "synced": false # 增量同步是否已追上上游。由于后台 `Sync` 单元并不会实时刷新保存点，当前值为 “false“ 并不一定代表发生了同步延迟。 - } - } - ], - "relayStatus": { # relay 单元的同步状态. - "masterBinlog": "(bin.000001, 3234)", # 上游数据库的 binlog position。 - "masterBinlogGtid": "c0149e17-dff1-11e8-b6a8-0242ac110004:1-14", # 上游数据库的 binlog GTID 信息。 - "relaySubDir": "c0149e17-dff1-11e8-b6a8-0242ac110004.000001", # 当前使用的 relay log 子目录。 - "relayBinlog": "(bin.000001, 3234)", # 已被拉取至本地存储的 binlog position。 - "relayBinlogGtid": "c0149e17-dff1-11e8-b6a8-0242ac110004:1-14", # 已被拉取至本地存储的 binlog GTID 信息。 - "relayCatchUpMaster": true, # 本地 relay log 同步进度是否与上游一致。 - "stage": "Running", # relay 处理单元状态 - "result": null - }, - "sourceID": "172.17.0.2:3306" # 上游实例或者复制组 ID - }, - { - "result": true, - "worker": "172.17.0.3:8262", - "msg": "", - "subTaskStatus": [ - { - "name": "test", - "stage": "Running", - "unit": "Load", - "result": null, - "unresolvedDDLLockID": "", - "load": { # `Load` 处理单元的同步信息。 - "finishedBytes": "115", # 已全量导入字节数。 - "totalBytes": "452", # 总计需要导入的字节数。 - "progress": "25.44 %" # 全量导入进度。 - } - } - ], - "relayStatus": { - "masterBinlog": "(bin.000001, 28507)", - "masterBinlogGtid": "c0149e17-dff1-11e8-b6a8-0242ac110004:1-96", - "relaySubDir": "c0149e17-dff1-11e8-b6a8-0242ac110004.000001", - "relayBinlog": "(bin.000001, 28507)", - "relayBinlogGtid": "c0149e17-dff1-11e8-b6a8-0242ac110004:1-96", - "relayCatchUpMaster": true, - "stage": "Running", - "result": null - }, - "sourceID": "172.17.0.3:3306" - }, - { - "result": true, - "worker": "172.17.0.6:8262", - "msg": "", - "subTaskStatus": [ - { - "name": "test", - "stage": "Paused", - "unit": "Load", - "result": { # 错误示例 - "isCanceled": false, - "errors": [ - { - "Type": "ExecSQL", - "msg": "Error 1062: Duplicate entry '1155173304420532225' for key 'PRIMARY'\n/home/jenkins/workspace/build_dm/go/src/github.com/pingcap/tidb-enterprise-tools/loader/db.go:160: \n/home/jenkins/workspace/build_dm/go/src/github.com/pingcap/tidb-enterprise-tools/loader/db.go:105: \n/home/jenkins/workspace/build_dm/go/src/github.com/pingcap/tidb-enterprise-tools/loader/loader.go:138: file test.t1.sql" - } - ], - "detail": null - }, - "unresolvedDDLLockID": "", - "load": { - "finishedBytes": "0", - "totalBytes": "156", - "progress": "0.00 %" - } - } - ], - "relayStatus": { - "masterBinlog": "(bin.000001, 1691)", - "masterBinlogGtid": "97b5142f-e19c-11e8-808c-0242ac110005:1-9", - "relaySubDir": "97b5142f-e19c-11e8-808c-0242ac110005.000001", - "relayBinlog": "(bin.000001, 1691)", - "relayBinlogGtid": "97b5142f-e19c-11e8-808c-0242ac110005:1-9", - "relayCatchUpMaster": true, - "stage": "Running", - "result": null - }, - "sourceID": "172.17.0.6:3306" - } - ] -} -``` - -关于 `workers` 下 `subTaskStatus` 中 `stage` 状态和状态转换关系的详细信息，请参阅[子任务状态](#子任务状态)。 - -关于 `workers` 下 `subTaskStatus` 中 `unresolvedDDLLockID`的操作细节，请参阅[手动处理 Sharding DDL Lock](/dev/reference/tools/data-migration/features/manually-handling-sharding-ddl-locks.md)。 - -## 子任务状态 - -### 状态描述 - -- `New`： - - - 初始状态。 - - 如果子任务没有发生错误，状态切换为 `Running`，其他情况则切换为 `Paused`。 - -- `Running`：正常运行状态。 - -- `Paused`： - - - 暂停状态。 - - 子任务发生错误，状态切换为 `Paused`。 - - 如在子任务为 `Running` 状态下执行 `pause-task` 命令，任务状态会切换为 `Paused`。 - - 如子任务处于该状态，可以使用 `resume-task` 命令恢复任务。 - -- `Stopped`： - - - 停止状态。 - - 如在子任务为 `Running` 或 `Paused` 状态下执行 `stop-task` 命令，任务状态会切换为 `Stopped`。 - - 如子任务处于该状态，不可使用 `resume-task` 命令恢复任务。 - -- `Finished`： - - - 任务完成状态。 - - 只有 `task-mode` 为 `full` 的任务正常完成后，任务才会切换为该状态。 - -### 状态转换图 - -``` - error occurs - New --------------------------------| - | | - | resume-task | - | |----------------------------| | - | | | | - | | | | - v v error occurs | v - Finished <-------------- Running -----------------------> Paused - ^ | or pause-task | - | | | - start task | | stop task | - | | | - | v stop task | - Stopped <-------------------------| -``` diff --git a/dev/reference/tools/data-migration/relay-log.md b/dev/reference/tools/data-migration/relay-log.md deleted file mode 100644 index 89a2c5eb426b..000000000000 --- a/dev/reference/tools/data-migration/relay-log.md +++ /dev/null @@ -1,176 +0,0 @@ ---- -title: DM Relay Log -summary: 了解目录结构、初始同步规则和 DM relay log 的数据清理。 -category: reference ---- - -# DM Relay Log - -DM (Data Migration) 工具的 relay log 由一组有编号的文件和一个索引文件组成。这些有编号的文件包含了描述数据库更改的事件。索引文件包含所有使用过的 relay log 的文件名。 - -DM-worker 在启动后，会自动将上游 binlog 同步到本地配置目录（若使用 DM-Ansible 部署 DM，则同步目录默认为 ` / relay_log` ）。DM-worker 在运行过程中，会将上游 binlog 实时同步到本地文件。DM-worker 的处理单元 Syncer 会实时读取本地 relay log 的 binlog 事件，将这些事件转换为 SQL 语句，再将 SQL 语句同步到下游数据库。 - -本文档介绍 DM relay log 的目录结构、初始同步规则和数据清理方法。 - -## 目录结构 - -Relay-log 本地存储的目录结构示例如下： - -``` -/relay_log/ -|-- 7e427cc0-091c-11e9-9e45-72b7c59d52d7.000001 -| |-- mysql-bin.000001 -| |-- mysql-bin.000002 -| |-- mysql-bin.000003 -| |-- mysql-bin.000004 -| `-- relay.meta -|-- 842965eb-091c-11e9-9e45-9a3bff03fa39.000002 -| |-- mysql-bin.000001 -| `-- relay.meta -`-- server-uuid.index -``` - -- `subdir`： - - - DM-worker 把从上游数据库同步到的 binlog 存储在同一目录下，每个目录都为一个 `subdir`。 - - `subdir` 的命名格式为 `<上游数据库 UUID>.<本地 subdir 序列号>`。 - - 在上游进行 master 和 slave 实例切换后，DM-worker 会生成一个序号递增的新 `subdir` 目录。 - - - 在以上示例中，对于 `7e427cc0-091c-11e9-9e45-72b7c59d52d7.000001` 这一目录，`7e427cc0-091c-11e9-9e45-72b7c59d52d7` 是上游数据库的 UUID，`000001` 是本地 `subdir` 的序列号。 - -- `server-uuid.index`：记录当前可用的 `subdir` 目录。 - -- `relay.meta`：存储每个 `subdir` 中已同步的 binlog 信息。例如， - - ```bash - cat c0149e17-dff1-11e8-b6a8-0242ac110004.000001/relay.meta - ``` - - ``` - binlog-name = "mysql-bin.000010" # 当前同步的 binlog 名 - binlog-pos = 63083620 # 当前同步的 binlog 位置 - binlog-gtid = "c0149e17-dff1-11e8-b6a8-0242ac110004:1-3328" # 当前同步的 binlog GTID - ``` - - 也可能包含多个 GTID： - - ```bash - cat 92acbd8a-c844-11e7-94a1-1866daf8accc.000001/relay.meta - ``` - - ``` - binlog-name = "mysql-bin.018393" - binlog-pos = 277987307 - binlog-gtid = "3ccc475b-2343-11e7-be21-6c0b84d59f30:1-14,406a3f61-690d-11e7-87c5-6c92bf46f384:1-94321383,53bfca22-690d-11e7-8a62-18ded7a37b78:1-495,686e1ab6-c47e-11e7-a42c-6c92bf46f384:1-34981190,03fc0263-28c7-11e7-a653-6c0b84d59f30:1-7041423,05474d3c-28c7-11e7-8352-203db246dd3d:1-170,10b039fc-c843-11e7-8f6a-1866daf8d810:1-308290454" - ``` - -## 初始同步规则 - -DM-worker 每次启动时（或在 DM-worker 暂停后 relay log 恢复同步），同步的起始位置会出现以下几种情况： - -- 若是有效的本地 relay log（有效是指 relay log 具有有效的 `server-uuid.index`，`subdir` 和 `relay.meta` 文件），DM-worker 从 `relay.meta` 记录的位置恢复同步。 - -- 若不存在有效的本地 relay log，而且 DM 配置文件中未指定 `relay-binlog-name` 或 `relay-binlog-gtid`： - - - 在非 GTID 模式下，DM-worker 从初始的上游 binlog 开始同步，并将所有上游 binlog 文件连续同步至最新。 - - - 在 GTID 模式下，DM-worker 从初始上游 GTID 开始同步。 - - > **注意：** - > - > 若上游的 relay log 被清理掉，则会发生错误。在这种情况下，需设置 `relay-binlog-gtid` 来指定同步的起始位置。 - -- 若不存在有效的本地 relay log： - - - 在非 GTID 模式下，若指定了 `relay-binlog-name`，则 DM-worker 从指定的 binlog 文件开始同步。 - - 在 GTID 模式下，若指定了 `relay-binlog-gtid`，则 DM-worker 从指定的 GTID 开始同步。 - -## 数据清理 - -因为存在文件读写的检测机制，所以 DM-worker 不会清理正在使用的 relay log，也不会清理当前任务稍后会使用到的 relay log。 - -Relay log 的数据清理包括自动清理和手动清理这两种方法。 - -### 自动数据清理 - -自动数据清理需对 DM-worker 命令行配置中的以下三项进行配置： - -- `purge-interval` - - 后台自动清理的时间间隔，以秒为单位。 - - 默认为 "3600"，表示每 3600 秒执行一次后台清理任务。 - -- `purge-expires` - - 未更新的 relay log 在被后台清理前可保留的小时数。 - - 默认为 "0"，表示不按 relay log 的更新时间执行数据清理。 - -- `purge-remain-space` - - 剩余磁盘空间，单位为 GB。若剩余磁盘空间小于该配置，则指定的 DM-worker 机器会在后台尝试自动清理可被安全清理的 relay-log。若这一数字被设为 "0"，则表示不按剩余磁盘空间来清理数据。 - - 默认为 "15"，表示可用磁盘空间小于 15GB 时，DM-master 会尝试安全地清理 relay log。 - -或者在 DM-woker 的配置文件中加入 purge 配置： - -```toml -# relay log purge strategy -[purge] -interval = 3600 -expires = 24 -remain-space = 15 -``` - -### 手动数据清理 - -手动数据清理是指使用 dmctl 提供的 `purge-relay` 命令，通过指定 `subdir` 和 binlog 文件名，来清理掉**指定 binlog 之前**的所有 relay log。若在命令中不填 `-subdir` 选项，则默认清理**最新 relay log 子目录之前**的所有 relay log。 - -假设当前 relay log 的目录结构如下： - -{{< copyable "shell-regular" >}} - -```bash -tree . -``` - -``` -. -|-- deb76a2b-09cc-11e9-9129-5242cf3bb246.000001 -| |-- mysql-bin.000001 -| |-- mysql-bin.000002 -| |-- mysql-bin.000003 -| `-- relay.meta -|-- deb76a2b-09cc-11e9-9129-5242cf3bb246.000003 -| |-- mysql-bin.000001 -| `-- relay.meta -|-- e4e0e8ab-09cc-11e9-9220-82cc35207219.000002 -| |-- mysql-bin.000001 -| `-- relay.meta -`-- server-uuid.index -``` - -{{< copyable "shell-regular" >}} - -```bash -cat server-uuid.index -``` - -``` -deb76a2b-09cc-11e9-9129-5242cf3bb246.000001 -e4e0e8ab-09cc-11e9-9220-82cc35207219.000002 -deb76a2b-09cc-11e9-9129-5242cf3bb246.000003 -``` - -在 dmctl 中使用 `purge-relay` 命令的示例如下： - -+ 以下命令指定的 relay log 子目录为 `e4e0e8ab-09cc-11e9-9220-82cc35207219.000002`，该子目录之前的 relay log 子目录为 `deb76a2b-09cc-11e9-9129-5242cf3bb246.000001`。所以该命令实际清空了 `deb76a2b-09cc-11e9-9129-5242cf3bb246.000001` 子目录，保留 `e4e0e8ab-09cc-11e9-9220-82cc35207219.000002` 和 `deb76a2b-09cc-11e9-9129-5242cf3bb246.000003` 子目录。 - - {{< copyable "" >}} - - ```bash - » purge-relay -w 10.128.16.223:10081 --filename mysql-bin.000001 --sub-dir e4e0e8ab-09cc-11e9-9220-82cc35207219.000002 - ``` - -+ 以下命令默认 `--sub-dir` 为最新的 `deb76a2b-09cc-11e9-9129-5242cf3bb246.000003` 子目录。该目录之前的 relay log 子目录为 `deb76a2b-09cc-11e9-9129-5242cf3bb246.000001` 和 `e4e0e8ab-09cc-11e9-9220-82cc35207219.000002`，所以该命令实际清空了这两个子目录，保留了 `deb76a2b-09cc-11e9-9129-5242cf3bb246.000003`。 - - {{< copyable "" >}} - - ```bash - » purge-relay -w 10.128.16.223:10081 --filename mysql-bin.000001 - ``` diff --git a/dev/reference/tools/data-migration/skip-replace-sqls.md b/dev/reference/tools/data-migration/skip-replace-sqls.md deleted file mode 100644 index b14b8a27cc0d..000000000000 --- a/dev/reference/tools/data-migration/skip-replace-sqls.md +++ /dev/null @@ -1,663 +0,0 @@ ---- -title: 跳过 (skip) 或替代执行 (replace) 异常的 SQL 语句 -category: reference ---- - -# 跳过 (skip) 或替代执行 (replace) 异常的 SQL 语句 - -本文介绍了如何使用 DM 来处理异常的 SQL 语句。 - -目前，TiDB 并不完全兼容所有的 MySQL 语法（详见 [TiDB 已支持的 DDL 语句](/dev/reference/mysql-compatibility.md#ddl)）。当使用 DM 从 MySQL 同步数据到 TiDB 时，如果 TiDB 不支持对应的 SQL 语句，可能会造成错误并中断同步任务。在这种情况下，DM 提供以下两种方式来恢复同步： - -- 使用 dmctl 来手动跳过该 SQL 语句对应的 binlog event。 - -- 使用 dmctl 来手动指定其他 SQL 语句来替代该 SQL 语句对应的 binlog event，并向下游执行。 - -如果提前预知将要同步 TiDB 不支持的 SQL 语句，也可以使用 dmctl 来手动预设跳过/替代执行操作。当 DM 尝试将该 SQL 语句对应的 binlog event 同步到下游时，该预设的操作将自动执行，从而避免同步过程被中断。 - - - -#### 使用限制 - -- 跳过/替代执行操作只适合用于一次性跳过/替代执行**下游 TiDB 不支持执行的 SQL 语句**，其它同步错误请不要使用此方式进行处理。 - - - 其它同步错误可尝试使用 [black & white table lists](/dev/reference/tools/data-migration/features/overview.md#black--white-table-lists) 或 [binlog event filter](/dev/reference/tools/data-migration/features/overview.md#binlog-event-filter)。 - -- 如果业务不能接受下游 TiDB 跳过异常的 DDL 语句，也不接受使用其他 DDL 语句作为替代，则不适合使用此方式进行处理。 - - - 比如：`DROP PRIMARY KEY` - - 这种情况下，只能在下游重建一个（DDL 执行完后的）新表结构对应的表，并将原表的全部数据重新导入该新表。 - -- 单次跳过/替代执行操作都是针对单个 binlog event 的。 - -- `--sharding` 仅用于对 sharding group 预设一些操作，并且必须在 DDL 语句执行之前预设，不能在 DDL 语句已经执行后预设。 - - - `--sharding` 模式下只支持预设，并只能使用 `--sql-pattern` 来匹配 binlog event。 - - 有关使用 DM 处理 sharding DDL 同步的原理，请参阅[分库分表合并同步原理](/dev/reference/tools/data-migration/features/shard-merge.md#实现原理)。 - -#### 匹配 binlog event - -当同步任务由于执行 SQL 语句出错而中断时，可以使用 `query-error` 命令获取对应 binlog event 的 position 信息。在执行 `sql-skip` / `sql-replace` 时，通过指定该 position 信息，即可与对应的 binlog event 进行匹配。 - -然而，在同步中断前主动处理不被支持的 SQL 语句的情况下，由于无法提前预知 binlog event 的 position 信息，则需要使用其他方式来确保与后续将到达的 binlog event 进行匹配。 - -在 DM 中，支持如下两种 binlog event 匹配模式（两种模式只能选择其中一种）： - -1. binlog position：binlog event 的 position 信息 - - - binlog position 在命令中使用 `--binlog-pos` 参数传入，格式为 `binlog-filename:binlog-pos`，如 `mysql-bin|000001.000003:3270`。 - - DM 中 binlog filename 的格式与上游 MySQL 中 binlog filename 的格式不完全一致。 - - 在同步执行出错后，binlog position 可直接从 `query-error` 返回的 `failedBinlogPosition` 中获得。 - -2. DDL pattern：（仅限于 DDL 语句的）正则表达式匹配模式 - - - DDL pattern 在命令中使用 `--sql-pattern` 参数传入，如要匹配 ```ALTER TABLE `db2`.`tbl2` DROP COLUMN `c2` ```，则对应的正则表达式为 ```~(?i)ALTER\s+TABLE\s+`db2`.`tbl2`\s+DROP\s+COLUMN\s+`c2` ```。 - - 正则表达式必须以 `~` 为前缀，且不包含任何原始空格（正则表达式字符串中的空格均以 `\s` 或 `\s+` 表示）。 - -对于合库合表场景，如果需要由 DM 自动选择 DDL lock owner 来执行跳过/替代执行操作，则由于不同 DM-worker 上 DDL 语句对应的 binlog position 无逻辑关联且难以确定，因此只能使用 DDL pattern 匹配模式。 - -> **注意：** -> -> - 一个 binlog event 只能注册一个使用 `--binlog-pos` 指定的 operator，后注册的 operator 会覆盖之前已经注册的 operator。 -> - 不要尝试为一个 binlog event 同时使用 `--binlog-pos` 和 `--sql-pattern` 指定 operator。 -> - operator 在与 binlog event 匹配成功后（而非执行成功后）即会被删除，后续如果需要再进行（`--sql-pattern`）匹配则必须重新注册。 - -### 支持场景 - -- 场景一：同步过程中，上游执行了 TiDB 不支持的 DDL 语句并同步到了 DM，造成同步任务中断。 - - - 如果业务能接受下游 TiDB 不执行该 DDL 语句，则使用 `sql-skip` 跳过对该 DDL 语句的同步以恢复同步任务。 - - 如果业务能接受下游 TiDB 执行其他 DDL 语句来作为替代，则使用 `sql-replace` 替代该 DDL 的同步以恢复同步任务。 - -- 场景二：同步过程中，预先知道了上游将执行 TiDB 不支持的 DDL 语句，则需要提前处理以避免同步任务中断。 - - - 如果业务能接受下游 TiDB 不执行该 DDL 语句，则使用 `sql-skip` 预设一个跳过该 DDL 语句的操作，当执行到该 DDL 语句时即自动跳过。 - - 如果业务能接受下游 TiDB 执行其他 DDL 语句来作为替代，则使用 `sql-replace` 预设一个替代该 DDL 语句的操作，当执行到该 DDL 语句时即自动替代。 - -### 实现原理 - -DM 在进行增量数据同步时，简化后的流程大致为： - -1. relay 处理单元从上游拉取 binlog 存储在本地作为 relay log。 - -2. binlog 同步单元（sync）读取本地 relay log，获取其中的 binlog event。 - -3. binlog 同步单元解析该 binlog event 并构造 DDL/DML 语句，然后将这些语句向下游 TiDB 执行。 - -在 binlog 同步单元解析完 binlog event 并向下游 TiDB 执行时，可能会由于 TiDB 不支持对应的 SQL 语句而报错并造成同步中断。 - -在 DM 中，可以为 binlog event 注册一些跳过/替代执行操作（operator）。在向下游 TiDB 执行 SQL 语句前，将当前的 binlog event 信息（position、DDL 语句）与注册的 operator 进行比较。如果 position 或 DDL 语句与注册的某个 operator 匹配，则执行该 operator 对应的操作并将该 operator 移除。 - -**同步中断后使用 `sql-skip` 或 `sql-replace` 恢复同步的流程** - -1. 使用 `sql-skip` 或 `sql-replace` 为指定的 binlog position 或 DDL pattern 注册 operator。 - -2. 使用 `resume-task` 恢复之前由于同步出错导致中断的任务。 - -3. 重新解析获得之前造成同步出错的 binlog event。 - -4. 该 binlog event 与第一步注册的 operator 匹配成功。 - -5. 执行 operator 对应的操作（跳过/替代执行）后，继续执行同步任务。 - -**同步中断前使用 `sql-skip` 或 `sql-replace` 预设操作以避免同步中断的流程** - -1. 使用 `sql-skip` 或 `sql-replace` 为指定的 DDL pattern 注册 operator。 - -2. 从 relay log 中解析获得 binlog event。 - -3. （包含 TiDB 不支持 SQL 语句的）binlog event 与第一步注册的 operator 匹配成功。 - -4. 执行 operator 对应的操作（跳过/替代执行）后，继续执行同步任务，任务不发生中断。 - -**合库合表同步中断前使用 `sql-skip` 或 `sql-replace` 预设操作以避免同步中断的流程** - -1. 使用 `sql-skip` 或 `sql-replace`（在 DM-master 上）为指定的 DDL pattern 注册 operator。 - -2. 各 DM-worker 从 relay log 中解析获得 binlog event。 - -3. DM-master 协调各个 DM-worker 进行 DDL lock 同步。 - -4. DM-master 判断得知 DDL lock 同步成功后，将第一步注册的 operator 发送给 DDL lock owner。 - -5. DM-master 请求 DDL lock owner 执行 DDL 语句。 - -6. DDL lock owner 将要执行的 DDL 语句与第四步收到的 operator 匹配成功。 - -7. 执行 operator 对应的操作（跳过/替代执行）后，继续执行同步任务。 - -### 命令介绍 - -使用 dmctl 手动处理 TiDB 不支持的 SQL 语句时，主要使用的命令包括 `query-status`、`query-error`、`sql-skip` 和 `sql-replace`。 - -#### query-status - -`query-status` 命令用于查询当前 DM-worker 内子任务及 relay 单元等的状态，详见[查询状态](/dev/reference/tools/data-migration/query-status.md)。 - -#### query-error - -`query-error` 命令用于查询 DM-worker 内子任务及 relay 单元当前在运行中存在的错误。 - -##### 命令用法 - -```bash -query-error [--worker=127.0.0.1:8262] [task-name] -``` - -##### 参数解释 - -+ `worker`： - - flag 参数，string，`--worker`，可选； - - 不指定时查询所有 DM-worker 上的错误，指定时仅查询特定一组 DM-worker 上的错误。 - -+ `task-name`： - - 非 flag 参数，string，可选； - - 不指定时查询所有任务内的错误，指定时仅查询特定任务内的错误。 - -##### 结果示例 - -{{< copyable "" >}} - -```bash -» query-error test -``` - -``` -{ - "result": true, # query-error 操作本身是否成功 - "msg": "", # query-error 操作失败的说明信息 - "workers": [ # DM-worker 信息列表 - { - "result": true, # 该 DM-worker 上 query-error 操作是否成功 - "worker": "127.0.0.1:8262", # 该 DM-worker 的 IP:port（worker-id） - "msg": "", # 该 DM-worker 上 query-error 操作失败的说明信息 - "subTaskError": [ # 该 DM-worker 上运行子任务的错误信息 - { - "name": "test", # 任务名 - "stage": "Paused", # 当前任务的状态 - "unit": "Sync", # 当前正在处理任务的处理单元 - "sync": { # binlog 同步单元（sync）的错误信息 - "errors": [ # 当前处理单元的错误信息列表 - { - // 错误信息描述 - "msg": "exec sqls[[USE `db1`; ALTER TABLE `db1`.`tbl1` CHANGE COLUMN `c2` `c2` decimal(10,3);]] failed, err:Error 1105: unsupported modify column length 10 is less than origin 11", - // 发生错误的 binlog event 的 position - "failedBinlogPosition": "mysql-bin|000001.000003:34642", - // 发生错误的 SQL 语句 - "errorSQL": "[USE `db1`; ALTER TABLE `db1`.`tbl1` CHANGE COLUMN `c2` `c2` decimal(10,3);]" - } - ] - } - } - ], - "RelayError": { # 该 DM-worker 上 relay 处理单元的错误信息 - "msg": "" # 错误信息描述 - } - } - ] -} -``` - -#### sql-skip - -`sql-skip` 命令用于预设一个跳过操作，当 binlog event 的 position 或 SQL 语句与指定的 `binlog-pos` 或 `sql-pattern` 匹配时，执行该跳过操作。 - -##### 命令用法 - -```bash -sql-skip <--worker=127.0.0.1:8262> [--binlog-pos=mysql-bin|000001.000003:3270] [--sql-pattern=~(?i)ALTER\s+TABLE\s+`db1`.`tbl1`\s+ADD\s+COLUMN\s+col1\s+INT] [--sharding] -``` - -##### 参数解释 - -+ `worker`： - - flag 参数，string，`--worker`； - - 未指定 `--sharding` 时必选，指定 `--sharding` 时禁止使用； - - `worker` 指定预设操作将生效的 DM-worker。 - -+ `binlog-pos`： - - flag 参数，string，`--binlog-pos`； - - `binlog-pos` 与 `--sql-pattern` 必须指定其中一个，且只能指定其中一个。 - - 在指定时表示操作将在 `binlog-pos` 与 binlog event 的 position 匹配时生效，格式为 `binlog-filename:binlog-pos`，如 `mysql-bin|000001.000003:3270`。 - - 在同步执行出错后，binlog position 可直接从 `query-error` 返回的 `failedBinlogPosition` 中获得。 - -+ `sql-pattern`： - - flag 参数，string，`--sql-pattern`； - - `--sql-pattern` 与 `binlog-pos` 必须指定其中一个，且只能指定其中一个。 - - 在指定时表示操作将在 `sql-pattern` 与 binlog event 对应的（经过可选的 router-rule 转换后的）DDL 语句匹配时生效。格式为以 `~` 为前缀的正则表达式，如 ```~(?i)ALTER\s+TABLE\s+`db1`.`tbl1`\s+ADD\s+COLUMN\s+col1\s+INT```。 - - 暂时不支持正则表达式中包含原始空格，需要使用 `\s` 或 `\s+` 替代空格。 - - 正则表达式必须以 `~` 为前缀，详见[正则表达式语法](https://golang.org/pkg/regexp/syntax/#hdr-syntax)。 - - 正则表达式中的库名和表名必须是经过可选的 router-rule 转换后的名字，即对应下游的目标库名和表名。如上游为 ``` `shard_db_1`.`shard_tbl_1` ```，下游为 ``` `shard_db`.`shard_tbl` ```，则应该尝试匹配 ``` `shard_db`.`shard_tbl` ```。 - - 正则表达式中的库名、表名及列名需要使用 ``` ` ``` 标记，如 ``` `db1`.`tbl1` ```。 - -+ `sharding`： - - flag 参数，boolean，`--sharding`； - - 未指定 `--worker` 时必选，指定 `--worker` 时禁止使用； - - 在指定时表示预设的操作将在 sharding DDL 同步过程中的 DDL lock owner 内生效。 - -+ `task-name`： - - 非 flag 参数，string，必选； - - 指定预设的操作将生效的任务。 - -#### sql-replace - -`sql-replace` 命令用于预设一个替代执行操作，当 binlog event 的 position 或 SQL 语句与指定的 `binlog-pos` 或 `sql-pattern` 匹配时，执行该替代执行操作。 - -##### 命令用法 - -```bash -sql-replace <--worker=127.0.0.1:8262> [--binlog-pos=mysql-bin|000001.000003:3270] [--sql-pattern=~(?i)ALTER\s+TABLE\s+`db1`.`tbl1`\s+ADD\s+COLUMN\s+col1\s+INT] [--sharding] -``` - -##### 参数解释 - -+ `worker`： - - 与 `sql-skip` 命令的 `--worker` 参数解释一致。 - -+ `binlog-pos`： - - 与 `sql-skip` 命令的 `--binlog-pos` 参数解释一致。 - -+ `sql-pattern`： - - 与 `sql-skip` 命令的 `--sql-pattern` 参数解释一致。 - -+ `sharding`： - - 与 `sql-skip` 命令的 `--sharding` 参数解释一致。 - -+ `task-name`： - - 与 `sql-skip` 命令的 `task-name` 参数解释一致。 - -+ `SQLs`： - - 非 flag 参数，string，必选； - - `SQLs` 指定将用于替代原 binlog event 的新的 SQL 语句。多条 SQL 语句间以 `;` 分隔，如 ```ALTER TABLE shard_db.shard_table drop index idx_c2;ALTER TABLE shard_db.shard_table DROP COLUMN c2;```。 - -### 使用示例 - -#### 同步中断后被动执行跳过操作 - -##### 应用场景 - -假设现在需要将上游的 `db1.tbl1` 表同步到下游 TiDB（非合库合表同步场景），初始时表结构为： - -{{< copyable "sql" >}} - -```sql -SHOW CREATE TABLE db1.tbl1; -``` - -``` -+-------+--------------------------------------------------+ -| Table | Create Table | -+-------+--------------------------------------------------+ -| tbl1 | CREATE TABLE `tbl1` ( - `c1` int(11) NOT NULL, - `c2` decimal(11,3) DEFAULT NULL, - PRIMARY KEY (`c1`) -) ENGINE=InnoDB DEFAULT CHARSET=latin1 | -+-------+--------------------------------------------------+ -``` - -此时，上游执行以下 DDL 操作修改表结构（将列的 DECIMAL(11, 3) 修改为 DECIMAL(10, 3)）： - -{{< copyable "sql" >}} - -```sql -ALTER TABLE db1.tbl1 CHANGE c2 c2 DECIMAL (10, 3); -``` - -则会由于 TiDB 不支持该 DDL 语句而导致 DM 同步任务中断且报如下错误： - -``` -exec sqls[[USE `db1`; ALTER TABLE `db1`.`tbl1` CHANGE COLUMN `c2` `c2` decimal(10,3);]] failed, -err:Error 1105: unsupported modify column length 10 is less than origin 11 -``` - -此时使用 `query-status` 查询任务状态，可看到 `stage` 转为了 `Paused`，且 `errors` 中有相关的错误描述信息。 - -使用 `query-error` 可以获取该错误的详细信息。比如，执行 `query-error test` 可获得出错的 binlog event 的 position（`failedBinlogPosition`）为 `mysql-bin|000001.000003:34642`。 - -##### 被动跳过 SQL 语句 - -假设业务上可以接受下游 TiDB 不执行此 DDL 语句（即继续保持原有的表结构），则可以通过使用 `sql-skip` 命令跳过该 DDL 语句以恢复同步任务。操作步骤如下： - -1. 使用 `query-error` 获取同步出错的 binlog event 的 position 信息。 - - position 信息可直接由 `query-error` 返回的 `failedBinlogPosition` 获得。 - - 本示例中的 position 为 `mysql-bin|000001.000003:34642`。 - -2. 使用 `sql-skip` 预设一个 binlog event 跳过操作，该操作将在使用 `resume-task` 后同步该 binlog event 到下游时生效。 - - {{< copyable "" >}} - - ```bash - » sql-skip --worker=127.0.0.1:8262 --binlog-pos=mysql-bin|000001.000003:34642 test - ``` - - ``` - { - "result": true, - "msg": "", - "workers": [ - { - "result": true, - "worker": "", - "msg": "" - } - ] - } - ``` - - 对应 DM-worker 节点中也可以看到类似如下日志： - - ``` - 2018/12/28 11:17:51 operator.go:121: [info] [sql-operator] set a new operator - uuid: 6bfcf30f-2841-4d70-9a34-28d7082bdbd7, pos: (mysql-bin|000001.000003, 34642), op: SKIP, args: - on replication unit - ``` - -3. 使用 `resume-task` 恢复之前出错中断的同步任务。 - - {{< copyable "" >}} - - ```bash - » resume-task --worker=127.0.0.1:8262 test - ``` - - ``` - { - "op": "Resume", - "result": true, - "msg": "", - "workers": [ - { - "op": "Resume", - "result": true, - "worker": "127.0.0.1:8262", - "msg": "" - } - ] - } - ``` - - 对应 DM-worker 节点中也可以看到类似如下日志： - - ``` - 2018/12/28 11:27:46 operator.go:158: [info] [sql-operator] binlog-pos (mysql-bin|000001.000003, 34642) matched, - applying operator uuid: 6bfcf30f-2841-4d70-9a34-28d7082bdbd7, pos: (mysql-bin|000001.000003, 34642), op: SKIP, args: - ``` - -4. 使用 `query-status` 确认该任务的 `stage` 已经转为 `Running`。 - -5. 使用 `query-error` 确认原错误信息已不再存在。 - -#### 同步中断前主动执行替代执行操作 - -##### 应用场景 - -假设现在需要将上游的 `db2.tbl2` 表同步到下游 TiDB（非合库合表同步场景），初始时表结构为： - -{{< copyable "sql" >}} - -```sql -SHOW CREATE TABLE db2.tbl2; -``` - -``` -+-------+--------------------------------------------------+ -| Table | Create Table | -+-------+--------------------------------------------------+ -| tbl2 | CREATE TABLE `tbl2` ( - `c1` int(11) NOT NULL, - `c2` int(11) DEFAULT NULL, - PRIMARY KEY (`c1`), - KEY `idx_c2` (`c2`) -) ENGINE=InnoDB DEFAULT CHARSET=latin1 | -+-------+--------------------------------------------------+ -``` - -此时，上游执行以下 DDL 操作修改表结构（即 DROP 列 c2）： - -{{< copyable "sql" >}} - -```sql -ALTER TABLE db2.tbl2 DROP COLUMN c2; -``` - -当同步该 DDL 语句对应的 binlog event 到下游时，会由于 TiDB 不支持该 DDL 语句而导致 DM 同步任务中断且报如下错误： - -``` -exec sqls[[USE `db2`; ALTER TABLE `db2`.`tbl2` DROP COLUMN `c2`;]] failed, -err:Error 1105: can't drop column c2 with index covered now -``` - -**但如果在上游实际执行该 DDL 语句前，你已提前知道该 DDL 语句不被 TiDB 所支持**。则可以使用 `sql-skip` 或 `sql-replace` 为该 DDL 语句预设一个跳过（skip）或替代执行（replace）操作。 - -对于本示例中的 DDL 语句，由于 TiDB 暂时不支持 DROP 存在索引的列，因此可以使用两条新的 SQL 语句来进行替代执行操作，即可以先 DROP 索引、然后再 DROP 列 c2。 - -##### 主动替代执行该 SQL 语句 - -1. 为将要在上游执行的 DDL 语句（经过可选的 router-rule 转换后的 DDL 语句）设计一个能匹配上的正则表达式。 - - 上游将执行的 DDL 语句为 `ALTER TABLE db2.tbl2 DROP COLUMN c2;`。 - - 由于该 DDL 语句不存在 router-rule 转换，可设计如下正则表达式： - - ``` - ~(?i)ALTER\s+TABLE\s+`db2`.`tbl2`\s+DROP\s+COLUMN\s+`c2` - ``` - -2. 为该 DDL 语句设计将用于替代执行的新的 DDL 语句： - - {{< copyable "sql" >}} - - ```sql - ALTER TABLE `db2`.`tbl2` DROP INDEX idx_c2;ALTER TABLE `db2`.`tbl2` DROP COLUMN `c2`; - ``` - -3. 使用 `sql-replace` 预设一个 binlog event 替代执行操作，该操作将在同步该 binlog event 到下游时生效。 - - {{< copyable "" >}} - - ```bash - » sql-replace --worker=127.0.0.1:8262 --sql-pattern=~(?i)ALTER\s+TABLE\s+`db2`.`tbl2`\s+DROP\s+COLUMN\s+`c2` test ALTER TABLE `db2`.`tbl2` DROP INDEX idx_c2;ALTER TABLE `db2`.`tbl2` DROP COLUMN `c2` - ``` - - ``` - { - "result": true, - "msg": "", - "workers": [ - { - "result": true, - "worker": "", - "msg": "" - } - ] - } - ``` - - 对应 DM-worker 节点中也可以看到类似如下日志： - - ``` - 2018/12/28 15:33:13 operator.go:121: [info] [sql-operator] set a new operator - uuid: c699a18a-8e75-47eb-8e7e-0e5abde2053c, pattern: ~(?i)ALTER\s+TABLE\s+`db2`.`tbl2`\s+DROP\s+COLUMN\s+`c2`, - op: REPLACE, args: ALTER TABLE `db2`.`tbl2` DROP INDEX idx_c2; ALTER TABLE `db2`.`tbl2` DROP COLUMN `c2` - on replication unit - ``` - -4. 在上游 MySQL 执行该 DDL 语句。 - -5. 观察下游表结构是否变更成功，对应 DM-worker 节点中也可以看到类似如下日志： - - ``` - 2018/12/28 15:33:45 operator.go:158: [info] [sql-operator] - sql-pattern ~(?i)ALTER\s+TABLE\s+`db2`.`tbl2`\s+DROP\s+COLUMN\s+`c2` matched SQL - USE `db2`; ALTER TABLE `db2`.`tbl2` DROP COLUMN `c2`;, - applying operator uuid: c699a18a-8e75-47eb-8e7e-0e5abde2053c, - pattern: ~(?i)ALTER\s+TABLE\s+`db2`.`tbl2`\s+DROP\s+COLUMN\s+`c2`, - op: REPLACE, args: ALTER TABLE `db2`.`tbl2` DROP INDEX idx_c2; ALTER TABLE `db2`.`tbl2` DROP COLUMN `c2` - ``` - -6. 使用 `query-status` 确认该任务的 `stage` 持续为 `Running`。 - -7. 使用 `query-error` 确认不存在 DDL 执行错误。 - -#### 合库合表场景下同步中断后被动执行跳过操作 - -##### 应用场景 - -假设现在通过多个 DM-worker 将上游多个 MySQL 实例内的多个表进行合库合表同步到下游 TiDB 的同一个表，并且上游各分表执行了 TiDB 不支持的 DDL 语句。 - -DM-master 通过 DDL lock 协调 DDL 同步、并请求 DDL lock owner 向下游 TiDB 执行该 DDL 语句后，由于 TiDB 不支持该 DDL 语句，同步任务会报错并中断。 - -##### 被动跳过 SQL 语句 - -合库合表场景下，被动跳过 TiDB 不支持的 DDL 语句的处理方式与非合库合表场景下的[同步中断后被动执行跳过操作](#同步中断后被动执行跳过操作)基本一致。 - -但在合库合表场景下，只需要 DDL lock owner 向下游同步该 DDL 语句，因此在两种场景下的处理过程主要存在以下区别： - -1. 合库合表场景下，仅需要对 DDL lock owner 执行 `sql-skip`（`--worker={DDL-lock-owner}`）。 - -2. 合库合表场景下，仅需要对 DDL lock owner 执行 `resume-task`（`--worker={DDL-lock-owner}`）。 - -#### 合库合表场景下同步中断前主动执行替代执行操作 - -##### 应用场景 - -假设现在存在如下四个上游表需要合并同步到下游的同一个表 ``` `shard_db`.`shard_table` ```： - -- MySQL 实例 1 内有 `shard_db_1` 逻辑库，包括 `shard_table_1` 和 `shard_table_2` 两个表。 -- MySQL 实例 2 内有 `shard_db_2` 逻辑库，包括 `shard_table_1` 和 `shard_table_2` 两个表。 - -初始时表结构为： - -{{< copyable "sql" >}} - -```sql -SHOW CREATE TABLE shard_db_1.shard_table_1; -``` - -``` -+---------------+------------------------------------------+ -| Table | Create Table | -+---------------+------------------------------------------+ -| shard_table_1 | CREATE TABLE `shard_table_1` ( - `c1` int(11) NOT NULL, - `c2` int(11) DEFAULT NULL, - PRIMARY KEY (`c1`), - KEY `idx_c2` (`c2`) -) ENGINE=InnoDB DEFAULT CHARSET=latin1 | -+---------------+------------------------------------------+ -``` - -此时，在上游所有分表上都执行以下 DDL 操作修改表结构（即 DROP 列 c2）： - -{{< copyable "sql" >}} - -```sql -ALTER TABLE shard_db_*.shard_table_* DROP COLUMN c2; -``` - -则当 DM 通过 sharding DDL lock 协调两个 DM-worker 同步该 DDL 语句、并请求 DDL lock owner 向下游执行该 DDL 语句时，会由于 TiDB 不支持该 DDL 语句而导致同步任务中断且报如下错误： - -``` -exec sqls[[USE `shard_db`; ALTER TABLE `shard_db`.`shard_table` DROP COLUMN `c2`;]] failed, -err:Error 1105: can't drop column c2 with index covered now -``` - -**但如果在上游实际执行该 DDL 语句前，你已提前知道该 DDL 语句不被 TiDB 所支持**。则可以使用 `sql-skip` 或 `sql-replace` 命令为该 DDL 语句预设一个跳过/替代执行操作。 - -对于本示例中的 DDL 语句，由于 TiDB 暂时不支持 DROP 存在索引的列，因此可以使用两条新的 SQL 语句来进行替代执行操作，即可以先 DROP 索引、然后再 DROP c2 列。 - -##### 主动替代执行该 SQL 语句 - -1. 为将要在上游执行的（经过可选的 router-rule 转换后的）DDL 语句设计一个能匹配上的正则表达式。 - - 上游将执行的 DDL 语句为 `ALTER TABLE shard_db_*.shard_table_* DROP COLUMN c2`。 - - 由于存在 router-rule 会将表名转换为 ``` `shard_db`.`shard_table` ```，可设计如下正则表达式： - - ``` - ~(?i)ALTER\s+TABLE\s+`shard_db`.`shard_table`\s+DROP\s+COLUMN\s+`c2` - ``` - -2. 为该 DDL 语句设计将用于替代执行的新的 DDL 语句： - - {{< copyable "sql" >}} - - ```sql - ALTER TABLE `shard_db`.`shard_table` DROP INDEX idx_c2;ALTER TABLE `shard_db`.`shard_table` DROP COLUMN `c2`; - ``` - -3. 由于这是合库合表场景，因此使用 `--sharding` 参数来由 DM 自动确定替代执行操作只发生在 DDL lock owner 上。 - -4. 使用 `sql-replace` 预设一个 binlog event 替代执行操作，该操作将在同步该 binlog event 到下游时生效。 - - {{< copyable "" >}} - - ```bash - » sql-replace --sharding --sql-pattern=~(?i)ALTER\s+TABLE\s+`shard_db`.`shard_table`\s+DROP\s+COLUMN\s+`c2` test ALTER TABLE `shard_db`.`shard_table` DROP INDEX idx_c2;ALTER TABLE `shard_db`.`shard_table` DROP COLUMN `c2` - ``` - - ``` - { - "result": true, - "msg": "request with --sharding saved and will be sent to DDL lock's owner when resolving DDL lock", - "workers": [ - ] - } - ``` - - **DM-master** 节点中也可以看到类似如下日志： - - ``` - 2018/12/28 16:53:33 operator.go:105: [info] [sql-operator] set a new operator - uuid: eba35acd-6c5e-4bc3-b0b0-ae8bd1232351, request: name:"test" - op:REPLACE args:"ALTER TABLE `shard_db`.`shard_table` DROP INDEX idx_c2;" - args:"ALTER TABLE `shard_db`.`shard_table` DROP COLUMN `c2`" - sqlPattern:"~(?i)ALTER\\s+TABLE\\s+`shard_db`.`shard_table`\\s+DROP\\s+COLUMN\\s+`c2`" - sharding:true - ``` - -5. 在上游 MySQL 实例的分表上执行 DDL 语句。 - -6. 观察下游表结构是否变更成功，对应的 DDL lock **owner** 节点中也可以看到类似如下日志： - - ``` - 2018/12/28 16:54:35 operator.go:121: [info] [sql-operator] set a new operator - uuid: c959f2fb-f1c2-40c7-a1fa-e73cd51736dd, - pattern: ~(?i)ALTER\s+TABLE\s+`shard_db`.`shard_table`\s+DROP\s+COLUMN\s+`c2`, - op: REPLACE, args: ALTER TABLE `shard_db`.`shard_table` DROP INDEX idx_c2; ALTER TABLE `shard_db`.`shard_table` DROP COLUMN `c2` - on replication unit - ``` - - ``` - 2018/12/28 16:54:35 operator.go:158: [info] [sql-operator] - sql-pattern ~(?i)ALTER\s+TABLE\s+`shard_db`.`shard_table`\s+DROP\s+COLUMN\s+`c2` matched SQL - USE `shard_db`; ALTER TABLE `shard_db`.`shard_table` DROP COLUMN `c2`;, - applying operator uuid: c959f2fb-f1c2-40c7-a1fa-e73cd51736dd, - pattern: ~(?i)ALTER\s+TABLE\s+`shard_db`.`shard_table`\s+DROP\s+COLUMN\s+`c2`, - op: REPLACE, args: ALTER TABLE `shard_db`.`shard_table` DROP INDEX idx_c2; ALTER TABLE `shard_db`.`shard_table` DROP COLUMN `c2` - ``` - - 另外，**DM-master** 节点中也可以看到类似如下日志： - - ``` - 2018/12/28 16:54:35 operator.go:122: [info] [sql-operator] get an operator - uuid: eba35acd-6c5e-4bc3-b0b0-ae8bd1232351, request: name:"test" op:REPLACE - args:"ALTER TABLE `shard_db`.`shard_table` DROP INDEX idx_c2;" - args:"ALTER TABLE `shard_db`.`shard_table` DROP COLUMN `c2`" - sqlPattern:"~(?i)ALTER\\s+TABLE\\s+`shard_db`.`shard_table`\\s+DROP\\s+COLUMN\\s+`c2`" - sharding:true - with key ~(?i)ALTER\s+TABLE\s+`shard_db`.`shard_table`\s+DROP\s+COLUMN\s+`c2` matched SQL - USE `shard_db`; ALTER TABLE `shard_db`.`shard_table` DROP COLUMN `c2`; - ``` - - ``` - 2018/12/28 16:54:36 operator.go:145: [info] [sql-operator] remove an operator - uuid: eba35acd-6c5e-4bc3-b0b0-ae8bd1232351, request: name:"test" op:REPLACE - args:"ALTER TABLE `shard_db`.`shard_table` DROP INDEX idx_c2;" - args:"ALTER TABLE `shard_db`.`shard_table` DROP COLUMN `c2`" - sqlPattern:"~(?i)ALTER\\s+TABLE\\s+`shard_db`.`shard_table`\\s+DROP\\s+COLUMN\\s+`c2`" - sharding:true - ``` - -7. 使用 `query-status` 确认任务的 `stage` 持续为 `Running`，且不存在正阻塞同步的 DDL 语句（`blockingDDLs`）与待解决的 sharding group（`unresolvedGroups`）。 - -8. 使用 `query-error` 确认不存在 DDL 执行错误。 - -9. 使用 `show-ddl-locks` 确认不存在待解决的 DDL lock。 diff --git a/dev/reference/tools/data-migration/table-selector.md b/dev/reference/tools/data-migration/table-selector.md deleted file mode 100644 index 45c5d6031b0d..000000000000 --- a/dev/reference/tools/data-migration/table-selector.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Table Selector -summary: 介绍 DM 的 Table Selector -category: reference ---- - -# Table Selector - -Table Selector 提供了一种基于[通配符](https://zh.wikipedia.org/wiki/%E9%80%9A%E9%85%8D%E7%AC%A6) 来匹配指定 `schema/table` 的功能。 - -## 通配符 - -table selector 在 `schema-pattern`/`table-pattern` 中可以使用以下两个通配符： - -+ 星号(`*`) - - - 匹配零个或者多个字符。例如， `doc*` 匹配 `doc` 和 `document`，但是不匹配 `dodo`。 - - `*` 只能放在 pattern 的最后一位，例如，支持 `doc*`，但是不支持 `do*c`。 - -+ 问号(`?`) - - - 匹配任意一个空字符除外的字符。 - -## 匹配规则 - -- `schema-pattern` 限制不能为空； -- `table-pattern` 可以设置为空。设置为空时，将只根据 `schema-pattern` 对 `schema` 进行匹配，然后返回匹配结果； -- `table-pattern` 不为空时，分别根据 `schema-pattern` 和 `table-pattern` 进行匹配，两个都匹配则结果为匹配。 - -## 使用示例 - -- 匹配所有库名以 `schema_` 开头的 schema 和 table - - ```yaml - schema-pattern： "schema_*" - table-pattern： "" - ``` - -- 匹配所有库名以 `schema_` 为前缀，并且表名以 `table_` 前缀的表 - - ```yaml - schema-pattern = "schema_*" - table-pattern = "table_*" - ``` diff --git a/dev/reference/tools/data-migration/troubleshoot/dm.md b/dev/reference/tools/data-migration/troubleshoot/dm.md deleted file mode 100644 index ed9efb77b294..000000000000 --- a/dev/reference/tools/data-migration/troubleshoot/dm.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Data Migration 故障诊断 -category: reference -aliases: ['/docs-cn/dev/how-to/troubleshoot/data-migration/'] ---- - -# Data Migration 故障诊断 - -本文总结了在 DM 工具使用过程中遇到问题的诊断流程，并指引用户通过错误信息查找相应的解决方案。 - -如果你在运行 DM 工具时出现了错误，请尝试以下解决方案： - -1. 执行 `query-status` 命令查看任务运行状态以及相关错误输出。 - -2. 查看与该错误相关的日志文件。日志文件位于 DM-master、DM-worker 部署节点上，通过 [Data Migration 错误含义](/dev/reference/tools/data-migration/troubleshoot/error-system.md) 获取错误的关键信息，然后查看 [Data Migration 常见错误及修复](/dev/reference/tools/data-migration/troubleshoot/error-handling.md)以寻找相应的解决方案。 - -3. 如果该错误还没有相应的解决方案，并且你无法通过查询日志或监控指标自行解决此问题，你可以联系相关销售人员进行支持。 - -4. 一般情况下，错误处理完成后，只需使用 dmctl 重启任务即可。 - - {{< copyable "shell-regular" >}} - - ```bash - resume-task ${task name} - ``` - -但在某些情况下，你还需要重置数据同步任务。有关何时需要重置以及如何重置，详见[重置数据同步任务](/dev/reference/tools/data-migration/faq.md#重置数据同步任务)。 diff --git a/dev/reference/tools/data-migration/troubleshoot/error-system.md b/dev/reference/tools/data-migration/troubleshoot/error-system.md deleted file mode 100644 index c053dcb905b3..000000000000 --- a/dev/reference/tools/data-migration/troubleshoot/error-system.md +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: Data Migration 错误说明 -category: reference -aliases: ['/docs-cn/dev/reference/tools/data-migration/error-system/'] ---- - -# Data Migration 错误说明 - -本文介绍了 Data Migration (DM) 的错误系统，以及各种错误信息的详细含义。 - -## DM 错误系统 - -DM 1.0.0-GA 版本中引入了新的错误系统。该系统： - -+ 增加了错误码机制。 -+ 增加了 `class`、`scope`、`level` 等错误信息。 -+ 优化了错误描述内容、错误调用链信息和调用堆栈信息。 - -错误系统的详细设计和实现，可参阅 [RFC 文档: Proposal: Improve Error System](https://github.com/pingcap/dm/blob/master/docs/RFCS/20190722_error_handling.md)。 - -## 错误信息示例 - -以下是 DM 实际输出的一条错误信息。本文根据这条信息，对各个字段作详细说明。 - -``` -[code=38008:class=dm-master:scope=internal:level=high] grpc request error: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp 172.17.0.2:8262: connect: connection refused" -github.com/pingcap/dm/pkg/terror.(*Error).Delegate - /root/code/gopath/src/github.com/pingcap/dm/pkg/terror/terror.go:267 -github.com/pingcap/dm/dm/master/workerrpc.callRPC - /root/code/gopath/src/github.com/pingcap/dm/dm/master/workerrpc/rawgrpc.go:124 -github.com/pingcap/dm/dm/master/workerrpc.(*GRPCClient).SendRequest - /root/code/gopath/src/github.com/pingcap/dm/dm/master/workerrpc/rawgrpc.go:64 -github.com/pingcap/dm/dm/master.(*Server).getStatusFromWorkers.func2 - /root/code/gopath/src/github.com/pingcap/dm/dm/master/server.go:1125 -github.com/pingcap/dm/dm/master.(*AgentPool).Emit - /root/code/gopath/src/github.com/pingcap/dm/dm/master/agent_pool.go:117 -runtime.goexit - /root/.gvm/gos/go1.12/src/runtime/asm_amd64.s:1337 -``` - -DM 中的错误信息均按以下固定格式输出： - -``` -[错误基本信息] + 错误 message 描述 + 错误堆栈信息（可选） -``` - -### 错误基本信息 - -- `code`：错误码，错误唯一标识。 - - 同一种错误都使用相同的错误码。错误码不随 DM 版本改变。 - - 在 DM 迭代过程中，部分错误可能会被移除，但错误码不会。新增的错误会使用新的错误码，不会复用已有的错误码。 - -- `class`：错误分类。 - - 用于标记出现错误的系统子模块。 - - 下表展示所有的错误类别、错误对应的系统子模块、错误样例： - - | 错误类别 | 错误对应的系统子模块 | 错误样例 | - | :-------------- | :------------------------------ | :------------------------------------------------------------ | - | `database` | 执行数据库操作出现错误 | `[code=10003:class=database:scope=downstream:level=medium] database driver: invalid connection` | - | `functional` | 系统底层的基础函数错误 | `[code=11005:class=functional:scope=internal:level=high] not allowed operation: alter multiple tables in one statement` | - | `config` | 配置错误 | `[code=20005:class=config:scope=internal:level=medium] empty source-id not valid` | - | `binlog-op` | binlog 操作出现错误 | `[code=22001:class=binlog-op:scope=internal:level=high] empty UUIDs not valid` | - | `checkpoint` | checkpoint 相关操作出现错误 | `[code=24002:class=checkpoint:scope=internal:level=high] save point bin.1234 is older than current pos bin.1371` | - | `task-check` | 进行任务检查时出现错误 | `[code=26003:class=task-check:scope=internal:level=medium] new table router error` | - | `relay-event-lib`| 执行 relay 模块基础功能时出现错误 | `[code=28001:class=relay-event-lib:scope=internal:level=high] parse server-uuid.index` | - | `relay-unit` | relay 处理单元内出现错误 | `[code=30015:class=relay-unit:scope=upstream:level=high] TCPReader get event: ERROR 1236 (HY000): Could not open log file` | - | `dump-unit` | dump 处理单元内出现错误 | `[code=32001:class=dump-unit:scope=internal:level=high] mydumper runs with error: CRITICAL **: 15:12:17.559: Error connecting to database: Access denied for user 'root'@'172.17.0.1' (using password: NO)` | - | `load-unit` | load 处理单元内出现错误 | `[code=34002:class=load-unit:scope=internal:level=high] corresponding ending of sql: ')' not found` | - | `sync-unit` | sync 处理单元内出现错误 | `[code=36027:class=sync-unit:scope=internal:level=high] Column count doesn't match value count: 9 (columns) vs 10 (values)` | - | `dm-master` | DM-master 服务内部出现错误 | `[code=38008:class=dm-master:scope=internal:level=high] grpc request error: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp 172.17.0.2:8262: connect: connection refused"` | - | `dm-worker` | DM-worker 服务内部出现错误 | `[code=40066:class=dm-worker:scope=internal:level=high] ExecuteDDL timeout, try use query-status to query whether the DDL is still blocking` | - | `dm-tracer` | DM-tracer 服务内部出现错误 | `[code=42004:class=dm-tracer:scope=internal:level=medium] trace event test.1 not found` | - -- `scope`：错误作用域。 - - 用于标识错误发生时 DM 作用对象的范围和来源，包括未设置 (not-set)、上游数据库 (upstream)、下游数据库 (downstream)、内部 (internal) 四种类型。 - - 如果错误发生的逻辑直接涉及到上下游数据库请求，作用域会设置为 upstream 或 downstream，其他出错场景目前都设置为 internal。 - -- `level`：错误级别。 - - 错误的严重级别，包括低级别 (low)、中级别 (medium)、高级别 (high) 三种。 - - 低级别通常是用户操作、输入错误，不影响正常同步任务；中级别通常是用户配置等错误，会影响部分新启动服务，不影响已有系统同步状态；高级别通常是用户需要关注的一些错误，可能存在同步任务中断等风险，需要用户进行处理。 - -在上述的错误样例中： - -- `code=38008` 表示 gRPC 通信出错的错误码。 -- `class=dm-master`，表示 DM-master 对外发送 gRPC 请求时出错（请求发送至 DM-worker）。 -- `scope=interal` 表示 DM 内部出现错误。 -- `level=high`，表示这是一个高级别错误，需要用户注意。可根据错误 message 和错误堆栈判断出更多错误信息。 - -### 错误 message 描述 - -错误 message 使用描述性语言来表示错误的详细信息。对于错误调用链上每一层额外增加的错误 message，采用 [errors.Wrap](https://godoc.org/github.com/pkg/errors#hdr-Adding_context_to_an_error) 的模式来叠加和保存错误 message。wrap 最外层的 message 是 DM 内部对该错误的描述，wrap 最内层的 message 是该错误最底层出错位置的错误描述。 - -以上述样例错误的 message 为例： - -- wrap 最外层 message，`grpc request error` 是 DM 对该错误的描述。 -- wrap 最内层 message，`connection error: desc = "transport: Error while dialing dial tcp 172.17.0.2:8262: connect: connection refused"`，是 gRPC 底层建立连接失败时返回的错误。 - -通过对基本错误信息和错误 message 进行分析，可以诊断出错误是在 DM-master 向 DM-worker 发送 gRPC 请求建立连接失败时出现的。该错误通常是由 DM-worker 未正常运行引起。 - -### 错误堆栈信息 - -DM 根据错误的严重程度和必要性来选择是否输出错误堆栈。错误堆栈记录了错误发生时完整的堆栈调用信息。如果用户通过错误基本信息和错误 message 描述不能完全诊断出错误发生的原因，可以通过错误堆栈进一步跟进出错时代码的运行路径。 - -## 常见错误码描述及处理 - -可在 DM 代码仓库[已发布的错误码](https://github.com/pingcap/dm/blob/master/_utils/terror_gen/errors_release.txt)中查询完整的错误码列表。 diff --git a/dev/reference/tools/data-migration/usage-scenarios/shard-merge.md b/dev/reference/tools/data-migration/usage-scenarios/shard-merge.md deleted file mode 100644 index 88e0dde84ac4..000000000000 --- a/dev/reference/tools/data-migration/usage-scenarios/shard-merge.md +++ /dev/null @@ -1,242 +0,0 @@ ---- -title: DM 分库分表合并场景 -category: reference ---- - -# DM 分库分表合并场景 - -本文介绍如何在分库分表合并场景中使用 Data Migration (DM)。使用场景中，三个上游 MySQL 实例的分库和分表数据需要同步至下游 TiDB 集群。 - -## 上游实例 - -假设上游库结构如下： - -- 实例 1 - - | Schema | Tables | - |:------|:------| - | user | information, log_north, log_bak | - | store_01 | sale_01, sale_02 | - | store_02 | sale_01, sale_02 | - -- 实例 2 - - | Schema | Tables | - |:------|:------| - | user | information, log_east, log_bak | - | store_01 | sale_01, sale_02 | - | store_02 | sale_01, sale_02 | - -- 实例 3 - - | Schema | Tables | - |:------|:------| - | user | information, log_south, log_bak | - | store_01 | sale_01, sale_02 | - | store_02 | sale_01, sale_02 | - -## 同步需求 - -1. 合并三个实例中的 `user`.`information` 表至下游 TiDB 中的 `user`.`information` 表。 -2. 合并三个实例中的 `user`.`log_{north|south|east}` 表至下游TiDB中的 `user`.`log_{north|south|east}` 表。 -3. 合并三个实例中的 `store_{01|02}`.`sale_{01|02}` 表至下游TiDB中的 `store`.`sale` 表。 -4. 过滤掉三个实例的 `user`.`log_{north|south|east}` 表的所有删除操作。 -5. 过滤掉三个实例的 `user`.`information` 表的所有删除操作。 -6. 过滤掉三个实例的 `store_{01|02}`.`sale_{01|02}` 表的所有删除操作。 -7. 过滤掉三个实例的 `user`.`log_bak` 表。 -8. 因为 `store_{01|02}`.`sale_{01|02}` 表带有 bigint 型的自增主键，将其合并至 TiDB 时会引发冲突。你需要有相应的方案来避免冲突。 - -## 下游实例 - -假设同步后下游库结构如下： - -| Schema | Tables | -|:------|:------| -| user | information, log_north, log_east, log_south| -| store | sale | - -## 同步方案 - -- 要满足同步需求 #1 和 #2，配置 [Table routing 规则](/dev/reference/tools/data-migration/features/overview.md#table-routing) 如下： - - {{< copyable "" >}} - - ```yaml - routes: - ... - user-route-rule: - schema-pattern: "user" - target-schema: "user" - ``` - -- 要满足同步需求 #3，配置 [table routing 规则](/dev/reference/tools/data-migration/features/overview.md#table-routing) 如下： - - {{< copyable "" >}} - - ```yaml - routes: - ... - store-route-rule: - schema-pattern: "store_*" - target-schema: "store" - sale-route-rule: - schema-pattern: "store_*" - table-pattern: "sale_*" - target-schema: "store" - target-table: "sale" - ``` - -- 要满足同步需求 #4 和 #5，配置 [Binlog event filter 规则](/dev/reference/tools/data-migration/features/overview.md#binlog-event-filter) 如下： - - {{< copyable "" >}} - - ```yaml - filters: - ... - user-filter-rule: - schema-pattern: "user" - events: ["truncate table", "drop table", "delete", "drop database"] - action: Ignore - ``` - - > **注意：** - > - > 同步需求 #4、#5 和 #7 的操作意味着过滤掉所有对 `user` 库的删除操作，所以此处配置了库级别的过滤规则。但是 `user` 库以后加入表的删除操作也都会被过滤。 - -- 要满足同步需求 #6，配置 [Binlog event filter 规则](/dev/reference/tools/data-migration/features/overview.md#binlog-event-filter) 如下： - - {{< copyable "" >}} - - ```yaml - filters: - ... - sale-filter-rule: - schema-pattern: "store_*" - table-pattern: "sale_*" - events: ["truncate table", "drop table", "delete"] - action: Ignore - store-filter-rule: - schema-pattern: "store_*" - events: ["drop database"] - action: Ignore - ``` - -- 要满足同步需求 #7，配置 [Black & white table lists](/dev/reference/tools/data-migration/features/overview.md#black--white-table-lists) 如下： - - {{< copyable "" >}} - - ```yaml - black-white-list: - log-bak-ignored: - ignore-tables: - - db-name: "user" - tbl-name: "log_bak" - ``` - -- 要满足同步需求 #8，首先参考[自增主键冲突处理](/dev/reference/tools/data-migration/usage-scenarios/best-practice-dm-shard.md#自增主键冲突处理)来解决冲突，保证在同步到下游时不会因为分表中有相同的主键值而使同步出现异常；然后需要配置 `ignore-checking-items` 来跳过自增主键冲突的检查： - - {{< copyable "" >}} - - ```yaml - ignore-checking-items: ["auto_increment_ID"] - ``` - -## 同步任务配置 - -同步任务的完整配置如下。详情请参阅 [Data Migration 任务配置文件](/dev/reference/tools/data-migration/configure/task-configuration-file.md)。 - -{{< copyable "" >}} - -```yaml -name: "shard_merge" -task-mode: all -meta-schema: "dm_meta" -remove-meta: false -ignore-checking-items: ["auto_increment_ID"] - -target-database: - host: "192.168.0.1" - port: 4000 - user: "root" - password: "" - -mysql-instances: - - - source-id: "instance-1" - route-rules: ["user-route-rule", "store-route-rule", "sale-route-rule"] - filter-rules: ["user-filter-rule", "store-filter-rule", "sale-filter-rule"] - black-white-list: "log-bak-ignored" - mydumper-config-name: "global" - loader-config-name: "global" - syncer-config-name: "global" - - - - source-id: "instance-2" - route-rules: ["user-route-rule", "store-route-rule", "sale-route-rule"] - filter-rules: ["user-filter-rule", "store-filter-rule", "sale-filter-rule"] - black-white-list: "log-bak-ignored" - mydumper-config-name: "global" - loader-config-name: "global" - syncer-config-name: "global" - - - source-id: "instance-3" - route-rules: ["user-route-rule", "store-route-rule", "sale-route-rule"] - filter-rules: ["user-filter-rule", "store-filter-rule", "sale-filter-rule"] - black-white-list: "log-bak-ignored" - mydumper-config-name: "global" - loader-config-name: "global" - syncer-config-name: "global" - -# 所有实例共享的其他通用配置 - -routes: - user-route-rule: - schema-pattern: "user" - target-schema: "user" - store-route-rule: - schema-pattern: "store_*" - target-schema: "store" - sale-route-rule: - schema-pattern: "store_*" - table-pattern: "sale_*" - target-schema: "store" - target-table: "sale" - -filters: - user-filter-rule: - schema-pattern: "user" - events: ["truncate table", "drop table", "delete", "drop database"] - action: Ignore - sale-filter-rule: - schema-pattern: "store_*" - table-pattern: "sale_*" - events: ["truncate table", "drop table", "delete"] - action: Ignore - store-filter-rule: - schema-pattern: "store_*" - events: ["drop database"] - action: Ignore - -black-white-list: - log-bak-ignored: - ignore-tables: - - db-name: "user" - tbl-name: "log_bak" - -mydumpers: - global: - threads: 4 - chunk-filesize: 64 - skip-tz-utc: true - -loaders: - global: - pool-size: 16 - dir: "./dumped_data" - -syncers: - global: - worker-count: 16 - batch: 100 - max-retry: 100 -``` diff --git a/dev/reference/tools/data-migration/usage-scenarios/simple-synchronization.md b/dev/reference/tools/data-migration/usage-scenarios/simple-synchronization.md deleted file mode 100644 index 1da1c21860b5..000000000000 --- a/dev/reference/tools/data-migration/usage-scenarios/simple-synchronization.md +++ /dev/null @@ -1,255 +0,0 @@ ---- -title: Data Migration 简单使用场景 -category: reference ---- - -# Data Migration 简单使用场景 - -本文介绍了 DM 工具的一个简单使用场景（非分库分表合并场景）：将三个上游 MySQL 实例的数据同步到一个下游 TiDB 集群中。 - -## 上游实例 - -假设上游结构为： - -- 实例 1 - - | Schema | Tables | - |:------|:------| - | user | information, log | - | store | store_bj, store_tj | - | log | messages | - -- 实例 2 - - | Schema | Tables | - |:------|:------| - | user | information, log | - | store | store_sh, store_sz | - | log | messages | - -- 实例 3 - - | Schema | Tables | - |:------|:------| - | user | information, log | - | store | store_gz, store_sz | - | log | messages | - -## 同步要求 - -1. 不合并 `user` 库。 - - 1. 将实例 1 中的 `user` 库同步到下游 TiDB 的 `user_north` 库中。 - - 2. 将实例 2 中的 `user` 库同步到下游 TiDB 的 `user_east` 库中。 - - 3. 将实例 3 中的 `user` 库同步到下游 TiDB 的 `user_south` 库中。 - - 4. 任何情况下都不删除 `log` 表的任何数据。 - -2. 将上游 `store` 库同步到下游 `store` 库中，且同步过程中不合并表。 - - 1. 实例 2 和实例 3 中都存在 `store_sz` 表，且这两个 `store_sz` 表分别被同步到下游的 `store_suzhou` 表和 `store_shenzhen` 表中。 - - 2. 任何情况下都不删除 `store` 库的任何数据。 - -3. `log` 库需要被过滤掉。 - -## 下游实例 - -假设下游结构为： - -| Schema | Tables | -|:------|:------| -| user_north | information, log | -| user_east | information, log | -| user_south | information, log | -| store | store_bj, store_tj, store_sh, store_suzhou, store_gz, store_shenzhen | - -## 同步方案 - -- 为了满足[同步要求](#同步要求)中第一点的前三条要求，需要配置以下 [table routing 规则](/dev/reference/tools/data-migration/features/overview.md#table-routing)： - - {{< copyable "" >}} - - ```yaml - routes: - ... - instance-1-user-rule: - schema-pattern: "user" - target-schema: "user_north" - instance-2-user-rule: - schema-pattern: "user" - target-schema: "user_east" - instance-3-user-rule: - schema-pattern: "user" - target-schema: "user_south" - ``` - -- 为了满足[同步要求](#同步要求)中第二点的第一条要求，需要配置以下 [table routing 规则](/dev/reference/tools/data-migration/features/overview.md#table-routing)： - - {{< copyable "" >}} - - ```yaml - routes: - ... - instance-2-store-rule: - schema-pattern: "store" - table-pattern: "store_sz" - target-schema: "store" - target-table: "store_suzhou" - instance-3-store-rule: - schema-pattern: "store" - table-pattern: "store_sz" - target-schema: "store" - target-table: "store_shenzhen" - ``` - -- 为了满足[同步要求](#同步要求)中第一点的第四条要求，需要配置以下 [binlog event filter 规则](/dev/reference/tools/data-migration/features/overview.md#binlog-event-filter)： - - {{< copyable "" >}} - - ```yaml - filters: - ... - log-filter-rule: - schema-pattern: "user" - table-pattern: "log" - events: ["truncate table", "drop table", "delete"] - action: Ignore - user-filter-rule: - schema-pattern: "user" - events: ["drop database"] - action: Ignore - ``` - -- 为了满足[同步要求](#同步要求)中第二点的第二条要求，需要配置以下 [binlog event filter 规则](/dev/reference/tools/data-migration/features/overview.md#binlog-event-filter)： - - {{< copyable "" >}} - - ```yaml - filters: - ... - store-filter-rule: - schema-pattern: "store" - events: ["drop database", "truncate table", "drop table", "delete"] - action: Ignore - ``` - - > **注意：** - > - > `store-filter-rule` 不同于 `log-filter-rule` 和 `user-filter-rule`。`store-filter-rule` 是针对整个 `store` 库的规则，而 `log-filter-rule` 和 `user-filter-rule` 是针对 `user` 库中 `log` 表的规则。 - -- 为了满足[同步要求](#同步要求)中的第三点要求，需要配置以下 [black & white table lists 规则](/dev/reference/tools/data-migration/features/overview.md#black--white-table-lists)： - - {{< copyable "" >}} - - ```yaml - black-white-list: - log-ignored: - ignore-dbs: ["log"] - ``` - -## 同步任务配置 - -以下是完整的同步任务配置，详见[配置介绍](/dev/reference/tools/data-migration/configure/task-configuration-file.md)。 - -{{< copyable "" >}} - -```yaml -name: "one-tidb-slave" -task-mode: all -meta-schema: "dm_meta" -remove-meta: false - -target-database: - host: "192.168.0.1" - port: 4000 - user: "root" - password: "" - -mysql-instances: - - - source-id: "instance-1" - route-rules: ["instance-1-user-rule"] - filter-rules: ["log-filter-rule", "user-filter-rule" , "store-filter-rule"] - black-white-list: "log-ignored" - mydumper-config-name: "global" - loader-config-name: "global" - syncer-config-name: "global" - - - source-id: "instance-2" - route-rules: ["instance-2-user-rule", instance-2-store-rule] - filter-rules: ["log-filter-rule", "user-filter-rule" , "store-filter-rule"] - black-white-list: "log-ignored" - mydumper-config-name: "global" - loader-config-name: "global" - syncer-config-name: "global" - - - source-id: "instance-3" - route-rules: ["instance-3-user-rule", instance-3-store-rule] - filter-rules: ["log-filter-rule", "user-filter-rule" , "store-filter-rule"] - black-white-list: "log-ignored" - mydumper-config-name: "global" - loader-config-name: "global" - syncer-config-name: "global" - -# 所有实例的共有配置 - -routes: - instance-1-user-rule: - schema-pattern: "user" - target-schema: "user_north" - instance-2-user-rule: - schema-pattern: "user" - target-schema: "user_east" - instance-3-user-rule: - schema-pattern: "user" - target-schema: "user_south" - instance-2-store-rule: - schema-pattern: "store" - table-pattern: "store_sz" - target-schema: "store" - target-table: "store_suzhou" - instance-3-store-rule: - schema-pattern: "store" - table-pattern: "store_sz" - target-schema: "store" - target-table: "store_shenzhen" - -filters: - log-filter-rule: - schema-pattern: "user" - table-pattern: "log" - events: ["truncate table", "drop table", "delete"] - action: Ignore - user-filter-rule: - schema-pattern: "user" - events: ["drop database"] - action: Ignore - store-filter-rule: - schema-pattern: "store" - events: ["drop database", "truncate table", "drop table", "delete"] - action: Ignore - -black-white-list: - log-ignored: - ignore-dbs: ["log"] - -mydumpers: - global: - threads: 4 - chunk-filesize: 64 - skip-tz-utc: true - -loaders: - global: - pool-size: 16 - dir: "./dumped_data" - -syncers: - global: - worker-count: 16 - batch: 100 - max-retry: 100 -``` diff --git a/dev/reference/tools/download.md b/dev/reference/tools/download.md deleted file mode 100644 index 4561fd02e82e..000000000000 --- a/dev/reference/tools/download.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: TiDB 工具下载 -category: reference ---- - -# TiDB 工具下载 - -本页面汇总了 TiDB 周边工具官方维护版本的下载链接。 - -## TiDB Binlog - -如需下载最新版本的 [TiDB Binlog](/dev/reference/tidb-binlog/overview.md)，直接下载 TiDB 安装包即可，因为 TiDB Binlog 包含在 TiDB 安装包中。 - -以下表格中也提供了 Kafka 版本的 TiDB Binlog 下载链接。 - -| 安装包 | 操作系统 | 架构 | SHA256 校验和 | -|:---|:---|:---|:---| -| `https://download.pingcap.org/tidb-{version}-linux-amd64.tar.gz` (TiDB Binlog) | Linux | amd64 | `https://download.pingcap.org/tidb-{version}-linux-amd64.sha256` | -| `https://download.pingcap.org/tidb-binlog-kafka-linux-amd64.tar.gz`（Kafka 版本的 TiDB Binlog）| Linux | amd64 | `https://download.pingcap.org/tidb-binlog-kafka-linux-amd64.sha256` | - -> **注意：** -> -> 下载链接中的 `{version}` 为 TiDB 的版本号。例如，`v3.0.5` 版本的下载链接为 `https://download.pingcap.org/tidb-v3.0.5-linux-amd64.tar.gz`。也可以使用 `latest` 替代 `{version}` 来下载最新的未发布版本。 - -## TiDB Lightning - -使用下表中的链接下载 [TiDB Lightning](/dev/reference/tools/tidb-lightning/overview.md)： - -| 安装包 | 操作系统 | 架构 | SHA256 校验和 | -|:---|:---|:---|:---| -| `https://download.pingcap.org/tidb-toolkit-{version}-linux-amd64.tar.gz` | Linux | amd64 | `https://download.pingcap.org/tidb-toolkit-{version}-linux-amd64.sha256` | - -> **注意：** -> -> 下载链接中的 `{version}` 为 TiDB Lightning 的版本号。例如，`v3.0.5` 版本的下载链接为 `https://download.pingcap.org/tidb-toolkit-v3.0.5-linux-amd64.tar.gz`。也可以使用 `latest` 替代 `{version}` 来下载最新的未发布版本。 - -## 快速备份和恢复（BR） - -使用下表中的链接下载 [快速备份和恢复（BR）](/dev/reference/tools/br/br.md)： - -| 安装包 | 操作系统 | 架构 | SHA256 校验和 | -|:---|:---|:---|:---| -| `https://download.pingcap.org/tidb-toolkit-{version}-linux-amd64.tar.gz` | Linux | amd64 | `https://download.pingcap.org/tidb-toolkit-{version}-linux-amd64.sha256` | - -> **注意：** -> -> 下载链接中的 `{version}` 为 BR 的版本号。例如，`v3.1.0-beta` 版本的下载链接为 `https://download.pingcap.org/tidb-toolkit-v3.1.0-beta-linux-amd64.tar.gz`。也可以使用 `latest` 替代 `{version}` 来下载最新的未发布版本。 - -## TiDB DM (Data Migration) - -使用下表中的链接下载 [DM](/dev/reference/tools/data-migration/overview.md)： - -| 安装包 | 操作系统 | 架构 | SHA256 校验和 | -|:---|:---|:---|:---| -| `https://download.pingcap.org/dm-{version}-linux-amd64.tar.gz` | Linux | amd64 | `https://download.pingcap.org/dm-{version}-linux-amd64.sha256` | - -> **注意：** -> -> 下载链接中的 `{version}` 为 DM 的版本号。例如，`v1.0.1` 版本的下载链接为 `https://download.pingcap.org/dm-v1.0.1-linux-amd64.tar.gz`。可以通过 [DM Release](https://github.com/pingcap/dm/releases) 查看当前已发布版本。也可以使用 `latest` 替代 `{version}` 来下载最新的未发布版本。 - -## Syncer，Loader 和 Mydumper - -如需下载最新版本的 [Syncer](/dev/reference/tools/syncer.md)，[Loader](/dev/reference/tools/loader.md) 或 [Mydumper](/dev/reference/tools/mydumper.md)，直接下载 tidb-enterprise-tools 安装包即可，因为这些工具均包含在此安装包中。 - -| 安装包 | 操作系统 | 架构 | SHA256 校验和 | -|:---|:---|:---|:---| -| [tidb-enterprise-tools-latest-linux-amd64.tar.gz](https://download.pingcap.org/tidb-enterprise-tools-latest-linux-amd64.tar.gz) | Linux | amd64 | [tidb-enterprise-tools-latest-linux-amd64.sha256](https://download.pingcap.org/tidb-enterprise-tools-latest-linux-amd64.sha256) | - -tidb-enterprise-tools 安装包包含以下工具： - -- Syncer -- Loader -- Mydumper -- ddl_checker -- [sync-diff-inspector](/dev/reference/tools/sync-diff-inspector/overview.md) diff --git a/dev/reference/tools/error-case-handling/load-misuse-handling.md b/dev/reference/tools/error-case-handling/load-misuse-handling.md deleted file mode 100644 index 2792b35fa4f1..000000000000 --- a/dev/reference/tools/error-case-handling/load-misuse-handling.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: 全量数据导入过程常见报错处理 -category: reference ---- - -# 全量数据导入过程常见报错处理 - -本文介绍了使用 [Loader](/dev/reference/tools/loader.md) 或者 [TiDB Data Migration](/dev/reference/tools/data-migration/overview.md)（以下简称为 DM）进行全量数据导入过程中常见的因为使用造成的出错场景，以及这些错误发生的原因和处理方式。 - -## 报错：```Try adjusting the `max_allowed_packet` variable``` - -在全量数据导入过程中遇到下面的报错 - -``` -packet for query is too large. Try adjusting the 'max_allowed_packet' variable -``` - -### 原因 - -* MySQL client 和 MySQL/TiDB Server 都有 `max_allowed_packet` 配额的限制，如果在使用过程中违反其中任何一个 `max_allowed_packet` 配额，客户端程序就会收到对应的报错。目前最新版本的 Syncer、Loader、DM 和 TiDB Server 的默认 `max_allowed_packet` 配额都为 `64M`。 - * 请使用最新版本，或者最新稳定版本的工具。[下载页面](/dev/reference/tools/download.md)。 -* Loader 或 DM 的全量数据导入处理模块不支持对 dump sqls 文件进行切分，原因是 Mydumper 采用了最简单的编码实现，正如 Mydumper 代码注释 `/* Poor man's data dump code */` 所言。如果在 Loader 或 DM 实现文件切分，那么需要在 `TiDB parser` 基础上实现一个完备的解析器才能正确的处理数据切分，但是随之会带来以下的问题： - * 工作量大 - * 复杂度高，不容易保证正确性 - * 性能的极大降低 - -### 解决方案 - -* 依据上面的原因，在代码层面不能简单的解决这个困扰，我们推荐的方式是：利用 Mydumper 提供的控制 `Insert Statement` 大小的功能 `-s, --statement-size`: `Attempted size of INSERT statement in bytes, default 1000000`。 - - 依据默认的 `--statement-size` 设置，Mydumper 默认生成的 `Insert Statement` 大小会尽量接近在 `1M` 左右，使用默认值就可以确保绝大部分情况不会出现该问题。 - - 有时候在 dump 过程中会出现下面的 `WARN` log，但是这个报错不影响 dump 的过程，只是表达了 dump 的表可能是宽表。 - - ``` - Row bigger than statement_size for xxx - ``` - -* 如果宽表的单行超过了 `64M`，那么需要修改以下两个配置，并且使之生效。 - * 在 TiDB Server 执行 `set @@global.max_allowed_packet=134217728` （`134217728 = 128M`） - * 根据实际情况为 Loader 的配置文件或者 DM task 配置文件中的 db 配置增加类似 `max-allowed-packet=128M`，然后重启进程或者任务 diff --git a/dev/reference/tools/loader.md b/dev/reference/tools/loader.md deleted file mode 100644 index f8d8b2db4c6d..000000000000 --- a/dev/reference/tools/loader.md +++ /dev/null @@ -1,154 +0,0 @@ ---- -title: Loader 使用文档 -category: reference ---- - -# Loader 使用文档 - -## Loader 简介 - -Loader 是由 PingCAP 开发的数据导入工具，用于向 TiDB 中导入数据。 - -Loader 包含在 tidb-enterprise-tools 安装包中，可[在此下载](/dev/reference/tools/download.md)。 - -## 为什么我们要做这个工具 - -当数据量比较大的时候，如果用 mysqldump 这样的工具迁移数据会比较慢。我们尝试了 [Mydumper/myloader 套件](https://github.com/maxbube/mydumper)，能够多线程导出和导入数据。在使用过程中，Mydumper 问题不大，但是 myloader 由于缺乏出错重试、断点续传这样的功能，使用起来很不方便。所以我们开发了 loader，能够读取 Mydumper 的输出数据文件，通过 MySQL protocol 向 TiDB/MySQL 中导入数据。 - -## Loader 有哪些优点 - -* 多线程导入 -* 支持表级别的并发导入，分散写入热点 -* 支持对单个大表并发导入，分散写入热点 -* 支持 Mydumper 数据格式 -* 出错重试 -* 断点续导 -* 通过 system variable 优化 TiDB 导入数据速度 - -## 使用方法 - -### 注意事项 - -请勿使用 loader 导入 MySQL 实例中 `mysql` 系统数据库到下游 TiDB。 - -如果 Mydumper 使用 -m 参数，会导出不带表结构的数据，这时 loader 无法导入数据。 - -如果使用默认的 `checkpoint-schema` 参数，在导完一个 database 数据库后，请 `drop database tidb_loader` 后再开始导入下一个 database。 - -推荐数据库开始导入的时候，明确指定 `checkpoint-schema = "tidb_loader"` 参数。 - -### 参数说明 - -``` - -L string - log 级别设置，可以设置为 debug, info, warn, error, fatal (默认为 "info") - -P int - TiDB/MySQL 的端口 (默认为 4000) - -V - 打印 loader 版本 - -c string - 指定配置文件启动 loader - -checkpoint-schema string - checkpoint 数据库名，loader 在运行过程中会不断的更新这个数据库，在中断并恢复后，会通过这个库获取上次运行的进度 (默认为 "tidb_loader") - -d string - 需要导入的数据存放路径 (default "./") - -h string - TiDB 服务 host IP (default "127.0.0.1") - -p string - TiDB 账户密码 - -status-addr string - Prometheus 可以通过该地址拉取 Loader metrics, 也是 Loader 的 pprof 调试地址 (默认为 ":8272")。 - -t int - 线程数 (默认为 16). 每个线程同一时刻只能操作一个数据文件。 - -u string - TiDB 的用户名 (默认为 "root") -``` - -### 配置文件 - -除了使用命令行参数外，还可以使用配置文件来配置，配置文件的格式如下： - -```toml -# 日志输出等级；可以设置为 debug, info, warn, error, fatal (默认为 "info") -log-level = "info" - -# 指定 loader 日志目录 -log-file = "loader.log" - -# 需要导入的数据存放路径 (default "./") -dir = "./" - -## Prometheus 可以通过该地址拉取 Loader metrics, 也是 Loader 的 pprof 调试地址 (默认为 ":8272")。 -status-addr = ":8272" - -# checkpoint 数据库名，loader 在运行过程中会不断的更新这个数据库，在中断并恢复后， -# 会通过这个库获取上次运行的进度 (默认为 "tidb_loader") -checkpoint-schema = "tidb_loader" - -# 线程数 (默认为 16). 每个线程同一时刻只能操作一个数据文件。 -pool-size = 16 - -# 目标数据库信息 -[db] -host = "127.0.0.1" -user = "root" -password = "" -port = 4000 - -# 导入数据时数据库连接所使用的 session 级别的 `sql_mode`。如果 `sql-mode` 的值没有提供或者设置为 "@DownstreamDefault"，会使用下游 global 级别的 `sql_mode`。 -# sql-mode = "" -# `max-allowed-packet` 设置数据库连接允许的最大数据包大小，对应于系统参数中的 `max_allowed_packet`。 如果设置为 0，会使用下游数据库 global 级别的 `max_allowed_packet`。 -max-allowed-packet = 67108864 - -# sharding 同步规则，采用 wildcharacter -# 1\. 星号字符 (*) 可以匹配零个或者多个字符, -# 例子, doc* 匹配 doc 和 document, 但是和 dodo 不匹配; -# 星号只能放在 pattern 结尾，并且一个 pattern 中只能有一个 -# 2\. 问号字符 (?) 匹配任一一个字符 - -# [[route-rules]] -# pattern-schema = "shard_db_*" -# pattern-table = "shard_table_*" -# target-schema = "shard_db" -# target-table = "shard_table" -``` - -### 使用示例 - -通过命令行参数： - -{{< copyable "shell-regular" >}} - -```bash -./bin/loader -d ./test -h 127.0.0.1 -u root -P 4000 -``` - -或者使用配置文件 "config.toml": - -{{< copyable "shell-regular" >}} - -```bash -./bin/loader -c=config.toml -``` - -## FAQ - -### 合库合表场景案例说明 - -根据配置文件的 route-rules 可以支持将分库分表的数据导入到同一个库同一个表中，但是在开始前需要检查分库分表规则： - -+ 是否可以利用 route-rules 的语义规则表示 -+ 分表中是否包含唯一递增主键，或者合并后是否包含数据上有冲突的唯一索引或者主键 - -Loader 需要配置文件中开启 route-rules 参数以提供合库合表功能 - -+ 如果使用该功能，必须填写 `pattern-schema` 与 `target-schema` -+ 如果 `pattern-table` 与 `target-table` 为空，将不进行表名称合并或转换 - -```toml -[[route-rules]] -pattern-schema = "example_db" -pattern-table = "table_*" -target-schema = "example_db" -target-table = "table" -``` diff --git a/dev/reference/tools/mydumper.md b/dev/reference/tools/mydumper.md deleted file mode 100644 index 492a6ba20f2b..000000000000 --- a/dev/reference/tools/mydumper.md +++ /dev/null @@ -1,190 +0,0 @@ ---- -title: Mydumper 使用文档 -summary: 使用 Mydumper 从 TiDB 导出数据。 -category: reference ---- - -# Mydumper 使用文档 - -## Mydumper 简介 - -[Mydumper](https://github.com/pingcap/mydumper) 是一个 fork 项目，针对 TiDB 的特性进行了优化，推荐使用此工具对 TiDB 进行逻辑备份。 - -Mydumper 包含在 tidb-enterprise-tools 安装包中，可[在此下载](/dev/reference/tools/download.md)。 - -### 相比于普通的 Mydumper，此工具有哪些改进之处？ - -+ 对于 TiDB 可以设置 [tidb_snapshot](/dev/how-to/get-started/read-historical-data.md#操作流程) 的值指定备份数据的时间点，从而保证备份的一致性，而不是通过 `FLUSH TABLES WITH READ LOCK` 来保证备份一致性。 - -+ 使用 TiDB 的隐藏列 `_tidb_rowid` 优化了单表内数据的并发导出性能。 - -## 基本用法 - -### 新添参数 - -- `-z` 或 `--tidb-snapshot`：设置 `tidb_snapshot` 用于备份。默认值为当前 TSO（`SHOW MASTER STATUS` 输出的 `Position` 字段）。此参数可设为 TSO 或有效的 `datetime` 时间，例如：`-z "2016-10-08 16:45:26"`。 - -### 需要的权限 - -- SELECT -- RELOAD -- LOCK TABLES -- REPLICATION CLIENT - -### 使用举例 - -执行如下命令从 TiDB 备份数据，需要根据实际情况添加命令行参数： - -{{< copyable "shell-regular" >}} - -```bash -./bin/mydumper -h 127.0.0.1 -u root -P 4000 -``` - -## 表内并发 Dump - -### 原理 - -Mydumper 首先计算 `min(_tidb_rowid)` 和 `max(_tidb_rowid)`，然后按照 `-r` 设定的值对表划分 chunks，将 chunks 分配到不同线程并发导出。 - -### 并发 Dump 相关参数 - -- `-t` 或 `--threads`：并发线程数，默认值为 `4`。 -- `-r` 或 `--rows`：每个 chunks 包含的最大行数。设置该值后，Mydumper 将会忽略 `--chunk-filesize` 值。 - -### 示例 - -以下是一条完整的 Mydumper 命令： - -{{< copyable "shell-regular" >}} - -```bash -./bin/mydumper -h 127.0.0.1 -u root -P 4000 -r 10000 -t 4 -``` - -### 支持 `_tidb_rowid` 索引的 TiDB 版本 - -由于表内并发使用 TiDB 的隐藏列 `_tidb_rowid`，数据库需要支持 `_tidb_rowid` 索引才能发挥并发导出的优势。 - -以下 TiDB 版本支持 `_tidb_rowid` 索引： - -- v2.1.3 及以上 -- v3.0 及以上，包括 v3.1 及未来版本 - -### 性能评估 - -在 Dump 操作前需要进行性能评估。由于并发 Scan 操作对 TiDB、TiKV 集群都会产生一定压力，所以需要评估与测试 Dump 操作对数据库集群和业务的影响。 - -## FAQ - -### 如何判断使用的 Mydumper 是否为 PingCAP 优化的版本？ - -执行如下命令： - -{{< copyable "shell-regular" >}} - -```bash -./bin/mydumper -V -``` - -如果输出结果中包含 `githash`（如下列示例输出中的 `d3e6fec8b069daee772d0dbaa47579f67a5947e7`），则使用的 Mydumper 为 PingCAP 优化的版本。 - -``` -mydumper 0.9.5 (d3e6fec8b069daee772d0dbaa47579f67a5947e7), built against MySQL 5.7.24 -``` - -### 使用 Loader 恢复 Mydumper 备份出来的数据时报错 "invalid mydumper files for there are no `-schema-create.sql` files found"，应该如何解决？ - -检查使用 Mydumper 备份数据时是否使用了 `-T` 或者 `--tables-list` 配置，如果使用了这些配置，Mydumper 就不会生成包含建库 SQL 的文件。 - -**解决方法**：在 Mydumper 备份数据目录下创建文件 `{schema-name}-schema-create.sql`，在文件中写入 "CREATE DATABASE `{schema-name}`"，再运行 Loader 即可。 - -### 为什么使用 Mydumper 导出来的 TIMESTAMP 类型的数据和数据库中的数据不一致？ - -检查一下运行 Mydumper 的服务器的时区与数据库的时区是否一致，Mydumper 会根据运行所在服务器的时区对 TIMESTAMP 类型的数据进行转化，可以给 Mydumper 加上 `--skip-tz-utc` 参数禁止这种转化。 - -### 如何配置 Mydumper 的参数 `-F, --chunk-filesize`？ - -Mydumper 在备份时会根据这个参数的值把每个表的数据划分成多个 chunk，每个 chunk 保存到一个文件中，大小约为 `chunk-filesize`。根据这个参数把数据切分到多个文件中，这样就可以利用 Loader/TiDB Lightning 的并行处理逻辑提高导入速度。如果后续使用 Loader 对备份文件进行恢复，建议把该参数的值设置为 `64`（单位 MB）；如果使用 TiDB Lightning 恢复，则建议设置为 `256`（单位 MB）。 - -### 如何配置 Mydumper 的参数 `-s --statement-size`？ - -Mydumper 使用该参数控制 `Insert Statement` 的大小，默认值为 `10000000`（约 1 MB）。使用该参数来尽量避免在恢复数据时报以下错误： - -```log -packet for query is too large. Try adjusting the 'max_allowed_packet' variable -``` - -默认值在绝大部分情况下都可以满足需求，但是**如果表为宽表，单行数据的大小可能超过 statement-size 的限制，Mydumper 会报如下的 Warning**： - -```log -Row bigger than statement_size for xxx -``` - -此时恢复数据时仍然会报 `packet for query is too large` 的错误日志，这个时候需要修改以下两个配置（以设置为 `128M` 为例）： - -* 在 TiDB Server 执行 `set @@global.max_allowed_packet=134217728`（`134217728` = `128M`）。 -* 根据实际情况为 Loader 的配置文件或者 DM task 配置文件中的 db 配置增加类似 `max-allowed-packet=128M` 的语句，然后重启进程或者任务。 - -### 如何设置 Mydumper 的参数 `-l, --long-query-guard`？ - -把该参数设置为预估备份需要消耗的时间，如果 Mydumper 运行时间超过该参数的值，就会报错退出。推荐初次备份设置为 `7200`（单位：秒），之后可根据具体备份时间进行调整。 - -### 如何设置 Mydumper 的参数 `--tidb-force-priority`？ - -仅当备份 TiDB 的数据时才可以设置该参数，值可以为 `LOW_PRIORITY`，`DELAYED` 或者 `HIGH_PRIORITY`。如果不希望数据备份对线上业务造成影响，推荐将该参数设置为 `LOW_PRIORITY`；如果备份的优先级更高，则可以设置为 `HIGH_PRIORITY`。 - -### Mydumper 备份 TiDB 数据报错 "GC life time is shorter than transaction duration" 应该怎么解决？ - -Mydumper 备份 TiDB 数据时为了保证数据的一致性使用了 TiDB 的 snapshot 特性，如果备份过程中 snapshot 对应的历史数据被 TiDB GC 处理了，则会报该错误。解决步骤如下： - -1. 在备份前，使用 MySQL 客户端查询 TiDB 集群的 `tikv_gc_life_time` 的值，并将其调整为一个合适的值： - - {{< copyable "sql" >}} - - ```sql - SELECT * FROM mysql.tidb WHERE VARIABLE_NAME = 'tikv_gc_life_time'; - ``` - - ``` - +-----------------------+------------------------------------------------------------------------------------------------+ - | VARIABLE_NAME | VARIABLE_VALUE | - +-----------------------+------------------------------------------------------------------------------------------------+ - | tikv_gc_life_time | 10m0s | - +-----------------------+------------------------------------------------------------------------------------------------+ - 1 rows in set (0.02 sec) - ``` - - {{< copyable "sql" >}} - - ```sql - update mysql.tidb set VARIABLE_VALUE = '720h' where VARIABLE_NAME = 'tikv_gc_life_time'; - ``` - -2. 备份完成后，将 `tikv_gc_life_time` 调整为原来的值： - - {{< copyable "sql" >}} - - ```sql - update mysql.tidb set VARIABLE_VALUE = '10m0s' where VARIABLE_NAME = 'tikv_gc_life_time'; - ``` - -### Mydumper 的参数 `--tidb-rowid` 是否需要配置？ - -如果设置该参数为 true，则导出的数据中会包含 TiDB 的隐藏列的数据。将数据恢复到 TiDB 的时候使用隐藏列会有数据不一致的风险，目前不推荐使用该参数。 - -### Mydumper 报错 "Segmentation fault" 怎么解决？ - -该 bug 已修复。如果仍然报错，可尝试升级到最新版本。 - -### Mydumper 报错 "Error dumping table ({schema}.{table}) data: line ...... (total length ...)" 怎么解决？ - -Mydumper 解析 SQL 时报错，可尝试使用最新版本。如果仍然报错，可以提 issue 到 [mydumper/issues](https://github.com/pingcap/mydumper/issues)。 - -### Mydumper 报错 "Failed to set tidb_snapshot: parsing time \"20190901-10:15:00 +0800\" as \"20190901-10:15:00 +0700 MST\": cannot parse \"\" as \"MST\"" 如何解决？ - -检查 TiDB 的版本是否低于 v2.1.11。如果是的话，需要升级 TiDB 到 v2.1.11 或以上版本。 - -### 未来是否计划让 PingCAP 对 Mydumper 的改动合并到上游？ - -是的，PingCAP 团队计划将对 Mydumper 的改动合并到上游。参见 [PR #155](https://github.com/maxbube/mydumper/pull/155)。 diff --git a/dev/reference/tools/pd-control.md b/dev/reference/tools/pd-control.md deleted file mode 100644 index 13d0b792be66..000000000000 --- a/dev/reference/tools/pd-control.md +++ /dev/null @@ -1,1143 +0,0 @@ ---- -title: PD Control 使用说明 -category: reference ---- - -# PD Control 使用说明 - -PD Control 是 PD 的命令行工具，用于获取集群状态信息和调整集群。 - -## 源码编译 - -1. [Go](https://golang.org/) Version 1.9 以上 -2. 在 PD 项目根目录使用 `make` 命令进行编译，生成 bin/pd-ctl - -## 下载安装包 - -如需下载最新版本的 `pd-ctl`，直接下载 TiDB 安装包即可，因为 `pd-ctl` 包含在 TiDB 安装包中。 - -| 安装包 | 操作系统 | 架构 | SHA256 校验和 | -|:---|:---|:---|:---| -| `https://download.pingcap.org/tidb-{version}-linux-amd64.tar.gz` (pd-ctl) | Linux | amd64 | `https://download.pingcap.org/tidb-{version}-linux-amd64.sha256` | - -> **注意：** -> -> 下载链接中的 `{version}` 为 TiDB 的版本号。例如 `v3.0.5` 版本的下载链接为 `https://download.pingcap.org/tidb-v3.0.5-linux-amd64.tar.gz`。也可以使用 `latest` 替代 `{version}` 来下载最新的未发布版本。 - -## 简单例子 - -单命令模式： - -{{< copyable "shell-regular" >}} - -```bash -./pd-ctl store -u http://127.0.0.1:2379 -``` - -交互模式： - -{{< copyable "shell-regular" >}} - -```bash -./pd-ctl -i -u http://127.0.0.1:2379 -``` - -使用环境变量： - -{{< copyable "shell-regular" >}} - -```bash -export PD_ADDR=http://127.0.0.1:2379 && -./pd-ctl -``` - -使用 TLS 加密： - -{{< copyable "shell-regular" >}} - -```bash -./pd-ctl -u https://127.0.0.1:2379 --cacert="path/to/ca" --cert="path/to/cert" --key="path/to/key" -``` - -## 命令行参数(flags) - -### --cacert - -- 指定 PEM 格式的受信任 CA 证书的文件路径 -- 默认值："" - -### --cert - -- 指定 PEM 格式的 SSL 证书的文件路径 -- 默认值："" - -### \-\-detach,-d - -+ 使用单命令行模式(不进入 readline) -+ 默认值: true - -### \-\-help,-h - -+ 输出帮助信息 -+ 默认值：false - -### \-\-interact,-i - -+ 使用交互模式（进入 readline） -+ 默认值：false - -### --key - -- 指定 PEM 格式的 SSL 证书密钥文件路径，即 `--cert` 所指定的证书的私钥 -- 默认值: "" - -### \-\-pd,-u - -+ 指定 PD 的地址 -+ 默认地址：`http://127.0.0.1:2379` -+ 环境变量：`PD_ADDR` - -### --version,-V - -- 打印版本信息并退出 -- 默认值: false - -## 命令(command) - -### cluster - -用于显示集群基本信息。 - -示例： - -{{< copyable "" >}} - -```bash ->> cluster -``` - -``` -{ - "id": 6493707687106161130, - "max_peer_count": 3 -} -``` - -### config [show | set \