TiDB丨从MySQL迁移至TiDB的常见问题及解决方案

深碍√TFBOYSˉ_ 2023-10-03 23:01 90阅读 0赞

> 提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

#### 文章目录 ####

*  一、前言
 *  二、GC设置过长的问题
 *   *  为什么在MySQL里可设置，保留更多的历史数据，而TiDB不行？
     *  TiDB中历史版本过多问题及排查方法
 *  二、SQL调优方式对比和SQL调优方法
 *   *  日常SQL调优分析对比
     *  MySQL迁移到TiDB后，可能会遇到的一些SQL调优的工作
 *  三、热点问题
 *   *  热点的排查与解决
     *  大范围热点处理
 *  四、总结

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

## 一、前言 ##

集团有一套业务库，对接淘宝流量。据说每年双11的时候，流量过大都会导致各种问题，苦不堪言。

经过内部评估，我们决定将这套系统从MySQL迁移到更适合大数据量的TIDB上。

经过团队的共同努力，我们完成了迁移，并在2022年“双11”期间经受住了考验，所以本期就跟大家分享一些从MySQL迁移到TIDB，我们遇到的问题，以及最后是如何解决。

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

## 二、GC设置过长的问题 ##

由于这套系统之前是跑在MySQL上，所以初期数据库的一些工作，是由MySQL的DBA和我们TiDB团队一起协作完成的。

某一天我们突然发现，集群的druation突然上升，并且是在没有更多请求的情况下，延迟上升了。

经排查发现，是MySQL的dba为了在数据库中保存最近7天的数据，并且实现误操作闪回，将 tidb\_gc\_life\_time 这个参数由1h改成了7d，从而导致tikv中历史版本过多，导致每次磁盘读取会扫描过多的无用数据，导致的整体变慢。

### 为什么在MySQL里可设置，保留更多的历史数据，而TiDB不行？ ###

基于 MySQL DBA 的操作，我思考了一下：为什么它直接就将GC保留的时间设置长了？

研究发现，**MySQL的闪回是通过本地保存binlog日志实现**的，且MySQL中，事务的一致性读是通过undo log实现的，所以这里并不会显著的影响正常数据的查询。

而**在TiDB中，闪回和一致性读是直接依赖本地保留的历史版本数据**，直接保存各个版本数据，实现mvcc，再通过GC定期清除历史版本数据。

MySQL在进行mvcc控制的时候，读取历史的版本依赖的是：事务开始时间戳、当前的数据、undo log日志链。

在事务中在读取历史版本数据时，会先找到最新的数据，依靠每行数据自带的回滚指针，去undo log 中找到事务开始时间戳前最近的一个版本，按时间有序的链表查找历史数据。

![在这里插入图片描述][b7de61ec5dee4878b1b2c4dbbb1c9e11.png_pic_center]  
而在TiDB中，所有的dml操作都转化为在磁盘中进行追加一行新的数据，**最新的数据和历史版本的数据都保留在一起了**。

在读取数据时，会先将附近版本的数据全部读取，再根据所需版本进行过滤，这样当保留了过多版本的历史数据时，每次读取都会读取很多无用的数据，造成性能开销。

![在这里插入图片描述][f538607b3c5f4793a4c44d8bb23c8236.png_pic_center]  
![在这里插入图片描述][2496d344d39c427a896859788cd069df.png_pic_center]

### TiDB中历史版本过多问题及排查方法 ###

在前面的推文中，我们分享过一期关于历史版本过多的排查方法，比较直观的描述了历史版本数据过多时，对于SQL执行直接的影响，大家有兴趣的可以回看→[《一次TiDB GC阻塞引发的性能问题分析》][TiDB GC]

![在这里插入图片描述][1c7d52abb589450989cb10f784e27f5c.png_pic_center]

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

## 二、SQL调优方式对比和SQL调优方法 ##

SQL作为和数据库交互的标准语言，SQL调优是DBA以及数据库使用者绕不开的东西。

这里我们看看相比于MySQL的SQL调优方式，在TiDB中的不同之处，以及将业务从MySQL迁移到TiDB后，SQL方面需要做的一些工作。

### 日常SQL调优分析对比 ###

在MySQL数据库的日常调优中，免不了有类似需求：

#查询频率
    show global status like 'com*'
    #查看慢查询日志
    cat slow_query.log
    #查看sql耗时以及到底耗费在哪里
    show profile for query query_id
    #查看sql执行计划，分析效率
    explain query

而在TiDB中，集群自带的监控dashboard，可以满足所有上述需求，并且还拥有统计功能、top功能、多种条件过滤功能，帮助分析异常以及SQL调优，非常方便。

![在这里插入图片描述][589870f4bcf94286b5de86ea76ba8869.png_pic_center]

### MySQL迁移到TiDB后，可能会遇到的一些SQL调优的工作 ###

在MySQL迁移至TiDB后，有一部分原来执行没有性能问题的SQL，在TiDB中出现了性能问题，主要有如下：

**1. 偶发性的复杂SQL的连接算子不合理**

这类SQL主要表现为比较复杂的SQL，且SQL中的表连接是隐式连接时，出现几率大。

\*\*解决方案：\*\*绑定执行计划，此方案对应用代码没有侵入性，且方便快捷。

**2. SQL执行逻辑不佳**

在部分复杂SQL中，在不影响SQL最终结果的前提下，先过滤计算某一部分结果作为临时表，会使整个SQL的效率提高。

在部分场景中，MySQL优化器能自动优化处理，TiDB的执行计划不太合理。

\*\*解决方案：\*\*这种通常只有改写SQL，在SQL中去显示的制作临时表。

**3. 部分小bug**

这种问题通常指**某些SQL导致的异常行为，多在后续版本中被修复了**。例如某些场景下index hash join算子会存在一些问题，通过hint其他算子可绕过。

**解决方案**：在github搜索相关issue或者pr，或者社区提问。

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

## 三、热点问题 ##

相比于单机的MySQL数据库，**分布式TiDB优势之一就是可以利用分布式集群多机器的能力，来突破单机的瓶颈。**

但在某些时候，由于数据分布不合理，或者是业务专一的访问某一小部分的数据，这种时候可能会导致分布式集群中单机的瓶颈成为整个集群的瓶颈，这就是热点问题。

### 热点的排查与解决 ###

通常我们**排查热点最常见的方法就是dashboard中的热力图**，来确认排查热点，越亮的区域，表示流量越高。

![在这里插入图片描述][7c731871b955482f92a6fc9a6d40caf5.png_pic_center]  
但是有时候，我们很难去确认哪些流量才是真正达到了某一单机器的瓶颈，我这里提供一个方法：

1、查询都热点，得到region_id和都流量数值
    （在一般系统中，70%以上的请求为读请求）
    SELECT DISTINCT region_id ,read_bytes 
    FROM INFORMATION_SCHEMA.tikv_region_status WHERE ORDER BY READ_BYTES DESC
    
    2、尝试去切分热点region
    tiup ctl:v5.3.2 pd -u http://10.0.*.*:2379 operator add split-region $id --policy=scan
    
    3、若观察到切分该region后duration有比较明显的下降，则说明该流量比较容易达到机器瓶颈
    （当然一台机器肯定不止只有一个region被访问，所以这里其实是一个观察性质的经验，不是具体某一个数值）

结合确定的流量瓶颈，我写了个简单的脚本挂在crontab，每隔20分钟执行一次，效果不错！

#!/bin/bash
    
    #打印当前时间
    echo "############################################">>/home/tidb/log/split-hot-region.log
    date>>/home/tidb/log/split-hot-region.log
    
    #查找读流量大于5G的region
    hot_id=`mysql -h10.0.*.* -P4000 -uroot -p* -e"SELECT DISTINCT region_id  FROM INFORMATION_SCHEMA.tikv_region_status WHERE  READ_BYTES >5368709120 ORDER BY READ_BYTES DESC"`
    
    #打印热点region_id和读流量到日志
    echo "当前读热点为：">>/home/tidb/log/split-hot-region.log
    mysql -h10.0.*.* -P4000 -uroot -p**** -e"SELECT DISTINCT region_id ,read_bytes FROM INFORMATION_SCHEMA.tikv_region_status WHERE  READ_BYTES >5368709120 ORDER BY READ_BYTES DESC
    ">>/home/tidb/log/split-hot-region.log
    
    source  /home/tidb/.bash_profile
    for id in $hot_id
    do
    if [ $id != 'region_id' ];
    then
    tiup ctl:v5.3.2 pd -u http://10.0.*.*:2379 operator add split-region $id --policy=scan
    sleep 1s
    tiup ctl:v5.3.2 pd -u http://10.0.*.*:2379 operator add split-region $id --policy=scan
    sleep 1s
    tiup ctl:v5.3.2 pd -u http://10.0.*.*:2379 operator add split-region $id --policy=scan
    sleep 1s
    tiup ctl:v5.3.2 pd -u http://10.0.*.*:2379 operator add split-region $id --policy=scan
    sleep 1s
    tiup ctl:v5.3.2 pd -u http://10.0.*.*:2379 operator add split-region $id --policy=scan
        if [ $? -eq 0 ]; then
            echo "已成功切分region "$id>>/home/tidb/log/split-hot-region.log
        else
            echo "切分region"$id"失败">>/home/tidb/log/split-hot-region.log
        fi
    fi
    done

当然也可以通过调整系统参数实现。

![在这里插入图片描述][a88e1351b9124efcae10318acd5c9c28.png_pic_center]

### 大范围热点处理 ###

有些时候，热点可能是由于SQL不合理所导致的，例如对某张表的查询没有建立索引，导致每次都是全表扫之后再过滤，导致大块热点。如果有索引，每次定向读取少量数据，就不会有热点。

**排查与解决方案：**

通常碰到这种类似问题之后，**根据热力图中的表名去查询相关的SQL，去验证执行计划中是否走了索引，后续添加索引**。

也有一部分为SQL写的不合理，每次请求大量的数据，到应用服务器之后再进行过滤，这种就需要与开发进行讨论添加过滤条件。

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

## 四、总结 ##

TiDB作为兼容MySQL的分布式数据库，**未来必然会有越来越多的业务从MySQL上面迁移到TiDB**，我希望有越来越多的案例和经验可以被分享出来，作为参考。

关于今天的迁移干货分享就到这里了，欢迎大家一起交流~

[b7de61ec5dee4878b1b2c4dbbb1c9e11.png_pic_center]: https://img-blog.csdnimg.cn/b7de61ec5dee4878b1b2c4dbbb1c9e11.png#pic_center
[f538607b3c5f4793a4c44d8bb23c8236.png_pic_center]: https://img-blog.csdnimg.cn/f538607b3c5f4793a4c44d8bb23c8236.png#pic_center
[2496d344d39c427a896859788cd069df.png_pic_center]: https://img-blog.csdnimg.cn/2496d344d39c427a896859788cd069df.png#pic_center
[TiDB GC]: https://digitalchinawuhan.blog.csdn.net/article/details/127878315
[1c7d52abb589450989cb10f784e27f5c.png_pic_center]: https://img-blog.csdnimg.cn/1c7d52abb589450989cb10f784e27f5c.png#pic_center
[589870f4bcf94286b5de86ea76ba8869.png_pic_center]: https://img-blog.csdnimg.cn/589870f4bcf94286b5de86ea76ba8869.png#pic_center
[7c731871b955482f92a6fc9a6d40caf5.png_pic_center]: https://img-blog.csdnimg.cn/7c731871b955482f92a6fc9a6d40caf5.png#pic_center
[a88e1351b9124efcae10318acd5c9c28.png_pic_center]: https://img-blog.csdnimg.cn/a88e1351b9124efcae10318acd5c9c28.png#pic_center