clickhouse - Not found column _block_number in block - Stack Overflow

admin管理员组

文章数量:1122818

I am using ClickHouse version v24.6.1.4609-stable.

I have a database with only one SRMT table, and a corresponding Buffer table. Partitions are by month.

I have a cron job to delete rows which runs nightly, and just started to fail yesterday.

I was able to isolate a problematic ALTER TABLE statement:

ALTER TABLE event_performances
 DELETE
 WHERE is_deleted = 1 
 AND event_timestamp = '2022-03-03 05:00:00'
 SETTINGS mutations_sync=2, alter_sync=2;

(There are 12 rows in the event_performances table that meet the criteria and should be deleted.)

The error message I get is

Code 341 : UNFINISHED
Mutation 0000000419 failed to finish, error: 'Not found column _block_number in block.
There are only columns: client_id, event_id, event_type,
[... lots of column names redacted],
event_timestamp, version, is_deleted'.

To be clear, the list of column names are the actual visible column names in my table, without any of the ClickHouse columns beginning with underscore.

I get the same error message when I run my query in the web client, and when I run it via PHP.

The similar query with earlier dates returns OK, that the ALTER succeeded.

I am at a loss of where to go from here; I don't understand what the _block_number column is doing here.

When I query for the mutations, I get rows like

0000000774  n*****  event_performances  0000000774  DELETE WHERE (is_deleted = 1) AND (event_timestamp = '2022-03-03 05:00:00') AND (delivery_id = 17869469)    2024-11-21 08:10:40 ["202105","202106","202107","202108","202109","202110","202111","202112","202201","202202","202203","202204","202205","202206","202207","202208","202209","202210","202211","202212","202301","202302","202303","202304","202305","202306","202307","202308","202309","202310","202311","202312","202401","202402","202403","202404","202405","202406","202407","202408","202409","202410","202411"]    ["781","775","778","787","784","788","792","799","809","815","840","839","840","846","874","882","920","960","959","939","969","965","975","989","1057","1077","1083","1153","1171","1207","1262","1338","1369","1461","1475","1569","1569","1653","1758","1940","2309","3204","17696"] ["202203_0_707_10_840"] 1   0   0       1970-01-01 00:00:00 

I understand that there are fields called block_numbers, but I don't know that those are related to _block_number.

Running the query SELECT * FROM "parts_columns" where partition_id = '202203' yields 157 rows, but I don't know enough to read the results intelligently.

How do I fix my issue? How can I get the ALTER TABLE to succeed?

I am using ClickHouse version v24.6.1.4609-stable.

I have a database with only one SRMT table, and a corresponding Buffer table. Partitions are by month.

I have a cron job to delete rows which runs nightly, and just started to fail yesterday.

I was able to isolate a problematic ALTER TABLE statement:

ALTER TABLE event_performances
 DELETE
 WHERE is_deleted = 1 
 AND event_timestamp = '2022-03-03 05:00:00'
 SETTINGS mutations_sync=2, alter_sync=2;

(There are 12 rows in the event_performances table that meet the criteria and should be deleted.)

The error message I get is

Code 341 : UNFINISHED
Mutation 0000000419 failed to finish, error: 'Not found column _block_number in block.
There are only columns: client_id, event_id, event_type,
[... lots of column names redacted],
event_timestamp, version, is_deleted'.

To be clear, the list of column names are the actual visible column names in my table, without any of the ClickHouse columns beginning with underscore.

I get the same error message when I run my query in the web client, and when I run it via PHP.

The similar query with earlier dates returns OK, that the ALTER succeeded.

I am at a loss of where to go from here; I don't understand what the _block_number column is doing here.

When I query for the mutations, I get rows like

0000000774  n*****  event_performances  0000000774  DELETE WHERE (is_deleted = 1) AND (event_timestamp = '2022-03-03 05:00:00') AND (delivery_id = 17869469)    2024-11-21 08:10:40 ["202105","202106","202107","202108","202109","202110","202111","202112","202201","202202","202203","202204","202205","202206","202207","202208","202209","202210","202211","202212","202301","202302","202303","202304","202305","202306","202307","202308","202309","202310","202311","202312","202401","202402","202403","202404","202405","202406","202407","202408","202409","202410","202411"]    ["781","775","778","787","784","788","792","799","809","815","840","839","840","846","874","882","920","960","959","939","969","965","975","989","1057","1077","1083","1153","1171","1207","1262","1338","1369","1461","1475","1569","1569","1653","1758","1940","2309","3204","17696"] ["202203_0_707_10_840"] 1   0   0       1970-01-01 00:00:00 

I understand that there are fields called block_numbers, but I don't know that those are related to _block_number.

Running the query SELECT * FROM "parts_columns" where partition_id = '202203' yields 157 rows, but I don't know enough to read the results intelligently.

How do I fix my issue? How can I get the ALTER TABLE to succeed?

• clickhouse

Share Improve this question Follow edited Nov 21, 2024 at 8:41 jonrsharpe 122k3030 gold badges263263 silver badges470470 bronze badges asked Nov 21, 2024 at 8:39 JXGJXG 7,40388 gold badges3636 silver badges6363 bronze badges 4

• The _block_number column is a virtual column, which is not intended to be touched by users as its generated by system itself. Could you reproduce the error as small as possible in the fiddle here fiddle.clickhouse.com – jsc0218 Commented Nov 21, 2024 at 14:24
• look clickhouse.com/docs/en/operations/settings/… – Slach Commented Nov 22, 2024 at 6:44
• and clickhouse.com/docs/en/engines/table-engines/mergetree-family/… – Slach Commented Nov 22, 2024 at 6:44
• and upgrad to clickhouse-server 24.8 latest lts release – Slach Commented Nov 22, 2024 at 6:46

Add a comment  | 

2 Answers 2

Sorted by: Reset to default 0

You could run something like ALTER TABLE <database>.<table> MODIFY SETTING enable_block_number_column = 0 and that should stop the errors. Is this a local deployment? (don't have enough reputation to comment, otherwise would)

As it turns out, this was an issue within ClickHouse itself.
We reached out to them, and they fixed the issue.

本文标签： clickhouseNot found column blocknumber in blockStack Overflow