| 版本 | 内容 | 时间 | | ---- | ---------------------------------------- | ---------------------- | | V1 | 新建 | 2023年04月05日00:30:28 | | V2 | 新增 Jedis 的 JedisSentinelPool 源码分析 | 2023年04月11日22:47:21 | ## Sentinel 基本概念 ### 引入在 Redis 复制机制，一旦主节点因故下线，可以将它其中的一个从节点转换为主节点，让新的主节点继续处理命令请求，这样整个系统就可以继续运作。但是转换的操作需要人为来操作，一般的步骤就是**让一个从节点晋升为主节点，然后还要通知客户端更换主节点地址**。这样操作比较麻烦，Redis Sentinel 可以通过心跳检测的方式监视多个主节点以及它们的从节点，并在某个主节点下线时自动对其进行故障转移操作，整个过程不需要人工介入。 ### 主从复制的作用和问题 Redis 主从复制的作用： 1. 主节点**故障转移**； 2. 可以**提高整个系统的读能力**；但是 Redis 主从复制也带了问题： 1. 一旦主节点发生故障，需要**手动将一个从节点晋升为主节点**，同时**需要修改客户端的主节点的地址**，还需其它的从节点作为新的主节点的从节点； 2. 主节点的**写能力**受到单节点的限制； 3. 主节点的**存储能力**受到单节点的限制；‘ 第一个可以用 Sentinel 解决，后面两个问题可以使用 Redis 集群解决。 ### 手动故障转移的过程 1. 当主节点发生故障后，客户端连接主节点失败，两个从节点与主机连接失败导致复制中断； 2. 如果主节点无法正常启动，需要选出一个从节点，对其执行 slaveof no one / replicaof no one 命令使其称为新的主节点； 3. 原来的从节点成为新的主节点后，更新客户端的主节点信息，重新启动客户端连接； 4. 客户端命令另一个从节点去复制新的主节点； 5. 等待原来的主节点恢复后，让它成为新的主节点的从节点；

因为上面的过程是人工手动介入的，有几个问题： - 判断节点不可达的机制是否合理； - 如果有多个从节点，怎么保证只有一个从节点变成新的主节点，为什么是这个节点成为新的主节点； - 通知客户端连接新的主节点的机制是否足够健壮； Redis Sentinel 的出现就是为了解决这些问题的。 ### Redis Sentinel 高可用 Redis Sentinel 是一个分布式系统，其中包含若干个 Sentinel 节点和 Redis 数据节点，提供的功能如下： - 监控：Sentinel 不断检查 Redis 的主从节点是否按预期工作，还会监控其余的 Sentinel 节点； - 通知：当其中一个受监控的 Redis 节点出现问题，Sentinel 可以通过 API 通知系统管理员或其他计算机程序； - 自动故障转移：如果主节点没有按预期工作，Sentinel 可以启动故障转移过程，将某个从节点提升为主节点，其它的从节点被重新配置为新的主节点的从节点，并且使用 Redis 服务的应用程序被告知连接时要使用的新主节点地址； - 配置提供者：Sentinel 充当客户端服务发现的权威来源：客户端连接到 Sentinel 以询问负责给定服务的当前 Redis 主节点的地址。如果发生故障转移，Sentinels 将报告新地址。 Redis Sentinel 和 Redis 的主从复制只是多了一些 Sentinel 节点，并没有对 Redis 数据节点做特殊处理。 Redis主从复制和Sentinel架构的区别

### Redis Sentinel 故障转移流程以 1 个主节点、2 个从节点、3 个 Sentinel 节点组成的 Redis Sentinel 为例： 1. 主节点出现故障，此时两个从节点与主节点失去连接，主从复制失败； 2. 每个 Sentinel 节点通过定时任务监控发现主节点发生了故障； 3. 多个 Sentinel 节点对主节点的故障达成一致，选举出 Sentinel3 节点作为领导者负责故障转移操作； 4. Sentinel 领导者节点执行了故障转移，整个过程和前面说的手动故障转移是一样的； Redis Sentinel的故障转移流程

## 启动 Sentinel 命令 Sentinel 的当前版本称为 Sentinel 2。它是对初始 Sentinel 实现的重写，使用更强大且更易于预测的算法。Redis Sentinel 的稳定版本从 Redis 2.8 开始发布。随 Redis 2.6 一起提供的 Redis Sentinel 版本 1 已经弃用了。可以使用 ``` redis-sentinel /path/to/sentinel.conf ``` 或者 ``` redis-server /path/to/sentinel.conf --sentinel ``` 在运行 Sentinel 时必须指定配置文件，因为系统将使用此文件来保存当前状态，以便在重新启动时重新加载。如果没有指定配置文件或者配置文件路径不可写，Sentinel 将拒绝启动。 > **关于 Redis Sentinel 节点，它本身就是一个独立的 Redis 节点，只不过它不存储数据，只支持部分命令。** ## Sentinel 配置文件在下载的 Redis 中有一个 sentinel.conf 文件 sentinel.conf 文件内（以 Redis 5.0.14 的配置为例）的主要配置如下（其他配置去看发行版的 sentinel.conf）： ```properties port logfile dir sentinel monitor

sentinel auth-pass sentinel down-after-milliseconds sentinel parallel-syncs sentinel failover-timeout sentinel notification-script

sentinel client-reconfig-script

``` - `port ` 给 Sentinel 指定端口号，默认 26379； - `logfile ` Sentinel 日志文件的名字； - `dir ` Sentinel 的工作目录； - `sentinel monitor

` - 表示要监视的主节点的信息 - mater-name：主节点的名字； - ip：主节点的地址； - redis-port：主节点的端口； - quorum：用于故障发现和判定。有两种含义，一种是**判断 master 不可达需要的 Sentinels 的数量**，例如将quorum 配置为 2，表示至少有 2 个 Sentinel 节点认为主节点不可达，那么这个不可达的判定才是客观的。第二种含义是**在 Sentinel 领导者选举**中，至少要有 `max(quorum, num(sentinels) / 2 + 1)` 个 Sentinel 节点参与选举，才能选出领导者 Sentinel，从而完成故障转移; - `sentinel auth-pass ` - master-name：主节点的名字； - password：配置主节点的密码，需要注意的是访问从节点的密码也是从这里获取的； - `sentinel down-after-milliseconds ` - 每个 Sentinel 节点都要通过定期发送 PING 命令来判断 Redis 数据节点和其他的 Sentinel 节点是否可达，如果超过了该时间且没有有效的回复（要么不回复我们的 PING，要么回复一个错误），则认为该节点不可达。（单位毫秒）； - 这个值设置的越大，也就是对 Sentinel 节点对其他节点不可达的判断条件是宽松的。反之越严格。**宽松的条件有可能带来的问题是节点确实不可达了，那么应用程序等待故障转移的时间越长**，也就意味着应用方故障的时间可能越长。**条件严格虽然可以及时发现故障并完成故障转移，但是也存在一定的误判率**； - 该参数**对 Sentinel 节点、主节点、从节点的故障判定同时有效**； - `sentinel parallel-syncs ` - 当 Sentinel 节点集合对主节点的故障判断达成一致时，选举出来的 Sentinel 领导者节点就会去做故障转移操作，选一个从节点作为新的主节点，其它的从节点需要向新的主节点发起复制请求，**parallel-syncs 配置项就是限制一次故障转移之后，每次向新的主节点发起复制的节点个数。** - 这个值数字越低，完成故障转移过程所需的时间就越长。虽然从节点的复制过程大部分是非阻塞的，但是**假如同时有很多个从节点给主节点发起同步请求时，就会消耗主节点的性能**。一般设置成 1 就好了； - `sentinel failover-timeout ` 故障转移的超时时间，通常有下面几个用处： - 如果某个 Sentinel 已经尝试过针对同一主节点进行故障转移，则重新启动故障转移所需的时间是两倍的故障转移超时时间； - 当 Sentinel 选一个从节点作为新的主节点后，从节点执行 SLAVEOF NO ONE 命令失败（可能是故障了），当这个时间超过 failover-timeout 时间，则认为故障转移失败； - 假如从节点成功晋升为主节点后，当按照 Sentinel 当前配置进行复制的从节点正在错误的主节点上复制时，强制其与正确的、新的主节点进行复制所需的时间正好是故障转移超时时间（从 Sentinel 检测到配置错误的时刻开始计算）； - 进行中的故障转移等待所有从节点被重新配置为新主节点的从节点的最长时间。注意即使超过了这个时间， Sentinel 节点也会最终配置从节点去同步最新的主节点，但不会按照指定的并行同步进度进行； - `sentinel notification-script

` - 在故障转移期间，当一些警告级别的 Sentinel 事件发生（指重要事件，例如 -sdown：客观下线、-odown：主观下线）时，会触发对应路径的脚本，并向脚本发送相应的事件参数。 - `sentinel client-reconfig-script

` - 当主节点由于故障转移而更改时，可以调用一个脚本来执行应用程序特定的任务，以通知客户端配置已更改，主节点已经位于不同的地址； - 当故障转移结束，每个Sentinel节点会将故障转移的结果发送给对应的脚本，具体参数如下 ```

``` - `` is currently always "failover"； - `` is either "leader" or "observer" - Redis 规定脚本的最大执行时间不能超过 60 秒，超过后脚本将被杀掉； > 上面的部分参数可以在运行时配置，后面讲解如何在运行时配置关于 parallel-syncs 配置项的含义如下： parallel-syncs配置项的含义

典型的最小配置文件如下所示： ```properties sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 60000 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster 1 sentinel monitor resque 192.168.1.3 6380 4 sentinel down-after-milliseconds resque 10000 sentinel failover-timeout resque 180000 sentinel parallel-syncs resque 5 ``` 这上面的配置**说明当前 Sentinel 实例监控两个主节点**。 Redis Sentinel集合监控多个主节点

## 设置从节点的优先级用户可以通过 replica-priority 配置项来设置各个从节点的优先级，优先级较高的从节点在 Sentinel 选择新的主节点的时候会被优先选择。 **replica-priority 默认值是 100，这个值越小表示从节点的服务器的优先级越高**。通过这个配置，我们**可以给性能较高的从节点设置较高的优先级来尽可能的保证新的主节点的性能**，因为主节点在下线并重新上线之后也会变成从节点，所以我们**也应该给主节点设置相应的优先级**。 **replica-priority 值为 0 的从几点永远不会被选为主节点**。 ## Sentinel 部署案例（官网的案例，看看就行了） ### 案例的图案的含义按照官网的部署案例分析，需要了解官网的案例的一些图案的含义 box 表示一个独立的机器； ``` +--------------------+ | This is a computer | | or VM that fails | | independently. We | | call it a "box" | +--------------------+ ``` 在框框里面写它里面运行的进程 ``` +-------------------+ | Redis master M1 | | Redis Sentinel S1 | +-------------------+ ``` 不同的 box用线连接起来，表示它们会进行通信： ``` +-------------+ +-------------+ | Sentinel S1 |---------------| Sentinel S2 | +-------------+ +-------------+ ``` 使用双斜线表示网络分区 ``` +-------------+ +-------------+ | Sentinel S1 |------ // ------| Sentinel S2 | +-------------+ +-------------+ ``` 另外： - Masters are called M1, M2, M3, ..., Mn. - Replicas are called R1, R2, R3, ..., Rn (R stands for *replica*). - Sentinels are called S1, S2, S3, ..., Sn. - Clients are called C1, C2, C3, ..., Cn. - 当一个实例因为 Sentinel 的动作而改变角色时，我们将其放在方括号内，因此 [M1] 表示一个实例由于 Sentinel 的干预后现在是主节点； ### Example 1:仅有两个 Sentinel（不建议） ``` +----+ +----+ | M1 |---------| R1 | | S1 | | S2 | +----+ +----+ Configuration: quorum = 1 ``` 在此设置中，如果主 M1 发生故障，R1 将晋升，因为两个 Sentinels 可以就故障达成一致（显然将 quorum 设置为 1）并且还可以授权故障转移，因为大多数是两个。看起来可以正常运行，如果运行 M1 的 box 停止工作，则 S1 也停止工作。在另一个box 的 S2 中运行的 Sentinel 将无法授权故障转移，因此系统将变得不可用 ``` +----+ +------+ | M1 |----//-----| [M1] | | S1 | | S2 | +----+ +------+ ``` 因为某种原因，两个机器断开链接，S2 将同机器的 R1 提升角色为 master，这样集群里，出现了两个 master 同时工作 —— 脑裂出现了。不同的 client 链接到不同的 redis 进行读写，那么两台机器就出现了 redis 数据不一致的现象。因此，请始终在 3 个不同的框中部署至少 3 个Sentinel。这样可以确保有一个多数支持的哨兵群体来监视并协调主从节点之间的切换，从而避免永久性的脑裂情况。 ### Example 2:三个 Sentinel 这是一个非常简单的设置，其优点是易于调整以提高安全性。它基于三个 box，每个 box 都运行一个 Redis 进程和一个 Sentinel 进程。 ``` +----+ | M1 | | S1 | +----+ | +----+ | +----+ | R2 |----+----| R3 | | S2 | | S3 | +----+ +----+ Configuration: quorum = 2 ``` 如果主 M1 发生故障，S2 和 S3 将就故障达成一致，并能够授权故障转移，使客户端能够继续。在每个 Sentinel 设置中，由于 Redis 使用异步复制，因此始终存在丢失某些写入的风险，因为给定的已确认写入可能无法及时同步到新晋升为 master 的从节点。然而，在上面的设置中，由于客户端被旧 master 分区，因此存在更高的风险，如下图所示： ``` +----+ | M1 | | S1 | <- C1 (writes will be lost) +----+ | / / +------+ | +----+ | [M2] |----+----| R3 | | S2 | | S3 | +------+ +----+ ``` 在这种情况下，网络分区隔离了旧的主节点 M1，因此从节点 R2 被提升为主节点。但是，与旧 master 位于同一分区中的客户端（如 C1）可能会继续向旧 master 写入数据。可以在 redis.conf 配置文件中配置下面两个配置项（下面的配置中的 replicas 假如是旧版本则替换成 salve） ``` min-replicas-to-write 1 min-replicas-max-lag 10 ``` 配置这两个选项后，主节点只会在从节点大于等于 min-slaves-to-write 的值，并且这些从节点与主节点最后一次成功通信的时间间隔不超过 min-slaves-max-lag 的时候才会执行写命令。使用此配置，上例中的旧 Redis 主节点 M1 将在 10 秒后变得不可用。当分区恢复后，Sentinel 配置将汇聚到新配置，客户端 C1 将能够获取有效配置并继续使用新的 master。但是这样也有一个问题，如果两个从节点都宕机了，master 将停止接受写入。这是一个需要权衡利弊的点。 ### Example 3:客户端中的 Sentinel 有时我们只有两个 Redis box 可用，一个用于 master，一个用于 replica。示例 2 中的配置在这种情况下不可行，因此我们可以求助于以下内容，将 Sentinels 放置在客户端所在的位置： ``` +----+ +----+ | M1 |----+----| R1 | | | | | | +----+ | +----+ | +------------+------------+ | | | | | | +----+ +----+ +----+ | C1 | | C2 | | C3 | | S1 | | S2 | | S3 | +----+ +----+ +----+ Configuration: quorum = 2 ``` 如果运行 M1 和 S1 的机器发生故障，故障转移将毫无问题地发生，但是很容易看出不同的网络分区会导致不同的行为。例如，如果客户端和 Redis 服务器之间的网络断开连接，则 Sentinel 将无法设置，因为 Redis 主服务器和副本服务器都将不可用。请注意，如果 C3 与 M1 分区（虽然在上述描述的网络中很难发生，但在不同布局或软件层面故障的情况下可能更容易发生），我们将遇到类似于示例 2 中所描述的问题，不同之处在于这里没有办法打破对称性，因为只有一个主节点和从节点，所以当主节点与其从节点断开连接时，主机无法停止接受查询，否则主机将永远无法在副本出现故障时可用。 ### Example 4: 少于 3 个客户端的 Sentinel 客户端如果客户端中的框少于三个（例如三个 Web 服务器），则无法使用示例 3 中描述的设置。在这种情况下，我们需要采用如下混合设置： ``` +----+ +----+ | M1 |----+----| R1 | | S1 | | | S2 | +----+ | +----+ | +------+-----+ | | | | +----+ +----+ | C1 | | C2 | | S3 | | S4 | +----+ +----+ Configuration: quorum = 3 ``` 这类似于示例 3 中的设置，但在这里我们在可用的四个框中运行四个 Sentinel。如果主 M1 变得不可用，其他三个 Sentinels 将执行故障转移。从理论上讲，此设置可以删除运行 C2 和 S4 的框，并将 quorum 设置为 2。但是，如果我们的应用程序层没有高可用性，我们不太可能希望 Redis 端具有高可用性。 ### 部署 Sentinel 注意的地方前面官网的 4 个案例，都是把 Sentinel 节点和 Redis 数据节点或者客户端放在一起。我觉得在实际应用中，应该**将 Sentinel 和被监视的 Redis 服务器放到不同的机器上运行，并且各个 Sentinel 也应该放在不同的机器上运行，这样整个系统才能够更准确、有效的判断出服务器的实际状态**。 - Sentinel 节点应该部署在不同的机器上； - **至少需要 3 个 Sentinel 实例才能进行可靠的部署，尽量奇数个 Sentinel 节点**； - 因为 Redis 使用异步复制，所以 Redis Sentinel 分布式系统**不能保证在故障期间的写入命令同步到从节点，也就是说可能有丢数据的风险**； - 客户端需要支持 Sentinel。例如 Jedis 就支持 Sentinel； - Sentinel、Docker或其他形式的网络地址转换或端口映射应小心混合：Docker 执行端口重新映射时，打破Sentinel 对其他 Sentinel 进程的自动发现和从节点列表； ## 实际部署案例本地部署的 Redis 版本 6.2.6。我要部署一主两从，三个 Sentinel 节点组成的集合。 Redis Sentinel实际部署案例

### 部署 Redis 数据节点配置文件 redis-6379.conf，其它两个改下端口号和文件名就行 ``` port 6379 daemonize yes # 工作目录 dir 的相对路径 logfile "./redis-6379.log" dbfilename dump-6379.rdb dir "../data/redis-sentinel-demo" # 密码 requirepass master123 masterauth master123 ``` 部署： ```shell ./redis-server ../conf/redis-sentinel-demo/redis-6379.conf ./redis-server ../conf/redis-sentinel-demo/redis-6380.conf ./redis-server ../conf/redis-sentinel-demo/redis-6381.conf ``` 在主节点使用 info replication 命令： ``` 127.0.0.1:6379> info replication # Replication role:master connected_slaves:2 slave0:ip=127.0.0.1,port=6380,state=online,offset=98,lag=1 slave1:ip=127.0.0.1,port=6381,state=online,offset=98,lag=1 master_failover_state:no-failover master_replid:1444b8ce1c3f903232525ecd278f0145080b1950 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:98 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:98 ``` 可以看到 master 有两个从节点了 ### 部署 Sentinel 节点配置文件 redis-sentinel-26379.conf，其它两个改下端口号和文件名就行 ``` port 26379 daemonize yes logfile "./sentinel-26379.log" dir "../data/redis-sentinel-demo" sentinel monitor demomaster 127.0.0.1 6379 2 sentinel down-after-milliseconds demomaster 30000 sentinel parallel-syncs demomaster 1 sentinel failover-timeout demomaster 180000 # 设置连接 redis 数据节点的密码 sentinel auth-pass demomaster master123 ``` 部署： ``` ./redis-sentinel ../conf/redis-sentinel-demo/redis-sentinel-26379.conf ./redis-sentinel ../conf/redis-sentinel-demo/redis-sentinel-26380.conf ./redis-sentinel ../conf/redis-sentinel-demo/redis-sentinel-26381.conf ``` 在 26379 端口的 Sentinel 上使用 info sentinel 命令 ``` 127.0.0.1:26379> info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=demomaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3 ``` 可以看到最后一行的信息，监控了名字为 demomaster 的主节点，有 2 个从节点，总共有 3 个 Sentinel 一起监控这个主节点。 ### 日志分析 Redis 主从复制的日志前面的文章分析过了，这里就不再分析了。这里分析端口 26379 的 Sentinel 的启动日志： ``` 75469:X 04 Apr 2023 16:34:21.827 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 75469:X 04 Apr 2023 16:34:21.827 # Redis version=6.2.11, bits=64, commit=720ea82e, modified=0, pid=75469, just started 75469:X 04 Apr 2023 16:34:21.827 # Configuration loaded 75469:X 04 Apr 2023 16:34:21.829 * Increased maximum number of open files to 10032 (it was originally set to 256). 75469:X 04 Apr 2023 16:34:21.829 * monotonic clock: POSIX clock_gettime 75469:X 04 Apr 2023 16:34:21.833 * Running mode=sentinel, port=26379. 75469:X 04 Apr 2023 16:34:21.835 # Sentinel ID is 12a27d10e3f1bdf445ae30dd1f4aba1af78234f6 75469:X 04 Apr 2023 16:34:21.835 # +monitor master demomaster 127.0.0.1 6379 quorum 2 75469:X 04 Apr 2023 16:34:21.838 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ demomaster 127.0.0.1 6379 75469:X 04 Apr 2023 16:34:21.838 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ demomaster 127.0.0.1 6379 75469:X 04 Apr 2023 16:34:23.868 * +sentinel sentinel 2b044ab85b5b93b8553baf65f8a40970ff4fbb9e 127.0.0.1 26381 @ demomaster 127.0.0.1 6379 75469:X 04 Apr 2023 16:34:23.871 * +sentinel sentinel 70668315c96c8bfb74520e4982f8378dcd564dfe 127.0.0.1 26380 @ demomaster 127.0.0.1 6379 ``` 按步骤分析：（1）当端口 26379 的 Sentinel 启动后，会打印下面的日志，表示当前监听一个名字为 demomaster 的主节点。这是一个 Sentinel 事件，如果我们自己订阅在 Pub/Sub 消息部分指定的事件名称，也可以通过 Pub/Sub 接收此类事件。 ``` 75469:X 04 Apr 2023 16:34:21.835 # +monitor master demomaster 127.0.0.1 6379 quorum 2 ``` （2）监听到了主节点有两个从节点； ``` 75469:X 04 Apr 2023 16:34:21.838 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ demomaster 127.0.0.1 6379 75469:X 04 Apr 2023 16:34:21.838 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ demomaster 127.0.0.1 6379 ``` （3）监听到了有另外两个 Sentinel 也在监视同一个主节点； ``` 75469:X 04 Apr 2023 16:34:23.868 * +sentinel sentinel 2b044ab85b5b93b8553baf65f8a40970ff4fbb9e 127.0.0.1 26381 @ demomaster 127.0.0.1 6379 75469:X 04 Apr 2023 16:34:23.871 * +sentinel sentinel 70668315c96c8bfb74520e4982f8378dcd564dfe 127.0.0.1 26380 @ demomaster 127.0.0.1 6379 ``` ## Sentinel API Sentinel 提供 API 以检查其状态、检查受监控的主节点和从节点的健康状况、订阅以接收特定通知以及在运行时更改 Sentinel 配置。 ### Sentinel 管理命令 > 详细的请看官网 https://redis.io/docs/management/sentinel/#sentinel-api - **SENTINEL CKQUORUM ``** ：检查可用的 Sentinel 数量检查 Sentinel 系统中当前可用的 Sentinel 数量是否达到了判断主节点客观下线并实施故障转移所需的数量。该命令应用于监控系统，以检查 Sentinel 部署是否正常； - **SENTINEL FLUSHCONFIG**：强制写入配置文件将 Sentinel 的配置文件重新写入磁盘中。因为 Sentinel 在被监视节点的状态发生改变的时候就会自动重写配置文件，所以这个命令的作用就是在配置文件由于某些原因或者错误丢失时，立即生成一个新的配置文件。此外，当 Sentinel 的配置选项发生变化时，Sentinel 内部也会使用这个命令创建新的配置文件来替代原有的配置文件；只有接收到该命令的 Sentinel 才会重写配置文件，Sentinel 集合中的其它 Sentinel 并不会受到这个命令的影响； - **SENTINEL FAILOVER ``** ：强制执行故障转移接收到这个命令的 Sentinel 强制对指定的主节点实施故障转移，无需选举出一个 Sentinel 进行故障转移； - **SENTINEL GET-MASTER-ADDR-BY-NAME ``**：获取给定主节点的 IP 和端口号；如果 Sentinel 正在对给定的主节点执行故障转移操作，或者原本的主节点已经因为故障转移而被新的主节点替换掉了，那么这个命令将会返回新节点的 IP 和端口号； - **SENTINEL INFO-CACHE** (`>= 3.2`) Return cached [`INFO`](https://redis.io/commands/info) output from masters and replicas. - **SENTINEL IS-MASTER-DOWN-BY-ADDR**：从当前 Sentinel 的角度检查 ip 和 port 指定的主机是否已关闭。此命令主要供内部使用； - **SENTINEL MASTER ``** ：获取被监视的主节点的信息； - **SENTINEL MASTERS**：获取所有被监视的主节点的信息； - **SENTINEL MYID** (`>= 6.2`) Return the ID of the Sentinel instance. - **SENTINEL PENDING-SCRIPTS** This command returns information about pending scripts. - **SENTINEL REPLICAS ``** (`>= 5.0`) 或者 **SENTINEL SLAVES ``** 获取被监视主节点的从节点的信息 - **SENTINEL SENTINELS ``** 获取其他 Sentinel 的相关信息； - **SENTINEL SIMULATE-FAILURE (crash-after-election|crash-after-promotion|help)** (`>= 3.2`)：该命令模拟不同的Sentinel崩溃场景。 - **SENTINEL RESET ``** 重置主节点的状态接受一个 glob 风格的模式作为参数，接收到该命令的 Sentinel 将重置所有与给定模式相匹配的主节点。命令将返回被重置的主节点的数量；接收到该命令的 Sentinel 除了会清理被匹配的主节点的相关信息之外，还会遗忘被匹配主节点目前已有的所有从节点，以及正在监视被匹配主节点的所有其他 Sentinel 节点。在此之后，这个 Sentinel 将会重新搜索正在监视被匹配主节点的其他 Sentinel，以及该节点下的各个从节点，并与它们重新建立连接； #### 关于 Sentinel master 的返回值 | 字段 | 含义 | | ----------------------- | ------------------------------------------------------------ | | name | 服务器的名称 | | ip | 服务器的 ip | | port | 服务器的端口 | | runid | 服务器的运行 ID | | flags | 服务器的角色和状态 | | link-pending-commands | Sentinel 向服务器发送了命令之后，仍然在等待回复的命令数量 | | link-refcount | Redis 实例拥有者数量，用于内部实现 | | last-ping-sent | 距离 Sentinel 最后一次向服务器发送的 PING 之后过的毫秒数 | | last-ok-ping-reply | 服务器最后一次向 Sentinel 返回有效 PING 的回复之后过的毫秒数 | | last-ping-reply | 服务器最后一次向 Sentinel 返回 PING 的回复之后过的毫秒数 | | down-after-milliseconds | Sentinel 的 down-after-milliseconds 配置项的值 | | info-refresh | 服务器最后一次向 Sentinel 返回 INFO 命令回复之后过的毫秒数 | | role-reported | 服务器向 Sentinel 汇报它自身的角色 | | role-reported-time | 服务器最后一次向 Sentinel 汇报它自身的角色之后过的毫秒数 | | config-epoch | 当前 Sentienl 网络所处的配置纪元，用于实现投票机制 | | num-slaves | 主节点下面的从节点数量 | | num-other-sentinels | 其他正在监视这一台服务器的 Sentinel 的数量 | | quorum | 判断服务器下线所需要的 Sentinel 的数量 | | failover-timeout | Sentinel 的 failover-time 配置选项的值 | | parallel-syncs | Sentinel 的 parallel-syncs 配置选项的值 | #### 关于 Sentinel slaves 返回值大部分字段的名称和含义，和 Sentinel master 的返回值一样 | 字段 | 含义 | | --------------------- | ---------------------------- | | master-link-down-time | 主从节点连接断开的时间，毫秒 | | master-link-status | 主从节点的连接状态 | | master-host | 主节点的地址 | | master-port | 主节点的端口号 | | slave-priority | 从节点的优先级 | | slave-repl-offset | 从节点的复制偏移量 | #### 关于 Sentinel sentinel 的返回值大部分字段的名称和含义，和 Sentinel master 的返回值一样 | 字段 | 含义 | | ------------------ | ------------------------------------------------------------ | | last-hello-message | 距离当前 Sentinel 最后一次从这个 Sentinel 收到 HELLO 消息后过的毫秒数 | | voted-leader | Sentinel 网络当前选举出来的 Sentinel 领导者，？表示当前没有领导者 | | voted-leader-epoch | Sentinel 领导者当前所处的配置纪元 | ### 在线修改 Sentinel 配置项在 Redis 2.8.4 之前，Redis Sentinel 只能通过加载配置文件的方式来修改配置项。从 Redis 2.8.4 开始，Sentinel 提供了一组子命令，这些子命令可以在线的修改 Sentinel 对于被监视主节点的配置选项，并把修改后的配置选项保存到配置文件中，整个过程不需要停止 Sentinel，也不需要手动修改配置文件 **如果有多个 Sentinel，则应将更改应用于所有 Sentinel 实例，这意味着更改单个 Sentinel 的配置不会自动将更改传播到网络中的其他 Sentinel。** 以下是用于更新 Sentinel 实例配置的 SENTINEL 子命令列表。 - **SENTINEL MONITOR `` `` `` ``** ：监视给的主节点当想要 Sentinel 监视一个新的主节点，但是又不想重启 Sentin 并手动修改 Sentinel 配置文件时，可以使用这个命令；（这里是添加一个监视主节点，之前的那个主节点还在监视着） - **SENTINEL REMOVE ``** ：取消对给定主节点的监视接收到这个命令的 Sentinel 会停止对给定主节点的监视，并删除 Sentinel 内部以及 Sentinel 配置文件中与给定主节点有关的所有信息，并返回 OK 表示执行成功； - **SENTINEL SET `` [`

Redis Sentinel高可用.

Dylan Kwok

Redis Sentinel高可用