MySQL implements transaction persistence using redo logs

summary

Mentioned earlier , In order to reduce the io operation , The loaded data page will be placed in Buffer pool, Wait until the time to brush the plate , Only then can the page data be really brushed to the disk for persistence . Suppose the modified dirty page , When the transaction has been committed , A sudden power failure , Then the modified dirty pages are lost , There is no way to ensure the persistence of transactions . This is the time redo Logs come in handy .

redo Log principle

1. When executing a write statement , First, it will be loaded into Buffer pool In the cache page of , Then modify the data in the page , Add to 
  flush In the list , We know that if the power is cut off at this time , The data is actually changed in memory , Data loss ,
   This modified dirty page can no longer be recovered .
  
2. Add to flush In the list , In fact, it will be written into a file called redo Log file , Of course not directly , Direct is too slow ,
   In fact, I first wrote a book called log buffer in , One is written each time mtr（ Indivisible log group ）, It can be understood as a log group .
   How many bytes are written , So this lsn Record the offset .
  
3. If the power is cut off at this time , Or will it lead to log buffer Data loss for , Persistence is still not guaranteed . therefore , In fact, at some time 
   Go and put log buffer Of mtr Refresh to the real physics text