Shulou(Shulou.com)06/01 Report--

There are six kinds of log files in MySQL

They are redo log (redo log), rollback log (undo log), binary log (binlog), error log (errorlog), slow query log (slow query log), general query log (general log), relay log (relay log).

Among them, redo log and rollback log are closely related to transaction operations, and binary logs are also related to transaction operations. These three kinds of logs are of great significance for understanding transaction operations in MySQL.

Here is a brief summary of the logs in which these three are related.

Redo log (redo log)

Function:

Ensure the persistence of the transaction.

Prevent dirty pages from being written to disk at the point of failure, and redo them according to redo log when the mysql service is restarted, so as to achieve transaction persistence.

Content:

The log in physical format records the modification information of the physical data page, and its redo log is sequentially written into the physical file of redo log file.

When will it come into being:

Redo log is generated after the start of the transaction, and the drop of redo log is not written with the commit of the transaction, but begins to be written into the redo log file during the execution of the transaction.

When will it be released:

When the dirty pages of the corresponding transaction are written to disk, the mission of redo log is completed, and the space occupied by the redo log can be reused (overwritten).

Corresponding physical files:

By default, the corresponding physical files are located in ib_logfile1&ib_logfile2 under the data directory of the database

Innodb_log_group_home_dir specifies the path where the log filegroup is located. / by default, it is in the data directory of the database.

Innodb_log_files_in_group specifies the number of files in the redo log filegroup. The default is 2.

The size and number of files are configured by the following two parameters

Size of the innodb_log_file_size redo log file.

Innodb_mirrored_log_groups specifies the number of log image filegroups. The default is 1.

Other:

It's very important. When did redo log write the disk? As mentioned earlier, the disk is written step by step after things begin.

The reason for saying that the redo log is to write the redo log file step by step after the start of the transaction, not necessarily the transaction commit before writing to the redo log cache.

The reason is that the redo log has a cache Innodb_log_buffer, and the default size of Innodb_log_buffer is 8m (16m set here), and the Innodb storage engine first writes the redo log to innodb_log_buffer.

The logs of the innodb log buffer are then flushed to disk in the following three ways

1, Master Thread performs a refresh of Innodb_log_buffer to the redo log file once a second.

2, the redo log is flushed to the redo log file when each transaction is committed.

3, when the free space of the redo log cache is less than half, the redo log cache is flushed to the redo log file

As you can see, the redo log is written to disk in more than one way, especially for the first, where Innodb_log_buffer to redo log files is a scheduled task for the Master Thread thread.

Therefore, the write disk of the redo log is not necessarily written to the redo log file with the commit of the transaction, but starts gradually with the beginning of the transaction.

In addition, I quote from the "MySQL Technology Insider Innodb Storage engine" (page37):

Even if a transaction has not been committed, the Innodb storage engine flushes the redo log cache to the redo log file every second.

This is important to know, because it can well explain that the commit (commit) time of even a large transaction is very short.

Roll back the log (undo log)

Function:

A version of the data before the transaction is saved, which can be used for rollback, while providing MVCC under multi-version concurrency control, that is, unlocked read.

Content:

Logically formatted logs, when performing undo, only logically restore the data to the state before the transaction, rather than manipulating from the physical page, which is different from redo log.

When will it come into being:

Before the transaction starts, the current version is generated into undo log, and undo also generates redo to ensure the reliability of undo log.

When will it be released:

Undo log cannot be deleted immediately after the transaction is committed

Instead, it is put into the linked list to be cleaned, and it is up to the purge thread to determine whether other transactions can clean up the log space of the undo log before using the version information of the previous transaction in the table in the undo segment.

Corresponding physical files:

Prior to MySQL5.6, undo tablespaces were in the rollback segment of the shared tablespaces, and the default name of the shared tablespaces was ibdata, which was located in the data file directory.

After MySQL5.6, the undo table space can be configured as a separate file, but it needs to be configured in the configuration file in advance. It takes effect after the database initialization is completed, and the number of undo log files cannot be changed.

If the database is not configured before initialization, it cannot be configured as a separate tablespace.

The configuration parameters for independent undo tablespaces after MySQL5.7 are as follows

Innodb_undo_directory = / data/undospace/-the directory where undo independent tablespaces are stored

Innodb_undo_logs = 128-rollback segment is 128KB

Innodb_undo_tablespaces = 4-4 undo log files are specified

If undo uses a shared tablespace, not only the information of undo is stored in this shared tablespace, the shared tablespace defaults to the data directory of MySQL, and its properties are configured by the parameter innodb_data_file_path.

Dns8b+B7Z/2gQ8IoEhEij8xJ6sOF/wam1eOsX4Mnm9ySPSdcBuB0ynI+zUpg8HXvAMvXVI1xflyVlxftkGKtn8ZOp/f5ANJWmatiHdIFWvX2T0Ji5tn1l/mpY/Mn1XPiHdLKZvm5tlLPs3G4zn8aau3Qqz9we10czcSKY5nWtf3uLbTSmL36ZEyuRL27ci/q34sjZAHbDZhJjPp9YmKbZ/01ZiuTICZfFbVp7pzQlYD8f5gJybLG51A4P2mxtE2Ad0LNziL+O/n/jv/jZy80GeJUmABEiABEjgJggU3ka+Cc/pJAmQAAmQAAl8E4HOdyN/k93DqsZ6llZkmvHiiaJsppEACZAACVw1Aa5sr7p56RwJkAAJkMAQCPCZ7RBagTaQAAmQAAlcNQEOtlfdvHSOBEiABEhgCAQ42A6hFWgDCZAACZDAVRPgYHvVzUvnSIAESIAEhkCgeLB1vP5eSzgEr2kDCVQRYPxX0WHetRNg/PfSwsWDbS9VUSkJkAAJkAAJ3CYBDra32e70mgRIgARI4BsJpP/OtuLFDFUfCkhflF73In/mF31ogfz0Cz8uHB+M/8IPgTA+BxKftR9iadl/auP/G0elK64q9yECON7Rdyf5dPTzguZbfNk3fR5wLDH+2fdv+VrH+O8l/nkb+YpnUXSNBEiABEhgGAQ42A6jHWgFCZAACZDAFRNIn9lesZN0jQRIgARIgAQuSYAr20vSZ90kQAIkQAI3QYCD7U00M50kARIgARK4JAEOtpekz7pJgARIgARuggAH25toZjpJAiRAAiRwSQIcbC9Jn3WTAAmQAAncBAEOtjfRzHSSBEiABEjgkgQ42F6SPusmARIgARK4CQKFg+3E9Vt9Ys/xglby3ZCXd4UGCHxXqRObgsCHO+lGO9S7SlP9XWntQk/kq/gb/ec5ttay9pF21zJ+d6Dsyns607ZnfT2nuj7i//T4s+P3HD/OkdGxc27718m7fhqX0jcdr8s+eY7H1ypzfvy0jf9rJdqFX7n3QE5c/0rejewcPd9N/HN9/+hOunwnr62/yfuOXd87On2+d3XiHn3D5yY2ZcsMuf2r+IndntO+ffvy//T4+974Er8Dzzme+270OnnHC6zriiofdN0nq9u/Kn6y/aCP8++t//T4EZ/7iv8+eP4knf90MVprHTIjepuP1Olh8xuL9V5nQeftdjtMp9M4XX9RA7X5WpHMjOMqkH6RJM7NfLlit1ppsfT3lwv/bY7YSmx+L2CYmZYrOqrT73gInrVvgMXAlA0CPMf6oy8qxSdV8kX2ZNJkVaGrD4J5lHvYYLZYq2PdBnJi2ZbRU3pq+hApSXSXysQZUbsdsNmEmM81o4PNv8p/s+4yflLXnQs/0O2bxledfV3kN+JbFX+mjxLd2fhty6dKHsB+vcBMQDgPFTj012XybCvlJy4exxssluk1QZWPQtOor1w/KuzX7HV/0n0hiXOTbUX8nHJ9gdG3YOhXNkBfC+IYh4HdKavf0KGAGPoT/0qun6p8Rj4XPwZlHl6GQLLy07OEtjObMvloJpuu7LLl6vJd354Zyww8SFZxztGzZslyHhj5OIp8YJaRVWCQ2qP9L/6t1w/HsVatUl92pVU5s20gX2ybMZtvsLLNcs/qLMvPrsxUeyX8DRtKVu4Rf4N3ln8D/6v4RfGTrpTK/Mj6mz0/V07rKZOvjr8BxVflV1/iflXVb4rki9IK46RCf018CHervxXUWRU/0j7W186s64tcP9LYkraW+tLrD45Q8RyXUcen9f86/ao+g7sdZw3ip5B3vt/aevP5Os75exqbTle2TeYKu9US27jg/isE7myp0vyJi/twZa2WsV1i9SDPfNZY/3rAePOKdOK8xfL3HfyXrH5jJbtf43Xj48kBttoou3h75jTQ/3mHR2PWKsK7VEP9UVv5+hrOLyH8RyOM3gLEa+ZY1xjySLgOn67YbF9k+Xfg/26Vtm9RfGk7LvVr2mf5j58SX1ssZ01bu4yyXr3G+bsVZkuts0J/B/FRZpGsTCuvL2gQ / / s1Fr8BX/URWdHOTrpr1qR/mf3Hiu8m16dS55nxHQS+fbD9DqfK6zgg/CzPbZfjwHu7x4fRweTWz1NjpW3lG1d0XsH9F8LDBov4lvR5Sqr4D9z/8xzOSFX5nymaO23Lp618zqDTEj5D4OGX3KxWUzM9YMsGqbs/eqCtUnlh+5vG/69x/IhqhLF2t8otnddUvy7P3x9HoHA38iC92K/xMX7M7CZ28DD+iGaP23eE8ye1ytL2O0/62Z1OGWH+Eu1OVikTFy/zEO9N+nqd/skdxofYFlGudEdPhnXt0e8Yd3pHtDyDCrzI5sbytrbvO9viPZy33GWe4Q/g3/uYf2P/S/h9H4gWNWX8N+Pvx8RXvMtVx21TGoX9t0i4RH/D+BjrziXPL/UGBquakvgptM+4vqA+/mVyHTwDq9kMs9kKeC76Vxkl9TfQb7mRPamLn2x5nn87gcJP7EnQvODVvmVba1rm1lBSPtpI8WlsnrI3EESbdV7xkmyuKspXm60yGwCkCr0hQlWX2UCB3Q676RTTwwarcI7n6UGSMJ3qQTCzQSexueSgQr9sQtKbGCLptK5yG+1NJo3kS0yTZHtzR1wwuUVX3T5b9U+ZnqG3LqXV2Dbm67DzU7n8kev7GIcmf3ujViP/rTZI6zZlS+Mnb1JhiujqOv6hNq+lMRFVnIk/yzcJ7jR+vyO+9KYiC4qxSSdK13GUstfla+UL+i+S+Ey0wAskDvP6zTYGUpZJ/7L0p5vxkk1SUoXFOFOHJR/Zk+iOzSuL/7rrW7JZtKr+wj4c2dhIv6U7Hz+acN3vefFfp5X5QqDzDVJFOpmW53xrTLIbQIbqPzeIMFaHGpvfYRfjv5/4/zm3kTkx+tEEohXBCPO3Yb4I5EfDpfEkQAKDJ1B4G3nwVtNAEiABEiABEvhBBG5sN3JJyxQ8q7FLZp7t2Jn9n9G+/hmzBhIgARLokQBXtj3CpWoSIAESIAESEAJ8Zss4IAESIAESIIGeCXCw7Rkw1ZMACZAACZAAB1vGAAmQAAmQAAn0TICDbc+AqZ4ESIAESIAEigdbx2v5Wj6CJYEfTIDx/4Mbj6a3JsD4b42wSEHxYFtUkmkkQAIkQAIkQAJnEeBgexY2CpEACZAACZBAcwLpv7OteHFC9DJu/QLyrHL9wgfmRy9QJx+bwA+JD8Z//AEAu/Xki8yrmXyDmv37qvt3bfxn44Ln5xDIfYgAjnf03Uk+veCjBd/xYmzW0c+Lscm1hCvjn33/lq91jP9e4p+3kc+ZnlCGBEiABEiABE4gwMH2BFgsSgIkQAIkQALnEEif2Z4jTRkSIAESIAESIIFaAlzZ1iJiARIgARIgARJoR4CDbTt+lCYBEiABEiCBWgIcbGsRsQAJkAAJkAAJtCPAwbYdP0qTAAmQAAmQQC0BDra1iFiABEiABEiABNoR4GDbjh+lSYAESIAESKCWAAfbWkQsQAIkQAIkQALtCOQGW8cLEATBj/7Envjgu5N2ZH6AtOv7yLo5cX3VftKGgeec7EWd/KDjQ97v6rsn+0wBEiABEvgOAsl7ICeufww858h4I5e8M7eD96W6vnd0OtAjbaTaytQlab6btKfjBUfPOcGXGvmfEB8n+2zy43ESO3xv9gn9hnHDuGkQA/+Yo/l+vcBMEpwHM7nxsesHmI+Aw+Y3XvGCNzlJvhoSqdFlojP9RREgSd+tMFtuVbasop6nEIWYLda1dsiqLKozsmGx3icyOm+322E6FaXyl9YfJ9T+JHZKycMBB3xgoW3LfjnDtNvMCwI8xzVFX1SqrTZXwH2cYvd3aaU7D2NsXtO07Z8NHp8cYBvxtAoXnNTJt40PqfJsfrG9SUzI+WGDDe6B1wV0UyufX1xgWx8vBQiYRAIkQAK9EcjPStp89UFWR0GQrrAcL1lduX5gf03IXElN3KMvq+rMDMHx/KM7OW2WKSuwoq8WqZVZkK4sy8plbdDn2fKyijJXkq5v26rqM1aaoqebla1z9Aw/tH05VsI0U78uW/TbWP7M+GjLT/E2YkTxDWzmgLDJpp0WP0VsmEaGjAHGQJsYsFa2XQ3nsrJNVpXbJdRaa+LiPlyl6VLZdonVgzx3XGO9X+Nj7MHBFneyQoasZr/wMP7AMl2gtjZxt5Jvc0Z/+68QuGuucr/+izB4QzDXMrIyjldQ4t9ohNGb2G7+jSFPTnWdZs7Zx5M7jM8WvpxgO34OHsYSEylJtdLOLWC3CA/PGP8C0GHcXI4aayYBErgGAr0MtueC+QrHuJs4GGODVXgP1wHG4de56nqQ22I5Sy/2cDwEvout3EbefyE8bNJbyj3UXq9ylB9kTuLXVr7OwqHzq7Of+SRAAiRwHoHcbuTz1DSQUivXx8zuWVmtfKTP295DjJ8eMP74D9v3EPeP9wjfjcGtQTV9Fina/YtkMNviPZw32AUtE4rYShmsA1nNn/gnA3uBiDyvTJUDztO8gJ8DT3YqF9TbTL6g4oZJ7fgV8Y18sTddOxiPDgg/GxrFYiRAAiTwDQSsla21+QTT6Hapucmn0iC58D0j2noUy8oWpNUM8X4nrF8/4Gdus0p+8vcZYvx8j48/e2D/jvD58YSLplm/aNS3e6NNUJ/J5qkAHmZYwkOgdl9N4cO47Z0YU3QwwtyyX3Snk4HtcqZugae3mUWHvQlr/TdEkOiw84pqLE6LbpU+ZPc+7dcIX4L0NrdsNkvNK1ZlptbIt4sPqagdvyK+ZnwpV+QW+6HbRw8mIh7TAAmQwDkE+D3bc6gNQUZWxQ/vyc7tIZg0BBtkQvDwnk7whmATbSABEiCB77uNTNbdEtgusRlnb8t3W8WP0zZx8TjeJHdSfpz9NJgESOBqCXBle7VNS8dIgARIgASGQoAr26G0BO0gARIgARK4WgIcbK+2aekYCZAACZDAUAhwsB1KS9AOEiABEiCBqyXw/0ZKbqIR53gdAAAAAElFTkSuQmCC ">

Other:

Undo is a version of modified data that is saved before the transaction starts, and the generation of undo logs is also accompanied by the generation of redolog similar to the protection transaction persistence mechanism.

By default, the undo file is kept in the shared tablespace, that is, the ibdatafile file. When some large transactional operations occur in the database, a large amount of undo information is generated, all saved in the shared tablespace.

As a result, shared tablespaces may become very large, and by default, when undo logs use shared tablespaces, shared tablespaces that are "enlarged" will not and cannot be automatically shrunk.

Therefore, the configuration of "separate undo tablespaces" after mysql5.7 is necessary.

Binary log (binlog):

Function:

1, used for replication. In master-slave replication, the slave library replays using the binlog on the master library to achieve master-slave synchronization.

2, a point-in-time restore of the database.

Content:

Logically formatted logs can simply be thought of as sql statements in executed transactions.

But it is not as simple as the sql statement, but includes the reverse information of the executed sql statement (addition, deletion and modification).

This means that delete corresponds to delete itself and its reverse insert; update corresponds to the information of the version before and after the execution of update; and insert corresponds to the information of delete and insert itself.

Some of the truth will come out after parsing binlog using mysqlbinlog.

Therefore, the flashback function similar to oracle can be achieved based on binlog, which actually depends on the logging in binlog.

When will it come into being:

When a transaction is committed, the sql statements in the transaction (one thing may correspond to multiple sql statements) are recorded into binlog in a certain format at one time.

The obvious difference between redo log and redo log is that redo log is not necessarily flushed to disk when the transaction commits, and redo log starts to write to disk gradually after the transaction begins.

So commit is fast for transactions, even for larger transactions, but when bin_log is turned on, commits for larger transactions may become slower.

This is because the binlog is written once when the transaction commits, which can be verified by the test.

When will it be released:

By default, the hold time of binlog is configured by the parameter expire_logs_days, which means that inactive log files will be deleted automatically after the generation time exceeds the number of days configured by expire_logs_days.

Corresponding physical files:

The path of the configuration file is log_bin_basename, and the binlog log file is of the specified size. After the log file reaches the specified maximum size, the log file is scrolled and updated to generate a new log file.

For each binlog log file, it is organized by a unified index file.

CDNLxlIf//vy0J+PsP2zB/af8ObTBideU79I1EvX4cayr3hDmoKDMRZwoIIdbUO4MJbwY2PyvvQwSdkvspMLis1iHCznJ0vmIiO9sW314UHFMtJ1eRrzy8Jl3+fsfrL9Ct6rSpbsZQNfYl6+KLO0ov958SGKzuOXx9eMr2AocrvAv+xtFBMRv5MACZDAXQgUbjrLbPy654126i7Y6CEb9owNWOQUcuKfdRXEC4/pow2tPGYYK22Kgdsuid/lkuQHK90ssO5nbzH84PHWGdrAxrS/jld06nRhGxIgARJoA4G/JMP+9etXG2yljSRAAiRAAiTQWQLMsDvreg6cBEiABEigTQQ4YbfJW7SVBEiABEigswQ4YXfW9Rw4CZAACZBAmwhwwm6Tt2grCZAACZBAZwlwwu6s6zlwEiABEiCBNhH4H0G/jmQnBPsTAAAAAElFTkSuQmCC ">

Other:

One of the functions of binary logs is to restore databases, which is very similar to redo log. Many people have confused it, but there are fundamental differences between the two.

1, the function is different: redo log ensures the persistence of transactions and is at the transaction level. Binlog, as a restore function, is at the database level (of course, it can also be accurate to the transaction level). Although it all means restore, the level of data protection is different.

2, the content is different: redo log is a physical log, a physical record after the modification of the data page, and binlog is a logical log, which can be simply thought of as a sql statement.

3, in addition, the time at which the logs are generated, the time that can be released, and the cleaning mechanism where they can be released are all completely different.

4. The efficiency of recovering data. The efficiency of redo log based on physical log is higher than that of binlog of statement logical log.

With regard to the writing order of redo log and binlog when a transaction is committed, in order to ensure that the master-slave replication is consistent (of course, it also includes the use of binlog for point-in-time restore), it is strictly consistent.

MySQL achieves transaction consistency through a two-phase commit process, that is, the consistency of redo log and binlog. Theoretically, redo log is written first, and then binlog is written. Only when both logs are committed successfully (flushed to disk), the transaction is really completed.

Reference: http://www.cnblogs.com/hustcat/p/3577584.html

Summary:

In MySQL, each of the above three kinds of logs is detailed enough to write a chapter. Here is a rough summary of some of the characteristics and functions of the three kinds of logs to help understand the things in MySQL and the principles behind them.

Mysql redo Log and its difference from binary Log

Mysql redo log and its difference from binary log (to http://blog.uouo123.com/post/623.html)

By default, Mysql has two files: ib_logfile0 and ib_logfile1, which are the redo log files, or transaction logs.

The purpose of redoing the log: in case the instance or media fails, the redo log file can be useful.

Each InnoDB storage engine has at least one redo log filegroup and at least 2 redo log files under each filegroup, such as the default ib_logfile0 and ib_logfile1. The InnoDB storage engine first writes redo log file 1, when it reaches the end of the file, it switches to redo log file 2, and when redo log file 2 is also full, it is switched to redo log file 1.

Parameters that affect the redo log:

Innodb_log_file_size, innodb_log_files_in_group, and innodb_log_group_home_dir affect the properties of log files.

VPSVjlZsvFbD8jU3AruPU5S8Gt4LZKJDupX1U24qEA0Mu+22eTabD1lffBHDNWnZTJtJ9Z79h+snWx5XzzE6rbzHgUyRTcCm4bjaLG3okzhie4Fdz6HK/gVnAruG32iZY+m+wkaMYMwLD9ZGCOWe8Et+2aE3PMfGOrtIQeBOrYhudTElYhmXKCW8Gtb4ER3ApuBbeC204Cdew11lcfs3bGjrayMn3+mtl8KHLbg6DJTGyIEjUJmorc1guaMXWjSIdCHQerj90kM704+BaLkIUg3c8qYFV2bJuQmV6kBoNMpSX8r+0x8XnjEQIwsdaobpYZ078w/SzrN6rMJyuTab9PJ0LXqBgyFbntQaCObXg+xWSNgCmnyG29QB1TNwS39d2A1AmgFtzWN59NbWTT/jOW7w6BicEgM6YfZcaWWTtDNuwxZTJ1+XRCcNuDoBnTqcWsizWWpmUKbgW3PmeptITpVsnaMFtOcCu4rRLpS64VZWw4S/8YiIy5Rvna7YO0MleQGJmsDbPlYspk6vKNm+BWcNuy44F6OU1wK7j1OUvBreA2b7FkYciVG6h+dDCBpuA2fFPm87Ehm2emLsHtjGhEGYr3DV5saGINii3HOmWmn0xdITu8JmXGnif20nnMeepmmTF1g+1nEzLLRExYG+hEikAnZCpyGw4JrA415V/S/jOW7w4BmMEgM6ZPY8aW1TO2XEyZTF0+nSjDfMwcFLVNObc9GC1mJj3ECHyKydbFlBPcKnLrc5aK3Cpyq8itTktIR6fL+I2sDR27fsZaF33tDomiMmss0+4QmUz7fTIFtz0ImjF37DHrCjECn2KydTHlBLeCW5+zFNwKbgW3glvBbZ8fqAMOmfWaYQOGW+pov69titz2IFCzO0+mHKOYrBEw5QS3glvBbf+bxarAHGN3WfUPBplFPpDxjyFj61ts2brYcjF9t88mOwmanehnbN3w1cfOOVuOmc+Ydfl0X3Dbg6AZ2/B8SsIqJFsuZvsZmYJbwa3P8Spyq8htFfBO6pfgVufchqw5zPpbB6gxa6fTax8os31gZfr8NcMQdYyZr5//HzsjGEING1yUAAAAAElFTkSuQmCC ">

The difference between redo logs and binary logs:

1) the binary log records all mysql-related logs, including those of other storage engines such as InnoDB, while the redo log of the InnoDB storage engine records only its own transaction logs.

2) the content of the record is not tolerable. no matter which format you set the binary log file to, it records the specific operation of a transaction, while the redo log file of the InnoDB storage engine records the physical changes of each page.

3) the time of writing is also different, the binary log file is recorded before the transaction is committed, and in the process of the transaction, redo log entries are constantly written to the redo log file.

Conditions for writing redo log files on disk from log buffers:

Every second in the main thread, the redo log buffer is written to the redo log file on disk, regardless of whether the transaction is committed or not. Another trigger for this process is controlled by the parameter innodb_flush_log_at_trx_commit, which indicates how the redo log is handled at the time of commit.

The values that can be set for the parameter innodb_flush_log_at_trx_commit are 1 and 2. 0 means that when a transaction is committed, the redo log of the transaction is not written to the log file on disk, but waits for the refresh of the main thread every second. The difference between 1 and 2 is that 1 synchronously writes the redo log buffer to disk during commit. 2 is that the redo log is written asynchronously to disk, that is, there is no complete guarantee that the redo log file will be written when commit, but there is only this action.

It is worth noting that because the redo log has a capacity variable, this value means that the last checkpoint cannot exceed this threshold.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.