• redis入门(二)

    目录

    redis入门(二)

    目录

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

    前言

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

    持久化

    redis作为内存数据库，数据全部存储到内存中。但是若出现断电等原因会造成数据丢失。redis内置了2种持久化的方式，分别为RDB持久化和AOF持久化。

    RDB

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

    1. 手动触发

      可以通过save和bgsave两个命令手动执行保存RDB快照。
      save命令：会阻塞当前redis主进程，直到RDB保存完成，save命令已经弃用，不建议生产环境使用。
      bgsave命令：redis进程会执行fork操作创建进程执行保存RDB快照。只有在fork子进程才会短时间阻塞。建议大家都是用bgsave命令保存RDB快照。目前redis内部所有RDB操作都使用bgsave命令

      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操作。

        redis debug命令提供了几个非常实用的debug功能

      • 默认情况下执行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节点

      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:UsersDm_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主节点加入从节点。

      准备三个配置文件端口分别设置为7479、7480和7481，分别对应7379、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

    20191127212134.png
    微信扫一扫二维码关注订阅号杰哥技术分享
    本文地址：https://www.cnblogs.com/Jack-Blog/p/11781421.html
    作者博客：杰哥很忙
    欢迎转载，请在明显位置给出出处及链接
  • 相关阅读:
    C#开发模式——单例模式
    C#开发模式——单例模式
    Memcached的基础梳理
    Memcached的基础梳理
    Memcached的基础梳理
    Memcached的基础梳理
    13条只有程序员才能懂的内涵段子
    13条只有程序员才能懂的内涵段子
    网页性能优化
    webpack中使用ECharts
  • 原文地址：https://www.cnblogs.com/Jack-Blog/p/11781421.html
Copyright © 2020-2023  润新知