发布网友 发布时间:2022-04-30 08:43
共2个回答
懂视网 时间:2022-04-30 13:04
公司采用的是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的应该性能不错,没去对比测试
失败的数据库迁移UDB
标签:
热心网友 时间:2022-04-30 10:12
如果你把语句一起执行的话,很容易卡死,如果把语句分开执行,成功的机率就比较高,特别是这种大数据的操作,如果一次删除10000W个数据,很容易卡死,如果分成10次删除,成功的机会就很高,你可以试试把语句分开执行。追问现在的迁移方案是:一个表5个分区,几乎所有的数据都是在第五区,现在是把第五分区切分出来,第一和第二个分区合并,创建第五个分区出来放新的数据。不是删除的。追答那现在就是第五分区的数据太多,那只能再细点,把第五分区再分多个,再依次执行,如按10天为一个单位,分开执行迁移语句,也就是一次迁移10天的数据。