mysql哨兵机制_Redis-主从复制,哨兵机制及redis cluster

一、Redis主从复制

1.1、主从复制介绍

1)使用异步复制。

2)一个主服务器可以有多个从服务器。从服务器也可以有自己的从服务器。

3)复制功能不会阻塞主服务器

4)可以通过复制功能来让主服务器免于执行持久化操作,由从服务器去执行持久化操作即可。

a98422b56d05bf7796f5242cbc03ea30.png

1.2、数据安全

当配置Redis复制功能时,强烈建议打开主服务器的持久化功能。否则的话,由于延迟等问题,部署的服务应该要避免自动拉起。为了帮助理解主服务器关闭持久化时自动拉起的危险性,参考一下以下会导致主从服务器数据全部丢失的例子:

1. 假设节点A为主服务器,并且关闭了持久化。 并且节点B和节点C从节点A复制数据

2. 节点A崩溃,然后由自动拉起服务重启了节点A. 由于节点A的持久化被关闭了,所以重启之后没有任何数据

3. 节点B和节点C将从节点A复制数据,但是A的数据是空的, 于是就把自身保存的数据副本删除。

4)在关闭主服务器上的持久化,并同时开启自动拉起进程的情况下,即便使用Sentinel来实现Redis的高可用性,也是非常危险的。 因为主服务器可能拉起得非常快,以至于Sentinel在配置的心跳时间间隔内没有检测到主服务器已被重启,然后还是会执行上面的数据丢失的流程。

无论何时,数据安全都是极其重要的,所以应该禁止主服务器关闭持久化的同时自动拉起。

1.3、主从复制原理

22402d9551ef518e8584772a4b8dc3d9.png

原理说明:

1. 副本库通过slaveof 10.0.0.51 6379命令,连接主库,并发送SYNC给主库

2. 主库收到SYNC,会立即触发BGSAVE,后台保存RDB,发送给副本库

3. 副本库接收后会应用RDB快照

4. 主库会陆续将中间产生的新的操作,保存并发送给副本库

5. 到此,我们主复制集就正常工作了

6. 再此以后,主库只要发生新的操作,都会以命令传播的形式自动发送给副本库.

7. 所有复制相关信息,从info信息中都可以查到.即使重启任何节点,他的主从关系依然都在.

8. 如果发生主从临时断开。从库数据没有被破坏的情况下,在下次重连之后,,从库发送PSYNC给主库 (2.8版本之后)

9. 主库只会将从库缺失部分的数据同步给从库应用,达到快速恢复主从的目的

其他说明:

1)SYNC 命令执行示例

84abca72aa5b465e6d3d5fa557d00e25.png

2)命令传播

在主从服务器完成同步之后,主服务器每执行一个写命令,它都会将被执行的写命令发送给从服务器执行,这个操作被称为“命令传播”(command propagate)。命令传播是一个持续的过程:只要复制仍在继续,命令传播就会一直进行,使得主从服务器的状态可以一直保持一致

047b7ccf5fcc4fbfc51232c03ef853d9.png

3)复制中的SYNC与PSYNC

①在 Redis 2.8 版本之前, 断线之后重连的从服务器总要执行一次完整重同步(full resynchronization)操作。

②从 Redis 2.8 开始,Redis 使用 PSYNC命令代替 SYNC 命令。PSYNC 比起 SYNC 的最大改进在于 PSYNC 实现了部分重同步(partial resync)特性:在主从服务器断线并且重新连接的时候,只要条件允许,PSYNC 可以让主服务器只向从服务器同步断线期间缺失的数据,而不用重新向从服务器同步整个数据库。

SYNC 处理断线重连示例:

bac6a1cd5205cae16a4592ee146a6c48.png

PSYNC 处理断线重连示例:

271dcd61e04b0223101fec478db431e3.png

1.4、复制一致性

1.4.1、问题引出

7d7357702f6663285a2cf46ec9e03879.png

1)在读写分离环境下,客户端向主服务器发送写命令 SET n 10086,主服务器在执行这个写命令之后,向客户端返回回复,并将这个写命令传播给从服务器。

2)接到回复的客户端继续向从服务器发送读命令 GET n ,并且因为网络状态的原因,客户端的 GET命令比主服务器传播的 SET 命令更快到达了从服务器。

3)因为从服务器键 n 的值还未被更新,所以客户端在从服务器读取到的将是一个错误(过期)的 n值。

1.4.2、问题解决

从 Redis 2.8 开始, 为了保证数据的安全性, 可以通过配置, 让主服务器只在有至少 N 个当前已连接从服务器的情况下, 才执行写命令。不过, 因为 Redis 使用异步复制, 所以主服务器发送的写数据并不一定会被从服务器接收到,因此, 数据丢失的可能性仍然是存在的。

通过以下两个参数保证数据的安全:

1.5、主从复制配置

19f443ec959fba12ceaf57b91acac696.png

1)环境准备

准备两个或两个以上redis实例:主节点:6380  从节点:6381、6382

2)配置文件

3)启动

4)开启主从

6381/6382命令行上操作

5)查询主从状态

示例:

1.6、主从切换

1)模拟主库故障

2)解除主从关系

3)重新设置主从

二、Redis Sentinel

2.1、哨兵简介

Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案,当用Redis做Master-slave的高可用方案时,假如master宕机了,Redis本身(包括它的很多客户端)都没有实现自动进行主备切换,而Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发现master宕机后能进行自动切换。

2.2、Sentinel 的构造

Sentinel 是一个监视器,它可以根据被监视实例的身份和状态来判断应该执行何种动作。

f80d8498eb6cba4b5812b3d36bdd9aa6.png

2.3、哨兵功能

1)监控(Monitoring):Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

2)提醒(Notification):当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

3)自动故障迁移(Automatic failover):当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时,集群也会向客户端返回新主服务器的地址,使得集群可以使用新主服务器代替失效服务器。

4)应用透明 ==>相当于mysql MHA vip功能

---------------------------------------------------------------------------------------------------------------------------------------------------

1)发现并连接主服务器

Sentinel 通过用户给定的配置文件来发现主服务器。Sentinel 会与被监视的主服务器创建两个网络连接:命令连接用于向主服务器发送命令。

订阅连接用于订阅指定的频道,从而发现监视同一主服务器的其他 Sentinel

86e0c1e5ebb158c8842ce0fab7a38190.png

2)发现并连接从服务器

Sentinel 通过向主服务器发送INFO 命令来自动获得所有从服务器的地址。跟主服务器一样,Sentinel 会与每个被发现的从服务器创建命令连接和订阅连接

e45719ba972a9d6fa723d8d24bfa9bcb.png

3)发现其他 Sentinel

Sentinel 会通过命令连接向被监视的主从服务器发送 “HELLO” 信息,该消息包含 Sentinel 的 IP、端口号、ID 等内容,以此来向其他 Sentinel 宣告自己的存在。与此同时Sentinel 会通过订阅连接接收其他 Sentinel 的“HELLO” 信息,以此来发现监视同一个主服务器的其他 Sentinel 。sentinel1 通过发送HELLO 信息来让sentinel2 和 sentinel3发现自己,其他两个sentinel 也会进行类似的操作。

77bcb90e271b9af494cef074dfc5d4bc.png

4)多个Sentienl之间的链接

Sentinel 之间只会互相创建命令连接,用于进行通信。因为已经有主从服务器作为发送和接收 HELLO 信息的中介,所以 Sentinel之间不会创建订阅连接。

85958c16fee392c814cb298fb7d9d5ad.png

5)检测实例的状态

Sentinel 使用 PING 命令来检测实例的状态:如果实例在指定的时间内没有返回回复,或者返回错误的回复,那么该实例会被 Sentinel 判断为下线

Redis 的 Sentinel 中关于下线(down)有两个不同的概念:

①主观下线(Subjectively Down, 简称 SDOWN)指的是单个 Sentinel 实例对服务器做出的下线判断。

②客观下线(Objectively Down, 简称 ODOWN)指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断, 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后, 得出的服务器下线判断。 (一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。)

如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内, 对向它发送 PING 命令的 Sentinel 返回一个有效回复(valid reply), 那么 Sentinel 就会将这个服务器标记为主观下线。

77b7257275c5c96e0c5aba61f99c88bd.png

6)故障转移FAILOVER

一次故障转移操作由以下步骤组成:

①发现主服务器已经进入客观下线状态。

②基于Raft leader election    协议 , 进行投票选举

③如果当选失败,那么在设定的故障迁移超时时间的两倍之后,重新尝试当选。 如果当选成功, 那么执行以下步骤。

④选出一个从服务器,并将它升级为主服务器。

⑤向被选中的从服务器发送 SLAVEOF NO ONE 命令,让它转变为主服务器。

⑥通过发布与订阅功能, 将更新后的配置传播给所有其他 Sentinel ,其他 Sentinel 对它们自己的配置进行更新。

⑦向已下线主服务器的从服务器发送 SLAVEOF 命令,让它们去复制新的主服务器。

⑧当所有从服务器都已经开始复制新的主服务器时, leader Sentinel 终止这次故障迁移操作。

2.4、哨兵搭建过程

1)创建哨兵目录

2)哨兵配置文件

d2ba9877d9387b6af84ef808d8f20304.png

3)启动哨兵

6deb7d97ea29a4bb2e36c8424608ef86.png

如果有问题,可按如下方法解决:

2.5、故障测试

1)停主库

7aee8ed9481f4e39d80d304e5f09e83a.png

634d1634286f3590da9ae3ac31640661.png

2)查看哨兵配置

aabb6303b7cb99f30ca39a87e2c9e9e9.png

3)重新启动宕机的实例

bfcba6f7f83c1849273ab39286dbad9c.png

2.6、哨兵管理命令

三、Redis cluster

3.1、cluster简介

1)Redis 集群是一个可以在多个 Redis 节点之间进行数据共享的设施(installation)。

2)Redis 集群不支持那些需要同时处理多个键的 Redis 命令, 因为执行这些命令需要在多个 Redis 节点之间移动数据, 并且在高负载的情况下, 这些命令将降低 Redis 集群的性能, 并导致不可预测的行为。

3)Redis 集群通过分区(partition)来提供一定程度的可用性(availability): 即使集群中有一部分节点失效或者无法进行通讯,集群也可以继续处理命令请求。

4)将数据自动切分(split)到多个节点的能力。当集群中的一部分节点失效或者无法进行通讯时, 仍然可以继续处理命令请求的能力。

3.2、集群数据共享

Redis 集群使用数据分片(sharding)而非一致性哈希(consistency hashing)来实现: 一个 Redis 集群包含 16384 个哈希槽(hash slot), 数据库中的每个键都属于这 16384 个哈希槽的其中一个, 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽, 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。

节点 A 负责处理 0 号至 5500 号哈希槽。

节点 B 负责处理 5501 号至 11000 号哈希槽。

节点 C 负责处理 11001 号至 16384 号哈希槽。

集群使用公式 CRC16(key) & 16384 计算键 key属于哪个槽

e59b88e6847f0b137e4a25878a43c3e2.png

5c3909bea7adf370e122aa56f8e43f57.png

1)高性能

1、在多分片节点中,将16384个槽位,均匀分布到多个分片节点中

2、存数据时,将key做crc16(key),然后和16384进行取模,得出槽位值(0-16383之间)

3、根据计算得出的槽位值,找到相对应的分片节点的主节点,存储到相应槽位上

4、如果客户端当时连接的节点不是将来要存储的分片节点,分片集群会将客户端连接切换至真正存储节点进行数据存储

2)高可用

在搭建集群时,会为每一个分片的主节点,对应一个从节点,实现slaveof的功能,同时当主节点down,实现类似于sentinel的自动failover的功能。

3.3、运行机制

1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.

2)节点的fail是通过集群中超过半数的master节点检测失效时才生效.

3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

4)把所有的物理节点映射到[0-16383]slot上,cluster 负责维护nodeslotkey

3.4、集群的复制

为了使得集群在一部分节点下线或者无法与集群的大多数(majority)节点进行通讯的情况下, 仍然可以正常运作, Redis 集群对节点使用了主从复制功能: 集群中的每个节点都有 1 个至 N 个复制品(replica), 其中一个复制品为主节点(master), 而其余的 N-1 个复制品为从节点(slave)。

在之前列举的节点 A 、B 、C 的例子中, 如果节点 B 下线了, 那么集群将无法正常运行, 因为集群找不到节点来处理 5501 号至 11000 号的哈希槽。

假如在创建集群的时候(或者至少在节点 B 下线之前), 我们为主节点 B 添加了从节点 B1 , 那么当主节点 B 下线的时候, 集群就会将 B1 设置为新的主节点, 并让它代替下线的主节点 B , 继续处理 5501 号至 11000 号的哈希槽, 这样集群就不会因为主节点 B 的下线而无法正常运作了。

不过如果节点 B 和 B1 都下线的话, Redis 集群还是会停止运作。

集群的复制特性重用了 SLAVEOF 命令的代码,所以集群节点的复制行为和 SLAVEOF 命令的复制行为完全相同。

3.5、集群故障转移

在集群里面,节点会对其他节点进行下线检测。当一个主节点下线时,集群里面的其他主节点负责对下线主节点进行故障移。换句话说,集群的节点集成了下线检测和故障转移等类似 Sentinel 的功能。因为 Sentinel 是一个独立运行的监控程序,而集群的下线检测和故障转移等功能是集成在节点里面的,它们的运行模式非常地不同,所以尽管这两者的功能很相似,但集群的实现没有重用 Sentinel 的代码。

3.6、集群执行命令情况

1)命令发送给正确的节点

命令发送到了正确的节点:命令要处理的键所在的槽正好是由接收命令的节点负责,那么该节点执行命令,就像单机 Redis 服务器一样。键 date 位于 2022 槽,该槽由节点 7000 负责,命令会直接执行

f56c77966f4fb6e171dc51e03dbbd91a.png

2)命令发送给了错误的节点

命令发送到了错误的节点:接收到命令的节点并非处理键所在槽的节点,那么节点将向客户端返回一个转向(redirection)错误,告知客户端应该到哪个节点去执行这个命令,客户端会根据错误提示的信息,重新向正确的节点发送命令。键 date 位于 2022 槽,该槽由节点 7000 负责,但错误发送到了7001节点

dfd043662ee4d867a505052cac58cb61.png

转向错误的实现:

1)集群中的节点会互相告知对方,自己负责处理哪些槽

d40b4c4df333e002900ea77b1ffe18a4.png

2)集群中的每个节点都会记录 16384 个槽分别由哪个节点负责,从而形成一个“槽表”(slot table)。

节点在接收到命令请求时,会通过槽表检查键所在的槽是否由本节点处理:如果是的话,那么节点直接执行命令;

如果不是的话,那么节点就从槽表里面提取出正确节点的地址信息,然后返回转向错误。

ae470e1022d64276520b525663eccb8e.png

3.7、集群搭建过程

1)环境准备

6个redis实例,一般会放到3台硬件服务器

注:在企业规划中,一个分片的两个分到不同的物理机,防止硬件主机宕机造成的整个分片数据丢失。

端口号:7000-7005

2)安装集群插件

3)集群节点准备

相关说明:

Redis 集群由多个运行在集群模式(cluster mode)下的 Redis 实例组成, 实例的集群模式需要通过配置来开启,开启集群模式的实例将可以使用集群特有的功能和命令

以下是一个包含了最少选项的集群配置文件示例:

4)启动节点

5)将节点加入集群管理

redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005

#--replicas 1表示副本是一个(如果是2,至少要准备9个节点,一主两从)

#前三个是主库,后三个是从库(需要保证对应的主库与从库在不同的节点上)

6)查看节点信息

关注点:

3.8、集群节点管理

3.8.1、增加新的节点

1)创建新节点的目录及配置文件

2)启动新节点

3)添加主节点

c9de349b11389fa85bcb275f00c4aa74.png

4)转移slot(重新分片),从已有的节点上分配槽位给新添加的节点

重新分片过程:

分片完之后,再次查看节点的槽位变化:

516c6c86429f1c0c99b190dc8658ce25.png

5)添加从节点

过程说明:

3.8.2、删除节点

1)查看当前槽位分配状态:

2fced4ce5ecc3aa4337e8e69069aa383.png

2)

将之前获取的槽位分批归还

查看最后归还结果:

98bfbaf22cd801e71934bd04772ccd76.png

3)删除主从节点(最好先删除从节点后删除主节点)

注意:删除之后,删除节点的进程会自动关闭

表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
相关推荐
©️2020 CSDN 皮肤主题: 游动-白 设计师:白松林 返回首页