mysql+heartbeat双主高可用

wKiom1NY95PxdZryAABkZkymrM8614.png

说明:1,平时对外提供vip让用户写
     2,两台主的互为主从,都有二进制日志和中继日志
     3,平时只有有vip的主的写,另一台主的只读
     4,主从复制时,一半从的指向一台主的
     5,当有vip的主的下线时,另一台主的把vip抢过来,继续提供写

优点:1,保证了一定程度的高可用
     2,分担了主从复制时,主服务器的压力
     3,虽然是双主,但是由于一直只有一台提供写,所以一般不会出现数据不一致
     4,解决drbd高可用时,另一台主的只能干备着,不能读也不能写

     5, 没有自动增长的问题

缺点:1,由于有一半的从服务器指向了一台主的,所以当一台主的下线时
        有一半的从服务器得不到最新的数据()

以上都是个人见解,如有错误。。

关于mysql主从复制:
MySQL使用3个线程来执行复制功能(其中1个在主服务器上,另两个在从服务器上。当发出start slave时,
从服务器创建一个i/o线程,以连接主服务器并让它发送记录在其二进制日志中的语句。主服务器创建一个线
程将二进制日志中的内容发送到从服务器。该线程可以识别为主服务器上show processlist的输出中
的binlog dump线程。从服务器i/o线程读取主服务器binlog dump线程发送的内容并将该数据拷贝到从服务器
数据目录中的本地文件中,即中继日志。第3个线程是sql线程,是从服务器创建用于读取中继日志并执行日
志中包含的更新。
show processlist语句可以提供在主服务器上和从服务器上发生的关于复制的信息

MySQL 的复制可以是基于一条语句(Statement Level),也可以是基于一条记录(Row
level),可以在 MySQL 的配置参数中设定这个复制级别,不同复制级别的设置会影响到
Master 端的 Binary Log 记录成不同的形式。
1.
Row Level:Binary Log 中会记录成每一行数据被修改的形式,然后在 Slave 端
再对相同的数据进行修改。
优点:在 Row Level 模式下,Binary Log 中可以不记录执行的 sql 语句的上下文相关
的信息,仅仅只需要记录那一条记录被修改了,修改成什么样了。所以 Row Level 的日志
内容会非常清楚的记录下每一行数据修改的细节,非常容易理解。而且不会出现某些特定情
况下的存储过程,或 function,以及 trigger 的调用和触发无法被正确复制的问题。
缺点:Row Level 下,所有的执行的语句当记录到 Binary Log 中的时候,都将以每行
记录的修改来记录,这样可能会产生大量的日志内容,比如有这样一条 update 语句:UPDATE
group_message SET group_id = 1 where group_id = 2,执行之后,日志中记录的不是这
条 update 语句所对应的事件(MySQL 以事件的形式来记录 Binary Log 日志),而是这条
语句所更新的每一条记录的变化情况,这样就记录成很多条记录被更新的很多个事件。自然 ,
Binary Log 日志的量就会很大。尤其是当执行 ALTER TABLE 之类的语句的时候,产生的日
志量是惊人的。因为 MySQL 对于 ALTER TABLE 之类的 DDL 变更语句的处理方式是重建整个
表的所有数据,也就是说表中的每一条记录都需要变动,那么该表的每一条记录都会被记录
到日志中。
2.
Statement Level:每一条会修改数据的 Query 都会记录到 Master 的 Binary
Log 中。Slave 在复制的时候 SQL 线程会解析成和原来 Master 端执行过的相同的 Query
来再次执行。
优点:Statement Level 下的优点首先就是解决了 Row Level 下的缺点,不需要记录每
一行数据的变化,减少 Binary Log 日志量,节约了 IO 成本,提高了性能。因为他只需要
记录在 Master 上所执行的语句的细节,以及执行语句时候的上下文的信息。
缺点:由于他是记录的执行语句,所以,为了让这些语句在 slave 端也能正确执行,那
么他还必须记录每条语句在执行的时候的一些相关信息,也就是上下文信息,以保证所有语
句在 slave 端杯执行的时候能够得到和在 master 端执行时候相同的结果。另外就是,由于
Mysql 现在发展比较快,很多的新功能不断的加入,使 mysql 得复制遇到了不小的挑战,自
然复制的时候涉及到越复杂的内容,bug 也就越容易出现。在 statement level 下,目前已
经发现的就有不少情况会造成 mysql 的复制出现问题,主要是修改数据的时候使用了某些特
定的函数或者功能的时候会出现,比如:sleep()函数在有些版本中就不能真确复制,在存
储过程中使用了 last_insert_id()函数,可能会使 slave 和 master 上得到不一致的 id 等
等。由于 row level 是基于每一行来记录的变化,所以不会出现类似的问题。

3,还有一种是混合模式(mixed),即让mysql自己判断语句应该怎么记录

这个参数就是配置文件的:binlog_format=mixed



复制时要考虑的几个mysql参数
“sync_binlog”:这个参数是对于MySQL系统来说是至关重要的,他不仅影响到Binlog对MySQL所
带来的性能损耗,而且还影响到 MySQL 中数据的完整性。对于“sync_binlog”参数的各种设置的说明如
下:
sync_binlog=0,当事务提交之后,MySQL 不做 fsync 之类的磁盘同步指令刷新 binlog_cache中
的信息到磁盘,而让 Filesystem 自行决定什么时候来做同步,或者 cache 满了之后才同步到磁
盘。
sync_binlog=n,当每进行 n 次事务提交之后,MySQL 将进行一次 fsync 之类的磁盘同步指令来
将 binlog_cache 中的数据强制写入磁盘。
在 MySQL 中系统默认的设置是 sync_binlog=0,也就是不做任何强制性的磁盘刷新指令,这时候的性
能是最好的,但是风险也是最大的。因为一旦系统 Crash,在 binlog_cache 中的所有 binlog 信息都会被
丢失。而当设置为“1”的时候,是最安全但是性能损耗最大的设置。因为当设置为 1 的时候,即使系统
Crash,也最多丢失 binlog_cache 中未完成的一个事务,对实际数据没有任何实质性影响。从以往经验
和相关测试来看,对于高并发事务的系统来说,“sync_binlog”设置为 0 和设置为 1 的系统写入性能差
距可能高达 5 倍甚至更多。

log-slave-updates、gtid-mode、enforce-gtid-consistency、report-port和report-host:用于启动GTID及满足附属的其它需求;
master-info-repository和relay-log-info-repository:启用此两项,可用于实现在崩溃时保证二进制及从服务器安全的功能;
sync-master-info:启用之可确保无信息丢失;
slave-paralles-workers:设定从服务器的SQL线程数;0表示关闭多线程复制功能;
binlog-checksum、master-verify-checksum和slave-sql-verify-checksum:启用复制有关的所有校验功能;
binlog-rows-query-log-events:启用之可用于在二进制日志记录事件相关的信息,可降低故障排除的复杂度;
log-bin:启用二进制日志,这是保证复制功能的基本前提;
server-id:同一个复制拓扑中的所有服务器的id号必须惟一;


服务配置段[mysqld]中于少应该定义如下选项
1.1、配置master节点:
[mysqld]
binlog-format=ROW
log-bin=master-bin
log-slave-updates=true
gtid-mode=on 
enforce-gtid-consistency=true
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1
server-id=1
report-port=3306
port=3306
datadir=/mydata/data
socket=/tmp/mysql.sock
report-host=master.magedu.com

1.2、配置slave节点:
[mysqld]
binlog-format=ROW
log-slave-updates=true
gtid-mode=on 
enforce-gtid-consistency=true
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
relay-log=mysql-relay-bin
binlog-rows-query-log_events=1
server-id=11
report-port=3306
port=3306
log-bin=mysql-bin.log
datadir=/mydata/data
socket=/tmp/mysql.sock
report-host=slave.magedu.com
read_only=on

配置双主(版本要一样):
修改my.cnf
server=1
log-bin=mysql-bin          二进制日志应该单独存放
relay-log=mysql-relay-bin

如果有数据可先备份数据到其他节点
mysql> flush tables with read lock;
记录二进制日志位置
mysql> show master status;
+-------------------+----------+--------------+------------------+
| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+------------------+
| master-bin.000031 |      284 |              |                  |
+-------------------+----------+--------------+------------------+
同步数据文件
[root@localhost ~]# rsync -av /mysql/ 192.168.100.9:/mysql
mysql> unlock tables;

授权复制主机
mysql> grant replication slave,replication client on *.* to 'repluser'@'192.168.100._' identified by 'redhat';
------------
配置好另一台后连接另一台主的
mysql> change master to master_host='192.168.100.10',master_user='repluser',master_password='redhat',master_log_file='master-bin.000001',master_log_pos=106;
-----------
mysql> start slave ;
确保都为yes
mysql> show slave statusG
 Relay_Master_Log_File: master-bin.000001
            Slave_IO_Running: Yes
           Slave_SQL_Running: Yes
在另一个主的上
server=2         一定不能和其他节点上的一样,否则主从复制失败
log-bin=mysql-bin          
relay-log=mysql-relay-bin
启动服务
service mysqld start
连接主服务器
mysql> change master to master_host='192.168.100.7',master_user='repluser',master_password='redhat',master_log_file='master-bin.000031',master_log_pos=284;

mysql> start slave ;
确保都为yes
mysql> show slave statusG
 Relay_Master_Log_File: master-bin.000031
            Slave_IO_Running: Yes
           Slave_SQL_Running: Yes

记录二进制日志位置
mysql> show master status;
+-------------------+----------+--------------+------------------+
| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+------------------+
| master-bin.000001 |      106 |              |                  |
+-------------------+----------+--------------+------------------+
授权复制主机
mysql> grant replication slave,replication client on *.* to 'repluser'@'192.168.100._' identified by 'redhat';

在双主之间配置heartbeat
安装heartbeat
主机名,时间,ssh互信

ha.cf配置文件部分参数:

   autojoin    none
       #集群中的节点不会自动加入
   logfile /var/log/ha-log
       #指名heartbaet的日志存放位置
   keepalive 2
       #指定心跳使用间隔时间为2秒(即每两秒钟在eth1上发送一次广播)
   deadtime 30
       #指定备用节点在30秒内没有收到主节点的心跳信号后,则立即接管主节点的服务资源
   warntime 10
       #指定心跳延迟的时间为十秒。当10秒钟内备份节点不能接收到主节点的心跳信号时,就会往日志中写入一个警告日志,但此时不会切换服务
   initdead 120
       #在某些系统上,系统启动或重启之后需要经过一段时间网络才能正常工作,该选项用于解决这种情况产生的时间间隔。取值至少为deadtime的两倍。
   #mcast eth0 225.0.0.1 694 1 0
       #采用网卡eth0的Udp多播来组织心跳,一般在备用节点不止一台时使用。Bcast、ucast和mcast分别代表广播、单播和多播,是组织心跳的三种方式,任选其一即可。
   auto_failback off
       #用来定义当主节点恢复后,是否将服务自动切回,heartbeat的两台主机分别为主节点和备份节点。主节点在正常情况下占用资源并运行所有的服务,遇到故障时把资源交给备份节点并由备份节点运行服务。在该选项设为on的情况下,一旦主节点恢复运行,则自动获取资源并取代备份节点,如果该选项设置为off,那么当主节点恢复后,将变为备份节点,而原来的备份节点成为主节点,这里设置为off
   ping 192.168.12.237
       #选择ping的节点,ping 节点选择的越好,HA集群就越强壮,可以选择固定的路由器作为ping节点,但是最好不要选择集群中的成员作为ping节点,ping节点仅仅用来测试网络连接
   crm yes
       表示受crm控制
   node node1.magedu.com  
       #主节点主机名,可以通过命令“uanme –n”查看。
   node node2.magedu.com  
       #备用节点主机名
   #下面是对传输的数据进行压缩,是可选项
   compression     bz2
   compression_threshold 2
在资源文件定义vip
资源文件(/etc/ha.d/haresources)
node1   IPaddr::192.168.100.5/24/eth0   

认证文件(/etc/ha.d/authkeys)
auth 1
1 crc
权限600

在两个节点同样配置确保一样
scp /etc/ha.d/authkeys /etc/ha.d/harsources /etc/ha.d/ha.cf 192.168.100.10:/etc/ha.d/
启动服务
service heartbeat start;ssh node2 'service heartbeat start'

测试vip是否转移

如果master意外崩溃导致二进制日志中的某事件损坏,可以在从服务器使用如下参数忽略:

            stop slave;
       set global     sql_slave_skip_counter = 1;

        start slave;

   复制相关的文件:
       master.info: 文本文件,保存从服务器连接至主服务时所需要的信息,每行一个值;
       relay-log.info: 文本文件,保存了复制位置:包括二进制日志和中继日志的文件及位置;

       为了复制的安全性:
           sync_master_info = 1    
           sync_relay_log = 1   
           sync_relay_log_info = 1

从服务器意外崩溃时,建议使用pt-slave-start命令来启动slave; 
从服务器落后于主服务器:
       Seconds_Behind_Master: 0

   评估主从服务表中的数据是否一致:
       pt-table-checksum

       如果数据不一致,解决办法
           1、重新备份并在从服务器导入数据;
           2、pt-table-sync 
pt开头的工具由:percona-toolkit-2.2.4-1.noarch.rpm

监控mysql服务器状态
[root@localhost ~]# vmstat 2
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
0  0    780 177488 152496 397160    0    0     4     9   21   15  0  0 100  0  0    
0  0    780 177472 152500 397188    0    0     0    12   32   30  0  0 100  0  0    

procs r:等待cpu时间片的进程数,一般不能大于cpu的物理核心数
procs b:有多少进程已经进入了不可中断式睡眠,比如等待io,网络

swpd:从内存交换到swpd的大小,通常是在内存中好久不用的,系统自动交换出去的,以保证有更多的内存给其他的进程
free:剩余内存
buff:缓冲
cache:缓存
swap si so:内存不够用了,在交换分区进进出出的量
io bi bo:磁盘io
system in cs:每秒中断和上下文切换
cpu:表示cpu的时间都花在哪了
        us:用户空间
        sy:内核空间
        id:剩余
        wa:等待io
        st:被偷走的

[root@localhost ~]# iostat -x -k /dev/sda
Linux 2.6.32-358.el6.x86_64 (localhost.localdomain)     02/22/2014     _x86_64_    (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          0.07    0.01    0.17    0.11    0.00   99.64

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.04     3.56    0.32    0.72     5.34    17.16    43.52     0.02   17.79   3.09   0.32

rrqm/s wrqm/s:每秒读写合并数
r/s w/s:每秒读写
rkB/s    wkB/s:每秒读写千字节数
await:磁盘排队所花的时间,单位毫秒(发起了一个读磁盘的请求,过了这么久才看到硬盘)
svctm:服务所用的时间,不包括排队 单位毫秒
%util:磁盘利用率

使用sar gnuplot监控系统
1,生成信息文件
[root@localhost ~]# LANG=C sar -q |awk '/^[^[:alpha:]]+$/{print $1,$(NF-2),$(NF-1),$NF}' >~/cpu.info

2,写一个生成图片的文件
[root@localhost ~]# vim gnuplot.cpu
set xdata time
set timefmt "%H:%M:%S"
set term png size 1024,768
set output "/var/www/html/cpu.png"
plot '~/cpu.info' using 1:2 title 'min/1' with line,'~/cpu.info' using 1:3 title 'min/5' with line

3,画图
[root@localhost ~]# gnuplot gnuplot.cpu
查看
wKioL1NY94nTdbUoAADDD0auoHk809.png

原文地址:https://www.cnblogs.com/lidabo/p/14254503.html