技术

A collection of 2 posts
技术

记一次MySQL主从复制

线上系统已经运行一年多,子系统越来越多,数据库越来越大。 我们的服务是一个4C8G,100G数据盘的云服务器。每次导出的sql脚本将近400M。 为了做好数据备份,一开始的做法是,线上系统每两个小时使用mysqldump进行备份,然后本地有一个内网服务器定时同步。 这种做法足够简单,但是问题也很明显: 1. 备份的数据有两个小时延迟。 2. 数据量较大是对于服务器的压力较大,要么占用大量空间,要么使用gzip压缩,不管是哪种,缺点都很大。 一开始,受限于对MySQL的了解,尝试了传统的主从复制,手动指定binlog文件和position;在本地尝试运行时,看起来是可以的,但是尝试进行线上同步时,失败了几次,原因是线上业务是持续的,主数据库有不断的写入,postion一直是变化的,从而导致从数据库同步失败。 后面,通过搜索了解了MySQL GTID主从复制的方法;这个方法也是在传统主从复制的基础上改进的,区别在与不用再手动设置binlog文件和position。 以下是互联网上关于MySQL GTID主从复制的介绍和描述: MySQL GTID(Global Trans
7 min read
前端

前端监控的设想

序言 2024年,年后上班的第一个周一,当我正在办公室把思绪从过年的喜悦转换到工作中时,车委会主任在工作群中反馈了一个关于驾驶员在小程序中无法提交加油记录的问题。 看到这个问题,我第一时间想的是如何去判断这个问题是如何发生的,是哪位驾驶员,什么时间,填写了哪些信息,上传了哪些图片,网络情况如何,发生的次数和频率大不大。 基于第一时间的判断,我开始了按图索骥,开始让车委会把截图发过来,从手机截图上看网络是没有问题的,并且图片上传是成功的,填写的表单也及其简单。 那么,问题处在哪里呢? 困境 于是开始查找那个时间在服务端发生的事情,通过查看日志,一无所获 ;更艰难的问题是,我们无法设身处地地调试驾驶员的微信小程序,这做不到。 更致命的是,过去的经历和经验,到现在,我们大都如此,一但前端用户出现了难以预测的问题,我们都难以判断为什么,甚至连基本的信息都没有。 基于以上困境,我们在设想一个解决我们当前困境的应用,这个应用能够让我们明白前端用户使用过程中问题是如何发生的。 这个目标在设想的时候是比较模糊的,我们只知道一些最基本想要达到的功能,并没有考虑实施路径,实施方法,、与
9 min read