The difference between RedoLog and Binlog
1. Redo log is unique to the InnoDB engine; binlog is implemented by the server layer of MySQL, and all engines
can be used.
2. redo log is a logical-physical log, operation records in the log logical page, the page operation is recorded between the physical log; the binlog logical day
blog, the log corresponding to Mysql server layer for all engines, and may be Write through parameter control.
3. The redo log is written cyclically, and the space will always be used up; the binlog can be written additionally. "Additional write" means that the
binlog file will switch to the next one after it is written to a certain size, and will not overwrite the previous log.
Remarks:
The log types of the database can be roughly divided into the following three types:
Logical log: records the original logic of sql statements, object-oriented is the logical structure such as tables, columns and other
physical logs: records the changes in file records, object-oriented is table space , Data files, data pages, offsets, etc.
Logical physical log: operations within a page are recorded in logical logs, operations between pages are recorded in physical logs, physical to a page, logical within a page
The execution process of an update statement is:
data page to memory -> modify data -> update data page -> write redolog (status is prepare) -> write binlog -> commit transaction (redolog status is changed to commit);
The advantage of using two-phase commit is that if an unexpected situation occurs in the database, such as downtime, breakpoint, restart, etc., it can ensure that the data recovered using BinLog is consistent with the data state at the time;
The strategy in specific situations is as follows:
binlog has records, redolog status commit: normally completed transactions, there is no need to restore
binlog records, redolog status prepare: crash before the commit transaction is completed in binlog, recovery operation: commit transaction
binlog has no record, Redolog state prepare: crash before binlog is written, recovery operation: rollback transaction
binlog has no record, redolog has no record: crash before redolog is written, recovery operation: rollback transaction
summary:
Redo log is used to ensure crash-safe capability. When innodb_flush_log_at_trx_commit is set to 1, it means that the redo log of each transaction is directly persisted to disk. I suggest you set this parameter to 1 to ensure that data is not lost after MySQL restarts abnormally.
When the sync_binlog parameter is set to 1, it means that the binlog of each transaction is persisted to disk. I also suggest that you set this parameter to 1, so as to ensure that binlog is not lost after MySQL restarts abnormally.