dot 快速的未来将在您所在城市的一场活动中呈现。

欢迎参加 Redis 发布会
白色 Redis 徽标 返回
搜索

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

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 + 闪存 (基于闪存的 Redis) 中; 如果进程或服务器发生故障，它有丢失的风险。有几种策略可用于降低这种风险：具有主用和辅助 数据分片 的高可用性 (HA) 数据库、地理分布的 活跃-活跃 数据库，当然还有基于磁盘的持久化。从性能的角度来看，总是优先从主数据库分片故障转移到同步辅助数据库分片，Redis Enterprise 采用的就是这种方式；只有在主分片和辅助分片都丢失时，才会从磁盘恢复数据库。同样，在数据中心发生故障的情况下，故障转移到另一个数据中心的同步活跃-活跃数据库会比从磁盘恢复更快。

关于持久化的疑问，Redis 支持仅追加文件 (AOF) 以提高耐用性，但需要更多资源，而快照 (RDB) 的耐用性较低，但需要的资源更少。所有事物都是如此，在 Redis Enterprise 文档 中可以进一步探讨权衡取舍。对于本文的目的，我们将假设我们希望 AOF 具有更好的耐用性。

illustration of data persistence

备份

当主用和辅助数据库分片都丢失时，Redis Enterprise 依赖持久化来恢复。如果没有使用活跃-活跃，并且存放数据库及其所连接存储的机架发生丢失，那么我们就只能从备份中恢复。对于 Redis Enterprise，备份始终是快照，与用于持久化的 AOF 结合使用时，会创建一个有恢复能力且耐用的数据平台。

这是 Cohesity SmartFiles 发挥作用的地方；Redis Enterprise 利用 SmartFiles 轻松提供的 S3 兼容端点，在云端进行受管理的备份。要设置此项，我们将使用 Redis Enterprise REST API，并拥有以下假设

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

启用 数据库持久性。

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

通过设置 S3 URL，将集群配置为使用 S3 对象存储。注意，存储桶名称未包含在 S3 URL 中。

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

将集群 S3 备份仅配置为隐私。 

curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT 
https://127.0.0.1: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://127.0.0.1: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://127.0.0.1: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://127.0.0.1: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\"'}}'

最后的想法

在无摩擦的世界里，使用高可用性配置的 Redis Enterprise 和 Active-Active 能让你不用担心持久性和备份。我们并不生活在无摩擦的世界中，当 Redis 预期从系统故障中恢复时，我们需要持久性和备份（以及高可用性）。可以看到，将 S3 备份端点视为设备产品很常见，比如 Dell EMC、NetApp 或 Pure Storage 等。幸运的是，与 Cohesity SmartFiles 验证的集成能够方便地使用此端点，并在操作策略中包含备份。