利用percona-toolkit工具检查MySQL数据库主从复制数据的一致性，以及修复。
一、 pt-table-checksum检查主从库数据的一致性
pt-table-checksum在MASTER上校验指定库、表，将结果存在一个库表里，复制进程将检验sql传递到slave上再执行一次。通过比较M/S的检验值确定数据是否一致。利用主从复制做检验，不需要在检验期间对主从数据库同时锁表，可以控制校验的数据和速度，不影响到正常服务。
安装：
yum –y perl-DBI perl-DBD-MySQL perl-TermReadKey
#percona-toolkit包
wget http://www.percona.com/downloads/percona-toolkit/LATEST/percona-toolkit-2.2.4.tar.gz
tar xzvf percona-toolkit-2.2.4.tar.gz ; cd percona-toolkit-2.2.4 ; perl Makefile.pl && make && make install
使用方法：
pt-table-checksum [OPTIONS] [DSN]
pt-table-checksum：在主<M>上通过执行校验的查询对复制的一致性进行检查，对比主从的校验值，从而产生结果。DSN指向的是主的地址，该工具的退出状态不为零，如果发现有任何差别，或者如果出现任何警告或错误，更多信息请见官网。
不指定任何参数，会直接对本地的所有数据库的表进行检查。
环境：
mysql> select * from t1;
+----+------+
| id | name |
+----+------+
| 1 | aa |
| 2 | bb |
| 3 | cc |
| 4 | dd |
| 5 | ee |
+----+------+
5 rows in set (0.00 sec)
#从库：
mysql> select * from t1;
+----+------+
| id | name |
+----+------+
| 1 | aa |
| 2 | bb |
| 3 | cc |
| 4 | dd |
+----+------+
4 rows in set (0.00 sec)
注意：
1、 根据测试，需要一个技能登录主库，也能登录从库，而且还能同步数据库的账号；
2、 只能指定一个host，必须为主库的IP；
3、 在检查时会向表加S锁；
4、 运行之前需要从库的同步IO和SQL进程是YES状态。
可以用该语句授权用户，这里为了方便直接用root用户了
执行检测（MASTER上）：
TS ERRORS DIFFS ROWS CHUNKS SKIPPED TIME TABLE
09-18T12:03:16 0 1 5 1 0 0.018 test.t1
参数说明：
TS ：完成检查的时间。
ERRORS ：检查时候发生错误和警告的数量。
DIFFS ：0表示一致，1表示不一致。当指定--no-replicate-check时，会一直为0，当指定--replicate-check-only会显示不同的信息。
ROWS ：表的行数。
CHUNKS ：被划分到表中的块的数目。
SKIPPED ：由于错误或警告或过大，则跳过块的数目。
TIME ：执行的时间。
TABLE ：被检查的表名。
参数意义：
--nocheck-replication-filters ：不检查复制过滤器，建议启用。后面可以用--databases来指定需要检查的数据库。
--no-check-binlog-format : 不检查复制的binlog模式，要是binlog模式是ROW，则会报错。
--replicate-check-only :只显示不同步的信息。
--replicate= ：把checksum的信息写入到指定表中，建议直接写到被检查的数据库当中。
--databases= ：指定需要被检查的数据库，多个则用逗号隔开。
--tables= ：指定需要被检查的表，多个用逗号隔开
h=127.0.0.1 ：Master的地址
u=root ：用户名
p=123456 ：密码
P=3306 ：端口
更多的参数请见官网，上面指出来的是常用的，对该场景够用的参数。
通过DIFFS是1可以看出主从的表数据不一致。通过查看从库上的test.checksum表可以看到主从库的检验信息。
*************************** 1. row ***************************
db: test
tbl: t1
chunk: 1
chunk_time: 0.001604
chunk_index: NULL
lower_boundary: NULL
upper_boundary: NULL
this_crc: 13fa7d9d #从的校验值
this_cnt: 4 #从的行数
master_crc: aa7a56c3 #主的校验值
master_cnt: 5 #主的行数
ts: 2013-09-18 12:03:16
1 row in set (0.00 sec)
通过上面的 this_crc <> master_crc 更能清楚的看出他们的不一致了，通过chunk知道是这个张表的哪个块上的记录出现不一致。要是主的binlog模式是Row 则会报错：
Replica db2 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.
从错误信息得出，要是不改binlog模式的话，则在执行上面的命令时候要指定：--no-check-binlog-format，即：
指定--replicate-check-only参数会在前一次pt-table-checksum检验的数据之上比较（不会再执行计算），显示出数据不一致的SLAVE主机名：
[root@host125 ~]# pt-table-checksum --nocheck-replication-filters --replicate=test.checksum --databases=test h=192.168.68.235,u=root,p=123 --empty-replicate-table --create-replicate-table --replicate-check-only
Differences on host122
TABLE CHUNK CNT_DIFF CRC_DIFF CHUNK_INDEX LOWER_BOUNDARY UPPER
localStorage的写入和读取，不能跨子域，否则在一些移动端浏览器上，会出现读取不到的情况。
最近开发一个移动端的播放记录功能，在pc端和android版的chrome测试很顺利通过了，但后来进行多平台测试的时候，悲剧发生了。。
掉进localStorage的坑里
android版本UC、iphone及ipad mini版的safari，localStorage跨页面读取不到数据，必须要重启浏览器后才能够正常的读取到数据。
爬出localStorage的坑
首先怀疑的可能是localStorage的访问方式的问题，写入的方式是属性设置localStorage.history而读取是api的方式localStorage.getItem，demo后确认localStorage的三种访问方式都是没有问题的。
思维短路了，开始思考如何规避这个跨页面无法读取的问题，首先想到的是尝试下sessionStorage，浏览器运行期间将数据保存在“session”中，后来发现有着同样的问题。
继续思考能够跨页面保存“大数据”的方式，“灵光”闪现，window.name应该是可以跨页面保存的，试了下各种设备确认这种方案确实可行，但是风险是任何页面都有可能重写掉这个name，甚至会有安全问题。
用极简的demo测试，发现这些有问题的浏览器对localStorage的支持是没问题的。在几乎要放弃的时候，同事跑过来说，将某个文件提前到head里，可以正常的读取数据，这是才意识到播放器的前置代码里没有显示的设置document.domain，导致读取和设置localStorage在不同的domain下面发生的。
在写入localStorage的页面方法之前没有显示的设置document.domain,默认的值为 labs.wxnet.me,但是在读取的页面，读取数据之前显示的设置了document.domain为根域wxnet.me
将问题环境抽象为demo
写入数据的页面 http://labs.wxnet.me/labs/writelocalstorage.html
//document.domain默认值为子域 labs.wxnet.me
localStorage['k'] = '{"a":"1"}';
document.domain = "wxnet.me";
读取数据的页面 http://labs.wxnet.me/labs/readlocalstorage.html
document.domain = "wxnet.me";
alert(localStorage['k']);
解决方案
读取和设置localStorage的页面必须要统一document.domain，要么全部不显示设置或统一设置为根域。
设置页面:
document.domain = "wxnet.me";
localStorage['k'] = '{"a":"1"}';
读取页面:
document.domain = "wxnet.me";
alert(localStorage['k']);
思考
不同的移动版浏览器在处理子域方式不同，iphone、ipad mini子域下写入，主域下是无法读取的，重启浏览器后忽略掉这个安全策略，可以读到数据。但是ipad、pc版的浏览器没有发现这个问题。
本文链接：http://www.cnblogs.com/wangxiang/p/3332797.html，转载请注明。
没有评论:
发表评论