Pytanie PostgreSQL ERROR: anulowanie instrukcji z powodu konfliktu z odzyskiwaniem


Otrzymuję następujący błąd podczas uruchamiania kwerendy na db PostgreSQL w trybie gotowości. Kwerenda, która powoduje błąd, działa poprawnie przez 1 miesiąc, ale gdy wyszukujesz przez ponad miesiąc, pojawia się błąd.

ERROR: canceling statement due to conflict with recovery
Detail: User query might have needed to see row versions that must be removed

Wszelkie sugestie, jak rozwiązać? Dzięki


76
2018-01-29 21:15


pochodzenie




Odpowiedzi:


Uruchamianie zapytań na serwerze hot-standby jest nieco skomplikowane - może się nie powieść, ponieważ podczas odpytywania niektóre potrzebne wiersze mogą być aktualizowane lub usuwane w wersji podstawowej. Jako podstawowy nie wie, że zapytanie jest uruchamiane na poziomie wtórnym, uważa, że ​​może ono oczyścić (odkurzać) stare wersje swoich wierszy. Następnie wtórne musi powtórzyć to oczyszczanie i musi wymusić anulowanie wszystkich zapytań, które mogą korzystać z tych wierszy.

Dłuższe zapytania będą częściej anulowane.

Możesz obejść to, uruchamiając powtarzalną transakcję odczytu na poziomie podstawowym, która wykonuje zapytanie fikcyjne, a następnie siedzi bezczynnie, podczas gdy prawdziwe zapytanie jest uruchamiane na drugorzędnym. Jego obecność uniemożliwi odkurzanie starych wersji wierszy pierwotnych.

Więcej na ten temat i inne obejścia są wyjaśnione w Gorący tryb gotowości - obsługa konfliktów zapytań sekcja w dokumentacji.


48
2018-01-29 23:51



Dla użytkowników PostgreSQL 9.1+: patrz eradmanPoniżej znajduje się odpowiedź na praktyczne rozwiązanie. - Zoltán


Nie ma potrzeby uruchamiania bezczynnych transakcji na urządzeniu nadrzędnym. W postgresql-9.1 najbardziej bezpośrednim sposobem rozwiązania tego problemu jest ustawienie

hot_standby_feedback = on

Spowoduje to, że master będzie świadomy długo działających zapytań. Od docs:

Pierwszą opcją jest ustawienie parametru hot_standby_feedback, co zapobiega   VACUUM usuwa ostatnie, martwe wiersze, więc nie występują konflikty czyszczenia.

Dlaczego nie jest to ustawienie domyślne? Ten parametr został dodany po pierwszym implementacja i to jedyny sposób, w jaki tryb gotowości może wpłynąć na wzorzec.


56
2018-02-10 19:34



Ten parametr powinien być ustawiony w trybie gotowości. - Steve Kehlet
W tym przypadku są pewne wady dla mistrza Hot-Standby-Feedback - Eugene Liskovets
Sprawdź moją odpowiedź, to nie jest dobra praktyka - Gilles Quenot


Jak wspomniano tutaj o hot_standby_feedback = on :

Cóż, wadą tego jest to, że w trybie gotowości można nadąć mistrza,   co też może być zaskakujące dla niektórych osób

I tutaj:

Z jakim ustawieniem max_standby_streaming_delay? wolałbym   domyślnie to do -1 niż domyślne hot_standby_feedback on. W ten sposób co   robisz w trybie gotowości wpływa tylko na tryb gotowości


Więc dodałem

max_standby_streaming_delay = -1

I nie więcej pg_dump błąd dla nas, ani mistrza wzdęcia :)


37
2017-10-22 13:58



@lennard, to działało dla mnie. Dodałem tę konfigurację do postgresql.conf slave'a, a następnie zrestartowałem urządzenie slave. - Ardee Aram
W ten sposób możesz oczywiście uzyskać nieograniczoną replikę lagów. A jeśli używasz gniazda replikacji do połączenia repliki z masterem, może to spowodować nadmierną retencję xloga w systemie głównym, więc jest to naprawdę opłacalne tylko wtedy, gdy korzystasz z archiwizacji WAL. - Craig Ringer
Jak ustawić to na RDS AWS? - Kris MP
@KrisMP Użyj psql - Yehonatan
@KrisMP w grupie parametrów - docs.aws.amazon.com/AmazonRDS/latest/UserGuide/... - r3m0t


Nie trzeba dotykać hot_standby_feedback. Jak wspomnieli inni, ustawienie tego on może nadąć mistrz. Wyobraź sobie otwarcie transakcji na niewolniku i nie zamykanie go.

Zamiast tego ustaw max_standby_archive_delay i max_standby_streaming_delay do jakiejś rozsądnej wartości:

# /etc/postgresql/10/main/postgresql.conf on a slave
max_standby_archive_delay = 900s
max_standby_streaming_delay = 900s

W ten sposób zapytania na niewolnikach trwające krócej niż 900 sekund nie zostaną anulowane. Jeśli twoje obciążenie pracą wymaga dłuższych zapytań, po prostu ustaw te opcje na wyższą wartość.


15
2017-12-05 19:33





Dane tabeli na serwerze podrzędnym trybu gotowości są modyfikowane podczas działania długo działającego zapytania. Rozwiązanie (PostgreSQL 9.1+), aby upewnić się, że dane tabeli nie zostały zmodyfikowane, to zawieszenie replikacji i wznowienie po zapytaniu:

select pg_xlog_replay_pause(); -- suspend
select * from foo; -- your query
select pg_xlog_replay_resume(); --resume

4
2017-10-05 08:56



Wymaga to uprawnień administratora. W niektórych przypadkach może to nie być rozwiązanie. - Joao Baltazar