Amazon Web Services er en teknologigigant, især når det kommer til at være banebrydende inden for top-of-the-line cloud computing-tjenester. Dets fuldt administrerede serviceprodukter (Amazon RDS) er unikke. Men så igen, selvom det kan være en perfekt platform for nogle organisationer, kan det være en udfordring at flytte ud fra det, hvis det ikke er det. Der er altid bekymringer om at sidde fast i en leverandørlåsningssituation.
Nogle ting, du skal huske på, når du migrerer fra RDS til en on-premise platform, er budgetbegrænsninger, sikkerhed og dataautonomi. Dette skyldes, at data er dit mest værdifulde aktiv, og at bevare kontrollen, uanset hvor de befinder sig, er det altid bydende nødvendigt for organisationen og virksomheden altid at forblive konkurrencedygtig. Ingen organisation har råd til at have cloud lock-in, og alligevel befinder mange virksomheder sig præcis i den situation og begynder at søge efter alternative eksisterende løsninger, der kan betjenes på stedet.
Denne blog vil guide dig gennem, hvordan du migrerer fra Amazon RDS til en lokal server. Vores måldatabase på den lokale server er på en RHEL/CentOS Linux-server, men den gældende procedure gælder for andre versioner af Linux, så længe pakkerne er korrekt installeret.
Der er nogle eksisterende tredjepartsløsninger, der tilbyder datamigrering, men det er ikke anvendeligt til en on-premise platform. Derudover er det ikke gratis, og migrering ved hjælp af gratis med open source-løsninger er altid fordelagtigt og fordelagtigt. Selvom der også er tvivl og bekymringer, da garantien og supporten ikke er bundet til open source-teknologier, men vi viser dig her, hvordan du opnår dette i en ligetil procedure.
Da Amazon RDS understøtter kompatibilitet med MySQL og MariaDB. Vi vil fokusere på dem til denne blog.
Migrering fra Amazon RDS til MySQL eller MariaDB
En typisk metode til at migrere dine data fra Amazon RDS til en lokal server er at tage en sikkerhedskopi ved hjælp af en logisk kopi. Dette kan gøres ved hjælp af backup-værktøjsløsninger, der er kompatible med Amazon RDS, som er en fuldt administreret tjeneste. Fuldt administrerede databasetjenester tilbyder ikke SSH-login, så fysisk kopi af sikkerhedskopier er ikke en mulighed.
Brug af mysqldump
Brug af mysqldump skal installeres i din måldatabaseknude, der er lokaliseret. Det skal udarbejdes som en replika af AWS RDS-knuden, så alle efterfølgende transaktioner skal replikeres til knudepunktet. For at gøre dette skal du følge nedenstående trin.
AWS RDS-kildevært :database-1.xxxxxxx.us-east-2.rds.amazonaws.com
On-Prem Server Host :192.168.10.226 (testnode26)
Før du starter dumpet, skal du sørge for, at binlog-opbevaringstimerne er indstillet. For at indstille det, kan du gøre som eksempel på procedurekaldet nedenfor i din Amazon RDS-instans,
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)
Installer mysqldump
-
Forbered lageret.
# Til MySQL
$ yum install https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm
# For MariaDB
$ curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash
-
Installer mysql-client-pakken
# Til MySQL
$ yum install -y mysql-community-client.x86_64
# For MariaDB
$ yum install -y MariaDB-client
-
Opret et datadump ved hjælp af mysqldump ved at udføre det inde i målknuden. Bemærk, med --master-data=2 angivet som en mulighed, virker dette kun for MariaDB, men ikke i MySQL. Så ekstra arbejde for MySQL skal udføres. Vi taler om dette senere.
## Gælder for MariaDB-tilgangen
[[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
-
Installer MySQL/MariaDB-serveren i måldatabasenoden
# Til MySQL (tjek altid, hvilken versionsdepot der er aktiveret i dit yum-lager. På dette tidspunkt bruger jeg MySQL 5.7)
$ yum --disablerepo=* --enablerepo=mysql57-community install mysql-community-common mysql-community-client mysql-community-server
# For MariaDB
$ yum install MariaDB-server.x86_64
-
Konfigurer MySQL/MariaDB Server-instansen (my.cnf, filtilladelser, mapper), og start serveren
# Opsætning af my.cnf (ved hjælp af my.cnf-implementeringen, der bruges af 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
## Nulstil databiblioteket og geninstaller databasesystemfilerne
$ rm -rf /var/lib/mysql/*
## Opret logbibliotekerne
$ mkdir /var/log/mysql
$ chown -R mysql.mysql /var/log/mysql
## til MySQL
$ mysqld --initialize
## For MariaDB
$ mysql_install_db
-
Start MySQL/MariaDB-serveren
## til MySQL
$ systemctl start mysqld
## For MariaDB
$ systemctl start mariadb
-
Indlæs det datadump, vi har taget fra AWS RDS til måldatabasenoden on-prem
$ mysql --show-warnings < backups/dump.sql
-
Opret replikeringsbrugeren fra AWS RDS-kildenoden
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)
-
Konfigurer MySQL/MariaDB-serveren som en replika/slave af AWS RDS-kildenoden
## Lad os først søge eller finde kommandoen 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;
## Kør CHANGE MASTER-sætningen, men tilføj replikeringsbrugeren/adgangskoden og værtsnavnet som følger,
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)
## Start derefter slavetrådene
MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.001 sec)
## Tjek slavestatus, hvordan det går
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)
Nu hvor vi endelig har været i stand til at replikere fra RDS som kilden eller masteren af vores replika lokaliseret. Det er ikke gjort endnu. Der er nogle tilfælde, hvor du vil støde på replikeringsfejl, såsom
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'
Da on-prem ikke behøver at replikere data, der kommer fra mysql-databasen for tabeller med præfiks med 'rds%', så ignorerer vi bare disse tabeller under replikering. Derudover vil du måske ikke have, at AWS RDS opdaterer og ændrer din mysql.user-tabel. For at gøre dette kan du valgfrit ignorere skemaet eller bare liste over tabeller såsom,
STOP SLAVE;
Så,
SET GLOBAL replicate_wild_ignore_table='mysql.rds%';
eller
SET GLOBAL replicate_wild_ignore_table='mysql.%';
MySQL-problemet med --master-data=2
At tage mysqldump med --master-data=2 kræver tilstrækkelige privilegier, hvilket kræver SUPER- og RELOAD-rettigheder. Problemet er, at AWS RDS ikke leverer dette til admin-brugeren under opsætning og oprettelse af databasen. For at løse dette problem skal det være, at din AWS RDS har en master- og en replika- eller slaveopsætning. Når du har en slaveopsætning, skal du tage den som målkildevært, når du tager mysqldump. Stop derefter slavetrådene fra din AWS RDS-replika som følger,
rds-replica-mysql> CALL mysql.rds_stop_replication;
Så tag mysqldump uden --master-data-indstillingen ligesom nedenfor,
mysqldump -h database-1.xxxxxxx.us-east-2.rds.amazonaws.com -uadmin -p --single-transaction --databases db1 db2 db3 > backups/dump.sql
Kør derefter SHOW SLAVE STATUS\G fra din AWS RDS-replika, og læg mærke til Master_Log_File og Exec_Master_Log_Pos, som du vil bruge, når du opretter forbindelse til AWS RDS-master-replikeringen til din lokale server. Brug disse koordinater, når du kører CHANGE MASTER TO... MASTER_LOG_FILE=Master_Log_File, MASTER_LOG_POS=
rds-replica-mysql> CALL mysql.rds_start_replication;
Brug af mydumper
mydumper kan være din alternative mulighed her, især når datasættet er meget stort, da det tilbyder parallelitet og hastighed, når du tager en dump eller sikkerhedskopi af dit datasæt fra en RDS-kildeknude. Følg nedenstående trin fra installation af mydumper til indlæsning af den til din lokale destinationsserver.
-
Installer det binære. De binære filer kan findes her 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
-
Tag sikkerhedskopien fra RDS-kildenoden. For eksempel,
[[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
Nu, på dette tidspunkt vil mydumper tage en sikkerhedskopi af filer i form af *.gz-filer
-
Indlæs den til din destinationsserver på stedet
$ 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`
-
Opsæt destinationsknuden som en slave/replika. MyDumper vil indeholde en fil kaldet metadata, der består af binære logkoordinater inklusive GTID -positioner, for eksempel:
$ 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
## Kør derefter en ændringsmaster fra replikaen eller din måldestination MySQL/MariaDB-databaseknude
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)
## Start slaven
MariaDB [jbmrcd_date]> start slave;
Query OK, 0 rows affected (0.001 sec)
På dette tidspunkt har du nu replikeret fra en Amazon RDS-instans, der kører MySQL/MariaDB. Når din applikation er klar til at flytte væk fra din Amazon RDS-instans, skal du konfigurere slutpunktet, der går til din lokale server, og alle resterende transaktioner fra din RDS-instans vil blive replikeret til din lokale, uden at der går nogen data glip af til din on-prem-instans. prem-server.
Se efter dataafvigelser
Når du har dine data indlæst eller dumpet til din lokale server, der fungerer som en replika fra AWS RDS-instansen, bør du dobbelttjekke dette ved at køre kontrolsumberegninger for at bestemme, hvor langt dine data er i forhold til kilde Amazon RDS. Jeg foreslår, at du bruger pt-table-checksum-værktøjet fra Percona, men du kan oprette dit eget ved at bruge kontrolsummeværktøjer såsom md5 eller sha256, men det tager tid at gøre. Derudover kan brug af pt-upgrade også hjælpe efter din datamigrering ved hjælp af denne replikeringstilgang er færdig.
Konklusion
At bruge mysqldump eller mydumper er gratis open source-værktøjer, hvilket også er en stor fordel, især hvis dine data er meget fortrolige, og du ikke ønsker, at en tredjepart skal få adgang til dem. Selvom det kan være nemt at tage denne tilgang, kan der være kedeligt og stort arbejde, der kan være involveret, da test og dobbelttjek altid følger for at bevise, at migreringen er fuldt ud opnået uden nogen datainkonsistens.