Streaming replication, loose ends
in [PgSql]
|
From: Tom Lane on 15 Jan 2010 12:11 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > I moved the line for src/backend/replication/walreceiver in src/Makefile > further down, after src/interfaces. That should fix the build failures > for now, but I'm all ears if there's better suggestions. Yeah, I saw. Seems like a reasonable solution for now. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Joshua D. Drake" on 15 Jan 2010 12:17 On Fri, 2010-01-15 at 05:36 -0500, Bruce Momjian wrote: > Heikki Linnakangas wrote: > > I've now committed streaming replication. I moved the files around a > > bit, and put the walreceiver/walsender stuff in a new > > src/backend/replication subdirectory. There's enough stuff there already > > to deserve a new subdirectory, and if we add the capability for > > streaming base backups etc. that has been discussed, we will have more > > code in there. > > > > But it's not time to party yet. There's still a few loose ends we need > > to address: > > > > Documentation. The patch originally moved around some sections, but I > > didn't include that in the committed version, to make it clear in the > > diff what exactly was added/changed. But I do agree with the original > > thought of adding a new "Replication" chapter, and moving all the > > replication and standby related stuff there from the "Backup and > > Restore" chapter, so let's start working on that. > > Uh, do we really want to call this "replication" rather than archive log > streaming or something. It seems "replication" is a generic term and > will confuse people who are using other replication solutions like > Slony. +1, it is not replication. I would call it something like continuous archiving or streaming pitr Joshua D. Drake > > -- > Bruce Momjian <bruce(a)momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 15 Jan 2010 12:24 On Fri, Jan 15, 2010 at 12:17 PM, Joshua D. Drake <jd(a)commandprompt.com> wrote: >> Uh, do we really want to call this "replication" rather than archive log >> streaming or something. It seems "replication" is a generic term and >> will confuse people who are using other replication solutions like >> Slony. > > +1, it is not replication. I would call it something like continuous > archiving or streaming pitr Of course "PITR" does stand for "point-in-time replication"... ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 15 Jan 2010 12:29 Bruce Momjian wrote: > Heikki Linnakangas wrote: >> I've now committed streaming replication. I moved the files around a >> bit, and put the walreceiver/walsender stuff in a new >> src/backend/replication subdirectory. There's enough stuff there already >> to deserve a new subdirectory, and if we add the capability for >> streaming base backups etc. that has been discussed, we will have more >> code in there. >> >> But it's not time to party yet. There's still a few loose ends we need >> to address: >> >> Documentation. The patch originally moved around some sections, but I >> didn't include that in the committed version, to make it clear in the >> diff what exactly was added/changed. But I do agree with the original >> thought of adding a new "Replication" chapter, and moving all the >> replication and standby related stuff there from the "Backup and >> Restore" chapter, so let's start working on that. > > Uh, do we really want to call this "replication" rather than archive log > streaming or something. It seems "replication" is a generic term and > will confuse people who are using other replication solutions like > Slony. Good question. OTOH, if we move the sections about setting up a file-shipping based standby with pg_standby, that's not streaming. What we have now is: Server Administration ... Backup and Restore SQL Dump File System Level Backup Continuous Archiving and Point-In-Time Recovery (PITR) Warm Standby Servers for High Availability Planning Implementation Failover Record-based Log Shipping Streaming Replication Incrementally Updated Backups Hot Standby User's Overview Handling query conflicts Administrator's Overview Hot Standby Parameter Reference Caveats High Availability, Load Balancing, and Replication I propose: Server Administration Backup and Restore SQL Dump File System Level Backup Continuous Archiving and Point-In-Time Recovery (PITR) High Availability, Load Balancing, and Replication Introduction Comparison of different solutions (*) File-based Log Shipping Planning Implementation Streaming Replication Setting up Failover Hot Standby User's Overview Handling query conflicts Administrator's Overview Hot Standby Parameter Reference Caveats Incrementally Updated Backups (*) Current content of "High Availability, Load Balancing, and Replication" chapter goes here Note that I propose to remove "Record-based Log Shipping" section altogether. We can briefly mention that method under Streaming Replication, but I consider that obsolete with streaming replication. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 15 Jan 2010 12:30 Robert Haas wrote: > On Fri, Jan 15, 2010 at 12:17 PM, Joshua D. Drake <jd(a)commandprompt.com> wrote: >>> Uh, do we really want to call this "replication" rather than archive log >>> streaming or something. It seems "replication" is a generic term and >>> will confuse people who are using other replication solutions like >>> Slony. >> +1, it is not replication. I would call it something like continuous >> archiving or streaming pitr > > Of course "PITR" does stand for "point-in-time replication"... I'm not sure if you're joking, but PITR actually stands for Point-In-Time *Recovery*. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: attoptions Next: [HACKERS] missing data in information_schema grant_* tables? |