分库分布的几件小事(二)如何进行分库分表的数据迁移

1.停机迁移方案

这是最简单的也是最low的迁移方案了,如果系统就算短期停机也没有关系或者造不成多大的影响,可以选用此方案。

首先停掉机器,将系统全都停掉,不要再有新的数据进来,然后使用之前写好的程序,连接旧的数据库,将旧数据库里面的数据读出来,然后通过数据分发中间件写到分库分好的数据里面去。然后修改系统是数据库连接、分库分表配置,然后重新上线。

2.双写不停机迁移方案

双写迁移方案的核心在双写,首先要修改系统所有需要写库的地方,将虽有对数据的写操作不但要写入就库,也要同时写入新库。

然后使用写好的数据迁移程序,去读取老数据库的数据写入到新的数据库里面去,写的时候要根据数据的最后更新时间去判断数据,如果读出来的数据新库没有直接写入,如果新库也有,查看最后更新时间,旧库的新就覆盖写入,如果新库的新就放弃这条数据。

导完一轮数据之后,有可能数据还是存在不一致,那么就写个程序做一轮校验,对比老库和新库的每条数据,如果存在不一样的,就针对这些不一样的,再次去进行数据同步。反复循环,直到数据完全一致。

接着当数据完全一致了,就ok了,基于仅仅使用分库分表的最新代码,重新部署一次,不就仅仅基于分库分表在操作了么,还没有几个小时的停机时间,很稳。所以现在基本玩儿数据迁移之类的,都是这么干了。

原文地址:https://www.cnblogs.com/jack1995/p/10924517.html

时间: 2024-11-20 07:42:15

分库分布的几件小事(二)如何进行分库分表的数据迁移的相关文章

分库分布的几件小事(一)数据库如何拆分

1.为什么要分库分表 ①分库分表说白了,就是因为数据量太大了,如果你的单表数据量都到了千万级别,那么你的数据库就无法承受高并发的要求,数据库操作性能就会出现极大的下降. ②数据库并发量太大了,一般而言,一个数据库最多支撑并发到2000,这时候一定要进行扩容,不然性能会出现严重下降.而且一个健康的单库并发值你最好保持在每秒1000左右,不要太大.那么你可以将一个库的数据拆分到多个库中,访问的时候就访问一个库好了. 2.有哪些分库分布中间件 比较常见的中间件有cobar.TDDL.atlas.sha

分库分布的几件小事(三)可以动态扩容缩容的分库分表方案

1.扩容与缩容 这个是你必须面对的一个事儿,就是你已经弄好分库分表方案了,然后一堆库和表都建好了,基于分库分表中间件的代码开发啥的都好了,测试都ok了,数据能均匀分布到各个库和各个表里去,而且接着你还通过双写的方案咔嚓一下上了系统,已经直接基于分库分表方案在搞了. 那么现在问题来了,你现在这些库和表又支撑不住了,要继续扩容咋办?这个可能就是说你的每个库的容量又快满了,或者是你的表数据量又太大了,也可能是你每个库的写并发太高了,你得继续扩容. 缩容就是现在业务不景气了,数据量减少,并发量下降,那么

数据库(分库分表)中间件对比

转自:http://www.cnblogs.com/cangqiongbingchen/p/7094822.html 分区:对业务透明,分区只不过把存放数据的文件分成了许多小块,例如mysql中的一张表对应三个文件.MYD,MYI,frm. 根据一定的规则把数据文件(MYD)和索引文件(MYI)进行了分割,分区后的表呢,还是一张表.分区可以把表分到不同的硬盘上,但不能分配到不同服务器上. 优点:数据不存在多个副本,不必进行数据复制,性能更高. 缺点:分区策略必须经过充分考虑,避免多个分区之间的数

数据库-数据库设计-分库分表

为什么要分库分表 分库分表的设计 带来的问题 扩容 分布式事务 多个路由字段怎么设置 关于分库分表最全的一篇文章 这里介绍设计分库分表框架时应该考虑的设计要点,并给出相应的解决方案. 一.整体的切分方式 简单来说,数据的切分就是通过某种特定的条件,将我们存放在同一个数据库中的数据分散存放到多个数据库(主机)中,以达到分散单台设备负载的效果,即分库分表. 数据的切分根据其切分规则的类型,可以分为如下两种切分模式. 垂直(纵向)切分:把单一的表拆分成多个表,并分散到不同的数据库(主机)上. 水平(横

超简单理解分库分表

目录 一.为什么要做分库分表 二.如何进行数据分片 1.垂直切分 2.水平切分(重点) 三.数据切分后会出现的问题 数据源管理的问题 一.为什么要做分库分表 在数据爆炸的年代,单表数据达到千万级别,甚至过亿的量,都是很常见的情景.这时候再对数据库进行操作就是非常吃力的事情了,select个半天都出不来数据,这时候业务已经难以维系.不得已,分库分表提上日程,我们的目的很简单,减小数据库的压力,缩短表的操作时间. 二.如何进行数据分片 数据切分(Sharding),简单的来说,就是通过某种特定的条件

数据库水平切分的实现原理解析——分库,分表,主从,集群,负载均衡器(转)

第1章 引言 随着互联网应用的广泛普及,海量数据的存储和访问成为了系统设计的瓶颈问题.对于 一个大型的互联网应用,每天几十亿的PV无疑对数据库造成了相当高的负载.对于系统的稳定性和扩展性造成了极大的问题.通过数据切分来提高网站性能,横向 扩展数据层已经成为架构研发人员首选的方式. 水平切分数据库:可以降低单台机器的负载,同时最大限度的降低了宕机造成的损失: 负载均衡策略:可以降低单台机器的访问负载,降低宕机的可能性: 集群方案:解决了数据库宕机带来的单点数据库不能访问的问题: 读写分离策略:最大

数据库分库分表系统学习

一  为什么要进行数据切分 为什么需要数据切分呢?比如像Oracle这样成熟稳定的数据库,足以支撑海量数据的存储与查询了?为什么还需要数据切片呢?的确,Oracle的DB确实很成熟很稳定,但是高昂的使用费用和高端的硬件支撑不是每一个公司能支付的起的.试想一下一年几千万的使用费用和动辄上千万元的小型机作为硬件支撑,这是一般公司能支付的起的吗?即使就是能支付的起,假如有更好的方案,有更廉价且水平扩展性能更好的方案,我们肯定会进行选择的. 平常我们会自觉的按照范式来设计我们的数据库,负载高点可能考虑使

数据库水平切分的实现原理解析---分库,分表,主从,集群,负载均衡器

原文来自:http://zhengdl126.iteye.com/blog/419850 第1章  引言 随着互联网应用的广泛普及,海量数据的存储和访问成为了系统设计的瓶颈问题.对于一个大型的 互联网应用,每天几十亿的PV无疑对数据库造成了相当高的负载.对于系统的稳定性和扩展性造成了极大的问题.通过数据切分来提高网站性能,横向扩展数据层 已经成为架构研发人员首选的方式.水平切分数据库,可以降低单台机器的负载,同时最大限度的降低了了宕机造成的损失.通过负载均衡策略,有效的降低了单台 机器的访问负载

数据库水平切分的原理探讨、设计思路--数据库分库,分表,集群,负载均衡器

本文转载:http://www.cnblogs.com/olartan/archive/2009/12/02/1615131.html 第1章  引言 数据量巨大时,首先把多表分算到不同的DB中,然后把数据根据关键列,分布到不同的数据库中.库分布以后,系统的查询,io等操作都可以有多个机器组成的群组共同完成了.本文主要就是针对,海量数据库,进行分库.分表.负载均衡原理,进行探讨,并提出解决方案. 随着互联网应用的广泛普及,海量数据的存储和访问成为了系统设计的瓶颈问题.对于一个大型的互联网应用,每