版權聲明:本文爲博主原創文章,未經博主容許不得轉載。 https://blog.csdn.net/a724888...前端
微信公衆號【黃小斜】大廠程序員,互聯網行業新知,終身學習踐行者。關注後回覆「Java」、「Python」、「C++」、「大數據」、「機器學習」、「算法」、「AI」、「Android」、「前端」、「iOS」、「考研」、「BAT」、「校招」、「筆試」、「面試」、「面經」、「計算機基礎」、「LeetCode」 等關鍵字能夠獲取對應的免費學習資料。 mysql
MySQL日誌文件系統的組成
a、錯誤日誌:記錄啓動、運行或中止mysqld時出現的問題。
b、通用日誌:記錄創建的客戶端鏈接和執行的語句。
c、更新日誌:記錄更改數據的語句。該日誌在MySQL 5.1中已再也不使用。
d、二進制日誌:記錄全部更改數據的語句。還用於複製。
e、慢查詢日誌:記錄全部執行時間超過long_query_time秒的全部查詢或不使用索引的查詢。
f、Innodb日誌:innodb redo log程序員
缺省狀況下,全部日誌建立於mysqld數據目錄中。
能夠經過刷新日誌,來強制mysqld來關閉和從新打開日誌文件(或者在某些狀況下切換到一個新的日誌)。
當你執行一個FLUSH LOGS語句或執行mysqladmin flush-logs或mysqladmin refresh時,則日誌被老化。
對於存在MySQL複製的情形下,從複製服務器將維護更多日誌文件,被稱爲接替日誌。面試
二、錯誤日誌
錯誤日誌是一個文本文件。
錯誤日誌記錄了MySQL Server每次啓動和關閉的詳細信息以及運行過程當中全部較爲嚴重的警告和錯誤信息。
能夠用--log-error[=file_name]選項來開啓mysql錯誤日誌,該選項指定mysqld保存錯誤日誌文件的位置。
對於指定--log-error[=file_name]選項而未給定file_name值,mysqld使用錯誤日誌名host_name.err 並在數據目錄中寫入日誌文件。
在mysqld正在寫入錯誤日誌到文件時,執行FLUSH LOGS 或者mysqladmin flush-logs時,服務器將關閉並從新打開日誌文件。
建議在flush以前手動重命名錯誤日誌文件,以後mysql服務將使用原始文件名打開一個新文件。
如下爲錯誤日誌備份方法:
shell> mv host_name.err host_name.err-old
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory算法
1 – Undo Logsql
Undo Log 是爲了實現事務的原子性,在MySQL數據庫InnoDB存儲引擎中,還用Undo Log來實現多版本併發控制(簡稱:MVCC)。shell
事務中的全部操做,要麼所有完成,要麼不作任何操做,不能只作部分操做。若是在執行的過程當中發生
了錯誤,要回滾(Rollback)到事務開始前的狀態,就像這個事務歷來沒有執行過。數據庫
Undo Log的原理很簡單,爲了知足事務的原子性,在操做任何數據以前,首先將數據備份到一個地方
(這個存儲數據備份的地方稱爲Undo Log)。而後進行數據的修改。若是出現了錯誤或者用戶執行了
ROLLBACK語句,系統能夠利用Undo Log中的備份將數據恢復到事務開始以前的狀態。segmentfault
除了能夠保證事務的原子性,Undo Log也能夠用來輔助完成事務的持久化。緩存
事務一旦完成,該事務對數據庫所作的全部修改都會持久的保存到數據庫中。爲了保證持久性,數據庫
系統會將修改後的數據徹底的記錄到持久的存儲上。
假設有A、B兩個數據,值分別爲1,2。
A.事務開始.
B.記錄A=1到undo log.
C.修改A=3.
D.記錄B=2到undo log.
E.修改B=4.
F.將undo log寫到磁盤。
G.將數據寫到磁盤。
H.事務提交
這裏有一個隱含的前提條件:‘數據都是先讀到內存中,而後修改內存中的數據,最後將數據寫回磁盤’。
之因此能同時保證原子性和持久化,是由於如下特色:
A. 更新數據前記錄Undo log。
B. 爲了保證持久性,必須將數據在事務提交前寫到磁盤。只要事務成功提交,數據必然已經持久化。
C. Undo log必須先於數據持久化到磁盤。若是在G,H之間系統崩潰,undo log是完整的,
能夠用來回滾事務。
D. 若是在A-F之間系統崩潰,由於數據沒有持久化到磁盤。因此磁盤上的數據仍是保持在事務開始前的狀態。
缺陷:每一個事務提交前將數據和Undo Log寫入磁盤,這樣會致使大量的磁盤IO,所以性能很低。
若是可以將數據緩存一段時間,就能減小IO提升性能。可是這樣就會喪失事務的持久性。所以引入了另一
種機制來實現持久化,即Redo Log.
2 – Redo Log
和Undo Log相反,Redo Log記錄的是新數據的備份。在事務提交前,只要將Redo Log持久化便可,
不須要將數據持久化。當系統崩潰時,雖然數據沒有持久化,可是Redo Log已經持久化。系統能夠根據
Redo Log的內容,將全部數據恢復到最新的狀態。
假設有A、B兩個數據,值分別爲1,2.
A.事務開始.
B.記錄A=1到undo log.
C.修改A=3.
D.記錄A=3到redo log.
E.記錄B=2到undo log.
F.修改B=4.
G.記錄B=4到redo log.
H.將redo log寫入磁盤。
I.事務提交
3 - 慢查詢日誌
數據庫查詢快慢是影響項目性能的一大因素,對於數據庫,咱們除了要優化 SQL,更重要的是得先找到須要優化的 SQL。如何找到低效的 SQL 是寫這篇文章的主要目的。
MySQL 數據庫有一個「慢查詢日誌」功能,用來記錄查詢時間超過某個設定值的SQL,這將極大程度幫助咱們快速定位到癥結所在,以便對症下藥。至於查詢時間的多少纔算慢,每一個項目、業務都有不一樣的要求,傳統企業的軟件容許查詢時間高於某個值,可是把這個標準放在互聯網項目或者訪問量大的網站上,估計就是一個bug,甚至可能升級爲一個功能性缺陷。
爲避免誤導讀者,特申明本文的討論限制在 Win 64位 + MySQL 5.6 範圍內。其餘平臺或數據庫種類及版本,我沒有嘗試過,不作贅述。
關於慢查詢日誌,主要涉及到下面幾個參數:
也就是說,只有知足以上三個條件,「慢查詢功能」纔可能正確開啓或關閉。
簡單來講就是保證主SQL(Master)和從SQL(Slave)的數據是一致性的,向Master插入數據後,Slave會自動從Master把修改的數據同步過來(有必定的延遲),經過這種方式來保證數據的一致性,就是主從複製
MySQL5.6開始主從複製有兩種方式:基於日誌(binlog)、基於GTID(全局事務標示符)。
本文只涉及基於日誌binlog的主從配置
一、Master將數據改變記錄到二進制日誌(binary log)中,也就是配置文件log-bin指定的文件,這些記錄叫作二進制日誌事件(binary log events)
二、Slave經過I/O線程讀取Master中的binary log events並寫入到它的中繼日誌(relay log)
三、Slave重作中繼日誌中的事件,把中繼日誌中的事件信息一條一條的在本地執行一次,完成數據在本地的存儲,從而實現將改變反映到它本身的數據(數據重放)
binlog是一個二進制格式的文件,用於記錄用戶對數據庫更新的SQL語句信息,例如更改數據庫表和更改內容的SQL語句都會記錄到binlog裏,可是對庫表等內容的查詢不會記錄。
默認狀況下,binlog日誌是二進制格式的,不能使用查看文本工具的命令(好比,cat,vi等)查看,而使用mysqlbinlog解析查看。
當有數據寫入到數據庫時,還會同時把更新的SQL語句寫入到對應的binlog文件裏,這個文件就是上文說的binlog文件。使用mysqldump備份時,只是對一段時間的數據進行全備,可是若是備份後忽然發現數據庫服務器故障,這個時候就要用到binlog的日誌了。
主要做用是用於數據庫的主從複製及數據的增量恢復。
<pre>1.啥是binlog? 記錄數據庫增刪改,不記錄查詢的二進制日誌. 2.做用:用於數據恢復.</pre>
在mysql的配置文件my.cnf中,增長log_bin參數便可開啓binlog日誌,也能夠經過賦值來指定binlog日誌的文件名,實例以下:
<pre>[root@DB02 ~]# grep log_bin /etc/my.cnf
log_bin = /application/mysql/logs/dadong-bin
[root@DB02 ~]#
提示:也能夠按「log_bin = /application/mysql/logs/dadong-bin」命名,目錄要存在
爲何要刷新binlog?找到全備數據和binlog文件的恢復臨界點.</pre>
總結
mysql數據庫的binlog和relay log日誌有着舉足輕重的做用,而且relay log僅僅存在於mysql 的slave庫,它的做用就是記錄slave庫中的io進程接收的從主庫傳過來的binlog,而後等待slave庫的sql進程去讀取和應用,保證主從同步,可是binlog主庫和從庫(slave)均可以存在,記錄對數據發生或潛在發生更改的SQL語句,並以二進制的形式保存在磁盤,因此能夠經過binlog來實時備份和恢復數據庫。
binlog是一個二進制格式的文件,用於記錄用戶對數據庫更新的SQL語句信息,例如更改數據庫表和更改內容的SQL語句都會記錄到binlog裏,可是對庫表等內容的查詢不會記錄。
默認狀況下,binlog日誌是二進制格式的,不能使用查看文本工具的命令(好比,cat,vi等)查看,而使用mysqlbinlog解析查看。
當有數據寫入到數據庫時,還會同時把更新的SQL語句寫入到對應的binlog文件裏,這個文件就是上文說的binlog文件。使用mysqldump備份時,只是對一段時間的數據進行全備,可是若是備份後忽然發現數據庫服務器故障,這個時候就要用到binlog的日誌了。
主要做用是用於數據庫的主從複製及數據的增量恢復。
<pre>1.啥是binlog? 記錄數據庫增刪改,不記錄查詢的二進制日誌. 2.做用:用於數據恢復.</pre>
在mysql的配置文件my.cnf中,增長log_bin參數便可開啓binlog日誌,也能夠經過賦值來指定binlog日誌的文件名,實例以下:
<pre>[root@DB02 ~]# grep log_bin /etc/my.cnf
log_bin = /application/mysql/logs/dadong-bin
[root@DB02 ~]#提示:也能夠按「log_bin = /application/mysql/logs/dadong-bin」命名,目錄要存在爲何要刷新binlog?找到全備數據和binlog文件的恢復臨界點.</pre>