失败的数据库迁移UDB

　　公司采用的是ucloud的云主机，数据库也是架设在云主机上。由于数据越来越多数据查询数据越来越慢，所以我决定往 UDB上迁移。当时考虑的理由如下：

（1）云主机底层架设在虚拟机上IO性能有折损，而UDB底层直接就是物理机集群IO性能有保障。

（2）UDB便于维护，直接就能查看各项性能指标及当前实时状态。

（3）方便的主从设置和扩展伸缩，主库配置好后，设置从库点两下鼠标就搞定，而且能随时改变配置满足不同时段的性能要求。

事实证明我还是太年轻了。

迁移步骤，

（1） 配置UDB主库

　　主库主要负责写入数据，所以配置的比较低，为1.5G内存100G存储

（2） 导出云主机mysql主数据库

　　采用mysqldump命令导出数据，导出文件sql文件大小为3G，耗时几分钟。

（4） 导入UDB

　　采用sourse命令导入，导入耗时2个小时多。（这时我就开始担心性能问题）

（5） 测试UDB主库

　　测试结果很不理想UDB的性能比云主机满了几倍，这个结果不科学。

（6）新建UDB从库

　　配置为3G内存100G存储

测试步骤

执行同样的sql语句进行对比

180万数据单表  全表扫描查询

UDB  5分11秒

 

云主机 28秒

 

难道是UDB配置过低问题？

看看udb的状态

 

都很正常没啥问题，为啥那么慢呢？升级到3G内存

再试试 表关联删除数据

最长的执行时间为4分钟

而在云主机上最长执行时间为25秒

 

再查看UDB状态发现有几条慢查询的执行。

那就查看一下慢查询的日志。

mysql> system vim /opt/udb/instance/mysql-5.6/udb-jpcbmd/log/mysql-slow.log

我擦 查不到

跟客服一聊才知道 不能这么查

 

那就 执行语句查询  结果

 

我勒个去 刷屏了，那我导出成文本文件 总可以吧

 

这都不行，原本以为运维方便呢，差个日志都那么费劲。

又跟客服 扯了半天，把情况反映，客服又去找UDB的工程师查看原因

结果给的是

 

貌似跟我现在的情况也没啥毛关系 我就执行一条语句 一个线程 你给我看这个。

 

最后还是人家UDB的工程师牛叉，给出了最终解释。

 

原来是对硬盘的iops做了限制，那问问限制与配置的对应关系，好选配置。

 

问了等于白问，

迁移也不迁移了，还用原来的云主机吧。多建几个从库吧。

SSD UDB的应该性能不错，没去对比测试