Debezium SQL Server连接器启动报Couldn't obtain database name错误

这个报错是Debezium SQL Server连接器的经典“吞错误”问题：连接器启动阶段所有连接相关的SQLException都会被统一包装成“Couldn't obtain database name”抛出，根本不会打印真实错误堆栈，绝大多数场景和库名配置、库名查询权限无关。
最高发的触发原因是：所用Debezium版本内置了8.4及以上版本的mssql-jdbc驱动，该版本驱动默认强制开启SSL传输加密，如果SQL Server实例没有配置公共CA信任的合法证书，SSL握手阶段就会连接失败，最终被上层逻辑包装成你看到的报错。

• 优先补全SSL相关连接配置
  在连接器配置中追加以下两个参数，透传给JDBC驱动关闭强制加密、信任服务端证书：

  database.encrypt=false
  database.trustServerCertificate=true
  

  如果你使用的Debezium版本低于1.8，不支持直接配置上述两个参数，可以直接指定完整JDBC连接串覆盖默认拼接逻辑：

  database.jdbc.url=jdbc:sqlserver://MyDbHost:1433;databaseName=MyDatabase;encrypt=false;trustServerCertificate=true
  

  配置完成后重新提交连接器任务，90%以上的场景可以直接恢复正常。
• 校验master库连接权限
  连接器默认会先连接master库执行sys.databases查询做库名校验，如果公司DBA限制了业务账号访问master库的权限，哪怕账号对目标业务库有完全权限，也会触发这个报错。这种场景直接用上面的database.jdbc.url参数指定连接到目标业务库，就可以跳过连master的校验逻辑。
• 校验库名大小写匹配
  如果SQL Server实例配置了区分大小写的排序规则，配置中database.dbname的大小写必须和sys.databases中存储的库名完全一致，大小写不匹配也会导致校验失败。
• 开启调试日志拿真实错误
  如果以上操作都没有解决问题，修改Kafka Connect的log4j配置，将io.debezium.connector.sqlserver包的日志级别调整为DEBUG，重启Connect服务后再提交任务，就能看到被异常捕获逻辑吞掉的原始错误堆栈，直接定位根因。

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