Amazon Web Services е технологичен гигант, особено когато става въпрос за пионерство в най-добрите услуги за изчисления в облак. Неговите напълно управлявани услуги (Amazon RDS) са единствени по рода си. Но отново, въпреки че може да бъде перфектна платформа за някои организации, може да бъде предизвикателство да се оттеглите от нея, ако не е така. Винаги има опасения да не останете в ситуация на блокиране на доставчика.
Някои неща, които трябва да имате предвид, когато мигрирате от RDS към локална платформа, са бюджетните ограничения, сигурността и автономността на данните. Това е така, защото данните са вашият най-ценен актив и запазвайки контрола, където и да се намират, винаги е наложително организацията и компанията винаги да остават конкурентоспособни. Никоя организация не може да си позволи да има блокиране в облака и въпреки това много предприятия се оказват точно в тази ситуация и започват да търсят всякакви алтернативни съществуващи решения, които могат да бъдат работещи чрез on-prem.
Този блог ще ви преведе през това как да мигрирате от Amazon RDS към локален сървър. Нашата целева база данни на on-prem сървър е на RHEL/CentOS Linux сървър, но приложимата процедура ще се прилага за други версии на Linux, както и стига пакетите да са правилно инсталирани.
Има някои съществуващи решения на трети страни, които предлагат миграция на данни, но това не е приложимо за локална платформа. Освен това не е безплатно и мигрирането с безплатни решения с отворен код винаги е благоприятно и изгодно. Въпреки че съществуват съмнения и притеснения, тъй като гаранцията и поддръжката не са обвързани с технологии с отворен код, но тук ще ви покажем как да постигнете това по проста процедура.
Тъй като Amazon RDS поддържа съвместимост с MySQL и MariaDB. Ще се съсредоточим върху тях за този блог.
Мигриране от Amazon RDS за MySQL или MariaDB
Типичен подход за мигриране на вашите данни от Amazon RDS към локален сървър е да направите резервно копие с помощта на логическо копие. Това може да стане с помощта на помощни решения за архивиране, които са съвместими за работа с Amazon RDS, която е напълно управлявана услуга. Напълно управляваните услуги за бази данни не предлагат SSH влизания, така че физическото копие на резервните копия не е опция.
Използване на mysqldump
Използването на mysqldump трябва да бъде инсталирано във вашия целеви възел на базата данни, разположен on-prem. Той трябва да бъде подготвен като реплика на AWS RDS възела, така че всички последващи транзакции да се репликират на възела. За да направите това, следвайте стъпките по-долу.
Изходен хост на AWS RDS :database-1.xxxxxxx.us-east-2.rds.amazonaws.com
On-Prem Server Host :192.168.10.226 (testnode26)
Преди да стартирате дъмпа, уверете се, че часовете за задържане на binlog са зададени. За да го настроите, можете да направите като примерното извикване на процедура по-долу във вашия екземпляр на 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)Инсталирайте mysqldump
-
Подгответе хранилището.
# За MySQL
$ yum install https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm# За MariaDB
$ curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash-
Инсталиране на mysql-client пакет
# За MySQL
$ yum install -y mysql-community-client.x86_64# За MariaDB
$ yum install -y MariaDB-client-
Създайте дъмп на данни с помощта на mysqldump, като го изпълните в целевия възел. Обърнете внимание, че с --master-data=2, посочен като опция, това работи само за MariaDB, но не и в MySQL. Така че трябва да се направи допълнителна работа за MySQL. Ще поговорим за това по-късно.
## Приложимо за подхода 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-
Инсталирайте MySQL/MariaDB сървъра в целевия възел на базата данни
# За MySQL (винаги проверявайте коя версия хранилище е активирано във вашето yum хранилище. В този момент използвам MySQL 5.7)
$ yum --disablerepo=* --enablerepo=mysql57-community install mysql-community-common mysql-community-client mysql-community-server# За MariaDB
$ yum install MariaDB-server.x86_64-
Настройте екземпляра на MySQL/MariaDB Server (my.cnf, разрешения за файлове, директории) и стартирайте сървъра
# Настройване на my.cnf (с използване на внедряването my.cnf от 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## Нулирайте директорията с данни и инсталирайте отново системните файлове на базата данни
$ rm -rf /var/lib/mysql/*## Създайте директориите на журнала
$ mkdir /var/log/mysql
$ chown -R mysql.mysql /var/log/mysql## За MySQL
$ mysqld --initialize## За MariaDB
$ mysql_install_db
-
Стартирайте MySQL/MariaDB сървъра
## За MySQL
$ systemctl start mysqld## За MariaDB
$ systemctl start mariadb-
Заредете дъмпа на данни, който сме взели от AWS RDS, към целевия възел на базата данни on-prem
$ mysql --show-warnings < backups/dump.sql-
Създайте потребителя за репликация от изходния възел на 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)-
Настройте MySQL/MariaDB сървъра като реплика/подчинен на изходния възел на AWS RDS
## Първо, нека потърсим или намерим командата 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;## Изпълнете оператора CHANGE MASTER, но добавете потребителя/паролата за репликация и името на хоста, както следва,
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)## След това стартирайте подчинените нишки
MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.001 sec)## Проверете състоянието на подчинения как върви
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)Сега, когато най-накрая успяхме да репликираме от RDS като източник или главен източник на нашата реплика, разположена on-prem. Все още не е направено. Има някои случаи, в които ще срещнете грешки при репликация, като например
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'Тъй като on-prem не е необходимо да репликира данни, идващи от mysql база данни за таблици с префикс 'rds%', ние просто игнорираме тези таблици по време на репликацията. Освен това може да не искате AWS RDS да актуализира и променя вашата таблица mysql.user. За да направите това, можете по желание да игнорирате схемата или просто списък с таблици като,
STOP SLAVE;След това,
SET GLOBAL replicate_wild_ignore_table='mysql.rds%';или
SET GLOBAL replicate_wild_ignore_table='mysql.%';Проблемът с MySQL с --master-data=2
Вземането на mysqldump с --master-data=2 изисква достатъчно привилегии, което изисква привилегии SUPER и RELOAD. Проблемът е, че AWS RDS не предоставя това за потребителя с администратор по време на настройка и създаване на база данни. За да заобиколите този проблем, трябва да се окаже, че вашият AWS RDS има главна и реплика или подчинена настройка. След като имате подчинена настройка, вземете това като целеви изходен хост, когато приемате mysqldump. След това спрете подчинените нишки от вашата AWS RDS реплика, както следва,
rds-replica-mysql> CALL mysql.rds_stop_replication;След това вземете mysqldump без опцията --master-data точно както по-долу,
mysqldump -h database-1.xxxxxxx.us-east-2.rds.amazonaws.com -uadmin -p --single-transaction --databases db1 db2 db3 > backups/dump.sqlСлед това стартирайте SHOW SLAVE STATUS\G от вашата AWS RDS реплика и вземете под внимание Master_Log_File и Exec_Master_Log_Pos, за които ще използвате, когато се свързвате с главния AWS RDS репликация към вашия локален сървър. Използвайте тези координати, когато изпълнявате CHANGE MASTER TO... MASTER_LOG_FILE=Master_Log_File, MASTER_LOG_POS=
rds-replica-mysql> CALL mysql.rds_start_replication;Използване на mydumper
mydumper може да бъде вашата алтернативна опция тук, особено когато наборът от данни е много голям, тъй като предлага паралелизъм и скорост при вземане на дъмп или резервно копие на вашия набор от данни от изходен RDS възел. Следвайте стъпките по-долу от инсталирането на mydumper до зареждането на вашия дестинационен локален сървър.
-
Инсталирайте двоичния файл. Двоичните файлове могат да се намират тук 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-
Вземете резервното копие от възела източник на RDS. Например,
[[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 1109Сега, в този момент, mydumper ще вземе архивни файлове под формата на *.gz файлове
-
Заредете го във вашия локален сървър на местоназначение
$ 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`-
Настройте дестинационния възел като подчинен/реплика. MyDumper ще включва файл, наречен Metadata, който се състои от двоични координати на дневника, включително GTID позиции, например:
$ 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## След това стартирайте главен код за промяна от репликата или вашата целева дестинация възел на базата данни 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)## Стартирайте подчинения
MariaDB [jbmrcd_date]> start slave;
Query OK, 0 rows affected (0.001 sec)В този момент вече сте репликирали от екземпляр на Amazon RDS, изпълняващ MySQL/MariaDB. След като приложението ви е готово да се отдалечи от вашия екземпляр на Amazon RDS, настройте крайната точка, която отива към вашия on-prem сървър и всички останали транзакции от вашия RDS екземпляр ще бъдат репликирани във вашия on-prem, без да се пропускат данни към вашия on-prem prem сървър.
Проверете за несъответствия в данните
След като данните ви бъдат заредени или изхвърлени на вашия on-prem сървър, действащ като реплика от екземпляра на AWS RDS, трябва да проверите това, като изпълните изчисления на контролната сума, за да определите колко далеч са вашите данни спрямо източник Amazon RDS. Предлагам ви да използвате инструмента pt-table-checksum от Percona, но можете да създадете свой собствен, като използвате инструменти за контролно сумиране като md5 или sha256, но това отнема време. Освен това, използването на pt-upgrade може да помогне и след приключване на миграцията на данните ви чрез този подход за репликация.
Заключение
Използването на mysqldump или mydumper са безплатни инструменти с отворен код, което също е голямо предимство, особено ако данните ви са много поверителни и не искате трета страна да има достъп до тях. Въпреки че може да е лесно да се възприеме този подход, може да има досадна и голяма работа, която може да бъде включена, тъй като винаги следват тестове и двойни проверки, за да се докаже, че миграцията е постигната напълно без несъответствия в данните.
