问题现象

客户建立MergeTree引擎的表，然后执行ALTER TABLE xxx MODIFY yyy，接着看到客户端一直卡住不动。

日志有如下打印：

Current max source part size for mutation is 46814673454 but part size 112917848106. Will not mutate part 202109_1970568_2268982_19. Max size depends not only on available space, but also on settings 'number_of_free_entries_in_pool_to_execute_mutation' and 'background_pool_size'

问题分析

ALTER TABLE流程

首先，了解下ALTER TABLE的整个流程，见分析：https://bbs.huaweicloud.com/blogs/313733

非复制表的流程比较简单，clickhouse会等待某个alter table操作结。在等待的过程中主要有两个条件：

1、mutation_wait_event事件的触发

waitForMutation会一直等待，直到被通知，再判断是否满足解除等待条件。而通知事件是在这里触发的：mutateSelectedPart --> updateMutationEntriesErrors。而进入mutateSelectedPart的条件是有需要被mutate的part。

2、mutation_wait_event事件的触发后解除阻塞的条件

三个条件满足一条就可以（见waitForMutation）

!mutation_status || mutation_status->is_done || !mutation_status->latest_fail_reason.empty()

正常情况下，第一个和第三个条件都是false的，主要看第二个条件，表示该mutation是否已经完成。

根因分析

看下日志的报错，可见，有些part没有被选上，那么对于mutation_status->is_done这个条件就无法满足，因为只有所有的part都做了订正操作后，它才会被置为true（见getIncompleteMutationsStatus）。

那么，为什么会有part没有被选上呢？

报错中也说了，磁盘空间不够了。但是，其实在clickhouse中这个磁盘空间是有自己的一套计算方式的（getMaxSourcePartSizeForMutation），跟实际的磁盘空间和设置有关系。

其实，通过分析getMaxSourcePartSizeForMutation这个函数，可以发现，如果业务量很大的情况下，可能会导致计算结果为0或者很小。

后遗症

1、相同表的数据不一致

你卡住了，那你得想办法把他停止吧，一停止的话，就表明有些part是没有修改成功的，这就导致表的数据不一致了。

2、可能影响到数据的合并

同一个分区内的part，有些有mutation，有些没有，在merge时，可能无法满足merge条件，而导致无法合并。

比如：current_mutations_by_version包含的mutation有100,200,211,212。而part有202109_10_205_10和202109_206_210_10_212(其中就是因为alter失败导致没有mutation number)。这两个part就无法正常合并。

3、如果数据都无法正常合并了，那TTL自然就无法生效了

总结

ALTER TABLE的操作千万不要在业务量大的情况下搞啊。
真的操作了就祈祷不要失败吧