Najlepszy sposób na migrację ogromnej bazy danych SQL Server przy niskim przestoju w sieci

Definicja problemu

Nasz serwer bazy danych musi zostać przeniesiony do innego centrum danych. Działa na Microsoft SQL Server 2012 Enterprise (64-bit) i zawiera dwie bazy danych o wielkości około 2 TB i 1 TB.

Idealny byłby brak przestojów lub brak przestojów.

Obciążenie pracą

Te bazy danych są używane w witrynie .NET i są stale aktualizowane.

Dopuszczalne byłoby jednak, że nie będzie dostępne w weekend. Aktualnie używana baza danych pozostanie jedyną używaną do momentu przejścia na nową.

Najlepiej byłoby, gdyby zmiana ta polegała na zmianie wpisów DNS tak, aby wskazywały na nowy serwer DB, przy jednoczesnym upewnieniu się, że DB nie jest aktualizowany.

Czas potrzebny na tę operację nie ma tak naprawdę znaczenia, o ile przełączanie z jednego serwera na drugi (przestój) jest utrzymywane na niskim poziomie.

Podejścia brane pod uwagę

• Kopia zapasowa i przywracanie

  Odbywało się to w przeszłości, ale wiązało się z dużym przestojem, mimo że odbywało się to za pośrednictwem sieci wewnętrznej, co jest bardziej wydajne niż przez Internet

• Przesyłka dziennika

  O ile rozumiem, takie podejście zminimalizuje przestoje poprzez skonfigurowanie urządzenia nadrzędnego / podrzędnego i przesłanie dokładnej kopii nadrzędnej bazy danych do urządzenia podrzędnego tylko do odczytu. Jak wspomniano powyżej, dostęp do urządzenia podrzędnego nie byłby konieczny i potrzebujemy tylko sposobu na posiadanie repliki głównej bazy danych bez uszkodzenia danych.

  Wydaje się również, że jest dość wydajny pod względem wykorzystania zasobów i nie miałby wpływu na dużą wydajność master.

  Mogę się mylić co do tego podejścia, więc możesz mnie poprawić.

• Dublowanie bazy danych

  Nie jestem zbyt świadomy tego podejścia, ale wydaje się to słuszną opcją. Nie ma potrzeby synchronizacji w czasie rzeczywistym, a wydajność urządzenia nadrzędnego jest dość ważna, więc asynchroniczna byłaby droga, gdyby wybrać to podejście.

• Inne opcje?

  Ten serwer działa bezpośrednio na czystym sprzęcie, więc rozwiązania niższego poziomu nie są niestety opcją. Może jest lepszy sposób, aby to zrobić?

Ograniczenia

Jak opisano, te bazy danych są dość duże do tego stopnia, że ​​są trudne w utrzymaniu, ale to inny problem.

Wersje SQL Server będą takie same (64-bitowy Microsoft SQL Server 2012 Enterprise).

Będzie musiał zostać przesłany przez sieć między dwoma centrami danych, a więc najprawdopodobniej przez Internet. Wysyłanie dysków z jednej witryny do drugiej w celu wstępnej synchronizacji nie jest niestety możliwe. Idealne byłoby posiadanie pewnego zabezpieczenia dla transferu, ale zrobimy to najlepiej, jak potrafimy.

To powinno dać całkiem dobry przegląd naszych potrzeb związanych z tym zadaniem i mam nadzieję, że niektórzy z was musieli wcześniej zmierzyć się z tą sytuacją.

Proste tworzenie kopii zapasowych i przywracanie jest oczywiście niedostępne. Nie rozważałbym też żadnej replikacji.

Kopia lustrzana bazy danych jest stosunkowo prosta do skonfigurowania, ale wymaga połączenia w czasie rzeczywistym między dwoma serwerami, konfigurowania partnerów i punktów końcowych itp. Grupy dostępności mogą być opcją, ale oprócz komplikacji sieciowych musisz mieć oba serwery jako członkowie tej samej WSFC - co oznacza, że ​​oboje muszą należeć do tej samej domeny. To nie jest typowa konfiguracja (lub może nawet zostać tymczasowo uruchomiona) dla przeniesienia centrum danych.

Mój głos dotyczyłby wysyłki kłód. Zaletą tego jest to, że możesz używać kopii zapasowych i rejestrować kopie zapasowe, które już robisz (prawda?) I niekoniecznie musisz mieć łączność między dwiema bazami danych w czasie rzeczywistym - nie muszą wiedzieć o każdej z nich po drugie, nie trzeba konfigurować punktów końcowych dla kopii lustrzanej, partnerów, bezpieczeństwa itp. Wystarczy po prostu przenieść pliki ze starego serwera do miejsca, w którym można je przywrócić na nowym serwerze. Możesz wykonać pełną kopię zapasową z dużym wyprzedzeniem, przenieść ją na nowy serwer, przywrócić, a następnie zastosować (możliwe różnice i) przyrostowe kopie zapasowe dziennika od tego momentu aż do momentu przełączenia. Proces ten jest w rzeczywistości dość prosty i istnieje wiele samouczków dotyczących wysyłania kłód dostępnych online, jeśli napotkasz jakiekolwiek trudności.

Jeśli aplikacja internetowa porusza się z bazą danych, ponieważ propagacja DNS może zająć trochę czasu, możesz chcieć dokonać zmiany w ciągach połączeń starej aplikacji, aby wskazywały na adres IP nowego serwera bazy danych, gdy tylko będzie można zapisać , ponieważ - nawet po zmianie, a nawet jeśli ustawienia TTL są ciasne - klienci mogą nadal atakować stare serwery sieciowe. Wszystko zależy od tego, ile szacunku ich dostawcy dają TTL.

Niedawno przeprowadziłem migrację 15 TB w 6 bazach danych przy użyciu kopii lustrzanej. Bardzo prosty i działał doskonale przy zaledwie kilku sekundach przełączania awaryjnego.

Edycje:

Miałem dwa nowe zwirtualizowane serwery SQL. Bazy danych pochodziły z 3 serwerów, które właśnie przerosły i wpływały na wydajność mniejszych hostowanych baz danych.

Proces był bardzo prosty.

1. Poczekaj na zakończenie pełnych kopii zapasowych w weekend
2. Przywróć bez odzyskiwania na nowe serwery
3. Po zakończeniu przywracania wstrzymaj tworzenie kopii zapasowych
4. Uruchom jedno dodatkowe przywracanie do najnowszej kopii zapasowej dziennika z oryginałów, nie pozostawiając odzyskiwania
5. Rozpocznij dublowanie we wszystkich sześciu
6. Wznów tworzenie kopii zapasowych

Zdecydowałem się pozostawić je w trybie asynchronicznym, dopóki nie będziemy gotowi do przełączenia awaryjnego w celu zmniejszenia obciążenia sieci itp. Tworzenie kopii lustrzanych ma pewną reputację z powodu opóźnień podczas konserwacji (indeks / statystyki) i innych działań o dużej objętości, ale nie zrobiłem tego przekonaj się, że to prawda. Przed ręcznym przełączeniem awaryjnym należy je przełączyć w tryb synchroniczny.

Podczas następnego okna konserwacji ręcznie przełączyłem awaryjnie każdą bazę danych, a po kilku testach dymu wyłączyłem dublowanie i ostatecznie usunąłem stare pliki danych z serwerów źródłowych. Jednym z dziwactw w tym procesie jest to, że awaria lustrzanej bazy danych powoduje, że poprzednia podstawowa jest w stanie odzyskiwania, więc jeśli nie masz ochoty po prostu upuszczając je, musisz przywrócić je do trybu online, a następnie odłączyć lub dowolną preferowaną metodą usuwania . Ponadto nie skonfigurowałem świadka dla żadnego z tego, ponieważ nie chciałem automatycznego przełączania awaryjnego. To było zdarzenie kontrolowane.

Daj mi znać, jeśli chcesz uzyskać dodatkowe informacje. Pominąłem specyfikację serwera i sieci, ale mogę podać, jeśli chcesz.

Dzięki