Closed d-kononov closed 6 months ago
I am having the same issue, just deployed fresh and latest sentry chart 20.7.0 and getting this.
I just received the same error on one of my installations. I'll look for the cause of the error and create an issue in the sentry/snuba repository
we have the same issue, this is stopping us from upgrading the sentry version from chart 20.5.5 version 20.8.1
the logs on sentry-snuba-metric-consumer are shown below
snuba.clickhouse.errors.ClickhouseWriterError: Method write is not supported by storage Distributed with more than one shard and no sharding key provided (version 21.8.13.6 (official build))
Sentry team confirmed that this is a bug. See https://github.com/getsentry/snuba/issues/4897
Hi,
A comment on getsentry/snuba
suggests that there might be a workaround to resolve this issue: https://github.com/getsentry/snuba/issues/4931#issuecomment-1785674614
Could someone have a look at this and see if there's anything that could be done while we wait for the migration to be fixed?
Thanks!
I suspect anyone/everyone who deploys 23.10.0 with sentry-kubernetes will run in to this and it would be great to know how to deal with this rather than to just leave it this way:
sentry-snuba-metrics-consumer-6cbbdbfcc7-5ds5b 0/1 ContainerStatusUnknown 641 (2d3h ago) 4d11h 172.27.156.14 ip-172-27-157-204.ec2.internal <none> <none>
sentry-snuba-metrics-consumer-6cbbdbfcc7-8fvs2 0/1 ContainerStatusUnknown 256 (29h ago) 2d3h 172.27.143.83 ip-172-27-156-165.ec2.internal <none> <none>
sentry-snuba-metrics-consumer-6cbbdbfcc7-l8mt2 0/1 CrashLoopBackOff 341 (5m1s ago) 29h 172.27.140.156 ip-172-27-149-66.ec2.internal <none> <none>
According to (now closed) issue comment https://github.com/getsentry/snuba/issues/4897#issuecomment-1799801423 we need to manually convert the metrics_raw clickhouse distributed table from v2 to v3. I'm not very familiar with clickhouse but will give it a shot here in the near future.
Does anybody know the commands to convert the metrics_raw clickhouse table? I'm also not familiar with clickhouse and honestly, i do not even know where to start. Thanks!
Does anybody know the commands to convert the metrics_raw clickhouse table? I'm also not familiar with clickhouse and honestly, i do not even know where to start. Thanks!
Same for us, some advice would be greatly appreciated.
This is what I did on my cluster. The usual caveats apply:
clickhouse-client
create or replace table metrics_raw_v2_dist as metrics_raw_v2_local ENGINE = Distributed('my-cluster-name', default, metrics_raw_v2_local, timeseries_id)
Thank you @jon-walton , that seams to work!
That didn't work for my installation:
sentry-clickhouse :) create or replace table metrics_raw_v2_dist as metrics_raw_v2_local ENGINE = Distributed('my-cluster-name', default, metrics_raw_v2_local, timeseries_id)
CREATE OR REPLACE TABLE metrics_raw_v2_dist AS metrics_raw_v2_local
ENGINE = Distributed('my-cluster-name', default, metrics_raw_v2_local, timeseries_id)
Query id: 713ed0e0-05ec-4631-864f-964a3ced90bf
0 rows in set. Elapsed: 0.008 sec.
Received exception from server (version 21.8.13):
Code: 80. DB::Exception: Received from 127.0.0.1:9000. DB::Exception: CREATE OR REPLACE TABLE query is supported only for Atomic databases.
That didn't work for my installation:
sentry-clickhouse :) create or replace table metrics_raw_v2_dist as metrics_raw_v2_local ENGINE = Distributed('my-cluster-name', default, metrics_raw_v2_local, timeseries_id) CREATE OR REPLACE TABLE metrics_raw_v2_dist AS metrics_raw_v2_local ENGINE = Distributed('my-cluster-name', default, metrics_raw_v2_local, timeseries_id) Query id: 713ed0e0-05ec-4631-864f-964a3ced90bf 0 rows in set. Elapsed: 0.008 sec. Received exception from server (version 21.8.13): Code: 80. DB::Exception: Received from 127.0.0.1:9000. DB::Exception: CREATE OR REPLACE TABLE query is supported only for Atomic databases.
i think you need to replace "my-cluster-name" with your cluster name. You will find the cluster name in the sentry-clickhouse-config configmap under "
@brogger71 here is this section, it's quite default:
<remote_servers>
<sentry-clickhouse>
<shard>
<replica>
<internal_replication>true</internal_replication>
<host>sentry-clickhouse-0.sentry-clickhouse-headless.sentry.svc.cluster.local</host>
<port>9000</port>
<user>default</user>
<compression>true</compression>
</replica>
</shard>
<shard>
<replica>
<internal_replication>true</internal_replication>
<host>sentry-clickhouse-1.sentry-clickhouse-headless.sentry.svc.cluster.local</host>
<port>9000</port>
<user>default</user>
<compression>true</compression>
</replica>
</shard>
<shard>
<replica>
<internal_replication>true</internal_replication>
<host>sentry-clickhouse-2.sentry-clickhouse-headless.sentry.svc.cluster.local</host>
<port>9000</port>
<user>default</user>
<compression>true</compression>
</replica>
</shard>
</sentry-clickhouse>
</remote_servers>
But changing cluster name in query didn't have any effect:
sentry-clickhouse :) create or replace table metrics_raw_v2_dist as metrics_raw_v2_local ENGINE = Distributed('sentry-clickhouse', default, metrics_raw_v2_local, timeseries_id)
CREATE OR REPLACE TABLE metrics_raw_v2_dist AS metrics_raw_v2_local
ENGINE = Distributed('sentry-clickhouse', default, metrics_raw_v2_local, timeseries_id)
Query id: 3085aa1e-905e-4f81-9dec-e186c0b4a610
0 rows in set. Elapsed: 0.003 sec.
Received exception from server (version 21.8.13):
Code: 80. DB::Exception: Received from 127.0.0.1:9000. DB::Exception: CREATE OR REPLACE TABLE query is supported only for Atomic databases.
@z0rc i have a default installation here as well. I used exactly the same create statement. How did you connect to clickhouse?
clickhouse-client --host sentry-clickhouse-0.sentry-clickhouse-headless.errortracking.svc.cluster.local --port 9000 --user default
How did you connect to clickhouse?
Shell into sentry-clickhouse-0 pod and run clickhouse-client -h 127.0.0.1
. I didn't want to bother with installing anything else additionally.
How did you connect to clickhouse?
Shell into sentry-clickhouse-0 pod and run
clickhouse-client -h 127.0.0.1
. I didn't want to bother with installing anything else additionally.
try using with "-u default". Maybe you're connected with the wrong user.
try using with "-u default". Maybe you're connected with the wrong user.
Nope, same error. I don't think it's related to how clickhouse accessed, but data in it.
I have this:
sentry-clickhouse :) SELECT * FROM system.databases;
SELECT *
FROM system.databases
Query id: 19e60ded-3c09-49a6-9640-0e637245555f
ββnameβββββ¬βengineββββ¬βdata_pathββββββββββββββββββββββββββ¬βmetadata_pathββββββββββββββββββββββββββββββββββββββββββββββββββββββββ¬βuuidββββββββββββββββββββββββββββββββββ
β default β Ordinary β /var/lib/clickhouse/data/default/ β /var/lib/clickhouse/metadata/default/ β 00000000-0000-0000-0000-000000000000 β
β system β Atomic β /var/lib/clickhouse/store/ β /var/lib/clickhouse/store/b5f/b5f009a7-31fc-4c2e-9b53-04a097fe6559/ β b5f009a7-31fc-4c2e-9b53-04a097fe6559 β
βββββββββββ΄βββββββββββ΄ββββββββββββββββββββββββββββββββββββ΄ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ΄βββββββββββββββββββββββββββββββββββββββ
This is quite old installation, maybe something changed for new installations over the course of last couple years. My db just kept running as is.
I had to connect using the actual pod/container IP address, eg.
# clickhouse-client -h 192.168.x.x
Apparently it wasn't binding to loopback, only the actual listening interface...
I tried the way described, changed the name of the cluster, but at the end ended up with an error:
CREATE OR REPLACE TABLE metrics_raw_v2_dist AS metrics_raw_v2_local ENGINE = Distributed('sentry-clickhouse', default, metrics_raw_v2_local, timeseries_id);
Syntax error: failed at position 19 ('TABLE'):
CREATE OR REPLACE TABLE metrics_raw_v2_dist AS metrics_raw_v2_local ENGINE = Distributed('sentry-clickhouse', default, metrics_raw_v2_local, timeseries_id);
Expected VIEW
Anyone an idea why replace table does not work?
Thanks all for assistance with this (am running into the same issue). Unfortunately our Clickhouse DB is ancient enough that it's running as an Ordinary, rather than Atomic, DB type - and converting it seems impossible on a Kubernetes setup (ClickHouse have made it very straightforward by setting a flag, but when I try and restart the DB server in Clickhouse to apply it, it kills the pod instead, no matter how much resource I throw at it).
Does anyone have any wisdom about how you'd run
create or replace table metrics_raw_v2_dist as metrics_raw_v2_local ENGINE = Distributed('my-cluster-name', default, metrics_raw_v2_local, timeseries_id)
.... 'long-form' for database engines that don't support 'create or replace' as a syntax?
Thanks!
@MikeW1901 Interesting, I also tried it to migrate from Ordinary to Atomic by adding a file called convert_ordinary_to_atomic
to the flags
directory as described here https://kb.altinity.com/engines/altinity-kb-atomic-database-engine/how-to-convert-ordinary-to-atomic/#new-official-way
However, it does not even do anything, probably because our Clickhouse version (ClickHouse 21.8.13.6) is too old, but it is still the helm chart default.
Do you use a higher Clickhouse version?
This is what I did on my cluster. The usual caveats apply:
- I've never used clickhouse, this was the result of a couple of hours in the documentation
- I don't know what I'm doing and you don't know me π
- I didn't care about availability or data loss during this procedure (it's a new-ish cluster)
- Scale the snuba-metrics-consumer deployment to 0
- For each clickhouse instance
clickhouse-client create or replace table metrics_raw_v2_dist as metrics_raw_v2_local ENGINE = Distributed('my-cluster-name', default, metrics_raw_v2_local, timeseries_id)
- Scale snuba-metrics-consumer deployment back up
Thank you @jon-walton, that worked for me! ππΌ
worked for me, too.
to find out the name of you cluster run
SELECT * FROM system.clusters LIMIT 2 FORMAT Vertical;
@MikeW1901 Interesting, I also tried it to migrate from Ordinary to Atomic by adding a file called
convert_ordinary_to_atomic
to theflags
directory as described here https://kb.altinity.com/engines/altinity-kb-atomic-database-engine/how-to-convert-ordinary-to-atomic/#new-official-way However, it does not even do anything, probably because our Clickhouse version (ClickHouse 21.8.13.6) is too old, but it is still the helm chart default.Do you use a higher Clickhouse version?
I do - the problem I'm having is that restarting Clickhouse Server kills the pod, and thus a new pod starts without the flag.
Snuba is being tested on clickhouse 22.8, but it is still not an officially supported version. You may try to update the version at your own risk. Or you can use clickhouse-copier to copy data to temp db, recreate default db as atomic and copy data back using clickhouse-copier
I also have an environment where this consumer scales to zero and I don't see any usability issues with Sentry. So this may also be a temporary solution until the migrations are fixed and/or the officially supported version of clickhouse is updated
This issue is stale because it has been open for 30 days with no activity.
Not stale. (I hate this bot)
I'm running into this problem as well, pretty annoying that its a blocker for upgrades.
I will say this is not really a blocker for upgrades. Once upgraded just follow the steps https://github.com/sentry-kubernetes/charts/issues/1042#issuecomment-1814347637 and you should be good to go. Just feels like a poorly managed database migration to me.
This issue is related to this: https://github.com/getsentry/snuba/issues/4897
This issue is stale because it has been open for 30 days with no activity.
For people like me with Clickhouse using Ordinary engine. Follow https://github.com/getsentry/snuba/issues/4897#issuecomment-1909077805 to delete and recreate table.
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.
Hey guys,
We have the latest chart version and snuba-metrics-consumer stuck in
CrashLoopBackOff
state because of:Spec:
Not sure how to fix it.
Any help appreciated!