Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
6346355a
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,发现更多精彩内容 >>
提交
6346355a
编写于
11月 22, 2006
作者:
B
Bruce Momjian
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Wording and term clarification for HA docs, per Markus Schiltknecht.
上级
84151d06
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
24 addition
and
22 deletion
+24
-22
doc/src/sgml/high-availability.sgml
doc/src/sgml/high-availability.sgml
+24
-22
未找到文件。
doc/src/sgml/high-availability.sgml
浏览文件 @
6346355a
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.1
1 2006/11/22 04:01:40
momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.1
2 2006/11/22 17:36:52
momjian Exp $ -->
<chapter id="high-availability">
<title>High Availability and Load Balancing</title>
...
...
@@ -49,13 +49,13 @@
meaning that a data-modifying transaction is not considered
committed until all servers have committed the transaction. This
guarantees that a failover will not lose any data and that all
load-balanced servers will return consistent results
with little
propagation delay. Asynchronous updating has a delay between the
t
ime of commit and its propagation to the other servers, opening
the possibility that some transactions might be lost in the switch
t
o a backup server, and that load balanced servers might return
slightly stale results. Asynchronous communication is used whe
n
synchronous would be too slow.
load-balanced servers will return consistent results
no matter
which server is queried. Asynchronous updating has a delay between
t
he time of commit and its propagation to the other servers,
opening the possibility that some transactions might be lost in
t
he switch to a backup server, and that load balanced servers
might return slightly stale results. Asynchronous communicatio
n
is used when
synchronous would be too slow.
</para>
<para>
...
...
@@ -110,7 +110,7 @@ https://forge.continuent.org/pipermail/sequoia/2006-November/004070.html
Oracle RAC is a shared disk approach and just send cache invalidations
to other nodes but not actual data. As the disk is shared, data is
only commited once to disk and there is a distributed locking
only commit
t
ed once to disk and there is a distributed locking
protocol to make nodes agree on a serializable transactional order.
-->
...
...
@@ -178,29 +178,29 @@ protocol to make nodes agree on a serializable transactional order.
using two-phase commit (<xref linkend="sql-prepare-transaction"
endterm="sql-prepare-transaction-title"> and <xref
linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">.
Pgpool
is
an example of this type of replication.
Pgpool
and Sequoia are
an example of this type of replication.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Synchonous Multi-Master Replication</term>
<term>Synch
r
onous Multi-Master Replication</term>
<listitem>
<para>
In synchonous multi-master replication, each server can accept
In synch
r
onous multi-master replication, each server can accept
write requests, and modified data is transmitted from the
original server to every other server before each transaction
commits. Heavy write activity can cause excessive locking,
leading to poor performance. In fact, write performance is
often worse than that of a single server. Read requests can
be sent to any server. Some implementations use
cluster-wide
shared memory or shared disk to reduce the communication
overhead. Clustering is best for mostly read workloads, though
its big advantage is that any server can accept write requests
— there is no need to partition workloads between master
and slave servers, and because the data changes are sent from
one
server to another, there is no problem with non-deterministic
be sent to any server. Some implementations use
shared disk
to reduce the communication overhead. Synchronous multi-master
replication is best for mostly read workloads, though its big
advantage is that any server can accept write requests —
there is no need to partition workloads between master and
slave servers, and because the data changes are sent from one
server to another, there is no problem with non-deterministic
functions like <function>random()</>.
</para>
...
...
@@ -222,9 +222,11 @@ protocol to make nodes agree on a serializable transactional order.
<para>
For servers that are not regularly connected, like laptops or
remote servers, keeping data consistent among servers is a
challenge. One simple solution is to allow each server to
modify the data, and have periodic communication compare
databases and ask users to resolve any conflicts.
challenge. Using asynchronous multi-master replication, each
server works independently, and periodically communicates with
the other servers to identify conflicting transactions. The
conflicts can be resolved by users or conflict resolution rules.
rules.
</para>
</listitem>
</varlistentry>
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录