本篇內(nèi)容主要講解“MySQL中基于WRITESET的并行復(fù)制方式是什么”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學(xué)習(xí)“MySQL中基于WRITESET的并行復(fù)制方式是什么”吧!
公司主營業(yè)務(wù):成都做網(wǎng)站、成都網(wǎng)站建設(shè)、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳,提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴謹、自律”為核心的企業(yè)文化,感謝他們對我們的高要求,感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn),讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出新華免費做網(wǎng)站回饋大家。
我們先來看一個截圖,仔細觀察其中的last commit:
我們可以看到其中的last commit看起來是亂序的,這種情況在基于COMMIT_ORDER 的并行復(fù)制方式下是不可能出現(xiàn)的。實際上它就是我們前面說的基于WRITESET的并行復(fù)制再盡可能降低的last commit的結(jié)果。這種情況會在MTS從庫獲得更好的并行回放效果,第19節(jié)將會詳細解釋并行判定的標(biāo)準。
實際上Writeset是一個集合,使用的是C++ STL中的set容器,在類Rpl_transaction_write_set_ctx中包含了如下定義:
std::set<uint64> write_set_unique;
集合中的每一個元素都是hash值,這個hash值和我們的transaction_write_set_extraction參數(shù)指定的算法有關(guān),其來源就是行數(shù)據(jù)的主鍵和唯一鍵。每行數(shù)據(jù)包含了兩種格式:
字段值為二進制格式
字段值為字符串格式
每行數(shù)據(jù)的具體格式為:
| 主鍵/唯一鍵名稱 | 分隔符 | 庫名 | 分隔符 | 庫名長度 | 表名 | 分隔符 | 表名長度 | 鍵字段1 | 分隔符 | 長度 | 鍵字段2 | 分隔符 | 長度 | 其他字段… |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
在Innodb層修改一行數(shù)據(jù)之后會將這上面的格式的數(shù)據(jù)進行hash后寫入到Writeset中。可以參考函數(shù)add_pke,后面我也會以偽代碼的方式給出部分流程。
但是需要注意一個事務(wù)的所有的行數(shù)據(jù)的hash值都要寫入到一個Writeset。如果修改的行比較多那么可能需要更多內(nèi)存來存儲這些hash值。雖然8字節(jié)比較小,但是如果一個事務(wù)修改的行很多,那么還是需要消耗較多的內(nèi)存資源的。
為了更直觀的觀察到這種數(shù)據(jù)格式,可以使用debug的方式獲取。下面我們來看一下。
我們使用如下表:
mysql> use test Database changed mysql> show create table jj10 \G *************************** 1. row *************************** Table: jj10 Create Table: CREATE TABLE `jj10` ( `id1` int(11) DEFAULT NULL, `id2` int(11) DEFAULT NULL, `id3` int(11) NOT NULL, PRIMARY KEY (`id3`), UNIQUE KEY `id1` (`id1`), KEY `id2` (`id2`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 1 row in set (0.00 sec)
我們寫入一行數(shù)據(jù):
insert into jj10 values(36,36,36);
這一行數(shù)據(jù)一共會生成4個元素分別為:
注意:這里顯示的?是分隔符
(gdb) p pke $1 = "PRIMARY?test?4jj10?4\200\000\000$?4" **注意:\200\000\000$ :為3個八進制字節(jié)和ASCII字符 $, 其轉(zhuǎn)換為16進制就是“0X80 00 00 24 ”**
分解為:
| 主鍵名稱 | 分隔符 | 庫名 | 分隔符 | 庫名長度 | 表名 | 分隔符 | 表名長度 | 主鍵字段1 | 分隔符 | 長度 |
|---|---|---|---|---|---|---|---|---|---|---|
| PRIMARY | ? | test | ? | 4 | jj10 | ? | 4 | 0x80 00 00 24 | ? | 4 |
(gdb) p pke $2 = "PRIMARY?test?4jj10?436?2"
分解為:
| 主鍵名稱 | 分隔符 | 庫名 | 分隔符 |庫名長度 | 表名 |分隔符|表名長度|主鍵字段1|分隔符|長度 |
| ——— | ——— | ——— | ——— | ——— | ——— | ——— | ——— | ——— |——— |———|
| PRIMARY |?| test|?|4|jj10|?|4|36 | ?|2|
(gdb) p pke $3 = "id1?test?4jj10?4\200\000\000$?4"
解析同上
(gdb) p pke $4 = "id1?test?4jj10?436?2"
解析同上
最終這些數(shù)據(jù)會通過hash算法后寫入到Writeset中。
下面是一段偽代碼,用來描述這種生成過程:
如果表中存在索引: 將數(shù)據(jù)庫名,表名信息寫入臨時變量 循環(huán)掃描表中每個索引: 如果不是唯一索引: 退出本次循環(huán)繼續(xù)循環(huán)。 循環(huán)兩種生成數(shù)據(jù)的方式(二進制格式和字符串格式): 將索引名字寫入到pke中。 將臨時變量信息寫入到pke中。 循環(huán)掃描索引中的每一個字段: 將每一個字段的信息寫入到pke中。 如果字段掃描完成: 將pke生成hash值并且寫入到寫集合中。 如果沒有找到主鍵或者唯一鍵記錄一個標(biāo)記,后面通過這個標(biāo)記來 判定是否使用Writeset的并行復(fù)制方式
前一節(jié)我們討論了基于ORDER_COMMIT的并行復(fù)制是如何生成last_commit和seq number的。實際上基于WRITESET的并行復(fù)制方式只是在ORDER_COMMIT的基礎(chǔ)上對last_commit做更進一步處理,并不影響原有的ORDER_COMMIT邏輯,因此如果要回退到ORDER_COMMIT邏輯非常方便。可以參考MYSQL_BIN_LOG::write_gtid函數(shù)。
根據(jù)binlog_transaction_dependency_tracking取值的不同會做進一步的處理,如下:
ORDER_COMMIT:調(diào)用m_commit_order.get_dependency函數(shù)。這是前面我們討論的方式。
WRITESET:調(diào)用m_commit_order.get_dependency函數(shù),然后調(diào)用m_writeset.get_dependency。可以看到m_writeset.get_dependency函數(shù)會對原有的last commit做處理。
WRITESET_SESSION:調(diào)用m_commit_order.get_dependency函數(shù),然后調(diào)用m_writeset.get_dependency再調(diào)用m_writeset_session.get_dependency。m_writeset_session.get_dependency會對last commit再次做處理。
這段描述的代碼對應(yīng):
case DEPENDENCY_TRACKING_COMMIT_ORDER: m_commit_order.get_dependency(thd, sequence_number, commit_parent); break; case DEPENDENCY_TRACKING_WRITESET: m_commit_order.get_dependency(thd, sequence_number, commit_parent); m_writeset.get_dependency(thd, sequence_number, commit_parent); break; case DEPENDENCY_TRACKING_WRITESET_SESSION: m_commit_order.get_dependency(thd, sequence_number, commit_parent); m_writeset.get_dependency(thd, sequence_number, commit_parent); m_writeset_session.get_dependency(thd, sequence_number, commit_parent); break;
我們到這里已經(jīng)討論了Writeset是什么,也已經(jīng)說過如果要降低last commit的值我們需要通過對事務(wù)的Writeset和Writeset的歷史MAP進行比對,看是否沖突才能決定降低為什么值。那么必須在內(nèi)存中保存一份這樣的一個歷史MAP才行。在源碼中使用如下方式定義:
/* Track the last transaction sequence number that changed each row in the database, using row hashes from the writeset as the index. */ typedef std::map<uint64,int64> Writeset_history; //map實現(xiàn) Writeset_history m_writeset_history;
我們可以看到這是C++ STL中的map容器,它包含兩個元素:
Writeset的hash值
最新一次本行數(shù)據(jù)修改事務(wù)的seq number
它是按照Writeset的hash值進行排序的。
其次內(nèi)存中還維護一個叫做m_writeset_history_start的值,用于記錄Writeset的歷史MAP中最早事務(wù)的seq number。如果Writeset的歷史MAP滿了就會清理這個歷史MAP然后將本事務(wù)的seq number寫入m_writeset_history_start,作為最早的seq number。后面會看到對于事務(wù)last commit的值的修改總是從這個值開始然后進行比較判斷修改的,如果在Writeset的歷史MAP中沒有找到?jīng)_突那么直接設(shè)置last commit為這個m_writeset_history_start值即可。下面是清理Writeset歷史MAP的代碼:
if (exceeds_capacity || !can_use_writesets)
//Writeset的歷史MAP已滿
{
m_writeset_history_start= sequence_number;
//如果超過最大設(shè)置,清空writeset history。從當(dāng)前seq number 重新記錄, 也就是最小的那個事務(wù)seq number
m_writeset_history.clear();
//清空歷史MAP
}這里介紹一下整個處理的過程,假設(shè)如下:
當(dāng)前通過基于ORDER_COMMIT的并行復(fù)制方式后,構(gòu)造出來的是(last commit=125,seq number=130)。
本事務(wù)修改了4條數(shù)據(jù),我分別使用ROW1/ROW7/ROW6/ROW10代表。
表只包含主鍵沒有唯一鍵,并且我的圖中只保留行數(shù)據(jù)的二進制格式的hash值,而沒有包含數(shù)據(jù)的字符串格式的hash值。
初始化情況如下圖(圖16-1,高清原圖包含在文末原圖中):
第一步 設(shè)置last commit為writeset_history_start的值也就是100。
第二步 ROW1.HASHVAL在Writeset歷史MAP中查找,找到?jīng)_突的行ROW1.HASHVAL將歷史MAP中這行數(shù)據(jù)的seq number更改為130。同時設(shè)置last commit為120。
第三步 ROW7.HASHVAL在Writeset歷史MAP中查找,找到?jīng)_突的行ROW7.HASHVAL將Writeset歷史MAP中這行數(shù)據(jù)的seq number更改為130。由于歷史MAP中對應(yīng)的seq number為114,小于120不做更改。last commit依舊為120。
第四步 ROW6.HASHVAL在Writeset歷史MAP中查找,找到?jīng)_突的行ROW6.HASHVAL將Writeset歷史MAP中這行數(shù)據(jù)的seq number更改為130。由于歷史MAP中對應(yīng)的seq number為105,小于120不做更改。last commit依舊為120。
第五步 ROW10.HASHVAL在Writeset歷史MAP中查找,沒有找到?jīng)_突的行,因此需要將這一行插入到Writeset歷史MAP中查找(需要判斷是否導(dǎo)致歷史MAP占滿,如果占滿則不需要插入,后面隨即要清理掉)。即要將ROW10.HASHVAL和seq number=130插入到Writeset歷史MAP中。
整個過程結(jié)束。last commit由以前的130降低為120,目的達到了。實際上我們可以看出Writeset歷史MAP就相當(dāng)于保存了一段時間以來修改行的快照,如果保證本次事務(wù)修改的數(shù)據(jù)在這段時間內(nèi)沒有沖突,那么顯然是可以在從庫并行執(zhí)行的。last commit降低后如下圖(圖16-2,高清原圖包含在文末原圖中):
整個邏輯就在函數(shù)Writeset_trx_dependency_tracker::get_dependency中,下面是一些關(guān)鍵代碼,代碼稍多:
if (can_use_writesets) //如果能夠使用writeset 方式
{
/*
Check if adding this transaction exceeds the capacity of the writeset
history. If that happens, m_writeset_history will be cleared only after 而 add_pke
using its information for current transaction.
*/
exceeds_capacity=
m_writeset_history.size() + writeset->size() > m_opt_max_history_size;
//如果大于參數(shù)binlog_transaction_dependency_history_size設(shè)置清理標(biāo)記
/*
Compute the greatest sequence_number among all conflicts and add the
transaction's row hashes to the history.
*/
int64 last_parent= m_writeset_history_start;
//臨時變量,首先設(shè)置為最小的一個seq number
for (std::set<uint64>::iterator it= writeset->begin(); it != writeset->end(); ++it)
//循環(huán)每一個Writeset中的每一個元素
{
Writeset_history::iterator hst= m_writeset_history.find(*it);
//是否在writeset history中 已經(jīng)存在了。 map中的元素是 key是writeset 值是sequence number
if (hst != m_writeset_history.end()) //如果存在
{
if (hst->second > last_parent && hst->second < sequence_number)
last_parent= hst->second;
//如果已經(jīng)大于了不需要設(shè)置
hst->second= sequence_number;
//更改這行記錄的sequence_number
}
else
{
if (!exceeds_capacity)
m_writeset_history.insert(std::pair<uint64, int64>(*it, sequence_number));
//沒有沖突則插入。
}
}
......
if (!write_set_ctx->get_has_missing_keys())
//如果沒有主鍵和唯一鍵那么不更改last commit
{
/*
The WRITESET commit_parent then becomes the minimum of largest parent
found using the hashes of the row touched by the transaction and the
commit parent calculated with COMMIT_ORDER.
*/;
commit_parent= std::min(last_parent, commit_parent);
//這里對last commit做更改了。降低他的last commit
}
}
}
}
if (exceeds_capacity || !can_use_writesets)
{
m_writeset_history_start= sequence_number;
//如果超過最大設(shè)置 清空writeset history。從當(dāng)前sequence 重新記錄 也就是最小的那個事務(wù)seqnuce number
m_writeset_history.clear();//清空真?zhèn)€MAP
}前面說過這種方式就是在WRITESET的基礎(chǔ)上繼續(xù)處理,實際上它的含義就是同一個session的事務(wù)不允許在從庫并行回放。代碼很簡單,如下:
int64 session_parent= thd->rpl_thd_ctx.dependency_tracker_ctx(). get_last_session_sequence_number(); //取本session的上一次事務(wù)的seq number if (session_parent != 0 && session_parent < sequence_number) //如果本session已經(jīng)做過事務(wù)并且本次當(dāng)前的seq number大于上一次的seq number commit_parent= std::max(commit_parent, session_parent); //說明這個session做過多次事務(wù)不允許并發(fā),修改為order_commit生成的last commit thd->rpl_thd_ctx.dependency_tracker_ctx(). set_last_session_sequence_number(sequence_number); //設(shè)置session_parent的值為本次seq number的值
經(jīng)過這個操作后,我們發(fā)現(xiàn)這種情況最后last commit恢復(fù)成了ORDER_COMMIT的方式。
本參數(shù)默認值為25000。代表的是我們說的Writeset歷史MAP中元素的個數(shù)。如前面分析的Writeset生成過程中修改一行數(shù)據(jù)可能會生成多個HASH值,因此這個值還不能完全等待于修改的行數(shù),可以理解為如下:
binlog_transaction_dependency_history_size/2=修改的行數(shù) * (1+唯一鍵個數(shù))
我們通過前面的分析可以發(fā)現(xiàn)如果這個值越大那么在Writeset歷史MAP中能容下的元素也就越多,生成的last commit就可能更加精確(更加小),從庫并發(fā)的效率也就可能越高。但是我們需要注意設(shè)置越大相應(yīng)的內(nèi)存需求也就越高了。
實際上在函數(shù)add_pke中就會判斷是否有主鍵或者唯一鍵,如果存在唯一鍵也是可以。Writeset中存儲了唯一鍵的行數(shù)據(jù)hash值。參考函數(shù)add_pke,下面是判斷:
if (!((table->key_info[key_number].flags & (HA_NOSAME )) == HA_NOSAME)) //跳過非唯一的KEY continue;
如果沒有主鍵或者唯一鍵那么下面語句將被觸發(fā):
if (writeset_hashes_added == 0) ws_ctx->set_has_missing_keys();
然后我們在生成last commit會判斷這個設(shè)置如下:
if (!write_set_ctx->get_has_missing_keys())
//如果沒有主鍵和唯一鍵那么不更改last commit
{
/*
The WRITESET commit_parent then becomes the minimum of largest parent
found using the hashes of the row touched by the transaction and the
commit parent calculated with COMMIT_ORDER.
*/;
commit_parent= std::min(last_parent, commit_parent);//這里對last commit做更改了。降低他的last commit
}
}因此沒有主鍵可以使用唯一鍵,如果都沒有的話WRITESET設(shè)置就不會生效回退到老的ORDER_COMMIT方式。
有了前面的基礎(chǔ),我們就很容易解釋這種現(xiàn)象了。其主要原因就是Writeset的歷史MAP的存在,只要這些事務(wù)修改的行沒有沖突,也就是主鍵/唯一鍵不相同,那么在基于WRITESET的并行復(fù)制方式中就可以存在這種現(xiàn)象,但是如果binlog_transaction_dependency_tracking設(shè)置為WRITESET_SESSION則不會出現(xiàn)這種現(xiàn)象。
到此,相信大家對“MySQL中基于WRITESET的并行復(fù)制方式是什么”有了更深的了解,不妨來實際操作一番吧!這里是創(chuàng)新互聯(lián)網(wǎng)站,更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢,關(guān)注我們,繼續(xù)學(xué)習(xí)!
當(dāng)前題目:MySQL中基于WRITESET的并行復(fù)制方式是什么
URL地址:http://www.chinadenli.net/article36/gcsipg.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供面包屑導(dǎo)航、搜索引擎優(yōu)化、云服務(wù)器、企業(yè)建站、App設(shè)計、網(wǎng)頁設(shè)計公司
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)