不支持,同一个通道最多只能有一个 SDK 连接并消费数据,如果用户有多个下游需要订阅同一个库表,可以通过建立多个通道来解决。
支持,一个 SDK 可以同时消费多个通道。
一个通道只能有一个 SDK 连接消费,如果新增连接,就会报这个错误。这时需确认程序是否完全退出,若确认完之后重连还是报同样的错误,可以将重启时间的间隔稍微加长一点,例如:20秒。
数据订阅可以订阅的增量数据包括:所有的增删改( DML )以及结构变更( DDL )。
可以,如果数据订阅只订阅数据变更,那么两边索引不同不会影响。如果订阅了结构变更,而且 TencentDB 实例上涉及到索引变更的话,可能会由于两边索引不同,导致结构变更在本地消费失败。
修改位点报错时,界面上有相应的提示。一般是由于订阅通道还有下游在消费,可以先到 DTS 控制台查看消费来源 IP,查看是否还有下游 SDK 在消费数据,如果有,那么需要先停止下游消费后,重新修改消费位点。
在有数据写入的情况( 或者还有数据没有消费完 ),如果数据正常消费,那么控制台上的消费位点就会正常迁移。
当 SDK 有 message 没有 ACK 时,SDK 会持续拉取消息直到 SDK 内的缓存塞满,SDK 不再获取新消息。此时,服务端保存的消费位点为未 ACK 之前的最后一条 message 的位点。
当SDK重启时,为了保证消息不丢,服务端会从未 ACK 前一条 message 对应的位点开始重新推送数据,所以 SDK 此时会重复收取一部分消息。
数据订阅通道中保留数据的时间范围为1天,从[当前时间-1天,当天时间],订阅通道会删除过期数据。所以如果上次 SDK 退出时最后一条消费数据的时间点对应的数据,不在当前订阅通道有效数据范围内,那么就不能订阅到这个消费位点对应的数据。为修复这个问题,在启动 SDK 之前,需要先修改消费位点,确保消费位点在有效数据范围内。
这种情况,比较大可能是 SDK 代码中没有调用 ackAsConsumed 接口汇报消费位点导致的。由于 SDK 内部设置了有限缓存空间,如果不调用 ackAsConsumed 汇报位点,那么这缓存空间数据就不会删除,当缓存满时,就不能拉取新的数据,就会出现 SDK 卡住不能订阅数据现象。
注意:
这里所有的消息,包括 BEGIN 和 COMMIT 消息都必须确认消费,当然也包括业务逻辑可能不关心的消息。
不会,根据用户指定的消费位点或者上次确认消费的位点,服务端会搜索这个消费位点对应的完整事务的起始位置,从整个事务头部的开始,向下游 SDK 传输数据,所以可以保证接收到完整的事务内容。
不会有问题,TencentDB 实例发生主备切换/重启时,数据订阅会自动切换,这个过程对 SDK 来说是透明的。
需要确认输入的参数是否匹配,ip、 port、 secretId、 secretKey、 channelId 是否匹配。
子账号默认没有任何权限,需要根账号给子账号赋予 name/dts:AuthenticateSubscribeSDK 操作的权限,或者赋予 DTS 所有操作的权限 QcloudDTSFullAccess。
说明:
QcloudDTSFullAccess 策略需要您自己创建,目前访问服务还没有预生成 QcloudDTSFullAccess。
{
"version": "2.0",
"statement": [
{
"action": [
"dts:AuthenticateSubscribeSDK"
],
"resource": "*",
"effect": "allow"
}
]
}
{
"version": "2.0",
"statement": [
{
"action": [
"dts:AuthenticateSubscribeSDK"
],
"resource": "qcs::dts:::channel/{channelId}",
"effect": "allow"
}
]
}
在正常消费情况下,不会。如果 SDK 非正常退出,最后确认的位点信息没有及时上报,下次启动可能会收到重复数据,这种情况概率极小。
如果没有确认完一个完整的事务,那么下次启动会从这个事务的头部开始重新拉取,这种情况下,不能看作重复数据。 SDK 的核心逻辑会保证事务的完整性。
不可以,目前一个数据订阅实例只能订阅一个 TencentDB 实例。
选一个配置更好一点的宿主机,单个 SDK 在高速平稳运行时,消耗 CPU 资源小于1核,内存占用小于1.5GB。
本页内容是否解决了您的问题?