Mam backup mysql jako dump 100GB. Nie pytajcie czemu. Jakie są strategie aby to backupować jakoś sensownie? Myślałem o jakiejś replikacji master slave aby nie zapisywać tych spakowanych dumpów cyklicznie co X czasu. Nie dość, że to w uj trwa to tak samo długo trwa przywracanie. Profesjonalny admin #linux musi to robić inaczej bo nie wierzę, że tak to musi działać. I jak to wogóle ma się zdumpować dobrze jeśli to trwa godzinę? Baza musi być zablokowana na ten czas aby zachować spójność danych. Za rok będę na pół dnia wyłączał aplikację aby wykonać dump? #mysql #sql #bazydanych #programowanie #programista15k
@incydent_kakaowy: replikacja Cię uchroni przed padem serwera ale nie uchroni przed zrobieniem masowego update na produkcji zamiast na testowym ;) Może duży dump raz na jakiś czas plus przyrostowo binary log?
może to się wyda na pierwszy rzut oka dziwne, ale bardzo cenną uwagę tutaj napisał @etutuit . to jest główna przyczyna problemu - jedna z bardziej zwalonych baz. wybierajta ludziska postgresql. swoją drogą zastanawiałbym się że skoro to jest tak #!$%@? narzędzie, że są tego problemy czy nie ograć tego w inny sposób - być może warto wywalić baze na LVM2 i walić co jakiś czas snapshoty / jakieś repliki lub połączyć
@incydent_kakaowy a musisz backapowac wszystkie tabele? Moze jakies logi mozesz wydzielić i backap Ci spadnie do 20gb i 80gb logu, ktorego nie musisz przywracać na podukcje po padzie, tylko lokalnie i sobie przeanalizwac ewentualnie?
@incydent_kakaowy: Nie napisales, jaki silnik. Jesli wiekszosc danych masz w tabelach InnoDB to ja bym sprobowal Xtrabackup, ktory w trakcie backupu blokuje tylko tabele MyISAM. Nastepna opcja to LVM snapshots.
czyli głównie kiepska replikacja, niewydajne isnerty/update, bo do tej pory było przekonanie że postgresql się sprawdza jak baza jest głównie do odczytów, jak masz dużo aktualizacji / insertów to się nie sprawdza, więc się ją stosuje pod data warehouse bardziej, niż w app gdzie jest dużo modyfikacji, wrzutów danych
@incydent_kakaowy: Pro admin / DevOps robi to dwupoziomowo, ale uprzedzam, ze mowimy tu o drogich zabawkach: 1) Problem holdowania bazy celem zrobienia bakckupu - tak sie nie robi na duzych bazach. Nie robi sie dumpow (te moga sluzyc ewentualnie do migracji), a korzysta z enterprise'owego oprogramowania do backupow (Commvault, EMC Networker, Veeam). ktore to wszystkie posiadaja dedytkowane do konkretnych silnikow bazodanowych pluginy dla systemow operacyjnych na ktorych rozne bazy pracuja. Pluginy
@incydent_kakaowy: Prosze. Ten problem pojawia sie predzej czy pozniej w kazdej firmie i obserwujac go doslownie latami, dziwie sie, ze tego typu wiedza nie jest bardziej upowszechniona. Wystarcza nazwy tych kilku vendorow i juz mozna chociazby poogladac ich tutoriale na YouTube i troche sobie uporzadkowac w glowie co jest mozliwe.
Myślałem o jakiejś replikacji master slave aby nie zapisywać tych spakowanych dumpów cyklicznie co X czasu. Nie dość, że to w uj trwa to tak samo długo trwa przywracanie. Profesjonalny admin #linux musi to robić inaczej bo nie wierzę, że tak to musi działać.
I jak to wogóle ma się zdumpować dobrze jeśli to trwa godzinę? Baza musi być zablokowana na ten czas aby zachować spójność danych. Za rok będę na pół dnia wyłączał aplikację aby wykonać dump?
#mysql #sql #bazydanych #programowanie #programista15k
typy mi płacą aby to gówno działało a ja chcę tak to ustawić aby mieć spokój na co najmniej rok aż ktoś inny się tym zajmie
Może duży dump raz na jakiś czas plus przyrostowo binary log?
Moze jakies logi mozesz wydzielić i backap Ci spadnie do 20gb i 80gb logu, ktorego nie musisz przywracać na podukcje po padzie, tylko lokalnie i sobie przeanalizwac ewentualnie?
jedną tabelę z logami mam już na celowniku, ogólnie to jest apka legacy kryjąca wiele niespodzianek
czyli głównie kiepska replikacja, niewydajne isnerty/update, bo do tej pory było przekonanie że postgresql się sprawdza jak baza jest głównie do odczytów, jak masz dużo aktualizacji / insertów to się nie sprawdza, więc się ją stosuje pod data warehouse bardziej, niż w app gdzie jest dużo modyfikacji, wrzutów danych
1) Problem holdowania bazy celem zrobienia bakckupu - tak sie nie robi na duzych bazach. Nie robi sie dumpow (te moga sluzyc ewentualnie do migracji), a korzysta z enterprise'owego oprogramowania do backupow (Commvault, EMC Networker, Veeam). ktore to wszystkie posiadaja dedytkowane do konkretnych silnikow bazodanowych pluginy dla systemow operacyjnych na ktorych rozne bazy pracuja. Pluginy
@user-agent-switcher:
Ten problem pojawia sie predzej czy pozniej w kazdej firmie i obserwujac go doslownie latami, dziwie sie, ze tego typu wiedza nie jest bardziej upowszechniona.
Wystarcza nazwy tych kilku vendorow i juz mozna chociazby poogladac ich tutoriale na YouTube i troche sobie uporzadkowac w glowie co jest mozliwe.