pgsql: Remove replicaiton FAQ item.

On Sunday 14 November 2004 16:33, Bruce Momjian wrote:

Log Message:
-----------
Remove replicaiton FAQ item.

Modified Files:
--------------
pgsql/doc:
FAQ (r1.269 -> r1.270)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/FAQ.diff?r1=1.269&r2=
1.270) pgsql/doc/src/FAQ:
FAQ.html (r1.227 -> r1.228)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/FAQ/FAQ.html.diff
?r1=1.227&r2=1.228)

While the answer may have been a little dated, this still seems to be an FAQ.
Was there a discussion on removing this? If so I'll go read that, but ISTM
this question should remain.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Tue, 16 Nov 2004, Robert Treat wrote:

On Sunday 14 November 2004 16:33, Bruce Momjian wrote:

Log Message:
-----------
Remove replicaiton FAQ item.

Modified Files:
--------------
pgsql/doc:
FAQ (r1.269 -> r1.270)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/FAQ.diff?r1=1.269&r2=
1.270) pgsql/doc/src/FAQ:
FAQ.html (r1.227 -> r1.228)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/FAQ/FAQ.html.diff
?r1=1.227&r2=1.228)

While the answer may have been a little dated, this still seems to be an FAQ.
Was there a discussion on removing this? If so I'll go read that, but ISTM
this question should remain.

agreed, this definitly does fall under a "Very FAQ" kinda thing ...
pointers to the various methods that are currently in use, at a minimum,
would be good ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

I am thinking of adding a replication section to the main docs rather
than have it in the FAQ. It would be part of the external
tools/interfaces section I want to add to 8.0 (during our RC period).

---------------------------------------------------------------------------

Marc G. Fournier wrote:

On Tue, 16 Nov 2004, Robert Treat wrote:

On Sunday 14 November 2004 16:33, Bruce Momjian wrote:

Log Message:
-----------
Remove replicaiton FAQ item.

Modified Files:
--------------
pgsql/doc:
FAQ (r1.269 -> r1.270)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/FAQ.diff?r1=1.269&r2=
1.270) pgsql/doc/src/FAQ:
FAQ.html (r1.227 -> r1.228)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/FAQ/FAQ.html.diff
?r1=1.227&r2=1.228)

While the answer may have been a little dated, this still seems to be an FAQ.
Was there a discussion on removing this? If so I'll go read that, but ISTM
this question should remain.

agreed, this definitly does fall under a "Very FAQ" kinda thing ...
pointers to the various methods that are currently in use, at a minimum,
would be good ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Wed, 1 Dec 2004, Bruce Momjian wrote:

I am thinking of adding a replication section to the main docs rather
than have it in the FAQ. It would be part of the external
tools/interfaces section I want to add to 8.0 (during our RC period).

Even then, a FAQ entry should be added to point to that section ... IMHO
...

---------------------------------------------------------------------------

Marc G. Fournier wrote:

On Tue, 16 Nov 2004, Robert Treat wrote:

On Sunday 14 November 2004 16:33, Bruce Momjian wrote:

Log Message:
-----------
Remove replicaiton FAQ item.

Modified Files:
--------------
pgsql/doc:
FAQ (r1.269 -> r1.270)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/FAQ.diff?r1=1.269&r2=
1.270) pgsql/doc/src/FAQ:
FAQ.html (r1.227 -> r1.228)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/FAQ/FAQ.html.diff
?r1=1.227&r2=1.228)

While the answer may have been a little dated, this still seems to be an FAQ.
Was there a discussion on removing this? If so I'll go read that, but ISTM
this question should remain.

agreed, this definitly does fall under a "Very FAQ" kinda thing ...
pointers to the various methods that are currently in use, at a minimum,
would be good ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

-- 
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 359-1001
+  If your life is a hard drive,     |  13 Roberts Road
+  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:

On Wed, 1 Dec 2004, Bruce Momjian wrote:

I am thinking of adding a replication section to the main docs rather
than have it in the FAQ. It would be part of the external
tools/interfaces section I want to add to 8.0 (during our RC period).

Even then, a FAQ entry should be added to point to that section ... IMHO
...

Yes, once the section is done we can point to it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Marc G. Fournier wrote:

On Tue, 16 Nov 2004, Robert Treat wrote:

On Sunday 14 November 2004 16:33, Bruce Momjian wrote:

Log Message:
-----------
Remove replicaiton FAQ item.

Modified Files:
--------------
pgsql/doc:
FAQ (r1.269 -> r1.270)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/FAQ.diff?r1=1.269&r2=
1.270) pgsql/doc/src/FAQ:
FAQ.html (r1.227 -> r1.228)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/FAQ/FAQ.html.diff
?r1=1.227&r2=1.228)

While the answer may have been a little dated, this still seems to be an FAQ.
Was there a discussion on removing this? If so I'll go read that, but ISTM
this question should remain.

agreed, this definitly does fall under a "Very FAQ" kinda thing ...
pointers to the various methods that are currently in use, at a minimum,
would be good ...

Yep, big mistake my removing the replication FAQ item. I have re-added a
new one:

4.21) What replication solutions are available?

Though "replication" is a single term, there are two major replication
technologies. Multi-master replication allows read/write queries to be
sent to multiple replicated computers. Using this capability has a
serious performance impact. Pgcluster is the most popular such solution
available for PostgreSQL. Master-slave replication allows a single
master to receive read/write queries, with slaves able to accept only
read/SELECT queries. The most popular master-slave PostgreSQL
replication solution is Slony. There are also commercial and
hardware-based replication solutions available.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Martha Stewart called it a Good Thing when pgman@candle.pha.pa.us (Bruce Momjian) wrote:

Yep, big mistake my removing the replication FAQ item. I have re-added a
new one:

4.21) What replication solutions are available?

Though "replication" is a single term, there are two major replication
technologies. Multi-master replication allows read/write queries to be
sent to multiple replicated computers. Using this capability has a
serious performance impact. Pgcluster is the most popular such solution
available for PostgreSQL. Master-slave replication allows a single
master to receive read/write queries, with slaves able to accept only
read/SELECT queries. The most popular master-slave PostgreSQL
replication solution is Slony. There are also commercial and
hardware-based replication solutions available.

A suggestion for rewording:

Though "replication" is a single term, there are a number of
approaches and technologies to handle it, and thus, for different
purposes, a number of replication systems are available.

Master/slave replication allows a single master to receive read/write
queries, where slaves can only accept read/SELECT queries. The most
popular freely available master-slave PostgreSQL replication solution
is Slony-I.

Multi-master replication allows read/write queries to be sent to
multiple replicated computers. Using this capability generaly has a
fairly severe impact on performance due to the need to synchronize
changes between servers. Pgcluster is the most popular such solution
freely available for PostgreSQL.

There are also commercial and hardware-based replication solutions
available supporting a variety of replication models.
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://linuxdatabases.info/info/slony.html
"It can be shown that for any nutty theory, beyond-the-fringe
political view or strange religion there exists a proponent on the
Net. The proof is left as an exercise for your kill-file."
-- Bertil Jonell

Should the text include a mention of synchronous vs. asynchronous? Or
does master-master imply synchronous?

Regards,
Jeff Davis

Jeff Davis wrote:

Should the text include a mention of synchronous vs. asynchronous? Or
does master-master imply synchronous?

It shouldn't. It is possible to have synchronous replication without it
being master<->master.

Sincerely,

Joshua D. Drake

Joshua D. Drake wrote:

Jeff Davis wrote:

Should the text include a mention of synchronous vs. asynchronous? Or
does master-master imply synchronous?

It shouldn't. It is possible to have synchronous replication without it
being master<->master.

We could mention async vs sync but at the FAQ stage I think the
multi-master/master-slave disinction is enough. Let's see what questions
we get.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Quoting Bruce Momjian <pgman@candle.pha.pa.us>:

Joshua D. Drake wrote:

Jeff Davis wrote:

Should the text include a mention of synchronous vs.

asynchronous? Or

does master-master imply synchronous?

It shouldn't. It is possible to have synchronous replication

without it

being master<->master.

We could mention async vs sync but at the FAQ stage I think the
multi-master/master-slave disinction is enough. Let's see what
questions
we get.

About all you can say is, it is not possible to implement synchronous
master-master replication, because of conflict resolution of
simultaneous transactions.
--
"Dreams come true, not free." -- S.Sondheim, ITW

Mischa Sandberg wrote:

Quoting Bruce Momjian <pgman@candle.pha.pa.us>:

Joshua D. Drake wrote:

Jeff Davis wrote:

Should the text include a mention of synchronous vs.

asynchronous? Or

does master-master imply synchronous?

It shouldn't. It is possible to have synchronous replication

without it

being master<->master.

We could mention async vs sync but at the FAQ stage I think the
multi-master/master-slave disinction is enough. Let's see what
questions
we get.

About all you can say is, it is not possible to implement synchronous
master-master replication, because of conflict resolution of
simultaneous transactions.

You mean asynchronous master-master? There are some implementations
(Sybase?, pgreplicator) that do this and have conflict resolution.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Quoting Bruce Momjian <pgman@candle.pha.pa.us>:

Mischa Sandberg wrote:

About all you can say is, it is not possible to implement

synchronous

master-master replication, because of conflict resolution of
simultaneous transactions.

You mean asynchronous master-master? There are some implementations
(Sybase?, pgreplicator) that do this and have conflict resolution.

Forgive my kibitz, then; perhaps my head has been stuck in sand a
while. You're right, I forgot about the nicer bits of Sybase
RepServer. Synchronous replication was scratched early in the project,
because two-phase commit took too long across a dozen db servers.

Pgreplicator advertises itself as a "store-and-forward asynch replica
(sic) engine." (quoth http://pgreplicator.sourceforge.net/ )
--
"Dreams come true, not free." -- S.Sondheim, ITW

OK, updated:

<P>Though "replication" is a single term, there are several technologies
for doing replication, with advantages and disadvantages for each.</P>

<P>Master/slave replication allows a single master to receive read/write
queries, while slaves can only accept read/<SMALL>SELECT</SMALL> queries.
The most popular freely available master-slave PostgreSQL replication
solution is <A href="http://gborg.postgresql.org/project/slony1/projdisplay$
Slony-I</A>.</P>

<P>Multi-master replication allows read/write queries to be sent to
multiple replicated computers. This capability also has a severe
impact on performance due to the need to synchronize changes between
servers. <A href="http://pgfoundry.org/projects/pgcluster/&quot;&gt;Pgcluster&lt;/a&gt;
is the most popular such solution freely available for PostgreSQL.</P>

<P>There are also commercial and hardware-based replication solutions
available supporting a variety of replication models.</P>

---------------------------------------------------------------------------

Christopher Browne wrote:

Martha Stewart called it a Good Thing when pgman@candle.pha.pa.us (Bruce Momjian) wrote:

Yep, big mistake my removing the replication FAQ item. I have re-added a
new one:

4.21) What replication solutions are available?

Though "replication" is a single term, there are two major replication
technologies. Multi-master replication allows read/write queries to be
sent to multiple replicated computers. Using this capability has a
serious performance impact. Pgcluster is the most popular such solution
available for PostgreSQL. Master-slave replication allows a single
master to receive read/write queries, with slaves able to accept only
read/SELECT queries. The most popular master-slave PostgreSQL
replication solution is Slony. There are also commercial and
hardware-based replication solutions available.

A suggestion for rewording:

Though "replication" is a single term, there are a number of
approaches and technologies to handle it, and thus, for different
purposes, a number of replication systems are available.

Master/slave replication allows a single master to receive read/write
queries, where slaves can only accept read/SELECT queries. The most
popular freely available master-slave PostgreSQL replication solution
is Slony-I.

Multi-master replication allows read/write queries to be sent to
multiple replicated computers. Using this capability generaly has a
fairly severe impact on performance due to the need to synchronize
changes between servers. Pgcluster is the most popular such solution
freely available for PostgreSQL.

There are also commercial and hardware-based replication solutions
available supporting a variety of replication models.
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://linuxdatabases.info/info/slony.html
"It can be shown that for any nutty theory, beyond-the-fringe
political view or strange religion there exists a proponent on the
Net. The proof is left as an exercise for your kill-file."
-- Bertil Jonell

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073