Azure SQL 数据同步最佳做法

  • 项目

适用于：Azure SQL 数据库

本文介绍了针对 Azure SQL 数据同步的最佳做法。

有关 SQL 数据同步的概述，请参阅使用 Azure SQL 数据同步跨多个云和本地数据库同步数据。

重要

目前，Azure SQL 数据同步不支持 Azure SQL 托管实例。

安全性和可靠性

客户端代理

  • 使用具有网络服务访问权限的最小特权用户帐户安装客户端代理。
  • 在不同于安装 SQL Server 的服务器上安装客户端代理。
  • 请勿向多个代理注册本地数据库。
    • 即使为不同的同步组同步不同表时也应避免这样做。
    • 如果向多个客户端代理注册本地数据库，则会在删除其中一个同步组时产生问题。

具有所需最小特权的数据库帐户

  • 对于同步设置：

    • SQL Server 权限：CREATE/ALTER TABLE、ALTER DATABASE、CREATE PROCEDURE、SELECT/ALTER SCHEMA、CREATE TYPE。 这些权限（连同其他权限）包含在内置数据库角色 ddl_admin 中。
    • 在资源组级别，需要 SQL DB 参与者角色的成员身份。 有关详细信息，请参阅使用 Azure 门户分配 Azure 角色。 如果已经分配了更广泛角色（如参与者或所有者）的成员身份，也可以使用。
    • 订阅级别的权限应该不是必需的，但可以提供一种简化的（尽管不是最低要求）方式，为订阅中的多个 Azure 数据同步实现提供必要的权限。 已弃用的原始 API 需要这些 Azure RBAC 权限，但不应再使用。
      • “Microsoft.Sql/locations/syncMemberOperationResults/read”
      • “Microsoft.Sql/locations/syncAgentOperationResults/read”
      • “Microsoft.Sql/locations/syncGroupOperationResults/read”

  • 对于正在进行的同步。

    • SQL Server 权限：在选择进行同步的用户表上为 SELECT、INSERT、UPDATE 和 DELETE 权限。 在用户定义的表类型上为 EXECUTE 权限。
    • SQL Server 权限：在同步元数据和系统创建的跟踪表上为 SELECT、INSERT、UPDATE 和 DELETE 权限。 在服务创建的存储过程上为 EXECUTE 权限。
      • DataSync 架构用于中心和成员数据库中系统创建的对象。
      • dss 和 TaskHosting 架构用于同步元数据数据库中系统创建的对象。

  • 对于取消预配。

    • SQL Server 权限：在同步的所有表部分为 ALTER；在同步元数据表上为 SELECT 和 DELETE；在同步跟踪表、存储过程和用户定义的类型上为 CONTROL。
    • 若要进行清理，请删除 DataSync、dss 和 TaskHosting 架构中系统创建的对象。

Azure SQL 数据库仅支持单组凭据。 若要在此约束内完成这些任务，请考虑使用以下选项：

  • 针对不同阶段更改凭据（例如 credential1 用于安装，credential2 用于正在运行）。
  • 更改凭据的权限（即，在设置同步后更改权限）。

审核

建议在同步组中的数据库级别启用审核。 了解如何在 Azure SQL 数据库上启用审核或在 SQL Server 数据库上启用审核。

设置

数据库考虑因素和约束

数据库大小

创建新的数据库时，请设置最大大小，以使其始终大于你部署的数据库。 如果未将最大大小设置为大于部署的数据库，则同步会失败。 尽管 SQL 数据同步不提供自动增长，但可以在创建数据库后运行 ALTER DATABASE 命令来增加数据库的大小。 请确保不超出数据库大小限制。

重要

SQL 数据同步会为每个数据库存储额外的元数据。 请确保在计算所需的空间时考虑此元数据。 增加的开销量与表宽度（例如，窄表会需要更多的开销）和流量大小有关。

表考虑因素和约束

选择表

无需在同步组中包括数据库中的所有表。 同步组中所包括的表会影响效率和成本。 仅当业务需要时才在同步组中包括表及其依赖的表。

主键

同步组中的每个表均必须具有主键。 SQL 数据同步服务无法同步不具有主键的表。

在使用 SQL 数据同步投入生产之前，请测试初始和正在进行的同步性能。

空表提供最佳性能

空表在初始化时提供最佳性能。 如果目标表为空表，则数据同步会使用批量插入来加载数据。 否则，数据同步会逐行进行比较和插入以检查是否存在冲突。 但是，如果不考虑性能，则可以在已包含数据的表之间设置同步。

预配目标数据库

SQL 数据同步提供了基本的数据库自动预配。

本部分讨论 SQL 数据同步预配的限制。

自动预配限制

SQL 数据同步自动预配的限制如下：

  • 在目标表中仅选择已创建的列。 在目标表中，不会对不属于同步组一部分的任何列进行预配。
  • 仅为所选列创建索引。 如果源表索引包含不是同步组一部分的列，则不会在目标表中预配这些索引。
  • 不会预配 XML 类型列上的索引。
  • 数据同步仅支持以下两个索引属性：Unique、Clustered/Non-Clustered。 索引的其他属性（如 IGNORE_DUP_KEY、Where 筛选器谓词等）不受支持，并且即使源索引设置了这些属性，目标索引也会在未设置这些属性的情况下进行预配。
  • 不会预配 CHECK 约束。
  • 不会预配源表上的现有触发器。
  • 不会在目标数据库上创建视图和存储的过程。
  • 对外键约束的 ON UPDATE CASCADE 和 ON DELETE CASCADE 操作不会在目标表中重新创建。
  • 如果具有精度大于 28 的十进制或数值列，则 SQL 数据同步在同步期间可能出现转换溢出问题。建议将十进制或数值列的精度限制为 28 或更小。

建议

  • 仅在尝试使用该服务时使用 SQL 数据同步自动预配功能。
  • 对于生产环境，应预配数据库架构。

在哪里定位中心数据库

企业到云方案

为了最大程度的减小延迟，请使中心数据库位于同步组数据库流量最密集的位置。

云到云方案

  • 如果同步组中的所有数据库位于一个数据中心，则中心数据库应位于同一个数据中心。 此配置会减少延迟并降低在数据中心之间的数据传输成本。
  • 如果同步组中的数据库位于多个数据中心，则中心数据库应位于与大部分数据库和数据库流量相同的数据中心。

混合方案

将前面的准则应用于复杂的同步组配置，例如，应用于企业到云和云到云方案的组合。

同步

避免缓慢且昂贵的初始同步

在本部分，我们将讨论同步组的初始同步。 了解如何帮助防止初始同步运行时间过长而产生不必要的昂贵开销。

初始同步工作原理

创建同步组时，请先仅处理一个数据库中的数据。 如果数据在多个数据库中，SQL 数据同步会将每一行都视为需要解决的冲突。 此冲突解决会导致初始同步运行缓慢。 如果数据在多个数据库中，则初始同步可能需要几天到几个月的时间，具体要取决于数据库大小。

如果数据库在不同的数据中心，每行都必须在不同的数据中心之间穿行。 这也增加了初始同步的成本。

建议

如果可能，请先仅处理同步组中一个数据库的数据。

进行设计以避免同步循环

在同步组中存在循环引用时将出现同步循环。 在此情况下，一个数据库中的每个更改都将通过同步组中的数据库进行循环无休止地复制。

请确保避免同步循环，因为它们会导致性能降低并可能显著增加成本。

无法传播的更改

更改无法传播的原因

更改可能由于以下原因之一而无法传播：

  • 架构/数据类型不兼容。
  • 在不可为 NULL 的列中插入 NULL。
  • 违反外键约束。

如果更改无法传播，会发生什么情况？

  • 同步组显示它处于警告状态。
  • 详细信息显示在门户 UI 日志查看器中。
  • 如果问题在 45 天未解决，数据库将过时。

注意

这些更改即不再传播。 在此情况下恢复的唯一方法是重新创建同步组。

建议

通过门户和日志界面定期监控同步组和数据库运行状况。

维护

避免过时的数据库和同步组

同步组或同步组中的数据库可能会过时。 如果同步组的状态为“过时”，则会停止运行。 如果数据库的状态为“过时”，数据可能会丢失。 最好避免这种情况，而不是尝试基于其还原。

避免过时的数据库

如果数据库离线长达 45 天或更多，其状态将设置为“过时”。 请确保没有任何数据库离线长达 45 天或更多，以避免数据库出现“过时”状态。

避免过时的同步组

如果同步组中的任何更改在 45 天或更长时间内无法传播到同步组中的其他数据库，则同步组的状态将设置为“过时”。 请定期检查同步组的历史记录日志，以避免同步组出现“过时”状态。 确保所有冲突已解决，且更改在同步组数据库之间成功传播。

同步组可能会由于下列原因之一无法应用更改：

  • 表之间的架构不兼容。
  • 表之间的数据不兼容。
  • 将具有 NULL 值的行插入不允许 NULL 值的列中。
  • 使用违反外键约束的值更新行。

若要避免同步组过时：

  • 更新架构以允许失败的行中包含的值。
  • 更新外键值以包括失败的行中包含的值。
  • 更新失败的行中的数据值，以使其与目标数据库中的架构或外键兼容。

避免取消预配问题

在某些情况下，向客户端代理取消注册数据库可能会导致同步失败。

方案

  1. 使用 SQL 数据库实例和 SQL Server 数据库创建与本地代理 1 关联的同步组 A。
  2. 向本地代理 2（此代理不与任何同步组关联）注册同一本地数据库。
  3. 从本地代理 2 取消注册本地数据库将会删除本地数据库的同步组 A 的跟踪和元表。
  4. 同步组 A 操作失败，并显示以下错误：“当前操作无法完成，因为尚未预配进行同步的数据库，或者你没有访问同步配置表的权限。”

解决方案

若要避免此情况，请不要向多个代理注册数据库。

若要从此情况恢复：

  1. 从数据库所属的每个同步组删除此数据库。
  2. 将数据库重新添加回从中删除的每个同步组。
  3. 部署每个受影响的同步组（此操作预配了数据库）。

修改同步组

请勿尝试先从同步组中删除数据库，然后在不先部署其中一个更改的情况下编辑同步组。

而是首先从同步组中删除数据库。 然后，部署更改并等待取消预配完成。 取消预配完成后，可以编辑同步组并部署更改。

如果你尝试先删除数据库，然后编辑同步组而不先部署其中一个更改，则一个或另一个操作会失败。 门户界面可能会出现不一致状态。 如果出现此情况，请刷新页面以还原正确的状态。

避免架构刷新超时

在要同步复杂架构的情况下，如果同步元数据数据库的 SKU 较低（例如为“基本”），则可能会在架构刷新过程中遇到“操作超时”错误。

解决方案

若要缓解此问题，请考虑扩展同步元数据数据库资源。

后续步骤

有关 SQL 数据同步的详细信息，请参阅：

有关 SQL 数据库的详细信息，请参阅：