hi,你好!欢迎访问本站!登录
本站由网站地图腾讯云宝塔系统阿里云强势驱动
当前位置:首页 - 教程 - 杂谈 - 正文 君子好学,自强不息!

redis入门(二)

2019-11-18杂谈搜奇网22°c
A+ A-

目次

  • redis入门(二)
    • 目次
    • 媒介
    • 耐久化
      • RDB
      • AOF
      • 耐久化文件加载
    • 高可用
    • 尖兵
      • 流程
      • 装置布置
      • 设置技能
    • 集群
      • 道理
      • 集群搭建
    • 参考文档

redis入门(二)

目次

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

媒介

在redis入门(一)简朴引见了redis的汗青和装置布置,以及基础的数据构造和api,本节解说redis耐久化、高可用、redis集群和散布式相干的学问。

耐久化

redis作为内存数据库,数据悉数存储到内存中。然则若涌现断电等缘由会构成数据丧失。redis内置了2种耐久化的体式格局,离别为RDB耐久化和AOF耐久化。

RDB

RDB耐久化是把当前历程数据生成快照保留到硬盘的历程,换句话来说是将当前redis内存中的数据悉数保留到硬盘。触发RDB耐久化历程分为手动触发和自动触发。

  1. 手动触发

    可以经由过程savebgsave两个敕令手动实行保留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。

道理

  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文件大的多。

道理

  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-sizeauto-aof-rewrite-percentage参数肯定自动触发机遇。

  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_*相干统计。

耐久化文件加载

  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的高可用题目。

尖兵仅仅时在主从复制之上做了分外的监控处置惩罚,因而现实架构并没有发作转变。

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主节点到场从节点。

    预备三个设置文件端口离别设置为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

本文地点:https://www.cnblogs.com/Jack-Blog/p/11781421.html
作者博客:杰哥很忙
迎接转载,请在显著位置给出出处及链接

  选择打赏方式
微信赞助

打赏

QQ钱包

打赏

支付宝赞助

打赏

  移步手机端
redis入门(二)

1、打开你手机的二维码扫描APP
2、扫描左则的二维码
3、点击扫描获得的网址
4、可以在手机端阅读此文章
未定义标签

本文来源:搜奇网

本文地址:https://www.sou7.cn/282042.html

关注我们:微信搜索“搜奇网”添加我为好友

版权声明: 本文仅代表作者个人观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。请记住本站网址https://www.sou7.cn/搜奇网。

发表评论

选填

必填

必填

选填

请拖动滑块解锁
>>