redis入门(二)
2019-11-18杂谈搜奇网33°c
A+ A-目次
- redis入门(二)
- 目次
- 媒介
- 耐久化
- RDB
- AOF
- 耐久化文件加载
- 高可用
- 尖兵
- 流程
- 装置布置
- 设置技能
- 集群
- 道理
- 集群搭建
- 参考文档
redis入门(二)
目次
redis入门(一)
redis入门(二)
redis入门(三)
媒介
在redis入门(一)简朴引见了redis的汗青和装置布置,以及基础的数据构造和api,本节解说redis耐久化、高可用、redis集群和散布式相干的学问。
耐久化
redis作为内存数据库,数据悉数存储到内存中。然则若涌现断电等缘由会构成数据丧失。redis内置了2种耐久化的体式格局,离别为RDB耐久化和AOF耐久化。
RDB
RDB耐久化是把当前历程数据生成快照保留到硬盘的历程,换句话来说是将当前redis内存中的数据悉数保留到硬盘。触发RDB耐久化历程分为手动触发和自动触发。
手动触发
可以经由过程
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
自动触发
- 运用save相干设置,如
save m n
。示意m秒内数据集存在n次修正时,自动触发bgsave。 - 若节点实行全量复制操纵时,主节点自动实行
bgsave
生成RDB文件并发给从节点。 实行
debug reload
敕令从新加载redis时,也会触发save操纵。redis debug敕令供应了几个异常有用的debug功用
默许状况下实行shutdown敕令时,假如没有开启AOF耐久化功用且设置过rdb自动保留战略则会自动实行bgsave。
- 运用save相干设置,如
道理
- 实行bgsave敕令,Redis父历程推断当前是不是存在正在实行的子历程,如RDB/AOF子历程,假如存在bgsave敕令直接返回。
父历程实行fork操纵建立子历程,fork操纵历程当中父历程会壅塞,经由过程
info stats
敕令检察latest_fork_usec选项,可以猎取近来一个fork操纵的耗时,单元为微秒。127.0.0.1:26379> info stats # Stats total_connections_received:1 ... latest_fork_usec:5391
- 父历程fork完成后,
bgsave
敕令返回Background saving started
信息并不再壅塞父历程,可以继承相应其他敕令。 子历程建立RDB文件,依据父历程内存生成暂时快照文件,完成后对原有文件举行原子替代。实行
lastsave
敕令可以猎取末了一次生成RDB的时刻,对应info统计的rdb_last_save_time
选项。历程发送信号给父历程示意完成,父历程更新统计信息,细致见info Persistence
下的rdb_*相干选项。O127.0.0.1:26379> lastsave (integer) 1572423635
经常使用设置
节点名 | 申明 |
---|---|
save | m秒有n次修正自动保留 |
dbfilename | RDB保留文件名,会保留到dir设置的途径种 |
经由过程
config set dbfilename
可以动态修正RDB保留文件名,下次运转RDB保留时会保留到新的文件名中。
履历
- RDB文件紧缩保留可以大幅度下降文件大小
- 若磁盘破坏可以经由过程
config set
敕令动态修正redis根途径和RDB文件途径。 - RDB文件加载速率远快于AOF文件加载速率
- RDB体式格局保留没办法做到及时保留,因而不能用于存储不能丧失的数据。
- RDB体式格局保留每次都邑将内存中的数据全量举行保留,因而不适用于内存数据较大且需要频仍保留的场景。
AOF
AOF(appendonlyfile)耐久化:以自力日记的体式格局纪录每次写敕令,重启时再从新实行AOF文件中的敕令到达恢复数据的目的。AOF保留的不是数据,而是每次实行的敕令,因而AOF文件会比RDB文件大的多。
道理
- 一切的写入敕令会追加到aof_buf(缓冲区)中。
AOF缓冲区依据对应的战略向硬盘做缓冲区文件操纵。
AOF有三种缓冲区文件同步战略
- 跟着AOF文件越来越大,需要按期对AOF文件举行重写,到达紧缩的目的。
当Redis效劳器重启时,可以加载AOF文件举行数据恢复。
缓冲区同步战略
- 及时同步
经由过程设置appendfsync always
,敕令写入缓存后,挪用体系fsync同步文件操纵。 - 每秒同步
经由过程设置appendfsync ecerysec
,敕令写入缓存后,挪用体系write操纵。一个特地的线程每秒挪用一次fsync同步文件操纵。 - 操纵体系决议什么时刻同步
经由过程设置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
参数肯定自动触发机遇。
- 实行AOF重写要求。假如当前历程正在实行AOF重写假如当前历程正在实行bgsave操纵,重写敕令耽误到bgsave完成今后再实行。
- 父历程实行fork建立子历程,开支等同于bgsave历程。
- 主历程fork操纵完成后,继承相应其他敕令。一切修正敕令依旧写入AOF缓冲区并依据appendfsync战略同步到硬盘,保证原有AOF机制正确性。
由于fork操纵运用写时复制手艺,子历程只能同享fork操纵时的内存数据。 - 子历程依据内存快照,根据敕令兼并划定规矩写入到新的AOF文件。每次批量写入硬盘数据量由设置
aof-rewrite-incremental-fsync
掌握,默许为32MB,防备单次刷盘数据过量构成硬盘壅塞。 - 新AOF文件写入完成后,子历程发送信号给父历程。
- 由于父历程依旧相应敕令,Redis运用“AOF重写缓冲区”保留这部份新数据,防备新AOF文件生成时期丧失这部份数据。
- 父历程更新统计信息,细致见
info persistence
下的aof_*相干统计。
耐久化文件加载
- AOF耐久化开启且存在AOF文件时,优先加载AOF文件
- AOF封闭或许AOF文件不存在时,加载RDB文件
- 加载AOF/RDB文件胜利后,Redis启动胜利。
- 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版本出厂的,已弃用。
流程
- 尖兵定时监控主节点。
- 主节点发作毛病时,若个尖兵对主节点发作毛病状况杀青一致,尖兵会选举出一个尖兵节点作为领导者担任毛病转移。
- 尖兵从从节点选举出一个新的节点作为主节点。实行
slaveof no one
敕令,将其设置为主节点。 - 尖兵将其他节点设置为新的主节点的从节点。实行
slaveof masterip masterport
从节点从主节点全量复制
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
- 主redis设置
sentinel monitor <master-name> <ip> <port> <quorum>
- master-name:是主节点的别号
- ip和port:主节点的ip和端口
- quorum:代表要剖断主节点终究不可达所需要的票数。
统一个尖兵可以监控多个主节点,只需要将差别主节点设置为差别的别号即可。
- 尖兵id
sentinel myid ID
尖兵初次启动会生成一个40位的唯一id,并会将id写入到设置文件中: - 其他尖兵可选设置
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>
。
- down-after-milliseconds:每一个尖兵节点都要按期发送
动态修正设置
尖兵也和redis节点相似,支撑动态修正设置,经由过程
sentinel set <master_name> <option_name> <option_value>
,修正当前尖兵的指定主节点的尖兵设置。
设置技能
- 多个尖兵节点不应该布置在统一台物理机上。
- 最少布置三个且为奇数个的尖兵。由于尖兵领导者最少需要一半加一个尖兵节点投票选举。
集群
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目次中。
预备设置
预备三个设置文件,以
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"
启动节点
启动三个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
示意以集群形式运转节点握手
节点握手是指集群节点经由过程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,因而我们需要将假造槽举行分派。分派假造槽
经由过程敕令
CLUSTER ADDSLOTS <slot> [slot ...]
分派假造槽,然则redis原生敕令只能一个个分派或许一次分派多个,没办法直接分派一个区间的假造槽,因而需要本身修正redis源码支撑,或许可以写一个剧本批量分派。批量分派槽
在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
搭建集群主从
现在我们分派了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
参考文档
- redis
- redis开辟与运维
- redis设置文件详解
- redis debug敕令详解
- Redis 主从复制 psync1 和 psync2 的区分
- 在 Linux 上装置 PowerShell Core
本文地点:https://www.cnblogs.com/Jack-Blog/p/11781421.html
作者博客:杰哥很忙
迎接转载,请在显著位置给出出处及链接