Wesentliche Unterschiede im Versionsverhalten und in der Kompatibilität 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 OSS Redis-Version auf die neueste verfügbare Redis-Version aktualisieren, ohne dass OSS sequentielle Upgrades erforderlich sind. Sie können beispielsweise direkt von Redis OSS Version 3.0 auf Version 7.0 aktualisieren.

OSSRedis-Versionen werden mit einer semantischen Version identifiziert, die eine MAJORMINOR, und -Komponente umfasst. PATCH 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:

• MAJORVersionen sind für inkompatible Änderungen API

• MINORVersionen sind für neue Funktionen vorgesehen, die abwärtskompatibel hinzugefügt wurden

• PATCHVersionen sind für abwärtskompatible Bugfixes und nicht funktionale Änderungen vorgesehen

Wir empfehlen, innerhalb eines bestimmten Zeitraums immer auf der neuesten Patch-Version zu bleiben. MAJOR MINORVersion, um die neuesten Leistungs- und Stabilitätsverbesserungen zu erzielen. Ab Redis OSS 6.0 wird ElastiCache (RedisOSS) eine einzige Version für jede OSS Redis-Nebenversion anbieten, anstatt mehrere Patch-Versionen anzubieten. ElastiCache (RedisOSS) verwaltet 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 ElastiCache (RedisOSS) die beiden neuesten. MAJOR MINORVersionen zu diesem Zeitpunkt für die neue Region. Zum Beispiel, wenn eine neue AWS Region eingeführt wird und die neuesteMAJOR. MINOR ElastiCache Die (Redis-OSS) Versionen sind 7.0 und 6.2, ElastiCache (RedisOSS) wird die Versionen 7.0 und 6.2 in der neuen AWS Region unterstützen. Wie neuer. MAJOR MINORVersionen von ElastiCache (RedisOSS) wurden veröffentlicht. Es ElastiCache wird weiterhin Unterstützung für die neu veröffentlichten ElastiCache (Redis-OSS) Versionen hinzugefügt. Weitere Informationen zur Auswahl von Regionen für ElastiCache finden Sie unter Regionen 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 und SCRIPT FLUSH werden nicht mehr auf Replikate weitergeleitet. Wenn Sie eine gewisse Haltbarkeit von Skripten benötigen, empfehlen wir Ihnen, die Verwendung von OSSRedis-Funktionen in Betracht zu ziehen.

• Pubsub-Kanäle sind jetzt standardmäßig für neue ACL Benutzer gesperrt.

• Der STRALGO-Befehl wurde durch den LCS-Befehl ersetzt.

• Das Format für ACL GETUSER wurde geändert, sodass alle Felder das standardmäßige Zugriffszeichenfolgemuster anzeigen. Wenn Sie Automatisierung mit ACL GETUSER verwendet haben, sollten Sie überprüfen, ob beide Formate verarbeitet werden.

• Die ACL Kategorien fürSELECT,WAIT,ROLE, LASTSAVE READONLYREADWRITE, und ASKING 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 und ZPOPMAX 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 und SORT_RO erfordern jetzt Zugriff auf den gesamten Schlüsselraum, um die Argumente GET sowie BY 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 LASTSAVE Befehle TIMEECHO,ROLE, und 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 wurde die Reihenfolge der Schlüssel/Wert-Paare, die von einer Map-Antwort an ein Lua-Skript zurückgegeben wurden, 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 das Skript bei Upgrades unterbrechen kann.

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.

• Setzen Sie den AutoMinorVersionUpgrade Parameter auf yes, und ElastiCache (RedisOSS) verwaltet das Upgrade der Nebenversion über Self-Service-Updates. 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 (RedisOSS) 5.0 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 ElastiCache (RedisOSS) bei Instance-Typen mit mehr als 4 einen Teil der I/O-Arbeit auf Hintergrundkerne auslagern. 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 stattdessen CLUSTER SLOTS verwenden.

In der Vergangenheit EOL

Verhalten und abwärtsinkompatible Änderungen in Redis OSS 3.2

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 Zeitplan für das Ende des Lebenszyklus der Redis-Versionen 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 OSS AOF wird Redis in (Redis) nicht mehr unterstützt. ElastiCache OSS Wir empfehlen die Verwendung von MemoryDB, wenn Daten dauerhaft gespeichert werden müssen.

• Ab Redis OSS 2.8.22 unterstützt ElastiCache (RedisOSS) das Anhängen von Replikaten an 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 6.0 als Alternative zu externen Replikaten verfügbar ist. OSS

• Die Befehle TTL und PTTL 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 für beide Bedingungen -1 zurück.

• SORT mit ALPHA sortiert jetzt nach lokalem Standardgebietsschema, wenn keine STORE-Option verwendet wird.

Weitere Informationen finden Sie unter Zeitplan für das Ende des Lebenszyklus der Redis-Versionen OSS.