Delivery 1.0 Help

Zasady tworzenia maszyn pod bazę PostgreSQL

[TL&DR] [Każdy host bazodanowy musi mieć:] [Host produkcyjny obowiązkowo musi mieć:] [Założenia ogólne] [Architektura] [Wersje] [To co musi mieć host bazodanowy] [Q&A]

TL&DR

Każdy host bazodanowy musi mieć:

  • min. 2GB RAM (pamietać żeby podbić parametry postgresa w postgresql.conf wg PGTune)

  • min. 2 CPU

  • osobną partycję na dane (ext4)

  • $PS1 wyświetlane w kolorze i z pełnym hostname

  • fio

  • pg_stat_statements (przez postgresql.conf żeby po restarcie nie ginęło)

    • shared_preload_libraries = 'pg_stat_statements'

    • pg_stat_statements.max = 10000

    • pg_stat_statements.track = all

Host produkcyjny obowiązkowo musi mieć:

  • slave’a (pod dyskusję archiwa bez archiwizacji ciągłej)

  • partycję po NFS na archiwizowani WALi

  • backup (baza transakcyjna raz dziennie, archiwum minimum raz na miesiąc)

  • alias na bazę danych

  • przez postgresql.conf żeby po restarcie nie ginęło

    • log_min_duration_statement = 1000

    • log_lock_waits = on

    • track_activity_query_size = 16384

    • track_io_timing = on

    • tcp_keepalives_idle = 180 (to detect dead connections and prevent FW from closing them)

    • tcp_keepalives_interval = 15

    • tcp_keepalives_count = 4

    • idle_in_transaction_session_timeout = 1d

Założenia ogólne

Architektura

W przypadku małych lub mało obciążonych baz odchodzimy od idei 1 host = 1 baza. W takiej sytuacji (gdy na jednym hoście jest więcej niż jedna baza, każda z nich powinna mieć ustawiony osobny alias. Nazewnictwo do ustalenia, propozycja: nazwa_bazy- rola_replikacji nazwa_projektu.postgresql.dcx.

Wersje

Jeśli w zadaniu nie podano inaczej, instalujemy maksymalny release major, który jednocześnie posiada wersję minor 2 lub większą. Na przykład, na dzień pisania tego artykułu, dostępne są m.in.: wersje 15.1 i 14.7 - wybieramy zatem 14.7 lub czekamy aż pojawi się 15.2. New is better, but not always - w wypadku baz danych, o ile sam upgrade jest bardzo kosztowną operacją, to downgrade na ogół 3+ razy droższą (bo co najmniej 3x dłuższą). PG co roku jesienią wypuszcza nową wersję, więc release x.2 pojawia się na ogół z końcem zimy.

https://www.timescale.com/blog/read-before-you-upgrade-best-practices-for-choosing-your-postgresql-version/

To co musi mieć host bazodanowy

OS: CentOS

$PS1 wyświetlane w przynajmniej w kolorze i z pełnym hostname, czyli np.: root@pg2-prod.postgresql.dc2:~#. Docelowo trzeba będzie dołożyć sprawdzenie, jaką role w replikacji pełni host.

echo 'export PS1="\[\e[1;33m\][\u@\H \W]\$ \[\e[0;00m\]"' >> ~/.bashrc Prod (czerwony): \e[0;31m[\u@\H \w]\$ \e[m Accept (żółty): \e[0;33m[\u@\H \w]\$ \e[m Test (zielony): \e[0;32m[\u@\H \w]\$ \e[m

Jeśli baza ma mieć slave’a (replikę binarną), co zasadniczo jest jednoznaczne z bazą produkcyjną, musi mieć wstawiony zasób po NFS, na którym będzie sobie archiwizować dzienniki transakcji. Rozmiar tego wolumenu to 10% rozmiaru partycji z danymi, ale nie mniej niż 10GB.

Osobna partycję pod dane, z

Q&A

Q: Dlaczego nową maszynę pod upgrade bazy?

Oczywiście, możemy wykonać pg_upgrade, nawet z opcją --link, na ogół nie potrzebujemy wówczas nawet więcej miejsca na dysku i jest to również opcja najszybsza. Co jednak wówczas tracimy to możliwośc bezpiecznego i wygodnego wykonania

Last modified: 30 May 2024