之前,我们已经讨论了MySQL分片的应用和设计挑战,以及一些可能导致和影响您的业务灵活性的相应业务挑战。 但是，MySQL面临的挑战是什么呢？
作为参考,这里有一个快速的pr & eacuteMySQL分片:MySQL分片是一种将MySQL应用程序工作负载划分到多个不同的MySQL数据库服务器上的策略,允许查询和数据CRUD操作分散开来。 这围绕着MySQL的单写主机架构工作,提供了向外扩展写和读的能力,尽管需要权衡。 这是一个大的DevOps项目。
既然我们已经看到了MySQL对业务规则支持的挑战,那么让我们来看看MySQL的挑战。
一旦选择了切分键,数据就需要在MySQL服务器阵列中进行物理分布。 这些服务器中的每一个都需要它自己的数据库用于它自己的一组数据分区。 初始数据分发可以是手动的；这更像是”一次性设置” .”但是,随着您的工作负载增加,会发生什么情况？ 理想情况下,每个碎片都是均等生长的,但有时生命会发生。
MySQL分片阵列面临两个主要的持续数据维护容量挑战：
- 碎片生长。
- 碎片热点。
碎片增长意味着您的一个或多个碎片将超过底层服务器的存储容量。 热点意味着您的一个或多个碎片服务器正在经历争用,例如,中央处理器或网络流量,即使它不在存储容量附近。 碎片增长和热点都会导致服务器性能下降,两者都有类似的解决方案：分割本地碎片,并将数据（例如,一半(移动到不同的MySQL服务器。 这对DevOps来说是一项重要的工作。
从业务角度来看,碎片增长是积极的；增长是好的。 然而,这种增长代表了一些DevOps挑战,因为这意味着进一步的数据分发是必要的。 简而言之,每台MySQL服务器都需要足够的”空闲空间”来增长,否则事务会开始变慢,甚至失败。 最佳做法是至少有40%的可用存储,平均中央处理器利用率在60%到70%之间。 一旦存储超过90%，这将对MySQL的性能产生影响。 要么服务器需要升级它们的磁盘和/或存储区域网络,要么本地碎片需要被分割,新的碎片”一半”被移动到不同的MySQL服务器。 理想情况下,将碎片转移到新服务器以最大化增长潜力,但有时资本支出预算要求进行整合。 在这种”合并”碎片的情况下,确保新的分割碎片不会在其新的共享服务器上造成争用是非常重要的,否则您将不得不再次移动它。 这很容易造成一些重大的MySQL分片DevOps挑战。
碎片热点意味着访问/数据不对称。 这充其量只是暂时的,随着时间的推移会自行解决。 最坏的情况是,这意味着MySQL分割键（策略(有问题,可能需要重新考虑。 这将需要重新分配整个数据工作负载,这意味着大量停机或大量冗余硬件支出。 碎片增长耗尽了本地存储,而碎片热点造成了网络、中央处理器和/或潜在的存储争用。 热点不是存储容量的问题；可能还剩下很多磁盘空间。 然而,数据库使用模式是由本地服务器上驻留的数据驱动的,所以处理这种热点的最直接的方法是进一步划分本地碎片,这意味着MySQL碎片化带来了更多的DevOps挑战
管理碎片分裂可能很棘手。 最简单的解决方案是让DevOps将碎片脱机,拆分,将新的半碎片移动到新的服务器,更新碎片：服务器映射LUT，然后将脱机碎片重新联机。 这将导致离线碎片上的所有事务应用程序（正常(失败。 从业务角度来看,这意味着将客户、特性或功能的子集离线。 例如,一些大型游戏公司进行定期维护,所有被修改的碎片上的客户（数千人(离线数小时。
但是对于要求高可用性的高容量/高价值的MySQL应用程序,由于每个碎片都是冗余的（例如,每个碎片都有一个用于高可用性的从机)，碎片更改可以在从机上完成,而生产不受影响。 一旦碎片被分割和移动,那么复制就需要赶上从机到主机的位置。 准备好了,提升奴隶,降职主人,然后交接。 这就用最少的停机时间换取了更多的开发工作。
一旦碎片被分割,并且一半的工作负载随着新碎片被移动到不同的（理想情况下是新的(节点,现在包含一半数据的原始本地服务器的工作负载应该会下降50% . 如果没有,那么碎片分割过程可能需要重复。 如果新创建的碎片被移动（共享(到另一个现场服务器,例如g.,由于预算限制。 在这种情况下,需要仔细检查该服务器的新使用模式,否则可能会出现”拆东墙补西墙”的情况。
碎片合并可能会定期有用。 如果业务提供发生变化,会发生什么？ 或者在用户访问模式中存在高峰/季节性,例如黑色星期五、黄金日或光棍节？ MySQL分片阵列在季节高峰时可以处理3到5倍的访客,但今年剩余时间严重超负荷。 但事实证明,由于分片合并需要与分片拆分相似的工作量,许多企业MySQL分片部署并不麻烦。 在这种情况下,任何后续的碎片分割将被转移到共享当前使用的MySQL服务器,而不是部署新的服务器。
“数据维护”硬币的另一面是基础设施。 无论是分片增长、热点、拆分还是分片：服务器映射,所有这些都需要DevOps来部署、升级、维护、备份和淘汰/更换服务器。 这些任务中的一些可以在云上变得更容易,尤其是部署速度,但是它们仍然需要被管理,并且仍然会对分割的MySQL应用程序和许多分割的DevOps挑战构成挑战。
具体来说,分割的MySQL应用程序有三个主要的基础架构挑战：
- 服务器物流。
- 服务器备份。
- 高可用性。
MySQL分片阵列的服务器后勤分为三个粗略的组:MySQL服务器本身（对高可用性而言可能是冗余的)，分片：服务器映射以及阵列中所需的任何复制策略,例如g.,以避免跨节点事务。 MySQL服务器很简单；购买（或租赁(具有最佳价格/性能的实例大小。 但是随着分片阵列变得越来越大,节点开始处于不同的生命阶段。 某种周期性的背景心跳和/或烟雾测试对于确定哪些服务器的性能落后,以及哪些服务器应该被替换是有用的。 由于高可用性,这一切都翻倍了。 在MySQL中,高可用性通常是通过一个从实例来实现的,它是主实例的完整拷贝。 因此,这是所需MySQL服务器数量的两倍,包括购买/租赁（资本支出(和管理(OPEX). 简而言之DevOps还有很多工作要做。
分片：服务器映射对于MySQL分片数组来说至关重要。 应用程序必须始终知道哪个MySQL服务器包含每个事务的数据。 通常这种映射是用Redis或Memcache完成的。e.快速内存键值存储,提供主键、分片键、数据库名、服务器id、服务器知识产权等之间的LUT(查找表(交集。 这允许应用程序在对运行中的事务影响最小的情况下进行动态查找。 这还需要部署和维护额外的LUT/地图服务器。 他们真的应该是多余的；如果没有这些数据,分片阵列就会瘫痪。
对于本地碎片上需要的任何数据,跨节点复制都是必要的。 这允许本地碎片上的事务避免跨节点事务,以及提供引用完整性和酸保证所需的重大应用程序修改。 如果需要跨节点复制,这将为DevOps增加一层全新的复杂性,确保在每个节点上创建从进程,在必要的主节点上设置binlogs，并监控/确保复制延迟在合理的范围内。
由于没有单一的关系数据库管理系统来管理阵列中的所有MySQL服务器,因此无法通过编程方式获得一致的备份。 可以使用MVCC启动备份,确保每台服务器的事务状态一致,但即使使用NTP(甚至是本地原子钟)，本地服务器时间也不会与其他服务器完全匹配。 如果每台服务器完全独立运行,这不是什么大问题；如果业务规则严格避免跨节点事务,那么”足够接近”就足够了。 然而,在与许多公司的DevOps主管交谈后,他们都倾向于对他们的备份策略不满意。 选项包括使用sqlserver数据库同步 数据块存储卷和在一个时间点同时进行数据块拷贝。 一些云提供商在其托管产品中也有快照备份选项,但阵列中每个节点的同步快照仍需要同步。 同样,从备份中恢复节点可能很棘手,需要使用复制来前滚以匹配其他节点的事务状态。 最后,再次同步所有MySQL碎片有时需要在碎片之间滚动重启。 谈论MySQL分割DevOps的挑战！
所有这些复杂性导致一些部署更加注重高可用性,而不是确保一致的备份。
最后,让我们讨论一下与高可用性相关的MySQL分片挑战。 一般来说，MySQL应用程序需要分片所提供的规模,提供需要高度可用的高容量/高价值事务。
这意味着DevOps需要确保每台MySQL服务器都是完全冗余的。每个”碎片”实际上至少由两台服务器组成,或者是主/从配置,或者是主/主配置。 主/从是最容易设置的,但不能保证事务一致性。 主设备/主设备,特别是基于认证复制的,保证了在主设备/主设备之前,辅助设备/主设备拥有事务信息的副本。 这保证了如果主服务器在它之后但在次服务器之前发生中断,次服务器仍然可以完成该事务并接受主服务器发送回应用程序的确认。 不出所料,这种级别的事务一致性高可用性比常规的主/从异步复制更需要设置；用OPEX换取更高水平的高可用性。 简而言之,创建多个额外的MySQL分片DevOps挑战。
自动气象站无线电数据系统每隔五分钟自动提供一次快照备份。 乍一看,这似乎比为高可用性部署冗余服务器要简单得多,更不用说设置和维护所有需要的复制（例如,在不同的关系数据系统主机之间,不同于关系数据系统中已经提供的读取副本).
然而,五分钟的延迟意味着五分钟的事务丢失。 这不同于丢失”飞行中”的交易；如果服务器出现故障，”运行中”的事务通常会在MySQL中丢失。 由于这些事务没有完成,数据更新没有提交,也没有向应用程序发送确认。 但是,如果交易完成,例如,订单被接受,并且客户已经收到订单确认号,那么客户有合理的期望,如果随后服务器停机,交易将持续。 如果客户的付款方式减少了,他们可以根据法律管辖权诉诸法律。 但是如果没有高可用性,电子商务提供商将没有交易记录,即使信用卡公司有。
这是一种制造负面新闻、污点品牌等的无用之举。,然后又回到了DevOps和它的MySQL分片。
还有一个问题,如果您在云部署中没有租用保留的实例,这意味着当新实例上线时,五分钟的备份延迟会显著延长。
虽然分割MySQL肯定是一个公认的解决MySQL应用程序可伸缩性需求的策略,但它需要睁大眼睛来处理。 架构和物流规划都需要创建和审查,以帮助避免您可能给您的开放带来的MySQL分割的DevOps挑战十、资本支出预算。 分割MySQL总是很困难的，它的权衡是多种多样的，尤其是当你的开发团队继续维护分割数组时的连锁效应。 很容易提前做出决定，DevOps最终将付出努力和资源的代价，导致你的MySQL应用程序可能失去可信度。