聊聊MySQL迁移到TDSQL相关稳定性
目录
一、背景
二、不推荐使用TDSQL分布式功能几点理由
三、TDSQL赤兔和扁鹊平台以外需要开发的功能
四、从MySQL迁移到TDSQL注意事项
一、背景
目前公司TDSQL私有云1k+实例（包含少量TDSQL分布式集群），数据量200多T，承载公司to b、职能，个别to c业务等，目前已稳定运行，聊聊TDSQL稳定性。
二、不推荐使用TDSQL分布式功能几点理由
下面从TDSQL 现有分布式架构，日常运维操作风险，平台应急保障功能，厂商应急保障SLA，Bug 或者Bug List 几个维度聊聊。建议通过其他中间件+ TDSQL 单实例代替 TDSQL分布式（目前这边中间件使用Sharding Sphere）
TDSQL分布式架构：
1、TDSQL的Proxy和DB不支持分开部署，Proxy的临时表和DB的binlog在相同SAS盘上，SAS盘性能较低，临时表写入时，挤占binlog IO，导致DB无法写入。（目前这边部署在SAS盘，可以要求部署在SSD盘）
日常运维操作风险：
1、TDSQL分布式 目前只支持多个分片并发执行DDL，锁超时/活跃线程飙高/延迟/服务器性能等影响服务器响应SLA, 业务受损比例变大。
2、分布式Online DDL变更工具只能使用pt-osc，意味着DDL执行前、中、后都可能带来风险，分布式加大了风险，并暂无计划切换到gh-ost
3、由于TDSQL 分布式 DDL变更与其他组件数据有耦合， 暂不支持用户通过gh-ost 替代去跑DDL，风险无法化解。
平台应急保障功能：
1、分布式DDL 任务管理，统一界面查看实例运行状况较差，影响提供应急保障功能 （可以通过平台开发建设，达到快速应急保障）
Bug 或者Bug List：
目前主要遇到的bug ：
1、批量插入只涉及单分片时，获取自增last_insert_id 与MySQL不一致，MySQL返回的是这批插入数据的最小ID，TDSQL返回的是这批数据的最大ID。下图为批量插入13条数据且落在同一个分片上，普通My SQL返回的是最小自增ID， 但TDSQL返回最大自增ID。
2、客户端兼容性问题：确保重连机制、执行DDL期间
在线 提交DDL以后， 尝试在页面查询这张表的数据，持续好几秒的时间提示如下几个报错：
mysql> select * from t1;
ERROR 2027 (HY000): Malformed packet
mysql> select * from t1;
No connection. Trying to reconnect...
Connection id: 121767678
报错原因以及修复方法：
onlineddl复制完数据，进行切换的瞬间多个set的表结构列数不一致
如果使用select * from tbl查询数据，多个set返回数据的列数不一致
导致结果集列包声明有6个列，但每行数据的内容只有5列；客户端因此报错Malformed packet，建议使用 select colname from tbl 进行规避；还需要保证客户端具备断线重连机制，截图如下；
3、已知XA bug：https://bugs.mysql.com/bug.php?id=94814
三、TDSQL赤兔和扁鹊平台以外需要开发的功能
目前TDSQL提供运维管理工具赤兔，赤兔包含资源管理，权限管理，慢查询，监控告警，应急保障，备份恢复等功能，DBbrige； 赤兔基本功能都已涵盖， 扁鹊主要监控；但以下功能需要研发：
1、监控缺乏集群维度、全实例为维度、机器与实例关联等维度
2、告警最小化原则还不够，个别告警指标不准确（比如实例宕机告警包含 获取MDL锁失败）
3、慢查询功能目前缺少集群维度，缺乏整体管理慢查询实例视角
4、应急保障功能需要在集群和全实例维度封装
5、独立备份库
四、从MySQL迁移到TDSQL注意事项
1、TDSQL语法兼容性（各个版本MySQL 与TDSQL语法兼容性）
2、客户端驱动兼容性
3、配置参数对比
4、性能测试、高可用测试
5、全量/增量迁移前后数据一致性（建议通过双写方式）