复制理念 [英] Replication Ideas

查看:65
本文介绍了复制理念的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

嗨 -


我一直在考虑多主机复制的问题,以及如何使用PostgreSQL进行高可用性的loadballanced集群。这是

我的大纲,我正在寻找关于这个

如何工作的限制的评论。


几个PostgreSQL服务器将共享一个虚拟IP地址,并且它们之间将协调
,它们将充当主地址。出于目的
单个交易的
(但连接可能更容易)。 SELECT

语句由交易主机独家处理,而

写入数据库的任何内容都将发送给所有

" Masters "在每次交易结束时,系统会相互调查

是否全部成功:


1:任何成功通知交易的系统必须

忽略任何未通过交易的系统,直到可以进行恢复。


2:任何未能通知委托交易的系统必须停止

是主人,只要它从集群的任何其他成员那里收到一个签名,该集群表明该成员成功提交了

交易。 br />

3:如果所有节点都没有提交,那么它们都是主人。


恢复将分几步完成:


1:使用pg_dump将数据库复制到失败的系统。

2:当前恢复将从事务日志中完成。

3:这将重复进行,以确保数据库达到
日期。

4:当两个连续恢复已经实现,数据库中没有新的增加的额外恢复,全部已恢复信号被发送到

集群,节点已准备好再次开始处理。 (需要更好的

这样做的方式)。


注意:恢复是问题,我知道。我的模型只是一个起点

点,用于讨论和尝试带来一些东西来讨论对话。


任意想法或建议?


祝福,

Chris Travers

------------- --------------(广播结束)---------------------------

提示8:解释分析是你的朋友

Hi--

I had been thinking of the issues of multimaster replication and how to
do highly available, loadballanced clustering with PostgreSQL. Here is
my outline, and I am looking for comments on the limitations of how this
would work.

Several PostgreSQL servers would share a virtual IP address, and would
coordinate among themselves which will act as "Master" for the purposes
of a single transaction (but connection could be easier). SELECT
statements are handled exclusively by the transaction master while
anything that writes to a database would be sent to all the the
"Masters." At the end of each transaction the systems would poll
eachother regarding whether they were all successful:

1: Any system which is successful in COMMITting the transaction must
ignore any system which fails the transaction untill a recovery can be made.

2: Any system which fails in COMMITting the transaction must cease to
be a master, provided that it recieves a signat from any other member of
the cluster that indicates that that member succeeded in committing the
transaction.

3: If all nodes fail to commit, then they all remain masters.

Recovery would be done in several steps:

1: The database would be copied to the failed system using pg_dump.
2: A current recovery would be done from the transaction log.
3: This would be repeated in order to ensure that the database is up to
date.
4: When two successive restores have been achieved with no new
additions to the database, the "All Recovered" signal is sent to the
cluster and the node is ready to start processing again. (need a better
way of doing this).

Note: Recovery is the problem, I know. my model is only a starting
point for the purposes of discussion and trying to bring something to
the conversation.

Any thoughts or suggestions?

Best Wishes,
Chris Travers
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

推荐答案

周六,2003-08-23 23:27, Chris Travers写道:
On Sat, 2003-08-23 at 23:27, Chris Travers wrote:
嗨 -

我一直在考虑多主机复制的问题,以及如何使用PostgreSQL进行高可用性,loadballanced集群。这是我的大纲,我正在寻找关于这个
如何工作的局限性的评论。

几个PostgreSQL服务器将共享一个虚拟IP地址,并且
它们之间的协调将充当主。出于单一交易的目的(但连接可能更容易)。 SELECT
语句由事务主机独占处理,而写入数据库的任何内容都将发送给所有的Masters。在每次交易结束时,系统会相互调查是否一切都成功:

1:任何成功通知交易的系统都必须忽略任何系统交易失败,直到可以进行恢复。

2:任何未通知交易的系统必须停止作为主人,只要它收到任何其他成员的签名。
表示该成员成功提交
事务的集群。

3:如果所有节点都未能提交,那么它们都将成为主人。

1:使用pg_dump将数据库复制到故障系统。
2:当前恢复将从事务日志中完成。
3:这将重复进行,以确保数据库达到最新状态。
4:当连续两次恢复时,d没有添加新的
atabase,All Recovered信号被发送到
集群,节点已准备好再次开始处理。 (需要一个更好的方法来做到这一点)。

注意:恢复是问题,我知道。我的模型只是一个开始的目的,用于讨论和尝试为谈话带来一些东西。
Hi--

I had been thinking of the issues of multimaster replication and how to
do highly available, loadballanced clustering with PostgreSQL. Here is
my outline, and I am looking for comments on the limitations of how this
would work.

Several PostgreSQL servers would share a virtual IP address, and would
coordinate among themselves which will act as "Master" for the purposes
of a single transaction (but connection could be easier). SELECT
statements are handled exclusively by the transaction master while
anything that writes to a database would be sent to all the the
"Masters." At the end of each transaction the systems would poll
eachother regarding whether they were all successful:

1: Any system which is successful in COMMITting the transaction must
ignore any system which fails the transaction untill a recovery can be made.

2: Any system which fails in COMMITting the transaction must cease to
be a master, provided that it recieves a signat from any other member of
the cluster that indicates that that member succeeded in committing the
transaction.

3: If all nodes fail to commit, then they all remain masters.

Recovery would be done in several steps:

1: The database would be copied to the failed system using pg_dump.
2: A current recovery would be done from the transaction log.
3: This would be repeated in order to ensure that the database is up to
date.
4: When two successive restores have been achieved with no new
additions to the database, the "All Recovered" signal is sent to the
cluster and the node is ready to start processing again. (need a better
way of doing this).

Note: Recovery is the problem, I know. my model is only a starting
point for the purposes of discussion and trying to bring something to
the conversation.




这个模糊地类似于两阶段提交,这是一个正常的分析交易,即sqn多主人

复制。


-

-------------- -------------------------------------------------- -

Ron Johnson,Jr。 ro ********** *@cox.net

美国路易斯安那州杰斐逊


永恒的警惕是自由的代价:权力永远是

从多人偷窃到少数人。必须每天收集流行自由的吗哪,或者它是腐烂的...被赋予权力的手,无论是来自人类的堕落还是精神上的< />
军团,人民的必要敌人。只有通过不断的监督,才能阻止办公室里的民主人士加强成为一个暴君:只有通过不间断的鼓动,人们才能保持
充分清醒的原则是不要让自由在物质繁荣中被扼杀......永远不要看,因为人们可以安静和安全的年龄。在这种专制时期,比如说掩饰着雾气,偷走了自由的镜子

Wendell Phillips

-------- -------------------(广播结束)-------------------------- -

提示5:您是否检查了我们广泛的常见问题解答?

http://www.postgresql.org/docs/faqs/FAQ.html



This is vaguely similar to Two Phase Commit, which is a sine qua
non of distributed transactions, which is the s.q.n. of multi-master
replication.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA

"Eternal vigilance is the price of liberty: power is ever
stealing from the many to the few. The manna of popular liberty
must be gathered each day, or it is rotten... The hand entrusted
with power becomes, either from human depravity or esprit de
corps, the necessary enemy of the people. Only by continual
oversight can the democrat in office be prevented from hardening
into a despot: only by unintermitted agitation can a people be
kept sufficiently awake to principle not to let liberty be
smothered in material prosperity... Never look, for an age when
the people can be quiet and safe. At such times despotism, like
a shrouding mist, steals over the mirror of Freedom"
Wendell Phillips
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html


周一,2003-08-25 12:06,Chris Travers写道:
On Mon, 2003-08-25 at 12:06, Chris Travers wrote:
Ron Johnson写道:
Ron Johnson wrote:
这与两阶段提交模糊地相似,这是一个正弦的非分布式交易,这是sqn多主人
复制。
This is vaguely similar to Two Phase Commit, which is a sine qua
non of distributed transactions, which is the s.q.n. of multi-master
replication.



我可能错了,但如果我没记错的话,其中一个问题是
标准2-阶段提交是指如果一台服务器出现故障,其他主服务器无法提交其事务。这将使群集数据库服务器的停机时间相当于其所有节点的总停机时间。这是一个真正的问题。当然,我对两阶段提交的理解可能不正确,在这种情况下,如果有人能指出我错在哪里,我将不胜感激。



I may be wrong, but if I recall correctly, one of the problems with a
standard 2-phase commit is that if one server goes down, the other
masters cannot commit their transactions. This would make a clustered
database server have a downtime equivalent to the total downtime of all
of its nodes. This is a real problem. Of course my understanding of
Two Phase Commit may be incorrect, in which case, I would appreciate it
if someone could point out where I am wrong.




请注意,我并不是说暗示2PC足以实现

MM。如果2PC失败,DBMS设计师必须决定做什么(比如排队等待
更改)。


-

------------------------------------------------- ----------------

Ron Johnson,Jr。 ro *********** @ cox.net

美国路易斯安那州杰斐逊


"我们的电脑和电脑颜色相同。

转换应该没问题!

未知

---------------- -----------(播出结束)---------------------------

提示1:订阅和取消订阅命令转至 ma*******@postgresql.org



Note that I didn''t mean to imply that 2PC is sufficient to implement
M-M. The DBMS designer(s) must decide what to do (like queue up
changes) if 2PC fails.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA

"Our computers and their computers are the same color. The
conversion should be no problem!"
Unknown
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org


2003年8月25日星期一上午10:06:22 -0700,Chris Travers写道:
On Mon, Aug 25, 2003 at 10:06:22AM -0700, Chris Travers wrote:
Ron Johnson写道:
Ron Johnson wrote:
这与两阶段提交模糊地相似,这是一个正常的非分布式事务,即sqn多主人复制。
This is vaguely similar to Two Phase Commit, which is a sine qua
non of distributed transactions, which is the s.q.n. of multi-master
replication.



我可能错了,但如果我没记错的话,
标准两阶段提交的问题之一是如果一台服务器发生故障,其他主服务器无法提交交易。



I may be wrong, but if I recall correctly, one of the problems with a
standard 2-phase commit is that if one server goes down, the other
masters cannot commit their transactions.




在讨论之前,请你阅读相关的工作吗? >
到Postgres-r?它与2PC AFAIK的动物大不相同。


-

Alvaro Herrera(< alvherre [a] dcc.uchile.cl>)

现在硬盘上的扇区按顺时针方向运行,但我听说有一个传言说,你可以通过逆时针运行来增加0.2%的吞吐量。

这是值得的。推荐"。 (Gerry Pourwelle)


---------------------------(播出结束) - -------------------------

提示3:如果通过Usenet发布/阅读,请发送相应的
subscribe-nomail命令 ma*******@postgresql.org 以便您的

消息可以干净利落地到达邮件列表



Before the discussion goes any further, have you read the work related
to Postgres-r? It''s a substantially different animal from 2PC AFAIK.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Right now the sectors on the hard disk run clockwise, but I heard a rumor that
you can squeeze 0.2% more throughput by running them counterclockwise.
It''s worth the effort. Recommended." (Gerry Pourwelle)

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly


这篇关于复制理念的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆