如何用AI技术提升“战斗力”

持久化.

重要: 记住同时修改redis.conf配置文件来打开AOF, 否则服务重启时将使用原来的配置.

Redis 2.0

• 将最近的dump.rdb文件备份.
• 将备份文件传输到安全的地方.
• 停止所有写操作.
• 执行后台重写AOF命令redis-cli BGREWRITEAOF. 该操作会创建AOF文件.
• 当AOF备份完成后, 停止Redis服务.
• 编辑redis.conf, 启用AOF功能.
• 重启服务
• 检查确认数据库中的键个数没有丢失.
• 检查写操作都正确的追加进了AOF文件.

在AOF和RDB之间交互

Redis >= 2.4会保证当RDB快照在运行时, 避免触发一个AOF重写进程, 或者当AOF重写已经运行时, 不允许后台保存快照BGSAVE. 这可以防止两个后台进程同时产生高负载的磁盘I/O.

备份Redis数据

开始本节内容前, 请确认已经对数据库进行备份, 如果磁盘损坏, 云实例消失等, 没有备份意味着数据面临着巨大风险, 会消失在"黑洞" /dev/null中.

Redis对于数据备份非常友好, 即使数据库数据库运行中也允许你对数据进行拷贝备份: RDB文件产生时就不会被修改, 快照备份期间, 它会生成零时的文件, 当快照最终备份完成后采用重命名替换原来的RDB文件.

这意味着服务在运行时, 拷贝RDB文件是非常安全的, 下面是我们的建议:

• 在服务器上, 创建定时任务CronJob, 每小时执行一次RDB快照, 保存到一个目录, 并且在另外一个目录下保存每日快照.
• 每次定时任务执行时, 确认使用find命令查找最旧的快照, 将它们删除, 对于每小时快照, 你可以保留最近48小时, 对于每天快照, 你可以保留1~2个月. 并确包快照名包含时间信息.
• 每天至少做一次数据转存, 比如将RDB快照转存到其他数据中心, 或者至少从当前Redis服务物理机转存到其他地方.

如果你使用ROF持久化方式, 仍然可以拷贝AOF文件来做备份. 这个AOF文件即使丢失最后一小段数据, Redis也可以重建它们(请参考上面的截断AOF文件处理方式)

灾难恢复

灾难恢复和备份基本是一致的, 加上可以在许多不同的数据中心间转存这些备份数据. 这种情况下, 即使影响到最主要的数据中心, 其他地方的备份也是安全并且可以恢复的.

针对刚起步, 没有太多的资金来做大型备份, 这里也提供了一些不需要太大开销的灾备恢复技术:

• AmazonS3对象存储或其他类似服务是一个实现灾备恢复系统的好方法. 只需将每小时或每日的RDB快照加密后传输到S3即可, 你可以使用gpg -c(使用对称加密模式)对数据加密. 请确认将密码保存到不同的安全的地方(比如拷贝一份交给最重要的人来管理). 建议使用多种存储服务来提高数据安全性.
• 使用SCP(SSH的一部分)命令来将数据转存到其他服务器. 这是一个简单而且安全的方法: 在云端, 获取远离当前Redis服务的一个小型虚拟专用服务器VPS, 在数据端, 安装ssh, 生成不带密码的ssh客户端密钥, 将它添加到VPS的authorized_keys文件, 这样就可以继续实现自动免密转存备份数据到VPS, 为了提高数据安全, 可以使用不同运营商, 不同网络区域的VPS.

这种方式可能会导致文件传输失败, 所以在传输完成后, 至少要增加文件完整性校验, 比如校验文件大小, 如果使用VPS, 甚至可以使用SHA1校验.

你也需要部署独立的监控报警系统, 对备份过程进行监控, 在备份失败时能及时发现并修复.

（编辑：盐城站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!