Re: "Hot standby"?

What is "hot" and "standby" about the proposed "hot standby" feature?

The way I understand these terms in a replication/cluster scenario are:

cold - If the first node dies, you need to start the replacement node from a
standing start.

warm - If the first node dies, the replacement node needs to do some work to
get ready, but it's a lot quicker than "cold".

hot - If the first node dies, the replacement node can take over immediately.

standby - While the master node is running, the standby node instance cannot
be used for anything (useful).

slave - While the master node is running, the slave node can be used in
limited capacity (typically read-only).

master - Both/all nodes have equivalent capabilities all the time while the
cluster is up.

For example, I'd say that a DRBD-based solution would be a cold standby.
Among WAL-based solutions, what we have now with pg_standby (nomen est omen),
is a warmish standby. From what I understand, Simon's patch set does not
change the "warm" property of this arrangement at all. It only changes the
"standby" to a "slave".

Am I off? What other definition of terms justifies the description of "hot
standby"?

On Tue, Aug 11, 2009 at 5:30 AM, Peter Eisentraut<peter_e(at)gmx(dot)net> wrote:
> What is "hot" and "standby" about the proposed "hot standby" feature?

Absolutely nothing. It's horribly misnamed.

I have also long argued that "Synchronous Replication" should really
be called "Streaming Replication". Perhaps it may eventually support
a synchronous mode of operation, but that will probably never be the
only one.

...Robert

>
> Am I off? What other definition of terms justifies the description of "hot
> standby"?
>

I think that "Hot Standby" is associated with the high WAL recovery
capacity.
In my opinion, is a good term to symbolizes the superiority compared with
"Warm Standby".

--
Matheus Ricardo Espanhol
---------------------------------------
Dextra Sistemas
http://www.dextra.com.br/postgres/

Robert Haas wrote:
> On Tue, Aug 11, 2009 at 5:30 AM, Peter Eisentraut<peter_e(at)gmx(dot)net> wrote:
> > What is "hot" and "standby" about the proposed "hot standby" feature?

OK, so it is "warm slave".

> Absolutely nothing. It's horribly misnamed.
>
> I have also long argued that "Synchronous Replication" should really
> be called "Streaming Replication". Perhaps it may eventually support
> a synchronous mode of operation, but that will probably never be the
> only one.

Yes, I like "streaming replication" because no matter how we implement
this feature, there are going to be synchronous and asynchronous modes
eventually.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> OK, so it is "warm slave".

That is technically accurate, given the preceding definitions, but it
has disturbing connotations. Enough so, in my view, to merit getting
a little more creative in the naming. How about "warm replica"?
Other ideas?

I agree that the present moniker misleads.

-Kevin

On Aug 11, 2009, at 5:32 AM, Bruce Momjian wrote:

> OK, so it is "warm slave".

I suggest steaming servant. Or tepid assistant.

David

On Tue, Aug 11, 2009 at 12:30:58PM +0300, Peter Eisentraut wrote:

> warm - If the first node dies, the replacement node needs to do some work to
> get ready, but it's a lot quicker than "cold".
>
> hot - If the first node dies, the replacement node can take over immediately.

> For example, I'd say that a DRBD-based solution would be a cold standby.
> Among WAL-based solutions, what we have now with pg_standby (nomen est omen),
> is a warmish standby. From what I understand, Simon's patch set does not
> change the "warm" property of this arrangement at all. It only changes the
> "standby" to a "slave".

> Am I off? What other definition of terms justifies the description of "hot
> standby"?

As for "warm/hot", it depends on what you exactly mean with "get
ready":

(A) If you mean "it is possible to connect to the second node", then
Simon's patch is "hot".

IIRC this meaning agrees with the terminology used by other
databases, such as Oracle, Sybase, etc.

(B) If you mean "the contents of the second node are equal to the
contents of the first node", then Simon's patch is "warm".

But then we have by definition "hot" == "synchronous" and "either
warm or cold" == "asynchronous". IMHO the other case is
preferrable, as the word sets "synchronous/asynchronous" and
"cold/warm/hot" are more expressive because they measure two
independent properties.

Best regards,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni(dot)ciolli(at)2ndquadrant(dot)it | www.2ndquadrant.it

On Tue, 2009-08-11 at 08:12 -0700, David E. Wheeler wrote:
> On Aug 11, 2009, at 5:32 AM, Bruce Momjian wrote:
>
> > OK, so it is "warm slave".
>
> I suggest steaming servant. Or tepid assistant.

We can't use those, I think they are on the list for Ubuntu.

Joshua D. Drake

>
> David
>
--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

On Tue, Aug 11, 2009 at 08:56:38AM -0500, Kevin Grittner wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> > OK, so it is "warm slave".
>
> That is technically accurate, given the preceding definitions, but
> it has disturbing connotations. Enough so, in my view, to merit
> getting a little more creative in the naming. How about "warm
> replica"? Other ideas?

Warm Read
Streamed Copy

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Peter,

I believe we're just copying Oracle's terminology. While that
terminology is not consistent, it is understood by the industry. Oracle
defined their Hot Standby to have both asynchronous and synchronous modes:
http://www.oracle.com/technology/products/rdb/htdocs/dbms/hotstandby.html

The other industry term which would be understood would be "log-based
replication". Terms we invent would be less likely to be understood,
and users would not get excited about them.

Otherwise, I say we go with "simmering follower". ;-)

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On Tue, Aug 11, 2009 at 1:08 PM, Josh Berkus<josh(at)agliodbs(dot)com> wrote:
> I believe we're just copying Oracle's terminology.  While that
> terminology is not consistent, it is understood by the industry.  Oracle
> defined their Hot Standby to have both asynchronous and synchronous modes:
> http://www.oracle.com/technology/products/rdb/htdocs/dbms/hotstandby.html

I think that you are wrong. Hot Standby is described in that document
as a way of replication the database and providing failover in the
event that the master dies. This feature has to do with allowing
queries to be executed on the slave, which is not discussed in that
document.

...Robert

David Fetter wrote:
> On Tue, Aug 11, 2009 at 08:56:38AM -0500, Kevin Grittner wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>
>>> OK, so it is "warm slave".

Why isn't it just a "read only slave". Do some systems
have read-only slave databases that can't serve as a warm
standby system as well as this one could?

>> That is technically accurate, given the preceding definitions, but
>> it has disturbing connotations. Enough so, in my view, to merit
>> getting a little more creative in the naming. How about "warm
>> replica"? Other ideas?
>
> Warm Read
> Streamed Copy

Master/Slave Replication and Warm Standby systems are common
enough terms that I can google them or look them up in many
computer science books.

While coming up with creative politically correct euphemisms
might be fun, I hope we stick near terms that other DBAs could
already be familiar with.

ISTM the best way to refer to it formally would be a
"Read Only Slave / Warm Standby"
system, even if informally we might have informal
discussions of "just how hot our slaves are" when hot-standby
features get added down the road.

On 08/11/2009 09:56 AM, Kevin Grittner wrote:
> Bruce Momjian<bruce(at)momjian(dot)us> wrote:
>
>
>> OK, so it is "warm slave".
>>
>
> That is technically accurate, given the preceding definitions, but it
> has disturbing connotations. Enough so, in my view, to merit getting
> a little more creative in the naming. How about "warm replica"?
> Other ideas?
>
> I agree that the present moniker misleads.

I remember this debate from 6 months ago. :-)

I prefer not to try and fit square pegs into round holes. Streaming
replication sounds like the best description. It may not be the keywords
that newbies are looking for, but too bad for them. Calling it something
different than what it is, just so that people who don't understand why
it is wrong will have something that approximates the right
understanding, is not a just cause. :-)

Cheers,
mark

--
Mark Mielke<mark(at)mielke(dot)cc>

On Tue, Aug 11, 2009 at 2:48 PM, Mark Mielke<mark(at)mark(dot)mielke(dot)cc> wrote:
> On 08/11/2009 09:56 AM, Kevin Grittner wrote:
>
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
>
>
> OK, so it is "warm slave".
>
>
>
> That is technically accurate, given the preceding definitions, but it
> has disturbing connotations. Enough so, in my view, to merit getting
> a little more creative in the naming. How about "warm replica"?
> Other ideas?
>
> I agree that the present moniker misleads.
>
> I remember this debate from 6 months ago. :-)
>
> I prefer not to try and fit square pegs into round holes. Streaming
> replication sounds like the best description. It may not be the keywords
> that newbies are looking for, but too bad for them. Calling it something
> different than what it is, just so that people who don't understand why it
> is wrong will have something that approximates the right understanding, is
> not a just cause. :-)

Uhm, I think you are confused.

Hot Standby = Allow read-only queries on a PostgreSQL server during
archive recovery
Synchronous (or Streaming) Replication = Allow WAL to be streamed on a
byte level rather than copied file-by-file

Hot Standby is not any sort of replication.

...Robert

On Tue, Aug 11, 2009 at 2:10 PM, Ron Mayer<rm_pg(at)cheapcomplexdevices(dot)com> wrote:
> David Fetter wrote:
>> On Tue, Aug 11, 2009 at 08:56:38AM -0500, Kevin Grittner wrote:
>>> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>>
>>>> OK, so it is "warm slave".
>
> Why isn't it just a "read only slave".  Do some systems
> have read-only slave databases that can't serve as a warm
> standby system as well as this one could?

I think that's about right. What we have now via pg_standby or
similar tools is a warm standby. What this tool does is makes the
warm-standby also serve as a read-only slave. It doesn't make
failover any simpler so it's not making the standby any hotter - it
instead makes the standby be able to do more useful work when no
failover has occurred.

The technical description for the commit message is probably something
like this:

"Allow read-only queries to be processed during archive recovery."

The P/R version is probably something like this:

"Warm standby servers now function as read-only slaves."

...Robert

On 08/11/2009 02:52 PM, Robert Haas wrote:
> On Tue, Aug 11, 2009 at 2:48 PM, Mark Mielke<mark(at)mark(dot)mielke(dot)cc> wrote:
>
>> I remember this debate from 6 months ago. :-)
>>
>> I prefer not to try and fit square pegs into round holes. Streaming
>> replication sounds like the best description. It may not be the keywords
>> that newbies are looking for, but too bad for them. Calling it something
>> different than what it is, just so that people who don't understand why it
>> is wrong will have something that approximates the right understanding, is
>> not a just cause. :-)
>>
>
> Uhm, I think you are confused.
>
> Hot Standby = Allow read-only queries on a PostgreSQL server during
> archive recovery
> Synchronous (or Streaming) Replication = Allow WAL to be streamed on a
> byte level rather than copied file-by-file
>
> Hot Standby is not any sort of replication.

I don't think I was confused before - but I am confused now. :-)

This patch does not provide streaming replication?

Having the standby allow for read-only queries is a "would be nice" for
me, but it's not very useful. I've been monitoring these threads (and
wishing they were at a level I could participate and contribute on),
because I want the ability to have near real time updates such that the
standby can become live. "Hot standby" to me means "the slave is as
close to up-to-date as possible and can potentially take over at any
time in a near instance." This *implies* some sort of streaming
replication (byte level rather than file-by-file) rather than waiting
for WAL logs to become full and shipped.

If this patch doesn't give me near real time replication, then I am
confused about why I would want it at all. pg_standby already gives the
ability to do replication on a per completed WAL log file basis.

Cheers,
mark

--
Mark Mielke<mark(at)mielke(dot)cc>

Mark Mielke escribió:

> I don't think I was confused before - but I am confused now. :-)
>
> This patch does not provide streaming replication?

No. What it does is allow you to query the slave while it's still
replaying transactions. There's another patch allowing you to do
"stream replication". Hopefully both things could be used
simultaneously.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Mark Mielke <mark(at)mark(dot)mielke(dot)cc> wrote:

> This patch does not provide streaming replication?

There's a separate effort to provide asynchronous and synchronous
streaming replication. Different patch.

> "Hot standby" to me means "the slave is as close to up-to-date as
> possible and can potentially take over at any time in a near
> instance." This *implies* some sort of streaming replication (byte
> level rather than file-by-file) rather than waiting for WAL logs to
> become full and shipped.

Most of use would expect that from something called "hot standby".
That's why so many of us have been saying that the name is misleading.
This patch, as I understand it, would allow you to use the warm
standby to run read-only queries -- for reports and such, to take some
load off the primary database. No more; no less.

So it's still warm, not hot, and it's still usable as a warm standby.
It just lets you squeeze a little extra benefit from the copy while it
sits there periodically updating itself.

-Kevin

All,

So really, the "streaming replication" patch should be called "hot
standby", and the "hot standby" patch should be called "read only slaves"?

And *why* can't we call it log-based replication?

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On Tue, Aug 11, 2009 at 4:07 PM, Josh Berkus<josh(at)agliodbs(dot)com> wrote:
> All,
>
> So really, the "streaming replication" patch should be called "hot
> standby", and the "hot standby" patch should be called "read only slaves"?
>
> And *why* can't we call it log-based replication?

+1

*) it _is_ used to replicate a database (replicate means make a copy!)
*) our target market will perceive it that way
*) sounds cool

'synchronous log-based replication'
'asynchronous log-based replication'
or,
'log-based replication', in both synchronous and asynchronous modes

merlin

On Tue, Aug 11, 2009 at 01:14:56PM -0400, Robert Haas wrote:
> On Tue, Aug 11, 2009 at 1:08 PM, Josh Berkus<josh(at)agliodbs(dot)com> wrote:
> > I believe we're just copying Oracle's terminology.  While that
> > terminology is not consistent, it is understood by the industry.  Oracle
> > defined their Hot Standby to have both asynchronous and synchronous modes:
> > http://www.oracle.com/technology/products/rdb/htdocs/dbms/hotstandby.html
>
> I think that you are wrong. Hot Standby is described in that document
> as a way of replication the database and providing failover in the
> event that the master dies. This feature has to do with allowing
> queries to be executed on the slave, which is not discussed in that
> document.

That web page contains only a brief summary of Oracle's Hot Standby;
by looking at the attached PDF guide you can see that the capability
of allowing read-only queries on the standby node is actually part of
their architecture.

Since we are comparing the features with Oracle's Hot Standby, it is
perhaps useful to mention two of the major differences:

* Oracle's Hot Standby allows only one Standby node, while on
PostgreSQL we can have as many as we want, since the Primary is
totally unaware of them.

Allowing N clones instead of only one may be a crucial advantage in
these use cases where read-only queries represent the vast majority
of the load.

* Oracle's Hot Standby allows cloning hash indexes, which on
PostgreSQL are not WAL safe (anyway, they are currently discouraged
by the documentation).

Best regards,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni(dot)ciolli(at)2ndquadrant(dot)it | www.2ndquadrant.it

On Tuesday 11 August 2009 18:16:04 Gianni Ciolli wrote:
> As for "warm/hot", it depends on what you exactly mean with "get
> ready":
>
> (A) If you mean "it is possible to connect to the second node", then
> Simon's patch is "hot".

Yeah, but by that definiton doing a pg_dump/pg_restore every hour is also
"hot". ;-)

Incidentally, we billed pg_dump as hot backup at some point.

On Tue, Aug 11, 2009 at 4:07 PM, Josh Berkus<josh(at)agliodbs(dot)com> wrote:
> So really, the "streaming replication" patch should be called "hot
> standby",

No. AIUI, hot standby means that when your primary falls over, the
secondary automatically promotes itself and takes over. It requires
things like heartbeat monitoring and STONITH and is unrelated to
anything we currently have under consideration.

> and the "hot standby" patch should be called "read only slaves"?

Yes.

> And *why* can't we call it log-based replication?

Well, we can call it anything we want. For example, up until now
we've been calling it "hot standby", even though that's clearly wrong.
:-)

But on the merits: log-based replication is, I think, what we already
have. Both of these patches do things that make it better. Streaming
replication (fka synch rep) makes it more nearly real-time, and
read-only slaves (fka hot standby) makes the standby server more
useful. But neither is ADDING log-based replication, they're both
IMPROVING it, in different ways.

...Robert

> Incidentally, we billed pg_dump as hot backup at some point.

mysql calls "mysqlhotcopy" a script that locks and flushes all tables,
then makes a copy of the database directory (all queries being locked out
while this is in progress, of course).

Pierre Frédéric Caillaud wrote:
>
>> Incidentally, we billed pg_dump as hot backup at some point.
>
> mysql calls "mysqlhotcopy" a script that locks and flushes all tables,
> then makes a copy of the database directory (all queries being locked
> out while this is in progress, of course).
>
>

Doesn't sound very "hot" to me. Tepid at best.

cheers

andrew

>> Incidentally, we billed pg_dump as hot backup at some point.

It *is* "hot backup" as in taken while the database is running and fully
accessible.

> mysql calls "mysqlhotcopy" a script that locks and flushes all tables,
> then makes a copy of the database directory (all queries being locked
> out while this is in progress, of course).

Which is actually 'cold backup'; it's only "hot" compared to earlier
MySQLs where you had to shut the db down. So it's sort of a "lukewarm
backup".

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On Wed, Aug 12, 2009 at 12:11:28AM +0300, Peter Eisentraut wrote:
> On Tuesday 11 August 2009 18:16:04 Gianni Ciolli wrote:
> > As for "warm/hot", it depends on what you exactly mean with "get
> > ready":
> >
> > (A) If you mean "it is possible to connect to the second node", then
> > Simon's patch is "hot".
>
> Yeah, but by that definiton doing a pg_dump/pg_restore every hour is also
> "hot". ;-)

OK, but only if (a) the data is so small that the restore takes less
than one hour, and if (b) the workload is far from 100% ;-)

Since there seem to be multiple views about terminology, it may be
useful to recall the proposed wording from
http://wiki.postgresql.org/wiki/Hot_Standby :

* the first node is called either "Primary" or "Master"

* the second node is called "Standby"

* the Standby is referred to as a "Clone" instead of a "Slave", to
mean that it is an exact copy, which, instead of being built by
repeating the actions of the master, is constructed just by
implementing their effects.

Best regards,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni(dot)ciolli(at)2ndquadrant(dot)it | www.2ndquadrant.it

Robert Haas wrote:
> On Tue, Aug 11, 2009 at 4:07 PM, Josh Berkus<josh(at)agliodbs(dot)com> wrote:
> > So really, the "streaming replication" patch should be called "hot
> > standby",
>
> No. AIUI, hot standby means that when your primary falls over, the
> secondary automatically promotes itself and takes over. It requires
> things like heartbeat monitoring and STONITH and is unrelated to
> anything we currently have under consideration.
>
> > and the "hot standby" patch should be called "read only slaves"?
>
> Yes.
>
> > And *why* can't we call it log-based replication?
>
> Well, we can call it anything we want. For example, up until now
> we've been calling it "hot standby", even though that's clearly wrong.
> :-)

How about "streaming archive logging" for synchronous replication, and
"continuous archive slave" for read-only queries on a warm standby.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Tue, Aug 11, 2009 at 10:13 PM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Aug 11, 2009 at 4:07 PM, Josh Berkus<josh(at)agliodbs(dot)com> wrote:
>> So really, the "streaming replication" patch should be called "hot
>> standby",
>
> No.  AIUI, hot standby means that when your primary falls over, the
> secondary automatically promotes itself and takes over.

No! This is *not* what "hot standby" means, at least not in the Oracle world.

The "hot" in "hot standby" is not a reference to the hot backups or
replication behaviour. It means to the fact that the server is able to
take queries. Ie, It's a living breathing server, not one in some kind
of half-alive state like a warm standby server.

Essentially "hot" vs "warm" versus uh, "plain old standby server"
refer to how alive the server is. A traditional standby server was a
machine which was available to take over after a restore. A warm
standby was one that was constantly replaying logs and could be given
life quickly. A hot standby was actually alive.

I think the term "warm standby" and "hot standby" were actually by
analogy to the older term "hot spare" which referred to a machine
which was on and hooked up and ready to go as opposed to one which was
in the cupboard and could be deployed after manual intervention.

>> and the "hot standby" patch should be called "read only slaves"?
>
> Yes.
>
>> And *why* can't we call it log-based replication?
>
> Well, we can call it anything we want.  For example, up until now
> we've been calling it "hot standby", even though that's clearly wrong.
> :-)

"log based replication", "read-only slaves", and "hot standby" are all
100% accurate descriptions of what the hot standby patch enables. I do
like "read only slaves" because it's the most precise and meaningful.

By comparison, it's not clear whether "log based replication" is what
we've had since 8.0 or whether it's multi-master read-write
replication. And "hot standby" is buzzwordy and depends on Oracle
experience to acquire any meaning.

When we have sync replication you'll also have to distinguish whether
the slave/standby/replica are sync slaves or async slaves and if
they're async what asynchronous mode they're in, streaming or
file-based. Using "hot" to describe those aspects would be horribly
confusing to Oracle users.

--
greg
http://mit.edu/~gsstark/resume.pdf

As I see it we potentially have the following modes to deal with:

Archive file mode asynchronous archive
Archive file mode asynchronous standby slave
Streaming mode asynchronous standby slave
Streaming mode synchronous standby slave
Archive file mode asynchronous read-only slave
Streaming mode asynchronous read-only slave
Streaming mode synchronous read-only slave

By "standby slave" I mean a server which is constantly in recovery
mode but isn't open for connections. This is what we (and Oracle) have
been calling a warm standby. By "read-only slave" I mean a server
which is open for connections and can handle read-only queries, which
as I mentioned Oracle calls a hot standby. Note that *all* of these
are "log-based replication".

I'm not actually certain we can handle streaming synchronous mode to a
standby slave. Does the slave need to have connections enabled to
handle feeding wal sync status to the master?

I don't see any particular reason to come up with names for each of
these combination of modes. I'm pretty happy just saying there are
three different configuration options and certain options depend on
other options so only certain combinations are legal.

--
greg

On Tue, Aug 11, 2009 at 9:44 PM, Greg Stark<gsstark(at)mit(dot)edu> wrote:
> On Tue, Aug 11, 2009 at 10:13 PM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Aug 11, 2009 at 4:07 PM, Josh Berkus<josh(at)agliodbs(dot)com> wrote:
>>> So really, the "streaming replication" patch should be called "hot
>>> standby",
>>
>> No.  AIUI, hot standby means that when your primary falls over, the
>> secondary automatically promotes itself and takes over.
>
> No! This is *not* what "hot standby" means, at least not in the Oracle world.

I'm perplexed by this. For example: http://en.wikipedia.org/wiki/Hot_standby

Admittedly, wikipedia is not an authoritative source, but I've always
understood cold/warm/hot just as Peter described them upthread. Cold
means it's on the shelf. Warm means it's plugged in, but you have to
have to do something to get it going. Hot means it just takes over
when needed.

But of course I guess Oracle can call their features what they want to...

> "log based replication", "read-only slaves", and "hot standby" are all
> 100% accurate descriptions of what the hot standby patch enables. I do
> like "read only slaves" because it's the most precise and meaningful.

Me too.

...Robert

On 08/11/2009 11:19 PM, Robert Haas wrote:
> On Tue, Aug 11, 2009 at 9:44 PM, Greg Stark<gsstark(at)mit(dot)edu> wrote:
>
>> No! This is *not* what "hot standby" means, at least not in the Oracle world.
>>
>
> I'm perplexed by this. For example: http://en.wikipedia.org/wiki/Hot_standby
>
> Admittedly, wikipedia is not an authoritative source, but I've always
> understood cold/warm/hot just as Peter described them upthread. Cold
> means it's on the shelf. Warm means it's plugged in, but you have to
> have to do something to get it going. Hot means it just takes over
> when needed.
>
> But of course I guess Oracle can call their features what they want to...
>

To further confuse things, the "temperature" might apply to only a
particular aspect of the solution. For example, "hot swappable disk
drives" are drives that probably do sit on a shelf until they are
needed, and the "hot" aspect only implies that the server does not need
to be shut down to install the drives, and initialize them for service. :-)

For databases, people seem to be associating "hot" with the ability to
issue read only queries. As somebody else said - under a definition of
hot that includes read-only clones, pg_dump/pg_restore could be
considered a "hot standby" strategy.

I don't agree with that definition. For the clone to be able to perform
read-only queries does not imply "hot" nor does it imply "standby". It
implies "slave". The original poster correctly raised this concern.

For myself, I associate "hot" to mean "ready to replace the master",
which implies that the data is up-to-date or nearly up-to-date, and
implies that the server is within a bit toggle of accepting mastership
of the data and serving ALL queries that the master would serve. Key to
this is "nearly up-to-date" (requires some sort of streaming) AND "ALL
queries" (not just read queries!).

If the server happens to be able to do read queries while it is waiting
in standby more - that's convenient and could be useful to somebody, but
that's not the value of a "hot standby" - that's the value of a
"read-only slave". The feature being provided is not "hot standby".

In the case of Oracle, I believe their "hot standby" provides the nearly
up-to-date, and the capability to switch over, which satisfies my
requirements. It might *also* allow read-only slave for the standby, but
that's just convenience - it's not really part of the definition or
expectation of "hot standby".

>> "log based replication", "read-only slaves", and "hot standby" are all
>> 100% accurate descriptions of what the hot standby patch enables. I do
>> like "read only slaves" because it's the most precise and meaningful.
>>
>
> Me too.
>

Read only slave works for me.

Cheers,
mark

--
Mark Mielke<mark(at)mielke(dot)cc>

Robert Haas wrote:
> I have also long argued that "Synchronous Replication" should really
> be called "Streaming Replication".

+1

Regards

Markus Wanner

On Wed, Aug 12, 2009 at 4:19 AM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Aug 11, 2009 at 9:44 PM, Greg Stark<gsstark(at)mit(dot)edu> wrote:
>> No! This is *not* what "hot standby" means, at least not in the Oracle world.
>
> I'm perplexed by this.  For example: http://en.wikipedia.org/wiki/Hot_standby

Well that just links to "Hot Spare" which is a term which existed long
before Oracle implemented hot standby or even warm standby for that
matter.

--
greg
http://mit.edu/~gsstark/resume.pdf

On Tue, Aug 11, 2009 at 11:19:18PM -0400, Robert Haas wrote:
> On Tue, Aug 11, 2009 at 9:44 PM, Greg Stark<gsstark(at)mit(dot)edu> wrote:
> > On Tue, Aug 11, 2009 at 10:13 PM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
> >> On Tue, Aug 11, 2009 at 4:07 PM, Josh Berkus<josh(at)agliodbs(dot)com> wrote:
> >>> So really, the "streaming replication" patch should be called "hot
> >>> standby",
> >>
> >> No.  AIUI, hot standby means that when your primary falls over, the
> >> secondary automatically promotes itself and takes over.
> >
> > No! This is *not* what "hot standby" means, at least not in the Oracle world.
>
> I'm perplexed by this. For example: http://en.wikipedia.org/wiki/Hot_standby
>
> Admittedly, wikipedia is not an authoritative source, but I've always
> understood cold/warm/hot just as Peter described them upthread. Cold
> means it's on the shelf. Warm means it's plugged in, but you have to
> have to do something to get it going. Hot means it just takes over
> when needed.

After all this, perhaps we can at least conclude that calling it "cold",
"warm", or "hot" anything is confusing, because no one can agree on what that
means. I propose we leave off finding a naming that includes temperature.

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com

Greg Stark <gsstark(at)mit(dot)edu> wrote:

> I'm not actually certain we can handle streaming synchronous mode to
> a standby slave. Does the slave need to have connections enabled to
> handle feeding wal sync status to the master?

I thought there were major concerns about the interaction of those
read-only queries with the replicated database transactions in
synchronous mode, too. Following threads on the topic has left me a
little dubious that it can be truly synchronous, in the sense that it
must commit to the clone before the master returns an indication of
success to the client. Are we still shooting for that or has
"synchronous" become shorthand for "we'll try really hard to keep the
lag minimal when we can"?

> I don't see any particular reason to come up with names for each of
> these combination of modes. I'm pretty happy just saying there are
> three different configuration options and certain options depend on
> other options so only certain combinations are legal.

Sounds reasonable to me.

-Kevin

Mark Mielke wrote:
> To further confuse things, the "temperature" might apply to only a
> particular aspect of the solution. For example, "hot swappable disk
> drives" are drives that probably do sit on a shelf until they are
> needed, and the "hot" aspect only implies that the server does not need
> to be shut down to install the drives, and initialize them for service. :-)
>
> For databases, people seem to be associating "hot" with the ability to
> issue read only queries. As somebody else said - under a definition of
> hot that includes read-only clones, pg_dump/pg_restore could be
> considered a "hot standby" strategy.
>
> I don't agree with that definition. For the clone to be able to perform
> read-only queries does not imply "hot" nor does it imply "standby". It
> implies "slave". The original poster correctly raised this concern.

Agreed. I think by definition, "standby" is "standing by", meaning it
isn't doing anything, so I don't see how a read-only system could be a
standby. I agree "slave" is a better name.

I understand that Oracle uses the terms differently but I assume their
terms were chosen for historical/marketing reasons, and I am not sure
following Oracle is a good idea if their terms are confusing for
non-Oracle folks.

This reminds me of the terminology change we made when we added
point-in-time recovery. At some point we started documenting the
process of "continuous archiving" separately from the process of
"point-in-time recovery". I think that served us well because once
pg_standby was available, we had the possibility of continuous-archiving
happening without the possibility for point-in-time recovery because the
standby was always current.

"Continuous archive slave" might be the most accurate terminology; that
seems the clearest, and people won't have to ask "what is that, exactly".

The streaming WAL log feature should probably be called "streaming
continuous archiving". That does allow the possibility of having a
"streaming continuous archving slave".

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +