MySQL深刻03-鎖-事務-GTID

MySQL的鎖

執行操做時施加的鎖模式

讀鎖：又稱共享鎖，多個讀操做能夠同時施加，非阻塞

寫鎖：又稱獨佔鎖或排它鎖，阻塞

根據鎖粒度分類

表鎖：table lock，鎖定了整張表，開銷小

行鎖：row lock，鎖定了須要的行，開銷大

注：鎖的粒度越小，開銷越大，但併發性越好

根據鎖的實現位置分類

MySQL鎖：能夠手動施加鎖，又稱顯示鎖(表級鎖)

lock tables Tb_Name {read | write} [,Tb_Name2 Lock_Type2]…

存儲引擎鎖：自動進行的，又稱隱式鎖

行級鎖：只鎖定挑選出的部分行，是InnoDB存儲引擎中支持的另一種顯示鎖

select … lock in share mode; # 對挑選出的行施加讀鎖
select … for update; # 對挑選出的行施加寫鎖

MySQL的事務

事務就是一組原子性的查詢語句

ACID測試：能知足ACID測試就表示其支持事務，或兼容事務

A：Atomicity # 原子性
C：Consistency # 一致性
I：Isolation # 隔離性，一個事務的全部操做在提交以前對其它事務是不可見的
D：Durability # 持久性，一旦事務得以提交，其所做的修改會永久有效

隔離級別

read uncommited (讀未提交) # 容易產生髒讀，不可重複讀，幻讀
# 髒讀：可以讀取未提交的事務內容
read commited(讀提交) # 只能看到已提交事務的修改內容，但仍然存在不可重複讀，幻讀
# 不可重複讀：在同一次事務中，屢次同一讀取操做結果不一致，由於讀取了其餘事務的操做結果
repeatable read(可重讀) # 容易產生幻讀
# 幻讀：對於本身未修改的內容，事務提交先後出現的結果不一致
serializable(可串行化)  # 強制事務的串行執行，避免了幻讀，但效率極低

查看MySQL的事務隔離級別

show global variables like ‘tx_isolation’;
select @@global.tx_isolation;
# 建議：對事務要求不嚴格的場景下，隔離級別可使用「讀提交」

MySQL實現事務的原理：MVCC(多版本併發控制)

每一個事務啓動時，InnoDB會爲每一個啓動的事務提供一個當下時刻的快照；
爲了實現此功能，InnoDB會爲每一個表提供2個隱藏字段，一個用於保存行的建立時間，一個用於保存行的失效時間（裏面存儲的是系統版本號：system version number）
在某一事務中，使用比當前事務相等或更舊的版本號數據，從而保證其所讀取的數據都是過去的數據
注：只在2個隔離級別下有效：read commited和repeatable read

手動執行事務操做

start transaction； # 手動開始執行事務操做
rollback；# 在事務未提交前回滾，放棄所有修改
savepoint a; # 定義當前位置爲保存點a
rollback to a; # 回滾至保存點a
commit； # 提交事務
# 若是沒有顯示啓動事務，每一個語句都會當作一個獨立事務，其執行完成後會被自動提交
select @@global.autocommit; # 查看當前自動提交選項
set global autocommit = 0; # 關閉自動提交功能
# 關閉自動提交後，請手動啓動事務，並手動進行提交

事務的GTID

簡介：Global Transaction ID，在MySQL5.6中被引入的，爲了快速提高salve爲master，同時保證事務安全的一種機制；使得其複製功能的配置、監控及管理變得更加易於實現，且更加健壯；

# 特性：
GTID=UUID（Server ID：128位）+事務號，可惟一標識事務
GTID在事務開始前寫入二進制日誌；
GTID和事務記錄同時被傳輸至slave；
# 注：即便salve被提高爲了master，對於複製到的事務也不會生成新的GTID的

配置使用GTID的簡單主從模型

說明：使用MariaDB 10 版本做爲MySQL 5.6的替代程序；區別是mariadb中默認開啓了GTID功能，故不支持以下2個參數：gtid-mode，enforce-gtid-consistency

配置主從節點的服務配置文件

# 配置master節點：
[mysqld]
server-id=1  # 主從複製架構中server-id需惟一
port=3306
datadir=/mydata/data
socket=/tmp/mysql.sock
log-bin=master-bin # 啓用二進制日誌，這是保證複製功能的基本前提
binlog-format=ROW # 二進制日誌的格式，必須爲row
log-slave-updates=true
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-threads=2
binlog-checksum=CRC32 # 啓用與複製有關的全部校驗功能
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1
report-host=master.lamp.com # slave註冊過程當中向master報告的slave的主機名或IP地址，只用於master上執行「show slave hosts」以顯示slave的主機名
report-port=3306 # slave註冊過程當中向master報告的slave使用的mysqld端口，只在slave使用非3306端口時須要
# 配置slave節點：
[mysqld]
server-id=11
port=3306
datadir=/mydata/data
socket=/tmp/mysql.sock
log-bin=slave-bin
binlog-format=ROW
log-slave-updates=true # 告訴slave在二進制日誌中記錄從主庫同步到的數據更新操做
master-info-repository=TABLE # slave利用repository中的信息跟蹤master的二進制日誌和本地的中繼日誌，在此設置爲table；可提升崩潰時從服務器的數據安全
relay-log-info-repository=TABLE
sync-master-info=1 # 對於master-info的信息每寫1次就刷新至磁盤，可確保slave無信息丟失
slave-parallel-threads=2 # 設定slave的SQL線程數；0表示關閉多線程複製功能
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1 # 啓用可在二進制日誌中記錄事件相關信息的功能，可下降故障排除的複雜度
report-host=slave.lamp.com
report-port=3306

主服務器上建立複製用戶

mysql> grant replication slave on *.* to repluser@'172.16.25.%' identified by 'replpass';

爲備節點提供初始數據集

# 鎖定主表，備份主節點上的數據，將其導入slave節點；
# master節點上
musqldump --single-transaction --all-databases --flush-logs --master-date=2 > all.sql
# slave節點上
mysql < all.sql
# 若是沒有啓用GTID，在備份時須要在master上使用show master status命令查看二進制日誌文件名稱及事件位置，以便後面啓動slave節點時使用；

啓動從節點的複製線程

# 若是啓用了GTID功能，則使用以下命令：
mysql> change master to master_host='master.lamp.com',master_user='repluser',master_password='replpass',master_user_gtid=current_pos;
mysql> start slave;

驗證查看

在master和slave上分別執行「show master status;」，查看Executed_Gtid_Set項是否一致便可

上一篇：MySQL深刻02-DML之Select查詢

下一篇：MySQL深刻04-存儲引擎