高并发热点/单点数据_性能问题解决方案
热点单点数据问题由于其独有的高访问特性，在性能上一直都一大难题，IT界的大牛们也一直在寻求一种更为优化的解决方案！其中也不乏很多优秀的解决方案，但随着业务的不断攀升和互联网的高速发展，也就显得捉襟见肘，可见对此探索的重要性！
最近项目中也遇到了此瓶颈，请容我将前因后果以及我自己设想的粗陋方案娓娓道来，欢迎大神们拍砖，在下感激不尽！
前段时间接了一个双11的活动，业务逻辑：用户购买某一类商品后，活动期间的4个整点在活动页点击按钮领取支付宝红包，每个时段奖品数量有限，先到先得。听着很简单，可是活动开始时，异常火热，流量超过了我们的预估，本来是分时段领取奖品，结果演变为了秒杀。
当时每个整点的QPS瞬间飙高，响应时间RT短时间内居高不下，但是整个Check下来应用全部机器的负载都非常正常，后来全面查找原因，才找到问题的根源，是由于每个时段更新数据库同一条奖品导致超时！
整点开抢后瞬时巨量的请求同时涌入，即使我们Apache端做过初步限流，应用也做了信号量的控制，而且加上分布式缓存的使用，减缓了相当大的压力，整个业务逻辑校验阶段运作良好，但是系统的瓶颈就转移到其他环节：减奖品库存!因为我们每个时段只有一个奖品A，每次减库存都是update奖品A中的奖品余额字段！大量符合发奖要求的用户请求瞬时涌入数据库去更新此条记录，update锁行，导致后面的请求全部排队等待，等前面一个update完成释放行锁后才能处理下一个请求，大量请求等待，占用了数据库的连接！一旦数据库同一时间片内的连接数被打满，就会导致这个时间片内其他后来的全部请求因拿不到连接而超时，导致访问此数据库的其他环节也出现问题！所以RT就会异常飙高！
根据木桶理论，我们后续肯定必须得优化这个最短板，将这个瓶颈解决!针对这样的情况，我们这边出了两套方案：1、强依赖分布式缓存达到减库存的目的；2、热点/单点数据拆分，弱依赖分布式缓存，采用分散热点的方式减库存.下面请允许我详细分解下这两套方案，也希望大家提各种建设性意见！
&&&&&&一、强依赖分布式缓存
应用中使用分布式缓存来存储当前时间段的奖品余额，有用户中奖则将此缓存中的余额减一，不需要查询和实时更新数据库，而是每隔自定义的一段时间将缓存中的余额异步更新至数据库中。
优点：这种方式完全依赖于缓存，读写速度快，不需要实时更新数据库，降低了数据库相当大的压力；
缺点：缓存不是100%稳定，很容易丢，即使采用持久化的缓存，在高并发下有时也会出问题；一旦丢失数据，这样
&&&&&&&&&&&&&&
就导致数据库记录的奖品余额比实际真实存在的奖品余额要多，这个时候读数据库，就会导致奖品多发，也就
&&&&&&&&&&&&&&
是所谓的超卖！
二、热点/单点数据拆分，弱依赖分布式缓存
某时段的一个奖品拆分为多条后，如何能保证先到先得的业务需求将奖品准确发完，这里就引入分布式缓存作为辅助，缓存不完全稳定没关系，只是借助其在多条奖品中进行准确分发，当数据库所有奖品都有余额的情况时，能减少查询操作！只有当某一条奖品余额为0时缓存中的数据才会失效，这时才需要查询一次数据库！
&&&&&&1、&同个时段的奖品拆为多份(比如10份），加行号N区分（1~10），奖1~10的数值存入数组M中；
&&&&&&2、&根据行号1~10&，查询分布式缓存中是否存在各行奖品对应的记录（缓存中存放没余额的奖品行）；
&&&&&&&&&&&&是：&将存在的行号存入数组P；
&&&&&&&&&&&&否：&数组P值为NULL；
&&&&&&3、&数组M-数组P=数组R；
&&&&&&4、&判断数组R是否为空
&&&&&&&&&&&&是：&没有奖品余额，返回未中奖！
&&&&&&&&&&&&否：&在数组R中随机一个行号L；
&&&&&&5、&更新数据库表，将L行奖品余额减一；
&&&&&&&&&&&&更新成功：&减奖品库存成功，直接返回发奖成功！
&&&&&&&&&&&&更新失败：&极大可能原因是由于没有奖品导致
&&&&&&&&&&&&&&&&&&&&&&&&&5.1、&查询数据库中这10个奖品List（全量list）；
&&&&&&&&&&&&&&&&&&&&&&&&&5.2、&将List中没有奖品余额的行同步至对应的缓存（第2&步），并判断List中是否所有奖品行余额全为0；
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&是：&无奖品，返回未中奖；
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&否：&List中选择一个有余额的奖品，最好是余额最多的，将行号存入L，执行第5&步；
&&&&&&&&&&
&&&&&&&&&&
优点：此方案不会发生奖品多发的情况，将单行数据分拆为多行，分散了热点，同样可以减轻数据库更新时超负荷长链等待导致的连接被等待用户占用而后续请求超时，可以通过拆分为适量的行来解决单点热点数据带来的性能问题！
&&&&&&&&&&
缺点：此方案需要做业务拆解，增加了业务的复杂性！奖品拆分为多条，数据量太大时，不是很便捷，可能会带来数据库性能问题，但这个可以通过分库分表，旧数据迁移备份的方式解决！在奖品快被抽完的那么几微秒的用户可能存在误杀！
&&&&&&&&&&
这就是目前针对数据库的单点热点问题，我个人的一些见解，也只是初步构想，还没有进入完全的实践中，还希望各位大神多指点一二！
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。如何解决或降低缓存服务的单点故障导致数据库的流量井喷_百度知道一个小型的网站，可以使用最简单的html静态页面就实现了，配合一些图片达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单。随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。
大型网站，比如门户网站，在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。这几个解决思路在一定程度上意味着更大的投入。
1、HTML静态化
其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。
除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化、有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。
同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现。比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储在数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。
2、图片服务器分离
大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的、甚至很多台的图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃。
在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持、尽可能少的LoadModule，保证更高的系统消耗和执行效率。
3、数据库集群、库表散列
大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。
在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。
上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。
我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。
sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。
缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。
架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。
网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，.net不是很熟悉，相信也肯定有。
镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。
6、负载均衡
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的高端解决办法。
负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。
（1）、硬件四层交换
第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。
第四层交换功能就像是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。
在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。“Yahoo中国”当初接近2000台服务器，只使用了三、四台Alteon就搞定了。
(2)、软件四层交换
大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。
软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的强壮性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。
一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。
对于大型网站来说，前面提到的每个方法可能都会被同时使用到，这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会。有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大。
7、最新：CDN加速技术
什么是CDN？
CDN的全称是内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可以就近取得所需的内容，提高用户访问网站的响应速度。
CDN有别于镜像，因为它比镜像更智能，或者可以做这样一个比喻：CDN=更智能的镜像+缓存+流量导流。因而，CDN可以明显提高Internet网络中信息流动的效率。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等问题，提高用户访问网站的响应速度。
CDN的类型特点
CDN的实现分为三类：镜像、高速缓存、专线。
镜像站点（Mirror Site），是最常见的，它让内容直接发布，适用于静态和准动态的数据同步。但是购买和维护新服务器的费用较高，还必须在各个地区设置镜像服务器，配备专业技术人员进行管理与维护。对于大型网站来说，更新所用的带宽成本也大大提高了。
高速缓存，成本较低，适用于静态内容。Internet的统计表明，超过80%的用户经常访问的是20%的网站的内容，在这个规律下，缓存服务器可以处理大部分客户的静态请求，而原始的服务器只需处理约20%左右的非缓存请求和动态请求，于是大大加快了客户请求的响应时间，并降低了原始服务器的负载。
CDN服务一般会在全国范围内的关键节点上放置缓存服务器。
专线，让用户直接访问数据源，可以实现数据的动态同步。
举个例子来说，当某用户访问网站时，网站会利用全球负载均衡技术，将用户的访问指向到距离用户最近的正常工作的缓存服务器上，直接响应用户的请求。
当用户访问已经使用了CDN服务的网站时，其解析过程与传统解析方式的最大区别就在于网站的授权域名服务器不是以传统的轮询方式来响应本地DNS的解析请求，而是充分考虑用户发起请求的地点和当时网络的情况，来决定把用户的请求定向到离用户最近同时负载相对较轻的节点缓存服务器上。
通过用户定位算法和服务器健康检测算法综合后的数据，可以将用户的请求就近定向到分布在网络“边缘”的缓存服务器上，保证用户的访问能得到更及时可靠的响应。
由于大量的用户访问都由分布在网络边缘的CDN节点缓存服务器直接响应了，这就不仅提高了用户的访问质量，同时有效地降低了源服务器的负载压力。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：19623次
排名：千里之外
原创：49篇
转载：135篇
(2)(1)(5)(6)(106)(16)(30)(8)(12)(4)MySQL主库高可用 -- 双主单活故障自动切换方案_数据库技术_Linux公社-Linux系统门户网站
你好，游客
MySQL主库高可用 -- 双主单活故障自动切换方案
来源：Linux社区&
作者：kaifly
前言：（PS：前言是后来修改本文时加的）对于这篇文章，有博友提出了一些疑问和见解， 有了博友的关注，也促使我想把这套东西做的更实用、更安全。后来又经过思考，对脚本中一些条件和行为做了些改变。经过几次修改，现在终于敢说让小伙伴本使用这套东西了。
主要目的：
以双主结构配合keepalived解决MySQL主从结构中主库的单点故障；同时通过具体的查询语句提供更细粒度、更为真实的关于主库可用性的判断。
基本思路：& & 将DB1和DB2做成主动被动模式的双主结构：DB1主动、DB2被动，通过keepalived的VIP对外，将VIP设置成原DB1的IP，保证改造过程对代码透明& & 三个前提：
& & & & & & 两台MySQL的配置文件里需要加上&log_slave_updates = 1&；& & & & & & 并且&备用机&通过&read_only&参数实现除root用户之外的只读特性；& & & & & & 分别在两个数据库创建test.test表，插入几条数据，供检测脚本使用。& & 正常时，VIP在DB1，通过keepalived调用脚本定期检查mysql服务可用性（通过一个低权限用户连接mysql服务器并执行一个简单查询，根据返回结果来判定mysql是否可用）
若无法执行查询：
1. 第一次检测失败后,检查服务状态,：
若服务异常，则执行切换：关闭DB1的keepalived，使VIP漂移至DB2，通过DB2上keepalived的notify_master机制，触发脚本将DB2的mysql从被动状态（只读）切换到主动状态（可读写），并发送通知邮件。
若服务正常（则可能是一些临时性因素导致的监测失败），等待30s做第二次检查，这30s是对瞬时/短时因素造成检查失败的容忍时间，本着&能不切则不切&的原则。若第二次检查仍然失败
2.& 开始执行系列切换动作
将DB1的MySQL设置为 read_only模式 （阻止写请继续求进入）
kill掉当前客户端的线程。原来担心kill掉线程会对数据执行造成影响，后来查看了官方文档&&，发现mysql正常关闭过程也有一步是如此操作，所以这里可以放心了。然后 sleep 2，给kill命令一些时间（关于kill命令的机制，参考）
关闭DB1的keepalived，使DB2接管VIP。通过DB2上keepalived的notify_master机制，触发脚本将DB2的
mysql从被动状态（只读）切换到主动状态（可读写），并发送通知邮件。
3.& 管理员修复DB1后，通过脚本&change_to_backup.sh&将主库切换回DB1。脚本思路如下：
& & 注：涉及到切换主备，就会有中断时间，所以推荐此步骤在业务低谷期执行
将DB2的read_only属性置为1
kill掉DB2上的client线程，并重启DB2的keepalived使VIP漂移至DB1
确定DB1跟上了DB2的更新，并将DB1上的read_only属性移除
关于&数据一致性&和&切换时间&：
& & & 连续两次失败以后，通过对主MySQL设置read_only属性，同时kill掉用户线程来保证在DB2接管服务之前，DB1上已经没有写操作，避免主从数据不一致。并且切换时间基本上是可确定的：
& & & 30s（两次检测间隔）+2s（等待kill命令时间）+约1s（keepalived 切换VIP），总时间不会超过35s。
以上是大致思路，具体实现看过下面的脚本，就会一目了然了。
DB1上keepalived 配置
! Configuration File for keepalived & vrrp_script chk_mysql { & & script "/etc/keepalived/check_mysql.sh"& & interval 30& & & & #这里我的检查间隔设置的比较长，因为我们数据库前面有redis做缓存，数据库一两分钟级别的中断对整体可用性影响不大。这也是我没有采用成熟的方案而自己搞了这一套方案的&定心丸& } vrrp_instance VI_1 { & & state BACKUP& & & & #通过下面的priority来区分MASTER和BACKUP，也只有如此，底下的nopreempt才有效 & & interface em2 & & virtual_router_id 51 & & priority 100 & & advert_int 1 & & nopreempt& & & & & #防止切换到从库后，主keepalived恢复后自动切换回主库 & & authentication { & & & & auth_type PASS & & & & auth_pass 1111 & & } & & track_script { & & & & chk_mysql & & } & & & & & virtual_ipaddress { & & & & 192.168.1.5/24& & } }
/etc/keepalived/check_mysql.sh脚本内容如下（主要的判断逻辑都在这里）#!/bin/sh & ###判断如果上次检查的脚本还没执行完，则退出此次执行 if [ `ps -ef|grep -w "$0"|grep "/bin/sh*"|grep "?"|grep "?"|grep -v "grep"|wc -l` -gt 2 ];then& #理论上这里应该是1，但是实验的结果却是2 & & exit 0 fi& alias mysql_con='mysql -uxxxx -pxxxx'& ###定义一个简单判断mysql是否可用的函数 function excute_query { & & mysql_con -e "select * from test." 2&&/etc/keepalived/logs/check_mysql.err } & ###定义无法执行查询，且mysql服务异常时的处理函数 function service_error { & & echo -e "`date "+%F& %H:%M:%S"`& & -----mysql service error，now stop keepalived-----" && /etc/keepalived/logs/check_mysql.err & & /sbin/service keepalived stop &&& /etc/keepalived/logs/check_mysql.err & & echo -e "\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\n" && /etc/keepalived/logs/check_mysql.err } & ###定义无法执行查询,但mysql服务正常的处理函数 function query_error { & & echo -e "`date "+%F& %H:%M:%S"`& & -----query error, but mysql service ok, retry after 30s-----" && /etc/keepalived/logs/check_mysql.err & & sleep 30 & & excute_query & & if [ $? -ne 0 ];then& & & & echo -e "`date "+%F& %H:%M:%S"`& & -----still can't execute query-----" && /etc/keepalived/logs/check_mysql.err & & & & & ###对DB1设置read_only属性 & & & & echo -e "`date "+%F& %H:%M:%S"`& & -----set read_only = 1 on DB1-----" && /etc/keepalived/logs/check_mysql.err & & & & mysql_con -e "set global read_only = 1;" 2&& /etc/keepalived/logs/check_mysql.err & & & & & ###kill掉当前客户端连接 & & & & echo -e "`date "+%F& %H:%M:%S"`& & -----kill current client thread-----" && /etc/keepalived/logs/check_mysql.err & & & & rm -f /tmp/kill.sql &&/dev/null& & & & ###这里其实是一个批量kill线程的小技巧 & & & & mysql_con -e 'select concat("kill ",id,";") from& information_schema.PROCESSLIST where command="Query" or command="Execute" into outfile "/tmp/kill.sql";'& & & & mysql_con -e "source /tmp/kill.sql"& & & & sleep 2& & ###给kill一个执行和缓冲时间 & & & & ###关闭本机keepalived& & & & & & & & echo -e "`date "+%F& %H:%M:%S"`& & -----stop keepalived-----" && /etc/keepalived/logs/check_mysql.err & & & & /sbin/service keepalived stop &&& /etc/keepalived/logs/check_mysql.err & & & & echo -e "\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\n" && /etc/keepalived/logs/check_mysql.err & & else& & & & echo -e "`date "+%F& %H:%M:%S"`& & -----query ok after 30s-----" && /etc/keepalived/logs/check_mysql.err & & & & echo -e "\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\n" && /etc/keepalived/logs/check_mysql.err & & fi} & ###检查开始: 执行查询 excute_query if [ $? -ne 0 ];then& & /sbin/service mysql status &&/dev/null& & if [ $? -ne 0 ];then& & & & service_error & & else& & & & query_error & & fifi
DB2上keepalived配置：! Configuration File for keepalived & vrrp_instance VI_1 { & & state BACKUP & & interface em2 & & virtual_router_id 51 & & priority 90 & & advert_int 1 & & authentication { & & & & auth_type PASS & & & & auth_pass 1111 & & } & & notify_master /etc/keepalived/notify_master_mysql.sh& & #此条指令告诉keepalived发现自己转为MASTER后执行的脚本 & & virtual_ipaddress { & & & & 192.168.1.5/24& & } }
/etc/keepalived/notify_master_mysql.sh脚本内容：#!/bin/bash ###当keepalived监测到本机转为MASTER状态时，执行该脚本 & change_log=/etc/keepalived/logs/state_change.log alias mysql_con='mysql -uroot -pxxxx -e "show slave status\G;" 2&/dev/null'& echo -e "`date "+%F& %H:%M:%S"`& -----keepalived change to MASTER-----" && $change_log & slave_info() { & & ###统一定义一个函数取得slave的position、running、和log_file等信息 & & ###根据函数后面所跟参数来决定取得哪些数据 & & if [ $1 = slave_status ];then& & & & slave_stat=`mysql_con|egrep -w "Slave_IO_Running|Slave_SQL_Running"` & & & & Slave_IO_Running=`echo $slave_stat|awk '{print $2}'` & & & & Slave_SQL_Running=`echo $slave_stat|awk '{print $4}'` & & elif [ $1 = log_file -a $2 = pos ];then& & & & log_file_pos=`mysql_con|egrep -w "Master_Log_File|Read_Master_Log_Pos|Exec_Master_Log_Pos"` & & & & Master_Log_File=`echo $log_file_pos|awk '{print $2}'` & & & & Read_Master_Log_Pos=`echo $log_file_pos|awk '{print $4}'` & & & & Exec_Master_Log_Pos=`echo $log_file_pos|awk '{print $6}'` & & fi} & action() { & & ###经判断'应该&可以'切换时执行的动作 & & echo -e "`date "+%F& %H:%M:%S"`& & -----set read_only = 0 on DB2-----" && $change_log & & & ###解除read_only属性 & & mysql_con -e "set global read_only = 0;" 2&& $change_log & & & echo "DB2 keepalived转为MASTER状态，线上数据库切换至DB2"|/bin/mailx -s "DB2 keepalived change to MASTER"\ & &
2&& $change_log & & & echo -e "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\n" && $change_log } & slave_info slave_status if [ $Slave_IO_Running = Yes -a $Slave_SQL_Running = Yes ];then& & i=0& & #一个计数器 & & slave_info log_file pos & & & & ###判断从master接收到的binlog是否全部在本地执行(这样仍无法完全确定从库已追上主库，因为无法完全保证io_thread没有延时(由网络传输问题导致的从库落后的概率很小) & & until [ $Read_Master_Log_Pos = $Exec_Master_Log_Pos ] & & do& & & & if [ $i -lt 10 ];then& & #将等待exec_pos追上read_pos的时间限制为10s & & & & & & echo -e "`date "+%F& %H:%M:%S"`& & -----Master_Log_File=$Master_Log_File. Exec_Master_Log_Pos($Exec_Master_Log_Pos) is behind Read_Master_Lo g_Pos($Read_Master_Log_Pos), wait......" && $change_log& & #输出消息到日志，等待exec_pos=read_pos & & & & & & i=$(($i+1)) & & & & & & sleep 1 & & & & & & slave_info log_file pos & & & & else& & & & & & echo -e "The waits time is more than 10s,now force change. Master_Log_File=$Master_Log_File Read_Master_Log_Pos=$Read_Master_Log_Pos Exec_Ma ster_Log_Pos=$Exec_Master_Log_Pos" && $change_log & & & & & & action & & & & & & exit 0 & & & & fi& & done& & action& & else& & slave_info log_file pos & & echo -e "DB2's slave status is wrong,now force change. Master_Log_File=$Master_Log_File Read_Master_Log_Pos=$Read_Master_Log_Pos& Exec_Master_Log_Po s=$Exec_Master_Log_Pos" && $change_log & & action fi
DB2上手动切换回DB1的脚本change_to_backup.sh：#!/bin/sh ###手动执行将主库切换回DB1的操作 & alias mysql_con='mysql -uxxxx -pxxxx'& echo -e "`date "+%F& %H:%M:%S"`& & -----change to BACKUP manually-----" && /etc/keepalived/logs/state_change.log echo -e "`date "+%F& %H:%M:%S"`& & -----set read_only = 1 on DB2-----" && /etc/keepalived/logs/state_change.log mysql_con -e "set global read_only = 1;" 2&& /etc/keepalived/logs/state_change.log & ###kill掉当前客户端连接 echo -e "`date "+%F& %H:%M:%S"`& & -----kill current client thread-----" && /etc/keepalived/logs/state_change.log rm -f /tmp/kill.sql &&/dev/null###这里其实是一个批量kill线程的小技巧 mysql_con -e 'select concat("kill ",id,";") from& information_schema.PROCESSLIST where command="Query" or command="Execute" into outfile "/tmp/kill.sql";'mysql_con -e "source /tmp/kill.sql" 2&& /etc/keepalived/logs/state_change.log sleep 2& & ###给kill一个执行和缓冲时间 & ###确保DB1已经追上了,下面的repl为复制所用的账户，-h后跟DB1的内网IP pos=`mysql -urepl -pxxxx -h192.168.1.x -e "show slave status\G;"|grep "Master_Log_Pos"|awk '{printf ("%s",$NF "\t")}'` read_pos=`echo $pos|awk '{print $1}'` exec_pos=`echo $pos|awk '{print $2}'` until [ $read_pos = $exec_pos ] do& & echo -e "`date "+%F& %H:%M:%S"`& & -----DB1 Exec_Master_Log_Pos($exec_pos) is behind Read_Master_Log_Pos($read_pos), wait......" && /etc/keepalived/logs/state_change.log & & sleep 1 done& ###然后解除DB1的read_only属性 echo -e "`date "+%F& %H:%M:%S"`& & -----set read_only = 0 on DB1-----" && /etc/keepalived/logs/state_change.log ssh 192.168.1.x 'mysql -uxxxx -pxxxx -e "set global read_only = 0;" && /etc/init.d/keepalived start' 2&& /etc/keepalived/logs/state_change.log & ###重启DB2的keepalived使VIP漂移到DB1 echo -e "`date "+%F& %H:%M:%S"`& & -----make VIP move to DB1-----" && /etc/keepalived/logs/state_change.log /sbin/service keepalived restart &&& /etc/keepalived/logs/state_change.log & echo "DB2 keepalived转为BACKUP状态，线上数据库切换至DB1"|/bin/mailx -s "DB2 keepalived change to BACKUP"
2&& /etc/keepalived/logs/state_change.log & echo -e "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\n" && /etc/keepalived/logs/state_change.log
日志截图：DB1 mysql服务故障：
DB1 mysql服务正常，查询失败：
DB2 一次切换过程：
DB2 执行脚本手动切回DB1：
总结：此方相比MHA或者MMM之类技术，特点在于简单，降低实施和维护复杂度；同时也安全的解决了主从中master节点的单点问题；在此基础上，亦可以再增加从库实现读写分离等架构；不足之处是双主仍是单活，DB2只是作为热备。
本文永久更新链接地址：
相关资讯 & & &
& (07月05日)
& (05月03日)
& (05月02日)
& (06月27日)
& (05月03日)
& (04月11日)
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款