转自:不停机分库分表迁移,作者:阿飞Javaer
需求说明
借鉴codis
分库分表
明白这个方案后,了解不停机分库分表迁移就比较容易了,接下来详细介绍笔者当初对installed_app
表的实施方案;即用户已安装的APP信息表;
1. 确定sharding column
sharding column
绝对是分库分表最最最重要的环节,没有之一。sharding column直接决定整个分库分表方案最终是否能成功落地;一个合适的sharding column的选取,基本上能让与这个表相关的绝大部分流量接口都能通过这个sharding column访问分库分表后的单表,而不需要跨库跨表,最常见的sharding column就是user_id
,笔记这里选取的也是user_id
;2. 分库分表方案
根据自身的业务选取最合适的sharding column后,就要确定分库分表方案了。笔者采用主动迁移
与被动迁移
相结合的方案:
-
主动迁移就是一个独立程序,遍历需要分库分表的
installed_app
表,将数据迁移到分库分表后的目标表中。 -
被动迁移就是与
installed_app
表相关的业务代码自身将数据迁移到分库分表后对应的表中。
接下来详细介绍这两个方案;
2.1 主动迁移
主动迁移就是一个独立的外挂迁移程序,其作用是遍历需要分库分表的installed_app
表,将这里的数据复制到分库分表后的目标表中,由于主动迁移
和被动迁移
会一起运行,所以需要处理主动迁移和被动迁移碰撞的问题,笔者的主动迁移
伪代码如下:
public void migrate(){ // 查询出当前表的最大ID, 用于判断是否迁移完成 long maxId = execute("select max(id) from installed_app"); long tempMinId = 0L; long stepSize = 1000; long tempMaxId = 0L; do{ try { tempMaxId = tempMinId + stepSize; // 根据InnoDB索引特性, where id>=? and id<?这种SQL性能最高 String scanSql = "select * from installed_app where id>=#{tempMinId} and id<#{tempMaxId}"; List<InstalledApp> installedApps = executeSql(scanSql); Iterator<InstalledApp> iterator = installedApps.iterator(); while (iterator.hasNext()) { InstalledApp installedApp = iterator.next(); // help GC iterator.remove(); long userId = installedApp.getUserId(); String status = executeRedis("get MigrateStatus:${userId}"); if ("COMPLETED".equals(status)) { // migration finish, nothing to do continue; } if ("MIGRATING".equals(status)) { // "被动迁移" migrating, nothing to do continue; } // 迁移前先获取锁: set MigrateStatus:18 MIGRATING ex 3600 nx String result = executeRedis("set MigrateStatus:${userId} MIGRATING ex 86400 nx"); if ("OK".equals(result)) { // 成功获取锁后, 先将这个用户所有已安装的app查询出来[即迁移过程以用户ID维度进行迁移] String sql = "select * from installed_app where user_id=#{user_id}"; List<InstalledApp> userInstalledApps = executeSql(sql); // 将这个用户所有已安装的app迁移到分库分表后的表中(有user_id就能得到分库分表后的具体的表) shardingInsertSql(userInstalledApps); // 迁移完成后, 修改缓存状态 executeRedis("setex MigrateStatus:${userId} 864000 COMPLETED"); } else { // 如果没有获取到锁, 说明被动迁移已经拿到了锁, 那么迁移交给被动迁移即可[这种概率很低] // 也可以加强这里的逻辑, "被动迁移"过程不可能持续很长时间, 可以尝试循环几次获取状态判断是否迁移完 logger.info("Migration conflict. userId = {}", userId); } } if (tempMaxId >= maxId) { // 更新max(id),因为迁移过程中由于双写,导致max(id)会有变化,所以需要再次确认maxId的值判断是否遍历完成 maxId = execute("select max(id) from installed_app"); } logger.info("Migration process id = {}", tempMaxId); }catch (Throwable e){ // 如果执行过程中有任何异常(这种异常只可能是redis和mysql抛出来的), 那么退出, 修复问题后再迁移 // 并且将tempMinId的值置为logger.info("Migration process id="+tempMaxId);日志最后一次记录的id, 防止重复迁移 System.exit(0); } tempMinId += stepSize; }while (tempMaxId < maxId); }
这里有几点需要注意:
- 第一步查询出max(id)是为了尽量减少max(id)的查询次数,假如第一次查询max(id)为10000000,那么直到遍历的id到10000000以前,都不需要再次查询max(id);
-
根据
id>=? and id<?
遍历,而不要根据id>=? limit n
或者limit m, n
进行遍历,因为limit性能一般,且会随着遍历越往后,性能越差。而id>=? and id<?
这种遍历方式即使会有一些踩空,也没有任何影响,且整个性能曲线非常平顺,不会有任何抖动;迁移程序毕竟是辅助程序,不能对业务程序有过多的影响; - 根据id区间范围查询出来的
List<InstalledApp>
要转换为Iterator<InstalledApp>
,每迭代处理完一个userId,要remove掉,否则可能导致GC异常,甚至OOM;
2.2 被动迁移
被动迁移就是在正常与installed_app
表相关的业务逻辑前插入了迁移逻辑,以新增用户已安装APP为例,其伪代码如下:
// 被动迁移方法是公用逻辑,所以与`installed_app`表相关的业务逻辑前都需要调用这个方法; public void migratePassive(long userId)throws Exception{ String status = executeRedis("get MigrateStatus:${userId}"); if ("COMPLETED".equals(status)) { // 该用户数据已经迁移完成, nothing to do logger.info("user's installed app migration completed. user_id = {}", userId); }else if ("MIGRATING".equals(status)) { // "被动迁移" migrating, 等待直到迁移完成; 为了防止死循环, 可以增加最大等待时间逻辑 do{ Thread.sleep(10); status = executeRedis("get MigrateStatus:${userId}"); }while ("COMPLETED".equals(status)); }else { // 准备迁移 String result = executeRedis("set MigrateStatus:${userId} MIGRATING ex 86400 nx"); if ("OK".equals(result)) { // 成功获取锁后, 先将这个用户所有已安装的app查询出来[即迁移过程以用户ID维度进行迁移] String sql = "select * from installed_app where user_id=#{user_id}"; List<InstalledApp> userInstalledApps = executeSql(sql); // 将这个用户所有已安装的app迁移到分库分表后的表中(有user_id就能得到分库分表后的具体的表) shardingInsertSql(userInstalledApps); // 迁移完成后, 修改缓存状态 executeRedis("setex MigrateStatus:${userId} 864000 COMPLETED"); }else { // 如果没有获取到锁, 应该是其他地方先获取到了锁并正在迁移, 可以尝试等待, 直到迁移完成 } } } // 与`installed_app`表相关的业务--新增用户已安装的APP public void addInstalledApp(InstalledApp installedApp) throws Exception{ // 先尝试被动迁移 migratePassive(installedApp.getUserId()); // 将用户已安装app信息(installedApp)插入到分库分表后的目标表中 shardingInsertSql(installedApp); // 单库单表的插入逻辑。是否需要这段旧业务代码,取决于方案的严谨性:如果需要方案可以回滚,那么这段代码需要保留; insertSql(installedApp); }
无论是CRUD中哪种操作,先根据缓存中MigrateStatus:${userId}
的值进行判断:
- 如果值为COMPLETED,表示已经迁移完成,那么将请求转移到分库分表后的表中进行处理即可;
- 如果值为MIGRATING,表示正在迁移中,可以循环等待直到值为COMPLETED即迁移完成后,再将请求转移到分库分表后的表中进行处理处理;
- 否则值为空,那么尝试获取锁再进行数据迁移。迁移完成后,将缓存值更新为COMPLETED,最后再将请求转移到分库分表后的表中进行处理处理;
3.方案完善1
MigrateStatus:${userId}
的值进行判断,数据迁移完成后这一步已经是多余的。可以加个总开关,当所有数据迁移完成后,将这个开关的值通过类似TOPIC的方式发送,所有服务接收到TOPIC后将开关local cache化。那么接下来服务的CRUD都不需要先根据缓存中MigrateStatus:${userId}
的值进行判断;4.方案完善2
installed_app
表的binlog(参考alibaba canal)来进一步优化,示例代码如下:// 与`installed_app`表相关的业务--新增用户已安装的APP--这段旧业务代码保持不变 public void addInstalledApp(InstalledApp installedApp) throws Exception{ insertSql(installedApp); }
// 当执行了新增SQL(insertSql(installedApp))后,会产生binlog日志,insert类型(canal可通过EventType判断)的binlog日志消费端的逻辑如下所示--即将被动迁移逻辑挪到binlog消费端处理即可: public void insertBinlogConsumer(InstalledApp installedApp){ // 先尝试被动迁移 migratePassive(installedApp.getUserId()); // 将用户已安装app信息(installedApp)插入到分库分表后的目标表中 shardingInsertSql(installedApp); }
5.遗留工作
迁移完成后,将主动迁移
程序下线,并将被动迁移
程序中对migratePassive()
的调用全部去掉,并可以集成一些第三方分库分表中间件,例如sharding-jdbc
,可以参考sharding-jdbc集成
回顾总结
回顾这个方案,最大的缺点就是如果碰到sharding column(例如userId)的总记录数比较多,且主动迁移正在进行中,被动迁移与主动迁移碰撞,那么被动迁移可能需要等待较长时间(如果采用binlog的方案,就没有这个缺点)。
不过根据DB性能,一般批量插入1000条数据都是10ms级别,并且同一sharding column的记录分库分表后只属于一张表,不涉及跨表。所以,只要在迁移前先通过sql统计待迁移表中没有这类异常sharding column即可放心迁移;
笔者当初迁移installed_app
表时,用户最多也只拥有不超过200个APP,所以不需要过多考虑碰撞带来的性能问题;没有万能的方案,但是有适合自己的方案;
如果有那种上千条记录的sharding column,可以把这些sharding column先缓存起来,迁移程序在夜间上线,优先迁移这些缓存的sharding column的数据,就可以尽可能的降低迁移程序对这些用户的体验。当然你也可以使用你想出来的更好的方案。
相关推荐
https://mp.csdn.net/console/uploadResources?spm=1011.2124.3001.4171
MYSQL性能优化之分库分表与不停机修改mysql表结构,需要的朋友可以参考下
不停机的数据库跨版本迁移方案.pdf
不停机搭建standby备库 介绍安装standby备库步骤及注意事项
1、前言前面我们学习的了Zookeeper的集群搭建和管理,也学习和探讨了它的选举原理,我们这一章节来学习zookeeper集群的升级和迁移在学习集群的升级和迁
SharePlex“不停机”的数据库升级和平台迁移方案.pdf
迁移之前的准备工作 在需要导出的数据库执行: 1. 检查Oracle实例状态 ,sid SQL< select instance_name,host_name,startup_time,status,database_status from v$instance; 2.查看用户和默认表...
某医院HIS核心库XTTS迁移实施方案_云和恩墨_20191126_v1.0 Oracle 11g R2 RAC with ASM存储迁移-手记 ORACLE实用技巧之不知道密码情况下dblink的迁移 Oracle 19C 升级、整合、迁移 Oracle11g单实例迁移到RAC架构方案...
【经典】SharePlex“不停机”的数据库升级和平台迁移方案
并采取相关预防措施以显著减少迁移过程期间的停机时间。在迁移过程期间,您将创建一个新集群。一旦对迁移后的环境进行了测试,您就可以将新的集群投入生产应用。本文中使用的示例基于从 WebSphere Commerce 版本 5.5...
oracle主从系统从生产库不停机搭建dataguard最佳实施文档
MySQL不停机不锁表主从同步与读写分离配置,1 .xtrabackup安装.2.核对mysql的版本.3.在master服务器上在线备份数据库.4.slave机器上操作
oracle rac 不停机调整时间.txt
由于预拷贝迁移算法的迭代拷贝过程存在重复地...在进行虚拟机迁移实验时,与预拷贝迁移算法相比,结果表明该算法在未延长停机时间的同时,缩短了总迁移时间,尤其是在高脏页率环境下,该算法明显表现出更优的迁移性能。
调节托辊的偏置角是对带式输送机输送带调偏的一个常见方法,介绍了2种不停机调节托辊斜置角的方法。1使用轴端加长的托辊;该托辊一端的伸出轴被加长,安装在托辊架上后,托辊支撑座的外侧伸出一段较长的轴段。可徒手或...
redis-migrate-tool-master, redis-full-check 工具促使redis不停机在线迁移方案,完整的步骤配置详情。
云平台&数据平台迁移方案合集,共21份。 Elasticsearch数据迁移与容灾实践 云计算业务迁移实验指导 kubernetes容器云平台迁移实践 ...云平台迁移解决方案(高效、不停机) 云时代数据库迁移 & 容灾技术新进展与应用
在实际的 PCS7 工程中, 基于不同行业的应用, 工程师常常会建立自己的工程功能库, 自 定义开发特定的 FB 功能块类型(Block Type) , 或者对已有功能块类型进行修改调整以 适应实际现场需求。 在 AS 程序中, 将...
目 录 第1章 概述 3 1.1 总体说明 3 1.2 迁移安排 4 ...3.2.1 数据迁移完成后,原盘阵数据不做任何改变,保留一段时间,确认系统无任何问题后,另行分配使用。 15 第4章 验证方案 15 4.1 验证结果 15