redis cluster 管理

add new node as master

./redis-trib.rb add-node 127.0.0.1:7006 127.0.0.1:7000

参数一：新节点的ip和端口
参数二：集群中的已有节点

add new node as slave

./redis-trib.rb add-node –slave 127.0.0.1:7006 127.0.0.1:7000

参数一：新节点的ip和端口
参数二：集群中的已有节点
结果：新的节点会作为集群中其中一个主节点的从节点，一般来说是从节点最少的主节点。

add new node as slave of a existing note

./redis-trib.rb add-node –slave –master-id 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 127.0.0.1:7006 127.0.0.1:7000

参数零：主节点ID
参数一：新节点的ip和端口
参数二：集群中的已有节点

Removing a node

./redis-trib del-node 127.0.0.1:7000 <node-id>

参数一：集群中的已有节点
参数二：待删除的节点
备注：如果删除的节点是主节点，主节点必须为空。

Replicas migration

CLUSTER REPLICATE
场景一：增加从节点
场景二：改变从节点的隶属关系

Upgrading nodes in a Redis Cluster节点升级

升级从节点过程：定制服务，重启。
升级主节点建议过程：

Use CLUSTER FAILOVER to trigger a manual failover of the master to one of its slaves (see the "Manual failover" section of this documentation).
1.执行failover，主节点变成从节点，再执行之间，确保从节点运行正常。
Wait for the master to turn into a slave.
2.等待待升级的主节点变为从节点，即failover正常执行。
Finally upgrade the node as you do for slaves.
3.升级节点同升级从节点。
If you want the master to be the node you just upgraded, trigger a new manual failover in order to turn back the upgraded node into a master.
4.如果需要，带从数据同步完成，再次手动执行failover。

Migrating to Redis Cluster

场景一：
Users willing to migrate to Redis Cluster may have just a single master, or may already using a preexisting sharding setup, where keys are split among N nodes, using some in-house algorithm or a sharding algorithm implemented by their client library or Redis proxy.

In both cases it is possible to migrate to Redis Cluster easily, however what is the most important detail is if multiple-keys operations are used by the application, and how. There are three different cases:

Multiple keys operations, or transactions, or Lua scripts involving multiple keys, are not used. Keys are accessed independently (even if accessed via transactions or Lua scripts grouping multiple commands, about the same key, together).
Multiple keys operations, transactions, or Lua scripts involving multiple keys are used but only with keys having the , which means that the keys used together all have a {…} sub-string that happens to be identical. For example the following multiple keys operation is defined in the context of the same hash tag: SUNION {user:1000}.foo {user:1000}.bar.
Multiple keys operations, transactions, or Lua scripts involving multiple keys are used with key names not having an explicit, or the same, hash tag.

The third case is not handled by Redis Cluster: the application requires to be modified in order to don’t use multi keys operations or only use them in the context of the same hash tag.

Case 1 and 2 are covered, so we’ll focus on those two cases, that are handled in the same way, so no distinction will be made in the documentation.

Assuming you have your preexisting data set split into N masters, where N=1 if you have no preexisting sharding, the following steps are needed in order to migrate your data set to Redis Cluster:

Stop your clients. No automatic live-migration to Redis Cluster is currently possible. You may be able to do it orchestrating a live migration in the context of your application / environment.
Generate an append only file for all of your N masters using the BGREWRITEAOF command, and waiting for the AOF file to be completely generated.
Save your AOF files from aof-1 to aof-N somewhere. At this point you can stop your old instances if you wish (this is useful since in non-virtualized deployments you often need to reuse the same computers).
Create a Redis Cluster composed of N masters and zero slaves. You'll add slaves later. Make sure all your nodes are using the append only file for persistence.
Stop all the cluster nodes, substitute their append only file with your pre-existing append only files, aof-1 for the first node, aof-2 for the second node, up to aof-N.
Restart your Redis Cluster nodes with the new AOF files. They'll complain that there are keys that should not be there according to their configuration.
Use redis-trib fix command in order to fix the cluster so that keys will be migrated according to the hash slots each node is authoritative or not.
Use redis-trib check at the end to make sure your cluster is ok.
Restart your clients modified to use a Redis Cluster aware client library.

There is an alternative way to import data from external instances to a Redis Cluster, which is to use the redis-trib import command.

The command moves all the keys of a running instance (deleting the keys from the source instance) to the specified pre-existing Redis Cluster. However note that if you use a Redis 2.8 instance as source instance the operation may be slow since 2.8 does not implement migrate connection caching, so you may want to restart your source instance with a Redis 3.x version before to perform such operation.