Chiến lược phục hồi để nhân rộng Master-Master


8

Tôi đã triển khai một giải pháp HA cho mysql dựa trên bản sao master-master. Có một cơ chế ở phần mặt trước đảm bảo rằng chỉ một db sẽ được đọc / ghi vào một thời điểm nhất định (nghĩa là chúng ta chỉ sử dụng sao chép cho HA).

Tôi đã xác nhận nhân rộng hoạt động như mong đợi, nhưng tôi tự hỏi về kịch bản thất bại và phục hồi. Cụ thể, tôi lo lắng về những gì xảy ra khi một chủ bị lỗi ở trạng thái không thể phục hồi và cần được tạo lại từ chủ khác:

  • Vì chủ khác đang hoạt động và rất có thể được sử dụng, tôi không thể khóa nó và tạo ra các bãi chứa mysqldump(cơ sở dữ liệu của chúng tôi có kích thước vừa phải và mysqldumpcó thể dễ dàng mất hàng giờ sau vài tháng sử dụng).
  • Ngay cả khi giả sử tôi có một bãi chứa, điều quan trọng là vị trí binlog như được hiển thị bởi SHOW MASTER STATUS tương ứng với kết xuất được thực hiện sau khi cơ sở dữ liệu bị khóa.

Giải pháp đơn giản cho vấn đề đầu tiên là sử dụng cơ sở dữ liệu thứ ba hoạt động như một bản sao lưu, từ đó tôi có thể thực hiện mysqldump. Nhưng sau đó, làm thế nào để tôi chắc chắn rằng bản gốc được tạo lại có thể bắt đầu sao chép từ bản gốc đang chạy một cách nhất quán?


Cân nhắc thêm một nô lệ cho một trong những bậc thầy để bạn có thể thực hiện các bãi chứa của mình từ đó. Nó cũng sẽ giúp sao lưu.
John Gardeniers

Câu trả lời:


2

Có hai cách tiếp cận cơ bản cho vấn đề này mà tôi biết. Đầu tiên, nếu bạn đang chạy InnoDB thay vì Myisam, thì bạn có thể thực hiện sao lưu trong một giao dịch (--single-giao dịch --lock-frames = FALSE), kết hợp với --flush-log (không bắt buộc nhưng tốt đẹp) và --master-data sẽ cung cấp cho bạn bản sao lưu phù hợp với thông tin vị trí sao chép. Nhật ký xả sẽ thiết lập lại nhật ký trước khi kết xuất được tạo, điều đó có nghĩa là vị trí sẽ luôn là 106 và --master-data sẽ đặt tên và vị trí của tệp logfile ngay trong tệp kết xuất. Tất nhiên, bạn phải chạy cái này trên master để --master-data hoạt động.

Cách thứ hai, mà bạn đã đề cập, là sử dụng máy chủ thứ ba để tạo bản sao lưu. Trong trường hợp này, bạn cần dừng sao chép, đảm bảo DB được đọc_only (mặc dù thực sự, tất cả các bản sao của bạn chỉ nên được đọc vì điều này không ảnh hưởng đến việc sao chép) và sau đó tạo bản sao lưu VÀ ghi lại vị trí sao chép. Bạn không thể sử dụng --master-data trong trường hợp này. Thay vào đó, bạn có thể làm một cái gì đó như thế này:

echo 'stop slave' | mysql {options)
mysqldump {your options} > DB.sql
echo 'show slave status\G' > DB.replication
echo 'start slave' | mysql {options)

Nếu bạn cần khôi phục từ bản sao lưu này, bạn sẽ chạy khôi phục và sau đó thiết lập sao chép trong đó hai tham số master_log_file và master_log_pose đến từ tệp DB.replication:

master_log_file = value of Master_Log_File
master_log_pos = value of Exec_Master_Log_Pos

Lưu ý: bạn có thể VÀ NÊN kiểm tra điều này từ một bản sao khác.

Lưu ý bổ sung: nếu bạn có một nhóm bản sao (ví dụ: nếu bạn đã tách các lần đọc khỏi ghi cho ứng dụng web) thì có thể các bản sao không đồng bộ với chủ mới; điều này có thể xảy ra nếu chuyển đổi dự phòng xảy ra trong khoảng thời gian I / O ghi nặng do luồng bản sao không đồng bộ và không có gì đảm bảo rằng chế độ chờ của bạn ở cùng vị trí với các bản sao khác khi bạn chuyển đổi dự phòng. Tuy nhiên, điều này chưa xảy ra với tôi ...


cảm ơn rất nhiều. Tất cả điều này thực sự được ghi nhận trong mysqldump. Tại sao nó không có trong tài liệu mysql chính nằm ngoài tôi ...
David Cournapeau
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.