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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Summary of new configuration file and data directory locations
Следующее
От: Andrew McMillan
Дата:
Сообщение: Re: Database abstration layers