pt-online-schema-change报错

今天在对一个大表加索引的时候失败了，具体如下：

SELECT /*!40001 SQL_NO_CACHE */ `goods_id` FROM `rosegal_db`.`eload_goods` FORCE INDEX(`PRIMARY`) WHERE ((`goods_id` >= ?)) ORDER BY `goods_id` LIMIT ?, 2 /*next chunk boundary*/

2016-01-05T23:32:28 Dropping triggers...

DROP TRIGGER IF EXISTS `rosegal_db`.`pt_osc_rosegal_db_eload_goods_del`;

DROP TRIGGER IF EXISTS `rosegal_db`.`pt_osc_rosegal_db_eload_goods_upd`;

DROP TRIGGER IF EXISTS `rosegal_db`.`pt_osc_rosegal_db_eload_goods_ins`;

2016-01-05T23:32:28 Dropped triggers OK.

2016-01-05T23:32:28 Dropping new table...

DROP TABLE IF EXISTS `rosegal_db`.`_eload_goods_new`;

2016-01-05T23:32:28 Dropped new table OK.

`rosegal_db`.`eload_goods` was not altered.

2016-01-05T23:32:28 Error copying rows from `rosegal_db`.`eload_goods` to `rosegal_db`.`_eload_goods_new`: Threads_running=52 exceeds its critical threshold 50

从提示上可以看出是Threads_running 超过了警告的阀值，查看官方文档，有两种方式来设置这个参数：

--critical-load

type: Array; default: Threads_running=50

Examine SHOW GLOBAL STATUS after every chunk, 

and abort if the load is too high. The option accepts a comma-separated list of MySQL status variables and thresholds. 

An optional =MAX_VALUE (or :MAX_VALUE) can follow each variable. If not given, 

the tool determines a threshold by examining the current value at startup and doubling it.

See --max-load for further details. These options work similarly, 

except that this option will abort the tool’s operation instead of pausing it,

 and the default value is computed differently if you specify no threshold. 

 The reason for this option is as a safety check in case the triggers on the

 original table add so much load to the server that it causes downtime. 

 There is probably no single value of Threads_running that is wrong for 

 every server, but a default of 50 seems likely to be unacceptably high

 for most servers, indicating that the operation should be canceled immediately.

大致的意思如下：

每次chunk操作前后，会根据show global status统计指定的状态量的变化，默认是统计Thread_running。

目的是为了安全，防止原始表上的触发器引起负载过高。这也是为了防止在线DDL对线上的影响。

超过设置的阀值，就会终止操作，在线DDL就会中断。提示的异常如上报错信息。

--max-load

type: Array; default: Threads_running=25

Examine SHOW GLOBAL STATUS after every chunk, and pause if any status variables are higher than their thresholds. 

The option accepts a comma-separated list of MySQL status variables. An optional =MAX_VALUE (or :MAX_VALUE) can 

follow each variable. If not given, the tool determines a threshold by examining the current value and increasing it by 20%.

For example, if you want the tool to pause when Threads_connected gets too high, you can specify “Threads_connected”,

 and the tool will check the current value when it starts working and add 20% to that value. If the current value is 100, 

 then the tool will pause when Threads_connected exceeds 120, and resume working when it is below 120 again. If you want to

 specify an explicit threshold, such as 110, you can use either “Threads_connected:110” or “Threads_connected=110”.

The purpose of this option is to prevent the tool from adding too much load to the server. If the data-copy queries are 

intrusive, or if they cause lock waits, then other queries on the server will tend to block and queue. This will typically 

cause Threads_running to increase, and the tool can detect that by running SHOW GLOBAL STATUS immediately after each query finishes. 

If you specify a threshold for this variable, then you can instruct the tool to wait until queries are running normally again. This will 

not prevent queueing, however; it will only give the server a chance to recover from the queueing. If you notice queueing, it is best to decrease the chunk time.

--max-load 选项定义一个阀值，在每次chunk操作后，查看show global status状态值是否高于指定的阀值。该参数接受一个mysql status状态变量以及一个阀值，

如果没有给定阀值，则定义一个阀值为为高于当前值的20%。

注意这个参数不会像--critical-load终止操作，而只是暂停操作。当status值低于阀值时，则继续往下操作。

是暂停还是终止操作这是--max-load和--critical-load的差别。

参数值为列表形式，可以指定show global status出现的状态值。比如，Thread_connect 等等。

格式如下：--critical-load="Threads_running=200"  或者--critical-load="Threads_running:200"。

本文转自 emma_cql 51CTO博客，原文链接:http://blog.51cto.com/chenql/1732076