Parametry mogą być ustawiane na różnych poziomach. Niektóre z nich da się ustawić dla sesji, a nawet transakcji (jak np. work_mem), inne dotyczyć mogą tylko całego klastra (jak shared_buffers).
Sprawdzać ustawienie parametrów klastra możemy na dwa sposoby. Poprzez komendę show oraz słownik pg_settings. Aby sprawdzić aktualne ustawienie dla naszej sesji jakiegoś parametru, możemy wywołać:
show nazwa_parametru;
W tym samym celu możemy też skorzystać ze słownika pg_settings. Jest tam więcej informacji:
select * from pg_settings;
Znajdziemy tu nazwy parametrów, ich aktualne ustawienie, opis do czego służy parametr oraz wiele innych. Możemy więc sprawdzić aktualne ustawienie parametru choćby w ten sposób:
select name,setting from pg_settings where name='log_line_prefix';
Należy pamiętać, że parametry można ustawiać na różnych poziomach. Za pomocą komendy show lub słownika pg_settings zobaczymy ustawienie obowiązujące dla naszej sesji - niezależnie od poziomu, na jakim dany parametr został ustawiony.
O ile "pg_settings" pokaże nam ustawienia obowiązujące nas, o tyle z pomocą słownika "pg_file_settings" można sprawdzić ustawienia pochodzące z plików konfiguracyjnych "postgresql.conf" i "postgresql.auto.conf", a więc obowiązujące dla całego klastra. Parametry tu widoczne będą uwzględniały również zmiany naniesione poleceniem:"alter system".
select * from pg_file_settings;
Niektóre z parametrów wymagają restartu, inne tylko przeładowania konfiguracji, a jeszcze inne można ustawić na poziomie bazy danych, użytkownika czy sesji. Możemy to zweryfikować za pomocą kolumny "context" w słowniku "pg_settings". Wartości bez powtórzeń, jakie pojawiają się w tej kolumnie, możemy zweryfikować następującym zapytaniem:
select distinct context from pg_settings;
Co oznaczają poszczególne wartości?
internal - Takie parametry to wartości ustalone wewnętrznie. Nie można ich zmieniać bezpośrednio. Są to takie parametry, jak np. wersja oprogramowania PostgreSQL.
postmaster - Zmiana takich parametrów wymaga restartu. Są to takie parametry, jak np. wielkość pamięci dostępnej dla klastra PostgreSQL
sighub - Zmiana wymaga tylko przeładowania konfiguracji klastra (choć może być też restart).
backend - Takie parametry można ustawić tylko w chwili nawiązywania połączenia z PostgreSQL. Mogą też być zmieniane przez przeładowanie konfiguracji.
superuser - Parametry, które może ustawić tylko superuser klastra. Do ich zmiany wymagane jest przeładowanie konfiguracji (choć może być też restart).
superuser-backend -Takie parametry można ustawić w chwili nawiązywania połączenia z PostgreSQL przez użytkownika lub dla klastra. Zmiana takich parametrów dla klastra wymaga przeładowania konfiguracji. Są to parametry umożliwiające np. logowanie wszystkich połączeń.
user - Te parametry mogą być zmieniane nawet przez zwykłego użytkownika na poziomie trwającej sesji. Przez superużytkownika mogą być dodatkowo ustawiane na poziomie klastra, bazy danych, użytkownika czy użytkownika w wybranej bazie. Zmiana takich parametrów dla całego klastra będzie wymagała przeładowania konfiguracji.
Parametry możemy zmieniać na różnych poziomach. Sprawdź: "Sprawdzanie dostępnych poziomów konfiguracji parametrów". W zależności od parametrów dostępne są ustawienia na różnych poziomach.
Ustawienia parametrów dla sesji przesłaniają ustawienia mniej granularne - w tym te wprowadzone w postgresql.conf. Do sprawdzenia, jaką mamy obowiązującą wartość parametru w sesji, możemy użyć polecenia show lub słownika pg_settings. W obu przypadkach będziemy widzieć ustawienie obowiązujące na poziomie naszej sesji. Trzeba pamiętać, że obowiązująca dla sesji wartość parametrów może wynikać z konfiguracji na różnych poziomach. Zawsze obowiązuje najbardziej granularny poziom. Sprawdzenie za pomocą słownika pg_settings:
select * from pg_settings where name='work_mem';
Sprawdzenie za pomocą show:
show work_mem;
Za pomocą show możemy też wyświetlić wszystkie parametry obowiązujące dla naszej sesji:
show all;
Istnieją dwa sposoby, aby zmienić parametr dla sesji. Możemy użyć komendy: "set" lub dokonać aktualizacji słownika "pg_settings" za pomocą update (!!!). Ustawiamy parametr "work_mem" za pomocą "set" i sprawdzamy jego ustawienie:
set work_mem='16MB';
show work_mem;
Ciekawostka - zmienić parametr dla sesji możemy również poprzez update na pg_settings:
update pg_settings set setting='32MB' where name='work_mem';
show work_mem;
Aby przywrócić domyślną wartość dla parametru ustawionego w ramach sesji, wystarczy zastosować komendę: "reset". Można przywrócić pojedynczy parametr:
reset work_mem;
lub wszystkie parametry ustawione dla sesji:
reset all;
Niektóre parametry możemy zmieniać dla wybranej bazy danych. Będą one obowiązywały w przypadku połączenia się nową sesją z daną bazą. Zmiana parametru nie będzie obowiązywać dla sesji już podłączonych. Należy pamiętać, że ustawienia dla bazy danych są przesłaniane przez ustawienia dla sesji. W celu prezentacji zmiany parametru dla bazy tworzymy nową bazę danych i ustawiamy dla niej parametr "work_mem":
create database test_config;
alter database test_config set work_mem='123MB';
Następnie łączymy się do tej bazy i sprawdzamy wartość parametru. W tym celu łączymy się za pomocą psql do bazy "test_config" i sprawdzamy aktualne ustawienie:
psql -d test_config
show work_mem;
Jak widać, dla nowo nawiązanej do bazy danych sesji “test_config” ten parametr obowiązuje.
Możemy też sprawdzić obowiązujące ustawienia dla baz danych dzięki słownikowi "pg_db_role_settings". Sprawdzamy, co mamy ustawione indywidualnie dla naszych baz:
select datname,setconfig
from pg_db_role_setting pdrs
join pg_database pd
on pdrs.setdatabase=pd.oid;
Jak widać, mamy ustawiony work_mem na 123MB dla bazy “test_config”.
Niektóre parametry możemy zmieniać dla wszystkich sesji danego użytkownika. Będą one obowiązywały dla wszystkich nowych sesji danego użytkownika. Zmiana parametru nie będzie obowiązywać dla sesji już podłączonych. Należy pamiętać, że ustawienia dla użytkownika są przesłaniane przez ustawienia dla sesji, natomiast same przesłaniają ustawienia dla bazy danych. W celu prezentacji tworzymy nowego użytkownika i ustawiamy dla niego work_mem na 40 MB:
create user mapet with password 'mapet';
alter user mapet set work_mem='40MB';
Następnie łączymy się z pomocą psql jako ten użytkownik i sprawdzamy jego aktualne ustawienie:
psql -U mapet -d postgres
show work_mem;
Przy łączeniu wskazujemy również bazę, ponieważ jeśli tego nie zrobimy, psql będzie usiłował łączyć się do bazy o nazwie takiej, jaka jest nazwa użytkownika, czyli np. mapet, a takiej bazy nie mamy.
Sprawdzamy, czy ustawienie to obowiązuje również dla bazy "test_config", dla której zmieniliśmy ten sam parametr:
psql -U mapet -d test_config
show work_mem;
Jak widać, obowiązuje ustawienie bardziej granularne. Ustawienie parametru dla użytkownika przesłania ustawienie dla danej bazy danych.
Obowiązujący dla danego użytkownika parametr możemy również sprawdzić, zaglądając do słownika "pg_shadow" lub "pg_user". Pg_shadow:
select usename, useconfig from pg_shadow;
Możemy znaleźć użytkowników, którzy mają indywidualnie ustawiony parametr, np. za pomocą takiego zapytania:
select * from (select usename,unnest(useconfig) as config from pg_user) e
where config like '%work_mem%';
W tym przypadku znaleźliśmy użytkowników mających indywidualnie ustawiony work_mem.
Niektóre parametry możemy zmieniać dla wszystkich sesji danego użytkownika w konkretnej bazie danych. Będą one obowiązywały dla wszystkich nowych sesji danego użytkownika łączących się do wskazanej bazy danych. Zmiana parametru nie będzie obowiązywać dla sesji już podłączonych. Należy pamiętać, że ustawienia dla użytkownika w bazie danych są przesłaniane przez ustawienia dla sesji, natomiast same przesłaniają ustawienia dla bazy danych oraz na poziomie samego użytkownika. W celu prezentacji ustawiamy dla wcześniej tworzonego użytkownika "mapet" w bazie "testy_config" parametr "work_mem" na 64MB i sprawdzamy to ustawienie za pomocą psql (nawiązując przy okazji nową sesję). Przestawiamy parametr:
psql
alter user mapet in database test_config set work_mem='64MB';
Następnie łączymy się jako użytkownik mapet do bazy test_config i sprawdzamy ustawienie work_mem dla naszej sesji:
psql -U mapet -d test_config
show work_mem;
Możemy też sprawdzić wszystkie ustawienia na wszystkich poziomach. Aby sprawdzić ustawienia indywidualne dla użytkownika, bazy danych czy użytkownika w konkretnej bazie danych możemy posłużyć się zapytaniem:
SELECT r.rolname, d.datname, rs.setconfig
FROM pg_db_role_setting rs
LEFT JOIN pg_roles r ON r.oid = rs.setrole
LEFT JOIN pg_database d ON d.oid = rs.setdatabase;
Jak widać, wynik działania prezentuje wszystkie ustawienia trwałe skonfigurowane w tym rozdziale. Jest wylistowane ustawienie work_mem zarówno dla samej bazy test_config, dla samego użytkownika mapet oraz dla użytkownika mapet w bazie test_config.
Ustawienia konfigurowane dla użytkownika, bazy danych czy użytkownika w bazie danych można zresetować. Po takiej operacji będą obowiązywać parametry ustawione dla klastra lub indywidualnie dla sesji. Należy pamiętać, że reset parametrów będzie obowiązywał od następnego połączenia i nie będzie dotyczył połączeń już nawiązanych.
Poniżej przykłady resetowania ustawień dla użytkownika, bazy danych, użytkownika w bazie danych - w takiej właśnie kolejności.
alter role mapet reset work_mem;
alter database test_config reset work_mem;
alter role mapet in database test_config reset work_mem;
Po wydaniu tych komend sprawdzamy, czy ustawienia nadal obowiązują, lista jest pusta:
Parametry możemy zmieniać również na poziomie klastra - będą wtedy obowiązywały dla wszystkich baz danych, wszystkich użytkowników, o ile nie zostanie zastosowane ustawienie na bardziej granularnym poziomie.
Zmieniać parametry klastra możemy na dwa sposoby – poprzez zmianę w pliku postgresql.conf lub wydanie polecenia: "alter system". Polecenie "alter system" dostępne jest od wersji 9.4.
Zmiana parametru przez plik konfiguracyjny postgresql.conf sprowadza się do jego edycji, a następnie przeładowania konfiguracji lub restartu (w zależności od wymogów danego parametru). Trzeba pamiętać o wcześniejszym zalogowaniu się jako użytkownik systemowy postgres. Eksperymentalnie zmienimy parametr "work_mem" (odpowiedzialny za przestrzeń pamięci dostępną dla zapytań) dla całego klastra. W tej chwili dla użytkownika postgres jego wartość jest zgodna z domyślną i wynosi 4MB:
Edytujemy teraz plik konfiguracyjny i zmieniamy jego wartość jako użytkownik systemowy postgres:
nano /data_pg/postgresql.conf
Odnajdujemy linię z parametrem “work_mem” (wyszukiwanie w nano to ctrl+w). Odkomentowujemy linię z tym parametrem i zmieniamy jego wartość na 8MB:
Bez przeładowania konfiguracji zmiana tego parametru nie będzie działać. Możemy to sprawdzić, korzystając ponownie z "show work_mem". Musimy więc przeładować konfigurację:
psql -c "select pg_reload_conf()"
bądź z poziomu PgAdmin4:
select pg_reload_conf();
Niektóre parametry wymagają tylko przeładowania konfiguracji jak wyżej (bez restartowania instancji klastra), inne restartu. Te, które wymagają restartu, mają w pliku postgresql.conf komentarz obok: "(change requires restart)". Po wykonaniu przeładowania możemy ponownie sprawdzić wartość tego parametru. Co ciekawe, zmiana dotyczyć będzie już nawiązanych i trwających sesji.
Parametry dla klastra od wersji 9.4 możemy również zmieniać poprzez komendę: "alter system". Parametry zmieniane poprzez "alter system" będą gromadzone w osobnym pliku konfiguracyjnym tj. "postgresql.auto.conf" znajdującym się obok "postgresql.conf" w PGDATA. Zmieniamy parametr "work_mem" za pomocą "alter system". Po wykonaniu, podobnie jak w przypadku zmiany w pliku "postgresql.conf", trzeba jeszcze przeładować konfigurację:
psql
alter system set work_mem='32MB';
psql -c "select pg_reload_conf()"
Sprawdzamy teraz ustawienie:
Parametry ustawiane poprzez "alter system" są wprowadzane do "postgresql.auto.conf", a nie aktualizowane w "postgresql.conf". Zajrzyjmy więc, co widać w jednym i drugim pliku. Ustawienie work_mem wg "postgresql.conf":
cat /data_pg/postgresql.conf | grep work_mem
Według postgresql.conf mamy 8MB work_mem. Porównamy to z postgresql.auto.conf, do którego dopisywane są parametry ustawiane przez alter system:
cat /data_pg/postgresql.auto.conf | grep work_mem
Według postgresql.auto.conf mamy 32MB pamięci. Sprawdzamy więc, które ustawienie obowiązuje:
psql
show work_mem;
Widzimy, że ten sam parametr może być ujęty w postgresql.conf i postgresql.auto.conf, natomiast obowiązujący będzie zawsze ten w postgresql.auto.conf. Wynika to z tego, że postgresql.auto.conf jest czytany jako drugi i wszelkie ustawienia w nim zawarte nadpisują ustawienia tych samych parametrów z postrgesql.conf’a. Z tego powodu warto jest zmieniać parametry poprzez “ALTER SYSTEM”. Dzięki temu będziemy widzieć w tym pliku wszystkie zmieniane parametry, do tego w chronologicznej kolejności.
Część parametrów klastra możesz również oddelegować do osobnych plików konfiguracyjnych. Jest to przydatne np w sytuacji gdy zarządzasz wieloma serwerami o prawie identycznej konfiguracji, ale różniącej się kilkoma parametrami. Możemy wciągnąć dodatkowe konfiguracje z konkretnego wskazanego pliku za pomocą include, lub cały katalog z dodatkowymi plikami konfiguracyjnymi za pomocą include_dir. Ważne - w przypadku include_dir wszystkie dodatkowe pliki konfiguracyjne muszą mieć rozszerzenie .conf bo tylko takie pliki będą przeszukiwane. Jeśli dodamy takie pliki lub katalogi, parametry z nich będą czytane pomiędzy postgresql.conf a postgresql.auto.conf. Aby wskazać dodatkowy pojedynczy plik, dodajemy w postgresql.conf taki parametr:
include ‘memory.conf’
Aby wskazać katalog z dodatkowymi plikami konfiguracyjnymi dodajemy w postgresql.conf taki parametr:
include_dir ‘additional_configs’
W samych plikach dodatkowych umieszczasz parametry tak jak w postgresql.conf. Po co nam taka możliwość? Przykład z życia, kiedy zmieniamy cokolwiek w klastrze, otwieramy dla tej zmiany no wy case, czy to w jirze czy jakimkolwiek innym systemie z ticktami, tam jest informacja co było zmienione, z jakiej wartości na jaką i dlaczego, a w "include_dir" tworzymy plik o nazwie X_jira-8123.conf, gdzie X to liczba porządkowa pliku konfiguracyjnego (1, 2, 3, ... 99, itd.). Jak potem jest problem, że coś nie działa i podejrzewasz jakiś parametr, sprawdzasz sobie w "select * from pg_file_settings" z którego pliku wartość jest pobierana dla danego parametru, od razu widzisz numer case'a z jiry, otwierasz historię i widzisz kto, co i dlaczego zmienił. Bardzo dobra praktyka.
Przeprowadźmy mały test. Tworzę sobie dodatkowy katalog w PGDATA i umieszczam w nim plik konfiguracyjny:
mkdir /data_pg/additional_configs
nano /data_pg/additional_configs/jira_1234.conf
Umieszczam w nim linijkę ustawiającą work_mem (sprawdź czy nie nadpisujesz tego parametru w postgresql.auto.conf):
work_mem=’666MB’
Do pliku postgresql.conf dodaję taką linijkę:
include_dir = 'additional_configs'
Restartuję klaster
pg_ctl -D /data_pg restart
Sprawdzam jakie są ustawienia parametru work_mem i z którego pliku wynikają:
psql
select * from pg_file_settings where name='work_mem';
Komentarze (0)
Brak komentarzy...