собсна интересно все. положительный и не очень опыт, успехи и достижения, софт и все остальное. лично мой опыт, а я занимался этим вопросом с пол года назад, говорит что это unreal
Беру свои слова обратно. Раз это все используется адским количеством людей, может и у меня не так все безнадежно. Сразу говорю, я больше по программированию, а в субд лишь постольку- поскольку. Ситуация такая: В 12-ти городах расположены 12 филиалов нашей организации. У каждого филиала стоит свой сервак Postgres+PHP. Требуется синхронизировать базы хотя бы каждые 10 минут. в базах, естественно первичные ключи, внешние ключии, последовательности, уникальные индексы и гигабайты ладж обжектов. Все это в таблицах, которые должны синхронизироваться. Удалений в базе вообще не бывает. В одной таблице случаются изменения, в остальных только инсерты. Ладж обжекты тоже не удаляются. Раз в месяц случаются изменения схемы. Это и создания таблиц и добавления колонок с сопутствующими новыми внешними ключами. 100% зеркальности никто не требует, но надо чтобы схема работала надежно и не падала. То есть если пара документов не дойдет до филиалов, это не страшно, главное тут чтобы один раз настроил и забыл. Каскадности тоже не требуется. Что тут можно посоветовать?
Забыл сказать, что триггеров вообще нет. Но есть виды, которые тоже пересоздаются и должны реплицироваться.
Т.е. запись идет в каждый сервер? Понял, это асинхронный мультимастер. Решений из коробки тут быть не может, так как решение конфликтов данных - дело зависимое от структуры этих данных. По-этому никто особо и не парится созданием онного. Двигаться советую в изучение утилит от скайпа и написании своей репликации на основе их очереди и т.д. https://developer.skype.com/SkypeGarage ... s/SkyTools Конкретнее не подскажу, лично с такими задачами не сталкивался. Может как-то можно и слони подкрутить, но коробка работать не будет - надо понимать. Так как все эти виды репликации работают на тригерах - большой простор для своего решения. С таблицами где тока инсерты все просто - нужно только сиквенсы настроить так, что бы а ID не пересекались... или же вообще не использовать сиквенс как праймари ключ, а делать его составным где второе поле - ID ноды. А вот там, где апдейты - тут нужно писать руками разрешение конфликтов. Если в 2-х базах поменяли одно и то же поле - что делать? Никто, кроме человека тут решить не сможет.
есть ли какие нибудь методы, как мультимастер немного покоцав превратить в матсер- слейв и при этом оставить синхронизацию баз? нас устраивает любой вариант, лишь бы он был предсказуемым. Например кто последний тот и прав, или у какой ноды "рейтинг" выше, тот и прав или где объект создавался, тот и прав или любой другой предсказуемый способ. Ищем готовое решение, чтобы установить и все заработало. Писать свое - все равно что запускать новый проект, надо изучать, сравнивать, учиться и, конечно, писать и это все затянется на годы. На это нет сил.
Пардон, но с такой мотивацией просто покупают оракл. Выбирая постгре или мускул надо быть готовым, что прийдется много-много-много-много пилить руками.
должно что-то быть. я когда-то думал, что для того чтобы сделать нормальные отчеты в эксель придется купить ASP.NET + MSOffise для COM- сервера и Visual Studio для программирования. А потом оказалось что есть простое решение PHPExcel.
Мы же не Америку открываем, репликация сто лет существует. должно что-то быть. Мне мега ньюансы не нужны, согласен на любую предсказуемую систему.
а не думали поставить ОДИН серва для всех? если будет репликация - то однозначно все в инете. собрать решение доступное для всех, но ОДНО. ну или по крайне мене один фронт для всех?
Коробки не будет. Не уверен, что коробка для асинхронного мультимастера есть и в Оракле. Есть разные решения разной степени глючности и сложности реализации, например http://opensource.replicator.daffodilsw.com/ http://bucardo.org/ Но без рук тут никак. Асинхронный мастер-слейв сделать не проблема, но в слейвы нельзя писать - писать нужно только в мастер. Тут слони подходит вполне. Третье решение - синхронный мультимастер. Можно писать в любую ноду, но медленно и нужна хорошая связь между нодами. Любой провал интернета - и нода выбывает из игры. В общем, для распределенных контор не очень хороший вариант. Скажите, а насколько важна скорость обновления нод? Можнет просто обойтись локальными серверами и неким софтом, который опрашивает все сервера, собирает изменения и рассылает их обратно.
Очень плохо, когда, например, торговая точка перестает работать только потому, что интернет кончился =)
тогда надо все делать с учетом того, что не все точки доступны и готовить данные. а так написать скрптик который бы сливал все на мастер и заливан на ноды да и все. аппаратная или софтовая стандартная реализация 100% не покатит. ручками... ручками...
Скажите, у вас по какому принципу должны данные обновлятся? Кто последний тот и прав или есть ещё приоритеты, типа "Нода Х приоритетнее других изменений, ибо начальство!" ? У меня есть мысль, но мне нужно знать условия что бы внятно описать вам возможное решение.
такой софт будет в самый раз. в этом практически и есть весь вопрос. подскажите где такой софт почитать. Ну не очень важна скорость. хотелось бы чтобы не реже 10 мин. но если иногда будет больше, тоже переживем. Летать будут объекты такие как учетки, инвентарки, люди, акты и прикрепленные ко всем ним файлы. Никаких рублей. Если по дороге что-то потеряться- тоже ничего страшного. Тут во-первых не часто такое будет, потому что каждый будет править больше свой кусок данных по своему филиалу, а, во-вторых, даже 10% объектов общую картину слабо меняют. 2Psih устраивает вообще любой предсказуемый вариант, т.е. который можно написать на бумаге, утвердить, и потом база по нему всегда и будет работать. PS: Postgres не очень для репликации. Lotus и его современные клоны вроде CouchDB умеют такие вещи из коробки. Кто- нибудь CouchDB руками щупал может что-нибудь из практического опыта про нее сказать?
alexey_baranov Тогда могу предложить сделать следующее: Настроить на всех серверах автоматическую коррекцию времени по ntp. При обновлении данных не удалять или обновлять старое, а записывать новую копию c timestamp меткой, и синхронизировать между нодами только те данные, которые новые (т.е. свежие копии). По умолчанию считаем актуальными с самым новым временем модификации. Т.е. по сути получается что-то типа SVN/CVS системы. Потом если надо, туда легко прикручиваются приоритеты, как к примеру изменения от начальства приоритетнее чем изменения данных в каком-то из филиалов. Если как ты говоришь, что реально в основном свои данные меняют только филиалы, то проблем с конфликтами быть не должно. А если они и возникнут - у тебя есть история изменений - можно сделать страницу где можно просмотреть все эти данные и выбрать какие реально будут актуальны. Присвой каждому филиалу/ноде свой ID и добавляй их к данным - будешь знать в каком филиале были сделаны изменения, заодно и и начальство сможет увидить данные отдельно по каждому из филиалов если надо. Обговорите срок хранения старых ревизий данных, скажем минимум пол года либо минимум 10-20 ревизий, если изменений крайне мало и редко. Можно просто скидывать в архив, что бы основные базы не росли слишком. Таким образом по сути можно даже стандартную master-master репликацию делать, т.к. вероятность одинаковых timestamp для одного и того-же объекта есть, но достаточно мала. К тому же если добавите ID филиала, то у вас даже в случае одинаковых ID и timestamp у репликации крыша не съедет, т.к. составной ключ objectid, timestamp, departmentid никогда не пересечётся из-за того, что филиалы разные. Если же вдруг, вот прямо нереальная почти ситуация, когда в одном филиале 2 человека отредактируют одни и те же данные в одну и ту-же секунду и совпадут timestamps - используйте тип с microseconds (насколько я помню в PostgreSQL такой есть). Вот в кратце идея такая.
Psih, как я понял, у человека уже есть система - переделывать ее на новый формат хранения данных в базе... эта писец. А если там какой-нить 1С использующий постгрес как бекенд =) alexey_baranov - писать свое. Это гораздо проще, чем писать репликацию. Берем изменения со всех серверов, объединяем, рассылаем. Например, таблицы где инсерты - читаем со всех серверов новые данные (храним последний ID - что бы найти новые), объединяем, идем по всем серверам делая инсерты этих данных (пропуская данные взятые с текущей ноды). С апдейтами не сложнее - нужно только будет какой-нибудь тригер приделать, что бы ставил в спец поле флажок на апдейте записи. Работы на неделю, в общем =)
Ну не нужно мешать в одну кучу и реляционные базы и объектные да еще и версионные. CouchDB, кстати, все-равно не решает конфликтов - она их просто хранит как версии документов, что позволяет обработать их позже.
MiksIr Мою идею можно просто добавить в уже существующее. Факт в том, что так или иначе ему придётся всё допиливать руками. Так что вполне можно сделать.
Одно дело внешний скрипт, опрашивающий базу.. ну и может несколько тригерочков для удобства поиска новых данных. А другое дело - реализация совершенно другого принципа хранения данных с переписыванием всего софта во всех филиалах для работы с ней. А самое главное - зачем? Что такого даст версионная система хранения данных? От этого конфликты не исчезнут.