LogStash 7.3.2连接SQL Server夏令时间隙时区异常求助

你遇到的这个错误是**夏令时间隙（daylight savings time 'gap'）**导致的——1942年9月1日的00:00:00在Asia/Kolkata时区是一个不存在的时间点（当时印度调整夏令时规则，跳过了这个时间段）。当Logstash用你配置的jdbc_default_timezone => "UTC"处理时间转换时，Java时区解析器无法将UTC时间映射到这个无效的本地时间，从而抛出异常。

具体修复方案 #

1. 对齐Logstash与数据库的时区配置 #

如果你的SQL Server数据库使用Asia/Kolkata时区存储时间，把Logstash的时区配置改成和数据库一致，避免跨时区转换时触发夏令时问题：

jdbc_default_timezone => "Asia/Kolkata"

这是最彻底的解决方式，能从根源上避免时区转换带来的时间解析错误。

2. 临时跳过无效时间点（应急方案） #

如果暂时无法修改时区配置，可以在查询语句中直接排除那个无效的时间区间：

SELECT * FROM TABLE_NAME 
WHERE INCR_COLUMN > :sql_last_value
AND NOT (INCR_COLUMN >= '1942-09-01T00:00:00.000' AND INCR_COLUMN < '1942-09-01T00:30:00.000')

注意这个方法只针对本次出现的特定时间点，不是通用解决方案。

3. 升级Logstash或JDBC驱动版本 #

你当前使用的Logstash 7.3.2和mssql-jdbc-7.4.1.jre8版本都比较旧，新版本的工具可能修复了旧夏令时规则的解析bug。建议尝试升级到Logstash 7.x系列的最新补丁版本，或者把JDBC驱动升级到mssql-jdbc-9.x及以上版本。

4. 校验跟踪列的类型配置 #

确认你的INCR_COLUMN在SQL Server中确实是datetime或datetime2类型，而非字符串类型。如果是字符串，需要把tracking_column_type调整为string，并确保时间格式符合标准，避免额外的解析错误。

额外调试建议 #

• 检查last_run_metadata_path指向的文件，看看里面存储的最后运行时间是不是刚好卡在1942-09-01T00:00:00.000这个无效点上。如果是，手动修改为1942-09-01T00:30:00.000，让Logstash从有效时间继续执行查询。
• 涉及时间的数据流链路中，尽量保证数据库、Logstash、下游系统的时区统一，减少跨时区转换带来的潜在问题。

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