pt-online-schema-change
# 只从普通单表角度分析，原表没有触发器、修改列不是外键列等复杂因素。
设置session变量: innodb_lock_wait_timeout=1,lock_wait_timeout=60,wait_timeout=10000
检查当前运行状态Threads_running?(原因？高并发怕负载大)
创建新表new_tb，与原表结构相同，(可优化:删除所有非唯一索引，拷贝完数据后再创建)
在old_tb创建触发器(AFTER INSERT/UPDATE/DELETE),其中INSERT/UPDATE 都使用新行数据在new_tb上执行replace into
在new_tb执行ddl
拷贝原表old_tb数据到new_tb，使用INSERT LOW_PRIORITY IGNORE INTO ，没有replace，防止新更新的数据被老数据替换
++ 加全局读锁flush table with read lock;防止改名、删除触发器过程中新DML由于new_tb上触发器引起的问题(短时间找不到new_tb表名)
new_tb表改名为old_tb
删除old_tb上的触发器

pt-table-checksum

工作原理：在主上执行检查语句在线检查mysql复制的一致性
[主]
1、根据where条件生成replace语句:this_src、this_cnt、master_src,、master_cnt
2、UPDATE MASTER INFO：根据this_src、this_cnt的值更新master_src、master_cnt。
这样SLAVE的this_src、this_cnt值都是本机的，但master_src、master_cnt的值都是master生成的(第二步的作用)
[从]
检测this_src和master_src的值从而判断是否一致。

注意：
如果表数据量较大，会根据主键拆为多批次校验，每次(1800行)
使用的时候选择业务地峰的时候运行，因为运行的时候会造成表的部分记录(读锁定，但锁定时间很短)锁定。使用--max-load来指定最大的负载情况，如果达到那个负载这个暂停运行。

src值计算公式见红色部分。有何漏洞？

点击(此处)折叠或打开

# 生成cnt，crc

REPLACE INTO`pt-tool`.`checksumss`(db,tbl,chunk,chunk_index,lower_boundary,upper_boundary,this_cnt,this_crc)

SELECT 'test', 't1', '1','PRIMARY','420001','420311',COUNT(*)AScnt

,COALESCE(LOWER(CONV(BIT_XOR(CAST(CRC32(CONCAT_WS('#',`id`,`age`))AS UNSIGNED)),10,16)),0) AS crc

FROM`test`.`t1`FORCE INDEX(`PRIMARY`)

WHERE ((`id`>='xxx'))AND((`id`<='xxx'));

# 查询this的cnt、crc

SELECT this_crc,this_cnt FROM `pt-tool`.`checksumss`

WHERE db='test' AND tbl='t1' AND chunk='N';

# 更新master的cnt、crc

UPDATE `pt-tool`.`checksumss` SET chunk_time='0.047304',master_crc='0',master_cnt=this_cnt

WHERE db='test' AND tbl='t1' AND chunk='N';

pt-table-sync

根据checksum比较原理，找出不同行，然后replace

xtrabackup/innobackupex

        利用innodb的崩溃恢复原理，备份前记录当前redo 位置，拷贝数据文件，同时记录拷贝期间产生的所有redo
        恢复:将拷贝期间产生的redo在数据文件上依次顺序执行，然后就是最终数据(备份完成时间点的数据)

      innodb可以实现增备，但myisam不能实现增备，每次都是全备
      默认使用innobackupex(可以输出binlog pos信息，搭建slave)，xtrabackup只能备份innodb引擎表

参考
http://blog.chinaunix.net/uid-20639775-id-3229211.html

pt工具实现