升级操作步骤
迁移后操作
- 一、系统正常，下架 tidb v3.0
- 二、系统异常，回滚到 tidb v3.0

升级操作步骤：
一、部署 TiDB v4.0
二、停机全备 TiDB v3.0 数据
三、恢复数据到 TiDB v4.0
四、数据校验
五、配置 TiDB v4.0 同步至 TiDB v3.0

迁移后操作
观察系统状态：
一、系统正常
二、系统异常需要回退步骤

升级操作步骤

一、部署 TiDB v4.0

第一步：按照文档检查系统配置
TiDB环境与系统配置检查

第二步：在中控机安装 tiup 组件
使用普通用户登录中控机，以 tidb 用户为例，后续安装 TiUP 及集群管理操作均通过该用户完成：

执行如下命令安装 TiUP 工具：

curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh

按如下步骤设置 TiUP 环境变量：
重新声明全局环境变量：
```
source .bash_profile
```
确认 TiUP 工具是否安装：
```
which tiup
```
安装 TiUP cluster 组件
```
tiup cluster
```
预期输出 “Update successfully!” 字样。
验证当前 TiUP cluster 版本信息。执行如下命令查看 TiUP cluster 组件版本：
```
tiup --binary cluster
```

第三步：编辑初始化配置文件
新建配置文件 topology.yaml
需要打开 binlog 配置
配置文件示例，详细配置实例

# # Global variables are applied to all deployments and used as the default value of
# # the deployments if a specific deployment value is missing.
global:
  user: "tidb"
  ssh_port: 22
  deploy_dir: "/home/tidb-deploy"
  data_dir: "/home/tidb-data"

server_configs:
 tidb:
   log.slow-threshold: 300
   alter-primary-key: true
   binlog.enable: true
   new_collations_enabled_on_first_bootstrap: true
   binlog.ignore-error: true
 tikv:
   readpool.storage.use-unified-pool: false
   readpool.coprocessor.use-unified-pool: true
 pd:
   replication.enable-placement-rules: true
 tiflash:
   logger.level: "info"

pd_servers:
  - host: 192.168.20.200
    name: "pd-1"
    client_port: 2379
    peer_port: 2380
    deploy_dir: "/tidb-deploy/pd-2379"
    data_dir: "/tidb-data/pd-2379"
    log_dir: "/tidb-deploy/pd-2379/log"

tidb_servers:
  - host: 192.168.20.200
    ssh_port: 22
    port: 4000
    status_port: 10080
    deploy_dir: "/tidb-deploy/tidb-4000"
    log_dir: "/tidb-deploy/tidb-4000/log"
    numa_node: "0,1"
    # # The following configs are used to overwrite the `server_configs.tidb` values.
    config:
      log.level: warn
      log.slow-query-file: tidb-slow-overwrited.log

tikv_servers:
  - host: 192.168.20.200
    # ssh_port: 22
    # port: 20160
    # status_port: 20180
    # deploy_dir: "/tidb-deploy/tikv-20160"
    # data_dir: "/tidb-data/tikv-20160"
    # log_dir: "/tidb-deploy/tikv-20160/log"
    # numa_node: "0,1"
    # # The following configs are used to overwrite the `server_configs.tikv` values.
    # config:
    #   server.grpc-concurrency: 4
    #   server.labels: { zone: "zone1", dc: "dc1", host: "host1" }
  - host: 192.168.20.201
  - host: 192.168.20.202

pump_servers:
  - host: 192.168.20.201
    ssh_port: 22
    port: 8250
    deploy_dir: "/tidb-deploy/pump-8249"
    data_dir: "/tidb-data/pump-8249"
    # The following configs are used to overwrite the `server_configs.drainer` values.
    config:
      gc: 7
drainer_servers:
  - host: 192.168.20.202
    port: 8249
    data_dir: "/tidb-data/drainer-8249"
    # If drainer doesn't have a checkpoint, use initial commitTS as the initial checkpoint.
    # Will get a latest timestamp from pd if commit_ts is set to -1 (the default value).
    commit_ts: -1
    deploy_dir: "/tidb-deploy/drainer-8249"
    # The following configs are used to overwrite the `server_configs.drainer` values.
    config:
      syncer.db-type: "tidb"
      syncer.to.host: "10.0.1.12"
      syncer.to.user: "root"
      syncer.to.password: ""
      syncer.to.port: 4000

monitoring_servers:
  - host: 192.168.20.200

grafana_servers:
  - host: 192.168.20.200

alertmanager_servers:
  - host: 192.168.20.200

第四步：执行部署命令

tiup cluster deploy ${cluster-name} v4.0.6 ./topology.yaml

第五步：启动集群

tiup cluster start ${cluster-name}

第六步：暂时关闭 drainer_servers 节点

tiup cluster  stop ${cluster-name} -R drainer

第七步：设置 sql_mode
进入数据库执行

set global  sql_mode = 'NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION' ;

检查节点状态

二、停机全备 TiDB v3.0 数据

第一步：下载 TiDB 官方备份工具包

wget https://download.pingcap.org/tidb-enterprise-tools-nightly-linux-amd64.tar.gz
tar -zxf tidb-enterprise-tools-nightly-linux-amd64.tar.gz

第二步：停止服务，禁止数据库进行写入、更新操作
在数据库中执行 show processlist; 确认没有更新写入操作

show processlist ;

第三步：修改 GC life time

# 查看现在 GC life time
SELECT * FROM mysql.tidb WHERE VARIABLE_NAME = 'tikv_gc_life_time';

# 修改 GC life time
update mysql.tidb set VARIABLE_VALUE = '720h' where VARIABLE_NAME = 'tikv_gc_life_time';

第四步：进行备份

nohup ./mydumper -h 127.0.0.1 -P 4000 -u root -p xxx -t 32 -F 256  --skip-tz-utc -o /var/backup > mydumper.log 2>&1 &

第五步：把备份传输到 TiDB v4.0 的 tidb-server 节点

第六步：恢复之前的 GC life time

update mysql.tidb set VARIABLE_VALUE = '10min' where VARIABLE_NAME = 'tikv_gc_life_time';

在数据更新频繁的场景下，如果将 tikv_gc_life_time 设置得比较大（如数天甚至数月），可能会有一些潜在的问题，如：

磁盘空间占用较多。
大量的历史版本会在一定程度上影响性能，尤其是范围查询（如 select count(*) from t）。

三、恢复数据到 TiDB v4.0

第一步：安装 TiDB 恢复工具
下载解压

wget https://download.pingcap.org/tidb-toolkit-{version}-linux-amd64.tar.gz
# {version} 修改为实际环境的 tidb version

第二步：配置恢复配置文件 tidb-lightning.toml

[lightning]

# 转换数据的并发数，默认为逻辑 CPU 数量，不需要配置。
# 混合部署的情况下可以配置为逻辑 CPU 的 75% 大小。
# region-concurrency =

# 日志
level = "info"
file = "tidb-lightning.log"

[checkpoint]
# 是否启用断点续传。
# 导入数据时，TiDB Lightning 会记录当前表导入的进度。
# 所以即使 Lightning 或其他组件异常退出，在重启时也可以避免重复再导入已完成的数据。
enable = true
# 存储断点的数据库名称。
schema = "tidb_lightning_checkpoint"
# 存储断点的方式。
#  - file：存放在本地文件系统。
#  - mysql：存放在兼容 MySQL 的数据库服务器。
driver = "file"

[tikv-importer]
# backend 设置为 local 模式
backend = "tidb"
on-duplicate = "replace"
# 设置本地临时存储路径
# sorted-kv-dir = "/home/tidb/backup/tmpdir"

[mydumper]
# Mydumper 源数据目录。
data-source-dir = "/tmp/test"
filter = ['edoc2v5.*','!*.rpt_fileoperationcount']
#filter = ['edoc2v5.*']

[tidb]
# 目标集群的信息。tidb-server 的监听地址，填一个即可。
host = "127.0.0.1"
port = 4000
user = "root"
password = ""
# 表架构信息在从 TiDB 的“状态端口”获取。
status-port = 10080

第三步：修改 schema.sql 中的字符排序规则
（注意：需要查看导出的 schema.sql 实际情况进行更改）

sed -i "s/DEFAULT CHARSET=utf8/DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci/g" *schema.sql

第四步：执行恢复命令

nohup ./tidb-lightning --config tidb-lightning.toml > lightning.output 2>&1 &

第五步：手动恢复 edoc2v5.rpt_fileoperationcount 表

四、数据校验

第一步：上传备份校验脚本

第二步：修改脚本连接信息

old_tidb='192.168.0.0'
new_tidb='192.168.0.0'
root_passwd=''

注意：old_tidb 为 tidb v3.0 ，new_tidb 为新导入数据的 tidb v4.0 , 两边的 root 密码需一致

第三步：执行校验脚本

第四步：查看校验结果
如果检查结果两边数据不一致，检查表中数据是否和 sql 文件中是否一致。如果一致则恢复过程没有问题。

五、配置同步，业务恢复

第一步：启动 drainer_servers 节点

tiup cluster start ${cluster-name} -R drainer

第二步：迁移业务窗口到 tidb v4.0 集群，恢复业务

第三步：查看 drainer 服务状态
在数据库中执行

show drainer status ;

如果 State 状态为 online ，则正常

第四步：查看tidb v3.0 是否有新数据写入
**

迁移后操作

一、系统正常，下架 tidb v3.0

第一步：备份 tidb v3.0 数据
操作如同上边「停机全备TiDB v3.0 数据」

第二步：停止 tidb v4.0 drainer_servers 节点

tiup cluster  stop ${cluster-name} -R drainer

第三步：关闭 tidb v3.0 集群**

第四步：评估是否需要关闭 tidb v4.0 binlog 功能
如果需要关闭

tiup cluster edit-config ${cluster-name}

编辑配置文件

server_configs:
  tidb:
    alter-primary-key: true
    binlog.enable: false
    binlog.ignore-error: true
    log.slow-threshold: 300
    new_collations_enabled_on_first_bootstrap: true

将 binlog.enable 设置为 false
reload tidb 集群 tidb-server 节点

tiup cluster reload ${cluster-name} -R tidb

停止 pump 节点

tiup cluster  stop ${cluster-name} -R pump

二、系统异常，回滚到 tidb v3.0

第一步：关闭业务系统

第二步：执行校验脚本，检查结果
数据无异常：检查业务接口日志报错内容。确定错误原因，判断是否需要回滚到 tidb v3.0，如果需要则进行下一步；

数据异常：检查业务接口日志报错内容。手动检查数据，对比 tidb 3.0 以及 tidb v4.0 数据
可能情况 tidb v3.0 缺少数据，判断是同步错误导致问题或无法写入的问题。如果确定 tidb v4.0 数据无异常，判断是否需要备份 tidb v4.0 恢复到 tidb 3.0。如果需要则进行下一步；

第三步：备份 tidb v4.0 以及 tidb v3.0 数据
操作如同上边「停机全备TiDB v3.0 数据」

第四步：恢复 tidb v4.0 备份到 tidb v3.0 环境
【如果数据校验脚本无异常，则可对 tidb v3.0部分数据进行检查，如果无误则可不进行此步骤】
操作如同上边「恢复数据到 TiDB v4.0」

第五步：切换业务窗口到 TiDB v3.0
检查业务运行情况

TiDB v3.0 升级切换 v4.0 操作手册