Mysql Repliaction（复制）集群架构理论实践篇

什么是MySQL Replication？
     1、Replication可以实现将数据从一台数据库服务器（master）复制到一台到多台数据库服务器上（slave）

     2、默认情况下，属于异步复制，所以无需维持长连接

MySQL Replication的原理：
    简单来说，master将数据库的改变写入二进制日志，slave同步这些二进制日志，并根据这些二进制日志进行数据重演操作，实现数据异步同步。

MySQL Replication的用途：
     1、Fail Over 故障切换
     2、Backup 在线热备份（机械故障）
     3、High Performance 高性能

MySQL Replication的架构：
master ---> slave (双机热备)
    默认情况下，master接受读写请求，slave只接受读请求以减轻master的压力

复制的过程：
     1、slave端的IO线程连上master端，请求
     2、master端返回给slave端，bin log文件名和位置信息
     3、IO线程把master端的bin log内容依次写到slave端relay bin log里，并把master端的bin-log文件名和位置记录到master.info里。
     4、salve端的sql线程，检测到relay bin log中内容更新，就会解析relay log里更新的内容，并执行这些操作

master ---> slave1 -----> slave2 (级联架构)
优点： 进一步分担读压力
缺点： slave1 出现故障，后面的所有级联slave服务器都会同步失败

/----> slave1
master (并联架构)
\----> slave2
优点：解决上面的slave1的单点故障，同时也分担读压力
缺点：间接增加master的压力（传输二进制日志压力）

master1 <------> master2 (互为主从)
优点：
从命名来看，两台master好像都能接受读、写请求，但实际上，往往运作的过程中，同一时刻只有其中一台master会接受写请求，另外一台接受读请求

————————————————————————————————————————————————————

实例：M—S架构：实现双机热备（AB复制）
     1、可以降低master读压力
     2、可以对数据库做“热备”，热备只能解决硬件master硬件故障，软件故障等重大故障问题，但无法解决人为误操作导致的逻辑故障（例如输入错误的SQL语句把重要的记录删除了），所以常规的备份是必须。

环境准备及要求：
1、关闭防火墙和selinux

2、hosts文件中两台服务器主机名和ip地址一一对应起来

3、系统时间需要同步

4、master和slave的数据库版本保持一致(系统版本保持一致)

5、master:10.1.1.1 slave:10.1.1.2

6、此处说明，我本机master端是通过源码包安装的mysql5.6.25版本，安装目录和数据目录都是自定义的:basedir=/mysql25,datadir=/data/mysql25。slave是直接从我本机master同步过去再初始化的。所以我当前环境是两台机上面版本一致的，数据库里面库和表也是一致的。

思路：
1、master必须开启二进制日志
2、slave必须开启中继日志
3、master和slave的server-id必须不一致 2^23-1
4、master和slave的初始数据一致

具体步骤：

1、修改配置文件（master和slave）
master：
[mysqld]
basedir=/mysql25
datadir=/data/mysql25
port=3307
socket=/mysql25/mysql.sock
log-bin=/var/lib/mysql/mysqld-bin                             master必须开启二进制日志
server-id=100                                                           mysql数据库的编号，master和slave必须不一样

slave：
[mysqld]
basedir=/mysql25
datadir=/data/mysql25
port=3307
socket=/mysql25/mysql.sock
log-bin=/mysql56/mysqld-bin                              slave上的二进制日志可以开启也可以不开启，看具体情况
server-id=200                                                      mysql数据库的编号
relay-log=/mysql56/relay-log                               主从复制日志需要开启

2、初始化数据，使两边数据一致。（以master为主）
此处省略，因为上面环境介绍那里已经说明了我的数据是一致的。

3、master端创建授权用户
mysql> grant replication slave on *.* to 'slave'@'10.1.1.%' identified by '123';
mysql> flush privileges;

4、查看master的正在写的二进制文件名和位置
mysql> flush tables with read lock;                     先加锁，防止两边数据不一致;如果业务还未上线，这个就没有必要了
Query OK, 0 rows affected (0.00 sec)
mysql> show master status;                              只有打开二进制日志，这句命令才有结果，表示当前数据库的二进制日志写到什么位置
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 331 | | |
+------------------+----------+--------------+------------------+
二进制文件名 正在写入的位置

5、slave端设定复制信息

mysql> change master to
-> master_host='10.1.1.20', master ip
-> master_user='slave',               同步用户（这里都是上面第三步创建的用户和授权密码）
-> master_password='123',         密码
-> master_port=3306,                  端口
-> master_log_file='mysqld-bin.000001',          master主上面查到到二进制日志名
-> master_log_pos=331;                                   主上面查到的位置号

6、启动复制线程，开始同步
mysql> start slave;
mysql> show slave status \G;

Slave_IO_Running: Yes 代表成功连接到master并且下载日志
Slave_SQL_Running: Yes 代表成功执行日志中的SQL语句

回到master端解锁：
mysql> unlock tables;
Query OK, 0 rows affected (0.00 sec)
7、测试验证
master写——>slave可以看到
slave写——>master看不到

在上述架构下实现故障迁移和恢复
故障迁移：
1、模拟master出现故障
2、查看slave同步状态并停止向master同步数据
slave > show slave status \G;
Slave_IO_Running: Connecting
Slave_SQL_Running: Yes
Last_IO_Error: error reconnecting to master 'slave@10.1.1.2:3307' - retry-time: 60 retries: 1

mysql> stop slave; <                   ---停止

3、master故障之后，前端的应用应该把读写请求都调度给slave

r/w
X |
master slave

直接用客户端登录slave，对数据进行修改，模拟写操作
mysql> use db2;
mysql> insert into t1 set id=2;
mysql> insert into t1 set id=3;
mysql> use db1;
mysql> update t1 set name='test' where id=3;

故障修复
可以肯定的是，在这个架构下，master要上线，肯定只有一个选择，就是作为原有slave的从，重新上线：
主 从
slave ---> master
情况：
假设数据已经损害了、丢失了，那么最简单的方法就是重装master数据库，把master作为slave的从，原来的slave就变成新架构的主

注意：
确保新的架构复制成功之后，回到slave服务器，把数据目录下的master.info文件删除，否则的化，下次如果slave重启数据库服务，会自动连接master；slave IO线程把master端的bin log内容依次写到slave端relay bin log里，并把master端的bin-log文件名和位置记录到master.info里