Re: [PATCHES] Replication Documentation
Hello, Peter Eisentraut wrote: 1. post information on pgsql-general 1.a. solicit comments 2. put information page on web site 3. link from documentation to web site I don't remember such a clear agreement either. I'm glad Chris has written something. And posting it to -docs seems a much better fit, IMHO. Also, I think we didn't really agree on where exactly to put what information. See my previous mail on -hackers for my opinion on that. I don't think this sort of material belongs directly into the PostgreSQL documentation. I agree with that. Regards Markus ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] Replication Documentation
Here's a patch to add in the material on replication recently discussed on pgsql.docs. I'm not thrilled that there were only a few comments made; I'd be happy to see slicing and dicing to see this made more useful. Index: filelist.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/filelist.sgml,v retrieving revision 1.44 diff -c -u -r1.44 filelist.sgml --- filelist.sgml 12 Sep 2005 22:11:38 - 1.44 +++ filelist.sgml 1 Aug 2006 20:00:00 - @@ -44,6 +44,7 @@ !entity configSYSTEM config.sgml !entity user-managSYSTEM user-manag.sgml !entity wal SYSTEM wal.sgml +!entity replication SYSTEM replication.sgml !-- programmer's guide -- !entity dfunc SYSTEM dfunc.sgml Index: postgres.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/postgres.sgml,v retrieving revision 1.77 diff -c -u -r1.77 postgres.sgml --- postgres.sgml 10 Mar 2006 19:10:48 - 1.77 +++ postgres.sgml 1 Aug 2006 20:00:00 - @@ -155,6 +155,7 @@ diskusage; wal; regress; + replication; /part Then add the following as .../doc/src/sgml/replication.sgml !-- $PostgreSQL$ -- chapter id=replication title Replication /title indextermprimaryreplication/primary/indexterm para People frequently ask about what replication options are available for productnamePostgreSQL/productname. Unfortunately, there are so many approaches and models to this that are useful for different purposes that things tend to get confusing. /para para At perhaps the most primitive level, one might use xref linkend=backup tools, whether xref linkend=app-pgdump or xref linkend=continuous-archiving to create additional copies of databases. This emphasisdoesn't/emphasis provide any way to keep the replicas up to date; to bring the state of things to a different point in time requires bringing up another copy. There is no way, with these tools, for updates on a quotemaster/quote system to automatically propagate to the replicas./para sect1 title Categorization of Replication Systems /title para Looking at replication systems, there are a number of ways in which they may be viewed: itemizedlist listitempara Single master versus multimaster./para para That is, whether there is a single database considered quotemaster/quote, where all update operations are required to be submitted, or the alternative, multimaster, where updates may be submitted to any of several databases./para para Multimaster replication is vastly more complex and expensive, because of the need to deal with the possibility of conflicting updates. The simplest example of this is where a replicated database manages inventory; the question is, what happens when requests go to different database nodes requesting a particular piece of inventory?/para para Synchronous multimaster replication introduces the need to distribute locks across the systems, which, in research work done with Postgres-R and Slony-II, has proven to be very expensive. /para/listitem listitempara Synchronous versus asynchronous/para paraSynchronous systems are ones where updates must be accepted on all the databases before they are permitted to commandCOMMIT/command. /para para Asynchronous systems propagate updates to the other databases later. This permits the possibility that one database may have data significantly behind others. Whether or not being behind is acceptable or not will depend on the nature of the application./para para Asynchronous multimaster replication introduces the possibility that conflicting updates will be accepted by multiple nodes, as they don't know, at commandCOMMIT/command time, that the updates conflict. It is then necessary to have some sort of conflict resolution system, which can't really be generalized as a generic database facility. An instance of this that is commonly seen is in the productnamePalmOS HotSync/productname system; the quotegeneral policy/quote when conflicts are noticed is to allow both conflicting records to persist until a human can intervene. That may be quite acceptable for an address book; it's emphasisnot/emphasis fine for OLTP systems. /para /listitem listitempara Update capture methods /para para Common methods include having triggers on tables, capturing SQL statements, and capturing transaction log (WAL) updates /para itemizedlist listitempara Triggers, as used in eRServer and Slony-I, have the advantage of capturing updates at the end of processing when all column values have been finalized. The use of transaction
Re: [PATCHES] Replication Documentation
Chris Browne wrote: Here's a patch to add in the material on replication recently discussed on pgsql.docs. I'm not thrilled that there were only a few comments made; I'd be happy to see slicing and dicing to see this made more useful. s/e.g. -/e.g.,/ s/ - /ndash;/ The indentation of the SGML file seems at odds with our conventions (we don't use tabs, for one thing.) You mention this: para Common methods include having triggers on tables, capturing SQL statements, and capturing transaction log (WAL) updates /para However you don't mention anything about WAL captures. Mentioning that PITR is one of these would be good. In the last few paragraphs, the title is about Postgres-R but then you comment on Slony-II. Should the title mention both? para As a result of those problems, Slony-II efforts have fallen off somewhat. /para s/those/these/ ? Otherwise looks good to my untrained eyes. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Replication Documentation
s/sequnce/sequence/ Nice work! -- Korry Douglas [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com
Re: [PATCHES] Replication Documentation
Thanks for mentioning about pgpool! sect2title pgpool /title para applicationpgpool/application was initially created by Tatsuo Isshii as a portable alternative to Java connection pool modules. He subsequently observed that it wouldn't take very much effort to extend it to create a simple replication system: if it is forwarding SQL queries to a PostgreSQL instance, extending that to two databases is very straightforward. /para para It suffers, by nature, from the problems associated with replicating using capture of SQL statements; any sort of nondeterminism in the replicated statements will cause the databases to diverge. /para para On the other hand, it is very easy to install and configure; for users with simple requirements, that can suffice. /para para A applicationpgpool-2/application is under way which introduces a more sophisticated query parser to try to address the nondeterminism issues; that may limit ongoing support for the legacy version./para pgpool-II (not pgpool-2, please) does not try to resolve nondeterminism issues but try to add parallel SELECT query execution. Also we will continue to support legacy version until pgpool-II becomes stable enough. Also you might want to add pgpool development site URL. FYI, pgpool-II presentation material for PostgreSQL Anniversary Summit can be obtained from: http://www.sraoss.co.jp/event_seminar/2006/pgpool_feat_and_devel.pdf -- Tatsuo Ishii SRA OSS, Inc. Japan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Replication Documentation
Chris Browne wrote: Here's a patch to add in the material on replication recently discussed on pgsql.docs. I'm not thrilled that there were only a few comments made; I'd be happy to see slicing and dicing to see this made more useful. The agreed-to process was 1. post information on pgsql-general 1.a. solicit comments 2. put information page on web site 3. link from documentation to web site You seem to have short-circuited all that. I don't think this sort of material belongs directly into the PostgreSQL documentation. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Replication Documentation
1. post information on pgsql-general 1.a. solicit comments 2. put information page on web site 3. link from documentation to web site You seem to have short-circuited all that. I don't think this sort of material belongs directly into the PostgreSQL documentation. It might be interesting to have some links in the external projects area for replication, but a section of its own doesn't seem relevant. Joshua D. Drkae -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] Replication Documentation
Joshua D. Drake wrote: I don't think this sort of material belongs directly into the PostgreSQL documentation. Why not? It might be interesting to have some links in the external projects area for replication, but a section of its own doesn't seem relevant. I disagree about having some links. Maybe we should consider adding this as a section in the external projects chapter, instead of having a chapter of its own, but some links seems a little short on actual contents. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Replication Documentation
Alvaro Herrera wrote: Joshua D. Drake wrote: I don't think this sort of material belongs directly into the PostgreSQL documentation. Why not? Well Peter said that, not me :) It might be interesting to have some links in the external projects area for replication, but a section of its own doesn't seem relevant. I disagree about having some links. Maybe we should consider adding this as a section in the external projects chapter, instead of having a chapter of its own, but some links seems a little short on actual contents. O.k. more specifically, I think that the content (even if it is a section) probably deserves discussion in the external projects section. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] Replication Documentation
Joshua D. Drake wrote: Alvaro Herrera wrote: Joshua D. Drake wrote: I don't think this sort of material belongs directly into the PostgreSQL documentation. Why not? Well Peter said that, not me :) I know, but I though I'd post one message instead of two. (In fact I didn't even think about it -- I just assume it's clear.) It might be interesting to have some links in the external projects area for replication, but a section of its own doesn't seem relevant. I disagree about having some links. Maybe we should consider adding this as a section in the external projects chapter, instead of having a chapter of its own, but some links seems a little short on actual contents. O.k. more specifically, I think that the content (even if it is a section) probably deserves discussion in the external projects section. Sure, see my suggestion above. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Replication Documentation
[EMAIL PROTECTED] (Peter Eisentraut) wrote: Chris Browne wrote: Here's a patch to add in the material on replication recently discussed on pgsql.docs. I'm not thrilled that there were only a few comments made; I'd be happy to see slicing and dicing to see this made more useful. The agreed-to process was 1. post information on pgsql-general 1.a. solicit comments 2. put information page on web site 3. link from documentation to web site You seem to have short-circuited all that. I don't think this sort of material belongs directly into the PostgreSQL documentation. I don't recall that anyone agreed to do anything in particular, let alone the process being formalized thus. Bruce was looking for there to be some form of overview of the free replication options so he'd have some kind of tale to tell about it. Apparently the issue comes up fairly frequently. 1. I posted information on pgsql-docs 1.a. I solicited comments 2. There being not many of those, I have put together something that could fit into the documentation. I frankly don't care all that much where the material goes; if it ought to be some place else other than in the documentation tree proper, I'm fine with that. -- select 'cbbrowne' || '@' || 'gmail.com'; http://linuxdatabases.info/info/postgresql.html How much more helpful could I be than to provide you with the appropriate e-mail address? I could engrave it on a clue-by-four and deliver it to you in Chicago, I suppose. -- Seen on Slashdot... ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
