一次业务跨库迁移过程

公司没有专职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

原文地址:https://blog.51cto.com/emulator/2364191

时间: 2024-11-04 17:09:35

一次业务跨库迁移过程的相关文章

分库分表的几种常见玩法及如何解决跨库查询等问题

在谈论数据库架构和数据库优化的时候,我们经常会听到"分库分表"."分片"."Sharding"-这样的关键词.让人感到高兴的是,这些朋友所服务的公司业务量正在(或者即将面临)高速增长,技术方面也面临着一些挑战.让人感到担忧的是,他们系统真的就需要"分库分表"了吗?"分库分表"有那么容易实践吗?为此,笔者整理了分库分表中可能遇到的一些问题,并结合以往经验介绍了对应的解决思路和建议. 垂直分表 垂直分表在日常开

SqlServer跨库查询

由于业务的拆分,数据库拆分为两种作用: 汇总数据库(Master,头节点数据库), 子节点数据库(Compute Node,计算子节点数据库) 这样,就设计到子节点访问头节点数据库中的某张汇总表,这种表的记录一般在几,到几十万行左右,目前适合做跨库查询. 跨库查询目前分为两种: 通过sp_addlinkedserver建立链接服务器 没有链接服务器时,可以使用openrowset或者opendatasource函数 在部署时,需要在SQLSERVER外围应用配置器中启用OpenRowSet和Op

跨库事务一致性问题的解决方案(例)

我们看一个跨库事务一致性的问题,这是一个简单的场景:有新老两个系统,对应新老两套数据库,新数据库采用分库分表的设计,考虑到项目发布之后可能存在风险,采取了新老系统的并行方案.这个系统的业务比较简单:接收来自外部的数据,然后对数据进行核对处理.为了保证新老系统能够并行,在接收数据的时候必须实现双写方案,从而导致了跨库事务的一致性问题. 下面一幅图展示这一简单的场景 这里面会存在一个小问题,就是可能存在写入老库成功,但是写入新库失败的场景. 我们假设出现这种概率的情况是百万分之一,在系统发布的情况下

ACCESS-如何多数据库查询(跨库查询)

测试通过:ACCESSselect * from F:\MYk.mdb.tablename说明:1.查询语句2.来原于哪(没有密码是个路径)3.查询的表名 =======================================我有两个数据库 A.B 然后我要将两个数据库的两张表组合作为一张表C显示 判断条件是 A数据库的aa表中字段a和B数据库的bb表中字段b相等 并且A数据库的aa表中字段a或B数据库的bb表中字段b等于某个值 示例:sql="select b.filetitle as

简单几部搞定laravel/lumen跨库操作

1.跨库数据库配置  在网站跟目录下的config文件中增加database.php作为数据库配置文件.配置如下: //当前默认数据库 'mysql' => [     'driver' => 'mysql',     'host' => env('DB_HOST', 'localhost'),     'port' => env('DB_PORT', 3306),     'database' => env('DB_DATABASE', 'forge'),     'use

跨库数据表的运算

文章出自http://c.raqsoft.com.cn/article/1536666621882?r=niu 1.    简单合并(FROM) 所谓跨库数据表,是指逻辑上同一张数据表被分别存储在不同数据库中.其原因有可能是因为数据量太大,放在一个数据库难以处理,也可能在业务上就需要将生产库和历史库分开.而不同的数据库,可能只是部署在不同的机器上的同种数据库,也可能是连类型都不同的数据库系统. 在面对跨库数据表,特别是数据库类型都不相同的情况时,数据库自带的工具往往就力所不及了,一般都需要寻找能

微服务改造中解决跨库问题的思路

今年一直在和团队做微服务的架构改造(相关的一些详情,有兴趣的朋友,可以参见之前的这篇分享).但是做过改造的朋友都知道 从“All-In-One” 到 “Micro-Service” 都需要迈过的一个坎,那就是垂直分库, 根据不同的子服务,将数据库拆分为不同的子服务库. 那么问题就来了,在开始做微服务改造前,我发现在摇旺的老系统中,有很多后台报表或者前端详情页所需的数据是通过SQL Join来完成的.但是,我们微服务改造后,每个服务背后的数据库已经在分布不同的实例中了,所以我们已经不能继续简单在S

mysql跨库数据表的运算

跨库数据表的运算,一直都是一个说难不算太难,说简单却又不是很简单的.总之是一个麻烦的事.大量的.散布在不同数据库中的数据表们,明明感觉要把它们合并起来,再来个小小的计算,似乎也就那么回事……但真要做起来,需要这又忘了那的,却又不像仅仅就那么回事?        想要给这些小麻烦们,来一个快刀斩乱麻式的.嘁嚓咔嚓地一劳永逸的解决方案么?首先,你需要一把叫做集算器的宝刀(重点):然后,你可以再看看这篇算是买一赠一的秘传刀法(免费):最后,面向敌人们手起刀落……你就可以轻松愉快地去睡一个好觉了:跨库数

DBLink 跨库查询

背景 随着业务复杂程度的提高.数据规模的增长,越来越多的公司选择对其在线业务数据库进行垂直或水平拆分,甚至选择不同的数据库类型以满足其业务需求.与此同时,业务的数据被“散落”在各个数据库实例中.如何方便地对这些数据进行汇总查询,已经成为困扰用户的一大问题. 例如,一家电商创业公司,最初的会员.商品.订单数据全部都存放在一个SQLServer实例中.但随着会员数量和交易规模的不断增长,单个SQLServer实例已经支撑不了巨大的业务压力,同时基于成本考虑,将商品和订单表从原来的SQLServer中