rdzviper,

вообще говоря timestamp это не дата, а просто уникальный номер изменения. Поэтому проблему можно решить достаточно просто. Вместо >= использовать >

Поскольку номер изменения уникальный, ничего не потеряется. А уже прочитанные данные перестанут таскаться туда сюда.

уникальный в таблице, надо было добавить.

ах да, по этой же причине вот это:

"После разбора ответа метка времени делается равной самому старому из последних значений пришедших параметров"

тоже неправильно. Метку надо делать равной самому новому (большому) значению пришедшего timestamp

Dimitry SibiryakovУ репликации, основанной на временных отметках только одна проблема: она совершенно
неработоспособна в многопользовательском окружении.


Вполне себе работоспособна. Делал года три назад для небольшой базы с сотней пользователей, все замечательно работает. Каждый пользователь сохраняет у себя max timestamp сервера на момент репликации, и при следующей репликации обновляется все, что больше сохраненного timestamp.

Dimitry Sibiryakov
Сценарий:
1. Транзакция 1 меняет данные
2. Транзакция 2 меняет данные
3. Транзакция 2 коммитится
4. Транзакция 3 запускает репликационный запрос
5. Транзакция 1 коммитится.



Я программирую и делаю дизайн базы по старинке, между открытием трансакции и commit / rollback проходят доли секунды, и изменяемые данные в это время не читаются. В том числе и репликацией, которая тоже ждет окончания трансакции (по этому поводу я даже сильно ругался на новый MS SQL Native Driver, который по умолчанию открывает трансакцию сразу после коннекта). Но это я отвлекся.

У пользователя в локальной базе сохранен старый timestamp, для каждой таблицы. И без разницы, в какой последовательности коммитятся трансакции, полученные в таблице новые timestamp в измененных записях будут гарантированно больше, чем сохраненный у пользователя локально. Поэтому и данные реплицируются корректно.

Dimitry SibiryakovЭксклюзивная блокировка на всю таблицу? Да, в таком случае оно может работать. Как и при
использовании Dirty Read.


Нет, обходится без блокировки. Репликация делает




И если на таблице есть открытые трансакции с измененными данными, то такой селект становится в очередь и ждет, пока трансакции не завершатся.


Dimitry SibiryakovВ вышеприведённом сценарии какой именно это будет timestamp? Из шага 1,2 или 4?


Во время репликации каждой таблицы там находится Max(timestamp) этой таблицы. Полученное значение сохраняется в локальной базе в специальной таблице (поле типа bigint). И используется при следующей репликации как [сохраненный timestamp]. Т.е. не из шага 1,2 или 4, а из прошлой репликации. Которая делалась в момент без открытых трансакций. Есть конечно заморочки с удаленными и новыми данными, но они решаемы. Долго рассказывать :)

Это я конечно схематично показал, самому смешно стало. Делается через курсор, и Max TIMESTAMP находится в процессе обработки.

tanglirа если транзакция 1 уже открыта, но ещё не успела изменить данные?

Тогда блокировки еще нет, и селект отрабатывает. Но и timestamp после коммита трансакции 1 будет больше, чем максимальный в данных селекта. Изменения, которые сделала транзакция 1 будут замечены в следующей репликации.

Dimitry SibiryakovПисатели не блокируют читателей.


Вообще зависит от TRANSACTION ISOLATION LEVEL. READ COMMITED блокирует измененные записи на чтение, пока не произведен COMMIT

Dimitry SibiryakovКакой-то это неправильный READ COMMITTED. Это скорее NOREAD COMMITTED...


Меня помнится тоже поначалу удивляло :) Но вообще логично - "читать закоммитенные данные". Т.е. не закоммитенные не читаются.

sphinx_mvА если до коммита 1-ой (все-таки меняющей данные) транзакции пройдет коммит еще надцати других меняющих и реплицирующих транзакций?
НЕ РАБОТАЕТ!
Кроме клинического случая с "грязным чтением".

1. SELECT на репликацию проходит только если нет открытых трансакций с измененными данными.
2. Max(timestamp) SELECTа на репликацию сохраняется локально на клиенте, который делает репликацию.
3. Любые изменения после прохождения SELECTа на репликацию (неважно от скольких трансакций) имеют как следствие увеличение timestamp по сревнению с полученным SELECTом на репликацию Max(timestamp). И поэтому отлавливаются следующей репликацией.
4. РАБОТАЕТ! уже больше 3 лет :)

sphinx_mv1. И кто же его запретит сделать? И как Вы узнаете, что открытые транзакции не успели изменили данные после момента любой такой проверки?


Как вам правильно написали, сервер сам не даст сделать SELECT, если существуют открытые трансакции с измененными данными.
SET TRANSACTION ISOLATION LEVEL READ COMMITED в коннекте на репликацию, и SELECT ждет коммита на измененные данные. Это блокировка на чтение измененных и незакоммиченых данных. Речь идет о MS SQL Server, если что.


sphinx_mv2. timestamp фиксируется в исходной таблице по UPDATE, а не по COMMIT. Если на сервере больше одного "пишушего" коннекта, НИКТО не гарантирует, что они коммитятся именно в порядке нарастания timestamp. И соответственно, совершенно никакой гарантии что именно в порядке нарастания timestamp данные будут реплицированы на получателя.


нас в данном случае совершенно не интересует порядок UPDATE и COMMIT, которые будут произведенв после SELECTа на репликацию. Потому что см. выше - нет измененных данных без коммита на момент SELECTa.


sphinx_mv3. Ваш MAX(timestamp) на получателе НЕ ВИДИТ timestamp незакоммиченных и тем более не прореплицированных записей из исходной базы данных. Из п.2. напрямую следует НАРУШЕНИЕ порядка нарастания значения MAX(timestamp) на основе данных получателя.


еще раз - нет измененных данных без коммита на момент SELECTa. Все timestamp на момент SELECTа актуальные - или закоммитенные, или без изменения с момента открытия трансакции. Все что случится после SELECTa приведет к увеличению timestamp по сравнению с полученным SELECTом.


sphinx_mv4. Без блокировок ТАБЛИЧНОГО уровня для пишуших транзакций - НЕ РАБОТАЕТ. Даже для серверов-"блокировочников".
Либо у Вас система НЕ-МНОГОПОЛЬЗОВАТЕЛЬСКАЯ.


Блокировок ТАБЛИЧНОГО уровня нет, есть блокировка на чтение измененных записей в трансакции. Система многопользовательская, в среднем около 10 пользователей единомоментно непосредственно работают на сервере и около 100 клиентов с локальными копиями, каждый раз в пару дней делает репликации. База небольшая, как я уже писал.

sphinx_mvИ даже этот самый строгий уровень изоляции не гарантирует, что будут заблокированы ВСЕ записи в таблице - актуально для запросов с критериями отбора (как в обсуждаемом случае). Соотвественно на непересекающихся наборах записей одновременные транзации вполне себе могут ужиться, не мешая друг другу...



Кстати тут как раз все "чисто". Критерий в SELECTе один - на timestamp, а он меняется гарантированно при любом изменении записи. И SELECT попадает на блокировку.

дополнение: Критерий в SELECTе один - на timestamp, а он меняется гарантированно при любом изменении записи так, что измененная запись попадает в выбоку SELECTа . И SELECT попадает на блокировку.

В больших таблицах проиндексированно. Сейчас заглянул в лог репликации, последние 2 длительность:

начало репл. конец репл.
25.05.2012 12:10:36 25.05.2012 12:15:51
25.05.2012 11:36:07 25.05.2012 11:47:10


база 1,5 гига. Так что мне кажется неплохо 5-10 мин. С учетом того, что интернет у client через мобильную связь. Это было кстати условием - короткая репликация с плохой связью.

Dimitry Sibiryakov
1. Репликационный запрос читает первую страницу из трёх
2. На второй он останавливается, ожидая окончания параллельного апдейта
3. Апдейт записи на первой странице
4. Апдейт записи на третьей странице
5. Вторая страница освобождается, запрос получает timestamp из записи на третьей странице,
который больше чем у записи из п.3 на первой. Запись с первой страницы выпадает из поля
зрения.

При наличии индекса, такое, вроде бы, невозможно.


Хм.. Теоретически наверно это возможно. Хотя с моей точки зрения это был бы баг в SQL Server. Надо будет прошерстить таблицы. Я давно в эту базу не заглядывал, не было поводов.