Trong Phần I, chúng tôi đã giới thiệu khung Tính sẵn sàng cao (HA) cho lưu trữ MySQL và thảo luận về các thành phần khác nhau và chức năng của chúng. Bây giờ trong Phần II, chúng ta sẽ thảo luận chi tiết về sao chép bán đồng bộ MySQL và các cài đặt cấu hình liên quan giúp chúng ta đảm bảo tính dự phòng và tính nhất quán của dữ liệu trong thiết lập HA của chúng ta. Đảm bảo kiểm tra lại Phần III, nơi chúng tôi sẽ xem xét các tình huống lỗi khác nhau có thể phát sinh và cách khung phản hồi và phục hồi từ các điều kiện này.
Sao chép bán đồng bộ MySQL là gì?
Nói một cách đơn giản, trong cấu hình sao chép bán đồng bộ MySQL, master chỉ cam kết các giao dịch với công cụ lưu trữ sau khi nhận được xác nhận từ ít nhất một trong các nô lệ. Các nô lệ sẽ chỉ cung cấp xác nhận sau khi các sự kiện được nhận và sao chép vào nhật ký chuyển tiếp và cũng được chuyển vào đĩa. Điều này đảm bảo rằng đối với tất cả các giao dịch được cam kết và trả lại cho khách hàng, dữ liệu tồn tại trên ít nhất 2 nút. Thuật ngữ ‘bán’ trong bán đồng bộ (sao chép) là do trình chủ cam kết các giao dịch khi các sự kiện được nhận và chuyển sang nhật ký chuyển tiếp, nhưng không nhất thiết phải cam kết với các tệp dữ liệu trên máy chủ. Điều này trái ngược với sao chép hoàn toàn đồng bộ, trong đó giao dịch sẽ được thực hiện trên cả máy chủ và máy chủ trước khi phiên quay trở lại máy khách.
Sao chép bán đồng bộ, vốn có sẵn trong MySQL, giúp khung HA đảm bảo tính nhất quán và dự phòng dữ liệu cho các giao dịch đã cam kết. Trong trường hợp lỗi chính, tất cả các giao dịch được cam kết trên bản chính sẽ được sao chép tới ít nhất một trong các nô lệ (được lưu vào nhật ký chuyển tiếp). Do đó, việc chuyển đổi dự phòng đối với nô lệ đó sẽ không bị mất dữ liệu vì nô lệ đã được cập nhật (sau khi các bản ghi chuyển tiếp của nô lệ đã hết hoàn toàn).
Sao chép và Cài đặt liên quan bán đồng bộ
Hãy thảo luận về một số cài đặt MySQL chính được sử dụng để đảm bảo hành vi tối ưu cho tính khả dụng cao và tính nhất quán dữ liệu trong khuôn khổ của chúng tôi.
Quản lý tốc độ thực thi của nô lệ
Việc cân nhắc đầu tiên là xử lý hành vi 'bán' của sao chép bán đồng bộ chỉ đảm bảo rằng dữ liệu đã được nhận và chuyển tới nhật ký chuyển tiếp bởi chuỗi I / O của nô lệ, nhưng không nhất thiết phải được cam kết bởi chuỗi SQL. Theo mặc định, luồng SQL trong MySQL slave là một luồng và sẽ không thể bắt kịp với luồng chính là đa luồng. Tác động rõ ràng của điều này là trong trường hợp lỗi chính, máy chủ sẽ không được cập nhật vì luồng SQL của nó vẫn đang xử lý các sự kiện trong bản ghi chuyển tiếp. Điều này sẽ làm trì hoãn quá trình chuyển đổi dự phòng vì khuôn khổ của chúng tôi mong đợi nô lệ được cập nhật đầy đủ trước khi nó có thể được thúc đẩy. Điều này là cần thiết để duy trì tính nhất quán của dữ liệu. Để giải quyết vấn đề này, chúng tôi bật các nô lệ đa luồng với tùy chọn slave_parallel_workers để đặt số lượng các luồng SQL song song để xử lý các sự kiện trong nhật ký chuyển tiếp.
Ngoài ra, chúng tôi định cấu hình các cài đặt bên dưới để đảm bảo rằng máy chủ không vào bất kỳ trạng thái nào mà máy chủ không ở trong:
- nô lệ-song song-loại =LOGICAL_CLOCK
- slave_preserve_commit_order =1
Điều này cung cấp cho chúng tôi tính nhất quán dữ liệu mạnh mẽ hơn. Với các cài đặt này, chúng tôi sẽ có thể có được tốc độ và tốc độ song song tốt hơn trên máy chủ, nhưng nếu có quá nhiều luồng song song, chi phí liên quan đến việc phối hợp giữa các luồng cũng sẽ tăng lên và rất tiếc có thể bù đắp lợi ích.
Một cấu hình khác mà chúng ta có thể sử dụng để tăng hiệu quả thực thi song song trên các nô lệ là điều chỉnh binlog_group_commit_sync_delay trên chính. Bằng cách thiết lập điều này ở chế độ chính, các mục nhật ký nhị phân trên máy chủ và do đó các mục nhật ký chuyển tiếp trên máy phụ sẽ có các lô giao dịch có thể được xử lý song song bởi các luồng SQL. Điều này được giải thích chi tiết trong blog của J-F Gagné, nơi anh ấy gọi hành vi này là ‘ làm chậm chủ để tăng tốc độ nô lệ’ .
Nếu bạn đang quản lý các triển khai MySQL của mình thông qua bảng điều khiển ScaleGrid, bạn có khả năng liên tục theo dõi và nhận cảnh báo theo thời gian thực về độ trễ sao chép của các nô lệ. Nó cũng cho phép bạn tự động điều chỉnh các thông số trên để đảm bảo các nô lệ đang làm việc cùng với chủ, do đó, giảm thiểu thời gian của bạn khi tham gia vào quá trình chuyển đổi dự phòng.
Giải thích về khung tính khả dụng cao của MySQL - Phần IIClick To Tweet
Tùy chọn sao chép bán đồng bộ quan trọng
Sao chép bán đồng bộ MySQL, theo thiết kế, có thể trở lại chế độ không đồng bộ dựa trên cài đặt thời gian chờ xác nhận nô lệ hoặc dựa trên số lượng nô lệ có khả năng bán đồng bộ có sẵn tại bất kỳ thời điểm nào. Theo định nghĩa, chế độ không đồng bộ không cung cấp đảm bảo rằng các giao dịch đã cam kết sẽ được sao chép tới máy chủ và do đó, việc mất bản gốc sẽ dẫn đến mất dữ liệu chưa được sao chép. Thiết kế mặc định của khung ScaleGrid HA là để tránh rơi trở lại chế độ không đồng bộ. Hãy xem lại các cấu hình ảnh hưởng đến hành vi này.
-
rpl_semi_sync_master_wait_for_slave_count
Tùy chọn này được sử dụng để định cấu hình số lượng nô lệ phải gửi xác nhận trước khi một chủ bán đồng bộ có thể thực hiện giao dịch. Trong cấu hình chủ-tớ 3 nút, chúng tôi đặt giá trị này thành 1 để chúng tôi luôn đảm bảo rằng dữ liệu có sẵn trong ít nhất một phụ trong khi tránh bất kỳ tác động hiệu suất nào liên quan đến việc chờ xác nhận từ cả hai nô lệ.
-
rpl_semi_sync_master_timeout
Tùy chọn này được sử dụng để định cấu hình lượng thời gian mà một tổng thể bán đồng bộ chờ xác nhận từ một phụ trước khi chuyển trở lại chế độ không đồng bộ. Chúng tôi đặt giá trị này thành giá trị thời gian chờ tương đối cao để không có dự phòng cho chế độ không đồng bộ.
Vì chúng tôi đang hoạt động với 2 nô lệ và rpl_semi_sync_master_wait_for_slave_count được đặt thành 1, chúng tôi nhận thấy rằng ít nhất một trong số các nô lệ xác nhận trong một khoảng thời gian hợp lý và chính không chuyển sang chế độ không đồng bộ khi mạng tạm thời bị gián đoạn.
-
rpl_semi_sync_master_wait_no_slave
Điều này kiểm soát xem máy chủ có đợi khoảng thời gian chờ được định cấu hình bởi rpl_semi_sync_master_timeout hết hạn hay không, ngay cả khi số lượng nô lệ giảm xuống ít hơn số lượng nô lệ được định cấu hình bởi rpl_semi_sync_master_wait_for_slave_count trong khoảng thời gian chờ. Chúng tôi giữ lại giá trị mặc định là BẬT để cái chính không rơi trở lại sao chép không đồng bộ.
Tác động của việc mất tất cả nô lệ bán đồng bộ
Như chúng ta đã thấy ở trên, khung làm việc của chúng tôi ngăn không cho bản chính chuyển sang sao chép không đồng bộ nếu tất cả các nô lệ bị hỏng hoặc không thể truy cập được từ bản chính. Tác động trực tiếp của điều này là việc ghi bị đình trệ trên bản chính ảnh hưởng đến tính khả dụng của dịch vụ. Điều này về cơ bản được mô tả bởi định lý CAP về các giới hạn của bất kỳ hệ thống phân tán nào. Định lý nói rằng, khi có phân vùng mạng, chúng ta sẽ phải chọn tính khả dụng hoặc tính nhất quán, nhưng không phải cả hai. Phân vùng mạng, trong trường hợp này, có thể được coi là nô lệ MySQL bị ngắt kết nối khỏi cái chính vì chúng bị hỏng hoặc không thể truy cập được.
Mục tiêu nhất quán của chúng tôi là đảm bảo rằng đối với tất cả các giao dịch đã cam kết, dữ liệu có sẵn trên ít nhất 2 nút. Kết quả là trong những trường hợp như vậy, khung ScaleGrid HA ủng hộ tính nhất quán so với tính khả dụng. Việc ghi thêm sẽ không được chấp nhận từ các máy khách mặc dù MySQL master vẫn sẽ phục vụ các yêu cầu đọc. Đây là một quyết định thiết kế có ý thức mà chúng tôi đã thực hiện như một hành vi mặc định, tất nhiên, có thể định cấu hình dựa trên các yêu cầu ứng dụng.
Đảm bảo đăng ký blog ScaleGrid để bạn không bỏ lỡ Phần III, nơi chúng ta sẽ thảo luận thêm về các trường hợp lỗi và khả năng khôi phục của khung MySQL HA . Hãy theo dõi !!
