1.前情提要
又是一天正常加班到凌晨的工作日，心血来潮改了一下clickhouse的配置文件（改了什么不重要），然后重启（这就很致命了），发现一切如昨，瞬间不慌，简单清理一下散落在座位周边零星的头发，骑上心爱的小电动想着早点回家峡谷逛逛，顺便早睡，毕竟明天依然要8.30上班。
一划两三天过去了。。。。。。。
有些事情虽迟但到，下面直奔主题
2.问题现象
某张表（这里称其为小T）最近突然没有数据写入
小T简介：
1.一张存储轨迹数据的表
2.数据是通过物化视图实时消费kafka引擎表同步的
3.被很多统计类的物化视图引用
3.解决思路
1.kafka问题检查
1.通过查看消费组情况，发现有最新的kafka数据
kafka-consumer-groups.sh --bootstrap-server ip:port --group groupname --describe --command-config consumer.properties
2.手动消费topic，发现可以正常消费
暂时认为kafka没有问题
2.clickhouse检查
历史问题关联分析：以前遇到过新建的kafka引擎表，因为 kafka_max_block_size太大导致无法消费，修改小一点才可以同步
1.修改kafka_max_block_size=5000，重建kafka引擎表
发现还是不行，尝试修改了几个不同数量
2.手动消费kafka引擎表
发现可以消费到最新数据，此时怀疑是物化视图同步出现的问题
3.重建物化视图
发现还是不行，一筹莫展，后来想要不直接往小T里面插一条数据试试
4.直接往小T插入一条测试数据
问题他来了，居然报错了，报物化视图不存在
mv_szi_zm_car_year物化视图：一个基于小T实现年统计，语句会查询小T
SQL 错误 [60]: ClickHouse exception, code: 60, host: xx.xx.xx.xx, port: xxxx; Code: 60, e.displayText() = DB::Exception: Table idap_zl.mv_szi_zm_car_year(287c82ce-b7f7-4950-8297-d25947f6ee06) doesn't exist. (version 20.10.3.30 (official build))
然后检查一下数据库，发现有这个视图，但是他们的UUID居然不一样
select uuid from system.tables t where name = 'mv_szi_zm_car_year';
mv_szi_zm_car_year当前的UUID
0873252a-9891-4dc2-8fba-016bd80cee10
mv_szi_zm_car_year报错的UUID
287c82ce-b7f7-4950-8297-d25947f6ee06
5.怀疑是重启clickhouse的时候导致元数据没有同步
/home/clickhouse/data/metadata/idap_zl/
/home/clickhouse/data/store/d11/d11a2226-3977-4362-b1b1-997a01fe3417/
/home/clickhouse/data/metadata_dropped
检查了这个几个路径，发现都有没有报不存在的UUID
后来在zk的日志文件中找了蛛丝马迹，发现有个这个物化视图的创建日志，且语句里指定了UUID（这里第一次知道，clickhouse建表，视图的时候可以手动指定UUID）
6.重建mv_szi_zm_car_year，并指定UUID
CREATE MATERIALIZED VIEW mv_szi_zm_car_year UUID '287c82ce-b7f7-4950-8297-d25947f6ee06'
。。。。。。。。。。。。。
大概有十几个物化视图引用了小T，根据报错信息，全部重建后，小T终于注入了新鲜数据，重获新生
后记
应该还是重启clickhouse导致元数据出了问题，重建修改UUID依然治标不治本，后面会继续研究如何根治，解决后会及时同步更新到文档中
2021.3.30
问题又一次出现，好烦。。。。。。。。。。
