配置数据库持久性
如何使用仅附加文件 （AOF） 或快照配置数据库持久性。
| Redis 企业软件 |
|---|
数据存储在 RAM 或 RAM 和闪存的组合 （Auto Tiering） 中，这可能会导致在进程或服务器故障期间丢失数据。Redis Enterprise Software 支持多种方法，以每个数据库为基础将数据持久化到磁盘，以确保数据持久性。
您可以在数据库创建期间或通过编辑现有数据库来配置持久性。尽管持久性模型可以动态更改，但切换可能需要一些时间，具体取决于数据库大小和要切换的模型。
配置数据库持久性
您可以在创建数据库时配置持久性，也可以编辑现有数据库的配置：
-
从 Databases 列表中，选择数据库，然后选择 Configuration。
-
选择 Edit（编辑）。
-
展开 Durability （持久性） 部分。
-
对于 Persistence （持久性），从列表中选择一个选项。
-
选择 Save （保存）。
数据持久性选项
Redis Enterprise Software 中有六个持久性选项：
| 选项 | 描述 |
|---|---|
| 没有 | 数据根本不持久化到磁盘。 |
| 仅附加文件 （AOF） - fsync 每次写入 | 每次写入时，数据都会同步到磁盘。 |
| 仅附加文件 （AOF） - 每 1 秒 fsync | 数据每秒同步到磁盘。 |
| 快照，每 1 小时 | 每小时创建一次数据库快照。 |
| 快照，每 6 小时 | 每 6 小时创建一次数据库快照。 |
| 快照，每 12 小时 | 每 12 小时创建一次数据库快照。 |
选择持久性策略
在选择持久性策略时，您应该考虑对数据丢失和性能需求的容忍度。两者之间总会有权衡取舍。 fsync（） 系统调用将数据从文件缓冲区同步到磁盘。您可以配置 Redis 执行 fsync（） 的频率，以最有效地在使用案例的性能和持久性之间进行权衡。 Redis 支持三种 fsync 策略：每次写入、每秒和禁用。
Redis 还允许通过 RDB 文件创建快照以实现持久性。在 Redis Enterprise 中，您可以配置快照和 fsync 策略。
对于任何高可用性需求，请使用复制来进一步降低数据丢失的风险。
对于数据丢失成本较高的使用案例：
仅附加文件 （AOF） - fsync 每次写入 - Redis Enterprise 设置 Redis 指令appendfsyncalways.使用此策略，Redis 将等待写入和 fsync 完成，然后再向客户端发送数据已写入的确认。除了执行命令之外，这还会引入 fsync 的性能开销。fsync 策略始终偏向于持久性而不是性能，当数据丢失成本较高时，应使用 fsync 策略。
对于只能有限容忍数据丢失的使用案例：
仅附加文件 （AOF） - 每 1 秒 fsync 一次 - Redis 将每秒 fsync 任何新写入的数据。此策略可平衡性能和持久性，在发生故障时可以接受最少的数据丢失时，应使用此策略。这是默认的 Redis 策略。此策略可能会导致 1 到 2 秒的数据丢失，但平均而言，这将接近 1 秒。
对于可以容忍或长时间恢复数据丢失的使用案例：
- 快照，每 1 小时 - 每小时执行一次完整备份。
- 快照，每 6 小时 - 每 6 小时执行一次完整备份。
- 快照，每 12 小时 - 每 12 小时执行一次完整备份。
- 无 - 根本不备份或保留数据。
仅附加文件 （AOF） 与快照 （RDB）
现在您知道了可用的选项，以帮助做出决策 关于哪个选项适合您的用例，下表中介绍了 二：
| 仅附加文件 （AOF） | 快照 （RDB） |
|---|---|
| 资源密集度更高 | 资源密集度较低 |
| 提供更好的持久性（恢复最新的时间点） | 耐用性较差 |
| 恢复时间较慢（文件较大） | 更快的恢复时间 |
| 需要更多磁盘空间（文件往往会变大并需要压缩） | 需要更少的资源（每隔几个小时一次 I/O，无需压缩） |
主动-主动数据持久性
主动-主动数据库仅支持 AOF 持久化。主动-主动数据库不支持快照持久性。
如果主动-主动数据库正在使用快照持久性，请使用crdb-cli切换到 AOF 持久化：
crdb-cli crdb update --crdb-guid <CRDB_GUID> --default-db-config \
'{"data_persistence": "aof", "aof_policy":"appendfsync-every-sec"}'
Auto Tiering data persistence
Auto Tiering flash storage is not considered persistent storage.
Flash-based databases are expected to hold larger datasets, and shard repair times can take longer after node failures. To better protect the database against node failures with longer repair times, consider enabling master and replica dual data persistence.
However, dual data persistence with replication adds some processor
and network overhead, especially for cloud configurations
with network-attached persistent storage, such as EBS-backed
volumes in AWS.
There may be times when performance is critical for your use case and
you don't want to risk data persistence adding latency.
You can enable or turn off data persistence on the master shards using the
following rladmin command:
rladmin tune db <database_ID_or_name> master_persistence <disabled | enabled>
On this page