几乎实时地将包含的SQL数据库复制到客户。

Question

我们托管了许多客户SQL Server数据库，这些数据库需要在几乎实时的情况下复制到外部客户站点。我们的主要限制是，出于安全考虑，我们的数据库被部分包含，以确保客户A不能看到客户B的数据库。

根据客户的大小，数据库的大小从5GB到200 5GB不等。在任何一天，通常都有多达5GB的更改。

其他的限制因素是我们的SQL服务器被保护在防火墙和DMZ后面。我们不想直接把它们暴露给顾客。我们在DMZ中托管的代理可能是一种解决办法。此外，可用性组、镜像和日志传送具有版本兼容性约束，这将导致与单个客户的紧密耦合，更不要说跨多个具有多种SQL版本的客户。我们正在运行SQLServer2019 Enterprise，AFAIK意味着客户需要运行SQLServer2019以实现可用性组、镜像或日志传送兼容性。

到目前为止我考虑过的选择

• 更改数据捕获(CDC)。Server 2019不支持包含数据库的CDC。
• 表复制。Server 2019不支持包含数据库的表复制。
• 触发装置。触发器是同步的，如果复制失败，可能会产生不必要的副作用，例如减慢事务和失败事务。
• 第三方软件HVR软件和Qlik复制。这两种方法都依赖于最初使CDC能够在日志流中添加“补充日志”。它们实际上并不依赖CDC进行复制，而是需要SQL日志文件中需要启用CDC的附加元数据。由于CDC不受包含数据库的支持，这也排除了这些选项。
• 按计划向客户发送完整数据库的副本(通过SFTP以压缩BACPAC格式发送)。然后在客户站点上还原数据库。这个完整的过程大约需要45分钟的快速互联网连接，所以我们现在只安排在一夜之间。它不能满足近乎实时的要求。
• 将每个客户数据库复制到Azure SQL数据库，并将其打开供客户访问。这是否可行，客户可以订阅Azure SQL中的更改，以及数据的实时性吗？涉及的费用是多少？

有人处理过这样的情况吗?你是如何解决的？复制数据库还有哪些其他选择？

Answer 1

有趣的问题要解决。我对包含的数据库不太熟悉，但是经过一些快速的研究，我了解了它们的一般用途以及您所面临的挑战。

出现在脑海中的少数几个想法可能是在研究日志运输或数据库镜像。与常规发送BACPAC文件相比，您可能可以安排更频繁的与这些方法之一的数据同步。

最后，看起来包含的数据库确实支持可用性组，但我不确定这是否会有多大帮助，因为AlwaysOn可用性组需要在可用性组的服务器之间安装Windows故障转移群集，我认为这不利于您的业务场景。

经过更多的集思广益、研究和重新阅读你所写的东西之后，也许有一种方法可以像你提到的那样，利用Azure这样的云提供商。这个DBA.StackExchange答案为将数据移动到Azure实例提供了一些选项。此外，它让我想起了SSIS，您应该能够利用它来将数据从DMZ中的实例同步到外部服务器(无论是Azure中的还是or中的)。

Answer 2

我过去曾为Attunity (现在是Qlik的一个部门)工作，他们的复制产品可以很好地解决这个问题(价格)。复制任务(可能运行在专用服务器上)将连接到具有特定于客户的或“上帝”凭据的源数据库，并写入特定于客户的目标数据库。这些任务可以设置为执行满载和基于日志的CDC，以提供近乎实时的复制。目标数据库不一定是Server。他们可以是甲骨文，雪花，mySQL -任何想要的。

Answer 3

我建议建立一种人工程序。您必须在目标数据库中开发和部署一种使用SSIS包生成的ETL过程。使用一组包，在suorce中检测每个表中的更改，并将它们合并到目标db中。

工作计划可以是这样的：

1. 在源处创建数据库快照
2. 在每个目标db中运行etl进程。
3. 将快照拖放到源

它可以每x分钟运行一次，具体取决于检测和复制更改所需的时间。但这是一项艰巨的任务(开发和维护)。