我对MySQL复制可以做什么有很好的感觉。我想知道还有哪些其他数据库支持复制，以及它们如何与MySQL和其他数据库进行比较？

我将要提出的一些问题是：

• 复制是内置的，还是添加组件/插件？
• 复制是如何工作的(高级)？ MySQL提供了基于语句的复制(以及5.1中的基于行的复制)。我对其他数据库的比较感兴趣。通过电线运输了什么？更改如何应用于副本？
• 检查主机和从机之间的一致性是否容易？
• 使失败的副本与主副本恢复同步有多么容易？
• 表现？我讨厌MySQL复制的一件事是它是单线程的，并且副本通常很难跟上，因为主服务器可以并行运行许多更新，但是副本必须串行运行。其他数据库中是否有类似的陷阱？
• 其他有趣的功能...

解决方案

另一种可行的方法是在虚拟环境中运行。我认为这篇博客文章中的数据很有趣

http://chucksblog.typepad.com/chucks_blog/2008/09/enterprise-apps.html

它来自EMC高管，因此很明显，它不是独立的，但是实验应该是可重复的

这是特定于Oracle的数据

http://oraclestorageguy.typepad.com/oraclestorageguy/2008/09/to-rac-or-not-to-rac-reprise.html

编辑：如果我们运行虚拟化，那么有什么方法可以复制任何东西

http://chucksblog.typepad.com/chucks_blog/2008/05/vmwares-srm-cha.html

MS SQL 2005 Standard Edition及更高版本具有出色的复制功能和工具。看一眼：

http://msdn.microsoft.com/zh-CN/library/ms151198(SQL.90).aspx

非常有能力。我们甚至可以将SQL Server Express用作只读订阅者。

MySQL的复制能力很弱，因为一个人需要牺牲其他功能来获得完整的主控/主控支持(由于受支持的后端的限制)。

PostgreSQL的复制很弱，因为它仅内置支持主服务器/备用服务器(使用日志传送)。更强大的解决方案(例如Slony或者Londiste)需要添加功能。归档日志段通过网络传送，这些记录与用于确保独立数据库在不干净启动时处于正常工作状态的记录相同。这就是我目前正在使用的，并且我们具有完全自动化的重新同步(以及设置和其他功能)。这些方法都不是完全同步的。从PostgreSQL 8.5开始将建立更全面的支持。日志传送不允许数据库脱离同步，因此不需要进程来测试同步状态。使两个数据库重新同步涉及在主数据库上设置备份标志，与从数据库同步(数据库仍在运行；这是安全的)，并使用在生成期间的存档日志取消备份标志(并重新启动从数据库进程)。可用的备份过程；我的商店已自动执行此过程(就像其他所有管理任务一样)。性能不是问题，因为主服务器除了执行其他工作外，还必须在内部重播日志段。因此，从站将始终比主站承受更少的负载。

Oracle的RAC(由于只有一个存储后端，因此无法正确复制-但是我们有多个前端共享负载，并且可以在该共享存储后端本身中建立冗余，因此在这里值得一提)比其他解决方案要全面得多，但是<I> <B>极其昂贵。数据库的内容不是"在线传送"的；而是将它们存储到共享后端，所有相关系统都可以访问该后端。因为只有一个后端，所以系统不会不同步。

Continent提供了一个第三方解决方案，它可以完全同步语句级别的复制，并支持上述所有三个数据库。但是，他们产品的商业支持版本并不是特别便宜(尽管价格便宜得多。上次我管理它时，Continentant的解决方案需要人工干预才能使群集恢复同步。

所有主要的商业数据库都具有不错的复制性，但是有些数据库比其他数据库更体面。 IBM Informix Dynamic Server(版本11和更高版本)特别好。它实际上有两个系统，一个用于高可用性(HDR高可用性数据复制)，另一个用于分发数据(ER企业复制)。而且，Mach 11功能(RSS远程独立辅助服务器和SDS共享磁盘辅助服务器)也非常出色，在11.50中更是如此，我们可以在其中写入HDR对的主服务器或者辅助服务器。

(完全公开：我研究Informix软件。)

有点题外话，但我们可能需要检查Maatkit以获取有助于MySQL复制的工具。

数据库CALL复制有很多不同的东西。并非所有这些实际上都涉及复制，并且确实以完全不同的方式工作。一些数据库支持几种不同的类型。

MySQL支持异步复制，这在某些方面非常有用。但是，也有弱点。基于语句的复制与大多数(任何其他)数据库不同，并且并不总是导致预期的行为。非生产就绪版本仅支持基于行的复制(但与其他数据库的实现方式更加一致)。

每个数据库都有自己的复制方式，其中一些涉及插入的其他工具。

我对使用MS-SQL 2005(发布者)和SQLEXPRESS(订阅者)进行海外合并复制有一些经验。这是我的评论：

1复制是内置的，还是添加组件/插件？

内建

2复制的工作方式
(高水平)？

从快照(在订户级别提供静态数据)到事务复制(每条INSERT / DELETE / UPDATE指令在所有服务器上都执行)的不同复制方式。合并复制仅复制最终更改(在复制过程中将一次对同一记录进行成功的UPDATES)。

3检查主机和从机之间的一致性是否容易？

我从未做过的事情...

4使失败的副本与主数据库恢复同步有多么容易？

基本的重新同步过程只是一个双击过程...。但是，如果我们有4Go的数据要通过64 Kb连接重新初始化，那么除非我们对其进行自定义，否则这将是一个漫长的过程。

5性能？

好吧……我们当然会遇到瓶颈，例如连接性能，数据量或者服务器性能。在我的配置中，用户仅写入订阅者，所有订阅者均使用主数据库=发布者进行复制。这样一来，最终用户就不会满意该服务器，并且它的CPU严格专用于数据复制(到多个服务器)和备份。订户专用于客户端和一个复制(至发布者)，这在最终用户的数据可用性方面给出了非常有趣的结果。发布者和订阅者之间的复制可以一起启动。

6其他有趣的功能...

出于某种预期，有可能继续开发数据库，​​甚至不停止复制过程....表(以间接方式)，可以添加字段和规则并将其复制到订户。

具有主发布者和​​多个订阅者的配置可能非常便宜(与其他发布者相比……)，因为即使在运行合并或者事务复制时，我们也可以在订阅者侧使用免费的SQLEXPRESS

试用Sybase SQL Anywhere

只需添加到SQL Server(特别是SQL 2008，现在具有更改跟踪功能)中的选项即可。需要考虑的是Microsoft的Sync Framework。这里有一些选择，从基本的中心辐射型体系结构(如果我们具有单个中央服务器和有时连接的客户端，那么很好)到对等同步，这非常有用，它使我们能够执行更高级的功能与多个"主"数据库同步。

我们可能要考虑使用此方法而不是传统复制的原因是，我们可以从代码中获得更多控制权，例如，可以在同步过程中获取事件，以进行更新/更新，更新/删除，删除/更新，插入/插入冲突并根据业务逻辑决定如何解决它们，并在需要时将冲突数据的丢失者存储在某个地方，以进行手动或者自动处理。请参阅本指南，以决定使用不同的复制和/或者同步方法可能发生的情况。

对于敏锐的程序员而言，Sync Framework已足够开放，我们可以使客户端通过WCF连接到WCF服务，该服务可以抽象任何后端数据存储(我听说有些人正在尝试使用Oracle作为后端)。

我的团队刚刚发布了一个大型项目，该项目涉及多个SQL Express数据库，这些数据库通过WAN和Internet(在某些情况下为慢速拨号连接)通过WAN和Internet同步了中央SQL Server数据库的数据子集，取得了巨大的成功。

我自己还没有尝试过，但是我们可能还想研究一下OpenBaseSQL，它似乎具有一些易于使用的内置复制功能。