Rozwiązywanie problemów z utratą danych w usłudze Azure Cache for Redis
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. |
| 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 Cache for Redis automatycznie usuwa klucz, jeśli klucz został przypisany do limitu czasu, a ten okres upłynął. 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 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ża się do skonfigurowanego ustawienia maxmemory, usługa 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 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 Cache for 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 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 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. |
| Niepoprawny wybór 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łać 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 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
Niepoprawny wybór bazy danych
Usługa Azure Cache for Redis domyślnie używa db0 bazy danych. Jeśli przejdziesz do innej bazy danych (na przykład db1) i spróbujesz odczytać klucze z niej, usługa 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 zapewniają znacznie większą odporność na utratę danych przy użyciu dwóch maszyn wirtualnych w zreplikowanej konfiguracji. 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, aby zwiększyć ochronę danych przed tymi awariami infrastruktury.
Dodatkowe informacje
Te artykuły zawierają więcej informacji na temat unikania utraty danych: