dot Redis 8 来了——而且它是开源的

了解更多
White Redis Logo 返回
搜索

数据库持久化和备份的重要性

LinkedIn-icon
分享
LinkedIn-icon分享到LinkedIn
Andre Srinivasan, Global Solutions Architect, Alliances, Platforms, Edge Compute, IoT, and Emerging Technologies, Redis

André Srinivasan

我们最近有机会与 Cohesity 团队合作，验证Helios和Redis Enterprise之间的集成，这是加入 Redis技术合作伙伴计划 的一步。  在Helios上运行的Cohesity SmartFiles服务，提供 非结构化数据 的单一视图和全球管理，无论数据驻留在何处。 在Redis Enterprise的上下文中，SmartFiles提供数据库快照的单一视图。

为什么我们需要关注持久化和备份？确实如此：如果Redis用作缓存，并且可以在对系统影响最小的情况下从后端数据库重新填充，那么就不需要持久化或备份。另一方面，考虑当Redis用作操作型数据库以提供对慢速数据的快速访问时（例如：交易历史、库存计数、客户查询）。Redis数据库需要从硬件问题中快速恢复，甚至故障转移到另一个数据中心。

持久化

Redis数据库中的所有数据都独占地存储在RAM或RAM + Flash内存 (Flash上的Redis) 中并进行管理；在进程或服务器故障时有丢失的风险。有几种策略可以用来减轻这种风险：具有主从 数据分片 的高可用性(HA)数据库，地理分布式 active-active 数据库，当然还有基于磁盘的持久化。从性能角度来看，始终首选从主数据库分片故障转移到同步的从数据库分片，这就是Redis Enterprise的工作方式；只有当主从分片都丢失时，数据库才会从磁盘恢复。类似地，在数据中心故障的情况下，故障转移到另一个数据中心中同步的active-active数据库会比从磁盘恢复更快。

关于持久化，Redis支持为了更好的持久性而使用只追加文件(AOF)，但这需要更多资源；以及快照(RDB)，虽然持久性稍差，但所需资源较少。就像所有事情一样，这其中存在权衡，可以在 Redis Enterprise文档 中进一步探讨。为了本文的目的，我们将假设我们需要AOF来实现更好的持久性。

illustration of data persistence

备份

当主从数据库分片都丢失时，Redis Enterprise依赖于持久化进行恢复。如果没有使用active-active，并且存放数据库及其附属存储的机架丢失，那么我们就只能从备份中恢复。对于Redis Enterprise来说，备份始终是快照，与AOF持久化结合使用时，可以创建一个弹性且持久的数据平台。

这就是Cohesity SmartFiles发挥作用的地方；Redis Enterprise利用SmartFiles方便提供的S3兼容端点，用于跨云的管理备份。为了进行设置，我们使用 Redis Enterprise REST API，并假设以下条件：

  • $S3_IP 设置为Cohesity S3对象存储IP地址，$BUCKET 设置为bucket名称
  • $USER 和 $PASS 分别设置为Redis Enterprise管理员用户名和密码
  • $ACCESS_KEY 和 $SECRET_KEY 分别设置为S3对象存储访问密钥和秘密密钥

启用 数据库持久化。

curl -s -k -u $USER:$PASS -H content-type:application/json -XPUT 
https://localhost:9443/v1/bdbs/1 -d '{"data_persistence": "aof"}'

通过设置S3 URL配置集群使用S3对象存储。请注意，S3 URL中不包含bucket名称。

curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT 
https://localhost:9443/v1/cluster -d '{"s3_url": '\"$S3_IP\"'}'

配置集群S3备份仅用于隐私。 

curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT 
https://localhost:9443/v1/cluster -d 
'{"s3_certificate_verification":false}'

验证备份位置。请注意，成功时的唯一响应是HTTP 200 OK。

curl -s -k -u $USER:$PASS -H content-type:application/json -X POST 
https://localhost:9443/v1/bdbs/actions/validate_backup_location -d 
'{"backup_location": {"type": "s3", "bucket_name": '\"$BUCKET\"', 
"subdir": "","access_key_id": '\"$ACCESS_KEY\"', "secret_access_key": 
'\"$SECRET_KEY\"'}}'

创建备份。请注意，成功时的唯一响应是HTTP 200 OK。

curl -s -k -u $USER:$PASS -H content-type:application/json -X POST 
https://localhost:9443/v1/bdbs/1/actions/export -d 
'{"export_location": {"type": "s3", "bucket_name": '\"$BUCKET\"', 
"subdir": "", "access_key_id": '\"$ACCESS_KEY\"', "secret_access_key": 
'\"$SECRET_KEY\"'}}'

配置每30分钟进行一次定期备份。请注意，成功时的唯一响应是HTTP 200 OK。

curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT 
https://localhost:9443/v1/bdbs/1 -d '{"backup":true, 
"backup_interval":1800, "backup_interval_offset":360, 
"backup_location": {"type": "s3", "bucket_name": '\"$BUCKET\"', 
"subdir": "", "access_key_id": '\"$ACCESS_KEY\"', "secret_access_key": 
'\"$SECRET_KEY\"'}}'

总结思考

在一个没有摩擦的世界里，配置了HA和Active-Active的Redis Enterprise可以让你无需担心持久化和备份。但我们并非生活在一个没有摩擦的世界，当Redis需要从系统故障中恢复时，我们需要持久化和备份（以及HA）。像Dell EMC、NetApp或Pure Storage等供应商的设备产品中常见提供S3备份端点。幸运的是，与Cohesity SmartFiles的经过验证的集成使得利用此端点并将备份纳入操作策略变得容易。