主从结构中 redis 从节点上只能读数据,不能写入数据,主节点写入的数据,在从节点都能查看并获取到
通过 slaveof 命令还可以实现切主操作,将当前从节点的数据源切换到另⼀个主节点,并且切换后会先删除当前节点的所有数据,再复制新的主节点数据。执行 slaveof 新主节点IP 新主节点端口
命令即可。
例如将端口号为 6381 从节点的 “主”,换成 端口号为 6380,如下
现在的情况就是6379是6380的主节点,6380是6381的主节点
而且此处的修改是临时的,如果重启 redis 服务器,就会按照最初再配置文件中设置的内容来建立主从关系
要设置Redis的主从复制为只读模式,可以通过修改从节点的配置文件来实现。
首先,在主节点的配置文件redis.conf中,设置slave-read-only参数为yes:
slave-read-only yes
然后,在从节点的配置文件redis.conf中,设置slave-read-only参数为yes,并且设置masterauth参数来保护主节点的写操作:
slave-read-only yes
masterauth
其中,
是主节点的密码。
保存并关闭配置文件后,重新启动从节点即可。从节点在只读模式下,将无法接受任何写入操作,只能进行读取操作。如果有写入操作,从节点将抛出错误。
确保从节点处于只读模式后,可以通过在从节点上执行redis-cli info
命令来验证。在输出的信息中查找role:slave
,并确保master_replid
和master_repl_offset
等参数被正确地设置为主节点的信息。
由于复制只能从主节点到从节 点,对于从节点的任何修改主节点都⽆法感知,修改从节点会造成主从数据不⼀致。所以建议线上不要修改从节点的只读模式。
Redis主从复制中的网络延迟问题是指主节点与从节点之间进行数据同步时所出现的网络延迟现象。
在Redis主从复制中,主节点将自己的写操作记录在内存中的AOF日志或者RDB文件中,并且将这些写操作发送给从节点,从节点则通过执行这些写操作来保持与主节点的数据同步。
然而,由于网络的不稳定性或者网络带宽的限制,主节点发送给从节点的数据可能会发生延迟。这可能导致从节点在执行主节点的写操作之前会有一段时间的数据不一致。
例如,如果主节点发送的写操作在发送之前就出现了网络延迟,从节点可能会在这段延迟期间没有接收到新的写操作,并且从节点上的数据可能会落后于主节点。
这种网络延迟问题可能会导致主节点和从节点之间的数据不一致,特别是在高写入负载下或者网络环境较差的情况下。
尽量减少网络延迟:确保主节点和从节点之间的网络连接质量良好,并尽量采用高带宽、低延迟的网络环境。
监控网络延迟:通过监控工具或者Redis的内置命令,实时监测主从节点之间的网络延迟情况,及时发现和解决延迟问题。
设置Redis复制的超时时间:通过设置适当的超时时间,可以确保主节点和从节点之间的数据同步不会因为网络延迟而无法完成。
使用命令等待复制完成:在从节点执行写操作之前,可以使用Redis的命令等待功能,等待主节点的数据同步完成后再执行写操作,以保证数据一致性。
增加从节点的数量:使用多个从节点可以减轻单个从节点的负载,并且增加了数据同步的冗余性,能够更好地应对网络延迟问题。
repl-disable-tcp-nodelay
这个选项就可以进行配置 naqle 算法是否开启.主节点有一个从节点,主节点负责处理写操作,从节点负责复制主节点的数据并处理读请求。
+--------+
| Master |
+--------+
|
|
v
+--------+
| Slave |
+--------+
主节点可以有多个从节点,主节点负责处理写操作,从节点负责复制主节点的数据并处理读请求。
+--------+
| Master |
+--------+
|
|
v
+--------+
| Slave |
+--------+
|
|
v
+--------+
| Slave |
+--------+
+--------+
| Master |
+--------+
|
|
+-------------------------------------+
| |
v v
+--------+ +--------+
| Slave1 | | Slave2 |
+---------------------------+ +--------+
| | |
| | |
v v v
+--------+ +--------+ +--------+
| Slave3 | | Slave4 | | Slave4 |
+--------+ +--------+ +--------+
多个主节点通过复制数据到各自的从节点,从节点可以作为主节点的备份,当主节点发生故障时,可以将其中一个从节点切换为新的主节点。
+--------+ +--------+
| Master | | Master |
+--------+ +--------+
| |
| |
v v
+--------+ +--------+
| Slave | | Slave |
+--------+ +--------+
Redis主从复制是一种数据同步机制,它允许将一个Redis服务器(主服务器)的数据复制到多个其他Redis服务器(从服务器)。下面是Redis主从复制的详细流程:
从服务器连接主服务器:从服务器通过向主服务器发送SYNC命令来与主服务器建立连接。
主服务器执行BGSAVE命令:主服务器收到SYNC命令后,执行BGSAVE命令将当前数据库状态保存到磁盘上的RDB文件中。
主服务器发送RDB文件:当BGSAVE命令完成后,主服务器将RDB文件发送给从服务器。
从服务器接收RDB文件:从服务器接收到RDB文件后,将其写入本地磁盘。
主服务器发送缓冲区数据:主服务器将在RDB文件生成期间接收到的所有命令写入到缓冲区。
主服务器发送缓冲区数据偏移量:当RDB文件发送完毕后,主服务器将发送缓冲区数据的偏移量给从服务器。
从服务器请求增量数据:从服务器收到缓冲区数据偏移量后,向主服务器发送PSYNC命令,请求增量数据。
主服务器发送增量数据:主服务器收到PSYNC命令后,将缓冲区数据偏移量之后的所有命令发送给从服务器。
从服务器执行增量数据:从服务器接收到增量数据后,将其执行,使自己的数据库与主服务器保持一致。
主从服务器保持同步:主服务器会持续地把接收到的写命令发送给从服务器,从服务器会实时地执行这些命令,以保持与主服务器的数据同步。
psync replicationid offset
从节点和主节点之间的数据同步,不是瞬间完成的,并且在复制数据的同时,主节点上也会 “源源不断” 的收到其他 “修改数据” 的请求,那么从节点怎么知道数据已经同步到哪里了呢?
在 psync 命令中,offset 有两种写法:
PSYNC命令用于在Redis主从复制中请求增量数据的同步操作,下面是PSYNC命令的运行流程:
从服务器发送PSYNC命令:从服务器向主服务器发送PSYNC命令,带上自己的复制偏移量和复制ID。
主服务器判断复制模式:主服务器收到PSYNC命令后,首先会判断当前的复制模式。
如果主服务器处于全量复制模式(即没有之前的复制关系),则主服务器将执行全量复制流程。
如果主服务器处于部分复制模式(即已经有之前的复制关系),则主服务器将执行部分复制流程。
主服务器执行全量复制流程:
a. 主服务器检查RDB文件:主服务器会检查自己是否有可用的RDB文件,以确定是否需要传输RDB文件给从服务器。如果有RDB文件,则进入步骤4;否则,进入步骤5。
b. 主服务器发送RDB文件和缓冲区数据:主服务器将发送RDB文件和缓冲区数据给从服务器。
c. 从服务器接收RDB文件和缓冲区数据:从服务器接收RDB文件和缓冲区数据后,将其写入本地磁盘,并执行缓冲区数据,使数据库与主服务器同步。
d. 主服务器继续发送增量数据:主服务器会持续地把接收到的写命令发送给从服务器,从服务器会实时地执行这些命令,以保持与主服务器的数据同步。
主服务器执行部分复制流程:
a. 主服务器检查复制ID:主服务器会根据从服务器发送的复制ID来检查是否有与之一致的复制积压数据。
b. 主服务器发送增量数据:如果有一致的复制积压数据,主服务器将发送这些增量数据给从服务器;否则,进入步骤5。
c. 从服务器接收增量数据:从服务器接收到增量数据后,将其执行,使自己的数据库与主服务器保持一致。
主服务器执行全量重同步流程:
a. 主服务器发送FULLRESYNC命令:主服务器将发送FULLRESYNC命令给从服务器,带上自己的复制ID和最新的复制偏移量。
b. 从服务器接收FULLRESYNC命令:从服务器接收到FULLRESYNC命令后,将其保存为自己的复制ID和复制偏移量。
c. 主服务器发送RDB文件和缓冲区数据:主服务器将发送RDB文件和缓冲区数据给从服务器。
d. 从服务器接收RDB文件和缓冲区数据:从服务器接收RDB文件和缓冲区数据后,将其写入本地磁盘,并执行缓冲区数据,使数据库与主服务器同步。
e. 主服务器继续发送增量数据:主服务器会持续地把接收到的写命令发送给从服务器,从服务器会实时地执行这些命令,以保持与主服务器的数据同步。
通过PSYNC命令的流程,主从服务器可以进行数据同步,保持数据的一致性。
全量复制:首次和主节点进行数据同步时(判断 replication id 不一样),或者是在部分复制的时候,发现已经超出积压缓冲区的数据范围了,也会进行全量复制.
部分复制:从节点之前从主节点上父之过数据了,或者是有网络抖动或者从节点重启而丢失数据(大部分数据是一致的).
在部分复制流程中,主服务器会根据从服务器提供的复制ID查找是否有与之一致的复制积压数据,如果有,则将这些增量数据发送给从服务器进行同步。这样可以减少数据传输的量,提高复制的效率。如果没有一致的复制积压数据,主服务器会执行全量同步来实现复制。
通常主从复制肯定不是我们现在这样一个redis服务分三个端口开放,常规来说都是分别部署在不同的服务器上,这样也能避免一些问题,比如最开始创建从节点的配置文件没有改 appendfilename 属性,导致生成的 aof 文件路径/文件名 都是同一个