1. Überblick über die Master-Slave-Replikation
65 Brother: Mit RDB und AOF haben Sie keine Angst mehr vor Datenverlust aufgrund von Ausfallzeiten, aber wie erreichen Sie eine hohe Verfügbarkeit, wenn die Redis-Instanz ausfällt? Da eine Maschine ausgefallen ist und keinen Service bieten kann, was ist mit den anderen Maschinen? Kann es gelöst werden? Redis bietet einen Master-Slave-Modus, der durch Master-Slave-Replikation eine redundante Kopie der Daten auf andere Redis-Server kopiert. Ersterer wird als Master-Knoten (Master) und letzterer als Slave-Knoten (Slave) bezeichnet. Die Datenreplikation erfolgt in eine Richtung und kann nur vom Master-Knoten zum Slave-Knoten erfolgen. Standardmäßig ist jeder Redis-Server ein Master-Knoten. Ein Master-Knoten kann mehrere Slave-Knoten (oder keine Slave-Knoten) haben, ein Slave-Knoten kann jedoch nur einen Master-Knoten haben. 65 Bruder: Wie kann die Datenkonsistenz zwischen Master und Slave sichergestellt werden? Um die Konsistenz der Replikatdaten sicherzustellen, verwendet die Master-Slave-Architektur eine Methode zur Lese-/Schreibtrennung.- Lesevorgang: Sowohl die Master- als auch die Slave-Bibliothek können ausgeführt werden.
- Schreibvorgang: Die Master-Bibliothek führt ihn zuerst aus und synchronisiert dann den Schreibvorgang mit der Slave-Bibliothek.
- Fehlerbehebung: Wenn der Master-Knoten ausgefallen ist, können andere Knoten weiterhin Dienste bereitstellen.
- Lastausgleich: Der Master-Knoten stellt Schreibdienste bereit, und der Slave-Knoten stellt Lesedienste bereit, um den Druck zu teilen
Eckpfeiler der Hochverfügbarkeit: Ja Die Grundlage der Sentry- und Cluster-Implementierung ist der Eckpfeiler der Hochverfügbarkeit.
- 2. Master-Slave-Replikation einrichten
Die Aktivierung der Master-Slave-Replikation wird vollständig vom Slave-Knoten aus initiiert und erfordert nicht, dass wir etwas auf dem Master-Knoten tun.
65 Bruder: Wie baut man eine Master-Slave-Replikationsarchitektur auf? Die Beziehung zwischen der Master-Datenbank und der Slave-Datenbank kann über den Befehl „replicaof“ (slaveof wurde vor Redis 5.0 verwendet) hergestellt werden.
Es gibt drei Möglichkeiten, die Master-Slave-Replikation auf dem Slave-Knoten zu aktivieren:
Konfigurationsdatei
- Fügen Sie
-
zur Konfigurationsdatei von hinzu der Slave-Server
Startbefehl
replicaof <masterip> <masterport></masterport></masterip> -
启动命令
redis-server 启动命令后面加入
--replicaof <masterip> <masterport></masterport></masterip> -
客户端命令
启动多个 Redis 实例后，直接通过客户端执行命令：
redis-server Fügen Siereplicaof <masterip> <masterport></masterport></masterip>--replicaof <masterip> <masterport></masterport></masterip>hinzu
replicaof <masterip> <masterport></masterport></masterip>replicaof <masterip> <masterport></masterport></masterip>, dann wird die Redis-Instanz ein Slave-Knoten. 🎜🎜🎜🎜Angenommen, es gibt Instanz 1 (172.16.88.1), Instanz 2 (172.16.88.2) und Instanz 3 (172.16.88.3). Führen Sie die folgenden Befehle für Instanz 2 und Instanz 3 aus 3 wird sein Es wird zur Slave-Bibliothek von Instanz 1 und Instanz 1 wird zum Master. 🎜replicaof 172.16.88.1 6379
3. Master-Slave-Replikationsprinzip
Sobald der Master-Slave-Bibliotheksmodus die Lese-Schreib-Trennung übernimmt, werden alle Datenschreibvorgänge nur in der Master-Bibliothek ausgeführt, ohne dass drei Instanzen koordiniert werden müssen.
Nachdem die Master-Datenbank über die neuesten Daten verfügt, wird sie mit der Slave-Datenbank synchronisiert, sodass die Daten in der Master- und Slave-Datenbank konsistent sind.
65 Bruder: Wie wird die Master-Slave-Datenbanksynchronisierung abgeschlossen? Werden die Daten der Master-Datenbank auf einmal an die Slave-Datenbank übertragen oder werden sie stapelweise synchronisiert? Wie synchronisiert man im Normalbetrieb? Bleiben die Daten nach der Wiederherstellung der Verbindung konsistent, wenn das Netzwerk zwischen der Master- und der Slave-Bibliothek getrennt wird?
65 Bruder, du hast so viele Fragen. Die Synchronisierung ist in drei Situationen unterteilt:
Die erste vollständige Kopie der Master-Slave-Bibliothek;
Synchronisierung während des normalen Betriebs der Master-Slave-Bibliothek;
- Master-Slave-Bibliothek Netzwerktrennung und Synchronisierung der erneuten Verbindung.
Die erste vollständige Kopie der Master-Slave-Datenbank
65 Bruder: Mir ist so schwindelig. Beginnen wir mit der ersten Synchronisierung zwischen der Master-Slave-Datenbank.Der erste Kopiervorgang der Master-Slave-Bibliothek kann grob in drei Phasen unterteilt werden: die Phase des Verbindungsaufbaus (d. h. die Vorbereitungsphase), die Phase der Synchronisierung von Daten von der Master-Bibliothek zur Slave-Bibliothek und die Phase des Senden neuer Schreibbefehle während der Synchronisierung an die Slave-Bibliothek
Schauen Sie sich einfach das Bild oben an, um einen Gesamtüberblick zu erhalten, der später im Detail vorgestellt wird.
Verbindung herstellen
Die Hauptfunktion dieser Phase besteht darin, eine Verbindung zwischen den Master- und Slave-Knoten herzustellen, um die vollständige Datensynchronisierung vorzubereiten.Die Slave-Bibliothek stellt eine Verbindung mit der Master-Bibliothek her, sendet den psync-Befehl und teilt der Master-Bibliothek mit, dass die Synchronisierung stattfinden wird Sklavenbibliotheken werden beginnen.
65 Bruder: Woher kennt die Slave-Datenbank die Informationen der Master-Datenbank und stellt eine Verbindung her? Nachdem die IP und der Port des Master-Knotens im Replikatkonfigurationselement in der Konfigurationsdatei des Slave-Knotens konfiguriert wurden, weiß der Slave-Knoten, mit welchem Master-Knoten er eine Verbindung herstellen möchte. Der Slave-Knoten verwaltet zwei Felder, Masterhost und Masterport, die zum Speichern der IP- und Portinformationen des Masterknotens verwendet werden. Die Slave-Bibliothek führtreplicaof aus und sendet den Befehl psync, der angibt, dass die Datensynchronisierung durchgeführt werden soll. Nach Erhalt des Befehls startet die Master-Bibliothek die Replikation gemäß den Parametern . Der Befehl enthält zwei Parameter: runIDreplicaof 并发送 psync 命令，表示要执行数据同步，主库收到命令后根据参数启动复制。命令包含了主库的 runID 和 复制进度 offset 两个参数。
- runID：每个 Redis 实例启动都会自动生成一个 唯一标识 ID，第一次主从复制，还不知道主库 runID，参数设置为 「?」。
- offset：第一次复制设置为 -1，表示第一次复制，记录复制进度偏移量。
主库收到 psync 命令后，会用 FULLRESYNC 响应命令带上两个参数：主库 runID 和主库目前的复制进度 offset，返回给从库。从库收到响应后，会记录下这两个参数。
FULLRESYNC 响应表示第一次复制采用的全量复制，也就是说，主库会把当前所有的数据都复制给从库。
主库同步数据给从库
第二阶段
master 执行 bgsave命令生成 RDB 文件，并将文件发送给从库，同时主库为每一个 slave 开辟一块 replication buffer 缓冲区记录从生成 RDB 文件开始收到的所有写命令。
从库收到 RDB 文件后保存到磁盘，并清空当前数据库的数据，再加载 RDB 文件数据到内存中。
发送新写命令到从库
第三阶段
从节点加载 RDB 完成后，主节点将 replication buffer 缓冲区的数据发送到从节点，Slave 接收并执行，从节点同步至主节点相同的状态。
65 哥：主库将数据同步到从库过程中，可以正常接受请求么？
主库不会被阻塞，Redis 作为唯快不破的男人，怎么会动不动就阻塞呢。
在生成 RDB 文件之后的写操作并没有记录到刚刚的 RDB 文件中，为了保证主从库数据的一致性，所以主库会在内存中使用一个叫 replication buffer 记录 RDB 文件生成后的所有写操作。
65 哥：为啥从库收到 RDB 文件后要清空当前数据库？
因为从库在通过 replcaof der Hauptbibliothek und
.
-
runID
: Jede Redis-Instanz generiert beim Start automatisch eine eindeutige Identifikations-ID. Bei der ersten Master-Slave-Replikation ist die Hauptdatenbank-RunID noch nicht bekannt und der Parameter ist auf „?“ gesetzt. .
Offset: Die erste Kopie wird auf -1 gesetzt, was die erste Kopie angibt und den Offset des Kopierfortschritts aufzeichnet.
🎜🎜Nachdem die Hauptbibliothek den psync-Befehl empfangen hat, verwendet sie 🎜FULLRESYNC, um auf den Befehl mit zwei Parametern zu antworten: der RunID der Hauptbibliothek und dem aktuellen Kopierfortschrittsoffset der Hauptbibliothek und gibt ihn an die Slave-Bibliothek zurück 🎜. Nach Erhalt der Antwort von der Bibliothek werden diese beiden Parameter aufgezeichnet. Die Antwort 🎜🎜🎜FULLRESYNC zeigt an, dass die erste Replikation die vollständige Replikation übernimmt🎜, das heißt, die Master-Datenbank kopiert alle aktuellen Daten in die Slave-Datenbank. 🎜🎜🎜Die Master-Bibliothek synchronisiert Daten mit der Slave-Bibliothek. In der zweiten Phase führt der Master den Befehlbgsave aus, um eine RDB-Datei zu generieren, und sendet die Datei gleichzeitig an die Slave-Bibliothek , die Master-Bibliothek🎜stellt Daten für jeden Slave bereit. Erstellen Sie einen Replikationspuffer, um alle seit der Generierung der RDB-Datei empfangenen Schreibbefehle aufzuzeichnen. 🎜🎜Nachdem Sie die RDB-Datei von der Bibliothek erhalten haben, speichern Sie sie auf der Festplatte, löschen Sie die Daten der aktuellen Datenbank und laden Sie dann die RDB-Dateidaten in den Speicher. 🎜🎜🎜Senden Sie einen neuen Schreibbefehl an die Slave-Bibliothek🎜🎜🎜Die dritte Phase🎜🎜Nachdem der Slave-Knoten die RDB geladen hat, sendet der Master-Knoten die Daten im Replikationspuffer an den Slave-Knoten, der Slave empfängt sie und führt sie aus. und der Slave-Knoten synchronisiert sich mit dem Master-Knoten Gleicher Status. 🎜🎜65 Bruder: Kann die Anfrage normal angenommen werden, wenn die Master-Datenbank Daten mit der Slave-Datenbank synchronisiert? 🎜🎜Die Hauptdatenbank wird nicht blockiert. Als Mann, der nur schnell und unzerbrechlich ist, wie kann Redis auf Schritt und Tritt blockiert werden? 🎜🎜Die Schreibvorgänge nach dem Generieren der RDB-Datei werden derzeit nicht in der RDB-Datei aufgezeichnet. Um die Konsistenz der Master-Slave-Datenbankdaten sicherzustellen, verwendet die Master-Datenbank einen Replikationspuffer im Speicher, um alle nachfolgenden Schreibvorgänge aufzuzeichnen Die RDB-Datei wird generiert. 🎜🎜65 Bruder: Warum müssen wir die aktuelle Datenbank löschen, nachdem wir die RDB-Datei von der Bibliothek erhalten haben? 🎜🎜Da die Slave-Bibliothek möglicherweise andere Daten speichert, bevor sie mit der Synchronisierung mit der Master-Bibliothek über den Befehl replcaof beginnt, um den Einfluss zwischen den Master- und Slave-Daten zu verhindern. 🎜🎜Was genau ist Replikationspuffer? 🎜🎜Ein auf der Masterseite erstellter Puffer. Die gespeicherten Daten sind alle Masterdaten-Schreibvorgänge in den folgenden drei Zeiträumen. 🎜🎜1) Der Schreibvorgang, wenn der Master bgsave ausführt, um die RDB zu generieren; 🎜🎜2) Der Schreibvorgang, wenn der Master die RDB zur Netzwerkübertragung sendet; 🎜🎜3) Die Schreiboperation, wenn der Slave die RDB lädt Datei und stellt die Daten im Speicher wieder her. 🎜Redis 和客户端通信也好，和从库通信也好，Redis 都分配一个内存 buffer 进行数据交互，客户端就是一个 client，从库也是一个 client，我们每个 client 连上 Redis 后，Redis 都会分配一个专有 client buffer，所有数据交互都是通过这个 buffer 进行的。
Master 先把数据写到这个 buffer 中，然后再通过网络发送出去，这样就完成了数据交互。
不管是主从在增量同步还是全量同步时，master 会为其分配一个 buffer ，只不过这个 buffer 专门用来传播写命令到从库，保证主从数据一致，我们通常把它叫做 replication buffer。
replication buffer 太小会引发的问题：
replication buffer 由 client-output-buffer-limit slave 设置，当这个值太小会导致主从复制连接断开。
1）当 master-slave 复制连接断开，master 会释放连接相关的数据。replication buffer 中的数据也就丢失了，此时主从之间重新开始复制过程。
2）还有个更严重的问题，主从复制连接断开，导致主从上出现重新执行 bgsave 和 rdb 重传操作无限循环。
当主节点数据量较大，或者主从节点之间网络延迟较大时，可能导致该缓冲区的大小超过了限制，此时主节点会断开与从节点之间的连接；
这种情况可能引起全量复制 -> replication buffer 溢出导致连接中断 -> 重连 -> 全量复制 -> replication buffer 缓冲区溢出导致连接中断……的循环。
具体详情：[top redis headaches for devops – replication buffer]
因而推荐把 replication buffer 的 hard/soft limit 设置成 512M。
config set client-output-buffer-limit "slave 536870912 536870912 0"
65 哥：主从库复制为何不使用 AOF 呢？相比 RDB 来说，丢失的数据更少。
这个问题问的好，原因如下：
RDB 文件是二进制文件，网络传输 RDB 和写入磁盘的 IO 效率都要比 AOF 高。
从库进行数据恢复的时候，RDB 的恢复效率也要高于 AOF。
增量复制
65 哥：主从库间的网络断了咋办？断开后要重新全量复制么？
在 Redis 2.8 之前，如果主从库在命令传播时出现了网络闪断，那么，从库就会和主库重新进行一次全量复制，开销非常大。
从 Redis 2.8 开始，网络断了之后，主从库会采用增量复制的方式继续同步。
增量复制：用于网络中断等情况后的复制，只将中断期间主节点执行的写命令发送给从节点，与全量复制相比更加高效。
repl_backlog_buffer
断开重连增量复制的实现奥秘就是 repl_backlog_buffer 缓冲区，不管在什么时候 master 都会将写指令操作记录在 repl_backlog_buffer 中，因为内存有限， repl_backlog_buffer 是一个定长的环形数组，如果数组内容满了，就会从头开始覆盖前面的内容。
master 使用 master_repl_offset记录自己写到的位置偏移量，slave 则使用 slave_repl_offset记录已经读取到的偏移量。
master 收到写操作，偏移量则会增加。从库持续执行同步的写指令后，在 repl_backlog_buffer 的已复制的偏移量 slave_repl_offset 也在不断增加。
正常情况下，这两个偏移量基本相等。在网络断连阶段，主库可能会收到新的写操作命令，所以 master_repl_offset会大于 slave_repl_offset。
当主从断开重连后，slave 会先发送 psync 命令给 master，同时将自己的 runID，slave_repl_offset发送给 master。
master 只需要把 master_repl_offset与 slave_repl_offset之间的命令同步给从库即可。
增量复制执行流程如下图：
65 哥：repl_backlog_buffer 太小的话从库还没读取到就被 Master 的新写操作覆盖了咋办？
我们要想办法避免这个情况，一旦被覆盖就会执行全量复制。我们可以调整 repl_backlog_size 这个参数用于控制缓冲区大小。计算公式：
repl_backlog_buffer = second * write_size_per_second
second：从服务器断开重连主服务器所需的平均时间；
write_size_per_second：master 平均每秒产生的命令数据量大小（写命令和数据大小总和）；
例如，如果主服务器平均每秒产生 1 MB 的写数据，而从服务器断线之后平均要 5 秒才能重新连接上主服务器，那么复制积压缓冲区的大小就不能低于 5 MB。
为了安全起见，可以将复制积压缓冲区的大小设为2 * second * write_size_per_second，这样可以保证绝大部分断线情况都能用部分重同步来处理。
基于长连接的命令传播
65 哥：完成全量同步后，正常运行过程如何同步呢？
当主从库完成了全量复制，它们之间就会一直维护一个网络连接，主库会通过这个连接将后续陆续收到的命令操作再同步给从库，这个过程也称为基于长连接的命令传播，使用长连接的目的就是避免频繁建立连接导致的开销。
在命令传播阶段，除了发送写命令，主从节点还维持着心跳机制：PING 和 REPLCONF ACK。
主->从：PING
每隔指定的时间，主节点会向从节点发送 PING 命令，这个 PING 命令的作用，主要是为了让从节点进行超时判断。
从->主：REPLCONF ACK
在命令传播阶段，从服务器默认会以每秒一次的频率，向主服务器发送命令：
REPLCONF ACK <replication_offset></replication_offset>
其中 replication_offset 是从服务器当前的复制偏移量。发送 REPLCONF ACK 命令对于主从服务器有三个作用：
检测主从服务器的网络连接状态。
辅助实现 min-slaves 选项。
检测命令丢失, 从节点发送了自身的 slave_replication_offset，主节点会用自己的 master_replication_offset 对比，如果从节点数据缺失，主节点会从
repl_backlog_buffer缓冲区中找到并推送缺失的数据。注意，offset 和 repl_backlog_buffer 缓冲区，不仅可以用于部分复制，也可以用于处理命令丢失等情形；区别在于前者是在断线重连后进行的，而后者是在主从节点没有断线的情况下进行的。
如何确定执行全量同步还是部分同步？
在 Redis 2.8 及以后，从节点可以发送 psync 命令请求同步数据，此时根据主从节点当前状态的不同，同步方式可能是全量复制或部分复制。本文以 Redis 2.8 及之后的版本为例。
关键就是 psync的执行：
-
从节点根据当前状态，发送
psync命令给 master：- 如果从节点从未执行过
replicaof，则从节点发送psync ? -1，向主节点发送全量复制请求； - 如果从节点之前执行过
replicaof则发送psync <runid> <offset></offset></runid>, runID 是上次复制保存的主节点 runID，offset 是上次复制截至时从节点保存的复制偏移量。
- 如果从节点从未执行过
-
主节点根据接受到的
psync命令和当前服务器状态，决定执行全量复制还是部分复制：- runID 与从节点发送的 runID 相同，且从节点发送的
slave_repl_offset之后的数据在repl_backlog_buffer缓冲区中都存在，则回复CONTINUE，表示将进行部分复制，从节点等待主节点发送其缺少的数据即可； - runID 与从节点发送的 runID 不同，或者从节点发送的 slave_repl_offset 之后的数据已不在主节点的
repl_backlog_buffer缓冲区中 (在队列中被挤出了)，则回复从节点FULLRESYNC <runid> <offset></offset></runid>，表示要进行全量复制，其中 runID 表示主节点当前的 runID，offset 表示主节点当前的 offset，从节点保存这两个值，以备使用。
- runID 与从节点发送的 runID 相同，且从节点发送的
一个从库如果和主库断连时间过长，造成它在主库 repl_backlog_buffer 的 slave_repl_offset 位置上的数据已经被覆盖掉了，此时从库和主库间将进行全量复制。
总结下
每个从库会记录自己的 slave_repl_offset，每个从库的复制进度也不一定相同。
在和主库重连进行恢复时，从库会通过 psync 命令把自己记录的 slave_repl_offset 发给主库，主库会根据从库各自的复制进度，来决定这个从库可以进行增量复制，还是全量复制。
Replikationspuffer und repl_backlog
Replikationspuffer entspricht jedem Slave und wird durch
config set client-output-buffer-limit Slavefestgelegt.config set client-output-buffer-limit slave设置。repl_backlog_buffer是一个环形缓冲区，整个 master 进程中只会存在一个，所有的 slave 公用。repl_backlog 的大小通过 repl-backlog-size 参数设置，默认大小是 1M，其大小可以根据每秒产生的命令、（master 执行 rdb bgsave） +（ master 发送 rdb 到 slave） + （slave load rdb 文件）时间之和来估算积压缓冲区的大小，repl-backlog-size 值不小于这两者的乘积。
总的来说，replication buffer 是主从库在进行全量复制时，主库上用于和从库连接的客户端的 buffer，而 repl_backlog_buffer 是为了支持从库增量复制，主库上用于持续保存写操作的一块专用 buffer。
repl_backlog_buffer 是一块专用 buffer，在 Redis 服务器启动后，开始一直接收写操作命令，这是所有从库共享的。主库和从库会各自记录自己的复制进度，所以，不同的从库在进行恢复时，会把自己的复制进度（slave_repl_offset
repl_backlog_buffer ist ein Ringpuffer, im gesamten Master-Prozess gibt es nur einen und er ist allen Slaves gemeinsam. Die Größe von repl_backlog wird durch den Parameter repl-backlog-size festgelegt. Die Größe kann auf den pro Sekunde generierten Befehlen basieren (Master führt RDB-BGSAVE aus) + (Master sendet RDB an Slave). Laden der RDB-Datei) und um die Größe des Backlog-Puffers abzuschätzen, ist der Wert repl-backlog-size nicht kleiner als das Produkt aus beiden. 
Im Allgemeinen ist Replikationspuffer der Puffer, den der Client auf der Master-Bibliothek verwendet, um eine Verbindung zur Slave-Bibliothek herzustellen, wenn die Master-Slave-Bibliothek eine vollständige Replikation durchführt, und repl_backlog_buffer code> ist ein dedizierter Puffer in der Hauptbibliothek, der zum kontinuierlichen Speichern von Schreibvorgängen verwendet wird, um die inkrementelle Replikation von der Slave-Bibliothek zu unterstützen.
repl_backlog_buffer ist ein dedizierter Puffer. Nachdem der Redis-Server gestartet wurde, beginnt er, Schreiboperationsbefehle zu empfangen. Dieser wird von allen Slave-Bibliotheken gemeinsam genutzt. Die Master-Bibliothek und die Slave-Bibliothek zeichnen daher jeweils ihren eigenen Replikationsfortschritt auf. Wenn verschiedene Slave-Bibliotheken wiederhergestellt werden, senden sie daher ihren eigenen Replikationsfortschritt (slave_repl_offset) an die Master-Bibliothek und die Master-Bibliothek kann mit der Master-Bibliothek kommunizieren. as im Bild gezeigt:
4. Szenario der Master-Slave-Replikation: Wird der Slave-Knoten abgelaufene Daten löschen?
Das ist eine gute Frage. Aus Gründen der Datenkonsistenz zwischen Master- und Slave-Knoten löschen die Slave-Knoten Daten nicht aktiv. Wir wissen, dass Redis über zwei Löschstrategien verfügt:
- Verzögertes Löschen: Wenn der Client die entsprechenden Daten abfragt, stellt Redis fest, ob die Daten abgelaufen sind, und löscht sie, wenn sie ablaufen.
- Regelmäßiges Löschen: Redis löscht abgelaufene Daten durch geplante Aufgaben.
- 65 Bruder: Wird der Client abgelaufene Daten lesen, indem er Daten vom Slave-Knoten liest?
Ab Redis 3.2 wird beim Lesen von Daten vom Knoten zunächst festgestellt, ob die Daten abgelaufen sind. Wenn es abläuft, wird es nicht an den Kunden zurückgegeben und die Daten werden gelöscht.4.2 Speichergrößenbeschränkung für eine einzelne Maschine
Wenn der Redis-Einzelmaschinenspeicher 10 GB erreicht, beträgt die Synchronisierungszeit eines Slave-Knotens mehrere Minuten. Wenn mehr Slave-Knoten vorhanden sind, ist die Wiederherstellungsgeschwindigkeit langsamer. Wenn die Leselast des Systems sehr hoch ist und der Slave-Knoten in diesem Zeitraum keine Dienste bereitstellen kann, wird das System stark belastet.
Wenn die Datenmenge zu groß ist, dauert es zu lange, bis der Master-Knoten die RDB-Datei während der vollständigen Replikationsphase gegabelt und gespeichert hat. Der Slave-Knoten kann lange Zeit keine Daten empfangen Die Synchronisierung zwischen den Master- und Slave-Knoten kann auch in
Vollständige Replikation -> Zeitüberschreitung fallen. Ein Zyklus, der eine Replikationsunterbrechung verursacht -> Neuverbindung -> Vollständige Replikation -> Zeitüberschreitung verursacht eine Replikationsunterbrechung.Darüber hinaus sollte die absolute Menge des eigenständigen Speichers des Masterknotens nicht zu groß sein, und der Anteil des Hostspeichers, den er einnimmt, sollte nicht zu groß sein: Am besten ist es, nur 50 % – 65 % davon zu nutzen Speicher, wobei 30 % bis 45 % des Speichers für die Ausführung des bgsave-Befehls und die Erstellung eines Kopierpuffers usw. übrig bleiben.
Zusammenfassung
Die Rolle der Master-Slave-Replikation: AOF- und RDB-Binärdateien sorgen für eine schnelle Datenwiederherstellung während Ausfallzeiten und verhindern Datenverlust so weit wie möglich. Da die Dienste nach einer Ausfallzeit jedoch immer noch nicht bereitgestellt werden konnten, entwickelte sich eine Master-Slave-Architektur und eine Lese-/Schreib-Trennung.
- Prinzip der Master-Slave-Replikation: Verbindungsaufbauphase, Datensynchronisationsphase, Befehlsausbreitungsphase; die Datensynchronisationsphase ist in vollständige Replikation und teilweise Replikation unterteilt, zwischen denen es PING- und REPLCONF-ACK-Befehle gibt Master- und Slave-Knoten führen Heartbeats zur gegenseitigen Erkennung durch.
- Obwohl die Master-Slave-Replikation Probleme wie Datenredundanz, Fehlerwiederherstellung und Leselastausgleich löst oder lindert, sind ihre Mängel immer noch offensichtlich: Fehlerwiederherstellung kann nicht automatisiert werden; die Speicherkapazität ist nicht begrenzt durch eine einzelne Maschine; Die Lösung dieser Probleme erfordert die Hilfe von Sentinels und Clustern, die ich in den folgenden Artikeln vorstellen werde.
65 Bruder: Deine Bilder sind wirklich wunderschön und der Inhalt ist gut. Ich möchte sie sammeln, liken, lesen und teilen. Lassen Sie weitere herausragende Entwickler gemeinsame Fortschritte sehen!
Weitere Kenntnisse zum Thema Programmierung finden Sie unter:
! !
