Re: Replication
От | Brian Bruns |
---|---|
Тема | Re: Replication |
Дата | |
Msg-id | Pine.LNX.4.33.0202081904190.18420-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Replication (Randall Jonasz <rjonasz@trueimpact.com>) |
Список | pgsql-hackers |
> > I have in the back of my mind, an idea of patching into the WAL stuff, and > > using that mechanism to push changes out to the slaves. > > > > Where one machine is still the master, but no trigger stuff, just a WAL patch. > > Perhaps some shared memory paradigm to manage WAL visibility? I'm not sure > > exactly, the idea hasn't completely formed yet. > > FWIW, Sybase Replication Server does just such a thing. They have a secondary log marker (prevents the log from truncating past the oldest unreplicated transaction). A thread within the system called the "rep agent" (but it use to be a separate process call the LTM), reads the log and forwards it to the rep server, once the rep server has the whole transaction and it is written to a stable device (aka synced to disk) the rep server responds to the LTM telling him it's OK to move the log marker forward. Anyway, once the replication server proper has the transaction it uses a publish/subscribe methodology to see who wants get the update. Bidirectional replication is done by making two oneway replications. The whole thing is table based, it marks the tables as replicated or not in the database to save the trip to the repserver on un replicated tables. Plus you can take parts of a database (replicate all rows where the country is "us" to this server and all the rows with "uk" to that server). Or opposite you can roll up smaller regional databases to bigger ones, it's very flexible. Cheers, Brian
В списке pgsql-hackers по дате отправления: