2022-09-28 大量删除hive分区导致hivemetas

28号晚一次删除了20万的hive表分区。导致hivemetastore 一直处于canary状态，查看元数据库没有发现死锁，查看CM监控也未发现问题。meta日志中也未问题，系统正常运行。
但是一直处于canary状态心中总觉得有隐患，下午发现建表删表时时长非常长达到了200s,而且每次都是200s，所以查看了元数据库中hive的事务 id 与 Sentry Server 中的最新同步事件 id是否有延迟。

mysql> select * from hive.NOTIFICATION_SEQUENCE order by  next_event_id desc  limit 1;
+--------+---------------+
| NNI_ID | NEXT_EVENT_ID |
+--------+---------------+
|      1 |      11594801 |
+--------+---------------+
1 row in set (0.00 sec)

mysql>   select * from  sentry.SENTRY_HMS_NOTIFICATION_ID order by NOTIFICATION_ID desc limit 1;
+-----------------+
| NOTIFICATION_ID |
+-----------------+
|        11394801 |
+-----------------+



使用如下sql用来展示sentry中存储的表信息

 select * from 
 AUTHZ_PATH t1, 
 AUTHZ_PATHS_MAPPING t2 
 where t1.AUTHZ_OBJ_ID=t2.AUTHZ_OBJ_ID 
 and t2.AUTHZ_OBJ_NAME='sum.t88_quantity_business_taking' 
 limit 100;

如果延迟太多，则hivestrore会出现canary的情况，但是很奇怪应该会打印日志

ERROR org.apache.sentry.core.common.transport.RetryClientInvocationHandler: [pool-5-thread-670]: failed to execute syncNotifications
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.apache.sentry.core.common.transport.RetryClientInvocationHandler.invokeImpl(RetryClientInvocationHandler.java:95)
        at org.apache.sentry.core.common.transport.SentryClientInvocationHandler.invoke(SentryClientInvocationHandler.java:41)
        at com.sun.proxy.$Proxy26.syncNotifications(Unknown Source)

但是我们的系统完全没有发现，只是通过建表删表缓慢发现问题。
处理方案，如果消息积压的太多，sentry 慢慢消费的时间太长的话，可能一直追不上 HMS 的最新 id，此时可以选择丢掉这些信息，具体操作在 sentry 元数据的 SENTRY_HMS_NOTIFICATION_ID 表中插入一条最大值（该最大值等于当前消息的 id 值，从 hive 元数据的 NOTIFICATION_SEQUENCE 表中获取 ），重启 sentry 服务。
引起的副作用就是在后期DDL这些表的时候会出现无权限的问题，