MySQL interview questions - log

Table of contents

1. What are the common logs in MySQL?

2. What is the use of slow query logs?

3. What does binlog mainly record?

4. How many input formats does Mysql binlog have? What's the difference?

5. How does redo log guarantee the durability of transactions?

6. Why not just refresh the disk after the page is modified?

7. What is the difference between binlog and redolog?

8. How to restore the database to the state of any second within half a month?

9. How do redo log and binglog ensure the logical consistency between the two logs

10. How does undo log guarantee the atomicity of transactions?

---

1. What are the common logs in MySQL?

1. redo log: redo log, used to restore data, to ensure the integrity of the data after the MySQL abnormal downtime, only record the physical log (the log records the modification of the data page, not the logical modification), circular write, because there is no need to return Roll, so you can overwrite.

2. undo log: Undo log, used to roll back transactions, can guarantee the atomicity, consistency and isolation of transactions. Record the logical log, write circularly, and record the value before the transaction operation, which is convenient for rolling back the transaction.

3. binlog: Binary log, which records all operations that modify the database, including operations such as addition, deletion, and modification, and is used in scenarios such as data recovery and data replication.

4. error log: Error log, which records errors, warnings and other information that occur during the running of the MySQL engine, and is used for troubleshooting.

5. slow query log: slow query log, which records SQL statements whose execution time exceeds the threshold, and is used in performance tuning, query optimization and other scenarios.

6. general log: general log, which records all client queries and status change information, including query, connection, disconnection and other operations, and is usually used for problem diagnosis and security auditing.

7. Relay log: Relay log, used for data transmission in MySQL master-slave replication, copying data from MySQL master node to slave node.

2. What is the use of slow query logs?

The slow query log is a log used in MySQL to record SQL statements whose execution time exceeds the threshold, and is usually used to analyze performance problems. It can record each SQL statement whose execution time exceeds the specified threshold, and record information such as execution time, accessed tables, used indexes, and users who execute SQL, so as to help developers find the cause of slow queries and optimize solutions.

Slow query logs can help developers identify which SQL statements take a long time to execute, so that targeted optimization can be performed. Optimization methods include but are not limited to optimizing the writing of query statements, adding indexes, separating large tables, etc. By analyzing slow query logs, developers can gain a deeper understanding of system bottlenecks and performance issues, so as to formulate better optimization strategies.

The slow query log can be turned on and off by setting parameters slow_query_logand long_query_time. Among them, slow_query_logthe parameter is used to enable or disable the slow query log function, and long_query_timethe parameter is used to set the SQL statement whose execution time exceeds how many seconds will be recorded in the slow query log.

3. What does binlog mainly record?

binlog (binary log) is a log file of MySQL, which records all modification operations on data, including addition, deletion and modification of the database. It is an important feature of MySQL and the basis for data replication, data recovery and data security.

Binlog mainly records the following types of information:

        1. Database addition, deletion and modification operations

        Binlog records all additions, deletions and modifications to the database, including modifications to the table structure. In each write operation, MySQL will write the data of the operation into the binlog.

        2. Transaction commit and rollback information

        When a transaction commits, MySQL will write the transaction commit information into binlog. If a transaction is rolled back, MySQL will also write the rollback information into the binlog, and the information recorded in the binlog at this time can be used for data recovery.

        3. Status information of the database

The binlog records the status information of MySQL, including the version of MySQL, the ID of the server, and the ID of the thread executed.

Usage scenarios of binlog:

1. Data replication: MySQL's master-slave replication is implemented through binlog. The master library writes the modification operation to the binlog, and the slave library replicates by reading the binlog file of the master library.

2. Data recovery: all modifications to the database are recorded in the binlog, so the binlog can be used for data recovery.

3. Data backup: By backing up the binlog file, the data state at a certain point in time can be restored when needed.

It should be noted that the binlog records the modification operation of the SQL statement, not the row-level modification. Therefore, when restoring data, if there is a modification method using non-SQL statements, such as directly modifying files, it cannot be restored through binlog.

4. How many input formats does Mysql binlog have? What's the difference?

MySQL's binlog has three formats: statement, row, and mixed.

• statement format: records are SQL statements. The SQL statements executed on the master library will be recorded in the binlog, and the SQL statements will be replayed on the slave library to achieve master-slave replication. This format is relatively simple and is suitable for scenarios with small data volume and simple writing operations.
• Row format: records the changes of rows. Each row-level write operation performed on the master library will be recorded in the binlog, and the corresponding row will be modified on the slave library to achieve master-slave replication. This format is relatively complex, but it is suitable for scenarios with a large amount of data and frequent write operations.
• Mixed format: The two formats of statement and row are mixed. MySQL will choose which format to use according to the specific operation. This format can take into account the advantages of the above two formats, but it is more complicated to implement.

5. How does redo log guarantee the durability of transactions?

In MySQL, redo log is mainly used to ensure the persistence of transactions, and its implementation is as follows:

When a transaction is committed, the InnoDB engine will first cache the redo log of the transaction into the redo log buffer in the memory, and update the corresponding data page in the memory at the same time; then at the appropriate time, the redo log in the redo log buffer Write to the redo log file on the disk to ensure that the transaction can be recovered through the redo log in abnormal situations such as crashes.

When writing to disk, MySQL will write the redo log file into a circular queue consisting of two files. The size of each file is innodb_log_file_sizecontrolled , and the default value is 48MB. When writing, it will start writing from the first file in order until it is full, and then continue to write to the next file.

Because the redo log is written to the disk sequentially, it can improve the efficiency of writing to the disk. At the same time, the redo log adopts a circular queue method, which can realize overwriting and save disk space.

InnoDB's redo log has a fixed size. For example, it can be configured as a set of 4 files, each with a size of 1GB.

The write pos is the position of the current record. It moves backward while writing, and returns to the beginning of file 0 after writing to the end of file No. 3. The checkpoint is the current position to be erased, and it is also moved backwards and cyclically. Before erasing the record, the record must be updated to the data file.

Between write pos and checkpoint is the part of the "pink board" that is still empty, which can be used to record new operations. If the write pos catches up with the checkpoint, it means that the "pink board" is full, and no new updates can be performed at this time. You have to stop and erase some records first, and advance the checkpoint.

With the redo log, InnoDB can ensure that even if the database restarts abnormally, the previously submitted records will not be lost. This capability is called crash-safe .

6. Why not just refresh the disk after the page is modified?

In a database, modifying data refers to modifying data pages in memory, rather than directly modifying data files on disk. The main reason for this is to improve write performance and ensure data consistency.

If you write directly to the disk every time there is a modification operation, it will seriously affect the write performance. Also, frequent disk writes can shorten the life of the disk. Additionally, writing modifications directly to disk can lead to data inconsistencies, such as in the event of operating system or hardware errors or interruptions.

Therefore, databases usually use a technology called "Write-Ahead Logging (WAL)" to record modifications to data in log files. Before writing to the disk, the modification operation will be recorded in the redo log to ensure the persistence and atomicity of the transaction. Only when the transaction is committed, the modification operation in the redo log will be synchronized to the data file on the disk, so that the consistency and durability of the data can be guaranteed.

When the system crashes or restarts, data files can be recovered through redo log replay. This is because, in the database, when a transaction commits, the data in the redo log will be written to the data file on the disk first, and then the identifier of the transaction commit will be written into the redo log. Therefore, when the database starts, you only need to replay the operations in the redo log to restore the data to the latest state.

7. What is the difference between binlog and redolog?

1. Redo log (redo log) is a log implemented by the InnoDB storage engine itself to ensure the durability of transactions. When the data in the InnoDB table is modified during transaction execution, InnoDB will first record the modification operation in the redo log and update the data page in memory. Before the transaction is committed, InnoDB will write the redo log to disk to ensure data persistence. The redo log is written to disk in a circular way and can be reused. The size of the redo log is fixed and can be set innodb_log_file_sizeby .

2. Binlog (archive log) is a log implemented by the MySQL database service layer, which records all update operations of the database, including what operations are performed on which table of which database. Binlog is used in scenarios such as master-slave replication and database recovery. Log records in binlog are written sequentially and are not reused. The size of binlog is variable and can be set max_binlog_sizeby .

The two logs differ in the following three points.

1. The redo log is specific to the InnoDB engine; the binlog is implemented by the MySQL server layer and can be used by all engines.

2. Redo log is a physical log, which records "what modification was made on a certain data page"; binlog is a logical log, which records the original logic of this statement, such as "add 1 to the c field of the row ID=2" .

3. The redo log is written cyclically, and the space will always be used up; the binlog can be appended. "Append write" means that after the binlog file is written to a certain size, it will switch to the next one, and will not overwrite the previous log.

8. How to restore the database to the state of any second within half a month?

Binlog will record all logical operations, and it adopts the form of "append writing". If your DBA promises that it can be restored within half a month, then all the binlogs of the last half month will be saved in the backup system, and the system will regularly back up the entire database. The "regular" here depends on the importance of the system, which can be once a day or once a week.

When you need to restore to a specified second, for example, at 2 o'clock in the afternoon one day, you find that a table was accidentally deleted at 12 o'clock in the noon, and you need to retrieve the data, then you can do this:

• First, find the latest full backup. If you are lucky, it may be a backup from last night, and restore it to the temporary library from this backup;
• Then, starting from the time point of the backup, take out the backup binlog in sequence, and replay it to the moment before the table was accidentally deleted at noon.

In this way, your temporary database is the same as the online database before the accidental deletion, and then you can take the table data out of the temporary database and restore it to the online database as needed.

9. How do redo log and binglog ensure the logical consistency between the two logs

The logical consistency of redo log and binlog is guaranteed by two-phase commit. When performing modification operations, MySQL will first record these operations into the redo log, and then record these operations into the binlog. Due to the different record order of redo log and binlog, there may be logical inconsistencies between them. In order to ensure logical consistency, MySQL introduces a two-phase commit mechanism.

In the two-phase commit, MySQL will first record the modification operation to the prepare phase in the redo log, and the transaction is not committed at this time. Then MySQL records these operations to binlog and marks the transaction as prepare state. Finally, in the commit phase, MySQL will change the transaction from the prepare state to the commit state, and submit the operations in the redo log to the disk at the same time. This ensures the logical consistency between redo log and binlog.

It should be noted that in the two-phase commit, if an error occurs in the prepare phase, MySQL will roll back the transaction and mark the corresponding operation in the binlog as rollback. In this case, there will be no logical inconsistency between redo log and binlog.

The logical consistency of redo log and binlog is guaranteed by two-phase commit, which is also the key for MySQL to realize A (atomicity) and C (consistency) in ACID.

10. How does undo log guarantee the atomicity of transactions?

The undo log is a mechanism used by the InnoDB storage engine to implement transaction atomicity and rollback operations. When a transaction is modified, InnoDB will first write the data before modification to the undo log, and then modify the data. If the transaction is rolled back, the information in the undo log can be used to restore the data to the state before the modification. In order to achieve the atomicity of the transaction.

Specifically, when a transaction starts, InnoDB will open an undo log for the transaction, and all data modifications made by the transaction will be written into the undo log first, and then the data will be modified. When a transaction is committed, all data modifications will be written to the redo log at one time, and then the transaction's commit status will be written to the redo log, indicating that the transaction is committed successfully.

If an error occurs during transaction execution and causes a rollback, InnoDB will use the information in the undo log to restore the data to the state before modification. When the transaction is rolled back, InnoDB will reverse the data modification operation of the transaction, that is, restore the modified data to the data before modification, and then write these operations into the redo log, indicating that the transaction rollback is successful.

The undo log is mainly used to ensure the atomicity and rollback of transactions. When the transaction execution fails, the information in the undo log can be used to restore the data to the state before modification, thus avoiding data damage and inconsistency.