作者:Arnab Ray 译:徐轶韬
在第1部分中,我们简要概述了各种协议和机制,这些协议和机制用于MySQL Cluster的数据节点和MySQL服务器的数据字典(DD)之间彼此保持同步。更具体地说,我们探讨了NDB Cluster 7.x版本中用户触发同步的实现问题。NDB Cluster 8.0中通过以下新功能解决了这些问题:自动模式同步(或简称为auto schema sync)。
引入了一个名为“元数据更改监视器”的新组件来检测NDB元数据的任何更改。该组件在后台运行,并以固定的,用户可配置的时间间隔将NDB字典的内容与MySQL服务器数据字典的内容进行比较。元数据更改监视器会检测到任何不匹配的情况,即NDB字典中存在元数据对象而MySQL服务器数据字典中缺少元数据对象的情况,反之亦然。检查不匹配的元数据对象包括:
元数据更改监视器将检测到的所有不匹配对象提交到队列中,这些对象最终将与NDB字典同步。这些对象最终由NDB事件处理组件进行同步,因此,不一致对象的发现和同步在设计上是异步的。NDB事件处理组件从队列的开头拾取一个对象,并尝试通过在MySQL服务器数据字典中创建或删除该对象来进行同步,具体取决于该对象是否存在于NDB字典中。控制模式对象同步的速率可以避免显着的性能开销。
在提高易用性方面,自动模式同步的主要目标是消除用户执行手动操作,以便在MySQL服务器中可以看到使用本机NdbApi进行的元数据更改。默认情况下,元数据更改监视器组件每60秒轮询一次不匹配项,以确保所有元数据更改最终都可以传播到MySQL服务器,而无需任何用户干预。可以通过将MySQL服务器系统变量ndb_metadata_check
设置为1或0 来启用或禁用该功能,同时可以使用ndb_metadata_check_interval
系统变量来调整间隔。间隔越短,不匹配的检测和同步就越快,但这也会导致更多的资源消耗,这是用户必须警惕的折衷方案。
MySQL服务器状态变量:Ndb_metadata_detected_count
和Ndb_metadata_synced_count
,分别包含检测到和同步的对象数的计数。
上述机制可确保元数据最终出现在MySQL服务器的数据字典中,并且还可以作为某些失败的模式分发或模式同步尝试的后备选项。但是,它并不是直接替代以前的SHOW TABLES
行为。例如,应用程序需要使用ndb_restore工具还原元数据,然后确保所有元数据现在都存在于MySQL服务器中,然后再继续进行进一步的处理。在这种情况下,通过轮询元数据更改监视器和队列同步实现的最终一致性是不理想的,因为这将需要其他应用程序逻辑来查看元数据是否存在或轮询上述状态变量,直到检测到所需状态为止。为了解决这个问题,引入了一个新的MySQL服务器系统变量,称为ndb_metadata_sync。
为了方便起见,在MySQL手册中对用法进行了很好的总结,为方便起见,以下逐字引用:
设置此变量将导致更改监视器线程覆盖为ndb_metadata_check或ndb_metadata_check_interval设置的任何值,并进入持续更改检测阶段。当线程确定没有更多要检测的更改时,它将停止直到二进制日志记录线程完成所有检测到的对象的同步为止。然后将ndb_metadata_sync设置为false,更改监视器线程将还原为由ndb_metadata_check和ndb_metadata_check_interval的设置确定的行为。
可以借助一个小示例来证明这一点,如下所示:
假设使用ndb_mgm客户端(为简洁起见,已跳过)备份了上述元数据,然后使用MySQL客户端删除了数据库'db1'。ndb_restore程序可用于在NDB字典中创建元数据,但不能在MySQL服务器的数据字典中创建元数据。用户不必等待定期轮询来查找不匹配并同步模式,而只需将ndb_metadata_sync
变量设置为true并等待直到它自动变回其默认值false即可。
在NDB Cluster 7.x实现中,采用一个全局锁,该锁跨越了同步活动的整个持续时间。通过自动模式同步,现在仅保留多个短的时间间隔。NDB事件处理组件基于每个对象获取(并释放)此全局锁。需要注意的重要一点是,在获取这个锁时使用try-lock策略。并且上锁的生命周期很短,使得自动模式同步不那么具有侵入性,不会对同时发生的其它DDL更改产生过多的影响。
SHOW TABLES
期间没有额外的开销 在NDB Cluster 8.0中,SHOW TABLES查询只做这些。NDB Cluster 7.x版本附加的同步和锁方面的资源争用已经完全删除。
元数据更改监视器组件仅用于检测任何不匹配项,并将其提交给NDB事件处理组件。NDB事件处理组件实际上负责在修改MySQL服务器的数据字典时获取适当的全局和元数据锁。这与模式同步和模式分发协议的设计相符,因此从设计角度调整了3种不同的机制。从代码的角度来看,这也可以删除部分代码,因为该功能被封装在一个地方。
此功能面临的一个有趣的设计挑战是NDB事件处理组件面临执行中的永久错误而无法同步对象的情况。在这种情况下,元数据更改监视器可以一次又一次地检测到相同的不匹配,并且NDB事件处理组件可以(可能)连续尝试失败。通过维护NDB事件处理组件未能同步的对象黑名单,可以防止此情况。失败时,该对象将被列入黑名单。然后,期望用户通过尝试使用SELECT
或者SHOW
来发现对象,在更极端的情况下触发MySQL服务器与MySQL Cluster的重新连接,从而解决不匹配问题。可以使用以下变量Ndb_metadata_blacklist_size
检查黑名单中存在的对象数量。
只要对象存在于黑名单中,元数据更改监视器就会在后续迭代中将其忽略。 在下一个检测周期开始时,元数据更改监视器将对黑名单中的对象进行验证。检查黑名单中的每个对象,以查看不匹配是否仍然存在。如果不,则从该黑名单中删除该对象,并从那时起将其视为自动模式同步的候选对象。如果不匹配仍然存在,则在另一个检测周期内将忽略该对象,并将继续忽略该对象,直到用户手动干预以纠正不匹配为止。
从用户的角度来看,由于NDB Cluster 8.0中的自动模式同步而导致的主要变化是,使用ndb_restore工具还原的元数据如何传播到MySQL服务器的数据字典。
在7.x版本中,用户应执行以下查询以同步更改:
在8.0中,用户可以简单地等待更改的定期轮询和同步。可以通过调整MySQL服务器系统变量ndb_metadata_check_interval
来更改轮询周期:
另外,在8.0中,用户可以将MySQL服务器系统变量ndb_metadata_sync设置为true,然后等待它自动变回false:
在该领域中,有更多的工作在计划中,它们将增加功能并在愿望清单的顶部向用户显示更多细节。与任何新功能一样,社区的早期反馈非常重要,非常值得赞赏!
本文分享自 MySQL解决方案工程师 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!