国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

MySQL如何解決主從數據不一致問題

IT那活兒 / 3416人閱讀
MySQL如何解決主從數據不一致問題

點擊上方“IT那活兒”，關注后了解更多內容，不管IT什么活兒，干就完了！！！





背景介紹



兩臺MySQL,發生了種種種種，導致了兩個表的數據不一致，但是同步還在正常進行，后來意識到這種問題（可能之前skip啊，或者一開始搭建的時候就是不一致的狀態），該如何修復呢？
我們可以來看下percona-toolkit這個工具是如何修復這種情況的。





環境搭建



1. 校驗

  • 主庫：192.168.100.8 3306

  • 從庫：192.168.100.12 3305

  • MySQL version：MySQL-5.6.30

1）master 服務器安裝yum依賴包：
yum install perl perl-devel perl-Time-HiRes perl-DBI perl-DBD-MySQL
2）安裝percona-toolkit工具包：
wget http://www.percona.com/get/percona-toolkit.tar.gz
tar zxf percona-toolkit-2.2.13.tar.gz
cd percona-toolkit-2.2.13
perl Makefile.PL
make && make install
3）master與slave數據庫創建以及用戶授權：
Create database pt CHARACTER SET utf8;
GRANT UPDATE,INSERT,DELETE,SELECT, PROCESS, SUPER, REPLICATION SLAVE ON . TO backup@192.168.100.8 identified by abc123;
GRANT ALL ON pt.* TO backup@192.168.100.8 IDENTIFIED BY abc123;
flush privileges;

use pt;
CREATE TABLE IF NOT EXISTS checksums (
db char(64) NOT NULL,
tbl char(64) NOT NULL,
chunk int NOT NULL,
chunk_time float NULL,
chunk_index varchar(200) NULL,
lower_boundary text NULL,
upper_boundary text NULL,
this_crc char(40) NOT NULL,
this_cnt int NOT NULL,
master_crc char(40) NULL,
master_cnt int NULL,
ts timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (db, tbl, chunk),
INDEX ts_db_tbl (ts, db, tbl)
) ENGINE=InnoDB;
4）進行校驗 master上執行：
pt-table-checksum --nocheck-binlog-format --nocheck-plan --
nocheck-replication-filters --replicate=pt.checksums --set-
vars innodb_lock_wait_timeout=120 --databases tmp -ubackup 
-pabc123 -h192.168.100.8 -P3306


  • -h -u -p -P -S -d 連接信息；
  • --nocheck-replication-filters 檢測中忽略mysql 配置參數binlog_ignore_db等；
  • --nocheck-binlog-format 不檢測日志格式；
  • --replicate 指定checksum 存儲的db和表， 如pt.checksum；
  • --chunk-size， --chunk-size-limit 用于指定檢測塊的大小，可控性更強；
  • --ignore-databases/tables/column 跳出指定元素的過濾；
  • --lock-wait-timeout innodb 鎖的超時設定， 默認為1；
  • --max-load 設置最大并發連接數；
  • --replicate-check-only 只輸出數據不一致的信息；
  • --help。
2. 校驗結果
A software update is available:

* The current version for Percona::Toolkit is 2.2.14.

TS ERRORS DIFFS ROWS CHUNKS SKIPPED TIME TABLE
01-21T12:21:59 0 0 3523 4 0 0.385 tmp.COMM_REGION
01-21T12:21:59 0 0 0 1 0 0.011 tmp.UCT_USER
01-21T12:01:04 0 0 115020 1 0 5.001 tmp.UCT_USER_1
01-21T12:01:04 0 0 0 1 0 0.017 tmp.UCT_USER_2
01-21T12:01:04 0 0 710 1 0 0.009 tmp.VOX_APPLICATION_MICROPHONE
01-21T12:01:04 0 0 3778 1 0 0.084 tmp.VOX_CLASS

  • TS ：完成檢查的時間；

  • ERRORS ：檢查時候發生錯誤和警告的數量；

  • DIFFS ：0表示一致，1表示不一致。當指定--no-replicate-check時，會一直為0，當指定--replicate-check-only會顯示不同的信息；

  • ROWS ：表的行數；

  • CHUNKS ：被劃分到表中的塊的數目；

  • SKIPPED ：由于錯誤或警告或過大，則跳過塊的數目；

  • TIME ：執行的時間；

  • TABLE ：被檢查的表名。

注意：
要是在執行命令的過程遇到找不到從服務器的錯誤，默認是通過show processlist 找到host的值或show slave hosts 找到host的值。
Diffs cannot be detected because no slaves were found. 
Please read the --recursion-method documentation for information.
1）關于--recursion-method參數的設置：
METHOD USES
=========== =============================================
processlist SHOW PROCESSLIST
hosts SHOW SLAVE HOSTS
cluster SHOW STATUS LIKE wsrep_incoming_addresses
dsn=DSN DSNs from a table
none Do not find slaves

pt-table-checksum --nocheck-binlog-format --nocheck-plan --nocheck-replication-filters --replicate=pt.checksums --set-vars innodb_lock_wait_timeout=120 --recursion-method dsn=h=10.0.1.73,D=stats,t=dsns -ubackup -pabc123 --host=10.0.1.72 -P3306 --databases=HS_Order（校驗）

[root@goufu data]# pt-table-sync --print --sync-to-master h=10.0.1.73,P=3306,u=backup,p=abc123 --replicate pt.checksums --databases=HS_Order --tables=VOX_REWARD_ORDER>zzz.sql （也可直接加--execute自動修復）

mysql> show slave hosts;
+-----------+------+------+-----------+--------------------------------------+
| Server_id | Host | Port | Master_id | Slave_UUID |
+-----------+------+------+-----------+--------------------------------------+
| 123305 | | 3305 | 533306 | 9645c4a3-178a-11e6-ac5d-d4ae52d034a7 |
+-----------+------+------+-----------+--------------------------------------+
1 row in set (0.00 sec)
在從庫的配置文件里加：report_host = 192.168.200.25 #設置成本地地址。
mysql> show slave hosts;
+-----------+----------------+------+-----------+--------------------------------------+
| Server_id | Host | Port | Master_id | Slave_UUID |
+-----------+----------------+------+-----------+--------------------------------------+
| 123305 | 192.168.100.12 | 3305 | 533306 | 9645c4a3-178a-11e6-ac5d-d4ae52d034a7 |
+-----------+----------------+------+-----------+--------------------------------------+
最后再執行以上命令（多加--recursion-method=hosts 參數）：
pt-table-checksum --nocheck-binlog-format --nocheck-plan --
nocheck-replication-filters --replicate=pt.checksums --set-
vars innodb_lock_wait_timeout=120 --recursion-method=hosts -
-databases tmp -ubackup -pabc123 -h192.168.100.8 -P3306
先校驗出哪些庫的表不同步，然后指定庫與表生成語句，采用第二種方法， 將生成的SQL語句在從庫執行即可。
2）數據同步，復制，消除差異（Master服務器運行） 要是有中文的則需要加上：--charset=utf8，防止亂碼。
i. 自動消除差異（不推薦）：
pt-table-sync --print --execute --sync-to-master h
=192.168.100.87,P=3341,u=backup,p=abc123 --databases=test 
--tables=goufu
ii. 打印出sql語句，人工干預到Slave庫執行（推薦）：
[root@goufu data]# pt-table-sync --print --sync-to-master h
=192.168.100.87,P=3341,u=goufu,p=abc123 --databases=test --tables=goufu 

REPLACE INTO test.goufu(a) VALUES (1) /*percona-toolkit src_db:test src_tbl:goufu
src_dsn:P=3340,h=192.168.100.87,p=...,u=goufu dst_db:test 
dst_tbl:goufu dst_dsn:P=3341,h=192.168.100.87,p=...,u=backup 
lock:1 transaction:1 changing_src:1 replicate:0 
bidirectional:0 pid:7020 user:root host:VM-TEST-87*/;

pt-table-sync --print --sync-to-master 
h=10.1.1.7,P=3306,u=backup,p=abc123--replicate pt.checksums


  • --sync-to-master ：指定一個DSN，即從的IP，他會通過show processlist或show slave status 去自動的找主；

  • --replicate ：指定通過pt-table-checksum得到的表，這2個工具差不多都會一直用；

  • --print ：打印，但不執行命令；

  • --execute ：執行命令。





解決方案




[root@goufu ~]# pt-table-checksum --nocheck-binlog-format --nocheck-plan --nocheck-replication-filters --replicate=pt.checksums --set-vars innodb_lock_wait_timeout=120 --recursion-method=hosts --databases bbs,HomeworkSitter_UAT --tables=dz_common_session,VOX_VOICE_RECOMMEND_DATA_SENTENCE_REF -u backup -pgoufu -h192.168.100.8 -P3306

TS ERRORS DIFFS ROWS CHUNKS SKIPPED TIME TABLE
01-21T15:37:03 0 2 106683 4 0 0.588 HomeworkSitter_UAT.VOX_VOICE_RECOMMEND_DATA_SENTENCE_REF
01-21T15:37:03 0 1 3 1 0 0.026 bbs.dz_common_session
由于其中一個表的數據較大，采用dump導出的方式在從庫上恢復。
1. 第一個執行采用pt-table-sync方式恢復：
pt-table-sync --print --sync-to-master h
=192.168.100.12,P=3305,u=goufu,p=abc123 --databases=bbs --tables=dz_common_session
2. 第二個表采用導出導入的方式恢復：
pt-table-sync --print --sync-to-master h
=192.168.100.12,P=3305,u=goufu,p=abc123 --databases=bbs --
tables=dz_common_session
3. 同步完成后再校驗：
[root@goufu ~]# pt-table-checksum --nocheck-binlog-format --nocheck-plan --nocheck-replication-filters --
replicate=pt.checksums --set-vars innodb_lock_wait_timeout=120 --recursion-method=hosts --
databases bbs,HomeworkSitter_UAT --tables=dz_common_session,VOX_VOICE_RECOMMEND_DATA_SENTENCE_R
EF -ubackup -pabc123 -h192.168.100.8 -P3306 
TS ERRORS DIFFS ROWS CHUNKS SKIPPED TIME TABLE
01-21T16:50:19 0 0 106683 5 0 1.006 HomeworkSitter_UAT.VOX_VOICE_RECOMMEND_DATA_SENTENCE_REF
01-21T16:50:19 0 0 3 1 0 0.013 bbs.dz_common_session






經驗總結



1. 采用replace into來修復主從不一致，必須保證被replace的表上有主鍵或唯一鍵，否則replace into退化成insert into，起不到修復的效果。
這種情況下pt-table-sync會采用其他校驗和修復算法，但是效率非常低，例如對所有列的group by然后求count(*)(表一定要有主鍵！)。
2. 主從數據不一致需要通過replace into來修復，該sql語句必須是語句級。
pt-table-sync會把它發起的所有sql語句都設置為statement格式，而不管全局的binlog_format值。這在級聯A-B-C結構中，也會遇到pt-table-checksum曾經遇到的問題，引起行格式的中繼庫的從庫卡庫是必然。
不過pt-table-sync默認會無限遞歸的對從庫的binlog格式進行檢查并警告。
3. 由于pt-table-sync每次只能修復一個表，所以如果修復的是父表，則可能導致子表數據連帶被修復，這可能會修復一個不一致而引入另一個不一致；如果表上有觸發器，也可能遇到同樣問題。
所以在有觸發器和主外鍵約束的情況下要慎用。
pt-table-sync工具同樣也不歡迎主從異構的結構。pt-table-sync工具默認會進行先決條件的檢查。
4. pt-table-sync在修復過程中不能容忍從庫延遲，這正好與pt-table-checksum相反。
如果從庫延遲太多，pt-table-sync會長期持有對chunk的for update鎖，然后等待從庫的master_pos_wait執行完畢或超時。從庫延遲越大，等待過程就越長，主庫加鎖的時間就越長，對線上影響就越大。
因此要嚴格設置max-lag。
5. 對從庫數據的修復通常是在主庫執行sql來同步到從庫。
因此，在有多個從庫時，修復某個從庫的數據實際會把修復語句同步到所有從庫。數據修復的代價取決于從庫與主庫不一致的程度，如果某從庫數據與主庫非常不一致。
舉例說，這個從庫只有表結構，那么需要把主庫的所有數據重新灌一遍，然后通過binlog同步，同時會傳遞到所有從庫。這會給線上帶來很大壓力，甚至拖垮集群。
正確的做法是：先用pt-table-checksum校驗一遍，確定不一致的程度：如果不同步的很少，用pt-table-sync直接修復；否則，用備份先替換它，然后用pt-table-sync修復。
說明：
這實際提供了一種對myisam備份的思路：如果僅有一個myisam的主庫，要為其增加從庫，則可以：先mysqldump出表結構到從庫上，然后啟動同步，然后用pt-table-sync來修復數據。



本文作者：王家福

本文來源：IT那活兒（上海新炬王翦團隊）

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129609.html

相關文章

發表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<