Để bắt đầu với ...
http://yoshinorimatsunobu.blogspot.com/2009 /08/great-performance-effect-of-fixing.html
Trước Plugin InnoDB 1.0.4, nó giống như:
obtain mutex
write innodb log and fsync, for prepare-phase (skip if innodb_support_xa=0)
write binlog (fsync as appropriate if sync_binlog > 0)
write innodb log and fsync, for commit-phase
release mutex
Trên và sau Plugin InnoDB 1.0.4 (và MySQL 5.5), bây giờ là:
write innodb log and fsync, for prepare-phase (skip if innodb_support_xa=0)
obtain mutex
write binlog (fsync as appropriate if sync_binlog > 0)
write innodb log, for commit-phase
release mutex
fsync innodb log, for commit-phase
Như bạn có thể thấy, trong phiên bản mới, không có gì (ngoại trừ trường hợp sync_binlog> 0) là fsync'd trong phần quan trọng. Bằng cách đó, cam kết nhóm hiện hoạt động và đảm bảo thông lượng đồng thời tốt hơn nhiều.
Ví dụ:với phiên bản "bị hỏng" trước đó, nếu bạn có 100 luồng cam kết đồng thời, tất cả các fsync đã được tuần tự hóa và bạn sẽ nhận được 100 fsync để chuẩn bị và 100 fsync khác để cam kết. Do đó, cam kết nhóm đã bị phá vỡ hoàn toàn.
Giờ đây với việc triển khai mới hơn, fsync được nhóm lại tùy thuộc vào đồng thời của các giao dịch, đồng thời đảm bảo thứ tự hoạt động giữa innodb log và binlog. Điều đó cũng có nghĩa là nếu chỉ có một luồng, sẽ không có hiệu suất tăng.
Đối với câu hỏi của bạn rằng, khi sự cố xảy ra sau khi một giao dịch được ghi vào binlog, nhưng trước khi nó được ghi vào nhật ký giao dịch - tôi ở cùng trang với bạn.
Nếu máy chủ gặp sự cố trước bước cuối cùng, có một chút khả năng là bạn có sự khác biệt giữa nhật ký innodb và binlog (cái này có thể đi trước cái kia), nhưng được đảm bảo rằng bạn có tất cả thông tin về những gì cần kiểm tra trong nhật ký innodb, vì nó được ghi lại trong giai đoạn chuẩn bị.
Tuy nhiên, những gì phải làm với không cam kết vẫn là không xác định. Ví dụ:trừ khi sync_binlog = 1 có khả năng một nô lệ đã nhận được dữ liệu nhưng chưa đồng bộ hóa hoàn toàn binlog trên bản chính. Bạn không thể chỉ thực hiện lại giao dịch bị lỗi vì nó có thể đã chạy trên một trong các nô lệ.
Điều đó cũng có nghĩa là, binlog có thể ngắn hơn nhật ký innodb, trả về "Nhật ký nhị phân [tên_tệp] ngắn hơn kích thước dự kiến của nó." như được mô tả trong tài liệu chính thức và bạn phải xây dựng lại nô lệ từ đầu. Không thân thiện với con người cho lắm.
http://dev.mysql.com/doc/refman /5.1/en/binary-log.html
Vì tính nhất quán về điều khoản hoạt động được đảm bảo độc lập với innodb_support_xa cài đặt (mâu thuẫn với những gì được nói trong tài liệu chính thức trên innodb_support_xa , có thể vì nó đã được viết về bản innodb 5.0.3 trước khi sửa chữa đồng thời) và tính nhất quán giữa bản ghi innodb trên bản chính và bản ghi chuyển tiếp trên bản phụ không được đảm bảo chặt chẽ ngay cả với innodb_support_xa , Tôi không thấy điểm nào khi sử dụng innodb_support_xa . Tuy nhiên, thật đáng sợ nếu không tuân theo khuyến nghị chính thức, tuy nhiên nó có vẻ cũ và sai ở nhiều điểm.
Tôi tự hỏi liệu có mối tương quan nào giữa innodb_flush_log_at_trx_commit không cài đặt và innodb_support_xa hành vi khi trước đó được đặt thành 2 hoặc 0.
Một cách suy nghĩ thực tế là, chuyển đổi dự phòng sang nô lệ là an toàn - xét cho cùng, giao dịch thất bại là điều bạn muốn thực hiện - nhưng đừng bao giờ quay lại chủ sở hữu, vì có thể có một số sai lệch trong dữ liệu. Bạn cần sao chép đầy đủ dữ liệu từ nô lệ, trước khi biến chủ nhân thành nô lệ mới. Nói cách khác, khi master gặp sự cố, hãy tin tưởng nô lệ từ đó trở đi - theo cách đó, bạn không cần phải làm phiền đến nhật ký innodb để khôi phục sự cố.
Cũng lưu ý rằng MySQL 5.5 hỗ trợ sao chép bán đồng bộ, cùng dòng với "tin cậy nô lệ" - bạn có thể quan tâm.
http://dev.mysql.com/doc/refman /5.5/en/replication-semisync.html
