>>>котором можно будет это проверить. А вообще, самое простое решение для
>>>репликации (сейчас придумал) -- пересылка бэкапа базы по мейлу, в автоматическом
>>>режиме.
>>Но, вам такого не простят если речь пойдет о приличном заказчикеИли просто при наличии у него грамотных специалистов.
>>нужен продуманный движек с интерфейсом для плагинов под smtp/ftp и
>выгрузка в текстовый файл -> упаковка _> smtp -> распаковка -> зарузка в базу.
>зачем усложнять?
Видите ли.
При помощи SMTP Вы абстрагируетесь от транспорта (включая асинхронную доставку), а взамен выгребаете все проблемы этого самого SMTP: раздувание бинарных данных, пересечение с достаточно сложной и хрупкой на сейчас системой на обоих концах (smtpd+clamav+spamd практически по минимуму) и риск подвергнуть бизнес-операции не относящимся к ним техническим деталям (вроде "антивирь подавился дампом" или "IP попал в RBL").
Меня при виде такого беспечного "зачем усложнять", честно говоря, передёрнуло ещё сильней, чем при виде "нормальный портедж". Поскольку в 2002--2003 прикручивали одну систему доставки мобильного контента к двум местным крупным мобильным операторам. У одного был самопальный, но грамотно сынженеренный XML-RPC. А вот у другого -- под грифом "секретно" или какая там тайна документация на самопальную систему доставки, которая в качестве транспорта использовала... SMTP!
Причём по стилю документации было кристально ясно, что дай этим фи... фидошникам волю, там бы в качестве требований по развёртыванию непременно был T-Mail и на поклон к боссу с пивом.
И как думаете -- не было проблем? Ещё как "не было".
Я это всё к чему.
Не надо мешать мух и котлеты. Почта может применяться как крайний, аварийный, для вырожденных случаев, в которых ничего больше просто не остаётся, случай.
Иначе лучше использовать rsync (возможно, over ssh; эта комбинация умеет и докачку, и компрессию, и шифрование, и аутентификацию с доступом по ключу), HTTP, да хоть XMPP, только не SMTP.
О проблемах с поддержкой Gentoo и портообразных в течение длительных сроков времени тоже есть что сказать (особенно по библиотечной части и прочим стыковкам API), но это не относится к прибитым в продукт вещам обычно. В отличие от транспорта.
>А если канал толстый -- то, лучше всякой репликации --
>общая база данных.
Вы проверяли? Есть мнение, что в таких случаях бывает проще терминальный режим работы того, чего в итоге написывается, чем удалённая база. Вообще исходить из того, что канал толстый, ресурсов дофига, а пользователи не ошибаются -- типичные стартовые ошибки, которых не стоит допускать даже на старте. Поскольку прототипы действительно мало где в итоге переписывают.
Плюс к тому стоит иметь в виду, что каналы бывают толстые, но латентные (особенно спутник или через кудыкины штаты).
>>ЗЫ не понял кстати что значит бэкап базы, может все таки измененных
>>данных подлежащих синхронизации?
>Бэкап базы филиала [дилера], для слияния с основной базой. Ну и, соответсвенно,
>изменения в ценах ассортименте, вообще -- в справочниках -- в другую
>сторону. Это для нашего полигона.
Опять же надеюсь, что Вы заранее видите проблему с масштабируемостью этого подхода без костылей вроде досрочного архивирования базы.