MariaDB
 sql >> Datenbank >  >> RDS >> MariaDB

Migrieren von Amazon RDS (MySQL oder MariaDB) auf einen lokalen Server

Amazon Web Services ist ein Technologiegigant, insbesondere wenn es darum geht, sich selbst als Pionier bei Cloud-Computing-Diensten der Spitzenklasse zu etablieren. Seine vollständig verwalteten Serviceprodukte (Amazon RDS) sind einzigartig. Aber andererseits, obwohl es für einige Unternehmen eine perfekte Plattform sein kann, kann es eine Herausforderung sein, sich davon zu entfernen, wenn dies nicht der Fall ist. Es gibt immer Bedenken, in einer Vendor-Lock-in-Situation stecken zu bleiben.

Einige Dinge, die Sie bei der Migration von RDS zu einer On-Premise-Plattform beachten sollten, sind Budgetbeschränkungen, Sicherheit und Datenautonomie. Dies liegt daran, dass Daten Ihr wertvollstes Gut sind und die Kontrolle behalten, wo immer sie sich befinden, es ist immer unerlässlich, dass die Organisation und das Unternehmen immer wettbewerbsfähig bleiben. Keine Organisation kann es sich leisten, Cloud-Lock-in zu haben, und dennoch befinden sich viele Unternehmen genau in dieser Situation und beginnen hüpfend nach alternativen bestehenden Lösungen zu suchen, die über On-Premises betrieben werden können.

Dieser Blog führt Sie durch die Migration von Amazon RDS zu einem On-Prem-Server. Unsere Zieldatenbank auf dem lokalen Server befindet sich auf einem RHEL/CentOS-Linux-Server, aber das anwendbare Verfahren gilt auch für andere Linux-Versionen, solange die Pakete ordnungsgemäß installiert sind.

Es gibt einige Lösungen von Drittanbietern, die eine Datenmigration anbieten, die jedoch nicht für eine lokale Plattform anwendbar ist. Außerdem ist es nicht kostenlos und die Migration mit kostenlosen Open-Source-Lösungen ist immer günstig und vorteilhaft. Obwohl es auch Zweifel und Bedenken gibt, da die Garantie und der Support nicht an Open-Source-Technologien gebunden sind, zeigen wir Ihnen hier, wie Sie dies in einem einfachen Verfahren erreichen können.

Da Amazon RDS die Kompatibilität mit MySQL und MariaDB unterstützt. Wir werden uns in diesem Blog auf sie konzentrieren.

Migration von Amazon RDS für MySQL oder MariaDB

Ein typischer Ansatz zur Migration Ihrer Daten von Amazon RDS auf einen lokalen Server besteht darin, eine Sicherung mit einer logischen Kopie zu erstellen. Dies kann mithilfe von Sicherungsdienstprogrammen erfolgen, die für den Betrieb mit Amazon RDS, einem vollständig verwalteten Dienst, kompatibel sind. Vollständig verwaltete Datenbankdienste bieten keine SSH-Anmeldungen, daher ist eine physische Kopie von Sicherungen keine Option.

Mysqldump verwenden

Die Verwendung von mysqldump muss in Ihrem Zieldatenbankknoten installiert sein, der sich lokal befindet. Es muss als Replikat des AWS RDS-Knotens vorbereitet werden, damit alle nachfolgenden Transaktionen auf den Knoten repliziert werden. Führen Sie dazu die folgenden Schritte aus.

AWS RDS-Quellhost :database-1.xxxxxxx.us-east-2.rds.amazonaws.com

Lokaler Serverhost :192.168.10.226 (testnode26)

Bevor Sie mit dem Dump beginnen, vergewissern Sie sich, dass die Binlog-Aufbewahrungsstunden eingestellt sind. Um es festzulegen, können Sie wie im folgenden Beispielprozeduraufruf in Ihrer Amazon RDS-Instance vorgehen,

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 installieren

  1. Bereiten Sie das Repository vor.

# Für MySQL

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

# Für MariaDB

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

  1. Mysql-Client-Paket installieren

# Für MySQL

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

# Für MariaDB

$ yum install -y MariaDB-client

  1. Erstellen Sie einen Datendump mit mysqldump, indem Sie ihn innerhalb des Zielknotens ausführen. Beachten Sie, dass dies mit der Option --master-data=2 nur für MariaDB, aber nicht für MySQL funktioniert. Es muss also zusätzliche Arbeit für MySQL geleistet werden. Wir sprechen später darüber.

## Gilt für den MariaDB-Ansatz

[[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. Installieren Sie den MySQL/MariaDB-Server im Zieldatenbankknoten

# Für MySQL (überprüfen Sie immer, welche Version des Repositorys in Ihrem yum-Repository aktiviert ist. An diesem Punkt verwende ich MySQL 5.7)

$ yum --disablerepo=* --enablerepo=mysql57-community install mysql-community-common mysql-community-client mysql-community-server

# Für MariaDB

$ yum install MariaDB-server.x86_64

  1. Richten Sie die MySQL/MariaDB-Serverinstanz ein (my.cnf, Dateiberechtigungen, Verzeichnisse) und starten Sie den Server 

# Einrichten von my.cnf (unter Verwendung der von ClusterControl verwendeten my.cnf-Bereitstellung)

[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

## Datenverzeichnis zurücksetzen und Datenbanksystemdateien neu installieren

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

## Erstellen Sie die Protokollverzeichnisse

$ mkdir /var/log/mysql

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

## Für MySQL

$ mysqld --initialize

## Für MariaDB

$ mysql_install_db

  1. Starten Sie den MySQL/MariaDB-Server

## Für MySQL

$ systemctl start mysqld

## Für MariaDB

$ systemctl start mariadb

  1. Laden Sie den Daten-Dump, den wir von AWS RDS genommen haben, in den lokalen Zieldatenbankknoten

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

  1. Erstellen Sie den Replikationsbenutzer aus dem AWS RDS-Quellknoten

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. Richten Sie den MySQL/MariaDB-Server als Replikat/Slave des AWS RDS-Quellknotens ein

## Lassen Sie uns zuerst den Befehl CHANGE MASTER suchen oder lokalisieren

[[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;

## Führen Sie die CHANGE MASTER-Anweisung aus, aber fügen Sie den Replikationsbenutzer/das Passwort und den Hostnamen wie folgt hinzu,

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)

## Dann starten Sie die Slave-Threads

MariaDB [(none)]> START SLAVE;

Query OK, 0 rows affected (0.001 sec)

## Überprüfen Sie den Slave-Status, wie es geht

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)

Jetzt, da wir endlich in der Lage waren, von RDS als Quelle oder Master unseres Replikats, das sich vor Ort befindet, zu replizieren. Es ist noch nicht fertig. In einigen Fällen treten Replikationsfehler auf, z. B.      

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 keine Daten aus der MySQL-Datenbank für Tabellen mit dem Präfix „rds%“ replizieren muss, ignorieren wir diese Tabellen einfach während der Replikation. Außerdem möchten Sie möglicherweise nicht, dass AWS RDS Ihre mysql.user-Tabelle aktualisiert und ändert. Dazu können Sie optional das Schema ignorieren oder nur eine Liste von Tabellen wie z. B. 

STOP SLAVE;

Dann

SET GLOBAL replicate_wild_ignore_table='mysql.rds%';

oder

SET GLOBAL replicate_wild_ignore_table='mysql.%';

Das MySQL-Problem mit --master-data=2

Das Übernehmen von mysqldump mit --master-data=2 erfordert ausreichende Berechtigungen, was SUPER- und RELOAD-Berechtigungen erfordert. Das Problem ist, dass AWS RDS dies während der Einrichtung und Erstellung der Datenbank nicht für den Administratorbenutzer bereitstellt. Um dieses Problem zu umgehen, muss Ihr AWS RDS über ein Master- und ein Replikat- oder Slave-Setup verfügen. Sobald Sie ein Slave-Setup haben, nehmen Sie diesen als Ziel-Quellhost, wenn Sie mysqldump verwenden. Stoppen Sie dann die Slave-Threads von Ihrem AWS RDS-Replikat wie folgt:

rds-replica-mysql> CALL mysql.rds_stop_replication;

Nehmen Sie dann mysqldump ohne die Option --master-data, genau wie unten,

mysqldump -h database-1.xxxxxxx.us-east-2.rds.amazonaws.com -uadmin -p --single-transaction --databases db1 db2 db3  > backups/dump.sql

Führen Sie dann SHOW SLAVE STATUS\G von Ihrem AWS RDS-Replikat aus und notieren Sie sich Master_Log_File und Exec_Master_Log_Pos, die Sie verwenden, wenn Sie eine Verbindung zum AWS RDS-Master herstellen, der auf Ihren lokalen Server repliziert. Verwenden Sie diese Koordinaten beim Ausführen von CHANGE MASTER TO… MASTER_LOG_FILE=Master_Log_File, MASTER_LOG_POS=. Vergessen Sie nach Abschluss der Sicherung natürlich nicht, Ihr RDS-Replikat zu starten, um seine Replikations-Threads erneut zu starten,

rds-replica-mysql> CALL mysql.rds_start_replication;

Mit mydumper

mydumper kann hier Ihre alternative Option sein, besonders wenn der Datensatz sehr groß ist, da er Parallelität und Geschwindigkeit bietet, wenn Sie einen Dump oder eine Sicherungskopie Ihres Datensatzes von einem Quell-RDS-Knoten erstellen. Befolgen Sie die nachstehenden Schritte von der Installation von mydumper bis zum Laden auf Ihren lokalen Zielserver.

  1. Installieren Sie die Binärdatei. Die Binärdateien finden Sie hier 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. Nehmen Sie die Sicherung vom RDS-Quellknoten. Zum Beispiel

[[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

Jetzt nimmt mydumper an dieser Stelle Sicherungsdateien in Form von *.gz-Dateien

  1. Laden Sie es auf Ihren lokalen Zielserver

$ 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. Richten Sie den Zielknoten als Slave/Replikat ein. MyDumper enthält eine Datei namens Metadaten, die aus binären Protokollkoordinaten einschließlich GTID -Positionen besteht, zum Beispiel:

$ 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

## Führen Sie dann einen Änderungsmaster von der Replik oder Ihrem MySQL/MariaDB-Zieldatenbankknoten aus

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)

## Starte den Slave

MariaDB [jbmrcd_date]> start slave;

Query OK, 0 rows affected (0.001 sec)

An diesem Punkt haben Sie nun von einer Amazon RDS-Instanz repliziert, auf der MySQL/MariaDB ausgeführt wird. Sobald Ihre Anwendung bereit ist, sich von Ihrer Amazon RDS-Instance zu entfernen, richten Sie den Endpunkt ein, der zu Ihrem On-Prem-Server geht, und alle verbleibenden Transaktionen von Ihrer RDS-Instance werden auf Ihre On-Prem repliziert, sodass keine Daten verloren gehen und zu Ihrem On-Prem-Server gehen. Prem-Server.

Auf Datenabweichungen prüfen

Sobald Sie Ihre Daten auf Ihren On-Prem-Server geladen oder ausgelagert haben, der als Replikat der AWS RDS-Instanz fungiert, sollten Sie dies noch einmal überprüfen, indem Sie Prüfsummenberechnungen durchführen, um festzustellen, inwieweit Ihre Daten mit dem übereinstimmen Quelle Amazon RDS. Ich schlage vor, dass Sie das pt-table-checksum-Tool von Percona verwenden, aber Sie können Ihr eigenes erstellen, indem Sie Prüfsummen-Tools wie md5 oder sha256 verwenden, aber dies dauert einige Zeit. Darüber hinaus kann die Verwendung von pt-upgrade auch hilfreich sein, nachdem Ihre Datenmigration mit diesem Replikationsansatz abgeschlossen ist.

Fazit

Die Verwendung von mysqldump oder mydumper sind kostenlose Open-Source-Tools, was ebenfalls ein großer Vorteil ist, insbesondere wenn Ihre Daten sehr vertraulich sind und Sie nicht möchten, dass Dritte darauf zugreifen. Obwohl dieser Ansatz einfach sein mag, kann es mühsame und umfangreiche Arbeit bedeuten, da immer Tests und doppelte Überprüfungen folgen, um nachzuweisen, dass die Migration vollständig und ohne Dateninkonsistenzen durchgeführt wird.