Detaillierte Erläuterung von Redis RDB und AOF

Redis verfügt über zwei Persistenzlösungen: RDB (Redis DataBase) und AOF (Append Only File). Wenn Sie RDB und AOF schnell verstehen und verwenden möchten, können Sie direkt zum Ende des Artikels springen, um die Zusammenfassung zu lesen. In diesem Kapitel werden Konfigurationsdateien, Möglichkeiten zum Auslösen von Snapshots, Datenwiederherstellungsvorgänge, Demonstrationen von Befehlsvorgängen sowie Vor- und Nachteile verwendet, um die wichtigsten Kenntnisse über die Persistenz von Redis zu erlernen. Dieser Artikel enthält hauptsächlich eine detaillierte Analyse der beiden Persistenzlösungen von Redis, RDB und AOF. Wir hoffen, dass die von uns zusammengestellten Inhalte jedem helfen können, diese beiden Lösungen besser zu verstehen.

Detaillierte Erklärung zu RDB

RDB ist die Standard-Persistenzlösung von Redis. Wenn innerhalb des angegebenen Zeitintervalls eine bestimmte Anzahl von Schreibvorgängen ausgeführt wird, werden die Daten im Speicher auf die Festplatte geschrieben. Das heißt, im angegebenen Verzeichnis wird eine Datei „dump.rdb“ generiert. Durch einen Neustart von Redis werden die Daten durch Laden der Datei dump.rdb wiederhergestellt.

Verstehen Sie RDB aus der Konfigurationsdatei

Öffnen Sie die Datei redis.conf und suchen Sie den entsprechenden Inhalt von SNAPSHOTTING
1 RDB-Kernregelkonfiguration (wichtige Punkte)

save <seconds> <changes>
# save ""
save 900 1
save 300 10
save 60 10000

Erläuterung: db0b120becc9d7d78b19e7e5164edf1c speichern 1d2932771077f85c199c63f10e25ae49, die Daten im Speicher mit der Festplatte synchronisieren, wenn die Bedingungen erfüllt sind traf. Die standardmäßige offizielle Werkskonfiguration sieht vor, dass bei 1 Änderung innerhalb von 900 Sekunden, 10 Änderungen innerhalb von 300 Sekunden und 10.000 Änderungen innerhalb von 60 Sekunden der Daten-Snapshot im Speicher auf die Festplatte geschrieben wird.

Wenn Sie die RDB-Lösung nicht verwenden möchten, können Sie den Kommentar „Speichern“ und die folgenden drei Kommentare öffnen.

2 Geben Sie den lokalen Datenbankdateinamen an, normalerweise den Standard-Dump.rdb

dbfilename dump.rdb

3 Geben Sie den lokalen Datenbankspeicher an Verzeichnis, verwenden Sie im Allgemeinen die Standardkonfiguration

dir ./

4, um die Datenkomprimierung standardmäßig zu aktivieren

rdbcompression yes

Erläuterung: Konfigurieren Sie, ob Daten beim Speichern in der lokalen Datenbank komprimiert werden sollen. Der Standardwert ist „Ja“. Redis verwendet die LZF-Komprimierung, nimmt jedoch etwas CPU-Zeit in Anspruch. Wenn diese Option deaktiviert ist, wird die Datenbankdatei sehr groß. Es wird empfohlen, es einzuschalten.

RDB-Snapshot auslösen

1 Die angegebene Anzahl von Schreibvorgängen innerhalb des angegebenen Zeitintervalls ausführen

2 Speichern ausführen (blockieren, Just Speichern Sie den Snapshot und warten Sie auf den Rest) oder verwenden Sie den bgsave-Befehl (asynchron)

3, um den Befehl „flushall“ auszuführen, um alle Daten in der Datenbank zu löschen, was von geringer Bedeutung ist.

4 Führen Sie den Befehl zum Herunterfahren aus, um sicherzustellen, dass der Server normal heruntergefahren wird, ohne dass Daten verloren gehen, was von geringer Bedeutung ist.

Daten über RDB-Dateien wiederherstellen

Kopieren Sie die Datei dump.rdb in das bin-Verzeichnis des Redis-Installationsverzeichnisses und starten Sie den Redis-Dienst neu. Bei der tatsächlichen Entwicklung wird im Allgemeinen der Festplattenschaden der physischen Maschine berücksichtigt und Backup dump.rdb ausgewählt. Sie können es anhand der folgenden Betriebsdemonstration erleben.

Vor- und Nachteile von RDB

Vorteile:

1 Geeignet für die Wiederherstellung großer Datenmengen.

2 Wenn das Unternehmen keine hohen Anforderungen an Datenintegrität und -konsistenz stellt, ist RDB eine gute Wahl.

Nachteile:

1 Die Integrität und Konsistenz der Daten ist nicht hoch, da die RDB möglicherweise während der letzten Sicherung ausgefallen ist.

2 Belegt während der Sicherung Speicher, da Redis während der Sicherung unabhängig einen Unterprozess erstellt und Daten in eine temporäre Datei schreibt (zu diesem Zeitpunkt sind die Daten im Speicher doppelt so groß wie die ursprüngliche Größe). Schließlich , ersetzen Sie die vorherige Sicherungsdatei durch die temporäre Datei.

Daher ist es sinnvoller, Redis-Persistenz und Datenwiederherstellung mitten in der Nacht auszuführen.

Betriebsdemonstration

[root@itdragon bin]# vim redis.conf
save 900 1
save 120 5
save 60 10000
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set key1 value1
OK
127.0.0.1:6379> set key2 value2
OK
127.0.0.1:6379> set key3 value3
OK
127.0.0.1:6379> set key4 value4
OK
127.0.0.1:6379> set key5 value5
OK
127.0.0.1:6379> set key6 value6
OK
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# cp dump.rdb dump_bk.rdb
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> FLUSHALL 
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# cp dump_bk.rdb dump.rdb
cp: overwrite `dump.rdb'? y
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "key5"
2) "key1"
3) "key3"
4) "key4"
5) "key6"
6) "key2"

Schritt 1: vim ändert die Persistenzkonfigurationszeit, wenn sie innerhalb von 120 fünfmal geändert wird Sekunden Bleiben einmal bestehen.

Schritt 2: Starten Sie den Dienst neu, damit die Konfiguration wirksam wird.

Schritt 3: Legen Sie jeweils 5 Schlüssel fest. Nach zwei Minuten wird automatisch eine dump.rdb-Datei im aktuellen Verzeichnis von bin generiert. (Setzen Sie Schlüssel6, um zu überprüfen, ob das Herunterfahren einen RDB-Snapshot auslösen kann)

Schritt 4: Erstellen Sie eine Sicherungskopie der aktuellen dump.rdb (Simulation der Online-Arbeit).

Schritt 5: Führen Sie den FLUSHALL-Befehl aus, um die Datenbankdaten zu löschen (Datenverlust simulieren).

Schritt 6: Starten Sie den Redis-Dienst neu und stellen Sie Daten wieder her ... Huh? ? ? ? (′◔ ‸◔`). Die Daten sind leer? ? ? ? Denn FLUSHALL hat auch die Funktion, RDB-Snapshots auszulösen.

Schritt 7: Ersetzen Sie das Backup dump_bk.rdb durch dump.rdb und dann redis.

Hinweis: Die Befehle SHUTDOWN und FLUSHALL lösen RDB-Snapshots aus. Bitte beachten Sie.

Andere Befehle:

keys * Passen Sie alle Schlüssel in der Datenbank an. Speichern Sie den Block, um einen RDB-Snapshot zum Sichern der Daten auszulösen. FLUSHALL Löschen Sie die Daten des gesamten Redis-Servers (selten verwendet). SHUTDOWN Herunterfahren und verlassen (selten) Verwendung)

Detaillierte AOF-Erklärung

AOF: Redis ist standardmäßig nicht aktiviert. Es scheint die Mängel von RDB (Dateninkonsistenz) auszugleichen und verwendet daher die Form eines Protokolls, um jeden Schreibvorgang aufzuzeichnen und an die Datei anzuhängen. Wenn Redis neu gestartet wird, werden die Schreibanweisungen basierend auf dem Inhalt der Protokolldatei von vorne nach hinten ausgeführt, um die Datenwiederherstellungsarbeiten abzuschließen.

Verstehen Sie AOF aus der Konfigurationsdatei

Öffnen Sie die Datei redis.conf und suchen Sie den entsprechenden Inhalt von APPEND ONLY MODE
1 Redis ist standardmäßig geschlossen. Um es zu aktivieren, müssen Sie dies tun Nein manuell in Ja ändern

appendonly yes

2 指定本地数据库文件名，默认值为 appendonly.aof

appendfilename "appendonly.aof"

 

3 指定更新日志条件

# appendfsync always
appendfsync everysec
# appendfsync no

 

解说：

always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）

everysec：出厂默认推荐，每秒异步记录一次（默认值）

no：不同步

4 配置重写触发机制

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

 

解说：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。

触发AOF快照

根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。

根据AOF文件恢复数据

正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。从下面的操作演示中体会。

AOF的重写机制

前面也说到了，AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。

重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（你都那么大了，我还去读你？？？ o(ﾟДﾟ)っ傻啊！）。最后替换旧的aof文件。

触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。

AOF 的优缺点

优点：数据的完整性和一致性更高

缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。

操作演示

[root@itdragon bin]# vim appendonly.aof
appendonly yes
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set keyAOf valueAof
OK
127.0.0.1:6379> FLUSHALL 
OK
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "keyAOf"
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# vim appendonly.aof
fjewofjwojfoewifjowejfwf
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> QUIT
[root@itdragon bin]# redis-check-aof --fix appendonly.aof 
'x    3e: Expected prefix '*', got: '
AOF analyzed: size=92, ok_up_to=62, diff=30
This will shrink the AOF from 92 bytes, with 30 bytes, to 62 bytes
Continue? [y/N]: y
Successfully truncated AOF
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "keyAOf"

第一步：修改配置文件，开启AOF持久化配置。

第二步：重启Redis服务，并进入Redis 自带的客户端中。

第三步：保存值，然后模拟数据丢失，关闭Redis服务。

第四步：重启服务，发现数据恢复了。（额外提一点：有教程显示FLUSHALL 命令会被写入AOF文件中，导致数据恢复失败。我安装的是redis-4.0.2没有遇到这个问题）。

第五步：修改appendonly.aof，模拟文件异常情况。

第六步：重启 Redis 服务失败。这同时也说明了，RDB和AOF可以同时存在，且优先加载AOF文件。

第七步：校验appendonly.aof 文件。重启Redis 服务后正常。

补充点：aof 的校验是通过 redis-check-aof 文件，那么rdb 的校验是不是可以通过 redis-check-rdb 文件呢？？？

总结 Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。 RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。 Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。

AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。 Redis 针对 AOF文件大的问题，提供重写的瘦身机制。若只打算用Redis 做缓存，可以关闭持久化。若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。

相关推荐：

深入剖析 redis RDB 持久化策略

Redis的持久化--RDB的工作原理及引发的问题

深入剖析 redis AOF 持久化策略

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung von Redis RDB und AOF. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!