репликация. асинхронный мульти-мастер

[zwitter]

да, я идеалист и мечтатель.
все усугубляется тем, что это УЖЕ мускул.
то есть вопрос о репликации встал поздно.

мальчишки, идеи?

лестер, выхади. расскажи нам про валентину. я без сарказма. интересно будет послушать.

zwitter добавил 06.10.2009 в 21:48
ок, жду до завтра а потом буду выдвигать свои убогие кустарные идеи

[ustas]

цитата , может тебе на глаза попадалась

И последний тип репликации — это асинхронный Multi-Master. Надо сказать, что это мечта человечества. Она не реализуется в общем виде, она антипаттерн. Если у вас приложение или бизнес требуют асинхронного Multi-Master’а, вам нужно что-то делать либо с приложением, либо с бизнесом. В общем виде проблему не решить по причине конфликтов. Вы можете научить базу данных разрешать какие-то конкретные конфликты. Например, на одном Master’е пользователь обновил запись о своём адресе, а на другом запись о своём телефоне — вот такой конфликт базу данных можно научить разрешать. Но если возникает что-то сложное, то, понятно, что без ручного вмешательства проблему решить невозможно, поэтому асинхронный Multi-Master это зло.

[pingwinator]

Сообщение от ustas

цитата , может тебе на глаза попадалась

тока что послал это 2 девушкам в аське, одна обиделать, сказала что я её проклял
филфак :(

[ustas]

ты скажи ей что умеешь снимать проклятия, и что это не самое сильное

ustas добавил 07.10.2009 в 00:57
еще цитата

Вопрос: Как оказалось, любая нода это слабое место кластера, от неё ожидается accept. Если она медленная, это означает, что весь кластер в результате медленный. В горизонтальном масштабировании ситуация такая же?

Иван: Хороший вопрос. Дело в том, что для горизонтального масштабирования лучше не использовать Multi-Master. Лучше строить приложения, партицируя свои данные, то есть, разбивая таблицу пользователей на 26 узлов по первой букве. Multi-Master синхронный, асинхронного нет, ни одного решения, ни в одной базе. Если говорят, что он есть, шарлатаны, не слушайте их. Соответственно не используйте синхронный Multi-Master, потому что нужно ждать самую медленную ноду.

а что за задача все таки, и почему именно такой тип репликации?

[zwitter]

Сообщение от ustas

цитата , может тебе на глаза попадалась

попадалась, да.

zwitter добавил 07.10.2009 в 12:14

а что за задача все таки, и почему именно такой тип репликации?

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

мои кустарные идеи таковы.

1. в моей базе реализована версионность записей. на данный момент я использую это как извращение вместо LOCK'a при конкурентных update'ах. типа открыл юзер запись, пока думал, другой ее апдейтит. собственно потом при сохранении первым встает вопрос - перезаписать или перечитать ? юзер решает.

собственно полу-автоматическая репликация самописным же софтом доставляет мне разницу в виде чистых инсертов и списка конфликтов по обновленным записям.

2. реализовать на триггерах таблицу журнала изменений базы
* ид
* ид таблицы
* ид записи
ну и для красоты
* ид операции (инсерт/апдейт/делит)
* ид юзера

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

база небольшая кстати.
единственно удручает что "репликацию" надо запускать вручную.

[ustas]

т.е. у тебя сейчас поле версия записи, если я например открыл какую то запись с версией 123, за это время один торопыга открыл, внёс изменения, версия записи стала 124 и при попытке сохранения я получу сообщение о том что запись поменялась, перечитать или перезаписать на мой выбор. Перекладывать такие заботы на пользователя приводит к упрекам в сторону разработчика , типа ну вот я делал-дала, а оно не сохранилось, ой а я и не заметил что за вопрос был задан мне при попытке сохраниться и т.п.

2. реализовать на триггерах таблицу журнала изменений базы
* ид
* ид таблицы
* ид записи
ну и для красоты
* ид операции (инсерт/апдейт/делит)
* ид юзера

я подобное в firebird делал, для ведения истории и возможности откатов операций
единственное что добавлены были поля (к тем что ты указал)
* поле
* значение (все перегонял в строку, в хранимых процедурах приводил к нужному типу)
* дата/время операции
единсвенно что, нужен ли тут будет собственный айди (праймарикей).
росла база быстренько из-за такого журнала (даже подумывал вынести это в отдельную бд), но т.к. по условию задачи хранение журнало ограничивалось тремя месяцами и вообще бд была не шибко большая, то такой вариант проканал.
хотя в firebird(interbase) насколько я помню есть и свой механизм ведения журналов, в своих системных таблицах. Уже не помню по какой причине, но по этому пути мы не пошли.

единственно удручает что "репликацию" надо запускать вручную.

а какая событийность этого запуска? что есть сигналом для запуска на текущий момент

[zwitter]

Сообщение от ustas

т.е. у тебя сейчас поле версия записи, если я например открыл какую то запись с версией 123, за это время один торопыга открыл, внёс изменения, версия записи стала 124 и при попытке сохранения я получу сообщение о том что запись поменялась, перечитать или перезаписать на мой выбор. Перекладывать такие заботы на пользователя приводит к упрекам в сторону разработчика , типа ну вот я делал-дала, а оно не сохранилось, ой а я и не заметил что за вопрос был задан мне при попытке сохраниться и т.п.

именно так.
для этого нарисован жирный восклицательный знак и большие буквы.
согласен, от идеала далеко, но ставить локи при резервировании записи юзером, чтобы другие могли иметь ее только в R/O - более геморойно, можно нарваться на неосвобождение, или писать дополнительную чекалку с проверкой срока резервирования ?

с другой стороны от человеческого фактора не отделаешься.
слабо кинуть калькулятор на клаву и выбить чек на 9999 литров топлива ? )))))))))

Сообщение от ustas

я подобное в firebird делал, для ведения истории и возможности откатов операций
единственное что добавлены были поля (к тем что ты указал)
* поле
* значение (все перегонял в строку, в хранимых процедурах приводил к нужному типу)
* дата/время операции
единсвенно что, нужен ли тут будет собственный айди (праймарикей).

кагбы же чтобы сравнивать с даты последней синхронизации баз

а какая событийность этого запуска? что есть сигналом для запуска на текущий момент

контролируемый обрыв канала и релокация второго мастера.

а вообще мне начинает казаться что 3G модем шикарненько решает проблему )))))))))))

[Davlat]

а ещё говорят, что Ленин - это гриб с молекулярно-волновыми свойствами... тьфу...