Redis-主从复制

原创已于 2024-11-04 08:40:43 修改 · 956 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#redis #数据库 #主从复制 #多实例主从复制 #级联复制 #异步复制

于 2024-10-29 22:09:49 首次发布

Redis 专栏收录该内容

9 篇文章

订阅专栏

一、Redis的主从复制机制介绍

在这里插入图片描述

注：“Redis的主从复制中，应该禁止主服务器关闭持久化的同时自动拉起”中的自动拉起是什么意思？

在Redis的主从复制配置中，“自动拉起”指的是当主服务器（Master）因为某些原因崩溃后，系统自动重启该主服务器的行为。在某些情况下，这种自动重启的行为可能会带来数据安全的风险，特别是在主服务器关闭了持久化功能的情况下。

当主服务器关闭了持久化功能，意味着它不会定期将内存中的数据保存到磁盘上。如果主服务器崩溃，重启后的主服务器将没有任何数据，因为它没有持久化的数据可以恢复。在这种情况下，如果主服务器配置了自动拉起，那么重启后的主服务器会向从服务器（Slave）请求数据同步。由于主服务器重启后是空的，它会要求从服务器发送其数据副本。从服务器在复制数据给主服务器的过程中，会删除自己的数据副本，以匹配主服务器的空状态，这将导致从服务器丢失所有数据。

因此，为了数据安全，建议不要在关闭主服务器持久化的同时配置自动拉起。正确的做法是保持主服务器的持久化功能开启，或者在关闭持久化的同时，确保主服务器不会因为崩溃而自动重启，以避免数据丢失的风险。

在这里插入图片描述

同步复制与异步复制

同步复制（Synchronous Replication）和异步复制（Asynchronous Replication）是数据复制领域中的两种主要复制模式，它们在数据一致性、性能和可用性方面有不同的特点和应用场景。

同步复制（Synchronous Replication）

定义：
同步复制是一种数据复制方式，其中主节点（Primary）在执行写操作（如插入、更新、删除）后，必须等待从节点（Secondary）确认数据已成功写入，才会向客户端返回操作成功的响应。
数据一致性：
同步复制确保了主从节点之间的数据强一致性。在任何时候，从节点的数据都是与主节点同步的。
性能影响：
由于需要等待从节点的确认，同步复制可能会影响主节点的性能，特别是在网络延迟高或从节点处理能力有限的情况下。
可用性：
如果从节点不可用，主节点的写操作将被阻塞，这可能会影响系统的可用性。
应用场景：
适用于对数据一致性要求极高的场景，如金融交易系统。

异步复制（Asynchronous Replication）

定义：
异步复制是一种数据复制方式，其中主节点在执行写操作后，不需要等待从节点的确认，即可向客户端返回操作成功的响应。从节点在后台异步地复制主节点的数据。
数据一致性：
异步复制可能导致主从节点之间的数据存在短暂的不一致性。在极端情况下，如果主节点发生故障，从节点可能还没有复制完最新的数据。
性能影响：
由于不需要等待从节点的确认，异步复制对主节点的性能影响较小，可以提供更好的写入性能。
可用性：
即使从节点不可用，主节点的写操作也不会被阻塞，这提高了系统的可用性。
应用场景：
适用于对写入性能要求较高，而对数据一致性要求不是非常高的场景，如日志收集系统。

总结

同步复制：保证数据的强一致性，但可能会牺牲一些性能和可用性。
异步复制：提供更好的性能和可用性，但数据一致性不如同步复制。

在实际应用中，选择哪种复制模式取决于具体的业务需求和对数据一致性、性能、可用性的权衡。有些系统可能会采用半同步复制（Semi-Synchronous Replication）作为折中方案，即主节点在写操作后等待至少一个从节点的确认，以提高数据一致性，同时减少对性能的影响。

级联复制

级联复制（Cascade Replication）是一种数据库复制方式，它允许一个从服务器（Slave）不仅从主服务器（Master）复制数据，还可以作为其他从服务器的主服务器，将数据再次复制到更多的从服务器。这种结构可以减少直接从属于主服务器的从服务器数量，从而减轻主服务器的压力，分散复制请求，提高整体的复制效率。

原理

级联复制的原理是通过中间的从服务器来传递主服务器的数据和二进制日志（Binary Log）到下游的从服务器。这样，主服务器只需要处理一个从服务器的复制请求，而这个中间从服务器再负责将数据传递给更多的从服务器。

应用场景

跨机房复制：在跨机房的场景中，可以使用级联复制来减少主服务器的负载。例如，主服务器A复制到中间服务器B，然后B再复制到跨机房的服务器C。如果A挂掉，B可以提升为主，此时C不需要重新配置复制。
库的拆分：如果某个数据库压力很大，可以使用级联复制将其独立出去，以减轻主服务器的负担。

缺点

复制延迟：由于存在多级复制，而主从复制是异步的，最底层的从服务器可能会有较大的延迟，且延迟随着级联层次的增加而增加。
数据一致性：在极端情况下，如果主服务器发生故障，最底层的从服务器可能还没有复制完最新的数据，这可能导致数据不一致。

配置要点

开启二进制日志：中间从服务器需要开启二进制日志功能，以便将主服务器的更新记录到自己的二进制日志中，然后传递给下游的从服务器。
log_slave_updates：这个参数用来配置从服务器的更新是否写入二进制日志，这对于级联复制是必需的，否则下游的从服务器无法获得二进制日志进行同步操作。

实现步骤

主服务器配置：设置server_id和log_bin，确保开启二进制日志。
中间从服务器配置：除了开启二进制日志外，还需要设置log_slave_updates，以便将主服务器的二进制日志记录到自己的日志中，并传递给下游从服务器。
下游从服务器配置：与普通从服务器配置相同，连接到中间从服务器并开始复制。

级联复制是一种有效的数据复制策略，尤其适用于需要减轻主服务器负载和分散复制压力的场景。然而，它也带来了复制延迟和数据一致性的问题，因此在实际应用中需要根据具体的业务需求和容忍度来决定是否采用级联复制。

Redis的断点续传机制

使用psync替代sync

Redis的断点续传机制是指在主从复制过程中，如果由于网络问题或其他原因导致连接中断，可以从中断的地方继续复制数据，而不需要从头开始复制整个数据集。这个机制从Redis 2.8版本开始支持，极大地提高了复制的效率和可靠性。以下是断点续传机制的详细介绍：

PSYNC命令：Redis 2.8引入了PSYNC命令，用于在主从复制中实现断点续传。PSYNC命令允许从服务器（slave）在重新连接到主服务器（master）时，请求从上次复制中断的地方继续复制数据。
复制偏移量（replication offset）：主从服务器都会维护一个复制偏移量，这个偏移量记录了复制数据的位置。当从服务器重新连接到主服务器时，它会发送上次的复制偏移量给主服务器，请求从该位置继续复制。
master run id：每个主服务器都有一个唯一的run id，当主服务器重启后，这个id会改变。如果从服务器重启，它会失去之前的复制状态，因为run id保存在内存中，不持久化到磁盘。
内存缓冲区（in-memory backlog）：主服务器会为复制流维护一个内存缓冲区，用于存储最近一段时间的数据。这个缓冲区允许主服务器在网络中断后，从上次中断的地方继续发送数据给从服务器。
断点续传的条件：如果主从服务器的run id相同，并且从服务器请求的偏移量在内存缓冲区内有效，那么复制就会从上次中断的点开始继续。如果任一条件不满足，就会进行完全重新同步。
增量复制和全量复制：在断点续传中，如果从服务器请求的偏移量有效，主服务器会发送从该偏移量开始的增量更新给从服务器。如果偏移量无效（例如，从服务器重启或偏移量超出了内存缓冲区的范围），则主服务器会执行一次全量复制，即发送一个新的RDB快照给从服务器。
无磁盘化复制：在某些情况下，为了提高复制效率，Redis支持无磁盘化复制，即主服务器直接在内存中创建RDB快照，然后发送给从服务器，而不在本地磁盘上落地。

通过这些机制，Redis的断点续传功能确保了在网络中断或其他故障后，主从复制可以高效地恢复，从而提高了数据复制的可靠性和系统的稳定性。

二、Redis多实例主从复制的操作

Redis的多实例主从复制是指设置多个Redis实例，其中一个或多个作为主节点（master），其他的作为从节点（slave）。从节点可以复制主节点的数据，并提供读操作服务。以下是实现多实例主从复制的具体步骤：

1. 准备Redis实例

你需要多个Redis实例。这些可以是运行在不同物理服务器或者虚拟机上的独立Redis实例，也可以是在同一台服务器上通过不同端口运行的多个Redis进程。

2. 配置主节点

主节点不需要特别的配置来支持复制，但是你需要确保主节点的配置文件（通常是redis.conf）中的bind和port配置允许从节点连接。

3. 配置从节点

对于每个从节点，你需要在它的配置文件中设置以下参数：

slaveof <masterip> <masterport>：指定主节点的IP地址和端口。
masterauth <password>：如果主节点设置了密码，从节点需要这个参数来认证。

例如，如果你的主节点运行在192.168.1.100的6379端口上，并且没有密码保护，从节点的配置将如下所示：

slaveof 192.168.1.100 6379

如果主节点设置了密码mypassword，则配置如下：

slaveof 192.168.1.100 6379
masterauth mypassword

4. 启动所有实例

启动所有的Redis主从节点实例。你可以使用redis-server命令启动每个实例，并指定各自的配置文件。

redis-server /path/to/master.conf
redis-server /path/to/slave1.conf
redis-server /path/to/slave2.conf
...

5. 验证复制状态

复制开始后，从节点会自动从主节点同步数据。你可以使用INFO replication命令来检查复制的状态：

redis-cli -p 端口号 info replication

在输出中，你应该能看到从节点显示为主节点的slave状态，包括复制的延迟、偏移量等信息。

6. 读写分离

在多实例主从复制的环境中，通常所有的写操作都发送到主节点，而读操作可以发送到任何一个从节点。这可以通过你的应用程序逻辑来实现，或者使用一些支持读写分离的客户端库。

注意事项

数据一致性：在复制过程中，可能会有短暂的延迟，这意味着从节点的数据可能稍微落后于主节点。
故障转移：多实例主从复制不自动处理故障转移。如果需要故障转移功能，你可能需要使用Redis Sentinel或者设置一个代理层（如Twemproxy）。
资源消耗：每个从节点都会消耗额外的内存和带宽来维持与主节点的复制连接，尤其是在数据变化频繁时。

通过上述步骤，你可以设置一个多实例的主从复制架构，以提高Redis的读扩展性和数据的可用性。

取消主从复制

取消Redis的主从复制关系，可以通过以下步骤来实现：

停止从节点的复制：
在从节点上执行以下命令来停止复制过程：
```
SLAVEOF NO ONE
```
这个命令会停止从节点对主节点的复制，并使从节点变成一个独立的Redis服务器。
配置文件修改：
如果你的Redis配置是通过配置文件设置的，你需要编辑配置文件，移除或注释掉相关的slaveof和masterauth指令。
重启Redis服务：
修改配置文件后，需要重启Redis服务以使更改生效。重启命令取决于你的操作系统和Redis服务的运行方式，可能是：
```
redis-server /path/to/your/redis.conf
```
或者如果你使用的是服务管理器（如systemd），可以使用：
```
systemctl restart redis
```
验证复制状态：
重启后，你可以使用INFO replication命令来检查复制状态，确保从节点已经不再是任何主节点的从节点：
```
INFO replication
```