redis 持久化哨兵主从

川长思鸟来 2024-04-19 11:58 70阅读 0赞

Redis搭建步骤

**环境：**

三台机器  centos7

关闭防火墙 selinux

Redis版本 3.0.5

依赖环境

yum install gcc-c++ ruby rubygems –y

把版本包上传到服务器上，redis-3.0.5.tar.gz

解压tar -zxvf redis-3.0.5.tar.gz

然后进入目录

cd redis-3.0.5

直接make

然后进入

cd /redis/redis-3.0.5/src/

make install

然后把启动文件还有配置文件移除到其他地方方便管理

mkdir -p/usr/local/redis/bin

mkdir -p /usr/local/redis/bin

mkdir -p /usr/local/redis/etc

移动文件

mv redis.conf /usr/local/redis/etc/

以下文件在src目录里：

mv mkreleasehdr.sh redis-benchmark redis-check-aof redis-check-dump redis-cli redis-server /usr/local/redis/bin/

方便后台启动需要改动redis.conf 配置文件

Vim redis.conf首先编辑conf文件，将daemonize属性改为yes（表明需要在后台运行）

redis-server /usr/local/redis/etc/redis.conf  完成单点

常用命令：

**Redis****：**

Redis-server /usr..../redis.conf 启动redis服务，并指定配置文件

Redis-cli 启动redis 客户端

Pkill redis-server 关闭redis服务

Redis-cli shutdown 关闭redis客户端

Netstat -tunpl|grep 6379 查看redis 默认端口号6379占用情况

**Redis****集群模式（主从）**

主库不需要动

从库修改salveof 后面添加主库IP + redis端口号

配置主服务器

1、进入192.168.2.100服务器，打开redis配置文件

\[root@localhost redis-4.0.10\]\# vim /etc/redis/6379.conf

2、将bind 127.0.0.1这行注释或者指定ip。（本例是注释，即所有ip都能连接）

![1162158-20190917164934985-1842577078.png][]

3、开启守护进程

![1162158-20190917164942469-1876988819.png][]

4、设置访问密码（由于redis性能非常高，撞库风险极大，建议线上把密码设置非常复杂，最好能在第2步中指定ip）

![1162158-20190917164950195-1943130020.png][]

注意：

当然，既然用到主从了，那说明对redis依赖非常高，还有几个参数需要根据服务器配置来设置

第一个就是客户端最大连接数（maxclients），默认是10000，可根据需求更改

![1162158-20190917164959443-850694398.png][]

第二个就是最大内存（默认不受限制，但如果有多个从服务器，建议还是设置个低于服务器内存的值）

![1162158-20190917165006409-1774084005.png][]

第三个是内存策略，如果内存足够用则不用管，如果内存不够用，建议设置最近最少使用策略（LRU）,默认是内存不够则报错

![1162158-20190917165017864-1079656204.png][]

至此主服务器配置完毕！

三、配置从服务器

前四步与主服务器配置基本一致

5、配置所属主服务器ip和端口

![1162158-20190917165029066-1105229184.png][]

6、配置所属主服务器的密码（再次强调，要将密码设置非常复杂，这里只是演示）

![1162158-20190917165036142-1728616605.png][]

需要注意的是，从服务器通常是只读，所以要配置只读（默认是只读，不要更改即可）

![1162158-20190917165047913-778746053.png][]

配置完成，启动服务

四、测试

使用redis客户端或者telnet都可以

本次使用redis客户端

![1162158-20190917165101578-75365326.png][]

1、进入主服务器（192.168.2.100）

进入redis客户端

\[root@localhost redis-4.0.10\]\# /usr/local/redis/bin/redis-cli

由于设置了密码，所以需要鉴权

![1162158-20190917165116830-1968205515.png][]

设置一个值

![1162158-20190917165127630-1651007303.png][]

2、进入从服务器（192.168.2.101）

使用get命令获取name的值，可以看到

![1162158-20190917165136194-469309734.png][]

代表配置成功

如果在从服务器上写，则会报错，如下图

![1162158-20190917165144273-669405333.png][]

至此，redis主从复制配置完成，如果需要配置多台从服务器，可以重复第三步

**主从复制原理：**

1.当从库和主库建立MS关系后,会向主数据库发送SYNC命令

2.主库接收到SYNC命令后会开始在后台保存快照(RDB持久化过程),并将期间接收到的写命令缓存起来

3.当快照完成后,主Redis会将快照文件和所有缓存的写命令发送给从Redis

4.从Redis接收到后,会载入快照文件并且执行收到的缓存的命令

5.之后,主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致

**Redis Sentinel (****哨兵****)****部署**

**Sentinel****介绍**：Sentinel是Redis的高可用性（HA）解决方案，由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进行下线状态时，

自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。Redis提供的sentinel（哨兵）机制，通过sentinel模式启动redis后，

自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决（每个sentinel只有一次选举的机会，当主库出现故障，哨兵会投票从库中选出一个承担主库的任务，剩下的还是从库）

**Sentinel****作用**:

1.  监控：监控主从是否正常  
    2. 通知：出现问题时，可以通知相关人员  
    3. 自动故障迁移：自动主从切换  
    4. 统一的配置管理：连接者询问sentinel取得主从的地址

部署哨兵

yum install gcc-c++ ruby rubygems –y

需要单独一个机器做哨兵部署

配置文件在redis包里名字sentinel.conf

配置如下

protected-mode no      （去掉注释）  
            daemonize yes          （自行添加守护进程）  
            dir /tmp  
            logfile "/var/log/redis/redis\_26379.log"    （自行添加哨兵的日志）  
            sentinel monitor mymaster 192.168.52.138 6379 2   （原基础上更改）  
            sentinel down-after-milliseconds mymaster 30000   （默认）  
            sentinel parallel-syncs mymaster 1                （默认）  
            sentinel failover-timeout mymaster 180000         （默认）  ）

![1162158-20190917165208613-432238097.png][]

![1162158-20190917165218682-1182362515.png][]

**Redis****持久化**

**都在redis.conf中配置**

** **

###   一、RDB持久化 ###

**1.1****介绍**

RDB方式是通过快照完成的,当符合一定的条件时,redis会自动将内存中的所有数据进行快照并且存储到硬盘上，默认存储在redis根目录的dump.rdb文件中(文件名在配置文件中dbfilename),进行快照的条件在redis.conf配置文件中指定，有两个参数构成，时间和改动的键的个数，当在指定时间被更改的键的个数大于指定数值时就会进行快照，RDB是redis默认的持久化方式

**1.2****快照过程**

当redis需要做持久化时，redis会fork一个子进程；子进程将数据写到磁盘上一个临时RDB文件中；当子进程完成写临时文件后，将原来的RDB替换掉,然后子进程退出

**1.3RDB****持久化配置**

RDB是Redis默认采用的持久化方式，在redis.conf配置文件中默认有此下配置：  
save 900 1  
save 300 10  
save 60 10000

save 开头的一行就是持久化配置，可以配置多个条件（每行配置一个条件），每个条件之间是“或”的关系，“save 900 1”表示15分钟（900秒钟）内至少1个键被更改则进行快照，“save 300 10”表示5分钟（300秒）内至少10个键被更改则进行快照。"60 10000"表示60秒内有10000个key出现变更  做一次快照

在redis.conf中：

配置dir指定rdb快照文件的位置

配置dbfilenam指定rdb快照文件的名称

**1.4RDB****的优缺点**

RDB的优点：

1). 一旦采用该方式，那么你的整个Redis[数据库][Link 1]将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦[系统][Link 2]出现灾难性故障，我们可以非常容易的进行恢复。

2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB的缺点：

1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。  
2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

**二、****AOF****持久化**

**1.1****介绍**

redis会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。AOF就可以做到全程持久化，只需要在配置文件中开启（默认是no不开启的）,开启AOF之后，（默认是：每秒fsync一次）

**1.2****持久化过程**

Redis 执行 fork() ，现在同时拥有父进程和子进程。子进程开始将新 AOF 文件的内容写入到临时文件。对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾： 这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。

**1.3AOF****的配置**

开启AOF持久化

appendonly yes \#启用aof持久化方式

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always \#每次有数据修改发生时都会写入AOF文件。  
appendfsync everysec \#每秒钟同步一次，该策略为AOF的缺省策略。  
appendfsync no \#从不同步。高效但是数据不会被持久化。

AOF持久化文件的名称

appendfilename “appendonly.aof”

**1.4****如何修复坏损的****AOF****文件：**

将现有已经坏损的AOF文件额外拷贝出来一份

执行”redis-check-aof –fix ”命令来修复坏损的AOF文件。

用修复后的AOF文件重新启动Redis服务器。

**1.5AOF****的优缺点**

AOF的优点：

1). 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。  
2). 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。  
3). 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。  
4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

AOF的劣势：

1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。  
2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

** **

[1162158-20190917164934985-1842577078.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/d82034985db74185bbe4ca9627420d54.png
[1162158-20190917164942469-1876988819.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/6fb9a4a6536a446eb8827038cc513736.png
[1162158-20190917164950195-1943130020.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/4bf78d4f16364078a96772d0ce33bbaa.png
[1162158-20190917164959443-850694398.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/0c079dc05aca44d1aa8ba8442a9f0f4c.png
[1162158-20190917165006409-1774084005.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/6111f91227ae49818cd7cbe3ae90ebb2.png
[1162158-20190917165017864-1079656204.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/a688ad5a4b714a119b13f377356e39aa.png
[1162158-20190917165029066-1105229184.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/cdf85f1868c347e3b8259a3879585186.png
[1162158-20190917165036142-1728616605.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/62e707c4c3d148aa8839cb5aafcfae94.png
[1162158-20190917165047913-778746053.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/c4fc0e3df421402cadc05c4cf878bf2f.png
[1162158-20190917165101578-75365326.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/762a2f707d4d4522bed12fd4cbfc9b8c.png
[1162158-20190917165116830-1968205515.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/398bb0e6a6e34d54bee1be3e3fb21709.png
[1162158-20190917165127630-1651007303.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/3c6200cff8d74e64a9faa2a5010c7b2e.png
[1162158-20190917165136194-469309734.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/444f24f41cda483e8449cfed921c49d2.png
[1162158-20190917165144273-669405333.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/07a3a6fab94f4480bb7331a299fb45d0.png
[1162158-20190917165208613-432238097.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/fbc7720074144d71a073292d9c2d05da.png
[1162158-20190917165218682-1182362515.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/c44e65ade21a432bbeb07d9a0dff07d8.png
[Link 1]: https://www.2cto.com/database/
[Link 2]: https://www.2cto.com/os/