为何我订阅指定表的其中一台CTP无法获取对应数据？

按操作侵入性从低到高排序，优先执行无业务影响的检查：

• 先核对两台CTP的订阅参数是否完全一致，重点检查subscribe函数的表名参数是否大小写匹配、是否有多余空格，过滤条件filter参数是否异常。如果是代码里硬编码的表名，直接打印两台CTP的订阅参数做diff对比即可，不需要重启服务。
• 检查TP侧该表的发布权限配置，确认是否给异常CTP的登录用户开放了该表的订阅权限。可以在TP侧执行getPublisherTablePerm查看对应表的权限列表，对比两台CTP的登录账号权限差异。
• 检查TP侧的订阅记录，执行getSubscriptions查看异常CTP的订阅是否真的注册到了该表的监听队列里，对比正常CTP和异常CTP的订阅记录差异。如果订阅记录里没有该表，说明订阅请求虽然链路通了，但实际未注册成功，需要重试订阅。
• 查看TP侧该表的发布队列积压情况，执行.px.getPublishQueueStat查看对应表的发布队列，如果异常CTP的队列积压满被丢弃，默认配置下不会打错误日志，只会静默丢弃消息。如果是队列满导致的，可以临时调大该CTP的订阅队列长度验证。
• 检查异常CTP和TP之间的网络是否存在特殊规则，比如防火墙、ACL规则是否拦截了该表的特定数据包端口，或者是否存在网络分片丢包的情况，优先排除网络层的定向拦截问题。
• 如果以上都正常，可以在不影响生产的前提下，临时在TP侧给该表加一个打印日志的触发器，仅打印接收到的写入请求和推送给订阅端的记录，确认是否真的推送给了异常CTP，验证完立刻删除触发器即可。
• 最后可以找业务低峰期，断开异常CTP的订阅重新发起订阅，验证是否是偶发的订阅注册异常导致的问题。

内容的提问来源于stack exchange，提问作者user06931912