2011-07-07 3 views
5

Mam skrypt, który jest częścią mojego procesu wdrażania, aby przenieść zmiany DB do serwera produkcyjnego. Jeśli skrypt z jakiegoś powodu zepsuje moje dane (zła aktualizacja), jest trudny do odzyskania.Jak wdrożyć zmiany w bazie danych na serwerze Live?

Jednym ze sposobów rozwiązania tego problemu jest wyłączenie aplikacji dla użytkowników podczas aktualizacji, więc jeśli wystąpi problem, po prostu wróć do kopii zapasowej wykonanej przed wdrożeniem.

Ale słyszałem o innych, którzy wdrażają i utrzymują swoją witrynę na żywo ... jak byś to zrobił, a jeśli ci się nie udało, w jaki sposób możesz odzyskać dane, które pojawiły się od momentu wykonania kopii zapasowej przed wdrożeniem?

Odpowiedz

1

Jest to ogólnie trudny problem, jak w przypadku wielu czynności związanych z administrowaniem bazą danych. Istnieją trzy sposoby podejścia:

  1. Unikaj awarii za wszelką cenę.
  2. Zablokuj wszystko (i dokonaj aktualizacji bardzo szybko).
  3. Zgubienie danych jest OK.

Jeśli masz złożony system, izoluj swoje komponenty zgodnie z tymi lub podobnymi kategoriami.

Posiadać system pomostowy do testowania aktualizacji. System przemieszczania jest mniej więcej kopią systemu produkcyjnego; jest oddzielny od systemu testowego. Kolejną rzeczą jest posiadanie systemu audytu lub rejestrowania, do którego możesz się odnosić, jeśli potrzebujesz powtórzyć dane.

Prawdziwy problem polega na tym, że znacznie później zauważysz, że uaktualnienie było wadliwe. Wtedy jesteś całkiem spieprzony.

0

Jak duża jest twoja baza danych? Czy możesz sobie pozwolić na utratę danych, które zostały zaktualizowane, gdy klient go używał, i zanim musiałeś iść do kopii zapasowej? Każdy plan wdrożenia zawiera gdzieś jakieś kompromisy i musisz zdecydować, które kompromisy są najmniej bolesne dla tego, co chcesz zrobić.

W przypadku prostych stron internetowych z uruchomionym programem pgsql można rozłączyć klientów i uruchomić całą aktualizację w jednej dużej transakcji. Jeśli jakaś część się nie powiedzie, cała rzecz się wycofa i wygląda na to, że nigdy nic nie zrobiłeś. Niestety to nie działa dokładnie tak samo dla innych dbs, ale z retrospekcją lub czymkolwiek, co nazywa oracle, można uzyskać coś podobnego.

W przypadku większych, złożonych witryn internetowych, które są uruchamiane na zreplikowanym zestawie serwerów db, rzeczy stają się o wiele bardziej złożone znacznie szybciej. Tam, gdzie pracowałem, wykorzystaliśmy Slony i nie jest przyjemnie bawić się z innymi, gdy wdrażasz zmiany DDL, a ty prawie MUSISZ zabrać wszystkich klientów w tryb offline podczas wdrażania DDL. Jednak czas przestoju mierzony jest w minutach, nawet w przypadku baz danych o rozmiarze 1 TB.