复制 [英] Replication
问题描述
我刚看到Mysql将在月底提出一个带有自动恢复的完整的
同步复制系统。 /> http://www.mysql.com/products/cluster/
我们需要看看何时会发布稳定版本.....
我使用PostgreSQL，我希望在< br $>
PostgreSQL。
有何评论？ （请不要火焰）
Cordialement，
Jean-GérardPailloncy
------ ---------------------（广播结束）------------------------ ---
提示2：您可以使用取消注册命令一次性取消所有列表
（将注册YourEmailAddressHere发送到 ma ******* @ postgresql.org ）
Hi,
I just see that Mysql will propose at the end of the month a full
synchronous replication system with auto-recovery.
http://www.mysql.com/products/cluster/
We need to see when stable version would be released.....
I use PostgreSQL and I would appreciate to have the same features in
PostgreSQL.
Any comments ? (no flame, please)
Cordialement,
Jean-Gérard Pailloncy
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)
推荐答案
2004年4月20日星期二上午11:26:24 + 0200，Pailloncy Jean-G？rard写道：
On Tue, Apr 20, 2004 at 11:26:24AM +0200, Pailloncy Jean-G?rard wrote:
我只是看到Mysql将在月底提出一个具有自动恢复功能的完整
同步复制系统。
好吧，有点儿。它似乎是来自MySQL的另一个80/20解决方案
（tm）。
它看起来像是基于新的表类型。它将所有内容存储在内存中，然后以异步方式写出来。从可靠性的角度来看，这对我来说非常危险：如果
盒子在写入完成之前就死了怎么办？ （并且不要告诉我有关
超级冗余高可用性硬件的信息。我已经__所有了。所有
硬件很糟糕; HA的东西只是糟透了更高的价格。）
此外，它不支持其他表格类型。如果你有一个跨越三种表类型并且硬件故障的
交易，我不想要想要清理可怕的混乱。
我很害怕我同意最近发布的Oracle Veep访谈：
这并不代表对核心ORAC的任何严重挑战
市场。
我使用PostgreSQL，我很高兴在PostgreSQL中拥有相同的功能。
Hi,
I just see that Mysql will propose at the end of the month a full
synchronous replication system with auto-recovery.
Well, sort of. It seems to be yet another 80/20 Solution From MySQL
(tm).
It looks like it''s based on a new table type. It stores everything
in memory, and then writes out asynchronously. This strikes me as
pretty dangerous from the point of view of reliability: what if the
box dies before the write is complete? (And don''t tell me about
super-redundant high-availability hardware. I _have_ all that. All
hardware sucks; HA stuff just sucks less often at a higher price.)
Also, it doesn''t support the other table types. I don''t want to
contemplate the horrible mess you''d have to clean up if you had a
transaction crossing three table types and get a hardware failure.
I''m afraid I agree with the recently-posted Oracle Veep interview:
this does not represent any serious challenge to the core ORAC
market.
I use PostgreSQL and I would appreciate to have the same features in
PostgreSQL.
当然，我也一样。和Jan Wieck谈谈他打算做什么
关于它，也许还考虑支持开发工作;-)
A $ / $
-
Andrew Sullivan | aj*@crankycanuck.ca
------------- --------------（广播结束）---------------------------
提示3：如果通过Usenet发布/阅读，请发送适当的
subscribe-nomail命令到 ma ******* @ postgresql.org ，以便您的
消息可以干净地通过邮件列表
Sure, so would I. Talk to Jan Wieck about what he plans to do
about it, and maybe consider supporting that development work too ;-)
A
--
Andrew Sullivan | aj*@crankycanuck.ca
---------------------------(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
Andrew Sullivan写道：
Andrew Sullivan wrote:
2004年4月20日星期二上午11:26:24 + 0200，Pailloncy Jean-G？rard写道：
On Tue, Apr 20, 2004 at 11:26:24AM +0200, Pailloncy Jean-G?rard wrote:
我只是看到Mysql将在月底提出一个具有自动恢复功能的完整
同步复制系统。
嗯，有点像。它似乎是另一个来自MySQL的80/20解决方案
（tm）。
它看起来像是基于一种新的表类型。它将所有内容存储在内存中，然后异步写出。从可靠性的角度来看，这对我来说非常危险：如果
盒子在写入完成之前就死了怎么办？ （并且不要告诉我有关超冗余高可用性硬件的信息。我已经完成了所有这些。所有硬件都很糟糕; HA的东西只是以较高的价格吸收较少的东西。）
此外，它不支持其他表类型。如果你的交易涉及三种类型并且硬件故障，我不想考虑你必须清理的可怕的混乱。
恐怕我同意最近发布的Oracle Veep采访：
这并不代表对核心ORAC市场的任何严峻挑战。
Hi,
I just see that Mysql will propose at the end of the month a full
synchronous replication system with auto-recovery.
Well, sort of. It seems to be yet another 80/20 Solution From MySQL
(tm).
It looks like it''s based on a new table type. It stores everything
in memory, and then writes out asynchronously. This strikes me as
pretty dangerous from the point of view of reliability: what if the
box dies before the write is complete? (And don''t tell me about
super-redundant high-availability hardware. I _have_ all that. All
hardware sucks; HA stuff just sucks less often at a higher price.)
Also, it doesn''t support the other table types. I don''t want to
contemplate the horrible mess you''d have to clean up if you had a
transaction crossing three table types and get a hardware failure.
I''m afraid I agree with the recently-posted Oracle Veep interview:
this does not represent any serious challenge to the core ORAC
market.
引用MySQL（tm）关于MySQL（tm）集群（tm）的常见问题解答
http://www.mysql.com/products/cluster/faq.html
< quote>
问：MySQL Cluster是否可以与MyISAM和InnoDB配合使用？
答：MySQL Cluster可以包含MyISAM和InnoDB存储引擎。
这些，高可用性数据必须驻留在MySQL Cluster
存储引擎中。
MySQL Cluster数据库节点存储MySQL Cluster数据，MySQL服务器
解析SQL并将请求发送到数据库节点。 MySQL服务器没有
存储属于MySQL Cluster存储引擎的任何数据。
InnoDB / MyISAM数据仍存储在MySQL服务器中，可以是以标准方式使用
，但该数据未被复制，因此从连接到MySQL的任何其他MySQL服务器看不到数据
群集。
< / quote>
这是另一个可用于SQL查询的表处理程序
发动机。大声兜售并在所有可用频道上MySQL Cluster
将世界上最流行的开源数据库与
并行服务器相结合自然会导致误解，所有的外键，MVCC和回滚等新功能现在将在多个高可用节点上水平扩展。这不是真的。
NDB表类型不支持外键，约束，
触发器。它确实支持事务，但是这些事务与InnoDB表处理程序的事务不同，因此在不同的表类型中，一个
COMMIT不是原子的。 MySQL喜欢指出，SAP R / 3这样的大型系统在数据库级别上不使用引用完整性。到目前为止这是真的，但作为一名SAP基础顾问多年来一直工作了很多年，我可以告诉你原因
不是性能。 SAP通过在数据库抽象层实现自己的自定义完整性控制和数据域系统（b
）来多次花费这些努力，以获得数据库供应商的独立性。那个
抽象层比PHP和Apache一样大，所以这个例子是恕我直言，与典型的MySQL用户完全无关。
此外，NDB表类型基于内存中的分区存储
引擎（速度来自哪里）并获得高可用性
一个人需要至少两倍于RAM中的完整数据库大小（加上一些
的操作系统和其他开销），以及更高的因素来真正实现
99.999％ 。所以，为了让我们说一个100 GB的数据库，我们正在谈论
大约220-240 GB的RAM。现在这8个盒子每个32GB？据我所采访的MySQL顾问说，真正的瓶颈是
网络，所以这些盒子喜欢比千兆以太网更好。作为一个
骨干。这是一些不错的硬件要求，请确保你的下一个购物清单上有
a叉车。
所以NDB在底线上得到的是另一个表格类型
对某些特殊情况很有用。我可以想象例如系统
读取传感器数据，这些数据无法被中断。传感器通常
不太关心参照完整性，所以对于日志系统来说这实际上是无关紧要的，现在必须存储数据并更正
之后。我认为对于一个系统来说确实是一个很大的优势，可以在同一个SQL查询引擎中提供可用的b * b b日志数据，其中更多的是b / b
复杂的应用程序的部分内容实现了。但是
就是这样，通过将日志数据大量加载到常规数据库表中，可以很容易地实现这一点。除非确实需要
能力来查询和分析最后一秒的logdata，否则运行
多个100千伏的硬件和网络设备仅用于
内存集群解决方案的乐趣有点矫枉过正。
作为产品策略的Oracle副总裁，Ken Jacobs指出：MySQL是
试图通过获得
第三方技术来解决某些产品缺陷。这并不意味着他们现在有一个产品，即b $ b与Oracle甚至其他数据库产品竞争，无论是否b
聚集在一起。绝对正确的雅各布先生，他们之前通过添加InnoDB完成了这个
，现在他们添加了一些有限的多主机
复制功能。但是，不是开发一个包含InnoDB表处理程序的集成
解决方案，而这个
功能将非常有用，他们只是将第五个轮子添加到购物车中。
Quoting from the MySQL(tm) FAQ about MySQL(tm) Cluster(tm) avaliable at
http://www.mysql.com/products/cluster/faq.html
<quote>
Q: Does MySQL Cluster work with MyISAM and InnoDB?
A: MySQL Cluster can include the MyISAM and InnoDB storage engines. Of
these, the high-availability data must reside in the MySQL Cluster
storage engine.
The MySQL Cluster DB node stores MySQL Cluster data, the MySQL Server
parses SQL and sends requests to the DB node. The MySQL Server does not
store any data belonging to the MySQL Cluster storage engine.
InnoDB/MyISAM data is still stored in the MySQL server and can be used
in the standard way, but that data is not replicated, so that data is
not visible from any other MySQL server that is connected to the MySQL
Cluster.
</quote>
It is just another table handler made available for the SQL query
engine. Touting loudly and on all available channels that "MySQL Cluster
combines the world''s most popular open source database with a
parallel-server" naturally leads to the misinterpretation that all the
wonderfull new features like foreign keys, MVCC and rollback will now
horizontally scale over multiple, high available nodes. This is not true.
The NDB table type does not have support for foreign keys, constraints,
triggers. It does support transactions, but these transactions are not
the same transactions as the ones of the InnoDB table handler, so a
COMMIT is not atomic across different table types. MySQL likes to point
out that the largest systems like SAP R/3 do not use referential
integrity on the database level. That is true so far, but having worked
for many years as an SAP base consultant I can tell you that the reason
for that is NOT performance. SAP spends that effort multiple times by
implementing their own, custom integrity control and data domain system
in the DB abstraction layer, to gain DB vendor independence. That
abstraction layer is larger than PHP and Apache together, so this
example is IMHO totally irrelevant for the typical MySQL user.
Also, the NDB table type is based on an in-memory, partitioned storage
engine (that''s where the speed comes from) and to get high availablility
one needs at least two times the full database size in RAM (plus some
for the OS and other overhead), and a higher factor to really achieve
the 99.999%. So to serve let''s say a 100 GB database, we''re talking
about 220-240 GB of RAM. Now that''s 8 boxes with 32GB each? And
according to a MySQL consultant I spoke with, the real bottleneck is the
network, so these boxes like to have "better than Gigabit Ethernet" as a
backbone. That are some decent hardware requirements, make sure you have
a forklift on your next shopping list.
So what one gets with NDB on the bottom line is another table type that
is usefull for some special cases. I can imagine for example systems
that read sensor data, which cannot be interrupted. Sensors usually
don''t care much about referential integrity, so for the logging system
this is in fact irrelevant, the data has to be stored now and corrected
later. I think it is indeed a big plus for a system, to make that
logging data available inside the same SQL query engine where the more
complicated bits and pieces of the application are implemented in. But
that is all, and that can pretty easy be achieved by doing bulk-loads of
the log data into regular database tables. Unless one really needs the
ability to query and analyse up to the last second of logdata, running
some multiple 100 kilodollar hardware and network equipment just for the
fun of a memory cluster solution is a bit overkill.
As the Oracle VP of product strategy, Ken Jacobs, pointed out: "MySQL is
trying to address certain product shortcomings by acquiring a
third-party technology. This does not mean they now have a product that
is competitive with Oracle?or even other?database products, whether
clustered or not.". Absolutely right Mr. Jacobs, they have done that
before by adding InnoDB, now they added some limited multimaster
replication capabilities. But instead of developing an integrated
solution that includes the InnoDB table handler, where this
functionality would be usefull, they just added a fifth wheel to the cart.
我使用PostgreSQL，我很高兴在PostgreSQL中拥有相同的功能。
I use PostgreSQL and I would appreciate to have the same features in
PostgreSQL.
当然，我也一样。与Jan Wieck交谈关于他打算做什么
关于它，也许也考虑支持开发工作; - ）
Sure, so would I. Talk to Jan Wieck about what he plans to do
about it, and maybe consider supporting that development work too ;-)
Ken Jacobs进一步说没人有什么完全像Oracle的Real
Application Clusters。这也是对的。然而，好的PostgreSQL由
现在比较SQL功能和独立的DB性能。在
复制时，我们落后2年或更长时间。
现在我们需要将Slony-I项目推出门并让它
稍微解决，可能会在一个以上的版本中得到增强。以此作为基础，我们将开始设计一个同步多主机系统，可以从正在运行的异步复制设置中跳转启动
。所有
这个高可用性 babble是恕我直言，只要
没有办法（重新）从头开始创建一个（失败的）节点而没有
中断。这个功能列在MySQL路线图上
for 5.1 ...所以在2008年的某个地方？ Slony今天就为async master-slave
做了这个。
Jan
-
＃================================================= =====================＃
＃因为错误而得到宽恕比对正确更容易。 ＃
＃让我们打破这个规则 - 请原谅我。 ＃
＃======================================== ========= = Ja******@Yahoo.com ＃
---------------------------（播出结束）-------------- -------------
提示7：别忘了增加免费空间地图设置
Ken Jacobs further said "No one has anything at all like Oracle''s Real
Application Clusters". And that is right too. However good PostgreSQL by
now compares on SQL features and standalone DB performance. On
replication we are 2 years or more behind.
Right now we need to get the Slony-I project out the door and let that
settle a bit and maybe get enhanced over one more release. With that as
the base, we will start designing a synchronous multimaster system that
can be jump-started from a running, asynchronous replication setup. All
this "high-availability" babble is IMHO totally pointless as long as
there is no way of (re)creataing a (failed) node from scratch without
taking an outage. And that functionality is listed on the MySQL roadmap
for 5.1 ... so somewhere in 2008? Slony does that for async master-slave
right today.
Jan
--
#================================================= =====================#
# It''s easier to get forgiveness for being wrong than for being right. #
# Let''s break this rule - forgive me. #
#================================================= = Ja******@Yahoo.com #
---------------------------(end of broadcast)---------------------------
TIP 7: don''t forget to increase your free space map settings
Andrew Sullivan写道：
Andrew Sullivan wrote:
2004年4月20日星期二上午11:26:24 + 0200，Pailloncy Jean-G？rard写道：
On Tue, Apr 20, 2004 at 11:26:24AM +0200, Pailloncy Jean-G?rard wrote:
我只是看到Mysql将在月底提出一个完整的
同步复制系统，并进行自动恢复。
好吧，等等。它似乎是另一个来自MySQL的80/20解决方案
（tm）。
它看起来像是基于一种新的表类型。它将所有内容存储在内存中，然后异步写出。从可靠性的角度来看，这对我来说非常危险：如果
盒子在写入完成之前就死了怎么办？ （并且不要告诉我有关超冗余高可用性硬件的信息。我已经完成了所有这些。所有硬件都很糟糕; HA的东西只是以较高的价格吸收较少的东西。）
此外，它不支持其他表类型。如果你的交易涉及三种类型并且硬件故障，我不想考虑你必须清理的可怕的混乱。
恐怕我同意最近发布的Oracle Veep采访：
这并不代表对核心ORAC市场的任何严峻挑战。
Hi,
I just see that Mysql will propose at the end of the month a full
synchronous replication system with auto-recovery.
Well, sort of. It seems to be yet another 80/20 Solution From MySQL
(tm).
It looks like it''s based on a new table type. It stores everything
in memory, and then writes out asynchronously. This strikes me as
pretty dangerous from the point of view of reliability: what if the
box dies before the write is complete? (And don''t tell me about
super-redundant high-availability hardware. I _have_ all that. All
hardware sucks; HA stuff just sucks less often at a higher price.)
Also, it doesn''t support the other table types. I don''t want to
contemplate the horrible mess you''d have to clean up if you had a
transaction crossing three table types and get a hardware failure.
I''m afraid I agree with the recently-posted Oracle Veep interview:
this does not represent any serious challenge to the core ORAC
market.
引用MySQL（tm）关于MySQL（tm）集群（tm）的常见问题解答
http://www.mysql.com/products/cluster/faq.html
< quote>
问：MySQL Cluster是否可以与MyISAM和InnoDB配合使用？
答：MySQL Cluster可以包含MyISAM和InnoDB存储引擎。
这些，高可用性数据必须驻留在MySQL Cluster
存储引擎中。
MySQL Cluster数据库节点存储MySQL Cluster数据，MySQL服务器
解析SQL并将请求发送到数据库节点。 MySQL服务器没有
存储属于MySQL Cluster存储引擎的任何数据。
InnoDB / MyISAM数据仍存储在MySQL服务器中，可以是以标准方式使用
，但该数据未被复制，因此从连接到MySQL的任何其他MySQL服务器看不到数据
群集。
< / quote>
这是另一个可用于SQL查询的表处理程序
发动机。大声兜售并在所有可用频道上MySQL Cluster
将世界上最流行的开源数据库与
并行服务器相结合自然会导致误解，所有的外键，MVCC和回滚等新功能现在将在多个高可用节点上水平扩展。这不是真的。
NDB表类型不支持外键，约束，
触发器。它确实支持事务，但是这些事务与InnoDB表处理程序的事务不同，因此在不同的表类型中，一个
COMMIT不是原子的。 MySQL喜欢指出，SAP R / 3这样的大型系统在数据库级别上不使用引用完整性。到目前为止这是真的，但作为一名SAP基础顾问多年来一直工作了很多年，我可以告诉你原因
不是性能。 SAP通过在数据库抽象层实现自己的自定义完整性控制和数据域系统（b
）来多次花费这些努力，以获得数据库供应商的独立性。那个
抽象层比PHP和Apache一样大，所以这个例子是恕我直言，与典型的MySQL用户完全无关。
此外，NDB表类型基于内存中的分区存储
引擎（速度来自哪里）并获得高可用性
一个人需要至少两倍于RAM中的完整数据库大小（加上一些
的操作系统和其他开销），以及更高的因素来真正实现
99.999％ 。所以，为了让我们说一个100 GB的数据库，我们正在谈论
大约220-240 GB的RAM。现在这8个盒子每个32GB？据我所采访的MySQL顾问说，真正的瓶颈是
网络，所以这些盒子喜欢比千兆以太网更好。作为一个
骨干。这是一些不错的硬件要求，请确保你的下一个购物清单上有
a叉车。
所以NDB在底线上得到的是另一个表格类型
对某些特殊情况很有用。我可以想象例如系统
读取传感器数据，这些数据无法被中断。传感器通常
不太关心参照完整性，所以对于日志系统来说这实际上是无关紧要的，现在必须存储数据并更正
之后。我认为对于一个系统来说确实是一个很大的优势，可以在同一个SQL查询引擎中提供可用的b * b b日志数据，其中更多的是b / b
复杂的应用程序的部分内容实现了。但是
就是这样，通过将日志数据大量加载到常规数据库表中，可以很容易地实现这一点。除非确实需要
能力来查询和分析最后一秒的logdata，否则运行
多个100千伏的硬件和网络设备仅用于
内存集群解决方案的乐趣有点矫枉过正。
作为产品策略的Oracle副总裁，Ken Jacobs指出：MySQL是
试图通过获得
第三方技术来解决某些产品缺陷。这并不意味着他们现在有一个产品，即b $ b与Oracle甚至其他数据库产品竞争，无论是否b
聚集在一起。绝对正确的雅各布先生，他们之前通过添加InnoDB完成了这个
，现在他们添加了一些有限的多主机
复制功能。但是，不是开发一个包含InnoDB表处理程序的集成
解决方案，而这个
功能将非常有用，他们只是将第五个轮子添加到购物车中。
Quoting from the MySQL(tm) FAQ about MySQL(tm) Cluster(tm) avaliable at
http://www.mysql.com/products/cluster/faq.html
<quote>
Q: Does MySQL Cluster work with MyISAM and InnoDB?
A: MySQL Cluster can include the MyISAM and InnoDB storage engines. Of
these, the high-availability data must reside in the MySQL Cluster
storage engine.
The MySQL Cluster DB node stores MySQL Cluster data, the MySQL Server
parses SQL and sends requests to the DB node. The MySQL Server does not
store any data belonging to the MySQL Cluster storage engine.
InnoDB/MyISAM data is still stored in the MySQL server and can be used
in the standard way, but that data is not replicated, so that data is
not visible from any other MySQL server that is connected to the MySQL
Cluster.
</quote>
It is just another table handler made available for the SQL query
engine. Touting loudly and on all available channels that "MySQL Cluster
combines the world''s most popular open source database with a
parallel-server" naturally leads to the misinterpretation that all the
wonderfull new features like foreign keys, MVCC and rollback will now
horizontally scale over multiple, high available nodes. This is not true.
The NDB table type does not have support for foreign keys, constraints,
triggers. It does support transactions, but these transactions are not
the same transactions as the ones of the InnoDB table handler, so a
COMMIT is not atomic across different table types. MySQL likes to point
out that the largest systems like SAP R/3 do not use referential
integrity on the database level. That is true so far, but having worked
for many years as an SAP base consultant I can tell you that the reason
for that is NOT performance. SAP spends that effort multiple times by
implementing their own, custom integrity control and data domain system
in the DB abstraction layer, to gain DB vendor independence. That
abstraction layer is larger than PHP and Apache together, so this
example is IMHO totally irrelevant for the typical MySQL user.
Also, the NDB table type is based on an in-memory, partitioned storage
engine (that''s where the speed comes from) and to get high availablility
one needs at least two times the full database size in RAM (plus some
for the OS and other overhead), and a higher factor to really achieve
the 99.999%. So to serve let''s say a 100 GB database, we''re talking
about 220-240 GB of RAM. Now that''s 8 boxes with 32GB each? And
according to a MySQL consultant I spoke with, the real bottleneck is the
network, so these boxes like to have "better than Gigabit Ethernet" as a
backbone. That are some decent hardware requirements, make sure you have
a forklift on your next shopping list.
So what one gets with NDB on the bottom line is another table type that
is usefull for some special cases. I can imagine for example systems
that read sensor data, which cannot be interrupted. Sensors usually
don''t care much about referential integrity, so for the logging system
this is in fact irrelevant, the data has to be stored now and corrected
later. I think it is indeed a big plus for a system, to make that
logging data available inside the same SQL query engine where the more
complicated bits and pieces of the application are implemented in. But
that is all, and that can pretty easy be achieved by doing bulk-loads of
the log data into regular database tables. Unless one really needs the
ability to query and analyse up to the last second of logdata, running
some multiple 100 kilodollar hardware and network equipment just for the
fun of a memory cluster solution is a bit overkill.
As the Oracle VP of product strategy, Ken Jacobs, pointed out: "MySQL is
trying to address certain product shortcomings by acquiring a
third-party technology. This does not mean they now have a product that
is competitive with Oracle?or even other?database products, whether
clustered or not.". Absolutely right Mr. Jacobs, they have done that
before by adding InnoDB, now they added some limited multimaster
replication capabilities. But instead of developing an integrated
solution that includes the InnoDB table handler, where this
functionality would be usefull, they just added a fifth wheel to the cart.
我使用PostgreSQL，我很高兴在PostgreSQL中拥有相同的功能。
I use PostgreSQL and I would appreciate to have the same features in
PostgreSQL.
当然，我也一样。与Jan Wieck交谈关于他打算做什么
关于它，也许也考虑支持开发工作; - ）
Sure, so would I. Talk to Jan Wieck about what he plans to do
about it, and maybe consider supporting that development work too ;-)
Ken Jacobs进一步说没人有什么完全像Oracle的Real
Application Clusters。这也是对的。然而，好的PostgreSQL由
现在比较SQL功能和独立的DB性能。在
复制时，我们落后2年或更长时间。
现在我们需要将Slony-I项目推出门并让它
稍微解决，可能会在一个以上的版本中得到增强。以此作为基础，我们将开始设计一个同步多主机系统，可以从正在运行的异步复制设置中跳转启动
。所有
这个高可用性 babble是恕我直言，只要
没有办法（重新）从头开始创建一个（失败的）节点而没有
中断。这个功能列在MySQL路线图上
for 5.1 ...所以在2008年的某个地方？ Slony今天就为async master-slave
做了这个。
Jan
-
＃================================================= =====================＃
＃因为错误而得到宽恕比对正确更容易。 ＃
＃让我们打破这个规则 - 请原谅我。 ＃
＃======================================== ========= = Ja******@Yahoo.com ＃
---------------------------（播出结束）-------------- -------------
提示7：别忘了增加免费空间地图设置
Ken Jacobs further said "No one has anything at all like Oracle''s Real
Application Clusters". And that is right too. However good PostgreSQL by
now compares on SQL features and standalone DB performance. On
replication we are 2 years or more behind.
Right now we need to get the Slony-I project out the door and let that
settle a bit and maybe get enhanced over one more release. With that as
the base, we will start designing a synchronous multimaster system that
can be jump-started from a running, asynchronous replication setup. All
this "high-availability" babble is IMHO totally pointless as long as
there is no way of (re)creataing a (failed) node from scratch without
taking an outage. And that functionality is listed on the MySQL roadmap
for 5.1 ... so somewhere in 2008? Slony does that for async master-slave
right today.
Jan
--
#================================================= =====================#
# It''s easier to get forgiveness for being wrong than for being right. #
# Let''s break this rule - forgive me. #
#================================================= = Ja******@Yahoo.com #
---------------------------(end of broadcast)---------------------------
TIP 7: don''t forget to increase your free space map settings
这篇关于复制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
