Facebook应用了洪量的MySQL以撑持他们最首要的劳动。并且他们踊跃开辟了很多MySQL中的新机能，以撑持不休进展的须要。这些更始性格产生在MySQL的不同范畴，囊括客户端接连器、储备引擎、优化器和复制。当Facebook对MySQL的每个新要紧版本举办晋级时，碰面对很多挑战，囊括：
将Facebook的自界说机能移植到新版本
保证复制在要紧版本之间兼容
最小化现有运用程序盘诘所需的更始
修理效劳器，以避免Facebook的劳动负载的本能退步
Facebook上一次晋级到MySQL5.6的要紧版本花了一年多的时候才推出。当5.7版发表时，他们仍在开辟5.6版上的LSM-Tree储备引擎MyRocks。由于害怕晋级到5.7会缓解MyRocks的开辟进度，他们那时取舍了维持5.6版本，直到MyRocks的开辟达成。MySQL8.0是在Facebook将MyRocks摆设到用户数据库(UDB)效劳层时发表的。
MySQL8.0版本囊括不少惹人注视标机能，譬喻基于写集的并行复制和供应原子DDL撑持的工做数据字典等等。Facebook盼望在MySQL社区中维持灵活，特为是他们在MyRocks储备引擎上的劳动。8.0中的增加机能，如立即DDL，也许加快MyRocks架构更始。思索到代码革新的便宜，Facebook决议转变到8.0。当他们着末肯定项目标规模时，发觉转变到8.0比转变到5.6或MyRocks愈加窘迫。
那时，Facebook定制的5.6分支有超越1,个代码补钉也许移植到8.0。在他们移植这些更始时，Facebook新的MySQL机能和修理不休被增加到5.6代码库中，进而使方向变得更远。
Facebook有洪量的MySQL效劳器在临盆中运转，为洪量不同的运用程序供应效劳。他们还占有效于办理MySQL实例的软件根本设备。这些运用程序履行诸如采集统计数据和办理效劳器备份之类的职掌。
从5.6晋级到8.0齐全跳过了5.7。在5.6中应用的某些API将在5.7中被弃用，并或者在8.0中被节略，这请求Facebook革新应用这些API的运用程序。
Facebook的很多机能与8.0中的相同机能不上前兼容，须要弃用和上前转变。
MyRocks增加机能须要在8.0中运转，囊括本机分区和崩溃复原。
代码补钉Facebook首先摆设了8.0分支，用于在他们的开辟处境中举办建设和测试。尔后，他们着手了从5.6分支移植补钉的悠久路程。着手时有1,多个补钉，也许将它们分为几个要紧种别。Facebook的大大都自界说代码都有很好的诠释和描摹，因而他们也许轻便肯定运用程序能否依然须要它，也许能否也许节略。但一些补钉特别朦胧，须要发掘旧的打算文档、帖子或代码稽察谈论以相识它们的史书。
Facebook用4个种别分辨每个补钉的类别：
节略：不再应用的机能或在8.0中具备等效机能，不须要移植。
建设/客户端：移植了撑持Facebook的建设处境和修悔改的MySQL器械（如mysqlbinlog）或增加的机能（如异步客户端API）的非效劳器机能。
非MyRocks效劳器：移植了mysqld效劳器中与MyRocks储备引擎无关的机能。
MyRocks效劳器：移植了撑持MyRocks储备引擎的机能。
Facebook应用电子表格跟踪每个补钉的形态和相干史书音信，并在节略补钉时纪录他们的推理。革新相同机能的多个补钉被组合在一同举办移植。移植并提交到8.0分支的补钉应用5.6提交音信举办了诠释。不成避免地会涌现移植形态的差别，由于他们须要挑选洪量补钉，这些诠释协助他们束缚了这些题目。
每个客户端和效劳器种别成为软件发表的历程碑。移植一切与客户审察关的更始后，Facebook将客户端器械和接连器代码革新到8.0。一旦移植了一切非MyRocks效劳器机能，Facebook就也许为InnoDB效劳器摆设8.0mysqld。达成MyRocks效劳器机能使Facebook也许革新MyRocks装置。
一些最繁杂的机能须要对8.0举办巨大更始，并且一些范畴存在巨大兼容性题目。譬喻，8.0binlog事项格式与咱们的一些自界说5.6窜改不兼容。Facebook5.6机能应用的过错代码与上游8.0分派给新机能的过错代码相摩擦。最后Facebook须要窜改5.6效劳器以与8.0上前兼容。
达成一切这些机能的移植花了几年时候。最后，Facebook曾经评价了,00多个补钉并将个中的1,个移植到8.0。
转变路途Facebook将多个mysqld实例组合成一个MySQL副本集。副本聚合的每个实例都包罗相同的数据，但在地舆上散布到不同的数据中间，以供应数据可用性和毛病转变撑持。每个副本集有一个主实例。另外实例都是帮忙实例。主节点责罚一切写入流量并将数据异步复制到一切帮忙节点。Facebook从由5.6主/5.6从构成的副本集着手，最后方向是具备8.0主/8.0从的副本集。遵命了一个相同于UDBMyRocks转变的规划。
关于每个副本集，应用mysqldump经过逻辑复制，缔造和增加8.0从副本。这些帮忙节点不供应任何运用程序读取流量。
在8.0帮忙节点上起用读取流量。
准许将8.0实例擢升为主实例。
读取流量禁用5.6实例。
节略一切5.6实例。
每个副本集均也许自力地过渡上述每个环节，并依照须要逗留在一个环节上。Facebook将副本集分红更小的组，并在屡屡更动中举办领导。若是发觉题目，也许回滚到上一步。在某些情景下，副本集也许在另外环节着手以前来到着末一步。
为了主动化洪量副本集的更动，Facebook建设了新的软件根本设备。它们也许将副本集分组在一同，并经过容易地更始摆设文献中的一行来将它们挪移到每个阶段。任何碰到题目的副本集均也许独自回滚。
基于行的复制做为8.0转变劳动的一部份，Facebook决议应用基于行的复制(RBR)。一些8.0机能须要RBR，它简化了MyRocks移植劳动。纵然Facebook的大部份MySQL副本集曾经在应用RBR，但仍在运转基于语句的复制(SBR)的副本没法轻便更动。这些副本集常常是没有任何高基数键的表。因而，Facebook将RBR做为8.0的请求。在评价并为每个表增加主键后，他们切换了往年着末一个SBR副本集。应用RBR还为Facebook供应了一种替换束缚规划，用于束缚咱们在将一些副本集挪移到8.0主版本时碰到的运用程序题目，稍后将对此举办议论。
主动化考证大大都8.0转变进程波及应用Facebook的主动化根本设备、运用程序盘诘测试和考证mysqld效劳器。
跟着MySQL机群的增进，Facebook用来办理效劳器的主动化根本设备也在增进。为了保证一切的MySQL主动化都与8.0版本兼容，Facebook投资建设了一个测试处境，该处境行使测试副本集和假造机来考证举动。Facebook编写了集成测试来探测在5.6版本和8.0版本上运转的每一部份主动化，并考证它们的确实性。在举办测试时，Facebook发觉了几个过错和举动差别。
由于每个MySQL根本设备都针对Facebook的8.0效劳器举办了考证，他们发觉并修理了很多兴趣的题目：
从过错日记、mysqldump的输出或效劳器显示吩咐文本输出的剖析软件很轻易被毁坏。效劳器输出的渺小变动常常会展示器械剖析逻辑中的过错。
8.0的默许utf8mb4排序法则摆设致使Facebook的5.6和8.0实例之间的排序法则不般配。以至是5.6的showcreatetable生成的create语句，由于8.0表或者会应用新的utf8mb4_排序法则，应用utf8mb4_general_ci的5.6形式没有明白指定排序法则。这些表差别常常会致使复制和形式考证器械涌现题目。
某些复制失利的过错代码产生了变动，必需修理Facebook的主动化器械以确实责罚它们。
8.0版本的数据字典废除了表.frm文献，但Facebook的一些主动化器械应用它们来探测表架构的窜改。
必需革新Facebook的主动化器械以撑持8.0中引入的动态权力。
运用考证Facebook盼望运用程序的更动尽或者晶莹，但一些运用程序盘诘会涌现本能降落或在8.0上履行失利。
关于MyRocks转变，Facebook建设了一个MySQL影子测试框架，用于拿获临盆流量并将其重放到测试实例。关于每个运用程序劳动负载，Facebook在8.0上建设测试实例并向它们重放影子流量盘诘。经过拿获并纪录了从8.0效劳器返回的过错，发觉了一些兴趣的题目。但并非一切题目都在测试进程中被发觉。譬喻，在转变进程中运用程序发觉了工做死锁。在协商不同的束缚规划时，Facebook也许有时将这些运用程序回滚到5.6。
8.0中引入了新的保存关键字，个中一些与运用程序盘诘中应用的表列名和别号相摩擦，譬喻组和排名。这些盘诘没有经过反引号对称号举办转义，进而致使剖析过错。应用将盘诘中列名举办主动转义的运用程序没有碰到这些题目。束缚这个题目很容易，但追踪运用程序一切者和生成这些盘诘的代码库须要时候。
在5.6和8.0之间还发觉了一些REGEXP不兼容题目。
一些运用程序在InnoDB上的反复键盘诘上碰到了波及insert…的可反复读取工做死锁。5.6的过错，在8.0中获得矫正，但修理增进了工做死锁的或者性。在剖析了Facebook的盘诘往后，他们经过消沉隔绝级别来束缚题目。由于Facebook已切换到基于行的复制，因而也许应用此选项。
Facebook的自界说5.6文档储备和JSON函数与8.0不兼容。应用文档储备的运用程序须要将文档类别更动为文本以举办转变。关于JSON函数，Facebook向8.0效劳器增加了5.6兼容版本，以便运用程序也许在往后转变到8.0API。
Facebook对8.0效劳器的盘诘和本能测试时，发觉了一些须要马上束缚的题目。
在ACL缓存方圆发觉了新的互斥量争用热门。当同时翻开洪量接连时，它们均也许阻拦搜检ACL。
当存在很多binlog文献且高binlog写入速度经常轮换文献时，binlog索引拜访也会涌现相同的争用。
几个波及偶尔表的盘诘被毁坏。盘诘将返回无意过错或运转时候太长而超时。
内存应用与5.6比拟有所增进，特为是关于MyRocks实例，由于必需加载8.0中的InnoDB。默许的performance_schema摆设起用了一切目标并损耗了洪量内存。Facebook经过仅起用少许目标，并更始代码以禁用没法手动闭塞的表来束缚内存应用。然则，并非一切增进的内存都由performance_schema分派。须要搜检和窜改各样InnoDB内部数据组织，以进一步增加内存占用。这些将8.0的内存应用率消沉到可接纳的程度。
下一步是甚么到方今为止，8.0转变曾经消费了几年时候。Facebook已将很多InnoDB副本集更动为齐全在8.0上运转。另外的大大都都处于转变路途的不同阶段。此刻Facebook的大部份自界说机能都已移植到8.0，革新到Oracle的次要版事实对轻易，但咱们规划跟上最新版本的步调。
跳过像5.7如此的要紧版本引入了Facebook的转变须要束缚的题目。
首先，没法立地晋级效劳器，须要应用逻辑转储和还平昔建设新效劳器。然则，关于特别大的mysqld实例，这在时刻临盆效劳器上或者须要不少天，并且这个脆弱的进程或者会在它达成以前被停顿。关于这些大型实例，Facebook不得不窜改备份和复原系统来责罚再建。
其次，探测API更始要窘迫不少，由于5.7也许向运用程序客户端供应弃用告诫以修理潜在题目。Facebook须要运转额外的影子测试来发觉毛病，尔后才力转变临盆劳动负载。应用主动转义架构方向称号的mysql客户端软件有助于增加兼容性题目的数目。
在一个副本聚合撑持两个要紧版本是很窘迫的。一旦副本集将其主实例擢升为8.0实例，最佳尽量禁用并节略5.6实例。运用程序用户每每会发觉仅8.0撑持的新机能，譬喻utf8mb4_排序法则，应用这些机能或者会停顿8.0和5.6实例之间的复制流。
纵然在转变进程中Facebook碰到了一切妨碍，但他们曾经看到了运转8.0的便宜。一些运用程序取舍提早更动到8.0，以行使文档储备和改善的日期时候撑持等机能。总的来讲，新版本极地面平添了Facebook也许用MySQL做的事项。
预览时标签不成点收录于合集#个