数据库宕机时Kafka JDBC Sink Connector的最大重试次数及重试间隔是多少？

针对你测试时遇到的情况，我来拆解一下这个场景下的关键信息和应对思路：

1. 重试机制的正常反馈 #

你看到的INFO日志是Connector内置的连接重试机制在正常工作：

INFO Unable to connect to database on attempt 1/3. Will retry in 10000 ms. (io.confluent.connect.jdbc.util.CachedConnectionProvider:91)

默认配置下，CachedConnectionProvider会尝试3次数据库连接，每次重试间隔10秒（10000ms）。这是Connector为应对临时网络波动或数据库短时间不可用设计的自愈逻辑，属于预期内的正常反馈。

2. SQL Server可用性组的特定错误解读 #

伴随的SQLServer异常指向了更具体的问题：

com.microsoft.sqlserver.jdbc.SQLServerException: Unable to access availability database 'Giorgos' because the database replica is not in the PRIMARY or SECONDA...

这说明你的数据库属于SQL Server Always On可用性组，当主库宕机后，副本没有切换到PRIMARY或SECONDARY可用状态，导致Connector无法建立合法的数据库连接。这种情况通常和可用性组的故障转移配置有关——比如故障转移未自动触发，或者副本本身处于异常状态。

3. 优化建议 #

• 调整重试参数：如果你的数据库恢复周期较长，可以修改Connector配置适配业务需求：
  • connection.max.retries：增大重试次数（默认值为3）
  • connection.retry.backoff.ms：延长重试间隔（默认值为10000ms）
• 排查可用性组状态：检查SQL Server可用性组的故障转移策略，确保主库宕机时能自动切换到健康的副本，让数据库回到PRIMARY/SECONDARY可用状态。
• 保障消息交付可靠性：Connector默认采用至少一次的交付语义，数据库恢复后未成功写入的消息会自动重试。如果担心重复写入问题，可以开启insert.mode=upsert，结合数据库主键约束实现幂等性写入。

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