Bản sao MySQL - Giới thiệu Slave mới để nhân rộng

Gần đây tôi đã đảm nhận vị trí quản trị viên hệ thống quản lý một nhóm gồm 20 (hoặc hơn) máy chủ. Một điều tôi chưa từng xử lý trước đây (ngoài tình huống thử nghiệm), là giới thiệu một nô lệ mới cho trang trại nhân rộng MySQL.

Về cơ bản, bản sao được thiết lập như vậy:

MS -> SL1 -> SL2 (backup)
|                     SL3 (reporting)
SB2                   SL4 (loadbalanced web slave)
                      SL5 (loadbalanced web slave)
                      SL6 (loadbalanced web slave)
                      SL7 (loadbalanced web slave)

Nhưng về cơ bản, nó là một Master với hai nô lệ đọc, (một hoàn toàn để sao lưu), một cho nô lệ đọc chính (chủ trong chờ đợi, nếu bạn muốn), với 6 nô lệ phía sau, được sử dụng để sao lưu bổ sung, đọc 4 trang web cân bằng tải nô lệ và một máy chủ được sử dụng để báo cáo.

Tôi đã đọc nhiều trên mạng và cho rằng việc thêm một nô lệ mới vào môi trường (từ SL1), sẽ là:

• Đăng nhập vào SL2:
  • STOP SLAVE;
  • FLUSH TABLES WITH READ LOCK;
  • (sao chép thư mục mysql sang máy chủ mới)
  • sau khi hoàn thành, UNLOCK TABLES;và sau đó START SLAVE;(tất cả đều ổn cho đến thời điểm này, SL2 trở lại trực tuyến và bắt kịp)
  • đảm bảo cấu trúc db là chính xác trên máy chủ mới và các điểm master.info ở đúng nơi (chỉ chính xác vào SL1)
  • Khởi động MySQL trên máy chủ mới, kiểm tra xem Slave SQL và I / O đang chạy (vâng, điều này tốt)

Tuy nhiên, sau một khoảng thời gian, tôi nhận được lỗi chèn khóa trùng lặp từ nhật ký nhị phân:

110122 17:01:25 [ERROR] Slave SQL: Error 'Duplicate entry '2011-01-22 17:00:01' for key 'PRIMARY'' on query. Default database: 'thelm_soft'. Query: 'INSERT INTO  thm_member_views  (   member_view_ts, logged_in_members, non_members ) VALUES ( now(), '27037', '132834' )', Error_code: 1062
110122 17:01:25 [Warning] Slave: Duplicate entry '2011-01-22 17:00:01' for key 'PRIMARY' Error_code: 1062

Đây có phải là một vấn đề với thực tế bây giờ () đang nằm trong một truy vấn, điều thông thường nói với tôi sẽ gây ra vấn đề nếu các phần chèn trên bảng đó đủ thường xuyên ??!?! Hoặc tôi đã có quá trình sao chép sai, tức là bắt đầu từ một vị trí đăng nhập không chính xác?

Đây có phải là một vấn đề với thực tế bây giờ () đang nằm trong một truy vấn, điều thông thường nói với tôi sẽ gây ra vấn đề nếu các phần chèn trên bảng đó đủ thường xuyên ??!?!

Vâng, tôi tin rằng đây là nguyên nhân gây ra lỗi của bạn. Phương pháp của bạn để giới thiệu nô lệ mới dường như là chính xác. Theo tôi, khá lạ khi định nghĩa một bảng có trường DATETIME là Khóa chính. Như bạn đã chỉ ra khá đúng, nô lệ nhận được các truy vấn được sao chép từ chủ và họ sẽ sử dụng từ khóa now () trong các truy vấn, sẽ lấy dấu thời gian từ máy chủ cục bộ.

Thực sự, bảng phải được xác định với một số loại dữ liệu khác cho PK (chẳng hạn như INT hoặc BIGINT) có thể được đảm bảo là duy nhất, không giống như dấu thời gian được chèn vào bây giờ ().

CẬP NHẬT

Đây là một câu trả lời thay thế mà tôi đã viết trong một trang web StackExchange khác

Câu trả lời gốc

Khi bạn sao chép thư mục mysql, xin lưu ý rằng bạn cũng đã sao chép nhật ký chuyển tiếp. Tất cả các nhật ký chuyển tiếp được gắn thẻ với server_id của chủ. Bậc thầy có xu hướng tạo ra một quá trình nô lệ "nấc" khi hai nô lệ (anh chị em) chia sẻ cùng một server_id.

MySQL sẽ khiếu nại nếu chủ và nô lệ có smae server_id. Bản sao MySQL thậm chí sẽ không bắt đầu trong trường hợp đó. Vấn đề này là một chút tinh tế và không quá rõ ràng. Đây là lý do tại sao:

Nếu một chủ có nhiều nô lệ và hai hoặc nhiều nô lệ đó chia sẻ cùng một server_id, thì nô lệ được kết nối trước (với ID tiến trình thấp hơn trong danh sách quy trình của chủ) sẽ sao chép từ chủ tốt. Tất cả các kết nối khác từ các nô lệ khác có server_id giống hệt với nô lệ đầu tiên có thể và sẽ ngắt kết nối và kết nối lại không liên tục dưới mui xe. Điều này cũng có thể gây nhầm lẫn cho chủ nhân vì nó ghi dữ liệu dấu thời gian trong nhật ký chuyển tiếp. Có thể an toàn hơn để xóa nhật ký chuyển tiếp trước.

Thay vì chỉ bắt đầu sao chép sau khi sao chép, bạn có thể thử điều này:

1. Thêm Skip-Slave-start vào /etc/my.cnf của nô lệ mới này
2. Bắt đầu mysql trên nô lệ mới
3. Chạy CHANGE MASTER TO trên nô lệ mới (Điều này xóa tất cả các rơle được tạo trước đó, do đó dữ liệu dấu thời gian khác nhau trong nhật ký chuyển tiếp có sẵn)
4. Xóa bỏ qua-nô lệ-bắt đầu từ /etc/my.cnf của nô lệ mới này
5. Khởi động lại mysql

Tôi hi vọng cái này giúp được.

FYI- Cuộc gọi now () sẽ sử dụng dấu thời gian từ chủ trong binlog sao chép. http://dev.mysql.com/doc/refman/5.5/en/replication-features-fifts.html

Câu trả lời ở trên Bản sao MySQL - Giới thiệu Slave mới để sao chép là hoàn toàn chính xác. Bạn đang thiếu MASTER THAY ĐỔI.

Tại sao bạn sao chép toàn bộ thư mục mysql mà không chỉ các tệp cơ sở dữ liệu cụ thể? Khi đưa vào một nô lệ mới, tôi thường thực hiện cài đặt mysql sau đó mang lại dữ liệu. Bạn không cần tất cả nhật ký chuyển tiếp của chủ và như vậy.

Bạn có đang chạy chủ của mình ở định dạng nhật ký nhị phân 'cấp độ câu lệnh' không? Tôi không chắc chắn 100% nó sẽ hoạt động, nhưng có lẽ việc thay đổi nó thành định dạng cấp hàng sẽ sửa lỗi.

Vấn đề với ghi nhật ký cấp hàng là nó ghi nhật ký nhiều thông tin hơn, bạn sẽ phải xem việc sử dụng đĩa và thường xuyên xóa nhật ký của mình để tránh hết dung lượng ổ cứng.

Ghi nhật ký mức hỗn hợp có thể tự động chuyển định dạng nhật ký sang 'hàng' cho cuộc gọi NOW (), nhưng tôi chưa bao giờ thử và các tài liệu không nói rõ rằng nó sẽ chuyển sang NOW (). Có thể là một cái gì đó để kiểm tra.