Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Wesentliche Unterschiede zwischen dem Verhalten und der Kompatibilität der Engine-Versionen mit Redis OSS
Wichtig
Auf der folgenden Seite sind alle Inkompatibilitätsunterschiede zwischen den Versionen aufgeführt und alle Aspekte angegeben, die Sie beim Upgrade auf neuere Versionen beachten sollten. In dieser Liste sind alle Probleme bezüglich Versionsinkompatibilitäten aufgeführt, die beim Upgrade auftreten können.
Sie können direkt von Ihrer aktuellen Redis OSS-Version auf die neueste verfügbare Redis OSS-Version aktualisieren, ohne dass sequentielle Upgrades erforderlich sind. Sie können beispielsweise direkt von Redis OSS Version 3.0 auf Version 7.0 aktualisieren.
Redis OSS-Versionen werden mit einer semantischen Version identifiziert, die aus einer Haupt-, Neben- und einer Patch-Komponente besteht. In Redis OSS 4.0.10 ist die Hauptversion beispielsweise 4, die Nebenversion 0 und die Patch-Version 10. Diese Werte werden im Allgemeinen basierend auf den folgenden Konventionen schrittweise erhöht:
-
Hauptversionen sind für API-inkompatible Änderungen vorgesehen
-
Nebenversionen sind für neue Funktionen vorgesehen, die abwärtskompatibel hinzugefügt wurden
-
Patch-Versionen sind für abwärtskompatible Bugfixes und nicht funktionale Änderungen vorgesehen
Wir empfehlen, immer die neueste Patch-Version innerhalb einer bestimmten Haupt-/Nebenversion zu verwenden, um die neuesten Leistungs - und Stabilitätsverbesserungen zu erzielen. Ab ElastiCache Version 6.0 für Redis OSS ElastiCache wird eine einzige Version für jede Redis OSS-Nebenversion angeboten, anstatt mehrere Patch-Versionen anzubieten. ElastiCacheverwaltet automatisch die Patch-Version Ihrer laufenden Cache-Cluster und sorgt so für eine verbesserte Leistung und erhöhte Sicherheit.
Wir empfehlen außerdem, regelmäßig auf die neueste Hauptversion zu aktualisieren, da die meisten wichtigen Verbesserungen nicht auf ältere Versionen zurückportiert werden. Da die Verfügbarkeit auf eine neue AWS Region ElastiCache ausgedehnt wird, unterstützt OSS ElastiCache für Redis die beiden jeweils neuesten Major.Minor-Versionen für die neue Region. Wenn beispielsweise eine neue AWS Region eingeführt wird und die neuesten ElastiCache Major.Minor-Versionen für Redis OSS 7.0 und 6.2 sind, ElastiCache werden die Redis OSS-Versionen 7.0 und 6.2 in der neuen Region unterstützt. AWS Sobald neuere Major.Minor-Versionen von ElastiCache für Redis OSS veröffentlicht werden, ElastiCache wird weiterhin Unterstützung für die neu veröffentlichten Versionen hinzugefügt. Weitere Informationen zur Auswahl von Regionen für finden Sie unter Regionen ElastiCache und Verfügbarkeitszonen auswählen.
Wenn Sie ein Upgrade durchführen, das Haupt- oder Nebenversionen umfasst, beachten Sie bitte die folgende Liste, die Verhaltens- und rückwärtsinkompatible Änderungen enthält, die im Laufe der Zeit mit Redis OSS veröffentlicht wurden.
Verhalten und abwärtsinkompatible Änderungen von Redis OSS 7.0
Eine vollständige Liste der Änderungen finden Sie in den Versionshinweisen zu Redis OSS 7.0
-
SCRIPT LOAD
undSCRIPT FLUSH
werden nicht mehr auf Replikate weitergeleitet. Wenn Sie eine gewisse Haltbarkeit für Skripts benötigen, empfehlen wir Ihnen, die Verwendung von Redis OSS-Funktionenin Betracht zu ziehen. -
Pubsub-Kanäle sind jetzt für neue ACL-Benutzer standardmäßig gesperrt.
-
Der
STRALGO
-Befehl wurde durch denLCS
-Befehl ersetzt. -
Das Format für
ACL GETUSER
wurde geändert, sodass alle Felder das standardmäßige Zugriffszeichenfolgemuster anzeigen. Wenn Sie Automatisierung mitACL GETUSER
verwendet haben, sollten Sie überprüfen, ob beide Formate verarbeitet werden. -
Die ACL-Kategorien für
SELECT
,WAIT
,ROLE
,LASTSAVE
,READONLY
,READWRITE
undASKING
haben sich geändert. -
Der
INFO
-Befehl zeigt jetzt Befehlsstatistiken pro Unterbefehl und anstatt bei den Container-Befehlen in der obersten Ebene an. -
Die Rückgabewerte der Befehle
LPOP
,RPOP
,ZPOPMIN
undZPOPMAX
haben sich in bestimmten Randfällen geändert. Wenn Sie diese Befehle verwenden, sollten Sie die Versionshinweise überprüfen und bewerten, ob Sie betroffen sind. -
Die Befehle
SORT
undSORT_RO
erfordern jetzt Zugriff auf den gesamten Schlüsselraum, um die ArgumenteGET
sowieBY
verwenden zu können.
Verhalten und abwärtsinkompatible Änderungen in Redis OSS 6.2
Eine vollständige Liste der Änderungen finden Sie in den Versionshinweisen zu Redis OSS 6.2
-
Die ACL-Flags der Befehle
TIME
,ECHO
,ROLE
undLASTSAVE
wurden geändert. Dies kann dazu führen, dass Befehle, die zuvor gestattet waren, abgelehnt werden und umgekehrt.Anmerkung
Keiner dieser Befehle verändert Daten oder gewährt Zugriff darauf.
-
Beim Upgrade von Redis OSS 6.0 wird die Reihenfolge der Schlüssel/Wert-Paare, die von einer Map-Antwort an ein Lua-Skript zurückgegeben werden, geändert. Wenn Ihre Skripte eine Map verwenden
redis.setresp()
oder zurückgeben (neu in Redis OSS 6.0), sollten Sie die Auswirkungen berücksichtigen, die sich daraus ergeben, dass das Skript bei Upgrades nicht mehr funktioniert.
Verhalten von Redis OSS 6.0 und abwärtsinkompatible Änderungen
Eine vollständige Liste der Änderungen finden Sie in den Versionshinweisen zu Redis OSS 6.0
-
Die maximale Anzahl zugelassener Datenbanken wurde von 1,2 Millionen auf 10.000 verringert. Der Standardwert ist 16, und wir raten davon ab, Werte zu verwenden, die viel größer sind, da wir Probleme mit der Leistung und dem Arbeitsspeicher festgestellt haben.
-
Stellen Sie den
AutoMinorVersionUpgrade
Parameter auf yes ein und das Upgrade der Nebenversion ElastiCache wird über Self-Service-Updates verwaltet. Dies wird über Standardkanäle für die Kundenbenachrichtigung über eine Self-Service-Update-Kampagne abgewickelt. Weitere Informationen finden Sie unter Self-Service-Updates unter. ElastiCache
Verhalten und abwärtsinkompatible Änderungen in Redis OSS 5.0
Eine vollständige Liste der Änderungen finden Sie in den Versionshinweisen zu Redis OSS 5.0
-
Skripte werden durch Effekte repliziert, statt das Skript auf dem Replikat erneut auszuführen. Dies verbessert im Allgemeinen die Leistung, kann jedoch die Menge der zwischen primären Replikaten und Replikaten replizierten Daten erhöhen. Es gibt eine Option, um zum vorherigen Verhalten zurückzukehren, die nur in ElastiCache Version 5.0 für Redis OSS verfügbar ist.
-
Wenn Sie ein Upgrade von Redis OSS 4.0 durchführen, geben einige Befehle in LUA-Skripten Argumente in einer anderen Reihenfolge zurück als in früheren Versionen. In Redis OSS 4.0 ordnete Redis OSS einige Antworten lexographisch an, um die Antworten deterministisch zu machen. Diese Reihenfolge wird nicht angewendet, wenn Skripten durch Effekte repliziert werden.
-
In Redis OSS 5.0.3 und höher wird bei Redis OSS bei ElastiCache Instance-Typen mit mehr als 4 ein Teil der I/O-Arbeit auf Hintergrundkerne ausgelagert. VCPUs Dies kann die Leistungsmerkmale von Redis OSS und die Werte einiger Metriken ändern. Weitere Informationen finden Sie unter Welche Metriken sollte ich überwachen?, um zu verstehen, ob Sie ändern müssen, welche Metriken Sie sich ansehen.
Verhalten von Redis OSS 4.0 und abwärtsinkompatible Änderungen
Eine vollständige Liste der Änderungen finden Sie in den Versionshinweisen zu Redis OSS 4.0
-
Slow Log protokolliert jetzt zwei zusätzliche Argumente, den Namen und die Adresse des Clients. Diese Änderung sollte abwärtskompatibel sein, sofern Sie sich nicht explizit darauf verlassen, dass jeder Slow-Log-Eintrag 3 Werte enthält.
-
Der Befehl
CLUSTER NODES
gibt jetzt ein etwas anderes Format zurück, das nicht abwärtskompatibel ist. Wir empfehlen, dass Clients diesen Befehl nicht verwenden, um mehr über die in einem Cluster vorhandenen Knoten zu erfahren, sondern stattdessenCLUSTER SLOTS
verwenden.
Vergangenes EOL
Verhalten von Redis OSS 3.2 und abwärtsinkompatible Änderungen
Eine vollständige Liste der Änderungen finden Sie in den Versionshinweisen zu Redis OSS 3.2
-
Für diese Version sind keine Kompatibilitätsänderungen erforderlich.
Weitere Informationen finden Sie unter ElastiCache Zeitplan für das Ende der Lebensdauer der Versionen für Redis OSS.
Verhalten von Redis OSS 2.8 und abwärtsinkompatible Änderungen
Eine vollständige Liste der Änderungen finden Sie in den Versionshinweisen zu Redis OSS 2.8
-
Ab Redis OSS 2.8.22 wird Redis OSS AOF für Redis OSS nicht mehr unterstützt. ElastiCache Wir empfehlen die Verwendung von MemoryDB, wenn Daten dauerhaft gespeichert werden müssen.
-
Ab Redis OSS 2.8.22 unterstützt Redis OSS das Anhängen von Replikaten an ElastiCache darin gehostete Primärdateien nicht mehr. ElastiCache Während des Upgrades werden externe Replikate getrennt und sie können keine erneute Verbindung herstellen. Wir empfehlen die Verwendung von clientseitigem Caching, das in Redis OSS 6.0 als Alternative zu externen Replikaten verfügbar ist.
-
Die Befehle
TTL
undPTTL
geben jetzt -2 zurück, wenn der Schlüssel nicht existiert, und -1, wenn er existiert, aber kein zugehöriges Ablaufdatum hat. Redis OSS 2.6 und frühere Versionen gaben in beiden Fällen -1 zurück. -
SORT
mitALPHA
sortiert jetzt nach lokalem Standardgebietsschema, wenn keineSTORE
-Option verwendet wird.
Weitere Informationen finden Sie unter ElastiCache Zeitplan für das Ende der Lebensdauer der Versionen für Redis OSS.