pulsar-6：生产环境解决pulsar-flink-connector导致磁盘满的问题

目录

(1).pulsar生产集群规模

(2).集群磁盘爆炸原因与解决

1.磁盘爆炸原因

2.恢复集群

3.解决方式

(1).pulsar生产集群规模

生产环境集群（为了省钱是一个最小集群）：

在aws上部署了3台8c16g的pulsar集群。选择的是1:2的c系列机型：c5a.2xlarge。

每台节点放3个进程：zk, broker, bookie。

磁盘是400G/node，一共是1.2T，但是副本数是2，所以可以存放600G的消息。

(2).集群磁盘爆炸原因与解决

1.磁盘爆炸原因

在进行全链路压测时出现磁盘爆炸的情况，3个node的磁盘使用率都超过了95%。

经过调查是因为实时计算flink中的pulsar-flink-connect使用的topic的订阅者出现了2、3亿条的消息堆积（一共12个分区，每个分区的backlog都是2、3千万）。

原因：

是pulsar-flink所创建/使用/管理的订阅者（reader）的markDeletePosition和readPosition不相等，value(markDeletePosition) << value(readPosition)，每个都差2、3千万。查看官方issue这里存在这种情况，貌似后续版本会解决。

2.恢复集群

通过设置过期时间1s（单位是秒），让pulsar自动删除过期ledgers。

注意这里我设置1秒是因为业务是内测阶段所以可以，生产这么设你可以跑路了！！！

bin/pulsar-admin namespaces set-message-ttl xxx/public --messageTTL 1

重启每个bookie。

bin/pulsar-daemon stop bookie

bin/pulsar-daemon start bookie

恢复TTL配置：

bin/pulsar-admin namespaces remove-message-ttl xxx/public

再次get是：null

bin/pulsar-admin namespaces get-message-ttl xxx/public

bookie是每隔15分钟做一次清理，所以还是很麻烦，要做好监控/报警。

注意：

pulsar的消息ttl设置只能在namespace这一个级别进行设置。

3.解决方式

四处盘也没有找到优雅的解决方式，最后用一种工程方法去解决：

pulsar-flink-connector用到的topic放到一个单独的namespace，然后对这个space进行ttl设置（1小时），这样来保证它的backlog不会爆炸。一定要和相关业务放进行确认！

创建namespace:

bin/pulsar-admin namespaces create xxx/flink

bin/pulsar-admin namespaces set-message-ttl xxx/flink --messageTTL 3600

然后创建topic即可：

/app/3rd/apache-pulsar-2.8.0/bin/pulsar-admin topics create-partitioned-topic -p 12 persistent://xxx/flink/topic

处理完后也得到了pulsar官方的回复（pulsar官方还是很给力的），并且在相关issue中看到类似问题和解决方式：目前也是这么通过ttl处理。