一次业务跨库迁移过程

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一次业务跨库迁移过程相关的知识,希望对你有一定的参考价值。

公司没有专职dba,公司运维当中我对mysql日常操作有一定了解,因此主动请缨配合业务部门进行数据库迁移。

一,业务背景

  1. 将现有业务数据库B迁移到新服采购服务器上;
  2. 将该业务线的A数据库中(100+表90G)表迁移到新数据库实例B库中;
  3. 部分业务表涉及到多个业务共同写入(前期没有提供接口)需要进行实时同步,方便后期改造。

二,迁移方案

  协同开发同学商量后,决定采用前期导入数据,并通过otter实时同步,然后切换业务的方式进行。具体如下:           
   1. 现有数据库迁移到新服务器
        A,新服务器上启动新数据库,并采用mysql级联复制:未来新的master挂载到现有数据库的master进行
        数据同步,并在它下面挂载两个slave进行数据同步,作为未来的slave;
        B,切换时停止应用,确认主从同步状态,修改业务数据库地址配置为新的地址,启动应用;                    
   2. 跨库迁移表,并实时同步  
        A,用mydumper(比mysqldump快,并能记录binlog位置)导出A库中迁移的表数据;并用myloader导入
        到B库中;
        B,根据导出的binlog位置配置otter进行数据同步;
   3. 业务切换
        A,停止业务,停止otter,并删除已完成同步的表配置(部分表需要长期)
        B,启动otter,修改业务数据库地址配置为新的地址,启动应用;
        C,后续业务改造,跨系统调用改为接口(禁止直接写表)方式,并最终停止otter;

三,迁移过程中的注意事项

  1.  迁移的表数量和名字反复确认;
  2.  mysql级联复制时候需要开启 log_slave_updates;
  3.  otter配置存放的数据库,需要忽略大小写;同步源和目标数据库需要字符集一致(utf-8);
  4.  myloader导入时候,需要开启 -e选项,否则导入数据不会记录binlog中;

四,mysqldump , mydumper/myloader速度比较

技术图片

五,mydumper/myloader简单使用说明

  • 账号授权
    GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, REFERENCES, INDEX, ALTER, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, EVENT, TRIGGER ON *.* TO mydumper‘@‘192.168.1.%‘ identified by ‘123456‘;
  • 导出
    导出db_a库中test1,test2表到/dumper/
    /usr/bin/mydumper -u mydumper -p 123456 -h 192.168.1.1 -P 3306 -B db_a -T  test1 test2 -t 8 -o /dumper/ &
  • 导入
    导入test1 test2 表到db_b库
    /usr/bin/myloader -u root -p 123456 -S  /tmp/mysql.sock -t 8 -o -e -B db_b -d /dumper/ &
  • binlog信息
    /dumper/metadata
  • 注意事项
    1,如果需要记录binlog日志,开启参数 -e
    2,如果需要drop 原有表,开启参数 -o
    3, 如果目标库存在 同名数据库,移除 /dumper/db_a-schema-create.sql

以上是关于一次业务跨库迁移过程的主要内容,如果未能解决你的问题,请参考以下文章

记一次代码重构

DBLink 跨库查询

[微服务系列] 微服务架构跨库分页解决的四种方案

Sublime Text自定制代码片段(Code Snippets)

使用实体框架迁移时 SQL Server 连接抛出异常 - 添加代码片段

初码-Azure系列-记一次MySQL数据库向Azure的迁移