一、系統環境css
系統 | IP | 主機名 | 說明 | server_id |
---|---|---|---|---|
centos6.7 | MasterIP | master | 數據庫:主 | 177 |
centos6.7 | SlaveIP | slave | 數據庫:從 | 148 |
二、軟件環境mysql
軟件 | 版本 | 安裝方式 | 說明 |
---|---|---|---|
pt工具 | 3.0.4 | 編譯安裝 | 這是一個綜合工具包,包含不少pt命令 |
mysql數據庫 | 5.6.37 | yum安裝 | 主從環境 |
三、須要用到庫算法
庫名 | 表名 | 用途 |
---|---|---|
percona | checksums | 存儲pt命令監測的結果,第一次執行檢測命令時會本身建立sql 修復工具修復的時候會讀取該表數據庫 |
#本表格也能夠本身建立,在使用pt工具的時候指定庫表名字,詳見下面的參數解釋。centos
注意:自建庫表測試還沒有經過。服務器
一、主從複製是基於binlog的邏輯複製,不免出現複製數據不一致的風險架構
二、這個風險不但會引發用戶數據訪問先後不一致的風險ide
三、並且會致使後續複製出現103二、1062錯誤進而引發複製架構停滯的隱患工具
四、爲了及時發現並解決這個問題
五、咱們須要按期或不按期地開展主從複製數據一致性的校驗和修復工做
用到的命令:
一、pt-table-check #監測主從一致
二、pt-table-sync #修復主從一致
mysql主從一致性校驗,基於pt工具進行。
#限制及問題
一、在檢查階段,超過1000行的數據,若是沒有設定索引或者主鍵,則報錯,該表會跳過檢查。
二、在修復階段,若是表沒有設置主鍵或索引,則修復報錯,能夠手動進行修復。
三、監測是基於塊進行的,若是mysql表的數據沒有進行分塊,那麼當表過大時,會形成監測一段時間後發現沒有問題會跳過改表。
四、當數據庫兩個數據不一致,可是checksum檢測一致時,沒有比對出不一致。
主庫和從庫帳號一致,密碼不一致發現了這種問題。
緣由:對於修改密碼的操做,chencksum的值並無發生變化。
最好全部主庫從庫都安裝
一、安裝依賴
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
二、下載安裝包
一、官網下載
三、安裝
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
一、建立監測帳號
grant all on *.* to 'zxfly_check'@'192.168.22.% ' identified by 'zxfly';
flush privileges;
二、監控用的表爲: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-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庫表結構及用法爲:
二、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= | 指定默認字符集 | 若是數據中包含中文不指定次字符集的話修復不成功 |
三、輸出信息解釋
TS :完成檢查的時間。
ERRORS :檢查時候發生錯誤和警告的數量。
DIFFS :0表示一致,1表示不一致。當指定--no-replicate-check時,會一直爲0,當指定--replicate-check-only會顯示不一樣的信息。
ROWS :表的行數。
CHUNKS :被劃分到表中的塊的數目。
SKIPPED :因爲錯誤或警告或過大,則跳過塊的數目。
TIME :執行的時間。
TABLE :被檢查的表名。
一、監測報錯(找不到從庫,使用--recursion-method指定模式)
Diffs cannot be detected because no slaves were found. Please read the --recursion-method documentation for information.
二、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.
三、沒有索引或主鍵致使的,在數據較少的時候(低於1000行,沒有測試出該信息,超過1000行會報錯)
Cannot checksum table test.t: There is no good index and the table is oversized. at ./pt-table-checksum line 6370.
四、等待信息,已檢測的百分比,這是由於設置了主鍵可是沒有索引致使沒有分塊且表過大形成。
Checksumming database.table: 27% 01:17 remain
pt-table-checksum監測數據庫結果:
數據大小 | 監測花費時間 | 監測報錯的表 | 緣由 |
---|---|---|---|
93G | 30m28.523s | 4個 |
#字符集bug(工具自帶,沒法解決) 正式平臺這些表都沒有 |
1個 | 未監測到(中文表名監測不到) 正式平臺無此表 |
||
1個 | 沒有主鍵或者索引(數據條數:132835) |
在使用pt-table-checksum進行檢測後,發現主從不一致的狀況後可使用pt-table-sync工具進行修復操做。
其原理爲:基於pt-table-checksum監測的結果進行檢查並生成修復語句去修復從庫中的數據。
遇到的報錯:
一、修復時候沒有任何提示,可是修復報錯。使用–print打印修復語句發現又亂碼。
處理方法:查看錶的字符集,經過--charset=命令指定默認字符集
二、報錯: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=參數指定算法,固然這種應該最好分庫分表進行恢復。
六、修復報錯(緣由:沒有惟一索引或主鍵致使的,1000之內的,1000行以上沒有索引或主鍵在監測時就會跳過。)
Can't make changes on the master because no unique index exists at /usr/local/bin/pt-table-sync line 10591.