MySQL redo log 與 binlog 的區別
1. 什麼是redo log?
redo log又稱重做日誌檔案,用於記錄事務操作的變化,記錄的是資料修改之後的值,不管事務是否提交都會記錄下來。在例項和介質失敗(media failure)時,redo log檔案就能派上用場,如資料庫掉電,InnoDB儲存引擎會使用redo log恢復到掉電前的時刻,以此來保證資料的完整性。
1.1 redo日誌檔名
每個InnoDB儲存引擎至少有1個重做日誌檔案組(group),每個檔案組至少有2個重做日誌檔案,如預設的ib_logfile0
和ib_logfile1
1.2 影響redo log引數
-
innodb_log_file_size
:指定每個redo日誌大小,預設值48MB -
innodb_log_files_in_group
:指定日誌檔案組中redo日誌檔案數量,預設為2 -
innodb_log_group_home_dir
:指定日誌檔案組所在路勁,預設值./
,指mysql的資料目錄datadir
-
innodb_mirrored_log_groups
:指定日誌映象檔案組的數量,預設為1,此功能屬於未實現的功能,在5.6版本中廢棄,在5.7版本中刪除了。
以下顯示了一個關於redo日誌組的配置:
mysql> show variables like 'innodb%log%';
+----------------------------------+------------+
| Variable_name | Value |
+----------------------------------+------------+
...
| innodb_log_file_size | 2147483648 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
...
+----------------------------------+------------+
15 rows in set (0.00 sec)
1.3 redo log大小怎麼設定?
redo log檔案的大小設定對於InnoDB儲存引擎的效能有著非常大的影響。
-
設定的太大
設定很大以後減少了checkpoint,並且由於redo log是順序I/O,大大提高了I/O效能。但是如果資料庫意外出現了問題,比如意外宕機,那麼需要重放日誌並且恢復已經提交的事務,如果日誌很大,那麼將會導致恢復時間很長。甚至到我們不能接受的程度。 -
設定的太小
當一個日誌檔案寫滿後,innodb會自動切換到另外一個日誌檔案,而且會觸發資料庫的檢查點(checkpoint),這會導致innodb快取髒頁的小批量重新整理,會明顯降低innodb的效能。 -
怎麼設定?
參考官方文件'Optimizing InnoDB Redo Logging'章節-
把重做日誌檔案設定很大,甚至與緩衝池一樣大。當InnoDB將重做日誌檔案寫滿時,它會觸發資料庫的檢查點,把緩衝池的髒資料寫入磁碟。小的重做日誌檔案會導致許多不必要的磁碟寫入。雖然在以前版本中,大的重做日誌檔案導致冗長的恢復時間,但現在恢復速度更快,可以放心地使用大型重做日誌檔案。
-
考慮增加日誌緩衝區的大小。 大型日誌緩衝區可以在事務提交之前執行大型事務,而無需將日誌寫入磁碟。 因此,如果您有更新,插入或刪除許多行的事務,則使日誌緩衝區更大可以節省磁碟I/O. 使用
innodb_log_buffer_size
配置選項配置日誌緩衝區大小。 -
設定
innodb_log_write_ahead_size
引數,表示redo log寫前的塊大小。InnoDB以512位元組一個block的方式對齊寫入ib_logfile檔案,但檔案系統一般以4096位元組為一個block單位。如果即將寫入的日誌檔案塊不在OS Cache時,就需要將對應的4096位元組的block讀入記憶體,修改其中的512位元組,然後再把該block寫回磁碟。當 當前寫入檔案的偏移量不能整除該值時,則補0,多寫一部分資料。這樣當寫入的資料是以磁碟block size對齊時,就可以直接write磁碟,而無需read-modify-write這三步了。
-
2. 什麼是binlog
binlog記錄了對MySQL資料庫執行更改的所有操作,但是不包括SELECT和SHOW這類操作,因為這類操作對資料本身並沒有修改。然後,若操作本身並沒有導致資料庫發生變化,那麼該操作也會寫入二進位制日誌。例如:
root@localhost [(none)] 08:30:14>set binlog_format = 'STATEMENT';
root@localhost [(none)] 08:30:26>use test;
Database changed
root@localhost [test] 08:30:33>select * from account;
+----------+---------+
| acct_num | amount |
+----------+---------+
| 138 | 14.98 |
| 141 | 1937.50 |
| 97 | -100.00 |
+----------+---------+
3 rows in set (0.00 sec)
root@localhost [test] 08:30:53>show master status;
+----------------------+----------+--------------+------------------+--------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------+----------+--------------+------------------+--------------------------------------------+
| my3306_binlog.000052 | 471 | | | e4382832-949d-11e8-97ba-080027793430:1-205 |
+----------------------+----------+--------------+------------------+--------------------------------------------+
root@localhost [test] 08:31:04>update account set acct_num=139 where amount=14;
Query OK, 0 rows affected (0.01 sec)
Rows matched: 0 Changed: 0 Warnings: 0
root@localhost [test] 08:31:35>show binlog events in 'my3306_binlog.000052';
+----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+
| my3306_binlog.000052 | 4 | Format_desc | 1003306 | 123 | Server ver: 5.7.23-log, Binlog ver: 4 |
| my3306_binlog.000052 | 123 | Previous_gtids | 1003306 | 194 | e4382832-949d-11e8-97ba-080027793430:1-204 |
| my3306_binlog.000052 | 194 | Gtid | 1003306 | 259 | SET @@SESSION.GTID_NEXT= 'e4382832-949d-11e8-97ba-080027793430:205' |
| my3306_binlog.000052 | 259 | Query | 1003306 | 331 | BEGIN |
| my3306_binlog.000052 | 331 | Table_map | 1003306 | 384 | table_id: 108 (test.account) |
| my3306_binlog.000052 | 384 | Update_rows | 1003306 |