Не уверена что выбрала правильный раздел, плиз перенесите если нужно.
В общем, допустим есть сервак с базой данных (SQL Server, windows мащина соответственно), а вот само приложение крутится на линуксе, на другом сервере получается.
Считаете ли вы что системное время должно быть синхронизировано между этими двумя серверами?
Дело в том что иногда некоторые поля в базе данных обновляются используя getdate() у sql serverа- это соовтетственно время виндовой машины. Другие поля (или те же самые, просто в другое время и в других условиях) могут обновляться используя какой нибудь new Date() выполняемый джавой в приложении, крутящемся на линуксе
понятно, что бизнес логика не должна быть заточена на том что время там должно совпадать. Правильно? все равно ж не будет совпадать до миллисекунд. но кто знает..
и вообще, гораздо удобнее исследовать какие-нибудь проблемы когда ты точно знаешь что какая-нибудь колонка в базе данных modifyDate совпадает до секунд со временем в логах джавы.
в общем является ли правомерным требование чтоб время было синхронизировано автоматически? у вас такое сделано?
и возможно ли это в принципе между виндовой и линукс машинами
естественно, допуская разницу в таймзонах. хотя у нас таймзона общая у этих серверов.
Здравствуйте, зиг, Вы писали:
зиг> в общем является ли правомерным требование чтоб время было синхронизировано автоматически? у вас такое сделано?
Требование не просто правомерно, оно такое же обязательное/естественное к выполнению, как чистить зубы по утрам.
зиг> и возможно ли это в принципе между виндовой и линукс машинами
Это не имеет значения — синхронизироваться машины должны с NTP серверами, чтобы на обоих шло точное время. У linux это стандартная служба ntpd, у windows должно быть что-то свое. Список ntp серверов можно получать как от pool.ntp.org (для нужной зоны/страны), так и забить руками.
зиг> естественно, допуская разницу в таймзонах. хотя у нас таймзона общая у этих серверов.
Если в записях БД не сохраняется таймзона, то обычно время пишут в GMT (так проще переводить в любую другую, особенно когда есть скачки на летнее/зимнее).
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, зиг, Вы писали:
зиг>> в общем является ли правомерным требование чтоб время было синхронизировано автоматически? у вас такое сделано? AB>Требование не просто правомерно, оно такое же обязательное/естественное к выполнению, как чистить зубы по утрам.
ну вот а зачем оно может быть нужно? логика программы от этого ведь не должна зависеть, нельяз на такие вещи полагаться. до миллисекунд разницы все равно быть не может
для нас причиной как я описала может быть удобно видеть когда понятно что getdate() был вызван между такими то и такимито записями в логах.
ну и всё... ?
Здравствуйте, зиг, Вы писали:
зиг> ну вот а зачем оно может быть нужно? логика программы от этого ведь не должна зависеть, нельяз на такие вещи полагаться. до миллисекунд разницы все равно быть не может
Логика, конечно же, не должна полагаться на такие вещи. А вот сами данные (дата/время) должны быть корректными, иначе зачем они нужны в базе? Ну будет там 20 июля вместо 11 октября, логика работы ведь не зависит? Не зависит. А вот данные уже лишены смысла.
зиг> для нас причиной как я описала может быть удобно видеть когда понятно что getdate() был вызван между такими то и такимито записями в логах. зиг> ну и всё... ?
Ну и это тоже.
P.S. Затраты на синхронизацию времени мизерны (если подходить к вопросу без фанатизма), профит вполне себе очевиден.
Здравствуйте, Anton Batenev, Вы писали:
AB>Требование не просто правомерно, оно такое же обязательное/естественное к выполнению, как чистить зубы по утрам.
Аргументы будут или ты просто постулируешь?
Здравствуйте, Kernan, Вы писали:
K> AB>Требование не просто правомерно, оно такое же обязательное/естественное к выполнению, как чистить зубы по утрам. K> Аргументы будут или ты просто постулируешь?
Вопрос поставил меня в полный тупик Ты пользуешься часами? Есть какие-нибудь аргументы, чтобы на них было более-менее точное время или это постулат?
Здравствуйте, Kernan, Вы писали:
AB>>Требование не просто правомерно, оно такое же обязательное/естественное к выполнению, как чистить зубы по утрам. K>Аргументы будут или ты просто постулируешь?
Можешь не чистить зубы по утрам.
Здравствуйте, Kernan, Вы писали: K>Аргументы будут или ты просто постулируешь?
1. Современные системы аутентификации (aka Kerberos) построены на time-sensitive тикетах. Поэтому разница во времени больше определённой приведёт к тому, что канал просто упадёт.
2. С точки зрения философии, время — это последовательность и длительность. Фраза "понятно, что бизнес логика не должна быть заточена на том что время там должно совпадать" в целом корректна, но интерпретируется совершенно неправильно. Хрен с ней с длительностью. Но последовательность??? Вот, допустим, я пишу в базу запись о проведённой операции. Timestamp начала берётся из приложения, timestamp окончания берётся из сервера. В итоге в базе имеем, что операция закончилась до того, как началась. Бред? Бред.
Бизнес-логика финансовых приложений построена на том, что есть определённый порядок операций, который не должен зависеть от особенностей локальных таймеров. Иначе получается полная фигня — типа мне в проводке отказали из-за "недостаточного баланса", я время у себя на 10 минут назад открутил — и оп-ля! Проводка прошла...
Так что фраза должна трактоваться так, что нельзя смешивать в БД времена с разных машин. Грубо говоря, всё должно храниться во времени сервера.
Клиентское время допустимо только там, где оно заведомо не будет использоваться совместно с серверным, или со временем других клиентов. То есть, к примеру, можно записывать в сервер лог операций банкомата, размеченный по локальному времени банкомата. В целях минимизации трафика — то есть пишем не ежесекундно, а только по окончанию операции скидываем батч со всеми шагами. При этом нигде в бизнес-логике не должны фигурировать формулы, в которых есть сразу "время сервера" и "время банкомата", или времена двух банкоматов. Потому что по таким данным невозможно сделать никаких выводов о взаимной последовательности операций из разных "доменов казуальности".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, зиг, Вы писали:
зиг>ну вот а зачем оно может быть нужно? логика программы от этого ведь не должна зависеть, нельяз на такие вещи полагаться.
Сегодня нет, а завтра есть.
Финансовые транзакции есть в системе? Как начнете фрод ловить, так вас и заставят все по уму сделать.
Здравствуйте, зиг, Вы писали:
зиг>В общем, допустим есть сервак с базой данных (SQL Server, windows мащина соответственно), а вот само приложение крутится на линуксе, на другом сервере получается. зиг>Считаете ли вы что системное время должно быть синхронизировано между этими двумя серверами? зиг>Дело в том что иногда некоторые поля в базе данных обновляются используя getdate() у sql serverа- это соовтетственно время виндовой машины. Другие поля (или те же самые, просто в другое время и в других условиях) могут обновляться используя какой нибудь new Date() выполняемый джавой в приложении, крутящемся на линуксе
зиг>понятно, что бизнес логика не должна быть заточена на том что время там должно совпадать. Правильно? все равно ж не будет совпадать до миллисекунд. но кто знает.. зиг>и вообще, гораздо удобнее исследовать какие-нибудь проблемы когда ты точно знаешь что какая-нибудь колонка в базе данных modifyDate совпадает до секунд со временем в логах джавы.
зиг>в общем является ли правомерным требование чтоб время было синхронизировано автоматически? у вас такое сделано? зиг>и возможно ли это в принципе между виндовой и линукс машинами зиг>естественно, допуская разницу в таймзонах. хотя у нас таймзона общая у этих серверов.
На соседнем линуксе, наверняка есть не занятый линукс рядом, или в крайнем случае на том же линуксе (а как сильно там джава его тормозит?) поднимите службу NTP. и синхронизируйте с атомными часами 0.pool.ntp.org.
А windows пусть с ним [линуксом] синхронизируется. Windows умеет штатно синхронизироваться с NTP. В реестре можно подкрутить чтобы он делал это чаще и точнее.
По крайней мере у вас "внутри" будет одинаковое время, что очень поможет при ловле ошибок и глюков.
Здравствуйте, зиг, Вы писали:
зиг>для нас причиной как я описала может быть удобно видеть когда понятно что getdate() был вызван между такими то и такимито записями в логах. зиг>ну и всё... ?
А потом начнут приходить клиенты из других тайм-зон, и будет срочный головняк "что за ерунду мы им показываем" (да даже достаточно того, чтобы шеф в командировку смотался и начал плеваться). Так что предыдущий совет полностью верен — во-первых, всё время в базе должно быть UTC+0, во-вторых, должна быть единая шкала времени, а не "каждый со своим самоваром". В принципе, можно обойтись бы и без NTP (например, сказать, что сервер БД — это и есть источник времени, но тогда проблемы начнутся при кластеризации этого сервера (или реплицировании базы), да и программистов лишний раз напрягать "не пользуйтесь локальными функциями времени, берите с БД-сервера" — возможно непродуктивное усложнение бизнес-кода.
