Tidb 部署

---手动配置 SSH 互信及 sudo 免密码
对于有需求，通过手动配置中控机至目标节点互信的场景，可参考本段。通常推荐使用 TiUP 部署工具会自动
配置 SSH 互信及免密登录，可忽略本段内容。
1. 以 root 用户依次登录到部署目标机器创建 tidb 用户并设置登录密码。
echo Seatrend0991 | passwd --stdin tidb

---2. 执行以下命令，将 tidb ALL=(ALL)NOPASSWD: ALL 添加到文件末尾，即配置好 sudo 免密码。
visudo
tidb ALL=(ALL) NOPASSWD: ALL
3. 以 tidb 用户登录到中控机，执行以下命令。将 10.0.1.1 替换成你的部署目标机器 IP，按提示输入部署
目标机器 tidb 用户密码，执行成功后即创建好 SSH 互信，其他机器同理。新建的 tidb 用户下没有 .ssh
目录，需要执行生成 rsa 密钥的命令来生成 .ssh 目录。如果要在中控机上部署 TiDB 组件，需要为中控
机和中控机自身配置互信。
ssh-keygen -t rsa
ssh-copy-id -i ~/.ssh/id_rsa.pub 15.1.1.51
4. 以 tidb 用户登录中控机，通过 ssh 的方式登录目标机器 IP。如果不需要输入密码并登录成功，即表示
SSH 互信配置成功。
ssh 15.1.1.51


--如果要在 CentOS 7 系统上手动安装 NTP 服务，可执行以下命令：
sudo yum install ntp ntpdate && \
sudo systemctl start ntpd.service && \
sudo systemctl enable ntpd.service

---要永久关闭 swap，可执行以如下命令:
echo "vm.swappiness = 0">> /etc/sysctl.conf
swapoff -a
sysctl -p

--关闭防火墙服务
systemctl stop firewalld.service

--执行以下命令修改 sysctl 参数。
echo "fs.file-max = 1000000">> /etc/sysctl.conf
echo "net.core.somaxconn = 32768">> /etc/sysctl.conf
echo "net.ipv4.tcp_tw_recycle = 0">> /etc/sysctl.conf
echo "net.ipv4.tcp_syncookies = 0">> /etc/sysctl.conf
echo "vm.overcommit_memory = 1">> /etc/sysctl.conf
sysctl -p

--. 执行以下命令配置用户的 limits.conf 文件。
cat << EOF >>/etc/security/limits.conf
tidb soft nofile 1000000
tidb hard nofile 1000000
tidb soft stack 32768
tidb hard stack 32768
EOF

--创建新的 tuned 策略。
mkdir /etc/tuned/balanced-tidb-optimal/
vi /etc/tuned/balanced-tidb-optimal/tuned.conf

[main]
include=balanced
[cpu]
governor=performance
[vm]
transparent_hugepages=never
[disk]
devices_udev_regex=(ID_SERIAL=36c0183915c34921323d598e4253d8a42)
elevator=noop

-- 应用新的 tuned 策略。
tuned-adm profile balanced-tidb-optimal

检查和配置操作系统优化参数

1. 关闭透明大页（即 Transparent Huge Pages，缩写为 THP）。数据库的内存访问模式往往是稀疏的而非连续
的。当高阶内存碎片化比较严重时，分配 THP 页面会出现较高的延迟。
2. 将存储介质的 I/O 调度器设置为 noop。对于高速 SSD 存储介质，内核的 I/O 调度操作会导致性能损失。
将调度器设置为 noop 后，内核不做任何操作，直接将 I/O 请求下发给硬件，以获取更好的性能。同时，
noop 调度器也有较好的普适性。
3. 为调整 CPU 频率的 cpufreq 模块选用 performance 模式。将 CPU 频率固定在其支持的最高运行频率上，不
进行动态调节，可获取最佳的性能。


----方法一： 采用如下步骤检查操作系统的当前配置，并配置系统优化参数：
1. 执行以下命令查看透明大页的开启状态。
cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
注意：
[always] madvise never 表示透明大页处于启用状态，需要关闭。
2. 执行以下命令查看数据目录所在磁盘的 I/O 调度器。假设在 sdb、sdc 两个磁盘上创建了数据目录。

cat /sys/block/sd[bc]/queue/scheduler
noop [deadline] cfq
noop [deadline] cfq
注意：
noop [deadline] cfq 表示磁盘的 I/O 调度器使用 deadline，需要进行修改。

3. 执行以下命令查看磁盘的唯一标识 ID_SERIAL。
udevadm info --name=/dev/sdb | grep ID_SERIAL
E: ID_SERIAL=36d0946606d79f90025f3e09a0c1f9e81
E: ID_SERIAL_SHORT=6d0946606d79f90025f3e09a0c1f9e81
注意：
如果多个磁盘都分配了数据目录，需要多次执行以上命令，记录所有磁盘各自的唯一标识。

4. 执行以下命令查看 cpufreq 模块选用的节能策略。
--创建新的 tuned 策略。
mkdir /etc/tuned/balanced-tidb-optimal/
vi /etc/tuned/balanced-tidb-optimal/tuned.conf

[main]
include=balanced
[cpu]
governor=performance
[vm]
transparent_hugepages=never
[disk]
devices_udev_regex=(ID_SERIAL=36c0183915c34921323d598e4253d8a42)
elevator=noop

include=balanced 表示在现有的 balanced 策略基础上添加操作系统优化配置。

3. 应用新的 tuned 策略。
tuned-adm profile balanced-tidb-optimal

-------------方法二：使用脚本方式。如果已经使用 tuned 方法，请跳过本方法。
1. 执行 grubby 命令查看默认内核版本。
注意：
需安装 grubby 软件包。
grubby --default-kernel
/boot/vmlinuz-3.10.0-957.el7.x86_64
2. 执行 grubby --update-kernel 命令修改内核配置。
grubby --args="transparent_hugepage=never" --update-kernel /boot/vmlinuz
,→ -3.10.0-957.el7.x86_64
注意：
--update-kernel 后需要使用实际的默认内核版本。
3. 执行 grubby --info 命令查看修改后的默认内核配置。
grubby --info /boot/vmlinuz-3.10.0-957.el7.x86_64
注意：
--info 后需要使用实际的默认内核版本。
index=0
kernel=/boot/vmlinuz-3.10.0-957.el7.x86_64
args="ro crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet LANG=en_US.UTF-8 transparent_hugepage=never"
root=/dev/mapper/centos-root
initrd=/boot/initramfs-3.10.0-957.el7.x86_64.img
title=CentOS Linux (3.10.0-957.el7.x86_64) 7 (Core)
4. 修改当前的内核配置立即关闭透明大页。
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
5. 配置 udev 脚本应用 IO 调度器策略。
vi /etc/udev/rules.d/60-tidb-schedulers.rules
ACTION=="add|change", SUBSYSTEM=="block", ENV{ID_SERIAL}=="36d0946606d79f90025f3e09a0c1fc035", ATTR{queue/scheduler}="noop"
ACTION=="add|change", SUBSYSTEM=="block", ENV{ID_SERIAL}=="36d0946606d79f90025f3e09a0c1f9e81", ATTR{queue/scheduler}="noop"
6. 应用 udev 脚本。
udevadm control --reload-rules
udevadm trigger --type=devices --action=change
7. 创建 CPU 节能策略配置服务。
cat >> /etc/systemd/system/cpupower.service << EOF
[Unit]
Description=CPU performance
[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower frequency-set --governor performance
[Install]
WantedBy=multi-user.target
EOF
8. 应用 CPU 节能策略配置服务。
systemctl daemon-reload
systemctl enable cpupower.service
systemctl start cpupower.service
6. 执行以下命令验证透明大页的状态。
cat /sys/kernel/mm/transparent_hugepage/enabled

-------------------------------------------------
--手动配置 SSH 互信及 sudo 免密码
对于有需求，通过手动配置中控机至目标节点互信的场景，可参考本段。通常推荐使用 TiUP 部署工具会自动
配置 SSH 互信及免密登录，可忽略本段内容。
1. 以 root 用户依次登录到部署目标机器创建 tidb 用户并设置登录密码。
useradd tidb && \
passwd tidb

--2. 执行以下命令，将 tidb ALL=(ALL)NOPASSWD: ALL 添加到文件末尾，即配置好 sudo 免密码。
visudo
tidb ALL=(ALL) NOPASSWD: ALL
3. 以 tidb 用户登录到中控机，执行以下命令。将 10.0.1.1 替换成你的部署目标机器 IP，按提示输入部署
目标机器 tidb 用户密码，执行成功后即创建好 SSH 互信，其他机器同理。新建的 tidb 用户下没有 .ssh
目录，需要执行生成 rsa 密钥的命令来生成 .ssh 目录。如果要在中控机上部署 TiDB 组件，需要为中控
机和中控机自身配置互信。
ssh-keygen -t rsa
ssh-copy-id -i ~/.ssh/id_rsa.pub 10.0.1.1
4. 以 tidb 用户登录中控机，通过 ssh 的方式登录目标机器 IP。如果不需要输入密码并登录成功，即表示
SSH 互信配置成功。
ssh 10.0.1.1
[tidb@10.0.1.1 ~]$
5. 以 tidb 用户登录到部署目标机器后，执行以下命令，不需要输入密码并切换到 root 用户，表示 tidb
用户 sudo 免密码配置成功。
sudo -su root
[root@10.0.1.1 tidb]#
3.2.7 安装 numactl 工具
1. 登录到目标节点进行安装（以 CentOS Linux release 7.7.1908 (Core) 为例）
sudo yum -y install numactl

2. 通过 TiUP 的 cluster 执行完 exec 命令
tiup cluster exec --help
Run shell command on host in the tidb cluster
Usage:
cluster exec <cluster-name> [flags]
Flags:
--command string the command run on cluster host (default "ls")
-h, --help help for exec
--sudo use root permissions (default false)
将 tidb-test 集群所有目标主机通过 sudo 权限执行安装命令
tiup cluster exec tidb-test --sudo --command "yum -y install numactl"



cpupower frequency-info --policy
analyzing CPU 0:
current policy: frequency should be within 1.20 GHz and 3.10 GHz.
The governor "powersave" may decide which speed to use within this range.
注意：
The governor "powersave"表示cpufreq的节能策略使用powersave，需要调整为performance
策略。如果是虚拟机或者云主机，则不需要调整，命令输出通常为 Unable to determine current policy。
5. 配置系统优化参数
方法一：使用 tuned（推荐）
1. 执行 tuned-adm list 命令查看当前操作系统的 tuned 策略。
tuned-adm list

Current active profile: balanced 表示当前操作系统的 tuned 策略使用 balanced，建议在当前
策略的基础上添加操作系统优化配置。
2. 创建新的 tuned 策略。
mkdir /etc/tuned/balanced-tidb-optimal/
vi /etc/tuned/balanced-tidb-optimal/tuned.conf




--部署本地测试集群
适用场景：利用本地 Mac 或者单机 Linux 环境快速部署 TiDB 测试集群，体验 TiDB 集群的基本架构，以及
TiDB、TiKV、PD、监控等基础组件的运行。
TiDB 是一个分布式系统。最基础的 TiDB 测试集群通常由 2 个 TiDB 实例、3 个 TiKV 实例、3 个 PD 实例和可选的
TiFlash 实例构成。通过 TiUP Playground，可以快速搭建出上述的一套基础测试集群，步骤如下：
1. 下载并安装 TiUP。
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh

2. 声明全局环境变量。
注意：
TiUP 安装完成后会提示对应 profile 文件的绝对路径。在执行以下 source 命令前，需要
根据 profile 文件的实际位置修改命令。
source .bash_profile
3. 在当前 session 执行以下命令启动集群。
直接执行 tiup playground 命令会运行最新版本的 TiDB 集群，其中 TiDB、TiKV、PD 和 TiFlash 实例各1 个：
tiup playground
也可以指定 TiDB 版本以及各组件实例个数，命令类似于：
tiup playground v5.4.0 --db 2 --pd 3 --kv 3
tiup playground --host 15.1.1.51 v5.4.0 --db 2 --pd 3 --kv 3

--上述命令会在本地下载并启动某个版本的集群（例如 v5.4.0）。最新版本可以通过执行
tiup list tidb ###来查看。运行结果将显示集群的访问方式：

---新开启一个 session 以访问 TiDB 数据库。
--使用 TiUP client 连接 TiDB：

tiup client
--也可使用 MySQL 客户端连接 TiDB：
mysql --host 127.0.0.1 --port 4000 -u root
5. 通过 http://127.0.0.1:9090 访问 TiDB 的 Prometheus 管理界面。
6. 通过 http://127.0.0.1:2379/dashboard 访问TiDB Dashboard 页面，默认用户名为 root，密码为空。
通过 http://127.0.0.1:3000 访问 TiDB 的 Grafana 界面，默认用户名和密码都为 admin。
7.（可选）将数据加载到 TiFlash 进行分析。
8. 测试完成之后，可以通过执行以下步骤来清理集群：
1. 通过按下 ctrl + c 键停掉进程。
2. 执行以下命令：
tiup clean --all

TiUP Playground 默认监听 127.0.0.1，服务仅本地可访问；若需要使服务可被外部访问，可使
用 --host 参数指定监听网卡绑定外部可访问的 IP。


---查看版本
[root@db51 ~]# tiup --binary cluster
/root/.tiup/components/cluster/v1.9.0/tiup-cluster

tiup list tidb
#####################################在单机上模拟部署生产环境集群

适用场景：希望用单台 Linux 服务器，体验 TiDB 最小的完整拓扑的集群，并模拟生产环境下的部署步骤。
本节介绍如何参照 TiUP 最小拓扑的一个 YAML 文件部署 TiDB 集群。

下表中拓扑实例的 IP 为示例 IP。在实际部署时，请替换为实际的 IP。
实例 个数 IP 配置
TiKV 3 10.0.1.1 10.0.1.1 10.0.1.1 避免端口和目录冲突
TiDB 1 10.0.1.1 默认端口全局目录配置
PD 1 10.0.1.1 默认端口全局目录配置
TiFlash 1 10.0.1.1 默认端口全局目录配置
Monitor 1 10.0.1.1 默认端口全局目录配置
部署主机软件和环境要求：
部署需要使用部署主机的 root 用户及密码
部署主机关闭防火墙或者开放 TiDB 集群的节点间所需端口
目前 TiUP 支持在 x86_64（AMD64 和 ARM）架构上部署 TiDB 集群
– 在 AMD64 架构下，建议使用 CentOS 7.3 及以上版本 Linux 操作系统
– 在 ARM 架构下，建议使用 CentOS 7.6 1810 版本 Linux 操作系统

1. 下载并安装 TiUP：
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
2. 声明全局环境变量：
注意：
TiUP 安装完成后会提示对应 profile 文件的绝对路径。在执行以下 source 命令前，需要
根据 profile 文件的实际位置修改命令。
source .bash_profile

3. 安装 TiUP 的 cluster 组件：
tiup cluster
4. 如果机器已经安装 TiUP cluster，需要更新软件版本：
tiup update --self && tiup update cluster
5. 由于模拟多机部署，需要通过 root 用户调大 sshd 服务的连接数限制：
1. 修改 /etc/ssh/sshd_config 将 MaxSessions 调至 20。
2. 重启 sshd 服务：
service sshd restart
6. 创建并启动集群
按下面的配置模板，编辑配置文件，命名为 topo.yaml，其中：
user: "tidb"：表示通过 tidb 系统用户（部署会自动创建）来做集群的内部管理，默认使用 22 端口通过 ssh 登录目标机器
replication.enable-placement-rules：---设置这个 PD 参数来确保 TiFlash 正常运行
host：设置为本部署主机的 IP
配置模板如下：

# # 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: "/tidb-deploy"
data_dir: "/tidb-data"

# # Monitored variables are applied to all the machines.
monitored:
node_exporter_port: 9100
blackbox_exporter_port: 9115
# deploy_dir: "/tidb-deploy/monitored-9100"
# data_dir: "/tidb-data/monitored-9100"
# log_dir: "/tidb-deploy/monitored-9100/log"

# # Server configs are used to specify the runtime configuration of TiDB components.
# # All configuration items can be found in TiDB docs:
# # - TiDB: https://pingcap.com/docs/stable/reference/configuration/tidb-server/configuration-file/
# # - TiKV: https://pingcap.com/docs/stable/reference/configuration/tikv-server/configuration-file/
# # - PD: https://pingcap.com/docs/stable/reference/configuration/pd-server/configuration-file/
# # All configuration items use points to represent the hierarchy, e.g:
# # readpool.storage.use-unified-pool
# #
# # You can overwrite this configuration via the instance-level `config` field.

server_configs:
tidb:
log.slow-threshold: 300
# binlog.enable: false
# binlog.ignore-error: false
tikv:
# server.grpc-concurrency: 4
# raftstore.apply-pool-size: 2
# raftstore.store-pool-size: 2
# rocksdb.max-sub-compactions: 1
# storage.block-cache.capacity: "16GB"
# readpool.unified.max-thread-count: 12
readpool.storage.use-unified-pool: false
readpool.coprocessor.use-unified-pool: true
pd:
replication.enable-placement-rules: true #来确保 TiFlash 正常运行
replication.location-labels: ["host"]
# schedule.leader-schedule-limit: 4
# schedule.region-schedule-limit: 2048
# schedule.replica-schedule-limit: 64
tiflash:
logger.level: "info"

pd_servers:
- host: 15.1.1.51
# ssh_port: 22
# 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"
# numa_node: "0,1"
# # The following configs are used to overwrite the `server_configs.pd` values.
# config:
# schedule.max-merge-region-size: 20
# schedule.max-merge-region-keys: 200000

tidb_servers:
- host: 15.1.1.51
# 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.slow-query-file: tidb-slow-overwrited.log

tikv_servers:
- host: 15.1.1.51
# 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.labels: { host: "logic-host-1" }

- host: 15.1.1.51
port: 20161
status_port: 20181
config:
server.labels: { host: "logic-host-2" }


- host: 15.1.1.51
port: 20162
status_port: 20182
config:
server.labels: { host: "logic-host-3" }

tiflash_servers:
- host: 10.0.1.11

monitoring_servers:
- host: 15.1.1.51
# ssh_port: 22
# port: 9090
# deploy_dir: "/tidb-deploy/prometheus-8249"
# data_dir: "/tidb-data/prometheus-8249"
# log_dir: "/tidb-deploy/prometheus-8249/log"

grafana_servers:
- host: 15.1.1.51
# port: 3000
# deploy_dir: /tidb-deploy/grafana-3000

alertmanager_servers:
- host: 15.1.1.51
# ssh_port: 22
# web_port: 9093
# cluster_port: 9094
# deploy_dir: "/tidb-deploy/alertmanager-9093"
# data_dir: "/tidb-data/alertmanager-9093"
# log_dir: "/tidb-deploy/alertmanager-9093/log"

-----------执行集群部署命令：
tiup cluster deploy <cluster-name> <tidb-version> ./topo.yaml --user root -p

参数 <cluster-name> 表示设置集群名称
参数 <tidb-version> 表示设置集群版本，可以通过 tiup list tidb 命令来查看当前支持部署的TiDB 版本
按照引导，输入”y” 及 root 密码，来完成部署：
Do you want to continue[y/N]: y
Input SSH password:
--启动集群：
tiup cluster start <cluster-name>
--访问集群：
安装 MySQL 客户端。如果已安装 MySQL 客户端则可跳过这一步骤。
yum -y install mysql
访问 TiDB 数据库，密码为空：
mysql -h 10.0.1.1 -P 4000 -u root

--执行以下命令确认当前已经部署的集群列表：
tiup cluster list
--执行以下命令查看集群的拓扑结构和状态：
tiup cluster display <cluster-name>

------------------------------------------------------------------------------------
tiup cluster template > topology.yaml
---混合部署场景：单台机器部署多个实例，详情参见混合部署拓扑架构 。
tiup cluster template --full > topology.yaml
---跨机房部署场景：跨机房部署 TiDB 集群，详情参见跨机房部署拓扑架构
tiup cluster template --multi-dc > topology-dc.yaml
-----a simple cluster locally.
tiup cluster template --local > topology-simple.yaml

--检查集群存在的潜在风险：
#tiup cluster check ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa]

----. 检查和自动修复集群存在的潜在风险:
tiup cluster check ./topotest.yaml --apply --user root -p
#tiup cluster check ./topology.yaml --apply --user root [-p] [-i /home/root/.ssh/gcp_rsa]

---执行集群部署命令：
tiup cluster deploy tidb-test v5.4.0 ./topotest.yaml --user root -p
#tiup cluster deploy tidb-test v5.4.0 ./topotest.yaml --user root -p -i /home/tidb/.ssh/gcp_rsa
tiup cluster deploy tidb-test v5.4.0 ./topotest.yaml --user root -p -i /home/root/.ssh/gcp_rsa

---查看 TiUP 管理的集群情况:
# tiup cluster list

---检查 tidb-test 集群情况:
# tiup cluster display tidb-test

--- 启动集群:

--安全启动
---tiup cluster start tidb-test --init
tiup cluster start tidb-test --init

Started cluster `tidb-test` successfully
Failed to set root password of TiDB database to '%TWM$NQ0h4687Gy_^9'

--普通启动
tiup cluster start tidb-test
#tiup cluster stop tidb-test

--访问集群：
安装 MySQL 客户端。如果已安装 MySQL 客户端则可跳过这一步骤。
yum -y install mysql
访问 TiDB 数据库，密码为空：
mysql -h 15.1.1.51 -P 4001 -u root

SET PASSWORD FOR 'root'@'%' = 'sunman';

ALTER USER 'root'@'localhost' IDENTIFIED BY 'sunman';


set password for 'root'@'localhost' = password('sunman');

tiup client
--执行以下命令确认当前已经部署的集群列表：
tiup cluster list
--执行以下命令查看集群的拓扑结构和状态：
tiup cluster display tidb-test

tiup cluster clean tidb-test --all

tiup cluster destroy tidb-test
Yes, I know my cluster and data will be deleted.

tiup cluster prune tidb-test


tiup cluster edit-config tidb-test
tiup cluster reload tidb-test

tiup cluster display tidb-test

tiup cluster stop tidb-test -N 15.1.1.51:4001

vi /tidb-deploy/tidb-4001/conf/tidb.toml

由于添加了skip-grant-table = true 无法直接通过tiup来启动 15.1.1.51上的 tidb-server
官方文档说明：设置 skip-grant-table 之后，启动 TiDB 进程会增加操作系统用户检查，只有操作系统的 root 用户才能启动 TiDB 进程。

查看tidb-server的日志
cd /tidb-deploy/tidb-4001/log/
[root@db51 ~]# tail -n 10 /tidb-deploy/tidb-4001/log/tidb_stderr.log
load config file: /tidb-deploy/tidb-4001/conf/tidb.toml
invalid config TiDB run with skip-grant-table need root privilege
load config file: /tidb-deploy/tidb-4001/conf/tidb.toml
invalid config TiDB run with skip-grant-table need root privilege
load config file: /tidb-deploy/tidb-4001/conf/tidb.toml
invalid config TiDB run with skip-grant-table need root privilege
load config file: /tidb-deploy/tidb-4001/conf/tidb.toml
invalid config TiDB run with skip-grant-table need root privilege
load config file: /tidb-deploy/tidb-4001/conf/tidb.toml
invalid config TiDB run with skip-grant-table need root privilege

连接到tidb-server所在的服务器，手工执行启动脚本

sh /tidb-deploy/tidb-4001/scripts/run_tidb.sh
--再打开一个新会话，就可以免密登录了
mysql -h 15.1.1.51 -P 4001 -u root

SET PASSWORD FOR 'root'@'%' = 'sunman';

ALTER USER 'root'@'localhost' IDENTIFIED BY 'sunman';

修改成功以后，在执行启动脚本的会话里执行ctrl+c,然后删除添加的参数

再使用tiup重新启动tidb-server

[root@node1 ~]# tiup cluster start tidb-test -N 15.1.1.51:4001
--因为密码信息是存储再TiKV中的，所以当密码修改成功以后，所有的TiDB-server节点都可以使用新密码登录

---检查 tidb-test 集群情况:
tiup cluster display tidb-test

--输入密码，登录TIDB
mysql -h 15.1.1.51 -P 4001 -u root -psunman

select tidb_version()\G

show databases;

create database tidb;

use tidb

CREATE TABLE `tab_tidb` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(20) NOT NULL DEFAULT '',
`age` int(11) NOT NULL DEFAULT 0,
`version` varchar(20) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `idx_age` (`age`));

insert into `tab_tidb` values (1,'TiDB',5,'TiDB-v5.0.0');

select * from tab_tidb;

查询当前数据库的连接状态:
show processlist;

. 创建测试表 t1（t1 表只有一列 a，并且是自增主键列）：
CREATE TABLE t1 (a int not null primary key auto_increment);

查看系统参数auto_increment_increment（auto_increment_increment默认值为1.）：

show session variables like 'auto_increment_increment';
插入 2 行测试数据（增量变为 1）:

MySQL [test]> insert into t1 values ();
Query OK, 1 row affected (0.01 sec)

MySQL [test]> insert into t1 values ();
Query OK, 1 row affected (0.00 sec)

MySQL [test]> select * from t1;
+---+
| a |
+---+
| 1 |
| 2 |
+---+
2 rows in set (0.00 sec)

5. 在会话级别修改参数auto_increment_increment为10:

set auto_increment_increment = 10;

MySQL [test]> set auto_increment_increment = 10;
Query OK, 0 rows affected (0.00 sec)

MySQL [test]> insert into t1 values ();
Query OK, 1 row affected (0.00 sec)

MySQL [test]> insert into t1 values ();
Query OK, 1 row affected (0.00 sec)

MySQL [test]> select * from t1;
+----+
| a |
+----+
| 1 |
| 2 |
| 11 |
| 21 |

---在 GLOBAL 范围进行修改: ，参数auto_increment_increment在GLOBAL 范围进行修改，并不会影响当前会话

set global auto_increment_increment=10;

在当前会话查询会话级别，查询参数auto_increment_increment:
show session variables like 'auto_increment_increment';

进入 TiKV-Server，打开配置文件，一般位置为 /tidb-deploy/tikv-20160/conf (注意：tikv-20160 可能不同)，打开文件 tikv.toml:

[root@db51 ~]# vi /tidb-deploy/tikv-20160/conf/tikv.toml

--进入到安装 tiup 的中控机或者节点，执行配置文件编辑命令:
tiup cluster edit-config tidb-test
tiup cluster edit-config tidb-test

server_configs:
tidb:
log.slow-threshold: 300
security.skip-grant-table: true
tikv:
readpool.coprocessor.use-unified-pool: true
readpool.storage.use-unified-pool: false
log-level: warning

tiup cluster reload tidb-test -N 15.1.1.51

tiup cluster reload tidb-test [-N <nodes>]


------对 TiDB 集群进行扩容和缩容编辑扩容文件，内容如下:
# vi scale-out-tikv.yaml
--扩容tikv
tikv_servers:
- host: 15.1.1.52
ssh_port: 54111
port: 20160
status_port: 20180
deploy_dir: /tidb-deploy/tikv-20160
data_dir: /tidb-data/tikv-20160
log_dir: /tidb-deploy/tikv-20160/log

--扩容
tiup cluster scale-out tidb-test scale-out-tikv.yaml -uroot -pYjc85235228
--查看集群状态
tiup cluster display tidb-test

--进行缩容操
tiup cluster scale-in tidb-test --node 15.1.1.52:20160

--查询所容后的集群状态，发现 15.1.1.52 节点的 Status 已经变为 Tombstone，代表 节点已经下线,如下所示:
tiup cluster display tidb-test
--执行 tiup cluster prune tidb-test , 清理节点信息，如下: PingCAP Education Copyright@2
tiup cluster prune tidb-test
tiup cluster display tidb-test

----------使用 tiup 进行集群名修改
tiup cluster rename tidb-test tidb-prod
--查看集群状态，发现集群名已经改为 tidb-prod,
tiup cluster display tidb-prod

tiup cluster rename tidb-prod tidb-test
tiup cluster display tidb-test

-------------

tar -xvf br-v5.4.0-linux-amd64.tar.gz -C /home/tidb/tidb-community-toolkit-v5.4.0-linux-amd64/bin

select VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME='new_collation_enabled';

----------
[root@db51 tidb]# chown -R tidb:tidb backup

[root@db51 tidb-community-toolkit-v5.4.0-linux-amd64]# cd bin
[root@db51 bin]# ./br backup full --pd "15.1.1.51:2379" --storage "local:///home/tidb/backup" --ratelimit 120 --log-file backupfull.log

--单库备份
./br backup db \
--pd "15.1.1.51:2379" \
--db test\ ##备份 test 库下面所有的表
--storage "local:///home/tidb/backup" \
--ratelimit 120 \
--log-file backupdbtest.log

./br backup db --pd "15.1.1.51:2379" --db test --storage "local:///home/tidb/backupdb" --ratelimit 120 --log-file backupdbtest.log

--删除数据库test
mysql> drop database test;

---单库恢复
首先,将所有 TiKV 目录 /tmp/employees 下面的备份文件相拷贝到其他节点,保证在所有的 TiKV 节点上都有所有的备份文件
循环操作,更换不同节点,使所有节点都有所有的备份文件

./br restore db --pd "15.1.1.51:2379" --db "test" --storage "local:///home/tidb/backupdb" --log-file restoredb.log

--单表备份
./br backup table --pd "15.1.1.51:2379" --db test --table t1 --storage "local:///home/tidb/backuptab" --ratelimit 120 --log-file backuptable.log
./br backup table \
--pd "15.1.1.51:2379" \
--db employees \
--table salaries \##备份 employees 库下面的 salaries 表
--storage "local:///tmp/salariestab" \
--ratelimit 120 \
--log-file backuptable.log

drop table t1;

--单表恢复

./br restore table --pd "15.1.1.51:2379" --db "test" --table "t1" --storage "local:///home/tidb/backuptab" --log-file restoretable.log

./br restore table \
--pd "15.1.1.51:2379" \
--db "employees" \
--table "salaries" \
--storage "local:///tmp/salariestab" \
--log-file restoretable.log

--执行 br backup full 命令，并使用 --filter 或 -f 来指定表库过滤规则。
--将所有db*.tbl*形式的表格数据备份到每个TiKV节点上的/tmp/backup路径，并将backupmeta文件写入该路径。
br backup full \
--pd "${PDIP}:2379" \
--filter 'db*.tbl*' \
--storage "local:///tmp/backup" \
--ratelimit 128 \ ##选项限制了每个 TiKV 执行备份任务的速度上限（单位 MiB/s）。
--log-file backupfull.log

br restore full \
--pd "${PDIP}:2379" \
--filter 'db*.tbl*' \
--storage "local:///tmp/backup" \
--ratelimit 128 \ ##选项限制了每个 TiKV 执行恢复任务的速度上限（单位 MiB/s）。
--log-file backupfull.log


--增量备份
如果想要备份增量，只需要在备份的时候指定上一次的备份时间戳 --lastbackupts 即可。
注意增量备份有以下限制：
增量备份需要与前一次全量备份在不同的路径下
GC safepoint 必须在 lastbackupts 之前
br backup full \
--pd ${PDIP}:2379 \
--ratelimit 128 \
-s local:///home/tidb/backupdata/incr \
--lastbackupts ${LAST_BACKUP_TS}
以上命令会备份 (LAST_BACKUP_TS, current PD timestamp] 之间的增量数据。
--你可以使用 validate 指令获取上一次备份的时间戳，示例如下：

LAST_BACKUP_TS=`br validate decode --field="end-version" -s local:///home/tidb/backupdata | tail -n1`


---br 实例
在所有的 TiKV 节点创建文件夹 /tmp/backup,用来存储本节点的备份文件(SST 文件) 并将文件夹的权限设置为可以读写 首先登录到 TiKV 节点,之后执行:
[root@copy-of-vm-ee-centos76-v1 ~]# mkdir /tmp/backup
[root@copy-of-vm-ee-centos76-v1 ~]# chmod 777 /tmp/backup

---
cd tidb-toolkit-v5.0.1-linux-amd64/bin/
./br backup full \
--pd "15.1.1.51:2379" \##连接 TiDB 数据库的 PD 节点,最好在 PD 节点 上执行,即连接本节点
--storage "local:///tmp/backup" \##备份文件存储在 TiKV 节点上的位置
--ratelimit 120 \##对于备份所用存储带宽限速
--log-file backupfull.log ##备份日志文件


[root@rac1 ~]# cd tidb-toolkit-v5.0.1-linux-amd64/
[root@rac1 tidb-toolkit-v5.0.1-linux-amd64]# ls
bin
[root@rac1 tidb-toolkit-v5.0.1-linux-amd64]# cd bin
[root@rac1 bin]# ls
br mydumper sync_diff_inspector tidb-lightning-ctl
dumpling pd-tso-bench tidb-lightning tikv-importer



示例备份的增量数据记录 (LAST_BACKUP_TS, current PD timestamp] 之间的数据变更，以及这段时间内的
DDL。在恢复的时候，BR 会先把所有 DDL 恢复，而后才会恢复数据。

Dumpling: 热、温备份，逻辑备份
复制： 热备，逻辑备份

从 TiDB/MySQL 导出数据
10.6.1.1 需要的权限
SELECT
RELOAD
LOCK TABLES
REPLICATION CLIENT
PROCESS

------dumpling-
tar -xvf dumpling-v5.4.0-linux-amd64.tar.gz -C /home/tidb/tidb-community-toolkit-v5.4.0-linux-amd64/bin

./dumpling -uroot -P4001 -h 15.1.1.51 --filetype sql -t 8 -o /home/tidb/dumpling -r 200000 -F 256MiB --where "id <100"

导出为 CSV 文件
假如导出数据的格式是 CSV（使用 --filetype csv 即可导出 CSV 文件），还可以使用 --sql <SQL> 导出指定 SQL
选择出来的记录，例如，导出 test.sbtest1 中所有 id < 100 的记录：

Dumpling 也可以通过 -B 或 -T 选项导出特定的数据库/数据表。
注意：
--filter 选项与 -T 选项不可同时使用。
-T 选项只能接受完整的 库名.表名 形式，不支持只指定表名。例：Dumpling 无法识别-T WorkOrder。
例如通过指定：
-B employees 导出 employees 数据库
-T employees.WorkOrder 导出 employees.WorkOrder 数据表

在 /tmp/test 查看导出的文件：
$ ls -lh /home/tidb/dumpling | awk '{print $5 "\t" $9}'


./dumpling -u root -P 4001 -h 127.0.0.1 -o /home/tidb/dumpling --filetype csv --sql 'select * from `test`.`t1` where id < 100'

./dumpling -uroot -psunman -P4001 -h 15.1.1.51 --filetype sql -t 8 -o /home/tidb/dumpling -r 200000 -F 256MiB --filter "test.*"

-uroot -P4000 -h 15.1.1.51 :用户名为 root,端口号为4000,主机IP 为15.1.1.51;
--filetype sql :导出文件类型为 SQL 文件 -t 8 :采用 8 线程同时导出
-o /tmp/city :导出文件保存在 /tmp/city 中
-r 200000 :每个导出文件最大容纳 200000 行数据
-F 256MiB :每个导出文件最大 256 MiB

-------从 TiDB 集群中导出数据库 employees
./dumpling -uroot -ptidb -P4000 -h 15.1.1.51 \
--filetype sql \
-t 8 \ #并行8线程
-o /tmp/city \
-r 200000 \
-F 256MiB \
-B employees ##导出数据库 world

导出会生成4个文件：
metadata，包含开始结束时间
建库语句文件，: {schema}.schema-create.sql
建表语句文件，: {schema}.{table}-schema.sql
数据文件 ： {schema}.{table}.{0001}.csv|sql


导出数据异质性 ： --consistency <consistency level>
./dumpling --snapshot
./dumpling --flush ##全库锁定
1. flush 2.snapshot 3. lock 4. none 5. auto
----------使用 Dumpling 工具将 3306 端口的 MySQL 数据库的employees 库导出
./dumpling -uroot -P3306 -h '127.0.0.1' -p'Pingcap!@3' --filetype sql -t 8 -o /tmp/employees -r 200000-F 256MiB -B employees


导出 TiDB 的历史数据快照
Dumpling 可以通过 --snapshot 指定导出某个tidb_snapshot 的数据。
--snapshot 选项可设为 TSO（SHOW MASTER STATUS 输出的 Position 字段）或有效的 datetime 时间（YYYY-MM-DD hh:mm:ss 形式），例如：
./dumpling --snapshot 417773951312461825
./dumpling --snapshot "2020-07-02 17:12:45"
即可导出 TSO 为 417773951312461825 或 2020-07-02 17:12:45 时的 TiDB 历史数据快照。
10.6.1.10 控制导出 TiDB 大表时的内存使用
Dumpling 导出 TiDB 较大单表时，可能会因为导出数据过大导致 TiDB 内存溢出 (OOM)，从而使连接中断导出失
败。可以通过以下参数减少 TiDB 的内存使用。
设置 -r 参数，可以划分导出数据区块减少 TiDB 扫描数据的内存开销，同时也可开启表内并发提高导出
效率。当上游为 TiDB 且版本为 v3.0 或更新版本时，该参数大于 0 表示使用 TiDB region 信息划分表内并发，
具体取值将不再生效。
调小 --tidb-mem-quota-query 参数到 8589934592 (8GB) 或更小。可控制 TiDB 单条查询语句的内存使用。
调整--params "tidb_distsql_scan_concurrency=5"参数，即设置导出时的session变量tidb_distsql_scan_concurrency
,→ 从而减少 TiDB scan 操作的并发度。
10.6.1.11 导出大规模数据时的 TiDB GC 设置
如果导出的 TiDB 版本为 v4.0.0 或更新版本，并且 Dumpling 可以访问 TiDB 集群的 PD 地址，Dumpling 会自动配置
延长 GC 时间且不会对原集群造成影响。
其他情况下，假如导出的数据量非常大，可以提前调长 GC 时间，以避免因为导出过程中发生 GC 导致导出失
败：
845
SET GLOBAL tidb_gc_life_time = '720h';
操作结束之后，再恢复 GC 时间为默认值 10m：
SET GLOBAL tidb_gc_life_time = '10m';

--------TiDB Lightning 简介
TiDB Lightning 是一个将全量数据高速导入到 TiDB 集群的工具，可在此下载。
TiDB Lightning 有以下两个主要的使用场景：
迅速导入大量新数据。
恢复所有备份数据。
目前，TiDB Lightning 支持：
导入Dumpling输出的数据、CSV 文件或Amazon Aurora 生成的 Apache Parquet 文件。
从本地盘或Amazon S3 云盘读取数据。

TiDB Lightning 整体工作原理如下：
1. 在导入数据之前，tidb-lightning 会自动将 TiKV 集群切换为 “导入模式” (import mode)，优化写入效率
并停止自动压缩。
2. tidb-lightning 会在目标数据库建立架构和表，并获取其元数据。
3. 每张表都会被分割为多个连续的区块，这样来自大表 (200 GB+) 的数据就可以用增量方式并行导入。
4. tidb-lightning 会为每一个区块准备一个 “引擎文件 (engine file)” 来处理键值对。tidb-lightning 会并
发读取 SQL dump，将数据源转换成与 TiDB 相同编码的键值对，然后将这些键值对排序写入本地临时存
储文件中。
5. 当一个引擎文件数据写入完毕时，tidb-lightning 便开始对目标 TiKV 集群数据进行分裂和调度，然后
导入数据到 TiKV 集群。
引擎文件包含两种：数据引擎与索引引擎，各自又对应两种键值对：行数据和次级索引。通常行数据
在数据源里是完全有序的，而次级索引是无序的。因此，数据引擎文件在对应区块写入完成后会被立
即上传，而所有的索引引擎文件只有在整张表所有区块编码完成后才会执行导入。

6. 整张表相关联的所有引擎文件完成导入后，tidb-lightning 会对比本地数据源及下游集群的校验和
(checksum)，确保导入的数据无损，然后让 TiDB 分析 (ANALYZE) 这些新增的数据，以优化日后的操作。同
时，tidb-lightning 调整 AUTO_INCREMENT 值防止之后新增数据时发生冲突。
表的自增 ID 是通过行数的上界估计值得到的，与表的数据文件总大小成正比。因此，最后的自增 ID 通
常比实际行数大得多。这属于正常现象，因为在 TiDB 中自增 ID 不一定是连续分配的。
7. 在所有步骤完毕后，tidb-lightning 自动将 TiKV 切换回 “普通模式” (normal mode)，此后 TiDB 集群可以
正常对外提供服务。

下游数据库所需空间
目标 TiKV 集群必须有足够空间接收新导入的数据。除了标准硬件配置以外，目标 TiKV 集群的总存储空间必须
大于 数据源大小 × 副本数量 × 2。例如集群默认使用 3 副本，那么总存储空间需为数据源大小的 6 倍以上。公
式中的 2 倍可能难以理解，其依据是以下因素的估算空间占用：
索引会占据额外的空间
RocksDB 的空间放大效应
目前无法精确计算 Dumpling 从 MySQL 导出的数据大小，但你可以用下面 SQL 语句统计信息表的 data_length 字
段估算数据量：
--统计所有 schema 大小，单位 MiB，注意修改 ${schema_name}
select table_schema,sum(data_length)/1024/1024 as data_length,sum(index_length)/1024/1024 as index_length,
sum(data_length+index_length)/1024/1024 as sum from information_schema.tables where table_schema = "${schema_name}" group by table_schema;

--统计最大单表，单位 MiB，注意修改 ${schema_name}
select table_name,table_schema,sum(data_length)/1024/1024 as data_length,sum(index_length)/1024/1024 as index_length,
sum(data_length+index_length)/1024/1024 as sum from information_schema.tables where table_schema = "${schema_name}"
group by table_name, table_schema order by sum desc limit 5;

10.7.2.2.3 TiDB Lightning 运行时资源要求
操作系统：本文档示例使用的是若干新的、纯净版 CentOS 7 实例，你可以在本地虚拟化一台主机，或在供应
商提供的平台上部署一台小型的云虚拟主机。TiDB Lightning 运行过程中，默认会占满 CPU，建议单独部署在一
台主机上。如果条件不允许，你可以将 TiDB Lightning 和其他组件（比如tikv-server）部署在同一台机器上，
然后设置region-concurrency 配置项的值为逻辑 CPU 数的 75%，以限制 TiDB Lightning 对 CPU 资源的使用。
内存和 CPU：因为 TiDB Lightning 对计算机资源消耗较高，建议分配 64 GB 以上的内存以及 32 核以上的 CPU，而
且确保 CPU 核数和内存（GB）比为 1:2 以上，以获取最佳性能。
存储空间：配置项 sorted-kv-dir 设置排序的键值对的临时存放地址，目标路径必须是一个空目录，目录空
间须大于待导入数据集的大小。建议与 data-source-dir 使用不同的存储设备，独占 IO 会获得更好的导入性
能，且建议优先考虑配置闪存等高性能存储介质。
网络：建议使用带宽 >=10Gbps 的网卡。


mysql -h 15.1.1.51 -P 4001 -u root -psunman

cd /home/tidb/tidb-community-toolkit-v5.4.0-linux-amd64/bin
vi tidb-lightning.toml
1) backend = "local”:表示直接导入到 TiKV-Server 中
(2) pd-addr = "15.1.1.51:2379”:选择任意一个 PD 节点的 IP 和输入端口号

[lightning]
####启动之前检查集群是否满足最低需求
check-requirements = true
####日志
level = "info"
file = "tidb-lightning.log"
[tikv-importer]
####选择使用的 local 后端 ：默认使用该模式，适用于 TB 级以上大数据量，但导入期间下游 TiDB 无法对外提供服务。
####"tidb"：TB 级以下数据量也可以采用`tidb`后端模式，下游 TiDB 可正常提供服务。
backend = "local"
####设置排序的键值对的临时存放地址，目标路径必须是一个空目录，目录空间须大于待导入数据集的大小
####建议设为与 `data-source-dir` 不同的磁盘目录并使用闪存介质，独占 IO会获得更好的导入性能
sorted-kv-dir = "/tmp"
[mydumper]
####源数据目录。
data-source-dir = "/home/tidb/dumpling"
[tidb]
####目标集群的信息
host = "15.1.1.51"
port = 4001
user = "root"
####表架构信息在从 TiDB 的“状态端口”获取。
status-port = 10080
####集群 pd 的地址
pd-addr = "15.1.1.51:2379"

---开始使用 TiDB Lightning 工具进行数据导入

! /bin/bash
[root@centos76_vm bin]# nohup ./tidb-lightning -tidb-password sunman -config tidb-lightning.toml > nohup.out &


----DM
=---------Data Migration(DM)的部署

1.通过 tiup 安装 dm 组件,如下:
tiup install dm

2. 通过 tiup 更新 dm 组件到最新版本,如下:
tiup update --self && tiup update dm

3. 生成一个初始化配置文件,并准备编辑,如下:
tiup dm template > topology.yaml

4. 编辑 topology.yaml 文件,加入 master_servers,worker_servers, monitoring_servers,grafana_servers 和 alertmanager_servers

vi topology.yaml
内容为：
# The topology template is used deploy a minimal DM cluster, which suitable
# for scenarios with only three machinescontains. The minimal cluster contains
# - 3 master nodes # - 3 worker nodes
# You can change the hosts according your environment
---
global:
user: "tidb"
ssh_port: 22
deploy_dir: "/home/tidb/dm/deploy"
data_dir: "/home/tidb/dm/data"
# arch: "amd64"

master_servers:
- host: 172.16.6.157
- host: 15.1.1.51
- host: 172.16.6.210

worker_servers:
- host: 172.16.6.157
- host: 172.16.6.210

monitoring_servers:
- host: 172.16.6.157

grafana_servers:
- host: 172.16.6.157

alertmanager_servers:
- host: 172.16.6.157

5. 查看当前可用的 Data Migration(DM) 最新版本,或者其他可用版本
tiup list dm-master

6. 部署 Data Migration(DM) 集群,集群名称为 集群 dm-test
tiup dm deploy <cluster-name> <version> <topology.yaml> [flags]

tiup dm deploy dm-test v5.4.0-nightly-20220531 ./topology.yaml --user root -p

7. 查看 TiUP 管理的 DM 集群情况,如下
tiup dm list

8. 检查部署的集群 dm-test 的状态
# tiup dm display dm-test

9. 启动集群 dm-test
tiup dm start dm-test
tiup dm display dm-test

10..获取集群控制工具 dmctl
tiup dmctl:v5.4.0-nightly-20220531

-------从 MySQL 同步数据到 TiDB

为 MySQL 数据库开通用户权限,并初始化数据,分别连接到端口号 3306 和 3307 的 MySQL 数据库,创建
'root'@'172.16.6.157' ,'root'@'172.16.6.210' 和 'root'@'15.1.1.51' ,并赋予allprivileges 权限(更详细权限请参考文档),
这 3 个用户用于 dm-worker 连接MySQL 数据库进行全量和增量数据的读取

mysql> create user 'root'@'172.16.6.157' identified by 'mysql'
mysql> grant all privileges on *.* to 'root'@'172.16.6.157';
mysql> create user 'root'@'172.16.6.210' identified by 'mysql'
mysql> grant all privileges on *.* to 'root'@'172.16.6.210';
mysql> create user 'root'@'15.1.1.51' identified by 'mysql'
mysql> grant all privileges on *.* to 'root'@'15.1.1.51';


. 分别连接到端口号 3306 和 3307 的 MySQL 数据库,导入数据库user,store,log,salesdb
mysql -uroot -pmysql -S /data/mydb3306/mysql.sock < 3306db.sql
mysql -uroot -pmysql -S /data/mydb3307/mysql.sock < 3307db.sql

1.编辑上游数据源配置文件
vi mysql-source-conf1.yaml
source-id: "mysql-replica-01"

from:
host: "172.16.6.212"
user: "root"
password: "F1GJCYzuWx/8H4EJHRDWwkBJCrN+4A=="
port: 3306

注意:password: "F1GJCYzuWx/8H4EJHRDWwkBJCrN+4A==" 表示隐藏掉明文的密码,
我们可以 按照如下方法生成:
tiup dmctl -encrypt 'mysql'

2. 将数据源配置文件加载到 DM 中
tiup dmctl --master-addr=15.1.1.51:8261 operate-source create mysql-source-conf1.yaml
##:--master-addr=15.1.1.51:8261 为 DM 集群中的任意一个 master 节点

2.1 查看已经加载的数据源
tiup dmctl --master-addr=15.1.1.51:8261 get-config source mysql-replica-01

2.2 查看数据源和 dm-worker 的对应关系
tiup dmctl --master-addr=15.1.1.51:8261 operate-source show
2.3## 任务配置
编辑任务配置文件 task.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"
# 需要迁移的库名或表名的黑白名单的配置项名称，用于引用全局的黑白名单配置，全局配置见下面的 `block-allow-list` 的配置。
block-allow-list: "global" # 如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list。
# dump 处理单元的配置项名称，用于引用全局的 dump 处理单元配置。
mydumper-config-name: "global"

-
source-id: "mysql-replica-02"
block-allow-list: "global" # 如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list。
mydumper-config-name: "global"

# 黑白名单全局配置，各实例通过配置项名引用。
block-allow-list: # 如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list。
global:
do-tables: # 需要迁移的上游表的白名单。
- db-name: "test_db" # 需要迁移的表的库名。
tbl-name: "test_table" # 需要迁移的表的名称。

# dump 处理单元全局配置，各实例通过配置项名引用。
mydumpers:
global:
extra-args: ""

######################3
name: "dm-taskX"
task-mode: all
ignore-checking-items: ["auto_increment_ID"]

任务名:dm-taskX,（X 代表任意字符）
复制方式:all(全量 + 增量),
gnore-checking-items: ["auto_increment_ID”]:忽略自增主键检测

##目标 TiDB 数据库配置信息
target-database:
host: "172.16.6.212"
port: 4000
user: "root"
password: "tidb"

数据库地址:172.16.6.212,端口为:4000,用户名:root,密码:tidb

mysql-instances:
-
source-id: "mysql-replica-01"
route-rules: ["instance-1-user-rule","sale-route-rule"]
filter-rules: ["trace-filter-rule", "user-filter-rule" , "store-filter-rule"]
block-allow-list: "log-ignored" ##定义数据源迁移表的过滤规则
mydumper-config-name: "global"
loader-config-name: "global"
syncer-config-name: "global"
-
source-id: "mysql-replica-02"
route-rules: ["instance-2-user-rule", "instance-2-store-rule","sale-route-rule"]
filter-rules: ["trace-filter-rule", "user-filter-rule" , "store-filter-rule"]
block-allow-list: "log-ignored"
mydumper-config-name: "global"
loader-config-name: "global"
syncer-config-name: "global"

# 黑白名单全局配置，各实例通过配置项名引用。
block-allow-list: # 如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list。
global:
do-tables: # 需要迁移的上游表的白名单。
- db-name: "test_db" # 需要迁移的表的库名。
tbl-name: "test_table" # 需要迁移的表的名称。


##log 库不会参与复制
block-allow-list:
log-ignored:
ignore-dbs: ["log"]

##
block-allow-list:
bw-rule-1: ##规则名称
do-dbs:["user"] ##迁移库
ignore-dbs: ["log"] ##忽略库
do-tables: # 需要迁移的上游表的白名单。
- db-name: "test_db" # 需要迁移的表的库名。
tbl-name: "test_table" # 需要迁移的表的名称。

filters: #上游数据库匹配的 binlog event filter规则
filter-rule-1: ##配置的名称
#user 库中的 trace 表不会复制 truncate ，drop 和 delete 操作
schema-pattern: "user" ##库名匹配规则，支持* 和？
table-pattern: "trace" ##表名匹配规则，支持* 和？
events: ["truncate table", "drop table", "delete"] ##匹配哪些操作
action: Ignore ##对与不匹配的binlog是迁移还是忽略
filter-rule-2:
# MySQL 数据库实例 3306 和 3307 中的 user 库不会复制删除操作
schema-pattern: "user"
events: ["drop database"]
action: Ignore

routes:
instance-1-user-rule: ##配置名称
schema-pattern: "user" ##库名匹配规则，支持* 和？
table-pattern: "test*" ##表名匹配规则，支持* 和？
target-schema: "user _north" #目标库名称
target-table: "test1" ##目标库的表名称


###
filters:
trace-filter-rule:
# user 库中的 trace 表不会复制 truncate ，drop 和 delete 操作
schema-pattern: "user"
table-pattern: "trace"
events: ["truncate table", "drop table", "delete"]
action: Ignore
user-filter-rule:
# MySQL 数据库实例 3306 和 3307 中的 user 库不会复制删除操作
schema-pattern: "user"
events: ["drop database"]
action: Ignore
store-filter-rule:
# store 库不会复制删除操作，store 库的表不会复制 truncate ，drop 和
delete 操作
schema-pattern: "store"
events: ["drop database", "truncate table", "drop table", "delete"]
action: Ignore

#########

filters:
trace-filter-rule:
# user 库中的 trace 表不会复制 truncate ，drop 和 delete 操作
schema-pattern: "user"
table-pattern: "trace"
events: ["truncate table", "drop table", "delete"]
action: Ignore
user-filter-rule:
# MySQL 数据库实例 3306 和 3307 中的 user 库不会复制删除操作
schema-pattern: "user"
events: ["drop database"]
action: Ignore
store-filter-rule:
# store 库不会复制删除操作，store 库的表不会复制 truncate ，drop 和 delete 操作
schema-pattern: "store"
events: ["drop database", "truncate table", "drop table", "delete"]
action: Ignore

###############
routes:
instance-1-user-rule:
schema-pattern: "user"
target-schema: "user _north"
instance-2-user-rule:
schema-pattern: "user"
target-schema: "user _east"
instance-2-store-rule:
schema-pattern: "store"
table-pattern: "store_sz"
target-schema: "store"
target-table: "store_suzhou

3.启动任务
为了提前发现数据迁移任务的一些配置错误，DM 中增加了前置检查功能：

启动数据迁移任务时，DM 自动检查相应的权限和配置。
也可使用 check-task 命令手动前置检查上游的 MySQL 实例配置是否符合 DM 的配置要求。
注意
第一次启动数据迁移任务时，必须确保上游数据库已配置。否则，启动任务时会报错。

使用 tiup dmctl 执行以下命令启动数据迁移任务。其中，task.yaml 是之前编辑的配置文件。
##任务配置文件 task.yaml：
tiup dmctl --master-addr=172.16.10.71:8261 start-task dm-task.yaml
###检查
##对于上游 MySQL 源数据库进行检查,得到期待结果,如下:
tiup dmctl --master-addr=15.1.1.51:8261 check-task dm-task.yaml
tiup dmctl --master-addr=172.16.10.71:8261 check-task dm-task.yaml
tiup dmctl --master-addr=172.16.10.71:8261 pause-task dm-task.yaml##暂停
tiup dmctl --master-addr=172.16.10.71:8261 resume-task dm-task.yaml ##恢复
tiup dmctl --master-addr=172.16.10.71:8261 stop-task dm-task.yaml
tiup dmctl --master-addr=15.1.1.51:8261 query-status dm-task.yaml
如果执行该命令后返回的结果如下，则表明任务已成功启动。

{
"result": true,
"msg": "",
"workers": [
{
"result": true,
"worker": "172.16.10.72:8262",
"msg": ""
},
{
"result": true,
"worker": "172.16.10.73:8262",
"msg": ""
}
]
}
如果任务启动失败，可根据返回结果的提示进行配置变更后执行 start-task task.yaml 命令重新启动任务。

4.查询任务
如需了解 DM 集群中是否存在正在运行的迁移任务及任务状态等信息，可使用 tiup dmctl 执行以下命令进行查询：

tiup dmctl --master-addr 172.16.10.71:8261 query-status
5停止任务
如果不再需要进行数据迁移，可以使用 tiup dmctl 执行以下命令停止迁移任务：

tiup dmctl --master-addr 172.16.10.71:8261 stop-task test
其中的 test 是 task.yaml 配置文件中 name 配置项设置的任务名。

第 8 步：监控任务与查看日志
如果使用 TiUP 部署 DM 集群时，正确部署了 Prometheus、Alertmanager 与 Grafana，且其地址均为 172.16.10.71。可在浏览器中打开 http://172.16.10.71:9093 进入 Alertmanager 查看 DM 告警信息；可在浏览器中打开 http://172.16.10.71:3000 进入 Grafana，选择 DM 的 dashboard 查看 DM 相关监控项。

DM 在运行过程中，DM-worker, DM-master 及 dmctl 都会通过日志输出相关信息。各组件的日志目录如下：

DM-master 日志目录：通过 DM-master 进程参数 --log-file 设置。如果使用 TiUP 部署 DM，则日志目录位于 {log_dir}。
DM-worker 日志目录：通过 DM-worker 进程参数 --log-file 设置。如果使用 TiUP 部署 DM，则日志目录位于 {log_dir}。



DM 配置优化
本文档介绍如何对迁移任务的配置进行优化，从而提高 DM 的数据迁移性能。

全量导出
全量导出相关的配置项为 mydumpers，下面介绍和性能相关的参数如何配置。

rows
设置 rows 选项可以开启单表多线程并发导出，值为导出的每个 chunk 包含的最大行数。开启后，DM 会在 MySQL 的单表并发导出时，优先选出一列做拆分基准，选择的优先级为主键 > 唯一索引 > 普通索引，选出目标列后需保证该列为整数类型（如 INT、MEDIUMINT、BIGINT 等）。

rows 的值可以设置为 10000，具体设置的值可以根据表中包含数据的总行数以及数据库的性能做调整。另外也需要设置 threads 来控制并发线程数量，默认值为 4，可以适当做些调整。

chunk-filesize
DM 全量备份时会根据 chunk-filesize 参数的值把每个表的数据划分成多个 chunk，每个 chunk 保存到一个文件中，大小约为 chunk-filesize。根据这个参数把数据切分到多个文件中，这样就可以利用 DM Load 处理单元的并行处理逻辑提高导入速度。该参数默认值为 64（单位为 MB），正常情况下不需要设置，也可以根据全量数据的大小做适当的调整。

注意
mydumpers 的参数值不支持在迁移任务创建后更新，所以需要在创建任务前确定好各个参数的值。如果需要更新，则需要使用 dmctl stop 任务后更新配置文件，然后再重新创建任务。
mydumpers.threads 可以使用配置项 mydumper-thread 替代来简化配置。
如果设置了 rows，DM 会忽略 chunk-filesize 的值。
全量导入
全量导入相关的配置项为 loaders，下面介绍和性能相关的参数如何配置。

pool-size
pool-size 为 DM Load 阶段线程数量的设置，默认值为 16，正常情况下不需要设置，也可以根据全量数据的大小以及数据库的性能做适当的调整。

注意
loaders 的参数值不支持在迁移任务创建后更新，所以需要在创建任务前确定好各个参数的值。如果需要更新，则需要使用 dmctl stop 任务后更新配置文件，然后再重新创建任务。
loaders.pool-size 可以使用配置项 loader-thread 替代来简化配置。
增量复制
增量复制相关的配置为 syncers，下面介绍和性能相关的参数如何配置。

worker-count
worker-count 为 DM Sync 阶段并发迁移 DML 的线程数量设置，默认值为 16，如果对迁移速度有较高的要求，可以适当调高改参数的值。

batch
batch 为 DM Sync 阶段迁移数据到下游数据库时，每个事务包含的 DML 的数量，默认值为 100，正常情况下不需要调整。

注意
syncers 的参数值不支持在迁移任务创建后更新，所以需要在创建任务前确定好各个参数的值。如果需要更新，则需要使用 dmctl stop 任务后更新配置文件，然后再重新创建任务。
syncers.worker-count 可以使用配置项 syncer-thread 替代来简化配置。
worker-count 和 batch 的设置需要根据实际的场景进行调整，例如：DM 到下游数据库的网络延迟较高，可以适当调高 worker-count，调低 batch。
-----------处理不兼容的DDL语句
handle-error
handle-error 命令用于处理错误的 DDL 语句。

---使用 handle-error <task-name> skip 命令跳过该 DDL 语句以恢复迁移任务
tiup dmctl --master-addr=172.16.10.71:8261 handle-error test skip
handle-error -h
Usage:
dmctl handle-error <task-name | task-file> [-s source ...] [-b binlog-pos] <skip/replace/revert> [replace-sql1;replace-sql2;] [flags]

Flags:
-b, --binlog-pos string position used to match binlog event if matched the handler-error operation will be applied. The format like "mysql-bin|000001.000003:3270"
-h, --help help for handle-error

Global Flags:
-s, --source strings MySQL Source ID
参数解释
task-name：

非 flag 参数，string，必选；
指定预设的操作将生效的任务。
source：

flag 参数，string，--source；
source 指定预设操作将生效的 MySQL 实例。
skip：跳过该错误

replace：替代错误的 DDL 语句

revert：重置该错误先前的 skip/replace 操作, 仅在先前的操作没有最终生效前执行

binlog-pos：

flag 参数，string，--binlog-pos；
若不指定，DM 会自动处理当前出错的 DDL 语句
在指定时表示操作将在 binlog-pos 与 binlog event 的 position 匹配时生效，格式为 binlog-filename:binlog-pos，如 mysql-bin|000001.000003:3270。
在迁移执行出错后，binlog position 可直接从 query-status 返回的 startLocation 中的 position 获得；在迁移执行出错前，binlog position 可在上游 MySQL 中使用 SHOW BINLOG EVENTS 获得。


TiDB Data Migration 日常巡检
本文总结了 TiDB Data Migration (DM) 工具日常巡检的方法：

方法一：执行 query-status 命令查看任务运行状态以及相关错误输出。详见查询状态。

方法二：如果使用 TiUP 部署 DM 集群时正确部署了 Prometheus 与 Grafana，如 Grafana 的地址为 172.16.10.71，可在浏览器中打开 http://172.16.10.71:3000 进入 Grafana，选择 DM 的 Dashboard 即可查看 DM 相关监控项。具体监控指标参照监控与告警设置。

方法三：通过日志文件查看 DM 运行状态和相关错误。

DM-master 日志目录：通过 DM-master 进程参数 --log-file 设置。如果使用 TiUP 部署 DM，则日志目录位于 {log_dir}。
DM-worker 日志目录：通过 DM-worker 进程参数 --log-file 设置。如果使用 TiUP 部署 DM，则日志目录位于 {log_dir}。



---------ticdc
编辑扩容配置文件,准备将 TiCDC 节点 15.1.1.52 加入到集群中去
[root@db51 ~]# vi scale-out-ticdc.yaml
cdc_servers:
- host: 15.1.1.52
gc-ttl: 86400
port: 8300
deploy_dir: "/tidb-deploy/cdc-8300"
log_dir: "/tidb-deploy/cdc-8300/log"

---运行扩容命令
vi scale-out-ticdc.yaml
tiup cluster scale-out <cluster-name> scale-out.yaml
tiup cluster scale-out tidb-test scale-out-ticdc.yaml -uroot -p

--扩容完毕后,检查 TiDB 数据库集群状态,检查 TiCDC 集群状态
tiup cluster display tidb-test

--使用 tiup ctl:v5.4.0 cdc 检查 TiCDC 的状态,如下
tiup ctl:v5.4.0 cdc capture list --pd=http://15.1.1.51:2379


---缩容 TiCDC 节点
--如果要缩容 IP 地址为 10.0.1.4 的一个 TiCDC 节点，可以按照如下步骤进行操作。

tiup cluster scale-in tidb-test --node 15.1.1.52:8300

----管理 TiCDC 服务进程 (capture)
查询 capture 列表：
cdc cli capture list --pd=http://10.0.10.25:2379

– id：服务进程的 ID。
– is-owner：表示该服务进程是否为 owner 节点。
– address：该服务进程对外提供接口的地址

---管理同步任务 (changefeed)
同步任务状态流转
同步任务状态标识了同步任务的运行情况。在 TiCDC 运行过程中，同步任务可能会运行出错、手动暂停、恢
复，或达到指定的 TargetTs，这些行为都可以导致同步任务状态发生变化。本节描述 TiCDC 同步任务的各状
态以及状态之间的流转关系。

--创建同步任务
--使用以下命令来创建同步任务：
tiup cdc cli changefeed create --pd=http://10.0.10.25:2379 --sink-uri="mysql://root:1@127.0.0.1:3306/" --changefeed-id="simple-replication-task" --sort-engine="unified"

--changefeed-id：同步任务的 ID，格式需要符合正则表达式 ^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$。如果
不指定该 ID，TiCDC 会自动生成一个 UUID（version 4 格式）作为 ID。
--sink-uri：同步任务下游的地址，需要按照以下格式进行配置，目前 scheme 支持 mysql/tidb/kafka
--start-ts：指定 changefeed 的开始 TSO。TiCDC 集群将从这个 TSO 开始拉取数据。默认为当前时间。
--target-ts：指定 changefeed 的目标 TSO。TiCDC 集群拉取数据直到这个 TSO 停止。默认为空，即 TiCDC 不 会自动停止。
--sort-engine：指定 changefeed 使用的排序引擎。因 TiDB 和 TiKV 使用分布式架构，TiCDC 需要对数据变
更记录进行排序后才能输出。该项支持 unified（默认）/memory/file：
– unified：优先使用内存排序，内存不足时则自动使用硬盘暂存数据。该选项默认开启。
– memory：在内存中进行排序。不建议使用，同步大量数据时易引发 OOM。
– file：完全使用磁盘暂存数据。已经弃用，不建议在任何情况使用。
--config：指定 changefeed 配置文件。
--sort-dir: 用于指定排序器使用的临时文件目录。自 TiDB v4.0.13, v5.0.3 和 v5.1.0 起已经无效，请不要使
用。

Sink URI 配置 mysql/tidb
配置样例如下所示：
--sink-uri="mysql://root:123456@127.0.0.1:3306/?worker-count=16&max-txn-row=5000";

参数解析
root 下游数据库的用户名
123456 下游数据库密码
127.0.0.1 下游数据库的 IP
3306 下游数据的连接端口
worker-count 向下游执行 SQL 的并发度（可选，默认值为 16）
max-txn-row 向下游执行 SQL 的 batch 大小（可选，默认值为 256）
ssl-ca 连接下游 MySQL 实例所需的 CA 证书文件路径（可选）
ssl-cert 连接下游 MySQL 实例所需的证书文件路径（可选）
ssl-key 连接下游 MySQL 实例所需的证书密钥文件路径（可选）
time-zone 连接下游 MySQL 实例时使用的时区名称，从 v4.0.8 开始生
效。（可选。如果不指定该参数，使用 TiCDC 服务进程的时区；如
果指定该参数但使用空值，则表示连接 MySQL 时不指定时区，
使用下游默认时区）

---查询特定同步任务
使用 changefeed query 命令可以查询特定同步任务（对应某个同步任务的信息和状态），指定 --simple 或 -s
参数会简化输出，提供最基本的同步状态和 checkpoint 信息。不指定该参数会输出详细的任务配置、同步状 态和同步表信息。
cdc cli changefeed query -s --pd=http://10.0.10.25:2379 --changefeed-id=simple-replication-task

{
"state": "normal",
"tso": 419035700154597378,
"checkpoint": "2020-08-27 10:12:19.579",
"error": null
}

state 代表当前 changefeed 的同步状态，各个状态必须和 changefeed list 中的状态相同。
tso 代表当前 changefeed 中已经成功写入下游的最大事务 TSO。
checkpoint 代表当前 changefeed 中已经成功写入下游的最大事务 TSO 对应的时间。
error 记录当前 changefeed 是否有错误发生。

cdc cli changefeed query --pd=http://10.0.10.25:2379 --changefeed-id=simple-replication-task

----停止同步任务
使用以下命令来停止同步任务：
tiup cdc cli changefeed pause --pd=http://10.0.10.25:2379 --changefeed-id simple-replication-task
以上命令中：
--changefeed-id=uuid 为需要操作的 changefeed ID。

----恢复同步任务
使用以下命令恢复同步任务：
tiup cdc cli changefeed resume --pd=http://10.0.10.25:2379 --changefeed-id simple-replication-task
以上命令中：
--changefeed-id=uuid 为需要操作的 changefeed ID。

--- 删除同步任务
使用以下命令删除同步任务：
tiup cdc cli changefeed remove --pd=http://10.0.10.25:2379 --changefeed-id simple-replication-task
--changefeed-id=uuid 为需要操作的 changefeed ID。


---更新同步任务配置
TiCDC 从 4.0.4 开始支持非动态修改同步任务配置，修改 changefeed 配置需要按照 暂停任务 -> 修改配置 -> 恢复任务 的流程。
tiup cdc cli changefeed pause -c test-cf --pd=http://10.0.10.25:2379

tiup cdc cli changefeed update -c test-cf --pd=http://10.0.10.25:2379 --sink-uri="mysql://127.0.0.1:3306/?max-txn-row=20&worker-number=8" --config=changefeed.toml;

tiup cdc cli changefeed resume -c test-cf --pd=http://10.0.10.25:2379
当前支持修改的配置包括：
changefeed 的 sink-uri
changefeed 配置文件及文件内所有配置
changefeed 是否使用文件排序和排序目录
changefeed 的 target-ts

-----------------------------------------
-------------Sink URI 配置 kafka
配置样例如下所示：
--sink-uri="kafka://127.0.0.1:9092/topic-name?kafka-version=2.4.0&partition-num=6&max-message-bytes=67108864&replication-factor=1"
URI 中可配置的的参数如下：
参数
解析
127.0.0.1
下游 Kafka 对外提供服务的 IP
9092
下游 Kafka 的连接端口
topic-name
变量，使用的 Kafka topic 名字
kafka-version
下游 Kafka 版本号。可选，默认值 2.4.0，目前支持的最低版本为 0.11.0.2，
最高版本为 2.7.0。该值需要与下游 Kafka 的实际版本保持一致。
kafka-client-id
指定同步任务的 Kafka 客户端的 ID。可选，默认值为
TiCDC_sarama_producer_同步任务的 ID。
partition-num
下游 Kafka partition 数量。可选，不能大于实际 partition 数量。如果不填，会自
动获取 partition 数量。
max-message-bytes
每次向 Kafka broker 发送消息的最大数据量（可选，默认值 64MB）
replication-factor
kafka 消息保存副本数（可选，默认值 1）
protocol
输出到 kafka 消息协议，可选值有 default、canal、avro、maxwell（默认值为
default）
max-batch-size
从 v4.0.9 引入。如果消息协议支持将多条变更记录输出到一条 kafka 消息，该
参数指定一条 kafka 消息中变更记录的最多数量，目前仅对 Kafka 的 protocol
为 default 时有效（可选，默认值为 16）
ca
连接下游 Kafka 实例所需的 CA 证书文件路径（可选）
cert
连接下游 Kafka 实例所需的证书文件路径（可选）
key
连接下游 Kafka 实例所需的证书密钥文件路径（可选）

-------------------------------------------