PCTA考试经验分享

考了OBCP，又从多个渠道听说TiDB和OceanBase的相似性，所以一直想了解TiDB原理。学习的最大驱动力就是考试了，所以就报了PCTA。

备考包括观看TiDB提供的【301 TiDB 系统管理基础】视频课程和学习TiDB提供的在线文档

https://learn.pingcap.com/learner/course/30002

TiDB 简介 | PingCAP Docs

文档可以直接下载PDF，学习很方便；视频的话就需要在线观看了

视频总共800分钟以上，TiDB建议观看60%就合格，但是强烈建议大家看完。刚开始正常速度看的，达到60%，后面备份恢复、复制迁移等时间不够，就草草观看了，谁知备份恢复、同步迁移的部分考试占比将近50%，导致第一次考试以32分失败。幸亏pcta免费，又报名了一周后的考试，就从后往前1.25倍速学习的。

1、报名通道

https://learn.pingcap.com/learner/certification-center/pcta

2、考试大纲和通过要求

https://learn.pingcap.com/learner/certification-center/syllabus/pcta

PCTA 认证考试为远程在线考试，考试时长 60 分钟，共 60 道题（单选 30 道，多选 30 道，每题 1 分）满分 60 分，36 分为及格

3、考前调试设备

【考试指南】PCTA&PCTP 在线考试操作指南 - 学习指南&经验分享 - TiDB 的问答社区

4、考试内容分析

（1）大纲之外的内容学习

出现了大纲中没出现的TiFlash、TiSpark、MPP、HTAP、分区表等内容，占比不多，但是需要了解。这些内容可以通过在线文档学习

TiFlash 可以兼容 TiDB 与 TiSpark，用户可以选择使用不同的计算引擎，TiFlash 暂时无法直接接受数据写入，任何数据必须先写入 TiKV 再同步到 TiFlash

TiDB 适合用于中等规模的 OLAP 计算，而 TiSpark 适合大规模的 OLAP 计算，用户可以根据自己的场景和使用习惯自行选择
MPP 模式仅对有 TiFlash 副本的表生效

用户可以使用 TiDB 或者 TiSpark 读取 TiFlash
也可使用 TiSpark 查询 TiKV 数据源

分区表的每个唯一键，必须包含分区表达式中用到的所有列

当前支持的类型包括 Range 分区、List 分区、List COLUMNS 分区和 Hash 分区，对于 Range Columns 类型的分区表，目前只支持单列的场景
Range 分区，List 分区和 List COLUMNS 分区可以用于解决业务中大量删除带来的性能问题，支持快速删除分区；Hash 分区则可以用于大量写入场景下的数据打散

TiFlash 简介 | PingCAP Docs

（2）TiDB系统变量和集群参数

变量的作用范围可以是全局范围有效 (Global Scope)、实例级别有效 (Instance Scope) 或会话级别有效 (Session Scope)

集群参数需要修改配置文件需重启集群生效（reload）

（3）TiDB监控 -- dashboard和Grafana+Prometheus

Grafana+Prometheus+Alertmanager的部署方式和查看，最好在创建TiDB的时候部署上

DashBoard的部署方式和查看，最好在创建TiDB的时候部署上，dashboard可以看到所有sql的执行情况，不止慢sql

（4）TiDB的数据文件和日志文件

TiDB只有日志文件没有数据文件；TiKV和PD既有数据文件也有日志文件

（5）LSM存储引擎和B-Tree存储引擎的适用场景

（6）TiDB的角色和用户

角色会被保存在 mysql.user 表中，角色名称的主机名部分（如果省略）默认为 '%'。如果表中有同名角色或用户，角色会创建失败并报错

角色在授予给用户之后，并不会生效；只有在用户启用了某些角色之后，才可以使用角色拥有的权限。可以对用户设置默认启用的角色；用户在登录时，默认启用的角色会被自动启用。（SET DEFAULT ROLE ALL TO 'dev1'@'localhost';）

修改用户密码的3种方式（注意考试时错误项的用户名不对）：

SET PASSWORD FOR 'test'@'localhost' = 'xxx';
ALTER USER 'test'@'localhost' IDENTIFIED BY 'mypass';
grant ** to 'test'@'localhost' identified by '';

（7）tiup工具

tiup从TiDB4.0开始引用，tiup主要安装、升级、卸载、清理、销毁TiDB集群

（8）TiDB Cluster的升级

在升级 TiDB 集群的过程中，请勿执行 DDL 语句

先升级 TiUP 版本 -> 再升级 TiUP Cluster 版本 -> 编辑 TiUP Cluster 拓扑配置文件，删除新版本不支持的参数 -> 检查当前集群的健康状况 -> 升级 TiDB 集群 -> 升级后验证版本和集群状态

（9）集群停止启动顺序

集群停止顺序：tiflash -> tidb -> tikv -> pd
集群启动顺序：pd -> tikv -> tidb -> tiflash

（10）TiDB各个组件扩容步骤

扩容 TiDB/PD/TiKV 节点：编写扩容拓扑配置 -> 执行扩容命令 -> 检查集群状态

扩容 TiFlash 节点，比上述的扩容操作多一步（其他相同）：开启 PD 的 Placement Rules 功能

（11）TimeZone

time_zone 的默认值是 System；优先使用 TimeZone 环境变量；如果失败，则从 /etc/localtime 的实际软链地址提取；如果上面两种都失败则使用 UTC 作为系统时区。

time_zone 的默认值是 System；优先使用 TimeZone 环境变量；如果失败，则从 /etc/localtime 的实际软链地址提取；如果上面两种都失败则使用 UTC 作为系统时区。
NOW() 和 CURTIME() 的返回值都受到时区设置的影响；只有 Timestamp 数据类型的值是受时区影响的，其实 Timestamp 持久化到存储的值始终没有变化过，只是根据时区的不同显示值不同
其它时间和日期类型，比如 Datetime/Date/Time 是不包含时区信息的，所以也不受到时区变化的影响。

还可以通过设置 session 变量 time_zone 为每个连接维护各自的时区

（12）TiKV的算子下推

TiKV -- coprocessor

TiDB -- Join

算子下推不需要显式指定，而是系统参数 tikv-client.copr-cache控制

TiDB 从 4.0 起支持下推计算结果缓存（即 Coprocessor Cache 功能）。开启该功能后，将在 TiDB 实例侧缓存下推给 TiKV 计算的结果，在部分场景下起到加速效果

不同 TiDB 实例之间不共享缓存
缓存的是下推计算结果，即使缓存命中，后续仍有 TiDB 计算
缓存以 Region 为单位。对 Region 的写入会导致涉及该 Region 的缓存失效。基于此原因，该功能主要会对很少变更的数据有效果
该功能对用户透明，开启和关闭都不影响计算结果，仅影响 SQL 执行时间
通常在以下场景下，下推计算的请求是相同或部分相同的：
SQL 语句完全一致，例如重复执行相同的 SQL 语句
SQL 语句包含一个变化的条件，其他部分一致，变化的条件是表主键或分区主键
SQL 语句包含多个变化的条件，其他部分一致，变化的条件完全匹配一个复合索引列。

（13）BR

BR 恢复到 TiCDC / Drainer 的上游集群时，恢复数据无法由 TiCDC / Drainer 同步到下游

在一次备份或恢复中，各个 TiKV 节点都会有一个对应的备份路径，恢复时会每个TiKV要有所有的备份文件

--ratelimit 选项限制了每个 TiKV 执行备份任务的速度上限
BR可以备份整个集群、单个数据库、单张表（--db 和 --table）

BR 可以并且会默认备份 mysql 数据库下的表，在执行恢复时，mysql 下的表默认不会被恢复

备份的时候仅仅在每个 Region 的 Leader 处生成该 Region 的备份文件。因此备份的大小等于数据大小，不会有多余的副本数据

（14）dumpling和lighting

Dumpling 可以通过 --snapshot 指定导出某个 tidb_snapshot 的数据

tidb lightning：几种后端导入数据的区别如下：
Local-backend（目标表必须为空，影响tidb对外服务）：tidb-lightning 先将数据编码成键值对并排序存储在本地临时目录，然后将这些键值对以 SST 文件的形式上传到各个 TiKV 节点，然后由 TiKV 将这些 SST 文件 Ingest 到集群中。和 Importer-backend 原理相同，不过不依赖额外的 tikv-importer 组件。
Importer-backend（目标表必须为空，影响tidb对外服务）：tidb-lightning 先将 SQL 或 CSV 数据编码成键值对，由 tikv-importer 对写入的键值对进行排序，然后把这些键值对 Ingest 到 TiKV 节点中
TiDB-backend（目标表可以不为空，不影响tidb对外服务）：tidb-lightning 先将数据编码成 INSERT 语句，然后直接在 TiDB 节点上运行这些 SQL 语句进行数据导入

使用多个 TiDB Lightning 向同一目标导入时，禁止混用不同的 backend，例如，不可同时使用 Local-backend 和 TiDB-backend 导入同一 TiDB 集群
与 TiDB-backend 模式不同，TiDB Lightning 在 Local-backend 模式下直到任务结束才会检测重复行

（15）TiDB Data Migration

TiDB Data Migration (DM) 是能将 MySQL/MariaDB（上游）的数据迁移到 TiDB （下游）的迁移工具；

分库分表 MySQL 合并迁移到 TiDB，可以使用 DM 进行分表合并迁移；

增量数据迁移：使用 TiDB DM 从 MySQL，MariaDB 或 Aurora 同步 Binlog 到 TiDB，该功能可以极大降低业务迁移过程中停机窗口时间

数据量大，你可以使用 Lightning 对分表数据进行快速合并导入（table-pattern = "table[3-4]"），然后根据业务需要选择是否使用 DM 进行增量数据 (Binlog) 的分表同步（DM：routes）

（15） TiDB Binlog

TiDB Binlog 是将 TiDB（上游）的修改同步给下游 TiDB 或者 MySQL、Kafka 的工具;

TiDB Binlog 的输入：TiDB 集群;

TiDB Binlog 的输出：TiDB 集群、MySQL、Kafka或者本地文件

TiDB Binlog 与 TiDB v5.0 版本开始引入的一些特性不兼容，无法一起使用，建议使用 TiCDC 替代 TiDB Binlog
Pump 用于实时记录 TiDB 产生的 Binlog，并将 Binlog 按照事务的提交时间进行排序，再提供给 Drainer 进行消费
Drainer 从各个 Pump 中收集 Binlog 进行归并排序，再将 Binlog 转化成 SQL 或者指定格式的数据，最终同步到下游。

当使用 TiDB DM (Data Migration) 将数据从上游 MySQL 或者 MariaDB 迁移到 TiDB 集群时，可使用 TiDB Binlog 保持 TiDB 集群与其一个独立下游 MySQL 或 MariaDB 实例或集群同步

下游是 TiDB/MySQL，需要同步的表中存在没有主键且没有唯一索引的表，这种情况会导致 binlog 性能下降，建议加主键或唯一索引
TiDB 配置中没有开启 binlog，需要修改 TiDB 配置 [binlog]
replicate-do-db 用于指定恢复的库，不指定的话，则全部都恢复
replicate-do-table 用于指定要恢复的表，不指定的话，则全部都恢复。

（16）TiCDC

TiCDC 是一款通过拉取 TiKV 变更日志（非binlog）实现的 TiDB 增量数据同步工具;

TiCDC 的输入：TiDB 集群;

TiCDC 的输出：TiDB 集群、MySQL、Kafka、Apache Pulsar、Confluent

（17）表ID等

TiDB 对每个表分配一个 TableID，每一个索引都会分配一个 IndexID，
每一行分配一个 RowID（默认情况下，如果表使用整数型的 Primary Key，那么会用 Primary Key 的值当做 RowID）
其中 TableID 在整个集群内唯一，IndexID/RowID 在表内唯一，这些 ID 都是 int64 类型

每行数据按照如下规则进行编码成 Key-Value pair：
Key: tablePrefix{tableID}_recordPrefixSep{rowID}
Value: [col1, col2, col3, col4]

对于 Index 数据，会按照如下规则编码成 Key-Value pair：

Key: tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue
Value: rowID

对于主键非整数或没有主键的表或者是联合主键，TiDB 会使用一个隐式的自增 RowID，大量 INSERT 时会把数据集中写入单个 Region，造成写入热点。AUTO_RANDOM可以解决热点

（18）schema version

schema version 的增长数量与每个 DDL 变更操作的 schema state 个数一致，例如 create table 操作会有 1 个版本变更，add column 操作会有 4 个版本变更（详情可以参考 online schema change），所以太多的 column 变更操作会导致 schema version 增长得很快

（19）执行计划

EXPLAIN 实际不会执行查询。EXPLAIN ANALYZE 可用于实际执行查询并显示执行计划。

如果 TiDB 所选的执行计划非最优，可用 EXPLAIN 或 EXPLAIN ANALYZE 来进行诊断

（20）Follower的读能力

Follower Read 功能是指在强一致性读的前提下使用 Region 的 follower 副本来承载数据读取的任务，从而提升 TiDB 集群的吞吐能力并降低 leader 负载
为了获得强一致读取的能力，在当前的实现中，follower 节点需要向 leader 节点询问当前的执行进度（即 ReadIndex），这会产生一次额外的网络请求开销，
因此目前 Follower Read 的主要优势是处理隔离集群的读写请求以及提升整体读取吞吐
为了允许在 TiKV 的 follower 节点进行数据读取，同时又不破坏线性一致性和 Snapshot Isolation 的事务隔离，Region 的 follower 节点需要使用 Raft ReadIndex 协议确保当前读请求可以读到当前 leader 上已经 commit 的最新数据。
在 TiDB 层面，Follower Read 只需根据负载均衡策略将某个 Region 的读取请求发送到 follower 节点

（21）TiDB事务

悲观事务模式下会在每个 DML 语句执行的时候，加上悲观锁，用于防止其他事务修改相同 Key，从而保证在最后提交的 prewrite 阶段不会出现写写冲突的情况。
在 TiDB 中，读取数据时，会获取一个包含当前物理时间且全局唯一递增的时间戳作为当前事务的 start_ts。
事务在读取时，需要读到目标 key 的 commit_ts 小于这个事务的 start_ts 的最新的数据版本。
当读取时发现目标 key 上存在 lock 时，因为无法知道上锁的那个事务是在 Commit 阶段还是 Prewrite 阶段，所以就会出现读写冲突的情况

5、总结

因为我也是考过obcp的，个人感觉pcta的难度跟obcp的差不多，考的比较细，除了官方给的视频还要看官方文档，每天抽2小时的话，需要10天的时间准备