Rozwiązywanie problemów z utratą danych w usłudze Azure Managed Redis (wersja zapoznawcza)
W tym artykule omówiono sposób diagnozowania rzeczywistych lub postrzeganych strat danych, które mogą wystąpić w usłudze Azure Managed Redis (wersja zapoznawcza).
Uwaga
Kilka kroków rozwiązywania problemów w tym przewodniku zawiera instrukcje dotyczące uruchamiania poleceń usługi Redis i monitorowania różnych metryk wydajności. Aby uzyskać więcej informacji i instrukcji, zobacz artykuły w sekcji Dodatkowe informacje .
Częściowa utrata kluczy
Usługa Azure Managed Redis nie usuwa losowo kluczy po ich zapisaniu w pamięci. Jednak usuwa klucze w odpowiedzi na zasady wygasania, zasady eksmisji i jawne polecenia usunięcia kluczy. Te polecenia można uruchamiać za pomocą interfejsu wiersza polecenia.
Klucze zapisane w węźle podstawowym w wystąpieniu usługi Azure Managed Redis również mogą nie być dostępne w replice od razu. Dane są replikowane z lokalizacji podstawowej do repliki w sposób asynchroniczny i nie powodujący blokad.
Jeśli okaże się, że klucze zniknęły z pamięci podręcznej, sprawdź następujące możliwe przyczyny:
| Przyczyna | Opis |
|---|---|
| Wygaśnięcie klucza | Klucze są usuwane z powodu ustawionych dla nich limitów czasu. |
| Eksmisja klucza | Klucze są usuwane z powodu obciążenia pamięci. |
| Usuwanie klucza | Klucze są usuwane za pomocą jawnych poleceń usunięcia. |
| Replikacja asynchroniowa | Klucze nie są dostępne w replice z powodu opóźnień replikacji danych. |
Wygaśnięcie klucza
Usługa Azure Managed Redis automatycznie usuwa klucz, jeśli przypisano mu limit czasu i upływa ten okres. Aby uzyskać więcej informacji o wygaśnięciu klucza usługi Redis, zobacz dokumentację polecenia EXPIRE . Wartości limitu czasu można również ustawić przy użyciu poleceń SET, SETEX, GETSET i innych poleceń *STORE .
Aby uzyskać statystyki dotyczące liczby wygasłych kluczy, użyj polecenia INFO . W Stats sekcji przedstawiono łączną liczbę wygasłych kluczy. Sekcja Keyspace zawiera więcej informacji na temat liczby kluczy z limitami czasu i średnią wartością limitu czasu.
# Stats
expired_keys:46583
# Keyspace
db0:keys=3450,expires=2,avg_ttl=91861015336
Możesz również zapoznać się z metrykami diagnostycznymi pamięci podręcznej, aby sprawdzić, czy istnieje korelacja między brakiem klucza a skokiem wygasłych kluczy. Aby uzyskać informacje na temat używania keyspace powiadomień lub MONITOR debugowania tego typu problemów, zobacz Dodatek debugowania chybień usługi Redis Keyspace.
Eksmisja klucza
Usługa Azure Managed Redis wymaga miejsca na pamięć do przechowywania danych. W razie potrzeby usuwa klucze, aby zwolnić dostępną pamięć. Gdy wartości used_memory lub used_memory_rss w poleceniu INFO zbliżają się do skonfigurowanego ustawienia maxmemory, usługa Azure Managed Redis rozpoczyna eksmitowanie kluczy z pamięci na podstawie zasad pamięci podręcznej.
Liczbę eksmitowanych kluczy można monitorować za pomocą polecenia INFO :
# Stats
evicted_keys:13224
Możesz również zapoznać się z metrykami diagnostycznymi pamięci podręcznej, aby sprawdzić, czy istnieje korelacja między brakiem klucza a skokiem eksmitowanych kluczy. Zobacz Dodatek Debugowanie chybień usługi Redis Keyspace, aby uzyskać informacje o korzystaniu z powiadomień o przestrzeni kluczy lub monitorze w celu debugowania tego typu problemów.
Usuwanie klucza
Klienci redis mogą wydać polecenie DEL lub HDEL , aby jawnie usunąć klucze z usługi Azure Managed Redis. Liczbę operacji usuwania można śledzić za pomocą polecenia INFO . Jeśli wywołano polecenia DEL lub HDEL , zostaną one wyświetlone w Commandstats sekcji .
# Commandstats
cmdstat_del:calls=2,usec=90,usec_per_call=45.00
cmdstat_hdel:calls=1,usec=47,usec_per_call=47.00
Replikacja asynchroniowa
Każde wystąpienie usługi Azure Managed Redis z włączoną wysoką dostępnością jest skonfigurowane z węzłem podstawowym i co najmniej jedną repliką. Dane są kopiowane z podstawowej do repliki asynchronicznie przy użyciu procesu w tle. W witrynie internetowej redis.io opisano ogólne działanie replikacji danych Redis. W przypadku scenariuszy, w których klienci zapisują w usłudze Redis często, może wystąpić częściowa utrata danych, ponieważ replikacja nie gwarantuje natychmiastowego wystąpienia. Jeśli na przykład podstawowy ulegnie awarii po zapisaniu klucza przez klienta, ale zanim proces w tle będzie miał szansę wysłać ten klucz do repliki, klucz zostanie utracony, gdy replika przejmie rolę nowego podstawowego.
Większościowa lub całkowita utrata kluczy
Jeśli z pamięci podręcznej zniknęły prawie wszystkie lub wszystkie klucze, sprawdź następujące możliwe przyczyny:
| Przyczyna | Opis |
|---|---|
| Opróżnianie klucza | Klucze zostały przeczyszczone ręcznie. |
| Niepowodzenie wystąpienia usługi Redis | Serwer Redis jest niedostępny. |
Opróżnianie klucza
Klienci mogą wywołać polecenie FLUSHDB lub FLUSHALL , aby usunąć wszystkie klucze z wystąpienia usługi Redis. Aby dowiedzieć się, czy klucze zostały opróżnione, użyj polecenia INFO . W Commandstats sekcji pokazano, czy którekolwiek FLUSH polecenie zostało wywołane:
# Commandstats
cmdstat_flushall:calls=2,usec=112,usec_per_call=56.00
cmdstat_flushdb:calls=1,usec=110,usec_per_call=52.00
Niepowodzenie wystąpienia usługi Redis
Redis to magazyn danych w pamięci. Dane są przechowywane na maszynach fizycznych lub wirtualnych hostujących pamięć podręczną Redis Cache. Pamięci podręczne Azure Managed Redis Cache zapewniają wysoką odporność na utratę danych, zapewniając domyślnie odporne na strefy pamięci podręczne. Gdy podstawowy fragment w takiej pamięci podręcznej ulegnie awarii, fragment repliki automatycznie przejmie obsługę danych. Te maszyny wirtualne znajdują się w oddzielnych domenach, aby zminimalizować prawdopodobieństwo jednoczesnego wystąpienia błędów i aktualizacji oraz niedostępności obu tych maszyn. Jeśli jednak wystąpi duża awaria centrum danych, maszyny wirtualne mogą nadal spaść razem. W tych rzadkich przypadkach dane zostaną utracone.
Rozważ użycie trwałości danych usługi Redis i replikacji geograficznej, aby zwiększyć ochronę danych przed tymi awariami infrastruktury.
Dodatkowe informacje
Te artykuły zawierają więcej informacji na temat unikania utraty danych: