redis入门(二)

时间  2019-11-09
标签 redis 入门 栏目 Redis 繁體版
原文   原文链接

目录html

redis入门(二)

目录

redis入门(一)
redis入门(二)
redis入门(三)node

前言

在redis入门(一)简单介绍了redis的历史和安装部署，以及基本的数据结构和api，本节讲解redis持久化、高可用、redis集群和分布式相关的知识。python

持久化

redis做为内存数据库，数据所有存储到内存中。可是若出现断电等缘由会形成数据丢失。redis内置了2种持久化的方式，分别为RDB持久化和AOF持久化。linux

RDB

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，换句话来讲是将当前redis内存中的数据所有保存到硬盘。触发RDB持久化过程分为手动触发和自动触发。redis

  1. 手动触发算法

    能够经过save和bgsave两个命令手动执行保存RDB快照。
    save命令：会阻塞当前redis主进程，直到RDB保存完成，save命令已经弃用，不建议生产环境使用。
    bgsave命令：redis进程会执行fork操做建立进程执行保存RDB快照。只有在fork子进程才会短期阻塞。建议你们都是用bgsave命令保存RDB快照。目前redis内部全部RDB操做都使用bgsave命令shell

    127.0.0.1:26379> save
OK
127.0.0.1:26379> bgsave
Background saving started

  2. 自动触发数据库

    • 使用save相关配置，如save m n。表示m秒内数据集存在n次修改时，自动触发bgsave。
    • 若节点执行全量复制操做时，主节点自动执行bgsave生成RDB文件并发给从节点。

    • 执行debug reload命令从新加载redis时，也会触发save操做。ubuntu

      redis debug命令提供了几个很是实用的debug功能windows

    • 默认状况下执行shutdown命令时，若是没有开启AOF持久化功能且设置过rdb自动保存策略则会自动执行bgsave。

原理

20191030161328.png

  1. 执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，若是存在bgsave命令直接返回。

  2. 父进程执行fork操做建立子进程，fork操做过程当中父进程会阻塞，经过info stats命令查看latest_fork_usec选项，能够获取最近一个fork操做的耗时，单位为微秒。

    127.0.0.1:26379> info stats
# Stats
total_connections_received:1
...
latest_fork_usec:5391
  3. 父进程fork完成后，bgsave命令返回Background saving started信息并再也不阻塞父进程，能够继续响应其余命令。

  4. 子进程建立RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令能够获取最后一次生成RDB的时间，对应info统计的rdb_last_save_time选项。进程发送信号给父进程表示完成，父进程更新统计信息，具体见info Persistence下的rdb_*相关选项。O

    127.0.0.1:26379> lastsave
(integer) 1572423635

经常使用配置

节点名 说明
save m秒有n次修改自动保存
dbfilename RDB保存文件名，会保存到dir配置的路径种

经过config set dbfilename能够动态修改RDB保存文件名，下次运行RDB保存时会保存到新的文件名中。

经验

  1. RDB文件压缩保存能够大幅度下降文件大小
  2. 若磁盘损坏能够经过config set命令动态修改redis根路径和RDB文件路径。
  3. RDB文件加载速度远快于AOF文件加载速度
  4. RDB方式保存没办法作到实时保存，所以不能用于存储不能丢失的数据。
  5. RDB方式保存每次都会将内存中的数据全量进行保存，所以不适用于内存数据较大且须要频繁保存的场景。

AOF

AOF（appendonlyfile）持久化：以独立日志的方式记录每次写命令，重启时再从新执行AOF文件中的命令达到恢复数据的目的。AOF保存的不是数据，而是每次执行的命令，所以AOF文件会比RDB文件大的多。

原理

20191030164532.png

  1. 全部的写入命令会追加到aof_buf（缓冲区）中。

  2. AOF缓冲区根据对应的策略向硬盘作缓冲区文件操做。

    AOF有三种缓冲区文件同步策略

  3. 随着AOF文件愈来愈大，须要按期对AOF文件进行重写，达到压缩的目的。

  4. 当Redis服务器重启时，能够加载AOF文件进行数据恢复。

缓冲区同步策略
  1. 实时同步
    经过配置appendfsync always，命令写入缓存后，调用系统fsync同步文件操做。
  2. 每秒同步
    经过配置appendfsync ecerysec，命令写入缓存后，调用系统write操做。一个专门的线程每秒调用一次fsync同步文件操做。
  3. 操做系统决定什么时候同步
    经过配置appendfsync no，命令写入缓存后，不作fsync同步文件操做，同步操做由操做系统负责，一般同步周期最长30秒
  • write操做会触发延迟写（delayedwrite）机制。Linux在内核提供页缓冲区用来提升硬盘IO性能。write操做在写入系统缓冲区后直接返回。同步硬盘操做依赖于系统调度机制，例如：缓冲区页空间写满或达到特定时间周期。同步文件以前，若是此时系统故障宕机，缓冲区内数据将丢失。
  • fsync针对单个文件操做（好比AOF文件），作强制硬盘同步，fsync将阻塞直到写入硬盘完成后返回，保证了数据持久化。
重写机制

随着命令不断写入AOF，文件会愈来愈大，为了解决这个问题，Redis引入AOF重写机制优化命令。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。定时AOF重写不但能够减少硬盘文件占用，同时能够在redis重启时更快的加载AOF文件。

AOF重写会重写如下内容，AOF重写能够删除已经超时的数据，旧的AOF无效命令(先新增后删除)，多条写命令合并为一个(多条插入集合能够合并为一条插入命令)

  • 手动触发：直接调用bgrewriteaof命令。

    127.0.0.1:26379> bgrewriteaof
Background append only file rewriting started

  • 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数肯定自动触发时机。

20191030182805.png

  1. 执行AOF重写请求。若是当前进程正在执行AOF重写若是当前进程正在执行bgsave操做，重写命令延迟到bgsave完成以后再执行。
  2. 父进程执行fork建立子进程，开销等同于bgsave过程。
  3. 主进程fork操做完成后，继续响应其余命令。全部修改命令依然写入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性。
    因为fork操做运用写时复制技术，子进程只能共享fork操做时的内存数据。
  4. 子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多形成硬盘阻塞。
  5. 新AOF文件写入完成后，子进程发送信号给父进程。
  6. 因为父进程依然响应命令，Redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
  7. 父进程更新统计信息，具体见info persistence下的aof_*相关统计。

持久化文件加载

20191030184841.png

  1. AOF持久化开启且存在AOF文件时，优先加载AOF文件
  2. AOF关闭或者AOF文件不存在时，加载RDB文件
  3. 加载AOF/RDB文件成功后，Redis启动成功。
  4. AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。

高可用

Redis支持主从复制，可是当发生故障的时候必须人工进行故障转移，人工故障转移实际就不是服务高可用。

  • 2.8 版本以前 Redis 复制采用 sync 命令，不管是第一次主从复制仍是断线重连后再进行复制都采用全量同步，成本过高
  • 2.8 ~ 4.0 之间复制采用 psync 命令，这一特性主要添加了 Redis 在断线重连时候可经过 offset 信息使用部分同步
  • 4.0 版本以后也采用 psync，相比于 2.8 版本的 psync 优化了增量复制，这里咱们称为 psync2.0，2.8 版本的 psync 能够称为 psync

主从复制详细流程能够看Redis 主从复制 psync1 和 psync2 的区别

哨兵

Redis Sentinel包含若干个Sentinel节点和Redis数据节点，每一个Sentinel节点会对Redis节点和其他Sentinel节点进行监控，当它发现节点不可达时，会对节点作下线标识。若是被标识的是主节点，它还会和其余Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，它们会选举出一个Sentinel节点来完成自动故障转移的工做，同时会将这个变化实时通知给Redis应用方。整个过程彻底是自动的，不须要人工来介入，因此这套方案颇有效地解决了Redis的高可用问题。

哨兵仅仅时在主从复制之上作了额外的监控处理，所以实际架构并无发生改变。

20191030191140.png

Redis2.8版本的哨兵成为Redis Sentinel 2，对初始Sentinel实现的重写，使用更强大、更简单的预测算法。Redis Sentinel 1是 Redis 2.6版本出厂的，已经弃用。

流程

  1. 哨兵定时监控主节点。
  2. 主节点发生故障时，若个哨兵对主节点发生故障状况达成一致，哨兵会选举出一个哨兵节点做为领导者负责故障转移。
  3. 哨兵从从节点选举出一个新的节点做为主节点。执行slaveof no one命令，将其设置为主节点。
  4. 哨兵将其他节点设置为新的主节点的从节点。执行slaveof masterip masterport

  5. 从节点从主节点全量复制

    redis4.0版本之后能够避免主从切换的全量复制问题。

安装部署

关于哨兵的服务搭建能够查看个人另外一篇博客《Windows版本redis高可用方案探究》,介绍了在windows版本的哨兵搭建，linux下也是大同小异的。

redis服务配置

配置名 配置说明
slaveof 主节点的ip和端口
requirepass 当前节点的密码
masterauth 主节点的密码

当主从设置密码时，必需要设置为同样的，不然可能出现主从切换时，密码发生变化致使从没法链接上主。

哨兵配置

一个完整哨兵配置以下

port 26379 
daemonize yes 
logfile "26379.log" 
dir "/opt/soft/redis/data" 
sentinel myid 5511e27289c117b38f42d2b8edb1d5446a3edf68
sentinel monitor mymaster 127.0.0.1 6379 2 
sentinel down-after-milliseconds master 5000
sentinel failover-timeout master 10000
sentinel auth-pass mymaster test1
sentinel config-epoch mymaster 0 
sentinel leader-epoch mymaster 0 
#发现两个slave节点 
sentinel known-slave mymaster 127.0.0.1 6380 
sentinel known-slave mymaster 127.0.0.1 6381 
#发现两个sentinel节点 
sentinel known-sentinel mymaster 127.0.0.1 26380 282a70ff56c36ed56e8f7ee6ada741 24140d6f53 
sentinel known-sentinel mymaster 127.0.0.1 26381 f714470d30a61a8e39ae031192f1fe ae7eb5b2be 
sentinel current-epoch 0
  1. 主redis配置
    sentinel monitor <master-name> <ip> <port> <quorum>
    • master-name：是主节点的别名
    • ip和port：主节点的ip和端口
    • quorum：表明要断定主节点最终不可达所须要的票数。

    同一个哨兵能够监控多个主节点，只须要将不一样主节点设置为不一样的别名便可。

  2. 哨兵id
    sentinel myid ID
    哨兵首次启动会生成一个40位的惟一id，并会将id写入到配置文件中:
  3. 其余哨兵可选配置
    sentinel <option_name> <master_name> <option_value>
    其余配置结构都是以sentinel开头，后面根据一个配置名 而后是redis别名和配置值
    • down-after-milliseconds：每一个哨兵节点都要按期发送ping命令从而判断Redis和其他哨兵系欸点是否可达，若超过了配置的时间没有恢复，则认为不可达，也被称之为主观下线。 配置格式为sentinel down-after-milliseconds <master-name> <times>,times为超时时间，单位为毫秒
    • parallel-syncs：当哨兵集合对主节点故障达成一致时，哨兵领导者节点会左故障转移操做，选出新的主节点。而从节点则会向新的主节点进行数据复制操做。如有大量的从节点同时复制，对网络带宽会占用必定影响，尤为时Redis4.0之前每次主从切换都须要继续全量数据同步。配置格式为sentinel parallel-syncs <master-name> <nums>，nums为并行同步的数量，配置为1时，从节点则会轮询同步。
    • failover-timeout：当故障转移失败时，过一点时间后再尝试故障转移。配置格式为sentinel failover-timeout <master-name> <times>,times为故障转移失败重试的时间间隔，单位为毫秒。
    • auth-pass：若redis节点配置了密码，则哨兵节点也须要配置redis的密码。须要注意的是，若redis配置密码，则主从Redis以及哨兵都须要配置相同的密码。

    • notification-script：当发生故障转移期间，当一些警告级别的Sentinel事件发生时(例如-sdown：客观下线和、-odown：主观下线)，会触发配置路径的脚本，并转递事件参数，能够经过脚本经过右键、短信或其余方式进行通知预警。配置格式为sentinel notification-script <master-name> <script-path>,script-path为脚本路径。

      客观下线：哨兵每隔1秒对主节点、从节点和其余哨兵节点发送ping命令作心跳检测，当超过down-after-milliseconds未响应，则认为节点不可达，即为主观下线。
      主观下线：当哨兵监控的主节点主观下线时，哨兵节点会经过经过 sentinel is-master-down-by-addr命令向其余哨兵节点确认主节点是否下线。当有quorum个哨兵认为主节点不可达(主观下线)时，则认为主节点客观下线(大部分哨兵都赞成主节点下线，即为客观)，即当主节点客观下线时哨兵领导者就会开始主节点的故障转移。
      * client-reconfig-script：当发生发生故障转移发生主从切换时，能够调用特定脚本执行指定的任务以通知新主节点的位置。sentinel client-reconfig-script <master-name> <script-path>。

  4. 动态修改配置

    哨兵也和redis节点相似，支持动态修改配置，经过sentinel set <master_name> <option_name> <option_value>，修改当前哨兵的指定主节点的哨兵配置。

配置技巧

  1. 多个哨兵节点不该该部署在同一台物理机上。
  2. 至少部署三个且为奇数个的哨兵。由于哨兵领导者至少须要一半加一个哨兵节点投票选举。

集群

Redis Cluster是官方提供的Redis分布式解决方案，在3.0版本正式推出。

原理

Redis集群经过分片的方式来保存数据库中的键值对。通常有Hash分区和顺序分区两种方式分片，Redis使用Hash分区的方式将数据进行平均分布。Redis内部分为0~16383个虚拟槽，将虚拟槽分发给各个Redis节点。集群上线前须要先将全部虚拟槽分发完成。

当一个Redis节点设置了虚拟槽时，它经过消息通知其余的节点本身所处的虚拟槽，这样全部的Redis节点都会更新并保存槽信息。

集群命令执行

当客户端向集群某个Redis发送了一个命令时，该节点会计算要处理的数据键属于哪一个槽，若属于本身的槽则直接执行命令，若属于其余节点，则发送一个MOVED错误执行请求重定向，客户端接受到MOVE重定向请求则会将命令发送到重定向后的节点执行。

从新分片

当Redis集群从新分片时，则将从新分配的虚拟槽的数据转移到目标节点，这个转移操做并不会影响新的命令请求。

ASK错误

当在分片期间执行命令时，可能出现部分数据被迁移到新的节点中，部分数据还在老的节点中未迁移，Redis集群也可以从容的应对该种状况，经过ASK错误执行ASK重定向将客户端转向正在迁移的目标节点，客户端则到新的节点从新执行命令。

集群搭建

  • 准备配置
  • 启动全部Redis节点
  • Redis节点握手，发现集群
  • 分配虚拟槽
  • 集群上线
  • 搭建集群主从

搭建由3个Redis节点组成的集群。将data目录设置为redis根目录，全部的RDB文件,AOP文件，日志和配置都存放到data目录中。

  1. 准备配置

    准备三个配置文件,以redis-{port}.config命名。
    好比7379端口的redis节点配置以下,7380和7381配置相似。
    port 7379 pidfile /var/run/redis_7379.pid logfile "log/redis-7379.txt" dbfilename dump-7379.rdb dir ./data/ appendfilename "appendonly-7379.aof" # 开启集群模式 cluster-enabled yes # 节点超时时间，单位毫秒 cluster-node-timeout 15000 # 集群内部配置文件 cluster-config-file "nodes-7379.conf"

  2. 启动节点

    启动三个redis节点
    shell jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-server data/redis-7379.config jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-server data/redis-7380.config jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-server data/redis-7381.config

    启动完成因为没有集群配置，默认会先建立集群配置nodes-{port}.conf

    jake@Jake-PC:~/tool/demo/redis-cluster/redis/data$ ls
appendonly-7379.aof  appendonly-7381.aof  nodes-7380.conf  redis-7379.config  redis-7380.config  redis-7381.config
appendonly-7380.aof  nodes-7379.conf      nodes-7381.conf  redis-7379.txt     redis-7380.txt     redis-7381.txt

    启动成功后会显示Running in cluster mode表示以集群模式运行

  3. 节点握手

    节点握手是指集群节点经过Gossip协议彼此通讯，达到感知对方的过程。只须要在客户端发起cluster meet {ip} {port}命令。

    127.0.0.1:7379> cluster meet 127.0.0.1 7380
127.0.0.1:7379> cluster meet 127.0.0.1 7381

    握手完毕后能够经过cluster nodes查看当前的集群节点

    127.0.0.1:7379> cluster nodes
ffff2fe734c1ae5be4f66d574484a89f8bd303f3 127.0.0.1:7379@17379 myself,master - 0 1572506163000 0 connected
1d3f7bd0d705ce2926ccc847b4323fcfbfe29f53 127.0.0.1:7381@17381 master - 0 1572506162658 2 connected
36f26b6c6a87202a4a29eba4daf7bf2ff47e2914 127.0.0.1:7380@17380 master - 0 1572506163689 1 connected

    经过 cluster info 查看当前集群状态

    127.0.0.1:7379> cluster info
cluster_state:fail
cluster_slots_assigned:0
cluster_slots_ok:0
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:3
cluster_size:0
cluster_current_epoch:2
cluster_my_epoch:0
cluster_stats_messages_ping_sent:84
cluster_stats_messages_pong_sent:88
cluster_stats_messages_meet_sent:2
cluster_stats_messages_sent:174
cluster_stats_messages_ping_received:88
cluster_stats_messages_pong_received:86
cluster_stats_messages_received:174

    若此时读写数据会返回错误

    127.0.0.1:7379> set hello redis-cluster
(error) CLUSTERDOWN Hash slot not served
127.0.0.1:7379> get hello
(error) CLUSTERDOWN Hash slot not served

    因为前面咱们提到了集群搭建完成后必须先分配虚拟槽。cluster_ slots_ assigned是已分配的虚拟槽，目前是0，所以咱们须要将虚拟槽进行分配。

  4. 分配虚拟槽

    经过命令CLUSTER ADDSLOTS <slot> [slot ...]分配虚拟槽，可是redis原生命令只能一个个分配或者一次分配多个，没办法直接分配一个区间的虚拟槽，所以须要本身修改redis源码支持，或者能够写一个脚本批量分配。

  5. 批量分配槽

    在linux上能够经过shell 脚本，在windows上能够经过powershell，且powershell脚本原生支持m..n生成m到n的一维数组，比较方便。

    我我的对linux上的shell脚本不是很了解，查找了下资料也没有像powershell或者python相似的初始化一维数组的语法。

    目前已经发布的powershell core(powershell 6.0)支持跨平台，下面咱们经过powershell脚本实现批量分配槽。再次以前我先要在linux上安装powershell

    我本机安装的是Ubuntu 18.04，以超级用户身份注册 Microsoft 存储库一次。 注册后，能够经过sudo apt-get upgrade powershell更新PowerShell。

    # Download the Microsoft repository GPG keys
wget -q https://packages.microsoft.com/config/ubuntu/18.04/packages-microsoft-prod.deb

# Register the Microsoft repository GPG keys
sudo dpkg -i packages-microsoft-prod.deb

# Update the list of products
sudo apt-get update

# Enable the "universe" repositories
sudo add-apt-repository universe

# Install PowerShell
sudo apt-get install -y powershell

# Start PowerShell
pwsh

    下载并安装完成后，经过pwsh能够启用powershell,就能够执行powershell脚本了。

    咱们能够经过redis-cli -p port CLUSTER ADDSLOTS <slot> [slot ...]直接执行脚本设置虚拟槽。
    在powershell中分配0到5的一维数组

    PS C:\Users\Dm_ca> 0..5
0
1
2
3
4
5

    经过redis-cli -p 7379 CLUSTER ADDSLOTS (0..5000) 分配0~5000的槽给7379端口

    PS /home/jake/tool/demo/redis-cluster/redis> ./src/redis-cli -p 7379 CLUSTER ADDSLOTS (0..5000)
OK

    一样分配其余的从给其余redis节点

    PS /home/jake/tool/demo/redis-cluster/redis> ./src/redis-cli -p 7380 CLUSTER ADDSLOTS (5001..10000)
OK
PS /home/jake/tool/demo/redis-cluster/redis> ./src/redis-cli -p 7381 CLUSTER ADDSLOTS (10001..16383)
OK

    再次查看redis集群状态,能够看到状态已经从fail变为ok,且cluster_slots_ok分配了16384个槽。

    127.0.0.1:7379> cluster info
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:3
cluster_size:3
cluster_current_epoch:2
cluster_my_epoch:0
cluster_stats_messages_ping_sent:3734
cluster_stats_messages_pong_sent:3677
cluster_stats_messages_meet_sent:2
cluster_stats_messages_sent:7413
cluster_stats_messages_ping_received:3677
cluster_stats_messages_pong_received:3736
cluster_stats_messages_received:7413

    查看集群节点状况,能够看到每一个节点后分配的槽的范围

    127.0.0.1:7379> cluster nodes
ffff2fe734c1ae5be4f66d574484a89f8bd303f3 127.0.0.1:7379@17379 myself,master - 0 1572510104000 0 connected 0-5000       1d3f7bd0d705ce2926ccc847b4323fcfbfe29f53 127.0.0.1:7381@17381 master - 0 1572510106000 2 connected 10001-16383
36f26b6c6a87202a4a29eba4daf7bf2ff47e2914 127.0.0.1:7380@17380 master - 0 1572510106756 1 connected 5001-10000

  6. 搭建集群主从

    目前咱们分配了3个主节点造成另外一个redis集群。可是若一个节点挂了，则整个集群又会变为不可用状态。

    将7379节点关闭，而后查看集群状态

    127.0.0.1:7380> cluster nodes
36f26b6c6a87202a4a29eba4daf7bf2ff47e2914 127.0.0.1:7380@17380 myself,master - 0 1572510227000 1 connected 5001-10000   1d3f7bd0d705ce2926ccc847b4323fcfbfe29f53 127.0.0.1:7381@17381 master - 0 1572510230245 2 connected 10001-16383
ffff2fe734c1ae5be4f66d574484a89f8bd303f3 127.0.0.1:7379@17379 master,fail - 1572510210543 1572510209905 0 disconnected 0-5000

127.0.0.1:7380> cluster info
cluster_state:fail
cluster_slots_assigned:16384
cluster_slots_ok:11383
cluster_slots_pfail:0
cluster_slots_fail:5001
cluster_known_nodes:3
cluster_size:3
cluster_current_epoch:2
cluster_my_epoch:1
...

    所以咱们须要实现集群高可用，为每一个redis主节点加入从节点。

    准备三个配置文件端口分别设置为747九、7480和7481，分别对应737九、7380和7381的从库。启动三个redis节点

    jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-server data/redis-7479.config
jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-server data/redis-7480.config
jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-server data/redis-7481.config
jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-cli -p 7479 cluster meet 127.0.0.1 7379
OK
jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-cli -p 7480 cluster meet 127.0.0.1 7380
OK
jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-cli -p 7481 cluster meet 127.0.0.1 7379
OK

    再次查看集群节点

    jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-cli -p 7481 cluster nodes
36f26b6c6a87202a4a29eba4daf7bf2ff47e2914 127.0.0.1:7380@17380 master - 0 1572514591000 1 connected 5001-10000
1d3f7bd0d705ce2926ccc847b4323fcfbfe29f53 127.0.0.1:7381@17381 master - 0 1572514593720 2 connected 10001-16383
44b31c845115b8e20ad07c50ef1fa035a8f77574 127.0.0.1:7479@17479 master - 0 1572514592000 3 connected
57dd93502af7600b074ed1a021f4f64fbb56c3f4 127.0.0.1:7481@17481 myself,master - 0 1572514591000 5 connected
0e0899d1c692fa3106073880d974acd93c426011 127.0.0.1:7480@17480 master - 0 1572514592713 4 connected
ffff2fe734c1ae5be4f66d574484a89f8bd303f3 127.0.0.1:7379@17379 master - 0 1572514592000 0 connected 0-5000

    经过cluster replicate {nodeId}命令将当前节点设置为集群主节点的从节点。

    jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-cli -p 7479 cluster replicate ffff2fe734c1ae5be4f66d574484a89f8bd303f3
OK
jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-cli -p 7480 cluster replicate 36f26b6c6a87202a4a29eba4daf7bf2ff47e2914
OK
jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-cli -p 7481 cluster replicate 1d3f7bd0d705ce2926ccc847b4323fcfbfe29f53
OK

    再次查看节点状态，能够看到三个新增节点已经变为从库

    jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-cli -p 7481 cluster nodes
36f26b6c6a87202a4a29eba4daf7bf2ff47e2914 127.0.0.1:7380@17380 master - 0 1572514841965 1 connected 5001-10000
1d3f7bd0d705ce2926ccc847b4323fcfbfe29f53 127.0.0.1:7381@17381 master - 0 1572514842981 2 connected 10001-16383
44b31c845115b8e20ad07c50ef1fa035a8f77574 127.0.0.1:7479@17479 slave ffff2fe734c1ae5be4f66d574484a89f8bd303f3 0 1572514842000 3 connected
57dd93502af7600b074ed1a021f4f64fbb56c3f4 127.0.0.1:7481@17481 myself,slave 1d3f7bd0d705ce2926ccc847b4323fcfbfe29f53 0 1572514841000 5 connected
0e0899d1c692fa3106073880d974acd93c426011 127.0.0.1:7480@17480 slave 36f26b6c6a87202a4a29eba4daf7bf2ff47e2914 0 1572514841000 4 connected
ffff2fe734c1ae5be4f66d574484a89f8bd303f3 127.0.0.1:7379@17379 master - 0 1572514840000 0 connected 0-5000

    把7381的主库断开,后7481自动变为主。

    jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-cli -p 7381 shutdown
127.0.0.1:7481> cluster nodes
36f26b6c6a87202a4a29eba4daf7bf2ff47e2914 127.0.0.1:7380@17380 master - 0 1572515223688 1 connected 5001-10000
1d3f7bd0d705ce2926ccc847b4323fcfbfe29f53 127.0.0.1:7381@17381 master,fail - 1572515116020 1572515114203 2 disconnected 44b31c845115b8e20ad07c50ef1fa035a8f77574 127.0.0.1:7479@17479 slave ffff2fe734c1ae5be4f66d574484a89f8bd303f3 0 1572515221634 3 connected
57dd93502af7600b074ed1a021f4f64fbb56c3f4 127.0.0.1:7481@17481 myself,master - 0 1572515220000 6 connected 10001-16383  0e0899d1c692fa3106073880d974acd93c426011 127.0.0.1:7480@17480 slave 36f26b6c6a87202a4a29eba4daf7bf2ff47e2914 0 1572515221000 4 connected
ffff2fe734c1ae5be4f66d574484a89f8bd303f3 127.0.0.1:7379@17379 master - 0 1572515222656 0 connected 0-5000

    最后将7381恢复,7381变为7481的从库

    jake@Jake-PC:~/tool/demo/redis-cluster/redis$ src/redis-cli -p 7381 cluster nodes
57dd93502af7600b074ed1a021f4f64fbb56c3f4 127.0.0.1:7481@17481 master - 0 1572515324842 6 connected 10001-16383
36f26b6c6a87202a4a29eba4daf7bf2ff47e2914 127.0.0.1:7380@17380 master - 0 1572515325852 1 connected 5001-10000
44b31c845115b8e20ad07c50ef1fa035a8f77574 127.0.0.1:7479@17479 slave ffff2fe734c1ae5be4f66d574484a89f8bd303f3 0 1572515322000 3 connected
1d3f7bd0d705ce2926ccc847b4323fcfbfe29f53 127.0.0.1:7381@17381 myself,slave 57dd93502af7600b074ed1a021f4f64fbb56c3f4 0 1572515324000 2 connected
0e0899d1c692fa3106073880d974acd93c426011 127.0.0.1:7480@17480 slave 36f26b6c6a87202a4a29eba4daf7bf2ff47e2914 0 1572515324000 4 connected
ffff2fe734c1ae5be4f66d574484a89f8bd303f3 127.0.0.1:7379@17379 master - 0 1572515323837 0 connected 0-5000

参考文档

  1. redis
  2. redis开发与运维
  3. redis配置文件详解
  4. redis debug命令详解
  5. Redis 主从复制 psync1 和 psync2 的区别
  6. 在 Linux 上安装 PowerShell Core

本文地址：http://www.javashuo.com/article/p-mmskrgis-ku.html 做者博客：杰哥很忙 欢迎转载，请在明显位置给出出处及连接

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程