Jakie praktyki stosujesz, aby unikać niewłaściwych aktualizacji danych w dużych bazach danych?

20

Typową radą przed wdrożeniem produkcyjnym jest wykonanie kopii zapasowej bazy danych. W ten sposób, jeśli nowa aktualizacja ma jakiś problem, który może prowadzić do potencjalnej utraty lub logicznego uszkodzenia danych, nadal masz kopię zapasową do porównania i poprawienia starych rekordów.

Może to jednak działać dobrze, dopóki rozmiar bazy danych nie osiągnie kilku GB. Gdy rozmiar bazy danych jest ogromny, tworzenie kopii zapasowych zajmuje dużo czasu. Jakie są najlepsze praktyki, których należy przestrzegać w takich sytuacjach, aby uniknąć logicznego uszkodzenia danych z powodu problemów logicznych podczas wdrażania kodu?

Pritam Barhate
źródło
11
Kopie zapasowe służą nie tylko do wdrażania. To znaczy, twoja utrata danych to tylko jedna awaria dysku, a te są nieprzewidywalne i mogą się zdarzyć dzisiaj lub jutro. (Tablice rajdowe nie są odpowiedzią, one również ulegają awarii.)
Pieter B
10
Chciałbym przeformułować to pytanie, problemem nie jest to, że tworzenie kopii zapasowych zajmuje dużo czasu, problem polega na tym, że w przypadku, gdy aktualizacja ma katastrofalną awarię, konieczne może być przywrócenie , które może blokować produkcję przez długi czas. Tak więc naprawdę szukasz strategii zmniejszającej ryzyko niepowodzenia podczas aktualizacji.
Doc Brown
1
Zgadzam się z @DocBrown tutaj. Unikanie uszkodzenia danych i zbyt długiego tworzenia kopii zapasowych to tak naprawdę dwa osobne pytania.
Robbie Dee,
1
Kiedy szybko zaakceptujesz, nie otrzymasz tyle wkładu.
paparazzo
1
Co masz na myśli „problemy logiczne we wdrożeniu kodu”?
paparazzo

Odpowiedzi:

25

Jako osoba, która regularnie zajmowała się aktualizacją produkcyjnej bazy danych dla klientów dla naszych aktualizacji oprogramowania, mówię wam, że najlepszym sposobem na zminimalizowanie błędów jest dokonywanie aktualizacji tak prosto, jak to możliwe.

Jeśli możesz dokonać zmiany we wszystkich rekordach, a nie w konkretnych, lepiej jest to zrobić.

Innymi słowy, jeśli otrzymasz listę identyfikatorów rekordów, które wymagają zmiany ich stanu, powinieneś zadać sobie pytanie, dlaczego aktualizacja jest wykonywana w kontekście programu. Może być tak, że z 10 rekordów, które musisz zaktualizować, tabela zawiera tylko 10 elementów. Dlatego powinieneś zadać sobie pytanie, czy koncepcyjnie wszystko, co robisz, to aktualizowanie stanu wszystkich rekordów.

Jeśli możesz wstawić, najlepiej.

Dodanie rekordu jest samodzielne. Rozumiem przez to, że istnieje tylko jeden efekt uboczny dodania rekordu, i jest nim rekord, który wcześniej nie istniał. Dlatego jeśli nie dodajesz rekordu, którego nie powinno tam być, nie powinno być żadnych problemów.

Jeśli możesz uniknąć usunięcia, lepiej jest.

Jeśli usuwasz, usuwasz dane, które w innym przypadku byłyby niemożliwe do odzyskania bez kopii zapasowej. Jeśli to możliwe, spróbuj uporządkować dane w taki sposób, aby można było wyłączyć rekordy, zmieniając ich stan, a nie usuwając fizycznie rekord. Nadmiar danych można umieścić na partycji lub całkowicie usunąć w późniejszym momencie, gdy masz pewność, że nie ma żadnych problemów.

Miej spójne zasady aktualizacji.

Jeśli musisz zaktualizować rekord, może się zdarzyć jedna z kilku rzeczy:

  1. Twój rekord nie istnieje.
  2. Twój rekord istnieje, ale został już zmieniony.
  3. Twój rekord istnieje i wymaga zmiany.

Musisz mieć politykę określającą kierunek działania, jeśli coś nie pójdzie zgodnie z planem. Dla uproszczenia powinieneś być konsekwentny i stosować tę politykę w każdej sytuacji tego typu, nie tylko w przypadku określonych tabel. Ułatwia to późniejsze odzyskiwanie danych. Ogólnie rzecz biorąc, moją zasadą jest pisanie skryptu w taki sposób, aby móc go później ponownie uruchomić. Jeśli skrypt się nie powiedzie, miło jest wiedzieć, że możesz wprowadzić odpowiednie poprawki i wykonać je ponownie, jednak możesz wybrać własną politykę, która najbardziej Ci odpowiada.

Kopie zapasowe

W żadnym wypadku nie usprawiedliwia to wykonania kopii zapasowej przed wykonaniem jakiejkolwiek aktualizacji w środowisku produkcyjnym! Chociaż nawet w przypadku kopii zapasowej uważam, że nie trzeba jej używać. Utrata danych nie może być możliwa nawet w najgorszym przypadku .

Wniosek

Nie zawsze będziesz w stanie mieć to po swojemu. Schemat tabeli prawdopodobnie nie zostanie określony przez Ciebie, a zatem oznacza to, że typy aktualizacji, których możesz oczekiwać, będą zarówno skomplikowane, jak i ryzykowne. Jeśli jednak masz coś do powiedzenia w tej sprawie, warto pamiętać o tych kwestiach, ponieważ wprowadzają one wszelkie aktualizacje bezpośrednio i bez znaczącego ryzyka.

Powodzenia!

Neil
źródło
Zgadzam się ze wszystkim, co powiedziałeś, ale byłem ciekawy twoich myśli o transakcjach, gdy istnieje 10 rekordów, które wymagają zmiany z 10 000 i wstawianie / aktualizowanie wszystkich rekordów nie jest wykonalne?
Jestem tu na zimowe czapki
Następnie wystarczy zaktualizować 10 rekordów. Powiedziałem, jeśli możesz, zrób to. Nie powiedziałem, zrób to, nawet jeśli zniszczy to produkcyjną bazę danych twojego klienta. Proszę, posłuchaj mojej rady z odrobiną soli.
Neil
12

W tym momencie powinieneś używać komercyjnego systemu DB, który obsługuje migawki (Oracles nazywa to Flashback ) - właśnie do tego właśnie służą.

Pamiętaj, że i tak potrzebujesz koncepcji tworzenia kopii zapasowych - posiadanie większej ilości danych nie oznacza, że ​​upuszczasz kopie zapasowe, ponieważ stają się trudne, wręcz przeciwnie. Potrzebujesz pewnego rodzaju ciągłej kopii zapasowej, np. Opartej na replikacji z automatycznym przełączaniem awaryjnym.

Michael Borgwardt
źródło
Nie mówię, że chcę porzucić kopie zapasowe. Zaplanowane kopie zapasowe są zawsze dostępne. Pytania dotyczą raczej kopii zapasowych ad hoc, które nie stanowią problemu w przypadku małych systemów.
Pritam Barhate
Aby rozwinąć tę kwestię, ta myśl pochodzi od NoSQL DB jako platform usług. Właściwie czytałem dokumentację Firestore, kiedy się pojawiła. Jeśli potrzebujesz zewnętrznych logicznie spójnych kopii zapasowych, wydaje się to bardzo kosztowne. Zastanawiałem się więc, jak skuteczne zespoły produktowe współpracują z takimi systemami i jak zapewniają, że logiczne uszkodzenie danych nie nastąpi.
Pritam Barhate
@PritamBarhate: nie potrzebujesz „więcej kopii zapasowych” z powodu aktualizacji. W produkcyjnej bazie danych, w której ludzie pracują z tymi danymi, kopie zapasowe muszą być wykonywane co najmniej raz dziennie, z aktualizacjami lub bez nich. Przywracanie jest twoim problemem, chcesz uniknąć niepotrzebnego przywracania we wszystkich okolicznościach.
Doc Brown
3
Replikacja z automatycznym przełączaniem awaryjnym to nadmiarowość, która nie jest już strategią tworzenia kopii zapasowych baz danych, tak jak w przypadku dysków RAID .
Blrfl
1
Wszystkie dobre punkty na temat kopii zapasowych i migawek, ale wyczyszczenie nieudanej operacji na bazie danych (jeśli kilka godzin nowych danych zostało dodanych przed ich realizacją) może być bardzo trudne w zależności od scenariusza i innych systemów, na które wpływa (harmonogramy, inne wpisy bazy danych polegają na nim, jeśli obejmuje kilka tabel, pamięci podręczne, uwierzytelnianie itp.). Zawsze zakładam, że będę musiał użyć kopii zapasowej, ale zawsze przynajmniej staram się tego nigdy nie robić.
Anonimowy pingwin
3

Jest to ogromny obszar - więc spodziewaj się, że to pytanie zostanie zamknięte w dość krótkim czasie, ale z góry (jako były DBA w dużych bazach danych):

Mart / Repository

Możesz zmniejszyć ryzyko, jeśli masz osobną bazę danych dla aktualizacji i osobną bazę danych, z której wszyscy korzystają. Jest to tylko przypadek skopiowania danych z jednego DB do drugiego po przeprowadzeniu różnych kontroli. Mart / repozytorium jest czasami opisywane, ale możesz mieć podstawowy / wtórny, master / slave itp.

Kod źródłowy

Aby wszystko, co można zmienić, należy mieć kod źródłowy, który odnosi się do sposobu aktualizacji danych. Ile ich masz, różni się od DB do DB, ale możesz mieć jeden dla każdego użytkownika, roli, pliku danych, modułu kodu itp.

Utwórz / zaktualizuj datę

Coś, co może znacznie pomóc w śledzeniu, gdzie coś poszło nie tak, to tworzenie i aktualizacja danych dla każdego wiersza. Następnie możesz szybko sprawdzić, które wiersze zostały zaktualizowane.

ETL

Jeśli aktualizacja bazy danych jest częścią fabryki danych, możesz przywrócić poprzedni rocznik z plików płaskich.

Utworzyć kopię zapasową

Pełne kopie zapasowe zajmują oczywiście dużo miejsca, ale typowym scenariuszem jest wykonywanie pełnej kopii zapasowej w regularnych odstępach czasu (powiedzmy, co tydzień) i częściowych częściej (codziennie itp.).

Odzyskanie punktu w czasie

W zależności od używanego RDBMS, niektóre punkty wsparcia w odzyskiwaniu czasu. Pozwala to cofnąć się do czasu, kiedy znany był dobry stan. Wymaga to jednak dużej ilości pamięci, która zwiększa się o to, jak daleko chcesz wrócić.

Rewizja

Posiadanie tabel audytu powie Ci, kto (lub co) dokonał aktualizacji wiersza. Może to stanowić dobry punkt wyjścia do dochodzenia.

Historia

W przypadku niektórych tabel krytycznych w momencie aktualizacji pobierana jest kopia odpowiedniego wiersza, aby w razie potrzeby można było przywrócić dane.

Walidacji danych

Upewnij się, że podstawowe kontrole walidacji są przeprowadzane na danych przed ich zapisaniem - ponad podstawowe kontrole typów danych.

Więzy integralności

Integralność referencyjna nie jest srebrną kulą, ale może pomóc zapewnić dobrą strukturę danych.

Robbie Dee
źródło
2

Wiele razy, jeśli wykonujemy aktualizację „jednego strzału”, wykonujemy kopię zapasową produkcji i przywracamy ją na serwer testowy. Następnie tworzymy zestaw testów i uruchamiamy jeden strzał. Sprawdzamy, czy dane zmieniły się za pomocą testów i czujemy się komfortowo, że aktualizacja się powiedzie, i zmodyfikujemy dane w sposób, którego się spodziewamy. Nazywa się to próbą suchą lub próbną. Polecam to zrobić.

To daje wszystkim poczucie, że jeden strzał się powiedzie. Nie możemy zagwarantować 100%, ponieważ dane zostaną zaktualizowane od daty uruchomienia próbnego, ale zwiększamy zaufanie i czynniki sukcesu. Daje to również prawdziwy obraz wszelkich problemów, które wystąpią, ponieważ używamy kopii produkcji. Teraz, jeśli z jakiegoś powodu aktualizacja się nie powiedzie, zawsze możemy przejść do ponownego uruchomienia przed przywróceniem, jeśli to konieczne, ale powinniśmy byli znaleźć i rozwiązać wszelkie problemy z suchym uruchomieniem.

Jeśli nie możesz wziąć całej bazy danych (jeśli jest naprawdę duża), spróbuj wyeksportować mniejszy rozmiar próbki i uruchom aktualizację (mały suchy test) w stosunku do rzeczywistych danych. Wolę cały zestaw danych, jeśli to możliwe, aby upewnić się, że test jest jak najbardziej kompletny.

Jon Raynor
źródło