Ustal, dlaczego zmiany z repliki pierwotnej nie są odzwierciedlone w replice wtórnej dla grupy dostępności Always On

Dotyczy:SQL Server

Aplikacja kliencka kończy poprawnie aktualizację repliki pierwotnej, ale zapytanie do repliki wtórnej pokazuje, że zmiana nie jest odzwierciedlona. W tym przypadku zakłada się, że stan dostępności jest prawidłowo zsynchronizowany. W większości przypadków to zachowanie ustępuje po kilku minutach.

Jeśli zmiany nadal nie będą widoczne na replice wtórnej po kilku minutach, może występować wąskie gardło w procesie synchronizacji. Lokalizacja wąskiego gardła zależy od tego, czy replika wtórna jest ustawiona na zatwierdzenie synchroniczne czy asynchroniczne.

synchroniczne zatwierdzenie

Każda pomyślnie wykonana aktualizacja na replice pierwotnej została już zsynchronizowana z repliką wtórną albo rekordy dziennika zostały już zapisane na dysku w celu trwałego zapisania na replice wtórnej. Dlatego wąskie gardło powinno znajdować się w procesie ponawiania, który zachodzi po opróżnieniu dziennika w replice wtórnej.

Jednak gdy proces ponawiania nadrobi zaległości, wszystkie operacje odczytu na replice pomocniczej korzystają z izolacji migawek:

  • Długotrwałe transakcje na podstawowej replice

  • Powtórz replikę wtórną

Asynchroniczne zatwierdzanie

Ponieważ zatwierdzanie asynchroniczne uznaje transakcję za zatwierdzoną, gdy tylko zostanie ona zapisana na dysku lokalnym, wąskie gardło może występować w dowolnym miejscu po tym momencie:

  • Długotrwałe transakcje na podstawowej repliki

  • Opóźnienie sieci lub przepustowość

  • Hartowanie kłod na repliki wtórnej

  • Powtórz replikę drugorzędną

Poniższe sekcje opisują typowe przyczyny, dla których zmiany w replice pierwotnej nie są odzwierciedlane w replice pomocniczej w przypadku zapytań tylko do odczytu.

Długotrwałe aktywne transakcje

Długotrwała transakcja na replice głównej uniemożliwia odczytywanie aktualizacji na replice wtórnej.

Explanation

Wszystkie obciążenia odczytu na wtórnej replice to zapytania izolujące snapshot. W izolacji snapshotów klienci tylko do odczytu widzą bazę danych dostępności na wtórnej replice w punkcie początkowym najstarszej aktywnej transakcji w przetworzonym logu. Jeśli transakcja nie została zatwierdzona od wielu godzin, otwarta transakcja uniemożliwia wszystkim zapytaniom tylko do odczytu zobaczenie jakichkolwiek nowych zmian.

Diagnoza i rozwiązanie procesu

Na podstawowej kopii użyj DBCC OPENTRAN (Transact-SQL ), aby zobaczyć najstarsze aktywne transakcje i sprawdzić, czy można je cofnąć. Gdy najstarsze aktywne transakcje zostaną cofnięte i zsynchronizowane z repliką wtórną, obciążenia odczytu na replice wtórnej mogą zobaczyć aktualizacje w bazie danych dostępności do początku najstarszej aktywnej transakcji.

Wysokie opóźnienia sieci lub niska przepustowość sieci powodują nagromadzenie logów na replikach pierwotnych

Wysokie opóźnienia sieci lub niska przepustowość mogą uniemożliwić szybkie przesyłanie logów do repliki wtórnej.

Explanation

Replika pierwotna aktywuje kontrolę przepływu podczas wysyłania logów, gdy przekroczy maksymalną dopuszczalną liczbę niepotwierdzonych wiadomości przesłanych do repliki wtórnej. Dopóki niektóre z tych wiadomości nie zostaną potwierdzone, nie można już wysyłać bloków logów do repliki wtórnej. Ta sytuacja może mieć poważniejszy wpływ na potencjalną utratę danych, co może zagrozić celowi punktu odzyskania (RPO).

Diagnoza i rozwiązanie procesu

Wysoka wartość DMV log_send_queue_size może wskazywać, że logi są wstrzymywane na replice podstawowej. Podzielenie tej wartości przez log_send_rate pozwala uzyskać przybliżone oszacowanie, jak szybko dane można nadrobić na replikach wtórnych.

Warto też sprawdzić dwa obiekty wydajności: SQL Server: Availability Replica > Flow Control Time (ms/sec) oraz SQL Server: Availability Replica > Flow control/sec. Mnożenie tych dwóch wartości pokazuje w ostatniej sekundzie, ile czasu poświęcono na oczyszczenie kontroli przepływu. Im dłuższy czas oczekiwania na kontrolę przepływu, tym niższa szybkość wysyłania.

Poniżej znajduje się lista przydatnych wskaźników do diagnozowania opóźnień i przepustowości sieci. Możesz użyć innych narzędzi Windows, takich jak ping.exe, aby ocenić wykorzystanie sieci.

  • DMV log_send_queue_size

  • DMV log_send_rate

  • Licznik wydajności SQL Server:Database > Log Bytes Flushed/sec

  • Licznik wydajności SQL Server:Database Mirroring > Send/Receive Ack Time

  • Licznik wydajności SQL Server:Availability Replica > Bytes Sent to Replica/sec

  • Licznik wydajności SQL Server:Availability Replica > Bytes Sent to Transport/sec

  • Licznik wydajności SQL Server:Availability Replica > Flow Control Time (ms/sec)

  • Licznik wydajności SQL Server:Availability Replica > Flow Control/sec

  • Licznik wydajności SQL Server:Availability Replica > Resent Messages/sec

Aby rozwiązać ten problem, spróbuj zwiększyć przepustowość sieci lub usunąć lub ograniczyć niepotrzebny ruch sieciowy.

Inne obciążenie związane z raportowaniem uniemożliwia działanie wątku redo

Wątek redo na wtórnej repliki jest blokowany przed wprowadzaniem zmian w języku definicji danych (DDL) przez długo działające zapytanie tylko do odczytu. Wątek redo musi zostać odblokowany, zanim będzie mógł udostępniać kolejne aktualizacje na potrzeby obciążeń odczytowych.

Explanation

W replikach wtórnych zapytania tylko do odczytu uzyskują blokady stabilności schematu (Sch-S). Te Sch-S blokady mogą uniemożliwiać wątkowi redo uzyskanie blokad modyfikacji schematu (Sch-M), aby można było wprowadzać wszelkie zmiany DDL. Zablokowany wątek powtórek nie może stosować rekordów logów, dopóki nie zostanie odblokowany.

Diagnoza i rozwiązanie procesu

Gdy wątek redo jest zablokowany, generowane jest zdarzenie rozszerzone o nazwie sqlserver.lock_redo_blocked. Dodatkowo możesz zapytać DMV sys.dm_exec_request na drugiej replice, aby dowiedzieć się, która sesja blokuje wątek REDO, a potem możesz podjąć działania naprawcze. Poniższe zapytanie zwraca identyfikator sesji obciążenia związanego z raportowaniem, które blokuje wątek redo.

select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource   
from sys.dm_exec_requests where command = 'DB STARTUP'

Możesz poczekać, aż obciążenie związane z raportowaniem zakończy działanie; wtedy wątek ponawiania zostanie odblokowany. Możesz też natychmiast odblokować wątek ponawiania, wykonując polecenie KILL (Transact-SQL) dla identyfikatora sesji blokującej.

Wątek redo ma opóźnienia z powodu rywalizacji o zasoby

Duże obciążenie związane z raportowaniem na replice wtórnej spowolniło jej działanie, a wątek ponawiania pozostaje w tyle.

Explanation

Podczas stosowania rekordów dziennika na replice wtórnej wątek redo odczytuje rekordy dziennika z dysku dziennika, a następnie dla każdego rekordu dziennika odwołuje się do stron danych, aby zastosować ten rekord dziennika. Dostęp do strony może być ograniczony I/O (dostęp do fizycznego dysku), jeśli strona nie znajduje się już w puli bufora. Jeśli jest obciążenie raportowania związane z I/O, to obciążenie raportowania konkuruje o zasoby I/O z wątkiem powtórek i może spowolnić wątek powtórek. Ta sytuacja wpływa nie tylko na inne obciążenia raportowania wynikające z aktualizacji danych, ale także na RTO.

Diagnoza i rozwiązanie procesu

Możesz użyć poniższego zapytania DMV, aby sprawdzić, jak duże jest opóźnienie wątku redo, mierząc wartość luki między last_redone_lsn a last_received_lsn.

select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,   
   last_redone_lsn, last_redone_time  
from sys.dm_hadr_database_replica_states

Jeśli wątek poprawki faktycznie pozostaje w tyle, musisz zbadać źródło pogorszenia wydajności na wtórnej replice. Jeśli wystąpi konflikt I/O w obciążeniu raportującym, możesz użyć Resource Governor do kontrolowania cykli CPU wykorzystywanych przez obciążenie raportujące do pośredniej kontroli wykonywanych cykli I/O, w pewnym stopniu. Na przykład jeśli obciążenie generowane przez raportowanie zużywa 10 procent zasobów procesora, ale jest ograniczane przez operacje we/wy, można użyć narzędzia Resource Governor, aby ograniczyć użycie procesora do 5 procent i w ten sposób zdławić obciążenie odczytem, co minimalizuje wpływ na operacje we/wy.

Treści powiązane

  • Last updated on