您需要了解的几种数据复制策略

数据复制在企业信息化建设中是非常重要的一环，不管是建设数据仓库，还是搭建灾备系统，都需要确定数据复制策略。

每种数据复制策略都有一个共同的成本：花费的时间。很少有企业能够承受因数据管理而降低系统速度的后果，因此数据复制速度越快，对业务的负面影响就越小。

复制数据库可能很耗时，而找到合适的工具来帮助加快和简化此过程，同时保证您的数据安全，对您的业务大有裨益。

下面简单介绍一下几种常用的数据复制策略：

1、基于日志的增量复制

有些数据库允许您出于各种原因存储事务日志，其中一个原因是在发生灾难时易于恢复。但是，在基于日志的增量复制中，复制工具还可以查看这些日志，识别对数据源的插入、更新或删除操作，然后在副本数据库中应用这些更改。

这种数据复制策略的好处是：

• 由于基于日志的增量复制只捕获源数据库中基于行的更改并定期更新，因此在目标数据库中应用这些更改时延迟较低。
• 同时，源数据库上的负载也相应减少，因为它只传输更改。
• 由于源数据库始终存储更改，我们可以相信它不会丢失事务。

不幸的是，基于日志的增量复制策略并非没有缺点：

• 它只适用于支持二进制日志复制的数据库，如Oracle、MongoDB、MySQL和PostgreSQL。
• 由于每个数据库都有自己的日志格式，因此很难构建一个涵盖所有受支持数据库的通用解决方案。
• 在目标服务器关闭的情况下，在恢复服务器之前，必须保持日志最新。否则，您将丢失关键数据。

尽管存在缺点，但基于日志的增量复制仍然是一种有价值的数据复制策略，因为它为数据存储和分析提供了快速、安全和可靠的复制。

2、基于键的增量复制

顾名思义，基于键的复制涉及通过使用复制键来复制数据。复制键是数据库表中的列之一，它可以是整数、时间戳、浮点数或 ID。

基于键的增量复制仅使用自上次复制作业以来源中的更改更新副本。在数据复制期间，您的复制工具会获取复制键列的最大值并将其存储。在下一次复制期间，您的工具会将此存储的最大值与源中复制键列的最大值进行比较。如果存储的最大值小于或等于源的最大值，您的复制工具会复制更改，并存储最后读取的数据库最大值，为下次复制时使用。

对每个基于键的复制作业都重复此过程，不断使用复制键来发现源数据库中的更改。

这种数据复制策略提供了与基于日志的数据复制类似的好处，但也有其自身的局限性：

• 它不识别源数据库中的删除操作。删除表中的数据条目时，也会从源数据库中删除复制键。因此复制工具无法捕获对该条目的更改。
• 如果记录具有相同的复制键（复制键字段非唯一约束），则可能存在重复行。发生这种情况是因为基于键的增量复制还会比较与存储的最大值相等的值。因此它会复制该记录，直到找到另一条具有更大复制键的记录。

在基于日志的复制不可行或不支持的情况下，基于键的复制将是一个不错的选择。了解这些限制将帮助您更好地解决发生数据差异的问题。

3、全表复制

与基于日志更改和复制键最大值更新的增量数据复制策略不同，全表复制是复制整个数据库表。它复制所有内容：从源到目标的每一个新的、现有的和更新的行。它不关心源的任何变化；无论某些数据是否更改，它都会复制它。

全表数据复制策略在以下几个方面很有用：

• 您确信您的副本是源的镜像，并且没有数据丢失。
• 当您需要在另一个位置创建副本时，全表复制特别有用，这样无论您的用户位于何处，都可以加载应用程序的内容。
• 与基于键的复制不同，此数据复制策略可以检测到源的变更。

但是，复制整个数据库表有明显的缺点：

• 由于复制的数据量很大，全表复制可能需要更长时间，具体取决于网络的强度。
• 它还需要更高的处理能力，并且可能导致在每个复制作业中复制大量数据的延迟。
• 您使用全表复制复制到同一个数据库的次数越多，您使用的行数就越多，存储所有数据的成本就越高。
• 复制数据时的低延迟和高处理能力可能会导致复制过程中的错误。

虽然全表复制不是复制数据的有效方式，但当您需要恢复已删除的数据或没有任何日志或合适的复制键时，它仍然是一个可行的选择。

4、事务复制

在事务复制中，首先将所有现有数据从发布服务器（源）复制到订阅服务器（副本）中。随后，对发布服务器的任何更改几乎立即以相同的顺序复制到订阅服务器中。

拥有发布服务器的快照很重要，因为订阅服务器需要与发布服务器具有相同的数据和数据库架构，才能接收一致的更新。然后分发代理确定订阅服务器的计划更新的规律性。

要执行事务性复制，需要分发代理、日志读取器代理和快照代理。

快照代理：其工作原理与快照复制的快照代理相同。它会生成所有相关的快照文件。

日志读取器代理：它观察发布者的事务日志，并在分发数据库中复制事务。

分发代理：它将快照文件和事务日志从分发数据库复制到订阅服务器。

分发数据库：它帮助文件和事务从发布者流向订阅者。它存储文件和事务，直到它们准备好移动到订阅服务器。

事务性复制适用于以下情况：

• 您的企业无法承受超过几分钟的停机时间。
• 您的数据库经常更改。
• 您希望订阅服务器实时进行增量更改。
• 你需要最新的数据来进行分析。

在事务复制中，订阅服务器主要用于读取目的，因此当服务器只需要与其他服务器通信时，通常会使用这种数据复制策略。

5、合并复制

合并复制将两个或多个数据库合并为一个数据库，以便一个（主）数据库的更新反映在另一个（辅助）数据库中。这是合并复制区别于其他数据复制策略的一个关键特征。辅助数据库可以从主数据库检索更改，脱机接收更新，然后在恢复联机后与主数据库和其他辅助数据库同步。

在合并复制中，每个数据库，无论是主数据库还是辅助数据库，都可以对数据进行更改。当一个数据库脱机，而您需要另一个数据库在生产中运行时，这会很有用，然后在脱机数据库重新联机后使其更新。

为了避免由于允许从辅助数据库进行修改而产生的数据冲突，合并复制允许您配置一组规则来解决此类冲突。

与大多数数据复制策略一样，合并复制从生成主数据库的快照开始，然后在目标数据库中复制数据。这意味着，我们还可以从快照代理开始合并复制过程。

合并复制还使用合并代理，它提交或应用辅助数据库中的快照文件。然后，合并代理在其他数据库中复制任何增量更新。它还可以识别并解决复制作业期间的所有数据冲突。

在以下情况下，您可以选择合并复制：

• 您不太关心数据对象的更改次数，而是更关心它的最新值。
• 您需要副本来更新和复制源以及其他副本中的更新。
• 复制副本需要单独的数据段。
• 您希望避免数据库中的数据冲突。

合并复制是需要比较复杂设置的数据复制策略，但它在客户端-服务器环境中很有价值，例如移动应用程序或需要合并多个站点数据的应用程序。

6、双向复制

双向复制是不太常见的数据复制策略之一。它是事务复制的子集，允许两个数据库交换更新。所以这两个数据库都允许修改，比如合并复制。但是，要使事务成功，两个数据库都必须处于活动状态。

这里没有明确的源数据库。每个数据库可能来自同一个平台（例如Oracle到Oracle），也可能来自不同的平台（例如Oracle到MySQL）。可以选择每个数据库可以修改哪些行或列。还可以决定哪个数据库在记录冲突的情况下具有更高的优先级，即决定首先反映哪些数据库更新。

如果您想充分利用数据库并提供灾难恢复，双向复制是一个不错的选择。