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