Commonly used commands and instructions for Redis clusters

1. Characteristics of clusters

1. Cluster architecture characteristics

(1) All redis nodes are interconnected with each other (PING-PONG mechanism), and a binary protocol is used internally to optimize transmission speed and bandwidth;

(2) The fail of a node takes effect only when more than half of the nodes in the cluster detect failures;

(3) The client is directly connected to the redis node, without the need for an intermediate proxy layer. The client does not need to connect to all nodes in the cluster, it can connect to any available node in the cluster;

(4) redis-cluster maps all physical nodes to [0-16383] slots (hash slots), and cluster is responsible for maintaining node<->slot<->value

2. Cluster election fault tolerance:

(1) The node failure election process involves the participation of all masters in the cluster. If more than half of the master nodes communicate with the currently detected master node to detect a timeout (cluster-node-timeout), the current master node is considered dead;

(2) When does the entire cluster become unavailable? (cluster_state:fail)

A: If any master in the cluster dies and the current master has no slave. The cluster enters the fail state, which can also be understood as entering the fail state when the cluster's slot mapping [0-16383] is incomplete. (redis-3.0.0.rcl adds the cluster-require-full-coverage parameter, which is turned off by default. Turning on the cluster compatibility part fails)

B: If more than half of the masters in the cluster die, no matter whether there is a slave cluster entering the fail state. (When the cluster is unavailable, all operations on the cluster are unavailable, and (error) CLUSTERDOWN The cluster is down error is received)

3. Cluster advantages and disadvantages:

advantage:

After the master node goes offline, the slave node will automatically be promoted to the master node to save the cluster and continue to provide services;

After the fail node is restored, it will be automatically added to the cluster and become a slave node;

shortcoming:

Since redis replication uses an asynchronous mechanism, the cluster may lose write commands during automatic failover. However, redis performs these two operations (resuming the command to the client and copying the command to the slave node) almost simultaneously, so in practice, the window for command loss is very small.

2. Cluster client command (redis-cli -c -p port)

Cluster
cluster info: Print cluster information
cluster nodes: List all nodes currently known to the cluster, as well as related information about these nodes.
Node
cluster meet <ip> <port>: Add the node specified by ip and port to the cluster and make it a member of the cluster.
cluster forget <node_id>: Remove the node specified by node_id from the cluster.
cluster replicate <node_id>: Set the current node as the slave node of the node specified by node_id.
cluster saveconfig: Save the node configuration file to the hard disk.
Slot
cluster addslots <slot> [slot ...]: Assign one or more slots to the current node.
cluster delslots <slot> [slot ... ]: Remove one or more slots assigned to the current node.
cluster flushslots: Remove all slots assigned to the current node, turning the current node into a node with no slots assigned to it.
cluster setslot <slot> node <node_id>: Assign the slot to the node specified by node_id. If the slot has been assigned to
another node, let the other node delete the slot first and then assign it.
cluster setslot <slot> migrating <node_id>: Migrate the slot of this node to the node specified by node_id.
cluster setslot <slot> importing <node_id>: Import slots from the node specified by node_id to this node.
cluster setslot <slot> stable: Cancel the import or migration of the slot.
Key
cluster keyslot <key>: Calculate the slot in which the key key should be placed.
cluster countkeysinslot <slot>: Returns the number of key-value pairs currently contained in the slot.
cluster getkeysinslot <slot> <count>: Returns the keys in count slots  

3. Offline and recovery of the Master in the cluster

1. After the Master goes offline, its corresponding Slaver node will automatically become the Master node.

2. The original Master becomes a Slaver node after restarting, and is the Slaver node of the original Master node.

Guess you like

Origin blog.csdn.net/tladagio/article/details/103594186