slon - Online w chmurze

PROGRAM:

IMIĘ

slon – demon Slony-I

STRESZCZENIE

slon [opcja]... [nazwa klastra] [powiązać]

OPIS

slon to aplikacja demona, która „uruchamia” replikację Slony-I. Instancja Slon musi być
uruchomić dla każdego węzła w klastrze Slony-I.

OPCJE

-d poziom_logowania
poziom_logowania określa, kiedy i kiedy slon powinien wyświetlać poziomy komunikatów debugowania
rejestrowanie jego aktywności.

Dziewięć poziomów rejestrowania to:

· Fatalny

· Błąd

· Ostrzegać

· Konfiguracja

· Informacje

· Debugowanie 1

· Debugowanie 2

· Debugowanie 3

· Debugowanie 4

Pierwsze pięć poziomów dziennika bez debugowania (od Fatal do Info) to zawsze wyświetlona w
dzienniki. We wczesnych wersjach Slony-I „sugerowane” poziom_logowania wartość wynosiła 2, co by oznaczało
wyświetla listę wyników na wszystkich poziomach aż do poziomu debugowania 2. W wersji 2 Slony-I tak jest
zalecane ustawienie poziom_logowania do 0; większość niezmiennie interesujących informacji z dziennika to
generowane na poziomach wyższych.

-s SYNC ZOBACZ interwał
Interwał synchronizacji, mierzone w milisekundach, wskazuje, jak często slon powinien sprawdzać
aby zobaczyć, czy SYNC należy przedstawić. Wartość domyślna to 2000 ms. Główna pętla w
sync_Thread_main() śpi w odstępach czasu Interwał synchronizacji milisekundy pomiędzy
iteracje.

Krótkie okresy sprawdzania synchronizacji utrzymują pochodzenie na „krótkiej smyczy”, aktualizując je
abonentów częściej. Jeśli masz często powtarzane sekwencje
zaktualizowane bez istnieją tabele, których to dotyczy, dzięki czemu tam nie ma
czasy, gdy aktualizowane są tylko sekwencje, i dlatego Nie odbywają się synchronizacje

Jeśli węzeł nie jest źródłem żadnego zestawu replikacji, więc nie napływają żadne aktualizacje,
jest nieco marnotrawstwem, gdy ta wartość jest znacznie mniejsza sync_interval_timeout
wartość.

-t SYNC interwał Timeout
Na koniec każdego sync_interval_timeout okres przekroczenia limitu czasu, a SYNC zostanie wygenerowany
w węźle „lokalnym”, nawet jeśli nie zaktualizowano żadnych dających się replikować danych
spowodowały SYNC do wygenerowania.

Jeśli działanie aplikacji ustanie, czy to z powodu zamknięcia aplikacji, czy też
ponieważ użytkownicy poszli do domu i przestali wprowadzać aktualizacje, slon(1)
będzie iterował, budząc się każdy Interwał synchronizacji milisekund i, ponieważ nie ma aktualizacji
są robione, nie SYNC zdarzenia zostaną wygenerowane. Bez tego parametru limitu czasu
Nie SYNC zdarzenia zostaną wygenerowane i wydaje się, że replikacja spada
za.

sync_interval_timeout wartość doprowadzi do ostatecznego wygenerowania SYNC, Nawet
chociaż nie było żadnej prawdziwej pracy związanej z replikacją. Im niższy jest ten parametr
jest ustawiony, tym częściej slon(1) wygeneruje SYNC zdarzenia, gdy aplikacja
nie generuje powtarzalnej aktywności; będzie to miało dwa skutki:

· System wykona więcej pracy związanej z replikacją.

(Oczywiście, ponieważ baza danych nie jest obciążona aplikacjami i nie ma danych do
powtórzyć, obciążenie to będzie bardzo łatwe w obsłudze.

· Replikacja będzie wyglądać na bardziej „aktualną”.

(Oczywiście, ponieważ nie ma żadnej powtarzalnej działalności, bycie „bardziej na poziomie”.
data” jest czymś w rodzaju mirażu.)

Wartość domyślna to 10000 ms, a maksymalna to 120000 ms. Domyślnie można oczekiwać, że każdy węzeł to zrobi
„zgłoś się” za pomocą a SYNC co 10 sekund.

Należy pamiętać, że SYNC zdarzenia generowane są także na węzłach abonenckich. Ponieważ tak naprawdę nimi nie są
generowanie dowolnych danych do replikacji do innych węzłów, tj SYNC wydarzenia nie są straszne
dużo wartości.

-g grupa rozmiar
To kontroluje maksimum SYNC Wielkość grupy, sync_group_maxsize; domyślnie wynosi 6. Zatem
jeśli dany węzeł jest opóźniony o 200 SYNCs, spróbuje je zgrupować
na grupy o maksymalnej wielkości sync_group_maxsize. Można się spodziewać, że to się zmniejszy
narzut transakcyjny ze względu na mniejszą liczbę transakcji POPEŁNIĆ.

Domyślna wartość 6 jest prawdopodobnie odpowiednia dla małych systemów, które mogą poświęcić tylko bardzo
ograniczone bity pamięci do slon. Jeśli masz dużo pamięci, tak
rozsądne jest zwiększenie tego, ponieważ zwiększy to ilość pracy wykonanej w każdym z nich
transakcji i pozwoli abonentowi, który ma duże zaległości, nadrobić zaległości
szybko.

Procesy Slon zwykle pozostają dość małe; nawet przy dużej wartości tej opcji,
oczekuje się, że rozmiar slon wzrośnie jedynie do kilku MB.

Dużą zaletą zwiększania tego parametru jest zmniejszenie
liczba transakcji POPEŁNIĆS; przejście z 1 na 2 zapewni znaczną poprawę
korzyści, ale korzyści będą stopniowo maleć po dokonaniu transakcji
przetworzone stają się dość duże. Prawdopodobnie nie będzie materiału
różnica w wydajności pomiędzy 80 a 90; w tym momencie, czy „większy jest”.
lepszy” będzie zależeć od tego, czy większy zestaw SYNCsprawia, że LOG zachowanie kursora
źle, ponieważ zużywa więcej pamięci i wymaga więcej czasu na sortowanie.

W wersji Slony-I 1.0 slon zawsze będzie próbował grupować SYNCjesteśmy w tym razem
maksimum, które nie będzie będzie idealny, jeśli replikacja została nieco zdestabilizowana przez
są bardzo duże aktualizacje (na przykład - pojedyncza transakcja, która aktualizuje setki
tysięcy wierszy) lub przez SYNCs zostaje zakłócony w węźle początkowym, co skutkuje tym
że jest ich kilka SYNCktóre są bardzo duże. Możesz napotkać taki problem
grupując kilka bardzo dużych SYNCs przewraca proces Slon. Kiedy wybiera
ponownie, spróbuje przetworzyć ten sam duży, pogrupowany zestaw SYNCs i wpaść na
ten sam problem w kółko, dopóki administrator nie przerwie tego i nie zmieni
dotychczasowy -g wartość, aby przełamać ten „impas”.

W Slony-I w wersji 1.1 i nowszych, slon zamiast tego adaptacyjnie „przyspiesza”
od zrobienia 1 SYNC jednocześnie w stronę maksymalnej wielkości grupy. W rezultacie, jeśli istnieje
jest kilka SYNCktóre powodują problemy, slon to zrobi (z odpowiednimi
pomoc watchdoga) zawsze będzie w stanie dotrzeć do punktu, w którym przetwarza plik
kłopotliwy SYNCjeden po drugim, co, miejmy nadzieję, sprawi, że pomoc operatora stanie się niepotrzebna.

-o życzenia synchronizować czas
„Maksymalny” czas zaplanowany dla grupy SYNCs.

Jeśli replikacja jest opóźniona, slon będzie stopniowo zwiększać liczbę plików SYNCs
zgrupowane razem, kierując się tym (na podstawie czasu potrzebnego na trwać Grupa
SYNCs) nie powinny przyjmować więcej niż podano pożądany_czas_synchronizacji wartość.

Wartość domyślna dla pożądany_czas_synchronizacji wynosi 60000 ms, co odpowiada jednej minucie.

W ten sposób możesz oczekiwać (lub przynajmniej mieć nadzieję!), że otrzymasz POPEŁNIĆ mniej więcej raz
na minutę.

to nie jest całkowicie przewidywalne, ponieważ jest całkowicie możliwe, że ktoś zażąda
początku. duży aktualizować, wszystko jako jedną transakcję, która może „wysadzić” długość
wynikły SYNC być prawie dowolnie długie. W takim przypadku heurystyka będzie
wycofaj się za Następny grupa.

Ogólnym efektem jest poprawa zdolności Slony-I do radzenia sobie z wahaniami
ruch drogowy. Zaczynając od 1 SYNC, i stopniowo przechodząc do więcej, nawet jeśli nie kolei
się, że różnice są na tyle duże, że powodują awarię backendów PostgreSQL, Slony-I
wycofa się, aby rozpocząć od jednej synchronizacji na raz, jeśli zajdzie taka potrzeba
będzie w ogóle możliwe, aby replikacja mogła postępować.

-c cleanup Cykle
Wartość częstotliwość_próżni wskazuje, jak często ODKURZAĆ w cyklach czyszczenia.

Ustaw tę wartość na zero, aby wyłączyć odkurzanie inicjowane przez slon. Jeśli czegoś używasz
jak pg_autovacuum do inicjowania próżni, może nie być konieczne inicjowanie slona
sam odkurza. Jeśli tak nie jest, istnieje kilka tabel, z których korzysta Slony-I, które zbierają a
los martwych krotek, które należy często odkurzać pg_słuchacz.

W Slony-I w wersji 1.1 to się trochę zmienia; ścieżki wątku czyszczącego, z
iteracja do iteracji, najwcześniejszy identyfikator transakcji nadal aktywny w systemie. Jeśli
to się nie zmienia z jednej iteracji na drugą, wtedy jest to stara transakcja
nadal aktywny, a zatem a ODKURZAĆ nie przyniesie nic dobrego. Zamiast tego wątek czyszczący
po prostu robi ANALIZOWAĆ w tych tabelach, aby zaktualizować statystyki pg_statystyka.

-p PID filename
plik_pid zawiera nazwę pliku, w którym przechowywany jest PID (identyfikator procesu) slon.

Może to ułatwić konstruowanie skryptów do monitorowania wielu procesów Slon
działa na jednym hoście.

-f config filet
Plik, z którego można odczytać konfigurację slon.

Konfiguracja ta jest omówiona szerzej w Konfiguracja czasu wykonywania Slon [„Run-time
Konfiguracja” [niedostępne jako strona podręcznika]]. Jeśli ma istnieć złożony zestaw
parametrów konfiguracyjnych lub jeśli istnieją parametry, których nie chcesz, aby były widoczne
w zmiennych środowiskowych procesu (takich jak hasła), może to być wygodne
narysować wiele lub wszystkie parametry z pliku konfiguracyjnego. Możesz albo umieścić wspólne
parametry dla wszystkich procesów Slon w powszechnie używanym pliku konfiguracyjnym, umożliwiając
wiersz poleceń, aby określić niewiele poza informacjami o połączeniu. Alternatywnie,
możesz utworzyć plik konfiguracyjny dla każdego węzła.

-a archiwum katalog
katalog_archiwum wskazuje katalog, w którym należy umieścić sekwencję SYNC archiwum
pliki do wykorzystania w transporcie kłód [„Wysyłka kłód – Slony-I z plikami” [niedostępne
jako strona podręcznika]] w trybie.

-x komenda do biegać on log archiwum
polecenie_na_logarchiwum wskazuje polecenie, które należy uruchomić za każdym razem, gdy plik SYNC jest odtwarzany
pomyślnie wygenerowany.

Zobacz więcej szczegółów na temat „slon_conf_command_on_log_archive” [niedostępne jako mężczyzna
strona].

-q porzucić na podstawie on SYNC dostawca
dostawca Quit_sync_provider wskazuje, w którym wątku roboczym dostawcy należy obserwować
zakończyć po określonym zdarzeniu. Należy tego używać w połączeniu z
-r opcja poniżej...

Pozwala to na zatrzymanie replikacji slon po pewnym momencie.

-r porzucić at wydarzenie numer
wyjdź_sync_finalsync wskazuje numer zdarzenia, po którym następuje wątek pracownika zdalnego
dla powyższego dostawcy powinna zostać rozwiązana. Należy tego używać w połączeniu z
-q opcja powyżej...

-l wlec się interwał
odstęp_opóźnienia wskazuje wartość przedziału, np 3 minuty or 4 godzin or 2 dni
oznacza to, że ten węzeł ma opóźniać swoich dostawców o określony przedział czasu
czas. Powoduje to, że zdarzenia są ignorowane, dopóki nie osiągną odpowiedniego wieku
przerwa.
Ostrzeżenie

Opóźnienie to ma jednocześnie wadę; zdarzenia, które wymagają od wszystkich węzłów
zsynchronizować, jak to zwykle bywa SŁONIK PRZEŁĄCZENIE AWARYJNE(7) i SŁONIK MOVE SET(7)
będzie musiał poczekać na ten opóźniony węzeł.

Może to nie być idealne zachowanie w czasie przełączania awaryjnego lub w momencie, gdy tego chcesz
biegać SŁONIK WYKONAĆ SCRIPT(7).

EXIT STATUS

slon zwraca 0 do powłoki, jeśli zakończyło się normalnie. Wraca przez wyjście(-1) (które będą
prawdopodobnie zwróci wartość 127 lub 255, w zależności od systemu), jeśli tak
napotka jakiś błąd krytyczny.

Używaj Slon online, korzystając z usług onworks.net