From 6512cda0c140c9d7c01f08ea7fd2c748b433e787 Mon Sep 17 00:00:00 2001 From: Keke Yi <40977455+yikeke@users.noreply.github.com> Date: Fri, 21 Feb 2020 20:57:23 +0800 Subject: [PATCH 001/232] release-3.1 branch: build (#2270) --- TOC.md | 489 +++++++ _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 {dev/benchmark => benchmark}/sysbench-v2.md | 0 {dev/benchmark => benchmark}/sysbench-v3.md | 0 {dev/benchmark => benchmark}/sysbench-v4.md | 0 {dev/benchmark => benchmark}/sysbench.md | 0 {dev/benchmark => benchmark}/tpcc.md | 0 {dev/benchmark => benchmark}/tpch-v2.md | 0 {v3.1/benchmark => benchmark}/tpch.md | 0 dev/contribute.md => contribute.md | 0 dev/TOC.md | 490 ------- dev/_index.md | 63 - dev/benchmark/tpch.md | 108 -- dev/faq/tidb-lightning.md | 190 --- dev/faq/tidb.md | 1082 --------------- dev/how-to/configure/memory-control.md | 67 - dev/how-to/configure/time-zone.md | 111 -- .../deploy/data-migration-with-ansible.md | 570 -------- dev/how-to/deploy/orchestrated/ansible.md | 966 -------------- .../deploy/orchestrated/offline-ansible.md | 159 --- dev/how-to/get-started/tidb-binlog.md | 521 -------- .../backup-and-restore/mydumper-lightning.md | 95 -- .../identify-slow-queries.md | 332 ----- dev/how-to/migrate/from-mysql-aurora.md | 208 --- .../secure/enable-tls-between-components.md | 131 -- dev/how-to/upgrade/from-previous-version.md | 220 ---- 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 --------------- dev/reference/error-codes.md | 120 -- dev/reference/garbage-collection/overview.md | 40 - dev/reference/mysql-compatibility.md | 226 ---- ...eck-cluster-status-using-sql-statements.md | 27 - .../performance/execution-plan-bind.md | 103 -- dev/reference/performance/index-merge.md | 99 -- dev/reference/performance/optimizer-hints.md | 268 ---- .../performance/statement-summary.md | 260 ---- dev/reference/performance/statistics.md | 321 ----- dev/reference/security/compatibility.md | 16 - dev/reference/security/privilege-system.md | 481 ------- dev/reference/sql/data-types/date-and-time.md | 66 - .../sql/functions-and-operators/reference.md | 12 - .../sql/language-structure/comment-syntax.md | 124 -- dev/reference/sql/sql-mode.md | 56 - dev/reference/sql/statements/admin.md | 161 --- 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/recover-table.md | 109 -- .../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 -- .../system-databases/information-schema.md | 767 ----------- .../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 ------ .../tools/data-migration/dm-upgrade.md | 161 --- dev/reference/tools/data-migration/faq.md | 52 - .../manually-handling-sharding-ddl-locks.md | 540 -------- .../tools/data-migration/overview.md | 102 -- .../tools/data-migration/query-status.md | 262 ---- .../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 -- .../load-misuse-handling.md | 41 - dev/reference/tools/pd-control.md | 1143 ---------------- dev/reference/tools/pd-recover.md | 39 - dev/reference/tools/syncer.md | 604 --------- dev/reference/tools/tidb-control.md | 271 ---- .../tools/tidb-lightning/checkpoints.md | 119 -- .../tools/tidb-lightning/deployment.md | 279 ---- 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/11beta.md | 49 - dev/releases/2.0.11.md | 21 - dev/releases/2.1.1.md | 46 - dev/releases/2.1.18.md | 76 -- dev/releases/2.1.3.md | 58 - dev/releases/2.1.4.md | 40 - dev/releases/2.1ga.md | 187 --- dev/releases/201.md | 49 - dev/releases/202.md | 30 - dev/releases/203.md | 37 - 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/21rc3.md | 63 - dev/releases/2rc1.md | 39 - dev/releases/2rc3.md | 59 - 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.3.md | 122 -- dev/releases/3.0.2.md | 144 -- dev/releases/3.0.8.md | 112 -- dev/releases/4.0.0-beta.md | 114 -- dev/releases/rn.md | 95 -- dev/roadmap.md | 189 --- dev/tidb-in-kubernetes/deploy/aws-eks.md | 531 -------- .../deploy/tidb-operator.md | 132 -- .../deploy-tidb-from-kubernetes-kind.md | 190 --- .../maintain/backup-and-restore/backup-gcs.md | 204 --- .../maintain/backup-and-restore/backup-s3.md | 267 ---- .../maintain/backup-and-restore/restore.md | 87 -- .../monitor/tidb-in-kubernetes.md | 97 -- .../reference/configuration/storage-class.md | 280 ---- .../reference/configuration/tidb-cluster.md | 212 --- dev/tidb-in-kubernetes/scale-in-kubernetes.md | 72 - {v3.1/faq => faq}/tidb-lightning.md | 18 +- {v3.1/faq => faq}/tidb.md | 90 +- {dev/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 .../backup-and-restore/mydumper-lightning.md | 14 +- .../identify-aborted-queries.md | 4 +- .../identify-slow-queries.md | 4 +- .../migrate/from-mysql-aurora.md | 6 +- .../monitor/monitor-a-cluster.md | 0 {dev/how-to => how-to}/monitor/overview.md | 0 {dev/how-to => how-to}/scale/horizontally.md | 4 +- {dev/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 +- dev/key-features.md => key-features.md | 0 v3.0/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 {v2.1/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/follower-read.md | 0 .../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.1/reference => reference}/tispark.md | 2 +- {v3.1/reference => reference}/tools/br/br.md | 8 +- .../tools/br/use-cases.md | 14 +- .../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 | 26 +- .../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 | 12 +- .../lightning-misuse-handling.md | 4 +- .../load-misuse-handling.md | 4 +- {dev/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.1/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 | 28 +- .../transactions/overview.md | 4 +- .../transactions/transaction-isolation.md | 4 +- .../transactions/transaction-optimistic.md | 8 +- .../transactions/transaction-pessimistic.md | 0 {dev/releases => releases}/11alpha.md | 0 {v2.1/releases => releases}/11beta.md | 0 {dev/releases => releases}/2.0.10.md | 0 {v3.1/releases => releases}/2.0.11.md | 0 {dev/releases => releases}/2.0ga.md | 0 {v3.1/releases => releases}/2.1.1.md | 0 {dev/releases => releases}/2.1.10.md | 0 {dev/releases => releases}/2.1.11.md | 0 {dev/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.1/releases => releases}/2.1.18.md | 0 {dev/releases => releases}/2.1.19.md | 0 {dev/releases => releases}/2.1.2.md | 0 {v2.1/releases => releases}/2.1.3.md | 0 {v3.1/releases => releases}/2.1.4.md | 0 {dev/releases => releases}/2.1.5.md | 0 {dev/releases => releases}/2.1.6.md | 0 {dev/releases => releases}/2.1.7.md | 0 {dev/releases => releases}/2.1.8.md | 0 {dev/releases => releases}/2.1.9.md | 0 {v3.1/releases => releases}/2.1ga.md | 0 {v2.1/releases => releases}/201.md | 0 {v2.1/releases => releases}/202.md | 0 {v2.1/releases => releases}/203.md | 0 {dev/releases => releases}/204.md | 0 {v2.1/releases => releases}/205.md | 0 {v2.1/releases => releases}/206.md | 0 {v2.1/releases => releases}/207.md | 0 {v2.1/releases => releases}/208.md | 0 {v2.1/releases => releases}/209.md | 0 {dev/releases => releases}/21beta.md | 0 {dev/releases => releases}/21rc1.md | 0 {dev/releases => releases}/21rc2.md | 0 {v2.1/releases => releases}/21rc3.md | 0 {dev/releases => releases}/21rc4.md | 0 {dev/releases => releases}/21rc5.md | 2 +- {v2.1/releases => releases}/2rc1.md | 0 {v2.1/releases => releases}/2rc3.md | 0 {dev/releases => releases}/2rc4.md | 0 {v2.1/releases => releases}/2rc5.md | 0 {v2.1/releases => releases}/3.0-ga.md | 0 {v3.1/releases => releases}/3.0.0-beta.1.md | 0 {v2.1/releases => releases}/3.0.0-rc.1.md | 0 {dev/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 | 0 {dev/releases => releases}/3.0.9.md | 0 {dev/releases => releases}/3.0beta.md | 0 {dev/releases => releases}/3.1.0-beta.1.md | 0 {dev/releases => releases}/3.1.0-beta.md | 0 {dev/releases => releases}/ga.md | 0 {dev/releases => releases}/prega.md | 0 {dev/releases => releases}/rc1.md | 0 {dev/releases => releases}/rc2.md | 0 {dev/releases => releases}/rc3.md | 0 {dev/releases => releases}/rc4.md | 0 releases/rn.md | 91 ++ dev/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/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 -- .../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/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 - .../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 ----------- .../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/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.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/204.md | 41 - v2.1/releases/21beta.md | 85 -- v2.1/releases/21rc1.md | 155 --- v2.1/releases/21rc2.md | 119 -- v2.1/releases/21rc4.md | 54 - v2.1/releases/21rc5.md | 63 - v2.1/releases/2rc4.md | 38 - v2.1/releases/3.0.0-beta.1.md | 108 -- 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 | 63 - 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-sysbench.md | 278 ---- v3.0/benchmark/how-to-run-tpcc.md | 258 ---- v3.0/benchmark/sysbench-in-k8s.md | 449 ------- v3.0/benchmark/sysbench-v2.md | 130 -- v3.0/benchmark/sysbench-v3.md | 143 -- v3.0/benchmark/sysbench-v4.md | 279 ---- v3.0/benchmark/sysbench.md | 211 --- v3.0/benchmark/tpcc.md | 97 -- v3.0/benchmark/tpch-v2.md | 105 -- v3.0/benchmark/tpch.md | 108 -- v3.0/contribute.md | 32 - v3.0/faq/tidb-lightning.md | 191 --- v3.0/faq/tidb.md | 1084 --------------- v3.0/faq/upgrade.md | 329 ----- v3.0/glossary.md | 78 -- v3.0/how-to/configure/memory-control.md | 68 - v3.0/how-to/configure/time-zone.md | 110 -- .../deploy/data-migration-with-ansible.md | 571 -------- .../deploy/data-migration-with-binary.md | 306 ----- .../location-awareness.md | 96 -- .../deploy/geographic-redundancy/overview.md | 71 - .../how-to/deploy/hardware-recommendations.md | 84 -- v3.0/how-to/deploy/orchestrated/ansible.md | 966 -------------- v3.0/how-to/deploy/orchestrated/docker.md | 261 ---- .../deploy/orchestrated/offline-ansible.md | 161 --- v3.0/how-to/get-started/data-migration.md | 523 -------- .../deploy-tidb-from-docker-compose.md | 206 --- v3.0/how-to/get-started/explore-sql.md | 275 ---- .../get-started/read-historical-data.md | 195 --- v3.0/how-to/get-started/tidb-lightning.md | 120 -- v3.0/how-to/get-started/tispark.md | 212 --- v3.0/how-to/maintain/ansible-operations.md | 47 - v3.0/how-to/maintain/backup-and-restore.md | 94 -- .../identify-aborted-queries.md | 52 - .../identify-slow-queries.md | 332 ----- v3.0/how-to/migrate/from-mysql-aurora.md | 208 --- v3.0/how-to/monitor/monitor-a-cluster.md | 356 ----- v3.0/how-to/monitor/overview.md | 29 - v3.0/how-to/scale/horizontally.md | 133 -- v3.0/how-to/scale/with-ansible.md | 528 -------- .../secure/enable-tls-between-components.md | 132 -- v3.0/how-to/secure/enable-tls-clients.md | 159 --- .../generate-self-signed-certificates.md | 163 --- v3.0/how-to/troubleshoot/cluster-setup.md | 150 --- v3.0/how-to/troubleshoot/tidb-lightning.md | 135 -- v3.0/how-to/upgrade/from-previous-version.md | 216 --- v3.0/key-features.md | 29 - v3.0/reference/alert-rules.md | 1161 ---------------- .../best-practices/grafana-monitor.md | 206 --- v3.0/reference/best-practices/haproxy.md | 227 ---- v3.0/reference/best-practices/java-app.md | 333 ----- .../best-practices/massive-regions.md | 143 -- .../reference/best-practices/pd-scheduling.md | 271 ---- .../pd-server/configuration-file.md | 265 ---- .../configuration/pd-server/configuration.md | 121 -- .../tidb-server/configuration-file.md | 423 ------ .../tidb-server/configuration.md | 146 --- .../tidb-server/mysql-variables.md | 202 --- .../tidb-server/tidb-specific-variables.md | 672 ---------- .../tikv-server/configuration-file.md | 1093 --------------- .../tikv-server/configuration.md | 61 - v3.0/reference/error-codes.md | 32 - .../garbage-collection/configuration.md | 125 -- v3.0/reference/garbage-collection/overview.md | 41 - .../overview-dashboard.md | 88 -- .../key-monitoring-metrics/pd-dashboard.md | 140 -- .../key-monitoring-metrics/tidb-dashboard.md | 139 -- .../key-monitoring-metrics/tikv-dashboard.md | 430 ------ v3.0/reference/mysql-compatibility.md | 226 ---- ...eck-cluster-status-using-sql-statements.md | 27 - v3.0/reference/performance/optimizer-hints.md | 60 - .../performance/sql-optimizer-overview.md | 27 - .../performance/statement-summary.md | 260 ---- v3.0/reference/performance/statistics.md | 318 ----- v3.0/reference/performance/tune-tikv.md | 253 ---- .../understanding-the-query-execution-plan.md | 156 --- .../security/cert-based-authentication.md | 483 ------- v3.0/reference/security/compatibility.md | 17 - v3.0/reference/security/privilege-system.md | 482 ------- .../security/role-based-access-control.md | 386 ------ .../security/user-account-management.md | 233 ---- v3.0/reference/sql/character-set.md | 328 ----- v3.0/reference/sql/constraints.md | 274 ---- .../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/overview.md | 16 - v3.0/reference/sql/data-types/string.md | 200 --- .../aggregate-group-by-functions.md | 158 --- .../bit-functions-and-operators.md | 21 - .../cast-functions-and-operators.md | 17 - .../control-flow-functions.md | 16 - .../date-and-time-functions.md | 74 -- .../encryption-and-compression-functions.md | 39 - .../expressions-pushed-down.md | 145 -- .../information-functions.md | 33 - .../functions-and-operators/json-functions.md | 85 -- .../miscellaneous-functions.md | 37 - .../numeric-functions-and-operators.md | 56 - .../sql/functions-and-operators/operators.md | 125 -- .../functions-and-operators/precision-math.md | 171 --- .../sql/functions-and-operators/reference.md | 13 - .../string-functions.md | 74 -- .../type-conversion.md | 9 - .../window-functions.md | 24 - v3.0/reference/sql/generated-columns.md | 101 -- .../sql/language-structure/comment-syntax.md | 125 -- .../language-structure/expression-syntax.md | 68 - .../keywords-and-reserved-words.md | 484 ------- .../sql/language-structure/literal-values.md | 284 ---- .../language-structure/schema-object-names.md | 110 -- .../user-defined-variables.md | 246 ---- 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 -- v3.0/reference/sql/statements/admin.md | 110 -- .../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-table.md | 304 ----- 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 -- v3.0/reference/sql/statements/explain.md | 224 ---- .../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/prepare.md | 72 - 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/select.md | 132 -- 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/supported-clients.md | 92 -- .../system-databases/information-schema.md | 757 ----------- v3.0/reference/system-databases/mysql.md | 37 - .../tidb-binlog/binlog-slave-client.md | 148 --- v3.0/reference/tidb-binlog/deploy.md | 645 --------- v3.0/reference/tidb-binlog/faq.md | 210 --- v3.0/reference/tidb-binlog/glossary.md | 29 - v3.0/reference/tidb-binlog/maintain.md | 257 ---- v3.0/reference/tidb-binlog/monitor.md | 164 --- v3.0/reference/tidb-binlog/overview.md | 60 - v3.0/reference/tidb-binlog/relay-log.md | 55 - v3.0/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 - .../troubleshoot/error-handling.md | 32 - v3.0/reference/tidb-binlog/upgrade.md | 83 -- v3.0/reference/tispark.md | 333 ----- .../data-migration/cluster-operations.md | 490 ------- .../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 | 38 - .../configure/task-configuration-file-full.md | 165 --- .../configure/task-configuration-file.md | 83 -- v3.0/reference/tools/data-migration/deploy.md | 187 --- .../tools/data-migration/dm-portal.md | 220 ---- .../tools/data-migration/dm-upgrade.md | 162 --- .../tools/data-migration/dm-worker-intro.md | 100 -- v3.0/reference/tools/data-migration/faq.md | 52 - .../manually-handling-sharding-ddl-locks.md | 541 -------- .../tools/data-migration/features/overview.md | 530 -------- .../data-migration/features/shard-merge.md | 178 --- .../tools/data-migration/from-aurora.md | 207 --- .../tools/data-migration/glossary.md | 124 -- .../tools/data-migration/manage-tasks.md | 957 -------------- .../reference/tools/data-migration/monitor.md | 119 -- .../tools/data-migration/overview.md | 102 -- .../tools/data-migration/precheck.md | 64 - .../tools/data-migration/query-status.md | 260 ---- .../tools/data-migration/relay-log.md | 177 --- .../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 | 662 ---------- .../tools/data-migration/table-selector.md | 45 - .../tools/data-migration/troubleshoot/dm.md | 27 - .../troubleshoot/error-handling.md | 71 - .../troubleshoot/error-system.md | 114 -- .../usage-scenarios/best-practice-dm-shard.md | 131 -- .../usage-scenarios/master-slave-switch.md | 55 - .../usage-scenarios/shard-merge.md | 243 ---- .../usage-scenarios/simple-synchronization.md | 256 ---- v3.0/reference/tools/download.md | 63 - .../lightning-misuse-handling.md | 35 - .../load-misuse-handling.md | 41 - v3.0/reference/tools/loader.md | 155 --- v3.0/reference/tools/mydumper.md | 191 --- v3.0/reference/tools/pd-control.md | 1139 ---------------- v3.0/reference/tools/pd-recover.md | 40 - .../tools/sync-diff-inspector/overview.md | 221 ---- .../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/syncer.md | 605 --------- v3.0/reference/tools/tidb-control.md | 271 ---- .../tools/tidb-lightning/checkpoints.md | 120 -- v3.0/reference/tools/tidb-lightning/config.md | 326 ----- v3.0/reference/tools/tidb-lightning/csv.md | 209 --- .../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 | 132 -- .../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/tools/user-guide.md | 135 -- v3.0/reference/transactions/overview.md | 214 --- .../transactions/transaction-optimistic.md | 178 --- v3.0/releases/11alpha.md | 53 - v3.0/releases/11beta.md | 50 - v3.0/releases/2.0.10.md | 40 - v3.0/releases/2.0.11.md | 22 - v3.0/releases/2.0ga.md | 157 --- v3.0/releases/2.1.1.md | 47 - v3.0/releases/2.1.10.md | 61 - v3.0/releases/2.1.11.md | 46 - v3.0/releases/2.1.12.md | 44 - 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.18.md | 76 -- v3.0/releases/2.1.19.md | 93 -- v3.0/releases/2.1.2.md | 39 - v3.0/releases/2.1.3.md | 58 - v3.0/releases/2.1.4.md | 41 - v3.0/releases/2.1.5.md | 55 - v3.0/releases/2.1.6.md | 39 - v3.0/releases/2.1.7.md | 42 - v3.0/releases/2.1.8.md | 65 - v3.0/releases/2.1.9.md | 70 - v3.0/releases/2.1ga.md | 188 --- v3.0/releases/201.md | 51 - v3.0/releases/202.md | 31 - v3.0/releases/203.md | 38 - v3.0/releases/204.md | 42 - v3.0/releases/205.md | 41 - v3.0/releases/206.md | 50 - v3.0/releases/207.md | 37 - v3.0/releases/208.md | 30 - v3.0/releases/209.md | 47 - v3.0/releases/21beta.md | 86 -- v3.0/releases/21rc1.md | 156 --- v3.0/releases/21rc2.md | 120 -- v3.0/releases/21rc3.md | 64 - v3.0/releases/21rc4.md | 55 - v3.0/releases/21rc5.md | 65 - v3.0/releases/2rc1.md | 40 - v3.0/releases/2rc3.md | 60 - v3.0/releases/2rc4.md | 39 - v3.0/releases/2rc5.md | 49 - v3.0/releases/3.0-ga.md | 219 ---- v3.0/releases/3.0.0-beta.1.md | 109 -- v3.0/releases/3.0.0-rc.1.md | 142 -- v3.0/releases/3.0.0-rc.2.md | 122 -- 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/3.0beta.md | 108 -- v3.0/releases/ga.md | 278 ---- v3.0/releases/prega.md | 40 - v3.0/releases/rc1.md | 42 - v3.0/releases/rc2.md | 53 - v3.0/releases/rc3.md | 54 - v3.0/releases/rc4.md | 49 - v3.0/releases/rn.md | 87 -- v3.0/report-issue.md | 18 - v3.0/roadmap.md | 103 -- v3.0/support-resources.md | 16 - v3.0/tidb-in-kubernetes/deploy/access-tidb.md | 63 - .../deploy/alibaba-cloud.md | 353 ----- v3.0/tidb-in-kubernetes/deploy/aws-eks.md | 532 -------- v3.0/tidb-in-kubernetes/deploy/gcp-gke.md | 741 ----------- .../deploy/general-kubernetes.md | 81 -- .../deploy/prerequisites.md | 175 --- .../deploy/tidb-operator.md | 133 -- v3.0/tidb-in-kubernetes/faq.md | 99 -- .../deploy-tidb-from-kubernetes-gke.md | 305 ----- .../deploy-tidb-from-kubernetes-kind.md | 190 --- .../deploy-tidb-from-kubernetes-minikube.md | 299 ----- v3.0/tidb-in-kubernetes/initialize-cluster.md | 95 -- .../maintain/auto-failover.md | 86 -- .../maintain/backup-and-restore.md | 160 --- .../maintain/destroy-tidb-cluster.md | 35 - .../maintain/kubernetes-node.md | 240 ---- v3.0/tidb-in-kubernetes/maintain/lightning.md | 143 -- .../maintain/log-collecting.md | 91 -- v3.0/tidb-in-kubernetes/maintain/restart.md | 65 - .../maintain/tidb-binlog.md | 214 --- .../monitor/tidb-in-kubernetes.md | 98 -- .../reference/configuration/backup.md | 112 -- .../reference/configuration/storage-class.md | 280 ---- .../reference/configuration/tidb-cluster.md | 212 --- .../reference/configuration/tidb-drainer.md | 46 - .../reference/tools/in-kubernetes.md | 257 ---- .../reference/tools/tkctl.md | 396 ------ .../tidb-in-kubernetes/scale-in-kubernetes.md | 73 -- .../tidb-operator-overview.md | 77 -- v3.0/tidb-in-kubernetes/troubleshoot.md | 373 ------ .../upgrade/tidb-cluster.md | 97 -- .../upgrade/tidb-operator.md | 23 - 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/contribute.md | 31 - v3.1/faq/upgrade.md | 328 ----- v3.1/glossary.md | 78 -- .../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/docker.md | 260 ---- 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 - .../identify-aborted-queries.md | 52 - 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 -------- 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/key-features.md | 28 - v3.1/overview.md | 66 - 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 --- .../best-practices/massive-regions.md | 143 -- .../reference/best-practices/pd-scheduling.md | 271 ---- .../pd-server/configuration-file.md | 265 ---- .../tikv-server/configuration.md | 60 - v3.1/reference/error-codes.md | 31 - .../garbage-collection/configuration.md | 125 -- .../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 - .../performance/sql-optimizer-overview.md | 26 - 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 --- .../string-functions.md | 73 -- .../type-conversion.md | 8 - .../window-functions.md | 24 - v3.1/reference/sql/generated-columns.md | 99 -- .../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 -- .../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 -- .../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 -- v3.1/reference/system-databases/mysql.md | 36 - v3.1/reference/tidb-binlog/glossary.md | 29 - .../troubleshoot/error-handling.md | 32 - .../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-worker-intro.md | 99 -- .../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/relay-log.md | 176 --- .../tools/data-migration/releases/1.0.2.md | 47 - .../tools/data-migration/releases/1.0.3.md | 38 - .../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 - v3.1/reference/tools/loader.md | 154 --- v3.1/reference/tools/mydumper.md | 190 --- 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/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/transactions/overview.md | 214 --- .../transactions/transaction-isolation.md | 55 - .../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.0ga.md | 156 --- 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.19.md | 93 -- v3.1/releases/2.1.2.md | 38 - v3.1/releases/2.1.3.md | 57 - 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/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-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/gcp-gke.md | 740 ----------- .../deploy/general-kubernetes.md | 80 -- .../deploy/prerequisites.md | 174 --- v3.1/tidb-in-kubernetes/faq.md | 98 -- .../deploy-tidb-from-kubernetes-gke.md | 304 ----- .../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 --- .../reference/configuration/backup.md | 111 -- .../reference/configuration/tidb-drainer.md | 46 - .../reference/tools/in-kubernetes.md | 256 ---- .../reference/tools/tkctl.md | 395 ------ .../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, 1425 insertions(+), 171388 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 {dev/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 {dev/benchmark => benchmark}/sysbench-v2.md (100%) rename {dev/benchmark => benchmark}/sysbench-v3.md (100%) rename {dev/benchmark => benchmark}/sysbench-v4.md (100%) rename {dev/benchmark => benchmark}/sysbench.md (100%) rename {dev/benchmark => benchmark}/tpcc.md (100%) rename {dev/benchmark => benchmark}/tpch-v2.md (100%) rename {v3.1/benchmark => benchmark}/tpch.md (100%) rename dev/contribute.md => contribute.md (100%) delete mode 100644 dev/TOC.md delete mode 100755 dev/_index.md delete mode 100644 dev/benchmark/tpch.md delete mode 100644 dev/faq/tidb-lightning.md delete mode 100755 dev/faq/tidb.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/orchestrated/ansible.md delete mode 100644 dev/how-to/deploy/orchestrated/offline-ansible.md delete mode 100644 dev/how-to/get-started/tidb-binlog.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/secure/enable-tls-between-components.md delete mode 100644 dev/how-to/upgrade/from-previous-version.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/error-codes.md delete mode 100644 dev/reference/garbage-collection/overview.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/index-merge.md delete mode 100644 dev/reference/performance/optimizer-hints.md delete mode 100644 dev/reference/performance/statement-summary.md delete mode 100644 dev/reference/performance/statistics.md delete mode 100644 dev/reference/security/compatibility.md delete mode 100644 dev/reference/security/privilege-system.md delete mode 100644 dev/reference/sql/data-types/date-and-time.md delete mode 100644 dev/reference/sql/functions-and-operators/reference.md delete mode 100644 dev/reference/sql/language-structure/comment-syntax.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/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/recover-table.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/system-databases/information-schema.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/dm-upgrade.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/overview.md delete mode 100644 dev/reference/tools/data-migration/query-status.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/error-case-handling/load-misuse-handling.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/syncer.md delete mode 100644 dev/reference/tools/tidb-control.md delete mode 100644 dev/reference/tools/tidb-lightning/checkpoints.md delete mode 100644 dev/reference/tools/tidb-lightning/deployment.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/11beta.md delete mode 100644 dev/releases/2.0.11.md delete mode 100644 dev/releases/2.1.1.md delete mode 100644 dev/releases/2.1.18.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.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/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/21rc3.md delete mode 100644 dev/releases/2rc1.md delete mode 100644 dev/releases/2rc3.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.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/4.0.0-beta.md delete mode 100644 dev/releases/rn.md delete mode 100644 dev/roadmap.md delete mode 100644 dev/tidb-in-kubernetes/deploy/aws-eks.md delete mode 100644 dev/tidb-in-kubernetes/deploy/tidb-operator.md delete mode 100644 dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-kind.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/monitor/tidb-in-kubernetes.md delete mode 100644 dev/tidb-in-kubernetes/reference/configuration/storage-class.md delete mode 100644 dev/tidb-in-kubernetes/reference/configuration/tidb-cluster.md delete mode 100644 dev/tidb-in-kubernetes/scale-in-kubernetes.md rename {v3.1/faq => faq}/tidb-lightning.md (86%) rename {v3.1/faq => faq}/tidb.md (92%) rename {dev/faq => faq}/upgrade.md (100%) rename dev/glossary.md => glossary.md (100%) rename {v3.1/how-to => how-to}/configure/memory-control.md (100%) rename {v3.1/how-to => how-to}/configure/time-zone.md (100%) rename {v3.1/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 {dev/how-to => how-to}/deploy/geographic-redundancy/location-awareness.md (94%) rename {dev/how-to => how-to}/deploy/geographic-redundancy/overview.md (100%) rename {dev/how-to => how-to}/deploy/hardware-recommendations.md (98%) rename {v3.1/how-to => how-to}/deploy/orchestrated/ansible.md (95%) rename {dev/how-to => how-to}/deploy/orchestrated/docker.md (98%) rename {v3.1/how-to => how-to}/deploy/orchestrated/offline-ansible.md (76%) rename {dev/how-to => how-to}/get-started/data-migration.md (97%) rename {dev/how-to => how-to}/get-started/deploy-tidb-from-docker-compose.md (97%) rename {dev/how-to => how-to}/get-started/explore-sql.md (97%) rename {dev/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 {dev/how-to => how-to}/maintain/ansible-operations.md (100%) rename {v3.1/how-to => how-to}/maintain/backup-and-restore/mydumper-lightning.md (82%) rename {dev/how-to => how-to}/maintain/identify-abnormal-queries/identify-aborted-queries.md (74%) rename {v3.1/how-to => how-to}/maintain/identify-abnormal-queries/identify-slow-queries.md (95%) rename {v3.1/how-to => how-to}/migrate/from-mysql-aurora.md (95%) rename {dev/how-to => how-to}/monitor/monitor-a-cluster.md (100%) rename {dev/how-to => how-to}/monitor/overview.md (100%) rename {dev/how-to => how-to}/scale/horizontally.md (96%) rename {dev/how-to => how-to}/scale/with-ansible.md (97%) rename {v3.1/how-to => how-to}/secure/enable-tls-between-components.md (92%) rename {dev/how-to => how-to}/secure/enable-tls-clients.md (95%) rename {dev/how-to => how-to}/secure/generate-self-signed-certificates.md (100%) rename {dev/how-to => how-to}/troubleshoot/cluster-setup.md (91%) rename {dev/how-to => how-to}/troubleshoot/tidb-lightning.md (92%) rename {v3.1/how-to => how-to}/upgrade/from-previous-version.md (86%) rename dev/key-features.md => key-features.md (100%) rename v3.0/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.1/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.1/reference => reference}/configuration/pd-server/configuration.md (100%) rename {v3.1/reference => reference}/configuration/tidb-server/configuration-file.md (99%) rename {v3.1/reference => reference}/configuration/tidb-server/configuration.md (98%) rename {v3.1/reference => reference}/configuration/tidb-server/mysql-variables.md (91%) rename {v3.1/reference => reference}/configuration/tidb-server/tidb-specific-variables.md (97%) rename {v3.1/reference => reference}/configuration/tikv-server/configuration-file.md (99%) rename {dev/reference => reference}/configuration/tikv-server/configuration.md (100%) rename {v2.1/reference => reference}/error-codes.md (84%) rename {dev/reference => reference}/garbage-collection/configuration.md (87%) rename {v3.1/reference => reference}/garbage-collection/overview.md (97%) rename {dev/reference => reference}/key-monitoring-metrics/overview-dashboard.md (99%) rename {dev/reference => reference}/key-monitoring-metrics/pd-dashboard.md (99%) rename {dev/reference => reference}/key-monitoring-metrics/tidb-dashboard.md (99%) rename {dev/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 {dev/reference => reference}/performance/follower-read.md (100%) rename {v3.1/reference => reference}/performance/optimizer-hints.md (100%) rename {dev/reference => reference}/performance/sql-optimizer-overview.md (100%) rename {v3.1/reference => reference}/performance/statement-summary.md (100%) rename {v3.1/reference => reference}/performance/statistics.md (100%) rename {dev/reference => reference}/performance/tune-tikv.md (100%) rename {dev/reference => reference}/performance/understanding-the-query-execution-plan.md (100%) rename {dev/reference => reference}/security/cert-based-authentication.md (100%) rename {v2.1/reference => reference}/security/compatibility.md (100%) rename {v2.1/reference => reference}/security/privilege-system.md (100%) rename {dev/reference => reference}/security/role-based-access-control.md (94%) rename {dev/reference => reference}/security/user-account-management.md (98%) rename {dev/reference => reference}/sql/character-set.md (100%) rename {dev/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 {dev/reference => reference}/sql/data-types/overview.md (71%) rename {dev/reference => reference}/sql/data-types/string.md (100%) rename {dev/reference => reference}/sql/functions-and-operators/aggregate-group-by-functions.md (97%) rename {dev/reference => reference}/sql/functions-and-operators/bit-functions-and-operators.md (100%) rename {dev/reference => reference}/sql/functions-and-operators/cast-functions-and-operators.md (100%) rename {dev/reference => reference}/sql/functions-and-operators/control-flow-functions.md (100%) rename {dev/reference => reference}/sql/functions-and-operators/date-and-time-functions.md (100%) rename {dev/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 {dev/reference => reference}/sql/functions-and-operators/information-functions.md (100%) rename {dev/reference => reference}/sql/functions-and-operators/json-functions.md (100%) rename {dev/reference => reference}/sql/functions-and-operators/miscellaneous-functions.md (100%) rename {dev/reference => reference}/sql/functions-and-operators/numeric-functions-and-operators.md (100%) rename {dev/reference => reference}/sql/functions-and-operators/operators.md (100%) rename {dev/reference => reference}/sql/functions-and-operators/precision-math.md (100%) rename {v3.1/reference => reference}/sql/functions-and-operators/reference.md (82%) rename {dev/reference => reference}/sql/functions-and-operators/string-functions.md (100%) rename {dev/reference => reference}/sql/functions-and-operators/type-conversion.md (100%) rename {dev/reference => reference}/sql/functions-and-operators/window-functions.md (100%) rename {dev/reference => reference}/sql/generated-columns.md (96%) rename {v3.1/reference => reference}/sql/language-structure/comment-syntax.md (95%) rename {dev/reference => reference}/sql/language-structure/expression-syntax.md (100%) rename {dev/reference => reference}/sql/language-structure/keywords-and-reserved-words.md (97%) rename {dev/reference => reference}/sql/language-structure/literal-values.md (100%) rename {dev/reference => reference}/sql/language-structure/schema-object-names.md (100%) rename {dev/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.1/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 {dev/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.1/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 {dev/reference => reference}/sql/statements/prepare.md (82%) 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 {dev/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 {dev/reference => reference}/supported-clients.md (100%) rename {v3.1/reference => reference}/system-databases/information-schema.md (99%) rename {dev/reference => reference}/system-databases/mysql.md (100%) rename {v3.1/reference => reference}/tidb-binlog/binlog-slave-client.md (100%) rename {v3.1/reference => reference}/tidb-binlog/deploy.md (98%) rename {v3.1/reference => reference}/tidb-binlog/faq.md (98%) rename {v2.1/reference => reference}/tidb-binlog/glossary.md (100%) rename {v3.1/reference => reference}/tidb-binlog/maintain.md (100%) rename {v3.1/reference => reference}/tidb-binlog/monitor.md (100%) rename {v3.1/reference => reference}/tidb-binlog/overview.md (85%) rename {v3.1/reference => reference}/tidb-binlog/relay-log.md (100%) rename {v3.1/reference => reference}/tidb-binlog/reparo.md (100%) rename {v3.1/reference => reference}/tidb-binlog/tidb-binlog-kafka.md (100%) rename {v3.1/reference => reference}/tidb-binlog/tidb-binlog-local.md (99%) rename {v3.1/reference => reference}/tidb-binlog/troubleshoot/binlog.md (50%) rename {dev/reference => reference}/tidb-binlog/troubleshoot/error-handling.md (75%) rename {v3.1/reference => reference}/tidb-binlog/upgrade.md (84%) rename {v3.1/reference => reference}/tispark.md (98%) rename {v3.1/reference => reference}/tools/br/br.md (96%) rename {v3.1/reference => reference}/tools/br/use-cases.md (93%) rename {dev/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 {dev/reference => reference}/tools/data-migration/configure/overview.md (69%) rename {dev/reference => reference}/tools/data-migration/configure/task-configuration-file-full.md (95%) rename {dev/reference => reference}/tools/data-migration/configure/task-configuration-file.md (90%) rename {dev/reference => reference}/tools/data-migration/deploy.md (92%) rename {dev/reference => reference}/tools/data-migration/dm-portal.md (87%) rename {v3.1/reference => reference}/tools/data-migration/dm-upgrade.md (98%) rename {dev/reference => reference}/tools/data-migration/dm-worker-intro.md (100%) rename {v3.1/reference => reference}/tools/data-migration/faq.md (86%) rename {v3.1/reference => reference}/tools/data-migration/features/manually-handling-sharding-ddl-locks.md (97%) rename {dev/reference => reference}/tools/data-migration/features/overview.md (95%) rename {dev/reference => reference}/tools/data-migration/features/shard-merge.md (96%) rename {dev/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 {v2.1/reference => reference}/tools/data-migration/overview.md (59%) rename {dev/reference => reference}/tools/data-migration/precheck.md (97%) rename {v3.1/reference => reference}/tools/data-migration/query-status.md (98%) rename {dev/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.1/reference => reference}/tools/data-migration/skip-replace-sqls.md (98%) rename {v3.1/reference => reference}/tools/data-migration/table-selector.md (100%) rename {v3.1/reference => reference}/tools/data-migration/troubleshoot/dm.md (74%) rename {dev/reference => reference}/tools/data-migration/troubleshoot/error-handling.md (93%) rename {v2.1/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 {dev/reference => reference}/tools/data-migration/usage-scenarios/shard-merge.md (87%) rename {dev/reference => reference}/tools/data-migration/usage-scenarios/simple-synchronization.md (88%) rename {dev/reference => reference}/tools/download.md (81%) rename {dev/reference => reference}/tools/error-case-handling/lightning-misuse-handling.md (81%) rename {v3.1/reference => reference}/tools/error-case-handling/load-misuse-handling.md (86%) rename {dev/reference => reference}/tools/loader.md (96%) rename {dev/reference => reference}/tools/mydumper.md (96%) rename {v3.1/reference => reference}/tools/pd-control.md (100%) rename {v2.1/reference => reference}/tools/pd-recover.md (100%) rename {dev/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.1/reference => reference}/tools/syncer.md (99%) rename {v3.1/reference => reference}/tools/tidb-control.md (100%) rename {v3.1/reference => reference}/tools/tidb-lightning/checkpoints.md (100%) rename {dev/reference => reference}/tools/tidb-lightning/config.md (97%) rename {dev/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 {dev/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.1/reference => reference}/tools/user-guide.md (70%) rename {v2.1/reference => reference}/transactions/overview.md (91%) rename {v3.0/reference => reference}/transactions/transaction-isolation.md (92%) rename {v3.1/reference => reference}/transactions/transaction-optimistic.md (91%) rename {v3.0/reference => reference}/transactions/transaction-pessimistic.md (100%) rename {dev/releases => releases}/11alpha.md (100%) rename {v2.1/releases => releases}/11beta.md (100%) rename {dev/releases => releases}/2.0.10.md (100%) rename {v3.1/releases => releases}/2.0.11.md (100%) rename {dev/releases => releases}/2.0ga.md (100%) rename {v3.1/releases => releases}/2.1.1.md (100%) rename {dev/releases => releases}/2.1.10.md (100%) rename {dev/releases => releases}/2.1.11.md (100%) rename {dev/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.1/releases => releases}/2.1.18.md (100%) rename {dev/releases => releases}/2.1.19.md (100%) rename {dev/releases => releases}/2.1.2.md (100%) rename {v2.1/releases => releases}/2.1.3.md (100%) rename {v3.1/releases => releases}/2.1.4.md (100%) rename {dev/releases => releases}/2.1.5.md (100%) rename {dev/releases => releases}/2.1.6.md (100%) rename {dev/releases => releases}/2.1.7.md (100%) rename {dev/releases => releases}/2.1.8.md (100%) rename {dev/releases => releases}/2.1.9.md (100%) rename {v3.1/releases => releases}/2.1ga.md (100%) rename {v2.1/releases => releases}/201.md (100%) rename {v2.1/releases => releases}/202.md (100%) rename {v2.1/releases => releases}/203.md (100%) rename {dev/releases => releases}/204.md (100%) rename {v2.1/releases => releases}/205.md (100%) rename {v2.1/releases => releases}/206.md (100%) rename {v2.1/releases => releases}/207.md (100%) rename {v2.1/releases => releases}/208.md (100%) rename {v2.1/releases => releases}/209.md (100%) rename {dev/releases => releases}/21beta.md (100%) rename {dev/releases => releases}/21rc1.md (100%) rename {dev/releases => releases}/21rc2.md (100%) rename {v2.1/releases => releases}/21rc3.md (100%) rename {dev/releases => releases}/21rc4.md (100%) rename {dev/releases => releases}/21rc5.md (98%) rename {v2.1/releases => releases}/2rc1.md (100%) rename {v2.1/releases => releases}/2rc3.md (100%) rename {dev/releases => releases}/2rc4.md (100%) rename {v2.1/releases => releases}/2rc5.md (100%) rename {v2.1/releases => releases}/3.0-ga.md (100%) rename {v3.1/releases => releases}/3.0.0-beta.1.md (100%) rename {v2.1/releases => releases}/3.0.0-rc.1.md (100%) rename {dev/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 (100%) rename {dev/releases => releases}/3.0.9.md (100%) rename {dev/releases => releases}/3.0beta.md (100%) rename {dev/releases => releases}/3.1.0-beta.1.md (100%) rename {dev/releases => releases}/3.1.0-beta.md (100%) rename {dev/releases => releases}/ga.md (100%) rename {dev/releases => releases}/prega.md (100%) rename {dev/releases => releases}/rc1.md (100%) rename {dev/releases => releases}/rc2.md (100%) rename {dev/releases => releases}/rc3.md (100%) rename {dev/releases => releases}/rc4.md (100%) create mode 100644 releases/rn.md rename dev/report-issue.md => report-issue.md (100%) rename v2.1/roadmap.md => roadmap.md (100%) rename dev/support-resources.md => support-resources.md (100%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/deploy/access-tidb.md (100%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/deploy/alibaba-cloud.md (99%) rename {v3.1/tidb-in-kubernetes => tidb-in-kubernetes}/deploy/aws-eks.md (99%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/deploy/gcp-gke.md (100%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/deploy/general-kubernetes.md (87%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/deploy/prerequisites.md (99%) rename {v3.1/tidb-in-kubernetes => tidb-in-kubernetes}/deploy/tidb-operator.md (91%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/faq.md (91%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/get-started/deploy-tidb-from-kubernetes-gke.md (98%) rename {v3.1/tidb-in-kubernetes => tidb-in-kubernetes}/get-started/deploy-tidb-from-kubernetes-kind.md (91%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/get-started/deploy-tidb-from-kubernetes-minikube.md (98%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/initialize-cluster.md (100%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/maintain/auto-failover.md (100%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/maintain/backup-and-restore.md (92%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/maintain/destroy-tidb-cluster.md (100%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/maintain/kubernetes-node.md (99%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/maintain/lightning.md (97%) rename {dev/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.1/tidb-in-kubernetes => tidb-in-kubernetes}/monitor/tidb-in-kubernetes.md (98%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/reference/configuration/backup.md (97%) rename {v3.1/tidb-in-kubernetes => tidb-in-kubernetes}/reference/configuration/storage-class.md (98%) rename {v3.1/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 {dev/tidb-in-kubernetes => tidb-in-kubernetes}/reference/tools/in-kubernetes.md (89%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/reference/tools/tkctl.md (100%) rename {v3.1/tidb-in-kubernetes => tidb-in-kubernetes}/scale-in-kubernetes.md (96%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/tidb-operator-overview.md (51%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/troubleshoot.md (97%) rename {dev/tidb-in-kubernetes => tidb-in-kubernetes}/upgrade/tidb-cluster.md (93%) rename {dev/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/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/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/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/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/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/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.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/204.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/21rc4.md delete mode 100644 v2.1/releases/21rc5.md delete mode 100644 v2.1/releases/2rc4.md delete mode 100644 v2.1/releases/3.0.0-beta.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 delete mode 100755 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-sysbench.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/sysbench-v2.md delete mode 100644 v3.0/benchmark/sysbench-v3.md delete mode 100644 v3.0/benchmark/sysbench-v4.md delete mode 100644 v3.0/benchmark/sysbench.md delete mode 100644 v3.0/benchmark/tpcc.md delete mode 100644 v3.0/benchmark/tpch-v2.md delete mode 100644 v3.0/benchmark/tpch.md delete mode 100644 v3.0/contribute.md delete mode 100644 v3.0/faq/tidb-lightning.md delete mode 100755 v3.0/faq/tidb.md delete mode 100644 v3.0/faq/upgrade.md delete mode 100644 v3.0/glossary.md delete mode 100644 v3.0/how-to/configure/memory-control.md delete mode 100644 v3.0/how-to/configure/time-zone.md delete mode 100644 v3.0/how-to/deploy/data-migration-with-ansible.md delete mode 100644 v3.0/how-to/deploy/data-migration-with-binary.md delete mode 100644 v3.0/how-to/deploy/geographic-redundancy/location-awareness.md delete mode 100644 v3.0/how-to/deploy/geographic-redundancy/overview.md delete mode 100644 v3.0/how-to/deploy/hardware-recommendations.md delete mode 100644 v3.0/how-to/deploy/orchestrated/ansible.md delete mode 100644 v3.0/how-to/deploy/orchestrated/docker.md delete mode 100644 v3.0/how-to/deploy/orchestrated/offline-ansible.md delete mode 100644 v3.0/how-to/get-started/data-migration.md delete mode 100644 v3.0/how-to/get-started/deploy-tidb-from-docker-compose.md delete mode 100644 v3.0/how-to/get-started/explore-sql.md delete mode 100644 v3.0/how-to/get-started/read-historical-data.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/ansible-operations.md delete mode 100644 v3.0/how-to/maintain/backup-and-restore.md delete mode 100644 v3.0/how-to/maintain/identify-abnormal-queries/identify-aborted-queries.md delete mode 100644 v3.0/how-to/maintain/identify-abnormal-queries/identify-slow-queries.md delete mode 100644 v3.0/how-to/migrate/from-mysql-aurora.md delete mode 100644 v3.0/how-to/monitor/monitor-a-cluster.md delete mode 100644 v3.0/how-to/monitor/overview.md delete mode 100644 v3.0/how-to/scale/horizontally.md delete mode 100644 v3.0/how-to/scale/with-ansible.md delete mode 100644 v3.0/how-to/secure/enable-tls-between-components.md delete mode 100644 v3.0/how-to/secure/enable-tls-clients.md delete mode 100644 v3.0/how-to/secure/generate-self-signed-certificates.md delete mode 100644 v3.0/how-to/troubleshoot/cluster-setup.md delete mode 100644 v3.0/how-to/troubleshoot/tidb-lightning.md delete mode 100644 v3.0/how-to/upgrade/from-previous-version.md delete mode 100644 v3.0/key-features.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/java-app.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/configuration/pd-server/configuration.md delete mode 100644 v3.0/reference/configuration/tidb-server/configuration-file.md delete mode 100644 v3.0/reference/configuration/tidb-server/configuration.md delete mode 100644 v3.0/reference/configuration/tidb-server/mysql-variables.md delete mode 100644 v3.0/reference/configuration/tidb-server/tidb-specific-variables.md delete mode 100644 v3.0/reference/configuration/tikv-server/configuration-file.md delete mode 100644 v3.0/reference/configuration/tikv-server/configuration.md delete mode 100644 v3.0/reference/error-codes.md delete mode 100644 v3.0/reference/garbage-collection/configuration.md delete mode 100644 v3.0/reference/garbage-collection/overview.md delete mode 100644 v3.0/reference/key-monitoring-metrics/overview-dashboard.md delete mode 100644 v3.0/reference/key-monitoring-metrics/pd-dashboard.md delete mode 100644 v3.0/reference/key-monitoring-metrics/tidb-dashboard.md delete mode 100644 v3.0/reference/key-monitoring-metrics/tikv-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/optimizer-hints.md delete mode 100644 v3.0/reference/performance/sql-optimizer-overview.md delete mode 100644 v3.0/reference/performance/statement-summary.md delete mode 100644 v3.0/reference/performance/statistics.md delete mode 100644 v3.0/reference/performance/tune-tikv.md delete mode 100644 v3.0/reference/performance/understanding-the-query-execution-plan.md delete mode 100644 v3.0/reference/security/cert-based-authentication.md delete mode 100644 v3.0/reference/security/compatibility.md delete mode 100644 v3.0/reference/security/privilege-system.md delete mode 100644 v3.0/reference/security/role-based-access-control.md delete mode 100644 v3.0/reference/security/user-account-management.md delete mode 100644 v3.0/reference/sql/character-set.md delete mode 100644 v3.0/reference/sql/constraints.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/overview.md delete mode 100644 v3.0/reference/sql/data-types/string.md delete mode 100644 v3.0/reference/sql/functions-and-operators/aggregate-group-by-functions.md delete mode 100644 v3.0/reference/sql/functions-and-operators/bit-functions-and-operators.md delete mode 100644 v3.0/reference/sql/functions-and-operators/cast-functions-and-operators.md delete mode 100644 v3.0/reference/sql/functions-and-operators/control-flow-functions.md delete mode 100644 v3.0/reference/sql/functions-and-operators/date-and-time-functions.md delete mode 100644 v3.0/reference/sql/functions-and-operators/encryption-and-compression-functions.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/information-functions.md delete mode 100644 v3.0/reference/sql/functions-and-operators/json-functions.md delete mode 100644 v3.0/reference/sql/functions-and-operators/miscellaneous-functions.md delete mode 100644 v3.0/reference/sql/functions-and-operators/numeric-functions-and-operators.md delete mode 100644 v3.0/reference/sql/functions-and-operators/operators.md delete mode 100644 v3.0/reference/sql/functions-and-operators/precision-math.md delete mode 100644 v3.0/reference/sql/functions-and-operators/reference.md delete mode 100644 v3.0/reference/sql/functions-and-operators/string-functions.md delete mode 100644 v3.0/reference/sql/functions-and-operators/type-conversion.md delete mode 100644 v3.0/reference/sql/functions-and-operators/window-functions.md delete mode 100644 v3.0/reference/sql/generated-columns.md delete mode 100644 v3.0/reference/sql/language-structure/comment-syntax.md delete mode 100644 v3.0/reference/sql/language-structure/expression-syntax.md delete mode 100644 v3.0/reference/sql/language-structure/keywords-and-reserved-words.md delete mode 100644 v3.0/reference/sql/language-structure/literal-values.md delete mode 100644 v3.0/reference/sql/language-structure/schema-object-names.md delete mode 100644 v3.0/reference/sql/language-structure/user-defined-variables.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/admin.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-table.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/explain.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/prepare.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/select.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/supported-clients.md delete mode 100644 v3.0/reference/system-databases/information-schema.md delete mode 100644 v3.0/reference/system-databases/mysql.md delete mode 100644 v3.0/reference/tidb-binlog/binlog-slave-client.md delete mode 100644 v3.0/reference/tidb-binlog/deploy.md delete mode 100644 v3.0/reference/tidb-binlog/faq.md delete mode 100644 v3.0/reference/tidb-binlog/glossary.md delete mode 100644 v3.0/reference/tidb-binlog/maintain.md delete mode 100644 v3.0/reference/tidb-binlog/monitor.md delete mode 100644 v3.0/reference/tidb-binlog/overview.md delete mode 100644 v3.0/reference/tidb-binlog/relay-log.md delete mode 100644 v3.0/reference/tidb-binlog/reparo.md delete mode 100644 v3.0/reference/tidb-binlog/tidb-binlog-kafka.md delete mode 100644 v3.0/reference/tidb-binlog/tidb-binlog-local.md delete mode 100644 v3.0/reference/tidb-binlog/troubleshoot/binlog.md delete mode 100644 v3.0/reference/tidb-binlog/troubleshoot/error-handling.md delete mode 100644 v3.0/reference/tidb-binlog/upgrade.md delete mode 100644 v3.0/reference/tispark.md delete mode 100644 v3.0/reference/tools/data-migration/cluster-operations.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/overview.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/configure/task-configuration-file.md delete mode 100644 v3.0/reference/tools/data-migration/deploy.md delete mode 100644 v3.0/reference/tools/data-migration/dm-portal.md delete mode 100644 v3.0/reference/tools/data-migration/dm-upgrade.md delete mode 100644 v3.0/reference/tools/data-migration/dm-worker-intro.md delete mode 100644 v3.0/reference/tools/data-migration/faq.md delete mode 100644 v3.0/reference/tools/data-migration/features/manually-handling-sharding-ddl-locks.md delete mode 100644 v3.0/reference/tools/data-migration/features/overview.md delete mode 100644 v3.0/reference/tools/data-migration/features/shard-merge.md delete mode 100644 v3.0/reference/tools/data-migration/from-aurora.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/overview.md delete mode 100644 v3.0/reference/tools/data-migration/precheck.md delete mode 100644 v3.0/reference/tools/data-migration/query-status.md delete mode 100644 v3.0/reference/tools/data-migration/relay-log.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/skip-replace-sqls.md delete mode 100644 v3.0/reference/tools/data-migration/table-selector.md delete mode 100644 v3.0/reference/tools/data-migration/troubleshoot/dm.md delete mode 100644 v3.0/reference/tools/data-migration/troubleshoot/error-handling.md delete mode 100644 v3.0/reference/tools/data-migration/troubleshoot/error-system.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/data-migration/usage-scenarios/shard-merge.md delete mode 100644 v3.0/reference/tools/data-migration/usage-scenarios/simple-synchronization.md delete mode 100644 v3.0/reference/tools/download.md delete mode 100644 v3.0/reference/tools/error-case-handling/lightning-misuse-handling.md delete mode 100644 v3.0/reference/tools/error-case-handling/load-misuse-handling.md delete mode 100644 v3.0/reference/tools/loader.md delete mode 100644 v3.0/reference/tools/mydumper.md delete mode 100644 v3.0/reference/tools/pd-control.md delete mode 100644 v3.0/reference/tools/pd-recover.md delete mode 100644 v3.0/reference/tools/sync-diff-inspector/overview.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/syncer.md delete mode 100644 v3.0/reference/tools/tidb-control.md delete mode 100644 v3.0/reference/tools/tidb-lightning/checkpoints.md delete mode 100644 v3.0/reference/tools/tidb-lightning/config.md delete mode 100644 v3.0/reference/tools/tidb-lightning/csv.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/table-filter.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/tools/user-guide.md delete mode 100644 v3.0/reference/transactions/overview.md delete mode 100644 v3.0/reference/transactions/transaction-optimistic.md delete mode 100644 v3.0/releases/11alpha.md delete mode 100644 v3.0/releases/11beta.md delete mode 100644 v3.0/releases/2.0.10.md delete mode 100644 v3.0/releases/2.0.11.md delete mode 100644 v3.0/releases/2.0ga.md delete mode 100644 v3.0/releases/2.1.1.md delete mode 100644 v3.0/releases/2.1.10.md delete mode 100644 v3.0/releases/2.1.11.md delete mode 100644 v3.0/releases/2.1.12.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.18.md delete mode 100644 v3.0/releases/2.1.19.md delete mode 100644 v3.0/releases/2.1.2.md delete mode 100644 v3.0/releases/2.1.3.md delete mode 100644 v3.0/releases/2.1.4.md delete mode 100644 v3.0/releases/2.1.5.md delete mode 100644 v3.0/releases/2.1.6.md delete mode 100644 v3.0/releases/2.1.7.md delete mode 100644 v3.0/releases/2.1.8.md delete mode 100644 v3.0/releases/2.1.9.md delete mode 100644 v3.0/releases/2.1ga.md delete mode 100644 v3.0/releases/201.md delete mode 100644 v3.0/releases/202.md delete mode 100644 v3.0/releases/203.md delete mode 100644 v3.0/releases/204.md delete mode 100644 v3.0/releases/205.md delete mode 100644 v3.0/releases/206.md delete mode 100644 v3.0/releases/207.md delete mode 100644 v3.0/releases/208.md delete mode 100644 v3.0/releases/209.md delete mode 100644 v3.0/releases/21beta.md delete mode 100644 v3.0/releases/21rc1.md delete mode 100644 v3.0/releases/21rc2.md delete mode 100644 v3.0/releases/21rc3.md delete mode 100644 v3.0/releases/21rc4.md delete mode 100644 v3.0/releases/21rc5.md delete mode 100644 v3.0/releases/2rc1.md delete mode 100644 v3.0/releases/2rc3.md delete mode 100644 v3.0/releases/2rc4.md delete mode 100644 v3.0/releases/2rc5.md delete mode 100644 v3.0/releases/3.0-ga.md delete mode 100644 v3.0/releases/3.0.0-beta.1.md delete mode 100644 v3.0/releases/3.0.0-rc.1.md delete mode 100644 v3.0/releases/3.0.0-rc.2.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/3.0beta.md delete mode 100644 v3.0/releases/ga.md delete mode 100644 v3.0/releases/prega.md delete mode 100644 v3.0/releases/rc1.md delete mode 100644 v3.0/releases/rc2.md delete mode 100644 v3.0/releases/rc3.md delete mode 100644 v3.0/releases/rc4.md delete mode 100644 v3.0/releases/rn.md delete mode 100644 v3.0/report-issue.md delete mode 100644 v3.0/roadmap.md delete mode 100644 v3.0/support-resources.md delete mode 100644 v3.0/tidb-in-kubernetes/deploy/access-tidb.md delete mode 100644 v3.0/tidb-in-kubernetes/deploy/alibaba-cloud.md delete mode 100644 v3.0/tidb-in-kubernetes/deploy/aws-eks.md delete mode 100644 v3.0/tidb-in-kubernetes/deploy/gcp-gke.md delete mode 100644 v3.0/tidb-in-kubernetes/deploy/general-kubernetes.md delete mode 100644 v3.0/tidb-in-kubernetes/deploy/prerequisites.md delete mode 100644 v3.0/tidb-in-kubernetes/deploy/tidb-operator.md delete mode 100644 v3.0/tidb-in-kubernetes/faq.md delete mode 100644 v3.0/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-gke.md delete mode 100644 v3.0/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-kind.md delete mode 100644 v3.0/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-minikube.md delete mode 100644 v3.0/tidb-in-kubernetes/initialize-cluster.md delete mode 100644 v3.0/tidb-in-kubernetes/maintain/auto-failover.md delete mode 100644 v3.0/tidb-in-kubernetes/maintain/backup-and-restore.md delete mode 100644 v3.0/tidb-in-kubernetes/maintain/destroy-tidb-cluster.md delete mode 100644 v3.0/tidb-in-kubernetes/maintain/kubernetes-node.md delete mode 100644 v3.0/tidb-in-kubernetes/maintain/lightning.md delete mode 100644 v3.0/tidb-in-kubernetes/maintain/log-collecting.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/monitor/tidb-in-kubernetes.md delete mode 100644 v3.0/tidb-in-kubernetes/reference/configuration/backup.md delete mode 100644 v3.0/tidb-in-kubernetes/reference/configuration/storage-class.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.0/tidb-in-kubernetes/reference/tools/in-kubernetes.md delete mode 100644 v3.0/tidb-in-kubernetes/reference/tools/tkctl.md delete mode 100644 v3.0/tidb-in-kubernetes/scale-in-kubernetes.md delete mode 100644 v3.0/tidb-in-kubernetes/tidb-operator-overview.md delete mode 100644 v3.0/tidb-in-kubernetes/troubleshoot.md delete mode 100644 v3.0/tidb-in-kubernetes/upgrade/tidb-cluster.md delete mode 100644 v3.0/tidb-in-kubernetes/upgrade/tidb-operator.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/contribute.md delete mode 100644 v3.1/faq/upgrade.md delete mode 100644 v3.1/glossary.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/docker.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/identify-abnormal-queries/identify-aborted-queries.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-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/key-features.md delete mode 100644 v3.1/overview.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/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/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/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/sql-optimizer-overview.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/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/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/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/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/mysql.md delete mode 100644 v3.1/reference/tidb-binlog/glossary.md delete mode 100644 v3.1/reference/tidb-binlog/troubleshoot/error-handling.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-worker-intro.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/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/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/loader.md delete mode 100644 v3.1/reference/tools/mydumper.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/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/transactions/overview.md delete mode 100644 v3.1/reference/transactions/transaction-isolation.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.0ga.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.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.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/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-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/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/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-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/reference/configuration/backup.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/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..9cef63ad533c --- /dev/null +++ b/TOC.md @@ -0,0 +1,489 @@ +# 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) + + 备份与恢复 + - [使用 Mydumper/TiDB Lightning 进行备份与恢复](/how-to/maintain/backup-and-restore/mydumper-lightning.md) + - [使用 BR 进行备份与恢复](/reference/tools/br/br.md) + - [BR 备份与恢复场景示例](/reference/tools/br/use-cases.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.1](/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) + - [Follower Read](/reference/performance/follower-read.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.1 + - [3.1.0-beta.1](/releases/3.1.0-beta.1.md) + - [3.1.0-beta](/releases/3.1.0-beta.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/dev/benchmark/how-to-run-sysbench.md b/benchmark/how-to-run-sysbench.md similarity index 95% rename from dev/benchmark/how-to-run-sysbench.md rename to benchmark/how-to-run-sysbench.md index faee8da77632..d6b7bab5934b 100644 --- a/dev/benchmark/how-to-run-sysbench.md +++ b/benchmark/how-to-run-sysbench.md @@ -9,9 +9,9 @@ category: benchmark ## 测试环境 -- [硬件要求](/dev/how-to/deploy/hardware-recommendations.md) +- [硬件要求](/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 部署文档](/how-to/deploy/orchestrated/ansible.md)部署 TiDB 集群。在 3 台服务器的条件下，建议每台机器部署 1 个 TiDB，1 个 PD，和 1 个 TiKV 实例。关于磁盘，以 32 张表、每张表 10M 行数据为例，建议 TiKV 的数据目录所在的磁盘空间大于 512 GB。 对于单个 TiDB 的并发连接数，建议控制在 500 以内，如需增加整个系统的并发压力，可以增加 TiDB 实例，具体增加的 TiDB 个数视测试压力而定。 IDC 机器： @@ -86,7 +86,7 @@ sync-log = false capacity = "30GB" ``` -更详细的 TiKV 参数调优请参考 [TiKV 性能参数调优](/dev/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/dev/benchmark/sysbench-v2.md b/benchmark/sysbench-v2.md similarity index 100% rename from dev/benchmark/sysbench-v2.md rename to benchmark/sysbench-v2.md diff --git a/dev/benchmark/sysbench-v3.md b/benchmark/sysbench-v3.md similarity index 100% rename from dev/benchmark/sysbench-v3.md rename to benchmark/sysbench-v3.md diff --git a/dev/benchmark/sysbench-v4.md b/benchmark/sysbench-v4.md similarity index 100% rename from dev/benchmark/sysbench-v4.md rename to benchmark/sysbench-v4.md diff --git a/dev/benchmark/sysbench.md b/benchmark/sysbench.md similarity index 100% rename from dev/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/dev/benchmark/tpch-v2.md b/benchmark/tpch-v2.md similarity index 100% rename from dev/benchmark/tpch-v2.md rename to benchmark/tpch-v2.md diff --git a/v3.1/benchmark/tpch.md b/benchmark/tpch.md similarity index 100% rename from v3.1/benchmark/tpch.md rename to benchmark/tpch.md diff --git a/dev/contribute.md b/contribute.md similarity index 100% rename from dev/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/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/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/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/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/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/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/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/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/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/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/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/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/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/statement-summary.md b/dev/reference/performance/statement-summary.md deleted file mode 100644 index 4dec2a67f211..000000000000 --- a/dev/reference/performance/statement-summary.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -title: Statement Summary Tables -category: reference ---- - -# Statement Summary Tables - -针对 SQL 性能相关的问题，MySQL 在 `performance_schema` 提供了 [statement summary tables](https://dev.mysql.com/doc/refman/5.6/en/statement-summary-tables.html)，用来监控和统计 SQL。例如其中的一张表 `events_statements_summary_by_digest`，提供了丰富的字段，包括延迟、执行次数、扫描行数、全表扫描次数等，有助于用户定位 SQL 问题。 - -为此，从 3.0.4 版本开始，TiDB 也提供系统表 `events_statements_summary_by_digest`，从 3.0.8 开始提供系统表 `events_statements_summary_by_digest_history`。本文将详细介绍这两张表，以及如何利用它们来排查 SQL 性能问题。 - -## `events_statements_summary_by_digest` - -`events_statements_summary_by_digest` 是 `performance_schema` 里的一张系统表，它把 SQL 按 SQL digest 和 plan digest 分组，统计每一组的 SQL 信息。 - -此处的 SQL digest 与 slow log 里的 SQL digest 一样，是把 SQL 规一化后算出的唯一标识符。SQL 的规一化会忽略常量、空白符、大小写的差别。即语法一致的 SQL 语句，其 digest 也相同。 - -例如： - -```sql -SELECT * FROM employee WHERE id IN (1, 2, 3) AND salary BETWEEN 1000 AND 2000; -select * from EMPLOYEE where ID in (4, 5) and SALARY between 3000 and 4000; -``` - -规一化后都是： - -```sql -select * from employee where id in (...) and salary between ? and ?; -``` - -此处的 plan digest 是把执行计划规一化后算出的唯一标识符。执行计划的规一化会忽略常量的差别。由于相同的 SQL 可能产生不同的执行计划，所以可能分到多个组，同一个组内的执行计划是相同的。 - -`events_statements_summary_by_digest` 用于保存 SQL 监控指标聚合后的结果。一般来说，每一项监控指标都包含平均值和最大值。例如执行延时对应 `AVG_LATENCY` 和 `MAX_LATENCY` 两个字段，分别是平均延时和最大延时。 - -为了监控指标的即时性，`events_statements_summary_by_digest` 里的数据定期被清空，只展现最近一段时间内的聚合结果。清空周期由系统变量 `tidb_stmt_summary_refresh_interval` 设置。如果刚好在清空之后进行查询，显示的数据可能很少。 - -因为 TiDB 中的很多概念不同于 MySQL，所以 TiDB 中 `events_statements_summary_by_digest` 的表结构与 MySQL 中的有很大区别。 - -以下为查询 `events_statements_summary_by_digest` 的部分结果： - -``` - SUMMARY_BEGIN_TIME: 2020-01-02 11:00:00 - SUMMARY_END_TIME: 2020-01-02 11:30:00 - STMT_TYPE: select - SCHEMA_NAME: test - DIGEST: 0611cc2fe792f8c146cc97d39b31d9562014cf15f8d41f23a4938ca341f54182 - DIGEST_TEXT: select * from employee where id = ? - TABLE_NAMES: test.employee - INDEX_NAMES: NULL - SAMPLE_USER: root - EXEC_COUNT: 3 - SUM_LATENCY: 1035161 - MAX_LATENCY: 399594 - MIN_LATENCY: 301353 - AVG_LATENCY: 345053 - AVG_PARSE_LATENCY: 57000 - MAX_PARSE_LATENCY: 57000 - AVG_COMPILE_LATENCY: 175458 - MAX_COMPILE_LATENCY: 175458 - ........... - AVG_MEM: 103 - MAX_MEM: 103 - AVG_AFFECTED_ROWS: 0 - FIRST_SEEN: 2020-01-02 11:12:54 - LAST_SEEN: 2020-01-02 11:25:24 - QUERY_SAMPLE_TEXT: select * from employee where id=3100 - PREV_SAMPLE_TEXT: - PLAN_DIGEST: f415b8d52640b535b9b12a9c148a8630d2c6d59e419aad29397842e32e8e5de3 - PLAN: Point_Get_1 root 1 table:employee, handle:3100 -``` - -> **注意：** -> -> 在 TiDB 中，statement summary tables 中字段的时间单位是纳秒 (ns)，而 MySQL 中的时间单位是皮秒 (ps)。 - -### 表的字段介绍 - -SQL 的基础信息： - -- `STMT_TYPE`：SQL 语句的类型 -- `SCHEMA_NAME`：执行这类 SQL 的当前 schema -- `DIGEST`：这类 SQL 的 digest -- `DIGEST_TEXT`：规一化后的 SQL -- `QUERY_SAMPLE_TEXT`：这类 SQL 的原 SQL 语句，多条语句只取其中一条 -- `TABLE_NAMES`：SQL 中涉及的所有表，多张表用 `,` 分隔 -- `INDEX_NAMES`：SQL 中使用的索引名，多个索引用 `,` 分隔 -- `SAMPLE_USER`：执行这类 SQL 的用户名，多个用户名只取其中一个 -- `PLAN_DIGEST`：执行计划的 digest -- `PLAN`：原执行计划，多条语句只取其中一条的执行计划 - -执行时间相关的信息： - -- `SUMMARY_BEGIN_TIME`：当前统计的时间段的开始时间 -- `SUMMARY_END_TIME`：当前统计的时间段的结束时间 -- `FIRST_SEEN`：这类 SQL 的首次出现时间 -- `LAST_SEEN`：这类 SQL 的最后一次出现时间 - -在 TiDB server 上的执行数据： - -- `EXEC_COUNT`：这类 SQL 的总执行次数 -- `SUM_LATENCY`：这类 SQL 的总延时 -- `MAX_LATENCY`：这类 SQL 的最大延时 -- `MIN_LATENCY`：这类 SQL 的最小延时 -- `AVG_LATENCY`：这类 SQL 的平均延时 -- `AVG_PARSE_LATENCY`：解析器的平均延时 -- `MAX_PARSE_LATENCY`：解析器的最大延时 -- `AVG_COMPILE_LATENCY`：优化器的平均延时 -- `MAX_COMPILE_LATENCY`：优化器的最大延时 -- `AVG_MEM`：使用的平均内存，单位 byte -- `MAX_MEM`：使用的最大内存，单位 byte - -和 TiKV Coprocessor Task 相关的字段： - -- `COP_TASK_NUM`：每条 SQL 发送的 Coprocessor 请求数量 -- `AVG_COP_PROCESS_TIME`：cop-task 的平均处理时间 -- `MAX_COP_PROCESS_TIME`：cop-task 的最大处理时间 -- `MAX_COP_PROCESS_ADDRESS`：执行时间最长的 cop-task 所在地址 -- `AVG_COP_WAIT_TIME`：cop-task 的平均等待时间 -- `MAX_COP_WAIT_TIME`：cop-task 的最大等待时间 -- `MAX_COP_WAIT_ADDRESS`：等待时间最长的 cop-task 所在地址 -- `AVG_PROCESS_TIME`：SQL 在 TiKV 的平均处理时间 -- `MAX_PROCESS_TIME`：SQL 在 TiKV 的最大处理时间 -- `AVG_WAIT_TIME`：SQL 在 TiKV 的平均等待时间 -- `MAX_WAIT_TIME`：SQL 在 TiKV 的最大等待时间 -- `AVG_BACKOFF_TIME`：SQL 遇到需要重试的错误时在重试前的平均等待时间 -- `MAX_BACKOFF_TIME`：SQL 遇到需要重试的错误时在重试前的最大等待时间 -- `AVG_TOTAL_KEYS`：Coprocessor 扫过的 key 的平均数量 -- `MAX_TOTAL_KEYS`：Coprocessor 扫过的 key 的最大数量 -- `AVG_PROCESSED_KEYS`：Coprocessor 处理的 key 的平均数量。相比 `avg_total_keys`，`avg_processed_keys` 不包含 MVCC 的旧版本。如果 `avg_total_keys` 和 `avg_processed_keys` 相差很大，说明旧版本比较多 -- `MAX_PROCESSED_KEYS`：Coprocessor 处理的 key 的最大数量 - -和事务相关的字段： - -- `AVG_PREWRITE_TIME`：prewrite 阶段消耗的平均时间 -- `MAX_PREWRITE_TIME` prewrite 阶段消耗的最大时间 -- `AVG_COMMIT_TIME`：commit 阶段消耗的平均时间 -- `MAX_COMMIT_TIME`：commit 阶段消耗的最大时间 -- `AVG_GET_COMMIT_TS_TIME`：获取 commit_ts 的平均时间 -- `MAX_GET_COMMIT_TS_TIME`：获取 commit_ts 的最大时间 -- `AVG_COMMIT_BACKOFF_TIME`：commit 时遇到需要重试的错误时在重试前的平均等待时间 -- `MAX_COMMIT_BACKOFF_TIME`：commit 时遇到需要重试的错误时在重试前的最大等待时间 -- `AVG_RESOLVE_LOCK_TIME`：解决事务的锁冲突的平均时间 -- `MAX_RESOLVE_LOCK_TIME`：解决事务的锁冲突的最大时间 -- `AVG_LOCAL_LATCH_WAIT_TIME`：本地事务等待的平均时间 -- `MAX_LOCAL_LATCH_WAIT_TIME`：本地事务等待的最大时间 -- `AVG_WRITE_KEYS`：写入 key 的平均数量 -- `MAX_WRITE_KEYS`：写入 key 的最大数量 -- `AVG_WRITE_SIZE`：写入的平均数据量，单位 byte -- `MAX_WRITE_SIZE`：写入的最大数据量，单位 byte -- `AVG_PREWRITE_REGIONS`：prewrite 涉及的平均 Region 数量 -- `MAX_PREWRITE_REGIONS`：prewrite 涉及的最大 Region 数量 -- `AVG_TXN_RETRY`：事务平均重试次数 -- `MAX_TXN_RETRY`：事务最大重试次数 -- `SUM_BACKOFF_TIMES`：这类 SQL 遇到需要重试的错误后的总重试次数 -- `BACKOFF_TYPES`：遇到需要重试的错误时的所有错误类型及每种类型重试的次数，格式为 `类型:次数`。如有多种错误则用 `,` 分隔，例如 `txnLock:2,pdRPC:1` -- `AVG_AFFECTED_ROWS`：平均影响行数 -- `PREV_SAMPLE_TEXT`：当 SQL 是 `COMMIT` 时，该字段为 `COMMIT` 的前一条语句；否则该字段为空字符串。当 SQL 是 `COMMIT` 时，按 digest 和 `prev_sample_text` 一起分组，即不同 `prev_sample_text` 的 `COMMIT` 也会分到不同的行 - -## `events_statements_summary_by_digest_history` - -`events_statements_summary_by_digest_history` 的表结构与 `events_statements_summary_by_digest` 完全相同，用于保存历史时间段的数据。通过历史数据，可以排查过去出现的异常，也可以对比不同时间的监控指标。 - -字段 `SUMMARY_BEGIN_TIME` 和 `SUMMARY_END_TIME` 代表历史时间段的开始时间和结束时间。 - -## 排查示例 - -下面用两个示例问题演示如何利用 statement summary 来排查。 - -### SQL 延迟比较大，是不是服务端的问题？ - -例如客户端显示 employee 表的点查比较慢，那么可以按 SQL 文本来模糊查询： - -```sql -SELECT avg_latency, exec_count, query_sample_text - FROM performance_schema.events_statements_summary_by_digest - WHERE digest_text LIKE 'select * from employee%'; -``` - -结果如下，`avg_latency` 是 1 ms 和 0.3 ms，在正常范围，所以可以判定不是服务端的问题，继而排查客户端或网络问题。 - -``` -+-------------+------------+------------------------------------------+ -| avg_latency | exec_count | query_sample_text | -+-------------+------------+------------------------------------------+ -| 1042040 | 2 | select * from employee where name='eric' | -| 345053 | 3 | select * from employee where id=3100 | -+-------------+------------+------------------------------------------+ -2 rows in set (0.00 sec) -``` - -### 哪类 SQL 的总耗时最高？ - -假如上午 10:00 到 10:30 的 QPS 明显下降，可以从历史表中找出当时耗时最高的三类 SQL： - -```sql -SELECT sum_latency, avg_latency, exec_count, query_sample_text - FROM performance_schema.events_statements_summary_by_digest_history - WHERE summary_begin_time='2020-01-02 10:00:00' - ORDER BY sum_latency DESC LIMIT 3; -``` - -结果显示以下三类 SQL 的总延迟最高，所以这些 SQL 需要重点优化。 - -``` -+-------------+-------------+------------+-----------------------------------------------------------------------+ -| sum_latency | avg_latency | exec_count | query_sample_text | -+-------------+-------------+------------+-----------------------------------------------------------------------+ -| 7855660 | 1122237 | 7 | select avg(salary) from employee where company_id=2013 | -| 7241960 | 1448392 | 5 | select * from employee join company on employee.company_id=company.id | -| 2084081 | 1042040 | 2 | select * from employee where name='eric' | -+-------------+-------------+------------+-----------------------------------------------------------------------+ -3 rows in set (0.00 sec) -``` - -## 参数配置 - -statement summary 功能默认关闭，通过设置系统变量打开，例如： - -```sql -set global tidb_enable_stmt_summary = true; -``` - -statement summary 关闭后，系统表里的数据会被清空，下次打开后重新统计。经测试，打开后对性能几乎没有影响。 - -还有两个控制 statement summary 的系统变量： - -- `tidb_stmt_summary_refresh_interval`：`events_statements_summary_by_digest` 的清空周期，单位是秒 (s)，默认值是 `1800`。 -- `tidb_stmt_summary_history_size`：`events_statements_summary_by_digest_history` 保存每种 SQL 的历史的数量，默认值是 `24`。 - -statement summary 配置示例如下： - -```sql -set global tidb_stmt_summary_refresh_interval = 1800; -set global tidb_stmt_summary_history_size = 24; -``` - -以上配置生效后，`events_statements_summary_by_digest` 每 30 分钟清空一次，`events_statements_summary_by_digest_history` 保存最近 12 小时的历史数据。 - -以上两个系统变量都有 global 和 session 两种作用域，它们的生效方式与其他系统变量不一样： - -- 设置 global 变量后整个集群立即生效 -- 设置 session 变量后当前 TiDB server 立即生效，这对于调试单个 TiDB server 比较有用 -- 优先读 session 变量，没有设置过 session 变量才会读 global 变量 -- 把 session 变量设为空字符串，将会重新读 global 变量 - -由于 statement summary tables 是内存表，为了防止内存问题，需要限制保存的 SQL 条数和 SQL 的最大显示长度。这两个参数都在 config.toml 的 `[stmt-summary]` 类别下配置： - -- 通过 `max-stmt-count` 更改保存的 SQL 种类数量，默认 200 条。当 SQL 种类超过 `max-stmt-count` 时，会移除最近没有使用的 SQL。 -- 通过 `max-sql-length` 更改 `DIGEST_TEXT` 和 `QUERY_SAMPLE_TEXT` 的最大显示长度，默认是 4096。 - -> **注意：** -> -> `tidb_stmt_summary_history_size`、`max-stmt-count`、`max-sql-length` 这些配置都影响内存占用，建议根据实际情况调整，不宜设置得过大。 - -## 目前的限制 - -Statement summary tables 现在还存在一些限制： - -- 查询 statement summary tables 时，只会显示当前 TiDB server 的 statement summary，而不是整个集群的 statement summary。 -- TiDB server 重启后 statement summary 会丢失。因为 statement summary tables 是内存表，不会持久化数据，所以一旦 server 被重启，statement summary 随之丢失。 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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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 \