Bạn chắc chắn đang đi đúng hướng ở đây.
Bất cứ khi nào InnoDB thực hiện một giao dịch phải được cam kết, nó được thực hiện như một cam kết hai giai đoạn. Giao dịch được ghi trong các bản ghi này đầu tiên. Sau đó, họ cam kết từ đó.
Điều này giúp ích rất nhiều trong trường hợp MySQL gặp sự cố hoặc sự cố máy chủ.
Khi bạn khởi động lại mysql, tất cả các mục chưa được cam kết trong ib_logfile0 và ib_logfile1 sẽ được phát lại như một phần của quá trình khôi phục sự cố của InnoDB để đưa InnoDB về trạng thái hài hòa (Đây là phần nhất quán và bền của Tuân thủ ACID )
Nếu bạn xóa ib_logfile0 và ib_logfile1 và khởi động mysql, bất kỳ giao dịch chưa cam kết nào chứa các tệp đó sẽ bị mất. Trong chu kỳ khôi phục sự cố, nếu thiếu tệp nhật ký, chúng sẽ được tạo lại dựa trên innodb_log_file_size cài đặt.
Vui lòng xem Tài liệu MySQL để biết chi tiết giải thích về InnoDB .
@karatedog phần MVCC của InnoDB xảy ra trong không gian bảng hệ thống, còn được gọi là ibdata1. Bất kỳ dữ liệu nào xuất hiện trước khi bắt đầu giao dịch đều được ghi lại để cho phép những người khác truy cập vào các hàng cần thiết có thể xem dữ liệu trước khi bất kỳ cập nhật nào được áp dụng. Điều này cho phép cái được gọi là REPEATABLE-READ. Điều này thuộc về tuân thủ I of ACID, ý tôi là Isolation. Tôi đã viết các bài đăng về điều này trong DBA StackExchange liên quan đến các tình huống khác nhau trong đó việc cô lập giao dịch là tốt, xấu hoặc xấu.
- đọc trước khi ghi giao dịch
- Hai truy vấn này có dẫn đến bế tắc nếu được thực thi theo trình tự không?
- Đột kích 5 có phù hợp để cài đặt mysql không?
Đối với MyISAM, khôi phục sự cố không tự động. Nó khá dễ gặp sự cố
. Đó là lý do tại sao lệnh SQL REPAIR TABLE tồn tại. Đó cũng là lý do tại sao tiện ích MySQL myisamchk có -r tùy chọn để thực hiện REPAIR TABLE cho các bảng MyISAM không trực tuyến.
MariaDB và Aria đã cố gắng tạo ra một công cụ lưu trữ an toàn khi gặp sự cố thay thế cho MyISAM.
