iTop使用MGR集群

MySQL Group Replication 能比较方便的实现高可用,但是 iTop 文档里明确说不支持多主的 MySQL 集群:

Galera clusters with multiple masters are NOT supported by iTop, because such clusters do not properly implement the GET_LOCK MySQL function (for more information: Galera cluster known limitations).

MGR 文档里也明确说不支持 GET_LOCK

Table Locks and Named Locks.  The certification process does not take into account table locks (see Section 13.3.6, “LOCK TABLES and UNLOCK TABLES Statements”) or named locks (see GET_LOCK()).

那么到底是哪些功能会受到影响呢?

架构

计划分别测试 iTop 使用 单主(Single Primary) 和 多主(Multi Primary) 模式的 MGR 集群,以及单节点,对比结果。以下是 MGR 单主和多主的架构图。

iTop MGR单主模式
iTop MGR单主模式
iTop MGR多主模式
iTop MGR多主模式

代码分析

搜索代码,可知 GET_LOCK 主要在 iTopMutex 类的 Lock() 方法里用到。

继续搜索 ->Lock(,找到以下文件:

下面基于 core/counter.class.inc.phpcore/ormlinkset.class.inc.php以及 core/ownershiplock.class.inc.php 来测试 MGR 的影响。其他文件基本是关于日志和备份的。暂时没有想到测试用例。

测试用例

core/counter

此文件定义了 iTopCounter 类,IncClass() 方法用到了 iTopMutex,此方法最终用在了 TicketMakeTicketRef() 里,被用户生成工单编号,即 R-000001 这种编号。

测试思路,并发创建工单,查看是否有重复的工单编号。编写以下 Shell 脚本:

使用 parallel 同时在 3 个 iTop 实例上并发调用:

结果出现较多重复编号:

iTop 使用MGR集群创建工单出现重复编号

MGR单主和单节点未出现重复工单编号。

core/ormlinkset

OrmLinkSet 类的 DBWrite() 方法使用了 iTopMutexDBWriteDBObjectDBWriteLinks 调用。DBWriteLinks 又被 DBOjectDBInsertNoReloadDBUpdate 调用。

测试思路,并发更新 Personteam_list,观察是否创建重复的 lnkPersonToTeam。编写以下 Shell 脚本:

使用 parallel 同时在3 个节点上并发操作:

多主,单主及单节点均出现重复创建的 lnkPersonToTeam

iTop MGR ormLinkSet测试

此项测试单节点也有问题,有可能是测试用例设计的有问题。

core/ownershiplock

主要用在 CMDBAbstractObjectDisplayModifyFormDisplayStimulusForm 中。用于阻止并发修改。

注意到代码中检查了配置项 concurrent_lock_enabled

可知阻止并发修改是一个可选的功能,默认是关闭的,如需使用,要在配置文件中开启[3]。 此功能效果是,当有人正在编辑一个对象时,其他人浏览该对象,会提示对象被锁住,正在被某人修改,并且不显示修改按钮。

iTop 阻止对象并发修改

测试结果显示

  • MGR多主模式下不同iTop实例编辑同一对象,此功能无效
  • MGR多主模式下在同一iTop实例操作,此功能正常
  • MGR单主模式及单节点,此功能正常

结论

测试结果对照表

测试项MGR多主MGR单主单节点备注
工单编号出现重复项未见异常未见异常 
Ormlinkset出现多lnk情况出现多lnk情况出现多lnk情况可能测试用例错误
阻止并发修改不同实例下异常未见异常未见异常 
iTop MGR测试结果

因此,iTop 使用 MGR 单主模式可以在实现高可用的前提下获得最好的兼容性。

参考资料

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注