山楼小院在哪家网站做宣传,山东建设厅科技处网站,海南注册家族公司条件,哪些网站免费做职业测评文章目录 背景迁移方案调研迁移过程服务监控脚本定时任务暂停本地副本服务启动#xff0c;在线服务下线MySQL 数据迁移Mongo 数据迁移切换新数据库 ip 本地服务启动数据库连接验证服务打包部署服务重启前端恢复正常监控脚本定时任务启动旧服务器器容器关闭 迁移总结 背景
校园… 文章目录 背景迁移方案调研迁移过程服务监控脚本定时任务暂停本地副本服务启动在线服务下线MySQL 数据迁移Mongo 数据迁移切换新数据库 ip 本地服务启动数据库连接验证服务打包部署服务重启前端恢复正常监控脚本定时任务启动旧服务器器容器关闭 迁移总结 背景
校园 e 站一群大学生在毕业前夕为打破信息差而开发的一个校园论坛。一个从零到一全靠一群大学生的满腔热忱而打造的一个前后端分离以小程序为最终展示载体的一个微服务架构体系的 App。并发量的初始定位为 w 级使用到多级缓存、数据分库等等前沿技术当然这也是本次就是数据迁移的根本原因所在架构过于庞大用户较少资源空等率高所以决定将服务缩容降低运营成本。 整体架构如上所示本次需要迁移的数据重点为Mongo 以及 MySQL 持久层数据。
迁移方案调研
因为持久层数据本身是通过 docker-compose进行容器编排加docker volume脚本启动所以调研到的方案大体可分为以下几种
在磁盘级别进行 volume迁移以旧数据库为主库新数据库为从库进行主从同步在应用层面使用应用本身的备份恢复功能进行数据迁移
三种方案的优缺点
方案优点缺点磁盘暂时想不到可能是看起来很牛技术要求高容易出现兼容性问题主从停机时间短需要改动两次服务启动脚本主从搭建时从库切主库备份恢复操作简单风险低停机时间较长 在综合考虑下选择了方案三进行备份恢复。 原因也很简单生产级别一般都是选择风险最低且操作简单的方式因为不管你有多牛也没办法保证迁移过程不会出现一点问题 迁移过程
服务监控脚本定时任务暂停
本地副本服务启动在线服务下线
MySQL 数据迁移
遇到的第一个问题是导出的文件压缩前 38M zip 压缩后依然 3.9 M远大于 phpmyadmin 允许上传的 2M 此时有两个方案一是调大数据导入的文件大小限制二是减少数据量。按道理正常使用数据不应该那么大毕竟用户量不大且主要数据存在 mongo 中在查询了之后发现有一个请求时间监控的表数据量达到 50W 执行 sql 将数据压缩
-- 数据平均
insert into controller_time(controller, time_cost, success) SELECT controller, AVG(time_cost) as time_cost, successFROM controller_time where id 563003GROUP BY controller, success
;-- 删除旧数据
delete from controller_time where id 563003;controller_time 数据压缩后导出文件 4.5M 压缩后 359K导入新数据库约十秒。
Mongo 数据迁移
进入 新机器 容器内到 /usr/bin目录调用容器已有的 mongo命令
将远程 mongo旧的数据库数据备份到新机器容器内
mongodump -h remote_ip:remote_port -d database -uuser_name -puser_password --authenticationDatabase admin -
o /home/mongodb/数据恢复到新 mongo
mongorestore -u local_user_name -p user_password --port 27017 --authenticationDatabase admin -d database
/home/mongodb/数据恢复结果 切换新数据库 ip 本地服务启动 数据库连接验证 服务打包部署
mvn clean install package服务重启 前端恢复正常 监控脚本定时任务启动
旧服务器器容器关闭 迁移总结
总涉及用户 6592 个用户其中已通过校园认证的用户 3943 全部数据迁移完毕服务恢复于 13:47 总耗时约 17 分钟。
