珠海 网站 设计,做网站如何购买服务器吗,网站开发项目总结,镇江网站建设介绍昨晚老板突然在群里发了一张图片#xff0c;说昨天才用的#xff0c;怎么今天还要登录#xff1f;相关人赶紧看看。
我心想让你登录就登录呗#xff0c;哪来那么多事#xff1f;本想洗洗睡了。老大突然微信问我说#xff0c;是不是 Redis 出问题了#xff1f;怎么用户…昨晚老板突然在群里发了一张图片说昨天才用的怎么今天还要登录相关人赶紧看看。
我心想让你登录就登录呗哪来那么多事本想洗洗睡了。老大突然微信问我说是不是 Redis 出问题了怎么用户的登录态没了我们趁老板还没收到客户投诉之前把数据恢复一下。
没办法既然到找到我了那就是对我的百分百信任为公司赴汤蹈火在所不辞。更何况只是恢复一下数据呢你说是吧
Redis 恢复数据那就免不了和 RBD、AOF这俩老货打交道了。
简单来说
RDB 是全量备份AOF 是增量备份
别急再通俗点
RDB 就是在一个特定的时间点把全部数据备份一次AOF 就是如果写入了就把这次写操作记起来
别动手举个栗子给你包懂的
我女朋友送了一盒乐高给我打算和我在星期四的晚上点个KFC疯狂套餐。然后做一件疯狂的事情。
我把盒子拿出来一看封面已经把乐高模型都画出来了。我说这不是洒洒水吗10分钟搞定它。
1个小时后装逼不成的我只能求女票把说明书给我然后和我一起拼。
经过两个人近3个小时的鏖战模型终于是拼好了。 把你的脚放下我马上解释。在这个例子中盒子封面就相当于RDB它是乐高模型在某个时刻的样子有一个词我相信你一定听过快照。我可以在拼好底座的时候拍个照这是一个快照。在底座的基础上再拼上主体然后我再拍个照这也是一个快照。总之呢只要能通过这张照片欢迎出原来的东西那这张照片就是一个完美的快照。像我拆电脑前必须先拍张照片不是怕忘记什么。只是我想记住写什么免得多出来一两颗螺丝就不好了。 说了半天AOF呢你难道没发现我最后是靠什么拼好乐高模型的吗没错说明书就相当于AOF。说明书记录了底座要怎么拼主体要怎么拼以及最后的封顶要怎么拼。每一步都给你写清楚就怕你到时候没拼好找他退钱。AOF 就是这样工作的当我向 Redis 里面写入数据时他就记起来一直记一直记。只要记得足够多那还原不是简简单单3小时的事吗
拼完乐高之后我女票说她累了要我抱抱 咳咳这篇文的主题是什么来着Redis 数据迁移差点忘了。接下来就是劲爆的数据迁移请先去厕所然后打开再看我怕你们其他时间不看。
说回数据恢复首先看一下 Redis 实例有没有开启备份
127.0.0.1:6379 CONFIG GET save
1) save
2)
127.0.0.1:6379 CONFIG GET appendonly
1) appendonly
2) no哇哦看到这个结果的时候我心都死了这表示不会自动进行 RDB 备份没有开启 AOF 备份。我嘞个豆你让我做饭但是不给我米还说想吃香香的饭那我怎么办我只能问运维有没有备份意外的是运维说他昨晚刚备份完。确实挺意外的果然这小伙之前被叼那么多次是有用的。
既然有备份文件了 那就直接恢复吧数据丢点就丢点。总比全部丢了要强。突然发现我的Redis是部署在K8S里面的那我就得先把文件给复制进去。
kubectl cp ./2406141123dump.rdb prod/redis-deploy-6764468fd6-lrkq7:/data/2406141123dump.rdb kubectl cp local-file_name name-space/pod-name:pod-file-name然后执行恢复命令
# 先找到对应得pod
kubectl get pods -n prod | grep redis # 进入pod
kubectl exec -it pod-name bash -n name-space# 通过redis-cli 恢复rdb
redis-cli -h localhost -p 6379 --rdb /data/2406141123dump.rdb这时候我们就拥有群里的狗叫权了 数据恢复完之后的常规操作那当然是再备份一把了我们可以选择开启RDB的自动备份和AOF但是但是那是运维的事情。秉承着别人的事情我坚决不做自己的事情适当不做的原则我们忽略它。 然后手动触发一次RDB备份给回运维保存数据恢复就告一段落了。
# 先查一下现在的rdb最新备份时间
127.0.0.1:6379 lastsave
(integer) 1718779144# 触发备份
127.0.0.1:6379 bgsave
Background saving started#再查一遍最新备份时间如果和上次不同就说明成了
127.0.0.1:6379 lastsave
(integer) 1719225459127.0.0.1:6379 exit别忘了我们现在在 K8S 的pod里面我们还得把备份文件复制到宿主机去
# 先看一下有没有备份文件 dump.rdb
ls -l /data# 将k8s中pod的文件拷贝到宿主机
kubectl cp prod/redis-deploy-6764468fd6-lrkq7:/data/dump.rdb ./dump.rdb发给运维大功告成。 作为一个专业的前端后端运维测试工程师我们解决了问题还得解决提出问题的人bushi。 让我来看看怎么个事问就是流量突增毕竟这是所有人都喜欢的答案当然是包括我的这意味着我们只要加钱就行了。加钱就意味着是老板给的不够不是我们前端后端运维测试工程师的问题。
这该死的世界啊我究竟要为这个世界背负多少的秘密。我永远不会告诉别人当时Redis所在的机器莫名重启了而且Redis是单节点没有挂载持久化盘。而且运维每天都是手动备份我当时能拿到前一天的备份真的是好运因为他想起来他好几天没备份了就备份了一下子。 既然发现了问题那就解决问题吧既然 Redis 单节点而且没有持久化那我们就打一层反逻辑。在集群里面部署一个 多节点有持久化的 Redis是不是就解决了。是的答案往往就是这么的朴实无华。那有没有更好更简单的方法呢必定是有的。给钱申请一个云Redis然后把数据迁移过去完美。 可用性和持久化解决了那接下来就是数据迁移了我找了挺多工具的但最后只留下两个来尝试因为很多工具都不维护了
https://github.com/erikdubbelboer/phpRedisAdminhttps://github.com/tair-opensource/RedisShake phpRedisAdmin 有图形页面还能导入导出。看起来相当不错但是有这几个问题让我放弃了它
导出结果是字符串格式的有序列化问题导出结果没有过期时间key 多的时候页面很卡 这就是我导出内容的一部分截图中间那一堆乱码是因为我用来默认了 RedisTemplate。
然后是 Redis-Shake这是一个go写的专门用来做数据迁移的工具。支持多种方式从源Redis实例拉取数据同步到目标实例。
# 下载二进制文件
wget https://github.com/tair-opensource/RedisShake/releases/download/v4.1.0/redis-shake-linux-amd64.tar.gz# 解压
tar -zxvf redis-shake-linux-amd64.tar.gz# 修改配置文件 shake.toml然后执行同步
./redis-shake shake.toml靠谱
