Migracja danych z bazy danych MySQL do usługi Azure Database for MySQL — spójna migawka mySQL

Migawka spójna na poziomie bazy danych MySQL to nowa funkcja, która umożliwia użytkownikom wykonywanie spójnej migawki serwera MySQL bez utraty integralności danych w źródle z powodu trwających operacji CRUD (tworzenie, odczytywanie, aktualizowanie i usuwanie). Spójność transakcyjna jest osiągana bez konieczności ustawiania serwera źródłowego na tryb tylko do odczytu za pomocą tej funkcji. Ponadto istnieje wiele opcji spójności danych przedstawionych dla użytkownika — włącz spójną migawkę z blokadą odczytu (GA), włącz spójną migawkę bez blokad (wersja zapoznawcza), Ustaw serwer źródłowy tylko do odczytu i Brak. Wybranie opcji "Brak" nie wiąże się z żadnymi dodatkowymi środkami w celu zapewnienia spójności danych. Obie opcje — włącz spójną migawkę z blokadą odczytu (GA), włącz spójną migawkę bez blokad obsługujących przeprowadzanie migracji online. Zdecydowanie zalecamy wybranie opcji "Włącz spójną migawkę bez blokad", aby zachować spójność transakcyjną.

Włączanie spójnej migawki bez blokad (wersja zapoznawcza)

Po włączeniu tej opcji zostanie wykonana faza uzgodnień po początkowym załadowaniu. Ma to na celu zapewnienie, że dane zapisane w obiekcie docelowym są transakcyjnie zgodne z serwerem źródłowym z określonej pozycji w dzienniku binarnym.

Dzięki tej funkcji nie bierzemy blokady odczytu na serwerze. Zamiast tego odczytujemy tabele w innym momencie, a jednocześnie śledzimy różne pozycje dziennika binlogu każdej tabeli. Ułatwia to uzgadnianie tabel pod koniec początkowego obciążenia przez wykonanie replikacji w trybie przechwytywania w celu uzyskania spójnej migawki.

Najważniejsze funkcje spójnej migawki bez blokad:

• Możliwość obsługi dużych obciążeń serwerów lub serwerów z długotrwałymi transakcjami bez konieczności odczytywania blokad.
• Odporność na kończenie migracji nawet w przypadku awarii spowodowanych przejściowymi blokami sieci/serwera, które powodują utratę wszystkich wstępnie utworzonych połączeń.

Włączanie spójnej migawki z blokadą odczytu (GA)

Po włączeniu tej opcji usługa opróżnia wszystkie tabele na serwerze źródłowym z blokadą odczytu w celu uzyskania migawki do punktu w czasie. To opróżnianie odbywa się, ponieważ blokada globalna jest bardziej niezawodna niż próba zablokowania poszczególnych baz danych lub tabel. W związku z tym nawet jeśli nie migrujesz wszystkich baz danych na serwerze, są one zablokowane w ramach konfigurowania procesu migracji. Usługa migracji inicjuje powtarzalny odczyt i łączy bieżący stan tabeli z zawartością dziennika cofania migawki. Migawka jest generowana po uzyskaniu szerokiej blokady serwera przez kilka sekund i zduplikowaniu kilku połączeń na potrzeby migracji. Po utworzeniu wszystkich połączeń używanych do migracji blokady w tabeli zostaną zwolnione.

Powtarzalne odczyty są włączone w celu zapewnienia dostępności dzienników cofania podczas migracji, co zwiększa ilość miejsca wymaganego w źródle z powodu długotrwałych połączeń. Długotrwała migracja z wieloma zmianami tabeli prowadzi do obszernej historii dzienników cofania, która musi zostać odtworzona, a także może zwiększyć wymagania obliczeniowe i obciążenie serwera źródłowego.

Ustaw serwer źródłowy jako tylko do odczytu

Wybranie tej opcji zachowuje integralność danych docelowej bazy danych, ponieważ źródło jest migrowane, uniemożliwiając operacje zapisu/usuwania na serwerze źródłowym podczas migracji. Po ustawieniu serwera źródłowego tylko do odczytu w ramach procesu migracji wybór dotyczy wszystkich baz danych serwera źródłowego, niezależnie od tego, czy są wybrane do migracji.

Ustawienie serwera źródłowego tylko do odczytu uniemożliwia użytkownikom modyfikowanie danych, renderowanie bazy danych niedostępnej dla żadnych operacji aktualizacji. Jeśli jednak ta opcja nie jest włączona, istnieje możliwość wystąpienia aktualizacji danych podczas migracji. W związku z tym zmigrowane dane mogą być niespójne, ponieważ migawki bazy danych będą odczytywane w różnych punktach w czasie.

Wymagania wstępne dotyczące włączania spójnej migawki z blokadą odczytu

Aby pomyślnie ukończyć migrację za pomocą spójnej migawki z włączoną blokadą odczytu:

• Upewnij się, że użytkownik, który próbuje opróżnić tabele z blokadą odczytu, ma uprawnienie PRZEŁADOWYWANIE LUB OPRÓŻNIANIE.

• Użyj narzędzia klienckiego mysql, aby określić, czy log_bin jest włączona na serwerze źródłowym. Dziennik pojemnika nie zawsze jest domyślnie włączony i należy sprawdzić, czy jest włączony przed rozpoczęciem migracji. Narzędzie klienckie mysql służy do określania, czy log_bin jest włączona w źródle, uruchamiając polecenie: SHOW VARIABLES LIKE 'log_bin';

• Skonfiguruj parametr binlog_expire_logs_seconds na serwerze źródłowym, aby upewnić się, że pliki binlog nie są czyszczone przed zatwierdzeniem zmian przez replikę. Po pomyślnym przejściu jednorazowym można zresetować wartość.

Znane problemy i ograniczenia dotyczące włączania spójnej migawki bez blokad

• Tabele z kluczami obcymi, które mają wartość Cascade lub Ustaw wartość null w klauzuli delete/on update, nie są obsługiwane.
• Podczas początkowego ładowania nie powinny występować żadne zmiany DDL.

Znane problemy i ograniczenia dotyczące włączania spójnej migawki z blokadą odczytu

Znane problemy i ograniczenia związane z spójną kopią zapasową są zasadniczo podzielone na dwie kategorie: blokady i ponawianie prób.

Blokady

Zazwyczaj jest to prosty proces uzyskiwania blokady, który powinien potrwać od kilku sekund do kilku minut. Jednak w kilku scenariuszach próby uzyskania blokady na serwerze źródłowym mogą zakończyć się niepowodzeniem.

• Obecność długotrwałych zapytań może spowodować niepotrzebny przestój, ponieważ usługa DMS może zablokować podzbiór tabel, a następnie upłynął limit czasu oczekiwania na udostępnienie kilku ostatnich. Przed rozpoczęciem migracji sprawdź, czy istnieją długotrwałe operacje, uruchamiając polecenie SHOW PROCESSLIST .

• Jeśli na serwerze źródłowym występuje wiele aktualizacji zapisu w momencie żądania blokady, nie można łatwo uzyskać blokady i może zakończyć się niepowodzeniem po przekroczeniu limitu czasu oczekiwania na blokadę. Dzieje się tak w przypadku zadań przetwarzania wsadowego w tabelach, które w toku mogą spowodować odmowę żądania blokady. Jak wspomniano wcześniej, żądana blokada jest pojedynczą blokadą na poziomie globalnym dla całego serwera, więc nawet jeśli jedna tabela lub baza danych jest przetwarzana, żądanie blokady będzie musiało czekać na zakończenie trwającego zadania.

• Inne ograniczenie dotyczy migracji z serwera źródłowego usług AWS RDS. Usługa RDS nie obsługuje opróżniania tabel z blokadą odczytu, a zapytanie LOCK TABLE jest uruchamiane w wybranych tabelach pod maską. Ponieważ tabele są blokowane indywidualnie, proces blokowania może być mniej niezawodny, a uzyskanie blokad może trwać dłużej.

Ponowne próby

Migracja obsługuje przejściowe problemy z połączeniem, a dodatkowe połączenia są zwykle aprowidowane z góry w tym celu. Przyglądamy się ustawieniu migracji, szczególnie liczbie równoległych operacji odczytu w źródle i stosujemy współczynnik (zazwyczaj ok. 1,5) i tworzymy tyle połączeń z góry. Dzięki temu usługa zapewnia, że możemy zachować równoległe działanie operacji. W dowolnym momencie, jeśli wystąpiła utrata połączenia lub usługa nie może uzyskać blokady, usługa korzysta z nadmiarowych połączeń aprowizowanych, aby ponowić próbę migracji. Jeśli wszystkie aprowizowane połączenia zostaną wyczerpane, co spowoduje utratę synchronizacji do punktu w czasie, migracja musi zostać uruchomiona ponownie od początku. W przypadku powodzenia i niepowodzenia wszystkie akcje oczyszczania są podejmowane przez tę usługę migracji w trybie offline, a użytkownik nie musi wykonywać żadnych jawnych akcji oczyszczania.

Następne kroki

• Dowiedz się więcej o replikacji typu data-in

• Samouczek: migrowanie bazy danych MySQL do usługi Azure Database for MySQL w trybie offline przy użyciu usługi DMS