Re: Replication and on-line recovery - Mailing list pgsql-general
From | Justin Clift |
---|---|
Subject | Re: Replication and on-line recovery |
Date | |
Msg-id | 3AE40793.3CBFDCF@postgresql.org Whole thread Raw |
In response to | Re: full text searching ("Thomas T. Thai" <tom@minnesota.com>) |
List | pgsql-general |
Hi Gordan, Whilst probably not really useful just yet, (as I presently know very little about replication, but I'm learning), I have just begun writing up my initial attempts with rserv and Usogres (another PostgreSQL replication approach). techdocs.postgresql.org/installguides.html#replication If you get it all setup and working in good order, can you write up a guide on doing it, as I haven't found anything "out there" about it, which is why I'm starting? :-) Regards and best wishes, Justin Clift Gordan Bobic wrote: > > Hi! > > I will be setting up a 3-way replicated server setup over the next > week or two, so this is probably a good time to make sure I know > exactly what I'm in for. To my knowledge, rserv is the only currently > available replication server for Postgres - is that correct? > > 1) Is there a way to designate 1 server as master, and do transparent > clustering by just connecting to that one server? Or does the > clustering have to be handled on the client end by making a connection > to each server and doing a "round-robin" for picking the server for > each query (multi-threaded application)? > > 2) If a server fails, how can it be resynchronised with the rest of > the cluster? I am asuming that inserts all have to be channeled > through the same server, in order to avoid race conditions. Is this > correct? If a server fails, and inserts are constantly being made, > then I am guessing that a dump/restore will not work properly if the > master (insert) server is not taken off-line and inserts are stopped. > Is this the case? How can this be done without taking the master > server off-line? Taking any server off line would take it out of sync, > so just doing a restore from another secondary server would then > result in two servers being out of sync. How is this worked around? > > 3) I know this has been asked before, and I've managed to get a few > responses about how to implement a quick and useable solution to this, > but I seem to have misplaced the emails, so please forgive me for > asking this again. > > Is it possible to run Linux + Mosix + GFS to achieve the functionality > of a truly distributed database system? The bandwidth of communication > between the servers is not a huge problem, because I have the option > of connecting them either in a "star" configuration with 100 Mb > ethernet, connect them to a switch, or use a fiber link between them. > I've been told that "postmaster" won't get migrated properly due to > IPC and shared memory issues. Can anyone suggest a work-around? DIPC, > perhaps? I can't see how to work around the shared memory, though... > > I know Oracle has a full distributed clustering support, but I have > made a decision to stick with open source software all the way (plus > the cost of running Oracle on a commercial setup is quite > prohibitive). > > Still, even if the answer to the fully distributed database question > here is still just big, fat, flat "NO!", I'd really appreciate some > input regarding failure recovery and insert handling on a replicated > database cluster. > > Regards. > > Gordan > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
pgsql-general by date: