Jakie praktyki lub narzędzia umożliwiają ciągłe wdrażanie baz danych?

Ciągłe dostarczanie lub ciągłe wdrażanie infrastruktury i kodu jest stosunkowo proste w porównaniu do wypróbowania takich samych podejść do baz danych, w szczególności RDBMS. Kod i infrastruktura nie zmieni się ani nie ewoluuje po zakończeniu wdrażania. W bazach danych będą jednak dodawane nowe dane, tworząc dane, jeśli nie schemat, z natury zmienne komponenty.

Wiem, że istnieją takie praktyki, jak dodawanie tylko obiektów bazy danych, tj. Tabel i kolumn, nigdy ich nie modyfikowanie ani usuwanie - ten czysto addytywny sposób podejścia do schematów bazy danych ma tę zaletę, że schematy są kompatybilne wstecz kosztem kolejnych, bardziej skomplikowanych schematy.

Podobnie istnieją produkty, takie jak Flyway i Ready Roll, które pomagają w pisaniu migracji, które mają być zapisywane między wersjami schematu.

Jakie inne praktyki i narzędzia istnieją obecnie, aby umożliwić ciągłe wdrażanie schematów baz danych w środowisku produkcyjnym, w którym integralność danych ma znaczenie?

Pramod Sadalage i Scott Ambler napisali książkę Refactoring Databases: Evolutionary Database Design, która jest niezwykle solidnym podkładem do tematu DB w org / zespole CD.

Wyzwania

Wiem, że istnieją takie praktyki, jak dodawanie tylko obiektów bazy danych, tj. Tabel i kolumn, nigdy ich nie modyfikując ani nie usuwając

W jednej firmie, dla której pracowałem, okno surowych danych wynosiło około 6 miesięcy i zjadło 10 TB. Dane zostały następnie przetworzone do formatu RDBMS, który kosztował 6 TB danych użytkowych, co stanowiło około 10 lat danych podlegających zgłoszeniu. Chodzi o to, że tego rodzaju praktyki po prostu nie są praktyczne. Magazynowanie jest drogie - prawdopodobnie największy koszt obliczeniowy. Zapewnia to kilka interesujących wyzwań:

1. Kopie zapasowe - wtyczki innodb są świetne, ale czasy tworzenia kopii zapasowych tak dużej ilości danych nie są tak praktyczne
2. Czasy przywracania - w przypadku dużych zestawów danych - szczególnie jeśli potrzebujesz replikacji, aby nadrobić zaległości po przywróceniu przywracania do stanu operacyjnego może potrwać kilka dni, a nawet tygodni
3. Tworzenie / inicjowanie nowych instancji - Często praca, którą możesz wykonywać w dev / test, obejmuje zadania ETL (wyodrębnianie, transformacja i ładowanie) w zbiorze danych. Należy je zweryfikować za pomocą jednostek testujących QA, ale należy to zrobić w sposób nieniszczący, aby zachować oryginalny zestaw danych produkcyjnych. Podczas katastrofy możesz być gotów poradzić sobie z długim czasem przywracania, zakładając, że kopie zapasowe są polisą ubezpieczeniową, a ich celem jest ich uniknięcie, proces tworzenia oprogramowania DevOps wymaga, w zasadzie, że możesz wykonać przywracanie lub regularne kopiowanie danych (być może wiele razy dziennie)
4. Pojemność - Przerzucanie tak dużej ilości danych w skali, którą właśnie opisałem, może być bardzo intensywne we / wy. Nie tylko musisz rozwiązać problemy opisane w 1-3, ale musisz to zrobić w sposób, który nie spowoduje przestojów ani spowolnienia wydajności systemów produkcyjnych.

Chociaż powyższe rozważania mogą nie dotyczyć mniejszych skal, w większych skalach stają się one ogromnymi problemami. Oznacza to, że niezwykle ważne jest zdefiniowanie wymagań i prognozowanie rozmiaru zestawu danych.

Określanie wymagań

W rezultacie musisz zdefiniować kilka wymagań:

1. RTO - RTO lub czas przywracania kopii zapasowych są jednym z najważniejszych sterowników rozwiązań do tworzenia kopii zapasowych baz danych. Chociaż na początku może nie wydawać się odpowiedni dla większości innych problemów, staje się niezwykle istotny, gdy zapytasz „Co, jeśli użyłem mojego rozwiązania do tworzenia kopii zapasowych lub tworzenia nowych instancji?”. W następnej sekcji omówię kilka technik.
2. RPO - RPO lub cel punktu przywracania dla kopii zapasowych określa A) jak daleko można przywrócić (minuty, godziny, dni, tygodnie, miesiące lub lata) B) Interwał tworzenia kopii zapasowych na różnych poziomach i C) jak szczegółowo możesz przywrócić . Na przykład w przypadku baz danych e-mail często poszukuje się kopii zapasowych na poziomie wiadomości - przywracania określonej wiadomości e-mail. Podobnie może się okazać, że dane z kilku dni są całkowicie bezużyteczne - więc nie ma sensu przywracać wstecz o rok.
3. Rozmiar zestawu danych - Jest to ważne, ponieważ w przypadku bazy danych o wielkości 1 MB Twój RTO może zostać osiągnięty za pomocą większości produktów i rozwiązań do tworzenia kopii zapasowych. Jednak w przypadku bazy danych 10 TB okaże się, że pełna kopia zapasowa na poziomie wiersza na taśmie LTO 3 prawdopodobnie nie osiągnie RTO i może zakłócać RPO, ponieważ kopie zapasowe zaczynają przekraczać okno kopii zapasowej. Nie można dokładnie zrobić mysqldump na tym dużym zbiorze danych, ale prawdopodobnie można by tego uniknąć w bazie danych 1 MB.
4. Spójność bazy danych - Ostatnią rzeczą, która ma ogromne znaczenie w ciągłym wdrażaniu, niezawodności witryny, skalowalności i wysokiej dostępności podczas pracy z bazami danych, jest twoja potrzeba (lub jej brak) spójności. Istnieją trzy podstawowe typy: natychmiastowa spójność, spójność Just-In-Time (JIT) i ostateczna spójność

Oprócz powyższych głównych uwag należy również wziąć pod uwagę wymagania dotyczące licencji i wsparcia (otwarte lub zamknięte źródło; wsparcie wewnętrzne, wsparcie strony trzeciej lub wsparcie dostawcy) wymagania dotyczące aplikacji / języka (konektory dla wielu baz danych mogą być ważne; Twoja aplikacja jest skompilowana? Czy masz dostęp do kodu źródłowego? Czy możesz go ponownie skompilować, czy też jest on dostarczany przez dostawcę? Czy może też działa w tłumaczonym języku?) Wymagania polityczne (Czy Twoja organizacja ufa Oracle? Czy nienawidzi wyroczni? „Czy nie ufają MySql?” Co sądzisz o MariaDB lub Postgres?) I silniku bazy danych (innoDB? MyISAM? Blackhole? NDB Cluster? Spider?) Oraz wymagania historyczne lub dotyczące zgodności (używaliśmy PL / SQL od półtora roku naszego kodu jest wbudowany w silnik Oracle! Jak moglibyśmy przenieść się do MariaDB?!?)

Wszystkie te rzeczy (znacząco) wpływają na dostępne narzędzia.

Niektóre opcje wewnętrznego zarządzania danymi

Uwaga: Poniższe informacje nie są w żaden sposób wyczerpujące, a inni użytkownicy SE powinni włączyć dodatkowe sugestie.

Uwzględniając ogólne rozważania, pozwólcie, że przedstawię kilka technik i technologii umożliwiających rozwiązanie powyższego problemu. Po pierwsze, zadaj sobie pytanie, czy naprawdę potrzebujesz korzystać z RDBMS, czy też nieuporządkowane dane z czymś takim jak Hadoop, CouchDB lub nawet Object Oriented Storage (coś takiego jak swift) są opcją.

Po drugie, zastanów się nad rozwiązaniem opartym na chmurze. W ten sposób część tego bólu głowy zostaje zlecona na zewnątrz, a skomplikowane problemy pozostawia się wysoko wykwalifikowanym (i opłacanym) osobom. W skali można jednak zauważyć, że to naprawdę pochłania Twój budżet (dostawcy usług chmurowych ZYSKUJĄ na tym zysk, i na pewną skalę możesz sobie pozwolić na zatrudnienie tych ekspertów samodzielnie) lub jeśli pracujesz pod szczególną ochroną lub polityką wymagania (czytaj: nie możemy robić chmur) rozważ hybrydowy filtr NFS / FibreChannel. Większość tych filtrów, takich jak NetApp, Pure Storage i Tegile, obsługuje technikę migawek i klonowania opartą na delcie, która może być bardzo przydatna dla A) robienia kopii zapasowych, B) przywracania kopii zapasowych i C) inicjowania nowych kopii zapasowych.

W tym momencie muszę zauważyć, że nie jestem ekspertem od tworzenia kopii zapasowych i przechowywania, więc jest kilka części tego problemu, których nigdy nie byłem w stanie rozwiązać, zanim przeszedłem na inne problemy (i bardziej zielone pastwiska).

Ale powiedziawszy to, produkty te umożliwiają robienie różnicowych migawek pod bazą danych. Będziesz musiał wykonać skrypt „pełnej tabeli blokowania z blokadą odczytu” na jednej z instancji bazy danych (zalecany jest tylko moduł podrzędny tylko do odczytu) i zrzucić swoją pozycję binlog lub GTID, ale w przypadku tych filtrów będzie to możliwe aby użyć tych przystawek do utworzenia nowych instancji bazy danych. Będziesz chciał umieścić binlogs na osobnej partycji i umieścić tylko dane bazy danych na tych partycjach. Gdy to zrobisz, będziesz mógł sklonować te partycje (w NetApps jest to znane jako „ FlexClone ”

Jest tak, ponieważ dla każdego odczytu bloku filer musi ustalić, czy dane znajdują się w zamrożonym oryginalnym obrazie stanu, czy w delcie. W przypadku woluminów / sklepów z wieloma migawkami może to wymagać wielokrotnego sprawdzenia. Możesz temu zaradzić, odświeżając dane (co oznacza, odrzuć migawkę i okresowo ją klonuj - co może się zdarzyć naturalnie i organicznie w celu zapewnienia dobrego ciągłego środowiska wdrażania) lub trwale dzieląc wolumin (znany jako „Flex Split” w terminologii NetApp ), co zajmie chwilę, aby trwale rozwiązać delty i utworzyć całkowicie nowy i osobny wolumin.

Te klony delta mają dodatkową zaletę polegającą na zmniejszeniu ogólnego zapotrzebowania na pamięć - możesz spawnować kilka klonów lub wystąpienie danych z produkcyjnej bazy danych, aby wykonać programowanie, testowanie i sprawdzanie poprawności. Jeśli przechowujesz tylko jedną kopię dużego zestawu danych plus (prawdopodobnie prawdopodobnie) małe delty, zmniejszysz całkowity koszt przechowywania i powierzchnię.

Jedyną sztuczką jest to, że może nie stanowić pełnego rozwiązania do tworzenia kopii zapasowych, ponieważ „kopia zapasowa” nadal znajduje się w twoim filerze. W tym celu może być konieczne użycie czegoś, co NetApp nazywa Snap Mirror, który będzie dublował dane (przy użyciu technologii w stylu rsync) między filtrami, a nawet centrami danych, lub użyć pewnego rodzaju zintegrowanego rozwiązania do tworzenia kopii zapasowych, które może wykonać kopię zapasową na jednej z migawek delta lub flex-klon.

Ma to jednak jedną poważną wadę: wszystkie twoje dane - deweloper, test i prod nadal używają I / O na tym samym filtrze i głowicy pamięci. Aby obejść ten problem, rozważ utworzenie instancji podrzędnej bazy danych na drugim filtrze, który może być punktem początkowym dla testowania i / lub filtrowania deweloperów, lub rozważ użycie kontrolera dostarczania równoważenia obciążenia / aplikacji dla warstwy aplikacji w celu odzwierciedlenia żądań produkcyjnych w twoim środowisko testowe (i / lub programistyczne). Ma to tę dodatkową zaletę, że generuje ruch produkcyjny w środowisku kontroli jakości / testowania przed awansowaniem do produkcji w przypadku problemów, które mogą nie zostać natychmiast zauważone. Następnie można sprawdzić dzienniki pod kątem błędów w oparciu o ruch produkcyjny i zachowanie użytkownika.

To powinno pozwolić ci na użycie kilku skryptów do programowego odrodzenia i zniszczenia całych (i dużych) zestawów danych do użycia z metodologiami ciągłego wdrażania.

Skalowalność i wysoka dostępność

Podczas gdy pytasz o ciągłe wdrażanie, DevOps jest zabezpieczony czymś więcej niż tylko ciągłym wdrażaniem - dlatego przedstawię kilka informacji na temat redundancji, skalowalności i wysokiej dostępności.

Wspomniałem, JIT, natychmiastową i ewentualną spójność. W tym miejscu pojawiają się różne silniki RDBMS. Ostateczna spójność jest stosunkowo łatwa dzięki prostej konfiguracji cyklicznej asynchronicznej replikacji. Może to jednak powodować niektóre kolizje * (co jeśli warstwa aplikacji aktualizuje dane po jednej stronie klastra i po drugiej stronie klastra przed zakończeniem replikacji?) Aby uzyskać natychmiastową spójność, spójrz na klaster Galera, który wymusi synchroniczną replikację, ale powoduje problemy ze skalowalnością (w jaki sposób zostanie przeprowadzona replikacja do witryny odzyskiwania po awarii lub równoważenie obciążenia geograficznego bez znacznego opóźnienia z powodu opóźnienia propagacji w warstwie sieci?) Możesz także sprawdzić, czy możesz wykonać replikację synchroniczną w centrum danych i replikację asynchroniczną między witrynami, ale wydaje się to najgorsze z obu światów.

Zazwyczaj jednak większość ludzi nie potrzebuje w pełni synchronicznej replikacji - jest to zwykle potrzebne tylko w bardzo specyficznych (i egzotycznych) środowiskach z wysokim zapisem, w których wymagany jest multi-master z dzieleniem tabel. Większość aplikacji może poradzić sobie ze spójnością Just-In-Time za pomocą serwera proxy bazy danych. Na przykład ScaleArc będzie monitorować stan replikacji i śledzić dokąd właśnie zapisy (aby wysłać kolejne żądania odczytu do momentu, aż replika się dogoni), aby zapewnić spójność i wygląd Just-In-Timespójności bazy danych. ScaleArc jest kompatybilny z Postgres, MySQL, MariaDB, Oracle i MSSQL i może używać wyrażeń regularnych do dzielenia / partycjonowania baz danych dla aplikacji, które nie mogą używać kluczy odłamków. Posiada również solidny interfejs API REST do oprogramowania do zarządzania konfiguracją, z którym można współpracować - a ich zespół wsparcia jest wyjątkowy

Podobnie możesz rozważyć darmową alternatywę MaxScale opracowaną przez zespół MariaDB dla MariaDB. Brakuje jednak GUI i niektórych funkcji buforowania ScaleArc.

Wreszcie, tkanina MySQL (i tylko klaster MySQL w pamięci RAM - jeśli możesz sobie pozwolić na tak dużo pamięci RAM) to inne potencjały - szczególnie z nowym serwerem proxy MySQL. Może to zapewnić składnik skalowalności i redundancji w twoim środowisku.

Postgres i Oracle powinny mieć potrzebne funkcje replikacji i shardingu, ale ScaleArc dobrze się sparuje, jeśli potrzebujesz proxy.

Ostatecznie wszystkie te elementy składają się na wysoce elastyczne środowisko odpowiednie do ciągłego wdrażania i rozwoju, jeśli nie jesteś w stanie po prostu korzystać ze środowiska opartego na chmurze i pozwolić dostawcy usług chmurowych zająć się powyższymi problemami.

Korzystamy z Flyway w pracy do zarządzania schematami Postgres w aplikacji oraz Pillar do zarządzania schematami Cassandra. Okazało się, że najlepiej, jeśli aplikacja zarządza własnym schematem.

Mieliśmy okropne doświadczenie, gdy ansible zarządzało schematami, zanim aplikacje zarządzały własnymi schematami.

Twierdzę, że samo narzędzie naprawdę nie pomoże, dopóki nie przeniesiesz odpowiedzialności za schemat na zespół aplikacji.

W pracy używamy likibase lub flyway , gdzie zespół aplikacyjny jest odpowiedzialny za tworzenie zestawów zmian.

Oprócz tego możesz uniknąć czysto addytywnego sposobu.
Każda aplikacja musi być zgodna z poprzednią wersją. Gdy trzeba dokonać zmiany schematu, wówczas aplikacja zintegruje nową kolumnę ze schematem, zapisze do niej i nadal będzie czytać i zapisywać z / do poprzedniej kolumny (umożliwiając poprzednia wersja nadal miała te same dane).
Następna wersja aplikacji może zatrzymać aktualizację starej kolumny i tylko trzecia wersja będzie mogła usunąć teraz nieużywaną kolumnę.

Oczywiście potrzebne są regularne kopie zapasowe na wypadek, gdyby coś poszło nie tak.
Właściwy podzbiór danych, który może powodować problemy w testach integracyjnych, aby uniknąć ich podczas produkcji, jest również dobrym pomysłem. Idealny przypadek uzyskuje anonimowy podzbiór danych produkcyjnych.

W naszej pracy używamy likibazy i będę za to głośno mówić. Jest również używany przez nasze narzędzie QAymphony .

Używamy go wewnętrznie w bazach danych MSSQL i Oracle, a QASymphony używa / używa go w obu instancjach postgres + mysql.

Aby odpowiedzieć na to pytanie w kontekście środowiska komputerów mainframe i specyficznych dla baz danych DB2®, zwykle są 2 powszechnie używane (nie tanie ...) alternatywy do wyboru:

• Administracja obiektowa dla DB2® z BMC. Oto kilka szczegółów na ten temat (cytat z połączonej strony):

  Wprowadzanie zmian w obiektach w bazie danych - a nawet wykonywanie rutynowych zadań administracyjnych - może być trudną, ryzykowną pracą. Należy śledzić dziesiątki zadań, a pojedynczy błąd może mieć katastrofalny wpływ na dostępność i integralność danych. Możesz zmniejszyć nakład pracy i ryzyko dzięki BMC Object Administration for DB2 11, kolekcji narzędzi, które pomogą Ci:

  • Skróć czas wymagany do administrowania złożonymi i odmiennymi środowiskami DB2.
  • Zautomatyzuj rutynowe zadania w całym cyklu życia aplikacji, aby zwiększyć integralność.
  • Zwiększ produktywność dzięki uproszczonej nawigacji w katalogu DB2 i zarządzaniu zmianami.
  • Zwiększ dostępność aplikacji, wykonując zmiany i konserwację przy minimalnych przestojach.

• Narzędzie administracyjne DB2 dla z / OS od IBM.

  Upraszcza złożone zadania związane z bezpiecznym zarządzaniem obiektami i schematem DB2 w całym cyklu życia aplikacji przy minimalnym możliwym wpływie na dostępność.

  • Umożliwia użytkownikom szybkie i łatwe poruszanie się po katalogu DB2
  • Buduje i wykonuje dynamiczne instrukcje SQL bez znajomości dokładnej składni SQL
  • Zarządza i śledzi zmiany wprowadzone w definicjach obiektów DB2 rozwiązujące wszelkie potencjalne konflikty przed wykonaniem
  • Pomaga budować komendy DB2 w celu wykonania na bazach danych i tabelach
  • Umożliwia użytkownikom tworzenie, modyfikowanie, migrowanie, upuszczanie i odtwarzanie obiektów DB2
  • Tworzy i wykonuje zadania narzędziowe, umożliwiając użytkownikom korzystanie z LISTDEF i SZABLONÓW w celu zwiększenia wydajności

Integracja z narzędziami SCM

Jakiś czas temu klient wezwał mnie do „zintegrowania” alternatywy BMC z ich cyklem życia SCM (zarządzanym przez SERENĘ ChangeMan ZMF ). Ideą takiej integracji jest „ Weź pod uwagę nasz zespół DB2 DBA (robiąc rzeczy z DDL) jako specjalny przypadek zespołu programistów, przypadkowo wykorzystujący egzotyczny edytor (narzędzie BMC) do stworzenia kodu (DDL) do migracji ”.

Jedynym (ale realnym !) Wyzwaniem związanym z tą integracją było również ułatwienie „ponownego uruchomienia”, co jest jedną z kluczowych zalet takiego narzędzia DBA:

• Ponowne uruchamianie oznacza, że ​​gdy to narzędzie DBA wykonuje swoje zadanie (czasami przez długotrwałe zadania, zgodnie z charakterem pracy, która ma zostać zakończona), mogą się zdarzyć nieoczekiwane rzeczy (impasy, brak czasu itp.).

• Jeśli którakolwiek z tych rzeczy się zdarzy i nie chcesz ponownie uruchomić kopii zapasowej (przed rozpoczęciem), narzędzie DBA oczekuje, że uruchomisz się ponownie od punktu (sprawdzania), od którego zaczęło się dziać źle (i skąd chcesz, aby wszystko zostało ponownie wykonane).

• Jeszcze lepiej (czy powinienem powiedzieć „jeszcze gorzej”?), Jeśli nowicjusz w narzędziu DBA tak naprawdę nie wie, jak zrestartować z takiego punktu kontrolnego i po prostu spróbuje ponownie (od początku), wtedy narzędzie DBA po prostu zawiedzie z jakimś błędem użytkownika. I to ze wskazaniem w rodzaju „ Dopóki nie powiesz mi, jak chcesz, abym postępował po moim ostatnim punkcie niepowodzenia, nie odmawiam niczego (żeby nie pogorszyć sprawy) ”.

• Ostatecznie prawdziwa wskazówka, aby wdrożyć tę możliwość ponownego uruchomienia w używanym narzędziu SCM, wymagała również dostrojenia narzędzia SCM. Właściwie aby mogła ona służyć do ponownego uruchomienia nieudanych procedur SCM (zwykle związane z dostawami do testów / target środowiskach prod ...) zamiast po prostu na nowo procedurę składania uszkodzonego SCM (co jest jak zwykle te narzędzia SCM odzyskać od takich sytuacjach ).

Bonus: po zakończeniu integracji SCM alternatywy BMC klient postanowił zmienić swoje narzędzie DBA na alternatywę IBM. I chociaż obie alternatywy nie wyglądają tak samo, wpływ na integrację SCM był raczej minimalny: po prostu kwestia zastąpienia (w niektórych modyfikacjach SCM wielokrotnego użytku) niektórych wywołań alternatywy BMC równoważnymi wywołaniami do IBM alternatywa ... która (używając terminologii DevOps) została zaimplementowana przez feature-flags / feature-toggles .