本篇內(nèi)容主要講解“MySQL中基于WRITESET的并行復制方式是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“MySQL中基于WRITESET的并行復制方式是什么”吧!

公司主營業(yè)務：成都做網(wǎng)站、成都網(wǎng)站建設(shè)、移動網(wǎng)站開發(fā)等業(yè)務。幫助企業(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：

我們可以看到其中的last commit看起來是亂序的，這種情況在基于COMMIT_ORDER 的并行復制方式下是不可能出現(xiàn)的。實際上它就是我們前面說的基于WRITESET的并行復制再盡可能降低的last commit的結(jié)果。這種情況會在MTS從庫獲得更好的并行回放效果，第19節(jié)將會詳細解釋并行判定的標準。

二、Writeset是什么

實際上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，后面我也會以偽代碼的方式給出部分流程。

但是需要注意一個事務的所有的行數(shù)據(jù)的hash值都要寫入到一個Writeset。如果修改的行比較多那么可能需要更多內(nèi)存來存儲這些hash值。雖然8字節(jié)比較小，但是如果一個事務修改的行很多，那么還是需要消耗較多的內(nèi)存資源的。

為了更直觀的觀察到這種數(shù)據(jù)格式，可以使用debug的方式獲取。下面我們來看一下。

三、Writeset的生成

我們使用如下表：

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個元素分別為：

注意：這里顯示的?是分隔符

1. 主鍵二進制格式

(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

2. 主鍵字符串格式：

(gdb) p pke
$2 = "PRIMARY?test?4jj10?436?2"

分解為：
| 主鍵名稱 | 分隔符 | 庫名 | 分隔符 |庫名長度 | 表名 |分隔符|表名長度|主鍵字段1|分隔符|長度 |
| ——— | ——— | ——— | ——— | ——— | ——— | ——— | ——— | ——— |——— |———|
| PRIMARY |?| test|?|4|jj10|?|4|36 | ?|2|

3. 唯一鍵二進制格式

(gdb) p pke
$3 = "id1?test?4jj10?4\200\000\000$?4"

解析同上

4. 唯一鍵字符串格式：

(gdb) p pke
$4 = "id1?test?4jj10?436?2"

解析同上

最終這些數(shù)據(jù)會通過hash算法后寫入到Writeset中。

四、函數(shù)add_pke的大概流程

下面是一段偽代碼，用來描述這種生成過程：

如果表中存在索引：
   將數(shù)據(jù)庫名，表名信息寫入臨時變量   
   循環(huán)掃描表中每個索引：
        如果不是唯一索引：
             退出本次循環(huán)繼續(xù)循環(huán)。
        循環(huán)兩種生成數(shù)據(jù)的方式(二進制格式和字符串格式)：
             將索引名字寫入到pke中。
             將臨時變量信息寫入到pke中。
             循環(huán)掃描索引中的每一個字段：
                將每一個字段的信息寫入到pke中。
                如果字段掃描完成：
                   將pke生成hash值并且寫入到寫集合中。
    如果沒有找到主鍵或者唯一鍵記錄一個標記，后面通過這個標記來
    判定是否使用Writeset的并行復制方式

五、Writeset設(shè)置對last commit的處理方式

前一節(jié)我們討論了基于ORDER_COMMIT的并行復制是如何生成last_commit和seq number的。實際上基于WRITESET的并行復制方式只是在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再次做處理。

這段描述的代碼對應：

    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;

六、Writeset的歷史MAP

我們到這里已經(jīng)討論了Writeset是什么，也已經(jīng)說過如果要降低last commit的值我們需要通過對事務的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ù)修改事務的seq number

它是按照Writeset的hash值進行排序的。

其次內(nèi)存中還維護一個叫做m_writeset_history_start的值，用于記錄Writeset的歷史MAP中最早事務的seq number。如果Writeset的歷史MAP滿了就會清理這個歷史MAP然后將本事務的seq number寫入m_writeset_history_start，作為最早的seq number。后面會看到對于事務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。從當前seq number 重新記錄， 也就是最小的那個事務seq number
    m_writeset_history.clear();
//清空歷史MAP
  }

七、Writeset的并行復制對last commit的處理流程

這里介紹一下整個處理的過程，假設(shè)如下：

• 當前通過基于ORDER_COMMIT的并行復制方式后，構(gòu)造出來的是（last commit=125，seq number=130）。

• 本事務修改了4條數(shù)據(jù)，我分別使用ROW1/ROW7/ROW6/ROW10代表。

• 表只包含主鍵沒有唯一鍵，并且我的圖中只保留行數(shù)據(jù)的二進制格式的hash值，而沒有包含數(shù)據(jù)的字符串格式的hash值。

初始化情況如下圖（圖16-1，高清原圖包含在文末原圖中）：

1. 第一步 設(shè)置last commit為writeset_history_start的值也就是100。

2. 第二步 ROW1.HASHVAL在Writeset歷史MAP中查找，找到?jīng)_突的行ROW1.HASHVAL將歷史MAP中這行數(shù)據(jù)的seq number更改為130。同時設(shè)置last commit為120。

3. 第三步 ROW7.HASHVAL在Writeset歷史MAP中查找，找到?jīng)_突的行ROW7.HASHVAL將Writeset歷史MAP中這行數(shù)據(jù)的seq number更改為130。由于歷史MAP中對應的seq number為114，小于120不做更改。last commit依舊為120。

4. 第四步 ROW6.HASHVAL在Writeset歷史MAP中查找，找到?jīng)_突的行ROW6.HASHVAL將Writeset歷史MAP中這行數(shù)據(jù)的seq number更改為130。由于歷史MAP中對應的seq number為105，小于120不做更改。last commit依舊為120。

5. 第五步 ROW10.HASHVAL在Writeset歷史MAP中查找，沒有找到?jīng)_突的行，因此需要將這一行插入到Writeset歷史MAP中查找（需要判斷是否導致歷史MAP占滿，如果占滿則不需要插入，后面隨即要清理掉）。即要將ROW10.HASHVAL和seq number=130插入到Writeset歷史MAP中。

整個過程結(jié)束。last commit由以前的130降低為120，目的達到了。實際上我們可以看出Writeset歷史MAP就相當于保存了一段時間以來修改行的快照，如果保證本次事務修改的數(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è)置清理標記
    /*
     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。從當前sequence 重新記錄 也就是最小的那個事務seqnuce number
    m_writeset_history.clear();//清空真?zhèn)€MAP
  }

八、WRITESET_SESSION的方式

前面說過這種方式就是在WRITESET的基礎(chǔ)上繼續(xù)處理，實際上它的含義就是同一個session的事務不允許在從庫并行回放。代碼很簡單，如下：

  int64 session_parent= thd->rpl_thd_ctx.dependency_tracker_ctx().
                        get_last_session_sequence_number();
//取本session的上一次事務的seq number
  if (session_parent != 0 && session_parent < sequence_number) 
//如果本session已經(jīng)做過事務并且本次當前的seq number大于上一次的seq number
    commit_parent= std::max(commit_parent, session_parent);
//說明這個session做過多次事務不允許并發(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恢復成了ORDER_COMMIT的方式。

九、關(guān)于binlog_transaction_dependency_history_size參數(shù)說明

本參數(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è)置越大相應的內(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方式。

十一、為什么同一個session執(zhí)行的事務也能生成同樣的last commit

有了前面的基礎(chǔ)，我們就很容易解釋這種現(xiàn)象了。其主要原因就是Writeset的歷史MAP的存在，只要這些事務修改的行沒有沖突，也就是主鍵/唯一鍵不相同，那么在基于WRITESET的并行復制方式中就可以存在這種現(xiàn)象，但是如果binlog_transaction_dependency_tracking設(shè)置為WRITESET_SESSION則不會出現(xiàn)這種現(xiàn)象。

到此，相信大家對“MySQL中基于WRITESET的并行復制方式是什么”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學習！

當前題目：MySQL中基于WRITESET的并行復制方式是什么
URL地址：http://m.newbst.com/article36/gcsipg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供面包屑導航、搜索引擎優(yōu)化、云服務器、企業(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)