Memigrasikan Azure Database untuk MySQL/MariaDB ke Server Lokal

Migrasi database dapat menimbulkan tantangan besar saat Anda mempertimbangkan cara memulai, alat apa yang digunakan, dan cara mencapai migrasi database lengkap dengan sukses. Sebelumnya, kami telah mencantumkan open source teratas yang dapat Anda gunakan pada migrasi untuk MySQL atau MariaDB. Di blog ini, kami akan menunjukkan cara memigrasikan data dari Microsoft Azure Database untuk MySQL atau MariaDB.

Microsoft Azure sekarang dikenal sebagai pesaing dari dua raksasa teknologi cloud lainnya:AWS dan Google Cloud. Ini mengkhususkan lebih banyak produk Microsoft khususnya database kepemilikan MSSQL yang ditanam di rumah mereka. Tetapi tidak hanya itu, ia juga memiliki sumber terbuka sebagai salah satu basis data layanan yang dikelola sepenuhnya untuk ditawarkan kepada publik. Di antara database yang didukungnya adalah MySQL dan MariaDB.

Pindah dari Azure Database untuk MySQL/MariaDB bisa jadi membosankan, tetapi itu tergantung pada jenis arsitektur dan jenis dataset apa yang telah Anda host di Azure sebagai penyedia cloud Anda saat ini. Dengan alat yang tepat, ini dapat dicapai dan migrasi penuh dapat dilakukan.

Kami akan fokus pada alat yang dapat kami gunakan untuk migrasi data di MySQL atau MariaDB. Untuk blog ini, saya menggunakan RHEL/CentOS untuk menginstal paket yang diperlukan. Mari kita bahas dan tentukan langkah dan prosedur tentang cara melakukannya.

Migrasi Dari Database Azure untuk MySQL atau MariaDB

Pendekatan umum untuk memigrasikan data Anda dari Azure Database ke server lokal adalah dengan mengambil cadangan menggunakan salinan logis. Ini dapat dilakukan dengan menggunakan solusi utilitas cadangan yang kompatibel untuk beroperasi dengan Azure Database untuk MySQL atau MariaDB yang merupakan layanan yang dikelola sepenuhnya. Layanan database yang terkelola sepenuhnya tidak menawarkan login SSH sehingga salinan fisik cadangan bukanlah pilihan.

Sebelum Anda dapat memigrasi atau membuang database yang ada dari Azure, Anda harus memperhatikan pertimbangan berikut.

Kasus Penggunaan Umum Untuk Dump dan Restore On-Prem

Kasus penggunaan yang paling umum adalah:

Menggunakan pencadangan logis (seperti mysqldump, mysqlpump atau mydumper/myloader) dan memulihkan adalah satu-satunya pilihan. Azure Database untuk MySQL atau MariaDB tidak mendukung akses fisik ke penyimpanan fisik karena ini adalah layanan database yang terkelola sepenuhnya.
Hanya mendukung mesin penyimpanan InnoDB dan Memori. Bermigrasi dari mesin penyimpanan alternatif ke InnoDB. Azure Database untuk MySQL atau MariaDB hanya mendukung mesin Penyimpanan InnoDB, dan karenanya tidak mendukung mesin penyimpanan alternatif. Jika tabel Anda dikonfigurasi dengan mesin penyimpanan lain, konversikan ke dalam format mesin InnoDB sebelum migrasi ke Azure Database untuk MySQL.
Misalnya, jika Anda memiliki WordPress atau WebApp menggunakan tabel MyISAM, pertama-tama konversikan tabel tersebut dengan bermigrasi ke format InnoDB sebelum memulihkan ke Azure Database untuk MySQL. Gunakan klausa ENGINE=InnoDB untuk mengatur mesin yang digunakan saat membuat tabel baru, lalu transfer data ke tabel yang kompatibel sebelum pemulihan.
Jika Basis Data Azure sumber Anda menggunakan versi tertentu, maka server lokal target Anda juga memiliki versi yang sama dengan Basis Data Azure sumber.

Jadi dengan batasan ini, Anda hanya berharap bahwa data Anda dari Azure harus berupa mesin penyimpanan atau Memori InnoDB, jika ada dalam kumpulan data Anda.

Pertimbangan Kinerja Untuk Mengambil Cadangan Logis dari Database Azure

Satu-satunya cara untuk mengambil cadangan logis dengan Azure adalah dengan menggunakan mysqldump atau mysqlpump. Untuk mengoptimalkan kinerja saat melakukan dump menggunakan alat ini, perhatikan pertimbangan berikut saat membuang database besar:

Gunakan opsi exception-triggers di mysqldump saat membuang database. Kecualikan pemicu dari file dump untuk menghindari perintah pemicu yang diaktifkan selama pemulihan data.
Gunakan opsi transaksi tunggal untuk menyetel mode isolasi transaksi ke REPEATABLE READ dan kirim pernyataan SQL MULAI TRANSAKSI ke server sebelum membuang data. Membuang banyak tabel dalam satu transaksi menyebabkan beberapa penyimpanan tambahan dikonsumsi selama pemulihan. Opsi transaksi tunggal dan opsi tabel kunci saling eksklusif karena LOCK TABLES menyebabkan transaksi yang tertunda dilakukan secara implisit. Untuk membuang tabel besar, gabungkan opsi transaksi tunggal dengan opsi cepat.
Gunakan sintaks multi-baris penyisipan yang diperluas yang menyertakan beberapa daftar VALUE. Ini menghasilkan file dump yang lebih kecil dan mempercepat penyisipan saat file dimuat ulang.
Gunakan opsi order-by-primary di mysqldump saat membuang database, sehingga data ditulis dalam urutan kunci utama.
Gunakan opsi disable-keys di mysqldump saat membuang data, untuk menonaktifkan batasan kunci asing sebelum memuat. Menonaktifkan pemeriksaan kunci asing memberikan peningkatan kinerja. Aktifkan batasan dan verifikasi data setelah pemuatan untuk memastikan integritas referensial.
Gunakan tabel yang dipartisi jika perlu.
Muat data secara paralel. Hindari terlalu banyak paralelisme yang akan menyebabkan Anda mencapai batas sumber daya, dan pantau sumber daya menggunakan metrik yang tersedia di portal Azure.
Gunakan opsi defer-table-indexes di mysqlpump saat membuang database, sehingga pembuatan indeks terjadi setelah data tabel dimuat.
Gunakan opsi lewati-definer di mysqlpump untuk menghilangkan klausa definisi dan SQL SECURITY dari pernyataan buat untuk tampilan dan prosedur tersimpan. Saat Anda memuat ulang file dump, itu membuat objek yang menggunakan nilai DEFINER dan SQL SECURITY default.
Salin file cadangan ke gumpalan/penyimpanan Azure dan lakukan pemulihan dari sana, yang seharusnya jauh lebih cepat daripada melakukan pemulihan di Internet.

Tidak didukung

Berikut ini tidak didukung:

Peran DBA:Dibatasi. Atau, Anda dapat menggunakan pengguna administrator (dibuat selama pembuatan server baru), memungkinkan Anda untuk melakukan sebagian besar pernyataan DDL dan DML.
Hak istimewa SUPER:Demikian pula, hak istimewa SUPER dibatasi.
DEFINER:Memerlukan hak super untuk membuat dan dibatasi. Jika mengimpor data menggunakan cadangan, hapus perintah CREATE DEFINER secara manual atau dengan menggunakan perintah --skip-definer saat menjalankan mysqldump.
Basis data sistem:Basis data sistem mysql bersifat hanya-baca dan digunakan untuk mendukung berbagai fungsionalitas PaaS. Anda tidak dapat membuat perubahan pada database sistem mysql.
PILIH ... INTO OUTFILE:Tidak didukung dalam layanan.

Menggunakan mysqldump

Menggunakan mysqldump harus diinstal di node database target Anda yang terletak di tempat. Itu harus disiapkan sebagai replika node Azure Database sehingga semua transaksi berikutnya harus direplikasi ke node. Untuk melakukannya, ikuti langkah-langkah di bawah ini.

Instal mysqldump

Siapkan repositori.

# Untuk MySQL

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

# Untuk MariaDB

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

Instal paket klien-mysql

# Untuk MySQL

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

# Untuk MariaDB

$ yum install -y MariaDB-client

Buat dump data menggunakan mysqldump dengan mengeksekusinya di dalam node target.

$ 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

Instal Server MySQL/MariaDB di node database target

# Untuk MySQL

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

# Untuk MariaDB

$ yum install MariaDB-server.x86_64

Siapkan instance Server MySQL/MariaDB (my.cnf, izin file, direktori), dan mulai server

# Menyiapkan my.cnf (menggunakan penerapan my.cnf digunakan oleh 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

## Atur ulang direktori data dan instal ulang file sistem database

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

## Buat direktori log

$ mkdir /var/log/mysql

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

## Untuk MySQL

$ mysqld --initialize

## Untuk MariaDB

$ mysql_install_db

Mulai Server MySQL/MariaDB

## Untuk MySQL

$ systemctl start mysqld

## Untuk MariaDB

$ systemctl start mariadb

Muat dump data yang telah kami ambil dari Azure Database ke node database target di tempat

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

Buat pengguna replikasi dari node sumber Azure Database Anda

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

Pastikan Anda mengubah alamat IP dari alamat IP node target Anda sebagai klien untuk terhubung.

Siapkan Server MySQL/MariaDB sebagai replika/budak node sumber Azure Database

## Pertama, mari kita cari atau temukan perintah CHANGE MASTER

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

## Jalankan pernyataan CHANGE MASTER tetapi tambahkan pengguna/sandi replikasi dan nama host sebagai berikut,

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

## Dalam beberapa kasus, Anda mungkin harus mengabaikan skema mysql. Jalankan pernyataan berikut:

SET GLOBAL replicate_wild_ignore_table='mysql.%';

## Kemudian mulai utas slave

START SLAVE;

## Periksa status budak bagaimana kelanjutannya

SHOW SLAVE STATUS \G

Sekarang kami akhirnya dapat mereplikasi dari Azure Database baik untuk MySQL/MariaDB sebagai sumber replika Anda yang berlokasi di tempat.

Menggunakan mydumper

Azure Database untuk MySQL atau MariaDB sebenarnya menyarankan bahwa menggunakan mydumper khusus untuk cadangan besar seperti 1TB dapat menjadi pilihan alternatif Anda. Ini menawarkan paralelisme dan kecepatan saat mengambil salinan dump atau cadangan dataset Anda dari node Azure Database sumber.

Ikuti langkah-langkah di bawah ini mulai dari menginstal mydumper hingga memuatnya ke server lokal tujuan Anda.

Instal biner. Binari dapat ditemukan di sini 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

Ambil cadangan dari node sumber Azure Database. Misalnya,

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

….

Seperti yang Anda lihat, ada batasan untuk mengambil cadangan dari database terkelola seperti Azure. Anda mungkin memperhatikan,

** (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

Ini karena, SUPER PRIVILEGE tidak didukung atau dibatasi. Idealnya, opsi terbaik untuk melakukan ini adalah mengambil cadangan dari replika Database Azure Anda. Kita akan membicarakannya nanti.

Sekarang, pada tahap ini, mydumper akan mengambil file cadangan berupa *.gz file

Muat ke server lokal tujuan Anda

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

…

….

Siapkan node tujuan sebagai budak/replika. MyDumper akan menyertakan file yang disebut metadata yang terdiri dari koordinat log biner termasuk posisi GTID, misalnya:

$ 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

## Kemudian jalankan master perubahan dari replika atau node database MySQL/MariaDB tujuan target Anda

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

## Mulai slave

START SLAVE;

Pada titik ini, Anda sekarang telah mereplikasi dari instance Azure Database yang menjalankan MySQL/MariaDB. Setelah aplikasi Anda siap untuk dipindahkan dari instans Azure Database Anda, atur titik akhir ke server lokal Anda dan semua transaksi yang tersisa dari instans Azure Anda akan direplikasi ke lokal Anda tanpa meninggalkan data yang terlewatkan ke Anda di- server utama.

Menangani Batasan Dengan Database Terkelola Untuk MySQL atau MariaDB di Azure

Menangani keterbatasan terutama saat mengambil dump cadangan dari kumpulan data Anda harus 100% akurat sejak Anda mengambil dump cadangan. Tentu saja, ini adalah migrasi ideal ke lokal Anda. Untuk mengatasinya, pengaturan arsitektur terbaik adalah memiliki topologi replikasi di Database Azure Anda.

Setelah Anda memilikinya dan siap untuk migrasi, mysqldump/mysqlpump atau mydumper harus menggunakan replika Azure Database sebagai sumbernya. Dalam replika Azure Database tersebut, pastikan SQL_THREAD dihentikan sehingga Anda dapat memotret atau merekam MASTER_LOG_FILE dan EXEC_MASTER_LOG_POS yang benar dari hasil SHOW SLAVE STATUS.

Tentu saja, setelah pencadangan selesai, jangan lupa untuk memulai replika Azure Database Anda untuk memulai utas replikasinya lagi.

Periksa Perbedaan Data

Setelah data Anda dimuat atau dibuang ke server lokal Anda yang bertindak sebagai replika dari instans Azure Database, Anda harus memeriksa ulang ini dengan menjalankan penghitungan checksum untuk menentukan seberapa jauh data Anda bertentangan dengan sumber Azure Database. Kami menyarankan Anda menggunakan alat pt-table-checksum dari Percona Toolkit, tetapi Anda dapat membuatnya sendiri dengan menggunakan alat checksumming seperti md5 atau sha256 tetapi ini membutuhkan waktu untuk dilakukan. Selain itu, menggunakan pt-upgrade dari Percona Toolkit juga dapat membantu setelah migrasi data Anda menggunakan pendekatan replikasi ini selesai.

Kesimpulan

Batasan hak istimewa dan jenis yang tidak didukung dari Azure Database dapat menjadi tantangan, tetapi dengan aliran dan arsitektur yang sesuai, bukan tidak mungkin untuk bermigrasi dari database yang dikelola sepenuhnya secara lokal. Yang perlu Anda lakukan hanyalah menyiapkan langkah-langkah yang diperlukan, menyiapkan topologi yang diperlukan dari sumber Azure Database Anda, lalu mulai migrasi dari mengambil cadangan, hingga replikasi, dan migrasi total ke lokal Anda.