On Thu, May 29, 2008 at 11:58:31AM -0400, Bruce Momjian wrote:
Josh Berkus wrote:
Publishing the XIDs back to the master is one possibility. We
also looked at using spillover segments for vacuumed rows, but
that seemed even less viable.
I'm also thinking, for *async replication*, that
David Fetter wrote:
This part is a deal-killer. It's a giant up-hill slog to sell warm
standby to those in charge of making resources available because the
warm standby machine consumes SA time, bandwidth, power, rack space,
etc., but provides no tangible benefit, and this feature would have
David Fetter wrote:
On Thu, May 29, 2008 at 11:58:31AM -0400, Bruce Momjian wrote:
Josh Berkus wrote:
Publishing the XIDs back to the master is one possibility. We
also looked at using spillover segments for vacuumed rows, but
that seemed even less viable.
I'm also thinking,
* Dave Page [EMAIL PROTECTED] [080529 12:03]:
On Thu, May 29, 2008 at 4:48 PM, Douglas McNaught [EMAIL PROTECTED] wrote:
I think the idea is that WAL records would be shipped (possibly via
socket) and applied as they're generated, rather than on a
file-by-file basis. At least that's what
Bruce,
Another idea I discussed with Tom is having the slave _delay_ applying
WAL files until all slave snapshots are ready.
Well, again, that only works for async mode. I personally think that's
the correct solution for async. But for synch mode, I think we need to
push the xids back to
Dave Page wrote:
On Thu, May 29, 2008 at 4:48 PM, Douglas McNaught [EMAIL PROTECTED] wrote:
On Thu, May 29, 2008 at 11:46 AM, Joshua D. Drake [EMAIL PROTECTED] wrote:
The only question I have is... what does this give us that PITR doesn't
give us?
I think the idea is that
On 5/29/08, Joshua D. Drake [EMAIL PROTECTED] wrote:
On Thu, 2008-05-29 at 08:21 -0700, David Fetter wrote:
On Thu, May 29, 2008 at 10:12:55AM -0400, Tom Lane wrote:
This part is a deal-killer. It's a giant up-hill slog to sell warm
standby to those in charge of making resources
Josh Berkus wrote:
Bruce,
Another idea I discussed with Tom is having the slave _delay_ applying
WAL files until all slave snapshots are ready.
Well, again, that only works for async mode. I personally think that's
the correct solution for async. But for synch mode, I think we
On May 29, 2008, at 9:12 AM, David Fetter wrote:
On Thu, May 29, 2008 at 11:58:31AM -0400, Bruce Momjian wrote:
Josh Berkus wrote:
Publishing the XIDs back to the master is one possibility. We
also looked at using spillover segments for vacuumed rows, but
that seemed even less viable.
I'm
Tom Lane wrote:
In practice, simple asynchronous single-master-multiple-slave
replication covers a respectable fraction of use cases, so we have
concluded that we should allow such a feature to be included in the core
project. We emphasize that this is not meant to prevent continued
development
On Thu, 2008-05-29 at 09:10 -0700, Josh Berkus wrote:
Joshua D. Drake wrote:
The only question I have is... what does this give us that PITR doesn't
give us?
Since people seem to be unclear on what we're proposing:
8.4 Synchronous Warm Standby: makes PostgreSQL more suitable for HA
On 5/29/08, Aidan Van Dyk [EMAIL PROTECTED] wrote:
* Dave Page [EMAIL PROTECTED] [080529 12:03]:
On Thu, May 29, 2008 at 4:48 PM, Douglas McNaught [EMAIL PROTECTED] wrote:
I think the idea is that WAL records would be shipped (possibly via
socket) and applied as they're generated, rather
* Marko Kreen [EMAIL PROTECTED] [080529 12:27]:
I don't think thats a problem. If the user runs its server at the
limit of write-bandwidth, thats its problem.
IOW, with synchronous replication, we _want_ the server to lag behind
slaves.
About the single-threading problem - afaik, the
Andrew Dunstan [EMAIL PROTECTED] writes:
Dave Page wrote:
Yes, we're talking real-time streaming (synchronous) log shipping.
That's not what Tom's email said, AIUI.
Sorry, I was a bit sloppy about that. If we go with a WAL-shipping
solution it would be pretty easy to support both synchronous
David Fetter wrote:
This part is a deal-killer. It's a giant up-hill slog to sell warm
standby to those in charge of making resources available because the
warm standby machine consumes SA time, bandwidth, power, rack space,
etc., but provides no tangible benefit, and this feature would have
David Fetter [EMAIL PROTECTED] writes:
On Thu, May 29, 2008 at 08:46:22AM -0700, Joshua D. Drake wrote:
The only question I have is... what does this give us that PITR
doesn't give us?
It looks like a wrapper for PITR to me, so the gain would be ease of
use.
A couple of points about that:
On Thu, 29 May 2008, David Fetter wrote:
It's a giant up-hill slog to sell warm standby to those in charge of
making resources available because the warm standby machine consumes SA
time, bandwidth, power, rack space, etc., but provides no tangible
benefit, and this feature would have exactly
On Thu, 2008-05-29 at 09:18 -0700, Josh Berkus wrote:
Bruce,
Another idea I discussed with Tom is having the slave _delay_ applying
WAL files until all slave snapshots are ready.
Well, again, that only works for async mode.
It depends on what we mean by synchronous. Do we mean the
Josh,
What does this give us that Solaris Cluster, RedHat Cluster, DRBD etc..
doesn't give us?
Actually, these solutions all have some serious drawbacks, not the least
of which is difficult administration (I speak from bitter personal
experience). Also, most of them require installation
On Thu, May 29, 2008 at 12:11:21PM -0400, Brian Hurt wrote:
Being able to do read-only queries makes this feature more valuable in more
situations, but I disagree that it's a deal-breaker.
Your managers are apparently more enlightened than some. ;-)
A
--
Andrew Sullivan
[EMAIL PROTECTED]
On Thu, May 29, 2008 at 07:20:37PM +0300, Marko Kreen wrote:
So you can do lossless failover. Currently there is no good
solution for this.
Indeed. Getting lossless failover would be excellent.
I understand David's worry (having had those arguments more times than
I care to admit), but if
On Thu, May 29, 2008 at 02:13:26PM -0400, Andrew Sullivan wrote:
On Thu, May 29, 2008 at 12:11:21PM -0400, Brian Hurt wrote:
Being able to do read-only queries makes this feature more
valuable in more situations, but I disagree that it's a
deal-breaker.
Your managers are apparently more
in this case too. So each slave just needs to report its own longest
open tx as open to master. Yes, it bloats master but no way around it.
Slaves should not report it every time or every transaction. Vacuum on master
will ask them before doing a real work.
--
Teodor Sigaev
On Thu, May 29, 2008 at 12:19 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
That's not what Tom's email said, AIUI. Synchronous replication surely
means that the master and slave always have the same set of transactions
applied. Streaming synchronous. But streaming log shipping will allow us
to
Hi everyone,
First of all, I'm absolutely delighted that the PG community is thinking
seriously about replication.
Second, having a solid, easy-to-use database availability solution that works
more or less out of the box would be an enormous benefit to customers.
Availability is the single
On Thu, May 29, 2008 at 3:05 PM, Robert Hodges
[EMAIL PROTECTED] wrote:
Third, you can't stop with just this feature. (This is the BUT part of the
post.) The use cases not covered by this feature area actually pretty
large. Here are a few that concern me:
1.) Partial replication.
2.) WAN
Andrew Sullivan wrote:
On Thu, May 29, 2008 at 12:11:21PM -0400, Brian Hurt wrote:
Being able to do read-only queries makes this feature more valuable in more
situations, but I disagree that it's a deal-breaker.
Your managers are apparently more enlightened than some. ;-)
A
No
On 5/29/08, Teodor Sigaev [EMAIL PROTECTED] wrote:
in this case too. So each slave just needs to report its own longest
open tx as open to master. Yes, it bloats master but no way around it.
Slaves should not report it every time or every transaction. Vacuum on
master will ask them
On Thu, May 29, 2008 at 12:05:18PM -0700, Robert Hodges wrote:
people are starting to get religion on this issue I would strongly
advocate a parallel effort to put in a change-set extraction API
that would allow construction of comprehensive master/slave
replication.
You know, I gave a
On 5/29/08, Tom Lane [EMAIL PROTECTED] wrote:
* The proposed approach is trying to get to real replication
incrementally. Getting rid of the loss window involved in file-by-file
log shipping is step one, and I suspect that step two is going to be
fixing performance issues in WAL replay to
David Fetter wrote:
Either one of these would be great, but something that involves
machines that stay useless most of the time is just not going to work.
Lots of people do use warm standby already anyway, just not based on
mechanisms built into PostgreSQL. So defining away this need is
Jeff Davis wrote:
It depends on what we mean by synchronous. Do we mean the WAL record
has made it to the disk on the slave system, or the WAL record has
been applied on the slave system?
DRBD, which is a common warm standby solution for PostgreSQL at the moment,
provides various levels of
Merlin Moncure wrote:
Read only slave is the #1 most anticipated feature in the
circles I run with.
Do these circles not know about slony and londiste?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Joshua D. Drake wrote:
What does this give us that Solaris Cluster, RedHat Cluster, DRBD etc..
doesn't give us?
I personally think that DRBD is a fine solution. But it only runs on Linux.
And Solaris Cluster isn't the same as DRBD.
--
Sent via pgsql-hackers mailing list
Andrew Sullivan [EMAIL PROTECTED] writes:
On Thu, May 29, 2008 at 12:05:18PM -0700, Robert Hodges wrote:
people are starting to get religion on this issue I would strongly
advocate a parallel effort to put in a change-set extraction API
that would allow construction of comprehensive
Andrew Sullivan wrote:
The big missing piece is lossless failover. People are currently
doing it with DRBD, various clustering things, c., and those are
complicated to set up and maintain.
Well, we'll see at the end of this (we hope) how a setup procedure of DRBD vs.
PG warm standby works
Mathias Brossard wrote:
From what I gather from those slides it seems to me that the NTT solution
is synchronous not asynchronous. In my opinion it's even better, but I do
understand that others might prefer asynchronous. I'm going to speculate,
but I would think it should be possible
Tom Lane wrote:
We believe that the most appropriate base technology for this is
probably real-time WAL log shipping, as was demoed by NTT OSS at PGCon.
Now how do we get our hands on their code?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Thu, May 29, 2008 at 3:59 PM, Peter Eisentraut [EMAIL PROTECTED] wrote:
Merlin Moncure wrote:
Read only slave is the #1 most anticipated feature in the
circles I run with.
Do these circles not know about slony and londiste?
Sure.
For various reasons mentioned elsewhere on this thread, a
Robert,
1.) Partial replication.
2.) WAN replication.
3.) Bi-directional replication. (Yes, this is evil but there are
problems where it is indispensable.)
4.) Upgrade support. Aside from database upgrade (how would this ever
really work between versions?), it would not support
On Thu, May 29, 2008 at 09:54:03PM +0200, Peter Eisentraut wrote:
David Fetter wrote:
Either one of these would be great, but something that involves
machines that stay useless most of the time is just not going to
work.
Lots of people do use warm standby already anyway, just not based
David Fetter [EMAIL PROTECTED] writes:
On Thu, May 29, 2008 at 09:54:03PM +0200, Peter Eisentraut wrote:
I think the consensus in the core team was that having synchronous
log shipping in 8.4 would already be a worthwhile feature by itself.
If that was in fact the consensus of the core team,
On Thu, May 29, 2008 at 04:44:19PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Thu, May 29, 2008 at 09:54:03PM +0200, Peter Eisentraut wrote:
I think the consensus in the core team was that having
synchronous log shipping in 8.4 would already be a worthwhile
feature
David Fetter wrote:
What is your justification for denigrating this plan with that? Or
are you merely complaining because we know we won't be all the way
there in 8.4?
Again, just my humble opinion, but given the stated goal, which I
agree with, I'd say it's worth holding up 8.4 until
David,
I think the consensus in the core team was that having synchronous
log shipping in 8.4 would already be a worthwhile feature by itself.
If that was in fact the consensus of the core team,
It is.
and what I've been
seeing from several core members in this thread makes that idea
On Thu, May 29, 2008 at 04:54:04PM -0400, Bruce Momjian wrote:
David Fetter wrote:
What is your justification for denigrating this plan with that?
Or are you merely complaining because we know we won't be all
the way there in 8.4?
Again, just my humble opinion, but given the stated
Bruce Momjian [EMAIL PROTECTED] writes:
David Fetter wrote:
Again, just my humble opinion, but given the stated goal, which I
agree with, I'd say it's worth holding up 8.4 until some kind of
out-of-the-box replication advances that goal, where Yet Another
Toolkit Suitable For People Who Are
On Thu, May 29, 2008 at 01:55:42PM -0700, Josh Berkus wrote:
David,
I think the consensus in the core team was that having synchronous
log shipping in 8.4 would already be a worthwhile feature by itself.
If that was in fact the consensus of the core team,
It is.
and what I've been
David,
I think having master-slave replication in the core using WAL is a
*great* thing to do, doable, a good path to go on, etc., and I think
it's worth holding up 8.4 until we have at least one actual
out-of-the-box version of same.
Ah, ok. Well, I can tell you that the core team is also
On Thu, May 29, 2008 at 01:39:29PM -0700, David Fetter wrote:
I think the consensus in the core team was that having synchronous
log shipping in 8.4 would already be a worthwhile feature by itself.
If that was in fact the consensus of the core team, and what I've been
seeing from several
Peter Eisentraut wrote:
Mathias Brossard wrote:
From what I gather from those slides it seems to me that the NTT solution
is synchronous not asynchronous. In my opinion it's even better, but I do
understand that others might prefer asynchronous. I'm going to speculate,
but I would think it
On Thursday 29 May 2008 12:13:20 Bruce Momjian wrote:
David Fetter wrote:
On Thu, May 29, 2008 at 11:58:31AM -0400, Bruce Momjian wrote:
Josh Berkus wrote:
Publishing the XIDs back to the master is one possibility. We
also looked at using spillover segments for vacuumed rows, but
On Thu, 2008-05-29 at 17:42 -0400, Robert Treat wrote:
I would have thought the read only piece would have been more important than
the synchronous piece. In my experience readable slaves is the big selling
point in both Oracle and MySQL's implementations, and people are not nearly
as
Robert Treat [EMAIL PROTECTED] writes:
I would have thought the read only piece would have been more important than
the synchronous piece. In my experience readable slaves is the big selling
point in both Oracle and MySQL's implementations, and people are not nearly
as concerned if there is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I'd first want to applaud core decision: having bare PostgreSQL
propose a reliable and simple to set-up synchronous replication
solution is an excellent perspective! ...
Le 29 mai 08 à 23:42, Robert Treat a écrit :
I would have thought the
Dimitri Fontaine [EMAIL PROTECTED] writes:
While at it, would it be possible for the simple part of the core
team statement to include automatic failover?
No, I think it would be a useless expenditure of energy. Failover
includes a lot of things that are not within our purview: switching
IP
Joshua D. Drake wrote:
On Thu, 2008-05-29 at 17:42 -0400, Robert Treat wrote:
I would have thought the read only piece would have been more important than
the synchronous piece. In my experience readable slaves is the big selling
point in both Oracle and MySQL's implementations, and
On Thu, 2008-05-29 at 18:39 -0400, Andrew Dunstan wrote:
Joshua D. Drake wrote:
On Thu, 2008-05-29 at 17:42 -0400, Robert Treat wrote:
You must be gauging a different market from the one I'm in. I have just
come back from a meeting with a (quite technically savvy) customer who
One
Joshua D. Drake [EMAIL PROTECTED] writes:
One customer does not make a hundred. I am not saying that the shipping
isn't valid, just that those that I talk to are more interested in the
read only slave. Consider that we have any number of ways to solve the
problem we are considering
On Thu, 2008-05-29 at 19:02 -0400, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
One customer does not make a hundred. I am not saying that the shipping
isn't valid, just that those that I talk to are more interested in the
read only slave. Consider that we have any number of
[EMAIL PROTECTED] (Tom Lane) writes:
As I said originally, we have no expectation that the proposed features
will displace the existing replication projects for high end
replication problems ... and I'd characterize all of Robert's concerns
as high end problems. We are happy to let those be
Joshua D. Drake [EMAIL PROTECTED] writes:
I think maybe my actual argument isn't coming through. What I am arguing
for is not shipping XY without Z. That is all. (and no, I don't think we
should hold up 8.4).
So we should keep all the work out of the tree until every part is done?
No thanks;
On Thu, May 29, 2008 at 7:12 PM, Joshua D. Drake [EMAIL PROTECTED] wrote:
On Thu, 2008-05-29 at 19:02 -0400, Tom Lane wrote:
I think we have nontrivial
work in front of us to build a simple, reliable, community-tested
log shipping solution; and it's not very sexy work either. But it
needs
On Thu, 29 May 2008, Tom Lane wrote:
There's no point in having read-only slave queries if you don't have a
trustworthy method of getting the data to them.
This is a key statement that highlights the difference in how you're
thinking about this compared to some other people here. As far as
* Tom Lane [EMAIL PROTECTED] [080529 20:22]:
Joshua D. Drake [EMAIL PROTECTED] writes:
I think maybe my actual argument isn't coming through. What I am arguing
for is not shipping XY without Z. That is all. (and no, I don't think we
should hold up 8.4).
So we should keep all the work out
Tom Lane wrote:
There's no point in having read-only slave queries if you don't have a
trustworthy method of getting the data to them.
O.k. I was with you until here. Log shipping ala pg_standby works fine
now sans read-only slave. No, it isn't out of the box which I can see an
argument for
Greg,
I fully accept that it may be the case that it doesn't make technical
sense to tackle them in any order besides sync-read-only slaves because
of dependencies in the implementation between the two. If that's the
case, it would be nice to explicitly spell out what that was to deflect
On Thu, May 29, 2008 at 07:02:56PM -0400, Tom Lane wrote:
People want the bits to go from point A to point B; they don't want
to have to research, design, test, and administer their own solution
for moving the bits.
I agree with this. I think I probably know as well as most people --
On Thu, May 29, 2008 at 9:26 PM, Josh Berkus [EMAIL PROTECTED] wrote:
I fully accept that it may be the case that it doesn't make technical
sense to tackle them in any order besides sync-read-only slaves because
of dependencies in the implementation between the two. If that's the
case, it
Josh Berkus wrote:
Greg,
I fully accept that it may be the case that it doesn't make technical
sense to tackle them in any order besides sync-read-only slaves because
of dependencies in the implementation between the two. If that's the
case, it would be nice to explicitly spell out what
Greg Smith [EMAIL PROTECTED] writes:
I fully accept that it may be the case that it doesn't make technical
sense to tackle them in any order besides sync-read-only slaves because
of dependencies in the implementation between the two.
Well, it's certainly not been my intention to suggest that
101 - 171 of 171 matches
Mail list logo
