One place for hosting & domains

      How To Expire Keys in Redis


      Introduction

      Redis is an open-source, in-memory key-value data store. Redis keys are persistent by default, meaning that the Redis server will continue to store them unless they are deleted manually. There may, however, be cases where you’ve set a key but you know you will want to delete it after a certain amount of time has passed; in other words, you want the key to be volatile. This tutorial explains how to set keys to expire, check the time remaining until a key’s expiration, and cancel a key’s expiration setting.

      How To Use This Guide
      This guide is written as a cheat sheet with self-contained examples. We encourage you to jump to any section that is relevant to the task you’re trying to complete.

      The commands shown in this guide were tested on an Ubuntu 18.04 server running Redis version 4.0.9. To set up a similar environment, you can follow Step 1 of our guide on How To Install and Secure Redis on Ubuntu 18.04. We will demonstrate how these commands behave by running them with redis-cli, the Redis command line interface. Note that if you’re using a different Redis interface — Redli, for example — the exact output of certain commands may differ.

      Alternatively, you could provision a managed Redis database instance to test these commands, but note that depending on the level of control allowed by your database provider, some commands in this guide may not work as described. To provision a DigitalOcean Managed Database, follow our Managed Databases product documentation. Then, you must either install Redli or set up a TLS tunnel in order to connect to the Managed Database over TLS.

      Setting Keys to Expire

      You can set an expiration time for an existing key with the expire command, which takes the name of the key and the number of seconds until expiration as arguments. To demonstrate this, run the following two commands. The first creates a string key named key_melon with a value of "cantaloupe", and the second sets it to expire after 450 seconds:

      • set key_melon "cantaloupe"
      • expire key_melon 450

      If the timeout was set successfully, the expire command will return (integer) 1. If setting the timeout failed, it will instead return (integer) 0.

      Alternatively, you can set the key to expire at a specific point in time with the expireat command. Instead of the number of seconds before expiration, it takes a Unix timestamp as an argument. A Unix timestamp is the number of seconds since the Unix epoch, or 00:00:00 UTC on January 1, 1970. There are a number of tools online you can use to find the Unix timestamp of a specific date and time, such as EpochConverter or UnixTimestamp.com.

      For example, to set key_melon to expire at 8:30pm GMT on May 1, 2025 (represented by the Unix timestamp 1746131400), you could use the following command:

      • expireat key_melon 1746131400

      Note that if the timestamp you pass to expireat has already occurred, it will delete the key immediately.

      Checking How Long Until a Key Expires

      Any time you set a key to expire, you can check the time remaining until expiry (in seconds) with ttl, which stands for “time to live”:

      Output

      (integer) 433

      For more granular information, you can run pttl which will instead return the amount of time until a key expires in milliseconds:

      Output

      (integer) 431506

      Both ttl and pttl will return (integer) -1 if the key hasn’t been set to expire and (integer) -2 if the key does not exist.

      Persisting Keys

      If a key has been set to expire, any command that overwrites the contents of a key — like set or getset — will clear a key’s timeout value. To manually clear a key’s timeout, use the persist command:

      The persist command will return (integer) 1 if it completed successfully, indicating that the key will no longer expire.

      Conclusion

      This guide details a number of commands used to manipulate and check key persistence in Redis. If there are other related commands, arguments, or procedures you’d like to see outlined in this guide, please ask or make suggestions in the comments below.

      For more information on Redis commands, see our tutorial series on How to Manage a Redis Database.



      Source link

      How To Manage Replicas and Clients in Redis


      Introduction

      Redis is an open-source, in-memory key-value data store. One of its most sought-after features is its support for replication: any Redis server can replicate its data to any number of replicas, allowing for high read scalability and strong data redundancy. Additionally, Redis was designed to allow many clients (up to 10000, by default) to connect and interact with data, making it a good choice for cases where many users need access to the same dataset.

      This tutorial goes over the commands used to manage Redis clients and replicas.

      How To Use This Guide
      This guide is written as a cheat sheet with self-contained examples. We encourage you to jump to any section that is relevant to the task you’re trying to complete.

      The commands shown in this guide were tested on an Ubuntu 18.04 server running Redis version 4.0.9. To set up a similar environment, you can follow Step 1 of our guide on How To Install and Secure Redis on Ubuntu 18.04. We will demonstrate how these commands behave by running them with redis-cli, the Redis command line interface. Note that if you’re using a different Redis interface — Redli, for example — the exact output of certain commands may differ.

      Alternatively, you could provision a managed Redis database instance to test these commands, but note that depending on the level of control allowed by your database provider, some commands in this guide may not work as described. To provision a DigitalOcean Managed Database, follow our Managed Databases product documentation. Then, you must either install Redli or set up a TLS tunnel in order to connect to the Managed Database over TLS.

      Note: The Redis project uses the terms “master” and “slave” in its documentation and in various commands to identify different roles in replication, though the project’s contributors are taking steps to change this language in cases where it doesn’t cause compatibility issues. DigitalOcean generally prefers to use the alternative terms “primary” and “replica”.

      This guide will default to “primary” and “replica” whenever possible, but note that there are a few instances where the terms “master” and “slave” unavoidably come up.

      Managing Replicas

      One of Redis’s most distinguishing features is its built-in replication. When using replication, Redis creates exact copies of the primary instance. These secondary instances reconnect to the primary any time their connections break and will always aim to remain an exact copy of the primary.

      If you’re not sure whether the Redis instance you’re currently connected to is a primary instance or a replica, you can check by running the role command:

      This command will return either master or slave, or potentially sentinel if you’re using Redis Sentinel.

      To designate a Redis instance as a replica of another instance on the fly, run the replicaof command. This command takes the intended primary server’s hostname or IP address and port as arguments:

      • replicaof hostname_or_IP port

      If the server was already a replica of another primary, it will stop replicating the old server and immediately start synchronizing with the new one. It will also discard the old dataset.

      To promote a replica back to being a primary, run the following replicaof command:

      This will stop the instance from replicating the primary server, but will not discard the dataset it has already replicated. This syntax is useful in cases where the original primary fails. After running replicaof no one on a replica of the failed primary, the former replica can be used as the new primary and have its own replicas as a failsafe.

      Note: Prior to version 5.0.0, Redis instead included a version of this command named slaveof.

      Managing Clients

      A client is any machine or software that connects to a server in order to access a service. Redis comes with several commands that help with tracking and managing client connections.

      The client list command returns a set of human-readable information about current client connections:

      Output

      "id=18165 addr=[2001:db8:0:0::12]:47460 fd=7 name=jerry age=72756 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping id=18166 addr=[2001:db8:0:1::12]:47466 fd=8 name= age=72755 idle=5 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=info id=19381 addr=[2001:db8:0:2::12]:54910 fd=9 name= age=9 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 obl=0 oll=0 omem=0 events=r cmd=client "

      Here is what each of these fields mean:

      • id: a unique 64-bit client ID
      • name: the name of the client connection, as defined by a prior client setname command
      • addr: the address and port from which the client is connecting
      • fd: the file descriptor that corresponds to the socket over which the client is connecting
      • age: the total duration of the client connection, in seconds
      • flags: a set of one or more single-character flags that provide more granular detail about the clients; see the client list command documentation for more details
      • db: the current database ID number that the client is connected to (can be from 0 to 15)
      • sub: the number of channels the client is subscribed to
      • psub: the number of the client’s pattern-matching subscriptions
      • mutli: the number of commands the client has queued in a transaction (will show -1 if the client hasn’t begun a transaction or 0 if it has only started a transaction and not queued any commands)
      • qbuf: the client’s query buffer length, with 0 meaning it has no pending queries
      • qbuf-free: the amount of free space in the client’s query buffer, with 0 meaning that the query buffer is full
      • obl: the client’s output buffer length
      • oll: the length of the client’s output list, where replies are queued when its buffer is full
      • omem: the memory used by the client’s output buffer
      • events: the client’s file descriptor events, these can be r for “readable”, w for “writable,” or both
      • cmd: the last command run by the client

      Setting client names is useful for debugging connection leaks in whatever application is using Redis. Every new connection starts without an assigned name, but client setname can be used to create one for the current client connection. There’s no limit to how long client names can be, although Redis usually limits string lengths to 512 MB. Note, though, that client names cannot include spaces:

      To retrieve the name of a client connection, use the client getname command:

      Output

      "elaine"

      To retrieve a client’s connection ID, use the client id command:

      Output

      (integer) "19492"

      Redis client IDs are never repeated and are monotonically incremental. This means that if one client has an ID greater than another, then it was established at a later time.

      Blocking Clients and Closing Client Connections

      Replication systems are typically described as being either synchronous or asynchronous. In synchronous replication, whenever a client adds or changes data it must receive some kind of acknowledgement from a certain number of replicas for the change to register as having been committed. This helps to prevent nodes from having data conflicts but it comes at a cost of latency, since the client must wait to perform another operation until it has heard back from a certain number of replicas.

      In asynchronous replication, on the other hand, the client sees a confirmation that the operation is finished as soon as the data is written to local storage. There can, however, be a lag between this and when the replicas actually write the data. If one of the replicas fails before it can write the change, that write will be lost forever. So while asynchronous replication allows clients to continue performing operations without the latency caused by waiting for replicas, it can lead to data conflicts between nodes and may require extra work on the part of the database administrator to resolve those conflicts.

      Because of its focus on performance and low latency, Redis implements asynchronous replication by default. However, you can simulate synchronous replication with the wait command. wait blocks the current client connection for a specified amount of time (in milliseconds) until all the previous write commands are successfully transferred and accepted by a specified number of replicas. This command uses the following syntax:

      • wait number_of_replicas number_of_milliseconds

      For example, if you want to block your client connection until all the previous writes are registered by at least 3 replicas within a 30 millisecond timeout, your wait syntax would look like this:

      The wait command returns an integer representing the number of replicas that acknowledged the write commands, even if not every replica does so:

      Output

      2

      To unblock a client connection that has been previously blocked, whether from a wait, brpop, or xread command, you can run a client unblock command with the following syntax:

      To temporarily suspend every client currently connected to the Redis server, you can use the client pause command. This is useful in cases where you need to make changes to your Redis setup in a controlled way. For example, if you’re promoting one of your replicas to be the primary instance, you might pause every client beforehand so you can promote the replica and have the clients connect to it as the new primary without losing any write operations in the process.

      The client pause command requires you to specify the amount of time (in milliseconds) you’d like to suspend the clients. The following example will suspend all clients for one second:

      The client kill syntax allows you to close a single connection or a set of specific connections based on a number of different filters. The syntax looks like this:

      • client kill filter_1 value_1 ... filter_n value_n

      In Redis versions 2.8.12 and later, the following filters are available:

      • addr: allows you to close a client connection from a specified IP address and port
      • client-id: allows you to close a client connection based on its unique ID field
      • type: closes every client of a given type, which can be either normal, master, slave, or pubsub
      • skipme: the value options for this filter are yes and no:
        • if no is specified, the client calling the client kill command will not get skipped, and will be killed if the other filters apply to it
        • if yes is specified, the client running the command will be skipped and the kill command will have no effect on the client. skipme is always yes by default

      Conclusion

      This guide details a number of commands used to manage Redis clients and replicas. If there are other related commands, arguments, or procedures you’d like to see outlined in this guide, please ask or make suggestions in the comments below.

      For more information on Redis commands, see our tutorial series on How to Manage a Redis Database.



      Source link

      How To Run Transactions in Redis


      Introduction

      Redis is an open-source, in-memory key-value data store. Redis allows you to plan a sequence of commands and run them one after another, a procedure known as a transaction. Each transaction is treated as an uninterrupted and isolated operation, which ensures data integrity. Clients cannot run commands while a transaction block is being executed

      This tutorial goes over how to execute and cancel transactions, and also includes some information on pitfalls commonly associated with transactions.

      How To Use This Guide
      This guide is written as a cheat sheet with self-contained examples. We encourage you to jump to any section that is relevant to the task you’re trying to complete.

      The commands shown in this guide were tested on an Ubuntu 18.04 server running Redis version 4.0.9. To obtain a similar setup, you can follow Step 1 of our guide on How To Install and Secure Redis on Ubuntu 18.04. We will demonstrate how these commands behave by running them with redis-cli, the Redis command line interface. Note that if you’re using a different Redis interface — Redli, for example — the exact output of certain commands may differ.

      Alternatively, you could provision a managed Redis database instance to test these commands, but note that depending on the level of control allowed by your database provider, some commands in this guide may not work as described. To provision a DigitalOcean Managed Database, follow our Managed Databases product documentation. Then, you must either install Redli or set up a TLS tunnel in order to connect to the Managed Database over TLS.

      Running Transactions

      The multi command tells Redis to begin a transaction block. Any subsequent commands will be queued up until you run an exec command, which will execute them.

      The following commands form a single transaction block. The first command initiates the transaction, the second sets a key holding a string with the value of 1, the third increases the value by 1, the fourth increases its value by 40, the fifth returns the current value of the string, and the last one executes the transaction block:

      • multi
      • set key_MeaningOfLife 1
      • incr key_MeaningOfLife
      • incrby key_MeaningOfLife 40
      • get key_MeaningOfLife
      • exec

      After running multi, redis-cli will respond to each of the following commands with QUEUED. After you run the exec command, it will show the output of each of those commands individually:

      Output

      1) OK 2) (integer) 2 3) (integer) 42 4) "42"

      Commands included in a transaction block are run sequentially in the order they’re queued. Redis transactions are atomic, meaning that either every command in a transaction block is processed (meaning that it’s accepted as valid and queued to be executed) or none are. However, even if a command is successfully queued, it may still produce an error when executed. In such cases, the other commands in the transaction can still run, but Redis will skip the error-causing command. See the section on understanding transaction errors for more details.

      Canceling Transactions

      To cancel a transaction, run the discard command. This prevents any previously-queued commands from running:

      • multi
      • set key_A 146
      • incrby key_A 10
      • discard

      Output

      OK

      The discard command returns the connection to a normal state, which tells Redis to run single commands as usual. You’ll need to run multi again to tell the server you’re starting another transaction.

      Understanding Transaction Errors

      Some commands may be impossible to queue, such as commands with syntax errors. If you attempt to queue a syntactically incorrect command Redis will return an error.

      The following transaction createst a key named key_A and then attempts to increment it by 10. However, a spelling error in the incrby command causes and error and closes the transaction:

      • multi
      • set key_A 146
      • incrbuy key_A 10

      Output

      (error) ERR unknown command 'incrbuy'

      If you try to run an exec command after trying to queue a command with a syntax error like this one, you will receive another error message telling you that the transaction was discarded:

      Output

      (error) EXECABORT Transaction discarded because of previous errors.

      In cases like this, you’ll need to restart the transaction block and make sure you enter each command correctly.

      Some impossible commands are possible to queue, such as running incr on a key containing only a string. Because such command is syntactically correct, Redis won’t return an error if you try to include it in a transaction and won’t prevent you from running exec. In cases like this, all other commands in the queue will be executed, but the impossible command will return an error:

      • multi
      • set key_A 146
      • incrby key_A "ten"
      • exec

      Output

      1) OK 2) (error) ERR value is not an integer or out of range

      For more information on how Redis handles errors inside transactions, see the official documentation on the subject.

      Conclusion

      This guide details a number of commands used to create, run, and cancel transactions in Redis. If there are other related commands, arguments, or procedures you’d like to see outlined in this guide, please ask or make suggestions in the comments below.

      For more information on Redis commands, see our tutorial series on How to Manage a Redis Database.



      Source link