Panowie z supportu, którzy obsługują serwer na którym stoi moja aplikacja codziennie w nocy wykonują backup bazy. Z jakiegoś powodu wymyślili sobie, że muszą na czas backupu wyłączać bazę (nie muszą, prawda?). Niestety po restarcie aplikacja nie nawiązuje ponownie połączenia i rzuca błędem 500. W logach natomiast:
[code]Started POST “/users/login” for 79.190.190.67 at 2011-08-26 08:40:45 +0200
Processing by Devise::SessionsController#create as HTML
Parameters: {“utf8”=>“✓”, “authenticity_token”=>“cJwisNE209l9CgTL5zwjwaqeyLJAfJ2x7ed/fJfx8k4=”, “user”=>{ (…) }, “commit”=>“Zaloguj”}
Redirected to http://prokliencki.eu/
Completed 302 Found in 360ms
Started GET “/” for 79.190.190.67 at 2011-08-26 08:40:45 +0200
PGError (no connection to the server):[/code]
Z tego co znalazłem, to w Railsach ~2.3 była opcja reconnect: true w database.yml. W Rails3 działa to dalej? Ustawiłem to, ale nie chcę czekać do następnego restartu żeby się przekonać
Bardzo możliwe, że to tylko dla mysql (nie znalazłem żadnego przykładu z reconnect: true dla pg).
Niestety to nie mój wybór To firmowy serwer, który obsługuje zewnętrzna firma supportowa.
Ale generalnie dobrze mi się wydawało, że bez sensu restartują tą bazę?
#!/bin/bash
su - postgres -c ' pg_dumpall > /opt/postgres_backups/dumpall_`date +%s`_.sql'
zapisujesz to w jakimś backup.sh czy coś takiego i wrzucasz do crona.
Jeśli nic się nie zmieniło, to na czas backupu tablice są lockowane, czyli wszystkie zapisy są odłożone póki backup się nie skończy. Skrypt Drogomira działa świetnie póki baza jest niewielka i czas trwania zrzutu jest liczony w sekundach
Kiedy masz dużą bazę, sporo weń zmian i nie możesz sobie pozwolić na jej blokowanie związane z wykonywaniem backupu (srsly, aplikacja ostro używana 24h na dobę?), to pewnym przemysłowym standardem jest po prostu replikacja w czasie rzeczywistym do drugiej, generalnie nieużywanej bazy (nazwijmy ją “slave” ) i robienie backupów wyłącznie z niej.
Jest jeden “myk”: aplikacja musi zadbać o spójność danych (jako że LOCK może się pojawić pomiędzy dowolnymi dwiema transakcjami). Mówiąc po ludzku oznacza to, że jeśli masz dwie-lub-więcej inwazyjne operacje (INSERT, UPDATE) które mają sens wyłącznie po wykonaniu w całym pakiecie… a zresztą, to nie jest wykład z podstaw baz danych, na pewno to już wiesz lub doczytasz
Backupom inkrementacyjnym (jak wspomniane przez Ciebie PITR) nie ufam, bo każda inkrementacja staje się zarazem single point of failure.
Tego się własnie obawiałem. Taki skrypcik wydawał się za prosty
Narazie nie. YAGNI oczywiście jest super, ale też nie lubię robić rozwiązań “na teraz”, jeżeli w niedalekiej przyszłości trzeba będzie wszystko przerabiać.
Spoko, tak gdzie są potrzebne są transakcje. Poza tym każdy save/update jest automatycznie w transakcji, tak?
@zlw: co do point in time recovery, poczytaj o logach WAL
No tak, zapomniałem napisać o tym, że mam drugi serwer, który jest replikowany W przypadku @zlw, założyłem po prostu, że skoro teraz serwer jest stopowany, to i tak lepiej mieć na chwilę locka niż restart.
To firmowy serwer, który obsługuje zewnętrzna firma supportowa.
