mysql⾼可⽤集部署⽅案（mha+atlas+keepalived）
⼀、mysql⾼可⽤前提
在许多⽐较重要的系统中，基本上都是24h*365d不间断运⾏的。
  对于应⽤程序来讲，可以做haproxy+app 或 nginx+app的集。好，问题来了，当应⽤程序的性能调优后，那么瓶颈就卡在数据库上。这个时候，就要对数据库进⾏优化。
  在进⾏去IOE后，基本上许多的数据库都采⽤的是开源的mysql数据库。
  当并发较⾼或数据量⽐较⼤的时候，数据库的瓶颈就会成为制约应⽤的关键。此时，我们会通过做mysql主从机读写分离（主节点master负责写，从节点slave负责读），再对主机进⾏双机热备（当主节点宕机后，⾃动切换到另⼀备⽤节点上），对从节点做集（读取数据分离到不同的节点上，以减⼩读数据库的压⼒）。
  这⾥在做主从读写分离是⽤qihoo的atlas。在mysql做故障转移是⽤mha。对数据库主备节点做故障切换则是⽤keepalived。
⾼可⽤性
很多公司的服务都是24⼩时*365天不间断的。这就要求⾼可⽤性。再⽐如购物⽹站，必须随时都可以交易。那么当购物⽹的server挂了⼀个的时候，不能对业务产⽣任何影响。这就是⾼可⽤性。
  当服务器down掉，或者出现错误的时候，可以⾃动的切换到其他待命的服务器，不影响服务器上App的运⾏。
读写分离
随着⼀个⽹站的业务不断扩展，数据不断增加，数据库的压⼒也会越来越⼤，对数据库或者SQL的基本优化可能达不到最终的效果，我们可以采⽤读写分离的策 略来改变现状。
  读写分离简单的说是把对数据库读和写的操作分开对应不同的数据库服务器，这样能有效地减轻数据库压⼒，也能减轻io压⼒。主数据库提供写操作，从数据库提 供读操作，其实在很多系统中，主要是读的操作。当主数据库进⾏写操作时，数据要同步到从的数据库，这样才能有效保证数据库完整性。
⼆、mysql⾼可⽤软件概述
MySQL⾼可⽤性⼤杀器之MHA
MHA（Master High Availability）⽬前在MySQL⾼可⽤⽅⾯是⼀个相对成熟的解决⽅案，它由⽇本De
NA公司youshimaton（现就职于Facebook公司）开发，是⼀套优秀的作为MySQL⾼可⽤性环境下故障切换和主从提升的⾼可⽤软件。在MySQL故障切换过程中，MHA能做到在 0~30秒之内⾃动完成数据库的故障切换操作，并且在进⾏故障切换的过程中，MHA能在最⼤程度上保证数据的⼀致性，以达到真正意义上的⾼可⽤。
  该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在⼀台独⽴的机器上管理多个master-slave集，也可以部署在⼀台slave节点上。MHA Node运⾏在每台MySQL服务器上，MHA Manager会定时探测集中的master节点，当master出现故障时，它可以⾃动将最新数据的slave提升为新的master，然后将所有其 他的slave重新指向新的master。整个故障转移过程对应⽤程序完全透明。
  在MHA⾃动故障切换过程中，MHA试图从宕机的主服务器上保存⼆进制⽇志，最⼤程度的保证数据的不丢失，但这并不总是可⾏的。例如，如果主服务器 硬件故障或⽆法通过ssh访问，MHA没法保存⼆进制⽇志，只进⾏故障转移⽽丢失了最新的数据。使⽤MySQL 5.5的半同步复制，可以⼤⼤降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有⼀个slave已经收到了最新的⼆进制⽇志，MHA可以将最 新的⼆进制⽇志应⽤于其他所有的slave服务器上，因此可以保证所有节点的数据⼀致性。
  ⽬前MHA主要⽀持⼀主多从的架构，要搭建MHA，要求⼀个复制集中必须最少有三台数据库服务器，⼀主⼆从，即⼀台充当master，⼀台充当备⽤master，另外⼀台充当从库，因为⾄少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进⾏了改造，⽬前淘
c++python混合编程宝TMHA已经⽀持⼀主⼀从。
读写分离利器atlas
现在⼤型的电⼦商务系统，在数据库层⾯⼤都采⽤读写分离技术，就是⼀个Master数据库，多个Slave数据库。
  Master库负责数据更新，Slave库当然负责⾮实时数据查询。
  因为在实际的应⽤中，数据库都是读多写少（读取数据的频率⾼，更新数据的频率相对较少），⽽读取数据通常耗时⽐较长，占⽤数据库服务器的CPU较多，从⽽影响⽤户体验。
  我们通常的做法就是把查询从主库中抽取出来，采⽤多个从库，使⽤负载均衡，减轻每个从库的查询压⼒。
  采⽤读写分离技术的⽬标：有效减轻Master库的压⼒，⼜可以把⽤户查询数据的请求分发到不同的Slave库，从⽽保证系统的健壮性。
  我们看下采⽤读写分离的背景。随着⽹站的业务不断扩展，数据不断增加，⽤户越来越多，数据库的压⼒也就越来越⼤，采⽤传统的⽅式。
  ⽐如：数据库或者SQL的优化基本已达不到要求，这个时候可以采⽤读写分离的策 略来改变现状。
  常见实现读写分离的⽅法:
素还真为什么杀史艳文  1. 开发在代码中写死 #指定修改操作，连接的是主库。查询操作，连接的是从库
  2. 第三⽅⼯具实现 Atlas、cobar、TDDL、mysql-proxy、阿⽶巴等
  3. 我们这套架构中的读写分离是使⽤Atlas实现的，Atlas是由 Qihoo 360 Web平台部基础架构团队开发维护的⼀个基于MySQL协议的数据中间层项⽬。
  它在MySQL官⽅推出的MySQL-Proxy 0.8.2版本的基础上，修改了⼤量bug，添加了很多功能特性。
  ⽬前该项⽬在360公司内部得到了⼴泛应⽤，很多MySQL业务已经接⼊了Atlas平台，每天承载的读写请求数达⼏⼗亿条。
  主要功能：
  a.读写分离
  b.从库负载均衡
  c.IP过滤
  d.SQL语句⿊⽩名单
  e.⾃动分表
⾼可⽤Keepalived
keepalived是⼀款c语⾔写的实现在linux系统上实现负载均衡和⾼可⽤的软件。它遵从于GNU是⼀款优秀的开源软件。keepalived观其名可知，保持存活，在⽹络⾥⾯就是保持在线了，也就是所谓的⾼可⽤或热备，⽤来防⽌单点故障的发⽣。
mysql查询索引语句负载均衡
  keepalived内置了对ipvs函数的调⽤⽀持。可以直接在keepalived中按照语法配置ipvs然后keepalived就可以实现对ipvs的配置。
⾼可⽤
  keepalived是以VRRPVirtual Router Redundancy Protocol协议为实现基础的即虚拟路由冗余协议。虚拟路由冗余协议可以认为是实现路由器⾼可⽤的协议即将N台提供相同功能的路由器组成⼀个路由器组这个组⾥⾯有⼀个master和多个backupmaster上⾯有⼀个对外提供服务的vip该路由器所在局域⽹内其他机器的默认路由为该vipmaster会发组播当backup收不到vrrp包时就认为master宕掉了这时就需要根据VRRP的优先级来选举⼀个backup当master。这样的话就可以保证路由器的⾼可⽤了。
本套架构中keepalive的作⽤05网暑假作业
  由于mysql+replication⽅案中master和slave的关系是⼀对多的关系，整个系统中只有⼀个master节点（写⼊节点），多个slave节点，那么master节点⼀旦down机后，整个系统的数据写⼊操作将瘫痪，对系统造成严重后果。为此引⼊了keepalive⼯具，让这个系统的master和slave关系是多对多的关系，对master节点进⾏双机热备，以达到整个系统的⾼可⽤性。其中keepalive⼯具负责对两个master 节点进⾏不间断监听，⼀旦⼯作中的master节点停⽌⼯作后，那么备份master节点就会接管 ，让这个系统正常⼯作。向外提供⼀个虚拟ip 以供proxy访问master，虚拟ip对应了两个实ip的maser节点。
三、mysql⾼可⽤架构
本次架构实现功能
1. ⼀主库，两个从库(其中1个为备主)，实现ABB复制
2. 使⽤Atlas实现读写分离，主库和备主库接收写操作，从库接收读操作
3. 使⽤Mha实现现有架构的⾼可⽤
4. 使⽤keepalived实现vip的漂移
5. ⼿⼯编写shell，修复Mha的不⾜
6. 修复当AB故障切换⼀次后，mha-manager会⾃动退出
7. 修复原主库，出问题后，修复后不能⾃动加⼊现有AB集
8. 关于relay log的清除
本次实现架构图
ip划分
主机ip os安装软件vip
192.168.10.189centos 6.7mysql master 、keepalived192.168.10.240
192.168.10.190centos 6.7mysql slave(master) 、keepalived192.168.10.240
192.168.10.166centos 6.7mysql slave
192.168.10.192centos 6.7mha、atlas
架构图
四、mysql数据库安装
五、mysql主从复制
MySql AB复制
  AB复制⼜称主从复制，实现的是数据同步。如果要做MySQL AB复制，数据库版本尽量保持⼀致。如果版本不⼀致，从服务器版本⾼于主服务器，但是版本不⼀致不能做双向复制。
MySQL AB复制有什么好处呢？
解决宕机带来的数据不⼀致，因为MySQL AB复制可以实时备份数据。
减轻数据库服务器压⼒，这点很容易想到，多台服务器的性能⼀般⽐单台要好。
AB复制主要通过2个线程实现：
I/O线程：从主库上把bin-log下载到从库后，放到从库的Relay-log中。(从库中的)
SQL线程：把Relay-log中的动作，在从库上做⼀次。(从库中的)AB复制的3个主要步骤
主服务器把数据更改记录到⼆进制⽇志中，这个操作叫做⼆进制⽇志事件。
mysql无法连接到服务器
从服务器把主服务器的⼆进制⽇志事件拷贝到⾃⼰的中继⽇志（relay log）中。
从服务器执⾏中继⽇志中的事件，把更改应⽤到⾃⼰的数据上。
修改主库和从库的参数⽂件(/etc/myf)
主库：192.168.10.189
#[mysqld]标签下追加
#表⽰是本机的序号为1,⼀般来讲就是master的意思
server_id =1
#服务器在关闭它之前在⼀个连接上等待⾏动的秒数。
wait_timeout=360000
#开启Binlog⽇志
log-bin=binlog
#开启Binlog⽇志的索引⽂件
log-bin-index=binlog.index
#表⽰slave将复制事件写进⾃⼰的⼆进制⽇志
log_slave_updates=1
#当每进⾏1次事务提交之后，MySQL将进⾏⼀次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写⼊磁盘sync-binlog = 1
#表⽰⾃增长字段从那个数开始，他的取值范围是1 .. 65535
auto_increment_offset = 2
#表⽰⾃增长字段每次递增的量，其默认值是1，取值范围是1 .. 65535
auto_increment_increment = 2
从库1：192.168.10.190(备主)
#[mysqld]标签下追加
#是否⾃动清空不再需要中继⽇志时,0不启动
relay_log_purge=0
server_id =2
#服务器在关闭它之前在⼀个连接上等待⾏动的秒数。
wait_timeout=360000
#开启Binlog⽇志
log-bin=binlog
#开启Binlog⽇志的索引⽂件
log-bin-index=binlog.index
#表⽰slave将复制事件写进⾃⼰的⼆进制⽇志
log_slave_updates=1
#当每进⾏1次事务提交之后，MySQL将进⾏⼀次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写⼊磁盘sync-binlog = 1
#表⽰⾃增长字段从那个数开始，他的取值范围是1 .. 65535
auto_increment_offset = 1
#表⽰⾃增长字段每次递增的量，其默认值是1，取值范围是1 .. 65535
auto_increment_increment = 2
从库2：192.168.10.166(所有从库的操作都⼀样)
#[mysqld]标签下追加
#只读操作控制
read_only=1
#是否⾃动清空不再需要中继⽇志时,0不启动
background属性用法relay_log_purge=0
server_id = 3
#定义relay_log的位置和名称
relay_log = /usr/local/mysql/mysql-relay-bin
#定义relay_log的索引⽂件位置和名称
relay_log_index=/usr/local/mysql/mysql-relay-bin.index
#服务器在关闭它之前在⼀个连接上等待⾏动的秒数。
wait_timeout=360000
主库
#创建⽤AB复制所需的⽤户
mysql> GRANT replication slave ON *.* TO 'xtgss'@'%' identified by 'Xtgss@123'; mysql> flush privileges;
所有从库 #如果从库以前有数据，要⼲掉原有数据，保持从库是⼲净的
service mysql stop #停⽌Mysql服务
cd /var/lib/mysql/data #进⼊数据⽬录
rm -fr 数据库⽬录 #删除数据库⽬录
service mysql restart #启动Mysql服务
主库 #主库的数据导出，并导⼊所有从库，保持数据⼀致
#主库导出数据
mysqldump -u root -pmysql m >/tmp/full.sql
#主库导出的数据通过scp传送到所有从库
scp /tmp/full.sql root@从库IP:/tmp/
所有从库 #导⼊主库传过来的数据
#导⼊主库传递过来的数据
1mysql -u root -pmysql m < /tmp/full.sql
主库 #为主库加上只读锁，查看当前Binlog⽇志情况

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。