Re: Replication and on-line recovery

From: Justin Clift <justin(at)postgresql(dot)org>
To: Gordan Bobic <gordan(at)freeuk(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Replication and on-line recovery
Date: 2001-04-23 10:44:35
Message-ID: 3AE40793.3CBFDCF@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Richard Huxton 2001-04-23 12:03:50 Re: Re: Cursors in plpgsql
Previous Message Gordan Bobic 2001-04-23 10:38:00 Replication and on-line recovery

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2001-04-23 12:31:47 Re: RFC: planner statistics in 7.2
Previous Message Gordan Bobic 2001-04-23 10:38:00 Replication and on-line recovery