Trong bài trước của tôi, tôi đã giải thích cách tạo một bản sao lưu hợp lý bằng cách sử dụng các tiện ích shell mysql. Trong bài đăng này, chúng tôi sẽ so sánh tốc độ của quá trình sao lưu và khôi phục.
Kiểm tra tốc độ vỏ MySQL
Chúng ta sẽ so sánh tốc độ sao lưu và khôi phục của các công cụ tiện ích shell mysqldump và MySQL.
Các công cụ dưới đây được sử dụng để so sánh tốc độ:
- mysqldump
- use.dumpInstance
- use.loadDump
Cấu hình Phần cứng
Hai máy chủ độc lập có cấu hình giống hệt nhau.
Máy chủ 1
* IP:192.168.33.14
* CPU:2 lõi
* RAM:4 GB
* Đĩa:SSD 200 GB
Máy chủ 2
* IP:192.168.33.15
* CPU:2 lõi
* RAM:4 GB
* Đĩa:SSD 200 GB
Chuẩn bị Khối lượng Công việc
Trên Máy chủ 1 (192.168.33.14), Chúng tôi đã tải khoảng 10 GB dữ liệu.
Bây giờ, Chúng tôi muốn khôi phục dữ liệu từ Máy chủ 1 (192.168.33.14) sang Máy chủ 2 (192.168.33.15).
Thiết lập MySQL
Phiên bản MySQL:8.0.22
Dung lượng bộ đệm InnoDB:1 GB
Dung lượng tệp nhật ký InnoDB:16 MB
Ghi nhật ký nhị phân:Bật
Chúng tôi đã tải 50 triệu bản ghi bằng sysbench.
[[email protected] sysbench]# sysbench oltp_insert.lua --table-size=5000000 --num-threads=8 --rand-type=uniform --db-driver=mysql --mysql-db=sbtest --tables=10 --mysql-user=root --mysql-password=****** prepare
WARNING: --num-threads is deprecated, use --threads instead
sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2)
Initializing worker threads...
Creating table 'sbtest3'...
Creating table 'sbtest4'...
Creating table 'sbtest7'...
Creating table 'sbtest1'...
Creating table 'sbtest2'...
Creating table 'sbtest8'...
Creating table 'sbtest5'...
Creating table 'sbtest6'...
Inserting 5000000 records into 'sbtest1'
Inserting 5000000 records into 'sbtest3'
Inserting 5000000 records into 'sbtest7
.
.
.
Creating a secondary index on 'sbtest9'...
Creating a secondary index on 'sbtest10'...Trường hợp thử nghiệm một
Trong trường hợp này, chúng tôi sẽ thực hiện một bản sao lưu hợp lý bằng cách sử dụng lệnh mysqldump.
Ví dụ
[[email protected] vagrant]# time /usr/bin/mysqldump --defaults-file=/etc/my.cnf --flush-privileges --hex-blob --opt --master-data=2 --single-transaction --triggers --routines --events --set-gtid-purged=OFF --all-databases |gzip -6 -c > /home/vagrant/test/mysqldump_schemaanddata.sql.gzstart_time =2020-11-09 17:40:02
end_time =2020-11-09 37:19:08
Mất gần 20 phút 19 giây để hoàn tất tất cả cơ sở dữ liệu với tổng dung lượng khoảng 10GB.
Trường hợp Thử nghiệm Hai
Bây giờ chúng ta hãy thử với tiện ích MySQL shell. Chúng tôi sẽ sử dụng dumpInstance để tạo một bản sao lưu đầy đủ.
Ví dụ
MySQL localhost:33060+ ssl JS > util.dumpInstance("/home/vagrant/production_backup", {threads: 2, ocimds: true,compatibility: ["strip_restricted_grants"]})
Acquiring global read lock
Global read lock acquired
All transactions have been started
Locking instance for backup
Global read lock has been released
Checking for compatibility with MySQL Database Service 8.0.22
NOTE: Progress information uses estimated values and may not be accurate.
Data dump for table `sbtest`.`sbtest1` will be written to 38 files
Data dump for table `sbtest`.`sbtest10` will be written to 38 files
Data dump for table `sbtest`.`sbtest3` will be written to 38 files
Data dump for table `sbtest`.`sbtest2` will be written to 38 files
Data dump for table `sbtest`.`sbtest4` will be written to 38 files
Data dump for table `sbtest`.`sbtest5` will be written to 38 files
Data dump for table `sbtest`.`sbtest6` will be written to 38 files
Data dump for table `sbtest`.`sbtest7` will be written to 38 files
Data dump for table `sbtest`.`sbtest8` will be written to 38 files
Data dump for table `sbtest`.`sbtest9` will be written to 38 files
2 thds dumping - 36% (17.74M rows / ~48.14M rows), 570.93K rows/s, 111.78 MB/s uncompressed, 50.32 MB/s compressed
1 thds dumping - 100% (50.00M rows / ~48.14M rows), 587.61K rows/s, 115.04 MB/s uncompressed, 51.79 MB/s compressed
Duration: 00:01:27s
Schemas dumped: 3
Tables dumped: 10
Uncompressed data size: 9.78 GB
Compressed data size: 4.41 GB
Compression ratio: 2.2
Rows written: 50000000
Bytes written: 4.41 GB
Average uncompressed throughput: 111.86 MB/s
Average compressed throughput: 50.44 MB/s Mất tổng cộng 1 phút 27 giây để hoàn thành toàn bộ cơ sở dữ liệu (dữ liệu giống như dữ liệu được sử dụng cho mysqldump) và nó cũng cho thấy tiến trình của nó, điều này sẽ thực sự hữu ích để biết được bao nhiêu phần mềm sao lưu đã hoàn thành. Nó cung cấp thời gian cần thiết để thực hiện sao lưu.
Tính song song phụ thuộc vào số lượng lõi trong máy chủ. Việc tăng giá trị một cách thô bạo sẽ không hữu ích trong trường hợp của tôi. (Máy của tôi có 2 lõi).
Kiểm tra tốc độ khôi phục
Trong phần khôi phục, chúng tôi sẽ khôi phục bản sao lưu mysqldump trên một máy chủ độc lập khác. Tệp sao lưu đã được chuyển đến máy chủ đích bằng rsync.
Trường hợp Kiểm tra 1
Ví dụ
[[email protected] vagrant]#time gunzip < /mnt/mysqldump_schemaanddata.sql.gz | mysql -u root -pMất khoảng 16 phút 26 giây để khôi phục 10GB dữ liệu.
Trường hợp thử nghiệm 2
Trong trường hợp này, chúng tôi đang sử dụng tiện ích shell mysql để tải tệp sao lưu trên một máy chủ độc lập khác. Chúng tôi đã chuyển tệp sao lưu đến máy chủ đích. Hãy bắt đầu quá trình khôi phục.
Ví dụ
MySQL localhost:33060+ ssl JS > util.loadDump("/home/vagrant/production_backup", {progressFile :"/home/vagrant/production_backup/log.json",threads :2})
Opening dump...
Target is MySQL 8.0.22. Dump was produced from MySQL 8.0.22
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL script for schema `cluster_control`
Executing DDL script for schema `proxydemo`
Executing DDL script for schema `sbtest`
.
.
.
2 thds loading \ 1% (150.66 MB / 9.78 GB), 6.74 MB/s, 4 / 10 tables done
2 thds loading / 100% (9.79 GB / 9.79 GB), 1.29 MB/s, 10 / 10 tables done
[Worker001] [email protected]@@37.tsv.zst: Records: 131614 Deleted: 0 Skipped: 0 Warnings: 0
[Worker002] [email protected]@@37.tsv.zst: Records: 131614 Deleted: 0 Skipped: 0 Warnings: 0
Executing common postamble SQL
380 chunks (50.00M rows, 9.79 GB) for 10 tables in 2 schemas were loaded in 40 min 6 sec (avg throughput 4.06 MB/s)Mất khoảng 40 phút 6 giây để khôi phục 10GB dữ liệu.
Bây giờ hãy thử tắt nhật ký làm lại và bắt đầu nhập dữ liệu bằng mysql tiện ích shell.
mysql> alter instance disable innodb redo_log;
Query OK, 0 rows affected (0.00 sec)
MySQL localhost:33060+ ssl JS >util.loadDump("/home/vagrant/production_backup", {progressFile :"/home/vagrant/production_backup/log.json",threads :2})
Opening dump...
Target is MySQL 8.0.22. Dump was produced from MySQL 8.0.22
Checking for pre-existing objects...
Executing common preamble SQL
.
.
.
380 chunks (50.00M rows, 9.79 GB) for 10 tables in 3 schemas were loaded in 19 min 56 sec (avg throughput 8.19 MB/s)
0 warnings were reported during the load.Sau khi tắt nhật ký làm lại, thông lượng trung bình đã tăng lên gấp 2 lần.
Lưu ý:Không tắt ghi nhật ký lại trên hệ thống sản xuất. Nó cho phép tắt và khởi động lại máy chủ trong khi quá trình ghi nhật ký bị tắt, nhưng máy chủ ngừng hoạt động không mong muốn trong khi tắt ghi nhật ký lại có thể gây ra mất dữ liệu và hỏng phiên bản.
Bản sao lưu vật lý
Như bạn có thể đã nhận thấy, các phương pháp sao lưu hợp lý, ngay cả khi đa luồng, khá tốn thời gian ngay cả đối với một tập dữ liệu nhỏ mà chúng tôi đã thử nghiệm chúng. Đây là một trong những lý do tại sao ClusterControl cung cấp phương pháp sao lưu vật lý dựa trên việc sao chép các tệp - trong trường hợp đó, chúng tôi không bị giới hạn bởi lớp SQL xử lý sao lưu logic mà là bởi phần cứng - đĩa có thể đọc tệp nhanh như thế nào và tốc độ mạng có thể truyền dữ liệu giữa nút cơ sở dữ liệu và máy chủ sao lưu.
ClusterControl đi kèm với các cách khác nhau để triển khai sao lưu vật lý, phương pháp nào khả dụng sẽ phụ thuộc vào loại cụm và đôi khi thậm chí cả nhà cung cấp. Hãy xem Xtrabackup được thực thi bởi ClusterControl sẽ tạo bản sao lưu toàn bộ dữ liệu trên môi trường thử nghiệm của chúng tôi.
Chúng tôi sẽ tạo một bản sao lưu đặc biệt lần này nhưng ClusterControl cho phép bạn cũng tạo một lịch trình sao lưu đầy đủ.
Ở đây chúng tôi chọn phương thức sao lưu (xtrabackup) cũng như máy chủ lưu trữ của chúng tôi sẽ lấy bản sao lưu từ. Chúng tôi cũng có thể lưu trữ nó cục bộ trên nút hoặc nó có thể được truyền trực tuyến đến một cá thể ClusterControl. Ngoài ra, bạn có thể tải bản sao lưu lên đám mây (AWS, Google Cloud và Azure được hỗ trợ).
Quá trình sao lưu mất khoảng 10 phút để hoàn tất. Đây là nhật ký từ tệp cmon_backup.metadata.
[[email protected] BACKUP-9]# cat cmon_backup.metadata
{
"class_name": "CmonBackupRecord",
"backup_host": "192.168.33.14",
"backup_tool_version": "2.4.21",
"compressed": true,
"created": "2020-11-17T23:37:15.000Z",
"created_by": "",
"db_vendor": "oracle",
"description": "",
"encrypted": false,
"encryption_md5": "",
"finished": "2020-11-17T23:47:47.681Z"
}Bây giờ hãy thử khôi phục tương tự bằng cách sử dụng ClusterControl. ClusterControl> Backup> Restore Backup
Ở đây chúng tôi chọn tùy chọn khôi phục sao lưu, nó sẽ hỗ trợ thời gian và dựa trên nhật ký phục hồi quá.
Ở đây chúng tôi chọn đường dẫn nguồn tệp sao lưu và sau đó là máy chủ đích. Bạn cũng phải đảm bảo có thể truy cập máy chủ này từ nút ClusterControl bằng SSH.
Chúng tôi không muốn ClusterControl thiết lập phần mềm, vì vậy chúng tôi đã tắt tùy chọn đó. Sau khi khôi phục, nó sẽ tiếp tục hoạt động của máy chủ.
Mất khoảng 4 phút 18 giây để khôi phục 10GB dữ liệu. Xtrabackup không khóa cơ sở dữ liệu của bạn trong quá trình sao lưu. Đối với cơ sở dữ liệu lớn (hơn 100 GB), nó cung cấp thời gian khôi phục tốt hơn nhiều so với tiện ích mysqldump / shell. Ngoài ra lusterControl còn hỗ trợ sao lưu và khôi phục một phần như một trong những đồng nghiệp của tôi đã giải thích trong blog của anh ấy:Sao lưu và khôi phục một phần.
Kết luận
Mỗi phương pháp đều có ưu và nhược điểm riêng. Như chúng ta đã thấy, không có một phương pháp nào phù hợp nhất cho mọi thứ mà bạn cần làm. Chúng tôi cần chọn công cụ của mình dựa trên môi trường sản xuất và thời gian mục tiêu để khôi phục.
