MySQL主从复制

　　在MySQL主从复制过程当中，会有两个角色，master和slave，数据流向是从master到slave。单个主机的数据库服务器缺乏健壮性，当主机出现故障后，数据库没法正常对外提供服务，对应用来是不可避免。因此这个时候须要提升数据库系统的健壮性，主从复制replication，是将master主机上指定数据库的变化，记录在指定的binlog文件中，slave主机经过读取master主机的binlog文件，将变化的数据，写入到slave主机的本地数据库中。实现数据库的备份。

　　MySQL数据库的主从复制，是一个异步的过程，也就是说master库的写操做，和slave库的复制操做，并无关系，能够彻底剥离开。

　　实现了MySQL数据库的主从复制以后，这个时候就带出一个更好的优点，不只能对master数据库服务器进行数据备份，还能作读写分离，因为主从复制的特殊性，全部的更新数据库的操做，都必须在master主机上进行，避免在slave主机上操做后，致使主从复制的结果不一致，slave主机上保留的，是master主机的彻底副本，因此这个时候，对应用来讲，全部的读操做，就能够放在slave主机上。相比于以前，同一台数据库服务器上，既进行数据库写操做，又进行数据库读操做，开启主从复制以后，能够规划应用，写操做只在master主机上，将全部的读操做，分担到全部的slave主机上，这就减轻了master主机的压力，同时，也提高了数据库读写的性能。

　　主从复制的三个线程：

　　一、master主机的IO线程,Binlog dump thread

　　一旦要开启主从复制，master主机上必需要制定一个二进制文件的位置，也就是binlog文件位置，在binlog文件中，记录了master数据库的变化，在master数据库变化的时候，一方面，master数据库将IO写操做，写入到本地数据库中data，同时，经过这个IO线程，记录master数据库的变化，将变化的内容，写入到二进制文件中。

　　该IO线程，还做为服务端，处理slave主机发过来的请求，在slave主机发过来的IO请求中，包含了几个关键因素：用户名/密码，binlog_file文件和位置position，其中用户名/密码是在master主机上建立的，而且分配了指定数据库的replication权限的，用户对slave主机进行鉴权；binlog_file文件名和position是用来肯定slave主机须要从哪里开始读取更新变化。根据slave主机发来的请求，该IO线程，会去指定的binlog_file和位置position，读取现有的更新内容，发送给slave端。同时还会将读取以后的新的binlog_file和位置position发送给slave主机。

　　show processlist，查看。

　　该线程向在读取master主机上binlog文件时，须要添加一个锁，当数据内容被读取以后，该锁就释放了，数据内容读取出来以后，就会由该线程发给slave。而锁的释放，有多是在数据发送给slave以前。

　　二、slave主机的IO线程

　　slave主机经过该IO线程，向master主机请求binlog日志文件，请求时会带上用户名/密码，binlog_file和位置position，接收到master主机的反馈后，master主机会反馈两部份内容，数据库binlog文件，和新的binlog_file和position位置，该IO线程会将数据库binlog文件内容，写入到本身的relay_log中，以增长的方式，同时将新的master主机的binlog_file和位置position写入到本身的master.info文件中，直接覆盖。master主机的属性、本身的用户名/密码、binlog_file和position都是slave主机设置的，一旦开启了主从同步，会自动生成master.info文件，每同步一次，该master.info文件就会更新一次。

　　当slave主机上启用了start slave以后，就会建立这个IO线程，这个线程会链接到master主机上，请求master主机binlog中的更新。

　　该IO线程，会读取master主机发送回来的更新，而后复制到本地文件中，组成本身的relaylog

　　经过show slave status中SLAVE io running，能够看到该线程的状态。

　　三、slave主机的SQL线程

　　slave主机的SQL线程，会时时监控slave主机的relay_log文件，当发现relay_log中有增长内容时，会将读取内容，还原成master主机上执行过的SQL操做，写入到本地的数据库中。

 　　在一个主从复制组group中，有3个线程，其中master上只会有一个bin log dump线程，每个slave主机上，都会有两个线程。

　　在slave主机上，2个线程分开处理，1个从master上去读取binlog，1个在本地执行，这是两个分别独立的任务，这两个任务之间也不会有什么影响，IO线程慢，不会影响SQL线程。好比，当slave主机中止复制了一段时间，当slave主机启动开始复制周，IO线程会从master主机上抓取全部的binlog信息，无论SQL线程处理了多少。当SQL线程尚未彻底将IO线程抓取的binlog信息内容彻底处理时，slave主机中止了，这个时候数据也不会丢失，由于IO线程已经获取了全部的binlog，而且存放到本身的本地relaylog中，当下一次slave主机启动时，继续执行SQL线程，这也方便master主机清理本身的binlog，一旦slave获取了binlog内容，master主机就会清理了。

　　master主机上的线程

　　

　　slave上的线程

　　

 　　在数据复制过程当中，slave上会生成多个日志文件，用来保存从master主机上获取的binlog信息，如今的状态，以及出列到relaylog中的位置，主要有三种：

　　一、relay log中的内容，是从master的binlog中读取的信息，由slave的IO线程写入，在relay log中的事件event，会被SQL线程执行

　　二、master info log，会记录slave主机链接的master主机的状态信息和当前的配置信息，包含master主机名，登陆凭据，以及slave主机已经读取到的位置

　　三、relay log info，记录了SQL线程执行了relay log中的位置。

 

　Relay log

　　relay log和binlog相似，包含了大量了描述数据库变动的文件，同时包含一个索引文件，该索引文件是全部使用过的relay log的名称。

　　relay log文件，指的是包含许多描述数据库变动的事件，而relay log，则是relay log文件和索引。

　　relay log文件，和binlog有相同的格式，能够经过mysqlbinlog来读取。默认状况下，relaylog文件存放在data目录中，命名格式是hostname-relay-bin.****,hostname是主机名，××××是序列号，序列号是连续的，连续的日志文件都是经过连续的序列号产生的，slave会用一个index索引文件，来跟踪当前使用的relay log文件，默认的索引文件也是在data目录中显示。默认状况下，relay log文件和index文件，都是连续产生的，也能够经过设置服务器属性，来直接覆盖。

　　若是slave主机使用的是基于主机名的命名方式，来命名relaylog文件，当修改了slave主机的主机名后，会产生问题，致使复制失败，Failed to open the relay log and Could not find target log during relay log initialization。为了不出现这样的问题，在初始化配置slave主机的时候，能够经过属性来设置relay log和index的命名。这就使得命名和主机名独立开来。

　　当SQL执行了relay log以后，会自动删除，由于已经执行了，也就不在须要这些文件了，

 

　　master.info文件和relay-log.info文件存储在硬盘上，当slave主机从新启动时，经过读取这两个文件，就能知道须要从master的binlog的何处开始读取binlog内容，以及须要从本身的relay-log的何处开始执行。其中，master.info文件是由slave上的IO线程负责更新的，relay-log.info文件是由SQL线程负责更新。

　　这是slave上的master.info文件，一次显示的是文件中行数、master的binlog文件、位置、master主机名、用户、密码、端口、重复次数。

　　而relay-log.info中显示了4行，relay log文件，位置，从master的读取的binlog文件名，slave上已经执行的位置（若是已经复制完成，后两行，应该和master上show master status内容一致）

　　

　　若是slave复制在进行，直接经过show slave status就能够看到状态，若是没有运行，就须要看文件了。

 

　　主从复制的4中架构演变

1. 一主一从，主机负责写，从机负责读
2. 一主多从，防止从机故障，影响读操做
3. 多级主从，防止主机故障，影响写操做
4. multi-source

 　　在一主多从中，一个master主机，下挂了多个slave从机，当master主机出现故障时，slave主机也就没法执行写操做，因此要对master主机进行保护，这个时候，能够考虑master主机作一个双主从服务，举个例子，两台主机A和B，A便是B的master主机，也是B的slave从机，保证不管是从A上面写仍是从B上写，都可以实现AB数据的一致性。

　　当有了两个主机以后，主机下挂的从机，就须要对两个主机进行同步，若是有4台主机A、B、C、D，其中AB互为主从，AC为主从，BD为主从，当在A上发生数据修改，则BC都能同步，可是D没法同步，由于D同步的是B的binlog，而B同步的是A的binlog，在B上面是relaylog，并无写入到binlog中，因此D也就没法同步数据。就是由于这种状况，因此全部的从机，须要对全部的主机进行同步，也就是所谓的multi-source，实际上就是添加多个change master to ，结尾是for channel ""，为这个master起一个名字，就行了。

CHANGE MASTER TO
 MASTER_HOST='192.168.64.132',
 MASTER_PORT=3307,
 MASTER_USER='replication',
 MASTER_PASSWORD='123456',
 MASTER_LOG_FILE='mysqlbin.000012',
 MASTER_LOG_POS=319 for channel 'mastera';
 
CHANGE MASTER TO
 MASTER_HOST='192.168.64.129',
 MASTER_PORT=3307,
 MASTER_USER='replication',
 MASTER_PASSWORD='123456',
 MASTER_LOG_FILE='mysqlbin.000015',
 MASTER_LOG_POS=2262 for channel 'masterb';
 
在slave的配置文件中增长
master_info_repository=TABLE;
relay_log_info_repository=TABLE;


或者在启动以后，设置全局系统变量
STOP SLAVE;
SET GLOBAL master_info_repository = 'TABLE'; 
SET GLOBAL relay_log_info_repository = 'TABLE';

　　当实现了multi-source以后，就可以保证任何主节点的数据修改，都会同步到全部的从节点中。实现了数据的一致性。