sql >> Database teknologi >  >> RDS >> MariaDB

Migrering af Amazon RDS (MySQL eller MariaDB) til en On-Prem Server

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

  1. 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
  1. Installer mysql-client-pakken

# Til MySQL

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

# For MariaDB

$ yum install -y MariaDB-client
  1. 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
  1. 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
  1. 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

  1. Start MySQL/MariaDB-serveren

## til MySQL

$ systemctl start mysqld

## For MariaDB

$ systemctl start mariadb
  1. Indlæs det datadump, vi har taget fra AWS RDS til måldatabasenoden on-prem

$ mysql --show-warnings < backups/dump.sql
  1. 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)
  1. 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=. Glem selvfølgelig ikke at starte din RDS-replika for at starte dens replikeringstråde igen, når sikkerhedskopieringen er udført,

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.

  1. 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
  1. 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

  1. 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`
  1. 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.


  1. PostgreSQL:Query Parallelism in Action

  2. PGError:FEJL:aggregater er ikke tilladt i WHERE-klausulen på en AR-forespørgsel af et objekt og dets har_mange objekter

  3. Bibliotek ikke indlæst:/usr/local/opt/readline/lib/libreadline.6.2.dylib

  4. Slet hændelser fra databasens maillog i SQL Server (T-SQL)