Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
8c556ce1
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,发现更多精彩内容 >>
提交
8c556ce1
编写于
11月 22, 2006
作者:
B
Bruce Momjian
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
New async/sync multi-master headings for docs.
上级
3b031358
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
19 addition
and
19 deletion
+19
-19
doc/src/sgml/high-availability.sgml
doc/src/sgml/high-availability.sgml
+19
-19
未找到文件。
doc/src/sgml/high-availability.sgml
浏览文件 @
8c556ce1
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.1
0 2006/11/22 04:00:19
momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.1
1 2006/11/22 04:01:40
momjian Exp $ -->
<chapter id="high-availability">
<title>High Availability and Load Balancing</title>
...
...
@@ -133,11 +133,11 @@ protocol to make nodes agree on a serializable transactional order.
</varlistentry>
<varlistentry>
<term>Master
/
Slave Replication</term>
<term>Master
-
Slave Replication</term>
<listitem>
<para>
A master
/
slave replication setup sends all data modification
A master
-
slave replication setup sends all data modification
queries to the master server. The master server asynchronously
sends data changes to the slave server. The slave can answer
read-only queries while the master server is running. The
...
...
@@ -184,24 +184,24 @@ protocol to make nodes agree on a serializable transactional order.
</varlistentry>
<varlistentry>
<term>Multi-Master Replication</term>
<term>
Synchonous
Multi-Master Replication</term>
<listitem>
<para>
In
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 functions like
<function>random()</>.
In
synchonous 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
functions like
<function>random()</>.
</para>
<para>
...
...
@@ -216,7 +216,7 @@ protocol to make nodes agree on a serializable transactional order.
</varlistentry>
<varlistentry>
<term>
Multi-Master With Conflict Resolu
tion</term>
<term>
Asynchronous Multi-Master Replica
tion</term>
<listitem>
<para>
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录