[breja]

Jak najlepiej zabezpieczyć bazę #postgresql ? ustawić na dwóch maszynach postgresa w trybie master-slave, DRBD, GlusterFS czy jeszcze coś innego? nie potrzebuję HA ani LB. Liczy się tylko by nie stracić danych w razie problemów lub stracić ich z max godziny. Baza ma ok 1.5GB i rośnie 3MB dzień
#sysadmin #devops

[szczeppan]

@breja: z tych bardziej szalonych pomysłów: vm na raid 1? Albo raid 5? Albo nawet same pliki danych na raid wrzucić

[breja]

@szczeppan: ESXi i wirtualka jest na raid10 z ssd a zrzut bazy i vm nocą na inny storage ale jak by co to strata całego dnia

[szczeppan]

@breja: strata danych z całego dnia czy że baza nie będzie cały dzień dostępna?

[breja]

@szczeppan: strata danych bo robię wszystkie kopie w nocy

[szczeppan]

@breja: ale raid 10 w najlepszym wypadku pozwoli Ci na pad połowy dysków, więc przed tym jesteś zabezpieczony. A jak chcesz to mieć jeszcze na innej maszynie dodatkowo replikowane, to możesz nawet głupim rsync + cron zrobić. HA ani LB nie potrzebujesz, więc nie widzę sensu stawiania drugiego środowiska do tego celu. No chyba że chcesz przy okazji przetestować jak to się robi, to w takim wypadku polecam :)

[plushy]

A jak chcesz to mieć jeszcze na innej maszynie dodatkowo replikowane, to możesz nawet głupim rsync + cron zrobić.

@szczeppan: Kopiowanie plików na których pracuje jakaś aplikacja rsynciem to proszenie się o kłopoty.

[szczeppan]

@plushy: dokumentacja nawet o tym pisze, że to jest jedna z metod. I dla takiej ilości danych to jest chyba najszybsze rozwiązanie

[plushy]

@szczeppan:

his is done by first running rsync while the database server is running, then shutting down the database server long enough to do an rsync --checksum. (--checksum is necessary because rsync only has file modification-time granularity of one second.) The second rsync will be quicker than the first, because it has relatively little data to transfer, and the end result will be consistent because the server was down. This method

[breja]

nie wchodzi w grę w trakcie dnia roboczego a w innych godzinach to i tak robie dump bazy i vm, wiem ze jest przynajmniej kilka rozwiazan np barman, replikacja ale szukam kogos kto mi powie ja to mam tak i tak i to dziala ;)

[szczeppan]

@plushy: jedyny poblem może być jeśli będzie rsync w trakcie transakcji, ale przy takiej ilości zapisywanych danych można robić rsync co np 30 minut i nigdy nie trafić w taki przypadek. Teoretycznie jeśli rsync pójdzie w czasie otwartej transakcji, to bazie się nie powinno nic stać. Teoretycznie, bo w praktyce to sprawdzę jak do domu wrócę

[maniac777]

@breja: To zależy czego oczekujesz i przed czym chcesz się zabezpieczyć. Jak przed awarią sprzętu to odpowiedzią jest replikacja i wtedy po takiej awarii masz zawsze slave i prawdopodobnie stracone jakieś kilkanaście-kilkadziesiąt sekund transakcji. Chyba że jesteś w stanie zaakceptować opóźnienia wynikające z replikacji synchronicznej wtedy możesz w wypadku awarii bazy nie stracić żadnej zamkniętej transakcji. Jeżeli interesuje cię zabezpieczenie się przed błędami wynikającymi z błędów ludzkich to backup bazy +

[plushy]

@szczeppan: Postgres jest zaprojektowany by przeżyć odłączenie prądu a nie rsynca, jeśli pliki się między sobą nie zgadzają lub początek pliku z końcem to będzie sieczka.

@maniac777: O ile się orientuję to polecenia blokuje replikację na slave, osobiście wybrałbym pg_dump który jest ogólnie wolniejszy ale nie blokuje nic i nie trzeba mieć replikacji. Ewentualnie snapshot całego dysku na systemie który to obsługuje, EBS ma np. taką możliwość.

[maniac777]

@plushy: Przy start backup i stop backup można kopiować na żywo i jest szybko. Jedyny mankament to tak stworzoną kopię uruchamia się na bazie w tej samej wersji i w systemie z tą samą architekturą oraz to że w backupie mogą wylądować (i prawdopodobnie wylądują) również nieużywane bloki z plików danych. Wylądują też indeksy co sprawia że taki backup jest zwyczajnie większy, ale z drugiej strony nie muszą być one ponownie

[breja]

@maniac777: zabezpieczenie tylko przed awaria sprzętu, drobne straty nie są problemem. To że żywcem rsync się nie nadaje to wiem, o pgstartbackup zapomniałem a widziałem to kiedyś w skryptach bodaj baculi.
@plushy: snapshoty mogę robić na ESXi ale nie chroni mnie to przed utrata sprzętu a przewalanie tych obrazów w tej chwili odpada (miedzy serwerami 100Mb)

[plushy]

@maniac777: Przy -Fc bym dodał że można takie pliki odtwarzać wielowątkowo i to jest ważniejsze niż kompresja bo zwykły tekstowy dump można walnąć do gz i nie będzie dużej różnicy.

Interesuje mnie natomiast czy można startbackup używać bez przerzucanie serwera w tryb read only czy jednak nie, bo jeśli baza ma być normalnie dostępna to pgdump jest lepszym rozwiązaniem nawet jeśli zależy nam nad tym by nie było przerw

[maniac777]

zabezpieczenie tylko przed awaria sprzętu, drobne straty nie są problemem.

@breja: To replikacja streaming.

https://wiki.postgresql.org/wiki/Streaming_Replication

Baza slave będzie dostępna do odczytu, ale pod pewnymi warunkami (jak w ramach replikacji przyjdzie log modyfikujący blok potrzebny do przeprowadzenia zapytania, to zapytanie zostanie przerwane). Jak Replikacja się wyrabia to po awarii sprzętu stracisz kilka do kilkunastu sekund. Failover jest operacją jednokierunkową i po jego przeprowadzeniu musisz zestawić replikację w drugą stronę.

Przy -Fc bym

[szczeppan]

@plushy: nie wiem czemu ubzdurało mi się, ze rsync robi snapshot na początku kopiowania, mój błąd. Natomiast bywają sytuacje, że właśnie rsync na żywej bazie jest jednym z najlepszych rozwiązań. Przykładowo: jak baza jest na tyle duża, że jej skopiowanie zajmuje kilka godzin, a chcesz przed wdrożeniem czegoś (np migracją danych) mieć jej kopię na koniec dnia. W takim wypadku odpowiednio wcześniej puszczasz rsync właśnie na żywej bazie. Na koniec dnia

[maniac777]

Na koniec dnia jak już się skończy kopiować, to bazę zatrzymujesz, ponowny rsync, który tym razem będzie trwał parę minut i dogra tylko resztki zmian, start bazy.

@plushy @szczeppan: to chyba tak nie zadziala. Baza przy zamykaniu prawdopodobnie zostanie podciagnieta do stanu spojnego.