All Products
Search
Document Center

Tair (Redis® OSS-Compatible):Disable AOF persistence

Last Updated:Nov 14, 2024

By default, append-only file (AOF) persistence is enabled for Tair (Redis OSS-compatible) instances. This topic describes how to configure the appendonly parameter to enable or disable AOF persistence.

Overview

Tair (Redis OSS-compatible) provides two data persistence options: AOF persistence and Redis Database (RDB) persistence. AOF persistence logs all write operations received by the server, such as SET. These operations can then be replayed again at server startup to reconstruct the original dataset. If an AOF is larger than required, the AOF is automatically rewritten to reduce its disk usage. AOF persistence in Tair (Redis OSS-compatible) works in the same way as that in Redis.

The AOF persistence policy for Tair (Redis OSS-compatible) instances is AOF_FSYNC_EVERYSEC. The policy specifies that the system records all write commands in an AOF every second and saves the AOF to disks. This process is also referred to as AOF flushing. The policy has little impact on the performance of instances and can minimize data loss in various unexpected conditions. Tair (Redis OSS-compatible) supports AOF incremental archiving, which prevents performance degradation caused by AOF rewrite.

AOF persistence generates some write performance overhead. If your instance is used only for caching purposes and you have no requirements for data persistence, you can perform the operations described in this topic to configure the appendonly parameter to disable AOF persistence for the instance.

Note

An AOF rewrite is triggered when the size of the AOF exceeds 25% of the instance memory and increases by more than 200% since the most recent rewrite (known as base rewrite). For empty instances, the size of the AOF during the base rewrite is 1 byte.

Status and impacts of AOF persistence

  • By default, AOF persistence is enabled when you create a Tair or Redis Open-Source Edition instance, unless the instance is a Tair persistent memory-optimized instance.

  • If you set the appendonly parameter to no, take note of the following impacts:

    • The system disables AOF persistence without the need to restart the instance.

    • After AOF persistence is disabled, AOFs cannot be used to restore data.

    • Existing AOF logs remain unaffected.

    • For a standard instance, AOF persistence is disabled for the master node, and the replica node is unaffected.

    • For a cluster instance, AOF persistence is disabled for the master nodes of all data shards, and the replica nodes are unaffected.

    • For a read/write splitting instance, AOF persistence is disabled for the master node and all read replicas, and the replica node is unaffected.

    • For a master-replica instance, disabling AOF persistence on the primary database can help reduce the latency caused by the AOF rewrite process. However, this may result in losing an additional layer of data protection.

  • If you change the value of the appendonly parameter from no to yes, take note of the following impacts:

    • The system enables AOF persistence without the need to restart the instance.

    • After AOF persistence is enabled, the system periodically performs a rewrite to compress the generated AOF. During the rewrite process, the system uses a technique called forking to create a child process that manages the compression. However, the forking operation can lead to a temporary delay that can last from several milliseconds to over a hundred milliseconds, depending on the memory usage of the instance. In Linux or Unix-like operating systems, forking involves copying the page tables, which can cause latency.

Scenarios

  • If the AOF persistence feature is enabled for your instance and the instance experiences long delays due to the time taken by the fork and aof_write operations, we recommend that you disable the AOF persistence feature.

  • If your instance is used as a caching application, we recommend that you disable the AOF persistence feature.

Warning

If you use a Tair (Enterprise Edition) instance for which Data Transmission Service (DTS) active geo-redundancy or data flashback (point-in-time data restoration) is enabled, you cannot disable the AOF persistence feature for the instance.

Procedure

  1. Log on to the console and go to the Instances page. In the top navigation bar, select the region in which the instance that you want to manage resides. Then, find the instance and click the instance ID.

  2. In the left-side navigation pane, click Parameter Settings.

  3. On the System Parameters page, click Modify in the Actions column corresponding to the appendonly parameter.
  4. In the dialog box that appears, perform the following steps:
    1. Set the appendonly parameter.
      Valid values:
      • yes: enables AOF persistence.
      • no: disables AOF persistence.
    2. Click OK.

Related API operations

API operation

Description

DescribeParameters

Queries the configuration and operational parameters of an instance.

ModifyInstanceConfig

Modifies the parameter settings of an instance.