设为首页 收藏本站
查看: 1026|回复: 0

[经验分享] Mysql高可用性keepalived+Mysql双主

[复制链接]

尚未签到

发表于 2018-10-10 07:09:31 | 显示全部楼层 |阅读模式
  一、搭建Mysql双主(互为主从)
  生产环境中一台mysql主机存在单点故障,所以我们要确保mysql的高可用性,即两台MySQL服务器如果其中有一台 MySQL 服务器挂掉后,另外一台能立马接替其进行工作。
  MySQL 的高可用方案一般有如下几种:
  keepalived+双主,MHA,PXC,MMM,Heartbeat+DRBD等,比较常用的是 keepalived+双主,MHA 和 PXC。
  本节主要介绍了利用keepalived 实现 MySQL 数据库 的高可用。
  Keepalived+mysql双主来实现MySQL-HA,我们必须保证两台MySQL数据库的数据完全一样,基本思路是两台 MySQL 互为主从关系(双主),通过 Keepalived 配置虚拟 IP,实现当其中的一台 MySQL 数据库宕机后,应用能够自动切换到另外一台 MySQL数据库,保证系统的高可用。
  拓扑环境
  OS:centos6.5 x86_64
  Mysql 版本:mysql 5.5.38
  Keepalived:keepalived-1.2.20
  Mysql-vip:192.168.1.100
  Mysql-master1:192.168.1.101
  Mysql-master2:192.168.1.102
  二、配置两台Mysql主从同步
DSC0000.png

  该过程的第一部分就是 master 记录二进制日志。在每个事务更新数据完成之前,master 在二日志记录这些改变。MySQL 将事务写入二进制日志。在事件写入二进制日志完成后,master通知存储引擎提交事务。
  下一步就是 slave 将 master 的binary log 拷贝到它自己的中继日志。首先,slave 开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接,然后开始binlog dump process。Binlog dump process 从 master 的二进制日志中读取事件,如果已经同步了 master,它会睡眠并等待 master 产生新的事件。I/O 线程将这些事件写入中继日志。
  SQL slave thread(SQL 从线程)处理该过程的最后一步。SQL 线程从中继日志读取事件,并重放其中的事件而更新 slave 的数据,使其与 master 中的数据一致。只要该线程与 I/O 线程保持一致,中继日志通常会位于 OS 的缓存中,所以中继日志的开销很小。
  主主同步就是两台机器互为主从的关系,在任何一台机器上写入都会同步。
  若 mysql 主机开启了防火墙,需要关闭防火墙或创建规则。
  1、修改 MySQL 配置文件
  两台 MySQL 均要开启 binlog 日志功能,开启方法:在 MySQL 配置文件[MySQLd]段中加上
  log-bin=MySQL-bin 选项,两台 MySQL 的server-ID 不能一样,默认情况下两台 MySQL 的
  serverID 都是 1,需将其中一台修改为 2 即可。
  master1 中有关复制的配置如下:
  log-bin =mysql-bin
  binlog_format =mixed
  server-id = 1
  relay-log =relay-bin
  relay-log-index =slave-relay-bin.index
  auto-increment-increment= 2
  auto-increment-offset= 1
  重启 mysqld 服务
  #service mysqldrestart
  master2 中有关复制的配置如下:
  log-bin =mysql-bin
  binlog_format =mixed
  server-id = 2
  relay-log =relay-bin
  relay-log-index =slave-relay-bin.index
  auto-increment-increment= 2
  auto-increment-offset= 2
  重启 mysqld 服务
  #service mysqldrestart
  注:master1 和 master2 只有 server-id 不同和 auto-increment-offset 不同。
  mysql 中有自增长字段,在做数据库的主主同步时需要设置自增长的两个相关配置:
  auto_increment_offset和auto_increment_increment。
  auto-increment-increment表示自增长字段每次递增的量,其默认值是 1。它的值应设为整个
  结构中服务器的总数,本案例用到两台服务器,所以值设为 2。
  auto-increment-offset是用来设定数据库中自动增长的起点(即初始值),因为这两能服务器都
  设定了一次自动增长值 2,所以它们的起点必须得不同,这样才能避免两台服务器数据同步
  时出现主键冲突,
  注:可以在 my.cnf文件中添加“binlog_do_db=数据库名”配置项(可以添加多个)来指定
  要同步的数据库
  2、将 master1 设为master2 的主服务器
  在 master1 主机上创建授权账户,允许在 master2(192.168.1.102)主机上连接
DSC0001.png

  查看 master1 的当前 binlog 状态信息
DSC0002.png

  在 master2 上将 master1 设为自已的主服务器并开启 slave 功能。
DSC0003.png

  查看从的状态,以下两个值必须为 yes,代表从服务器能正常连接主服务器
  Slave_IO_Running:Yes
  Slave_SQL_Running:Yes
DSC0004.png

  3、将 master2 设为master1 的主服务器
  在 master2 主机上创建授权账户,允许在 master1(192.168.1.101)主机上连接
DSC0005.png

  查看 master2 的当前 binlog 状态信息
DSC0006.png

  在 master1 上将 master2 设为自已的主服务器并开启 slave 功能。
DSC0007.png

  查看从的状态,以下两个值必须为 yes,代表从服务器能正常连接主服务器
  Slave_IO_Running:Yes
  Slave_SQL_Running:Yes
DSC0008.png

  4、测试主主同步
  在 master1 上创建要同步的数据库如 test_db,并在 test_db 中创建一张测试表如 tab1
DSC0009.png

  查看 master2 主机是否同步了 master1 上的数据变化
DSC00010.png

  从上图可以看出master2 同步了 master 的数据变化
  在 master2 主机上向 tab1 表中插入数据
DSC00011.png

  查看 master1 主机是否同步了 master2 上的数据变化
DSC00012.png

  现在任何一台 MySQL 上更新数据都会同步到另一台 MySQL,MySQL 同步完成。
  注:若主 MYSQL 服务器已经存在,只是后期才搭建从 MYSQL 服务器,在置配数据同步前应先将主 MYSQL 服务器的要同步的数据库拷贝到从 MYSQL 服务器上(如先在主 MYSQL 上备份数据库,再用备份在从 MYSQL 服务器上恢复)
  下面我们就完成keepalived 的高可用性。
  keepalived 是集群管理中保证集群高可用的一个软件解决方案,其功能类似于 heartbeat,用来防止单点故障keepalived 是以 VRRP 协议为实现基础的,VRRP 全称 Virtual Router Redundancy Protocol,即虚拟路由冗余协议 。
  虚拟路由冗余协议,可以认为是实现路由器高可用的协议,即将 N 台提供相同功能的路由器组成一个路由器组,这个组里面有一个 master 和多个 backup,master 上面有一个对外提供服务的 vip,master 会发组播(组播地址为 224.0.0.18),当 backup 收不到 vrrp 包时就认为 master 宕掉了,这时就需要根据 VRRP 的优先级 来 选举一个 backup 当 master。这样的话就可以保证路由器的高可用了。keepalived 主要有三个模块,分别是 core、check 和 vrrp。core 模块为 keepalived 的核心,负责主进程的启动、维护以及全局配置文件的加载和解析。check 负责健康检查,包括常见的各种检查方式(方式 1:tcp_check,工作第四层。方式 2:http_get,工作在第五层,向指定的URL 执行 http 请求,将得到的结果用 md5 加密并与指定的 md5 值比较看是否匹配,不匹配则从服务器池中移除。方式 3:ssl_get:与http_get 相似。方式 4:misc_check:用脚本来检测。方式 5:smtp_check:用来检测邮件服务的 smtp)。vrrp 模块是来实现VRRP 协议的。
  三、keepalived 的安装配置
  1、在 master1 和master2 上安装软件包 keepalived
  安装keepalived 软件包与服务控制
  在编译安装 Keepalived 之前,必须先安装内核开发包 kernel-devel 以及 openssl-devel、popt-devel 等支持库。
DSC00013.png

  若没有安装则通过 rpm或 yum 工具进行安装
  编译安装Keepalived
  使用指定的 linux 内核位置对 keepalived 进行配置,并将安装路径指定为根目录,这样就无需额外创建链接文件了,配置完成后,依次执行 make、make install 进行安装。
DSC00014.png

  注意:如不知道 keepalived 需要哪些依赖包,可到下载后的源码解压目录下查看 INSTALL 文件内容,安装需要的依赖包,源码安装任何一个软件都要养成查看源码包文档的习惯,比如INSTALL,README,doc 等文档,可以获得很多有用的信息
  注意:在 centos7.2 上安装 keepalived 不需要添加--with-kernel-dir
  [root@localhostkeepalived-1.2.20]# ./configure --prefix=/ && make && makeinstall
  使用keepalived 服务
  执行 makeinstall 操作之后,会自动生成/etc/init.d/keepalived 脚本文件,但还需要手动添加
  为系统服务,这样就可以使用 service、chkconfig 工具来对 keepalived 服务程序进行管理了。
DSC00015.png

  Master2 主机也完成keepalived 安装,与 master1 一样,安装过程略
  注:若开启了防火墙,需要关闭防火墙或创建规则。
  注:如果在 centos7.2 上安装 keepalived 防火墙的规则配置如下
  [root@localhost ~]# firewall-cmd --permanent--add-rich-rule="rule family=ipv4 destination
  address=224.0.0.18 protocol value=ip accept"
  success
  [root@localhost ~]# firewall-cmd --reload
  2、修改 Keepalived 的配置文件
  keepalived 只有一个配置文件 keepalived.conf,里面主要包括以下几个配置区域,分别是global_defs、vrrp_instance 和 virtual_server。
  global_defs:     主要是配置故障发生时的通知对象以及机器标识。
  vrrp_instance:   用来定义对外提供服务的 VIP 区域及其相关属性。
  virtual_server:虚拟服务器定义
  master1 主机上的 keepalived.conf 文件的修改:
  vi/etc/keepalived/keepalived.conf:
  ! ConfigurationFile for keepalived //!表示注释
  global_defs {
  router_id MYSQL-1//表示运行 keepalived 服务器的一个标识
  }
  vrrp_instance VI_1{
  state BACKUP      //指定keepalived的角色,两台配置此处均是BACKUP,设为BACKUP将根据
  优先级决定主或从
  interface eth0     //指定 HA 监测网络的接口
  virtual_router_id 51     //虚拟路由标识,这个标识是一个数字(取值在 0-255 之间,用来区分多个
  instance 的 VRRP 组播),同一个 vrrp 实例使用唯一的标识,
  确保和 master2 相同,同网内不同集群此项必须不同,否则发
  生冲突。
  priority 100      //用来选举 master 的,要成为 master,该项取值范围是 1-255(在此范围
  之外会被识别成默认值 100),此处 master2 上设置为 50
  advert_int 1    //发 VRRP 包的时间间隔,即多久进行一次 master 选举(可以认为是健康查
  检时间间隔)
  nopreempt      //不抢占,即允许一个 priority 比较低的节点作为 master,即使有 priority 更高
  的节点启动
  authentication {   //认证区域,认证类型有PASS 和 HA(IPSEC),推荐使用 PASS(密码
  只识别前 8 位)
  auth_type PASS
  auth_pass 1111
  }
  virtual_ipaddress{        //VIP 区域,指定 vip 地址
  192.168.1.100
  }
  }
  virtual_server192.168.1.100 3306 {      //设置虚拟服务器,需要指定虚拟 IP 地址和服务端口,
  IP 与端口之间用空格隔开
  delay_loop 2                        //设置运行情况检查时间,单位是秒
  lb_algo rr                          //设置后端调度算法,这里设置为 rr,即轮询算法
  lb_kind DR                       //设置 LVS 实现负载均衡的机制,有 NAT、TUN、DR 三个模式选
  persistence_timeout 60           //会话保持时间,单位是秒。这个选项对动态网页是非常有用的,为集群系统中的 session 共享提供了一个很好的解决方案。有了这个会话保持功能,用户的请求会被一直分发到某个服务节点,直到超过这个会话的保持时间。
  protocol TCP            //指定转发协议类型,有 TCP 和 UDP 两种
  real_server 192.168.1.101 3306{          //配置服务节点 1,需要指定real server 的真实 IP 地址和端口,IP 与端口之间用空格隔开
  注:master2 上此处改为 192.168.1.102(即 master2 本机 ip)
  weight 3                  //配置服务节点的权值,权值大小用数字表示,数字越大,权值越高,设置权值大小为了区分不同性能的服务器
  notify_down/etc/keepalived/bin/mysql.sh     //检测到 realserver 的 mysql 服务 down 后执行的脚本
  TCP_CHECK {
  connect_timeout 3          //连接超时时间
  nb_get_retry 3              //重连次数
  delay_before_retry3        //重连间隔时间
  connect_port 3306          //健康检查端口
  }
  }
  }
  master1 主机上有关 keepalived.conf 文件的具体配置如下:
DSC00016.png

DSC00017.png

  启动keepalived 服务
  #/etc/init.d/keepalivedstart
  Master2 主机上的 keepalived.conf 文件的修改:
  Master2 主机的 keepalived.conf 文件配置与 master1 基本相同,只是 router_id,priority,real_server 三处不同,其他配置都相同
  可以使用 scp 命令把 server1 主机上配置好的 keepalived.conf 文件拷贝到 server2 主机,
  只要做简单修改即可,如下图所示:
DSC00018.png

DSC00019.png

  启动keepalived 服务
  #/etc/init.d/keepalivedstart
  3、master1 和master2 上都添加此检测脚本,作用是当 mysql 停止工作时自动关闭本机的
  keepalived,从而实现将故障机器踢出(因每台机器上keepalived 只添加了本机为 realserver).
  当 mysqld 正常启动起来后,要手动启动 keepalived 服务。
  #mkdir/etc/keepalived/bin
  vi/etc/keepalived/bin/mysql.sh,内容如下:
DSC00020.png

DSC00021.png

  Master2 主机完成相同的操作
  4、测试
  在 master1 和 master2 分别执行 ipaddr show dev eth0 命令查看 master1 和 master2 对VIP
  (群集虚拟 IP)的控制权。
  Master1 主的查看结果:
DSC00022.png

  Master2 主的查看结果:
DSC00023.png

  从上图可以看出master1 是主服务器,master2 为备用服务器。
  停止 MySQL 服务,看 keepalived 健康检查程序是否会触发我们编写的脚本
  停止 master1 主机的 mysql 服务
DSC00024.png

  Master2 主的查看结果:
DSC00025.png

  这说明在主服务上停止MySQL 服务,触发了我们编写的脚本,进行自动故障切换。
  MySQL 远程登录测试
  我们找一台安装有MySQL 客户端,然后登录 VIP,看是否能登录,在登录之两台 MySQL 服
  务器都要授权允许从远程登录。例如:
DSC00026.png

  在客户端上测试登录
DSC00027.png

  上图显示说明在客户端访问 VIP 地址,由 master1 主机提供响应的,因为 master1 当前是主服务器,将 master1 的 mysql 服务停止,在客户端执行 show variableslike‘server_id’;
DSC00028.png

  上图显示说明在客户端的查询请求是由 master2 主机响应的。故障切换成功。
  总结:
  Keepalived+mysql 双主一般来说,中小型规模的时候,采用这种架构是最省事的。在 master 节点发生故障后,利用 keepalived 的高可用机制实现快速切换到备用节点。
  在这个方案里,有几个需要注意的地方:
  1.采用 keepalived 作为高可用方案时,两个节点最好都设置成 BACKUP模式,避免因为意外情况下(比如 脑裂)相互抢占导致往两个节点写入相同数据而引发冲突;
  2.把两个节点的 auto_increment_increment(自增步长)和 auto_increment_offset(自增起始值)设成不同值。其目的是为了避免master 节点意外宕机时,可能会有部分 binlog 未能及时复制到slave上被应用,从而会导致slave新写入数据的自增值和原先master上冲突了,因此一开始就使其错开;当然了,如果有合适的容错机制能解决主从自增ID 冲突的话,也可以不这么做;
  3.slave 节点服务器配置不要太差,否则更容易导致复制延迟。作为热备节点的 slave服务器,硬件配置不能低于 master 节点;
  4.如果对延迟问题很敏感的话,可考虑使用 MariaDB 分支版本,或者直接上线 MySQL 5.7 最新版本,利用多线程复制的方式可以很大程度降低复制延迟。
  ===============================================================================
  
  
  通过理论和实践的结合能更好的提升,欢迎转载,学习!


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-619690-1-1.html 上篇帖子: mysql 主从同步 下篇帖子: centos7-mysql-cnf配置文件优化
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表