MySQL to produkt firmy
Oracle i jest on dostępny w kilku komercyjnych wersjach, jak również darmowo jako wersja
MySQL Community Edition. Pliki instalacyjne
MySQL można uzyskać na przykład na
http://www.mysql.com.
Częścią składową pakietu instalacyjnego (od wersji
MySQL 5.6) jest narzędzie do administracji
Workbench oraz również drivera
ODBC.
Do pracy z bazami danych
MySQL w systemie PROMOTIC jest konieczne na komputerze posiadać zainstalowane
32-bitowe drivery do tej bazy danych a to nawet jeżeli sama baza danych jest w wersji 64-bitowej.
Do bazy danych można zapisywać:
- przy pomocy obiektu
PmaDatabase (przestarzałe) poprzez ustawione nazwane źródło danych
ODBC- Wersja Community jest dostępna darmowo.
- Funkcjonalność produktu nie jest sztucznie ograniczana w darmowej wersji.
- Funkcjonalnie oraz konfiguracyjnie jest
MySQL prostrzy od
MS SQL Serwer.
- Baza danych działa jako usługa Windows.
- Umożliwia prosty backup, ustawienie uprawnień dostępu, obsługuje transakje, replikacje, itd.
- Działa przez większość systemów operacyjnych SO Windows, Linux oraz OS X.
- Posiada własny język programowania do definicji tzw. wyzwalaczy (triggers), lub zapisanych procedur.
- Można wybrać jeden z dwu standardowych mechanizmów bazodanowych: MyISAM lub InnoDB.
- Często wykorzystywany w Web aplikacjach
Właściwości podstawowych mechanizmów bazodanowych
MyISAM
MyISAM mechanizm bazodanowy nie jest wskazanym do częstego zapisu, został zoptymalizowany do częstego odczytu z bazy danych, nie wspiera transakcji. Podczas jednoczesnego podłączenia kilku użytkowników stosuje zamki na poziomie całej tabeli.
W systemie PROMOTIC nie jest zalecany do zapisu
trendów,
alarmów oraz
eventów.
InnoDB
Mechanizm
InnoDB jest bardziej odpowiedni do częstszego zapisu, wspiera transakcje, podczas jednoczesnego podłączenia kilku użytkowników stosuje zamki na poziomie wierszy.
Mechanizm ten jest zalecany do stosowania w systemie PROMOTIC do zapisu
trendów,
alarmów oraz
eventów.
Uwaga
Oprócz wszystkich swoich zalet
InnoDB posiada również pewne mankamenty. Jednym z nich jest np. problem z poleceniem typu
SELECT COUNT(*). Mechanizm ten wykonuje to polecenie o tyle dłużej, o ile większa jest tabela, ponad którą polecenie zostało wywołane. Dla tabeli zawierającej około 300-400 tysięcy rekordów może wykonanie tego polecenia trwać aż 1 sekundę. Z tego powodu polecenie to może negatywnie wpłynąć na płynne działanie Państwa aplikacji.
Zalecane ustawienia bazy danych MySQL w celu zastosowania w systemie PROMOTIC
Dla zaawansowanych aplikacji (duża ilość obiektów
PmaTrendGroup, częste zapisy
alarmów itd.) jest konieczne ustawić bazę danych
MySQL dodatkowo tak, by nie dochodziło do jej przeciążenia:
1. W pliku konfiguracyjnym
my.ini jest konieczne zmienieć wybór "
default-storage-engine" na
InnoDB, by ewentualnie nowo wytwarzane tabeli korzystały z mechanizmu
InnoDB. Istniejące tabele należy skonwertować do InnoDB, np. przy pomocy narzędzia administracyjnego
Workbench.
2. Następnie należy dla mechanizmu
InnoDB ustawić "
innodb_flush_log_at_trx_commit" na opcję
0 lub
2 (standardowo jest ustawione na 1). Opcja ta ma wpływ na sposób fizycznego zapisu danych do bazy danych.
0 - dane oraz log transakcji zapisuje na dysk za ok. jedną sekundę - mniejsza ilość operacji dyskowych
1 - log transakcji zapisuje na dysk podczas każdego zapisu - bezpieczne, lecz przy wielkiej ilości jednoczesnych zapisów powolne
2 - zapisuje do logu transakcji podczas każdego potwierdzenia transakcji, ale fizyczny zapis logu transakcji na dysk wykonywany jest ok. 1 raz na minutę - mniejsza ilość operacji dyskowych
3. Zalecane jest również ustawienie pamięci cache dla danych oraz indeksów tebeli przy pomocy wyboru "
innodb_buffer_pool_size". W przypadku deddykowanych serwerów bazodanowych zalecane się aż 70% - 80% instalowanej pamięci RAM.
4.
MySQL jest standardowo ustawiony w taki sposób, by utrzymywał połączenie z klientem na czas
8 godzin (
28800 sekund) jeżeli klient nie wykonuje żadnej czynności. Po upływie w/w okresu połaczenie zostanie automatycznie zamknięte od strony serwera. Zachowanie to spowoduje, że aplikacja PROMOTIC utraci łączność z serwerem bazodanowym i niepotrafi dalej zapisywać potrzebne dane do bazy danych.
Możliwe rozwiązania:
A) Po stronie serwera MySQL - wydłużenie w/w czasu (parametry wait_timeout oraz/lub interactive_timeout) w serwerze MySQL
B)
Po stronie aplikacji PROMOTIC - zapewnienie, by aplikacja PROMOTIC przed upływem tego timeouta periodycznie wykonała dowolną czynność z bazą danych (tzn. zapisała lub odczytała dane z bazy danych)
Opis rozwiązania dla różnych obiektów w aplikacji PROMOTIC:
1. Alarmy/Eventy - wszystkie obiekty
PmaAlarmGroup/
PmaEventGroup o zgodnym parametrze "ConnectionString" korzystają z jednego połączenia do bazy danych. W przypadku
MySQL jest konieczne zapewnić, by przynajmniej raz w określonym czasie (interaction_timeout) zapisano do bazy danych. W praktyce wystarczy wytworzyć jedną grupę eventów i raz na
8 godzin (lub częściej np. każdą godzinę) w aplikacji wytwarzać event typu "aplikacja działa". To zapewni, by połączenie z bazą danych dla alarmów nie zostało zamknięte.
2. Trendy - wszystkie obiekty
PmaTrendGroup o zgodnym parametrze "ConnectionString" korzystają z jednego połączenia do bazy danych. Dlatego jest potrzebne, by przynajmniej jeden
PmaTrendGroup zapisywał częsciej niż określony period timeouta, co w większości przypadków jest zapewnione - sytuacja kiedy aplikacja zapisuje trendy raz na
8 godzin lub rzadziej występuje bardzo rzadko.
3. PmaAdo - tu projektant musi sobie zapewnić, by przynajmniej raz na okres timeouta (lepiej częściej) wykonywał zapytanie do serwera MySQL. W przypadku automatycznego odłączenia serwera obiekt
PmaAdo potrafi wykonać odłączenie/ponowne podłączenie do bazy danych.
Przykład polecenia, który można zastosować w celu utrzymania połączenia z minimalnym obciążeniem serwera MySQL:
SHOW GLOBAL STATUS LIKE 'Uptime'
Następne opisy dotyczące
MySQL patrz: