Migrowanie bazy danych MySQL — serwer elastyczny do obsługi stref dostępności
W tym przewodniku opisano sposób migrowania programu MySQL — serwer elastyczny z obsługi stref niedostępnych do obsługi stref dostępności.
Usługę Azure Database for MySQL — elastyczny serwer można skonfigurować tak, aby korzystała z jednego z dwóch modeli architektury wysokiej dostępności (HA):
Architektura wysokiej dostępności w tej samej strefie (strefowa). Ta opcja jest preferowana w przypadku nadmiarowości infrastruktury z mniejszym opóźnieniem sieci, ponieważ serwery podstawowe i rezerwowe będą znajdować się w tej samej strefie dostępności. Zapewnia wysoką dostępność bez konieczności konfigurowania nadmiarowości aplikacji w różnych strefach. Wysoka dostępność w tej samej strefie jest preferowana, gdy chcesz uzyskać najwyższy poziom dostępności w ramach pojedynczej strefy dostępności z najniższym opóźnieniem sieci. Wysoka dostępność w tej samej strefie jest dostępna we wszystkich regionach świadczenia usługi Azure, w których można używać usługi Azure Database for MySQL — serwer elastyczny. Aby dowiedzieć się więcej na temat architektury wysokiej dostępności w tej samej strefie, zobacz Architektura wysokiej dostępności w tej samej strefie.
Architektura strefowo nadmiarowej wysokiej dostępności. Ta opcja jest preferowana w przypadku pełnej izolacji i nadmiarowości infrastruktury w wielu strefach dostępności. Zapewnia najwyższy poziom dostępności, ale wymaga skonfigurowania nadmiarowości aplikacji w różnych strefach. Strefowo nadmiarowa wysoka dostępność jest preferowana, jeśli chcesz osiągnąć najwyższy poziom dostępności w przypadku awarii infrastruktury w strefie dostępności i gdy opóźnienie w strefie dostępności jest akceptowalne. Można ją włączyć tylko po utworzeniu serwera. Strefowo nadmiarowa wysoka dostępność jest dostępna w podzestawie regionów platformy Azure, w których region obsługuje wiele stref dostępności i strefowo nadmiarowe udziały plików Premium są dostępne. Aby dowiedzieć się więcej o architekturze strefowo nadmiarowej wysokiej dostępności, zobacz Architektura strefowo nadmiarowej wysokiej dostępności.
Aby przeprowadzić migrację istniejącego obciążenia z strefowego (ta sama strefa wysokiej dostępności) do strefowo nadmiarowej wysokiej dostępności, należy wykonać następujące czynności:
Wdróż i skonfiguruj nowy serwer, który został skonfigurowany pod kątem strefowo nadmiarowej wysokiej dostępności.
Postępuj zgodnie ze wskazówkami dotyczącymi migracji w tym dokumencie, aby przenieść zasoby na nowy serwer.
Wymagania wstępne
Aby przeprowadzić migrację do obsługi stref dostępności:
Potrzebny będzie co najmniej jeden z następujących dwóch serwerów:
Serwer źródłowy z uruchomionym serwerem elastycznym usługi Azure Database for MySQL w regionie, który nie obsługuje stref dostępności.
Serwer elastyczny usługi Azure Database for MySQL, który nie był włączony dla wysokiej dostępności podczas tworzenia.
Ważne
Jeśli pierwotnie aprowizowaliśmy serwer elastyczny usługi Azure Database for MySQL jako serwer inny niż wysoka dostępność, możesz po prostu włączyć ją dla architektury wysokiej dostępności tej samej strefy. Jeśli jednak chcesz włączyć ją dla architektury strefowo nadmiarowej wysokiej dostępności, musisz zaimplementować jedną z dostępnych opcji migracji wymienionych w tym artykule.
Musisz utworzyć serwer docelowy z uruchomionym serwerem elastycznym usługi Azure Database for MySQL w regionie obsługującym strefy dostępności. Aby uzyskać więcej informacji na temat tworzenia elastycznego serwera usługi Azure Database for MySQL, zobacz Tworzenie serwera elastycznego usługi Azure Database for MySQL przy użyciu witryny Azure Portal. Upewnij się, że utworzony serwer jest skonfigurowany do nadmiarowości strefy, włączając wysoką dostępność i wybierając opcję Strefowo nadmiarowa .
Napiwek
Jeśli chcesz mieć elastyczność przenoszenia między strefową (tą samą strefą) i strefowo nadmiarową wysoką dostępnością w przyszłości, możesz aprowizować serwer elastyczny usługi Azure Database for MySQL z strefowo nadmiarową wysoką dostępnością włączoną podczas tworzenia serwera. Po aprowizacji serwera można wyłączyć wysoką dostępność.
Wymagania dotyczące przestojów
Migracje można podzielić na kategorie online lub offline:
• Migracja w trybie offline. Jeśli aplikacja może sobie pozwolić na przestój, migracje offline są zawsze preferowanym wyborem, ponieważ są proste i łatwe do wykonania. W przypadku migracji w trybie offline serwer źródłowy jest przełączony w tryb offline, a zrzut i przywracanie baz danych są wykonywane na serwerze docelowym. Ta opcja będzie wymagała największego przestoju. Czas przestoju jest określany przez czas potrzebny do wykonania przywracania na serwerze docelowym.
• Migracja online. Ta opcja ma minimalny przestój i jest najlepszym wyborem, jeśli chcesz mniej przestojów. Serwer źródłowy zezwala na aktualizacje, a rozwiązanie do migracji zajmie się replikacją bieżących zmian między serwerem źródłowym i docelowym wraz z początkowym zrzutem i przywracaniem na obiekcie docelowym.
Opcja migracji 1: Migracja w trybie offline
Migrację z jednego serwera elastycznego usługi Azure Database for Flexible Server można przeprowadzić przy użyciu jednego z następujących narzędzi. Obie te opcje będą wymagały przestoju.
Data Migration Service (DMS). Aby dowiedzieć się, jak przeprowadzić migrację serwera elastycznego MySQL do innego za pomocą usługi DMS, zobacz Migrowanie usługi Azure Database for MySQL — pojedynczy serwer do serwera elastycznego w trybie offline przy użyciu usługi DMS za pośrednictwem witryny Azure Portal. Mimo że w samouczku opisano kroki migracji z pojedynczego serwera Usługi Azure MySQL do serwera elastycznego, możesz użyć tej samej procedury migracji danych z jednego serwera elastycznego usługi Azure Database for MySQL, który nie obsługuje stref dostępności do innej, która obsługuje strefy dostępności.
Narzędzia typu open source. Możesz przeprowadzić migrację w trybie offline za pomocą narzędzi typu open source, takich jak MySQL Workbench, mydumper/myloader lub mysqldump , aby utworzyć kopię zapasową i przywrócić bazę danych. Aby uzyskać informacje na temat korzystania z tych narzędzi, zobacz Opcje migracji usługi Azure Database for MySQL — pojedynczy serwer do serwera elastycznego. Mimo że w samouczku opisano kroki migracji z pojedynczego serwera Usługi Azure MySQL do serwera elastycznego, możesz użyć tej samej procedury migracji danych z jednego serwera elastycznego usługi Azure Database for MySQL, który nie obsługuje stref dostępności do innej, która obsługuje strefy dostępności.
Opcja migracji 2: Migracja w trybie online
Migrację z jednego serwera elastycznego usługi Azure Database for Flexible Server można przeprowadzić z minimalnym przestojem w aplikacjach przy użyciu jednego z następujących narzędzi:
Data Migration Service (DMS). Aby dowiedzieć się, jak przeprowadzić migrację serwera elastycznego MySQL do innego za pomocą usługi DMS, zobacz Migrowanie usługi Azure Database for MySQL — pojedynczy serwer do serwera elastycznego w trybie online przy użyciu usługi DMS za pośrednictwem witryny Azure Portal. Mimo że w samouczku opisano kroki migracji z pojedynczego serwera Usługi Azure MySQL do serwera elastycznego, możesz użyć tej samej procedury migracji danych z jednego serwera elastycznego usługi Azure Database for MySQL, który nie obsługuje stref dostępności do innej, która obsługuje strefy dostępności.
Narzędzia typu open source. Możesz użyć kombinacji narzędzi typu open source, takich jak mydumper/myloader wraz z replikacją typu Data-in. Aby dowiedzieć się, jak skonfigurować replikację typu data-in, zobacz Jak skonfigurować replikację usługi Azure Database for MySQL Data-in.
Ważne
Replikacja typu data-in nie jest obsługiwana w przypadku serwerów z włączoną wysoką dostępnością. Obejściem jest aprowizowanie serwera docelowego z strefowo nadmiarową wysoką dostępnością, a następnie wyłączenie wysokiej dostępności przed skonfigurowaniem replikacji danych. Po zakończeniu replikacji ponownie włącz strefowo nadmiarową wysoką dostępność na serwerze docelowym.
Następne kroki
Dowiedz się więcej na następujące tematy:
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla