corosync 实现 MariaDB 数据库服务的高可用

方案：

    corosync + pacemaker  提供HA的解决方案。

    使用NFS共享服务器导出的共享文件系统做为数据目录；

拓扑图如下：

一、配置HA高可用集群的各节点间能够基于主机名通讯。

1、设置主机名

(1)、在 192.168.60.128 主机设置

编辑/etc/sysconfig/network文件，使得主机名永久有效

使用hostname命令设置主机名，让它即时生效

(2)、在 192.168.60.22 主机设置

编辑/etc/sysconfig/network文件，使得主机名永久有效

使用hostname命令设置主机名，让它即时生成

2、为了，操作方便设置节点之间能够基于密钥通讯。也就是所谓的建立信任主机。

3、节点之间基于主机名通讯，要能够解析主机名才可以。解析主机名有两种方式：

(1)、使用DNS地址解析服务器；

(2)、使用本地hosts文件解析

基于效率和安全方面考虑，这里使用hosts文件解析主机名。

把/etc/hosts文件复制到node2节点

4、测试两个节点能够实现基于密钥的方式进行通讯和能否基于主机名进行通讯

说明：

   从上述可以看出，两个节点已经能够实现基于主机名的方式进行通讯。

二、配置NFS服务器

1、提供NFS服务器共享的文件系统

使用LVM逻辑卷做为数据库的数据目录，为了使用逻辑卷的快照功能备份数据。

(1)、创建分区

(2)、把该分区做成pv 

(3)、创建逻辑卷组myvg,PE大小为8E.

(4)、创建lvm,大小为：2G

(5)、创建挂载点

(6)、编辑/etc/fstab文件，实现开机可以自动挂载“/dev/myvg/sharedir”

(7)、挂载

查看是否挂载

2、配置挂载NFS服务器共享的文件系统的客户端中的数据库服务进程(mysql)具有共享文件系统(目录)的读写权限。

     把NFS服务器导出的文件系统中，作为数据库的数据目录，根据NFS服务器的工作原理，NFS的客户端可以往NFS服务器导出的文件系统(目录)写数据要满足两个条件：

     (A)、在NFS服务器级别，做访问控制时候是否授写NFS客户端写(w)的权限；

     (B)、在NFS客户端发起写(W)操作的进程的属主对应的UID，在NFS服务器端所在的主机是否该UID

          对应的用户。

     1)、如果有的话，那么就检查该用户是否有NFS服务器导出的文件系统(目录)的写权限。如果有

         写权限的话，那么NFS客户端的进程就可以往NFS服务器导出的文件系统发起写操作了。否则

         的话NFS客户端是无权限往NFS服务器导出的文件系统写数据的。

     2)、如果没有的话，那就就检查nobody用户是否有NFS服务器导出的文件系统(目录)的写权限。

         不过在Linux系统上，nobody用户的权限是最小。

     因为，在MySQL数据库中，接收客户端SQL操作请求的进程的属主是：mysql. 所以，我们要配置该用户的UID号在NFS服务器所在的主机上有对应的用户名，且要求该用户有NFS服务器导出的文件系统(目录)，有读写权限。对HA高可用节点和NFS服务器，三台主机添加下述用户：

规划在三台主机都使用系统用户，且UID都为：404；GID都为：404.

(1)、在三台主机设置用户

(A)、在node1 主机创建mysql用户

(B)、在node2 主机创建mysql用户

(C)、在NFS服务器也创建UID、GID都为：404的用户；

(2)、授权

(A)、在文件系统级别授权；使用控制列表方式，授权UID为：404的用户usenfs有NFS服务器导出的文件系统的读写权限。

(B)、设置NFS服务器导出的文件系统，在NFS级别做访问控制。

启动NFS服务器

(3)、查看NFS服务器导出的文件系统

(4)、创建MariDB数据库的数据目录

使用控制列表方式授与 usefs 用户有该目录的读写执行权限。

三、分别在两个节点安装数据库软件：

    两个节点使用的数据库软件的版本要求是一致的。因为，两个节点的数据库软件使用的是同一份数据集。由于不同版本的数据库，它的元数据有差异。会造成无法启动数据库服务的。

这里两个节点都使用二进制版本的MariaDB数据库软件。

1、在 node1(192.168.60.22)安装数据库软件

(1)、在node1挂载并测试NFS服务器导出的文件系统

查看NFS服务器导出的文件系统

创建挂载点

挂载NFS寻出的文件系统

(2)、安装： MariaDB 数据库

使用的是二进制包安装数据包的方式。

(A)、初始化数据前的准备工作

解压到指定目录下

为了以后维护方便不直接修改目录名称，使用软连接的方式

由于初始化数据库的时候，要以mysql用户的身份运行一些脚本来完成数据库的初始化工作。所以。修改数据库的程序文件的属主为mysql

(B)、初始化数据库，指定数据目录的位置和初始化数据库使用的用户

说明：

    从上述可以看出，初始化数据库已经OK！

(3)、为启动 MariaDB 数据库做准备

提供数据库提供配置文件

由于，修改了数据库的数据目录，所以要在配置文件中指定数据库的数据目录

提供LSB风格的启动脚本，管理 MariaDB 的启动、停止、重启、重新加裁配置文件等操作

为了安全考虑把数据库的程序目录的属主修改为：root

(4)、启动MariaDB数据库并测试

启动 MariaDB 数据库

连接测试数据库

测试在该节点是否能够创建数据库和删除数据库，来检测mysql用户是否有NFS共享文件系统的读写权限的。

创建数据库

删除数据库

说明：

    在node1节点数据库已经安装成功！

(5)、配置成HA高可用服务的资源不能让它开机自动启动

停止node1节点的数据库服务

卸载nfs文件系统

由于是提供数据库的高可用的，是不允许开机自动启用数据库服务的。保证开机不会自动启用高可用服务

2、在node2(192.168.60.128)节点安装数据库

(1)、在node1挂载并测试NFS服务器导出的文件系统

创建挂载点

查看NFS服务器导出的共享文件系统

挂载NFS服务器导出的共享文件系统

查看是否挂载成功

(2)、安装： MariaDB 数据库

解压到指定目录下

为了日后操作维护方便，不直接修改目标名称，给该目录创建一个软链接

由于在node1节点已经初始化过数据库了，该节点无需再次初始化数据库了。

修改数据库程序的属主属组为：root:mysql

(3)、为启动服务库服务准备条件； 

为了保证两个节点的数据库的配置一样，从node1节点分别拷贝：配置文件和启动脚本 到node2节点

(4)、启动 MariDB 数据库并测试

启动数据库服务

连接数据库

说明：

   可以连接数据库

测试在该节点是否能够创建数据库和删除数据库，来检测mysql用户是否有NFS共享文件系统的读写权限的。

创建数据库

删除数据库

说明：

    从上述操作及结果可以得出结论。在node2节点可以正常操作数据库。

(5)、做数据库服务做一些初始化工作；

由于安装数据库的时候会默认添加了一些用户且是没有密码，按照实际情况删除不需要的用户

给保留的用户设置密码，为了管理数据库方便是，设置远程管理数据库的用户。

删除数据库一些默认添加的的用户

给保留的用户添加密码

添加能够远程管理数据库的用户

修改后的 MariaDB数据库的用户如下：

刷新授权表

(6)、配置成HA高可用服务的资源不能让它开机自动启动

停止数据库服务

卸载挂载的NFS文件系统

设置不能开机启动数据库服务

四、配置 corosync 提供数据库服务的高可用；

1、提供HA高可用集群的节点通信的密钥；

   节点间的心跳信息和集群事务信息要加密传输的，不允许主机随便加入HA高可用集群的。

使用corosync提供的命令【corosync-keygen】生成该HA高可用集群的认证密钥。持有该解密的节点才属于该HA高可用集群的成员。

在node1节点生成密钥，生成的密钥是默认保存在/etc/corosync目录中的

生成密钥

为corosync提供配置文件

2、提供配置文件

配置文件设置如下：

复制配置文件和密钥文件到node2节点，保证HA高可用节点的配置是一样的。

3、启动node1节的 corosync 服务

(1)、在node1节点启动corosync服务

(2)、检测在该节点启动的corosync是否正常

由于HA高可用集群的核心层是：

corosync 自己实现 Message Layer 层的功能，使用 pacemaker 做为HA的资源管理器(corosync 2.0 版本以前，是做为corosync的一个模块工作的)，

从而提供一个完成的HA高可用解决方案。为了保证 corosync 能够正常工作，通过日志查看HA的核心层的工作状况。

(A)、查看 Message Layer 层的运行状况

查看corosync引擎是否正常启动

查看初始化成员节点通知是否正常发出：

(B)、查看 Manager Resource Manager 资源管理层的工作状况 

查看资源管理器pacemaker是否正常启动：

(C)、检查启动过程中是否有错误产生

说明： 

   在 corosync 2.0版本，packmaker是作为 corosync 的插件运行的。

   上述的错误信息表示packmaker不久之后将不再作为corosync的插件运行，因此，建议使用cman作为集群基础架构服务；此处可安全忽略。

  从查看corosync的日志可以得知，node2节点的corosync已经运行正常。   

4、启动node2节的 corosync 服务

node1 节点的 corosync 运行正常了，就可以启动 node2 节点的 corosyn 服务器。

(1)、通过远程方式启动corosync服务

(2)、同样，也像查看 node1 节点那样，查看 node2 节点的 corosync 的运行状况：

(A)、查看 Message Layer 的运行状况

查看corosync引擎是否正常启动

查看初始化成员节点通知是否正常发出

(B)、查看 Cluser Resource Manager 层的工作状况

查看资源管理器pacemaker是否正常启动

(C)、查看 corosync 启动过程中是否有错误信息。

说明:

    上述的错误信息可以忽略。

 从上述的日志分析，corosync 服务已经运行正常。

 到此为止，两个节点的 corosync 服务都运行OK！！！

五、配置HA高可用集群的资源：

1、分析提供高可用数据库服务需要哪些资源？

2、由上述的3个资源一起才能够提供数据库服务，所以在HA高可用集群服务中，要对资源做一些约束。

   (1)、保证无论何时，这三个资源都始终运行在同一个HA节点

        解决方案：

   (2)、提供数据库服务必须的3资源，要有启动的先后顺序。

        原因1、由于使用NFS共享文件系统做为数据库的数据目录，挂载nfs共享文件系统成功之后才可以启用数据库服务进程。

原因2、即使数据库服务启动成功，没有IP地址。启动成功数据库服务也没有用。

所以，在配置资源时，要对资源的启动顺序做一些限制。方案：

使用资源约束中的顺序约束：order 

   (3)、考滤HA节点的硬件资源能力和备用节点运行资源时是否压力过大

        可以使用位置约束location： 资源对某节点运行的倾向性(负无穷--正无穷)

注意：资源的流转必然会导致服务暂时的中断。

3、使用pacemaker 提供的资源代理来管理提供数据库服务的三个资源的：启动、关闭、监控，从而实现数据库服务的高可用。

         

说明：

   这里使用crm 文本接口配置HA高可用的集群

4、查看启动的HA集群的各项信息

(1)、查看集群状态

(2)、查看,pacemaker提供资源管理层(Cluster Resources Manager)的各个组件：

5、配置资源

一般HA高可用集群的节点不止两个。当某个节点故障了，该节点的资源就需要在运行正常的节点启动，是在每个正常的节点都启动呢，还是在其中的某个节点启动呢？

这是通过资源的类型来定义的。所以在配置HA高可用集群资源时，要指定资源的类型的。那么HA高可用集群的资源类型有那些？

(1)、由于提供的两个节点的HA高可用集群，只要有一个节点故障集群都不能满足法定票数，该HA集群就不能工作了。所以，要设置当法定票数不满足时，集群还可以正常工作。如果不提供stonith，是不允许启动corosync 的。所以，还需要关闭stonith

(A)、设置HA高可用集群不满足法定票数时的策略

(B)、关闭stonith

(2)、添加资源

(A)、配置流动IP资源

说明：

   primitive 指定该资源为主资源

   使用的资源代理(Resource Agent)为：IPaddr

(B)、配置挂载nfs共享文件系统的资源

(C)、配置启动数据库服务的进程资源

(3)、设置资源的约束

(A)、使用排列约束(colocation)，限定提供数据库服务的三个资源一定必须运行在同一个节点

(B)、使用顺序约束(order),指定提供数据库服务的三个资源的先后启动顺序(关闭资源的顺序是一个相反的过程，所以不会造成卸载NFS文件系统再关闭数据库服务的情况)

(C)、使用位置约束(location),限定资源倾向于运行在那个节点。

(4)、配置好后的处理

(A)、检验配置是否有错误

(B)、没有错误就提交

(C)、查看提供数据库高可用集群的运行状态

说明：

    从上述信息得出结论，提供数据库服务的HA高可用集群已经配置成功。

六、测试提供数据库服务的HA高可用集群是否成功？

测试节点的高可用，可以理解为是否能够提供节点的冗余

1、检查资源

(1)、流动IP

(2)、是否挂载nfs共享文件系统

(3)、查看mysqld进程

2、远程连接测试

说明：

    数据库服务工作正常。

3、模拟节点故障测试服务是否可以转移

(1)、让 node1 下线

(2)、查看HA高可用集群的运行状况

说明：

    三个资源立即转移到node2.9527du.com 节点

 (3)、查看 node2的资源情况

说明：

    提供数据库服务的3个资源在node2节点都工作正常。

4、访问mysql并删除testdb数据库

(1)、远程连接数据库

(2)、执行删除数据库操作

说明：

   在node2也可以操作数据库。资源转移到node2节点，一样可以操作数据库。

5、让 node1上线，再测试

(1)、让node1节点上线

(2)、查看HA高可用集群的运行状况

说明：

   从上述可以看出资源立即流转回node1节点。因为定义了位置约束。

   提供数据库服务的HA高可用集群是正常工作的。

测试服务的高可用，意思是说，停止某个资源后，corosync的资源代理监控该该资源故障了，通告资源管理器。资源管理器理是否会指挥资源代理重新启动该资源。

1、停止 mysqld 进程

2、查看自动启动服务

再查看

说明：

   20:36:03 关闭mysqld 进程

   20:36:17 mysql数据库又重新提供服务了。

   资源的高可用已经实现。

数据库服务的高可用已经OK。。。。