Development and O&M Rules

This section describes usage rules of the GeminiDB Redis database based on Huawei's years of experience in cloud database development and O&M, so as to help you effectively evaluate and improve service system stability.

Development Rules

When developing a service program, you need to pay attention to the following development rules to prevent service instability caused by improper usage.

**Table 1** Development rules of GeminiDB Redis
No.	Development Rules	Description
1	The service program must have a proper automatic reconnection mechanism.	In scenarios for the specification change, patch upgrade, HA switchover, network link jitter, or packet loss, the connection between the service program and the DB instance may be interrupted for a short period of time. The service program must support automatic reconnection. NOTE: Use Jedis instead of Lettuce because Lettuce is not automatically reconnected after multiple requests time out.
2	Provide a connection pool and configure sufficient connections for a service program.	To prevent the program from failing to obtain connections when the number of concurrent requests increases sharply, you are advised to use a connection pool for the service program and configure proper connection pool parameters. For details about the recommended configuration of the connection pool of the client, see Configuring Parameters for a Client Connection Pool.
3	The service program must have a proper command retry mechanism for important operations.	When the connection is interrupted or the request times out, requests from the service program may fail to be executed within a short period of time. Therefore, a service fault tolerance mechanism is needed. Proper command retry intervals and times can ensure important data is successfully written or modified.
4	A correct HA connection address needs to be used to prevent services from being affected by a single point of failure.	When connecting a service program to a database through a private network, use a load balancer IP address to achieve HA. Do not directly connect the service program to an independent compute node. NOTE: If a database is accessed from a public network, do not directly connect the service program to an independent compute node.
5	A connection pool needs to be used to avoid using a single connection or a large number of short connections.	A single connection has HA risks. The performance of short connections is poor, and short connections consume a large number of CPUs and network resources, which may cause bottlenecks. Therefore, you are advised to use mainstream SDK connection pools to connect a service program to GeminiDB Redis instances.
6	You are not allowed to run the KEYS command when there are more than 1,000 keys in an instance.	The KEYS command is a typical high-risk command. It obtains all data in the entire instance at a time and returns the data to the client. If there are a large number of keys in an instance, running the KEYS command will block requests or make the instance unavailable.
7	Do not set element values to excessively large or small values and ensure the number of elements contained in a single key is not too large.	The recommended maximum key size of the string data type is 10 KB. Fewer than 5,000 elements are recommended for keys of HASH, LIST, ZSET, or SET data types. The recommended value size of a single element is 1 KB or smaller. NOTE: Similar to Redis Community Edition, GeminiDB Redis API does not strictly restrict storage of big keys. Therefore, you need to develop service programs according to related specifications.
8	A single command does not contain many elements at a time. Too large network packets cannot be generated by a single command.	It is recommended that no more than 1000 keys be concurrently operated using MSET or MGET. Make sure that no more than 1000 key elements to be concurrently operated using HMSET, HGETALL, LRANGE, ZADD, or ZRANGE. The limit parameter is not included in the Redis ZREMRANGEBYSCORE command, so the number of elements to be deleted at a time cannot be limited. You are advised to use ZRANGEBYSCORE (with limit) + ZREM instead. NOTE: Similar to Redis Community Edition, GeminiDB Redis API does not strictly restrict access of big keys. Therefore, you need to develop service programs according to related specifications.
9	Properly distribute keys to avoid performance bottlenecks in hotspot keys or hash tags.	Frequent access to a single key or a group of keys with the same hash tags may cause hot key problems, which may cause bottlenecks such as compute resource skew, request queuing, and slow response. Hot keys are usually created due to insufficient key splitting in service design. Therefore, service splitting needs to be optimized. NOTE: Negative examples: Ultra-large global rankings are accessed frequently and intensively. Several hash keys are stored in an instance. Each key is used to store information of the entire table. For product inventory, there are only a small number of bucket hash tags for all keys. As a result, requests for querying hot hash tags may queue.
10	Run less than 100 packaging commands at a time using the pipeline.	Do not include a large number of commands in a pipeline. Using pipelines improperly may cause bottlenecks in CPU and bandwidth resources and block requests. NOTE: Similar to Redis Community Edition, GeminiDB Redis API does not strictly restrict pipeline usage. Therefore, you need to develop service programs according to related specifications.
11	Do not use time-consuming code in Lua scripts.	When using LUA scripts, excessive command execution times and time-consuming statements such as long-time sleep and large loop statements should be avoided.
12	Do not pack too many commands in a transaction.	When using a transaction, do not pack too many commands or complex commands in a single transaction. If a transaction contains too many commands, requests are blocked, or the instance may become abnormal.
13	Different data types cannot use the same key.	In Redis Community Edition, the same key name cannot be used for different data types. Although GeminiDB Redis API does not have mandatory restrictions on this, avoid using the same key for different data types to keep programs clear and easy to maintain.
14	Exercise caution when running batch deletion commands.	Do not delete too much data (tens or hundreds of thousands of elements) of the LIST and ZSET types via a single batch deletion command (for example, LREM, LTRIM, and ZREMRANGEBYSCORE). Deleting a large amount of data may take a long time, affecting other commands. Processes causing OOM may restart and the instance may be abnormal. In extreme scenarios, service processes may fail to be started repeatedly.
15	Cursors returned by a SCAN command must be parsed as 64-bit unsigned integers.	Similar to the open-source Redis, GeminiDB encodes cursors into 64-bit unsigned integers. Therefore, the returned cursors need to be parsed as 64-bit unsigned integers. Otherwise, a parsing error may occur. If GeminiDB receives these incorrect results, error message "invalid cursor" will be reported.
16	The length of Redis inline commands must be less than 64 KB.	This rule is also applied for open-source Redis to avoid risks such as OOM. If the length of a command exceeds 64 KB, error message "ERR Protocol error: too big inline request" will be returned to a server.
17	Avoid frequently running SUBSCRIBE commands and blocking commands like BRPOP to prevent the server from exhausting connection resources and failing to accept new connections.	A shared connection pool is maintained for communication between proxies and shards. Common commands reuse these connections. To execute blocking commands (such as BRPOP) and SUBSCRIBE commands, dedicated connections need to be established for proxies and shards. As a result, the number of connections per shard might exceed the maximum capacity of an individual process, and new connections cannot be established. Therefore, ensure that fewer than 1,000 client connections are established for a single proxy when running these commands.

O&M Rules

During routine O&M, you need to pay attention to the following O&M rules to prevent potential risks and master key emergency solutions.

**Table 2** O&M rules of GeminiDB Redis API
No.	Rule	Description
1	Ensure that the phone number and email address bound to your Huawei Cloud account are valid so that you can receive notifications in a timely manner.	Huawei Cloud will send notifications to you through websites, emails, SMS messages, or internal messages in scenarios for changes, upgrades, and fault notifications. Ensure that the contact information bound to your account is valid.
2	Subscribe to major alarms.	You can subscribe to alarms such as big key access, high storage utilization, high connection usage, and high CPU usage to detect and handle instance risks in a timely manner. For details, see Configuring Alarm Rules.
3	When the LB address is used for access, you need to configure access control instead of security groups.	A load balancer address does not support security groups. After instance creation is complete, configure IP address access control. If no whitelist is configured, all IP addresses that can communicate with the VPC can access the instance.
4	Reserve more than 50% of storage space to prevent instances from becoming read-only.	GeminiDB uses RocksDB as the storage engine. Data is periodically compacted to improve read performance. While data is compacted, temporary files are generated, occupying more storage space temporarily. The storage space usage varies depending on the service model, and it may increase by two times. It is relatively inexpensive to store data on disks. You are advised to reserve 50% of storage space.
5	Configure autoscaling for instances.	GeminiDB Redis instance storage can be automatically scaled up in case of a sudden surge in data volumes. Enable autoscaling by following Automatically Scaling Up Storage Space.
6	Keep the instance load healthy.	If the service data volume is greater than 80% for a long time, you are advised to expand the capacity in a timely manner. If the service traffic exceeds the QPS limit of an instance or the CPU usage maintains 80% or more for a long time, upgrade the specifications or add nodes to prevent overloading and affecting service access. When the instance computing power is overloaded due to the sharp increase of service traffic and the number of connections, you can add nodes to quickly improve the cluster computing power. Scaling up CPU cores is performed in rolling mode and takes a long time, which is not recommended in emergency scenarios.
7	Rename high-risk commands.	Disable or rename high-risk commands such as FLUSHALL, or KEYS to enhance instance security. For details, see Renaming Commands.
8	Exercise caution when performing the FLUSHALL operation during account management.	When an IAM user with the read and write permissions executes FLUSHALL, all data on the instance is cleared. Do not perform FLUSHALL. You can perform FLUSHDB after confirming the database. Exercise caution when performing this operation.
9	Perform periodical online diagnosis of big keys.	You can periodically view the big key diagnosis report of the instance on the console to view keys that are the most frequently accessed in the Redis database. For details, see Big Key Diagnosis.
10	Run the dbsize command after migration.	Running DBSIZE can ensure data consistency. For example, if there are no expired keys, you can run DBSIZE several minutes after data is imported to obtain the accurate number of keys and ensure data consistency.