Restructure streaming docs so streaming seems more integrated in the

paragraphs, per suggestion from Dan Birken.
This commit is contained in:
Bruce Momjian 2011-01-26 19:54:41 -05:00
parent 7ab6f2da23
commit 81c48aeaa8
1 changed files with 8 additions and 7 deletions

View File

@ -486,18 +486,19 @@ protocol to make nodes agree on a serializable transactional order.
<para> <para>
Directly moving WAL records from one database server to another Directly moving WAL records from one database server to another
is typically described as log shipping. <productname>PostgreSQL</> is typically described as log shipping. <productname>PostgreSQL</>
implements file-based log shipping, which means that WAL records are implements file-based log shipping by transfering WAL records
transferred one file (WAL segment) at a time. WAL files (16MB) can be one file (WAL segment) at a time. WAL files (16MB) can be
shipped easily and cheaply over any distance, whether it be to an shipped easily and cheaply over any distance, whether it be to an
adjacent system, another system at the same site, or another system on adjacent system, another system at the same site, or another system on
the far side of the globe. The bandwidth required for this technique the far side of the globe. The bandwidth required for this technique
varies according to the transaction rate of the primary server. varies according to the transaction rate of the primary server.
Record-based log shipping is also possible with streaming replication Record-based log shipping is more granular and streams WAL changes
(see <xref linkend="streaming-replication">). incrementally over a network connection (see <xref
linkend="streaming-replication">).
</para> </para>
<para> <para>
It should be noted that the log shipping is asynchronous, i.e., the WAL It should be noted that log shipping is asynchronous, i.e., the WAL
records are shipped after transaction commit. As a result, there is a records are shipped after transaction commit. As a result, there is a
window for data loss should the primary server suffer a catastrophic window for data loss should the primary server suffer a catastrophic
failure; transactions not yet shipped will be lost. The size of the failure; transactions not yet shipped will be lost. The size of the
@ -505,8 +506,8 @@ protocol to make nodes agree on a serializable transactional order.
<varname>archive_timeout</varname> parameter, which can be set as low <varname>archive_timeout</varname> parameter, which can be set as low
as a few seconds. However such a low setting will as a few seconds. However such a low setting will
substantially increase the bandwidth required for file shipping. substantially increase the bandwidth required for file shipping.
If you need a window of less than a minute or so, consider using Streaming replication (see <xref linkend="streaming-replication">)
streaming replication (see <xref linkend="streaming-replication">). allows a much smaller window of data loss.
</para> </para>
<para> <para>