sentinel.conf

完整的 sentinel.conf 配置如下：
# 示例 sentinel.conf
 
# *** 重要事项 ***
#
# 默认情况下，无法从本地主机以外的接口访问 Sentinel，
# 可以使用 "bind" 指令来绑定网络接口列表，
# 或者在这个配置文件中加入 "protected-mode no" 来禁用保护模式。
#
# 在执行此操作之前，请确保通过防火墙或其他方式保护实例免受外界侵害。
#
# 例如，您可以使用以下方法之一：
#
# bind 127.0.0.1 192.168.1.1
#
protected-mode no
 
# port <sentinel-port>
# 运行此哨兵实例的端口
port 26379
 
# 默认情况下，Redis Sentinel 不作为守护进程运行。如果需要，请使用 "yes"。
# 请注意，Redis 会在守护程序化时在 /var/run/redis-sentinel.pid 中写入一个 pid 文件。
daemonize no
 
# 运行守护进程时，Redis Sentinel 默认在 /var/run/redis-sentinel.pid 中写入一个 pid 文件。
# 您可以在此处指定自定义 pid 文件位置。
# pidfile /var/run/redis-sentinel.pid
 
# 指定日志文件名。空字符串可用于强制 Sentinel 将日志输出到标准输出。
# 注意，如果使用标准输出进行日志记录，但使用守护程序运行，则日志将发送到 /dev/null。
logfile ""
 
# sentinel announce-ip <ip>
# sentinel announce-port <port>
#
# 上述两个配置指令在以下环境中非常有用：由于NAT的存在，Sentinel可以从外部通过非本地地址到达。
#
# 当提供 announce-ip 时，Sentinel 将在 HELLO 消息中宣称指定的 IP 地址，而不是像通常那样自动侦测本地地址。
#
# 同样，当提供 announce-port 并且是有效和非零时，Sentinel 将公布指定的 TCP 端口。
#
# 这两个选项不需要一起使用，如果只提供 announce-ip，哨兵将公布指定的 IP 和 "port" 选项所指定的服务器端口。
# 如果只提供 announce-port，哨兵将公布自动检测到的本地 IP 和指定的端口。
#
# 例子:
#
# sentinel announce-ip 1.2.3.4
 
# dir <working-directory>
# 每个长期运行的进程都应该有一个定义明确的工作目录。
# 对于 Redis Sentinel 来说，在启动时 chdir 到 /tmp 是最简单的事情，
# 因为这个过程不会干扰到管理任务，如卸载文件系统。
# dir /tmp
 
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
#
# 告诉哨兵监控这个主站（master），只有在至少 <quorum> 哨兵同意的情况下，
# 才会认为它处于 O_DOWN（客观下线）状态。
#
# 请注意，无论 ODOWN 仲裁是多少，Sentinel 都需要由大多数已知哨兵选举才能启动故障转移，
# 因此无法在少数情况下执行故障转移。
#
# 副本是自动发现的，因此您无需以任何方式指定副本。
# Sentinel 本身将使用其他配置选项重写此配置文件添加副本。
# 另请注意，当副本提升为主站（master）时，配置文件会被重写。
#
# 注意：主站（master）名称不应包含特殊字符或空格。
# 有效的字符集是 A-z 0-9 和三个字符 “.-_”。
sentinel myid 19e18f6594d97e540e075ca27bd73708911ad102
 
# sentinel auth-pass <master-name> <password>
#
# 设置用于向主站和副本进行身份验证的密码。
# 如果 Redis 实例中设置了要监控的密码，则很有用。
#
# 请注意，主站密码也用于副本，所以如果你想用Sentinel监控这些实例，不可能在主站和副本实例中设置不同的密码。
#
# 然而，你可以将没有启用认证的Redis实例与需要认证的Redis实例混在一起（只要所有需要密码的实例的密码设置是相同的），
# 因为AUTH命令在认证关闭的Redis实例中没有任何作用。
#
# 例子:
#
# sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
 
# sentinel down-after-milliseconds <master-name> <milliseconds>
#
# 主站（或任何附属的副本或哨兵）在指定的时间内无法到达（例如，不接受对 PING 的回复，连续的），
# 以便认为它处于 S_DOWN 状态（主观下线）的毫秒数量。
#
# 默认为30秒。
sentinel deny-scripts-reconfig yes
 
# sentinel parallel-syncs <master-name> <numreplicas>
#
# 在故障转移过程中，我们可以重新配置多少个副本来同时指向新的副本。
# 如果你使用复制体来服务查询，请使用一个较低的数字，以避免在执行与主站同步时，
# 所有的复制体将在差不多的时间内无法到达。
 
# Sentinel去监视一个名为 mymaster 的主redis实例，这个主实例的IP地址为本机地址127.0.0.1，端口号为6379，
# 而将这个主实例判断为失效至少需要2个 Sentinel 进程的同意，只要同意 Sentinel 的数量不达标，自动 failover 就不会执行
sentinel monitor mymaster 127.0.0.1 6377 1
 
# 指定了Sentinel认为Redis实例已经失效所需的毫秒数。当实例超过该时间没有返回PING，
# 或者直接返回错误，那么Sentinel将这个实例标记为主观下线。
# 只有一个 Sentinel进程将实例标记为主观下线并不一定会引起实例的自动故障迁移：
# 只有在足够数量的Sentinel都将一个实例标记为主观下线之后，实例才会被标记为客观下线，
# 这时自动故障迁移才会执行
sentinel down-after-milliseconds mymaster 5000
 
sentinel auth-pass mymaster aaaaaa
 
# 指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，
# 在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
sentinel config-epoch mymaster 29
 
# 如果在该时间（ms）内未能完成failover操作，则认为该failover失败
sentinel leader-epoch mymaster 29
 
# sentinel failover-timeout <master-name> <milliseconds>
#
# 指定故障转移的超时时间，单位是毫秒。它在许多方面都被使用：
#
# - 在给定 Sentinel 已针对同一主服务器尝试上一次故障转移后，重新启动故障转移所需的时间是故障转移超时的两倍。
#
# - 根据 Sentinel 当前配置将副本复制到错误的主服务器并强制使用正确的主服务器进行复制所需的
#   时间恰好是故障切换超时（从 Sentinel 检测到错误配置的那一刻起计算）。
#
# - 取消已在进行但未产生任何配置更改的故障切换所需的时间（SLAVEOF NO ONE 尚未被提升的副本确认）。
#
# - 正在进行的故障转移等待所有副本重新配置为新主节点副本的最长时间。
#   但是，即使在这段时间之后，副本仍将由哨兵重新配置，但不会按照指定的确切并行同步进度进行配置。
#
# 默认值为 3 分钟。
 
# 脚本执行
#
# Sentinel 通知脚本和 Sentinel 重新配置脚本用于配置调用以通知系统管理员或在故障转移后重新配置客户端的脚本。
# 脚本使用以下错误处理规则执行：
#
# 如果脚本以 "1 "退出，以后会重新执行（目前设定的最大次数为10次）。
#
# 如果脚本以 "2"（或更高的值）退出，脚本的执行不会被重试。
#
# 如果脚本因为收到一个信号而终止，其行为与退出代码1相同。
#
# 一个脚本的最长运行时间为60秒。在达到这个极限后，脚本会以 SIGKILL 的方式终止，并重新开始执行。
 
# 通知脚本
#
# sentinel notification-script <master-name> <script-path>
#
# 对任何在警告级别产生的哨兵事件（例如 -sdown，-odown，等等）调用指定的通知脚本。
# 这个脚本应该通过电子邮件、短信或任何其他信息传递系统通知系统管理员，被监控的 Redis 系统出现了问题。
#
# 该脚本的调用只有两个参数：第一个是事件类型，第二个是事件描述。
#
# 如果提供了这个选项，该脚本必须存在并可执行，以便哨兵启动。
#
# 例子:
#
# sentinel notification-script mymaster /var/redis/notify.sh
 
# 客户端重新配置脚本
#
# sentinel client-reconfig-script <master-name> <script-path>
#
# 当主站因为故障切换而改变时，可以调用一个脚本，以执行特定的应用任务，通知客户配置已经改变，主站在不同的地址。
#
# 以下是传递给脚本的参数：
#
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
#
# <state> 目前总是 "failover"
# <role> 取值为 "leader" 或 "observer"
#
# 参数 from-ip、from-port、to-ip、to-port 用于传达主站的旧地址和当选副本（现在是主站）的新地址。
#
# 这个脚本应该能够抵御多次调用。
#
# 例子:
#
# sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
 
# 安全性
#
# 默认情况下，SENTINEL SET 将不能在运行时改变 notification-script 和 client-reconfig-script。
# 这就避免了一个微不足道的安全问题，即客户端可以将脚本设置为任何内容，并触发故障转移，以获得程序的执行。
 
# Redis命令重命名
#
# 有时，Redis 服务器将某些需要 Sentinel 正常工作的命令重命名为不可猜测的字符串。
# 在提供 Redis 服务的供应商中，CONFIG 和 SLAVEOF 常常是这样的情况，他们不希望客户在管理控制台之外重新配置实例。
#
# 在这种情况下，可以告诉 Sentinel 使用不同的命令名称，而不是正常的命令。
# 例如，如果主站 "mymaster" 和相关副本的 "CONFIG" 都重命名为 "GUESSME"，我可以使用：
#
# SENTINEL rename-command mymaster CONFIG GUESSME
#
# 设置了这样的配置后，Sentinel每次使用CONFIG时，都会用GUESSME来代替。
# 请注意，实际上不需要尊重命令的大小写，所以在上面的例子中写 "config guessme" 是一样的。
#
# 也可以使用 SENTINEL SET 在运行时执行此配置。
#
# 为了把一个命令设回它的原名（撤销重命名），可以直接把一个命令重命名为它自己：
#
# SENTINEL rename-command mymaster CONFIG CONFIG
# 由 CONFIG REWRITE 产生
说说我的看法
* 必填
全部评论（0）
没有评论
Redis 教程

sentinel.conf
