高可用性、負載均衡的mysql集群解決方案

1、數(shù)據庫弱一致性四個隔離級別數(shù)據庫弱一致性四個隔離級別SQL92標準中定義了四個隔離級別，這四個隔離級別在以前版本的SQLServer中即受到支持：READUNCOMMITTEDREADUNCOMMITTED是限制性最弱的隔離級別，因為該級別忽略其他事務放置的鎖。使用READUNCOMMITTED級別執(zhí)行的事務，可以讀取尚未由其他事務提交的修改后的數(shù)據值，這些行為稱為“臟”讀。這是因為在ReadUncommitted級別下，讀取數(shù)據不需要

2、加級別下，讀取數(shù)據不需要加S鎖，這樣就不鎖，這樣就不會跟被修改的數(shù)據上的會跟被修改的數(shù)據上的X鎖沖突鎖沖突。比如，事務1修改一行，事務2在事務1提交之前讀取了這一行。如果事務1回滾，事務2就讀取了一行沒有提交的數(shù)據，這樣的數(shù)據我們認為是不存在的。READCOMMITTEDREADCOMMITTED(Nonrepeatablereads)是SQLServer默認的隔離級別。該級別通過指定語句不能讀取其他事務已修改但是尚未提交的數(shù)據值，禁止

3、執(zhí)行臟讀。在當前事務中的各個語句執(zhí)行之間，其他事務仍可以修改、插入或刪除數(shù)據，從而產生無法重復的讀操作，或“影子”數(shù)據。比如，事務1讀取了一行，事務2修改或者刪除這一行并且提交。如果事務1想再一次讀取這一行，它將獲得修改后的數(shù)據或者發(fā)現(xiàn)這一樣已經被刪除，因此事務的第二次讀取結果與第一次讀取結果不同，因此也叫不可重復讀。實驗實驗1query1：事務1step1:創(chuàng)建實驗數(shù)據intoEmployeefromAdventureWks.Huma

4、nResources.EmployeealtertableEmployeeaddconstraintpk_Employee_EmployeeIDprimarykey(EmployeeID)step2:設置隔離級別這是數(shù)據庫的默認隔離界別SETTRANSACTIONISOLATIONLEVELREADCOMMITTEDstep3:開啟第一個事務BEGINTRANtran1step4:執(zhí)行操作查看VacationHours對查找的記錄加S鎖

5、，在語句執(zhí)行完以后自動釋放S鎖EmployeeIDVacationHoursFROMEmployeeWHEREEmployeeID=4step5:查看當前加鎖情況沒有發(fā)現(xiàn)在Employee表上面有鎖這是因為當前的隔離界別是READCOMMITTED在執(zhí)行完step2以后馬上釋放了S鎖.然后我們回到事務1當中再次執(zhí)行查詢語句，我們會發(fā)現(xiàn)查詢被阻塞，我們新建一個查詢query3來查看這個時候的鎖狀況，其查詢結果如下，我們可以發(fā)現(xiàn)查詢操作需要

6、在KEY級別上申請S鎖，在Page和表(Object)上面申請IS鎖，但是因為Key上面原先有了X鎖，與當前讀操作申請的S鎖沖突，所以這一步處于WAIT狀態(tài)。如果此時提交事務2的update操作，那么事務1的操作不再被阻塞，得到查詢結果，但是我們發(fā)現(xiàn)此時得到的查詢結果與第一次得到的查詢結果不同，這也是為什么將readcommitted稱為不可重復讀，因為同一個事物內的兩次相同的查詢操作的結果可能不同。REPEATABLEREADREPE

7、ATABLEREAD是比READCOMMITTED限制性更強的隔離級別。該級別包括READCOMMITTED，并且另外指定了在當前事務提交之前，其他任何事務均不可以修改或刪除當前事務已讀取的數(shù)據。并發(fā)性低于READCOMMITTED，因為已讀數(shù)據的共享鎖在整個事務期間持有，而不是在每個語句結束時釋放。比如，事務1讀取了一行，事務2想修改或者刪除這一行并且提交，但是因為事務1尚未提交，數(shù)據行中有事務1的鎖，事務2無法進行更新操作，因此事務

8、2阻塞。如果這時候事務1想再一次讀取這一行，它讀取結果與第一次讀取結果相同，因此叫可重復讀。實驗實驗2query1：事務1step1:創(chuàng)建實驗數(shù)據intoEmployeefromAdventureWks.HumanResources.EmployeealtertableEmployeeaddconstraintpk_Employee_EmployeeIDprimarykey(EmployeeID)step2:設置隔離級別SETTRANS