mysql,redis数据备份方案
发布时间：2022-09-20 15:08:36 所属栏目：MySql教程 来源：
导读： 先说下背景，公司的服务器一直用的阿里云，包括mysql、redis也都是买了ECS自己搭建的。这里面有几个原因:
创业的时候，阿里云只提供mysql的存储，redis的存储还没提供。没钱，即时现在去看redis的存储价
创业的时候，阿里云只提供mysql的存储，redis的存储还没提供。没钱，即时现在去看redis的存储价
|
先说下背景，公司的服务器一直用的阿里云，包括mysql、redis也都是买了ECS自己搭建的。这里面有几个原因: 创业的时候，阿里云只提供mysql的存储，redis的存储还没提供。没钱，即时现在去看redis的存储价格也是贵的吓人。 这样自己来搞存储有好处也有坏处。 好处： 完全可控，比如连接数限制mysql备份，内存限制，存储限制。还有数据备份的灵活性等等。强迫团队服务器研发要有存储运维能力。省钱 坏处： 冷备、热备方案不完善。存储运维的成本较高，需要长时间积累。 ok，问题就是这样，接下来再来说一下我们之前的冷备和热备方案。 可以说极其简陋： mysql、redis每天10点冷备，备份到本地磁盘和阿里云OSSredis使用rdb落地，每60秒至少有1次写就会触发落地。 这样做的问题其实挺多的，主要几个: mysql dump的时候会导致游戏卡顿，即使加了 -single-transaction 参数 也仅仅是缓解冷备频率过低，真出现问题数据已经太久没有热备，风险较大 针对这些问题，我们先做了mysql备份的优化。 mysql主从同步，实现热备。主机不再执行mysqldump，从机上每隔10分钟执行一次mysqldump，并备份到本地磁盘和阿里云OSS mysql的备份方案还是比较简单的，唯一要注意的是，从机启动的时候并不会从主机拉取所有数据，所以需要停服先把主机的数据手动同步到从机，之后再启动同步。 接下来，是redis的备份问题。 为了与mysql的备份时间一致，redis这边改成了主机每10分钟备份rdb文件一次。 但新方案运行了几天之后，发现mysql经常会突然响应变慢。 后来发现因为备份脚本的逻辑是会先把rdb文件copy一份出来，而copy的目标位置和mysql使用的磁盘是同一个磁盘，所以导致磁盘IO上升，从而mysql变慢。 并且redis的bgsave每隔60秒运行一次，也是会对磁盘有大量的写操作，不过目前看来影响不是特别大，因为数据量比较小。 所以我们开始考虑新的redis备份方案。 与mysql不同，redis从机在第一次启动的时候会从主机全量同步一次数据。 所以我们想了几套方案，我分别列一下。 redis主从热备，从机进行冷备 这种方案其实是可以的，但是有几个问题: 如果主机不关闭rdb保存就没有问题，如果关闭了的话，那么当主机不小心宕机重启，那么当主机redis启动之后，会把从机redis的数据也抹掉。十分危险。一旦从机服务器出问题，重新启动后会从主机同步所有数据，导致主机bgsave运行，如果数据量很大，会导致主机内存狂飙，如果主机又忘记配置内存使用限制，就会是灾难了。这在云风的一篇文章中有写: 谈谈陌陌争霸在数据库方面踩过的坑( Redis 篇) 所以后来，我决定选择一个比较简单的方案。 使用ssh将rdb文件传输到另一台机器上，再进行冷备。 既然是因为磁盘写IO增加导致问题，那么我们就先规避掉这个问题好了。 至于，redis是否要做主从热备的问题，暂时我们是还没做的，等以后再说吧。 其实要不是之前有一次阿里云服务器出现故障导致我们mysql全都用不了，我也不会狠下心半夜停服一个小时去调整备份方案。 正如前段时间被DDOS了，相关的抵御优化才被提上日程一样，无非时、势二字。 （编辑：我爱制作网_沈阳站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
浙公网安备 33038102330576号