Di chuyển cơ sở dữ liệu Azure cho MySQL / MariaDB sang máy chủ On-Prem

Di chuyển cơ sở dữ liệu có thể đặt ra những thách thức lớn khi bạn cân nhắc cách bắt đầu, sử dụng công cụ nào và làm thế nào để di chuyển toàn bộ cơ sở dữ liệu thành công. Trước đó, chúng tôi đã liệt kê nguồn mở hàng đầu mà bạn có thể sử dụng khi di chuyển cho MySQL hoặc MariaDB. Trong blog này, chúng tôi sẽ chỉ cho bạn cách di chuyển dữ liệu từ Cơ sở dữ liệu Microsoft Azure cho MySQL hoặc MariaDB.

Microsoft Azure hiện được biết đến là đối thủ chống lại hai gã khổng lồ công nghệ đám mây khác:AWS và Google Cloud. Nó chuyên sâu hơn về các sản phẩm của Microsoft, đặc biệt là cơ sở dữ liệu độc quyền MSSQL do họ phát triển. Nhưng không chỉ vậy, nó còn có các nguồn mở là một trong những cơ sở dữ liệu dịch vụ được quản lý hoàn toàn của họ để chào bán công khai. Trong số các cơ sở dữ liệu được hỗ trợ có MySQL và MariaDB.

Chuyển ra khỏi Cơ sở dữ liệu Azure cho MySQL / MariaDB có thể tẻ nhạt nhưng nó phụ thuộc vào loại kiến trúc và loại tập dữ liệu bạn đã lưu trữ trong Azure với tư cách là nhà cung cấp đám mây hiện tại của bạn. Với các công cụ phù hợp, nó có thể đạt được và có thể thực hiện toàn bộ quá trình di chuyển.

Chúng tôi sẽ tập trung vào các công cụ mà chúng tôi có thể sử dụng để di chuyển dữ liệu trên MySQL hoặc MariaDB. Đối với blog này, tôi đang sử dụng RHEL / CentOS để cài đặt các gói cần thiết. Hãy xem xét và xác định các bước và thủ tục về cách thực hiện việc này.

Di chuyển từ Cơ sở dữ liệu Azure cho MySQL hoặc MariaDB

Cách tiếp cận điển hình để di chuyển dữ liệu của bạn từ Cơ sở dữ liệu Azure sang máy chủ tại chỗ là sao lưu bằng bản sao hợp lý. Điều này có thể được thực hiện bằng cách sử dụng các giải pháp tiện ích sao lưu tương thích để hoạt động với Cơ sở dữ liệu Azure cho MySQL hoặc MariaDB, là một dịch vụ được quản lý hoàn toàn. Các dịch vụ cơ sở dữ liệu được quản lý hoàn toàn không cung cấp thông tin đăng nhập SSH nên bản sao lưu vật lý không phải là một tùy chọn.

Trước khi bạn có thể di chuyển hoặc kết xuất cơ sở dữ liệu hiện có của mình khỏi Azure, bạn phải lưu ý những điều sau.

Các trường hợp sử dụng phổ biến để đổ và khôi phục ngay khi bắt đầu

Các trường hợp sử dụng phổ biến nhất là:

Sử dụng sao lưu hợp lý (chẳng hạn như mysqldump, mysqlpump hoặc mydumper / myloader) và khôi phục là lựa chọn duy nhất. Cơ sở dữ liệu Azure cho MySQL hoặc MariaDB không hỗ trợ truy cập vật lý vào bộ nhớ vật lý vì đây là dịch vụ cơ sở dữ liệu được quản lý hoàn toàn.
Chỉ hỗ trợ các công cụ lưu trữ InnoDB và Bộ nhớ. Di chuyển từ các công cụ lưu trữ thay thế sang InnoDB. Cơ sở dữ liệu Azure cho MySQL hoặc MariaDB chỉ hỗ trợ công cụ lưu trữ InnoDB và do đó không hỗ trợ công cụ lưu trữ thay thế. Nếu các bảng của bạn được định cấu hình bằng các công cụ lưu trữ khác, hãy chuyển đổi chúng thành định dạng công cụ InnoDB trước khi chuyển sang Cơ sở dữ liệu Azure cho MySQL.
Ví dụ:nếu bạn có WordPress hoặc WebApp sử dụng bảng MyISAM, trước tiên hãy chuyển đổi các bảng đó bằng cách chuyển sang định dạng InnoDB trước khi khôi phục vào Cơ sở dữ liệu Azure cho MySQL. Sử dụng mệnh đề ENGINE =InnoDB để đặt công cụ được sử dụng khi tạo bảng mới, sau đó chuyển dữ liệu vào bảng tương thích trước khi khôi phục.
Nếu Cơ sở dữ liệu Azure nguồn của bạn là một phiên bản cụ thể, thì máy chủ tại chỗ đích của bạn cũng có cùng phiên bản với Cơ sở dữ liệu Azure nguồn.

Vì vậy, với những hạn chế này, bạn chỉ mong đợi rằng dữ liệu của bạn từ Azure phải là công cụ lưu trữ InnoDB hoặc Bộ nhớ, nếu có như vậy trong tập dữ liệu của bạn.

Cân nhắc về Hiệu suất để Sao lưu lôgic từ Cơ sở dữ liệu Azure

Cách duy nhất để sao lưu hợp lý với Azure là sử dụng mysqldump hoặc mysqlpump. Để tối ưu hóa hiệu suất khi thực hiện kết xuất bằng cách sử dụng các công cụ này, hãy lưu ý đến những cân nhắc sau khi kết xuất cơ sở dữ liệu lớn:

Sử dụng tùy chọn loại trừ kích hoạt trong mysqldump khi kết xuất cơ sở dữ liệu. Loại trừ trình kích hoạt khỏi tệp kết xuất để tránh các lệnh kích hoạt kích hoạt trong quá trình khôi phục dữ liệu.
Sử dụng tùy chọn giao dịch đơn để đặt chế độ cách ly giao dịch thành REPEATABLE READ và gửi câu lệnh SQL START TRANSACTION tới máy chủ trước khi kết xuất dữ liệu. Việc kết xuất nhiều bảng trong một giao dịch duy nhất sẽ làm tiêu tốn thêm một số dung lượng lưu trữ trong quá trình khôi phục. Tùy chọn giao dịch đơn và tùy chọn bảng khóa loại trừ lẫn nhau vì BẢNG KHÓA khiến mọi giao dịch đang chờ xử lý được cam kết ngầm. Để kết xuất các bảng lớn, hãy kết hợp tùy chọn một giao dịch với tùy chọn nhanh.
Sử dụng cú pháp chèn nhiều hàng mở rộng bao gồm một số danh sách VALUE. Điều này dẫn đến tệp kết xuất nhỏ hơn và tăng tốc độ chèn khi tệp được tải lại.
Sử dụng tùy chọn theo thứ tự chính trong mysqldump khi kết xuất cơ sở dữ liệu để dữ liệu được viết theo thứ tự khóa chính.
Sử dụng tùy chọn vô hiệu hóa khóa trong mysqldump khi kết xuất dữ liệu, để vô hiệu hóa các ràng buộc khóa ngoại trước khi tải. Việc vô hiệu hóa kiểm tra khóa ngoại sẽ mang lại hiệu suất tăng. Bật các ràng buộc và xác minh dữ liệu sau khi tải để đảm bảo tính toàn vẹn của tham chiếu.
Sử dụng các bảng được phân vùng khi thích hợp.
Tải dữ liệu song song. Tránh sử dụng song song quá nhiều có thể khiến bạn đạt đến giới hạn tài nguyên và theo dõi tài nguyên bằng cách sử dụng các chỉ số có sẵn trong cổng Azure.
Sử dụng tùy chọn defer-table-indexes trong mysqlpump khi kết xuất cơ sở dữ liệu, để quá trình tạo chỉ mục diễn ra sau khi dữ liệu của bảng được tải.
Sử dụng tùy chọn bỏ qua định nghĩa trong mysqlpump để bỏ qua các mệnh đề định nghĩa và SQL SECURITY khỏi các câu lệnh tạo cho các dạng xem và các thủ tục được lưu trữ. Khi bạn tải lại tệp kết xuất, tệp sẽ tạo ra các đối tượng sử dụng các giá trị DEFINER và SQL SECURITY mặc định.
Sao chép các tệp sao lưu vào Azure blob / store và thực hiện khôi phục từ đó, việc này sẽ nhanh hơn rất nhiều so với thực hiện khôi phục trên Internet.

Không được hỗ trợ

Những điều sau không được hỗ trợ:

Vai trò DBA:Bị hạn chế. Ngoài ra, bạn có thể sử dụng người dùng quản trị viên (được tạo trong quá trình tạo máy chủ mới), cho phép bạn thực hiện hầu hết các câu lệnh DDL và DML.
SUPER đặc quyền:Tương tự, SUPER đặc quyền cũng bị hạn chế.
DEFINER:Yêu cầu siêu đặc quyền để tạo và bị hạn chế. Nếu nhập dữ liệu bằng bản sao lưu, hãy xóa các lệnh CREATE DEFINER theo cách thủ công hoặc bằng cách sử dụng lệnh --skip-definer khi thực hiện mysqldump.
Cơ sở dữ liệu hệ thống:Cơ sở dữ liệu hệ thống mysql ở chế độ chỉ đọc và được sử dụng để hỗ trợ các chức năng PaaS khác nhau. Bạn không thể thay đổi cơ sở dữ liệu hệ thống mysql.
CHỌN ... VÀO OUTFILE:Không được hỗ trợ trong dịch vụ.

Sử dụng mysqldump

Sử dụng mysqldump phải được cài đặt trong nút cơ sở dữ liệu mục tiêu của bạn nằm tại chỗ. Nó phải được chuẩn bị như một bản sao của nút Cơ sở dữ liệu Azure để tất cả các giao dịch tiếp theo sẽ được sao chép sang nút. Để thực hiện việc này, hãy làm theo các bước bên dưới.

Cài đặt mysqldump

Chuẩn bị kho lưu trữ.

# Đối với MySQL

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

# Đối với MariaDB

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

Cài đặt gói mysql-client

# Đối với MySQL

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

# Dành cho MariaDB

$ yum install -y MariaDB-client

Tạo kết xuất dữ liệu bằng mysqldump bằng cách thực thi nó bên trong nút đích.

$ 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

Cài đặt Máy chủ MySQL / MariaDB trong nút cơ sở dữ liệu đích

# Đối với MySQL

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

# Đối với MariaDB

$ yum install MariaDB-server.x86_64

Thiết lập phiên bản Máy chủ MySQL / MariaDB (my.cnf, quyền tệp, thư mục) và khởi động máy chủ

# Thiết lập my.cnf (sử dụng triển khai my.cnf của 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

## Đặt lại thư mục dữ liệu và cài đặt lại các tệp hệ thống cơ sở dữ liệu

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

## Tạo thư mục nhật ký

$ mkdir /var/log/mysql

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

## Đối với MySQL

$ mysqld --initialize

## Đối với MariaDB

$ mysql_install_db

Khởi động MySQL / MariaDB Server

## Đối với MySQL

$ systemctl start mysqld

## Dành cho MariaDB

$ systemctl start mariadb

Tải kết xuất dữ liệu mà chúng tôi đã lấy từ Cơ sở dữ liệu Azure vào nút cơ sở dữ liệu đích tại chỗ

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

Tạo người dùng sao chép từ nút nguồn Cơ sở dữ liệu Azure của bạn

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

Đảm bảo rằng bạn thay đổi địa chỉ IP của địa chỉ IP của nút đích làm ứng dụng khách để kết nối.

Thiết lập Máy chủ MySQL / MariaDB làm bản sao / nô lệ của nút nguồn Cơ sở dữ liệu Azure

## Trước tiên, hãy tìm kiếm hoặc định vị lệnh 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;

## Chạy câu lệnh CHANGE MASTER nhưng thêm người dùng / mật khẩu sao chép và tên máy chủ như sau,

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

## Trong một số trường hợp, bạn có thể phải bỏ qua lược đồ mysql. Chạy câu lệnh sau:

SET GLOBAL replicate_wild_ignore_table='mysql.%';

## Sau đó, bắt đầu chuỗi phụ

START SLAVE;

## Kiểm tra trạng thái nô lệ.

SHOW SLAVE STATUS \G

Bây giờ chúng tôi cuối cùng đã có thể sao chép từ Cơ sở dữ liệu Azure cho MySQL / MariaDB làm nguồn bản sao của bạn được đặt tại chỗ.

Sử dụng mydumper

Cơ sở dữ liệu Azure cho MySQL hoặc MariaDB trên thực tế gợi ý rằng việc sử dụng mydumper đặc biệt cho các bản sao lưu lớn như 1TB có thể là lựa chọn thay thế của bạn. Nó cung cấp khả năng song song và tốc độ khi lấy bản sao lưu hoặc sao lưu tập dữ liệu của bạn từ một nút Cơ sở dữ liệu Azure nguồn.

Làm theo các bước bên dưới từ cài đặt bộ đệm tôi đến tải bộ đệm lên máy chủ tại chỗ đích của bạn.

Cài đặt hệ nhị phân. Các mã nhị phân có thể được đặt tại đây 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

Sao lưu từ nút nguồn Cơ sở dữ liệu Azure. Ví dụ:

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

….

Như bạn thấy, có một hạn chế khi sao lưu từ cơ sở dữ liệu được quản lý như Azure. Bạn có thể nhận thấy,

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

Điều này là do, SUPER PRIVILEGE không được hỗ trợ hoặc hạn chế. Tốt nhất, lựa chọn tốt nhất để thực hiện việc này là sao lưu từ một bản sao của Cơ sở dữ liệu Azure của bạn. Chúng ta sẽ nói về vấn đề này sau.

Tại thời điểm này, mydumper sẽ lấy các tệp sao lưu ở dạng tệp * .gz

Tải nó vào máy chủ tại chỗ đích của bạn

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

…

….

Thiết lập nút đích dưới dạng nô lệ / bản sao. mydumper sẽ bao gồm một tệp có tên là siêu dữ liệu bao gồm các tọa độ nhật ký nhị phân bao gồm các vị trí GTID, ví dụ:

$ 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

## Sau đó chạy thay đổi tổng thể từ bản sao hoặc nút cơ sở dữ liệu MySQL / MariaDB đích đích của bạn

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

## Bắt đầu nô lệ

START SLAVE;

Tại thời điểm này, bạn đã sao chép từ một phiên bản Cơ sở dữ liệu Azure đang chạy MySQL / MariaDB. Khi ứng dụng của bạn đã sẵn sàng để di chuyển khỏi phiên bản Cơ sở dữ liệu Azure của bạn, hãy thiết lập điểm cuối đi tới máy chủ tại chỗ của bạn và tất cả các giao dịch còn lại từ phiên bản Azure của bạn sẽ được sao chép sang phiên bản tại chỗ của bạn để không bỏ sót dữ liệu nào đến máy chủ tại chỗ của bạn máy chủ tiền sẵn.

Xử lý các hạn chế với Cơ sở dữ liệu được quản lý cho MySQL hoặc MariaDB trong Azure

Xử lý các hạn chế, đặc biệt là khi lấy bản sao lưu tập dữ liệu của bạn phải chính xác 100% kể từ thời điểm bạn lấy bản sao lưu. Tất nhiên, đây là một sự di chuyển lý tưởng đến cơ sở của bạn. Để giải quyết vấn đề này, thiết lập kiến trúc tốt nhất là có một cấu trúc liên kết nhân bản trong Cơ sở dữ liệu Azure của bạn.

Khi bạn đã có nó và sẵn sàng để di chuyển, mysqldump / mysqlpump hoặc mydumper phải sử dụng bản sao Cơ sở dữ liệu Azure làm nguồn của nó. Trong bản sao Cơ sở dữ liệu Azure đó, hãy đảm bảo rằng SQL_THREAD được dừng lại để bạn có thể chụp nhanh hoặc ghi lại MASTER_LOG_FILE và EXEC_MASTER_LOG_POS chính xác từ kết quả của TÌNH TRẠNG SÓNG CHẬM.

Tất nhiên, sau khi sao lưu đã được thực hiện xong, đừng quên khởi động bản sao Cơ sở dữ liệu Azure của bạn để bắt đầu lại các chuỗi sao chép của nó.

Kiểm tra sự khác biệt về dữ liệu

Khi bạn đã tải hoặc kết xuất dữ liệu của mình tới máy chủ tại chỗ của mình, hoạt động như một bản sao từ phiên bản Cơ sở dữ liệu Azure, bạn nên kiểm tra lại điều này bằng cách chạy các phép tính tổng kiểm tra để xác định xem dữ liệu của bạn ở mức độ nào so với nguồn Cơ sở dữ liệu Azure. Chúng tôi khuyên bạn nên sử dụng công cụ pt-table-checksum từ Bộ công cụ Percona, nhưng bạn có thể tạo công cụ của riêng mình bằng cách sử dụng các công cụ tổng kiểm tra như md5 hoặc sha256 nhưng điều này cần thời gian để thực hiện. Ngoài ra, việc sử dụng nâng cấp pt từ Bộ công cụ Percona cũng có thể hữu ích sau khi quá trình di chuyển dữ liệu của bạn bằng cách sử dụng phương pháp sao chép này được thực hiện xong.

Kết luận

Các hạn chế về đặc quyền và các loại không được hỗ trợ từ Cơ sở dữ liệu Azure có thể là một thách thức nhưng với quy trình và kiến trúc phù hợp, việc di chuyển từ cơ sở dữ liệu được quản lý đầy đủ sẽ không phải là điều bất khả thi. Tất cả những gì bạn cần làm là chuẩn bị các bước cần thiết, thiết lập cấu trúc liên kết bắt buộc từ nguồn Cơ sở dữ liệu Azure của bạn, sau đó bắt đầu di chuyển từ sao lưu, sang sao chép và di chuyển toàn bộ đến cơ sở của bạn.