Re: Replication
От | F Harvell |
---|---|
Тема | Re: Replication |
Дата | |
Msg-id | 200202072235.g17MZhR17707@odin.fts.net обсуждение исходный текст |
Ответ на | Re: Replication (mlw <markw@mohawksoft.com>) |
Список | pgsql-hackers |
I'm not that familiar with the whole replication issues in PostgreSQL, however, I would be partial to replication that was based upon the playback of the (a?) journal file. (I believe that the WAL is a journal file.) By being based upon a journal file, it would be possible to accomplish two significant items. First, it would be possible to "restore" a database to an exact state just before a failure. Most commercial databases provide the ability to do this. Banks, etc. log the journal files directly to tape to provide a complete transaction history such that they can rebuild their database from any given snapshot. (Note that the journal file needs to be "editable" as a failure may be "delete from x" with a missing where clause.) This leads directly into the second advantage, the ability to have a replicated database operating anywhere, over any connection on any server. Speed of writes would not be a factor. In essence, as long as the replicated database had a snapshot of the database and then was provided with all journal files since the snapshot, it would be possible to build a current database. If the replicant got behind in the processing, it would catch up when things slowed down. In my opionion, the first advantage is in many ways most important. Replication becomes simply the restoration of the database in realtime on a second server. The "replication" task becomes the definition of a protocol for distributing the journal file. At least one major database vendor does replication (shadowing) in exactly this mannor. Maybe I'm all wet and the journal file and journal playback already exists. If so, IMHO, basing replication off of this would be the right direction. On Thu, 07 Feb 2002 07:52:23 EST, mlw wrote: > > 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. >
В списке pgsql-hackers по дате отправления: