Bản sao MySQL: 'Mục nhập trùng lặp cho khóa CHÍNH'


9

Bạn có thể vui lòng giúp tôi hiểu lý do tại sao tôi nhận được 'Mục nhập trùng lặp cho khóa CHÍNH HÃNG' trên máy chủ nô lệ sau khi đồng bộ hóa lại đầy đủ.

Về cơ bản, 'mysqldump' đã hoạt động gần như cả đêm và sau đó quá trình khôi phục mất vài giờ, vì vậy khi tôi bắt đầu nô lệ, nó chỉ còn ~ 63874 giây so với chủ nhân.

Máy chủ nô lệ chỉ được đọc (read_only) và không có bất kỳ ghi nào trong quá trình đồng bộ hóa lại vì vậy tôi không hiểu tại sao có các khóa trùng lặp.

Định dạng nhật ký nhị phân được đặt thành MIXED trên bản gốc.

Lệnh được sử dụng để sao lưu DB:

mysqldump --opt --single-transaction -Q --master-data=2 db | bzip2 -cz > db.sql.bz2

Slave chỉ sao chép một cơ sở dữ liệu từ master (db -> db_backup) với các tùy chọn sau:

replicate-wild-do-table = db_backup.%
replicate-rewrite-db = db->db_backup

Câu trả lời:


11

NHIỆM VỤ # 1: Nhân rộng

Tôi không nghĩ rằng

replicate-wild-do-table = db_backup.%
replicate-rewrite-db = db->db_backup

thuộc về nhau.

Những người khác cũng đã tự hỏi về điều này là tốt

Vấn đề bắt nguồn từ các quy tắc sao chép đơn hàng được xử lý. Theo Tài liệu MySQL về Quy tắc nhân rộng :

Nếu bất kỳ tùy chọn --replicate-Rewrite-db nào được chỉ định, chúng sẽ được áp dụng trước khi các quy tắc lọc --replicate- * được kiểm tra.

Ngay cả Tài liệu MySQL về sao chép-viết lại-db cũng nói:

Việc dịch tên cơ sở dữ liệu được thực hiện trước khi các quy tắc --replicate- * được kiểm tra.

Việc replicate-wild-do-tablenày được thi hành sau khi viết lại. Sẽ không có gì đáng ngạc nhiên nếu thứ tự này bằng cách nào đó áp đặt một CHERTN vào một bảng đã có dữ liệu.

Có lẽ bạn đang hỏi làm thế nào dữ liệu đạt được điều đó?

NHIỆM VỤ # 2: mysqldump

Làm mysqldump --single-transactiondường như là cách tốt nhất để kết xuất dữ liệu theo thời gian. Thật không may, mysqldump --single-transactioncó một gót chân Achilles : ALTER TABLE. Nếu một bảng tuân theo bất kỳ ALTER TABLElệnh nào , chẳng hạn như a DROP TABLECREATE TABLE, có thể phá vỡ tính toàn vẹn của giao dịch, mysqldump đã cố gắng thực hiện kết xuất. Cắt ngắn một bảng (là DDL trong Vũ trụ MySQL) và bỏ và thêm chỉ mục có thể cũng như gây rối.

Bạn có thể tìm thêm thông tin về điều đó từ MySQL Performance Bí mật giữ bí mật tốt nhất của MySQL Performance Blog . Tôi thực sự đã giải quyết điểm này trong một câu hỏi trước đây mô tả 12 lệnh có thể phá vỡ tính toàn vẹn của giao dịch của mysqldump: Sao lưu MySQL InnoDB

CAUPAT

TIẾNG VIỆT

Một hoặc cả hai khía cạnh có thể đã góp phần khiến cho một hàng bị trượt trong quá trình mysqldump không tồn tại do các quy tắc viết lại hoặc sự cô lập của mysqldump bị ghi đè.

BỀN VỮNG

Tôi sẽ thực hiện kết xuất mysqlbinlog của tất cả các bản ghi chuyển tiếp kể từ khi bắt đầu mysqldump để xem tất cả các CHỨNG CHỈ rằng Slave sẽ xử lý và xem các hàng đó đã tồn tại trên Slave chưa. Nếu họ làm, bạn có thể làm hai điều:

1: Bỏ qua tất cả các lỗi Khóa trùng lặp

Đơn giản chỉ cần thêm phần này vào my.cnf trên Slave

[mysqld]
slave-skip-errors=1062
skip-slave-start

và khởi động lại mysql. Sau đó chạySTART SLAVE;

tất cả các lỗi khóa trùng lặp sẽ được bỏ qua. Khi Seconds_Behind_Mastervề 0, xóa các dòng đó và khởi động lại mysql.

2: Tải về các công cụ percona

Các công cụ bạn cần là

Sử dụng chúng để tìm sự khác biệt trong Slave, và sau đó sửa chúng


0

Kiểm tra chèn truy vấn trong mã mà chèn trực tiếp vào nô lệ. Chúng tôi chỉ có thể đọc từ nô lệ. Viết truy vấn nên được chuyển đến chủ.


Nhìn lại câu hỏi. Slave là chỉ đọc và không có ghi trong khi đồng bộ lại.
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.