Исключение часового пояса Logstash с SQL Server

Я использую версию 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"

person Rajendra Jangir    schedule 09.12.2019    source источник
comment
Это не ошибка SQL Server. SQL Server не имеет типов с часовыми поясами. datetimeoffset содержит смещение часового пояса, а не имя часового пояса. Это означает, что ошибка возникает, когда logstash пытается конвертировать между разными типами, которые могут поддерживать или не поддерживать смещения. Каковы типы поля lastupdatetimestamp и параметра :sql_last_value? Если lastupdatetimestamp является datetimeoffset, sql_last_value тоже должен иметь тот же тип, чтобы избежать преобразования   -  person Panagiotis Kanavos    schedule 09.12.2019
comment
В любом случае SQL Server предлагает встроенный отслеживание изменений, что намного эффективнее запроса временной метки обновления. Например, временные метки обновления не могут обрабатывать удаления.   -  person Panagiotis Kanavos    schedule 09.12.2019
comment
@PanagiotisKanavos Спасибо за ваш ответ. В SQL Server поле lastupdatetimestamp имеет тип даты и времени. И я определил это поле в LogStash как тип отметки времени.   -  person Rajendra Jangir    schedule 09.12.2019
comment
Что касается самой ошибки, я предполагаю, что код передал в запрос datetime или datetime2, заставив logstash преобразовать его в локальное значение datetimeoffset. Если библиотека, используемая для таких преобразований (обычно tzdb), не имеет правил часового пояса для Asia/Kolkata для 1942 года, вы можете получить сообщение об ошибке. Раньше это имя было Asia/Calcutta   -  person Panagiotis Kanavos    schedule 09.12.2019
comment
иногда работает нормально... Но раз в неделю выдает исключение и LogStash не сохраняет последнюю временную метку. Итак, какие изменения я должен внести в LogStash?   -  person Rajendra Jangir    schedule 09.12.2019
comment
Вы можете попробовать с Loc. Вместо этого вы должны использовать datetimeoffset - что, если клиент и сервер находятся в разных часовых поясах? . Более того, используйте отслеживание изменений, чтобы вам вообще не приходилось беспокоиться о часовых поясах и триггерах. Вы также можете попробовать новые типы, например LocalDateTime или OffsetDateTime.   -  person Panagiotis Kanavos    schedule 09.12.2019
comment
Согласно документации logstash, я могу использовать только числовой тип столбца отслеживания и отметку времени. Так есть ли способ изменить его на LocalDateTime и OffsetDateTime?   -  person Rajendra Jangir    schedule 09.12.2019
comment
время просто недопустимо для этого часового пояса. Если вы проверите историю часового пояса, вы увидите, что переход на летнее время ровно 1942-09-01 00:00 с +5:30 до +6:30. См. эта проблема с elasticsearch тоже   -  person Panagiotis Kanavos    schedule 09.12.2019
comment
Пожалуйста, опубликуйте фактические имена и версии драйвера JDBC, Elastic, logstash и код/конфигурацию, которые вы использовали. Опубликуйте также стек вызовов ошибки. Почему сентябрь 1942 года также использовался как время обновления? Тогда не было компьютеров, и это конкретное значение для этого часового пояса гарантирует сбои.   -  person Panagiotis Kanavos    schedule 09.12.2019
comment
@PanagiotisKanavos Я добавил рассматриваемую конфигурацию logstash. Пожалуйста, просмотрите конфиг.   -  person Rajendra Jangir    schedule 11.12.2019
comment
@PanagiotisKanavos .. Не могли бы вы просмотреть конфигурацию logstash?   -  person Rajendra Jangir    schedule 13.12.2019
comment
@PanagiotisKanavos У вас была возможность просмотреть мою конфигурацию logstash?   -  person Rajendra Jangir    schedule 13.12.2019


Ответы (1)


вам нужно привести его к отметке времени

WHERE lastupdatetimestamp >  DATETIME(TIMESTAMP :sql_last_value);"
person ArunasB    schedule 19.12.2019