pt-table-checksum原理詳解

蘭春發表於2016-08-19

環境

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

如何找到不一致的地方

* slave上執行:
SELECT db, tbl, SUM(this_cnt) AS total_rows, COUNT(*) AS chunks
FROM percona.checksums
WHERE (
 master_cnt <> this_cnt
 OR master_crc <> this_crc
 OR ISNULL(master_crc) <> ISNULL(this_crc))
GROUP BY db, tbl;

原理

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

  1. master> /!50108 SET @@binlog_format := `STATEMENT`/ 設定binlog-format為statement
  2. master> SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 這是隔離級別為RR，利用RR的特性讓資料在這一刻靜止，就不用加鎖了。
  3. master> checksums表：REPLACE INTO select設定this_cnt, this_crc(傳遞到slave，這其實設定slave每個chunk的cnt,crc)，演算法來自：COALESCE(LOWER(CONV(BIT_XOR(CAST(CRC32(主鍵) AS UNSIGNED)), 10, 16)), 0)
  4. slave> 當同步追上後，開始執行REPLACE INTO select，然後設定slave每個chunk的cnt,crc
  5. master> checksums表：update master_cnt,master_crc ，這是設定master每個chunk的cnt，crc
  6. slave> 當同步追上後，開始執行update master_cnt,master_crc ，這是設定master每個chunk的cnt，crc

以上，基本完成。 接下來只需要去checksums表中找 master_cnt <> this_cnt or OR master_crc <> this_crc 的記錄就行

常問的問題

  • 一般在什麼場景下使用pt-table-checksum？會在生產環境的master上用嗎？
  1. 如果不太在乎master和slave之間的一致性的話，在master上設定ROW模式後，就基本可以保證資料一致了。
  2. pt-table-checksum雖然很智慧，但還是會對伺服器造成一定的影響，所以一般不會用在master上,除非迫不得已
  3. 一般檢查資料一致性，我們都會在兩臺slave上進行對比，如果兩臺slave ok，基本就ok了
  • 聽說該工具只對statement格式有用，如果是row格式，還能檢查一致性嗎？為什麼？
  1. 如果是row模式，pt-table-checksum會報錯，但是加上–no-check-binlog-format 即可
  2. 此工具會自動設定row-format=statement，所以使用者不用擔心。即便設定row，也沒事
  • 它是怎麼做到master和slave的記錄對比的，master不是一直再更新嗎？會有鎖嗎？
  1. 詳細原理，請看上面的原理分析。
  2. master一直再更新沒錯，但是不會有鎖，利用RR隔離級別的特性就能保證當前事務的資料是不會變的
  • RR隔離級別是什麼鬼？為什麼能夠保證當前事務的資料不變呢？
  1. 可參看之前的分享: SELECT 你知多少

缺陷

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

master：table xx( A int,B char)
slave:  table xx( A int)

pt-table-checksum 無法檢測B欄位。。。

重要

  • 風險1

這裡設定了SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 直到對比完成，才結束這個session.
那這樣意味什麼呢？意味著如果這個session不結束，這個事務對應的undo一直不會被purge，會導致undo不斷變大，即ibdata會一直變大。
措施：儘量在低峰期執行

  • 風險2

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


相關文章