Articles in this section

Why do clients reports error code 22: AEROSPIKE_ERR_FAIL_FORBIDDEN when writing to a set?

Problem Description

A client (can also be asrestore) reports an error during operation:

Error while storing record - code 22: AEROSPIKE_ERR_FAIL_FORBIDDEN at src/main/aerospike/as_command.c:594

Explanation

This error indicates that the record cannot be written. There can be different situations that cause this issue. The most common causes with solutions are covered below. Refer to the solution application to you.
- Attempting to write to a set that is undergoing deletion.
- Attempting to write to a set that is under stop-write situation
- Attempting to write to a namespace via a regular client when it is configured to only accept writes from XDR client.
- Cluster clock skew between nodes is greater than 40 seconds.
- Attempting to write a record with TTL to a namespace which has namespace supervisor disabled.

Solution

  • Writing to a set that is being deleted (set-delete for server versions prior to 3.14) or a truncate command has been issued with a timestamp preventing writes. (Check for set-delete or truncate in the server logs).

    Solution: Avoid writing to set when a delete operation is ongoing. If the set-delete was in force during the write operation, wait for the set-delete to complete before attempting to write the records.

 

 

 

 
  • If writing via a regular client when allow-nonxdr-writes is set to false or, for XDR traffic, when allow-xdr-writes is set to false. See fail_xdr_forbidden statistic for related information.

    Solution: Verify and update the configurations to ensure they are set per your use-case.

 

 
  • As of Aerospike Server 4.5.1, for each Available mode (AP) namespace where nsup is enabled (i.e. nsup-period not zero) writes will be suspended if cluster clock skew exceeds 40 seconds.

    Solution: Confirm if the cluster clock is skew within the specified limit

 

 
  • If writing or updating records with a TTL while nsup-period is set to 0. When using Aerospike Server 4.9 or above, the default value of nsup-period is set to zero (disabled). This means that the sub-system within Aerospike that controls eviction and expiration (the namespace supervisor) is not running by default and the database will not accept records with an expiration set.

    Solution: The applicable solution depends on the desired behaviour of the database. If expiration and eviction are not required then when the record is written or updated do not set a TTL. This is done at an application level. If it is required to have records expiring or being evicted to free up space then enable nsup by changing nsup-period to a value other than zero.

    If the default-ttl is configured with a value other than 0 the database will not start with nsup-period equal to zero.

    There is a parameter called allow-ttl-without-nsup which allows the user to write records with a TTL even when nsup-period is set to zero. The purpose of this parameter is to allow testing of the amount of CPU used by the namespace supervisor (NSUP) sub-system. This parameter should not be used unless it is part of a formalised testing process. Enabling allow-ttl-without-nsup is not recommended since records might that might be expected to expire will not be removed from the device or memory. For additional discussion, see Namespace Data Retention Configuration.


Applies To Earliest Version

Pre 4.9

Applies To Latest Version

Current Version
Was this article helpful?
0 out of 0 found this helpful