数据库复制指南

重复一遍，但是每次都以一种新的方式-这不是艺术吗？



Stanislav Jerzy Lec，摘自《未梳理的思想》一书

字典将复制定义为将两组（或更多组）数据保持在一致状态的过程。什么是“数据集的一致状态”是一个单独的大问题，所以让我们以一种更简单的方式来重新定义定义：响应一个数据集（称为副本）以响应另一个数据集（称为主数据库）的更改的过程。集合不一定相同。







数据库复制支持是管理员最重要的任务之一：几乎每个重要的数据库都有一个副本，甚至多个。



复制任务至少包括

• 在主数据库丢失的情况下支持备份数据库；
• 减少由于将部分请求转移到副本而导致的基础负载；
• 数据传输到档案或分析系统。

在本文中，我将讨论复制的类型以及每种复制解决的任务。



有三种复制方法：

• 在存储系统级别阻止复制；
• DBMS级别的物理复制；
• 在DBMS级别上的逻辑复制。

块复制

使用块复制，不仅可以在主磁盘上执行每个写操作，而且还可以在备份上执行每个写操作。因此，一个阵列上的卷对应于另一阵列上的镜像卷，并以字节精度重复主卷：







这种复制的优点包括易于设置和可靠性。主机与磁盘之间的磁盘阵列或某种东西（设备或软件）都可以将数据写入远程磁盘。



磁盘阵列可以补充有启用复制的选项。选项名称取决于阵列制造商：





如果磁盘阵列无法复制数据，则可以在主机和阵列之间安装一个代理，该代理可以一次写入两个阵列。代理可以是独立设备（EMC VPLEX）或软件组件（HPE PeerPersistence，Windows Server存储副本，DRBD）。与只能与同一阵列或至少与同一制造商的阵列一起使用的磁盘阵列不同，代理可以与完全不同的磁盘设备一起使用。



块复制的主要目的是提供容错能力。如果数据库丢失，则可以使用镜像卷重新启动它。



块复制以其多功能性而著称，但是多功能性是有代价的。



首先，没有服务器可以处理镜像卷，因为它的操作系统无法控制对其的写入。从观察者的角度来看，镜像卷上的数据本身会出现。万一发生灾难（主服务器或主服务器所在的整个数据中心发生故障），则应停止复制，卸载主卷并安装镜像卷。请尽快以相反的方向重新启动复制。



在使用代理的情况下，所有这些动作将由代理执行，这简化了配置，但没有减少切换时间。



第二，备用服务器上的DBMS本身只能在装入磁盘后才能启动。在某些操作系统中，例如在Solaris中，在分配过程中标记了用于缓存的内存，标记时间与分配的内存量成正比，也就是说，实例的启动不会是瞬时的。另外，重新启动后缓存将为空。



第三，在备份服务器上启动后，DBMS将发现磁盘上的数据不一致，并且您需要花费大量时间使用重做日志进行恢复：首先，重复这些事务，其结果已保存在日志中，但没有时间保存到数据文件中，然后回滚失败时没有时间完成的事务。



块复制不能用于负载平衡，并且使用类似的方案来升级具有与主磁盘相同阵列上的镜像卷的数据存储。 EMC和HP将此方案称为BCV，只有EMC代表业务连续性卷，而HP代表业务复制量。 IBM在这种情况下没有特殊商标，该方案称为“镜像卷”。







在阵列中创建两个卷，并且在两个卷上同时执行写入操作（A）。在某个时间，镜像断开（B），即，卷变得独立。镜像卷安装到专用于存储升级的服务器上，并在该服务器上引发数据库实例。该实例将花费与执行块复制还原一样长的时间，但是可以通过在非高峰时段断开镜像来显着减少该时间。关键在于，破坏镜像的后果等同于DBMS的异常终止，并且异常终止情况下的恢复时间在很大程度上取决于崩溃时活动事务的数量。用于卸载的数据库可用于读取和写入。所有块标识符中断后更改的镜像，无论是在主卷还是在镜像卷上，都保存在块更改跟踪-BCT的特殊区域中。



上载结束后，将卸载镜像卷（C），还原镜像，并在一段时间后再次将镜像卷追上主卷并成为其副本。

物理复制

日志（重做日志或预写日志）包含对数据库文件所做的所有更改。物理复制的思想是将日志中的更改重新提交到另一个数据库（副本），因此副本中的数据逐字节复制主数据库中的数据。



使用数据库日志更新副本的功能出现在1996年发布的Oracle 7.3版本中，并且已经在Oracle 8i版本中实现了从主数据库到副本的日志传送自动化，并被称为DataGuard。事实证明对这项技术的需求如此之大，以至于如今几乎所有现代DBMS中都存在物理复制机制。





经验表明，如果仅使用服务器来保持副本为最新，则运行主服务器的服务器的处理能力的大约10％足以满足要求。



DBMS日志不打算在此平台之外使用，其格式未记录在案，如有更改，恕不另行通知。因此，很自然的要求，即仅在同一DBMS的相同版本的实例之间才可以进行物理复制。因此，对操作系统和处理器体系结构的可能限制，也可能影响日志的格式。



自然地，物理复制不会对存储模型施加任何限制。此外，副本数据库中的文件可以与源数据库中的文件完全不同地放置-您只需要描述这些文件所在的卷之间的对应关系即可。



Oracle DataGuard允许您从副本数据库中删除某些文件-在这种情况下，与这些文件相关的日志中的更改将被忽略。



与存储复制相比，物理数据库复制具有许多优点：

• 由于仅传输日志而不传输数据文件，因此传输的数据量较少；实验表明，流量减少了5-7倍；
• : - , ; , ;
• , . , .

从副本中读取数据的功能是在2007年Oracle 11g发行版中引入的，如DataGuard技术名称中添加的绰号“ active”所示。其他DBMS也具有从副本中读取的功能，但这未反映在名称中。



将数据写入副本是不可能的，因为更改是逐字节进行的，并且副本无法同时执行其请求。最新版本中的Oracle Active DataGuard允许写入副本，但这仅是“糖”：实际上，更改是在主要基础上执行的，客户端正在等待它们滚动到副本。



如果主数据库中的文件已损坏，则可以简单地从副本中复制相应的文件（在对数据库执行此操作之前，请仔细阅读管理员手册！）。副本上的文件可能与主数据库中的文件不同：事实是，在扩展该文件时，新块没有填充任何东西以加快速度，并且它们的内容是偶然的。基数可能不会使用该块中的所有空间（例如，该块中可能有可用空间），但是已用空间的内容最多匹配字节。



物理复制可以是同步的也可以是异步的。对于异步复制，总会有一些事务在主数据库上完成，但尚未到达备用数据库，如果主数据库发生故障，则在过渡到备用数据库的情况下，这些事务将丢失。在同步复制中，提交操作的完成意味着与该事务相关的所有日志记录都已提交给副本。重要的是要了解，获取日志副本并不意味着更改已应用于数据。如果主数据库丢失了，事务也不会丢失，但是如果应用程序将数据写入主数据库并从副本中读取数据，那么它就有机会获得此数据的旧版本。



在PostgreSQL中，可以配置复制，以便仅在将更改应用于副本数据之后才完成提交（选项synchronous_commit = remote_apply），而在Oracle中，可以配置整个副本或单个会话，以便仅在副本不落后于主数据库的情况下才执行查询（STANDBY_MAX_DATA_DELAY=0）。但是，最好还是设计应用程序，以便在不同的模块中执行对主数据库的写入和对副本的读取。



在寻找选择哪种模式（同步还是异步）的答案时，Oracle市场人员会为您提供帮助。DataGuard提供了三种模式，每种模式都最大化了其中一个参数-数据安全性，性能和可用性-却以其他模式为代价：

• 最高性能：复制始终是异步的；
• Maximum protection: ; , commit ;
• Maximum availability: ; , , , .

尽管数据库复制相对于块复制具有不可否认的优势，但是许多公司的管理员，尤其是那些具有可靠传统的公司，仍然非常不愿意放弃块复制。有两个原因。



首先，在使用磁盘阵列进行复制的情况下，流量不会通过数据传输网络（LAN），而是会通过存储区域网络。通常，在很久以前建立的基础架构中，SAN比数据网络更可靠，更高效。



其次，借助于DBMS的同步复制在最近已经变得可靠。在Oracle中，这一突破发生在2007年发布的11g版本中，而在其他DBMS中，同步复制甚至出现在后来。当然，按照信息技术领域的标准，十年并不是那么短，但是在数据安全方面，一些管理员仍然遵循“无论发生什么”的原则。

逻辑复制

数据库中的所有更改都是由于对其API的调用而发生的-例如，由于执行SQL查询而导致的。在两个不同的基础上运行相同查询序列的想法似乎很诱人。复制要遵循两个规则：

1. , , . D, A B.
2. , , . B , , C.

例如，在MySQL中实现命令的复制（基于语句的复制）。不幸的是，由于两个原因，这种简单的方案不能得到相同的数据集。



首先，并不是所有的API都是确定性的。例如，如果一个SQL查询包含now（）或sysdate（）函数，该函数返回当前时间，则它将在不同的服务器上返回不同的结果，因为查询不是同时执行的。另外，触发器和存储函数的不同状态，影响排序顺序的不同语言环境以及更多其他原因也会导致差异。



其次，基于命令的并行复制无法暂停和正常重启。







如果复制在时间T1停止，则事务B应该中止并回滚。当您重新启动复制，事务B的执行能够带来的副本从源数据库的状态的状态不同：在源，事务B开始之前事务A结束，这意味着它没有看到交易A.所做的更改

请求的复制可以停止和当数据库中没有活动事务时，仅在时间T2重新启动。当然，在繁重的工业基础上没有这样的时刻。



通常，逻辑复制使用确定性查询。请求的确定性由两个属性提供：

• 查询更新（或插入或删除）单个记录，并通过其主键（或唯一键）对其进行标识；
• 所有请求参数都在请求本身中明确设置。

与基于语句的复制不同，此方法称为基于行的复制。



假设我们有一个雇员表，其中包含以下数据：





在此表上执行了以下操作：

update employee set salary = salary*1.2 where dept=36;

为了正确地复制数据，将在副本中执行以下查询：

update employee set salary = 2160 where id=3817;
update employee set salary = 1920 where id=2274;

查询产生的结果与基于原始查询的结果相同，但是它们不等同于执行的查询。



副本库是开放的，不仅可用于读取，而且可用于写入。这允许将副本用于执行部分查询，包括用于生成需要创建其他表或索引的报表。



重要的是要理解，逻辑副本仅在不对其进行任何其他更改的情况下才等效于原始库。例如，如果在上面的示例中，在副本中Sidorov的部门被添加到36，则他将不会获得晋升；如果Ivanov从部门36调任，则无论如何他都会获得晋升。



逻辑复制提供了许多其他复制类型所没有的功能：

• 在表级别上设置一组复制数据（对于物理复制-在文件和表空间级别，对于块复制-在卷级别）；
• 建立复杂的复制拓扑-例如，将多个数据库合并为一个或双向复制；
• 减少传输的数据量；
• 在不同版本的DBMS之间甚至在不同制造商的DBMS之间进行复制；
• 复制期间的数据处理，包括重组，扩充，历史记录保存。

还有一些缺点也不允许逻辑复制取代物理复制：

• 所有复制的数据都必须具有主键；
• 逻辑复制不支持所有数据类型-例如，BLOB可能存在问题。
• : , ;
• ;
• , , – , .

后两个缺点极大地限制了逻辑副本作为容错工具的使用。如果主数据库中的一个查询一次更改许多行，则副本可能会严重滞后。更改角色的能力需要开发人员和管理员付出巨大的努力。



有几种方法可以实现逻辑复制，而这些方法中的每一种都实现功能的一部分，而没有实现另一种功能：

• 通过触发器复制；
• 使用DBMS日志；
• 使用CDC（变更数据捕获）软件；
• 应用的复制。

触发复制

触发器是一种存储过程，可以在执行任何修改数据的操作时自动执行。每个记录更改时都会调用该触发器，它可以访问该记录的键以及旧的和新的字段值。必要时，触发器可以将新的行值保存到特殊表中，副本端的特殊进程将从中读取它们。触发器中的代码量很大，因此存在生成此类触发器的特殊软件，例如，“合并复制”（Microsoft SQL Server的组件）或Slony-I（用于PostgreSQL复制的单独产品）。



触发器复制的优点：

• 独立于主库和副本的版本；
• 广泛的数据转换功能。

缺点：

• 装载在主底座上；
• 高复制延迟。

使用DBMS日志

DBMS本身也可以提供逻辑复制功能。日志是数据源，就像物理复制一样。关于字节更改的信息也添加到有关更改的字段的信息（Oracle中的补充日志记录，wal_level = logical在PostgreSQL中）以及唯一键的值，即使它不变。结果，数据库日志的数量正在增加-根据各种估计，从10％到15％。



复制功能取决于特定DBMS中的实现-如果您可以在Oracle中构建逻辑备用数据库，那么在PostgreSQL或Microsoft SQL Server中，您可以使用内置平台工具来部署相互预订和发布的复杂系统。此外，DBMS提供了内置的复制监视和控制功能。



这种方法的缺点包括日志量增加以及节点之间的流量可能增加。

使用CDC

有一整类旨在组织逻辑复制的软件。该软件称为CDC，用于更改数据捕获。以下是该类最著名的平台的列表：

• Oracle GoldenGate（于2009年被GoldenGate收购）；
• IBM InfoSphere Data Replication（以前是InfoSphere CDC；甚至更早的版本是DataMirror Transformation Server，在2007年被DataMirror收购）；
• VisionSolutions DoubleTake / MIMIX（以前为Vision Replicate1）；
• Qlik数据集成平台（以前称为Attunity）；
• Informatica PowerExchange CDC；
• Debezium;
• StreamSets数据收集器...

该平台的任务是读取数据库日志，转换信息，将信息传输到副本并应用。与通过DBMS本身进行复制的情况一样，日志应包含有关已更改字段的信息。通过使用其他应用程序，您可以动态地对复制的数据执行复杂的转换，并构建相当复杂的复制拓扑。



优点：

• 在不同DBMS之间进行复制的能力，包括将数据加载到报告系统中；
• 数据处理和转换的最大可能性；
• 节点之间的通信量最小-平台可切断不必要的数据并压缩通信量；
• 内置功能来监视复制状态。

没有很多缺点：

• 日志量的增加，例如通过DBMS进行逻辑复制；
• 新软件难以配置和/或许可证价格昂贵。

CDC平台传统上用于近乎实时地更新公司数据仓库。

应用复制

最后，另一种复制方式是直接在客户端上形成变更向量。客户端必须发出影响单个记录的确定性查询。这可以通过使用特殊的数据库库（例如Borland数据库引擎（BDE）或Hibernate ORM）来实现。







当应用程序完成事务时，Hibernate ORM插件将更改向量写入队列并在数据库上执行事务。一个特殊的复制器过程从队列中减去向量，并在复制库中执行事务。

此机制对于更新报告系统很有用。它也可以用来提供容错能力，但是在这种情况下，必须在应用程序中监视复制状态。



传统上-这种方法的优点和缺点：

• 在不同DBMS之间进行复制的能力，包括将数据加载到报告系统中；
• 处理和转换数据，状态监视等的能力；
• 节点之间的通信量最小-平台可切断不必要的数据并压缩通信量；
• 完全独立于数据库-既独立于格式又独立于内部机制。

此方法的优点不可否认，但是有两个非常严重的缺点：

• 对应用程序体系结构的限制；
• 大量的本地复制代码。

那么哪个更好呢？

这个问题以及其他许多问题都没有明确的答案。但我希望下表能帮助您为每个特定任务做出正确的选择：

• , ; .
• , .
• , .
• .
• , , .
• CDC , / .
• .