Migracja bazy danych Azure dla MySQL/MariaDB na serwer lokalny

Migracje baz danych mogą stanowić ogromne wyzwanie, jeśli weźmie się pod uwagę, jak zacząć, jakich narzędzi użyć i jak pomyślnie przeprowadzić pełną migrację bazy danych. Wcześniej wymieniliśmy najlepsze oprogramowanie typu open source, którego możesz użyć podczas migracji do MySQL lub MariaDB. W tym blogu pokażemy, jak przeprowadzić migrację danych z bazy danych Microsoft Azure dla MySQL lub MariaDB.

Microsoft Azure jest obecnie znany jako rywal z dwoma innymi gigantami technologii chmury:AWS i Google Cloud. Specjalizuje się w większej liczbie swoich produktów Microsoft, w szczególności w ich domowej, zastrzeżonej bazie danych MSSQL. Ale nie tylko to, ma również otwarte źródła jako jedną z w pełni zarządzanych baz danych usług, które można oferować publicznie. Wśród obsługiwanych baz danych znajdują się MySQL i MariaDB.

Wychodzenie z usługi Azure Database for MySQL/MariaDB może być żmudne, ale zależy to od typu architektury i typu zestawu danych hostowanego na platformie Azure jako obecnego dostawcy chmury. Dzięki odpowiednim narzędziom można to osiągnąć i przeprowadzić pełną migrację.

Skoncentrujemy się na narzędziach, których możemy używać do migracji danych na MySQL lub MariaDB. W tym blogu używam RHEL/CentOS do zainstalowania wymaganych pakietów. Przyjrzyjmy się i zdefiniujmy kroki i procedury, jak to zrobić.

Migracja z bazy danych Azure dla MySQL lub MariaDB

Typowym podejściem do migracji danych z usługi Azure Database na serwer lokalny jest wykonanie kopii zapasowej przy użyciu kopii logicznej. Można to zrobić za pomocą narzędzi do tworzenia kopii zapasowych, które są zgodne z działaniem Azure Database for MySQL lub MariaDB, która jest usługą w pełni zarządzaną. W pełni zarządzane usługi baz danych nie oferują logowania SSH, więc fizyczna kopia kopii zapasowych nie jest opcją.

Zanim będziesz mógł przeprowadzić migrację lub zrzucić istniejącą bazę danych z platformy Azure, musisz wziąć pod uwagę następujące kwestie.

Typowe przypadki użycia zrzutu i przywrócenia w środowisku lokalnym

Najczęstsze przypadki użycia to:

Korzystanie z logicznej kopii zapasowej (takiej jak mysqldump, mysqlpump lub mydumper/myloader) i przywracanie jest jedyną opcją. Azure Database for MySQL lub MariaDB nie obsługuje fizycznego dostępu do fizycznego magazynu, ponieważ jest to w pełni zarządzana usługa bazy danych.
Obsługuje tylko silniki pamięci masowej InnoDB i Memory. Migracja z alternatywnych silników pamięci masowej do InnoDB. Azure Database for MySQL lub MariaDB obsługuje tylko aparat magazynu InnoDB, dlatego nie obsługuje alternatywnych aparatów magazynu. Jeśli Twoje tabele są skonfigurowane z innymi aparatami magazynu, przekonwertuj je na format aparatu InnoDB przed migracją do Azure Database for MySQL.
Jeśli na przykład masz WordPress lub aplikację internetową korzystającą z tabel MyISAM, najpierw przekonwertuj te tabele, przeprowadzając migrację do formatu InnoDB przed przywróceniem do Azure Database for MySQL. Użyj klauzuli ENGINE=InnoDB, aby ustawić silnik używany podczas tworzenia nowej tabeli, a następnie przenieś dane do zgodnej tabeli przed przywróceniem.
Jeśli źródłowa baza danych Azure jest w określonej wersji, docelowy serwer lokalny jest również w tej samej wersji co źródłowa baza danych Azure.

Tak więc z tymi ograniczeniami można oczekiwać, że dane z platformy Azure muszą być silnikiem pamięci masowej InnoDB lub pamięcią, jeśli takie są w zestawie danych.

Rozważania dotyczące wydajności tworzenia logicznej kopii zapasowej z bazy danych Azure

Jedynym sposobem wykonania logicznej kopii zapasowej na platformie Azure jest użycie mysqldump lub mysqlpump. Aby zoptymalizować wydajność podczas robienia zrzutu za pomocą tych narzędzi, zwróć uwagę na następujące kwestie podczas zrzucania dużych baz danych:

Użyj opcji exclude-triggers w mysqldump podczas zrzucania baz danych. Wyklucz wyzwalacze z plików zrzutu, aby uniknąć uruchamiania poleceń wyzwalaczy podczas przywracania danych.
Użyj opcji pojedynczej transakcji, aby ustawić tryb izolacji transakcji na REPEATABLE READ i wyślij instrukcję SQL START TRANSACTION do serwera przed zrzuceniem danych. Zrzucanie wielu tabel w ramach jednej transakcji powoduje zużycie dodatkowej pamięci podczas przywracania. Opcja pojedynczej transakcji i opcja lock-tables wzajemnie się wykluczają, ponieważ LOCK TABLES powoduje, że wszystkie oczekujące transakcje są zatwierdzane niejawnie. Aby zrzucić duże tabele, połącz opcję pojedynczej transakcji z opcją szybkiej.
Użyj składni wielowierszowej z rozszerzoną wstawką, która obejmuje kilka list VALUE. Powoduje to mniejszy plik zrzutu i przyspiesza wstawianie, gdy plik jest ponownie ładowany.
Użyj opcji order-by-primary w mysqldump podczas zrzucania baz danych, aby dane były zapisywane w skryptach w kolejności klucza podstawowego.
Użyj opcji disable-keys w mysqldump podczas zrzucania danych, aby wyłączyć ograniczenia kluczy obcych przed załadowaniem. Wyłączenie sprawdzania kluczy obcych zapewnia wzrost wydajności. Włącz ograniczenia i zweryfikuj dane po załadowaniu, aby zapewnić integralność referencyjną.
W razie potrzeby używaj tabel partycjonowanych.
Wczytaj dane równolegle. Unikaj zbyt dużej równoległości, która spowodowałaby przekroczenie limitu zasobów, i monitoruj zasoby przy użyciu metryk dostępnych w Azure Portal.
Użyj opcji defer-table-indexes w mysqlpump podczas zrzucania baz danych, aby tworzenie indeksu następowało po załadowaniu danych tabeli.
Użyj opcji skip-definer w mysqlpump, aby pominąć klauzule definiujące i SQL SECURITY w instrukcjach tworzenia widoków i procedur składowanych. Kiedy ponownie ładujesz plik zrzutu, tworzy on obiekty, które używają domyślnych wartości DEFINER i SQL SECURITY.
Skopiuj pliki kopii zapasowej do obiektu blob/store Azure i wykonaj przywracanie z tego miejsca, co powinno być dużo szybsze niż przywracanie przez Internet.

Nieobsługiwane

Nieobsługiwane są następujące elementy:

Rola DBA:Ograniczona. Alternatywnie możesz użyć użytkownika administratora (utworzonego podczas tworzenia nowego serwera), co pozwala na wykonanie większości instrukcji DDL i DML.
Uprawnienia SUPER:Podobnie uprawnienia SUPER są ograniczone.
DEFINIER:Wymaga super uprawnień do tworzenia i jest ograniczony. Jeśli importujesz dane przy użyciu kopii zapasowej, usuń polecenia CREATE DEFINER ręcznie lub używając polecenia --skip-definer podczas wykonywania mysqldump.
Systemowe bazy danych:Baza danych systemu mysql jest tylko do odczytu i służy do obsługi różnych funkcji PaaS. Nie możesz wprowadzać zmian w bazie danych systemu mysql.
WYBIERZ... INTO OUTFILE:Nieobsługiwane w usłudze.

Korzystanie z mysqldump

Korzystanie z mysqldump musi być zainstalowane w docelowym węźle bazy danych zlokalizowanym lokalnie. Musi być przygotowany jako replika węzła Azure Database, aby wszystkie kolejne transakcje były replikowane do węzła. Aby to zrobić, wykonaj poniższe czynności.

Zainstaluj mysqldump

Przygotuj repozytorium.

# Dla MySQL

$ yum install https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm

# Dla MariaDB

$ curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash

Zainstaluj pakiet mysql-client

# Dla MySQL

$ yum install -y mysql-community-client.x86_64

# Dla MariaDB

$ yum install -y MariaDB-client

Utwórz zrzut danych za pomocą mysqldump, wykonując go w węźle docelowym.

$ MYSQL_PWD=<YOUR_MYSQL_PASS> mysqldump -h<YOUR_AZURE_DB_HOSTNAME>  -u<YOUR_AZURE_USERNAME> --single-transaction --master-data=2 --extended-insert --order-by-primary --disable-keys --databases maximusdb db2 db3 > backups/dump.sql

Zainstaluj serwer MySQL/MariaDB w docelowym węźle bazy danych

# Dla MySQL

$  yum install mysql-community-server.x86_64 mysql-community-client mysql-community-common

# Dla MariaDB

$ yum install MariaDB-server.x86_64

Skonfiguruj instancję MySQL/MariaDB Server (my.cnf, uprawnienia do plików, katalogi) i uruchom serwer

# Konfigurowanie my.cnf (przy użyciu wdrożenia my.cnf używanego przez ClusterControl)

[MYSQLD]

user=mysql

basedir=/usr/

datadir=/var/lib/mysql

socket=/var/lib/mysql/mysql.sock

pid_file=/var/lib/mysql/mysql.pid

port=3306

log_error=/var/log/mysql/mysqld.log

log_warnings=2

slow_query_log_file=/var/log/mysql/mysql-slow.log

long_query_time=2

slow_query_log=OFF

log_queries_not_using_indexes=OFF

innodb_buffer_pool_size=2G

innodb_flush_log_at_trx_commit=2

innodb_file_per_table=1

innodb_data_file_path=ibdata1:100M:autoextend

innodb_read_io_threads=4

innodb_write_io_threads=4

innodb_doublewrite=1

innodb_log_file_size=256M

innodb_log_buffer_size=32M

innodb_buffer_pool_instances=1

innodb_log_files_in_group=2

innodb_thread_concurrency=0

innodb_flush_method=O_DIRECT

innodb_rollback_on_timeout=ON

innodb_autoinc_lock_mode=2

innodb_stats_on_metadata=0

default_storage_engine=innodb

server_id=1126

binlog_format=ROW

log_bin=binlog

log_slave_updates=1

relay_log=relay-bin

expire_logs_days=7

read_only=OFF

report_host=192.168.10.226

key_buffer_size=24M

tmp_table_size=64M

max_heap_table_size=64M

max_allowed_packet=512M

skip_name_resolve=true

memlock=0

sysdate_is_now=1

max_connections=500

thread_cache_size=512

query_cache_type=0

query_cache_size=0

table_open_cache=1024

lower_case_table_names=0

performance_schema=OFF

performance-schema-max-mutex-classes=0

performance-schema-max-mutex-instances=0



[MYSQL]

socket=/var/lib/mysql/mysql.sock



[client]

socket=/var/lib/mysql/mysql.sock



[mysqldump]

socket=/var/lib/mysql/mysql.sock

max_allowed_packet=512M

## Zresetuj katalog danych i ponownie zainstaluj pliki systemu bazy danych

$ rm -rf /var/lib/mysql/*

## Utwórz katalogi dzienników

$ mkdir /var/log/mysql

$ chown -R mysql.mysql /var/log/mysql

## Dla MySQL

$ mysqld --initialize

## Dla MariaDB

$ mysql_install_db

Uruchom serwer MySQL/MariaDB

## Dla MySQL

$ systemctl start mysqld

## Dla MariaDB

$ systemctl start mariadb

Załaduj zrzut danych, który pobraliśmy z usługi Azure Database do docelowego węzła bazy danych lokalnie

$ mysql --show-warnings < backups/dump.sql

Utwórz użytkownika replikacji z węzła źródłowego Azure Database

CREATE USER 'repl_user'@'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO [email protected]'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';

Upewnij się, że zmieniłeś adres IP adresu IP węzła docelowego jako klient, z którego chcesz się połączyć.

Skonfiguruj serwer MySQL/MariaDB jako replikę/slave węzła źródłowego Azure Database

## Najpierw wyszukajmy lub zlokalizujmy polecenie CHANGE MASTER

$ grep -rn -E -i 'change master to master' backups/dump.sql |head -1

22:-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610;

## Uruchom instrukcję CHANGE MASTER, ale dodaj użytkownika/hasło replikacji i nazwę hosta w następujący sposób,

CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';

## W niektórych przypadkach może być konieczne zignorowanie schematu mysql. Uruchom następującą instrukcję:

SET GLOBAL replicate_wild_ignore_table='mysql.%';

## Następnie uruchom wątki podrzędne

START SLAVE;

## Sprawdź status urządzenia podrzędnego, jak idzie

SHOW SLAVE STATUS \G

Teraz, gdy w końcu byliśmy w stanie przeprowadzić replikację z bazy danych Azure dla MySQL/MariaDB jako źródła Twojej repliki zlokalizowanej lokalnie.

Korzystanie z mydumper

Azure Database for MySQL lub MariaDB w rzeczywistości sugeruje, że używanie mydumper specjalnie do dużych kopii zapasowych, takich jak 1 TB, może być alternatywną opcją. Oferuje równoległość i szybkość podczas wykonywania zrzutu lub kopii zapasowej zestawu danych ze źródłowego węzła Azure Database.

Wykonaj poniższe czynności, od zainstalowania mydumper do załadowania go na docelowy serwer lokalny.

Zainstaluj plik binarny. Pliki binarne można znaleźć tutaj https://github.com/maxbube/mydumper/releases.

 $ yum install https://github.com/maxbube/mydumper/releases/download/v0.9.5/mydumper-0.9.5-2.el6.x86_64.rpm

Pobierz kopię zapasową z węzła źródłowego Azure Database. Na przykład

[[email protected] mydumper]# MYSQL_PWD=<YOUR_AZURE_DB_PASSWORD> /usr/bin/mydumper --outputdir=. --verbose=3 --host=<YOUR_AZURE_DB_HOSTNAME>  -u <YOUR_AZURE_USER>@<YOUR_AZURE_DB_HOSTNAME> --port=3306 --kill-long-queries --chunk-filesize=5120 --build-empty-files --events --routines --triggers --compress --less-locking --success-on-1146 --regex='(maximusdb\.|db1\.|db2\.)'

** Message: Connected to a MySQL server

** Message: Using Percona Backup Locks



** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1

** Message: Started dump at: 2020-10-26 01:34:05



** Message: Written master status

** Message: Multisource slave detected.

** Message: Thread 5 connected using MySQL connection ID 64315

** Message: Thread 6 connected using MySQL connection ID 64345

** Message: Thread 7 connected using MySQL connection ID 64275

** Message: Thread 8 connected using MySQL connection ID 64283

** Message: Thread 1 connected using MySQL connection ID 64253

** Message: Thread 2 connected using MySQL connection ID 64211

** Message: Thread 3 connected using MySQL connection ID 64200

** Message: Thread 4 connected using MySQL connection ID 64211



** (mydumper:28829): CRITICAL **: Error: DB: mysql - Could not execute query: Access denied for user 'mysqldbadmin'@'%' to database 'mysql'

** Message: Thread 5 shutting down

** Message: Thread 6 shutting down

** Message: Thread 7 shutting down

** Message: Thread 8 shutting down

** Message: Thread 1 dumping data for `db1`.`TB1`

** Message: Thread 2 dumping data for `db1`.`tb2

….

Jak widać, istnieje ograniczenie dotyczące tworzenia kopii zapasowej z zarządzanej bazy danych, takiej jak Azure. Możesz zauważyć,

** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1

Dzieje się tak, ponieważ SUPER PRIVILEGE nie jest obsługiwany ani ograniczony. W idealnym przypadku najlepszą opcją jest wykonanie kopii zapasowej z repliki bazy danych Azure. Porozmawiamy o tym później.

Teraz, w tym momencie mydumper pobierze pliki kopii zapasowej w postaci plików *.gz

Załaduj go na docelowy serwer lokalny

$ myloader --host localhost --directory=$(pwd) --queries-per-transaction=10000 --threads=8 --compress-protocol --verbose=3

** Message: 8 threads created

** Message: Creating database `maximusdb`

** Message: Creating table `maximusdb`.`usertbl`

** Message: Creating table `maximusdb`.`familytbl`

** Message: Creating table `db2`.`t1`

** Message: Creating table `db3`.`test1`

…

….

Skonfiguruj węzeł docelowy jako slave/replikę. mydumper będzie zawierał plik o nazwie metadane, który składa się ze współrzędnych dziennika binarnego, w tym pozycji GTID, na przykład:

$ cat metadata

Started dump at: 2020-10-26 01:35:12

SHOW MASTER STATUS:

        Log: mysql-bin.000007

        Pos: 801

        GTID:0-3649485694-1705



Finished dump at: 2020-10-26 01:37:12

## Następnie uruchom zmiany master z repliki lub docelowego węzła bazy danych MySQL/MariaDB

CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000007', MASTER_LOG_POS=801, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';

## Uruchom urządzenie podrzędne

START SLAVE;

W tym momencie wykonano już replikację z wystąpienia usługi Azure Database z systemem MySQL/MariaDB. Gdy aplikacja będzie gotowa do przeniesienia z wystąpienia Azure Database, skonfiguruj punkt końcowy prowadzący do serwera lokalnego, a wszystkie pozostałe transakcje z wystąpienia platformy Azure zostaną zreplikowane do lokalnego, dzięki czemu żadne dane nie zostaną pominięte. serwer premium.

Obsługa ograniczeń związanych z zarządzanymi bazami danych dla MySQL lub MariaDB na platformie Azure

Pokonywanie ograniczeń, zwłaszcza podczas wykonywania kopii zapasowej zestawu danych, musi być w 100% dokładne od momentu wykonania kopii zapasowej. Oczywiście jest to idealna migracja do Twojej siedziby. Aby sobie z tym poradzić, najlepszą konfiguracją architektury jest obecność topologii replikacji w bazie danych Azure.

Gdy masz już i gotowe do migracji, mysqldump/mysqlpump lub mydumper musi używać repliki Azure Database jako źródła. W obrębie tej repliki Azure Database upewnij się, że SQL_THREAD jest zatrzymany, aby można było wykonać migawkę lub zarejestrować poprawne MASTER_LOG_FILE i EXEC_MASTER_LOG_POS z wyniku SHOW SLAVE STATUS.

Oczywiście po utworzeniu kopii zapasowej nie zapomnij uruchomić repliki Azure Database, aby ponownie uruchomić wątki replikacji.

Sprawdź rozbieżności danych

Gdy dane zostaną załadowane lub zrzucone na serwer lokalny działający jako replika z wystąpienia Azure Database, należy to dokładnie sprawdzić, uruchamiając obliczenia sum kontrolnych, aby określić, jak daleko odbiegają one od źródłowa baza danych Azure. Sugerujemy użycie narzędzia pt-table-checksum z Percona Toolkit, ale możesz stworzyć własne, używając narzędzi do sum kontrolnych, takich jak md5 lub sha256, ale to wymaga czasu. Ponadto użycie pt-upgrade z Percona Toolkit może pomóc również po zakończeniu migracji danych przy użyciu tego podejścia do replikacji.

Wnioski

Ograniczenia uprawnień i nieobsługiwane typy z usługi Azure Database mogą być trudne, ale przy odpowiednim przepływie i architekturze migracja z w pełni zarządzanej bazy danych działającej lokalnie nie jest niemożliwa. Wszystko, co musisz zrobić, to przygotować wymagane kroki, skonfigurować wymaganą topologię ze źródła Azure Database, a następnie rozpocząć migrację od wykonania kopii zapasowych do replikacji i całkowitej migracji do lokalnej.