【问题标题】:Database replication: multiple geographical locations with local database, one main remote database数据库复制:具有本地数据库的多个地理位置,一个主远程数据库
【发布时间】:2014-02-13 23:46:07
【问题描述】:

我有一个非常具体的用例,由于我对数据库复制不太熟悉,因此我愿意接受有关如何以最佳方式完成以下任务的建议和想法:

  • Web 应用程序 + 数据库正在远程服务器上运行。让我们将此设置称为远程 R。

  • 现在假设有 3 个不同的地理位置需要对数据库进行读写访问。我将这些位置称为 L1、L2 和 L3。

主要问题:远程服务器可能不可用或其中一个位置的互联网连接可能无法始终正常工作,从而导致远程应用程序不可用;但我们希望应用程序作为高可用性解决方案(现场)工作,即使在远程服务器关闭或出现互联网连接问题时也是如此。

部分解决方案:所以我正在考虑为每个地理位置提供其自己的服务器以及 Web 应用程序的本地副本。 Web 应用程序本身可以在需要时从版本控制系统自动更新(例如使用 git 挂钩)。

到目前为止一切都很好......(至少我相信如此?)

但是我们的数据呢?真正棘手的部分似乎是数据库复制。让我们假设没有 DNS 或 IP 故障转移,并假设用户首先尝试直接访问远程服务器,如果这不起作用,用户仍然可以在现场使用本地服务器。这一切都发生在网络浏览器(或类似的客户端)内。

一种可能(但不令人满意)的解决方案是使用从 R(主)到 L1、L2 和 L3(从)的主从复制。异步执行此操作时,这应该很快吗?我认为这是一个可行的解决方案,用于在主服务器损坏或无法访问时临时访问本地只读数据库。

但是……读写支持呢?我想在这种情况下我们需要多主复制,但我担心使用 MySQL Cluster 或 Galera 之类的同步复制会减慢速度,特别是因为 L1、L2 和 L3 的连接带宽较低。它们通过广域网连接。 (另外,L1、L2 或 L3 可能并不总是在线。)

真正的问题:您将如何处理这个特定的用例?目前我倾向于多主复制,如果它不会减慢太多的话。该应用程序本身将主要由现场员工使用,但也由一些外部人员通过 WAN 使用。多主复制工作得好吗?例如,如果 L1 停机 24 小时后突然恢复在线,该怎么办?如果 R 无法访问怎么办?

额外:不是我的主要问题,但我还需要通过 SSL 安全发送同步数据,如果可能,请在回答时考虑到这一点。

也许我还是忘记了一些必要的细节;如果是这样,请回复一些反馈,我会尝试相应地更新我的问题。

请注意,我还没有决定数据库,数据库架构将从头开始开发,因此也欢迎使用其他数据库或数据库引擎的想法。 (目前我对 MySQL 和 PostgreSQL 最有经验)

【问题讨论】:

    标签: mysql database replication cluster-computing


    【解决方案1】:

    由于您还没有决定,我强烈建议您看看 MS-SQL merge replication。它功能强大、高度可靠,可以通过 LAN 和 HTTPS 进行复制(所谓的网络复制),而且价格也不贵。

    术语不同于 mySql Master\Slave 的想法。我们在这里谈论一个发布者和多个订阅者。在订阅者级别完成的所有更改都被收集并发送给发布者,然后重新分配给所有订阅者(如果需要,可以使用“过滤订阅”等花哨的选项)。

    标准架构将是:

    • 服务器上某处的发布者,它在订阅者之间收集和重新分配更改。最终用户可能无法访问 Publisher。
    • 其他数据库订阅服务器,用于本地或 Web 访问,与发布者一起复制。最终用户可以访问订阅者。

    我们多年来一直在使用这种架构,包括:

    • 一个用户可以上网
    • 一个用户访问内网
    • 本地访问的数十个订阅者:一些订阅者正在我们的建筑项目中,在沙漠的某个地方....

    这种架构在 MySQL 中“现成”是不可用的。我想它可以被构建,但它肯定会比购买相应的 MS-SQL 许可证要贵得多。不要忘记免费的 SQLEXPRESS 版本的 MS-SQL 可以订阅。

    注意:如果您打算进行这样的配置,我(真的)强烈建议您将所有主键设置为 uniqueIdentifier 数据类型,并随机生成。这将避免典型的复制陷阱,其中 PK 设置为具有自动增量的 int,并且独立服务器在两个复制之间生成相同的主键(MS-SQL 提出了一种避免此类问题的工具,您可以在其中为每个服务器分配 PK 范围,但这个解决方案是真正的 PITA ...)。

    【讨论】:

      猜你喜欢
      • 2015-05-14
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-09-02
      • 2017-06-04
      • 1970-01-01
      相关资源
      最近更新 更多