Рыжий КотЭто фраза гипотетическая или реклама своей разработки? :)
Я, кажется, сказал "есть". Если угодно, считайте рекламой - хотя я в данном случае не имел этого в виду.

Рыжий КотОн потратил больше года на отладку и вылавливание багов.
Это странно. Развитие - согласен, а вот персонально на отладку - многовато. Хотя, безусловно, это вопрос того, что он туда заложил.

Рыжий КотНо тем не менее, я уверен, что его репликация будет уступать ASA.
Вполне возможно. Никто не предлагает меряться репликациями - скажем, для поставленной задачи моей разработки хватит процентов на 500. И если возможностей ASA хватит на 1500% - так ли это важно?

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

P.S. На всякий случай уточню, что под "Есть вопросы" я не имею в виду "есть проблемы" - я имею в виду "не знаем, как делать".

arniУважаемые Softwarer и ASCRUS действительно полагают, что 100 тыс. записей на таблицу, а хоть бы и миллион, а хоть бы этих таблиц и с полсотни - это сложная задача для IB/FB?
Я знаю как факт утверждение человека, в компетентности которого уверен: для баз больше полугига лучше выбирать что-то помощнее интербейза. Разумеется, как любое общее утверждение, оно применимо с оговорками, однако в данном случае (нулевой стартовый уровень) игнорировать его было бы неразумно.

arniКогда я встречаю при описании сложности задачи "n таблиц в сумме составляющих m Mb/Gb" я могу с уверенностью прикинуть лишь одно: время полного фетча

Несложные селекты с подключением пары-тройки справочных таблиц

Где признаки того, что решение задачи выйдет за эти элеменарные требования? С нулем-то опытом разработчиков?
Я бы спросил - где признаки того, что не выйдет?

Понятно, что с тупым хранением справится любая БД. Однако баз, суть которых в тупом хранении, я видел очень мало. Зато явно указаны как минимум зачатки аналитики - а из зачатков регулярно вырастают вполне серьезные требования. Аппетиты заказчиков растут много быстрее умений разработчиков.

Давайте тогда уж и я отвечу.

Рыжий КотУ вас репликация между 2 машинами? или между 10? а каждая вторая из этих 10 несет еще постолько же подчиненных узлов?
В принципе - произвольный граф. Связный, разумеется ;) Но желательна "снежинка", поскольку иначе здорово повышается вероятность коллизий. Простой пример проблем при наличии альтернативных путей - если на сервере A создана запись, на сервере B она изменена - в силу каких-то причин это изменение может приехать на сервер C раньше, чем (другим путем) туда приедет оригинальная запись с A.

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

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

Транспортная программа передает эти пакеты транспортной программе, работающей с другими серверами. Данные упаковываются и передаются по ftp (предусмотрено легкое подключение чего угодно). На другой стороне данные принимаются и кладутся на сервер. Серверный код выполняет изменения и при необходимости передает их дальше (своим линкам).

Все обвешано возможностью подключать дополнительный код - типа "обработчиков событий". В частности, есть возможность реализовать что-то типа instead of; то есть вместо собственно инсерта пришедших данных выполняется заданный код с этими данными. Код в принципе произвольный; так, реализована куча механизмов типа "отклика", например, пинговалка, которая используется для проверки живости всего процесса.

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

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

Транспортные программы - сообщают об ошибках (я использую smtp).

В серверную часть входят несколько подпрограмм контроля данных и профилактики; они также пишут письма администратору при обнаружении проблем.

Рыжий Котправда вы храните в базе еще таблицу с изменениями,
по какому принципу опустошается она?
Хм. Не совсем уверен, что понял вопрос. Скажем так, после обработки данные "удаляются", хранятся какое-то время в "удаленном" виде (нужно в основном для администрирования - просмотр истории по записям, анализ статистики итп), после чего purge-атся по времени.

Рыжий КотASA использует для всех этих целей transaction log, в базу ничего лишнего не пишется.
Я обдумываю этот вариант, но пока не готов его реализовать. "Извне" трудно делать такие решения ;)

Рыжий Котнужно добавить во все базы, участвующие в реплике, новый код, или поля или раздать права. что вы в этом случае делаете?
Да в общем-то ничего.

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

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

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

Рыжий Котправда вы храните в базе еще таблицу с изменениями,
по какому принципу опустошается она?
Хм. Не совсем уверен, что понял вопрос. Скажем так, после обработки данные "удаляются", хранятся какое-то время в "удаленном" виде (нужно в основном для администрирования - просмотр истории по записям, анализ статистики итп), после чего purge-атся по времени.

Рыжий КотASA использует для всех этих целей transaction log, в базу ничего лишнего не пишется.
Я обдумываю этот вариант, но пока не готов его реализовать. "Извне" трудно делать такие решения ;)

Рыжий Котнужно добавить во все базы, участвующие в реплике, новый код, или поля или раздать права. что вы в этом случае делаете?
Да в общем-то ничего.

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

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

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