pt-table-checksum原理詳解

mysql: mysql 5.6.27 os: centos 6.6 tool: pt-table-checksum 2.2.15

業界最流行的mysql主從資料對比工具，資料一緻性檢測最好的的工具，沒有之一

./pt-table-checksum -hxx -p 3306 -u backup -p backup --no-check-binlog-format --databases=xx_db,yy_db,zz_db --no-check-replication-filters

大緻的原理網上都能看到，這裡會描述幾個核心的點 這裡假設就一個庫，一張表，100條記錄 pt-table-checksum進行比對的時候，不是一條條記錄比的，而是一個個chunk進行對比 這裡我們将100條記錄分為10個chunk，一個chunk 10條記錄。 每個chunk對比完後，再進行下一個chunk對比，直到全部結束。是以，這裡我們就以一個chunk來描述下面的原理即可

master> /!50108 set @@binlog_format := 'statement'/ 設定binlog-format為statement

master> set session transaction isolation level repeatable read 這是隔離級别為rr，利用rr的特性讓資料在這一刻靜止，就不用加鎖了。

master&gt; checksums表：replace into select設定this_cnt, this_crc(傳遞到slave，這其實設定slave每個chunk的cnt,crc)，算法來自：coalesce(lower(conv(bit_xor(cast(crc32(<code>主鍵</code>) as unsigned)), 10, 16)), 0)

slave&gt; 當同步追上後，開始執行replace into select，然後設定slave每個chunk的cnt,crc

master&gt; checksums表：update master_cnt,master_crc ，這是設定master每個chunk的cnt，crc

slave&gt; 當同步追上後，開始執行update master_cnt,master_crc ，這是設定master每個chunk的cnt，crc

以上，基本完成。 接下來隻需要去checksums表中找 master_cnt &lt;&gt; this_cnt or or master_crc &lt;&gt; this_crc 的記錄就行

一般在什麼場景下使用pt-table-checksum？會在生産環境的master上用嗎？

如果不太在乎master和slave之間的一緻性的話，在master上設定row模式後，就基本可以保證資料一緻了。 pt-table-checksum雖然很智能，但還是會對伺服器造成一定的影響，是以一般不會用在master上,除非迫不得已 一般檢查資料一緻性，我們都會在兩台slave上進行對比，如果兩台slave ok，基本就ok了

聽說該工具隻對statement格式有用，如果是row格式，還能檢查一緻性嗎？為什麼？

如果是row模式，pt-table-checksum會報錯，但是加上--no-check-binlog-format 即可 此工具會自動設定row-format=statement，是以使用者不用擔心。即便設定row，也沒事

它是怎麼做到master和slave的記錄對比的，master不是一直再更新嗎？會有鎖嗎？

詳細原理，請看上面的原理分析。 master一直再更新沒錯，但是不會有鎖，利用rr隔離級别的特性就能保證目前事務的資料是不會變的

rr隔離級别是什麼鬼？為什麼能夠保證目前事務的資料不變呢？

如果master和slave直接的表結構不一緻，目前是沒辦法檢測出來的

風險1

這裡設定了set session transaction isolation level repeatable read 直到對比完成，才結束這個session. 那這樣意味什麼呢？意味着如果這個session不結束，這個事務對應的undo一直不會被purge，會導緻undo不斷變大，即ibdata會一直變大。 措施：盡量在低峰期執行

風險2

這裡是通過rr隔離級别來保證select crc的值一緻的，那麼如果rr被破壞了呢？ 沒錯，這樣的對比，很容易被ddl所破壞。 措施：ddl是可以人為控制時間視窗和周期的