Baza komunikatów¶

Dla zastosowań produkcyjnych zalecamy zainstalowanie odrębnej usługi bazodanowej dla Postgres, który jest głównym magazynem dla przesyłanych w ramach EDA komunikatów. Przy minimalnym wdrożeniu EDA usługa może być zainstalowana razem z bazą Firebird, ale zalecamy instalację na osobnej maszynie Linuxowej.

Instalacja¶

Zaleca się instalację dedykowanego serwera postgres. W miarę możliwości na osobnej maszynie, w odpseparowaniu od bazy esystem. Proces instalacji został dokładnie opisany w dokumentacji https://www.postgresql.org/docs/current/tutorial-install.html lub w tutorialu ukazującym podstawy tego procesu https://www.postgresqltutorial.com/install-postgresql-linux/

Wymagania¶

Serwer:¶

Procesor (Ilość wątków x taktowanie):
Minimalne: 4 x 1,6 GHz
Zalecane: 4 x 2,2 GHz (lub więcej)
Pamięć RAM:
Minimalne:
- Windows: 8 GB
- Linux: 4 GB
Zalecane:
- Windows: 16 GB
- Linux 8 GB
Pojemność dysku twardego: Minmum: 80GB
System: Zalecany: Linux Debian

Dodatkowe zalecenia:¶

Broker: Zalecany: RabbitMQ
Zewnętrzny serwer PostrgreSQL : Do zastosowań innych niż rozwój oprogramowania na lokalnej maszynie, powinniśmy stosować zewnętrzny serwer bazodanowy, ponieważ wbudowane rozwiązanie nie jest na tyle stabilne, aby zapewnić nieprzerwaną pracę na serwerze produkcyjnym lub współdzielonym do pracy dla więcej niż jednego użytkownika.
Czyszczenie komunikatów: w celu utrzymania rozsądnego rozmiaru bazy danych zaleca się automatyczne czyszczenie komunikatów po określonym czasie. Nie ma tu żadnych widełek, jeżeli chodzi o zalecany okres, ponieważ to zależy od ruchu, jaki odbywa się w mechanizmie EDA.
Pojemność dysku dla bazy danych jest ciężką do jednoznacznego określenia, ponieważ zależy od tego, jak duży ruch jest generowany w ciągu dnia, oraz jak często komunikaty są usuwane. Zalecamy dać większą pojemność i ustawić okresowe usuwanie komunikatów, a następnie po kilku tygodniach będziemy mieli średni rozmiar, jaki nasza baza utrzymuje w danym okresie i wielkość dysku będziemy mogli dostosować do tego rozmiaru, oczywiście biorąc pod uwagę margines.

Kopia bezpieczeństwa¶

Informacje o możliwych technikach tworzenia kopii bezpieczeństwa bazy Postgres można znaleźć tutaj.

Backup/Restore¶

Ręczny zrzut bazy danych do pliku to podstawowa metod wykonywania kopii bezpieczeństwa.

Polecenie backup (pg_dump)¶

pg_dump eda > eda_backup.sql

Polecenie restore¶

psql eda < eda_backup.sql

Kopia cykliczna (cron)¶

Dla minimalnego stopnia zabezpieczeń zalecamy utworzenie harmonogramu tworzenia kopii zapasowej (podobnie jak dla bazy Firebird).

Replikacja¶

Rekomendowanym sposobem utrzymywania kopii bezpieczeństwa jest rozszerzenie cyklicznego backup, opartego na cron, o system replikacji. Wymaga to osobnej instancji bazy i zmian w konfiguracji, aby baza główna po każdej wykonanej transakcji replikowała zmiany na bazy-repliki.

Ustawienie maksymalnej liczby połączeń¶

To ustawienie określa maksymalną liczbę jednoczesnych połączeń z serwerem bazy danych. Domyślnie jest to 100 połączeń. Aby ustawić nową wartość należy wejść do pliku postgresql.conf i wyszukać pozycję max_connections. Tam przypisać nową wartość. Przy zwiększaniu max_connections należy też proporcjonlnie zwiększyć parametr shared_buffers wyszukując go w tym samym pliku, czyli np. gdy ustawimy 100 połączeń to należy ustawić shared_buffers = 100MB. Po wprowadzeniu tych zmian zapisać plik i ponownie uruchomić usługę postgresa.

Uwaga!

W przypadku gdy do bazy łączy się więcej niż 1 serwer Neos i każdy ma po 90 połączeń to tych połączeń musi być conajmniej 100 dla każdego Neosa. Czyli np. dla 3 Neosów ustawiamy max_connections = 300.

Konfiguracja¶

Konfiguracja następuje przez plik *.smd w sekcji [EDA]

Persistance [None|Debug|Embedded|External] - tryb przechowywania komunikatów
None - jak Debug.
Debug - zrzuca komunikaty do pliku log. Wyłącza monitorowanie.
Embedded - wykorzystuje wbudowaną instancje bazy danych do przechowywania komunikatów.
External - wykorzystuje zewnętrzny serwer bazodanowy do przechowywania komunikatów.
PersistanceMaxPoolSize - liczba dostępnych połączeń udostępniona przez connection pooler. Musi być mniejsza (przynajmniej o 10) niż maksymalna liczba połączeń np. gdy max_connections=100 to PersistanceMaxPoolSize=90.
PersistanceHost (external) - adres serwera bazodanowego
PersistancePort (external) - port serwera bazodanowego
PersistanceUsername (external) - użytkownik bazodanowy
PersistancePassword (external) - hasło użytkownika
PersistanceDatabase (external) - nazwa bazy danych na zewnętrznym serwerze bazy danych. Domyslnie "eda"

[EDA]
Persistance=External
PersistanceHost=<host>
PersistancePort=<port>
PersistanceMaxPoolSize=90
PersistanceUsername=<username>
PersistancePassword=<password>
PersistanceDatabase=<bazwa_bazy_posgresql>

Cykliczne czyszczenie bazy danych komunikatów¶

Uwaga!

Od wersji 6.0.10 wprowadzony został domyślny mechanizm czyszczący komunikaty starsze niż 90 dni! Czyszczenie komunikatów EDA

Automatyczne czyszczenie tabeli SYS_EDAEVENTS¶

Tabela SYS_EDAEVENTS przechowuje zdarzenia bazodanowe oczekujące na wyemitowanie na szynie komunikatów. W przypadku dużego ruchu w systemie, tabela ta może znacząco rozrosnąć się, co może wpływać na wydajność systemu.

W celu automatycznego czyszczenia starszych wpisów w tabeli SYS_EDAEVENTS dostępna jest metoda schedulerowa DELETE_EDA_EVENTS.

Konfiguracja parametru retencji¶

Parametr określający ile dni wstecz dane mają być przechowywane jest definiowany w SMD w sekcji EDA:

Nazwa parametru: EdaEventsRetentionDays
Wartość domyślna: 50 dni
Lokalizacja: sekcja [EDA] w pliku SMD

Przykładowa konfiguracja w pliku SMD:

[EDA]
EdaEventsRetentionDays=50

Działanie schedulera¶

Metoda scheduler DELETE_EDA_EVENTS: * Wykonywana jest automatycznie według zdefiniowanego harmonogramu (zalecane: raz dziennie) * Odczytuje parametr EdaEventsRetentionDays z SMD * Usuwa wpisy starsze niż określona liczba dni (data utworzenia < CURRENT_DATE - liczba_dni) * Loguje informacje o liczbie usuniętych rekordów w historii schedulera

Informacja

Harmonogram wykonywania metody schedulerowej oraz jej aktywacja zarządzane są przez moduł Scheduler. Aby zmienić okres retencji, należy zmodyfikować parametr EdaEventsRetentionDays w pliku SMD i zrestartować serwer aplikacji.

Zarządzanie bazą¶

Do zarządzania/przeglądania bazy danych można wykorzystać dowolne narzędzie przeznaczone dla baz PostgreSQL.

Polecamy darmowy programy DBeaver.

Konfiguracja połączenia¶

Baza wbudowana¶

Host: <ip serwera>
Port: <do pobrania z logów serwera> (port ustawia się automatycznie przy pierwszym uruchomieniu bazy wbudowanej, później nie zmienia się)
Database: eda
Username: postgres
Password: <puste> (baza wbudowana przyjmuje jedynie połączenia lokalne)