mysqlheartbeat共享存储
⑴ 如何提高网站并发访问性能
1、HTML静态化
其实大家都知道,效率最高、消耗最小的就是纯静态化的html页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法
其实也是最有效的方法。但是对于大量内容并且频繁更新的网站,我们无法全部手动去挨个实现,于是出现了我们常见的信息发布系统CMS,像我们常访问的各个
门户站点的新闻频道,甚至他们的其他频道,都是通过信息发布系统来管理和实现的,信息发布系统可以实现最简单的信息录入自动生成静态页面,还能具备频道管
理、权限管理、自动抓取等功能,对于一个大型网站来说,拥有一套高效、可管理的CMS是必不可少的。
除了门户和信息发布类型的网站,对于交互性要求很高的社区类型网站来说,尽可能的静态化也是提高性能的必要手段,将社区内的帖子、文章进行实时的静态化、有更新的时候再重新静态化也是大量使用的策略,像Mop的大杂烩就是使用了这样的策略,网易社区等也是如此。
同时,html静态化也是某些缓存策略使用的手段,对于系统中频繁使用数据库查询但是内容更新很小的应用,可以考虑使用html静态化来实现。
比如论坛中论坛的公用设置信息,这些信息目前的主流论坛都可以进行后台管理并且存储在数据库中,这些信息其实大量被前台程序调用,但是更新频率很小,可以
考虑将这部分内容进行后台更新的时候进行静态化,这样避免了大量的数据库访问请求。
2、图片服务器分离
大家知道,对于Web服务器来说,不管是Apache、IIS还是其他容器,图片是最消耗资源的,于是我们有必要将图片与页面进行分离,这是基
本上大型网站都会采用的策略,他们都有独立的、甚至很多台的图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力,并且可以保证系统不会因为
图片问题而崩溃。
在应用服务器和图片服务器上,可以进行不同的配置优化,比如apache在配置ContentType的时候可以尽量少支持、尽可能少的LoadMole,保证更高的系统消耗和执行效率。
3、数据库集群、库表散列
大型网站都有复杂的应用,这些应用必须使用数据库,那么在面对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用,于是我们需要使用数据库集群或者库表散列。
在数据库集群方面,很多数据库都有自己的解决方案,Oracle、Sybase等都有很好的方案,常用的Mysql提供的Master/Slave也是类似的方案,您使用了什么样的DB,就参考相应的解决方案来实施即可。
上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制,于是我们需要从应用程序的角度来考虑改善系统架构,库表散列是常用并且最有效的解决方案。
我们在应用程序中安装业务和应用或者功能模块将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略对某个页面或者功能进行更小的数据库散列,比如用户表,按照用户ID进行表散列,这样就能够低成本的提升系统的性能并且有很好的扩展性。
sohu的论坛就是采用了这样的架构,将论坛的用户、设置、帖子等信息进行数据库分离,然后对帖子、用户按照板块和ID进行散列数据库和表,最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。
4、缓存
缓存一词搞技术的都接触过,很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。
架构方面的缓存,对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块,也可以使用外加的Squid模块进行缓存,这两种方式均可以有效的提高Apache的访问响应能力。
网站程序开发方面的缓存,linux上提供的Memory
Cache是常用的缓存接口,可以在web开发中使用,比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享,一些大
型社区使用了这样的架构。另外,在使用web语言开发的时候,各种语言基本都有自己的缓存模块和方法,PHP有Pear的Cache模块,Java就更多
了,.net不是很熟悉,相信也肯定有。
5、镜像
镜像是大型网站常采用的提高性能和数据安全性的方式,镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异,比如ChinaNet和
ENet之间的差异就促使了很多网站在教育网内搭建镜像站点,数据进行定时更新或者实时更新。在镜像的细节技术方面,这里不阐述太深,有很多专业的现
成的解决架构和产品可选。也有廉价的通过软件实现的思路,比如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的实例
举个例子来说,当某用户访问网站时,网站会利用全球负载均衡技术,将用户的访问指向到距离用户最近的正常工作的缓存服务器上,直接响应用户的请求。
当用户访问已经使用了CDN服务的网站时,其解析过程与传统解析方式的最大区别就在于网站的授权域名服务器不是以传统的轮询方式来响应本地
DNS的解析请求,而是充分考虑用户发起请求的地点和当时网络的情况,来决定把用户的请求定向到离用户最近同时负载相对较轻的节点缓存服务器上。
通过用户定位算法和服务器健康检测算法综合后的数据,可以将用户的请求就近定向到分布在网络“边缘”的缓存服务器上,保证用户的访问能得到更及时可靠的响应。
由于大量的用户访问都由分布在网络边缘的CDN节点缓存服务器直接响应了,这就不仅提高了用户的访问质量,同时有效地降低了源服务器的负载压力。
⑵ mysql数据库可靠性分析
mysql数据库有undo空间
5种mysql做可靠性分析的方案:
1.MySQL Clustering(ndb-cluster stogare)
简介:
MySQL公司以存储引擎方式提供的高可靠性方案,是事务安全的,实时复制数据,可用于需要高可靠性及负载均衡的场合。该方案至少需要三个节点服务器才能达到较好的效果。
成本:
节点服务器对RAM的需求很大,与数据库大小呈线性比例;
最好使用千兆以太网络;
还需要使用Dolphin公司提供的昂贵的SCI卡。
优点:
可用于负载均衡场合;
可用于高可靠性场合;
高伸缩性;
真正的数据库冗余;
容易维护。
缺点:
随着数据库的变大,对RAM的需求变得更大,因此成本很高;
速度:
几乎 比典型的单独服务器(无千兆以太网,无SCI卡,存储引擎相关的限制少)慢10倍。
应用场合:
冗余,高可靠性,负载均衡
2. MySQL / GFS-GNBD/ HA (Active/Passive)
简介:
如果多个MySQL服务器使用共享硬盘作为数据存储,此方案如何?
GFS/GNBD可以提供所需的共享硬盘。
GFS是事务安全的文件系统。同一时刻你可以让一个MySQL使用共享数据。
成本:
最多n台高性能服务器的成本,其中一个激活的,其他作为备份服务器。
优点:
高可靠性
某种程度的冗余
按照高可靠性进行伸缩
缺点:
没有负载均衡
没有保证的冗余
无法对写操作进行伸缩
速度:
单独服务器的2倍。对读操作支持得较好。
应用场合:
需要高可靠性的、读操作密集型的应用
3. MySQL / DRBD / HA (Active/Passive)
简介:
如果多个MySQL服务器使用共享硬盘作为数据存储,此方案如何?
DRBD可以提供这样的共享硬盘。DRBD可以被设置成事务安全的。
同一时刻你可以让一个MySQL使用共享数据。
成本:
最多n台高性能服务器的成本,其中一个激活的,而其他则作为备份服务器。
优点:
高可靠性;
一定程度的冗余;
以高可靠性名义来看是可伸缩的。
缺点:
没有负载均衡
没有保证的冗余
在写负载方面没有伸缩性
速度:
在读写方面相当于单独服务器
应用场合
需要高可靠性、读操作密集型的应用
4. MySQL Write Master / Multiple MySQL Read Slaves (Active/Active)
简介:
考虑不同的读、写DB数据库连接的情况。可以使用一台主服务器用于写操作,而采用n台从服务器用于读操作。
成本:
最多1台高性能写服务器,n台读服务器的成本
优点:
读操作的高可靠性;
读操作的负载均衡;
在读操作负载均衡方面是可伸缩的。
缺点:
无写操作的高可靠性;
无写操作的负载均衡;
在写操作方面无伸缩性;
速度:
同单独服务器;在读操作方面支持得较好
应用场合
读操作密集型的、需要高可靠性和负载均衡的应用。
5. Standalone MySQL Servers(Functionally separated) (Active)
多台功能分离的单独服务器,没有高可靠性、负载均衡能力,明显缺点太多,不予考虑。
⑶ 基于MySQL双主的高可用解决方案理论及实践
MySQL在互联网应用中已经遍地开花,但是在银行系统中,还在生根发芽的阶段。本文记录的是根据某生产系统实际需求,对数据库高可用方案从需求、各高可用技术特点对比、实施、测试等过程进行整理,完善Mysql高可用方案,同时为后续开展分布式数据库相关测试做相应准备。
存储复制技术: 传统IOE架构下,常用高可用方案,靠存储底层复制技术实现数据的一致性,优点数据安全性有保障,限制在于是依赖存储硬件,实施成本较高。
keepalived+双主复制: 两台MySQL互为主从关系,即双主模式,通过Keepalived配置虚拟IP,实现当其中的一台数据库故障时,自动切换VIP到另外一台MySQL数据库,备机快速接管业务来保证数据库的高可用。
MHA: MHA部署在每台mysql服务器上,定时探测集群中的master节点,当master出现故障时,它可以自动将最新的slave提升为新的master,然后将所有其他的slave重新指向新的master,优点在最大程度保证数据的一致性的前提下实现快速切换,最少需要3台服务器,存在数据丢失的可能性。
PXC: Percona eXtra Cluster是Percona基于galera cluster封装的集群方案。不同于普通多主复制,PXC保障强一致性和实时同步,故障切换更快。但是也需要3个节点,配置相对复杂,对性能也稍有影响。
除了上述方案外,还有MMM、Heartbeat+DRBD等高可用方案,此处不做详细介绍。
综合评估下,本次实施采用了 keepalived+mysql双主实现数据库同城双机房的高可用。MySQL版本为: 5.7.21。操作系统:Red Hat Enterprise Linux Server 7.3。
配置过程如下:
Mysql-master1: IP地址1 --以下简称master1
Mysql-master2: IP地址2 --以下简称master2
Mysql-vip : VIP地址 --应用连接使用
Mysql复制相关概念描述:
1、 Mysql主从复制图示:
2、 Mysql主从复制过程描述:
(1)master记录二进制日志:在每个事务更新数据完成之前,master在二进制日志记录这些改变。MySQL将事务写入二进制日志。在事务写入二进制日志完成后,master通知存储引擎提交事务。
(2)slave将master的binarylog拷贝到自己的中继日志:首先,slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接,然后开始binlog mp process。Binlog mp process从master的二进制日志中读取事务,如果已经同步了master,它会睡眠并等待master产生新的事件。I/O线程将这些事务写入中继日志。
(3)SQL slave thread处理该过程的最后一步:SQL线程从中继日志读取事务,并重放其中的事务而更新slave的数据,使其与master中的数据一致。只要该线程与I/O线程保持一致,中继日志通常会位于OS的缓存中,所以中继日志的开销很小。
主主同步就是两台机器互为主的关系,在任何一台机器上写入都会同步至备端。
为了便于后续数据库服务器的扩展,且在整个复制环境中能够自动地切换,降低运维成本,引入了当前主流的基于Mysql GTID的复制特性,工作原理及优缺点简介如下。
3、 GTID工作原理简介:
(1) master更新数据时,会在事务前产生GTID,一同记录到Binlog日志中。
(2) slave的I/O线程将变更的binlog写入到本地的relay log中。
(3) slave的sql线程从relay log中获取GTID,然后对比slave端的binlog是否有记录。
(4) 如果有记录说明该GTID的事务已经执行,slave会忽略。
(5) 如果没有记录,slave就会从relay log中执行该GTID的事务,并记录到binlog。
(6) 在解析的过程中会判断是否有主键,如果有就用索引,如果没有就用全部扫描。
4、 GTID优点:
(1) 一个事务对应一个唯一的ID,一个GTID在一个服务器上 只会执行一次。(2) GTID是用来替代传统复制的方法,GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置。
(3) 减少手工干预和降低服务故障时间,当主机宕机之后会通过软件从众多的备机中提升一台备机为新的master。
5、 GTID也存在一些限制:
(1) 不支持非事务引擎。
(2) 不支持create table … select 语句复制(主库直接报错)。
(3) 不允许一个sql同时更新一个事务引擎表和非事务引擎表。
(4) 在一个复制组中,必须要求统一开启GTID或者是统一关闭GTID。
(5) 开启GTID需要重启(5.7版本除外)。
(6) 开启GTID后,就不再使用原理的传统复制方式。
(7) 不支持create temporary table 和 drop temporary table语句。
(8) 不支持sql_slave_skip_counter。
前置条件:
主备两个节点使用行内统一的安装部署脚本安装mysql5.7.21介质(略)
Master1端创建应用的数据库(略)
1、 修改MySQL配置文件
参考相关配置规范,分别设置master1、master2的my.cnf文件,
其中server-id参数设置为不同值;
由于后续keepalived会挂起VIP,应用通过VIP连接数据库,为了避免应用程序无法通过VIP访问,需将两个节点的bind-address参数注释掉;
2、 设置master1端自动半同步模式
Mysql的同步模式主要有如下3种:
a. 主从同步复制:数据完整性好,但是性能消耗略高;
b. 主从异步复制:性能消耗低,但容易出现不一致;
c. 主从半自动复制:介于上述两种之间,既保持了数据的完整性,又提高了性能;
基于上述特性,建议采用半自动同步模式,由于后续要配置为双主模式,因此任一节点其角色既为master又为slave,因此相关的master/slave插件要同时配置,过程如下。
(1) 首先查看库是否支持动态加载(默认都支持)
(2) 主从库上分别安装插件
作为主库,安装插件semisync_master.so
作为从库,安装插件semisync_slave.so
(3) 安装完成后,从plugin表中能够看到刚刚安装的插件
(4) 分别打开主从库半同步复制
同时添加到各自的my.cnf中,在后续数据库实例重启时自动加载该配置。
此时查看状态还没有启动
(5) 两个节点分别启动IO进程
(6) 查看半同步状态
3、 将master1设为master2的主服务器
(1)在master1主机上创建授权账户,允许在master2主机上连接
(2)将主库master1数据导出
(3)将master.sql传输到master2上并导入
(4)在master2端将master1设置为自己的主库,并开启slave功能
在master2上查看slave状态
至此master1到master2的主从复制关系已经建立完成。
4、 将master2设为master1的主服务器
在master1上执行
在master1上查看slave状态
1、keepalived相关概念说明:
keepalived是集群管理中保证集群高可用的一个软件解决方案,其功能类似于heartbeat,用来防止单点故障
keepalived是以VRRP协议为实现基础的,VRRP全称VirtualRouter Rendancy Protocol,即虚拟路由冗余协议。
虚拟路由冗余协议,可以认为是实现路由器高可用的协议,即将N台提供相同功能的路由器组成一个路由器组,这个组里面有一个master和多个backup,master上面有一个对外提供服务的vip,master会发组播(组播地址为224.0.0.18),当backup收不到vrrp包时就认为master宕掉了,这时就需要根据VRRP的优先级来选举一个backup当master,这样的话就可以保证路由器的高可用了。
keepalived主要有三个模块,分别是core 、check和vrrp。core模块为keepalived的核心,负责主进程的启动、维护以及全局配置文件的加载和解析。check负责 健康 检查,包括常见的各种检查方式。vrrp模块是来实现VRRP协议的。同时为了避免出现脑裂,应关闭防火墙或者开启防火墙但允许接收VRRP协议。
2、keepalived的安装配置
(1)配置本地yum源,在master1和master2两台服务器上安装keepalived的相关依赖包Kernel-devel/openssl-devel/popt-devl等
配置指向rhel-7.5.iso的yum本地源,步骤略
注意:如不知道keepalived需要哪些依赖包,可到下载后的源码解压目录下查看INSTALL 文件内容,安装需要的依赖包,源码安装任何一个软件都要养成查看源码包文档的习惯,比如INSTALL,README,doc等文档,可以获得很多有用的信息。
(2)在两台mysql上解压缩并编译安装keepalived
(3)master1、master2上分别配置keepalived.conf
注意上图红色字体中两个节点配置相同处及差异。
说明:keepalived只有一个配置文件keepalived.conf,里面主要包括以下几个配置区域:
· global_defs:主要是配置故障发生时的通知对象以及机器标识。
· vrrp_instance:用来定义对外提供服务的VIP区域及其相关属性。
· virtual_server:虚拟服务器定义
(4)同时两个节点上都需要添加检测脚本
作用:是当mysql停止工作时自动关闭本机的keeplived服务,从而实现将故障主机踢出热备组,因每台机器上keepalived只添加了本机为realserver,所以当mysqld正常启动后,我们还需要手动启动keepalived服务。
(5)分别启动两个节点的keepalived服务
检查两个节点keepalived启动进程
检查两个节点的vip挂载情况
(6)主备机故障切换测试
停止master2的mysql服务,看keepalived 健康 检查程序是否会触发脚本,自动进行故障切换,步骤略
查看master1节点的VIP挂载情况,验证是否实现了自动切换,步骤略
说明在master2服务器的mysql服务发生故障时,触发了脚本,自动完成了切换。
(7)现在我们把master2的mysql服务开起来,并且keepalived的服务也需要启动。
即便master2的mysql服务和keepalived服务都重新开启了,master1仍然是主master了,master2未对主master的权利进行抢夺,说明设置的nopreempt参数生效了,为了保证群集的稳定性,生产环境不允许抢占配置,只有当master1的mysql服务坏掉的时候,master2才会再次成为主master,否则它永远只能当master1的备份。(注:nopreempt一般是在优先级高的mysql上设置)
Sysbench是一个模块化的、跨平台、多线程基准测试工具,可用于评估数据库负载情况,通过sysbench命令配置IP地址、端口号、用户名、密码连接到指定的数据库db1中,创建多个表,并快速插入指定条数的记录,观察主备库同步效率
(1) 下载开源工具sysbench-0.4.12.14.tar.gz,放置在相应目录下并解压
(2) 使用iso配置本地yum源并安装Sysbench如下的依赖包(步骤略):autoconf/automake/cdbs/debhelper(>=9)/docbook-xml/docbook-xsl/libmysqlclient15-dev/libtool/xsltproc
(3) 编译sysbench
编辑配置文件/etc/ld.so.conf中添加mysql lib目录/mysql/app/5.7.21/lib,并执行命令ldconfig生效
(4) 执行sysbench压测
使用sysbench工具向主节点的db1数据库中创建5张表,并且每张表分别插入10万条记录
同时观察备机同步效率
几个重要的参数说明:
B、半自动同步模式、异步模式切换测试
(1) 检查主备同步状态,及同步参数设置
rpl_semi_sync_master_enabled参数表示启用半同步模式;
rpl_semi_sync_master_timeout参数单位为毫秒,表示主库事务等待从库返回commit成功信息超过10秒就降为异步模式,不再等待从库,等探测到从库io线程恢复后,再返回为半自动同步;
rpl_semi_sync_master_wait_no_slave参数表示事务提交后需要等待从库返回确认信息;
(2) 将slave的io线程停止
(3) 使用sysbench向master写入少量的数据,本例创建一张表,并插入10条记录,命令包装在1.sh测试脚本中
通过记录的时间戳发现,master在等待了slave10秒无响应,自动切换为异步模式,将数据写入本地。
(4) Slave启动io线程,数据自动追平
至此MySQL主主复制配置完成,运行在半自动同步模式,通过keepalived实现Mysql的HA高可用。
上线后应符合统一的标准监控策略,添加备份协议对数据进行周期备份并保存到带库中,以及定期的数据恢复测试。
由于是靠keepalived实现的高可用,还应将如下资源添加到监控管理平台:
1、 对每台数据库主机的3个keepalived进程进行监控;
2、 对主备节点的io线程、sql线程工作状态进行监控;
⑷ 查看mysql是否为双机
mysql双机热备实现原理分析,在本文经过深思熟虑和多次用不同的方式实测试后。最后在这篇文章中,用一个小例子来完成mysql双机热备的实现。
Mysql数据库没有增量备份的机制,当数据量太大的时候备份是一个很大的问题。还好mysql数据库提供了一种主从备份的机制,其实就是把主数据库的所有的数据同时写到备份的数据库中。实现mysql数据库的热备份。
要想实现双机的热备,首先要了解主从数据库服务器的版本的需求。要实现热备mysql的版本都高于3.2。还有一个基本的原则就是作为从数据库的数据版本可以高于主服务器数据库的版本,但是不可以低于主服务器的数据库版本。
当然要实现mysql双机热备,除了mysql本身自带的REPLICATION功能可以实现外,也可以用Heartbeat这个开源软件来实现。不过本文主要还是讲如何用mysql自带的REPLICATION来实现mysql双机热备的功能。
1. 准备服务器
由于Mysql不同版本之间的(二进制日志)binlog格式可能会不太一样,因此最好的搭配组合是主(Master)服务器的Mysql版本和从(Slave)服务器版本相同或者更低,主服务器的版本肯定不能高于从服务器版本。
本次我用于测试的两台服务器版本都是Mysql-5.5.17。
2. Mysql 建立主-从服务器双机热备配置步骤
2.1环境描述
A服务器(主服务器Master):59.151.15.36
B服务器(从服务器Slave):218.206.70.146
主从服务器的Mysql版本皆为5.5.17
Linux环境下
将主服务器需要同步的数据库内容进行备份一份,上传到从服务器上,保证始初时两服务器中数据库内容一致。
不过这里说明下,由于我是利用Mysql在安装后就有的数据库test进行测试的,所以两台服务器里面是没有建立表的,只不分别在test里面建立了同样的一张空表tb_mobile;
Sql语句如下:
mysql> create table tb_mobile( mobile VARCHAR(20) comment'手机号码', time timestamp DEFAULT now() comment'时间' );
2.2 主服务器Master配置
2.2.1 创建同步用户
进入mysql操作界面,在主服务器上为从服务器建立一个连接帐户,该帐户必须授予REPLICATION SLAVE权限。因为从mysql版本3.2以后就可以通过REPLICATION对其进行双机热备的功能操作。
操作指令如下:
mysql> grant replication slave on *.* to 'replicate'@餲.206.70.146' identified by '
mysql> flush privileges;
创建好同步连接帐户后,我们可以通过在从服务器(Slave)上用replicat帐户对主服务器(Master)数据库进行访问下,看下是否能连接成功。
在从服务器(Slave)上输入如下指令:
[root@YD146 ~]# mysql -h59.151.15.36 -ureplicate -p123456
如果出现下面的结果,则表示能登录成功,说明可以对这两台服务器进行双机热备进行操作。2.2.2 修改mysql配置文件
如果上面的准备工作做好,那边我们就可以进行对mysql配置文件进行修改了,首先找到mysql配置所有在目录,一般在安装好mysql服务后,都会将配置文件复制一一份出来放到/ect目录下面,并且配置文件命名为:my.cnf。即配置文件准确目录为/etc/my.cnf
(Linux下用rpm包安装的MySQL是不会安装/etc/my.cnf文件的,
至于为什么没有这个文件而MySQL却也能正常启动和作用,在点有两个说法,
第一种说法,my.cnf只是MySQL启动时的一个参数文件,可以没有它,这时MySQL会用内置的默认参数启动,
第二种说法,MySQL在启动时自动使用/usr/share/mysql目录下的my-medium.cnf文件,这种说法仅限于rpm包安装的MySQL,
解决方法,只需要复制一个/usr/share/mysql目录下的my-medium.cnf文件到/etc目录,并改名为my.cnf即可。)
找到配置文件my.cnf打开后,在[mysqld]下修改即可:
[mysqld]
server-id = 1
log-bin=mysql-bin //其中这两行是本来就有的,可以不用动,添加下面两行即可
binlog-do-db = test
binlog-ignore-db = mysql
2.2.3 重启mysql服务
修改完配置文件后,保存后,重启一下mysql服务,如果成功则没问题。2.2.4 查看主服务器状态
进入mysql服务后,可通过指令查看Master状态,输入如下指令:注意看里面的参数,特别前面两个File和Position,在从服务器(Slave)配置主从关系会有用到的。
注:这里使用了锁表,目的是为了产生环境中不让进新的数据,好让从服务器定位同步位置,初次同步完成后,记得解锁。2.3 从服务器Slave配置
2.3.1修改配置文件
因为这里面是以主-从方式实现mysql双机热备的,所以在从服务器就不用在建立同步帐户了,直接打开配置文件my.cnf进行修改即可,道理还是同修改主服务器上的一样,只不过需要修改的参数不一样而已。如下:
[mysqld]
server-id = 2
log-bin=mysql-bin
replicate-do-db = test
replicate-ignore-db = mysql,information_schema,performance_schema
2.3.2重启mysql服务
修改完配置文件后,保存后,重启一下mysql服务,如果成功则没问题。2.3.3用change mster 语句指定同步位置
这步是最关键的一步了,在进入mysql操作界面后,输入如下指令:
mysql>stop slave; //先停步slave服务线程,这个是很重要的,如果不这样做会造成以下操作不成功。
mysql>change master to
>master_host=ཷ.151.15.36',master_user='replicate',master_password=',
> master_log_file=' mysql-bin.000016 ',master_log_pos=107;
注:master_log_file, master_log_pos由主服务器(Master)查出的状态值中确定。也就是刚刚叫注意的。master_log_file对应File, master_log_pos对应Position。Mysql 5.x以上版本已经不支持在配置文件中指定主服务器相关选项。
遇到的问题,如果按上面步骤之后还出现如下情况:则要重新设置slave。指令如下
mysql>stop slave;
mysql>reset slave;
之后停止slave线程重新开始。成功后,则可以开启slave线程了。
mysql>start slave;
2.3.4查看从服务器(Slave)状态
用如下指令进行查看
mysql> show slave statusG;查看下面两项值均为Yes,即表示设置从服务器成功。
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
2.4 测试同步
之前开始已经说过了在数据库test只有一个表tb_mobile没有数据,我们可以先查看下两服务器的数据库是否有数据:
Master:59.151.15.36Slave:218.206.70.146好了,现在可以在Master服务器中插入数据看下是否能同步。
Master:59.151.15.36Slave:218.206.70.146可以从上面两个截图上看出,在Master服务器上进行插入的数据在Slave服务器可以查到,这就表示双机热备配置成功了。
3. Mysql 建立主-主服务器双机热备配置步骤
服务器还是用回现在这两台服务器
3.1创建同步用户
同时在主从服务器建立一个连接帐户,该帐户必须授予REPLIATION SLAVE权限。这里因为服务器A和服务器B互为主从,所以都要分别建立一个同步用户。
服务器A:
mysql> grant replication slave on *.* to 'replicate'@餲.206.70.146' identified by '
mysql> flush privileges;
服务器B:
mysql> grant replication slave on *.* to 'replicate'@ཷ.151.15.36' identified by '
mysql> flush privileges;
3.2修改配置文件my.cnf
服务器A
[mysqld]
server-id = 1
log-bin=mysql-bin
binlog-do-db = test
binlog-ignore-db = mysql
#主-主形式需要多添加的部分
log-slave-updates
sync_binlog = 1
auto_increment_offset = 1
auto_increment_increment = 2
replicate-do-db = test
replicate-ignore-db = mysql,information_schema
服务器B:
[mysqld]
server-id = 2
log-bin=mysql-bin
master-slave need
replicate-do-db = test
replicate-ignore-db = mysql,information_schema,performance_schema
#主-主形式需要多添加的部分
binlog-do-db = test
binlog-ignore-db = mysql
log-slave-updates
sync_binlog = 1
auto_increment_offset = 2
auto_increment_increment = 2
3.3分别重启A服务器和B服务器上的mysql服务
重启服务器方式和上面的一样,这里就不做讲解了。
3.4分别查A服务器和B服务器作为主服务器的状态
服务器A:
服务器B:3.5分别在A服务器和B服务器上用change master to 指定同步位置
服务器A:
mysql>change master to
>master_host=餲.206.70.146',master_user='replicate',master_password=',
> master_log_file=' mysql-bin.000011 ',master_log_pos=497;
服务器B:
mysql>change master to
>master_host=ཷ.151.15.36',master_user='replicate',master_password=',
> master_log_file=' mysql-bin.000016 ',master_log_pos=107;
3.6 分别在A和B服务器上重启从服务线程
mysql>start slave;
3.7 分别在A和B服务器上查看从服务器状态
mysql>show slave statusG;
查看下面两项值均为Yes,即表示设置从服务器成功。
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
3.8 测试主-主同步例子
测试服务器A:
在服务器A上插入一条语句如下图所示:
之后在服务器B上查看是否同步如下图所示:
测试服务器B:
在服务器B上插入一条语句如下图所示:然后在从服务器A上查看是否有同步数据如下图所示:最后从结果可以看出主-主形式的双机热备是能成功实现的。
4. 配置参数说明
Server-id
ID值唯一的标识了复制群集中的主从服务器,因此它们必须各不相同。Master_id必须为1到232-1之间的一个正整数值,slave_id值必须为2到232-1之间的一个正整数值。
Log-bin
表示打开binlog,打开该选项才可以通过I/O写到Slave的relay-log,也是可以进行replication的前提。
Binlog-do-db
表示需要记录二进制日志的数据库。如果有多个数据可以用逗号分隔,或者使用多个binlog-do-dg选项。
Binglog-ingore-db
表示不需要记录二进制日志的数据库,如果有多个数据库可用逗号分隔,或者使用多binglog-ignore-db选项。
Replicate-do-db
表示需要同步的数据库,如果有多个数据可用逗号分隔,或者使用多个replicate-do-db选项。
Replicate-ignore-db
表示不需要同步的数据库,如果有多个数据库可用逗号分隔,或者使用多个replicate-ignore-db选项。
Master-connect-retry
master-connect-retry=n表示从服务器与主服务器的连接没有成功,则等待n秒(s)后再进行管理方式(默认设置是60s)。如果从服务器存在mater.info文件,它将忽略些选项。
Log-slave-updates
配置从库上的更新操作是否写入二进制文件,如果这台从库,还要做其他从库的主库,那么就需要打这个参数,以便从库的从库能够进行日志同步。
Slave-skip-errors
在复制过程,由于各种原因导致binglo中的sql出错,默认情况下,从库会停止复制,要用户介入。可以设置slave-skip-errors来定义错误号,如果复制过程中遇到的错误是定义的错误号,便可以路过。如果从库是用来做备份,设置这个参数会存在数据不一致,不要使用。如果是分担主库的查询压力,可以考虑。
Sync_binlog=1 Or N
Sync_binlog的默认值是0,这种模式下,MySQL不会同步到磁盘中去。这样的话,Mysql依赖操作系统来刷新二进制日志binary log,就像操作系统刷新其他文件的机制一样。因此如果操作系统或机器(不仅仅是Mysql服务器)崩溃,有可能binlog中最后的语句丢失了。要想防止这种情况,可以使用sync_binlog全局变量,使binlog在每N次binlog写入后与硬盘同步。当sync_binlog变量设置为1是最安全的,因为在crash崩溃的情况下,你的二进制日志binary log只有可能丢失最多一个语句或者一个事务。但是,这也是最慢的一种方式(除非磁盘有使用带蓄电池后备电源的缓存cache,使得同步到磁盘的操作非常快)。
即使sync_binlog设置为1,出现崩溃时,也有可能表内容和binlog内容之间存在不一致性。如果使用InnoDB表,Mysql服务器处理COMMIT语句,它将整个事务写入binlog并将事务提交到InnoDB中。如果在两次操作之间出现崩溃,重启时,事务被InnoDB回滚,但仍然存在binlog中。可以用-innodb-safe-binlog选项来增加InnoDB表内容和binlog之间的一致性。(注释:在Mysql 5.1版本中不需要-innodb-safe-binlog;由于引入了XA事务支持,该选项作废了),该选项可以提供更大程度的安全,使每个事务的binlog(sync_binlog=1)和(默认情况为真)InnoDB日志与硬盘同步,该选项的效果是崩溃后重启时,在滚回事务后,Mysql服务器从binlog剪切回滚的InnoDB事务。这样可以确保binlog反馈InnoDB表的确切数据等,并使从服务器保持与主服务器保持同步(不接收回滚的语句)。
Auto_increment_offset和Auto_increment_increment
Auto_increment_increment和auto_increment_offset用于主-主服务器(master-to-master)复制,并可以用来控制AUTO_INCREMENT列的操作。两个变量均可以设置为全局或局部变量,并且假定每个值都可以为1到65,535之间的整数值。将其中一个变量设置为0会使该变量为1。
这两个变量影响AUTO_INCREMENT列的方式:auto_increment_increment控制列中的值的增量值,auto_increment_offset确定AUTO_INCREMENT列值的起点。
如果auto_increment_offset的值大于auto_increment_increment的值,则auto_increment_offset的值被忽略。例如:表内已有一些数据,就会用现在已有的最大自增值做为初始值。
⑸ mysql为什么能用nfs作为共享存储
还是先上规划图
1.首先进行资源的分析
1)Vip
2)Mysqld
3)Nfs
理清他们之间的启动先后顺序:nfs必须在Mysqld前启动
2.nfs的配置
Nfs共享目录上挂载的分区,最好做成lvm,实现自动扩展
2.1.安装
#yum-yinstallnfs-utils
2.2配置
#mkdir/share
#vim/etc/exports
172.16.98.3:/share172.16.98.1(rw,no_root_squash)172.16.98.2(rw,no_root_squash)
#servicenfsstart
#groupadd-g186mysql
#useradd-u186-gmysql-s/sbin/nologin-Mmysql
#chownmysql:mysql/share
3.Mysql1结合nfs的安装测试
3.1挂载nfs
#mkdir/data
#chownmysql:mysql/data
#mount172.16.98.3:/share/data
3.2使用mysql的解压缩包安装
#groupadd-g186mysql
#useradd-u186-gmysql-s/sbin/nologin-Mmysql
*在三台机器上,创建的mysql组和用户的uid、gid要保持一致
#tarxfmysql-5.5.24-linux2.6-i686.tar.gz-C/usr/local
#cd/usr/local
#ln-smysql-5.5.24-linux2.6-i686mysql
#cdmysql
#chown-Rmysql:mysql.
#scripts/mysql_install_db--user=mysql--datadir=/data
#chowm-Rroot.
#cpsupport-files/my-large.cnf/etc/my.cnf
#cpcpsupport-files/mysql.server/etc/rc.d/init.d/mysqld
#chmod+x/etc/rc.d/init.d/mysqld
#vim/etc/profile
PATH=$PATH:/usr/local/mysql/bin
#exportPATH=$PATH:/usr/local/mysql/bin
3.3编辑配置文件,启动服务
#vim/etc/my.cnf
[mysqld]
thread_concurrency=2
datadir=/data
#servicemysqldstart
3.4另一台mysql的安装
参考前面的步骤
需要说明一点的是
Mysql的安装,这里不需要再初始化mysql
##tarxfmysql-5.5.24-linux2.6-i686.tar.gz-C/usr/local
#cd/usr/local
#ln-smysql-5.5.24-linux2.6-i686mysql
#cdmysql
#chowm-Rroot.
#cpsupport-files/my-large.cnf/etc/my.cnf
#cpcpsupport-files/mysql.server/etc/rc.d/init.d/mysqld
#chmod+x/etc/rc.d/init.d/mysqld
#vim/etc/profile
PATH=$PATH:/usr/local/mysql/bin
#exportPATH=$PATH:/usr/local/mysql/bin
#servicemysqldstart
#cd/data
#
3.5停止所有资源
1)关闭mysql服务
2)将nfs共享目录卸载
4.Corosync的安装
前期准备
1)ssh双机互信,方便配置
2)时间保持一致
3)/etc/hosts,主机名设置,互相解析
4.1corosync的安装,两台都安装上
##yuminstall-ycluster-glue-1.0.6-1.6.el5.i386.rpmcluster-glue-libs-1.0.6-1.6.el5.i386.rpmcorosynclib-1.2.7-1.1.el5.i386.rpmcorosync-1.2.7-1.1.el5.i386.rpmheartbeat-3.0.3-2.3.el5.i386.rpmheartbeat-libs-3.0.3-2.3.el5.i386.rpmlibesmtp-1.0.4-5.el5.i386.rpmpacemaker-cts-1.1.5-1.1.el5.i386.rpmpacemaker-libs-1.1.5-1.1.el5.i386.rpmpacemaker-1.1.5-1.1.el5.i386.rpmperl-TimeDate-1.16-5.el5.noarch.rpmresource-agents-1.0.4-1.1.el5.i386.rpm
4.2corosync的配置
1)mysql1
#cd/etc/corosync
#cpcorosync.conf.examplecorosync.conf
#vimcorosync.conf
compatibility:whitetank
totem{
version:2
secauth:on开启身份验证
threads:0
interface{
ringnumber:0
bindnetaddr:172.16.0.0
mcastaddr:226.94.1.1
mcastport:5405
}
}
logging{
fileline:off
to_stderr:on
to_logfile:yes
#to_syslog:yes
logfile:/var/log/cluster/corosync.log
debug:off
timestamp:on
logger_subsys{
subsys:AMF
debug:off
}
}
amf{
mode:disabled
}
service{
ver:0
name:pacemaker
}
#corosync-keygen创建authkeys
#scpauthkeyscorosync.confnode2:/etc/corosync
两台mysql上分别创建用于日志的目录
#mkdir/var/log/cluster
4.3通过mysql1开启corosync,配置资源
1)开启
#servicecorosyncstart
#sshnode2'servicecorosyncstart'
#crm_mon
============
Lastupdated:ThuAug922:12:222012
Stack:openais
CurrentDC:node1.7ing.com-partitionwithquorum
Version:1.1.5-1.1.el5-
2Nodesconfigured,2expectedvotes
0Resourcesconfigured.
============
Online:[node2.7ing.comnode1.7ing.com]
2)资源的配置
#crm
crm(live)#configure
crm(live)configure#primitivevipocf:heartbeat:IPaddrparamsip=172.16.99.1
crm(live)configure#primitivemysqldlsb:mysqld
crm(live)configure#primitivenfsocf:heartbeat:Filesystemparamsdevice=172.16.98.3:/sharedirectory=/datafstype=nfsopstarttimeout=60opstoptimeout=60
*定义nfs资源,默认的超时时间是20s,是小于建议的时间60s的,所以手动配置
crm(live)configure#colocationvip_mysqld_nfsinf:mysqldnfsvip
crm(live)configure#ordermysqld_after_nfsinf:nfsmysqld
crm(live)configure#propertystonith-enabled=false
crm(live)configure#propertyno-quorum-policy=ignore
crm(live)configure#verify
crm(live)configure#commit
3)检测
#crm_mon
Lastupdated:ThuAug922:34:522012
Stack:openais
CurrentDC:node1.7ing.com-partitionwithquorum
Version:1.1.5-1.1.el5-
2Nodesconfigured,2expectedvotes
3Resourcesconfigured.
============
Online:[node2.7ing.comnode1.7ing.com]
nfs(ocf::heartbeat:Filesystem):Startednode1.7ing.com
vip(ocf::heartbeat:IPaddr):Startednode1.7ing.com
mysqld(lsb:mysqld):Startednode1.7ing.com
#crmnodestandy
#crm_mon
============
Lastupdated:ThuAug922:36:182012
Stack:openais
CurrentDC:node1.7ing.com-partitionwithquorum
Version:1.1.5-1.1.el5-
2Nodesconfigured,2expectedvotes
3Resourcesconfigured.
============
Nodenode1.7ing.com:standby
Online:[node2.7ing.com]
nfs(ocf::heartbeat:Filesystem):Startednode2.7ing.com
vip(ocf::heartbeat:IPaddr):Startednode2.7ing.com
mysqld(lsb:mysqld):Startednode2.7ing.com