失败的数据库迁移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的应该性能不错,没去对比测试
最新文章
- MySQL 安装 启动 基本语法概述
- Java你可能不知道的事系列(1)
- 关于HTML的Element
- CentOS 6.4 离线安装 Cloudera 5.7.1 CDH 5.7.1
- 使用 sp_executesql
- 64位SqlServer通过链接服务器与32位oracle通讯
- 在DataTable中添加行和列数据
- .Net 平台下的互联网架构新思考
- BZOJ_1601_[Usaco2008_Oct]_灌水_(最小生成树_Kruskal)
- Gradle的简介、安装与配置
- java版-JQuery上传插件Uploadify使用实例
- js中判断按键的方法
- Oracle第一波
- ASP.NET Core Web API下事件驱动型架构的实现(四):CQRS架构中聚合与聚合根的实现
- Linux 添加到环境变量
- 微信小程序开发记录
- python--使用递归的方式建立二叉树
- Docker docker-compose安装
- share drive 无效
- mysql数据库通过二进制 -【恢复数据记录】