Migrowanie z warstw Podstawowa, Standardowa, Premium i Enterprise do usługi Azure Managed Redis

W tym artykule wyjaśniono, dlaczego i jak przeprowadzić migrację z usługi Azure Cache for Redis (w tym warstwy Podstawowa, Standardowa, Premium i Enterprise) do usługi Azure Managed Redis.

Dowiesz się więcej o:

• Korzyści wynikające z wyboru usługi Azure Managed Redis w porównaniu z poprzednimi warstwami.
• Najważniejsze różnice cech między usługami.
• Strategie migracji danych pamięci podręcznej.
• Sposoby zapewnienia bezproblemowego procesu migracji.
• Wskazówki dotyczące wybierania odpowiedniej jednostki SKU usługi Azure Managed Redis i warstwy wydajności dla Twoich potrzeb.
• Zagadnienia i zalecenia dotyczące aktualizowania aplikacji klienckich.

Niezależnie od tego, czy używasz warstw Podstawowa, Standardowa, Premium, Enterprise, czy OSS, ten przewodnik ułatwia planowanie i wykonywanie migracji do usługi Azure Managed Redis.

Dokument dzieli się na dwie sekcje. Jednym z tematów są instancje korporacyjne. Druga dotyczy warstw Podstawowa, Standardowa i Premium usługi Azure Cache for Redis.

• Korzyści wynikające z przejścia z usługi Enterprise do usługi Azure Managed Redis
• Korzyści wynikające z przejścia z pamięci podręcznych w warstwie Podstawowa, Standardowa lub Premium do usługi Azure Managed Redis

Korzyści wynikające z przejścia z usługi Enterprise do usługi Azure Managed Redis

Usługa Azure Managed Redis jest oparta na zaawansowanym oprogramowaniu Redis Enterprise. Usługa Azure Managed Redis to usługa oferowana bezpośrednio przez Azure, co oznacza, że nie ma składnika Azure Marketplace, a użytkownicy nie muszą osobno uczestniczyć w transakcjach z Azure Marketplace. Aprowizujesz, zarządzasz i płacisz za usługę Azure Managed Redis jak za każdą inną natywną usługę lub produkt platformy Azure.

Usługa Azure Managed Redis nie wymaga węzła kworum , który prowadzi do niedostatecznie używanych zasobów i ogranicza regiony lub chmury, w których można oferować usługę Azure Cache for Redis Enterprise. Usługa Azure Managed Redis jest teraz dostępna w większości regionów platformy Azure, z planami wsparcia w innych suwerennych chmurach. Aby uzyskać więcej informacji na temat węzła kworum, zobacz poziomy Enterprise i Enterprise Flash. Usunięcie nieużywanego węzła kworum zwiększa wydajność kosztową, ponieważ wszystkie węzły mogą być używane jako węzły danych.

Usługa Azure Managed Redis jest domyślnie odporna na awarie strefowe.

Usługi Azure Managed Redis można używać bez wysokiej dostępności (HA) dla środowisk deweloperskich i testowych. Korzystanie ze środowisk nieprodukcyjnych bez wysokiej dostępności zmniejsza koszt instancji o połowę.

Struktura jednostki SKU dla usługi Azure Managed Redis jest oparta na wymaganiach dotyczących pamięci i wydajności. Zamiast zarządzać czynnikami skalowania lub pojemnością, tak jak w przypadku usługi Azure Cache for Redis Enterprise, możesz wybrać 3 warstwy wydajności w usłudze Azure Managed Redis. Aby uzyskać więcej informacji, zobacz Wybieranie odpowiedniej warstwy.

Na koniec usługa Azure Managed Redis oferuje uwierzytelnianie Microsoft Entra ID podczas tworzenia pamięci podręcznej, aby poprawić bezpieczeństwo obciążenia.

Porównanie funkcji

Funkcja	Platforma Azure Cache dla Redis Enterprise	Zarządzany Redis w Azure
Wersja usługi Redis	7.2	7.4
Zasady klastrowania	Oprogramowanie open source, przedsiębiorstwo	Oprogramowanie open source, korporacyjne, nieklastrowane
Geo-replication	Aktywny	Aktywny
SLA	Do 99,999%	Do 99,999%
Redundancja strefowa	Yes	*Tak z wysoką dostępnością
Tryb bez wysokiej dostępności	No	Tak (w przypadku tworzenia i testowania)
Stan trwały danych	Tak (w wersji zapoznawczej)	Yes
Scaling	Yes	Yes
Obsługa wersji protokołu TLS	1.2,1.3	1.2,1.3
Uwierzytelnianie za pomocą Microsoft Entra ID	No	Yes
Obsługa regionów platformy Azure	Limited	Rozległy
Obsługa suwerennej chmury platformy Azure	No	Tak (wkrótce)
Sufiks DNS nazwy hosta	<name>.<region>.redisenterprise.cache.azure.net	<name>.<region>.redis.azure.net

* Po włączeniu wysokiej dostępności usługa Azure Managed Redis jest strefowo nadmiarowa w regionach z wieloma strefami dostępności.

Zagadnienia dotyczące przechodzenia z usługi Enterprise do usługi Azure Managed Redis

Usługa Azure Managed Redis używa tego samego stosu oprogramowania co usługa Azure Cache for Redis Enterprise, więc istniejące aplikacje korzystające z warstwy Enterprise nie wymagają wielu zmian. Znaczącym wyjątkiem jest potrzeba zmiany poświadczeń połączenia.

Inna nazwa hosta i sufiks

Chociaż podstawowe oprogramowanie usługi Azure Cache for Redis Enterprise i Azure Managed Redis jest podobne, sufiks DNS dla nazwy hosta klastra Redis jest inny. Po przejściu do usługi Azure Managed Redis aplikacja musi zmienić nazwę hosta klastra Redis. Jeśli używasz kluczy dostępu do nawiązywania połączenia z pamięcią podręczną, musisz również zaktualizować klucz dostępu używany do nawiązywania połączenia z pamięcią podręczną.

Ważne

Rozważ zaktualizowanie kodu łączącego się z pamięcią podręczną. Zamiast używać kluczy dostępu, użyj identyfikatora Entra firmy Microsoft. Zalecamy używanie identyfikatora Entra firmy Microsoft zamiast kluczy dostępu.

Wybieranie odpowiedniego rozmiaru i SKU usługi Azure Managed Redis

Usługa Azure Managed Redis oferuje wiele rozmiarów pamięci i trzy warstwy wydajności. Więcej informacji o rozmiarach pamięci i warstwach wydajności można znaleźć tutaj : Wybieranie odpowiedniej warstwy.

Identyfikowanie rozmiaru pamięci istniejącego wystąpienia usługi Azure Cache for Redis Enterprise

Wystąpienia usługi Azure Cache for Redis Enterprise można skalować poziomo, aby zapewnić więcej pamięci i zasobów obliczeniowych, więc ważne jest, aby zwrócić uwagę na współczynnik poziomego skalowania pamięci podręcznej. Skalowanie w górę jest również związane z pojemnością, czyli zasadniczo liczbą maszyn wirtualnych uruchomionych dla klastra.

Aby wybrać odpowiedni rozmiar pamięci usługi Azure Managed Redis:

1. Przejdź do witryny Azure Portal i wybierz pozycję Przegląd z menu zasobów.
2. Sprawdź pole Stan w zakładce Przegląd wystąpienia przedsiębiorstwa. Pole Stan pokazuje rozmiar pamięci instancji usługi Redis Enterprise.

Przyjrzyjmy się możliwej sytuacji.

Patrząc na Stan w panelu Przegląd, widzisz uruchomione — Enterprise 8 GB (2 x 4 GB). Ta notacja oznacza, że pamięć podręczna używa obecnie SKU E5 Enterprise w skali 2, co daje 8 GB pamięci podręcznej. W związku z tym należy zacząć od co najmniej 10 GB pamięci podręcznej w usłudze Azure Managed Redis.

W takim przypadku należy użyć dowolnej warstwy, która oferuje 12 GB pamięci.

SKU	Warstwa
M10	Zoptymalizowana pamięć
B10	Balanced
X10	Zoptymalizowany pod obliczenia

Identyfikowanie warstwy wydajności

Należy również rozważyć, czy obciążenie intensywnie korzysta z pamięci, czy intensywnie korzysta z zasobów obliczeniowych. Jeśli bieżąca instancja przedsiębiorstwa ma większe prawdopodobieństwo wyczerpania pamięci niż zasobów CPU, to oznacza, że obciążenie jest intensywne pod względem zużycia pamięci. Rozważ wybór poziomu wydajności zoptymalizowanego pod kątem pamięci.

Jeśli twoje obciążenie jest intensywne pod względem przepustowości lub charakteryzuje się zbyt dużym opóźnieniem, to znaczy, że obciążenie jest intensywne obliczeniowo. Rozważ wybór warstwy wydajności Optimized for Compute.

Jeśli nie masz pewności, możesz zacząć od warstwy wydajności Zrównoważone , ponieważ oferuje ona zdrową mieszankę pamięci i wydajności.

Jeśli obecnie używasz warstwy Redis Enterprise Flash, wybierz warstwę Zoptymalizowaną dla pamięci Flash.

Utwórz nowe wystąpienie usługi Azure Managed Redis

Po wybraniu warstwy pamięci i wydajności dla nowego wystąpienia usługi Azure Managed Redis możesz utworzyć nowe wystąpienie usługi Azure Managed Redis. Aby uzyskać więcej informacji na temat tworzenia pamięci podręcznej, zobacz Szybki start: tworzenie wystąpienia usługi Azure Managed Redis.

Następnie należy wybrać strategię przenoszenia danych. Na koniec należy zaktualizować aplikację, aby korzystała z nowej pamięci podręcznej.

Zaktualizuj aplikację, aby połączyć się z wystąpieniem usługi Azure Managed Redis

Po utworzeniu nowego wystąpienia usługi Azure Managed Redis należy zmienić punkt końcowy/nazwę hosta usługi Redis i klucz dostępu w aplikacji, aby wskazać nowe wystąpienie usługi Azure Managed Redis. Zalecamy wprowadzenie tej zmiany punktu końcowego poza godzinami pracy, ponieważ może to spowodować krótkotrwałe przerwy w łączności.

Note

Jeśli połączysz się z istniejącym wystąpieniem usługi Redis Enterprise za pośrednictwem prywatnego punktu końcowego, upewnij się, że nowa, zarządzana przez usługę Azure pamięć podręczna Redis jest również połączona z siecią wirtualną Twojej aplikacji za pomocą komunikacji równorzędnej. Nowa pamięć podręczna musi mieć podobną konfigurację jako istniejące wystąpienie usługi Redis Enterprise.

Sprawdź, czy aplikacja działa zgodnie z oczekiwaniami, a następnie usuń poprzednią instancję Redis Enterprise.

Przenoszenie danych z pamięci podręcznej przedsiębiorstwa do nowej, zarządzanej przez Azure pamięci podręcznej Redis.

Podczas migracji do wystąpienia usługi Azure Managed Redis należy rozważyć najlepszy sposób przenoszenia danych z istniejącego wystąpienia usługi Redis Enterprise do nowego wystąpienia usługi Azure Managed Redis. Jeśli aplikacja może tolerować utratę danych lub ma inne mechanizmy umożliwiające ponowne wypełnianie pamięci podręcznej bez negatywnych skutków, pomiń ten krok i przejdź do następnych kroków.

Jeśli aplikacja musi zapewnić, że dane zostaną również przeniesione do nowej instancji usługi Azure Managed Redis, wybierz jedną z następujących opcji:

Eksportowanie i importowanie danych przy użyciu pliku RDB

• Zalety: zachowuje migawkę danych.
• Wady: Ryzyko utraty danych, jeśli zapisy wystąpią po migawce.

Oto podstawowa procedura eksportowania/importowania:

1. Wyeksportuj bazę danych RDB z istniejącej pamięci podręcznej Redis Enterprise do konta usługi Azure Storage.
2. Zaimportuj dane z konta usługi Azure Storage do nowej pamięci podręcznej Azure Managed Redis Cache.
3. Przeczytaj więcej na temat eksportowania/importowania danych tutaj Importowanie i eksportowanie danych w usłudze Azure Managed Redis.

Strategia podwójnego zapisu

• Zalety: zero przestojów, bezpieczne przejście.
• Wady: Tymczasowe ustawienie podwójnej pamięci podręcznej jest wymagane.

Oto podstawowa procedura podwójnego zapisu:

1. Zmodyfikuj aplikację, aby zapisywała dane zarówno w istniejącej pamięci podręcznej Azure Cache for Redis Enterprise, jak i w nowej pamięci podręcznej Azure Managed Redis.
2. Kontynuuj odczytywanie i zapisywanie z pamięci podręcznej Redis Enterprise Cache.
3. Po wystarczającej synchronizacji danych przełącz odczytywanie danych do Azure Managed Redis i usuń wystąpienie Redis Enterprise

Migracja programowa przy użyciu RIOT-X

RIOT-X umożliwia migrowanie zawartości z usługi Enterprise do usługi Azure Managed Redis. Aby uzyskać więcej informacji, zobacz Migracja danych za pomocą RIOT-X dla usługi Azure Managed Redis.

• Zalety: pełna kontrola, możliwość dostosowywania.
• Wady: wymaga nakładu pracy programistycznej.

Korzyści wynikające z przejścia z pamięci podręcznych w warstwie Podstawowa, Standardowa lub Premium do usługi Azure Managed Redis

Jeśli używasz dowolnego SKU dla otwartego oprogramowania, Basic, Standard lub Premium, przejście do usługi Azure Managed Redis oferuje więcej funkcji na każdym poziomie pamięci podręcznej.

Oto tabela porównująca funkcje z usługi Azure Cache for Redis z funkcjami w usłudze Azure Managed Redis

Opis funkcji	Basic OSS	Standard OSS	Premium OSS	Balanced AMR	Zoptymalizowana pamięć AMR	Zoptymalizowany pod obliczenia AMR
Availability	N/A	99.9%	99.9%	Do 99,999%	Do 99,999%	Do 99,999%
Szyfrowanie danych podczas przesyłania	Yes	Yes	Yes	Yes	Yes	Yes
Izolacja sieci	Yes	Yes	Yes	Yes	Yes	Yes
Skalowanie w górę/wy	Yes	Yes	Yes	Yes	Yes	Yes
Skalowanie w dół/w	Yes	Yes	Yes	No	No	No
Klastrowanie systemu operacyjnego	No	No	Yes	Yes	Yes	Yes
Stan trwały danych	No	No	Yes	Yes	Yes	Yes
Redundancja strefowa	No	Tak (wersja zapoznawcza)	Yes	*Tak z wysoką dostępnością	*Tak z wysoką dostępnością	*Tak z wysoką dostępnością
Geo-replication	No	No	Tak (pasywne)	Tak (aktywne)	Tak (aktywne)	Tak (aktywne)
Dzienniki inspekcji połączeń	No	No	Yes	Yes(Event-based)	Yes(Event-based)	Yes(Event-based)
Moduły Redis	No	No	No	Yes	Yes	Yes
Import/Eksport	No	No	Yes	Yes	Yes	Yes
Reboot	Yes	Yes	Yes	No	No	No
Zaplanowane aktualizacje	Yes	Yes	Yes	No	No	No
Uwierzytelnianie za pomocą Microsoft Entra ID	Yes	Yes	Yes	Yes	Yes	Yes
Microsoft Entra ID RBAC	Yes	Yes	Yes	No	No	No
Powiadomienie o przestrzeni kluczy	Yes	Yes	Yes	No	No	No
Brak wysokiej dostępności	N/A	No	No	Yes	Yes	Yes

OSS odnosi się do Azure Cache for Redis
Usługa AMR odnosi się do usługi Azure Managed Redis

* Po włączeniu wysokiej dostępności usługa Azure Managed Redis jest strefowo nadmiarowa w regionach z wieloma strefami dostępności.

Poniżej przedstawiono kilka innych różnic, które należy wziąć pod uwagę podczas implementowania usługi Azure Managed Redis. Rozważ następujące zmiany aplikacji klienckiej:

Opis funkcji	Azure Cache for Redis	Zarządzany Redis w Azure
Sufiks DNS (tylko dla chmury PROD)	.redis.cache.windows.net	<region>.redis.azure.net
Port TLS	6380	10000
Port inny niż TLS	6379	Niewspierane
Porty TLS z pojedynczym węzłem	13XXX	85xx
Pojedynczy węzeł inny niż TLS	15XXX	Niewspierane
Obsługa klastrowania	Tryb klastrowania systemu operacyjnego	Tryby klastra systemu operacyjnego i przedsiębiorstwa
Nieobsługiwane polecenia	Nieobsługiwane polecenia	Polecenia wieloklawiszowe
Dostępność regionalna	Wszystkie regiony platformy Azure	* Zobacz listę regionów po tej sekcji.
Wersja usługi Redis	6	7.4
Obsługiwane wersje protokołu TLS	1.2 i 1.3	1.2 i 1.3

Przenieś swoją pamięć podręczną Podstawowej, Standardowej lub Premium do usługi Azure Managed Redis

Na podstawie tabeli przedstawiono kilka mapowań między jednostkami SKU usługi Azure Cache for Redis i opcjami pamięci podręcznych w usłudze Azure Managed Redis.

Note

Użyj opcji braku wysokiej dostępności usługi Azure Managed Redis na potrzeby migrowania podstawowych jednostek SKU

Azure Cache for Redis	Zarządzany Redis w Azure	Dodatkowa pamięć (%)
Podstawowa/Standardowa — C0	Zrównoważony — B0	50
Podstawowa/Standardowa — C1	Zrównoważony — B1	0
Podstawowa/Standardowa — C2	Zrównoważony — B3	17
Podstawowa/Standardowa — C3	Zrównoważony — B5	0
Podstawowa/Standardowa — C4	Zoptymalizowane pod kątem pamięci — M10*	-8
Podstawowa/Standardowa — C4	Zoptymalizowane pod kątem pamięci — M20**	46
Podstawowa/Standardowa — C5	Zoptymalizowane pod kątem pamięci — M20*	-8
Podstawowa/Standardowa — C5	Zoptymalizowane pod kątem pamięci — M50**	57
Podstawowa/Standardowa — C6	Zoptymalizowane pod kątem pamięci — M50	12
Premium — P1	Zrównoważony — B5	0
Premium — P2	Zrównoważony — B10*	-8
Premium — P2	Zrównoważony — B20**	46
Premium — P3	Zrównoważony — B20*	-8
Premium — P3	Zrównoważony — B50**	57
Premium — P4	Zrównoważony — B50	12
Premium — P5	Zrównoważony — B100	0

• * Ta opcja jest dla wydajności kosztowej. Upewnij się, że szczyt całkowitej ilości używanej pamięci w ostatnim miesiącu jest mniejszy niż sugerowana pamięć usługi Azure Managed Redis, aby wybrać tę opcję.
• ** Ta opcja dotyczy dużego zużycia pamięci.

Klaster usługi Azure Cache for Redis Premium

• W przypadku klastra podzielonego na fragmenty wybierz warstwę Zoptymalizowane pod kątem pamięci, która ma równoważną całkowitą pamięć.
• W przypadku klastrów z więcej niż jedną repliką do odczytu wybierz warstwę Zoptymalizowana pod kątem obliczeń z równoważną całkowitą pamięcią jako repliką podstawową.

Opcje migracji

Aplikacje klienckie powinny mieć możliwość korzystania z wystąpienia usługi Azure Managed Redis, które ma różne tryby klastrowania i punkty końcowe. Usługi Azure Cache for Redis i Azure Managed Redis są zgodne, więc w większości scenariuszy nie są wymagane żadne zmiany kodu aplikacji inne niż konfiguracje połączeń.

Więcej informacji:

• Skalowanie instancji Azure Managed Redis

Opcje migracji usługi Azure Cache for Redis do usługi Azure Managed Redis

Option	Advantages	Disadvantages
Tworzenie nowej pamięci podręcznej	Najprostsze do zaimplementowania.	Należy ponownie wypełniać dane w nowej pamięci podręcznej, co może nie działać z wieloma aplikacjami.
Eksportowanie i importowanie danych za pośrednictwem pliku RDB	Zgodna z dowolną pamięcią podręczną Redis.	Niektóre dane mogą zostać utracone, jeśli zostaną zapisane w istniejącej pamięci podręcznej po wygenerowaniu pliku RDB.
Podwójne zapisywanie danych w dwóch pamięciach podręcznych	Brak utraty lub przestoju danych. Nieprzerwane operacje istniejącej pamięci podręcznej. Łatwiejsze testowanie nowej pamięci podręcznej.	Wymaga dwóch pamięci podręcznych na dłuższy okres.
Programowe migrowanie danych	Pełna kontrola nad sposobem przenoszenia danych.	Wymaga kodu niestandardowego.

Tworzenie nowego wystąpienia usługi Azure Managed Redis

To podejście technicznie nie jest migracją. Jeśli utrata danych nie jest problemem, najprostszym sposobem przejścia do warstwy Azure Managed Redis jest utworzenie nowego wystąpienia pamięci podręcznej i połączenie aplikacji z nią. Jeśli na przykład używasz Redis jako pamięci podręcznej dla rekordów bazy danych, możesz łatwo odbudować pamięć podręczną od podstaw. Ogólne kroki implementacji tej opcji to:

1. Utwórz nowe wystąpienie usługi Azure Managed Redis.
2. Zaktualizuj aplikację, aby korzystała z nowego wystąpienia.
3. Usuń stare wystąpienie usługi Azure Cache for Redis.

Eksportowanie danych do pliku RDB i importowanie ich do usługi Azure Managed Redis

Ta opcja ma zastosowanie tylko do pamięci podręcznych w warstwie Premium. Usługa Redis typu open source definiuje standardowy mechanizm tworzenia migawki zestawu danych w pamięci podręcznej i zapisywania go w pliku. Inna pamięć podręczna Redis cache może odczytać wyeksportowany plik RDB. Warstwa Premium usługi Azure Cache for Redis obsługuje eksportowanie danych z wystąpienia pamięci podręcznej za pośrednictwem plików RDB. Możesz użyć pliku RDB do transferu danych z istniejącego wystąpienia usługi Azure Cache for Redis do wystąpienia usługi Azure Managed Redis.

Ogólne kroki implementacji tej opcji to:

1. Utwórz nowe wystąpienie usługi Azure Managed Redis o takim samym rozmiarze (lub większym niż) istniejące wystąpienie usługi Azure Cache for Redis.
2. Eksportowanie pliku RDB z obecnego wystąpienia usługi Azure Cache for Redis przy użyciu tych instrukcji eksportowania lub polecenia PowerShell export-cmdlet
3. Zaimportuj plik RDB do nowego wystąpienia usługi Azure Managed Redis przy użyciu tych instrukcji importowania lub polecenia cmdlet importowania programu PowerShell
4. Zaktualizuj aplikację, aby korzystała z nowego wystąpienia usługi Azure Managed Redis parametry połączenia.

Pisanie do dwóch pamięci podręcznych Redis jednocześnie podczas okresu migracji

Zamiast przenosić dane bezpośrednio między pamięciami podręcznymi, możesz użyć aplikacji do zapisywania danych zarówno w istniejącej pamięci podręcznej, jak i nowej, którą konfigurujesz. Aplikacja nadal odczytuje dane z istniejącej pamięci podręcznej. Gdy nowa pamięć podręczna zawiera niezbędne dane, przełącz aplikację do tej pamięci podręcznej i wycofasz starą pamięć podręczną. Załóżmy na przykład, że używasz usługi Redis jako magazynu sesji, a sesje aplikacji są ważne przez siedem dni. Po zapisaniu do dwóch pamięci podręcznych przez tydzień będziesz mieć pewność, że nowa pamięć podręczna zawiera wszystkie informacje o sesji brak. Możesz bezpiecznie polegać na nim od tego momentu, nie obawiając się utraty danych.

Ogólne kroki implementacji tej opcji to:

1. Utwórz nowe wystąpienie usługi Azure Managed Redis o takim samym rozmiarze jak (lub większe) istniejące wystąpienie usługi Azure Cache for Redis.
2. Zmodyfikuj kod aplikacji, aby zapisywać zarówno do nowych, jak i oryginalnych instancji.
3. Kontynuuj odczytywanie danych z oryginalnego wystąpienia, dopóki nowe wystąpienie nie zostanie wystarczająco wypełnione danymi.
4. Zaktualizuj kod aplikacji tak, aby odczytywał i zapisywał wyłącznie z nowej instancji.
5. Usuń oryginalne wystąpienie.

Programowe migrowanie

Utwórz niestandardowy proces migracji, programowo odczytując dane z istniejącego wystąpienia usługi Azure Cache for Redis i zapisując je w wystąpieniu usługi Azure Managed Redis. Istnieją dwa narzędzia typu open source, które można wypróbować:

• Redis-copy
  • To narzędzie typu open source może służyć do kopiowania danych z jednego wystąpienia usługi Azure Cache for Redis do innego. To narzędzie jest przydatne do przenoszenia danych między wystąpieniami pamięci podręcznej w różnych regionach usługi Azure Cache. Dostępna jest również skompilowana wersja . Możesz również znaleźć kod źródłowy, który będzie przydatnym przewodnikiem dotyczącym pisania własnego narzędzia do migracji.
• RIOT
  • RIOT to kolejne popularne narzędzie do migracji przetestowane przez społeczność redis. Jest to narzędzie wiersza polecenia, które ułatwia pobieranie danych z usługi Redis i z niej.

Note

To narzędzie nie jest oficjalnie obsługiwane przez firmę Microsoft.

Ogólne kroki implementacji tej opcji to:

1. Utwórz maszynę wirtualną w regionie, w którym znajduje się istniejąca pamięć podręczna. Jeśli zestaw danych jest duży, wybierz stosunkowo zaawansowaną maszynę wirtualną, aby skrócić czas kopiowania.
2. Utwórz nowe wystąpienie usługi Azure Managed Redis.
3. Opróżnij dane z nowej pamięci podręcznej, aby upewnić się, że są puste. Ten krok jest wymagany, ponieważ samo narzędzie do kopiowania nie zastępuje żadnego istniejącego klucza w docelowej pamięci podręcznej. Ważne: pamiętaj, aby nie opróżnić pamięci podręcznej źródłowej.
4. Użyj aplikacji, takiej jak narzędzie open source wymienione wcześniej, aby zautomatyzować kopiowanie danych z pamięci podręcznej źródłowej do miejsca docelowego. Pamiętaj, że proces kopiowania może zająć trochę czasu, w zależności od rozmiaru zestawu danych.

Dostępność regionalna usługi Azure Managed Redis

Usługa Azure Managed Redis stale rozwija się w nowe regiony. Aby sprawdzić dostępność według regionów, zobacz Dostępność produktów według regionów.

Treści powiązane

• Co to jest usługa Azure Managed Redis?
• Architektura zarządzanego Redis w Azure