Amazon Web Services to gigant technologiczny, zwłaszcza jeśli chodzi o pionierstwo w zakresie najwyższej klasy usług przetwarzania w chmurze. Jej w pełni zarządzane produkty usługowe (Amazon RDS) są jedyne w swoim rodzaju. Ale z drugiej strony, chociaż może to być idealna platforma dla niektórych organizacji, może być wyzwaniem, aby się z niej wycofać, jeśli tak nie jest. Zawsze istnieją obawy, że utkniesz w sytuacji zablokowania dostawcy.
Niektóre kwestie, o których należy pamiętać podczas migracji z RDS na platformę lokalną, to ograniczenia budżetowe, bezpieczeństwo i autonomia danych. Dzieje się tak, ponieważ dane są Twoim najcenniejszym zasobem, a zachowanie kontroli bez względu na to, gdzie się znajdują, zawsze konieczne jest, aby organizacja i firma zawsze pozostawały konkurencyjne. Żadna organizacja nie może sobie pozwolić na blokadę w chmurze, a jednak wiele przedsiębiorstw znajduje się właśnie w takiej sytuacji i zaczyna szukać alternatywnych istniejących rozwiązań, które mogą być obsługiwane lokalnie.
W tym blogu dowiesz się, jak przeprowadzić migrację z Amazon RDS na serwer lokalny. Nasza docelowa baza danych na serwerze on-prem znajduje się na serwerze RHEL/CentOS Linux, ale odpowiednia procedura będzie obowiązywać w innych wersjach systemu Linux, a także o ile pakiety są poprawnie zainstalowane.
Istnieją rozwiązania innych firm, które oferują migrację danych, ale nie mają zastosowania do platformy lokalnej. Dodatkowo nie jest darmowy, a migracja za pomocą darmowych rozwiązań open source jest zawsze korzystna i korzystna. Chociaż istnieją również wątpliwości i obawy, ponieważ gwarancja i wsparcie nie są związane z technologiami open source, ale pokażemy Ci tutaj, jak to osiągnąć w prostej procedurze.
Ponieważ Amazon RDS obsługuje zgodność z MySQL i MariaDB. Skoncentrujemy się na nich w tym blogu.
Migracja z Amazon RDS dla MySQL lub MariaDB
Typowym podejściem do migracji danych z Amazon RDS 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ą kompatybilne z Amazon RDS, który 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ą.
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 AWS RDS, aby wszystkie kolejne transakcje były replikowane do węzła. Aby to zrobić, wykonaj poniższe czynności.
Host źródłowy AWS RDS :baza danych-1.xxxxxxx.us-east-2.rds.amazonaws.com
Własny host serwera :192.168.10.226 (węzeł testowy26)
Przed rozpoczęciem zrzutu upewnij się, że ustawione są godziny przechowywania binlogów. Aby to ustawić, możesz wykonać przykładowe wywołanie procedury poniżej w instancji Amazon RDS,
mysql> call mysql.rds_set_configuration('binlog retention hours', 24);
Query OK, 2 rows affected (0.23 sec)
mysql> CALL mysql.rds_show_configuration;
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| name | value | description |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| binlog retention hours | 24 | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
1 row in set (0.23 sec)
Query OK, 0 rows affected (0.23 sec)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. Zwróć uwagę, że z opcją --master-data=2 określoną jako opcja, działa to tylko w przypadku MariaDB, ale nie w MySQL. Więc dodatkowa praca dla MySQL musi być wykonana. Porozmawiamy o tym później.
## Dotyczy podejścia MariaDB
[[email protected] ~]# mysqldump -h database-1.xxxxxxx.us-east-2.rds.amazonaws.com -uadmin -p --single-transaction --master-data=2 --databases db1 db2 db3 > backups/dump.sql
Enter password:
[[email protected] ~]# ls -alth backups/dump.sql
-rw-r--r--. 1 root root 196M Oct 18 02:34 backups/dump.sql-
Zainstaluj serwer MySQL/MariaDB w docelowym węźle bazy danych
# Dla MySQL (zawsze sprawdzaj, jakie repozytorium wersji jest włączone w repozytorium yum. W tym momencie używam MySQL 5.7)
$ yum --disablerepo=* --enablerepo=mysql57-community install mysql-community-common mysql-community-client mysql-community-server# 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 dziennika
$ 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 AWS RDS do docelowego węzła bazy danych na miejscu
$ mysql --show-warnings < backups/dump.sql-
Utwórz użytkownika replikacji z węzła źródłowego AWS RDS
MariaDB [(none)]> CREATE USER 'repl_user'@'149.145.213.%' IDENTIFIED BY 'repl_passw0rd';
Query OK, 0 rows affected (0.242 sec)
MariaDB [(none)]> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO repl_user'@'149.145.213.%' IDENTIFIED BY 'repl_passw0rd' ;
Query OK, 0 rows affected (0.229 sec)-
Skonfiguruj serwer MySQL/MariaDB jako replikę/slave węzła źródłowego AWS RDS
## Najpierw wyszukajmy lub zlokalizujmy polecenie CHANGE MASTER
[[email protected] ~]# grep -rn -E -i 'change master to master' backups/dump.sql |head -1
22:-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000584', MASTER_LOG_POS=421;## Uruchom instrukcję CHANGE MASTER, ale dodaj użytkownika/hasło replikacji i nazwę hosta w następujący sposób,
MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='database-1.xxxxxxx.us-east-2.rds.amazonaws.com', MASTER_LOG_FILE='mysql-bin-changelog.000584', MASTER_LOG_POS=421, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';
Query OK, 0 rows affected (0.004 sec)## Następnie uruchom wątki podrzędne
MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.001 sec)## Sprawdź status urządzenia podrzędnego, jak idzie
MariaDB [(none)]> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: database-1.xxxxxxx.us-east-2.rds.amazonaws.com
Master_User: repl_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin-changelog.000584
Read_Master_Log_Pos: 421
Relay_Log_File: relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: mysql-bin-changelog.000584
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 421
Relay_Log_Space: 256
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1675507089
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: optimistic
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Slave_DDL_Groups: 0
Slave_Non_Transactional_Groups: 0
Slave_Transactional_Groups: 0
1 row in set (0.000 sec)Teraz, gdy w końcu byliśmy w stanie replikować z RDS jako źródło lub master naszej repliki zlokalizowanej lokalnie. To jeszcze nie koniec. W niektórych przypadkach napotkasz błędy replikacji, takie jak:
Last_SQL_Errno: 1146
Last_SQL_Error: Error 'Table 'mysql.rds_heartbeat2' doesn't exist' on query. Default database: 'mysql'. Query: 'INSERT INTO mysql.rds_heartbeat2(id, value) values (1,1602988485784) ON DUPLICATE KEY UPDATE value = 1602988485784'Ponieważ lokalnie nie trzeba replikować danych pochodzących z bazy danych mysql dla tabel z prefiksem „rds%”, po prostu ignorujemy te tabele podczas replikacji. Ponadto możesz nie chcieć, aby AWS RDS aktualizował i zmieniał tabelę mysql.user. Aby to zrobić, możesz opcjonalnie zignorować schemat lub po prostu listę tabel, np.
STOP SLAVE;W takim razie
SET GLOBAL replicate_wild_ignore_table='mysql.rds%';lub
SET GLOBAL replicate_wild_ignore_table='mysql.%';Problem MySQL z --master-data=2
Pobranie mysqldump z --master-data=2 wymaga wystarczających uprawnień, co wymaga uprawnień SUPER i RELOAD. Problem polega na tym, że AWS RDS nie zapewnia tego użytkownikowi administracyjnemu podczas konfigurowania i tworzenia bazy danych. Aby obejść ten problem, musi być tak, że Twój AWS RDS ma konfigurację nadrzędną i replikę lub podrzędną. Gdy masz już konfigurację podrzędną, weź ją jako docelowy host źródłowy podczas pobierania mysqldump. Następnie zatrzymaj wątki podrzędne z repliki AWS RDS w następujący sposób,
rds-replica-mysql> CALL mysql.rds_stop_replication;Następnie weź mysqldump bez opcji --master-data, tak jak poniżej,
mysqldump -h database-1.xxxxxxx.us-east-2.rds.amazonaws.com -uadmin -p --single-transaction --databases db1 db2 db3 > backups/dump.sqlNastępnie uruchom SHOW SLAVE STATUS\G ze swojej repliki AWS RDS i zanotuj Master_Log_File i Exec_Master_Log_Pos, których będziesz używać podczas łączenia się z główną repliką AWS RDS z serwerem lokalnym. Użyj tych współrzędnych podczas uruchamiania ZMIEŃ MASTER NA… MASTER_LOG_FILE=Master_Log_File, MASTER_LOG_POS=
rds-replica-mysql> CALL mysql.rds_start_replication;Korzystanie z mydumper
mydumper może być tutaj twoją alternatywną opcją, zwłaszcza gdy zestaw danych jest bardzo duży, ponieważ oferuje równoległość i szybkość podczas robienia zrzutu lub kopii zapasowej zestawu danych ze źródłowego węzła RDS. 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 RDS. Na przykład
[[email protected] mydumper-2]# /usr/bin/mydumper --outputdir=. --verbose=3 --host=database-1.xxxxxxx.us-east-2.rds.amazonaws.com --port=3306 --kill-long-queries --chunk-filesize=5120 --build-empty-files --events --routines --triggers --compress --less-locking --success-on-1146 --regex='(db1\.|db2\.|db3\.|mydb4\.|testdb5\.)' -u admin --password=admin123
** Message: Connected to a MySQL server
** (mydumper:18904): CRITICAL **: Couldn't acquire global lock, snapshots will not be consistent: Access denied for user 'admin'@'%' (using password: YES)
** Message: Started dump at: 2020-10-18 09:34:08
** Message: Written master status
** Message: Multisource slave detected.
** Message: Thread 5 connected using MySQL connection ID 1109Teraz, 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 `db1`
** Message: Creating table `db1`.`folders_rel`
** Message: Creating table `db2`.`p`
** Message: Creating table `db2`.`t1`
** Message: Creating table `db3`.`AddressCodeTest`-
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-18 10:23:35
SHOW MASTER STATUS:
Log: mysql-bin-changelog.000680
Pos: 676
GTID:0-1675507089-3044## Następnie uruchom zmiany master z repliki lub docelowego węzła bazy danych MySQL/MariaDB
MariaDB [jbmrcd_date]> CHANGE MASTER TO MASTER_HOST='database-1.cmu8qdlvkepg.us-east-2.rds.amazonaws.com', MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd', MASTER_LOG_FILE='mysql-bin-changelog.000680', MASTER_LOG_POS
=676;
Query OK, 0 rows affected (0.002 sec)## Uruchom urządzenie podrzędne
MariaDB [jbmrcd_date]> start slave;
Query OK, 0 rows affected (0.001 sec)W tym momencie wykonałeś już replikację z instancji Amazon RDS z uruchomionym MySQL/MariaDB. Gdy Twoja aplikacja będzie gotowa do odejścia od instancji Amazon RDS, skonfiguruj punkt końcowy prowadzący do lokalnego serwera, a wszystkie pozostałe transakcje z Twojej instancji RDS zostaną zreplikowane do Twojej lokalnej instancji, dzięki czemu żadne dane nie zostaną pominięte. serwer premium.
Sprawdź rozbieżności danych
Gdy dane zostaną załadowane lub zrzucone na serwer lokalny działający jako replika z instancji AWS RDS, należy to dokładnie sprawdzić, wykonując obliczenia sum kontrolnych, aby określić, jak daleko odbiegają one od źródło Amazon RDS. Proponuję użyć narzędzia pt-table-checksum firmy Percona, 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 może pomóc również po zakończeniu migracji danych przy użyciu tej metody replikacji.
Wnioski
Korzystanie z mysqldump lub mydumper to bezpłatne narzędzia typu open source, co jest również wielką zaletą, zwłaszcza jeśli Twoje dane są bardzo poufne i nie chcesz, aby osoby trzecie miały do nich dostęp. Chociaż przyjęcie takiego podejścia może być proste, może to być żmudne i duże nakłady pracy, ponieważ zawsze następują testy i podwójne kontrole w celu udowodnienia, że migracja została w pełni osiągnięta bez żadnych niespójności danych.
