MySQL 高可用架构实战

最新推荐文章于 2024-07-17 14:18:17 发布
最新推荐文章于 2024-07-17 14:18:17 发布
阅读量982 收藏 2
点赞数
文章标签： 数据库 mysql 搭建 Replication Semisynchronous
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/crasheye/article/details/51479121
版权

基于 MySQL5.7, Semisynchronous Replication(MySQL 半同步复制), Keepalived, MHA 的 MySQL 高可用方案

MySQL, 用得最多最广泛的关系型数据库。 在生产环境中，难免遇到诸如 需要重启服务器或者 MySQL 服务莫名宕了 等问题。如何保证 MySQL 能够持续提供读写等服务，即 高可用性？

本文主要讲述如何从无到有构建一套简单的 MySQL 高可用方案，少概念原理，多实操。

概念及架构简介

  • semi-synchronous Replication: 传统的 asynchronous 模式在 master 宕机时仍然有数据丢失的风险。MySQL5.5 之后提供了 semi-synchronous 模式，它会在 master 处理完一个事务并且等待至少一个支持 semi-synchronous 的 slave 确认收到该事件并将其写 入relay-log 之后才会返回。相较于前者，数据安全性更高。性能也无需担心，因为 facebook 也用了。
  • Keepalived: 基于 VRRP 实现的路由管理工具，在 负载均衡 和 高可用 场景中应用广泛。这里主要用来创建 VIP(虚拟路由)
  • MHA: 即 mysql-master-ha, 最主要的一个功能是监控 MySQL 主从集群( 确切地说主要监控 Master), 在 Master 出现故障后自动选择一个 Slave 提升为 Master，并且可以保证新 Master 和 Slave 的一致性。

来看一下 架构图

应用通过 VIP(虚拟路由，由 Keepalived 创建)访问 MySQL 集群。一主(图 M )二从(图 S1 和 S2)，S2 作备用主库。一旦原 Master 节点出现故障，MHA 自动将主库切换到 S1，并且 S2 随之连接到新的 Master。MHA 同时通过 master_ip_failover_script 脚本停止原 Master 节点上的 Keepalived，路由自动切换到 新 Master。这时候外部应用实际访问的是 S1 了，不会出现 MySQL 突然无法使用的问题。


机器规划

Host IP VIP Role Software
M 10.20.78.241 10.20.78.11 Master MySQL5.7 Keepalived MHA-Node
S1 10.20.78.243 备用 candidate_master (Slave) MySQL5.7 Keepalived MHA-Node
S2 10.20.78.245 - Slave MySQL5.7 MHA-Node
MHA-Manager 10.20.78.227 - MHA Manager MHA-Node MHA-Manger

M 出现故障后：

Host IP VIP Role
M 10.20.78.241 - stoped
S1 10.20.78.243 10.20.78.11 master
S2 10.20.78.245 - Slave
MHA-Manager 10.20.78.227 - MHA Manager(stoped)

集群的搭建

整个集群搭建安装分为 MySQL 半同步复制、MHA 和 VIP(Keepalived) 三大部分。几乎都是以命令的方式来展示。

在安装具体的软件之前，对所有机器 yum -y upgrade (这是一个很好的习惯)。

所有服务器上 安装 EPEL( MHA 依赖包需要)

wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
rpm -Uvh epel-release-latest-6.noarch.rpm

下面开始分别从 MySQL 的半同步复制、Keepalived(VIP) 和 MHA 三方面具体说明。

Semisynchronous Replication

MySQL 在 5.5 以上的版本支持 半同步 复制，并且需要已经配置好 主从复制。

安装 MySQL 5.7
// 安装
wget http://dev.mysql.com/get/mysql57-community-release-el6-7.noarch.rpm
yum localinstall mysql57-community-release-el6-7.noarch.rpm

// 检查是否安装成功
service mysqld start
service mysqld status
mysql --version

// 初始的安全配置
grep 'temporary password' /var/log/mysqld.log
mysql_secure_installation //根据提示操作, 包括设置 root 新密码等操作

// 开始使用
mysql -uroot -p
配置 MySQL 主从同步

Master 机器上的操作：

  • 修改 my.cnf

    [mysqld]
    server-id=1     ## 在整个 MySQL 集群中必须唯一
    log-bin=mysql-bin
    binlog_format=ROW

  • 重启服务：service mysqld restart

  • 创建 slave 同步需要的用户: mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl_username'@'10.20.%.%' IDENTIFIED BY 'repl_password';

  • 查看 master 状态：mysql> show master status\G

Slave 机器上的操作：

  • 修改 my.cnf：

    [mysqld]
    server-id=2         // S2节点 上为 3，保证唯一
    relay_log=relay-log
    skip-slave-start

  • 重启 mysql: service mysqld restart

  • 配置 Master 信息： 
    mysql> CHANGE MASTER TO MASTER_HOST='10.20.78.241',MASTER_PORT=3306,MASTER_USER='mha',MASTER_PASSWORD='King@123',MASTER_LOG_FILE='mysql-bin.000009',MASTER_LOG_POS=496;

  • 启动 slave 并 查看状态

    mysql> START SLAVE

    mysql> SHOW SLAVE STATUS\G

主从同步配置完成，检查状态

  • 回到 Master 机器，查看 slave 连接情况：mysql> show slave hosts;
  • Master 上创建数据库 mysql> CREATE DATABASE sync_test;，在两个 Slave 上查看，发现同步成功。
半同步

  • Master

    // 动态加载插件
    mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

    mysql> SET GLOBAL rpl_semi_sync_master_enabled = {0|1}; // 1 开启
    mysql> SET GLOBAL rpl_semi_sync_master_timeout = N; // 单位是 ms

  • Slave

    // 动态加载插件
    mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

    mysql> SET GLOBAL rpl_semi_sync_slave_enabled = {0|1}; / 1 开启

    mysql> STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;

  • 半同步状态监控

    可以分别在 Master 和 Slave 上查看
    查看配置：`SHOW VARIABLES LIKE 'rpl_semi_sync%';`
    查看状态：`SHOW STATUS LIKE 'Rpl_semi_sync%';`

Keepalived

需要在 M 和 S1 两台服务器上安装配置

  • 安装和编辑

    wget http://www.keepalived.org/software/keepalived-1.2.20.tar.gz
    tar -zxvf keepalived-1.2.20.tar.gz 
    cd keepalived-1.2.20
     ./configure --prefix=/usr/local/keepalived
    make && make install
    cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/keepalived
    cp /usr/local/keepalived/sbin/keepalived /usr/sbin/
    cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
    mkdir -p /etc/keepalived/
    cp /usr/local/etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf
    vim /etc/keepalived/keepalived.conf

  • 启动 keeplived： service keepalived start

  • 查看虚拟 IP: ip a，此时可以看到在 M 上虚拟 IP 挂载成功，S1 上没有该 IP。一旦 M 上的 keeplived 服务挂掉，虚拟 IP 自动挂载到 S1 上。

  • 给 MySQl 可操作 Keepalived 启停的权限

    通过 visudo 命令，在 /etc/sudoers 文件末尾添加如下几行：

        Host_Alias HOSTKEEP =110.20.78.241 # 本机IP
        Cmnd_Alias COMKEEP = /etc/init.d/keepalived stop, /etc/init.d/keepalived start, /etc/init.d/keepalived restart, /etc/init.d/keepalived reload ## reload is used to check connection error
        User_Alias USERKEEP = mysql
        USERKEEP  HOSTKEEP=(ALL)  NOPASSWD:COMKEEP

        #Defaults   requiretty # 注释掉

MHA

MHA 由 Node 和 Manager 两部分组成，Node 安装在每一台 MySQL 服务器上，而 MHA-Manager 需要同时安装 Node 和 Manager.

各节点间的SSH 公钥免密码登陆

MHA Manager 使用 SSH 连接到各个 MySQL 服务器，最新 Slave 节点上的MHA Node 也要用 SSH (scp) 把 relay log 文件发给各个从库节点

  • 创建 RSA Keys(详情)

    mkdir ~/.ssh
    chmod 700 ~/.ssh
    ssh-keygen -t rsa

  • 在四台服务器上进行 ssh 配置

    ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.20.78.241
    ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.20.78.243
    ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.20.78.245
    ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.20.78.227
MHA 安装
三台 MySQL 服务器上安装 MHA-Node
yum install perl-DBD-MySQL -y
rpm -Uvh https://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.52-0.noarch.rpm
MHA-Manager 结点

  • MHA-Manager 的安装和配置

    yum install -y perl-DBD-MySQL, perl-Config-Tiny, perl-Log-Dispatc,perl-Parallel-ForkManager
    rpm -Uvh https://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.52-0.noarch.rpm
    rpm -Uvh https://mysql-master-ha.googlecode.com/files/mha4mysql-manager-0.52-0.noarch.rpm

  • 配置 /etc/mha/mha.conf 文件

    [server default]
    user=repl_username
    password=repl_password
    ssh_user=root
    remote_workdir=/usr/local/mha
    repl_user=repl_username
    repl_password=repl_password
    master_ip_failover_script=/usr/local/mha/master_ip_failover

    [server1]
    hostname=10.20.78.241

    [server2]
    hostname=10.20.78.243
    candidate_master=1

    [server3]
    hostname=10.20.78.245
    no_master=1

  • 编辑 master_ip_failover 脚本：/usr/local/mha/master_ip_failover

    主要作用是 kill 原 Master 服务器上的 Keeplived，核心代码如下

    my $vip = '10.20.78.11';
    my $ssh_start_vip = "/etc/init.d/keepalived start";
    my $ssh_stop_vip = "/etc/init.d/keepalived stop";

  • 检查节点间的 ssh 连接: masterha_check_ssh --conf=/etc/mha/mha.conf

    成功会在终端输出 「All SSH connection tests passed successfully」

  • 检查MySQL 主从同步： masterha_check_repl --conf=/etc/mha/mha.conf

    成功会在终端输出 MySQL Replication Health is OK.

  • 启动 MHA Manager: masterha_manager --conf=/etc/mha/mha.conf

  • 查看 MHA 状态 masterha_check_status --conf=/etc/mha/mha.conf

    正常显 「PING_OK」，否则显示 「NOT_RUNNING」

全部配置完毕!


本文作者：波波老师

crasheye
关注
MySQL——Keepalived+Mysql高可用架构实战
庄小焱
01-09 4649
在生产环境中mysql的高可用的对于整个项目而言有着至关重要的作用。因此需要将mysql设计成为高可用的架构。本博文将详细介绍的mysql+keepalived构建的mysql互为主从的架构实战。
MySQL实战宝典 高可用架构篇 17 高可用设计三大高可用设计架构方案
javalingyu的博客
05-09 519
前面学习了MySQL数据库的复制、优化，以及基于复制技术实现业务层的读写分离方案，这些内容是为了铺垫MySQL数据库的高可用架构设计。因为复制是高可用的基础，但只用复制同步数据远远不够，还要结合自己的业务进行高可用设计。 同时，高可用也不仅仅是数据库的事，你要从业务的全流程出发，思考怎么设计一个真正健壮的高可用架构。 高可用概念（High Availability） 首先，我们来看一下wiki上对高可用的定义： High availability (HA) is a characteristic
mysql高可用实战
06-01
mysql高可用的部署方案， galera 集群以及 pxc方案的部署文档。
mysql高可用架构
08-22 130
高可用 高可用(High Availabiltity) 应用提供持续不间断(可用)的服务的能力 系统高可用性的评价通常用可用率表示 造成不可用的原因 硬件故障(各种) 预期中的系统软硬件维护 软件缺陷(应用代码，服务程序都可能存在bug) 攻击，泄露，认为失误...等安全事件 对于系统来说，不可用时间是各关键组件不可用时间的总和...
老生常谈：MySQL高可用架构
最新发布
2401_85377090的博客
07-17 871
MySQL高可用========MySQL的高可用也是同样的思路，首先要有多个MySQL实例提供服务，其次就是当某个实例挂掉时，可以自动切换流量。同时MySQL作为存储，节点之间数据同步也是一个难题（换句话说，有状态的服务都面临这个问题）。一主一备：=====MySQL的各种高可用架构，都脱离不了MySQL实例之间的数据同步，因此，我们先介绍下最简单的一主一备架构下MySQL的数据同步流程。上图是主从数据同步的一个示意图。
​老生常谈：MySQL高可用架构
m0_64374605的博客
12-15 5144
引言 “高可用”是互联网一个永恒的话题，先避开MySQL不谈，为了保证各种服务的高可用有几种常用的解决方案。 服务冗余：把服务部署多份，当某个节点不可用时，切换到其他节点。服务冗余对于无状态的服务是相对容易的。 服务备份：有些服务是无法同时存在多个运行时的，比如说：Nginx的反向代理，一些集群的leader节点。这时可以存在一个备份服务，处于随时待命状态。 自动切换：服务冗余之后，当某个节点不可用时，要做到快速切换。 总结起来就是冗余+故障转移。 MySQL高可用 MySQL的高可用也是同..
MySQL高可用架构
bin的专栏
09-18 1373
MySQL学习笔记一，高可用架构对于一个企业来讲，设计一个高可用的架构非常重要，包括前端的高可用和后端数据库的高可用。企业业务每暂停一分钟，可能会造成大量的金钱流失，因此只有在整个架构的设计上足够的高可用，才可以保证应用程序对外提供不间断的服务，进而把因软件/硬件/人为造成的故障对业务的影响降低到最小程度，把损失降低到最低。MySQL数据库高可用方面的两个主流架构：MMM和MHA。二，MMM架构MM
打造不间断服务的堡垒：MySQL高可用架构实战
[打造不间断服务的堡垒：MySQL高可用架构实战](https://img-blog.csdnimg.cn/img_convert/746f4c4b43b92173daf244c08af4785c.png) # 1. MySQL高可用性概述 MySQL高可用性是指MySQL数据库系统能够在发生故障或中断时...
PostgresSQLHA高可用架构实战
03-03
中国移动主动使用PostgreSQL实现分布式数据库架构。金融业方面平安集团明确表示将使用PostgreSQL作为新一代数据库的选型。华为中兴纷纷加入PostgreSQL内核研究队伍。阿里云正式提供PostgreSQL服务。大部分人了解...
Mysql高可用架构
qq_49662572的博客
08-21 888
目录 架构选择 市面上有非常厉害牛逼的数据高可用框架，但是对于绝大多数中小型公司来说成本过高，我们选择一个架构时不是它牛逼，厉害就去选择，要考虑实际情况，也要考虑我们项目业务具体的情况，我们项目并发最高不到1W我们难道要去做到10W并发？这明显是过度开发，造成资源和时间的浪费，不仅对Mysql高可用架构是如此，其他中间件高可用架构也是如此。此外我们引入的架构，要尽量减少或者不对我们的项目代..
33.MySQL高可用架构
weixin_30682127的博客
07-25 219
33.高可用架构33.1 MMM架构MMM(Master-Master replication manager for MySQL)是一套支持双主故障切换和双主日常管理的脚本程序(Perl)。主要用来监控和管理MySQL Master-Master双主复制。优点：故障切换、多个Slave的read负载均衡。缺点：无法完全保证数据一致性。 33.2 MHA架构MHA(Master High Ava...
实战 MySQL 高可用架构
悟空聊架构的专栏
05-17 538
这是悟空的第147篇原创文章 ​官网：www.passjava.cn 你好，我是悟空。 业界流传一句话：没有做过运维的程序员不是好架构师。 不知是真是假。 前言 对于 MySQL 数据库作为各个业务系统的存储介质，在系统中承担着非常重要的职责，如果数据库崩了，那么对于读和写数据库的操作都会受到影响。如果不能迅速恢复，对业务的影响是非常大的。之前 B 站不是出过一次事故么，2 小时才恢复过来，详细可以看之前写的文章。 B 站崩了，总结下「高可用」和「异地多活」 上次折腾完 EL...
mysql高可用架构设计
sinat_34814635的博客
03-04 1180
数据库中的数据在主库完成更新后，是异步同步到每个从库上的，这个过程有一个微小的时间差，这个时间差叫主从同步延迟。正常情况下，主从延迟非常小，不超过 1ms。但即使这个非常小的延迟，也会导致在某一个时刻，主库和从库上的数据是不一致的。应用程序需要能接受并克服这种主从不一致的情况，否则就会引发一些由于主从延迟导致的数据错误。主备切换可能是一个主动运维动作，比如软件升级、主库所在机器按计划下线等，也可能是被动操作，比如主库所在机器掉电。接下来，我们先一起看看主动切换的场景。
MySQL数据库高可用架构解决方案
weixin_32822759的博客
05-23 488
一、前言 我们在实际生产中，对于mysql数据库而言，基本上都是采用的高可用架构，没有谁还采用单个mysql数据库。因为单个mysql会存在单点故障、性能瓶颈等缺点，那么针对这个缺点，所以才会出现高可用的mysql数据库架构。既然提到高可用的架构，那就离不开架构的设计，怎么样的架构设计才算是合理，当然是跟你的业务所挂钩的。 二 、常用架构辨析 首先，我们需要知道高可用架构需要解决我们的哪些问题？ 无外乎以下几点： 热备份， 多活， 故障切...
MySQL高可用架构知识整理
发现问题，面对问题，分析问题，解决问题，总结问题
02-08 3966
文章目录（1）MySQL 复制架构（2）MySQL复制类型（3）主库大事务处理（4）主从复制延迟优化（5）数据库高可用架构设计（6）容灾级别（7）数据核对（8）高可用套件——VIP（9）高可用套件MHA和Orchestrator（10） InnoDB Cluster和MGR技术（11）数据库备份 （1）MySQL 复制架构 【1】数据库复制本质上就是数据同步。MySQL 数据库是基于二进制日志（binary log）进行数据增量同步，而二进制日志记录了所有对于 MySQL 数据库的修改操作。 在默认 ROW
mysql高可用架构_mysql高可用架构详解
weixin_36488760的博客
01-18 2078
高可用(High Availabiltity)应用提供持续不间断(可用)的服务的能力系统高可用性的评价通常用可用率表示造成不可用的原因硬件故障(各种)预期中的系统软硬件维护软件缺陷(应用代码，服务程序都可能存在bug)***，泄露，认为失误...等安全事件对于系统来说，不可用时间是各关键组件不可用时间的总和.....提高可用性的主要手段冗余，Redundancy关键软硬件通过备用冗余避免故障时长时...
浅谈MySQL集群高可用架构
Enweitech Software Works
12-15 1083
前言 高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。对于一个系统而言，可能包含很多模块，比如前端应用，缓存，数据库，搜索，消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用可能更复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此数据库的高可用方案是一直以来的讨论热点，今天就各种的高可用方案，谈一下个人的
MySQL高可用架构解析与实战
"这篇分享主要探讨了MySQL的高可用架构，包括各种实现方式及其特点，以及如何根据实际需求选择合适的高可用方案。分享者是数据库爱好者，任职于新媒传信新技术研发部，并且是北京MySQL技术交流圈子的发起人之一。" ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值