双主一从架构，从服务器在本地，用于备份和研发测试。两台线上服务器进行数据库相互同步，保证数据一致性，采用xtrabackup备份数据库+脚本每天1点异地备份到从服务器。


一、对线上的一台主服务器数据进行备份，并恢复到另外两台服务器上。

innobackupex --defaults-file=/wqdata/mysql/my.cnf --user=bkuser --password='123456' /wqdata/mofidbbak/fullbackup/    备份

scp -P 8022 modb0909.tar.gz 223.100.98.83:/wqdata/   传送

从服务器恢复数据库步骤：

service mysqld stop
  951  rm -rf /mydata/data/*
  953  innobackupex --defaults-file=/wqdata/mysql/my.cnf --copy-back /wqdata/2015-09-09_13-06-43/
  955  chown -R mysql.mysql /wqdata/mydata/data/
  956  service mysqld start

二、配置主主从：

主服务器 show master status; 

从服务器 change master to master_host='223.10.11.124',master_user='1123wq',master_password='1112011',master_log_file='mysql-bin.000018',master_log_pos=24418754;

start slave;

show slave status\G；

主主就是反着做一遍

三、xtrabackup备份脚本，见之前文章。


提供几个mysql的高可用方案，各有用途，仅供参考：


A.普通的主从复制————客户端通过master对数据库进行读/写操作，Slave端作为备机，可用来进行一些查询，备份等操作。

优点：部署简单，易于扩展，能提供一定的数据保护。

缺点：如果master主机硬件故障且无法恢复，则可能造成部分未传送到Slave端的数据丢失；如果master端需要进行某些维护操作，将slave临时作为master提供服务之后，又需要重新搭建主从环境，会对master造成一定的性能影响。


B.双主复制————两个 mysql server互相将对方作为自己的master，自己作为对方的Slave来进行复制，一端提供写服务，另一端读服务或者仅仅作为备机不用提供任何服务，而且其还能够跟一个或者多个Slave专门提供读服务。

优点：最大的好处就是既可以避免主Master的写入操作不会受到Slave集群的复制所带来的影响，同时主Master需要切换的时候也基本上不会出现重搭Replication的情况。

缺点：这个架构也有一个弊端，那就是备用的Master有可能成为瓶颈，因为如果后面的Slave集群比较大的话，备用Master可能会因为过多的SlaveIO线程请求而成为瓶颈。


C.主从复制扩展：读写分离————由一个master复制到一个或者多个Slave的架构模式，客户端通过master对数据库进行写操作，通过Slave端进行读操作，并可进行备份，master出现问题后，可以后动将应用切换到Slave端。该方案主要用于读压力比较大的应用系统中。

优点：结构灵活，数据库端廉价扩展，能够解决很多中小型网站的数据库压力瓶颈问题。

缺点：需要程序来实现读写分离，增加了程序的复杂度，如果服务器架构调整或者有主机发生故障，还需要调整程序。


D.HearBeat+双主复制———— hearbeat最核心包括的两个部分是心跳监测和资源接管。使用hearbeat+mysql主主同步来实现mysql数据库的 高可用，当master的主机或hearbeat宕机以后会自动切换到备用机上，当恢复以后可以自动切换回来，master继续提供服务。

优点：配置简单，能在一定的程度上避免单点故障。

缺点：如果master上的mysql挂掉，则无法检测到并进行切换，需要一些脚本来协助监控。默认切换到备用机后，不会自动启动mysql，需要手动或者脚本启动，不方便扩展，可能会出现脑裂的问题。


E.Hearbeat+DRBD+Mysql———— 本方案采用Hearbeat双机热备软件来保证数据库的高稳定性和连续性，数据的一致性有DRBD这个工具来保证。默认情况下只有一台mysql在工作， 当主mysql服务器出现问题后，系统将自动切换到备机上继续提供服务，当主数据库修复完毕，又将服务切回继续由主mysql提供服务。

适用场景：适用于数据库访问量不太大，短期内访问量增长不会太快，对数据库可用性要求非常高的场景。

优点：安全性高，稳定性高，可用性高，出现故障自动切换。

缺点：只有一台服务器提供服务，成本相对较高，不方便扩展，可能会出现数据库脑裂。


F.LVS+Keepalive+双主复制————lvs提供负载均衡，keepalive作为故障转移。服务器单点写入，读实现负载很横和故障切换。当网络、mysql服务、服务器、keepalive服务出现故障后，服务器能自动跳转到备用机，当主服务器服务启动起来后会自动切换回来。

适用场景：适用于对数据库可用性要求比较高，读压力比较大的场景（后端可跟一个或多个Slave服务器，让lvs实现读的负载均衡）。这个方案也能够很方便地进行单台数据库的管理维护以及切换工作，比如进行大表的表结构更改，数据库的升级等。

优点：高可用效率好，可以根据服务与系统的可用性多方面进行切换。可以将写vip和读vip分别进行设置，为读写分离做准备。扩展很方便。可以在后面添加多个从服务器，并做到读的负载均衡。

缺点：在启动或者恢复后如果要实现指定条件替换或者不替换需要通过其他方式实现，比如：临时更改mysql的端口等。安装配置比单写入稍微复杂，需要另外一个vip。管理比单写入复杂。主切换后，从需要手工切换。主备切换需要1s左右的时间。


G.MMM+mysqlproxy+双主复制———— MMM（mysql主主复制管理器）是一套灵活的脚本程序，用来对mysql replication进行监控和故障迁移?并能管理mysql Master-Master复制的配置 。附带的工具套件可以实现多个slaves的read负载均衡.两个mysql server服务器互为主从，MMM提供浮动IP的功能，如果当前的主服务器挂掉后，客户端的读写请求会通过漂移的虚拟IP自动转移到另一台服务器上，从 而自动实现服务器的故障转移，mysqlproxy实现了读写分离。

适用场景：这个方案是目前比较成熟的解决方案，适用于数据库访问量大，业务增长快的场景。适用于读/写比较高的web2.0应用中。

优点：安全性、稳定性高，可扩展性好，高可用好，当主服务器挂掉以后，另一个主立即接管，其他的从服务器能自动切换，不用人工干预。

缺点：至少三个节点，对主机的数量有要求，对于实时性很高的场合可能需要做一些处理。

mysqlprox与mysql MMM集成的必要性：实现mysql数据库层的负载均衡；数据库节点实现HA动态切换；读写分离，降低主数据库负载



2种方法解决mysql主从不同步 .                      

 先上Master库：

 

mysql>show processlist;   查看下进程是否Sleep太多。发现很正常。

show master status; 也正常。

 

mysql> show master status;

+-------------------+----------+--------------+-------------------------------+

| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB              |

+-------------------+----------+--------------+-------------------------------+

| mysqld-bin.000001 |     3260 |              | mysql,test,information_schema |

+-------------------+----------+--------------+-------------------------------+

1 row in set (0.00 sec)

 

再到Slave上查看

 

mysql> show slave status\G                                                

 

Slave_IO_Running: Yes

Slave_SQL_Running: No

 

可见是Slave不同步

 

下面介绍两种解决方法：

 

 

方法一：忽略错误后，继续同步

该方法适用于主从库数据相差不大，或者要求数据可以不完全统一的情况，数据要求不严格的情况

 

解决： 

stop slave;

 

#表示跳过一步错误，后面的数字可变

set global sql_slave_skip_counter =1;

start slave;

 

之后再用mysql> show slave status\G  查看：

 

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

 

ok，现在主从同步状态正常了。。。

 

 

方式二：重新做主从，完全同步

该方法适用于主从库数据相差较大，或者要求数据完全统一的情况

 

解决步骤如下：

 

1.先进入主库，进行锁表，防止数据写入

 

使用命令：

 

mysql> flush tables with read lock;

 

注意：该处是锁定为只读状态，语句不区分大小写

 

2.进行数据备份 

 

#把数据备份到mysql.bak.sql文件

[root@server01 mysql]#mysqldump -uroot -p -hlocalhost > mysql.bak.sql

这里注意一点：数据库备份一定要定期进行，可以用shell脚本或者python脚本，都比较方便，确保数据万无一失

3.查看master 状态

 

mysql> show master status;

+-------------------+----------+--------------+-------------------------------+

| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB              |

+-------------------+----------+--------------+-------------------------------+

| mysqld-bin.000001 |     3260 |              | mysql,test,information_schema |

+-------------------+----------+--------------+-------------------------------+

1 row in set (0.00 sec)

 

4.把mysql备份文件传到从库机器，进行数据恢复

 

#使用scp命令

[root@server01 mysql]# scp mysql.bak.sql root@192.168.128.101:/tmp/

 

5.停止从库的状态

mysql> stop slave;

 

 

6.然后到从库执行mysql命令，导入数据备份

 

mysql> source /tmp/mysql.bak.sql

 

7.设置从库同步，注意该处的同步点，就是主库show master status信息里的| File| Position两项

 

change master to master_host = '192.168.128.100', master_user = 'rsync', master_port=3306, master_password='', master_log_file = 'mysqld-bin.000001', master_log_pos=3260;

 

8.重新开启从同步

mysql> start slave;

 

9.查看同步状态

mysql> show slave status\G  查看：

 

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

 

10、解锁主库表

mysql> UNLOCK TABLES;