pt-online-schema-change 最佳实践(转)

pt的详细步骤

Step 1: Create the new table.
Step 2: Alter the new, empty table.
        This should be very quick, or die if the user specified a bad alter statement.
Step 3: Create the triggers to capture changes on the original table and apply them to the new table.
Step 4: Copy rows.
Step 5: Rename tables: orig -> old, new -> orig
Step 6: Update foreign key constraints if there are child tables.
Step 7: Drop the old table.
        DROP TABLE IF EXISTS `_xx_old`
        DROP TRIGGER IF EXISTS `pt_osc_xx_xx_del`;
        DROP TRIGGER IF EXISTS `pt_osc_xx_xx_upd`;
        DROP TRIGGER IF EXISTS `pt_osc_xx_xx_ins`;
done


一、常用参数解读

1.0 生产环境使用的参数

inception调用pt-online-schema-change,相关参数如下:

inception_osc_alter_foreign_keys_method = rebuild_constraints
inception_osc_check_alter = on
inception_osc_check_interval = 5
inception_osc_check_replication_filters = OFF
inception_osc_chunk_size = 1000
inception_osc_chunk_size_limit = 4
inception_osc_chunk_time = 1
inception_osc_critical_thread_connected = 4000
inception_osc_critical_thread_running = 300
inception_osc_drop_new_table = on
inception_osc_drop_old_table = on
inception_osc_max_lag = 3
inception_osc_max_thread_connected = 2500
inception_osc_max_thread_running = 200
inception_osc_min_table_size = 16
inception_osc_recursion_method = none

以上inception参数对应的pt-online-schema-change的命令参数如下:

pt-online-schema-change
    --alter " xx "
    --alter-foreign-keys-method=rebuild_constraints
    --check-alter=yes
    --check-interval=5
    --check-replication-filters=no
    --chunk-size=1000
    --chunk-size-limit=4
    --chunk-time=1
    --critical-load=thread_connected:4000,thread_running:300
    --max-load=thread_connected:2500,thread_running:200
    --drop-new-table=yes
    --drop-old-table=yes
    --max-lag=3
    --recursion-method=none

1.1 基本用法

  • pt-online-schema-change [OPTIONS] DSN
  • pt-online-schema-change --alter "ADD COLUMN c1 INT" D=sakila,t=actor
  • pt-online-schema-change --alter "ENGINE=InnoDB" D=sakila,t=actor

1.2 安全的pt-online-schema-change

默认情况下,pt-online-schema-change 是不会修改表的,除非你显示的指定了 --execute
pt-online-schema-change 有一系列动作来阻住一切不期望的后果发生,包括 自动检测复制,以及以下相关措施

  • 大部分情况下,pt-online-schema-change会拒绝给没有主键和唯一键的表做操作,可以参考 --alter 了解更多信息
  • 如果检测到复制过滤(ignore-db,do-db等),pt-online-schema-change会拒绝操作,可以参考 --[no]check-replication-filters 了解更多信息
  • 如果发现复制严重的厉害,那么会暂停copy数据,可以参考 --max-lag 了解更多的信息
  • 如果发现服务器负载非常高,那么也会暂停或者停止相关操作,可以参考 --max-load and --critical-load 了解更多信息
  • 该工具默认会设置 innodb_lock_wait_timeout=1 和 lock_wait_timeout=60来减少竞争 , 参考 --set-vars 了解更多信息
  • 如果有外键约束,那么禁止改表,出发你指定 --alter-foreign-keys-method.
  • Percona XtraDB Cluster中禁止修改MYISAM的表

1.3 常用参数

  • --dry-run and --execute , 这两个是互斥的参数,一个是打印,一个是执行
  • --alter

通过这个选项,就不需要alter table关键字了。 你可以通过逗号来指定多个修改操作。

* 以下列出--alter中的一些限制,大家谨记和避免

1. 原表必须要有主键或唯一键,因为delete触发器需要用到,否则会报错

2. rename子句,不允许给表重命名

2.1 不能通过删除一列,然后再新增一列的方式来完成对列的重命名操作

3. 新增字段,如果这个字段是NOT NULL,必须要指定default值,否则报错。  你必须指定默认值

4. 如果是DROP FOREIGN KEY constraint_name , 那么必须指定 _ 加上 constraint_name , 而不是 constraint_name。
    举例: CONSTRAINT `fk_foo` FOREIGN KEY (`foo_id`) REFERENCES `bar` (`foo_id`)
    你必须指定: --alter "DROP FOREIGN KEY _fk_foo"  而不是  --alter "DROP FOREIGN KEY fk_foo".

5. 必须确保数据库高于5.0版本,因为5.0版本转换MYSIAM到InnoDB会出错
  • [no]check-alter

默认yes, 给--alter 做一些检测

* 列的重命名

在之前的版本 CHANGE COLUMN name new_name 这个操作是会丢失数据的,现在的工具修复了

但是,由于pt代码并不是full-blown SQL parser,所以,你应该先 --dry-run and --print , 确认下renamed的列名是否正确,以确保无误

* 删除主键

删除主键是很危险的事情,尽量不要做这样的动作
  • --alter-foreign-keys-method

我们的规范不允许有外键,如果有外键,我们采取其他方式DDL

如何把外键引用到新表?需要特殊处理带有外键约束的表,以保证它们可以应用到新表.当重命名表的时候,外键关系会带到重命名后的表上。
该工具有两种方法,可以自动找到子表,并修改约束关系。
    auto: 在rebuild_constraints和drop_swap两种处理方式中选择一个。
    rebuild_constraints:使用 ALTER TABLE语句先删除外键约束,然后再添加.如果子表很大的话,会导致长时间的阻塞。
    drop_swap: 执行FOREIGN_KEY_CHECKS=0,禁止外键约束,删除原表,再重命名新表。这种方式很快,也不会产生阻塞,但是有风险:
            1, 在删除原表和重命名新表的短时间内,表是不存在的,程序会返回错误。
            2, 如果重命名表出现错误,也不能回滚了.因为原表已经被删除。
    none: 类似"drop_swap"的处理方式,但是它不删除原表,并且外键关系会随着重命名转到老表上面。
  • --host=xxx --user=xxx --password=xxx
连接实例信息,缩写-h xxx -u xxx -p xxx,密码可以使用参数--ask-pass 手动输入。

  • D=db_name,t=table_name
指定要ddl的数据库名和表名


  • --charset
最好设置为MySQL默认字符集: utf8
  • --check-interval
默认1秒,检测--max-lag
  • --[no]check-replication-filters

默认yes

如果发现任何服务器有 binlog_ignore_db and replicate_do_db , 那么就报错
  • --check-slave-lag
指定一个从库的DSN连接地址,如果从库超过--max-lag参数设置的值,就会暂停操作。
  • --[no]swap-tables
默认yes。交换原始表和新表,除非你禁止--[no]drop-old-table。
  • --max-lag
默认1s。
每个chunk拷贝完成后,会查看所有复制Slave的延迟情况。
要是延迟大于该值,则暂停复制数据,直到所有从的滞后小于这个值,使用Seconds_Behind_Master。
如果有任何从滞后超过此选项的值,则该工具将睡眠--check-interval指定的时间,再检查。
如果从被停止,将会永远等待,直到从开始同步,并且延迟小于该值。
如果指定--check-slave-lag,该工具只检查该服务器的延迟,而不是所有服务器。
  • --max-load
默认为Threads_running=25。
每个chunk拷贝完后,会检查SHOW GLOBAL STATUS的内容,检查指标是否超过了指定的阈值。
如果超过,则先暂停。
这里可以用逗号分隔,指定多个条件,
每个条件格式: status指标=MAX_VALUE 或者 status指标:MAX_VALUE。
如果不指定MAX_VALUE,那么工具会设置其为当前值的120%。


  • --critical-load
默认为Threads_running=50。
用法基本与--max-load类似,如果不指定MAX_VALUE,那么工具会这只其为当前值的200%。
如果超过指定值,则工具直接退出,而不是暂停。
  • --print
打印SQL语句到标准输出。指定此选项可以让你看到该工具所执行的语句,和--dry-run配合最佳。
  • --progress
复制数据的时候打印进度报告,二部分组成:第一部分是百分比,第二部分是时间。
  • --set-vars
设置MySQL变量,多个用逗号分割。
默认该工具设置的是: wait_timeout=10000 innodb_lock_wait_timeout=1 lock_wait_timeout=60
  • --recursion-method

默认是show processlist,发现从的方法,也可以是host,但需要在从上指定report_host,通过show slave hosts来找到,可以指定none来不检查Slave。
METHOD       USES
===========  ==================
processlist  SHOW PROCESSLIST
hosts        SHOW SLAVE HOSTS
dsn=DSN      DSNs from a table
none         Do not find slaves

指定none则表示不在乎从的延迟。

--pause-file

可以指定文件暂停pt-online-schema-change

二、使用限制

  • 哪些ddl是不可以做的,做了容易出错
1. 禁止创建唯一索引,会丢失数据,更加不允许添加 --alter-check=no,--check-unique-key-change=no
2. 如果原表没有主键,或者也没有唯一索引,这些表是不允许用pt做DDL的
3. 禁止对外键的表进行pt ddl
4. 禁止对表进行重命名
5. 禁止对列进行重命名,如果一定要做,也必须先print出来检测清楚列名是否正确
6. 新增字段,NOT NULL必须要指定默认值
7. 不允许删除主键
  • 由于pt触发器原理,rowcopy会产业一堆的binlog,所以做之前要检测binlog空间是否够用,也要检测数据空间多一倍表空间是否够用
  • 禁止在业务高峰期进行pt-online-schema-change操作
  • 原表不能有触发器
  • MySQL最好设置为innodb_autoinc_lock_mode=2,否则在高并发的写入情况下,很容易产生所等待以及死锁
  • master的表结构必须跟slave的表结构一致,不允许异构,否则pt-online-schema-change的原理就是会rename,然后slave不一致的表结构会被master覆盖,谨记

三、关于触发器

  • 3.0.2之前的update触发器
REPLACE INTO `lc`.`_hb_new` (`id`, `ts`, `ts2`, `c1`) VALUES (NEW.`id`, NEW.`ts`, NEW.`ts2`, NEW.`c1`)
  • 3.0.2之后的update触发器
BEGIN
    DELETE IGNORE FROM `lc`.`_hb_new` WHERE !(OLD.`id` <=> NEW.`id`) AND `lc`.`_hb_new`.`id` <=> OLD.`id`;
    REPLACE INTO `lc`.`_hb_new` (`id`, `ts`, `ts2`) VALUES (NEW.`id`, NEW.`ts`, NEW.`ts2`);
END
  • 原理
update触发器
    =SQL转换=> delete ignore + replace into (大于3.0.2版本)
    =SQL转换=> replace into(低于3.0.2版本,所以这个版本会有问题,如果这时候对老的主键修改,那么修改之前的值不会去掉,从而多了一些异常数据)


举例:t表中有三条数据,第一列id是主键

------
1 lc  --row1
2 lc  --row2
3 lc  --row3
------

pt-online-schema-change的原理大致四个阶段:

1. 创建临时表_t_new
2. 创建触发器
3. 老数据row copy
4. swap table


好了,我们来举个例子:

1. 创建临时表_t_new
2. 创建触发器
3. 老数据row copy
    3.1 拷贝数据row1,row2完毕
    3.2 这时候业务有一个update语句, update t set id = 10 where id=1;
    3.3 拷贝数据row3
4. swap table

这时候脑补一下原表和新表的示意图, 这时候已经执行到3.1阶段

老表
------------
1 lc  --row1
2 lc  --row2
3 lc  --row3
------------

新表
-----------
1 lc
2 lc
-----------

这时候脑补一下原表和新表的示意图, 这时候已经执行到3.3阶段

老表(update t set id = 10 where id=1)
------------
10 lc  --row1
2 lc  --row2
3 lc  --row3
------------

新表(3.0.2之前版本的触发器,没有delete映射,所以最终结果如下,跟老表相比已经不一致了,多了一条数据1,lc) , 触发器 replace into _t_new(id,name) values(10,lc)
-----------
1 lc
2 lc
10 lc
3 lc
-----------

新表(3.0.2之后版本的触发器,有delete映射,所以最终结果如下,于老表的数据一致) , 触发器 delete ignore _t_new where id = 1;replace into _t_new(id,name) values(10,lc);
-----------
2 lc
10 lc
3 lc
-----------

四、错误处理

遇到错误后,继续补充完整

posted @ 2019-08-15 10:35  zping  阅读(1086)  评论(0编辑  收藏  举报