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

Migrieren von Azure Database for MySQL/MariaDB auf einen lokalen Server

Datenbankmigrationen können enorme Herausforderungen darstellen, wenn Sie überlegen, wie Sie beginnen, welche Tools Sie verwenden und wie Sie eine vollständige Datenbankmigration erfolgreich durchführen. Zuvor haben wir die Top-Open-Source aufgelistet, die Sie bei der Migration für MySQL oder MariaDB verwenden können. In diesem Blog zeigen wir Ihnen, wie Sie Daten aus Microsoft Azure Database for MySQL oder MariaDB migrieren.

Microsoft Azure ist jetzt als Konkurrent gegen die beiden anderen Cloud-Technologiegiganten bekannt:AWS und Google Cloud. Es spezialisiert sich auf mehr seiner Microsoft-Produkte, insbesondere auf seine selbst entwickelte proprietäre MSSQL-Datenbank. Aber nicht nur das, es hat auch Open Sources als eine seiner vollständig verwalteten Servicedatenbanken öffentlich anzubieten. Zu den unterstützten Datenbanken gehören MySQL und MariaDB.

Der Wechsel von Azure Database for MySQL/MariaDB kann mühsam sein, hängt jedoch davon ab, welche Art von Architektur und welche Art von Dataset Sie in Ihrem Azure als Ihrem aktuellen Cloud-Anbieter gehostet haben. Mit den richtigen Tools kann dies erreicht und eine vollständige Migration durchgeführt werden.

Wir konzentrieren uns auf die Tools, die wir für Datenmigrationen auf MySQL oder MariaDB verwenden können. Für diesen Blog verwende ich RHEL/CentOS, um die erforderlichen Pakete zu installieren. Lassen Sie uns die Schritte und Verfahren dazu durchgehen und definieren.

Migration von Azure Database for MySQL oder MariaDB

Ein typischer Ansatz zum Migrieren Ihrer Daten von Azure Database auf einen lokalen Server besteht darin, mithilfe einer logischen Kopie eine Sicherung zu erstellen. Dies kann mithilfe von Sicherungsdienstprogrammlösungen erfolgen, die für den Betrieb mit Azure Database for MySQL oder MariaDB, einem vollständig verwalteten Dienst, kompatibel sind. Vollständig verwaltete Datenbankdienste bieten keine SSH-Anmeldungen, daher ist eine physische Kopie von Sicherungen keine Option.

Bevor Sie Ihre vorhandene Datenbank von Azure migrieren oder sichern können, müssen Sie die folgenden Überlegungen beachten.

Häufige Anwendungsfälle für Dump und Restore On-Prem

Die häufigsten Anwendungsfälle sind:

  • Die Verwendung einer logischen Sicherung (wie mysqldump, mysqlpump oder mydumper/myloader) und Wiederherstellung ist die einzige Option. Azure Database for MySQL oder MariaDB unterstützt keinen physischen Zugriff auf den physischen Speicher, da es sich um einen vollständig verwalteten Datenbankdienst handelt.
  • Unterstützt nur InnoDB- und Memory-Speicher-Engines. Migration von alternativen Speicher-Engines zu InnoDB. Azure Database for MySQL oder MariaDB unterstützt nur die InnoDB-Speicher-Engine und unterstützt daher keine alternativen Speicher-Engines. Wenn Ihre Tabellen mit anderen Speicher-Engines konfiguriert sind, konvertieren Sie sie vor der Migration zu Azure Database for MySQL in das InnoDB-Engine-Format.
  • Wenn Sie beispielsweise eine WordPress- oder WebApp haben, die die MyISAM-Tabellen verwendet, konvertieren Sie diese Tabellen zuerst, indem Sie sie in das InnoDB-Format migrieren, bevor Sie sie in Azure Database for MySQL wiederherstellen. Verwenden Sie die Klausel ENGINE=InnoDB, um die Engine festzulegen, die beim Erstellen einer neuen Tabelle verwendet wird, und übertragen Sie die Daten dann vor der Wiederherstellung in die kompatible Tabelle.
  • Wenn sich Ihre Azure-Quelldatenbank in einer bestimmten Version befindet, hat Ihr lokaler Zielserver auch dieselbe Version wie die Azure-Quelldatenbank.

Mit diesen Einschränkungen erwarten Sie also nur, dass Ihre Daten aus Azure die InnoDB-Speicher-Engine oder der Arbeitsspeicher sein müssen, wenn dies in Ihrem Datensatz vorhanden ist.

Leistungsüberlegungen zum Erstellen einer logischen Sicherung aus der Azure-Datenbank

Die einzige Möglichkeit, ein logisches Backup mit Azure zu erstellen, ist die Verwendung von mysqldump oder mysqlpump. Um die Leistung beim Erstellen eines Dumps mit diesen Tools zu optimieren, beachten Sie beim Sichern großer Datenbanken die folgenden Überlegungen:

  • Verwenden Sie die Option exclude-triggers in mysqldump, wenn Sie Datenbanken sichern. Schließen Sie Trigger aus Dump-Dateien aus, um zu vermeiden, dass Trigger-Befehle während der Datenwiederherstellung ausgelöst werden.
  • Verwenden Sie die Einzeltransaktionsoption, um den Transaktionsisolationsmodus auf REPEATABLE READ festzulegen, und senden Sie eine START TRANSACTION-SQL-Anweisung an den Server, bevor Sie Daten ausgeben. Das Sichern vieler Tabellen innerhalb einer einzigen Transaktion führt dazu, dass während der Wiederherstellung zusätzlicher Speicherplatz verbraucht wird. Die Einzeltransaktionsoption und die Sperrtabellenoption schließen sich gegenseitig aus, da LOCK TABLES bewirkt, dass alle anstehenden Transaktionen implizit festgeschrieben werden. Um große Tabellen auszugeben, kombinieren Sie die Einzeltransaktionsoption mit der Schnelloption.
  • Verwenden Sie die Extended-Insert-Syntax für mehrere Zeilen, die mehrere VALUE-Listen enthält. Dies führt zu einer kleineren Dump-Datei und beschleunigt das Einfügen, wenn die Datei neu geladen wird.
  • Verwenden Sie die Option order-by-primary in mysqldump, wenn Sie Datenbanken sichern, damit die Daten in der Reihenfolge der Primärschlüssel geschrieben werden.
  • Verwenden Sie beim Sichern von Daten die Option disable-keys in mysqldump, um Fremdschlüsseleinschränkungen vor dem Laden zu deaktivieren. Das Deaktivieren von Fremdschlüsselprüfungen bietet Leistungssteigerungen. Aktivieren Sie die Einschränkungen und überprüfen Sie die Daten nach dem Laden, um die referenzielle Integrität sicherzustellen.
  • Verwenden Sie gegebenenfalls partitionierte Tabellen.
  • Daten parallel laden. Vermeiden Sie zu viel Parallelität, die dazu führen würde, dass Sie ein Ressourcenlimit erreichen, und überwachen Sie Ressourcen mithilfe der im Azure-Portal verfügbaren Metriken.
  • Verwenden Sie die Option defer-table-indexes in mysqlpump, wenn Sie Datenbanken sichern, damit die Indexerstellung erfolgt, nachdem die Daten der Tabelle geladen wurden.
  • Verwenden Sie die Option skip-definer in mysqlpump, um die Klauseln definer und SQL SECURITY aus den create-Anweisungen für Ansichten und gespeicherte Prozeduren auszulassen. Wenn Sie die Dump-Datei neu laden, erstellt sie Objekte, die die Standardwerte DEFINER und SQL SECURITY verwenden.
  • Kopieren Sie die Sicherungsdateien in einen Azure-Blob/Speicher und führen Sie die Wiederherstellung von dort aus durch, was viel schneller sein sollte als die Wiederherstellung über das Internet.

Nicht unterstützt

Folgendes wird nicht unterstützt:

  • DBA-Rolle:Eingeschränkt. Alternativ können Sie den Administrator-Benutzer verwenden (erstellt während der Erstellung eines neuen Servers), mit dem Sie die meisten DDL- und DML-Anweisungen ausführen können.
  • SUPER-Berechtigung:Ebenso ist die SUPER-Berechtigung eingeschränkt.
  • DEFINER:Erfordert Super-Privilegien zum Erstellen und ist eingeschränkt. Wenn Sie Daten mithilfe einer Sicherung importieren, entfernen Sie die CREATE DEFINER-Befehle manuell oder verwenden Sie den Befehl --skip-definer, wenn Sie einen mysqldump durchführen.
  • Systemdatenbanken:Die mysql-Systemdatenbank ist schreibgeschützt und wird verwendet, um verschiedene PaaS-Funktionen zu unterstützen. Sie können keine Änderungen an der MySQL-Systemdatenbank vornehmen.
  • SELECT ... INTO OUTFILE:Wird vom Dienst nicht unterstützt.

Mysqldump verwenden

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

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 Daten-Dump mit mysqldump, indem Sie ihn innerhalb des Zielknotens ausführen.

$ MYSQL_PWD=<YOUR_MYSQL_PASS> mysqldump -h<YOUR_AZURE_DB_HOSTNAME>  -u<YOUR_AZURE_USERNAME> --single-transaction --master-data=2 --extended-insert --order-by-primary --disable-keys --databases maximusdb db2 db3 > backups/dump.sql

  1. Installieren Sie den MySQL/MariaDB-Server im Zieldatenbankknoten

# Für MySQL

$  yum install mysql-community-server.x86_64 mysql-community-client mysql-community-common

# 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/*

## Protokollverzeichnisse erstellen

$ 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 aus der Azure-Datenbank genommen haben, in den lokalen Zieldatenbankknoten

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

  1. Erstellen Sie den Replikationsbenutzer aus Ihrem Azure Database-Quellknoten

CREATE USER 'repl_user'@'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO [email protected]'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';

Stellen Sie sicher, dass Sie die IP-Adresse der IP-Adresse Ihres Zielknotens als Client ändern, von dem aus eine Verbindung hergestellt werden soll.

  1. Richten Sie den MySQL/MariaDB-Server als Replikat/Slave des Azure-Datenbank-Quellknotens ein

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

$ grep -rn -E -i 'change master to master' backups/dump.sql |head -1

22:-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610;

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

CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';

## In einigen Fällen müssen Sie möglicherweise das mysql-Schema ignorieren. Führen Sie die folgende Anweisung aus:

SET GLOBAL replicate_wild_ignore_table='mysql.%';

## Dann starten Sie die Slave-Threads

START SLAVE;

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

SHOW SLAVE STATUS \G

Nun, da wir endlich in der Lage waren, aus Azure Database zu replizieren, entweder für MySQL/MariaDB als Quelle Ihres Replikats, das sich lokal befindet.

Mit mydumper

Azure Database for MySQL oder MariaDB schlägt tatsächlich vor, dass die Verwendung von mydumper speziell für große Backups wie 1 TB Ihre alternative Option sein kann. Es bietet Parallelität und Geschwindigkeit beim Erstellen einer Dump- oder Sicherungskopie Ihres Datasets von einem Azure-Datenbank-Quellknoten.

 Führen Sie die folgenden Schritte aus, 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 Quellknoten der Azure-Datenbank. Zum Beispiel

[[email protected] mydumper]# MYSQL_PWD=<YOUR_AZURE_DB_PASSWORD> /usr/bin/mydumper --outputdir=. --verbose=3 --host=<YOUR_AZURE_DB_HOSTNAME>  -u <YOUR_AZURE_USER>@<YOUR_AZURE_DB_HOSTNAME> --port=3306 --kill-long-queries --chunk-filesize=5120 --build-empty-files --events --routines --triggers --compress --less-locking --success-on-1146 --regex='(maximusdb\.|db1\.|db2\.)'

** Message: Connected to a MySQL server

** Message: Using Percona Backup Locks



** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1

** Message: Started dump at: 2020-10-26 01:34:05



** Message: Written master status

** Message: Multisource slave detected.

** Message: Thread 5 connected using MySQL connection ID 64315

** Message: Thread 6 connected using MySQL connection ID 64345

** Message: Thread 7 connected using MySQL connection ID 64275

** Message: Thread 8 connected using MySQL connection ID 64283

** Message: Thread 1 connected using MySQL connection ID 64253

** Message: Thread 2 connected using MySQL connection ID 64211

** Message: Thread 3 connected using MySQL connection ID 64200

** Message: Thread 4 connected using MySQL connection ID 64211



** (mydumper:28829): CRITICAL **: Error: DB: mysql - Could not execute query: Access denied for user 'mysqldbadmin'@'%' to database 'mysql'

** Message: Thread 5 shutting down

** Message: Thread 6 shutting down

** Message: Thread 7 shutting down

** Message: Thread 8 shutting down

** Message: Thread 1 dumping data for `db1`.`TB1`

** Message: Thread 2 dumping data for `db1`.`tb2

….

Wie Sie sehen können, gibt es eine Einschränkung beim Erstellen von Backups aus einer verwalteten Datenbank wie Azure. Sie werden es vielleicht bemerken,

** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1

Das liegt daran, dass SUPER PRIVILEGE nicht unterstützt oder eingeschränkt wird. Im Idealfall ist es am besten, die Sicherung von einem Replikat Ihrer Azure-Datenbank zu erstellen. Darüber reden wir später.

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 `maximusdb`

** Message: Creating table `maximusdb`.`usertbl`

** Message: Creating table `maximusdb`.`familytbl`

** Message: Creating table `db2`.`t1`

** Message: Creating table `db3`.`test1`

…

….

  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-26 01:35:12

SHOW MASTER STATUS:

        Log: mysql-bin.000007

        Pos: 801

        GTID:0-3649485694-1705



Finished dump at: 2020-10-26 01:37:12

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

CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000007', MASTER_LOG_POS=801, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';

## Starte den Slave

START SLAVE;

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

Umgang mit Einschränkungen bei verwalteten Datenbanken für MySQL oder MariaDB in Azure

Der Umgang mit Einschränkungen, insbesondere beim Erstellen eines Backup-Dumps Ihres Datensatzes, muss zu 100 % ab dem Zeitpunkt erfolgen, an dem Sie den Backup-Dump erstellt haben. Dies ist natürlich eine ideale Migration zu Ihrem lokalen Standort. Um dies zu bewältigen, besteht die beste Architekturkonfiguration darin, eine Replikationstopologie in Ihrer Azure-Datenbank zu haben.

Sobald Sie es haben und bereit für die Migration sind, muss mysqldump/mysqlpump oder mydumper das Azure-Datenbankreplikat als Quelle verwenden. Stellen Sie in diesem Azure-Datenbankreplikat sicher, dass SQL_THREAD beendet ist, damit Sie die richtigen MASTER_LOG_FILE und EXEC_MASTER_LOG_POS aus dem Ergebnis von SHOW SLAVE STATUS erstellen oder aufzeichnen können.

Vergessen Sie nach Abschluss der Sicherung natürlich nicht, Ihr Azure Database-Replikat zu starten, um seine Replikationsthreads erneut zu starten.

Auf Datenabweichungen prüfen

Sobald Sie Ihre Daten auf Ihren lokalen Server geladen oder ausgelagert haben, der als Replikat der Azure-Datenbankinstanz fungiert, sollten Sie dies noch einmal überprüfen, indem Sie Prüfsummenberechnungen ausführen, um zu bestimmen, wie weit Ihre Daten mit dem übereinstimmen Quelle Azure-Datenbank. Wir empfehlen Ihnen, das pt-table-checksum-Tool von Percona Toolkit zu 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 aus dem Percona Toolkit auch hilfreich sein, nachdem Ihre Datenmigration mit diesem Replikationsansatz abgeschlossen ist.

Fazit

Einschränkungen von Berechtigungen und nicht unterstützte Typen von Azure Database können eine Herausforderung darstellen, aber mit dem entsprechenden Ablauf und der entsprechenden Architektur ist es nicht unmöglich, von einer vollständig verwalteten Datenbank, die lokal läuft, zu migrieren. Alles, was Sie tun müssen, ist, die erforderlichen Schritte vorzubereiten, die erforderliche Topologie aus Ihrer Azure-Datenbankquelle einzurichten und dann die Migration vom Erstellen von Sicherungen über die Replikation bis hin zur vollständigen Migration zu Ihrem lokalen System zu starten.