Thanks for the reply. This is a one way push to the slaves. In theory, there shouldn't be any conflicts .... although I wouldn't swear to that. If there's a conflict, the master db should win. At the moment we just drop the tables, recreate the schema and reload the tables. However, some of the large tables literally take hours across the network, for maybe a few dozen changes.
On Wed, Sep 23, 2009 at 4:58 PM, Scott Marlowe
<scott.marlowe@gmail.com> wrote:
On Wed, Sep 23, 2009 at 11:11 AM, Bryan Montgomery <
monty@english.net> wrote:
> Hi,
> I'm looking for a way to replicate am master database to multiple (100+)
> databases that are taken in to the field. Currently for each laptop we dump
> and load the tables. However,there is only a small percentage of data that
> changes on a frequent basis.
>
> I've been looking around and come across pyerplica, londiste and bucardo -
> the documentation on most of these is fairly sparse. It seems that Bucardo
> may be the best bet - at least initially.
>
> However, I thought I'd see if anyone is doing something similar and what
> thoughts there might be out there as to a better way to accomplish this.
replication. Most replication solutions are made to keep two machines
that talk to each other all the time in sync. Disconnect one machine
and maybe replication will resume properly, and maybe it wont.
So, do you need the slave databases to be updatable? Do you need the
changes to go back into the master? Do you need conflict resolution?
Depending on the full fleshed out requirements, you may be stuck
writing your own solution, or re-writing one somebody already wrote.