思考线上如何既保证不影响查询,又能做更新操作

目前遇到的情况有:

一、数据库进行在线ddl(修改表结构和字段)

也是使用重名表名的方式。复制一张表,包括里面的数据,假设名称为tmp。在这张tmp表上面执行dll语句操作。此时要记录某个时刻开始对数据库的更新操作sql,缓存起来。

执行dll操作完毕。就把之前缓存起的sql放到这个tmp表中执行一遍。

二、sphinx重建索引。此时要不能关掉shpinx,要保证能够进行正常的查询服务

使用的是重名名的方式。把最新的索引结果保存在一个.new这样的文件中。原来的所以文件假设是master,那么现在要把这个master用.new来替换掉,因为索引更新了。

怎么保证,替换操作进行的同时,不影响客户端查询sphinx索引呢。不可能关掉sphinx服务吧。

发送发送SIGHUP 给searchd,等待所以子进程退出,退出后才执行下面的步骤

master>重命名为>old

把new文件重命名为master,以便提供给正在使用的sphinx查询使用。

然后让sphinx进程加载替换后的所以文件。如果加载成功。就正常。加载失败,则回滚:

searchd会把.old文件回滚为当前文件,并把刚建立的新索引重命名为 .new

三、redis主从同步数据时候,主服务器此时有更新操作。怎么办。

现在看到redis针对这种情况的处理是:先把更新的命令缓存起来。然后把这些命令同步到从服务器去执行。

具体是:同步的时候,先把当前内存数据库的数据做一个快照保存在磁盘上,目的是把这个文件中的数据发给从服务器。从服务器然后载入到内存中。在这个同步文件的过程中。

主要服务器仍然能够接受客户端的查询操作和更新(写入)操作。执行更新操作,会额外把把这些更新命令缓存起来。等到数据库快照同步完毕后,就会把这些命令发给从服务器去执行。

相当于主服务器执行哪些更新操作,从服务器把这些更新操作在那边也执行一遍。当然是在之前数据库快照的基础上去执行更新操作才会正确。

最终结果是,从服务器就是主服务器的redis数据的一个快照。然后把命令重新执行一遍。

时间: 2024-07-29 12:42:08

思考线上如何既保证不影响查询,又能做更新操作的相关文章

对线上系统维护工作的总结与思考

背景描述:目前在一家网站公司工作,2015年初研发中心部门改革,小组重组,被分配到了网站平台的维护组.下面内容是对近期维护工作的一个总结: 个人感受:以前也在老东家的团队也做线上系统的维护和新产品的研发,由于大家的认真负责,Leader的管理也很到位,线上的系统很少有bug反馈,不管是UI上迭代,还是系统逻辑的升级都很顺畅. 目前负责的平台运行了3年多,可能由于当时逻辑设计问题,也可能是执行问题,发现近期反馈的问题多是逻辑问题,在此对这些问题的原因不做探讨和深究,只是想讲讲面对线上问题的维护工作

线上缓存不一致问题排查

缓存不一致问题 背景 会员相关有: 综合系统 :会员的基础CRUD ,旧系统,慢慢废弃,不再维护. 会员系统 :从综合系统里拆分出来的,有基础服务,接口服务,数据同步服务,SSO服务等. 每个服务都是单独的应用. 两个系统共用同一张表,只是维护的字段不一样. email[邮箱]是我们新版本中新支持的功能.综合系统没有 email 字段,会员系统里有 email 字段. 第一次反馈 用户反馈说: 邮箱收不邮件,去设置中看,邮箱设置会自动消失.重新设置一下就好了. 定位问题 一) 排查数据问题 怀疑

【前端小记】从线上开发到本地化

开篇 这篇文章是因为想总结一下一直以来工作中记录在记事本中的前端知识点.从而进行复盘.虽然不是所有的知识点都记录下来的,但是其实也记录了很多.知识是无限的,如果之前记录的知识后来没有去回顾和使用,那和没有记录是没有区别的. 而且我希望发布一些文章,应该也能给别人带来一些帮助,尽管自己能力有限,可能在大佬看来不算什么,但总能帮助到一些人的. 废话不多说,那么马上开始吧. 欢迎关注公众号:大前端早读 起因 以前的工作模式基本是完全线上开发的,页面采取碎片化开发,页面是由前端使用freemarker模

关于线上的bug什么时候修复的思考

这里系统专门指的是那种用户量大的系统,比如有几百万或者上千万的注册会员.因为小系统因为用户量少,不存在这种思考,考虑有时候是多余的.另外还有内部系统,给自己公司内部人员使用的,即便是出现了问题,也不会造成很大的问题,内部协调一下即可. 而针对客户的系统,公司的收入和价值来源于给客户提供稳定的服务.这是关系到公司命脉的.如果系统不稳定,在客户心中造成的印象就会不好. 快速修复与稳定测试之间的权衡 如果线上系统出现了bug,用户反馈问题.作为开发人员,肯定要修复bug.是马修复代码后上传到生产环境,

关于线上故障的思考

周末早上,一个哥们突然@我,问是否有线上故障处理和定级的规范或者模板,虽然手头有既有文档,但内容显的太具象了,跟我们的业务有很强的关联性,并不是那么好直接复制到他的团队中.因此,个人对过去的线上故障处理进行了回顾和思考,并进行了简要的归纳,望帮助到需要的同学.文本将按事中处理.事后总结和事前预防的顺序进行介绍,不足之处望大家不吝赐教. 换个角度来说,其实故障处理的过程,和小朋友发高烧的处理过程类似.首先mama会带孩子上医院,如果温度高医生会要求打退烧针,类似发布回滚,之后再通常吃对症的药物慢慢

Android线上bug热修复分析

针对app线上修复技术,目前有好几种解决方案,开源界往往一个方案会有好几种实现.重复的实现会有造轮子之嫌,但分析解决方案在技术上的探索和衍变,这轮子还是值得去推动的 关于Hot Fix技术 Hot Fix技术,简单来说就是针对线上已发布app出现了bug,在不推送新版本的情况下通过发布修复补丁进行修复.通常是刚上线的app,需要快速线上修复bug,类似的技术就叫做热修复或热补丁. 热修复技术能带来什么 让app具有了上线后被修复的可能性,增加事故风险可控性: 避免为修复bug而快速增发新版本,让

复现一个典型的线上Spring Bean对象的线程安全问题(附三种解决办法)

问题复现 假设线上是一个典型的Spring Boot Web项目,某一块业务的处理逻辑为: 接受一个name字符串参数,然后将该值赋予给一个注入的bean对象,修改bean对象的name属性后再返回,期间我们用了 Thread.sleep(300) 来模拟线上的高耗时业务 代码如下: @RestController @RequestMapping("name") public class NameController { @Autowired private NameService n

从线上教育的如火如荼,反思传统培训行业的未来发展

最近好像只要一沾上"线上教育"四个字的培训课程就一定很火.周未去听一个技术分享沙龙.得知,现在的北京VC圈,只要你是从国外回来,只要你说要做线上教育,就会有VC向你砸钱!在想,现在教育培训这个行业难道真的到了那种"人傻,钱多,速来"的情况了吗? 为了体验线上教育课程,作为体验者的自己来说,已经在网络上买了近2000多元的课程.说一下自己的感受.首先,我是做培训行业的.先说结论吧!线上教育不可能,也不会将线下的传统培训所取代,也取代不了!两者最好的融合就是线上3-5分

系统上线那点事 - 记一次线上系统故障

该项目是一个微信转盘游戏抽奖营销项目.因为运营营销时间要求紧迫.开发測试部署上线用了10天不到,有些准备工作并没有到位,如: 1.因为总体开发在上线前2天才完毕,測试了解这个项目需求是在开发的第二周,并没有充足的时间进行完好的功能,UI机型适配,系统压力測试. 2.技术上因为合作方的公众号密钥并不适合直接给出,所以由对方封装微信接口获取所需功能,对方封装的微信接口给出比較迟,在预定開始时间前三天: 微信的网页接口授权回调域名仅仅有一个.这个回调域名还有其它应用在使用,不能直接简单的改为我们部署应