Tính sẵn sàng cao, chuyển đổi dự phòng và nhân rộng của MySQL với Độ trễ


8

Chúng tôi đang trong quá trình triển khai một CMS mới (Drupal 6.x) chạy trên MySQL. Chúng tôi có hai trung tâm dữ liệu - chính và phụ - với độ trễ đã biết giữa chúng. Chúng tôi không chắc chắn phiên bản MySQL nào chúng tôi sẽ chạy ... Cộng đồng hoặc Doanh nghiệp, nhưng đó là TBD. Có vẻ như chúng tôi sẽ chạy công cụ InnoDB, HĐH sẽ là RedHat EL 5.5 Các máy chủ chính sẽ hoạt động, trong khi máy phụ sẽ bị động hoặc chờ nóng.

Tôi muốn triển khai nhân rộng, tính sẵn sàng cao và chuyển đổi dự phòng tự động trong MySQL trên hai trung tâm dữ liệu.

Sau khi chuyển đổi dự phòng sang máy chủ thứ cấp, khi chúng tôi không quay lại máy chủ chính, chúng tôi muốn dữ liệu được đồng bộ hóa từ DB thứ cấp sang DB chính một cách nhanh chóng và hoàn toàn để chúng tôi có thể tiếp tục phục vụ nội dung từ các máy chủ chính.

Tôi muốn biết những công nghệ / công cụ / thực tiễn tốt nhất nào có thể được sử dụng để giải quyết / giải quyết những vấn đề này. Ngoài ra, bất kỳ khoảnh khắc gotchas hoặc ah-ha cũng sẽ được đánh giá cao. Tôi đã đọc về sao chép MySQL, phân cụm và tại một số công cụ của bên thứ 3 như Vonfram và Cá heo, nhưng tôi không chắc đâu là hành động tốt nhất.

Cảm ơn bạn đã dành thời gian!

Quốc gia

Câu trả lời:


3

Để đơn giản, tôi khuyên bạn chỉ nên sao chép thông tư MySQL. Đây là lý do tại sao:

Có nhiều công nghệ và cấu trúc liên kết vượt trội hơn nhiều so với Bản sao Thông tư của MySQL. Yêu thích của tôi, xuống tay, là DRBD (Thiết bị khối sao chép phân tán) . Tuy nhiên, DRBD hoạt động tuyệt vời khi Cặp máy chủ ở cùng một chỗ phình, trung tâm dữ liệu và giá đỡ. Thậm chí còn tốt hơn khi sử dụng cáp chéo trong mạng con 192.168.xx giữa DRBD sơ cấp và DRBD thứ cấp. Thật không may , DRBD có hiệu suất khủng khiếp trong khoảng cách giữa hai địa điểm, mặc dù DRBD vẫn có thể hoạt động. Không có cấu trúc liên kết mạng xung quanh để cung cấp cho bạn hiệu suất DRBD thỏa đáng cần thiết giữa hai trung tâm dữ liệu.

Khi bạn thiết lập Bản sao Thông tư MySQL giữa hai máy chủ DB ở hai trung tâm dữ liệu khác nhau, điều chỉnh duy nhất cần thiết là cho mạng. Về bản chất, hiệu suất sao chép là một chức năng của cài đặt mạng (tốc độ / độ trễ của truyền nhật ký nhị phân trong Thiết lập sao chép MySQL) và I / O đĩa (DRBD).

Một sự thay thế bạn có thể muốn dự phòng tốt hơn là ví dụ sau:

Thiết lập Cặp DRBD ở cả hai vị trí
Cặp DRBD trong Trang web số 1 với VIP 111.111.111.111
Cặp DRBD trong Trang web số 2 với VIP 222.222.222.222

Thiết lập bản sao thông tư MySQL giữa các máy chủ chính DRBD theo các điều kiện sau:
Đối với trang web số 1, hãy sử dụng 222.222.222.222 làm Master_host trong MySQL
Đối với trang web số 2, sử dụng 111.111.111.111 làm Master_host trong MySQL

Mặc dù giới thiệu một mức độ phức tạp, nhưng bây giờ bạn có hai mức độ dự phòng: DRBD trong mỗi trang web và Bản sao Thông tư MySQL giữa các trang web. Bạn có các lợi ích bổ sung của việc chạy các bản sao lưu thông qua mysqldump trên DRBD Chính của máy chủ dự phòng nóng.

Đối với chuyển đổi dự phòng, DRBD cung cấp chuyển đổi dự phòng tự động tại bất kỳ một trang web nào.

Chỉ trong trường hợp trung tâm dữ liệu hoàn toàn không thể sử dụng DB VIP tại trang dự phòng nóng.

CẬP NHẬT

Tôi vừa thực hiện một lần và nhận thấy rằng bạn đang sử dụng Drupal6. Tôi rất vui vì bạn sẽ chuyển đổi tất cả các bảng drupal sang InnoDB. Điều này sẽ loại bỏ bất kỳ cơ hội cập nhật bảng MyISAM nào khiến khóa bảng đóng băng các kết nối DB chỉ đơn giản là đọc các bảng MyISAM. Bất kỳ bản cập nhật DML nào (CHỨNG MINH, CẬP NHẬT, XÓA) đối với bảng MyISAM SWAY LUÔN LUÔN LÀM MỘT KHÓA BẢNG ĐẦY ĐỦ !!! Sử dụng InnoDB sẽ giới thiệu khóa cấp hàng, giúp loại bỏ khóa bảng đầy đủ.

Ngoài ra, DRBD trở thành bạn của bạn khi mọi thứ đều là InnoDB vì việc khôi phục sự cố sẽ phù hợp giữa Cặp DRBD. Contrawise, DRBD với MyISAM không mua gì cho bạn vì bảng MyISAM bị lỗi trên DRBD Primary chỉ đơn giản là được sao chép vào DRBD thứ cấp, như bạn đoán nó , bảng MyISAM bị sập.

CẬP NHẬT # 2

Bạn nên sử dụng hai cấp độ dự phòng

Cấp 1: Tại mỗi trung tâm cơ sở dữ liệu, sử dụng DRBD.
http://dev.mysql.com/doc/refman/5.1/en/ha-drbd.html

Thiết lập một cặp Máy chủ DB
Khởi động DRBD
Khởi động MySQL trên Chính DRBD

Điều này tạo ra dữ liệu dư thừa ở cấp độ đĩa.

Cấp độ 2: Bạn nên thiết lập Bản sao thông tư MySQL giữa
Chính DRBD của DataCenter # 1 và DRBD chính của DataCenter # 2

Mỗi DRBD chính sẽ chạy MySQL và sẽ hoạt động
như cả Master và Slave cho nhau

Tôi đã thiết lập cho các cấu trúc liên kết khách hàng như thế này và tôi thấy nó khá ổn định.


Cảm ơn @RolandoMySQLDBA. Quan điểm của bạn về việc sử dụng VIP cân bằng tải cho việc ngừng hoạt động của trung tâm dữ liệu có ý nghĩa. Vậy chúng ta sẽ có Master-Slave trong mỗi trung tâm dữ liệu, phải không? Trong trường hợp không thành công, bạn nghĩ đâu là cách tốt nhất để đảm bảo các DB chính được cập nhật? Ngoài ra, tôi đã xem xét sao chép vòng tròn, và có vẻ như nó dựa trên phân cụm MySQL? với NDB? Tôi không nghĩ Drupal 6 hoạt động tốt với NDB ( drupal.org/node/391130 ). Cảm ơn bạn một lần nữa cho thời gian của bạn!
KM.

Tôi đã cập nhật câu trả lời của tôi !!! BTW Tôi không bao giờ đề cập đến NDB. Bản sao Thông tư MySQL chỉ là Master-Slave được triển khai hai chiều.
RolandoMySQLDBA

Cảm ơn bạn đã làm rõ. Một số tài liệu tham khảo sao chép vòng tròn MySQL đã đề cập đến NDB vì vậy tôi muốn kiểm tra lại (-: BTW, Bạn có thể tự động hóa như thế nào với chuyển đổi dự phòng bằng cách sử dụng các cấu trúc liên kết này?
KM.

DRBD được thiết kế để hỗ trợ chuyển đổi dự phòng tự động bằng Linux HeartBeat hoặc ucarp ( ucarp.org/project/ucarp ). Công ty của tôi, LogicWorks, là một cửa hàng ucarp. ucarp cho phép hai máy chia sẻ một địa chỉ IP ảo (VIP). DRBD Master sẽ có VIP với MySQL chạy trên nó. DRBD Thứ cấp sẽ có ucarp chạy và chờ tỷ lệ thời gian chết để kích hoạt chuyển đổi dự phòng tự động. Các tập lệnh lên và xuống cho ucarp để giả sử DB VIP nên bao gồm việc gắn đĩa DRBD, biến nó thành Chính và khởi động MySQL. Kịch bản xuống sẽ ngăn MySQL gỡ bỏ DRBD, đi Trung học và tiêu diệt VIP.
RolandoMySQLDBA
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.