- Introduction
- Concepts
- Architecture
- Key Features
- Horizontal Scalability
- MySQL Compatible Syntax
- Replicate from and to MySQL
- Distributed Transactions with Strong Consistency
- Cloud Native Architecture
- Minimize ETL with HTAP
- Fault Tolerance & Recovery with Raft
- Automatic Rebalancing
- Deployment and Orchestration with Ansible, Kubernetes, Docker
- JSON Support
- Spark Integration
- Read Historical Data Without Restoring from Backup
- Fast Import and Restore of Data
- Hybrid of Column and Row Storage
- SQL Plan Management
- Open Source
- Online Schema Changes
- How-to
- Get Started
- Deploy
- Hardware Recommendations
- From Binary Tarball
- Orchestrated Deployment
- Geographic Redundancy
- Data Migration with Ansible
- Configure
- Secure
- Transport Layer Security (TLS)
- Generate Self-signed Certificates
- Monitor
- Migrate
- Maintain
- Scale
- Upgrade
- Troubleshoot
- Reference
- SQL
- MySQL Compatibility
- SQL Language Structure
- Data Types
- Functions and Operators
- Function and Operator Reference
- Type Conversion in Expression Evaluation
- Operators
- Control Flow Functions
- String Functions
- Numeric Functions and Operators
- Date and Time Functions
- Bit Functions and Operators
- Cast Functions and Operators
- Encryption and Compression Functions
- Information Functions
- JSON Functions
- Aggregate (GROUP BY) Functions
- Miscellaneous Functions
- Precision Math
- SQL Statements
ADD COLUMN
ADD INDEX
ADMIN
ADMIN CANCEL DDL
ADMIN CHECKSUM TABLE
ADMIN CHECK [TABLE|INDEX]
ADMIN SHOW DDL [JOBS|QUERIES]
ALTER DATABASE
ALTER TABLE
ALTER USER
ANALYZE TABLE
BEGIN
CHANGE COLUMN
COMMIT
CREATE DATABASE
CREATE INDEX
CREATE TABLE LIKE
CREATE TABLE
CREATE USER
DEALLOCATE
DELETE
DESC
DESCRIBE
DO
DROP COLUMN
DROP DATABASE
DROP INDEX
DROP TABLE
DROP USER
EXECUTE
EXPLAIN ANALYZE
EXPLAIN
FLUSH PRIVILEGES
FLUSH STATUS
FLUSH TABLES
GRANT <privileges>
INSERT
KILL [TIDB]
LOAD DATA
LOAD STATS
MODIFY COLUMN
PREPARE
RENAME INDEX
RENAME TABLE
REPLACE
REVOKE <privileges>
ROLLBACK
SELECT
SET [NAMES|CHARACTER SET]
SET PASSWORD
SET TRANSACTION
SET [GLOBAL|SESSION] <variable>
SHOW CHARACTER SET
SHOW COLLATION
SHOW [FULL] COLUMNS FROM
SHOW CREATE TABLE
SHOW DATABASES
SHOW ENGINES
SHOW ERRORS
SHOW [FULL] FIELDS FROM
SHOW GRANTS
SHOW INDEXES [FROM|IN]
SHOW INDEX [FROM|IN]
SHOW KEYS [FROM|IN]
SHOW PRIVILEGES
SHOW [FULL] PROCESSSLIST
SHOW SCHEMAS
SHOW STATUS
SHOW [FULL] TABLES
SHOW TABLE STATUS
SHOW [GLOBAL|SESSION] VARIABLES
SHOW WARNINGS
START TRANSACTION
TRACE
TRUNCATE
UPDATE
USE
- Constraints
- Generated Columns
- Character Set
- Configuration
- Security
- Transactions
- System Databases
- Errors Codes
- Supported Client Drivers
- Garbage Collection (GC)
- Performance
- Key Monitoring Metrics
- Alert Rules
- Best Practices
- TiSpark
- TiDB Binlog
- Tools
- Overview
- Use Cases
- Download
- Mydumper
- Syncer
- Loader
- TiDB Data Migration
- TiDB Lightning
- sync-diff-inspector
- PD Control
- PD Recover
- TiKV Control
- TiDB Control
- FAQs
- Support
- Contribute
- Releases
- All Releases
- v2.1
- v2.0
- v1.0
- Glossary
You are viewing the documentation of an older version of the TiDB database (TiDB v2.1).
TiDB 2.1 Upgrade Guide
This document describes how to upgrade from TiDB 2.0 to 2.1 versions, or from an earlier 2.1 version to later 2.1 versions.
TiDB 2.1 is not compatible with the Kafka version of TiDB Binlog. If your current TiDB cluster has already been using the Kafka version of TiDB Binlog, you need to upgrade it to the cluster version of TiDB Binlog.
For details about using TiDB Ansible to perform a rolling update to components, see Perform a rolling update to TiDB cluster components.
Upgrade caveat
TiDB 2.1 does not support downgrading to v2.0.x or earlier versions due to the adoption of the new storage engine.
Parallel DDL is supported in TiDB 2.1 and later versions. Therefore, for clusters with a TiDB version earlier than 2.0.1, rolling update to TiDB 2.1 is not supported. To upgrade, you can choose either of the following two options:
- Stop the cluster and upgrade to 2.1 directly.
- Roll update to 2.0.1 or later 2.0.x versions, and then roll update to the 2.1 version.
If you upgrade from TiDB 2.0.6 or earlier to TiDB 2.1, check if there is any ongoing DDL operation, especially the time consuming
Add Index
operation, because the DDL operations slow down the upgrading process. If there is ongoing DDL operation, wait for the DDL operation to finish and then roll update.
Do not execute any DDL statements during the upgrading process, otherwise the undefined behavior error might occur.
Step 1: Install TiDB Ansible and dependencies on the Control Machine
If you have installed TiDB Ansible and its dependencies, you can skip this step.
TiDB Ansible release-2.1 depends on Ansible 2.4.2 ~ 2.7.11 (2.4.2 ≦ ansible < 2.7.11
) and the Python modules of jinja2 ≧ 2.9.6
and jmespath ≧ 0.9.0
.
To make it easy to manage dependencies, use pip
to install TiDB Ansible and its dependencies. For details, see Install TiDB Ansible and its dependencies on the Control Machine. For offline environment, see Install TiDB Ansible and its dependencies offline on the Control Machine.
After the installation is finished, you can view the version information using the following command:
ansible --version
ansible 2.6.8
pip show jinja2
Name: Jinja2
Version: 2.10
pip show jmespath
Name: jmespath
Version: 0.9.3
- You must install TiDB Ansible and its dependencies following the above procedures.
- Make sure that the Jinja2 version is correct, otherwise an error occurs when you start Grafana.
- Make sure that the jmespath version is correct, otherwise an error occurs when you perform a rolling update to TiKV.
Step 2: Download TiDB Ansible to the Control Machine
Log in to the Control Machine using the
tidb
user account and enter the/home/tidb
directory.Back up the
tidb-ansible
folders of TiDB 2.0 or an earlier 2.1 version using the following command:mv tidb-ansible tidb-ansible-bak
Download the latest tidb-ansible
release-2.1
branch using the following command. The default folder name istidb-ansible
.git clone -b release-2.1 https://github.com/pingcap/tidb-ansible.git
Step 3: Edit the inventory.ini
file and the configuration file
Log in to the Control Machine using the tidb
user account and enter the /home/tidb/tidb-ansible
directory.
Edit the inventory.ini
file
Edit the inventory.ini
file. For IP information, see the /home/tidb/tidb-ansible-bak/inventory.ini
backup file.
Pay special attention to the following variables configuration. For variable meaning, see Description of other variables.
Make sure that
ansible_user
is the normal user. For unified privilege management, remote installation using the root user is no longer supported. The default configuration uses thetidb
user as the SSH remote user and the program running user.## Connection # ssh via normal user ansible_user = tidb
You can refer to How to configure SSH mutual trust and sudo rules on the Control Machine to automatically configure the mutual trust among hosts.
Keep the
process_supervision
variable consistent with that in the previous version. It is recommended to usesystemd
by default.# process supervision, [systemd, supervise] process_supervision = systemd
If you need to modify this variable, see How to modify the supervision method of a process from
supervise
tosystemd
. Before you upgrade, first use the/home/tidb/tidb-ansible-bak/
backup branch to modify the supervision method of a process.
Edit the configuration file of TiDB cluster components
If you have previously customized the configuration file of TiDB cluster components, refer to the backup file to modify the corresponding configuration file in the /home/tidb/tidb-ansible/conf
directory.
Note the following parameter changes:
In the TiKV configuration,
end-point-concurrency
is changed to three parameters:high-concurrency
,normal-concurrency
andlow-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
NoteFor the cluster topology of multiple TiKV instances (processes) on a single machine, you need to modify the three parameters above.
Recommended configuration: the number of TiKV instances * the parameter value = the number of CPU cores * 0.8.
In the TiKV configuration, the
block-cache-size
parameter of different CFs is changed toblock-cache
.storage: block-cache: capacity: "1GB"
NoteFor the cluster topology of multiple TiKV instances (processes) on a single machine, you need to modify the
capacity
parameter.Recommended configuration:
capacity
= MEM_TOTAL * 0.5 / the number of TiKV instances.
Step 4: Download TiDB 2.1 binary to the Control Machine
Make sure that tidb_version = v2.1.x
in the tidb-ansible/inventory.ini
file, and then run the following command to download TiDB 2.1 binary to the Control Machine:
ansible-playbook local_prepare.yml
Step 5: Perform a rolling update to TiDB cluster components
ansible-playbook rolling_update.yml
Step 6: Perform a rolling update to TiDB monitoring components
ansible-playbook rolling_update_monitor.yml
- Upgrade caveat
- Step 1: Install TiDB Ansible and dependencies on the Control Machine
- Step 2: Download TiDB Ansible to the Control Machine
- Step 3: Edit the inventory.ini file and the configuration file
- Step 4: Download TiDB 2.1 binary to the Control Machine
- Step 5: Perform a rolling update to TiDB cluster components
- Step 6: Perform a rolling update to TiDB monitoring components