samum TiGпервой же ссылкой в гугле получаем MySQL 5.0 Reference Manual :: 15 Replication . Даже если там нет таких наворотов как в Oracle Advanced Replication, все равно это штатный механизм, на базе которого можно построить свою репликацию, при необходимости дополнив ее нужными фичами.
А вы про протоколы
Да это можно сказать первое, что я прочитал по теме :))
Штатный механизм обеспечивает только Master/Slave репликацию, т.е. все филиалы пишут на какую-то одну (условно центральную) базу, а читают с одной из реплик (ближайшей, например, из локальной сети).

Чтобы обеспечить то что я хотел бы получить - типа мастер/мастер, мануал рекомендует кластеризацию. Особенности реализации этой самой кластеризации в MySQL несолько... Ну в общем не подходит кластеризация... Там и требования к связи должны быть иными.MultiMaster replication даже в оракле только в EE есть. А вы хотите совсем забесплатно.
Кстати, basic replication (read only mat.views для XE/SE) есть в бесплатном Oracle XE. А поскольку объемы репликации небольшие, то репликация с помощью мат.вью вполне подходящий способ. У XE правда есть ограничение на размер БД, но вполне возможно вам и не нужно больше 4Гб ;)

Kachalov Blazkowicz
Репликация в том или ином виде существует для всех основных вендоров БД. Даже Master2Master. Хотя наверное, кроме SQL Server и Orcale с Master2Master вряд ли кто-то адекватно справляется.
- как то плохо представляется автоматическая двунаправленная репликация в момент установления связи филиала с ЦО, защищенная от сбоев при передаче данных. По моему без внешней логики не обойтись. Хотя конечно я не специалист по соответствующим продуктам (Oracle, MS SQL Server), возможно есть готовые решения, которые стоят дешевле чем разработка самоделок.Хм, если не "защищенная от сбоев при передаче данных" (т.е. возможны потери насколько я вас понял), то какая это нафик вообще репликация ? Да и вообще, думаю несложно и на базе JMS сделать "репликацию с потерями" ;-)

Kachalov TiGДа и вообще, думаю несложно и на базе JMS сделать "репликацию с потерями" ;-)
автор
It is characterized by following :
* Only one consumer will get the message
* The producer does not have to be running at the time the receiver consumes the message, nor does the receiver need to be running at the time the message is sent
* Every message successfully processed is acknowledged by the receiver

Собственно вариант с JMS возник из-за того что автор темы использует Hibernate, от Hibernate логически недалеко до JBoss, а там поддержку JMS реализовать уже несложно :)Вот-вот, все зависит от того как реализовать receiver-а. С потерями ? Лехко
Сосбно все дело в том, что чем больше самописного кода, тем больше вероятность наделать в них граблей. Чего все-таки по возможности следует избегать.
samum Kachalov samumОрганизовать доставку/рассылку не сложно и без JMS с JBoss'ом, было бы что рассылать .
- а что реплицировать есть? :)
Дак вот тема собсно и затевалась, как бы из Hibernate достать то, что надо реплицировать :)
Тут же вполне резонно указали на то, что если кто-то ручками в базе поковыряется, то все, труба :(

Вот кстати по репликам и хиберу нашел такое http://www.jroller.com/Solomon/entry/hibernate_replication_via_xml Я бы все таки рекомендовал реплицировать данные из конечного хранилища, а не отлавливать их где-то посередине. Иначе рано или поздно это может выйти боком.