Redo log, undo log và binary log

Đây là ba loại log mà bạn đã từng nghe khi tiếp cận mysql. Trong các cơ sở dữ liệu quan hệ (RDBMS) khác, cũng sẽ có các thành phần có vai trò tương tự ba loại log trên. Mỗi loại log lại có những vai trò khác nhau nên được mysql sử dụng trong các tình huống khác nhau.

Có bao giờ bạn tự hỏi mysql sẽ làm gì khi một sự cố như sụt nguồn, cháy CPU, hỏng ổ hoặc mysql crash. Ngay từ khi thiết kế database, những case trên thực sự là vấn đề phải được xem xét kỹ lưỡng nếu không sẽ dẫn đến hậu quả mất mát dữ liệu. Đặc biệt với các transaction nhạy cảm như rút tiền khỏi tài khoản. Hành động rút tiền đã được commit nhưng ngay sau đó một sự cố khủng khiếp xảy ra và thế là transaction đó biến mất cùng sự cố. Bạn rút 10 triệu khỏi tài khoản nhưng vào ngày nào đó, khi kiểm tra tài khoản, bạn bỗng nhận ra bạn vẫn còn 10 triệu. Đây sẽ là tin mừng với ai đó đang cháy túi vào cuối tháng nhưng là điều tai hại với mọi ngân hàng. Vậy mysql đã phải bảo vệ data thế nào khỏi các tình huống éo le trên ? Redo log và undo log đóng các vai trò quan trọng trong các tình huống này. Trong các tình huống trên, mất mát dữ liệu bắt nguồn từ các transaction nằm trong memory nhưng chưa kịp flush xuống data files (ibd hay ibdata tùy vào cấu hình). 

Redo log hay còn gọi là transaction log sẽ replay các thay đổi nằm trong memory nhưng chưa kip flush xuống data files. Nếu muốn chứa các thay đổi nằm trong memory nhưng chưa có trong data files thì hẳn là tốc độ đẩy data xuống redo log phải nhanh hơn xuống data files. Đó đúng là điều thực sự diễn ra. Mysql sẽ write data theo cách ngẫu nhiên xuống data files nên sẽ châm hơn khi write data tuần tự xuống redo log. Cũng vì cơ chế này, một số tài liệu khuyến khích sử dụng ổ SSD để lưu data files còn ổ rotation disk để lưu redo log. Các transaction chưa kịp flush xuống data files giờ sẽ nằm trong redo log và các transaction này sẽ được replay lại trong quá trình recovery tự động tại thời điểm mysql startup sau sự cố.

Cùng với redo log còn có undo log. Undo log nằm trong ibdata. Vai trò của undo log là giúp db xác nhận trong các transaction vừa được replay từ redo log thì transaction nào cần được commit, transaction nào cần được rollback. Nếu một transaction bị ngắt giữa chừng, client disconnet, mysql crash trước khi commit hoặc transaction đó kết thúc bằng một rollback thì tất cả các thay đổi do transaction này tạo ra phải bị loại bỏ, db khi đó sẽ được đưa về trạng thái trước transaction này. Với transaction đã đươc commit thì ngược lại, mọi thay đổi bắt buộc phải được giữ lại trong db.

Giả sử bạn đang insert 10.000 bản ghi. Quá trình này diễn ra êm đẹp được 8000 bản ghi thì mysql crash. Sau khi xử lý sự cố, bạn start mysql, quá trình recovery được tự động thực hiện. Mysql sẽ đọc redo log. Nó sẽ biết bạn đang thực hiện insert 10.000 bản ghi, transaction insert 10.000 bản ghi được replay. Sau đó, mysql đọc tiếp undo log. Nó sẽ biết transaction của bạn bị ngắt khi thực hiện insert 8000 bản ghi. Do đó, mysql sẽ rollback 8000 bản ghi nói trên.

Ngoài redo log và undo log, mysql còn có binary log nhưng loại log này không tham gia vào quá trình recovery nói trên. Binary log phục vụ cho quá trình replication giữa các server mysql. Có thể hiểu nó là phương tiện để đem các thay đổi có trên một mysql server gọi là master apply lên một mysql server khác gọi là slave. Binary log được sử dụng trong quá trình point-in-time recovery. Đây là quá trình recovery bổ sung cho một full backup để đưa db về trạng thái ngay trước khi xảy ra sự cố. Một số sự cố làm tiêu tan hoàn toàn data trên mysql ví dụ bạn lỡ tay xóa nhầm data trong database. Redo log và undo log không giúp gì cho bạn. Phương án cho tình huống này là bạn sử dụng bản full backup để khôi phục data trước sự cố. Nhưng các bản full backup thường được tạo ra định kỳ. Ví dụ bạn định kỳ tạo full backup tại 12h trưa và 12h đêm. Sự cố xóa nhầm data xảy ra lúc 3h chiều. Sử dụng bản full backup gần nhất lúc 12 trưa, bạn vẫn mất data trong ba tiếng sau đó. Point-in-time recovery sử dụng binary log cho phép bạn khôi phục lại lượng data trong ba tiếng đến ngay sát trước thời điểm xảy ra sự cố lúc 3h chiều.  

Bài viết tóm lược nội dung tổng quan và phân biệt ba loại log trong mysql hi vọng sẽ hữu ích cho các bạn.

Tham khảo:

http://www.pythian.com/blog/overview-of-transaction-logging-in-mysql/
http://kipalog.com/posts/So-luoc-mysql-innodb-internal-va-cach-mysql-innodb-thuc-hien-crash-recovery