为什么我们要从MySQL迁移到TiDB？

enum modify 为 tinyint 发现内容出现变化，原本的’'变成了 default 值，‘1’ 变成了 2，经测试 varchar 正常，因此不要尝试去变更 DM 备份出来的 Schema 文件来实现表结构变更，应该从上游 MySQL 解决。

⑤分区表元数据无法获取

没有视图可以查询当前已建分区信息。在 TiDB 中目前没有视图支持查询分区表已建分区信息，那么用户那边没有办法直观的判断当前已建的分区，以及当前是否需要及时的添加新分区。目前已转化为 PRM 产品需求，相信新版本不旧会实现。

分区表 - 部分分区 - limit 未下推：分区表出现 limit 未下推的现象，表 content_info_p 其中只有分区 p201911 有数据。该问题已在 3.0.6 版本修复。

mysql.tidb 表权限异常：使用 use db_name 或者 mysql 客户端指定 DB name 后，可以对该表进行查询或更新操作。计划 3.1 版本修复。

事物的限制：单个事物的 SQL statement 不超过 5000(stmt-count-limit 参数可调);每个键值对不超过 6M;键值对的总数不超过 300000;键值对的总大小不超过 100M。

注：键值对是指一张表里有 2 个索引，那么一共就是数值 +2 个索引，总共 3 个键值对，那么每个键值对的总是不能超过 30 万/3=10 万。

一行数据会映射为一个 KV entry，每多一个索引，也会增加一个 KV entry，所以这个限制反映在 SQL 层面是：总的行数*(1+索引个数)<30w。

官方提供内部 batch 的方法，来绕过大事务的限制，分别由三个参数来控制：

tidb_batch_insert

tidb_batch_delete

tidb_dml_batch_size

写热点的处理：如果可以去掉 MySQL 自增主键，就可以通过建表时指定 SHARD_ROW_ID_BITS、PRE_SPLIT_REGION 来实现预切分，避免单调自增引发的只往某个 KV 上写数据引起的热点问题。

详情可参考官网 TiDB 专用系统变量和语法中 SHARD_ROW_ID_BITS 的介绍。

⑥TiDB 监控和 DM 监控 Ansible 部署数据冲突

这块可以通过将 TiDB 和 DM 监控部署到不同的机器上来绕过解决，否则就会出现通过 Ansible 安装后，ansible-playbook rolling_update_monitor.yml --tags=prometheus 时，两者只有一个是正常的。

磁盘已使用不建议超过 50%：数据量太多 LSM 过大， compaction 成本会很高，并且内存命中率下降，同时单机恢复时间很长，50% 左右最好，使用率太高，如果突然写入爆增，region 来不及调度会写满磁盘，有风险。

因此建议 SSD 不要使用超过 2T 的，采用更多的机器会有更好的性能。

⑦Mydumper 导致的内存和网卡打满

在使用 Mydumper 备份大时，会打满 TiDB 网卡，同时会消耗 TiDB、TiKV 更多的内存。

【TiDB ERR】[emergency]TiDB_schema_error:192.168.1.1:10080,[add_dba_mysql]【360】 

【TiDB ERR】[critical]NODE_memory_used_more_than_80%:192.168.1.2:9100,[add_dba_mysql]【360】 

去抓取慢日志会看到如下内容：

grep Query_time tidb_slow_query-2019-12-24T04-53-14.111.log|awk -F : '$2>10' 

# Time: 2019-12-24T03:18:49.685904971+08:00 

# Txn_start_ts: 413433784152621060 

# User: backup@192.168.1.3 

# Conn_ID: 4803611 

# Query_time: 4002.295099802 

SELECT /*!40001 SQL_NO_CACHE */ * FROM `360`.`t_d` ; 

期待后续的版本物理备份，逻辑备份看起来目前是可以备份，但会比较消耗资源，同时恢复时间也会更久。

展望

从 TiDB 2.x 开始我们就已经开始进行测试了，最终选择的版本是 3.0.2，后续升级到 3.0.5。

上述文章总结和一些案例希望能够帮助到已使用或打算使用 TiDB 的朋友。

360 云平台 DBA 团队也计划将 TiDB 推上 360 HULK 云平台，为 360 集团更多的业务线提供丰富多彩和稳定可靠的数据库服务。

在这里首先要感谢 PingCAP 同学及时的技术支持，帮助我们尽快的解决了一些技术问题。

同时，我自己也通读完了 TiDB 的官方手册。从 Ansible 部署、二进制部署、升级、DM、Lighting、Pump、Drainer、调优、排障、迁移、备份，这一路打怪下来，切身感受到了 TiDB 越来越好的过程。

我相信未来随着 3.1 和 4.0 版本的推出，有更多人加入使用 TiDB 的这个队伍中来。

从业务给我们的反馈也是对 TiDB 的使用情况表示满意，我们相信，TiDB 会在大家共同的努力下，越来越好。

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!