Mysqldump là công cụ sao lưu logic phổ biến nhất cho MySQL. Nó được bao gồm trong bản phân phối MySQL, vì vậy nó đã sẵn sàng để sử dụng trên tất cả các phiên bản MySQL.
Tuy nhiên,Sao lưu logic không phải là cách nhanh nhất và cũng không phải là cách tiết kiệm không gian nhất để sao lưu cơ sở dữ liệu MySQL, nhưng chúng có lợi thế rất lớn so với sao lưu vật lý.
Sao lưu vật lý thường là loại sao lưu toàn bộ hoặc không có gì. Mặc dù có thể tạo bản sao lưu một phần bằng Xtrabackup (chúng tôi đã mô tả điều này trong một trong các bài đăng trên blog trước đây của chúng tôi), nhưng việc khôi phục bản sao lưu như vậy rất phức tạp và tốn thời gian.
Về cơ bản, nếu chúng ta muốn khôi phục một bảng duy nhất, chúng ta phải dừng toàn bộ chuỗi sao chép và thực hiện khôi phục trên tất cả các nút cùng một lúc. Đây là một vấn đề lớn - ngày nay bạn hiếm khi đủ khả năng để dừng tất cả các cơ sở dữ liệu.
Một vấn đề khác là cấp bảng là mức chi tiết thấp nhất mà bạn có thể đạt được với Xtrabackup:bạn có thể khôi phục một bảng nhưng không thể khôi phục một phần của nó. Tuy nhiên, sao lưu lôgic có thể được khôi phục theo cách chạy các câu lệnh SQL, do đó, nó có thể dễ dàng được thực hiện trên một cụm đang chạy và bạn có thể (chúng tôi sẽ không gọi nó là dễ dàng, nhưng vẫn) chọn câu lệnh SQL nào để chạy để bạn có thể thực hiện khôi phục một phần bảng.
Hãy xem cách thực hiện điều này trong thế giới thực.
Khôi phục một bảng MySQL duy nhất bằng mysqldump
Lúc đầu, xin lưu ý rằng các bản sao lưu một phần không cung cấp một cái nhìn nhất quán về dữ liệu. Khi bạn sao lưu các bảng riêng biệt, bạn không thể khôi phục bản sao lưu đó về vị trí đã biết trong thời gian (ví dụ:để cung cấp nô lệ sao chép) ngay cả khi bạn khôi phục tất cả dữ liệu từ bản sao lưu. Có điều này đằng sau chúng ta, hãy tiếp tục.
Chúng ta có một chủ nhân và một nô lệ:
Tập dữ liệu chứa một lược đồ và một số bảng:
mysql> SHOW SCHEMAS;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sbtest |
| sys |
+--------------------+
5 rows in set (0.01 sec)
mysql> SHOW TABLES FROM sbtest;
+------------------+
| Tables_in_sbtest |
+------------------+
| sbtest1 |
| sbtest10 |
| sbtest11 |
| sbtest12 |
| sbtest13 |
| sbtest14 |
| sbtest15 |
| sbtest16 |
| sbtest17 |
| sbtest18 |
| sbtest19 |
| sbtest2 |
| sbtest20 |
| sbtest21 |
| sbtest22 |
| sbtest23 |
| sbtest24 |
| sbtest25 |
| sbtest26 |
| sbtest27 |
| sbtest28 |
| sbtest29 |
| sbtest3 |
| sbtest30 |
| sbtest31 |
| sbtest32 |
| sbtest4 |
| sbtest5 |
| sbtest6 |
| sbtest7 |
| sbtest8 |
| sbtest9 |
+------------------+
32 rows in set (0.00 sec)Bây giờ, chúng ta phải sao lưu. Có một số cách mà chúng ta có thể tiếp cận vấn đề này. Chúng tôi chỉ có thể sao lưu toàn bộ tập dữ liệu nhất quán nhưng điều này sẽ tạo ra một tệp lớn, duy nhất với tất cả dữ liệu. Để khôi phục bảng đơn, chúng tôi sẽ phải trích xuất dữ liệu cho bảng từ tệp đó. Tất nhiên là có thể, nhưng nó khá tốn thời gian và hoạt động thủ công khá nhiều có thể được viết theo tập lệnh nhưng nếu bạn không có tập lệnh phù hợp, việc viết mã đặc biệt khi cơ sở dữ liệu của bạn gặp sự cố và bạn đang phải chịu áp lực rất lớn. không nhất thiết phải là ý tưởng an toàn nhất.
Thay vào đó, chúng ta có thể chuẩn bị sao lưu theo cách mà mọi bảng sẽ được lưu trữ trong một tệp riêng biệt:
[email protected]:~/backup# d=$(date +%Y%m%d) ; db='sbtest'; for tab in $(mysql -uroot -ppass -h127.0.0.1 -e "SHOW TABLES FROM ${db}" | grep -v Tables_in_${db}) ; do mysqldump --set-gtid-purged=OFF --routines --events --triggers ${db} ${tab} > ${d}_${db}.${tab}.sql ; doneXin lưu ý rằng chúng tôi đặt --set-gtid-purged =OFF. Chúng tôi cần nó nếu sau này chúng tôi tải dữ liệu này vào cơ sở dữ liệu. Nếu không, MySQL sẽ cố gắng đặt @@ GLOBAL.GTID_PURGED, rất có thể, sẽ không thành công. MySQL cũng sẽ đặt SET @@ SESSION.SQL_LOG_BIN =0; mà chắc chắn không phải là những gì chúng tôi muốn. Những cài đặt đó là bắt buộc nếu chúng tôi muốn tạo một bản sao lưu nhất quán cho toàn bộ tập dữ liệu và chúng tôi muốn sử dụng nó để cung cấp một nút mới. Trong trường hợp của chúng tôi, chúng tôi biết đó không phải là một bản sao lưu nhất quán và không có cách nào chúng tôi có thể xây dựng lại bất cứ thứ gì từ nó. Tất cả những gì chúng tôi muốn là tạo ra một kết xuất mà chúng tôi có thể tải trên cái chính và để nó sao chép thành nô lệ.
Lệnh đó đã tạo một danh sách đẹp các tệp sql có thể được tải lên cụm sản xuất:
[email protected]:~/backup# ls -alh
total 605M
drwxr-xr-x 2 root root 4.0K Mar 18 14:10 .
drwx------ 9 root root 4.0K Mar 18 14:08 ..
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest10.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest11.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest12.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest13.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest14.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest15.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest16.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest17.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest18.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest19.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest1.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest20.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest21.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest22.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest23.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest24.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest25.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest26.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest27.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest28.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest29.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest2.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest30.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest31.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest32.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest3.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest4.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest5.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest6.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest7.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest8.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest9.sqlKhi bạn muốn khôi phục dữ liệu, tất cả những gì bạn cần làm là tải tệp SQL vào nút chính:
[email protected]:~/backup# mysql -uroot -ppass sbtest < 20200318_sbtest.sbtest11.sqlDữ liệu sẽ được tải vào cơ sở dữ liệu và được sao chép tới tất cả các nô lệ.
Cách khôi phục một bảng MySQL bằng ClusterControl?
Hiện tại ClusterControl không cung cấp cách dễ dàng để khôi phục chỉ một bảng duy nhất nhưng bạn vẫn có thể thực hiện việc đó chỉ với một vài thao tác thủ công. Có hai tùy chọn bạn có thể sử dụng. Đầu tiên, phù hợp với số lượng bảng nhỏ, về cơ bản bạn có thể tạo lịch biểu trong đó bạn thực hiện sao lưu từng phần từng bảng riêng biệt:
Ở đây, chúng tôi đang sao lưu bảng sbtest.sbtest1. Chúng tôi có thể dễ dàng lên lịch sao lưu khác cho bảng sbtest2:
Ngoài ra, chúng ta có thể thực hiện sao lưu và đưa dữ liệu từ một giản đồ vào một tệp riêng biệt:
Bây giờ bạn có thể tìm dữ liệu bị thiếu bằng tay trong tệp, khôi phục sao lưu này vào một máy chủ riêng biệt hoặc để ClusterControl thực hiện:
Bạn duy trì hoạt động của máy chủ và bạn có thể trích xuất dữ liệu mà bạn muốn khôi phục bằng cách sử dụng mysqldump hoặc SELECT… INTO OUTFILE. Dữ liệu được trích xuất như vậy sẽ sẵn sàng được áp dụng trên cụm sản xuất.
