国内最专业的IT技术学习网

Mysql数据库

当前位置:主页 > Mysql数据库 >

100亿数据,非“双倍”扩容,如何不影响服务,数据平滑迁移?

发布时间:2019/07/29标签:   数据库      架构      高可用    点击量:

原标题:100亿数据,非“双倍”扩容,如何不影响服务,数据平滑迁移?

上次《百亿级数据DB秒级平滑扩容!》之后,很多朋友提问,说如果不是“双倍”扩容,能否做到平滑迁移,不影响服务呢?

适用什么场景?

互联网有很多“数据量较大,并发量较大,业务复杂度较高”的业务场景,其典型系统分层架构如下:

(1)上游是业务层biz,实现个性化的业务逻辑;

(2)中游是服务层service,封装数据访问;

(3)下游是数据层db,存储固化的业务数据;

服务化分层架构的好处是,服务层屏蔽下游数据层的复杂性,例如缓存、分库分表、存储引擎等存储细节不需要向调用方暴露,而只向上游提供方便的RPC访问接口,当有一些数据层变化的时候,所有的调用方也不需要升级,只需要服务层升级即可。

互联网架构,网站seo价格,很多时候面临着这样一些需求:

(1)底层表结构变更:数据量非常大的情况下,数据表增加了一些属性,删除了一些属性,修改了一些属性。

(2)分库个数变化:由于数据量的持续增加,底层分库个数非成倍增加。

(3)底层存储介质变化:底层存储引擎由一个数据库换为另一个数据库

种种需求,都需要进行数据迁移,如何平滑迁移数据,迁移过程不停机,保证系统持续服务,是文本将要讨论的问题。

方案一:停机方案

在讨论平滑迁移数据方案之前,先看下不平滑的停机数据迁移方案,主要分三个步骤。

步骤一:挂一个类似“为了给广大用户提供更好的服务,服务器会在凌晨0:00-0:400进行停机维护”的公告,并在对应时段进行停机,这个时段系统没有流量进入。

步骤二:停机后,研发一个离线的数据迁移工具,进行数据迁移。针对第一节的三类需求,会分别开发不同的数据迁移工具。

(1)底层表结构变更需求:开发旧表导新表的工具;

(2)分库个数变换需求:开发2库导3库的工具;

(3)底层存储介质变换需求:开发Mongo导Mysql工具;

步骤三:恢复服务,并将流量切到新库,不同的需求,可能会涉及不同服务升级。

(1)底层表结构变更需求:服务要升级到访问新表;

(2)分库个数变换需求:服务不需要升级,只需要改寻库路由配置;

(3)底层存储介质变换需求:服务升级到访问新的存储介质;

总的来说,停机方案是相对直观和简单的,但对服务的可用性有影响,许多游戏公司的服务器升级,游戏分区与合区,可能会采用类似的方案。

除了影响服务的可用性,这个方案还有一个缺点,就是必须在指定时间完成升级,这个对研发、测试、运维同学来说,压力会非常大,一旦出现问题例如数据不一致,必须在规定时间内解决,否则只能回滚。根据经验,人压力越大越容易出错,这个缺点一定程度上是致命的。

无论如何,停机方案并不是今天要讨论的重点,接下来看一下常见的平滑数据迁移方案。

方案二:追日志方案

追日志方案,是一个高可用的平滑迁移方案,这个方案主要分为五个步骤。

数据迁移前,上游业务应用通过旧的服务访问旧的数据。

版权信息Copyright © IT技术教程 版权所有    ICP备案编号:鲁ICP备09013610号