Re: Using RSYNC for replication?

Well this email is for everyone:

1) I don't want to PG dump because of 1) the time and 2) the space. If I
did it that way, I might as well keep the old copy around and run diff
on that, and ship that over the wire. Since this DB can get quie large,
I'd rather not have to have the binary copy AND the bigger text copy
around.

2)I can assure myself that there are no existing open transactions.
Also, this is the reason why I'd lock all the tables. My call for locks
would block until all other transactions were complete, ensuring I get a
consistant copy.

I'm trying to do this from a user-invoked script where the user knows
nothing about starting/stoping services. Also, as things currently are,
we can get the modified/added records from our database and ship those
over the wire. As things are now, between script invocations, there's
only 5-15k byte differences. If we were to dump a lot more, our current
remote sites would get upset. Most of these remote sites are via modem.

Thanks for th einput so far. Keep it coming!

Lincoln Yeoh wrote:
> What about existing open transactions during the sync?
>
> Link.
>
> At 11:56 PM 1/27/03 -0500, Jason Hihn wrote:
>
>> In general, data is only added to a few tables in the database, with
>> updates occuring infrequently to the rest. Rarely are deletes ever
>> done. During the sync neither DB will change except as part of the
>> rsync.
>>
>> I think this would be a quick, dirty, safe and efficient way to
>> accomplish this without having to take down postmaster and send the
>> whole shebang over.
>>
>> Are people using this? Will it work? Is it feasible? Thoughts?
>>
>> Many thanks in advance,
>> -Jason
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>