在线学习地址：https://learn.pingcap.com/learner/course/1110001

软件包下载地址：https://cn.pingcap.com/product-community/

Lesson 01 TiDB Cluster 部署

• TiUP 是从 TiDB 4.0 引入的包管理器
• TiUP 在执行时，命令 和组件 < component > 可以同时出现
• TiDB 集群启动顺序：PD => TiKV => TiDB => TiFlash；停止顺序是启动顺序倒序
• tiup cluster start tidb-test --init 安全启动，为 root 用户生成初始密码
• set password = password('new pwd'); 可修改密码

Lesson 02 TiDB 的连接管理

• 100% 兼容 MySQL 5.7 协议
• 支持 MySQL 5.7 常用的功能及语法
• 不支持的功能特性：存储过程与函数、触发器、外键、函数、全文索引、CREATE TABLE AS SELECT
• TiDB 默认端口 4000
• 查看 TiDB 版本：select tidb_version()\G

Lesson 03 TiDB 的配置

• TiDB 配置分两类

1. 系统配置：TiDB Server，跟 SQL 有关的，存在 TiKV 里，更新配置不需要重启，可以通过 MySQL 客户端进行修改，有作用域
2. 集群配置：TiKV、PD、一部分的 TiDB Server，存在自己节点的配置文件中，重启节点方可生效，没有作用域

• TiDB 系统参数的作用域：SESSION（会话级别，默认）、GLOBAL（全局级别）、INSTANCE（实例级别）
• 修改集群配置：tiup cluster edit-config tidb-test，之后 tiup cluster reload tidb-test 重启所有节点应用新配置。tiup cluster show-config tidb-test 查看配置。
• 6.0 有在线修改集群配置，但是实验特性，所以集群配置的修改还是需要重启节点才能生效

Lesson 04 用户管理与安全

• 查看用户信息

  select user, host, authentication_string from mysql.user;

• 创建/删除用户

  create user 'jack'@'172.31.0.%' identified by 'pingcap';
  drop user 'user3'@'localhost';

• 修改密码

  SET PASSWORD FOR 'test'@'localhost'=password('mypass');
  ALTER USER 'test'@'localhost' IDENTIFIED BY 'mypass';

• 创建/删除角色

  create role r_emp@'172.31.0.159';
  create role r_emp@'%';
  create role r_emp;
  drop role 'r_admin','r_dev'@'localhost';

• 授权

    grant select,insert on test.emp to 'jack'@'172.31.0.159';
    grant select,insert on test.emp to 'r_emp';
    -- 赋予用户全部权限
    grant all privileges on *.* to 'user2'@'localhost' with grant option;
    -- 将角色赋予用户
    grant r_emp to 'jack'@'172.31.0.%';
    -- 拥有角色的用户登录后，需开启角色
    set role all;
    -- 查看授权
    show grants;
    show grants for 'admin'@'localhost';
    -- 回收用户全部权限
    revoke all privileges on *.* from 'user2'@'localhost';

• 角色与用户相似之处为：

1. 是被锁住（locked）的（不能用于登录）
2. 没有密码
3. 被存储在 mysql.user 表中
4. 当用户登录后，必须使用 set role all 命令开启用户被赋予的角色

• 忘记 root 密码的解决办法：

1. 修改配置文件

   [security]
   skip-grant-table = true

2. 重启数据库后生效 mysql -h 127.0.0.1 -P 4000 -u root

Lesson 05 监控 TiDB

• 两套体系：

1. Grafana + Prometheus —— http://{grafana-ip}:3000，用户名密码默认 admin / admin
2. TiDB Dashboard —— http://{pd-ip}:2379/dashboard，root / tidb

• 确认 TiDB 集群状态

  $ tiup cluster display didb-test

• 报警项由低到高分为：警告、严重、紧急 三个级别

Lesson 06 TiDB 集群管理

• TiDB/TiKV/PD 在线扩容步骤：

1. 编辑配置文件
2. 执行扩容命令 tiup cluster scale-out tidb-test scale-out-tikv.yaml -uroot -p
3. 确认新节点是否加入 tiup cluster display tidb-test

• TiFlash 在线扩容

1. 确认当前 TiDB 的版本支持 TiFlash
2. Enable-plcaement-rules 开启参数
3. 编辑配置文件
4. 执行扩容命令
5. 确认新节点加入

• TiDB/TiKV/PD 在线缩容步骤：

1. 查看节点 ID 信息 tiup cluster display tidb-test
2. 执行缩容操作 tiup cluster scale-in tidb --node <node-IP>:<node-Port>，执行后节点变为 Tombstone 状态，可继续通过 tiup cluster prune tidb-test 命令清理节点
3. 检查集群状态

• TiFlash 在线缩容

1. 根据 TiFlash 剩余节点数调整数据表的副本数 alter table <db-name>.<table-name> set tiflash replica 0;
2. 确认表的副本已经被删除 SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA='<db_name>' and TABLE_NAME='<table_name>'
3. 查看节点 ID 信息
4. 通过 TiUP 缩容 TiFlash 节点
5. 检查集群状态

• 重命名集群 tiup cluster rename ${cluster-name} ${new-name}
• 清理集群数据 tiup cluster clean ${clust4er-name} --xxx，清理会停库，再使用需要重新启动 TiDB，清理后 root 用户没有密码了，可以直接登录

1. --log 清理日志
2. --data 清理数据
3. --all 清理日志和数据

• 销毁集群 tiup cluster destroy tidb-test
• 查看全局和 session 的时区：

  select @@global.time_zone, @@session.time_zone;

• 设置 session 级别时区

  set session time_zone='UTC';

• Datetime 类型不受时区影响，timestamp 类型受时区影响

Lesson 07 升级 TiDB Cluster

• 升级集群上的所有 TiDB 实例，-R 指定要升级的组件，tidb、tikv、pd 等

  $ tiup cluster patch ${cluster-name} /tmp/tidb-hotfix.tar.gz -R tidb

• 替换其中一个 TiDB 实例

  $ tiup cluster patch ${cluster-name} /tmp/tidb-hotfix.tar.gz -N ${Node_IP}:${Node_Port}

• 升级 TiDB 集群分为不停机升级和停机升级
• 版本升级流程：升级 TiUP => 修改 TiUP Cluster 拓扑配置文件 => 检查当前集群健康状况 => 将集群升级到指定版本 => 验证
• 5.3 之前 TiFlash 不支持在线升级
• 升级时报错中断，处理完报错后如何继续

  # 查看操作记录，找到失败的升级操作记录的 ID
  $ tiup cluster audit
  # 重试上次的升级操作记录
  $ tiup cluster replay <audit-id>

• 升级过程中 evict leader 等待时间过长，如何跳过该步骤快速升级

  $ tiup cluster upgrade <cluster-name> <version> --force

Lesson 08 备份恢复策略

• 备份的类型

1. 热备份：允许读写，对性能有影响，TiDB 采用 MVCC 方式实现
2. 冷备份：不允许读写
3. 温备份：允许读，不允许写

• 按输出分类：

1. 逻辑备份：SQL、CSV，可读性好，速度慢，支持异构数据迁移
2. 物理备份：二进制副本，恢复速度快，不可读，只能同构恢复
3. 基于复制增量备份：主从模式，对主库影响小，主库出问题备库能立即提供服务

• BR 是热备份 & 物理备份

Lesson 09 数据导出工具 Dumpling

• 用于完成逻辑上的全量备份或者导出，不支持增量导出
• 支持 table-filter，筛选数据导出
• 适用于数据量小于 50G 的导出场景
• 导出数据的一致性：通过 –consistency 标识控制导出数据，默认是 Snapshot 级别（获取指定时间戳的一致性快照），还有 Flush（全库加只读锁）, Lock（给要导出的表加读锁）, None（不要一致性）, Auto（根据数据库类型，如果是 TiDB，设置为 Snapshot，如果是 MySQL，设置为 Flush）

  $ ./dumpling --snapshot 417773951312461825
  $ ./dumpling --snapshot "2020-07-02 17:12:45"

Lesson 10 使用 TiDB Lightning 导入数据

• TiDB Lightning 是导入 SQL、CSV 至 TiDB 的工具
• TiDB Lightning 的两种导入模式：

1. Physical Import Mode
2. Logical Import Mode：连到 TiDB Server 上执行 SQL
   

• Physical Import Mode 原理

1. 切换 TiKV 为导入模式
2. Schema & 表创建
3. 分割源数据
4. 读取 dump 文件
5. 写入本地临时文件（转换成 key-value 格式，并排序）
6. 导入临时文件到 TiKV 集群
7. 检验与分析
8. 切换回普通模式

• 并行导入时，TiDB Lightning 实例数不宜超过 10 个
• 支持断点续传，断点可以存储在文件或数据库中
• 逻辑模式不直接写 TiKV，是向 TiDB Server 执行 SQL

Lesson 11 使用 BR 进行备份恢复

• BR —— Backup & Restore
• BR 直接与 PD 和 TiKV 交互，不经过 TiDB Server
• BR 是二进制备份，只能恢复到 TiDB 数据库中
• 备份输出文件：SST 文件、backupmeta 文件、backup.lock 文件
• TiDB 5.4 版本之后才开始支持 GBK 字符集
• BR 恢复的工具无法通过 TiCDC 或 TiDB Binlog 同步到下游
• 备份时，每个 TiKV 备份自己 TiKV 节点里存储的数据
• 恢复时，要将各个节点的数据先进行汇总，保证每个节点都有全量的恢复数据，才能进行恢复

    $ br backup/restore full/db/table \
    --pd "${PDIP}:2379" \
    --db test \
    --table usertable \
    --storage "s3://backup-data/table/" \
    --ratelimit 128 \
    --log-file backup.log

• 增量备份需先获得最近一次备份的时间点，并传入备份指令
• BR 是热备份，物理备份，支持增量备份 & 恢复

Lesson 12 使用 sync-diff-inspector 校验数据

• 原理：并行切分数据并行比较，比较时采用二分法，缩小逐行比较的范围
• 限制：

1. 不支持 JSON、BIT、BINARY、BLOG 等类型的数据
2. FLOAT、DOUBLE 等浮点数类型无法在 TiDB 和 MySQL 之间进行校验
3. 不包含主键或者唯一索引的表可以进行校验，但修复 SQL 可能无法正确修复数据
4. MySQL 与 TiDB 之间或者 MySQL 与 MySQL 之间的数据校验不支持数据同步在线校验

• sharding 选项默认打开，支持源端分表分库目标并表的验证

Lesson 13 使用 TiDB DataMigration（DM）同步数据

• 一个 DM worker 对应上游的一个数据库实例，读取上游 binlog 进行同步
• 数据源多于 worker 数量时，多出的 worker 空闲
• DM 的目标端只能是 TiDB，源端可以是多个兼容 MySQL 协议的数据库
• DM 依赖源端数据库开启 binlog，可以通过 binlog event filter 过滤某些操作不进行复制
• 用户通过 dmctl 命令行工具向 DM master 发送指令，DM master 再操作 DM worker 进行同步
• 支持全量及增量同步、源库表与目标库异构表的同步、进行分表分库的合并同步
• DM 可以支持一定程度的异构表迁移，只要异构表存在包含关系（源库不能选择列，需要复制全部列；目标表的列可以多于源库表的列）
• DM 部署相关命令

  $ tiup install dm dmctl
  $ tiup dm display dm-test
  $ tiup dm start dm-test
  $ tiup dm list
  # DM 集群缩容
  $ tiup dm scale-in dm-test -N 172.31.0.175:8262
  # DM 集群扩容
  $ tiup dm scale-out dm-test dm-scale.yaml -uroot -p
  $ tiup dm stop dm-test
  $ tiup dm destory dm-test

• DM 的任务包含：源端、目标端、数据过滤（黑白名单、事件过滤）和表路由
  

  # 检查与启动任务
  $ tiup dmctl --master-addr=172.31.0.49:8261 start-task dm-task.yaml
  # 暂停任务
  $ tiup dmctl --master-addr=172.31.0.49:8261 pause-task dm-task.yaml
  # 恢复任务
  $ tiup dmctl --master-addr=172.31.0.49:8261 resume-task dm-task.yaml
  # 查询任务
  $ tiup dmctl --master-addr=172.31.0.49:8261 query-status dm-task.yaml
  # 停止任务
  $ tiup dmctl --master-addr=172.31.0.49:8261 stop-task dm-task.yaml

Lesson 14 使用 TiCDC 同步数据

• 数据源是 TiDB，下游是兼容 MySQL 协议的数据库或 kafka 等，与 DM 是反向的
• TiCDC 集群中的一个节点负责多个 TiKV
• TiCDC 读取的是 TiKV 的 changelog，比 TiDB Binlog 的效率高
• TiCDC 是异步复制，目标端与源端有时间延迟；源头数据库出现灾难后依然有丢失数据的可能
• TiCDC 只能同步至少存在一个有效索引的表
• 同步任务不能在线修改配置，需要先 pause，然后 update，再 resume
• TiCDC capture 可以有多个，并行从 TiKV 读取 changelog；导入目标端时，一个 capture 对应一个目标端，但是会将其他 capture 中的数据复制到自己这再向下游同步。只有负责汇聚数据的 capture 里才有全量的 changelog 数据
• TiCDC 目标端不支持 Oracle
• Changelog 抽取到 TiCDC 中时，会在本地进行排序
• TiCDC 可以通过 TiDB 集群的拓扑文件进行部署及扩缩容

Lesson 15 使用 TiDB Binlog 同步数据

• TiDB Binlog 的作用与 TiCDC 类似，TiDB 5.0 版本后，推荐使用 TiCDC 替代 TiDB Binlog
• 只能做增量复制，不能做全量复制
• 可以使用 tiup 工具为 TiDB 集群增加 TiDB Binlog 所使用的 pump 和 drainer 节点
• Pump 会先将数据进行排序，之后发送给 drainer，drainer 再进行合并排序
• TiDB Binlog 类似 MySQL row 格式的 binlog，记录的是已经提交的事务，默认未开启
• Pump 不是从 TiKV 读取，是直接从 TiDB 读取 TiDB 产生的 binlog 日志
• 一个 drainer 对应一个目标端

Lesson 16 数据库高可用概述

• 恢复时间目标（Recovery Time Objective，RTO）
• 恢复点目标（Recovery Point Objective，RPO）
• TiDB 支持 CP，不支持 AP，出现网络隔离时，保证一致性，不保证可用性
• TiDB 数据库提供强一致性，如不能保证强一致性，则拒绝服务
• 故障解决会伴随有服务的降级

Lesson 17 TiDB 数据库常用高可用架构

• 同城三中心：网络延迟小，RTO 较小，RPO 为 0
• 同城两中心（50km 内），中心之间同步复制，DR AutoSync，建议四副本，3 voter 1 leaner，非极端情况可保证 RPO = 0
• 两地三中心，城市之间是异步复制，不能保证 RPO = 0 和一致性恢复
• 异步复制是通过 TiDB Binlog 或 CDC 组件完成，会丢失数据（RPO 不为 0），有损恢复后，保证一致性