Những sai lầm hàng đầu cần tránh trong MySQL Replication

Thiết lập sao chép trong MySQL rất dễ dàng, nhưng quản lý nó trong sản xuất chưa bao giờ là một nhiệm vụ dễ dàng. Ngay cả với định vị tự động GTID mới hơn, nó vẫn có thể gặp trục trặc nếu bạn không biết mình đang làm gì. Sau khi thiết lập nhân rộng, tất cả mọi thứ có thể gặp trục trặc. Sai lầm có thể dễ dàng mắc phải và có thể dẫn đến một kết cục thảm hại cho dữ liệu của bạn.

Bài đăng này sẽ nêu bật một số lỗi phổ biến nhất thường mắc phải với sao chép MySQL và cách bạn có thể ngăn chặn chúng.

Thiết lập bản sao

Khi thiết lập bản sao MySQL, bạn cần kết hợp các nút nô lệ với tập dữ liệu từ chính. Với các giải pháp như Galera cluster, điều này sẽ tự động được xử lý cho bạn với phương pháp bạn chọn. Để sao chép MySQL, bạn cần phải tự mình thực hiện việc này, vì vậy đương nhiên bạn phải sử dụng công cụ sao lưu tiêu chuẩn của mình.

Đối với MySQL, có sẵn rất nhiều công cụ sao lưu, nhưng công cụ được sử dụng phổ biến nhất là mysqldump. Mysqldump xuất ra một bản sao lưu hợp lý của tập dữ liệu của tổng thể của bạn. Điều này có nghĩa là bản sao của dữ liệu sẽ không phải là một bản sao nhị phân, mà là một tệp lớn chứa các truy vấn để tạo lại tập dữ liệu của bạn. Trong hầu hết các trường hợp, điều này sẽ cung cấp cho bạn một bản sao (gần) giống hệt dữ liệu của bạn, nhưng có những trường hợp thì không - do kết xuất trên cơ sở từng đối tượng. Điều này có nghĩa là ngay cả trước khi bạn bắt đầu sao chép dữ liệu, tập dữ liệu của bạn không giống với tập dữ liệu trên trang cái.

Có một số chỉnh sửa bạn có thể thực hiện để làm cho mysqldump đáng tin cậy hơn như kết xuất dưới dạng một giao dịch duy nhất và cũng đừng quên bao gồm các quy trình và trình kích hoạt:

mysqldump -uuser -ppass --single-transaction --routines --triggers --all-databases > dumpfile.sql

Một phương pháp hay là kiểm tra xem nút phụ của bạn có giống nhau 100% hay không bằng cách sử dụng pt-table-checksum sau khi thiết lập bản sao:

pt-table-checksum --replicate=test.checksums --ignore-databases mysql h=localhost,u=user,p=pass

Công cụ này sẽ tính toán tổng tổng cho mỗi bảng trên cái chính, sao chép lệnh tới nút phụ và sau đó nút phụ sẽ thực hiện thao tác tổng kiểm tương tự. Nếu bất kỳ bảng nào không giống nhau, điều này sẽ hiển thị rõ ràng trong bảng tổng kiểm tra.

Sử dụng phương pháp sao chép sai

Phương thức sao chép mặc định của MySQL được gọi là sao chép dựa trên câu lệnh. Phương thức này chính xác là như thế nào:một luồng sao chép của mọi câu lệnh chạy trên bản chính sẽ được phát lại trên nút nô lệ. Vì bản thân MySQL là đa luồng nhưng nó là bản sao (truyền thống) thì không, thứ tự các câu lệnh trong luồng nhân bản có thể không giống nhau 100%. Ngoài ra, việc phát lại một câu lệnh có thể cho các kết quả khác nhau khi không được thực thi vào cùng một thời điểm.

Điều này có thể dẫn đến các bộ dữ liệu khác nhau giữa chính và phụ, do dữ liệu bị trôi dạt. Đây không phải là vấn đề trong nhiều năm, vì không có nhiều người chạy MySQL với nhiều luồng đồng thời, nhưng với kiến ​​trúc đa CPU hiện đại, điều này thực sự có thể xảy ra với khối lượng công việc bình thường hàng ngày.

Câu trả lời từ MySQL là cái gọi là sao chép dựa trên hàng. Sao chép dựa trên hàng sẽ sao chép dữ liệu bất cứ khi nào có thể, nhưng trong một số trường hợp ngoại lệ vẫn sử dụng các câu lệnh. Một ví dụ điển hình là thay đổi DLL của một bảng, trong đó bản sao sẽ phải sao chép mọi hàng trong bảng thông qua sao chép. Vì điều này là không hiệu quả, một tuyên bố như vậy sẽ được lặp lại theo cách truyền thống. Khi sao chép dựa trên hàng phát hiện ra sự trôi dạt dữ liệu, nó sẽ dừng chuỗi phụ để ngăn chặn việc làm cho mọi thứ trở nên tồi tệ hơn.

Sau đó, có một phương pháp ở giữa hai phương thức này:sao chép chế độ hỗn hợp. Loại sao chép này sẽ luôn sao chép các câu lệnh, ngoại trừ khi truy vấn chứa hàm UUID (), các trình kích hoạt, thủ tục được lưu trữ, UDF và một số ngoại lệ khác được sử dụng. Chế độ hỗn hợp sẽ không giải quyết được vấn đề trôi dạt dữ liệu và nên tránh việc sao chép dựa trên câu lệnh.

Sao chép vòng tròn

Việc chạy bản sao MySQL với multi-master thường là cần thiết nếu bạn có môi trường nhiều trung tâm dữ liệu. Vì ứng dụng không thể đợi bản chính trong trung tâm dữ liệu khác xác nhận bài viết của bạn, nên ưu tiên ứng dụng chính cục bộ. Thông thường, độ lệch tăng dần tự động được sử dụng để ngăn xung đột dữ liệu giữa các bản gốc. Việc để hai bậc thầy thực hiện ghi cho nhau theo cách này là một giải pháp được chấp nhận rộng rãi.

Tuy nhiên, nếu bạn cần ghi vào nhiều trung tâm dữ liệu vào cùng một cơ sở dữ liệu, bạn sẽ có nhiều bản gốc cần ghi dữ liệu của chúng cho nhau. Trước MySQL 5.7.6, không có phương pháp nào để thực hiện sao chép kiểu lưới, vì vậy giải pháp thay thế sẽ là sử dụng sao chép vòng tròn thay thế.

Sao chép vòng trong MySQL có vấn đề vì những lý do sau:độ trễ, tính khả dụng cao và sự trôi dạt dữ liệu. Ghi một số dữ liệu vào máy chủ A, sẽ mất ba bước để kết thúc trên máy chủ D (thông qua máy chủ B và C). Vì bản sao MySQL (truyền thống) là một luồng, nên bất kỳ truy vấn nào đang chạy lâu trong bản sao có thể làm ngưng trệ toàn bộ vòng lặp. Ngoài ra, nếu bất kỳ máy chủ nào gặp sự cố, vòng đệm sẽ bị hỏng và hiện tại không có phần mềm chuyển đổi dự phòng nào có thể sửa chữa cấu trúc vòng. Sau đó, sự trôi dạt dữ liệu có thể xảy ra khi dữ liệu được ghi vào máy chủ A và được thay đổi cùng lúc trên máy chủ C hoặc D.

Nói chung, sao chép vòng tròn không phù hợp với MySQL và nó nên được tránh bằng mọi giá. Galera sẽ là một lựa chọn thay thế tốt cho việc viết nhiều trung tâm dữ liệu, vì nó đã được thiết kế với ý nghĩ đó.

Ngăn sao chép của bạn bằng các bản cập nhật lớn

Thông thường, các công việc hàng loạt của công việc quản lý nhà sẽ thực hiện nhiều tác vụ khác nhau, từ dọn dẹp dữ liệu cũ cho đến tính toán mức trung bình của lượt "thích" được lấy từ một nguồn khác. Điều này có nghĩa là trong những khoảng thời gian đã định, một công việc sẽ tạo ra rất nhiều hoạt động cơ sở dữ liệu và rất có thể, ghi nhiều dữ liệu trở lại cơ sở dữ liệu. Đương nhiên, điều này có nghĩa là hoạt động trong luồng nhân rộng sẽ tăng như nhau.

Sao chép dựa trên câu lệnh sẽ sao chép các truy vấn chính xác được sử dụng trong các công việc hàng loạt, vì vậy nếu truy vấn mất nửa giờ để xử lý trên bản chính, thì luồng phụ sẽ bị dừng ít nhất trong cùng một khoảng thời gian. Điều này có nghĩa là không có dữ liệu nào khác có thể sao chép và các nút phụ sẽ bắt đầu tụt hậu so với nút chính. Nếu điều này vượt quá ngưỡng của công cụ chuyển đổi dự phòng hoặc proxy của bạn, nó có thể làm rớt các nút phụ này khỏi các nút có sẵn trong cụm. Nếu bạn đang sử dụng sao chép dựa trên câu lệnh, bạn có thể ngăn chặn điều này bằng cách thu thập dữ liệu cho công việc của mình thành các lô nhỏ hơn.

Bây giờ bạn có thể nghĩ rằng việc sao chép dựa trên hàng không bị ảnh hưởng bởi điều này, vì nó sẽ sao chép thông tin hàng thay vì truy vấn. Điều này đúng một phần, đối với các thay đổi DDL, bản sao sẽ quay trở lại định dạng dựa trên câu lệnh. Ngoài ra, số lượng lớn các hoạt động CRUD sẽ ảnh hưởng đến luồng sao chép:trong hầu hết các trường hợp, đây vẫn là một hoạt động luồng đơn và do đó mọi giao dịch sẽ đợi giao dịch trước đó được phát lại thông qua nhân bản. Điều này có nghĩa là nếu bạn có tính đồng thời cao trên master, thì slave có thể bị đình trệ do quá tải các giao dịch trong quá trình sao chép.

Để giải quyết vấn đề này, cả MariaDB và MySQL đều cung cấp bản sao song song. Việc triển khai có thể khác nhau tùy theo nhà cung cấp và phiên bản. MySQL 5.6 cung cấp sao chép song song miễn là các truy vấn được phân tách bằng lược đồ. MariaDB 10.0 và MySQL 5.7 đều có thể xử lý sao chép song song trên các lược đồ, nhưng có các ranh giới khác. Việc thực thi các truy vấn thông qua các chuỗi nô lệ song song có thể tăng tốc luồng sao chép của bạn nếu bạn viết nhiều. Tuy nhiên, nếu không, tốt nhất bạn nên sử dụng cách sao chép đơn luồng truyền thống.

Thay đổi giản đồ

Thực hiện các thay đổi giản đồ trên một thiết lập sản xuất đang chạy luôn là một vấn đề khó khăn. Điều này liên quan đến thực tế là phần lớn thời gian thay đổi DDL sẽ khóa một bảng và chỉ giải phóng khóa này khi thay đổi DDL đã được áp dụng. Nó thậm chí còn trở nên tồi tệ hơn khi bạn bắt đầu sao chép những thay đổi DDL này thông qua nhân bản MySQL, nơi nó cũng sẽ làm ngưng trệ luồng nhân bản.

Một giải pháp thường được sử dụng là áp dụng thay đổi lược đồ cho các nút phụ trước. Đối với sao chép dựa trên câu lệnh, điều này hoạt động tốt, nhưng đối với sao chép dựa trên hàng, điều này có thể hoạt động ở một mức độ nhất định. Sao chép dựa trên hàng cho phép các cột thừa tồn tại ở cuối bảng, vì vậy, miễn là nó có thể viết các cột đầu tiên là được. Đầu tiên áp dụng thay đổi cho tất cả các nô lệ, sau đó chuyển đổi dự phòng cho một trong các nô lệ và sau đó áp dụng thay đổi cho chủ nhân và đính kèm thay đổi đó như một nô lệ. Nếu thay đổi của bạn liên quan đến việc chèn một cột vào giữa hoặc xóa một cột, điều này sẽ hoạt động với tính năng sao chép dựa trên hàng.

Có những công cụ xung quanh có thể thực hiện các thay đổi giản đồ trực tuyến một cách đáng tin cậy hơn. Percona Online Schema Change (còn được gọi là pt-osc) sẽ tạo một bảng bóng với cấu trúc bảng mới, chèn dữ liệu mới thông qua trình kích hoạt và chèn lấp dữ liệu trong nền. Sau khi hoàn tất việc tạo bảng mới, nó sẽ chỉ cần hoán đổi bảng cũ cho bảng mới trong một giao dịch. Điều này không hoạt động trong mọi trường hợp, đặc biệt nếu bảng hiện tại của bạn đã có trình kích hoạt.

Một giải pháp thay thế là công cụ Gh-ost mới của Github. Công cụ thay đổi giản đồ trực tuyến này trước tiên sẽ tạo một bản sao của bố cục bảng hiện có của bạn, thay đổi bảng thành bố cục mới và sau đó kết nối quy trình như một bản sao MySQL. Nó sẽ sử dụng luồng nhân bản để tìm các hàng mới đã được chèn vào bảng ban đầu và đồng thời nó sẽ lấp đầy bảng. Sau khi hoàn tất việc lấp đầy, bảng ban đầu và bảng mới sẽ chuyển đổi. Đương nhiên, tất cả các hoạt động đối với bảng mới cũng sẽ kết thúc trong luồng sao chép, do đó trên mỗi bản sao, việc di chuyển diễn ra cùng một lúc.

Bảng bộ nhớ và sao chép

Trong khi chúng ta đang nói về chủ đề DDL, một vấn đề phổ biến là việc tạo các bảng bộ nhớ. Bảng bộ nhớ là bảng không liên tục, cấu trúc bảng của chúng vẫn còn nhưng chúng bị mất dữ liệu sau khi khởi động lại MySQL. Khi tạo một bảng bộ nhớ mới trên cả master và slave, cả hai sẽ có một bảng trống và điều này sẽ hoạt động hoàn toàn tốt. Sau khi một trong hai được khởi động lại, bảng sẽ bị trống và lỗi sao chép sẽ xảy ra.

Sao chép dựa trên hàng sẽ bị hỏng khi dữ liệu trong nút phụ trả về các kết quả khác nhau và sao chép dựa trên câu lệnh sẽ bị hỏng khi nó cố gắng chèn dữ liệu đã tồn tại. Đối với bảng bộ nhớ, đây là một bộ ngắt sao chép thường xuyên. Cách khắc phục rất dễ dàng:chỉ cần tạo một bản sao mới của dữ liệu, thay đổi công cụ thành InnoDB và bây giờ nó sẽ an toàn sao chép.

Đặt biến read_only thành True

Như chúng ta đã mô tả trước đó, việc không có cùng dữ liệu trong các nút nô lệ có thể phá vỡ quá trình sao chép. Thường thì điều này là do một cái gì đó (hoặc ai đó) thay đổi dữ liệu trên nút phụ, nhưng không phải trên nút chính. Khi dữ liệu của nút chính bị thay đổi, dữ liệu này sẽ được sao chép sang nút phụ, nơi nó không thể áp dụng thay đổi và điều này khiến quá trình sao chép bị hỏng.

Có một cách dễ dàng ngăn chặn điều này:đặt biến read_only thành true. Điều này sẽ không cho phép bất kỳ ai thực hiện thay đổi đối với dữ liệu, ngoại trừ người sao chép và người dùng root. Hầu hết các trình quản lý chuyển đổi dự phòng tự động đặt cờ này để ngăn người dùng ghi vào bản chính đã sử dụng trong quá trình chuyển đổi dự phòng. Một số người trong số họ thậm chí còn giữ lại điều này sau khi chuyển đổi dự phòng.

Điều này vẫn khiến người dùng root thực hiện một truy vấn CRUD sai trên nút phụ. Để ngăn điều này xảy ra, có một biến super_read_only kể từ MySQL 5.7.8 thậm chí còn khóa người dùng root cập nhật dữ liệu.

Bật GTID

Trong sao chép MySQL, điều cần thiết là bắt đầu nô lệ từ vị trí chính xác trong các bản ghi nhị phân. Có được vị trí này có thể được thực hiện khi tạo bản sao lưu (xtrabackup và mysqldump hỗ trợ điều này) hoặc khi bạn đã ngừng sử dụng nút mà bạn đang tạo bản sao. Bắt đầu sao chép bằng lệnh CHANGE MASTER TO sẽ trông giống như sau:

mysql> CHANGE MASTER TO MASTER_HOST='x.x.x.x',MASTER_USER='replication_user', MASTER_PASSWORD='password', MASTER_LOG_FILE='master-bin.0001', MASTER_LOG_POS=  04;

Bắt đầu sao chép sai chỗ có thể gây ra hậu quả tai hại:dữ liệu có thể bị ghi kép hoặc không được cập nhật. Điều này gây ra sự chênh lệch dữ liệu giữa nút chính và nút phụ.

Ngoài ra, khi thất bại giữa một chủ nhân với một nô lệ liên quan đến việc tìm vị trí chính xác và thay đổi chủ nhân thành máy chủ thích hợp. MySQL không giữ lại các vị trí và nhật ký nhị phân từ cái chính của nó, mà tạo ra các vị trí và nhật ký nhị phân của riêng nó. Đối với việc căn chỉnh lại một nút nô lệ cho nút chính mới, điều này có thể trở thành một vấn đề nghiêm trọng:vị trí chính xác của nút chính khi chuyển đổi dự phòng phải được tìm thấy trên nút chính mới và sau đó tất cả các nô lệ có thể được căn chỉnh lại.

Để giải quyết vấn đề này, Mã định danh giao dịch toàn cầu (GTID) đã được cả Oracle và MariaDB triển khai. GTID cho phép tự động căn chỉnh các nô lệ và trong cả MySQL và MariaDB, máy chủ tự tìm ra vị trí chính xác. Tuy nhiên, cả hai đều đã triển khai GTID theo một cách khác và do đó không tương thích. Nếu bạn cần thiết lập sao chép từ cái này sang cái khác, thì việc nhân rộng phải được thiết lập với định vị nhật ký nhị phân truyền thống. Ngoài ra, phần mềm chuyển đổi dự phòng của bạn cũng nên lưu ý không sử dụng GTID.

Kết luận

Chúng tôi hy vọng đã cung cấp cho bạn đủ mẹo để tránh gặp rắc rối. Đây là tất cả các phương pháp phổ biến của các chuyên gia trong MySQL. Họ đã phải học nó một cách khó khăn và với những mẹo này, chúng tôi đảm bảo bạn không cần phải làm như vậy.

Chúng tôi có một số sách trắng bổ sung có thể hữu ích nếu bạn muốn đọc thêm về sao chép MySQL.