Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
1026be15
G
Gpdb
项目概览
Greenplum
/
Gpdb
通知
7
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
Gpdb
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
1026be15
编写于
2月 12, 2010
作者:
H
Heikki Linnakangas
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Clean up Streaming Replication documentation a little bit. A lot more
needs to be done, but it's a step forward..
上级
54cbd175
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
41 addition
and
33 deletion
+41
-33
doc/src/sgml/high-availability.sgml
doc/src/sgml/high-availability.sgml
+41
-33
未找到文件。
doc/src/sgml/high-availability.sgml
浏览文件 @
1026be15
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.4
0 2010/02/09 16:50:25
heikki Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.4
1 2010/02/12 08:28:44
heikki Exp $ -->
<chapter id="high-availability">
<title>High Availability, Load Balancing, and Replication</title>
...
...
@@ -764,7 +764,7 @@ if (!triggered)
<para>
<productname>PostgreSQL</> includes a simple streaming replication
mechanism, which lets the standby server to stay more up-to-date than
file-based
replication
allows. The standby connects to the primary
file-based
log shipping
allows. The standby connects to the primary
and the primary starts streaming WAL records from where the standby
left off, and continues streaming them as they are generated, without
waiting for the WAL file to be filled. So with streaming replication,
...
...
@@ -805,20 +805,17 @@ if (!triggered)
<listitem>
<para>
Set up connections and authentication so that the standby server can
successfully connect to the pseudo <literal>replication</> database of
the primary server (see
<xref linkend="streaming-replication-authentication">). Ensure that
<xref linkend="guc-listen-addresses"> and <filename>pg_hba.conf</> are
configured appropriately on the primary.
Set <xref linkend="guc-listen-addresses"> and authentication options
(see <filename>pg_hba.conf</>) so that the standby server can connect to
the pseudo <literal>replication</> database of the primary server (see
<xref linkend="streaming-replication-authentication">).
</para>
<para>
On systems that support the keepalive socket option, setting
<xref linkend="guc-tcp-keepalives-idle">,
<xref linkend="guc-tcp-keepalives-interval"> and
<xref linkend="guc-tcp-keepalives-count"> helps you to find the
troubles with replication (e.g., the network outage or the failure of
the standby server) as soon as possible.
<xref linkend="guc-tcp-keepalives-count"> helps the master to notice
a broken connection promptly.
</para>
</listitem>
<listitem>
...
...
@@ -827,13 +824,6 @@ if (!triggered)
(see <xref linkend="guc-max-wal-senders"> for details).
</para>
</listitem>
<listitem>
<para>
Enable WAL archiving in the primary server because we need to make a base
backup of it later (see <xref linkend="guc-archive-mode"> and
<xref linkend="guc-archive-command"> for details).
</para>
</listitem>
<listitem>
<para>
Start the <productname>PostgreSQL</> server on the primary.
...
...
@@ -850,13 +840,12 @@ if (!triggered)
</listitem>
<listitem>
<para>
Set up WAL archiving, connections and authentication like the primary
server, because the standby server might work as a primary server after
failover. Ensure that your settings are consistent with the
<emphasis>future</> environment after the primary and the standby
server are interchanged by failover. If you're setting up the standby
server for e.g reporting purposes, with no plans to fail over to it,
configure the standby accordingly.
If you're setting up the standby server for high availability purposes,
set up WAL archiving, connections and authentication like the primary
server, because the standby server will work as a primary server after
failover. If you're setting up the standby server for e.g reporting
purposes, with no plans to fail over to it, configure the standby
accordingly.
</para>
</listitem>
<listitem>
...
...
@@ -871,12 +860,25 @@ if (!triggered)
<listitem>
<para>
Specifies whether to start the <productname>PostgreSQL</> server as
a standby. If this parameter is <literal>on</>, the streaming
replication is enabled and the standby server will try to connect
to the primary to receive and apply WAL records continuously. The
default is <literal>off</>, which allows only an archive recovery
without replication. So, streaming replication requires this
parameter to be explicitly set to <literal>on</>.
a standby. If this parameter is <literal>on</>, the server will
not end recovery when the end of archived WAL is reached, but
will keep trying to continue recovery using <varname>restore_command</>
and by connecting to the primary server as specified by
<varname>primary_conninfo</> setting.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>restore_command</varname> (<type>string</type>)</term>
<term><varname>restore_end_command</varname> (<type>string</type>)</term>
<listitem>
<para>
In standby-mode, <varname>restore_command</> (and <varname>restore_end_command</>) is set to a
simple command or script like in PITR. pg_standby or similar tools
that wait for the next WAL file to arrive, cannot be used with
streaming replication, as the server handles retries and waiting
itself. Set <varname>restore_command</> as you would if you were
recovering using a Continuous archiving backup (see <xref linkend="backup-pitr-recovery">).
</para>
</listitem>
</varlistentry>
...
...
@@ -902,16 +904,22 @@ if (!triggered)
the password needs to be set if the primary demands password
authentication.
</para>
<para>
This setting has no effect if <varname>standby_mode</> is <literal>off</>.
</para>
</listitem>
</varlistentry>
<varlistentry id="trigger-file" xreflabel="trigger_file">
<term><varname>trigger_file</varname> (<type>string</type>)</term>
<listitem>
<para>
Specifies a trigger file whose presence
activates the standby.
If no trigger file is specified, the standby never exits
Specifies a trigger file whose presence
ends recovery in the
standby.
If no trigger file is specified, the standby never exits
recovery.
</para>
<para>
This setting has no effect if <varname>standby_mode</> is <literal>off</>.
</para>
</listitem>
</varlistentry>
</variablelist>
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录