• 失败的数据库迁移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的应该性能不错,没去对比测试

     

  • 相关阅读:
    01 Java基础第一天
    2019牛客暑期多校训练营(第七场)J A+B problem
    SDNU 1477.矩形面积交(思维)
    SDNU 1194.传纸条(DP)&& 1032.机器人
    SDNU 1280.就问你慌不慌(高精度)
    POJ 2528 Mayor's posters(线段树+离散化)
    HDU 1698 Just a Hook(线段树区间赋值)
    POJ 3468 A Simple Problem with Integers (区间加区间查找)
    HDU 1754 I Hate It(线段树单点更改、区间查找最大值)
    HDU 1166 敌兵布阵(线段树单点加区间查询)
  • 原文地址:https://www.cnblogs.com/xiaokangufo/p/4736281.html
Copyright © 2020-2023  润新知