From 207e09f2098b8e2a8fcefbcb0847b2241e528c69 Mon Sep 17 00:00:00 2001 From: Itamar Haber Date: Sat, 14 Dec 2019 20:14:39 +0200 Subject: [PATCH 0001/1006] Moves some commands to a new 'bit' category This moves the 6 bit-related commands from the 'string' to a new category. The motivation is giving more exposure for these lesser- known capabilities. --- commands.json | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/commands.json b/commands.json index 05fea94bf9..0102c805fb 100644 --- a/commands.json +++ b/commands.json @@ -57,7 +57,7 @@ } ], "since": "2.6.0", - "group": "string" + "group": "bit" }, "BITFIELD": { "summary": "Perform arbitrary bitfield integer operations on strings", @@ -119,7 +119,7 @@ } ], "since": "3.2.0", - "group": "string" + "group": "bit" }, "BITOP": { "summary": "Perform bitwise operations between strings", @@ -140,7 +140,7 @@ } ], "since": "2.6.0", - "group": "string" + "group": "bit" }, "BITPOS": { "summary": "Find first bit set or clear in a string", @@ -166,7 +166,7 @@ } ], "since": "2.8.7", - "group": "string" + "group": "bit" }, "BLPOP": { "summary": "Remove and get the first element in a list, or block until one is available", @@ -1220,7 +1220,7 @@ } ], "since": "2.2.0", - "group": "string" + "group": "bit" }, "GETRANGE": { "summary": "Get a substring of the string stored at a key", @@ -2548,7 +2548,7 @@ } ], "since": "2.2.0", - "group": "string" + "group": "bit" }, "SETEX": { "summary": "Set the value and expiration of a key", From e0fb54518b634230eeeed1721a6cc5c7f8838ebc Mon Sep 17 00:00:00 2001 From: Itamar Haber Date: Wed, 5 Feb 2020 19:15:38 +0200 Subject: [PATCH 0002/1006] Renames bit group to bitmap to conform to internals --- commands.json | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/commands.json b/commands.json index 0102c805fb..efd2a2ce76 100644 --- a/commands.json +++ b/commands.json @@ -57,7 +57,7 @@ } ], "since": "2.6.0", - "group": "bit" + "group": "bitmap" }, "BITFIELD": { "summary": "Perform arbitrary bitfield integer operations on strings", @@ -119,7 +119,7 @@ } ], "since": "3.2.0", - "group": "bit" + "group": "bitmap" }, "BITOP": { "summary": "Perform bitwise operations between strings", @@ -140,7 +140,7 @@ } ], "since": "2.6.0", - "group": "bit" + "group": "bitmap" }, "BITPOS": { "summary": "Find first bit set or clear in a string", @@ -166,7 +166,7 @@ } ], "since": "2.8.7", - "group": "bit" + "group": "bitmap" }, "BLPOP": { "summary": "Remove and get the first element in a list, or block until one is available", @@ -1220,7 +1220,7 @@ } ], "since": "2.2.0", - "group": "bit" + "group": "bitmap" }, "GETRANGE": { "summary": "Get a substring of the string stored at a key", @@ -2548,7 +2548,7 @@ } ], "since": "2.2.0", - "group": "bit" + "group": "bitmap" }, "SETEX": { "summary": "Set the value and expiration of a key", From c72a016de2a65647972633c2b615fd33bf04c718 Mon Sep 17 00:00:00 2001 From: Tyson Andre Date: Wed, 30 Sep 2020 01:51:08 -0400 Subject: [PATCH 0003/1006] Add documentation for zmscore command (#1361) Co-authored-by: Tyson Andre --- commands.json | 17 +++++++++++++++++ commands/zmscore.md | 16 ++++++++++++++++ 2 files changed, 33 insertions(+) create mode 100644 commands/zmscore.md diff --git a/commands.json b/commands.json index 8f606997f3..207447f4ec 100644 --- a/commands.json +++ b/commands.json @@ -3883,6 +3883,23 @@ "since": "1.2.0", "group": "sorted_set" }, + "ZMSCORE": { + "summary": "Get the score associated with the given members in a sorted set", + "complexity": "O(N) where N is the number of members being requested.", + "arguments": [ + { + "name": "key", + "type": "key" + }, + { + "name": "member", + "type": "string", + "multiple": true + } + ], + "since": "6.2.0", + "group": "sorted_set" + }, "ZUNIONSTORE": { "summary": "Add multiple sorted sets and store the resulting sorted set in a new key", "complexity": "O(N)+O(M log(M)) with N being the sum of the sizes of the input sorted sets, and M being the number of elements in the resulting sorted set.", diff --git a/commands/zmscore.md b/commands/zmscore.md new file mode 100644 index 0000000000..c2317e90b8 --- /dev/null +++ b/commands/zmscore.md @@ -0,0 +1,16 @@ +Returns the scores associated with the specified `members` in the sorted set stored at `key`. + +For every `member` that does not exist in the sorted set, a `nil` value is returned. + +@return + +@array-reply: list of scores or `nil` associated with the specified `member` values (a double precision floating point number), +represented as strings. + +@examples + +```cli +ZADD myzset 1 "one" +ZADD myzset 2 "two" +ZMSCORE myzset "one" "two" "nofield" +``` From 6608023641d860f24734220aa8263071b2f41b01 Mon Sep 17 00:00:00 2001 From: valentinogeron Date: Wed, 30 Sep 2020 08:58:39 +0300 Subject: [PATCH 0004/1006] Add docs for XGROUP CREATECONSUMER subcommand (#1385) Co-authored-by: Itamar Haber --- commands.json | 14 ++++++++++++++ commands/xgroup.md | 17 +++++++++++++---- topics/notifications.md | 1 + 3 files changed, 28 insertions(+), 4 deletions(-) diff --git a/commands.json b/commands.json index 207447f4ec..4619dc1ad5 100644 --- a/commands.json +++ b/commands.json @@ -4313,6 +4313,20 @@ ], "optional": true }, + { + "command": "CREATECONSUMER", + "name": [ + "key", + "groupname", + "consumername" + ], + "type": [ + "key", + "string", + "string" + ], + "optional": true + }, { "command": "DELCONSUMER", "name": [ diff --git a/commands/xgroup.md b/commands/xgroup.md index f503c12267..95dc9fb550 100644 --- a/commands/xgroup.md +++ b/commands/xgroup.md @@ -40,15 +40,20 @@ The consumer group will be destroyed even if there are active consumers and pending messages, so make sure to call this command only when really needed. +Consumers in a consumer group are auto-created every time a new consumer +name is mentioned by some command. They can also be explicitly created +by using the following form: + + XGROUP CREATECONSUMER mystream consumer-group-name myconsumer123 + To just remove a given consumer from a consumer group, the following form is used: XGROUP DELCONSUMER mystream consumer-group-name myconsumer123 -Consumers in a consumer group are auto-created every time a new consumer -name is mentioned by some command. However sometimes it may be useful to -remove old consumers since they are no longer used. This form returns -the number of pending messages that the consumer had before it was deleted. +Sometimes it may be useful to remove old consumers since they are no longer +used. This form returns the number of pending messages that the consumer +had before it was deleted. Finally it possible to set the next message to deliver using the `SETID` subcommand. Normally the next ID is set when the consumer is @@ -64,3 +69,7 @@ Finally to get some help if you don't remember the syntax, use the HELP subcommand: XGROUP HELP + +@history + + * `>= 6.2.0`: Supports the `CREATECONSUMER` subcommand. diff --git a/topics/notifications.md b/topics/notifications.md index b84a774d11..786e348a34 100644 --- a/topics/notifications.md +++ b/topics/notifications.md @@ -136,6 +136,7 @@ Different commands generate different kind of events according to the following * `XADD` generates an `xadd` event, possibly followed an `xtrim` event when used with the `MAXLEN` subcommand. * `XDEL` generates a single `xdel` event even when multiple entries are deleted. * `XGROUP CREATE` generates an `xgroup-create` event. +* `XGROUP CREATECONSUMER` generates an `xgroup-createconsumer` event. * `XGROUP DELCONSUMER` generates an `xgroup-delconsumer` event. * `XGROUP DESTROY` generates an `xgroup-destroy` event. * `XGROUP SETID` generates an `xgroup-setid` event. From 7ad24ee79785b26e2dfe39ab2f1a5ff9c03b0a38 Mon Sep 17 00:00:00 2001 From: Tyson Andre Date: Wed, 30 Sep 2020 01:59:56 -0400 Subject: [PATCH 0005/1006] Document proposed SMISMEMBER KEY MEMBER ... (#1364) Documentation PR for https://github.com/redis/redis/pull/7615 --- commands.json | 17 +++++++++++++++++ commands/smismember.md | 16 ++++++++++++++++ 2 files changed, 33 insertions(+) create mode 100644 commands/smismember.md diff --git a/commands.json b/commands.json index 4619dc1ad5..84f9b032f6 100644 --- a/commands.json +++ b/commands.json @@ -2961,6 +2961,23 @@ "since": "1.0.0", "group": "set" }, + "SMISMEMBER": { + "summary": "Returns the membership associated with the given elements for a set", + "complexity": "O(N) where N is the number of elements being checked for membership", + "arguments": [ + { + "name": "key", + "type": "key" + }, + { + "name": "member", + "type": "string", + "multiple": true + } + ], + "since": "6.2.0", + "group": "set" + }, "SLAVEOF": { "summary": "Make the server a replica of another instance, or promote it as master. Deprecated starting with Redis 5. Use REPLICAOF instead.", "arguments": [ diff --git a/commands/smismember.md b/commands/smismember.md new file mode 100644 index 0000000000..c4cec64a6b --- /dev/null +++ b/commands/smismember.md @@ -0,0 +1,16 @@ +Returns whether each `member` is a member of the set stored at `key`. + +For every `member`, `1` is returned if the value is a member of the set, or `0` if the element is not a member of the set or if `key` does not exist. + +@return + +@array-reply: list representing the membership of the given elements, in the same +order as they are requested. + +@examples + +```cli +SADD myset "one" +SADD myset "one" +SMISMEMBER myset "one" "notamember" +``` From e676d450cd16df6f142b876caead503c5781e589 Mon Sep 17 00:00:00 2001 From: alexronke-channeladvisor <41968397+alexronke-channeladvisor@users.noreply.github.com> Date: Wed, 30 Sep 2020 02:03:16 -0400 Subject: [PATCH 0006/1006] Documentation update for new ZADD GT and LT options (#1397) Co-authored-by: Itamar Haber Co-authored-by: Oran Agra --- commands.json | 9 +++++++++ commands/zadd.md | 8 +++++++- topics/modules-api-ref.md | 2 ++ 3 files changed, 18 insertions(+), 1 deletion(-) diff --git a/commands.json b/commands.json index 84f9b032f6..e4ebb0ae04 100644 --- a/commands.json +++ b/commands.json @@ -3399,6 +3399,15 @@ ], "optional": true }, + { + "name": "comparison", + "type": "enum", + "enum": [ + "GT", + "LT" + ], + "optional": true + }, { "name": "change", "type": "enum", diff --git a/commands/zadd.md b/commands/zadd.md index e112a19118..8656ce9c22 100644 --- a/commands/zadd.md +++ b/commands/zadd.md @@ -10,7 +10,7 @@ members is created, like if the sorted set was empty. If the key exists but does The score values should be the string representation of a double precision floating point number. `+inf` and `-inf` values are valid values as well. -ZADD options (Redis 3.0.2 or greater) +ZADD options --- ZADD supports a list of options, specified after the name of the key and before @@ -18,9 +18,13 @@ the first score argument. Options are: * **XX**: Only update elements that already exist. Never add elements. * **NX**: Don't update already existing elements. Always add new elements. +* **LT**: Only update existing elements if the new score is **less than** the current score. This flag doesn't prevent adding new elements. +* **GT**: Only update existing elements if the new score is **greater than** the current score. This flag doesn't prevent adding new elements. * **CH**: Modify the return value from the number of new elements added, to the total number of elements changed (CH is an abbreviation of *changed*). Changed elements are **new elements added** and elements already existing for which **the score was updated**. So elements specified in the command line having the same score as they had in the past are not counted. Note: normally the return value of `ZADD` only counts the number of new elements added. * **INCR**: When this option is specified `ZADD` acts like `ZINCRBY`. Only one score-element pair can be specified in this mode. +Note: The **GT**, **LT** and **NX** options are mutually exclusive. + Range of integer scores that can be expressed precisely --- @@ -70,6 +74,8 @@ If the `INCR` option is specified, the return value will be @bulk-string-reply: * `>= 2.4`: Accepts multiple elements. In Redis versions older than 2.4 it was possible to add or update a single member per call. +* `>= 3.0.2`: Added the `XX`, `NX`, `CH` and `INCR` options. +* `>=6.2`: Added the `GT` and `LT` options. @examples diff --git a/topics/modules-api-ref.md b/topics/modules-api-ref.md index 8089710067..9ed02e2472 100644 --- a/topics/modules-api-ref.md +++ b/topics/modules-api-ref.md @@ -1053,6 +1053,8 @@ The input flags are: REDISMODULE_ZADD_XX: Element must already exist. Do nothing otherwise. REDISMODULE_ZADD_NX: Element must not exist. Do nothing otherwise. + REDISMODULE_ZADD_LT: For existing element, only update if the new score is less than the current score. + REDISMODULE_ZADD_GT: For existing element, only update if the new score is greater than the current score. The output flags are: From 7ac6599a8d30919116c0838d6324da66e5671b19 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E6=9D=A8=E5=8D=9A=E4=B8=9C?= Date: Wed, 30 Sep 2020 14:05:02 +0800 Subject: [PATCH 0007/1006] Add `ZINTER/ZUNION` command (#1396) Co-authored-by: Itamar Haber Co-authored-by: Oran Agra --- commands.json | 86 ++++++++++++++++++++++++++++++++++++++++++++++ commands/zinter.md | 21 +++++++++++ commands/zunion.md | 21 +++++++++++ 3 files changed, 128 insertions(+) create mode 100644 commands/zinter.md create mode 100644 commands/zunion.md diff --git a/commands.json b/commands.json index e4ebb0ae04..f4c5f3379b 100644 --- a/commands.json +++ b/commands.json @@ -3491,6 +3491,49 @@ "since": "1.2.0", "group": "sorted_set" }, + "ZINTER": { + "summary": "Intersect multiple sorted sets", + "complexity": "O(N*K)+O(M*log(M)) worst case with N being the smallest input sorted set, K being the number of input sorted sets and M being the number of elements in the resulting sorted set.", + "arguments": [ + { + "name": "numkeys", + "type": "integer" + }, + { + "name": "key", + "type": "key", + "multiple": true + }, + { + "command": "WEIGHTS", + "name": "weight", + "type": "integer", + "variadic": true, + "optional": true + }, + { + "command": "AGGREGATE", + "name": "aggregate", + "type": "enum", + "enum": [ + "SUM", + "MIN", + "MAX" + ], + "optional": true + }, + { + "name": "withscores", + "type": "enum", + "enum": [ + "WITHSCORES" + ], + "optional": true + } + ], + "since": "6.2.0", + "group": "sorted_set" + }, "ZINTERSTORE": { "summary": "Intersect multiple sorted sets and store the resulting sorted set in a new key", "complexity": "O(N*K)+O(M*log(M)) worst case with N being the smallest input sorted set, K being the number of input sorted sets and M being the number of elements in the resulting sorted set.", @@ -3909,6 +3952,49 @@ "since": "1.2.0", "group": "sorted_set" }, + "ZUNION": { + "summary": "Add multiple sorted sets", + "complexity": "O(N)+O(M*log(M)) with N being the sum of the sizes of the input sorted sets, and M being the number of elements in the resulting sorted set.", + "arguments": [ + { + "name": "numkeys", + "type": "integer" + }, + { + "name": "key", + "type": "key", + "multiple": true + }, + { + "command": "WEIGHTS", + "name": "weight", + "type": "integer", + "variadic": true, + "optional": true + }, + { + "command": "AGGREGATE", + "name": "aggregate", + "type": "enum", + "enum": [ + "SUM", + "MIN", + "MAX" + ], + "optional": true + }, + { + "name": "withscores", + "type": "enum", + "enum": [ + "WITHSCORES" + ], + "optional": true + } + ], + "since": "6.2.0", + "group": "sorted_set" + }, "ZMSCORE": { "summary": "Get the score associated with the given members in a sorted set", "complexity": "O(N) where N is the number of members being requested.", diff --git a/commands/zinter.md b/commands/zinter.md new file mode 100644 index 0000000000..5a7adccd79 --- /dev/null +++ b/commands/zinter.md @@ -0,0 +1,21 @@ +This command is similar to `ZINTERSTORE`, but instead of storing the resulting +sorted set, it is returned to the client. + +For a description of the `WEIGHTS` and `AGGREGATE` options, see `ZUNIONSTORE`. + +@return + +@array-reply: the result of intersection (optionally with their scores, in case +the `WITHSCORES` option is given). + +@examples + +```cli +ZADD zset1 1 "one" +ZADD zset1 2 "two" +ZADD zset2 1 "one" +ZADD zset2 2 "two" +ZADD zset2 3 "three" +ZINTER 2 zset1 zset2 +ZINTER 2 zset1 zset2 WITHSCORES +``` diff --git a/commands/zunion.md b/commands/zunion.md new file mode 100644 index 0000000000..d77d81f47c --- /dev/null +++ b/commands/zunion.md @@ -0,0 +1,21 @@ +This command is similar to `ZUNIONSTORE`, but instead of storing the resulting +sorted set, it is returned to the client. + +For a description of the `WEIGHTS` and `AGGREGATE` options, see `ZUNIONSTORE`. + +@return + +@array-reply: the result of union (optionally with their scores, in case +the `WITHSCORES` option is given). + +@examples + +```cli +ZADD zset1 1 "one" +ZADD zset1 2 "two" +ZADD zset2 1 "one" +ZADD zset2 2 "two" +ZADD zset2 3 "three" +ZUNION 2 zset1 zset2 +ZUNION 2 zset1 zset2 WITHSCORES +``` From 950401c7e66cc2079121760395f1607e99f2b9a4 Mon Sep 17 00:00:00 2001 From: Gavrie Philipson Date: Thu, 1 Oct 2020 01:51:31 +0300 Subject: [PATCH 0008/1006] Fix some typos, punctuation and style errors (#1406) --- topics/cluster-tutorial.md | 42 +++++++++++++++++++------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/topics/cluster-tutorial.md b/topics/cluster-tutorial.md index a48973259b..d004f60cde 100644 --- a/topics/cluster-tutorial.md +++ b/topics/cluster-tutorial.md @@ -83,7 +83,7 @@ Redis Cluster data sharding --- Redis Cluster does not use consistent hashing, but a different form of sharding -where every key is conceptually part of what we call an **hash slot**. +where every key is conceptually part of what we call a **hash slot**. There are 16384 hash slots in Redis Cluster, and to compute what is the hash slot of a given key, we simply take the CRC16 of the key modulo @@ -131,13 +131,13 @@ range 5501-11000. However when the cluster is created (or at a later time) we add a slave node to every master, so that the final cluster is composed of A, B, C -that are masters nodes, and A1, B1, C1 that are slaves nodes, the system is -able to continue if node B fails. +that are master nodes, and A1, B1, C1 that are slave nodes. +This way, the system is able to continue if node B fails. Node B1 replicates B, and B fails, the cluster will promote node B1 as the new master and will continue to operate correctly. -However note that if nodes B and B1 fail at the same time Redis Cluster is not +However, note that if nodes B and B1 fail at the same time, Redis Cluster is not able to continue to operate. Redis Cluster consistency guarantees @@ -166,19 +166,19 @@ This is **very similar to what happens** with most databases that are configured to flush data to disk every second, so it is a scenario you are already able to reason about because of past experiences with traditional database systems not involving distributed systems. Similarly you can -improve consistency by forcing the database to flush data on disk before -replying to the client, but this usually results into prohibitively low +improve consistency by forcing the database to flush data to disk before +replying to the client, but this usually results in prohibitively low performance. That would be the equivalent of synchronous replication in the case of Redis Cluster. -Basically there is a trade-off to take between performance and consistency. +Basically, there is a trade-off to be made between performance and consistency. Redis Cluster has support for synchronous writes when absolutely needed, -implemented via the `WAIT` command, this makes losing writes a lot less -likely, however note that Redis Cluster does not implement strong consistency -even when synchronous replication is used: it is always possible under more -complex failure scenarios that a slave that was not able to receive the write -is elected as master. +implemented via the `WAIT` command. This makes losing writes a lot less +likely. However, note that Redis Cluster does not implement strong consistency +even when synchronous replication is used: it is always possible, under more +complex failure scenarios, that a slave that was not able to receive the write +will be elected as master. There is another notable scenario where Redis Cluster will lose writes, that happens during a network partition where a client is isolated with a minority @@ -190,23 +190,23 @@ with 3 masters and 3 slaves. There is also a client, that we will call Z1. After a partition occurs, it is possible that in one side of the partition we have A, C, A1, B1, C1, and in the other side we have B and Z1. -Z1 is still able to write to B, that will accept its writes. If the +Z1 is still able to write to B, which will accept its writes. If the partition heals in a very short time, the cluster will continue normally. -However if the partition lasts enough time for B1 to be promoted to master -in the majority side of the partition, the writes that Z1 is sending to B -will be lost. +However, if the partition lasts enough time for B1 to be promoted to master +on the majority side of the partition, the writes that Z1 has sent to B +in the mean time will be lost. Note that there is a **maximum window** to the amount of writes Z1 will be able to send to B: if enough time has elapsed for the majority side of the partition to elect a slave as master, every master node in the minority -side stops accepting writes. +side will have stopped accepting writes. This amount of time is a very important configuration directive of Redis Cluster, and is called the **node timeout**. After node timeout has elapsed, a master node is considered to be failing, and can be replaced by one of its replicas. -Similarly after node timeout has elapsed without a master node to be able +Similarly, after node timeout has elapsed without a master node to be able to sense the majority of the other master nodes, it enters an error state and stops accepting writes. @@ -221,10 +221,10 @@ as you continue reading. * **cluster-enabled ``**: If yes, enables Redis Cluster support in a specific Redis instance. Otherwise the instance starts as a stand alone instance as usual. * **cluster-config-file ``**: Note that despite the name of this option, this is not a user editable configuration file, but the file where a Redis Cluster node automatically persists the cluster configuration (the state, basically) every time there is a change, in order to be able to re-read it at startup. The file lists things like the other nodes in the cluster, their state, persistent variables, and so forth. Often this file is rewritten and flushed on disk as a result of some message reception. * **cluster-node-timeout ``**: The maximum amount of time a Redis Cluster node can be unavailable, without it being considered as failing. If a master node is not reachable for more than the specified amount of time, it will be failed over by its slaves. This parameter controls other important things in Redis Cluster. Notably, every node that can't reach the majority of master nodes for the specified amount of time, will stop accepting queries. -* **cluster-slave-validity-factor ``**: If set to zero, a slave will always try to failover a master, regardless of the amount of time the link between the master and the slave remained disconnected. If the value is positive, a maximum disconnection time is calculated as the *node timeout* value multiplied by the factor provided with this option, and if the node is a slave, it will not try to start a failover if the master link was disconnected for more than the specified amount of time. For example if the node timeout is set to 5 seconds, and the validity factor is set to 10, a slave disconnected from the master for more than 50 seconds will not try to failover its master. Note that any value different than zero may result in Redis Cluster to be unavailable after a master failure if there is no slave able to failover it. In that case the cluster will return back available only when the original master rejoins the cluster. +* **cluster-slave-validity-factor ``**: If set to zero, a slave will always consider itself valid, and will therefore always try to failover a master, regardless of the amount of time the link between the master and the slave remained disconnected. If the value is positive, a maximum disconnection time is calculated as the *node timeout* value multiplied by the factor provided with this option, and if the node is a slave, it will not try to start a failover if the master link was disconnected for more than the specified amount of time. For example, if the node timeout is set to 5 seconds and the validity factor is set to 10, a slave disconnected from the master for more than 50 seconds will not try to failover its master. Note that any value different than zero may result in Redis Cluster being unavailable after a master failure if there is no slave that is able to failover it. In that case the cluster will return to being available only when the original master rejoins the cluster. * **cluster-migration-barrier ``**: Minimum number of slaves a master will remain connected with, for another slave to migrate to a master which is no longer covered by any slave. See the appropriate section about replica migration in this tutorial for more information. * **cluster-require-full-coverage ``**: If this is set to yes, as it is by default, the cluster stops accepting writes if some percentage of the key space is not covered by any node. If the option is set to no, the cluster will still serve queries even if only requests about a subset of keys can be processed. -* **cluster-allow-reads-when-down ``**: If this is set to no, as it is by default, a node in a Redis Cluster will stop serving all traffic when the cluster is marked as fail, either when a node can't reach a quorum of masters or full coverage is not met. This prevents reading potentially inconsistent data from a node that is unaware of changes in the cluster. This option can be set to yes to allow reads from a node during the fail state, which is useful for applications that want to prioritize read availability but still want to prevent inconsistent writes. It can also be used for when using Redis Cluster with only one or two shards, as it allows the nodes to continue serving writes when a master fails but automatic failover is impossible. +* **cluster-allow-reads-when-down ``**: If this is set to no, as it is by default, a node in a Redis Cluster will stop serving all traffic when the cluster is marked as failed, either when a node can't reach a quorum of masters or when full coverage is not met. This prevents reading potentially inconsistent data from a node that is unaware of changes in the cluster. This option can be set to yes to allow reads from a node during the fail state, which is useful for applications that want to prioritize read availability but still want to prevent inconsistent writes. It can also be used for when using Redis Cluster with only one or two shards, as it allows the nodes to continue serving writes when a master fails but automatic failover is impossible. Creating and using a Redis Cluster @@ -302,7 +302,7 @@ Creating the cluster Now that we have a number of instances running, we need to create our cluster by writing some meaningful configuration to the nodes. -If you are using Redis 5, this is very easy to accomplish as we are helped by the Redis Cluster command line utility embedded into `redis-cli`, that can be used to create new clusters, check or reshard an existing cluster, and so forth. +If you are using Redis 5 or higher, this is very easy to accomplish as we are helped by the Redis Cluster command line utility embedded into `redis-cli`, that can be used to create new clusters, check or reshard an existing cluster, and so forth. For Redis version 3 or 4, there is the older tool called `redis-trib.rb` which is very similar. You can find it in the `src` directory of the Redis source code distribution. You need to install `redis` gem to be able to run `redis-trib`. From 4a6aaa3a2a974f8c1dc36dc0c8b02711b6be58e4 Mon Sep 17 00:00:00 2001 From: Nykolas Laurentino de Lima Date: Fri, 2 Oct 2020 02:07:36 -0300 Subject: [PATCH 0009/1006] Add GET parameter to SET command (#1405) Add optional GET parameter to SET command in order to set a new value to a key and retrieve the old key value. With this change we can deprecate `GETSET` command and use only the SET command with the GET parameter. Equivalent of adding an EX to GETSET. --- commands.json | 8 ++++++++ commands/getset.md | 2 ++ commands/set.md | 7 +++++-- 3 files changed, 15 insertions(+), 2 deletions(-) diff --git a/commands.json b/commands.json index f4c5f3379b..f6bb4016f3 100644 --- a/commands.json +++ b/commands.json @@ -2818,6 +2818,14 @@ "XX" ], "optional": true + }, + { + "name": "get", + "type": "enum", + "enum": [ + "GET" + ], + "optional": true } ], "since": "1.0.0", diff --git a/commands/getset.md b/commands/getset.md index ea68401543..b3674f6881 100644 --- a/commands/getset.md +++ b/commands/getset.md @@ -15,6 +15,8 @@ GETSET mycounter "0" GET mycounter ``` +As per Redis 6.2, GETSET is considered deprecated. Please use `SET` with `GET` parameter in new code. + @return @bulk-string-reply: the old value stored at `key`, or `nil` when `key` did not exist. diff --git a/commands/set.md b/commands/set.md index a4d2f411e1..7d9ec38476 100644 --- a/commands/set.md +++ b/commands/set.md @@ -11,18 +11,21 @@ The `SET` command supports a set of options that modify its behavior: * `NX` -- Only set the key if it does not already exist. * `XX` -- Only set the key if it already exist. * `KEEPTTL` -- Retain the time to live associated with the key. +* `GET` -- Return the old value stored at key, or nil when key did not exist. -Note: Since the `SET` command options can replace `SETNX`, `SETEX`, `PSETEX`, it is possible that in future versions of Redis these three commands will be deprecated and finally removed. +Note: Since the `SET` command options can replace `SETNX`, `SETEX`, `PSETEX`, `GETSET`, it is possible that in future versions of Redis these three commands will be deprecated and finally removed. @return @simple-string-reply: `OK` if `SET` was executed correctly. -@nil-reply: a Null Bulk Reply is returned if the `SET` operation was not performed because the user specified the `NX` or `XX` option but the condition was not met. +@bulk-string-reply: when `GET` option is set, the old value stored at key, or nil when key did not exist. +@nil-reply: a Null Bulk Reply is returned if the `SET` operation was not performed because the user specified the `NX` or `XX` option but the condition was not met or if user specified the `NX` and `GET` options that do not met. @history * `>= 2.6.12`: Added the `EX`, `PX`, `NX` and `XX` options. * `>= 6.0`: Added the `KEEPTTL` option. +* `>= 6.2`: Added the `GET` option. @examples From be74d8adbbe34f0575587b596f7982c7e2d9d09d Mon Sep 17 00:00:00 2001 From: 1Jack2 <37974403+1Jack2@users.noreply.github.com> Date: Mon, 5 Oct 2020 23:24:36 +0800 Subject: [PATCH 0010/1006] change 'configEpoch' to 'currentEpoch'. (#1410) --- topics/cluster-spec.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/topics/cluster-spec.md b/topics/cluster-spec.md index b8eb801420..2a81b52f24 100644 --- a/topics/cluster-spec.md +++ b/topics/cluster-spec.md @@ -777,7 +777,7 @@ At node creation every Redis Cluster node, both slaves and master nodes, set the Every time a packet is received from another node, if the epoch of the sender (part of the cluster bus messages header) is greater than the local node epoch, the `currentEpoch` is updated to the sender epoch. -Because of these semantics, eventually all the nodes will agree to the greatest `configEpoch` in the cluster. +Because of these semantics, eventually all the nodes will agree to the greatest `currentEpoch` in the cluster. This information is used when the state of the cluster is changed and a node seeks agreement in order to perform some action. From ea5eaeb6503ee5d085c617961b41f00d34aea693 Mon Sep 17 00:00:00 2001 From: Oran Agra Date: Tue, 6 Oct 2020 12:27:49 +0300 Subject: [PATCH 0011/1006] update client list fields: tracking flags and argv-mem / tot-mem (#1409) --- commands/client-list.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/commands/client-list.md b/commands/client-list.md index 3843689be1..1ed45be669 100644 --- a/commands/client-list.md +++ b/commands/client-list.md @@ -31,6 +31,8 @@ Here is the meaning of the fields: * `omem`: output buffer memory usage * `events`: file descriptor events (see below) * `cmd`: last command played +* `argv-mem`: incomplete arguments for the next command (already extracted from query buffer) +* `tot-mem`: total memory consumed by this client in its various buffers The client flags can be a combination of: @@ -49,6 +51,8 @@ S: the client is a replica node connection to this instance u: the client is unblocked U: the client is connected via a Unix domain socket x: the client is in a MULTI/EXEC context +t: the client enabled keys tracking in order to perform client side caching +R: the client tracking target client is invalid ``` The file descriptor events can be: From 1963925f7cae5741d2b64b3a3296e0671c874e57 Mon Sep 17 00:00:00 2001 From: Felipe Machado <462154+felipou@users.noreply.github.com> Date: Thu, 8 Oct 2020 03:04:19 -0300 Subject: [PATCH 0012/1006] Add new LMOVE and BLMOVE commands deprecating [B]RPOPLPUSH (#1347) --- commands.json | 68 ++++++++++++++++++++++++++++++++ commands/blmove.md | 24 +++++++++++ commands/brpoplpush.md | 3 ++ commands/info.md | 2 +- commands/lmove.md | 81 ++++++++++++++++++++++++++++++++++++++ commands/rpoplpush.md | 3 ++ topics/data-types-intro.md | 4 +- topics/notifications.md | 1 + 8 files changed, 183 insertions(+), 3 deletions(-) create mode 100644 commands/blmove.md create mode 100644 commands/lmove.md diff --git a/commands.json b/commands.json index f6bb4016f3..1748905bbf 100644 --- a/commands.json +++ b/commands.json @@ -355,6 +355,42 @@ "since": "2.2.0", "group": "list" }, + "BLMOVE": { + "summary": "Pop an element from a list, push it to another list and return it; or block until one is available", + "complexity": "O(1)", + "arguments": [ + { + "name": "source", + "type": "key" + }, + { + "name": "destination", + "type": "key" + }, + { + "name": "wherefrom", + "type": "enum", + "enum": [ + "LEFT", + "RIGHT" + ] + }, + { + "name": "whereto", + "type": "enum", + "enum": [ + "LEFT", + "RIGHT" + ] + }, + { + "name": "timeout", + "type": "integer" + } + ], + "since": "6.2.0", + "group": "list" + }, "BZPOPMIN": { "summary": "Remove and return the member with the lowest score from one or more sorted sets, or block until one is available", "complexity": "O(log(N)) with N being the number of elements in the sorted set.", @@ -2625,6 +2661,38 @@ "since": "1.2.0", "group": "list" }, + "LMOVE": { + "summary": "Pop an element from a list, push it to another list and return it", + "complexity": "O(1)", + "arguments": [ + { + "name": "source", + "type": "key" + }, + { + "name": "destination", + "type": "key" + }, + { + "name": "wherefrom", + "type": "enum", + "enum": [ + "LEFT", + "RIGHT" + ] + }, + { + "name": "whereto", + "type": "enum", + "enum": [ + "LEFT", + "RIGHT" + ] + } + ], + "since": "6.2.0", + "group": "list" + }, "RPUSH": { "summary": "Append one or multiple elements to a list", "complexity": "O(1) for each element added, so O(N) to add N elements when the command is called with multiple arguments.", diff --git a/commands/blmove.md b/commands/blmove.md new file mode 100644 index 0000000000..e1d5be924b --- /dev/null +++ b/commands/blmove.md @@ -0,0 +1,24 @@ +`BLMOVE` is the blocking variant of `LMOVE`. +When `source` contains elements, this command behaves exactly like `LMOVE`. +When used inside a `MULTI`/`EXEC` block, this command behaves exactly like `LMOVE`. +When `source` is empty, Redis will block the connection until another client +pushes to it or until `timeout` is reached. +A `timeout` of zero can be used to block indefinitely. + +This command comes in place of the now deprecated `BRPOPLPUSH`. Doing +`BLMOVE RIGHT LEFT` is equivalent. + +See `LMOVE` for more information. + +@return + +@bulk-string-reply: the element being popped from `source` and pushed to `destination`. +If `timeout` is reached, a @nil-reply is returned. + +## Pattern: Reliable queue + +Please see the pattern description in the `LMOVE` documentation. + +## Pattern: Circular list + +Please see the pattern description in the `LMOVE` documentation. diff --git a/commands/brpoplpush.md b/commands/brpoplpush.md index 9a6fe376d9..7f260d8f6c 100644 --- a/commands/brpoplpush.md +++ b/commands/brpoplpush.md @@ -5,6 +5,9 @@ When `source` is empty, Redis will block the connection until another client pushes to it or until `timeout` is reached. A `timeout` of zero can be used to block indefinitely. +As per Redis 6.2.0, BRPOPLPUSH is considered deprecated. Please use `BLMOVE` in +new code. + See `RPOPLPUSH` for more information. @return diff --git a/commands/info.md b/commands/info.md index 18202face6..7d18df11cd 100644 --- a/commands/info.md +++ b/commands/info.md @@ -78,7 +78,7 @@ Here is the meaning of all fields in the **clients** section: * `client_biggest_input_buf`: Biggest input buffer among current client connections * `blocked_clients`: Number of clients pending on a blocking call (`BLPOP`, - `BRPOP`, `BRPOPLPUSH`, `BZPOPMIN`, `BZPOPMAX`) + `BRPOP`, `BRPOPLPUSH`, `BLMOVE`, `BZPOPMIN`, `BZPOPMAX`) * `tracking_clients`: Number of clients being tracked (`CLIENT TRACKING`) * `clients_in_timeout_table`: Number of clients in the clients timeout table * `io_threads_active`: Flag indicating if I/O threads are active diff --git a/commands/lmove.md b/commands/lmove.md new file mode 100644 index 0000000000..ec62ced7ab --- /dev/null +++ b/commands/lmove.md @@ -0,0 +1,81 @@ +Atomically returns and removes the first/last element (head/tail depending on +the `wherefrom` argument) of the list stored at `source`, and pushes the +element at the first/last element (head/tail depending on the `whereto` +argument) of the list stored at `destination`. + +For example: consider `source` holding the list `a,b,c`, and `destination` +holding the list `x,y,z`. +Executing `LMOVE source destination RIGHT LEFT` results in `source` holding +`a,b` and `destination` holding `c,x,y,z`. + +If `source` does not exist, the value `nil` is returned and no operation is +performed. +If `source` and `destination` are the same, the operation is equivalent to +removing the first/last element from the list and pushing it as first/last +element of the list, so it can be considered as a list rotation command (or a +no-op if `wherefrom` is the same as `whereto`). + +This command comes in place of the now deprecated `RPOPLPUSH`. Doing +`LMOVE RIGHT LEFT` is equivalent. + +@return + +@bulk-string-reply: the element being popped and pushed. + +@examples + +```cli +RPUSH mylist "one" +RPUSH mylist "two" +RPUSH mylist "three" +LMOVE mylist myotherlist RIGHT LEFT +LMOVE mylist myotherlist LEFT RIGHT +LRANGE mylist 0 -1 +LRANGE myotherlist 0 -1 +``` + +## Pattern: Reliable queue + +Redis is often used as a messaging server to implement processing of background +jobs or other kinds of messaging tasks. +A simple form of queue is often obtained pushing values into a list in the +producer side, and waiting for this values in the consumer side using `RPOP` +(using polling), or `BRPOP` if the client is better served by a blocking +operation. + +However in this context the obtained queue is not _reliable_ as messages can +be lost, for example in the case there is a network problem or if the consumer +crashes just after the message is received but it is still to process. + +`LMOVE` (or `BLMOVE` for the blocking variant) offers a way to avoid +this problem: the consumer fetches the message and at the same time pushes it +into a _processing_ list. +It will use the `LREM` command in order to remove the message from the +_processing_ list once the message has been processed. + +An additional client may monitor the _processing_ list for items that remain +there for too much time, and will push those timed out items into the queue +again if needed. + +## Pattern: Circular list + +Using `LMOVE` with the same source and destination key, a client can visit +all the elements of an N-elements list, one after the other, in O(N) without +transferring the full list from the server to the client using a single `LRANGE` +operation. + +The above pattern works even if the following two conditions: + +* There are multiple clients rotating the list: they'll fetch different + elements, until all the elements of the list are visited, and the process + restarts. +* Even if other clients are actively pushing new items at the end of the list. + +The above makes it very simple to implement a system where a set of items must +be processed by N workers continuously as fast as possible. +An example is a monitoring system that must check that a set of web sites are +reachable, with the smallest delay possible, using a number of parallel workers. + +Note that this implementation of workers is trivially scalable and reliable, +because even if a message is lost the item is still in the queue and will be +processed at the next iteration. diff --git a/commands/rpoplpush.md b/commands/rpoplpush.md index 49aa8fa798..121c05090f 100644 --- a/commands/rpoplpush.md +++ b/commands/rpoplpush.md @@ -13,6 +13,9 @@ If `source` and `destination` are the same, the operation is equivalent to removing the last element from the list and pushing it as first element of the list, so it can be considered as a list rotation command. +As per Redis 6.2.0, RPOPLPUSH is considered deprecated. Please use `LMOVE` in +new code. + @return @bulk-string-reply: the element being popped and pushed. diff --git a/topics/data-types-intro.md b/topics/data-types-intro.md index 13b55cb591..e1b6515fb3 100644 --- a/topics/data-types-intro.md +++ b/topics/data-types-intro.md @@ -445,8 +445,8 @@ A few things to note about `BRPOP`: There are more things you should know about lists and blocking ops. We suggest that you read more on the following: -* It is possible to build safer queues or rotating queues using `RPOPLPUSH`. -* There is also a blocking variant of the command, called `BRPOPLPUSH`. +* It is possible to build safer queues or rotating queues using `LMOVE`. +* There is also a blocking variant of the command, called `BLMOVE`. Automatic creation and removal of keys --- diff --git a/topics/notifications.md b/topics/notifications.md index 786e348a34..bf2c0f3b26 100644 --- a/topics/notifications.md +++ b/topics/notifications.md @@ -118,6 +118,7 @@ Different commands generate different kind of events according to the following * `LREM` generates an `lrem` event, and additionally a `del` event if the resulting list is empty and the key is removed. * `LTRIM` generates an `ltrim` event, and additionally a `del` event if the resulting list is empty and the key is removed. * `RPOPLPUSH` and `BRPOPLPUSH` generate an `rpop` event and an `lpush` event. In both cases the order is guaranteed (the `lpush` event will always be delivered after the `rpop` event). Additionally a `del` event will be generated if the resulting list is zero length and the key is removed. +* `LMOVE` and `BLMOVE` generate an `lpop`/`rpop` event (depending on the wherefrom argument) and an `lpush`/`rpush` event (depending on the whereto argument). In both cases the order is guaranteed (the `lpush`/`rpush` event will always be delivered after the `lpop`/`rpop` event). Additionally a `del` event will be generated if the resulting list is zero length and the key is removed. * `HSET`, `HSETNX` and `HMSET` all generate a single `hset` event. * `HINCRBY` generates an `hincrby` event. * `HINCRBYFLOAT` generates an `hincrbyfloat` event. From 4d64e538e115e0940e8e41719898540f32acd70f Mon Sep 17 00:00:00 2001 From: Lin Taylor Date: Fri, 9 Oct 2020 10:56:14 -0400 Subject: [PATCH 0013/1006] Fix minor typos and line lengths in mass-insert.md (#921) * Fix typo * A couple more minor typos * Wrap line lengths to 80 characters Co-authored-by: Itamar Haber --- topics/mass-insert.md | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/topics/mass-insert.md b/topics/mass-insert.md index ea81e09094..cfa8e305a7 100644 --- a/topics/mass-insert.md +++ b/topics/mass-insert.md @@ -122,7 +122,7 @@ first mass import session. errors: 0, replies: 1000 How the pipe mode works under the hood ---------------------------------------- +-------------------------------------- The magic needed inside the pipe mode of redis-cli is to be as fast as netcat and still be able to understand when the last reply was sent by the server @@ -132,9 +132,17 @@ This is obtained in the following way: + redis-cli --pipe tries to send data as fast as possible to the server. + At the same time it reads data when available, trying to parse it. -+ Once there is no more data to read from stdin, it sends a special **ECHO** command with a random 20 bytes string: we are sure this is the latest command sent, and we are sure we can match the reply checking if we receive the same 20 bytes as a bulk reply. -+ Once this special final command is sent, the code receiving replies starts to match replies with these 20 bytes. When the matching reply is reached it can exit with success. - -Using this trick we don't need to parse the protocol we send to the server in order to understand how many commands we are sending, but just the replies. - -However while parsing the replies we take a counter of all the replies parsed so that at the end we are able to tell the user the amount of commands transferred to the server by the mass insert session. ++ Once there is no more data to read from stdin, it sends a special **ECHO** +command with a random 20 byte string: we are sure this is the latest command +sent, and we are sure we can match the reply checking if we receive the same +20 bytes as a bulk reply. ++ Once this special final command is sent, the code receiving replies starts +to match replies with these 20 bytes. When the matching reply is reached it +can exit with success. + +Using this trick we don't need to parse the protocol we send to the server +in order to understand how many commands we are sending, but just the replies. + +However while parsing the replies we take a counter of all the replies parsed +so that at the end we are able to tell the user the amount of commands +transferred to the server by the mass insert session. From e0cdd4054825e4435cf0eb29f14b3b92f77d0d25 Mon Sep 17 00:00:00 2001 From: Stefan Merettig Date: Fri, 9 Oct 2020 17:18:04 +0200 Subject: [PATCH 0014/1006] Fix typo in streams-intro (#1064) * streams-intro: Grammar fixes Co-authored-by: Itamar Haber --- topics/streams-intro.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/topics/streams-intro.md b/topics/streams-intro.md index e0bdc03673..fb6bae323a 100644 --- a/topics/streams-intro.md +++ b/topics/streams-intro.md @@ -596,7 +596,7 @@ Many applications do not want to collect data into a stream forever. Sometimes i Using **MAXLEN** the old entries are automatically evicted when the specified length is reached, so that the stream is taken at a constant size. There is currently no option to tell the stream to just retain items that are not older than a given amount, because such command, in order to run consistently, would have to potentially block for a lot of time in order to evict items. Imagine for example what happens if there is an insertion spike, then a long pause, and another insertion, all with the same maximum time. The stream would block to evict the data that became too old during the pause. So it is up to the user to do some planning and understand what is the maximum stream length desired. Moreover, while the length of the stream is proportional to the memory used, trimming by time is less simple to control and anticipate: it depends on the insertion rate that is a variable often changing over time (and when it does not change, then to just trim by size is trivial). -However trimming with **MAXLEN** can be expensive: streams are represented by macro nodes into a radix tree, in order to be very memory efficient. Altering the single macro node, consisting of a few tens of elements, is not optimal. So it is possible to give the command in the following special form: +However trimming with **MAXLEN** can be expensive: streams are represented by macro nodes into a radix tree, in order to be very memory efficient. Altering the single macro node, consisting of a few tens of elements, is not optimal. So it's possible to use the command in the following special form: ``` XADD mystream MAXLEN ~ 1000 * ... entry fields here ... @@ -604,7 +604,7 @@ XADD mystream MAXLEN ~ 1000 * ... entry fields here ... The `~` argument between the **MAXLEN** option and the actual count means, I don't really need this to be exactly 1000 items. It can be 1000 or 1010 or 1030, just make sure to save at least 1000 items. With this argument, the trimming is performed only when we can remove a whole node. This makes it much more efficient, and it is usually what you want. -There is also the **XTRIM** command available, which performs something very similar to what the **MAXLEN** option does above, but this command does not need to add anything, it can be run against any stream in a standalone way. +There is also the **XTRIM** command, which performs something very similar to what the **MAXLEN** option does above, except that it can be run by itself: ``` > XTRIM mystream MAXLEN 10 @@ -616,15 +616,15 @@ Or, as for the **XADD** option: > XTRIM mystream MAXLEN ~ 10 ``` -However, **XTRIM** is designed to accept different trimming strategies, even if currently only **MAXLEN** is implemented. Given that this is an explicit command, it is possible that in the future it will allow to specify trimming by time, because the user calling this command in a stand-alone way is supposed to know what she or he is doing. +However, **XTRIM** is designed to accept different trimming strategies, even if only **MAXLEN** is currently implemented. -One useful eviction strategy that **XTRIM** should have is probably the ability to remove by a range of IDs. This is currently not possible, but will be likely implemented in the future in order to more easily use **XRANGE** and **XTRIM** together to move data from Redis to other storage systems if needed. +As **XTRIM** is an explicit command, the user is expected to know about the possible shortcomings of different trimming strategies. As such, it's possible that trimming by time will be implemented at a later time. + +Another useful eviction strategy that **XTRIM** may learn later is to remove by a range of IDs to ease use of **XRANGE** and **XTRIM** to move data from Redis to other storage systems if needed. ## Special IDs in the streams API -You may have noticed that there are several special IDs that can be -used in the Redis streams API. Here is a short recap, so that they can make more -sense in the future. +You may have noticed that there are several special IDs that can be used in the Redis API. Here is a short recap, so that they can make more sense in the future. The first two special IDs are `-` and `+`, and are used in range queries with the `XRANGE` command. Those two IDs respectively mean the smallest ID possible (that is basically `0-1`) and the greatest ID possible (that is `18446744073709551615-18446744073709551615`). As you can see it is a lot cleaner to write `-` and `+` instead of those numbers. From 27b34645086e3fa3f00b134dcf2ed063044819a0 Mon Sep 17 00:00:00 2001 From: piglig <1197437384@qq.com> Date: Fri, 9 Oct 2020 23:20:35 +0800 Subject: [PATCH 0015/1006] Fix document spelling errors (#1413) Co-authored-by: root --- topics/rediscli.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/topics/rediscli.md b/topics/rediscli.md index 26b2535e64..6b6c7d0643 100644 --- a/topics/rediscli.md +++ b/topics/rediscli.md @@ -350,7 +350,7 @@ syntax hints. This behavior can be turned on and off via the CLI preferences. ## Preferences -TThere are two ways to customize the CLI's behavior. The file `.redisclirc` +There are two ways to customize the CLI's behavior. The file `.redisclirc` in your home directory is loaded by the CLI on startup. Preferences can also be set during a CLI session, in which case they will last only the the duration of the session. From e978cf5875a257ba4a3389abfa844a23df28c0f0 Mon Sep 17 00:00:00 2001 From: Itamar Haber Date: Sat, 10 Oct 2020 14:35:03 +0300 Subject: [PATCH 0016/1006] Uses double timeout value in blocking commands (#1411) --- commands.json | 12 ++++++------ commands/blpop.md | 6 +++++- commands/brpop.md | 4 ++++ commands/brpoplpush.md | 4 ++++ commands/bzpopmax.md | 6 +++++- commands/bzpopmin.md | 6 +++++- 6 files changed, 29 insertions(+), 9 deletions(-) diff --git a/commands.json b/commands.json index 1748905bbf..b65afe1a8b 100644 --- a/commands.json +++ b/commands.json @@ -312,7 +312,7 @@ }, { "name": "timeout", - "type": "integer" + "type": "double" } ], "since": "2.0.0", @@ -329,7 +329,7 @@ }, { "name": "timeout", - "type": "integer" + "type": "double" } ], "since": "2.0.0", @@ -349,7 +349,7 @@ }, { "name": "timeout", - "type": "integer" + "type": "double" } ], "since": "2.2.0", @@ -385,7 +385,7 @@ }, { "name": "timeout", - "type": "integer" + "type": "double" } ], "since": "6.2.0", @@ -402,7 +402,7 @@ }, { "name": "timeout", - "type": "integer" + "type": "double" } ], "since": "5.0.0", @@ -419,7 +419,7 @@ }, { "name": "timeout", - "type": "integer" + "type": "double" } ], "since": "5.0.0", diff --git a/commands/blpop.md b/commands/blpop.md index b0777f9e2f..3a0abf6f9c 100644 --- a/commands/blpop.md +++ b/commands/blpop.md @@ -36,7 +36,7 @@ the client will unblock returning a `nil` multi-bulk value when the specified timeout has expired without a push operation against at least one of the specified keys. -**The timeout argument is interpreted as an integer value specifying the maximum number of seconds to block**. A timeout of zero can be used to block indefinitely. +**The timeout argument is interpreted as a double value specifying the maximum number of seconds to block**. A timeout of zero can be used to block indefinitely. ## What key is served first? What client? What element? Priority ordering details. @@ -91,6 +91,10 @@ If you like science fiction, think of time flowing at infinite speed inside a where an element was popped and the second element being the value of the popped element. +@history + +* `>= 6.0`: `timeout` is interpreted as a double instead of an integer. + @examples ``` diff --git a/commands/brpop.md b/commands/brpop.md index dfa2b91cac..1e0f22a0a0 100644 --- a/commands/brpop.md +++ b/commands/brpop.md @@ -19,6 +19,10 @@ the tail of a list instead of popping from the head. where an element was popped and the second element being the value of the popped element. +@history + +* `>= 6.0`: `timeout` is interpreted as a double instead of an integer. + @examples ``` diff --git a/commands/brpoplpush.md b/commands/brpoplpush.md index 7f260d8f6c..3547ff49ee 100644 --- a/commands/brpoplpush.md +++ b/commands/brpoplpush.md @@ -15,6 +15,10 @@ See `RPOPLPUSH` for more information. @bulk-string-reply: the element being popped from `source` and pushed to `destination`. If `timeout` is reached, a @nil-reply is returned. +@history + +* `>= 6.0`: `timeout` is interpreted as a double instead of an integer. + ## Pattern: Reliable queue Please see the pattern description in the `RPOPLPUSH` documentation. diff --git a/commands/bzpopmax.md b/commands/bzpopmax.md index 1c99c247a4..d3a38cd07c 100644 --- a/commands/bzpopmax.md +++ b/commands/bzpopmax.md @@ -5,7 +5,7 @@ members to pop from any of the given sorted sets. A member with the highest score is popped from first sorted set that is non-empty, with the given keys being checked in the order that they are given. -The `timeout` argument is interpreted as an integer value specifying the maximum +The `timeout` argument is interpreted as a double value specifying the maximum number of seconds to block. A timeout of zero can be used to block indefinitely. See the [BZPOPMIN documentation][cb] for the exact semantics, since `BZPOPMAX` @@ -23,6 +23,10 @@ with the highest scores instead of popping the ones with the lowest scores. where a member was popped, the second element is the popped member itself, and the third element is the score of the popped element. +@history + +* `>= 6.0`: `timeout` is interpreted as a double instead of an integer. + @examples ``` diff --git a/commands/bzpopmin.md b/commands/bzpopmin.md index 1b75aa4f4a..651e229301 100644 --- a/commands/bzpopmin.md +++ b/commands/bzpopmin.md @@ -5,7 +5,7 @@ members to pop from any of the given sorted sets. A member with the lowest score is popped from first sorted set that is non-empty, with the given keys being checked in the order that they are given. -The `timeout` argument is interpreted as an integer value specifying the maximum +The `timeout` argument is interpreted as an double value specifying the maximum number of seconds to block. A timeout of zero can be used to block indefinitely. See the [BLPOP documentation][cl] for the exact semantics, since `BZPOPMIN` is @@ -23,6 +23,10 @@ popped from. where a member was popped, the second element is the popped member itself, and the third element is the score of the popped element. +@history + +* `>= 6.0`: `timeout` is interpreted as a double instead of an integer. + @examples ``` From 8fa5ba577f3f9a90f55027c5a0d83bec8271ad27 Mon Sep 17 00:00:00 2001 From: Cristian Greco Date: Sat, 10 Oct 2020 12:37:35 +0100 Subject: [PATCH 0017/1006] Rewrite all links to redis.io with https scheme. (#1412) On some pages, Firefox shows a warning in the url bar when visiting the website over https, caused by images being loaded over http. For the sake of completeness, here I've moved all internal links to use https scheme. --- commands/set.md | 2 +- commands/setnx.md | 2 +- topics/clients.md | 4 ++-- topics/cluster-spec.md | 2 +- topics/data-types-intro.md | 2 +- topics/indexes.md | 6 +++--- topics/lru-cache.md | 2 +- topics/memory-optimization.md | 2 +- topics/partitioning.md | 2 +- topics/pipelining.md | 2 +- topics/quickstart.md | 10 +++++----- topics/twitter-clone.md | 2 +- 12 files changed, 19 insertions(+), 19 deletions(-) diff --git a/commands/set.md b/commands/set.md index 7d9ec38476..4697f33652 100644 --- a/commands/set.md +++ b/commands/set.md @@ -38,7 +38,7 @@ SET anotherkey "will expire in a minute" EX 60 ## Patterns -**Note:** The following pattern is discouraged in favor of [the Redlock algorithm](http://redis.io/topics/distlock) which is only a bit more complex to implement, but offers better guarantees and is fault tolerant. +**Note:** The following pattern is discouraged in favor of [the Redlock algorithm](https://redis.io/topics/distlock) which is only a bit more complex to implement, but offers better guarantees and is fault tolerant. The command `SET resource-name anystring NX EX max-lock-time` is a simple way to implement a locking system with Redis. diff --git a/commands/setnx.md b/commands/setnx.md index 94d0b517b9..833573c45e 100644 --- a/commands/setnx.md +++ b/commands/setnx.md @@ -22,7 +22,7 @@ GET mykey **Please note that:** -1. The following pattern is discouraged in favor of [the Redlock algorithm](http://redis.io/topics/distlock) which is only a bit more complex to implement, but offers better guarantees and is fault tolerant. +1. The following pattern is discouraged in favor of [the Redlock algorithm](https://redis.io/topics/distlock) which is only a bit more complex to implement, but offers better guarantees and is fault tolerant. 2. We document the old pattern anyway because certain existing implementations link to this page as a reference. Moreover it is an interesting example of how Redis commands can be used in order to mount programming primitives. 3. Anyway even assuming a single-instance locking primitive, starting with 2.6.12 it is possible to create a much simpler locking primitive, equivalent to the one discussed here, using the `SET` command to acquire the lock, and a simple Lua script to release the lock. The pattern is documented in the `SET` command page. diff --git a/topics/clients.md b/topics/clients.md index f621d0f653..da8e6d75ff 100644 --- a/topics/clients.md +++ b/topics/clients.md @@ -153,11 +153,11 @@ In the above example session two clients are connected to the Redis server. The * **name**: The client name as set by `CLIENT SETNAME`. * **age**: The number of seconds the connection existed for. * **idle**: The number of seconds the connection is idle. -* **flags**: The kind of client (N means normal client, check the [full list of flags](http://redis.io/commands/client-list)). +* **flags**: The kind of client (N means normal client, check the [full list of flags](https://redis.io/commands/client-list)). * **omem**: The amount of memory used by the client for the output buffer. * **cmd**: The last executed command. -See the [CLIENT LIST](http://redis.io/commands/client-list) documentation for the full list of fields and their meaning. +See the [CLIENT LIST](https://redis.io/commands/client-list) documentation for the full list of fields and their meaning. Once you have the list of clients, you can easily close the connection with a client using the `CLIENT KILL` command specifying the client address as argument. diff --git a/topics/cluster-spec.md b/topics/cluster-spec.md index 2a81b52f24..aba8e73588 100644 --- a/topics/cluster-spec.md +++ b/topics/cluster-spec.md @@ -273,7 +273,7 @@ the node was pinged and the last time the pong was received, the current *configuration epoch* of the node (explained later in this specification), the link state and finally the set of hash slots served. -A detailed [explanation of all the node fields](http://redis.io/commands/cluster-nodes) is described in the `CLUSTER NODES` documentation. +A detailed [explanation of all the node fields](https://redis.io/commands/cluster-nodes) is described in the `CLUSTER NODES` documentation. The `CLUSTER NODES` command can be sent to any node in the cluster and provides the state of the cluster and the information for each node according to the local view the queried node has of the cluster. diff --git a/topics/data-types-intro.md b/topics/data-types-intro.md index e1b6515fb3..f7c00ef576 100644 --- a/topics/data-types-intro.md +++ b/topics/data-types-intro.md @@ -548,7 +548,7 @@ as well, like `HINCRBY`: > hincrby user:1000 birthyear 10 (integer) 1997 -You can find the [full list of hash commands in the documentation](http://redis.io/commands#hash). +You can find the [full list of hash commands in the documentation](https://redis.io/commands#hash). It is worth noting that small hashes (i.e., a few elements with small values) are encoded in special way in memory that make them very memory efficient. diff --git a/topics/indexes.md b/topics/indexes.md index f2ef46b332..1460022e61 100644 --- a/topics/indexes.md +++ b/topics/indexes.md @@ -547,7 +547,7 @@ our coordinates. Both variables max value is 400. The blue box in the picture represents our query. We want all the points where `x` is between 50 and 100, and where `y` is between 100 and 300. -![Points in the space](http://redis.io/images/redisdoc/2idx_0.png) +![Points in the space](https://redis.io/images/redisdoc/2idx_0.png) In order to represent data that makes these kinds of queries fast to perform, we start by padding our numbers with 0. So for example imagine we want to @@ -586,7 +586,7 @@ variable is between 70 and 79, and the `y` variable is between 200 and 209. We can write random points in this interval, in order to identify this specific area: -![Small area](http://redis.io/images/redisdoc/2idx_1.png) +![Small area](https://redis.io/images/redisdoc/2idx_1.png) So the above lexicographic query allows us to easily query for points in a specific square in the picture. However the square may be too small for @@ -601,7 +601,7 @@ This time the range represents all the points where `x` is between 0 and 99 and `y` is between 200 and 299. Drawing random points in this interval shows us this larger area: -![Large area](http://redis.io/images/redisdoc/2idx_2.png) +![Large area](https://redis.io/images/redisdoc/2idx_2.png) Oops now our area is ways too big for our query, and still our search box is not completely included. We need more granularity, but we can easily obtain diff --git a/topics/lru-cache.md b/topics/lru-cache.md index 20d4f355f2..91a7184f0e 100644 --- a/topics/lru-cache.md +++ b/topics/lru-cache.md @@ -105,7 +105,7 @@ costs more memory. However the approximation is virtually equivalent for the application using Redis. The following is a graphical comparison of how the LRU approximation used by Redis compares with true LRU. -![LRU comparison](http://redis.io/images/redisdoc/lru_comparison.png) +![LRU comparison](https://redis.io/images/redisdoc/lru_comparison.png) The test to generate the above graphs filled a Redis server with a given number of keys. The keys were accessed from the first to the last, so that the first keys are the best candidates for eviction using an LRU algorithm. Later more 50% of keys are added, in order to force half of the old keys to be evicted. diff --git a/topics/memory-optimization.md b/topics/memory-optimization.md index 35b3b8fefd..3b09a9e0fb 100644 --- a/topics/memory-optimization.md +++ b/topics/memory-optimization.md @@ -187,7 +187,7 @@ To store user keys, Redis allocates at most as much memory as the `maxmemory` setting enables (however there are small extra allocations possible). The exact value can be set in the configuration file or set later via -`CONFIG SET` (see [Using memory as an LRU cache for more info](http://redis.io/topics/lru-cache)). There are a few things that should be noted about how +`CONFIG SET` (see [Using memory as an LRU cache for more info](https://redis.io/topics/lru-cache)). There are a few things that should be noted about how Redis manages memory: * Redis will not always free up (return) memory to the OS when keys are removed. diff --git a/topics/partitioning.md b/topics/partitioning.md index 2989ae4727..bba6ac2535 100644 --- a/topics/partitioning.md +++ b/topics/partitioning.md @@ -116,4 +116,4 @@ Clients supporting consistent hashing An alternative to Twemproxy is to use a client that implements client side partitioning via consistent hashing or other similar algorithms. There are multiple Redis clients with support for consistent hashing, notably [Redis-rb](https://github.com/redis/redis-rb) and [Predis](https://github.com/nrk/predis). -Please check the [full list of Redis clients](http://redis.io/clients) to check if there is a mature client with consistent hashing implementation for your language. +Please check the [full list of Redis clients](https://redis.io/clients) to check if there is a mature client with consistent hashing implementation for your language. diff --git a/topics/pipelining.md b/topics/pipelining.md index 20c30a2a71..3554eaf4f8 100644 --- a/topics/pipelining.md +++ b/topics/pipelining.md @@ -129,7 +129,7 @@ Pipelining VS Scripting Using [Redis scripting](/commands/eval) (available in Redis version 2.6 or greater) a number of use cases for pipelining can be addressed more efficiently using scripts that perform a lot of the work needed at the server side. A big advantage of scripting is that it is able to both read and write data with minimal latency, making operations like *read, compute, write* very fast (pipelining can't help in this scenario since the client needs the reply of the read command before it can call the write command). -Sometimes the application may also want to send `EVAL` or `EVALSHA` commands in a pipeline. This is entirely possible and Redis explicitly supports it with the [SCRIPT LOAD](http://redis.io/commands/script-load) command (it guarantees that `EVALSHA` can be called without the risk of failing). +Sometimes the application may also want to send `EVAL` or `EVALSHA` commands in a pipeline. This is entirely possible and Redis explicitly supports it with the [SCRIPT LOAD](https://redis.io/commands/script-load) command (it guarantees that `EVALSHA` can be called without the risk of failing). Appendix: Why are busy loops slow even on the loopback interface? --- diff --git a/topics/quickstart.md b/topics/quickstart.md index 733023884a..b1addb4f2a 100644 --- a/topics/quickstart.md +++ b/topics/quickstart.md @@ -19,7 +19,7 @@ Redis has no dependencies other than a working GCC compiler and libc. Installing it using the package manager of your Linux distribution is somewhat discouraged as usually the available version is not the latest. -You can either download the latest Redis tar ball from the [redis.io](http://redis.io) web site, or you can alternatively use this special URL that always points to the latest stable Redis version, that is, [http://download.redis.io/redis-stable.tar.gz](http://download.redis.io/redis-stable.tar.gz). +You can either download the latest Redis tar ball from the [redis.io](https://redis.io) web site, or you can alternatively use this special URL that always points to the latest stable Redis version, that is, [http://download.redis.io/redis-stable.tar.gz](http://download.redis.io/redis-stable.tar.gz). In order to compile Redis follow these simple steps: @@ -83,7 +83,7 @@ Another interesting way to run redis-cli is without arguments: the program will redis 127.0.0.1:6379> get mykey "somevalue" -At this point you are able to talk with Redis. It is the right time to pause a bit with this tutorial and start the [fifteen minutes introduction to Redis data types](http://redis.io/topics/data-types-intro) in order to learn a few Redis commands. Otherwise if you already know a few basic Redis commands you can keep reading. +At this point you are able to talk with Redis. It is the right time to pause a bit with this tutorial and start the [fifteen minutes introduction to Redis data types](https://redis.io/topics/data-types-intro) in order to learn a few Redis commands. Otherwise if you already know a few basic Redis commands you can keep reading. Securing Redis === @@ -109,7 +109,7 @@ Using Redis from your application Of course using Redis just from the command line interface is not enough as the goal is to use it from your application. In order to do so you need to download and install a Redis client library for your programming language. -You'll find a [full list of clients for different languages in this page](http://redis.io/clients). +You'll find a [full list of clients for different languages in this page](https://redis.io/clients). For instance if you happen to use the Ruby programming language our best advice is to use the [Redis-rb](https://github.com/redis/redis-rb) client. @@ -135,12 +135,12 @@ commands calling methods. A short interactive example using Ruby: Redis persistence ================= -You can learn [how Redis persistence works on this page](http://redis.io/topics/persistence), however what is important to understand for a quick start is that by default, if you start Redis with the default configuration, Redis will spontaneously save the dataset only from time to time (for instance after at least five minutes if you have at least 100 changes in your data), so if you want your database to persist and be reloaded after a restart make sure to call the **SAVE** command manually every time you want to force a data set snapshot. Otherwise make sure to shutdown the database using the **SHUTDOWN** command: +You can learn [how Redis persistence works on this page](https://redis.io/topics/persistence), however what is important to understand for a quick start is that by default, if you start Redis with the default configuration, Redis will spontaneously save the dataset only from time to time (for instance after at least five minutes if you have at least 100 changes in your data), so if you want your database to persist and be reloaded after a restart make sure to call the **SAVE** command manually every time you want to force a data set snapshot. Otherwise make sure to shutdown the database using the **SHUTDOWN** command: $ redis-cli shutdown This way Redis will make sure to save the data on disk before quitting. -Reading the [persistence page](http://redis.io/topics/persistence) is strongly suggested in order to better understand how Redis persistence works. +Reading the [persistence page](https://redis.io/topics/persistence) is strongly suggested in order to better understand how Redis persistence works. Installing Redis more properly ============================== diff --git a/topics/twitter-clone.md b/topics/twitter-clone.md index d52a079191..2603eee868 100644 --- a/topics/twitter-clone.md +++ b/topics/twitter-clone.md @@ -143,7 +143,7 @@ also to retrieve its score if it exists, we use the `ZSCORE` command: Sorted Sets are a very powerful data structure, you can query elements by score range, lexicographically, in reverse order, and so forth. -To know more [please check the Sorted Set sections in the official Redis commands documentation](http://redis.io/commands/#sorted_set). +To know more [please check the Sorted Set sections in the official Redis commands documentation](https://redis.io/commands/#sorted_set). The Hash data type --- From 99a0aa5242ce7fb1f4b2293a3ef8b142e46f8dcb Mon Sep 17 00:00:00 2001 From: Guy Korland Date: Sun, 11 Oct 2020 20:52:13 +0300 Subject: [PATCH 0018/1006] Add redex (#1415) * Add redex * Update modules.json --- modules.json | 41 +++++++++++++++-------------------------- 1 file changed, 15 insertions(+), 26 deletions(-) diff --git a/modules.json b/modules.json index c7e9915ea6..61d1d4b333 100644 --- a/modules.json +++ b/modules.json @@ -7,7 +7,7 @@ "authors": [ "antirez" ], - "stars": 332 + "stars": 457 }, { "name": "RedisGears", @@ -81,29 +81,7 @@ "dvirsky", "RedisLabs" ], - "stars": 2585 - }, - { - "name": "topk", - "license": "Redis Source Available License", - "repository": "https://github.com/RedisLabsModules/topk", - "description": "An almost deterministic top k elements counter", - "authors": [ - "itamarhaber", - "RedisLabs" - ], - "stars": 32 - }, - { - "name": "countminsketch", - "license": "Redis Source Available License", - "repository": "https://github.com/RedisLabsModules/countminsketch", - "description": "An apporximate frequency counter", - "authors": [ - "itamarhaber", - "RedisLabs" - ], - "stars": 39 + "stars": 2616 }, { "name": "RedisBloom", @@ -135,7 +113,7 @@ "danni-m", "RedisLabs" ], - "stars": 452 + "stars": 455 }, { "name": "RedisAI", @@ -339,7 +317,8 @@ ], "stars":0 }, - { "name":"Redis-ImageScout", + { + "name":"Redis-ImageScout", "license": "pHash Redis Source Available License", "repository": "https://github.com/starkdg/Redis-ImageScout.git", "description": "Redis module for Indexing of pHash Image fingerprints for Near-Duplicate Detection", @@ -347,5 +326,15 @@ "starkdg" ], "stars":2 + }, + { + "name":"redex", + "license": "AGPL-3.0", + "repository": "https://github.com/RedisLabsModules/redex.git", + "description": "Extension modules to Redis' native data types and commands", + "authors": [ + "itamarhaber" + ], + "stars":52 } ] From c387a8f0c330f2af8c96cf46919e2f1248316a37 Mon Sep 17 00:00:00 2001 From: Wen Hui Date: Sun, 25 Oct 2020 08:45:13 -0400 Subject: [PATCH 0019/1006] Updates to Sentinel doc (#1417) * Adds ACL authentication for Redis and Sentinel * Documents missing commands and minimal versions * Generic edits Co-authored-by: Oran Agra Co-authored-by: Itamar Haber --- topics/sentinel.md | 114 ++++++++++++++++++++++++++++++++++----------- 1 file changed, 87 insertions(+), 27 deletions(-) diff --git a/topics/sentinel.md b/topics/sentinel.md index 70458a7532..f82c1d097f 100644 --- a/topics/sentinel.md +++ b/topics/sentinel.md @@ -583,30 +583,50 @@ so forth. Sentinel commands --- -The following is a list of accepted commands, not covering commands used in -order to modify the Sentinel configuration, which are covered later. - +The `SENTINEL` command, as of Redis 2.8, is the main API for Sentinel. The following is the list of its subcommands (minimal version is noted for where applicable): + +* **SENTINEL CKQUORUM ``** Check if the current Sentinel configuration is able to reach the quorum needed to failover a master, and the majority needed to authorize the failover. This command should be used in monitoring systems to check if a Sentinel deployment is ok. +* **SENTINEL FLUSHCONFIG** Force Sentinel to rewrite its configuration on disk, including the current Sentinel state. Normally Sentinel rewrites the configuration every time something changes in its state (in the context of the subset of the state which is persisted on disk across restart). However sometimes it is possible that the configuration file is lost because of operation errors, disk failures, package upgrade scripts or configuration managers. In those cases a way to to force Sentinel to rewrite the configuration file is handy. This command works even if the previous configuration file is completely missing. +* **SENTINEL FAILOVER ``** Force a failover as if the master was not reachable, and without asking for agreement to other Sentinels (however a new version of the configuration will be published so that the other Sentinels will update their configurations). +* **SENTINEL GET-MASTER-ADDR-BY-NAME ``** Return the ip and port number of the master with that name. If a failover is in progress or terminated successfully for this master it returns the address and port of the promoted replica. +* **SENTINEL INFO-CACHE** (`>= 3.2`) Return cached `INFO` output from masters and replicas. +* **SENTINEL IS-MASTER-DOWN-BY-ADDR ** Check if the master specified by ip:port is down from current Sentinel's point of view. This command is mostly for internal use. +* **SENTINEL MASTER ``** Show the state and info of the specified master. +* **SENTINEL MASTERS** Show a list of monitored masters and their state. +* **SENTINEL MONITOR** Start Sentinel's monitoring. Refer to the [_Reconfiguring Sentinel at Runtime_ section](#reconfiguring-sentinel-at-runtime) for more information. +* **SENTINEL MYID** (`>= 6.2`) Return the ID of the Sentinel instance. +* **SENTINEL PENDING-SCRIPTS** This command returns information about pending scripts. +* **SENTINEL REMOVE** Stop Sentinel's monitoring. Refer to the [_Reconfiguring Sentinel at Runtime_ section](#reconfiguring-sentinel-at-runtime) for more information. +* **SENTINEL REPLICAS ``** (`>= 5.0`) Show a list of replicas for this master, and their state. +* **SENTINEL SENTINELS ``** Show a list of sentinel instances for this master, and their state. +* **SENTINEL SET** Set Sentinel's monitoring configuration. Refer to the [_Reconfiguring Sentinel at Runtime_ section](#reconfiguring-sentinel-at-runtime) for more information. +* **SENTINEL SIMULATE-FAILURE (crash-after-election|crash-after-promotion|help)** (`>= 3.2`) This command simulates different Sentinel crash scenarios. +* **SENTINEL RESET ``** This command will reset all the masters with matching name. The pattern argument is a glob-style pattern. The reset process clears any previous state in a master (including a failover in progress), and removes every replica and sentinel already discovered and associated with the master. + +For connection management and administration purposes, Sentinel supports the following subset of Redis' commands: + +* **ACL** (`>= 6.2`) This command manages the Sentinel Access Control List. For more information refer to the [ACL](/topics/acl) documentation page and the [_Sentinel Access Control List authentication_](#sentinel-access-control-list-authentication). +* **AUTH** (`>= 5.0.1`) Authenticate a client connection. For more information refer to the `AUTH` command and the [_Configuring Sentinel instances with authentication_ section](#configuring-sentinel-instances-with-authentication). +* **CLIENT** This command manages client connections. For more information refer to the its subcommands' pages. +* **COMMAND** (`>= 6.2`) This command returns information about commands. For more information refer to the `COMMAND` command and its various subcommands. +* **HELLO** (`>= 6.0`) Switch the connection's protocol. For more information refer to the `HELLO` command. +* **INFO** Return information and statistics about the Sentinel server. For more information see the `INFO` command. * **PING** This command simply returns PONG. -* **SENTINEL masters** Show a list of monitored masters and their state. -* **SENTINEL master ``** Show the state and info of the specified master. -* **SENTINEL replicas ``** Show a list of replicas for this master, and their state. -* **SENTINEL sentinels ``** Show a list of sentinel instances for this master, and their state. -* **SENTINEL get-master-addr-by-name ``** Return the ip and port number of the master with that name. If a failover is in progress or terminated successfully for this master it returns the address and port of the promoted replica. -* **SENTINEL reset ``** This command will reset all the masters with matching name. The pattern argument is a glob-style pattern. The reset process clears any previous state in a master (including a failover in progress), and removes every replica and sentinel already discovered and associated with the master. -* **SENTINEL failover ``** Force a failover as if the master was not reachable, and without asking for agreement to other Sentinels (however a new version of the configuration will be published so that the other Sentinels will update their configurations). -* **SENTINEL ckquorum ``** Check if the current Sentinel configuration is able to reach the quorum needed to failover a master, and the majority needed to authorize the failover. This command should be used in monitoring systems to check if a Sentinel deployment is ok. -* **SENTINEL flushconfig** Force Sentinel to rewrite its configuration on disk, including the current Sentinel state. Normally Sentinel rewrites the configuration every time something changes in its state (in the context of the subset of the state which is persisted on disk across restart). However sometimes it is possible that the configuration file is lost because of operation errors, disk failures, package upgrade scripts or configuration managers. In those cases a way to to force Sentinel to rewrite the configuration file is handy. This command works even if the previous configuration file is completely missing. +* **ROLE** This command returns the string "sentinel" and a list of monitored masters. For more information refer to the `ROLE` command. +* **SHUTDOWN** Shut down the Sentinel instance. + +Lastly, Sentinel also supports the `SUBSCRIBE`, `UNSUBSCRIBE`, `PSUBSCRIBE` and `PUNSUBSCRIBE` commands. Refer to the [_Pub/Sub Messages_ section](#pubsub-messages) for more details. Reconfiguring Sentinel at Runtime --- Starting with Redis version 2.8.4, Sentinel provides an API in order to add, remove, or change the configuration of a given master. Note that if you have multiple sentinels you should apply the changes to all to your instances for Redis Sentinel to work properly. This means that changing the configuration of a single Sentinel does not automatically propagates the changes to the other Sentinels in the network. -The following is a list of `SENTINEL` sub commands used in order to update the configuration of a Sentinel instance. +The following is a list of `SENTINEL` subcommands used in order to update the configuration of a Sentinel instance. * **SENTINEL MONITOR `` `` `` ``** This command tells the Sentinel to start monitoring a new master with the specified name, ip, port, and quorum. It is identical to the `sentinel monitor` configuration directive in `sentinel.conf` configuration file, with the difference that you can't use an hostname in as `ip`, but you need to provide an IPv4 or IPv6 address. * **SENTINEL REMOVE ``** is used in order to remove the specified master: the master will no longer be monitored, and will totally be removed from the internal state of the Sentinel, so it will no longer listed by `SENTINEL masters` and so forth. -* **SENTINEL SET `` `