Redis persistence refers to the process of periodically saving data from memory to disks to prevent data loss. This ensures that if Redis stops responding or restarts, data can be restored from the persistent files on disks. ApsaraDB for Redis provides the Redis database (RDB), append-only file (AOF), and Tair-Binlog persistence policies to meet the backup and restoration requirements in various scenarios.
Persistence policies
ApsaraDB for Redis supports the following persistence policies:
RDB persistence
RDB persistence creates snapshots of the data stored in Redis at specified intervals, and saves the snapshots to disks in the form of RDB files. This way, data persistence is implemented. RDB files are small in size and easy to migrate. You can use RDB files to back up or migrate data of a specified point in time.
When Redis generates RDB files, operations in progress may be blocked. The blocking time varies based on the total amount of data in the instance. ApsaraDB for Redis optimizes the persistence mechanism and implements non-blocking backup. This optimization allows instance backup operations to occur without affecting client requests.
By default, Redis instances are configured to back up data automatically once a day. You can modify the automatic backup policy based on your business requirements or manually create a temporary backup.
AOF persistence
AOF persistence logs all write operations received by the server, such as SET. These operations can then be replayed again at server startup, reconstructing the original dataset.
As the number of entries in an AOF grows, Redis starts an AOF rewrite process to reorganize the AOF when the AOF reaches a specific size. This process reduces the disk usage of the AOF and enhances the efficiency of data restoration. However, AOF rewrite can incur some performance overhead for write operations.
By default, AOF persistence is enabled in ApsaraDB for Redis. The AOF persistence policy is AOF_FSYNC_EVERYSEC and cannot be modified. Redis performs an fsync operation every second as per the policy to flush write commands from the AOF buffer to disks. This process is also referred to as AOF flushing. The AOF_FSYNC_EVERYSEC policy has little impact on the performance of Redis while also significantly reducing the risk of data loss in the event of an accident.
Tair-Binlog
Tair DRAM-based instances not only support the preceding two persistence policies, but also optimizes the AOF persistence mechanism to implement AOF incremental archiving. After optimization, AOFs can be archived incrementally to prevent performance degradation caused by AOF rewrite. Incremental archiving also allows data in an instance or a key to be restored to a point in time accurate to the second as this method saves each write operation and its timestamp. This data restoration process is called point-in-time recovery (PITR). For more information, see Use data flashback to restore data by point in time.
Backup and restoration solutions
ApsaraDB for Redis implements data backup and restoration based on RDB persistence, AOF persistence, and AOF incremental archiving.
Category | Solution | Description |
Data backup | Redis supports data persistence. Instance data is automatically backed up based on the default backup policy (based on RDB). You can modify the automatic backup policy based on your business requirements or manually create a temporary backup. | |
Backup files of Redis can be retained for 7 to 730 days. If you want to retain backup files for a longer period of time, you can download the backup files to your computer. For example, you may want to retain backup files for a longer period of time due to regulatory or information security requirements. | ||
Data restoration | Redis allows you to create an instance from a specified backup set. The data in the new instance is the same as that in the backup set. This feature is suitable for scenarios such as data restoration, quick workload deployment, and data verification. | |
After you enable the data flashback feature (based on AOF), you can restore Redis data of an instance to a specified point in time accurate to the second. This feature minimizes data loss caused by accidental operations and is suitable for scenarios in which data is frequently restored. Note This feature is supported only for Tair DRAM-based instances. |