基本的な
センチネル原理は複雑ではありません。
- Nスタートセンチネルたとえば、これらのセンチネルは、あなたがRedisのマスター/スレーブを指定するインスタンスを監視するには
- ハングRedisのマスターノードは、ピングを検出することによってセンチネル例では、ノードは、SDOWN状態に入るような場合を見つけるために失敗した場合、すなわちセンチネルとしては、(主観的に)Redisの考えマスタノードハング主観的検出しました。
- センチネルインスタンスがマスターハングした場合の際に一定数(定足数パラメータセット)、ODOWN状態にノードの遷移、すなわち、客観的(客観的に)状態を掛けます。
- センチネルインスタンス間の次回起動選挙、センチネル例を選択し、フェールオーバープロセスを開始する。ので、新しいデータの他のスレーブマスタコピーすること、およびパブ/サブ公開イベントを通して、新しいマスタとしてスレーブから選択します。
- Redisののいずれかのセンチネルインスタンスおよびモニターからユーザーのクライアントを取得設定情報(オプション)センチネルイベントを発行:などSDOWN、ODOWNおよびフェイルオーバー、および適切なマスタースレーブスイッチを作り、センチネルは、サービス発見の役割を果たしました。
- センティネルのリーダー選挙は使用 ラフト契約を。
通常の状況下での概略:
ときM1ハング:
ノード2がマスターに昇格して、Sentinelは新しいマスターを使用するために、クライアントと奴隷を知らせます。
実験環境を構築
- Redisの2、それぞれ6379および6380でのマスタからの1は、ポートをリスニング
1
2
|
|
redis-cli -p 6380
でも、6380のポートRedisのは、実行がslaveof 127.0.0.1 6379
6379個のスレーブに設定します。- 启动三个 sentinel 实例,分别监听在 5000 - 5002 端口,并且监控 6379 的 redis master,首先是配置文件
s1.conf:
1
2
3
4
|
|
其他两个配置文件是 s2.conf 和 s3.conf 只是将 port 5000
修改为 5001 和 5002,就不再重复。需要确保配置文件是可写的,因为 Sentinel 会往配置文件里添加很多信息作为状态持久化,这是为了重启等情况下可以正确地恢复 sentinel 的状态。
启动:
1
2
3
|
|
配置说明:
- port ,指定 sentinel 启动后监听的端口,sentinel 实例之间需要通过此端口通讯。
sentinel monitor [name] [ip] [port] [quorum]
,最重要的配置,指定要监控的 redis master 的 IP 和端口,给这个监控命名 name。Quorum 指定至少多少个 sentinel 实例对 redis master 挂掉的情况达成一致,只有达到这个数字后,Sentinel 才会去开始一次 failover 过程。- down-after-milliseconds,设定 Sentinel 发现一个 redis 没有响应 ping 到 Sentinel 认为该 redis 实例不可访问的时间。
- failover-timeout,Sentinel 实例投票对于同一个 master 发起 failover 过程的间隔时间,防止同时开始多次 failover。
Sentinel 启动后会输出类似的日志:
1
2
|
|
表示开始监控 mymaster 集群,并输出集群的基本信息。
以及 Sentinel 之间的感知日志,比如 s3 节点的输出:
1
2
|
|
查看信息
可以用 redis-cli 连上 sentinel 实例,查看信息:
1
2
3
4
5
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
|
sentinel master [name]
用于查看监控的某个 redis master 信息,包括配置和状态等,其他命令还包括:
sentinel masters
查看所有监控的 master 信息。sentinel slaves [name]
查看监控的某个 redis 集群的所有 slave 节点信息。sentinel sentinels [name]
查看所有 sentinel 实例信息。
更重要的一个命令是根据名称来查询 redis 信息,客户端会用到:
1
2
3
|
|
测试 Failover
我们让 6379 的 master 主动休眠 30 秒来观察 failover 过程:
1
|
|
我们可以看到每个 sentinel 进程都监控到 master 挂掉,从 sdown 状态进入 odown,然后选举了一个 leader 来进行 failover,最终 6380 成为新的 master, sentinel 的日志输出:
1
2
3
4
5
6 7 8 9 10 |
|
日志的几个主要事件:
+sdown master mymaster 127.0.0.1 6379
,发现 master 检测失败,主观认为该节点挂掉,进入 sdown 状态。+odown master mymaster 127.0.0.1 6379 #quorum 3/2
,有两个 sentinel 节点认为 master 6379 挂掉,达到配置的 quorum 值 2,因此认为 master 已经客观挂掉,进入 odown 状态。+vote-for-leader eab05ac9fc34d8af6d59155caa195e0df5e80d73
准备选举一个 sentinel leader 来开始 failover。+switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
切换 master 节点, failover 完成。+config-update-from sentinel eab05ac9fc34d8af6d59155caa195e0df5e80d73 127.0.0.1 5000 @ mymaster 127.0.0.1 6379
更新 sentinel 配置。- 6379 休眠回来,作为 slave 挂载到 6380 后面,可见 sentinel 确实同时在监控 slave 状态,并且挂掉的节点不会自动移除,而是继续监控。
此时查看 sentinel 配置文件,会发现增加了一些内容:
1
2
3
4
5
6 7 8 9 |
|
可以看到 sentinel 将最新的集群状态写入了配置文件。
运维
命令
除了上面提到的一些查看信息的命令之外, sentinel 还支持下列命令来管理和检测 sentinel 配置:
SENTINEL reset <pattern>
强制重设所有监控的 master 状态,清除已知的 slave 和 sentinel 实例信息,重新获取并生成配置文件。SENTINEL failover <master name>
强制发起一次某个 master 的 failover,如果该 master 不可访问的话。SENTINEL ckquorum <master name>
检测 sentinel 配置是否合理, failover 的条件是否可能满足,主要用来检测你的 sentinel 配置是否正常。SENTINEL flushconfig
强制 sentinel 重写所有配置信息到配置文件。
增加和移除监控以及修改配置参数:
SENTINEL MONITOR <name> <ip> <port> <quorum>
SENTINEL REMOVE <name>
SENTINEL SET <name> <option> <value>
增加和移除 Sentinel
增加新的 Sentinel 实例非常简单,修改好配置文件,启动即可,其他 Sentinel 会自动发现该实例并加入集群。如果要批量启动一批 Sentinel 节点,最好以 30 秒的间隔一个一个启动为好,这样能确保整个 Sentinel 集群的大多数能够及时感知到新节点,满足当时可能发生的选举条件。
移除一个 sentinel 实例会相对麻烦一些,因为 sentinel 不会忘记已经感知到的 sentinel 实例,所以最好按照下列步骤来处理:
- 停止将要移除的 sentinel 进程。
- 给其余的 sentinel 进程发送
SENTINEL RESET *
命令来重置状态,忘记将要移除的 sentinel,每个进程之间间隔 30 秒。 - 确保所有 sentinel 对于当前存货的 sentinel 数量达成一致,可以通过
SENTINEL MASTER [mastername]
命令来观察,或者查看配置文件。
客户端实现
客户端从过去直接连接 redis ,变成:
- 先连接一个 sentinel 实例
- 使用
SENTINEL get-master-addr-by-name master-name
获取 redis 地址信息。 - 连接返回的 redis 地址信息,通过
ROLE
命令查询是否是 master。如果是,连接进入正常的服务环节。否则应该断开重新查询。 - (可选)客户端可以通过
SENTINEL sentinels [name]
来更新自己的 sentinel 实例列表。
当 Sentinel 发起 failover 后,切换了新的 master,sentinel 会发送 CLIENT KILL TYPE normal 命令给客户端,客户端需要主动断开对老的master 的链接,然后重新查询新的 master 地址,再重复走上面的流程。这样的方式仍然相对不够实时,可以通过 sentinel 提供的 Pub/Sub 来更快地监听到 failover 事件,加快重连。
如果需要实现读写分离,读走 slave,那可以走 SENTINEL slaves [name]
来查询 slave 列表并连接。
生产环境推荐
对于一个最小集群,Redis 应该是一个 master 带上两个 slave,并且开启下列选项:
1
2
|
|
这样能保证写入 master 的同时至少写入一个 slave,如果出现网络分区阻隔并发生 failover 的时候,可以保证写入的数据最终一致而不是丢失,写入老的 master 会直接失败,参考 Consistency under partitions。
Slave 可以适当设置优先级,除了 0 之外(0 表示永远不提升为 master),越小的优先级,越有可能被提示为 master。如果 slave 分布在多个机房,可以考虑将和 master 同一个机房的 slave 的优先级设置的更低以提升他被选为新的 master 的可能性。
考虑到可用性和选举的需要,Sentinel 进程至少为 3 个,推荐为 5 个,如果有网络分区,应当适当分布(比如 2 个在 A 机房, 2 个在 B 机房,一个在 C 机房)等。
其他
Redisのは、非同期レプリケーションであるので、それは実際には強い一貫性センチネルを達成することはできません、それは一貫性の究極の約束です:マスターの勝者がすべて最終的フェイルオーバーをRedisの、他のスレーブのデータが新しいマスターからのデータを再コピーし、破棄されます。前述もたらしたパーティションの一貫性もあります。
第二に、センチネル選挙アルゴリズムは、時間に依存しているため、すべてのマシンの確認時刻同期を行い、あなたは時間の矛盾を見つけた場合、Sentinelは実装 TITLの システムの可用性を保護するためのモード。