Rozwiązywanie problemów z utratą danych w usłudze Azure Cache for Redis

  • Artykuł

W tym artykule omówiono sposób diagnozowania rzeczywistych lub postrzeganych strat danych, które mogą wystąpić w usłudze Azure Cache for Redis.

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 Cache for 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 uruchomić w konsoli programu lub za pomocą interfejsu wiersza polecenia.

Klucze zapisane w węźle podstawowym w wystąpieniu usługi Azure Cache for Redis w warstwie Premium lub Standardowa 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.
Eksmisji 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

Azure Cache for Redis automatycznie usuwa klucz, jeśli klucz zostanie przypisany do limitu czasu i ten okres upłynął. Aby uzyskać więcej informacji o wygaśnięciu klucza 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 kluczy wygasłych, użyj polecenia INFO . W Stats sekcji przedstawiono całkowitą liczbę wygasłych kluczy. Sekcja Keyspace zawiera więcej informacji o liczbie 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 wystąpiła korelacja między brakiem klucza a skokiem wygasłych kluczy. Aby uzyskać informacje na temat używania keyspace powiadomień lub MONITOR debugowania tych typów problemów, zobacz Dodatek debugowania błędów usługi Redis Keyspace.

Eksmisji klucza

Azure Cache for 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, Azure Cache for 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 wystąpiła korelacja między brakiem klucza a skokiem eksmitowanych kluczy. Aby uzyskać informacje na temat używania powiadomień dotyczących przestrzeni kluczy kluczy lub monitora do debugowania tego typu problemów, zobacz dodatek Debugowanie usługi Redis Keyspace Misses.

Usuwanie klucza

Klienci usługi Redis mogą wydać polecenie DEL lub HDEL, aby jawnie usunąć klucze z Azure Cache for Redis. Liczbę operacji usuwania można śledzić przy użyciu polecenia INFO . Jeśli wywołano polecenia DEL lub HDEL , zostaną one wymienione 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 Azure Cache for Redis w warstwie Standardowa lub Premium 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 jest gwarantowana natychmiast. Jeśli na przykład podstawowy przejdzie w dół 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.
Niepoprawne zaznaczenie bazy danych Usługa Azure Cache for Redis jest skonfigurowana w celu używania innej bazy danych niż domyślna.
Niepowodzenie wystąpienia usługi Redis Serwer Redis jest niedostępny.

Opróżnianie klucza

Klienci mogą wywoływać polecenie FLUSHDB , aby usunąć wszystkie klucze w jednej bazie danych lub FLUSHALL , aby usunąć wszystkie klucze ze wszystkich baz danych w pamięci podręcznej Redis. Aby dowiedzieć się, czy klucze zostały opróżnione, użyj polecenia INFO . W Commandstats sekcji pokazano, czy dowolne 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

Niepoprawne zaznaczenie bazy danych

Azure Cache for Redis domyślnie używa db0 bazy danych. Jeśli przełączysz się do innej bazy danych (na przykład db1) i spróbujesz odczytać klucze z niej, Azure Cache for Redis nie znajdzie ich tam. Każda baza danych jest logicznie oddzielną jednostką i zawiera inny zestaw danych. Skorzystaj z polecenia SELECT, aby użyć innych dostępnych baz danych i wyszukać klucze w każdej z nich.

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. Wystąpienie usługi Azure Cache for Redis w warstwie Podstawowa działa tylko na jednej maszynie wirtualnej. Jeśli ta maszyna wirtualna ulegnie awarii, wszystkie dane przechowywane w pamięci podręcznej zostaną utracone.

Pamięci podręczne w warstwach Standardowa i Premium oferują znacznie większą odporność na utratę danych przy użyciu dwóch maszyn wirtualnych w konfiguracji replikowanej. Gdy węzeł podstawowy w takiej pamięci podręcznej ulegnie awarii, węzeł repliki automatycznie przejmuje 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 nadal mogą przestać działać jednocześnie. W tych rzadkich przypadkach dane zostaną utracone.

Rozważ użycie trwałości danych usługi Redis i replikacji geograficznej w celu zwiększenia ochrony danych przed tymi awariami infrastruktury.

Dodatkowe informacje

Te artykuły zawierają więcej informacji na temat unikania utraty danych: