Что-то пропало сообщение, которе писал пол часа.
Сгличило на сайте. Тада в кратце.

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

Равноправная репликация не предполагает "условно главных". Может быть тока с точки зрения управления репликационной средой или разрешения конфликтов в некоторых случаях - када двое полезли в одну запись, то может быть правило в пользу сайта, хотя не обязательно. Может быть по тайм ауту.
А по данным они равноценны - вся идея не различать сайты в распределенной среде. Вообще всегда витали идей прозрачности, хотя они и услужняют админство.

Выбрал не стэндбай по след причинам:
1) Все-таки остается возможность сделать незаметным отказ сервака. Т.е. сервак падает, а юзра не чувствуют. И даже админы. Однако, именно в последних все дело, почему этого пока не сделал.

2) Стэндбай не работает на запись и полностью БД идентичны. А у нас один из серваков используется для репликации в центральный офис - нет полной идетичности и работают на запись.

3) Не знаю, так ли легко проверять идентичночть данных и их выравнивать в стэндбае как в мультимастер репликации.

О проблемах правильности данных в равноправной среде при асинхронной репликации. В Оракле равнопровной соответствует мультимастер репликация (т.е. каждый серсер - мастер, нет более главных и менее главных).
Она бывает асинхронной, но может быть и синхронной. В случае асинхронной - отложенные транзакции распространяются с первого на второй и выполняются там как будто их там и создали. При этом аппдэйты и удаления они выполняются только если запись идентична первой, иначе любимое "данные не найдены". Если репликация отпадала и данные не идентичны, то соответственно пойдет рост таких отложенных транзакций. Все они в очереди и в общем то возможность для восстановления есть. Но это требует квалификации от админов. Тем более что по багу может пропасть промежуточная транзакция. Если обнаружили поздно и работали с несколькими серваками, то на всех надо проводить это восстановление. Это может занять часы и не гарантирован упех, если их тысчи. А у наших нас админов у некоторых заказчиков можно сказать что нету, а и где есть, они с репликацией не на короткую ногу. Мне приходится в случае особых отказов по аське писать инструкции SQL. Это и так может занимать часы - хорошо, что это происходит редко - не чаще раза в год. Поэтому и не решаюсь сделать их юзерам полное счатье, ну и нам зачет не плохой. Тем более и часы Х происходят не часто и беспокойств минут на 10. Не так критично.

Cat2
Ситуация с банками - это уже не репликация, а гетерогенный запрос. Давайте не будем путать распределенные транзакции и репликации. Репликация, это когда в какой-то период времени, по расписанию, массово закачивается информация с разных серверов.

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

Cat2
Я пытался сказать Вам, что она в общем случае может сама при реализации использовать и использует распределенные или удаленные транзакции.
Отличаются юзерские запросы - в случае репликации, юзера выполняют локальные запросы, хотя для того, чтобы они имели такую возможность распределенные запросы до этого выполняли серваки сами, для поддержки актуальности копий в распределенной среде. Т.е. у юзера на сервере B есть табла а, копия таблы а на сервкре А, и он выполняет локальный (т.е. приконнектился к серверу В) запрос к табле а, которая на В. Но чтобы там копия была актуальна, механихмы репликации выполнили распеределенные запросы. Клиентами в них, например, выступали сами серваки. Синхронная репликация, асинхронная, но очень частая (массы маленькие) или суточная - это детали задачи.
К денормализации не имеет отношения - это логически одна и таже табла. Это в идеале только физически разные таблы - в идеале распределенность прозрачна. А денормализация - относится тока к логичекому проектированию.

softwarer
Да. Хотя можно уточнять формулировку :)

Можно. Но обычно репликация в распределенной БД - это именно генерация и воспроизводство копий на сайтах. Ну примерно так этот термин используется в литературе.

softwarer
Хм. Ну если специально делать именно так - будет означать. Но зачем?

И не специально "именно так" делать, а это и есть асинхронность. Процесс выполнивший вызов не ждет завершения вызова, а продлжает свою работу. Все остальное дополнительное. У Оракла есть AQ, которая предусматривает асинхронные события и там есть механизм подписчик- получатель. Т.е. можно посматривать время от времени, а можно получать извещения о том что событе, например, завершение вызванной процедуры произошло. Это при желании можно привестовать к асинхронной репликации. Но без этого она "делает именно так".

softwarer
Хм. С очень философской точки зрения наверное можно считать и так.

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

softwarer
Но имхо это такая же синхронность, как определение Cat2 - репликация.

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

softwarer
Если ее можно хорошо использовать - безусловно, проще. Но моя реплика - повтор - в тех условиях, в которых можно хорошо использовать синхронную репликацию, скорее всего можно использовать и удаленные соединения к центральной БД, и это будет еще проще.

У Оракла есть оговорка, если не подходят Оракловые репликации, лабайте свою. Т.е. для каких-то задач Ваша, наверное, будет луче. Задачи ить разные есть. Но в типовых случаях все же Оракловые, мне кажутся, более предпочтительными.
Можно, как я писал, прилабать и AQ и триггерное что-то.
Мне в центральном офисе приходится разрабатывать подсистемы контроля актуальности данных. А в филиалах, где равноправная, там просто раз в сутки проверяют идентичносить данных на сайтах. Такова жизнь.
Но в случае с банками, я думаю, с синхронной, если она будет нормально работать, моно спать спокойно. Все остальное - вынужденное и, возможно даже, не избежное, но ухищрение.

softwarer
Хм. Имхо не слишком-то важно, как именно называется работающая схема. Не равноправная - так не равноправная. Целью обычно является работающая БД, а не равноправная, и если при равноправной работает хуже - тем хуже для равноправной :)

В пропавшем тексте было и про репликацию Ведущий - Ведомый. Иногда именно ее и достаточно и она имеет преимущества. Например, в ней не нужна полная копия, а тока частичная. В общем случае эта копия может быть представлена в другом виде, чем на Ведущем. Это противоречит равноправной. Но равноправная не всегда противоречит "работающей БД", а иногда и лучше других этому способствует. Ить не я и даже не в Оракле ее придумали. Я говорил про нее, потому что считал, что та задача именно про нее - в банках копии счетов, но логически это один и тот же счет (и ничего лишенго - никаких хранимок). Поди плохо? У обоих серваков равные права на работу - типа логически это одна БД. Мы (и проггеры, но не админы) ниче не хотим знать в работе про то, что их два. Просто такой пример я имел в виду изначально, когда сравнивал синхронную и асинхронную. Равноправная здесь как бы подразумевается. И не тока мной.

softwarer
А по данным они равноценны. Именно так. Пользователь обращается к хранимой процедуре, на любом сайте. Эта хранимка в своей реализации делает нечто, в результате чего появляется нужный результат. То, что она внутри себя покумекала насчет "условно главных" - ее внутренее инкапсулированное дело :)

Ну боюсь, что покумекать придется таки проггерам и админам, что она там делала и чего не сделала или может не сделать. И есть ли шанец, что пропадут таки бабки (т.е. окажутся ли данные во всех отношениях равноценными или распределенность "почувствуется" при работе с ними). Сам я отношусь с настороженностью к хранимкам в распределенной БД. У нас была раньше "ручная" (с хранимками) репликация. Заменили на штатную Оракловую - распределенность может привносить свое по сравнеию с одной централизованной БД. Поэтому путь с хранимками не кажется безоблачным во всех отношениях. Могут возникать сюрпризы разные в разное время эксплуатации и на разных версиях Оракла. И чаще када не до сюрпризов. Но в общем, как писал выше, в каких-то случаях "ручные" репликации могут оказаться неизбежными.

softwarer
Генерация копий - не то же, что копии таблиц.

Не то же, но не исключает копии таблиц. В равноправной именно копии таблиц, в Ведущий_Ведомый просто копий. Могут быть конечно и копии обектов. Типа на одном создали триггер, среда репликации на втором такой же генерит.

softwarer
В репликации есть интересный момент: в принципе возможна такая ситуация, что ни в какой момент времени данные в любой локальной БД не отражают реальной картины мира (или хотя бы копию таблицы с другого сервера), в то время как ее отражает "распределенная БД".

Ну это как бы не в репликации этот интересный момент, а в распределенной БД. А в репликации этот интересный момент интересен, тока если обеспечивается требуемая актуальность копий. Иначе он совсем не интерсен.

softwarer
Это один из вариантов асинхронности.

Ну не знаю как иначе можно в этом контексте понять сам термин асинхронность. Асинхронный способ вызова процедур, может, наверное, подразумевать в широком смысле что-то дополнительное к этому в общем случае. Но это, наверное, какое-то расширение термина для сокращений текстов описаний.

softwarer
Проблема, от которой нужно так или иначе защищаться. Но настаивать, что это единственный и принципиальный вариант - имхо неверно.

Ну какбы этот термин был и раньше. И означал в данном контексте, что вызвавший процедуру не ждет ее завершения. Ну термин такой для этого используют. Хотя мож я чего-то упустил. Но с Ораклом вроде совпадает. Есче с какой-то литературой.

softwarer
Напомню: я говорю о том, что не представляю себе ситуации, в которой синхронная репликация будет хорошим (aka "лучше либо не слишком хуже других") решением.

Я уверен на сто процентов, что если система позволяет реализовать синхронную репликацию так, чтобы ничего там не висло, не откатывало работу лишний раз из-за сбоев в сети, то она в равноправной репликации лучше. Копии актуальны в любой момент времени. Чего же лучше может быть?

Это во всех отношениях преимущество. Т.е. если убрать ее недостатки, связанные с тем, что на каком-то узле всегда может что-то случиться и транзакция не выполнится нигде, то останутся весьма ощутимые преимущества.

Можно провести аналогию с триггерами в одной БД. Триггер меняет другую таблу синхронно. Нужна там асинхронность? Там и автономность не всегда благо.
Мож я не так что-то выразил, но не понимаю, почему Вы не представляете себе ситуации где синхронная лучше.
Просто в современных условиях в распределенной БД ее недостаки, приведенные выше чаще перевешивают достоинства.

softwarer
Хм. Признаться, мне не очень нравится такая сложность администрирования репликации :)

Это как раз ее легкость. Запустил процедуру - она вернула список таблов в которых есть отличия. И все. Это может делать и джоб и любой юзер, не понимая что такое репликация. Сложности начнутся когда отличия будут обнаружены, осорбенно если поздновато обнаружат. У нас один заказчик цельный квартал не обнаруживал. Вот я склевал удаленно восстанавливать.
В случае синхронной - отличия никада не появятся. А Вы говорите.

softwarer
Есть. Но не всегда он подходит лучше всего другого. Названный мной в примере расходный ордер - совершенно реальный, бумажный документ, выступающий в роли такого асинхронного сообщения.

Я не имел ввиду, что всегда лучше. Я упомянул в связи с термином "асинхронный". Ну и считаю, что если использовать для задач фичи СУБД, то плюс в том, что в решении СУБД берет на себя многое. В частности, ожидаю, что такое решение надежней, легче разрабытывать и сопровождать, оно лучше масштабируется. Ну в общем много хорошего там должно быть.

softwarer
Хм. Если не ошибаюсь, из текста выпал кусок про работу на одном сервере. Что я бы не назвал вынужденным ухищрением по сравнению с репликацией, скорее наоборот :)

А "ручную" репликацию по сравнению со штатной?

softwarer
Вадим, Вы стягиваете к оракловым схемам там, где я говорю о репликации вообще.

Стараюсь Оркл использовать тока как поясняющий пример. Во-первых, знаю что Вы Ораклист. Во-вторых его репликации согласуются с литературой более или менее.


softwarer
Насколько я помню (могу ошибаться) оракловая репликация не слишком-то гибка в плане возможной логики работы с данными; можно нарисовать логику репликации, которую в оракле просто не реализуешь.


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

softwarer
Я нарисовал схему решения некоторой конкретной, поставленной Вами задачи. Если она "неравноправна" - тем хуже для равноправной, вот и все.


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

softwarer
И это все верно про нарисованное мной с расходными ордерами. И без хранимок, и равные права. Все можно делать.

Возможно. Но если бы получилась равноправная было бы не полохо, хотя бы по стилю. Мы знали бы где находимся. Вы говорите равноправная - сразу известно что это, что при этом происходит и все такое. Говорите синхронная или асинхронная - ясно как оно происходит и какие могут быть при этом траблы. А Ваше решение еще нуно исследовать. Есть разница? Как Вы думаете?

softwarer
Хм. Скажем так, это фраза из той же оперы, что "программист что-нибудь разработает, а админ пусть тюнит под это БД". Неконструктивная постановка вопроса.


Я имел в виду сложности разработки и сопровождения. Т.е. не тока конечные юзера критерий выбора решения. Они и про БД ниче не знать могут и про СУБД.
Мы же не откажемся из-за этого от СУБД? Не скажеи какая разница - юзеру вроде все равно. Бум как ЧАЛ файловые системы лабать. Но не все равно проггерам и админам, а через это в конечном счете и конечному юзеру.
Он будет просить что-то поменять, а это сложнее. Дольше или вообще проггеры начнут отмазываться. А в штатной может тока гайку повернул и готово. Я по крайней мере на это расчитываю. А если проггер знает что два сервера, программирует с учетом этого, то это дополнительная нагрузка.
Админу поневоле нуно знать, что их два в любом случае, нето доиграется.

softwarer
Могу снова назвать случай, недавно вызвавший бурю эмоций на мою голову :) Несколько лет назад было так: некий программист написал примерно следующий job:
.


Видел такое. Кстати, вот и пример. Такое один написал - репликация должна качать инкременто, а инкремент несусветный. Он там в цикле тучу транзакций нагерил, хотя они ниче не меняют. Но репликация штатная. Ее легко проверить. Поэтому на проверку своих решений времени тратить совсем не надо было. А так поди разбери почему с Кольского полуострова суточные данные в Москву качаются час вместо 5 минут. Правда тогда мне были доступны удаленно оба сервака. Но все равно - экономия усилий по поиску причин.

softwarer
В результате несколько ночей по репликации катались толпы.. малоосмысленных изменений. Вот и расскажите, пожалуйста, про "прозрачность" и "ниче не хотим знать".

Прозрачность для админа проблема. Чем прозрачнее, тем труднее.
Но проггеры могут ничего не хотеть знать по возможности про репликацию. Особенно када занимаются логикой. Не потому что они плохие, а потому что это все-таки что-то больше для физических аспектов. Я имел в виду максимальное снижение влияния наличия задач репликации на логику основной работы системы.

softwarer
В результате несколько ночей по репликации катались толпы.. малоосмысленных изменений. Вот и расскажите, пожалуйста, про "прозрачность" и "ниче не хотим знать".

Прозрачность для админа проблема. Чем прозрачнее, тем труднее.
Но проггеры могут ничего не хотеть знать по возможности про репликацию. Особенно када занимаются логикой. Не потому что они плохие, а потому что это что-то левое. Я имел в виду максимальное снижение влияния наличия задач репликации на логику основной работы системы.


softwarer
Я упомянул хранимку как один из возможных путей лечения проблемы асинхронности. При этом эта хранимка никуда не лазит и ничего не реплицирует; она работает на локальном сервере. Репликация - стандартная либо нет, неважно - таскает ее данные туда-сюда, стандартной логикой.


Я имел в виду, противопоставление штатной репликации, процедурам написанным прогерром для тех же целей и соответствующей реализацией.
Т.е. я считаю это важным. Логика может и похожа, но реализация разная.
Конечно, может кто-то и налобает на низком уровне захват транзакций, помещение их в очередь, а потом распространение на другие серваки и выполнение их там, как будто их там запустили. Но чаще он просто налабает логи изменений, записывыть туда измененнгия и читать эти журналы удаленно другими сервакми. Так кастати, реализована и стандартная репликация Ведущий- Ведомый в Оракле. Но Мультимастер так как мало кто налабает, а может таких спосов и нет. Не уверен. Не даром она тока в Интерпрайз Эдишон.
А Вы говорите стандартная логика. У СУБД тоже стандартная логика. Что же нам теперь ее функционал (например, механизм транзакций) с помощью хранимок реализовывать?