mysql主從一致性校驗工具-pt
一、環境
1、系統環境
系統 | IP | 主機名 | 說明 | server_id |
---|---|---|---|---|
centos6.7 | MasterIP | master | 數據庫:主 | 177 |
centos6.7 | SlaveIP | slave | 數據庫:從 | 148 |
2、軟件環境
軟件 | 版本 | 安裝方式 | 說明 |
---|---|---|---|
pt工具 | 3.0.4 | 編譯安裝 | 這是一個綜合工具包,包含很多pt命令 |
mysql數據庫 | 5.6.37 | yum安裝 | 主從環境 |
3、需要用到庫
庫名 | 表名 | 用途 |
---|---|---|
percona | checksums |
存儲pt命令監測的結果,第一次執行檢測命令時會自己創建 修復工具修復的時候會讀取該表 |
#本表格也可以自己創建,在使用pt工具的時候指定庫表名字,詳見下面的參數解釋。
註意:自建庫表測試尚未通過。
二、為什麽要做主從一致性監測
1、主從復制是基於binlog的邏輯復制,難免出現復制數據不一致的風險
2、這個風險不但會引起用戶數據訪問前後不一致的風險
3、而且會導致後續復制出現1032、1062錯誤進而引起復制架構停滯的隱患
4、為了及時發現並解決這個問題
5、我們需要定期或不定期地開展主從復制數據一致性的校驗和修復工作
三、主從一致性監測原理
四、pt工具監測
用到的命令:
1、pt-table-check #監測主從一致
2、pt-table-sync #修復主從一致
mysql主從一致性校驗,基於pt工具進行。
#限制及問題
1、在檢查階段,超過1000行的數據,如果沒有設定索引或者主鍵,則報錯,該表會跳過檢查。
2、在修復階段,如果表沒有設置主鍵或索引,則修復報錯,可以手動進行修復。
3、監測是基於塊進行的,如果mysql表的數據沒有進行分塊,那麽當表過大時,會造成監測一段時間後發現沒有問題會跳過改表。
4、當數據庫兩個數據不一致,但是checksum檢測一致時,沒有比對出不一致。
主庫和從庫賬號一致,密碼不一致發現了這種問題。
原因:對於修改密碼的操作,chencksum的值並沒有發生變化。
五、安裝pt工具
最好所有主庫從庫都安裝
1、安裝依賴
yum install perl-IO-Socket-SSL perl-DBD-MySQL perl-Time-HiRes perl perl-DBI -y
yum install perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker -y
2、下載安裝包
1、官網下載
3、安裝
tar xzvf percona-toolkit-3.0.4_x86_64.tar.gz
cd percona-toolkit-3.0.4
perl Makefile.PL --安裝到非默認路徑PREFIX=${HOME}
make
make test
make install
六、pt工具常用命令
1、創建監測賬號
grant all on *.* to ‘zxfly_check‘@‘192.168.22.% ‘ identified by ‘zxfly‘;
flush privileges;
2、監控用的表為:percona.checksum該表會自動創建。
監測:
#指定庫名
pt-table-checksum --databases zxfly -u‘zxfly‘ -p‘zxfly‘ -hMasterIP -P3306 2>/logs/pt_error.log 1>/logs/pt_info.log
#不指定庫,監測所有數據庫(除information_schema、percona、performance_schema庫)
pt-table-checksum --quiet -u‘zxfly‘ -p‘zxfly‘ -hMasterIP -P3306 2>/logs/pt_error.log 1>/logs/pt_info.log
pt-table-checksum --replicate-check-only -u‘zxfly‘ -p‘zxfly‘ -hMasterIP -P3306
打印修復sql:指定庫表
pt-table-sync --databases=dataname --tables=table1,table2 h=MasterIP,u=zxfly,p=zxfly h=SlaveIP,u=zxfly,p=zxfly --charset=utf8 --print
修復:
pt-table-sync --databases=dataname --tables=table1,table2 h=MasterIP,u=zxfly,p=zxfly h=SlaveIP,u=zxfly,p=zxfly --charset=utf8 --exec
七、pt工具常用參數
1、pt-table-checksum
參數 | 參數說明 | 備註 |
---|---|---|
--[no]check-replication-filters | 不檢查復制過濾器,建議啟用。後面可以用--databases來指定需要檢查的數據庫。 | 當前環境不需要該參數,默認開啟 |
--no-check-binlog-format | 不檢查復制的binlog模式,要是binlog模式是ROW,則會報錯。 | 默認是監測,使用默認值,如果添加該參數可能導致diff不出來 |
--replicate-check-only | 只顯示不同步的信息。 |
開啟這個,可以減少輸出並且顯示不一致的從庫主機名 不過這個只是顯示已經檢測過的不一致信息,並不能顯示當前的。 |
--replicate= | 把checksum的信息寫入到指定表中,建議直接寫到被檢查的數據庫當中。不需要指定 | 默認會創建percona庫下checksum表 |
-h -u -p -P | masterIP 監測賬號 密碼 端口 | |
--databases= | 指定需要被檢查的數據庫,多個則用逗號隔開。 | |
--tables= | 指定需要被檢查的表,多個用逗號隔開 | |
--recursion-method | 指定監測從庫的模式,默認使用processlist,也可以指定dsn |
多個從庫可以這樣指定。--recursion-method=dsn=h=host,D=pt,t=dsns D 庫名 t 表名 |
--quiet | 安靜模式,最小化打印,紙打印錯誤行 | 與--replicate-check-only類似,但不顯示從庫信息 |
dsn庫表結構及用法為:
- CREATE TABLE `dsns` ( `id` int(11) NOT NULL AUTO_INCREMENT, `parent_id` int(11) DEFAULT NULL, `dsn` varchar(255) NOT NULL, PRIMARY KEY (`id`) );
- -- 寫入從庫信息
- INSERT INTO dsns (parent_id,dsn) values(1, "h=replica_host,u=checksums,p=password,P=3306");
- -- 如果有多個從庫,就插入多條記錄.
- -- 也可以按如下簡寫
- INSERT INTO dsns (parent_id,dsn) values(1, "h=replica_host");
2、pt-table-sync
參數 | 參數說明 | 備註 |
---|---|---|
--replicate= | 指定通過pt-table-checksum得到的表 | 默認會創建percona庫下checksum表時不需要指定 |
--databases= | 指定執行同步的數據庫 | 在只修復指定的庫時使用 |
--tables= | 指定需要被修復的表,多個用逗號隔開 | |
--sync-to-master | 指定一個DSN,即從的IP | 會通過show processlist或show slave status 去自動的找主。報錯找不到主庫時使用 |
h= u= p= | 服務器地址,賬號,密碼 | 命令裏有2個ip,第一次出現的是Master的地址,第2次是Slave的地址。 |
打印修復的sql語句 | 只打印不執行。 | |
--exec 或 --execute | 執行修復 | |
--algorithms=c | 指定修復算法 |
default Chunk,Nibble,GroupBy,Stream 在報錯算法問題的時候需要指定算法 |
--charset= | 指定默認字符集 | 如果數據中包含中文不指定次字符集的話修復不成功 |
3、輸出信息解釋
TS :完成檢查的時間。
ERRORS :檢查時候發生錯誤和警告的數量。
DIFFS :0表示一致,1表示不一致。當指定--no-replicate-check時,會一直為0,當指定--replicate-check-only會顯示不同的信息。
ROWS :表的行數。
CHUNKS :被劃分到表中的塊的數目。
SKIPPED :由於錯誤或警告或過大,則跳過塊的數目。
TIME :執行的時間。
TABLE :被檢查的表名。
八、pt工具常見報錯信息
1、監測報錯(找不到從庫,使用--recursion-method指定模式)
Diffs cannot be detected because no slaves were found. Please read the --recursion-method documentation for information.
2、binlog模式問題(由於指定為row行復制造成 使用--no-check-binlog-format跳過監測,不過這樣有可能監測不出來主從不一致的信息,row行模式對於主從來說不需要進行主從監測)
Replica centos-1 has binlog_format ROW which could cause pt-table-checksum to break replication. Please read "Replicas using row-based replication" in the LIMITATIONS section of the tool‘s documentation. If you understand the risks, specify --no-check-binlog-format to disable this check.
3、沒有索引或主鍵導致的,在數據較少的時候(低於1000行,沒有測試出該信息,超過1000行會報錯)
Cannot checksum table test.t: There is no good index and the table is oversized. at ./pt-table-checksum line 6370.
4、等待信息,已檢測的百分比,這是因為設置了主鍵但是沒有索引導致沒有分塊且表過大造成。
Checksumming database.table: 27% 01:17 remain
九、對多個庫所有數據進行監測結果
pt-table-checksum監測數據庫結果:
數據大小 | 監測花費時間 | 監測報錯的表 | 原因 |
---|---|---|---|
93G | 30m28.523s |
4個 |
#字符集bug(工具自帶,無法解決) 正式平臺這些表都沒有 |
1個 |
未監測到(中文表名監測不到) 正式平臺無此表 |
||
1個 | 沒有主鍵或者索引(數據條數:132835) |
十、pt修復工具pt-table-sync遇到的問題
在使用pt-table-checksum進行檢測後,發現主從不一致的情況後可以使用pt-table-sync工具進行修復操作。
其原理為:基於pt-table-checksum監測的結果進行檢查並生成修復語句去修復從庫中的數據。
遇到的報錯:
1、修復時候沒有任何提示,但是修復報錯。使用–print打印修復語句發現又亂碼。
處理方法:查看表的字符集,通過--charset=命令指定默認字符集
2、報錯:Failed to prepare TableSyncChunk plugin: Cannot chunk table `zxfly_zxfly1`.`mongo_task_data` using the character column guid, most likely because all values start with the same character. This table must be synced separately by specifying a list of --algorithms without the Chunk algorithm at /usr/local/bin/pt-table-sync line 4088. while doing table on 192.168.0.177
原因是在默認的算法中,要保證主鍵字段的數據前一位有不一樣字符出現,而該表的主鍵數據第一個字符是一樣的。
解決辦法:
使用--algorithms=參數指定算法,當然這種應該最好分庫分表進行恢復。
6、修復報錯(原因:沒有唯一索引或主鍵導致的,1000以內的,1000行以上沒有索引或主鍵在監測時就會跳過。)
Can‘t make changes on the master because no unique index exists at /usr/local/bin/pt-table-sync line 10591.
mysql主從一致性校驗工具-pt