В нашем приложении у нас есть центральная база данных и множество отключенных клиентских приложений с их собственными локальными базами данных. Клиент подключается к центральному серверу, и сервер должен отправить им данные, которые были изменены с момента последнего подключения клиента.Отслеживание изменений данных с некоторого времени
Поскольку клиентов слишком много, и некоторые из них могут перестать существовать без уведомления сервера, нецелесообразно оставлять ожидающие изменения на сервере для каждого клиента.
Именно поэтому в каждой соответствующей таблице имеется столбец update_date, который находится на каждой вставке, и каждое обновление установлено на current_timestamp. Удаления обрабатываются аналогичным образом со вспомогательной таблицей для каждой синхронизированной таблицы, где мы храним первичный ключ синхронизированной таблицы и delete_date.
Когда клиент соединяется с сервером, он посылает на сервер последнюю метку синхронизации, сервер посылает все изменения, где update_date > last_sync, а затем current_timestamp сделки для хранения на стороне клиента, как last_sync.
Проблема этого подхода заключается в том, что, когда есть бегущая сделка T1 с current_timestamp = 1000, клиент подключается в транзакции T2 с current_timestamp = 2000. Так как T2 не видит еще не зафиксированные изменения, сделанные в T1 , их не отправляют клиенту. В следующий раз, когда клиент подключится, изменения с T1 уже совершены, но они отмечены update_date = 1000, поэтому они не будут отправлены клиенту с просьбой об изменениях, внесенных после 2000 года.
Любые предложения, как убедиться что клиенты получают все измененные записи? Допустимо, что клиенты получают одни и те же изменения несколько раз.
Thanks Wolph, я думаю, что триггеры аудита были бы немного переборщиками, так как мне нужно отправить клиенту только текущие значения, а не полную историю. Кроме того, я не уверен, что это решит мою проблему пропустить некоторые изменения, сделанные в транзакции, изолированной во время предыдущей синхронизации. Я посмотрю на Букардо. Я ранее не рассматривал репликационные решения, потому что клиенты не используют PostgreSql, и их слишком много. –
Ну, в этом случае вы можете изменить уровень изоляции транзакций, чтобы каждый клиент всегда видел последние данные. Или даже используйте блокировки чтения при чтении данных. – Wolph
У меня есть вопрос об уровне изоляции транзакций. Проблема в том, что тогда я могу отправить клиентам данные из транзакций, которые позже будут откатны. Мое текущее «решение» заключается в том, чтобы отправить клиенту все изменения с «last_sync - 5 минут», считая, что транзакции будут не более 5 минут. У клиентов нет проблем с получением данных несколько раз, это всего лишь немного менее эффективно.Блокировки чтения, вероятно, слишком сильно повлияют на производительность основного серверного приложения, но я проверяю это. –