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这些表的时候会出现无权限的问题，
网友评论