Jakie są techniki aktualizacji schematu bazy / bazy danych serwera produkcyjnego bez powodowania przestojów?
deployment
Olivier Lalonde
źródło
źródło
Odpowiedzi:
Ogólnie rzecz biorąc, strony, nad którymi pracowałem, które miały tego rodzaju wymagania, znajdowały się za modułami równoważenia obciążenia lub miały osobne lokalizacje przełączania awaryjnego. W tym przykładzie założę, że masz jeden moduł równoważenia obciążenia, 2 serwery WWW (A i B) i 2 serwery bazy danych (M i N - zwykle serwery DB są połączone poprzez logshipping - przynajmniej w świecie SQL Server ).
W bardzo skomplikowanych aplikacjach internetowych czynności opisane w punktach 1-5 mogą zająć całą noc i być 50-stronicowym arkuszem kalkulacyjnym Excel z czasami i numerami alarmowymi. W takich sytuacjach aktualizacja połowy systemu planowana jest na 18:00 do 6:00, pozostawiając system dostępny dla użytkowników. Obsługa aktualizacji strony DR jest zwykle planowana na następną noc - mam tylko nadzieję, że pierwszego dnia nic nie zepsuje.
Tam, gdzie wymagany jest czas działania, łatki są najpierw testowane w środowisku kontroli jakości, którym idealnie jest ten sam sprzęt co produkcja. Jeśli nie wykazują zakłóceń, można je stosować zgodnie z regularnym harmonogramem, zwykle w weekend.
źródło
W typowych bazach danych (na przykład Oracle) możliwa jest zmiana schematu bazy danych przy jednoczesnym równoległym uruchamianiu zapytań. Wymaga to jednak pewnego planowania.
Są pewne ograniczenia dotyczące zastosowania zmiany:
CREATE INDEX
)Aby schemat był kompatybilny z poprzednimi wersjami, zwykle możesz DODAĆ lub MODYFIKOWAĆ kolumnę, możesz ZROBIĆ coś tylko wtedy, gdy istniejący kod już go nie używa.
Jeśli Twój kod nie może obsłużyć zmiany w sposób transparentny, zmień kod przed zmianą bazy danych.
Prosta rada dotycząca planowania z wyprzedzeniem: zawsze podawaj nazwy kolumn we wnioskach DB (nie używaj
SELECT * FROM
). W ten sposób nie będziesz wyświetlać nowych kolumn w starych żądaniach.źródło
select *
oznacza, że kod zepsuje się, jeśli dodawana jest nowa kolumna (z powodu braku zmiennej, w której można by ją zapisać). Oczywiście może to wynikać z używania silnie napisanego języka.select *
jest bardziej niezawodny i bezpieczny. Jeśli kiedyś tak było,select one, two from ...
wtedy używałeś tylkoone
itwo
; jeślithird
zostanie dodany do tabeli, nie ma dla niego zastosowania (tutaj), więc nie ma powodu, aby go odzyskać. A jeśli musisz go nagle użyć, zmodyfikujesz kod, aby w tym momencie równie dobrze zmodyfikować zapytanie!select
muszą być tak selektywne, jak to możliwe (i objęte indeksem), w przeciwnym razie jestem toast (nawet przed obowiązkowym dołączeniem). Przykro mi to mówić, ale podejście, które opisujesz, było całkowitą porażką tych produktów.Nie wszystkie systemy mogą, należy je skonfigurować w sposób, który je obsługuje.
Na przykład jeden z naszych głównych systemów, który pomogłem zaktualizować kilka lat temu, powinien być dostępny 24/7. Składał się z wielu warstw, w tym czystej warstwy komunikacyjnej między zewnętrzną warstwą interfejsu użytkownika a warstwą biznesową. Ze względu na sposób kodowania warstwy komunikacyjnej wszelkie przyszłe zmiany w warstwie biznesowej lub schemacie DB można wdrożyć bez rzeczywistej awarii. W najgorszym przypadku użytkownik doświadczyłby 10-30 sekundowej przerwy, gdy zmiany zostały wprowadzone.
Gdyby zmiany były czysto kodowymi zmianami w warstwie biznesowej, mogłyby zostać umieszczone w kolejce i „włączone” z opóźnieniem tylko o milisekundy.
Może to zrobić, ponieważ:
Inne techniki obejmują replikację transakcji do innego serwera lustrzanego istniejącego systemu. Stosując aktualizację do jednej, przełączając i odtwarzając wszystkie transakcje wykonane między aktualizacją a przełączeniem. YMMV w zależności od systemu.
źródło
Oto inna perspektywa ze świata systemów wbudowanych baz danych i systemów wbudowanych. Systemy wbudowane obejmują różne urządzenia infrastruktury sieci / infrastruktury telekomunikacyjnej, aw tej dziedzinie często mówią o 99,999% (pięciu 9) przestojów.
My (McObject) jesteśmy dostawcą rodziny produktów wbudowanych baz danych eXtremeDB, w tym wysokiej dostępności eXtremeDB.
Po pierwsze, zrozum, że „osadzona baza danych” oznacza, że system bazy danych jest biblioteką skompilowaną i połączoną z kodem aplikacji; w tym sensie jest „osadzony” w twojej aplikacji.
Dzięki eXtremeDB High Availability istnieje instancja MASTER aplikacji (która może być jednym lub kilkoma procesami) i jedna lub więcej instancji REPLICA aplikacji. Gdy replika ustanawia połączenie z serwerem głównym, otrzymuje kopię bazy danych jednostki głównej w procesie zwanym „synchronizacją początkową”. Można to zrobić, gdy aplikacja główna kontynuuje pracę. Po zsynchronizowaniu otrzymuje transakcje wzorca poprzez replikację. Dlatego replika zawsze ma bieżące dane i może przejąć (poprzez proces zwany przełączaniem awaryjnym) w przypadku awarii wzorca.
Jedną z cech początkowej synchronizacji jest „ewolucja schematu binarnego”. Mówiąc wprost, oznacza to, że proces zapełniania bazy danych repliki uwzględni różnice między schematem bazy danych repliki a schematem bazy danych wzorca.
W praktyce oznacza to, że możesz zbudować nowszą wersję aplikacji (z nowymi / usuniętymi tabelami, nowymi / usuniętymi / zmienionymi polami, nowymi / usuniętymi indeksami), dołączyć tę nową wersję aplikacji do wzorca, a następnie spowodować, że nowsza replika, aby stać się nowym masterem (tzn. wymusić przełączenie awaryjne do nowej repliki, aby stała się master, a stary master sam się wyłączył). Voila, migrowałeś aplikację z wersji N do N + 1, nie zakłócając dostępności twojego systemu. Teraz możesz przejść na aktualizację starego wzorca i wszelkich innych replik do wersji N + 1.
źródło