Я использую версию LogStash 7.3.2 для извлечения данных из SQL Server. Это исключение ниже:
Исключение при выполнении запроса JDBC {:exception=>#
переход (переход на летнее время «пробел»): 1942-09-01T00:00:00.000 (Азия/Калькутта)>}
Я указал ниже запрос в LogStash:
select *
from mytable
where lastupdatetimestamp > :sql_last_value
Пожалуйста, предложите мне, что мне здесь не хватает.
Я использую следующую конфигурацию: -
jdbc_connection_string => "jdbc:sqlserver://HOST:PORT;databaseName=DB_NAME;integratedSecurity=false
jdbc_user => "USERNAME"
jdbc_password => "PASSWORD"
jdbc_driver_library => "/home/user/LOGSTASH/mssql-jdbc-7.4.1.jre8.jar"
jdbc_driver_class => "com.microsoft.sqlserver.jdbc.SQLServerDriver"
statement => "SELECT * FROM TABLE_NAME where INCR_COLUMN > :sql_last_value "
schedule => "*/60 * * * * *"
use_column_value => true
tracking_column => "INCR_COLUMN"
tracking_column_type => "timestamp"
record_last_run => true
last_run_metadata_path => "/home/user/LOGSTASH/LAST_RUN/.mssql_USERS_logstash_jdbc_last_run"
connection_retry_attempts => "1000"
connection_retry_attempts_wait_time => "60"
jdbc_default_timezone => "UTC"
datetimeoffset
содержит смещение часового пояса, а не имя часового пояса. Это означает, что ошибка возникает, когда logstash пытается конвертировать между разными типами, которые могут поддерживать или не поддерживать смещения. Каковы типы поляlastupdatetimestamp
и параметра:sql_last_value
? Еслиlastupdatetimestamp
являетсяdatetimeoffset
,sql_last_value
тоже должен иметь тот же тип, чтобы избежать преобразования - person Panagiotis Kanavos   schedule 09.12.2019datetime
илиdatetime2
, заставив logstash преобразовать его в локальное значениеdatetimeoffset
. Если библиотека, используемая для таких преобразований (обычно tzdb), не имеет правил часового пояса дляAsia/Kolkata
для 1942 года, вы можете получить сообщение об ошибке. Раньше это имя былоAsia/Calcutta
- person Panagiotis Kanavos   schedule 09.12.2019datetimeoffset
- что, если клиент и сервер находятся в разных часовых поясах? . Более того, используйте отслеживание изменений, чтобы вам вообще не приходилось беспокоиться о часовых поясах и триггерах. Вы также можете попробовать новые типы, напримерLocalDateTime
илиOffsetDateTime
. - person Panagiotis Kanavos   schedule 09.12.20191942-09-01 00:00
с +5:30 до +6:30. См. эта проблема с elasticsearch тоже - person Panagiotis Kanavos   schedule 09.12.2019