Mysql事務和Mysql 日誌

事務特性

一、原子性（Atomicity）：事務開始後全部操做，要麼所有作完，要麼所有不作，不可能停滯在中間環節。

二、一致性（Consistency）：事務開始前和結束後，數據庫的完整性約束沒有被破壞 。好比A向B轉帳，不可能A扣了錢，B卻沒收到。

三、隔離性（Isolation）：同一時間，只容許一個事務請求同一數據，不一樣的事務之間彼此沒有任何干擾。好比A正在從一張銀行卡中取錢，在A取錢的過程結束前，B不能向這張卡轉帳。

四、持久性（Durability）：事務完成後，事務對數據庫的全部更新將被保存到數據庫，不能回滾。

事務併發問題

一、髒讀：事務A讀取了事務B更新的數據，而後B回滾操做，那麼A讀取到的數據是髒數據

二、不可重複讀：事務 A 屢次讀取同一數據，事務 B 在事務A屢次讀取的過程當中，對數據做了更新並提交，致使事務A屢次讀取同一數據時，結果 不一致。

三、幻讀：系統管理員A將數據庫中全部學生的成績從具體分數改成ABCDE等級，可是系統管理員B就在這個時候插入了一條具體分數的記錄，當系統管理員A改結束後發現還有一條記錄沒有改過來，就好像發生了幻覺同樣，這就叫幻讀。

小結：不可重複讀的和幻讀很容易混淆，不可重複讀側重於修改，幻讀側重於新增或刪除。解決不可重複讀的問題只需鎖住知足條件的行，解決幻讀須要鎖表

事務隔離

mysql默認是「可重複讀」，串行化後

事務隔離級別	髒讀	不可重複讀	幻讀
讀未提交（read-uncommitted）	是	是	是
不可重複讀（read-committed）	否	是	是
可重複讀（repeatable-read）	否	否	是
串行化（serializable）	否	否	否

#查全局事務隔離級別
SELECT @@global.tx_isolation;
#查當前會話事務隔離級別
SELECT @@session.tx_isolation; 
#查當前事務隔離級別
SELECT @@tx_isolation;
#設置全局隔離級別
set global transaction isolation level read committed;
#設置當前會話隔離級別
set session transaction isolation level read committed;

串行化是最高的隔離級別，它經過強制事務排序，使之不可能相互衝突，從而解決幻讀問題。簡言之,它是在每一個讀的數據行上加上共享鎖，在這個級別，可能致使大量的超時現象和鎖競爭。

共享鎖(Share)：共享鎖的代號是S

mysql日誌文件系統組成

一、MySQL日誌文件系統的組成
   a、錯誤日誌：記錄啓動、運行或中止mysqld時出現的問題。
   b、通用日誌：記錄創建的客戶端鏈接和執行的語句。
   c、更新日誌：記錄更改數據的語句。該日誌在MySQL 5.1中已再也不使用。
   d、二進制日誌：記錄全部更改數據的語句。還用於複製。
   e、慢查詢日誌：記錄全部執行時間超過long_query_time秒的全部查詢或不使用索引的查詢。
   f、Innodb日誌：innodb redo log

二進制日誌（binlog）：

包含了全部更新了數據或者已經潛在更新了數據(好比沒有匹配任何行的一個DELETE)
包含關於每一個更新數據庫(DML)的語句的執行時間信息
不包含沒有修改任何數據的語句，若是須要啓用該選項，須要開啓通用日誌功能
主要目的是儘量的將數據庫恢復到數據庫故障點，由於二進制日誌包含備份後進行的全部更新
用於在主複製服務器上記錄全部將發送給從服務器的語句
啓用該選項數據庫性能下降1%，但保障數據庫完整性，對於重要數據庫值得以性能換完整。有些相似於oracle開啓歸檔模式。

show variables like '%version%';  
show variables like '%log_bin%';  //是否啓用 binlog
show variables like '%binlog%';  //binlog 相關參數
show variables like '%datadir%';   //數據文件目錄，默認日誌存在該目錄

#編輯my.cnf來設定binary log日誌位置(注，配置二進制日誌路徑及文件名後，系統變量log_bin被自動置爲on)  

log_bin=/var/lib/mysql/binarylog/binlog  

#若是在my.cnf裏面只設置log_bin，可是不指定file_name，而後重啓數據庫。你會發現二進制日誌文件名稱爲${hostname}-bin 這樣的格式
#切換日誌
show master status;
flush logs;
show master status;

每次重啓MySQL服務也會生成一個新的二進制日誌文件，至關於二進制日誌切換。切換二進制日誌時，你會看到這些number會不斷遞增。另外，除了這些二進制日誌文件外，你會看到還生成了一個DB-Server-bin.index的文件，這個文件中存儲全部二進制日誌文件的清單又稱爲二進制文件的索引

二進制日誌的刪除能夠經過命令手工刪除，也能夠設置自動清理。

show binary logs;
mysql> purge binary logs to 'DB-Server-bin.000002';

purge binary logs to xxx; 表示刪除某個日誌以前的全部二進制日誌文件。這個命令會修改index中相關數據
purge binary logs before '2017-03-10 10:10:00'; 清除某個時間點之前的二進制日誌文件。
purge master logs before date_sub( now( ), interval 7 day);清除7天前的二進制日誌文件
reset master;清除全部的二進制日誌文件（當前不存在主從複製關係）

show variables like 'expire_logs_days';咱們也能夠設置expire_logs_days參數，設置自動清理，其默認值爲0,表示不啓用過時自動刪除功能，若是啓用了自動清理功能，表示超出此天數的二進制日誌文件將被自動刪除，自動刪除工做一般發生在MySQL啓動時或FLUSH日誌時。
set expire_logs_days=7;

二進制日誌相關參數

一、系統變量log_bin_trust_function_creators，默認爲OFF，這個參數開啓會限制存儲過程、Function、觸發器的建立。

2：系統變量sql_log_bin 用於控制會話級別二進制日誌功能的開啓或關閉，默認爲ON，表示啓用二進制日誌功能。

三、系統變量binlog_cache_size 表示爲每一個客戶端分配binlog_cache_size大小的緩存，默認值32768。二進制日誌緩存使用的前提條件是服務器端使用了支持事務的引擎以及開啓了bin log功能，它是MySQL用來提升binlog的效率而設計的一個用於短期內臨時緩存binlog數據的內存區域。通常來講，若是咱們的數據庫中沒有什麼大事務，寫入也不是特別頻繁，2MB～4MB是一個合適的選擇。可是若是咱們的數據庫大事務較多或多事務語句，寫入量比較大，可適當調高binlog_cache_size。同時，咱們能夠經過binlog_cache_use 以及 binlog_cache_disk_use來分析設置的binlog_cache_size是否足夠，是否有大量的binlog_cache因爲內存大小不夠而使用臨時文件（binlog_cache_disk_use）來緩存了。

能夠經過查看Binlog_cache_disk_use 與 Binlog_cache_use來判斷binlog_cache_size是否須要調整。

四、系統變量max_binlog_cache_size 二進制日誌可以使用的最大cache內存大小。當執行多語句事務時，max_binlog_cache_size 若是不夠大，系統可能會報出「Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage」的錯誤。

五、 系統變量max_binlog_stmt_cache_size

max_binlog_cache_size針對事務語句，max_binlog_stmt_cache_size針對非事務語句，當咱們發現Binlog_cache_disk_use或者Binlog_stmt_cache_disk_use比較大時就須要考慮增大cache的大小

六、系統變量max_binlog_size， 表示二進制日誌的最大值，通常設置爲512M或1GB，但不能超過1GB。該設置並不能嚴格控制二進制日誌的大小，尤爲是二進制日誌比較靠近爲不而又遇到一根比較大事務時， 爲了保證事務的完整性，不可能作切換日誌的動做，只能將該事務的全部SQL都記錄進當前日誌，直到事務結束。

七、系統變量binlog_checksum 用做複製的主從校檢。 NONE表示不生成checksum，CRC-32表示使用這個算法作校檢。

八、系統變量sync_binlog，這個參數對於Mysql系統來講是相當重要的，它不只影響到二進制日誌文件對MySQL所帶來的性能損耗，並且還影響到MySQL中數據的完整性。

sync_binlog=0，當事務提交後，Mysql僅僅是將binlog_cache中的數據寫入binlog文件，但不執行fsync之類的磁盤同步指令通知文件系統將緩存刷新到磁盤，而是讓Filesystem自行決定何時來作同步。MySQL中默認的設置是 sync_binlog=0，即不做任何強制性的磁盤刷新指令，這個設置性能是最好的，但風險也是最大的。一旦系統崩潰（Crash），在文件系統緩存中的全部二進制日誌信息都會丟失。從而帶來數據不完整問題。

sync_binlog=n，在進行n次事務提交之後，Mysql將執行一次fsync之類的磁盤同步指令，同時文件系統將Binlog文件緩存刷新到磁盤。

能夠適當的調整sync_binlog， 在犧牲必定的一致性下，獲取更高的併發和性能。

九、系統變量binlog_format 指定二進制日誌的類型。分別有STATEMENT、ROW、MIXED三種值。MySQL 5.7.6以前默認爲STATEMENT模式。MySQL 5.7.7以後默認爲ROW模式。這個參數主要影響主從複製。

基於SQL語句的複製(statement-based replication, SBR)，

基於行的複製(row-based replication, RBR)，

混合模式複製(mixed-based replication, MBR)。

查看二進制日誌內容

方法1：使用show binlog events方式能夠獲取當前以及指定binlog的日誌，不適宜提取大量日誌。

SHOW BINLOG EVENTS[IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]

SHOW BINLOG EVENTS IN 'mysql-bin.000005' \G

方法2: 使用mysqlbinlog命令行查看日誌內容(適宜批量提取日誌)。

system mysqlbinlog /var/lib/mysql/DB-Server-bin.000013;

mysqlbinlog /var/lib/mysql/DB-Server-bin.000013 > test.sql;

二進制日誌的類型

基於段的日誌格式

binlog_format=STATEMENT

記錄了操做的sql語句。

優勢：

日誌記錄量相對較小，節約磁盤及網絡I/O,只對以一條記錄修改或插入ROW格式所產生日量小於段產生的日誌量。

缺點：

必須記錄上下文信息，保證語句在從服務器上的執行結果和在主服務器上相同。

特定函數如UUID,USER()這樣非肯定性的函數沒法複製。

可能形成mysql複製的主備服務器數據不一致，從而中斷複製鏈路。

顯示binlog 格式

show variables like 'binlog_format';

set session binlog_format=statement;

基於行的日誌格式

將my.ini 二進制格式修改成binlog_format=ROW

row 的優勢：row格式能夠避免MYSQL複製中出現主從不一致的問題，官方推薦這種格式。同一個sql語句修改了10000條數據的狀況下。基於段的日誌只會記錄這個SQL語句。基於行的日誌會有10000條記錄，分別記錄每一行數據的修改。

1.是mysql主從複製更加安全。

2.對每一行數據修改比基於段的複製高效。若是誤操做修改了數據庫中的數據，同時沒有備份能夠恢復時，咱們就能夠經過分析二進制日誌，對日誌中記錄的數據修改操做作反向處理的方式來達到恢復數據的目的。

row 的缺點：記錄日誌量較大

binlog_row_image=[full,minimal,noblob]

full : 記錄列的全部修改；minimal ：只記錄修改的列。noblob :若是是text類型或clob字段，不記錄 這些日誌。

使用 mysqlbinlog -vv ../data/mysql-bin.000005 查看明細日誌。

set session binlog_row_image=minimal

混合日誌格式:

binlog_format=MIXED

特色：根據sql語句由系統決定在記錄段和基於行的日誌格式中進行選擇。數據量大小由所執行的SQL決定。

如何選擇二進制格式

建議binlog_formart =mixed    or   binlog_format=row;   binlog_row_image=minimal;

複製方式：

1.基於SQL語句的複製（SBR)

優勢：生成日誌量少，節約網絡傳輸的ID.並不要求對主從數據庫的表定義徹底相同。

相比於基於行的複製方式更爲靈活。

缺點：對於非肯定事件，沒法保證主從複製數據的一致性。對於存儲過程，觸發器

2.基於行的複製(RBR)

優勢：能夠應用於任何SQL的複製包括非肯定性函數，存儲過程等。能夠減小數據庫鎖的使用。

缺點：要求主從數據庫的表結構相同，不然就會中斷複製。

3.複製工做方式

1.主服務器將變動寫入二進制日誌。

2.從讀取主的二進制日誌變動並寫入到relay_log中。

基於日誌點的複製，基於GTID的複製。

3.在從上重放relay_log中的日誌。

基於SQL段的日誌是在從庫上從新執行記錄的SQL。

基於行的日誌則是在從庫上直接應用對數據行的修改。