vadiminfoМожно. Но обычно репликация в распределенной БД - это именно генерация и воспроизводство копий на сайтах.
Это уже ближе :) Генерация копий - не то же, что копии таблиц. В репликации есть интересный момент: в принципе возможна такая ситуация, что ни в какой момент времени данные в любой локальной БД не отражают реальной картины мира (или хотя бы копию таблицы с другого сервера), в то время как ее отражает "распределенная БД".
vadiminfoИ не специально "именно так" делать, а это и есть асинхронность.
Это один из вариантов асинхронности. Проблема, от которой нужно так или иначе защищаться. Но настаивать, что это единственный и принципиальный вариант - имхо неверно. Примерно так же, как настаивать на известной Вам неправильности ораклового serializable.
vadiminfoУ Оракла есть AQ, которая предусматривает асинхронные события
Есть. Но не всегда он подходит лучше всего другого. Названный мной в примере расходный ордер - совершенно реальный, бумажный документ, выступающий в роли такого асинхронного сообщения.
vadiminfoУ Оракла есть оговорка, если не подходят Оракловые репликации, лабайте свою. Т.е. для каких-то задач Ваша, наверное, будет луче. Задачи ить разные есть. Но в типовых случаях все же Оракловые, мне кажутся, более предпочтительными.
Я не очень понимаю логического перехода к этой мысли, хотя она сама по себе правильна.
Напомню: я говорю о том, что не представляю себе ситуации, в которой синхронная репликация будет хорошим (aka "лучше либо не слишком хуже других") решением. Оракловая либо еще какая - не так важно.
vadiminfoА в филиалах, где равноправная, там просто раз в сутки проверяют идентичносить данных на сайтах. Такова жизнь.
Хм. Признаться, мне не очень нравится такая сложность администрирования репликации :)
vadiminfoНо в случае с банками, я думаю, с синхронной, если она будет нормально работать, моно спать спокойно. Все остальное - вынужденное и, возможно даже, не избежное, но ухищрение.
Хм. Если не ошибаюсь, из текста выпал кусок про работу на одном сервере. Что я бы не назвал вынужденным ухищрением по сравнению с репликацией, скорее наоборот :)
vadiminfoВ пропавшем тексте было и про репликацию Ведущий - Ведомый.
Вадим, Вы стягиваете к оракловым схемам там, где я говорю о репликации вообще. Насколько я помню (могу ошибаться) оракловая репликация не слишком-то гибка в плане возможной логики работы с данными; можно нарисовать логику репликации, которую в оракле просто не реализуешь.
vadiminfoНо равноправная не всегда противоречит "работающей БД", а иногда и лучше других этому способствует.
Я нигде и не говорю "всегда".
Я нарисовал схему решения некоторой конкретной, поставленной Вами задачи. Если она "неравноправна" - тем хуже для равноправной, вот и все.
vadiminfoв банках копии счетов, но логически это один и тот же счет (и ничего лишенго - никаких хранимок). Поди плохо? У обоих серваков равные права на работу - типа логически это одна БД.
И это все верно про нарисованное мной с расходными ордерами. И без хранимок, и равные права. Все можно делать.
vadiminfoМы (и проггеры, но не админы) ниче не хотим знать в работе про то, что их два.
Хм. Скажем так, это фраза из той же оперы, что "программист что-нибудь разработает, а админ пусть тюнит под это БД". Неконструктивная постановка вопроса.
Могу снова назвать случай, недавно вызвавший бурю эмоций на мою голову :) Несколько лет назад было так: некий программист написал примерно следующий job:
1.
2.
3.
4.
update SomeTable set flag = 'N';
commit;
update SomeTable set flag = 'Y' where <some almost always true condition>;
commit;
В результате несколько ночей по репликации катались толпы.. малоосмысленных изменений. Вот и расскажите, пожалуйста, про "прозрачность" и "ниче не хотим знать".
vadiminfoСам я отношусь с настороженностью к хранимкам в распределенной БД.
Хм. Фраза звучит так, словно без хранимок с ними проще :)
Распределенная БД - дополнительный фактор сложности. От которого не убежишь, но который можно загнать в приемлимые рамки.
vadiminfoУ нас была раньше "ручная" (с хранимками) репликация. Заменили на штатную Оракловую - распределенность может привносить свое по сравнеию с одной централизованной БД. Поэтому путь с хранимками не кажется безоблачным во всех отношениях. Могут возникать сюрпризы разные в разное время эксплуатации и на разных версиях Оракла. И чаще када не до сюрпризов. Но в общем, как писал выше, в каких-то случаях "ручные" репликации могут оказаться неизбежными.
Честно говоря, мало что понял. Совершенно не понял, как связаны хранимки с репликацией, с ручной репликацией итп.
Я упомянул хранимку как один из возможных путей лечения проблемы асинхронности. При этом эта хранимка никуда не лазит и ничего не реплицирует; она работает на локальном сервере. Репликация - стандартная либо нет, неважно - таскает ее данные туда-сюда, стандартной логикой.
