您的位置: 首页  >  文章  >  选择-MySQL-高可用性-解决方案

选择-MySQL-高可用性-解决方案

分类: 文章 • 2024-03-05 10:59:18

在这篇博文中，我们将看看各种MySQL高可用性解决方案，并检查它们的优缺点。

高可用性环境为必须保持可用的数据库提供了巨大的好处。 高可用性数据库环境跨多台机器共同定位数据库，其中任何一台机器都可以承担数据库的功能。 这样，数据库就不会有“单点故障”。”

有许多高可用性策略和解决方案，那么如何在众多选项中选择最佳解决方案呢？ 首先要问的问题是: 你想解决的问题是什么？ 答案归结为冗余对扩展对高可用性。 这些不一定都一样！

  • 发生灾难时需要多个数据副本
  • 需要提高读取和/或写入吞吐量
  • 需要最大限度地缩短停机时间

选择-MySQL-高可用性-解决方案当您计划您的数据库环境时，记住应用CAP定理是很重要的。 CAP定理将问题分为三类:一致性、可用性和分区容差。 你可以从这三个中选择任何两个，而牺牲第三个。
  • 一致性。 所有节点同时看到相同的数据。
  • 有效。 每个请求都会收到一个关于成功与否的响应。
  • 分区容差。 尽管由于网络故障导致任意分区，系统仍继续运行。

无论你选择哪种解决方案，都应该最大限度地保持一致性。 问题是，尽管MySQL复制很棒，但它本身并不能保证所有节点的一致性。 数据总是有可能不同步，因为事务可能会在故障转移和其他原因期间丢失。 基于Galera的集群，如Percona XtraDB集群，是基于认证的，以防止这种情况！

你应该问自己的第一个问题是: 我能承受丢失数据吗？

这通常取决于应用。 应用程序应该检查交易的状态代码，以确保它们被提交。 许多人没有！ 在故障转移过程中，还可能丢失事务。 在故障切换期间，简单复制方案有可能丢失数据

不一致的节点是另一个问题。 没有冲突检测和解决，不一致的节点是不可避免的。 一种解决方案是经常运行pt-table-checksum来检查跨复制节点的不一致数据。 另一种选择是将基于Galera的分布式集群（例如Percona XtraDB集群(与认证过程一起使用。

什么在监视您的系统？
还是准备好干预故障？
对于复制，请查看MHA和MySQL Orchestrator。
两者都是执行副本服务器故障转移的好工具。
还有其他

许多MySQL DBA担心设置
innodb_flush_log_at_trx_commit
 还有其他
这在逻辑上是一致的吗？
Percona 许多人错误地试图通过写入到XtraDB集群中的多个节点来扩展写入，从而导致冲突通过认证保持一致性。

许多MySQL数据库管理员担心设置
Galera的认证过程遵循以下方法：

  • innodb_flush_log_at_trx_commit
  • 为1表示酸符合性和sync_binlog，但随后使用复制而没有一致性检查！
  • 这在逻辑上是一致的吗？
  • Percona XtraDB集群通过认证保持一致性。

所有解决方案都必须具有某种检测和解决冲突的方法。
故障转移系统一次运行一个实例，并在发生问题时“故障转移”到另一个实例。
分布式系统一次运行多个实例，所有实例都处理不同的数据。

  • 故障转移陷阱：
    • 故障转移系统具有监视器，该监视器可检测故障节点并将服务移至其他位置（如果可用）
    • 更改收集到一个写入集中。
  • 分布式系统：
    • 分布式系统最大程度地减少了故障转移时间

选择-MySQL-高可用性-解决方案如果认证失败,则会丢弃写入集,并回滚事务。
  • 手动故障转移的优势
    • 所有节点将对每个事务做出相同的决定,因此是确定性的。
    • 另一个重要的考虑因素是您应该具有故障转移还是分布式系统。
  • 自动故障转移的优势
    • 减少停机次数，从而增加了Nines
    • 无需等待DBA执行

分布式系统一次运行多个实例,所有实例都处理不同的数据。
显然，发生的速度越快，潜在数据丢失的时间就越少。

  • 复制/ MHA / MMM
  • DRBD
  • XtraDB Cluster / 复制
    • 分布式系统：

分布式系统最大程度地减少了故障转移时间另一个问题是：您的故障转移应该是自动还是手动？

手动故障转移的优势

选择-MySQL-高可用性-解决方案

手动故障转移的主要优点是,人们通常可以对是否需要进行故障转移做出更好的决策。 系统很少能完美地实现它,但是它们可以接近！ 自动故障转移的优势

  • Scaling reads
  • Scaling writes
    • 无需等待工商管理学博士执行

另一个问题是故障转移必须多快发生？

  • Replication
    • 显然,发生的速度越快,潜在数据丢失的时间就越少。
    • 复制/ MHA / MMM
  • Distributed Clusters

取决于挂起的副本事务需要多长时间才能完成故障转移 通常大约30秒 DRBD

通常在15到30秒之间 数据库集群/ MySQL集群 非常快速的故障转移。 取决于负载平衡器，通常小于1秒

精确度的“9”是衡量一个系统完美程度的标准。 说到“多少个9”，每个9要精确一个数量级。

99扩展写入 99是4个9，而99。 999是五个九。 每个经理在回答“有多少个9”这个问题时总是说:“我能拿多少就拿多少。”

“听起来不错，但现实是需要权衡取舍！ 许多应用程序可以容忍几分钟的停机时间，而影响最小。

  • Replicating from a XtraDB Cluster to a DR site
    • 查看您的环境时，了解您的工作负载非常重要。
    • 您的工作负荷是读、写还是两者兼而有之？
    • 了解您是否需要扩展读取或写入对于选择高可用性解决方案非常重要:

缩放读数 大多数解决方案都提供了从多个节点或副本读取的能力

  • MHA、XtraDB集群、MySQL集群和其他集群都非常适合这种情况其他人尝试使用数据同步 主-主复制，这也是有问题的
  • XtraDB Cluster 这方面最好的解决方案可能是MySQL集群 配置新节点怎么样？
  • MySQL Cluster. 很大程度上，这是一个手动过程

MySQL实用程序使这比以往任何时候都更容易 分布式集群

  • HAProxy
    • XtraDB集群和MySQL集群使这变得更加容易
    • XtraDB群集使用状态转移(SST或IST)来自动化群集节点的过程 使用XtraDB集群，尝试拥有三样东西。
  • F5 BigIP
    • 如果您的节点在一个交换机上，请尝试使用三个交换机。
  • MaxScale
    • 出于投票原因，奇数是首选。
  • 忘记尝试在只有两个数据中心的故障期间保持一个群集的活动状态吧。

你最好把一个变成灾难恢复站点。 忘记定制权重，试着通过两个数据中心。 无论如何，51%规则会让你如愿以偿！

  • A power outage in a single data center could lead to issues
    • 运行多个数据中心对您采用的高可用性解决方案有影响。
    • 如果我只有一个数据中心呢？ 根据群集大小，您可以针对单个或多个故障节点获得保护。如果您有两个数据中心，您可能应该考虑将第二个数据中心作为灾难恢复解决方案。
  • Surviving a Reboot
    • 灾难恢复规划在您的高可用性环境中至关重要。
    • 确保灾难恢复节点能够处理流量，即使是在最低性能级别。

从数据库集群复制到灾难恢复站点 从XtraDB集群到单个节点的异步复制

从XtraDB集群到复制拓扑的异步复制 从Extradb集群到另一个Extradb集群的异步复制 尤其是现在，有大量的存储引擎可用于数据库环境。

您应该在高可用性解决方案中使用哪一种？ 您的解决方案将帮助您确定可以使用哪种存储引擎。 不依赖于存储引擎

。 适用于所有存储引擎 超数据库集群

。 需要InnoDB。 对MyISAM的支持是实验性的，不应用于生产

MySQL集群 。 需要NDB存储引擎 负载平衡器提供了一种在环境资源间分配工作负载的方法，这样就不会在任何一个特定点造成瓶颈。

以下是一些负载平衡选项:

  • HAProxy
  • 开源软件解决方案
  • 无法分割读取和写入。
  • 如果这是一个要求，应用程序将需要这样做！

F5 BigIP

相关推荐