说明：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 status\G
 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 status\G
 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
查看