1 Temat przez freez

  • freez
  • Nowy
  • Nieaktywny
  • Zarejestrowany: 2010-03-02
  • Posty: 2

Temat: Procedura serwisowania bazy w aplikacji trybu online

zamieszczam w tym dziale gdyż problem jest chwilowo czysto teoretyczny (aplikacja jeszcze nie działa) ale jestem na etapie planowania architektury.

Otóż chciałbym uzyskać funcjonalność którą czasem widać w sklepie internetowym pewnej firmy  Ko...nik .pl
Otóż jak sklep "muli" dostaje się komunikat iż "proszę o powrócenie za parę minut gdyż baza jest serwisowana"

Moje pytanie :
czy w postgresie da się zastopować bazę w taki sposób by dokonać reindeksacji i czyszczenia i jednocześnie powiadomić aplikację iż baza ma tryb serwisowy? czy taki tryb istnieje w postrgresie?

Myślałem by po prostu zablokować tabele do odczytu dla danego użytkownika (użytkowników trzymam w aplikacji a nie w bazie)  ,a z poziomu dbadmina wykonać skrypt czyszczący.

Nie mam także pomysłu na to w jaki sposób automatycznie sprawdzić iż baza zaczyna mulić?
----  odpalać zapytanie które zwracało by czas wykonania ?? - jeśli byłby większy niż założony X wtedy baza/tabele byłyby blokowane a nastepnie wykonywane czyszczenie(lub inne operacje optymalizujące) itp.

za wszelkie sugestie będę bardzo wdzięczny.

2 Odpowiedź przez rski

  • rski
  • Moderator
  • Nieaktywny
  • Skąd: Gdańsk
  • Zarejestrowany: 2008-03-02
  • Posty: 924

Odp: Procedura serwisowania bazy w aplikacji trybu online

Możesz zatrzymać bazę i uruchomić bazę w trybie single-user i a następnie wykonać operacje administracyjne.
Znam tylko jeden 'automat' który sprawdza czy baza muli i dlaczego, nazywa się administrator smile (ale oczywiście możesz spróbować napisać jakiś skrypt który będzie sprawdzał jak sobie baza radzi).

PS
Często się ma pojawiać taki komunikat "Baza jest serwisowana .." bo jeśli często to chyba niezbyt dobrze co? W końcu sklep internetowy na tym zarabia ze jest dostępny a nie 'serwisowany' taki komunikat moze zniechęcać. Moze warto pomysleć nad jakimś zapasowym serwerem i przełączaniem się na niego podczas 'konserwacji' głównej bazy.

3 Odpowiedź przez freez

  • freez
  • Nowy
  • Nieaktywny
  • Zarejestrowany: 2010-03-02
  • Posty: 2

Odp: Procedura serwisowania bazy w aplikacji trybu online

Witam psorze wink  i dzięki za odp.

po pierwsze : to nie ma być sklep - raczej system planowania z częstym updatem
po drugie : w trakcie tej przerwy serwisowej chciałbym wykonać trochę więcej niż tylko optymalizację.

Mam ambicje by system był bliski systemowi czasu rzeczywistego - przynajmniej w niektórych aspektach.  Ponieważ moja wiedza jest jeszcze za płytka by stosować serwer aplikacyjny a używanie triggerów przy każdej operacji jest dość kosztowne chciałbym co np. 3 godziny robić około 1min przerwę serwisową podczas której byłyby wykonywane przeliczenia z jobów - np generowanie widoków , indeksów itp  (zakładam tu pewną transakacyjność i limit czasu na wykonanie wszystkich przeliczeń)

zakładam iż paczka danych do przeliczenia będzie zawsze taka sama - średni dzienny przyrost i tylko na tej paczce byłyby wykonywane te przeliczenia - oczywiście raz na dobę i raz na tydzień startowałyby inne joby .
Stosując częstsze interwały mogę skrócić czas wykonywania operacji z jobów - nie znalazłem jeszcze metody by "obliczyć" co mi się bardziej opłaca.

W obecnej chwili staram się znaleść jakieś informacje jak napisać takiego interceptora który sprawdza wydajność bazy.
Do pierwszego poziomu sprawdzania wykorzystam chyba pgpinga smile lub pgbash'a

4 Odpowiedź przez rski

  • rski
  • Moderator
  • Nieaktywny
  • Skąd: Gdańsk
  • Zarejestrowany: 2008-03-02
  • Posty: 924

Odp: Procedura serwisowania bazy w aplikacji trybu online

Pewnie dałoby się znaleźc jakiś program (pewnie na pg_foundry.org) do mierzenie wydajności w najprostszej postaci możesz
1) samo okresowo zapuszczac jakieś zapytanie i sprawdzać czas odpowiedzi, ale w ten sposób sam będziesz obciążał bazę
2) sprawdzać zużycie zasobów (CPU, MEM) w systemie przez postgersa
3) założyc sobie ile może maksymalne wykonywać się zapytanie i skonfigurowac postgresql.conf tak aby logował zapytania wykonujące się dłużej niż założony czas, jeśli zacznie coś logować to baza zaczyna mulić (chociaż to też pewnie naciągane)