diff --git a/commands/auth.md b/commands/auth.md index bad8157a..833767f7 100644 --- a/commands/auth.md +++ b/commands/auth.md @@ -5,7 +5,7 @@ The standard way to `AUTH` is the two-argument form: AUTH This authenticates the current connection with one of the users -defined in the ACL list (see `ACL SETUSER` and the official [ACL guide](../topics/acl.md) for more information). +defined in the ACL list (see [`ACL SETUSER`](acl-setuser.md) and the official [ACL guide](../topics/acl.md) for more information). When the single argument form of the command is used, where only the password is specified, it is assumed that the implicit username is "default". @@ -22,4 +22,4 @@ Otherwise, an error is returned and the clients needs to try a new password. Because of the high performance nature of Valkey, it is possible to try a lot of passwords in parallel in very short time, so make sure to generate a strong and very long password so that this attack is infeasible. -A good way to generate strong passwords is via the `ACL GENPASS` command. +A good way to generate strong passwords is via the [`ACL GENPASS`](acl-genpass.md) command. diff --git a/commands/client-caching.md b/commands/client-caching.md index cee0640a..f96e2733 100644 --- a/commands/client-caching.md +++ b/commands/client-caching.md @@ -4,7 +4,7 @@ Please check the [client side caching documentation](../topics/client-side-caching.md) for background information. -When tracking is enabled Valkey, using the `CLIENT TRACKING` command, it is +When tracking is enabled Valkey, using the [`CLIENT TRACKING`](client-tracking.md) command, it is possible to specify the `OPTIN` or `OPTOUT` options, so that keys in read only commands are not automatically remembered by the server to be invalidated later. When we are in `OPTIN` mode, we can enable the diff --git a/commands/client-capa.md b/commands/client-capa.md index 557a6d87..fafd3370 100644 --- a/commands/client-capa.md +++ b/commands/client-capa.md @@ -9,4 +9,4 @@ The capabilities currently supported are: * `redirect` - This indicates that the client is capable of handling redirect messages. When accessing a replica node in standalone mode, if a data operation is performed (read or write commands), Valkey will return `-REDIRECT primary-ip:port` to this connection. - Using the `READONLY` command can enable this connection to execute read commands on the replica node. + Using the [`READONLY`](readonly.md) command can enable this connection to execute read commands on the replica node. diff --git a/commands/client-getname.md b/commands/client-getname.md index 0991c6ee..3f53e518 100644 --- a/commands/client-getname.md +++ b/commands/client-getname.md @@ -1 +1 @@ -The `CLIENT GETNAME` returns the name of the current connection as set by `CLIENT SETNAME`. Since every new connection starts without an associated name, if no name was assigned a null bulk reply is returned. +The `CLIENT GETNAME` returns the name of the current connection as set by [`CLIENT SETNAME`](client-setname.md). Since every new connection starts without an associated name, if no name was assigned a null bulk reply is returned. diff --git a/commands/client-getredir.md b/commands/client-getredir.md index 640f4ead..f3433817 100644 --- a/commands/client-getredir.md +++ b/commands/client-getredir.md @@ -1,6 +1,6 @@ This command returns the client ID we are redirecting our [tracking](../topics/client-side-caching.md) notifications to. We set a client -to redirect to when using `CLIENT TRACKING` to enable tracking. However in +to redirect to when using [`CLIENT TRACKING`](client-tracking.md) to enable tracking. However in order to avoid forcing client libraries implementations to remember the ID notifications are redirected to, this command exists in order to improve introspection and allow clients to check later if redirection is active diff --git a/commands/client-id.md b/commands/client-id.md index 99a05035..0533311d 100644 --- a/commands/client-id.md +++ b/commands/client-id.md @@ -4,7 +4,7 @@ ID has certain guarantees: 1. It is never repeated, so if `CLIENT ID` returns the same number, the caller can be sure that the underlying client did not disconnect and reconnect the connection, but it is still the same connection. 2. The ID is monotonically incremental. If the ID of a connection is greater than the ID of another connection, it is guaranteed that the second connection was established with the server at a later time. -This command is especially useful together with `CLIENT UNBLOCK`. +This command is especially useful together with [`CLIENT UNBLOCK`](client-unblock.md). Check the `CLIENT UNBLOCK` command page for a pattern involving the two commands. ## Examples diff --git a/commands/client-info.md b/commands/client-info.md index bdf160b5..6783d989 100644 --- a/commands/client-info.md +++ b/commands/client-info.md @@ -1,6 +1,6 @@ The command returns information and statistics about the current client connection in a mostly human readable format. -The reply format is identical to that of `CLIENT LIST`, and the content consists only of information about the current client. +The reply format is identical to that of [`CLIENT LIST`](client-list.md), and the content consists only of information about the current client. ## Examples diff --git a/commands/client-list.md b/commands/client-list.md index c8ed044f..0415b2c0 100644 --- a/commands/client-list.md +++ b/commands/client-list.md @@ -45,7 +45,7 @@ Here is the meaning of the fields: * `addr`: address/port of the client * `laddr`: address/port of local address client connected to (bind address) * `fd`: file descriptor corresponding to the socket -* `name`: the name set by the client with `CLIENT SETNAME` +* `name`: the name set by the client with [`CLIENT SETNAME`](client-setname.md) * `age`: total duration of the connection in seconds * `idle`: idle time of the connection in seconds * `flags`: client flags (see below) @@ -69,7 +69,7 @@ Here is the meaning of the fields: * `user`: the authenticated username of the client * `redir`: client id of current client tracking redirection * `resp`: client RESP protocol version. -* `lib-name`: The client library name as set by `CLIENT SETINFO` +* `lib-name`: The client library name as set by [`CLIENT SETINFO`](client-setinfo.md) * `lib-version`: The client library version as set by `CLIENT SETINFO` * `tot-net-in`: Total network input bytes read from this client. Added in Valkey 8.0 * `tot-net-out`: Total network output bytes sent to this client. Added in Valkey 8.0 diff --git a/commands/client-no-touch.md b/commands/client-no-touch.md index da723058..3d583b4b 100644 --- a/commands/client-no-touch.md +++ b/commands/client-no-touch.md @@ -1,5 +1,5 @@ The `CLIENT NO-TOUCH` command controls whether commands sent by the client will alter the LRU/LFU of the keys they access. -When turned on, the current client will not change LFU/LRU stats, unless it sends the `TOUCH` command. +When turned on, the current client will not change LFU/LRU stats, unless it sends the [`TOUCH`](touch.md) command. When turned off, the client touches LFU/LRU stats just as a normal client. diff --git a/commands/client-pause.md b/commands/client-pause.md index 4decf975..facb777e 100644 --- a/commands/client-pause.md +++ b/commands/client-pause.md @@ -26,7 +26,7 @@ This command is useful as it makes able to switch clients from a Valkey instance * Reconfigure clients to connect with the new primary. The recommended mode for client pause is `WRITE`. This mode will stop all replication traffic, can be -aborted with the `CLIENT UNPAUSE` command, and allows reconfiguring the old primary without risking accepting writes after the +aborted with the [`CLIENT UNPAUSE`](client-unpause.md) command, and allows reconfiguring the old primary without risking accepting writes after the failover. This is also the mode used during cluster failover. This command also prevents keys to be evicted or expired during the time clients are paused. diff --git a/commands/client-setinfo.md b/commands/client-setinfo.md index 64a66f37..e07f38ed 100644 --- a/commands/client-setinfo.md +++ b/commands/client-setinfo.md @@ -1,4 +1,4 @@ -The `CLIENT SETINFO` command assigns various info attributes to the current connection which are displayed in the output of `CLIENT LIST` and `CLIENT INFO`. +The `CLIENT SETINFO` command assigns various info attributes to the current connection which are displayed in the output of [`CLIENT LIST`](client-list.md) and [`CLIENT INFO`](client-info.md). Client libraries are expected to pipeline this command after authentication on all connections and ignore failures since they could be connected to an older version that doesn't support them. @@ -9,4 +9,4 @@ Currently the supported attributes are: There is no limit to the length of these attributes. However it is not possible to use spaces, newlines, or other non-printable characters that would violate the format of the `CLIENT LIST` reply. -Note that these attributes are **not** cleared by the RESET command. +Note that these attributes are **not** cleared by the [`RESET`](reset.md) command. diff --git a/commands/client-setname.md b/commands/client-setname.md index e3a3f7f6..528f1d3f 100644 --- a/commands/client-setname.md +++ b/commands/client-setname.md @@ -1,6 +1,6 @@ The `CLIENT SETNAME` command assigns a name to the current connection. -The assigned name is displayed in the output of `CLIENT LIST` so that it is possible to identify the client that performed a given connection. +The assigned name is displayed in the output of [`CLIENT LIST`](client-list.md) so that it is possible to identify the client that performed a given connection. For instance when Valkey is used in order to implement a queue, producers and consumers of messages may want to set the name of the connection according to their role. @@ -8,7 +8,7 @@ There is no limit to the length of the name that can be assigned if not the usua It is possible to entirely remove the connection name setting it to the empty string, that is not a valid connection name since it serves to this specific purpose. -The connection name can be inspected using `CLIENT GETNAME`. +The connection name can be inspected using [`CLIENT GETNAME`](client-getname.md). Every new connection starts without an assigned name. diff --git a/commands/client-tracking.md b/commands/client-tracking.md index 26750558..a959878a 100644 --- a/commands/client-tracking.md +++ b/commands/client-tracking.md @@ -21,9 +21,9 @@ unless tracking is turned off with `CLIENT TRACKING off` at some point. The following are the list of options that modify the behavior of the command when enabling tracking: -* `REDIRECT `: send invalidation messages to the connection with the specified ID. The connection must exist. You can get the ID of a connection using `CLIENT ID`. If the connection we are redirecting to is terminated, when in RESP3 mode the connection with tracking enabled will receive `tracking-redir-broken` push messages in order to signal the condition. +* `REDIRECT `: send invalidation messages to the connection with the specified ID. The connection must exist. You can get the ID of a connection using [`CLIENT ID`](client-id.md). If the connection we are redirecting to is terminated, when in RESP3 mode the connection with tracking enabled will receive `tracking-redir-broken` push messages in order to signal the condition. * `BCAST`: enable tracking in broadcasting mode. In this mode invalidation messages are reported for all the prefixes specified, regardless of the keys requested by the connection. Instead when the broadcasting mode is not enabled, Valkey will track which keys are fetched using read-only commands, and will report invalidation messages only for such keys. * `PREFIX `: for broadcasting, register a given key prefix, so that notifications will be provided only for keys starting with this string. This option can be given multiple times to register multiple prefixes. If broadcasting is enabled without this option, Valkey will send notifications for every key. You can't delete a single prefix, but you can delete all prefixes by disabling and re-enabling tracking. Using this option adds the additional time complexity of O(N^2), where N is the total number of prefixes tracked. -* `OPTIN`: when broadcasting is NOT active, normally don't track keys in read only commands, unless they are called immediately after a `CLIENT CACHING yes` command. +* `OPTIN`: when broadcasting is NOT active, normally don't track keys in read only commands, unless they are called immediately after a [`CLIENT CACHING yes`](client-caching.md) command. * `OPTOUT`: when broadcasting is NOT active, normally track keys in read only commands, unless they are called immediately after a `CLIENT CACHING no` command. * `NOLOOP`: don't send notifications about keys modified by this connection itself. diff --git a/commands/client-unblock.md b/commands/client-unblock.md index 7fe53f9b..0959e64d 100644 --- a/commands/client-unblock.md +++ b/commands/client-unblock.md @@ -1,4 +1,4 @@ -This command can unblock, from a different connection, a client blocked in a blocking operation, such as for instance `BRPOP` or `XREAD` or `WAIT`. +This command can unblock, from a different connection, a client blocked in a blocking operation, such as for instance [`BRPOP`](brpop.md) or [`XREAD`](xread.md) or [`WAIT`](wait.md). By default the client is unblocked as if the timeout of the command was reached, however if an additional (and optional) argument is passed, it is possible to specify the unblocking behavior, that can be **TIMEOUT** (the default) or **ERROR**. If **ERROR** is specified, the behavior is to unblock the client returning as error the fact that the client was force-unblocked. Specifically the client will receive the following error: @@ -19,7 +19,7 @@ the new key, and issue the blocking command again. To obtain this behavior the following pattern is used. The process uses an additional *control connection* in order to send the `CLIENT UNBLOCK` command if needed. In the meantime, before running the blocking operation on the other -connections, the process runs `CLIENT ID` in order to get the ID associated +connections, the process runs [`CLIENT ID`](client-id.md) in order to get the ID associated with that connection. When a new key should be added, or when a key should no longer be monitored, the relevant connection blocking command is aborted by sending `CLIENT UNBLOCK` in the control connection. The blocking command diff --git a/commands/client-unpause.md b/commands/client-unpause.md index 9878ee1b..b825c0b0 100644 --- a/commands/client-unpause.md +++ b/commands/client-unpause.md @@ -1 +1 @@ -`CLIENT UNPAUSE` is used to resume command processing for all clients that were paused by `CLIENT PAUSE`. +`CLIENT UNPAUSE` is used to resume command processing for all clients that were paused by [`CLIENT PAUSE`](client-pause.md). diff --git a/commands/client.md b/commands/client.md index fdfd0e8b..657fbd30 100644 --- a/commands/client.md +++ b/commands/client.md @@ -1,3 +1,3 @@ This is a container command for client connection commands. -To see the list of available commands you can call `CLIENT HELP`. \ No newline at end of file +To see the list of available commands you can call [`CLIENT HELP`](client-help.md). diff --git a/commands/cluster-addslotsrange.md b/commands/cluster-addslotsrange.md index 77f8c991..914a387d 100644 --- a/commands/cluster-addslotsrange.md +++ b/commands/cluster-addslotsrange.md @@ -1,4 +1,4 @@ -The `CLUSTER ADDSLOTSRANGE` is similar to the `CLUSTER ADDSLOTS` command in that they both assign hash slots to nodes. +The `CLUSTER ADDSLOTSRANGE` is similar to the [`CLUSTER ADDSLOTS`](cluster-addslots.md) command in that they both assign hash slots to nodes. The difference between the two commands is that `CLUSTER ADDSLOTS` takes a list of slots to assign to the node, while `CLUSTER ADDSLOTSRANGE` takes a list of slot ranges (specified by start and end slots) to assign to the node. diff --git a/commands/cluster-delslots.md b/commands/cluster-delslots.md index e7c7e9ac..6fb3a38a 100644 --- a/commands/cluster-delslots.md +++ b/commands/cluster-delslots.md @@ -9,7 +9,7 @@ has consequently removed the associations for the passed hash slots, we say those hash slots are *unbound*. Note that the existence of unbound hash slots occurs naturally when a node has not been configured to handle them (something that can be done with the -`CLUSTER ADDSLOTS` command) and if it has not received any information about +[`CLUSTER ADDSLOTS`](cluster-addslots.md) command) and if it has not received any information about who owns those hash slots (something that it can learn from heartbeat or update messages). diff --git a/commands/cluster-delslotsrange.md b/commands/cluster-delslotsrange.md index fdcbdb1d..5da06b0a 100644 --- a/commands/cluster-delslotsrange.md +++ b/commands/cluster-delslotsrange.md @@ -1,4 +1,4 @@ -The `CLUSTER DELSLOTSRANGE` command is similar to the `CLUSTER DELSLOTS` command in that they both remove hash slots from the node. +The `CLUSTER DELSLOTSRANGE` command is similar to the [`CLUSTER DELSLOTS`](cluster-deslots.md) command in that they both remove hash slots from the node. The difference is that `CLUSTER DELSLOTS` takes a list of hash slots to remove from the node, while `CLUSTER DELSLOTSRANGE` takes a list of slot ranges (specified by start and end slots) to remove from the node. ## Example diff --git a/commands/cluster-failover.md b/commands/cluster-failover.md index 3e4caecc..b8a147ba 100644 --- a/commands/cluster-failover.md +++ b/commands/cluster-failover.md @@ -64,6 +64,6 @@ Because of this the **TAKEOVER** option should be used with care. * An `OK` reply is no guarantee that the failover will succeed. * A replica can only be promoted to a primary if it is known as a replica by a majority of the primaries in the cluster. If the replica is a new node that has just been added to the cluster (for example after upgrading it), it may not yet be known to all the primaries in the cluster. - To check that the primaries are aware of a new replica, you can send `CLUSTER NODES` or `CLUSTER REPLICAS` to each of the primary nodes and check that it appears as a replica, before sending `CLUSTER FAILOVER` to the replica. -* To check that the failover has actually happened you can use `ROLE`, `INFO REPLICATION` (which indicates "role:master" after successful failover), or `CLUSTER NODES` to verify that the state of the cluster has changed sometime after the command was sent. + To check that the primaries are aware of a new replica, you can send [`CLUSTER NODES`](cluster-nodes.md) or [`CLUSTER REPLICAS`](cluster-replicas.md) to each of the primary nodes and check that it appears as a replica, before sending `CLUSTER FAILOVER` to the replica. +* To check that the failover has actually happened you can use [`ROLE`](role.md), [`INFO REPLICATION`](info.md) (which indicates "role:master" after successful failover), or `CLUSTER NODES` to verify that the state of the cluster has changed sometime after the command was sent. * To check if the failover has failed, check the replica's log for "Manual failover timed out", which is logged if the replica has given up after a few seconds. diff --git a/commands/cluster-getkeysinslot.md b/commands/cluster-getkeysinslot.md index 1ac997f7..57b3ec5a 100644 --- a/commands/cluster-getkeysinslot.md +++ b/commands/cluster-getkeysinslot.md @@ -6,9 +6,9 @@ Note that this works only when deleting keys, as the same `count` keys are returned on each call unless removed. The main usage of this command is during rehashing of cluster slots from one -node to another. The way the rehashing is performed is exposed in the Valkey -Cluster specification, or in a more simple to digest form, as an appendix -of the `CLUSTER SETSLOT` command documentation. +node to another. The way the rehashing is performed is exposed in the [Valkey +Cluster specification](../topics/cluster-spec.md), or in a more simple to digest form, as an appendix +of the [`CLUSTER SETSLOT`](cluster-setslot.md) command documentation. ``` > CLUSTER GETKEYSINSLOT 7000 3 diff --git a/commands/cluster-info.md b/commands/cluster-info.md index c55073c3..ca487d0d 100644 --- a/commands/cluster-info.md +++ b/commands/cluster-info.md @@ -1,4 +1,4 @@ -`CLUSTER INFO` provides `INFO` style information about Valkey Cluster vital parameters. +`CLUSTER INFO` provides [`INFO`](info.md) style information about Valkey Cluster vital parameters. The following fields are always present in the reply: ``` @@ -29,10 +29,10 @@ total_cluster_links_buffer_limit_exceeded:0 * `cluster_nodes_fail`: Number of nodes in `FAIL` state. A non-zero value indicates one or more nodes are unreachable and have been marked as failed by a quorum of voting nodes. * `cluster_voting_nodes_pfail`: Number of voting nodes in `PFAIL` state. A non-zero value indicates one or more primary nodes serving at least one slot are unreachable but not yet confirmed as failed by a quorum of voting nodes. * `cluster_voting_nodes_fail`: Number of voting nodes in `FAIL` state. A non-zero value indicates one or more primary nodes serving at least one slot have been marked as failed by a quorum of voting nodes. -* `cluster_known_nodes`: The total number of known nodes in the cluster, including nodes in `HANDSHAKE` state that may not currently be proper members of the cluster. +* `cluster_known_nodes`: The total number of known nodes in the cluster, including nodes in [`HANDSHAKE`](../topics/cluster-spec.md#node-handshake) state that may not currently be proper members of the cluster. * `cluster_size`: The number of primary nodes serving at least one hash slot in the cluster. -* `cluster_current_epoch`: The local `Current Epoch` variable. This is used in order to create unique increasing version numbers during fail overs. -* `cluster_my_epoch`: The `Config Epoch` of the node we are talking with. This is the current configuration version assigned to this node. +* `cluster_current_epoch`: The local [Current Epoch](../topics/cluster-spec.md#cluster-current-epoch). This is used in order to create unique increasing version numbers during fail overs. +* `cluster_my_epoch`: The [Config Epoch](../topics/cluster-spec.md#configuration-epoch) of the node we are talking with. This is the current configuration version assigned to this node. * `cluster_stats_messages_sent`: Number of messages sent via the cluster node-to-node binary bus. * `cluster_stats_messages_received`: Number of messages received via the cluster node-to-node binary bus. * `total_cluster_links_buffer_limit_exceeded`: Accumulated count of cluster links freed due to exceeding the `cluster-link-sendbuf-limit` configuration. @@ -40,10 +40,10 @@ total_cluster_links_buffer_limit_exceeded:0 The following message-related fields may be included in the reply if the value is not 0: Each message type includes statistics on the number of messages sent and received. Here are the explanation of these fields: - -* `cluster_stats_messages_ping_sent` and `cluster_stats_messages_ping_received`: Cluster bus PING (not to be confused with the client command `PING`). +] +* `cluster_stats_messages_ping_sent` and `cluster_stats_messages_ping_received`: Cluster bus PING (not to be confused with the client command [`PING`](ping.md). * `cluster_stats_messages_pong_sent` and `cluster_stats_messages_pong_received`: PONG (reply to PING). -* `cluster_stats_messages_meet_sent` and `cluster_stats_messages_meet_received`: Handshake message sent to a new node, either through gossip or `CLUSTER MEET`. +* `cluster_stats_messages_meet_sent` and `cluster_stats_messages_meet_received`: Handshake message sent to a new node, either through gossip or [`CLUSTER MEET`](cluster-meet.md). * `cluster_stats_messages_fail_sent` and `cluster_stats_messages_fail_received`: Mark node xxx as failing. * `cluster_stats_messages_publish_sent` and `cluster_stats_messages_publish_received`: Pub/Sub Publish propagation, see [Pubsub](../topics/pubsub.md#pubsub). * `cluster_stats_messages_auth-req_sent` and `cluster_stats_messages_auth-req_received`: Replica initiated leader election to replace its primary. diff --git a/commands/cluster-keyslot.md b/commands/cluster-keyslot.md index 07afba25..21d499b5 100644 --- a/commands/cluster-keyslot.md +++ b/commands/cluster-keyslot.md @@ -17,4 +17,4 @@ Example use cases for this command: (integer) 2515 ``` -Note that the command implements the full hashing algorithm, including support for **hash tags**, that is the special property of Valkey Cluster key hashing algorithm, of hashing just what is between `{` and `}` if such a pattern is found inside the key name, in order to force multiple keys to be handled by the same node. +Note that the command implements the full hashing algorithm, including support for [hash tags](../topics/cluster-spec.md#hash-tags), that is the special property of Valkey Cluster key hashing algorithm, of hashing just what is between `{` and `}` if such a pattern is found inside the key name, in order to force multiple keys to be handled by the same node. diff --git a/commands/cluster-nodes.md b/commands/cluster-nodes.md index 3cc086a6..3376b32f 100644 --- a/commands/cluster-nodes.md +++ b/commands/cluster-nodes.md @@ -4,12 +4,12 @@ nodes, their flags, properties and assigned slots, and so forth. `CLUSTER NODES` provides all this information, that is, the current cluster configuration of the node we are contacting, in a serialization format which -happens to be exactly the same as the one used by Valkey Cluster itself in +happens to be exactly the same as the one used by the Valkey Cluster itself in order to store on disk the cluster state (however the on disk cluster state has a few additional info appended at the end). Note that normally clients willing to fetch the map between Cluster -hash slots and node addresses should use `CLUSTER SLOTS` instead. +hash slots and node addresses should use [`CLUSTER SLOTS`](cluster-slots.md) instead. `CLUSTER NODES`, that provides more information, should be used for administrative tasks, debugging, and configuration inspections. It is also used by `valkey-cli` in order to manage a cluster. @@ -37,7 +37,7 @@ Each line is composed of the following fields: The meaning of each field is the following: -1. `id`: The node ID, a 40-character globally unique string generated when a node is created and never changed again (unless `CLUSTER RESET HARD` is used). +1. `id`: The node ID, a 40-character globally unique string generated when a node is created and never changed again (unless [`CLUSTER RESET HARD`](cluster-reset.md) is used). 2. `ip:port@cport`: The node address that clients should contact to run queries, along with the used cluster bus port. `:0@0` can be expected when the address is no longer known for this node ID, hence flagged with `noaddr`. 3. `hostname`: A human readable string that can be configured via the `cluster-annouce-hostname` setting. The max length of the string is 256 characters, excluding the null terminator. The name can contain ASCII alphanumeric characters, '-', and '.' only. @@ -81,7 +81,7 @@ as already explained above: However node hash slots can be in a special state, used in order to communicate errors after a node restart (mismatch between the keys in the AOF/RDB file, and the node hash slots configuration), or when there is a resharding operation in progress. This two states are **importing** and **migrating**. -The meaning of the two states is explained in the Valkey Specification, however the gist of the two states is the following: +The meaning of the two states is explained in the [Valkey Specification](../topics/cluster-spec.md), however the gist of the two states is the following: * **Importing** slots are yet not part of the nodes hash slot, there is a migration in progress. The node will accept queries about these slots only if the `ASK` command is used. * **Migrating** slots are assigned to the node, but are being migrated to some other node. The node will accept queries if all the keys in the command exist already, otherwise it will emit what is called an **ASK redirection**, to force new keys creation directly in the importing node. @@ -98,11 +98,11 @@ The following are a few examples of importing and migrating slots: * `[77->-e7d1eecce10fd6bb5eb35b9f99a514335d9ba9ca]` * `[16311->-292f8b365bb7edb5e285caf0b7e6ddc7265d2f4f]` -Note that the format does not have any space, so `CLUSTER NODES` output format is plain CSV with space as separator even when this special slots are emitted. However a complete parser for the format should be able to handle them. +Note that the format does not have any space, so `CLUSTER NODES` output format is plain CSV with space as separator even when these special slots are emitted. However a complete parser for the format should be able to handle them. Note that: 1. Migration and importing slots are only added to the node flagged as `myself`. This information is local to a node, for its own slots. -2. Importing and migrating slots are provided as **additional info**. If the node has a given hash slot assigned, it will be also a plain number in the list of hash slots, so clients that don't have a clue about hash slots migrations can just skip this special fields. +2. Importing and migrating slots are provided as **additional info**. If the node has a given hash slot assigned, it will be also a plain number in the list of hash slots, so clients that don't have a clue about hash slots migrations can just skip these special fields. -> NOTE: If not for backward compatibility, the Valkey project no longer uses the words "master" and "slave". Unfortunately in the given commands these words are part of the protocol, so we'll be able to remove such occurrences only when this API will be naturally deprecated. +> NOTE: If not for backward compatibility, the Valkey project no longer uses the words "master" and "slave". Unfortunately, in the given commands these words are part of the protocol, so we'll be able to remove such occurrences only when this API is naturally deprecated. diff --git a/commands/cluster-replicas.md b/commands/cluster-replicas.md index b2d87a95..addf6da0 100644 --- a/commands/cluster-replicas.md +++ b/commands/cluster-replicas.md @@ -1,5 +1,5 @@ The command provides a list of replica nodes replicating from the specified -primary node. The list is provided in the same format used by `CLUSTER NODES` (please refer to its documentation for the specification of the format). +primary node. The list is provided in the same format used by [`CLUSTER NODES`](cluster-nodes.md) (please refer to its documentation for the specification of the format). The command will fail if the specified node is not known or if it is not a primary according to the node table of the node receiving the command. diff --git a/commands/cluster-reset.md b/commands/cluster-reset.md index 620a31c6..7f80a362 100644 --- a/commands/cluster-reset.md +++ b/commands/cluster-reset.md @@ -1,7 +1,7 @@ Reset a Valkey Cluster node, in a more or less drastic way depending on the reset type, that can be **hard** or **soft**. Note that this command **does not work for primaries if they hold one or more keys**, in that case -to completely reset a primary node keys must be removed first, e.g. by using `FLUSHALL` first, +to completely reset a primary node keys must be removed first, e.g. by using [`FLUSHALL`](flushall.md) first, and then `CLUSTER RESET`. Effects on the node: diff --git a/commands/cluster-saveconfig.md b/commands/cluster-saveconfig.md index 3f237019..41b9e9b7 100644 --- a/commands/cluster-saveconfig.md +++ b/commands/cluster-saveconfig.md @@ -1,4 +1,4 @@ -Forces a node to save the `nodes.conf` configuration on disk. Before to return +Forces a node to save the `nodes.conf` configuration on disk. Before returning, the command calls `fsync(2)` in order to make sure the configuration is flushed on the computer disk. diff --git a/commands/cluster-setslot.md b/commands/cluster-setslot.md index 4b0b2fa0..4fb29a83 100644 --- a/commands/cluster-setslot.md +++ b/commands/cluster-setslot.md @@ -1,4 +1,4 @@ -`CLUSTER SETSLOT` is responsible of changing the state of a hash slot in the receiving node in different ways. It can, depending on the subcommand used: +`CLUSTER SETSLOT` is responsible for changing the state of a hash slot in the receiving node in different ways. It can, depending on the subcommand used: 1. `MIGRATING` subcommand: Set a hash slot in *migrating* state. 2. `IMPORTING` subcommand: Set a hash slot in *importing* state. @@ -66,7 +66,7 @@ The `CLUSTER SETSLOT` command is an important piece used by Valkey Cluster in or 1. Set the destination node slot to *importing* state using `CLUSTER SETSLOT IMPORTING `. 2. Set the source node slot to *migrating* state using `CLUSTER SETSLOT MIGRATING `. -3. Get keys from the source node with `CLUSTER GETKEYSINSLOT` command and move them into the destination node using the `MIGRATE` command. +3. Get keys from the source node with [`CLUSTER GETKEYSINSLOT`](cluster-getkeysinslot.md) command and move them into the destination node using the [`MIGRATE`](migrate.md) command. 4. Send `CLUSTER SETSLOT NODE ` to the destination node. 5. Send `CLUSTER SETSLOT NODE ` to the source node. 6. Send `CLUSTER SETSLOT NODE ` to the other primary nodes (optional). diff --git a/commands/cluster-shards.md b/commands/cluster-shards.md index 5a674ee2..75ac5dc1 100644 --- a/commands/cluster-shards.md +++ b/commands/cluster-shards.md @@ -3,7 +3,7 @@ A shard is defined as a collection of nodes that serve the same set of slots and A shard may only have a single primary at a given time, but may have multiple or no replicas. It is possible for a shard to not be serving any slots while still having replicas. -This command replaces the `CLUSTER SLOTS` command, by providing a more efficient and extensible representation of the cluster. +This command replaces the [`CLUSTER SLOTS`](cluster-slots.md) command, by providing a more efficient and extensible representation of the cluster. The command is suitable to be used by Valkey Cluster client libraries in order to understand the topology of the cluster. A client should issue this command on startup in order to retrieve the map associating cluster *hash slots* with actual node information. diff --git a/commands/hello.md b/commands/hello.md index 3e87e1af..e7098e58 100644 --- a/commands/hello.md +++ b/commands/hello.md @@ -3,7 +3,7 @@ connection's name, or provide a contextual client report. Valkey supports two protocols: RESP2 and RESP3. RESP3 has certain advantages since when the connection is in this mode, Valkey is able to reply with more semantical -replies: for instance, `HGETALL` will return a *map type*, so a client library +replies: for instance, [`HGETALL`](hgetall.md) will return a *map type*, so a client library implementation no longer requires to know in advance to translate the array into a hash before returning it to the caller. For a full coverage of RESP3, please check the [RESP3 specification](https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md). @@ -58,5 +58,5 @@ command instead of the canonical `PING` when setting up the connection. When called with the optional `protover` argument, this command switches the protocol to the specified version and also accepts the following options: -* `AUTH `: directly authenticate the connection in addition to switching to the specified protocol version. This makes calling `AUTH` before `HELLO` unnecessary when setting up a new connection. Note that the `username` can be set to "default" to authenticate against a server that does not use ACLs, but rather the simpler `requirepass` mechanism. -* `SETNAME `: this is the equivalent of calling `CLIENT SETNAME`. +* `AUTH `: directly authenticate the connection in addition to switching to the specified protocol version. This makes calling [`AUTH`](auth.md) before `HELLO` unnecessary when setting up a new connection. Note that the `username` can be set to "default" to authenticate against a server that does not use ACLs, but rather the simpler `requirepass` mechanism. +* `SETNAME `: this is the equivalent of calling [`CLIENT SETNAME`](client-setname.md). diff --git a/commands/readonly.md b/commands/readonly.md index c79c35fe..a78f2f28 100644 --- a/commands/readonly.md +++ b/commands/readonly.md @@ -19,4 +19,4 @@ primary node. This may happen because: In standalone mode, by default, clients accessing a replica node can execute read queries, (which might read stale data) without entering readonly mode. -Since Valkey 8.0, if a client in standalone mode uses the `CLIENT CAPA redirect` command to declare its capability to handle redirections, then the replica node will send redirection messages to the client when executing both read and write commands. The client must issue the `READONLY` command to enter readonly mode before it can execute read commands. +Since Valkey 8.0, if a client in standalone mode uses the [`CLIENT CAPA redirect`](client-capa.md) command to declare its capability to handle redirections, then the replica node will send redirection messages to the client when executing both read and write commands. The client must issue the `READONLY` command to enter readonly mode before it can execute read commands. diff --git a/commands/readwrite.md b/commands/readwrite.md index b1858d59..326ccbc4 100644 --- a/commands/readwrite.md +++ b/commands/readwrite.md @@ -3,8 +3,8 @@ Disables read queries for a connection to a Valkey replica node. Read queries against a Valkey Cluster replica node are disabled by default. For standalone replica nodes, since Valkey 8.0, read queries are also disabled -for clients that have executed the `CLIENT CAPA redirect` command. +for clients that have executed the [`CLIENT CAPA redirect`](client-capa.md) command. -But you can use the `READONLY` command to change this behavior on a per- +But you can use the [`READONLY`](readonly.md) command to change this behavior on a per- connection basis. The `READWRITE` command resets the readonly mode flag of a connection back to readwrite. diff --git a/commands/select.md b/commands/select.md index 8e68f92a..c28b0d61 100644 --- a/commands/select.md +++ b/commands/select.md @@ -1,10 +1,10 @@ Select the Valkey logical database having the specified zero-based numeric index. New connections always use the database 0. -Selectable Valkey databases are a form of namespacing: all databases are still persisted in the same RDB / AOF file. However different databases can have keys with the same name, and commands like `FLUSHDB`, `SWAPDB` or `RANDOMKEY` work on specific databases. +Selectable Valkey databases are a form of namespacing: all databases are still persisted in the same RDB / AOF file. However different databases can have keys with the same name, and commands like [`FLUSHDB`](flushdb.md), [`SWAPDB`](swapdb.md) or [`RANDOMKEY`](randomkey.md) work on specific databases. In practical terms, Valkey databases should be used to separate different keys belonging to the same application (if needed), and not to use a single Valkey instance for multiple unrelated applications. Valkey 9.0 and later supports multiple databases in cluster mode. You can use `SELECT ` to switch between them. -Since the currently selected database is a property of the connection, clients should track the currently selected database and re-select it on reconnection. While there is no command in order to query the selected database in the current connection, the `CLIENT LIST` output shows, for each client, the currently selected database. +Since the currently selected database is a property of the connection, clients should track the currently selected database and re-select it on reconnection. While there is no command in order to query the selected database in the current connection, the [`CLIENT LIST`](client-list.md) output shows, for each client, the currently selected database.