一种基于DNS和MGR的MySQL高可用实现方法与流程

一种基于dns和mgr的mysql高可用实现方法
技术领域
1.本发明涉及数据库技术领域，具体涉及一种基于dns和mgr的mysql高可用实现方法。


背景技术：

2.数据库作为信息系统数据存储设备，主要提供了数据的存储与访问功能，其往往是信息系统的核心。随着数据库技术的快速迭代与发展，目前各数据库厂商提供了更多的功能和特性，其中就包括数据库高可用技术。
3.数据库高可用技术是指通过数据库软件自身特性，提供了一种在部分节点因服务器、操作系统或数据库软件等发生故障后，能持续提供服务的一种技术。mysql数据库作为各行业广发使用的一种技术，先后提供异步主从、半同步主从及最新的mgr分布式技术，技术和方案日趋完善和成熟。
4.mgr指mysql组复制(mysql group replication)，是mysql数据库自5.7版本开始基于paxos分布式协议提供的一种同步技术。通过该技术对主备同步的事务日志进行冲突检查和分析，从而保证数据库服务和数据在极端场景下的一致性。
5.域名解析系统(domain name service，dns)是提供域名和ip地址映射关系的一种服务，其主要目的应用系统通过配置域名服务器，通过访问具有业务含义的域名即可访问真正的服务，无需关心ip地址，实现应用配置的统一，从而降低维护的难度。dns已逐渐成为各行各业信息系统建设的标准配置。目前业界已提供完善的解决方案，包括商业版本zdns、开源版本bind、bind-dlz等。
6.综合以上技术，由于数据库和dns分属于不同的技术领域，未进行有效的整合。数据库虽然提供了主从同步、mgr等完善的同步方案，但切换完成后应用无法识别，应用需自主实现相关功能。业界常见方案及其优缺点分析如下：
7.1.基于vip的切换方案。该方案通过单独的控制服务器对数据库节点进行探测，当发现主节点探测失败后启动故障切换，提升从节点为主。但由于采用数据库之外的节点进行探测，当因为异常的网络隔离、服务器假死等原因触发故障切换，可能引发数据库发生脑裂，导致数据丢失；同时，控制节点由于其特殊性，往往采用单节点或主备架构，在面对复杂故障场景时，其自身可能会发生故障，导致无法执行切换操作；此外，该方案多由第三方机构实现，其核心的切换逻辑与数据库版本强关联，存在与实际所使用数据库版本不兼容导致高可用方案失效的可能，特别是当前mysql8版本。
8.2.中间代理方案。该方案通过在数据库和应用之间建立代理层，通过代理层识别数据库的主节点，然后提供与数据库相近的协议供应用连接。数据库主节点发生故障后，中间代理识别到新的节点，然后重建应用连接至新的数据库节点。但因为需引入额外中间代理层，任何一个数据库请求都需要通过中间代理层，必然会导致应用的整体架构更加复杂、请求路径更多、耗时更长等问题。同时，应用代理往往通过第三方组织，通过对mysql常见操作的模拟，以实现兼容，但必然存在中间代理无法识别的操作，将需要进行额外的兼容性改
造；此外，中间代理层自身可能存在高可用问题、性能瓶颈等问题。
9.3.基于dns健康检查方案。该方案通过dns服务器对数据库定期进行检查，当发现原主节点故障引起状态发生改变后，更新对应的域名的ip为新主节点的ip。但该方案仅提供了应用在数据库发生切换后，如何连接数据库，未提供完整的方案，包括数据库如何进行故障切换、数据不丢失、应用能根据更新后的域名信息连接到新主节点；同时，还依赖于特定的dns产品，以实现基于数据库主动探测功能，普遍推广价值不足。


技术实现要素：

10.本发明的目的是针对现有技术存在的不足，提供一种基于dns和mgr的mysql高可用实现方法。
11.为实现上述目的，本发明提供了一种基于dns和mgr的mysql高可用实现方法，包括：
12.步骤1、进行数据库集群的安装与上线配置；
13.步骤2、对探针进行初始化，然后进行对运行中的数据库集群进行探测；
14.步骤3、根据探测获得的数据库集群架构、事务堆积情况以及域名ip判断数据库集群运行是否正常，具体包括：
15.若数据库集群主节点ip等于域名ip，且数据库集群节点等于配置节点，则表示集群运行正常；
16.若数据库集群主节点ip等于域名ip，但数据库集群节点不等于配置节点，表示存在从节点运行异常，触发告警；
17.若数据库集群主节点ip不等于域名ip，且本节点ip等于数据库集群主节点ip，触发故障切换流程；
18.若数据库集群主节点ip不等于域名ip，且本节点ip不等于数据库集群主节点ip，触发告警。
19.进一步的，所述故障切换流程包括：
20.通过分布式一致性协议选择新主节点，原主节点数据库实例终止或进入离线模式，并调整探测间隔时间；
21.解析数据库运行状态，确认新主节点是否存在未应用完成的事务；
22.堆积的事务应用完成后，若本节点为新主节点，则探针发起dns切换流程；
23.在dns切换成功后，若dns存在缓存，执行dns缓存的刷新操作；
24.进行域名ip、新主节点ip及ping结果的校验，校验成功即表示故障切换完成；
25.恢复探测间隔为配置间隔时间，继续执行探测。
26.进一步的，所述dns切换流程包括更新前域名与ip的一致性校验、更新域名的ip、更新后域名与ip的一致性校验，对于商业dns设备使用其提供的api接口进行检查和更新，对于开源dns设备使用远程命令或sql请求等方式进行更新，最后校验成功即dns切换成功，否则表示发生异常，将退出。
27.进一步的，所述步骤1具体包括：
28.步骤1.1、进行资源申请与配置；
29.步骤1.2、进行数据库软件部署；
30.步骤1.3、进行参数配置优化；
31.步骤1.4、进行数据库初始化并启动；
32.步骤1.5、进行用户与权限配置；
33.步骤1.6、进行mgr插件与参数配置；
34.步骤1.7、启动mgr操作；
35.步骤1.8、配置并启动各数据库节点探针，至此，完成该数据库节点的配置，并以此逐步完成所有数据库节点的配置；
36.步骤1.9、应用系统根据配置的数据库域名、用户名和密码等信息，连接数据库集群。
37.进一步的，所述步骤2具体包括：
38.步骤2.1、读取固定路径配置文件，确认配置文件格式是否非法、参数值是否合理；
39.步骤2.2、解析得到数据库登陆信息、登陆数据库查询变量、集群结构和事务堆积情况；
40.步骤2.3、校验所述集群结构与配置文件中的信息是否匹配，若配置信息的节点集合等于或包含数据库实时集群架构，则校验返回成功，否则返回失败；
41.步骤2.4、根据域名执行ping操作，获取域名对应的ip地址；
42.步骤2.5、对dns更新接口进行校验，然后打印初始化信息，并对初始化配置进行合理校验。
43.进一步的，在故障切换流程完成后，对故障进行修复，具体包括：
44.分析数据库集群发生故障切换的根本原因，根据分析结果确认是否需要对操作系统、数据库、探针等组件进行优化；
45.检查操作系统运行状态、日志等数据，确认是否需要执行操作系统层面的修复操作，若因操作系统缺陷导致故障切换，则重启操作系统；
46.检查数据库错误日志，确认是否需要执行数据库实例的修复操作，若数据库实例或进程异常触发故障切换，则重启数据库；
47.确认故障节点的数据库关键参数是否正常，包括离线模式和只读配置等相关参数；
48.重启mgr，启动操作后将自动进行数据恢复，并将故障节点重新加入到数据库集群中；
49.执行探针启动操作，若日志正常且初始化成功，则表示故障修复成功。
50.有益效果：本发明适用于使用mysql数据库的应用，具有以下优点：
51.1.对应用完全透明，具有广泛应用基础。该数据库高可用方案，从应用程序编码、驱动程序、sql解析执行均保留了原生的mysql标准，对于应用系统完全透明。应用系统从其它高可用方案迁移使用本方案时，只需进行必要的规范化改造，即可投产使用。
52.2.完全基于分布式一致性协议，安全可靠。该方案基于mgr提供的分布式一致性协议进行设计，对于集群的事务验证、视图切换等影响数据库和集群结构的所有操作均通过一致性协商，超过半数成员投票同意后才进行的操作，同时探针是基于一致性切换结果而进一步执行的视图更新等操作。因此，其整个方案在任何情况下均是安全可靠的。
53.3.基于普通的基础设施，投产和成本可控。由于该方案整体不改变系统的整体架
构，因此将保持常见的应用服务 数据库的基本架构，不引入其它中间代理服务。同时，dns作为数据中心的基础资源，无论其采用商业的dns软件(如zdns)，还是基于开源的dns(如bind、bind-dlz)，均能满足本方案所需。同时，由于故障切换过程中，是探针根据数据库一致性切换结果向dns主动切换，可根据目标dns进行定制化设计(可以是api接口、远程命令以及sql请求)，无需对dns进行定制化改造，以控制成本和可控性。
54.4.架构简单，便于配置和维护。综上所述，本高可用方案是结合应用系统自身整体架构、dns、mgr及探针的特性进行设计，因此其架构简单。同时，探针介于接口化设计，不局限于任何语言，实际使用时可结合使用者熟悉的语言进行实现，以便于维护。
附图说明
55.图1是进行数据库集群的安装与上线配置的流程示意图；
56.图2是对探针进行初始化和对数据库集群进行探测的流程示意图；
57.图3是故障切换流程示意图；
58.图4是对故障进行修复的流程示意图；
59.图5是应用系统直接访问dns的架构图；
60.图6是应用系统访问dns缓存的架构图。
具体实施方式
61.下面结合附图和具体实施例，进一步阐明本发明，本实施例在以本发明技术方案为前提下进行实施，应理解这些实施例仅用于说明本发明而不用于限制本发明的范围。
62.如图1至4所示，本发明实施例提供了一种基于dns和mgr的mysql高可用实现方法，包括：
63.步骤1、进行数据库集群的安装与上线配置。具体的，参见图1，步骤1包括：
64.步骤1.1、进行资源申请与配置。
65.在系统上线过程中，由应用系统负责人通过已有的规范流程(如itsm)，申请服务器、域名等资源。提交申请并审批完成后，由相关责任团队对资源进行分配与配置。比如由系统管理部门分配数据库服务器并进行ip地址、安全策略、监控策略等模块的配置；网络管理部门根据分配的ip分配域名，并配置相关的视图和权限。
66.步骤1.2、进行数据库软件部署。
67.该步骤由数据库管理部门进行数据库软件的安装部署。包括操作系统依赖包安装、操作系统用户配置、操作系统内核参数优化、数据库目录创建、数据库软件安装以及修改目录权限等操作。
68.步骤1.3、进行参数配置优化。
69.具体的，根据服务器配置(如cpu内核个数、内存总大小)，计算相关数据库参数值。如设置innodb_thread_concurrency为服务器cpu个数、innodb_buffer_pool_size为服务器内存总大小的70％、slave_parallel_workers为服务器的内核个数、计算唯一的server-id。以及其它关键参数设置，详见表1：
[0070][0071][0072]
表1
[0073]
步骤1.4、进行数据库初始化并启动。
[0074]
使用已部署的数据库软件，结合优化的参数文件、目录配置，进行数据库的初始化操作。主要包括生成系统表空间、生成重做(redo)日志文件、生成双写(double write)缓存文件、创建撤销(undo)表空间、创建临时排序文件以及生成临时密码等操作。初始化完成后，执行命令启动数据库。
[0075]
步骤1.5、进行用户与权限配置。
[0076]
由于数据库初始化完成后，采用随机密码不便于统一管理，同时相关密码记录至数据库日志，存在安全风险。还需根据应用与运维需求建立相关用户，用户列表如表2所示：
[0077][0078]
表2
[0079]
另外需要注意的是，以上注明按照权限最小化原则的用户，应根据实际需求分配表或数据库的权限。特别是不能赋予connection_admin和super权限。
[0080]
步骤1.6、进行mgr插件与参数配置。
[0081]
配置数据库支持完整的mgr(mysql group replication)功能，需要安装group_replication和mysql_clone两个插件，group_replication用于实现mgr的核心功能，mysql_clone用于故障修复时进行全量数据同步。此外，需对mgr相关参数进行设置，规范设置如表3所示：
[0082][0083]
表3
[0084]
步骤1.7、启动mgr操作。
[0085]
完成mgr的插件和参数配置后，重启数据库实例以生效参数。重启完成后，设置使用group_replication_recovery通道，然后启动组复制即可。当数据库集群的第一个节点执行启动组复制时，应设置为引导模式，并在启动完成后，关闭引导模式，然后启动其它节点的组复制。
[0086]
步骤1.8、配置并启动各数据库节点探针，至此，完成该数据库节点的配置，并以此逐步完成所有数据库节点的配置。
[0087]
在进行配置并启动各数据库节点探针时，根据申请的域名地址、数据库集群配置，完善探针配置文件，执行探针启动操作，观察日志正常且初始化成功即可。
[0088]
步骤1.9、应用系统根据配置的数据库域名、用户名和密码等信息，连接数据库集群。
[0089]
另外需要注意的是，首先，对mgr配置修改需按照上述的规范配置进行，以确保故障发生后在期望的时间范围内完成切换操作。其次，应用程序数据库用户的权限应采用权限最小化原则进行按需分配，确保原主节点在被驱逐出集群后能中断已有数据库连接。
[0090]
步骤2、对探针进行初始化，然后进行对运行中的数据库集群进行探测。具体的，参
见图2，步骤2具体包括：
[0091]
步骤2.1、读取固定路径配置文件，确认配置文件格式是否非法、参数值是否合理。
[0092]
步骤2.2、解析得到数据库登陆信息、登陆数据库查询变量、集群结构和堆积情况。
[0093]
步骤2.3、校验所述集群结构与配置文件中的信息是否匹配，若配置信息的节点集合等于或包含数据库实时集群架构，则校验返回成功，否则返回失败。
[0094]
步骤2.4、根据域名执行执行ping操作，获取域名对应的ip地址。
[0095]
步骤2.5、对dns更新接口进行校验，然后打印初始化信息，并对初始化配置进行合理校验。
[0096]
步骤3、根据探测获得的数据库集群架构、事务堆积情况以及域名ip判断数据库集群运行是否正常，具体包括：
[0097]
若数据库集群主节点ip等于域名ip，且数据库集群节点等于配置节点，则表示集群运行正常。
[0098]
若数据库集群主节点ip等于域名ip，但数据库集群节点不等于配置节点，表示存在从节点运行异常，触发告警。
[0099]
若数据库集群主节点ip不等于域名ip，且本节点ip等于数据库集群主节点ip，触发故障切换流程。
[0100]
若数据库集群主节点ip不等于域名ip，且本节点ip不等于数据库集群主节点ip，触发告警。
[0101]
参见图3，上述故障切换流程具体包括：
[0102]
通过分布式一致性协议选择新主节点，原主节点数据库实例终止或进入离线模式，并调整探测间隔时间。在原主节点数据库实例终止或进入离线模式后，所有运行在原主节点的会话或连接均会中断。上述探针间隔时间优选调整为1秒。
[0103]
解析数据库运行状态，确认新主节点是否存在未应用完成的事务。
[0104]
堆积的事务应用完成后，若本节点为新主节点，则探针发起dns切换流程。
[0105]
在dns切换成功后，若dns存在缓存，执行dns缓存的刷新操作。
[0106]
进行域名ip、新主节点ip及ping结果的校验，校验成功即表示故障切换完成。
[0107]
恢复探针间隔为配置间隔时间，继续执行探测。
[0108]
上述dns切换流程包括更新前域名与ip的一致性校验、更新域名的ip、更新后域名与ip的一致性校验，对于商业dns设备使用其提供的api接口进行检查和更新，对于开源dns设备使用远程命令或sql请求的方式进行更新，最后校验成功即dns切换成功，否则表示发生异常，将退出。
[0109]
在故障切换流程完成后，还可以采用以下方式对故障进行修复，参见图4，具体包括：
[0110]
分析数据库集群发生故障切换的根本原因，根据分析结果确认是否需要对操作系统、数据库、探针等组件进行优化。
[0111]
检查操作系统运行状态、日志等数据，确认是否需要执行操作系统层面的修复操作，若因操作系统缺陷导致故障切换，则重启操作系统。
[0112]
检查数据库错误日志，确认是否需要执行数据库实例的修复操作，若数据库实例或进程触发故障切换，则重启数据库。
[0113]
确认故障节点的数据库关键参数是否正常，包括离线模式和只读配置相关参数。具体可参见表4：
[0114]
参数名称参数值offline_modeoffsuper_read_onlyonread_onlyon
[0115]
表4
[0116]
重启mgr，启动操作后将自动进行数据恢复，并将故障节点重现加入到数据库集群中。
[0117]
执行探针启动操作，若日志正常且初始化成功，则表示故障修复成功。
[0118]
参见图5和图6，本发明可以基于应用系统直接访问dns或访问dns缓存实现，在通过直接访问dns时，当故障发生后，mgr识别故障并进行切换；探针结合mgr切换结果，访问dns提供api发起域名的更新和校验；应用系统因为数据库集群的原主节点故障，重新连接时通过dns得到域名更新后的ip，以连接至数据库集群的新主节点。在通过访问dns缓存实现时，当故障发生后，mgr识别故障并进行切换；探针结合mgr切换结果，访问dns提供api发起域名的更新和校验，并将更新的信息实时刷新至缓存；应用系统因为数据库集群的原主节点故障，重新连接时通过dns缓存得到域名更新后的ip，以连接至数据库集群的新主节点。
[0119]
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，其它未具体描述的部分，属于现有技术或公知常识。在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。