【Redis源码】集群之哨兵sentinel故障转移 (十二)

最新推荐文章于 2024-09-12 08:00:00 发布
最新推荐文章于 2024-09-12 08:00:00 发布
阅读量922 收藏
点赞数
分类专栏： Redis C++ 文章标签： redis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/byxiaoyuonly/article/details/104549345
版权
C++ 同时被 2 个专栏收录
32 篇文章 6 订阅
订阅专栏
Redis
20 篇文章 3 订阅
订阅专栏

前言：

各位看官大家好，这个主题内容比较长然后接着上一章就拆成了两个部分。那么我们接着上一章内容开始说。上一章中我们说到哨兵定时器sentinelTimer它们作用。sentinelTimer方法中执行哨兵模式中的任务。包括执行定期操作比如PING、分析主服务和从服务的INFO命令、故障转移等等。那么这一章我们就先从sentinelTimer开始说起。

(一) 基本结构

1.1 sentinelTimer 定时程序

在这里插入图片描述
图中为sentinelTimer调用链路，须线部分为调用aeCreateTimeEvent注册serverCron事件。
sentinel.c 中sentinelTimer方法：

void sentinelTimer(void) {
    //检测是否需要开启sentinel TILT模式
    sentinelCheckTiltCondition();
    //对哈希表中的每个服务器实例执行调度任务
    sentinelHandleDictOfRedisInstances(sentinel.masters);
    //执行脚本命令，
    sentinelRunPendingScripts();
    //清理已经执行完脚本的进程，
    sentinelCollectTerminatedScripts();
    //kill执行时间超时的脚本
    sentinelKillTimedoutScripts();
    /*
    * 为了防止多个哨兵同时选举时故意错开定时程序执行的时间。
    */
    server.hz = CONFIG_DEFAULT_HZ + rand() % CONFIG_DEFAULT_HZ;
}

1.2 哨兵结构介绍

基本数据结构

struct sentinelState {
    char myid[CONFIG_RUN_ID_SIZE+1]; /* 哨兵ID */
    uint64_t current_epoch;         /* Current epoch. */
    dict *masters;                  /* 存储哨兵监听服务器的信息 对应一个
                                    sentinelRedisInstance 结构体指针 */
    int tilt;                       /* 判断 TILT 模式 */
    int running_scripts;            /* 当前正在执行的脚本数。 */
    mstime_t tilt_start_time;       /*  TITL 开始时间. */
    mstime_t previous_time;         /* 上次处理程序运行时间. */
    list *scripts_queue;           /* 要执行的用户脚本队列. */
    char *announce_ip;             /* IP 地址（gossip协议握手地址） */
    int announce_port;              /* 端口 （gossip协议端口） */
    unsigned long simfailure_flags; /* 故障模拟状态. */
} sentinel;

每一个哨兵都有一个sentinel结构，里面维护着多个主机连接。每个主机连接信息都维护着一个sentinelRedisInstance，通过这个结构维护着所有主机连接的关系。

sentinelRedisInstance结构信息:
typedef struct sentinelRedisInstance {
    int flags;      /* 记录哨兵类型以及实力当前状态 */
    char *name;     /* 哨兵名称格式为ip:port ，例如"127.0.0.1:26379" */
    char *runid;    /* 哨兵运行ID.*/
    uint64_t config_epoch;  /* 配置纪元，用于故障转移. */
    sentinelAddr *addr; /* 实例地址. */
     
     //...省略
     
    mstime_t s_down_since_time; /* 主观下线标记时间. */
    mstime_t o_down_since_time; /* 客观下线标记时间. */
    mstime_t down_after_period; /* 实例无响应多少毫秒之后才会被判断为主观下线（subjectively down ）,SENTINEL down-after-milliseconds 选项设定的值 */
  
    //。。。省略
    /* Master specific. */
    dict *sentinels;    /* 其他sentinels. */
    dict *slaves;       /* 这个master的slave */
    unsigned int quorum;/* 判断这个实例客观下线（objectively down ）所需的支持投票数量，SENTINEL monitor <master-name> <IP> <port> <quorum> 选项中的quorum 参数 */
    int parallel_syncs; /* 在执行故障转移操作时，可以同时对新的主服务器进行同步的从服务器数量，SENTINEL parallel-syncs <master-name> <number> 选项的值. */
    char *auth_pass;    /* Password to use for AUTH against master & slaves. */

    //。。。省略
    mstime_t failover_start_time;   /* 上次故障转移尝试开始时间. */
    mstime_t failover_timeout;      /* 刷新故障迁移状态的最大时间限制. SENTINEL failover-timeout <master-name> <ms> 选项的值*/
    
    //。。。省略
} sentinelRedisInstance;

在这里插入图片描述

1.3 sentinel建立网络连接

创建与被监听的master网络连接后，sentinel会成功master的客户端，它会向master发送命令。
并从master的响应中获取master的信息。对于每个被监听者的master，sentinel会向创建两个异步的网络连接。
该连接通过sentinelReconnectInstance函数创建，一个链接为commands链接。另外一个链接为Pub / Sub 连接。订阅发布会创建一个__sentinel__:hello的通道。

1.4 sentinel命令集

# 重置名字匹配正则表达式的所有master状态信息，清除之前存储的状态信息和slaves信息。PS：节点只要加入过sentinel，信息就会保存而不会自动清除  
sentinel reset <pattern>

# 用于改变关于master的配置，例如 sentinel set mymaster down-after-milliseconds 1000 ,此命令修改了当节点第一次失去连接到判定其下线所经过的时间
sentinel set <name> <option> <value>

# 告诉sentinel去监听新的master 
sentinel monitor <name> <ip> <port> <quorum>  

# 命令sentinel放弃对某个master的监听
sentinel remove <name>  

# 这个参数设置集群从判断节点挂掉，到执行故障转移操作（即重新选举master节点）的时间
sentinel failover-timeout mymaster 10000

# 获取哨兵监视某个sentinel的信息
sentinel sentinels <master-name>

# 获取sentinel监视的某个master的slaves信息
sentinel slaves <master-name>

# 获取sentinel 监视的某个 master信息
sentinel master <name>

# 获取sentinel监视所有的master信息
sentinel masters

# 询问该sentinel，该 ip，port的master是否为down状态，
# 如果该sentinel为tilt模式，会不理会这个询问，不去判断
# 该master是否为主观下线状态，直接回复正常状态。
sentinel is-master-down-by-addr <ip> <port> <current-epoch> <runid>

# 根据master名字获取到master的ip和port
sentinel get-master-addr-by-name <master-name>

# 将sentinel 状态信息写入到配置文件当中
setinel flushconfig

# 检查可投票同意master on failure的sentinel+1的个数以及相关状态
# （可用的投票个数是否大于master 的quorum，需要quorum个同意master on failure）
setinel ckquorum <name>

(二)发现故障

2.1如何确定故障

提及到确认故障，哨兵中确认故障有两种形式分为对应两种状态SRI_S_DOWN（主观下线）和SRI_O_DOWN（客观下线）。

1） 主观下线

主观下线会涉及到一个方法sentinelCheckSubjectivelyDown，图中会主观下线链路
在这里插入图片描述

void sentinelCheckSubjectivelyDown(sentinelRedisInstance *ri) {
    mstime_t elapsed = 0;

    if (ri->link->act_ping_time)
        elapsed = mstime() - ri->link->act_ping_time;
    else if (ri->link->disconnected)
        elapsed = mstime() - ri->link->last_avail_time;

    /* 检测command 连接是否被关闭 */
    if (ri->link->cc &&
        (mstime() - ri->link->cc_conn_time) >
        SENTINEL_MIN_LINK_RECONNECT_PERIOD &&
        ri->link->act_ping_time != 0 && /* Ther is a pending ping... */
        /* The pending ping is delayed, and we did not received
         * error replies as well. */
        (mstime() - ri->link->act_ping_time) > (ri->down_after_period/2) &&
        (mstime() - ri->link->last_pong_time) > (ri->down_after_period/2))
    {
        instanceLinkCloseConnection(ri->link,ri->link->cc);
    }

    /* 检测pubsub连接是否需要被关闭 
     */
    if (ri->link->pc &&
        (mstime() - ri->link->pc_conn_time) >
         SENTINEL_MIN_LINK_RECONNECT_PERIOD &&
        (mstime() - ri->link->pc_last_activity) > (SENTINEL_PUBLISH_PERIOD*3))
    {
        instanceLinkCloseConnection(ri->link,ri->link->pc);
    }

    /* 更新SRI_S_DOWN状态
     */
    if (elapsed > ri->down_after_period ||
        (ri->flags & SRI_MASTER &&
         ri->role_reported == SRI_SLAVE &&
         mstime() - ri->role_reported_time >
          (ri->down_after_period+SENTINEL_INFO_PERIOD*2)))
    {
        /* Is subjectively down */
        if ((ri->flags & SRI_S_DOWN) == 0) {
            sentinelEvent(LL_WARNING,"+sdown",ri,"%@");
            ri->s_down_since_time = mstime();
            ri->flags |= SRI_S_DOWN;
        }
    } else {
        /* Is subjectively up */
        if (ri->flags & SRI_S_DOWN) {
            sentinelEvent(LL_WARNING,"-sdown",ri,"%@");
            ri->flags &= ~(SRI_S_DOWN|SRI_SCRIPT_KILL_SENT);
        }
    }
}
  1. 检测command 连接是否被关闭；
    2.检测pubsub连接是否需要被关闭 ；
    3.更新SRI_S_DOWN状态状态，更新状态有如下两个规则：
    3.1 超过ri->down_after_period，代表超过响应时间，及ping无响应请求。该时间默认走的时SENTINEL_DEFAULT_DOWN_AFTER宏为30s。
    3.2 SLAVE上报连续时间间隔要大于ri->down_after_period+SENTINEL_INFO_PERIOD2，及（30s + 10s2），如果超过这个时间代表slave长时间连续不到master，所以视为主观下线。

2） 客观下线

说到客观下线是，我们要思考一个问题。当一台master服务已经掉线，并且已经维护自己的状态为SRI_S_DOWN。由于在哨兵集群中，ri->down_after_period值可能不一样。判断master下线的时间间隔可能不一样。所以必须去询问sentinel节点这台master服务是否下线。

void sentinelHandleRedisInstance(sentinelRedisInstance *ri) {
    //。。。省略
    /* Only masters */
    if (ri->flags & SRI_MASTER) {
        sentinelCheckObjectivelyDown(ri);
        if (sentinelStartFailoverIfNeeded(ri))
            sentinelAskMasterStateToOtherSentinels(ri,SENTINEL_ASK_FORCED);
        sentinelFailoverStateMachine(ri);
        sentinelAskMasterStateToOtherSentinels(ri,SENTINEL_NO_FLAGS);  
    }
}

在上面代码中可以看到客观下线只能master中使用。然后看一下sentinelAskMasterStateToOtherSentinels方法，该方法检测master主观下线后去询问其他sentinel。

void sentinelAskMasterStateToOtherSentinels(sentinelRedisInstance *master, int flags) {
    dictIterator *di;
    dictEntry *de;

    di = dictGetIterator(master->sentinels);
    while((de = dictNext(di)) != NULL) {
        sentinelRedisInstance *ri = dictGetVal(de);
        mstime_t elapsed = mstime() - ri->last_master_down_reply_time;
        char port[32];
        int retval;

        /* If the master state from other sentinel is too old, we clear it. */
        if (elapsed > SENTINEL_ASK_PERIOD*5) {
            ri->flags &= ~SRI_MASTER_DOWN;
            sdsfree(ri->leader);
            ri->leader = NULL;
        }

        /* 满足下列情况才可以询问其他哨兵：
         *
         * 1) 主观下线是否在进行
         * 2) Sentinel是否连接
         * 3) 我们没有在哨兵询问期内收到信息，1秒内. */
        if ((master->flags & SRI_S_DOWN) == 0) continue;
        if (ri->link->disconnected) continue;
        if (!(flags & SENTINEL_ASK_FORCED) &&
            mstime() - ri->last_master_down_reply_time < SENTINEL_ASK_PERIOD)
            continue;

        /* Ask */
        ll2string(port,sizeof(port),master->addr->port);
        retval = redisAsyncCommand(ri->link->cc,
                    sentinelReceiveIsMasterDownReply, ri,
                    "SENTINEL is-master-down-by-addr %s %s %llu %s",
                    master->addr->ip, port,
                    sentinel.current_epoch,
                    (master->failover_state > SENTINEL_FAILOVER_STATE_NONE) ?
                    sentinel.myid : "*");
        if (retval == C_OK) ri->link->pending_commands++;
    }
    dictReleaseIterator(di);
}

通过遍历维护的master->sentinels结构向其他sentinel节点发送命令：SENTINEL is-master-down-by-addr
命令格式如下：
SENTINEL is-master-down-by-addr <current_epoch> <leader_id>

命令询问其他sentinel是否同意主服务器已下线。

接受SENTINEL is-master-down-by-addr命令返回状态：
<down_state> <leader_runid> <leader_epoch>

down_state：为1代表主服务器已下线，0表示主服务器未下线。
leader_runid：领头sentinal id。
leader_epoch：领头sentinel当前投票纪元。

(三)故障转移

3.1 故障状态

当某个主节点进行故障转移时，该主节点的的故障转移状态，master->failover_state,依次会经历6个状态：
状态宏：

SENTINEL_FAILOVER_STATE_NONE 0                 /*没有故障转移在进行*/
//以下为经历的6个状态
SENTINEL_FAILOVER_STATE_WAIT_START 1           /* sentinel接手故障转移*/
SENTINEL_FAILOVER_STATE_SELECT_SLAVE 2         /* 选择slave成为master*/
SENTINEL_FAILOVER_STATE_SEND_SLAVEOF_NOONE 3   /* 发送slaveof no one给新master */
SENTINEL_FAILOVER_STATE_WAIT_PROMOTION 4       /* 等待新master升级完成，超时终止故障转移*/
SENTINEL_FAILOVER_STATE_RECONF_SLAVES 5        /* 新master升级完成后，让slaves复制新master */
SENTINEL_FAILOVER_STATE_UPDATE_CONFIG 6        /* 监视新master */

3.2 状态机

void sentinelFailoverStateMachine(sentinelRedisInstance *ri) {
    serverAssert(ri->flags & SRI_MASTER);

    if (!(ri->flags & SRI_FAILOVER_IN_PROGRESS)) return;

    switch(ri->failover_state) {
        case SENTINEL_FAILOVER_STATE_WAIT_START:
            sentinelFailoverWaitStart(ri);         //sentinel接手故障转移
            break;
        case SENTINEL_FAILOVER_STATE_SELECT_SLAVE:
            sentinelFailoverSelectSlave(ri);      //选择slave成为master
            break;
        case SENTINEL_FAILOVER_STATE_SEND_SLAVEOF_NOONE:
            sentinelFailoverSendSlaveOfNoOne(ri); //发送slaveof no one给新master
            break;
        case SENTINEL_FAILOVER_STATE_WAIT_PROMOTION:
            sentinelFailoverWaitPromotion(ri);    //等待新master升级完成，超时终止故障转移
            break;
        case SENTINEL_FAILOVER_STATE_RECONF_SLAVES:
            sentinelFailoverReconfNextSlave(ri); //新master升级完成后，让slaves复制新master
            break;
    }
}

状态机变化过程：
在这里插入图片描述

总结

1）一个哨兵结构中可以维护多个主机，包括master，slave，sentinel。
2）确定故障分为：主观下线和客观下线两种。
3）主观下线：为一段时间内ping返回无效，探测所有节点都是一致的，则为主观下线。主观下线的时间是可以配置的，以master配置维度为准。
4）客观下线：客观下线只针对于master节点，且需要master为主观下线，并通过其他sentinel节点发送SENTINEL is-master-down-by-addr询问其他节点master下线问题，达成共识的一个状态。
5) 哨兵会创建两个链接一个commands链接，一个订阅发布链接。

c-rain
关注
专栏目录
Redis学习笔记(九)：哨兵模式-监控、通知、故障转移
shiang_yan的博客
06-18 1296
简介 哨兵(sentinel)是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时，通过投票机制选择新的master并将所有slave连接到新的master 哨兵的作用： 监控：不断地检查master和slave是否正常运行，master存活检测、master与slave运行情况检测 通知(提醒)：当被监控的服务器出现问题时，向其它(哨兵间、客户端)发送通知 自动故障转移：断开master与slave连接，选取一个slave作为master，将其它slave连接到新的master，并告知
Redis高可用方案：sentinel（哨兵模式）和集群
2401_84004024的博客
04-30 804
每年转战互联网行业的人很多，说白了也是冲着高薪去的，不管你是即将步入这个行业还是想转行，学习是必不可少的。作为一个Java开发，学习成了日常生活的一部分，不学习你就会被这个行业淘汰，这也是这个行业残酷的现实。如果你对Java感兴趣，想要转行改变自己，那就要趁着机遇行动起来。或许，这份限量版的Java零基础宝典能够对你有所帮助。im 7002/redis.conf #修改端口为7002将配置文件目录拷贝到192.168.126.161上修改配置文件（端口号和ip）
Redis哨兵模式故障转移
yywuzc123的博客
06-16 952
故障转移步骤 哨兵选举领导者 选领导者的原因：只有一个sentinel节点完成故障转移 选举sentinel领导者 使用raft算法(https://raft.github.io)，大致思路： 1、每个做主观下线的sentinel节点像其他sentinel节点发送命令，要求将自己设置为领导者 2、接收到的sentinel可以同意或者拒绝 3、如果该sentinel节点发现自己的票数已经超过半数并且超过了quorum(多数派),那么它将成为领导者 4、如果此过程选举出了多个领导者，那么将等待一段时重新进行选举
java.lang.IllegalStateException: Error processing condition on org.springframework.boot.autoconfigur
最新发布
小星袁
09-12 1730
在运行代码的过程中，报出了java.lang.IllegalStateException: Error processing condition on org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration.redisTemplate的错误、以及java.lang.IllegalStateException: Error processing condition on org.springframework.boot.
Redis主从哨兵架构的故障转移
IT深耕十余载，大道之简
05-27 505
Redis主从哨兵架构的故障转移是一个确保系统高可用性的重要过程。
聊聊Redis哨兵选举与故障转移的实现
Hi，我是sharkchili，CSDN Java领域博客专家，开源项目JavaGuide维护人员，我想写一些有意思的东西，希望对你有帮助。
07-16 990
上一篇文章我们将哨兵主观下线的核心流程都分析完成，这一篇我们将接着之前的思路，将哨兵获取客观下线结果并结合raft协议完成哨兵leader选举完成故障转移的流程分析完成，希望对你有帮助。因为近期收到很多读者的私信，所以也专门创建了一个交流群，感兴趣的读者可以通过上方的公众号获取笔者的联系方式完成好友添加，点击备注。因为近期收到很多读者的私信，所以也专门创建了一个交流群，感兴趣的读者可以通过上方的公众号获取笔者的联系方式完成好友添加，点击备注。下线的看法，如果累加到的哨兵对于下线的看法大于或者等于我们配置。
redis学习(肆) -- sentinel哨兵
clouderpig的博客
07-17 1184
一、定义 上一次我们讲过redis的主从复制存在一个很大的问题，就是主节点遇到故障只能手动恢复，而redis sentinel正是为了解决这一问题出现的。sentinel的核心功能就是通过对主从节点的监控实现及时发现主节点故障并自动故障转移的功能。sentinel实际上是特殊的redis节点，只是不存储数据。启动方式类似redis：./redis-sentinel sentinel.conf...
[redis 源码走读] - sentinel 哨兵 - 故障转移
smart_an的专栏
06-01 841
作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！前面几章已经讲了：redis 集群各个角色之间的通信，主客观下线，投票选举；在选举中胜出的哨兵 leader，由它来完成 redis 集群的故障转移：。
redis集群之哨兵模式sentinel
longlong6682的博客
02-29 345
一. 实验说明 1、环境说明 前提：本试验环境已经提前安装了docker和docker-compose 说明：本次部署是单机伪集群，想要部署真正的集群，需要将秒个主件拆分到各个机器上去部署，只修改ip地址 2、redis三种集群 1. 主从（主从同步原理） 2. sentinel（哨兵模式） 3. codis 详细内容请参考：https://www.cnblogs.com/xiaonq/p...
Redis简介三（哨兵sentinel,故障转移）
Ralap的博客
04-04 792
sentinel启动哨兵自动发现 Sentinel 和从服务器定期任务名词解释故障转移Sentinel leader 选举新的主服务器：参考文档 在上一章节，我们已经简单的聊过了哨兵以及它的功能，这一章我们详细介绍它的运行机制 启动哨兵 跟上一章一样，演示一个小demo，现在是在床上换了个笔记本，屏幕比较小，图片看不清楚的自己放大。 首先我们启动两个Redis实例6379和6380，同时将63...
redis集群之Sentinel(哨兵)
Super body的博客
02-11 562
文章目录redis集群Sentinel(哨兵)配置master-slave编辑配置文件sentinel.conf启动哨兵停止Redis Master测试故障转移 redis集群 上一个步骤的主从架构无法实现master和slave角色的自动切换，即当master出现redis服务异常、主机断电、磁盘损坏等问题导致master无法使用，而redis高可用无法实现自故障转移(将slave提升为mast...
Redisson（一）介绍与常见API
w_t_y_y的博客
08-21 2008
Redisson自定义序列化_redisson 序列化_yzh_1346983557的博客-CSDN博客
Sentinel哨兵监控详细解析，写得太好了.
12-09 1280
什么是Sentinel哨兵监控 前面搭建了主从复制，也了解到当主服务器宕机后，需要手动的把一台从服务器切换成主服务器。是不是感觉很麻烦？没错这样的话不仅费人工，还会造成一段时间内服务不可用，这显然是不可行的。所有，Redis就有了哨兵模式。Redis提供了哨兵命令，它是一个独立的进程哨兵通过发送命令给多个节点，并让Redis的服务器响应，从而来监控Redis实例的运行情况。当哨兵检查到主节点宕机了，会自动将从节点切换成主节点，并通知其他的从服务器修改配置文件切换主机。 Sentinel有三大任务 任.
Redis学习手册18—Sentinel
程序员客栈
06-16 941
故障转移 因为Redis支持主从复制，并且主从服务器的数据完全一致。因此，当主服务器因故障下线时，将它的其中一台从服务器转换为主服务器，并使用新的主服务器继续处理命令请求，这样整个系统就可以继续运行，不比仅因为主服务器下线而停机。这种使用正常服务器替换下线服务器以维持系统正常运转的操作，一般被称为故障转移（failover）。 手动故障转移 因为Redis支持主从复制特性，所以我们同样可以对下线的Redis主服务器实施故障转移，假设现在有一个主服务器 127.0.0.1:6379（简称 6379），它有两个
全面剖析Redis Cluster原理和应用
william的博客
04-11 347
全面剖析Redis Cluster原理和应用 1.Redis Cluster总览 1.1 设计原则和初衷 在官方文档Cluster Spec中，作者详细介绍了Redis集群为什么要设计成现在的样子。最核心的目标有三个： 性能：这是Redis赖以生存的看家本领，增加集群功能后当然不能对性能产生太大影响，所以Redis采取了P2P而非Proxy方式、异步复制、客户端重定向等设计...
redis4.0.1主从配置及Sentinel配置自动Failover
eagle89的专栏
08-18 8242
一、单机版 1、前提条件 yum install gcc-c++   2、安装redis tar -xf redis-4.0.1.tar.gz cd redis-xxxx make make install 3、测试Redis是否安装成功 后台启动redis     ./redis-server redis.conf   注：分别在每台机器上安装以上过程
记一次官方redis cluster集群和sentinel哨兵模式结合下的节点故障切换不了的排查过程
APPLEHU09的博客
03-29 2075
环境： redis cluster集群分别在三个ip上部署了9个节点（7001-7009），三个主节点六个从节点；节点中主从数据同步确保正常；再在三个ip上部署了sentinel26379，sentinel26380，sentinel26381三个哨兵； 客户端连接： 使用ServiceStack组件 + .NET CORE 6.0；使用的哨兵+卡槽计算方式创建连接（ServiceStack官网信息说不支持redis cluster集群分区模式连接，要用redis sentinel哨兵模式创建连接，如
Redis集群之Sentinel（哨兵）
Kason_iWiki
01-09 316
1. redis-sentinel（哨兵） 1、监控 2、自动选主，切换（6381 slaveof no one） 3、2号从库（6382）指向新主库（6381） 4、应用透明 5、自动处理故障节点 sentinel搭建过程 1.创建相关目录 mkdir /data/26380 cd /data/26380 2.编写配置文件 vim sentinel.conf port 26380 dir...
Redis3.0 配置文件说明
weixin_33885676的博客
08-22 755
2019独角兽企业重金招聘Python工程师标准>>> ...
Sentinel+Redis安装配置及小窍门
scott_bing的专栏
01-15 567
Sentinel+Redis安装配置及小窍门
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值