drbd编译安装

㈠ 怎么在linux上内核启动drbd模块

linux下编译运行驱动嵌入式linux下设备驱动的运行和linux x86 pc下运行设备驱动是类似的，由于手头没有嵌入式linux设备，先在vmware上的linux上学习驱动开发。
按照如下方法就可以成功编译出hello world模块驱动。
1、首先确定本机linux版本
怎么查看Linux的内核kernel版本?
'uname'是Linux/unix系统中用来查看系统信息的命令，适用于所有Linux发行版。配合使用'uname'参数可以查看当前服务器内核运行的各个状态。

㈡ heartbeat在rhel5上安装包与安装基本步骤

这个啊，用Grub安装。不过ISO文件必须放在FAT32的分区。
详细补充说明：首先下载RHEL5的5块CD盘或1块DVD盘，把它们放到一个FAT32的分区根目录里，再下载个GRUB4DOS，装好GRUB4DOS后，在menu.lst文件里添加下面代码：
title install RHEL5
root (hd0,0)
kernel /vmlinuz
initrd /initrd.img
并在RHEL5的第一块CD盘或DVD盘里提取出一个名为boot.iso的文件，将这个文件里的vmlinuz和initrd.img提取出放到C盘目录里，C盘格式可以是NTFS也可以是FAT32。（注意，vmlinuz和initrd.img这两个文件只能从那个boot.iso文件中提取出来，其他文件夹内的无法启动硬盘安装）重启电脑，进去GRUB选单，里面选择“install RHEL5”就可以启动安装程序了。
多说的话：不建议安装RHEL5，安装要序列号，并且只能试用30天，官方也不提供更新，因为这个系统是要钱DI。你可以安装CENTOS5，这个本质和RHEL5是一样的，是RHEL5的二次开发版本，其实就是下载了RHEL5的源代码重新编译生成的LINUX发行版，但是CENTOS5是免费，并且也提供更新，我也装过，稳定性还不错要比Fedora 7稳定多了。但是硬盘安装CENTOS5只能下载6CD版本，它的DVD版本无法硬盘安装，而且存在很多安装问题。

㈢ 数据库如何优化

body{
line-height:200%;
}
如何优化Mysql数据库
当MySQL数据库邂逅优化，它有好几个意思，今天我们所指的是性能优化。
我们究竟该如何对MySQL数据库进行优化呢？下面我就从MySQL对硬件的选择、Mysql的安装、my.cnf的优化、MySQL如何进行架构设计及数据切分等方面来说明这个问题。
1.服务器物理硬件的优化
1)磁盘(I/O)，MySQL每一秒钟都在进行大量、复杂的查询操作，对磁盘的读写量可想而知，所以推荐使用RAID1+0磁盘阵列，如果资金允许，可以选择固态硬盘做RAID1+0；
2)cpu对Mysql的影响也是不容忽视的，建议选择运算能力强悍的CPU。
2.MySQL应该采用编译安装的方式
MySQL数据库的线上环境安装，我建议采取编译安装，这样性能会较大的提升。
3.MySQL配置文件的优化
1)skip
-name
-resolve，禁止MySQL对外部连接进行DNS解析，使用这一选项可以消除MySQL进行DNS解析的时间；
2)back_log
=
384，back_log指出在MySQL暂时停止响应新请求之前，短时间内的多少个请求可以被存在堆栈中，对于Linux系统而言，推荐设置小于512的整数。
3)如果key_reads太大，则应该把my.cnf中key_buffer_size变大，保持key_reads/key_read_requests至少在1/100以上，越小越好。
4.MySQL上线后根据status状态进行适当优化
1)打开慢查询日志可能会对系统性能有一点点影响，如果你的MySQL是主-从结构，可以考虑打开其中一台从服务器的慢查询日志，这样既可以监控慢查询，对系统性能影响也会很小。
2)MySQL服务器过去的最大连接数是245，没有达到服务器连接数的上限256，应该不会出现1040错误。比较理想的设置是：Max_used_connections/max_connections
*
100%
=85%
5.MySQL数据库的可扩展架构方案
1)MySQL
cluster，其特点为可用性非常高，性能非常好，但它的维护非常复杂，存在部分Bug;
2)DRBD磁盘网络镜像方案，其特点为软件功能强大，数据可在底层块设备级别跨物理主机镜像，且可根据性能和可靠性要求配置不同级别的同步。

㈣ ubuntu14.04 怎么编译安装drbd

apt-get install build-essential 安装编译环境， apt-get install linux-source 安装源码 cd /usr/src tar xvjf linux-source-2.6.24.tar.bz2 cd linux-srouce-2.6.24 下面就可以按照一般的方式编译了

㈤ 怎样给访问量过大的mysql数据库减压

单机MySQL数据库的优化
一、服务器硬件对MySQL性能的影响

①磁盘寻道能力（磁盘I/O），我们现在上的都是SAS15000转的硬盘。MySQL每秒钟都在进行大量、复杂的查询操作，对磁盘的读写量可想而知。
所以，通常认为磁盘I/O是制约MySQL性能的最大因素之一，对于日均访
问量在100万PV以上的Discuz!论坛，由于磁盘I/O的制约，MySQL的性能会非常低下！解决这一制约因素可以考虑以下几种解决方案：
使用RAID1+0磁盘阵列，注意不要尝试使用RAID-5，MySQL在RAID-5磁盘阵列上的效率不会像你期待的那样快。
②CPU 对于MySQL应用，推荐使用DELL R710，E5620 @2.40GHz（4 core）* 2 ，我现在比较喜欢DELL R710，也在用其作Linuxakg 虚拟化应用；
③物理内存对于一台使用MySQL的Database Server来说，服务器内存建议不要小于2GB，推荐使用4GB以上的物理内存，不过内存对于现在的服务器而言可以说是一个可以忽略的问题，工作中遇到高端服务器基本上内存都超过了32G。
我们工作中用得比较多的数据库服务器是HP DL580G5和DELL R710，稳定性和性能都不错；特别是DELL R710，我发现许多同行都是采用它作数据库的服务器，所以重点推荐下。

二、MySQL的线上安装我建议采取编译安装的方法，这样性能上有较大提升，服务器系统我建议用64bit的Centos5.5，源码包的编译参数会默
认以Debgu模式生成二进制代码，而Debug模式给MySQL带来的性能损失是比较大的，所以当我们编译准备安装的产品代码时，一定不要忘记使用“—
without-debug”参数禁用Debug模式。而如果把—with-mysqld-ldflags和—with-client-ldflags二
个编译参数设置为—all-static的话，可以告诉编译器以静态方式编译和编译结果代码得到最高的性能。使用静态编译和使用动态编译的代码相比，性能
差距可能会达到5%至10%之多。我参考了简朝阳先生的编译参数，特列如下，供大家参考
./configure
–prefix=/usr/local/mysql –without-debug –without-bench
–enable-thread-safe-client –enable-assembler –enable-profiling
–with-mysqld-ldflags=-all-static –with-client-ldflags=-all-static
–with-charset=latin1 –with-extra-charset=utf8,gbk –with-innodb
–with-csv-storage-engine –with-federated-storage-engine
–with-mysqld-user=mysql –without-我是怎么了ded-server
–with-server-suffix=-community
–with-unix-socket-path=/usr/local/mysql/sock/mysql.sock
三、MySQL自身因素当解决了上述服务器硬件制约因素后，让我们看看MySQL自身的优化是如何操作的。对 MySQL自身的优化主要是对其配置文件my.cnf中的各项参数进行优化调整。下面我们介绍一些对性能影响较大的参数。
下面，我们根据以上硬件配置结合一份已经优化好的my.cnf进行说明：
#vim /etc/my.cnf
以下只列出my.cnf文件中[mysqld]段落中的内容，其他段落内容对MySQL运行性能影响甚微，因而姑且忽略。
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
skip-locking
#避免MySQL的外部锁定，减少出错几率增强稳定性。
skip-name-resolve
#禁止MySQL对外部连接进行DNS解析，使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意，如果开启该选项，则所有远程主机连接授权都要使用IP地址方式，否则MySQL将无法正常处理连接请求！
back_log = 384

#back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。
如果系统在一个短时间内有很多连接，则需要增大该参数的值，该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自
己的限制。 试图设定back_log高于你的操作系统的限制将是无效的。默认值为50。对于Linux系统推荐设置为小于512的整数。
key_buffer_size = 384M
#key_buffer_size指定用于索引的缓冲区大小，增加它可得到更好的索引处理性能。对于内存在4GB左右的服务器该参数可设置为256M或384M。注意：该参数值设置的过大反而会是服务器整体效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 614K
sort_buffer_size = 6M
#查询排序时所能使用的缓冲区大小。注意：该参数对应的分配内存是每连接独占，如果有100个连接，那么实际分配的总共排序缓冲区大小为100 × 6 ＝ 600MB。所以，对于内存在4GB左右的服务器推荐设置为6-8M。
read_buffer_size = 4M
#读查询操作所能使用的缓冲区大小。和sort_buffer_size一样，该参数对应的分配内存也是每连接独享。
join_buffer_size = 8M
#联合查询操作所能使用的缓冲区大小，和sort_buffer_size一样，该参数对应的分配内存也是每连接独享。
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M

#指定MySQL查询缓冲区的大小。可以通过在MySQL控制台观察，如果Qcache_lowmem_prunes的值非常大，则表明经常出现缓冲不
够
的情况；如果Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，如果该值较小反而会影响效率，那么可以考虑不用查询缓
冲；Qcache_free_blocks，如果该值非常大，则表明缓冲区中碎片很多。
tmp_table_size = 256M
max_connections = 768
#指定MySQL允许的最大连接进程数。如果在访问论坛时经常出现Too Many Connections的错误提 示，则需要增大该参数值。
max_connect_errors = 1000
wait_timeout = 10
#指定一个请求的最大连接时间，对于4GB左右内存的服务器可以设置为5-10。
thread_concurrency = 8
#该参数取值为服务器逻辑CPU数量*2，在本例中，服务器有2颗物理CPU，而每颗物理CPU又支持H.T超线程，所以实际取值为4*2=8；这个目前也是双四核主流服务器配置。
skip-networking
#开启该选项可以彻底关闭MySQL的TCP/IP连接方式，如果WEB服务器是以远程连接的方式访问MySQL数据库服务器则不要开启该选项！否则将无法正常连接！
table_cache=1024
#物理内存越大，设置就越大。默认为2402,调到512-1024最佳
innodb_additional_mem_pool_size=4M
#默认为2M
innodb_flush_log_at_trx_commit=1
#设置为0就是等到innodb_log_buffer_size列队满后再统一储存，默认为1
innodb_log_buffer_size=2M
#默认为1M
innodb_thread_concurrency=8
#你的服务器CPU有几个就设置为几，建议用默认一般为8
key_buffer_size=256M
#默认为218，调到128最佳
tmp_table_size=64M
#默认为16M，调到64-256最挂
read_buffer_size=4M
#默认为64K
read_rnd_buffer_size=16M
#默认为256K
sort_buffer_size=32M
#默认为256K
thread_cache_size=120
#默认为60
query_cache_size=32M
※值得注意的是：
很多情况需要具体情况具体分析
一、如果Key_reads太大，则应该把my.cnf中Key_buffer_size变大，保持Key_reads/Key_read_requests至少1/100以上，越小越好。
二、如果Qcache_lowmem_prunes很大，就要增加Query_cache_size的值。

很多时候我们发现，通过参数设置进行性能优化所带来的性能提升，可能并不如许多人想象的那样产生质的飞跃，除非是之前的设置存在严重不合理的情况。我们
不能将性能调优完全依托于通过DBA在数据库上线后进行的参数调整，而应该在系统设计和开发阶段就尽可能减少性能问题。
【51CTO独家特稿】如果单MySQL的优化始终还是顶不住压力时，这个时候我们就必须考虑MySQL的高可用架构（很多同学也爱说成是MySQL集群）了，目前可行的方案有：
一、MySQL Cluster
优势：可用性非常高，性能非常好。每份数据至少可在不同主机存一份拷贝，且冗余数据拷贝实时同步。但它的维护非常复杂，存在部分Bug，目前还不适合比较核心的线上系统，所以这个我不推荐。
二、DRBD磁盘网络镜像方案

优势：软件功能强大，数据可在底层快设备级别跨物理主机镜像，且可根据性能和可靠性要求配置不同级别的同步。IO操作保持顺序，可满足数据库对数据一致
性的苛刻要求。但非分布式文件系统环境无法支持镜像数据同时可见，性能和可靠性两者相互矛盾，无法适用于性能和可靠性要求都比较苛刻的环境，维护成本高于
MySQL Replication。另外，DRBD也是官方推荐的可用于MySQL高可用方案之一，所以这个大家可根据实际环境来考虑是否部署。
三、MySQL Replication

在实际应用场景中，MySQL
Replication是使用最为广泛的一种提高系统扩展性的设计手段。众多的MySQL使用者通过Replication功能提升系统的扩展性后，通过
简单的增加价格低廉的硬件设备成倍
甚至成数量级地提高了原有系统的性能，是广大MySQL中低端使用者非常喜欢的功能之一，也是许多MySQL使用者选择MySQL最为重要的原因。
比较常规的MySQL Replication架构也有好几种，这里分别简单说明下
MySQL Replication架构一：常规复制架构--Master-slaves，是由一个Master复制到一个或多个Salve的架构模式，主要用于读压力大的应用数据库端廉价扩展解决方案，读写分离，Master主要负责写方面的压力。
MySQL Replication架构二：级联复制架构，即Master-Slaves-Slaves,这个也是为了防止Slaves的读压力过大，而配置一层二级 Slaves，很容易解决Master端因为附属slave太多而成为瓶劲的风险。
MySQL Replication架构三：Dual Master与级联复制结合架构，即Master-Master-Slaves，最大的好处是既可以避免主Master的写操作受到Slave集群的复制带来的影响，而且保证了主Master的单点故障。
以上就是比较常见的MySQL replication架构方案，大家可根据自己公司的具体环境来设计 ，Mysql 负载均衡可考虑用LVS或Haproxy来做，高可用HA软件我推荐Heartbeat。

MySQL
Replication的不足：如果Master主机硬件故障无法恢复，则可能造成部分未传送到slave端的数据丢失。所以大家应该根据自己目前的网络
规划，选择自己合理的Mysql架构方案，跟自己的MySQL
DBA和程序员多沟涌，多备份（备份我至少会做到本地和异地双备份），多测试，数据的事是最大的事，出不得半点差错

㈥ 如何编译drbd

（一）DRBD的编译安装
1、DRBD软件包的获取
[root@www tmp]# wget http://oss.linbit.com/drbd/8.3/drbd-8.3.10.tar.gz
2、DRBD的编译
解压：
[root@www tmp]# tar -zxvf drbd-8.3.10.tar.gz
进入：
[root@www tmp]# cd drbd-8.3.10
编译：
[root@www drbd-8.3.10]# ./configure –prefix=/ –with-km
[root@www drbd-8.3.10]# make
3、DRBD的安装
[root@www drbd-8.3.10]# make install
4、查看安装是否成功
[root@www drbd-8.3.10]# drbdadm
USAGE: drbdadm [OPTION...] [-- DRBDSETUP-OPTION...] COMMAND {all|RESOURCE…}
OPTIONS:
{–stacked|-S}
{–dry-run|-d}
{–verbose|-v}
{–config-file|-c} val
{–config-to-test|-t} val
{–drbdsetup|-s} val
{–drbdmeta|-m} val
{–drbd-proxy-ctl|-p} val
{–sh-varname|-n} val
{–force|-f}
{–peer|-P} val
{–version|-V}
COMMANDS:
attach detach
connect disconnect
up down
primary secondary
invalidate invalidate-remote
outdate resize
syncer verify
pause-sync resume-sync
adjust wait-connect
wait-con-int role
cstate dstate
mp mp-xml
create-md show-gi
get-gi mp-md
wipe-md hidden-commands
Version: 8.3.10 (api:88)
GIT-hash: build by [email protected], 2011-04-26 10:47:49
missing arguments

参考：http://blog.chinaunix.net/uid-24020646-id-2942207.html

㈦ 基于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线程工作状态进行监控；