Warehouse collection ingestion from document" failures.tanzusm namespace with commands like: kubectl get pods -n tanzusm, the chi-clickhouse pods are stuck in CrashLoopBackOff state.kubectl get pods -n tanzusm | egrep -v "Running|Completed"registry/########-####-####-####-############:$ kubectl get pods -n tanzusm | grep -v RunNAME READY STATUS RESTARTS AGEchi-clickhouse-metrics-default-0-0-0 0/1 CrashLoopBackOff 428 (71s ago) 47hchi-clickhouse-metrics-default-2-0-0 0/1 CrashLoopBackOff 392 (3m11s ago) 47hkubectl get pods -A | grep chi-clickhouse-defaultNAMESPACE NAME READY STATUS RESTARTStanzusm chi-clickhouse-metrics-default-0-0-0 1/1 Running 990tanzusm chi-clickhouse-metrics-default-1-0-0 1/1 Running 0tanzusm chi-clickhouse-metrics-default-2-0-0 1/1 Running 976tanzusm chi-clickhouse-metrics-default-3-0-0 1/1 Running 0tanzusm chi-clickhouse-metrics-default-4-0-0 1/1 Running 0tanzusm chi-clickhouse-metrics-default-5-0-0 1/1 Running 0tanzusm chi-clickhouse-metrics-default-6-0-0 1/1 Running 0
Tanzu Hub 10.4.x
This failure occurs when the Metric Store Job Instances in Tanzu Hub tile -> Resource Config section have been scaled from 3 to 7 instances directly (skipping 5). This increase skips the maximum instance count of 5 for the Metric Store job instances and leads to data inconsistency on the Clickhouse storage. Increasing to 7 instances directly is not supported for Metric Store job instances at this time. It is recommended not to go beyond 5 instances, and when increasing, do not increase more than 2 at a time up to a max of 5 instances. For example: 1 instance would need to be increased to 3 instances before being increased to 5 instances. It is preferred to scale the Metric Store VMs vertically before scaling horizontally.
The data inconsistency caused by this unsupported increase in instance replicas requires rebuilding the Clickhouse store.
Use the the following KB for reference to rebuild the Clickhouse store.