---

一、MySQL异步复制

MASTER
vim /etc/my.cnf
	server-id=1														
							#指定serverid范围为(2*32 )-1之间一般在配置文件中server-id可以进行重启生效
	log-bin=mysql-bin				
							#指定mysql二进制日志位置
systemctl restart mysqld											
							#重启后进行mysql的的配置更改生效
SET GLOBAL server_id=1; 											
							#数据库临时更改server-id用于数据库无法进行重启是使用
CREATE USER 'repl'@'%' IDENTIFIED BY 'dockerps-A1';					
							#表示建立一个用户允许任何人登录设定密码为dockerps-A1
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';						
							#表示给与这个用户链接到域中的任何主机使得其可以进行复制任何表和任何库
CREATE USER 'westos'@'%' IDENTIFIED BY 'dockerps-A1' REQUIRE SSL;	
							#生产环境中一般会使用强制加密连接的方式进行使用
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

SELAVE
vim /etc/my.cnf
server-id=2
systemctl restart mysql
CHANGE MASTER TO MASTER_HOST='192.168.63.131',  MASTER_USER='repl', MASTER_PASSWORD='dockerps-A1', MASTER_LOG_FILE='mysql-bin.000004', MASTER_LOG_POS=319 ;
							#MASTER_HOST=表示MASTER主机IP地址
							#MASTER_USER=表示使用的用户
							#MASTER_PASSWORD=表示所使用的密码
							#MASTER_LOG_FILE=表示所使用的二进制日志文件名称
							#MASTER_LOG_POS=表示从那个位置开始复制
1
2
3
4
5
6
7
8
9
10

复制是将主库的DDL和DML操作通过二进制日志传递到复制服务器（从库）上，然后从库对这些日志重新执行（重做），从而使得主库和从库保持数据一致

缺点：当大容量数据写入数据库时，带宽会影响二进制日志的接受并且SLAVE端接受不到日志则无法同步日志，主节点如果崩溃掉了，此时主节点上已经提交的事务可能并没有传到从节点上，如果此时，强行将从提升为主，可能导致新主节点上的数据不完整。进而导致数据不一致，或是数据出现损耗。

二、基于GTID的主从复制

即全局事务ID, 保证了在每个在主库上提交的事务在集群中有一个唯一的ID
通过主节点的ip，端口，以及账号密码，利用GTID的机制进行自动复制，不需要指定pos点以及二进制文件

MASTER，SLAVE
vim /etc/my.cnf
	gtid_mode=ON
							#开启GTID模式
	enforce-gtid-consistency=ON
							#服务器通过只允许执行可以使用 GTID 安全记录的语句来强制执行 GTID 一致性。
							#ON:不允许任何事务违反 GTID 一致性。
							#OFF：允许所有事务违反 GTID 一致性。
							#WARN：允许所有事务违反 GTID 一致性，但在这种情况下会生成警告。
systemctl restart mysql
1
2
3
4
5
6
7
8
9
10

SLAVE
STOP SLAVE ;
							#停止原有的SLAVE进程原有的MASTER已经停止
CHANGE MASTER TO MASTER_HOST='192.168.63.131', MASTER_USER='repl', MASTER_PASSWORD='dockerps-A1', MASTER_AUTO_POSITION=1, MASTER_PORT=3306 ;
							#MASTER_PORT数据库的指定端口号，默认未3306
							#MASTER_AUTO_POSITION副本源的事务由 GTID 标识的选项
1
2
3
4
5
6

MASTER_LOG_FILE选项和 选项 都MASTER_LOG_POS不能与 MASTER_AUTO_POSITIONset 等于 1 一起使用。尝试这样做会导致CHANGE MASTER TO语句失败并出现错误。

三、MySQL半同步复制

半同步复制提高了数据的安全性，一定程度的保证了数据能成功备份到从库，同时它也造成了一定程度的延迟，但是比全同步模式延迟要低，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

MASTER
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
										#下载插件rpl_semi_sync_master
SET GLOBAL rpl_semi_sync_master_enabled =1；
										#将插件激活
SHOW STATUSS LINK '%repl_semi_sync%' ;
										#查看插件是否为激活状态
vim /etc/my.cnf
	rpl_semi_sync_master_enabled=1
										#用来保证下次可以正常使用
	rpl_semi_sync_master_timeout=1000
										#最大等待时间为1000毫秒
1
2
3
4
5
6
7
8
9
10
11
12

SLAVE
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
										#下载插件但是为slave端的rpl_semi_sync_slave
SET GLOBAL rpl_semi_sync_slave_enabled = 1;
										#将插件激活
STOP SLAVE IO_THREAD;
										#重启一次IO线程
STRT SLAVE IO_THREAD;
vim /etc/my.cnf
	rpl_semi_sync_slave_enabled=1
1
2
3
4
5
6
7
8
9
10

四、三种方式的对比

全同步模式：适用于低延迟的网络环境中但是可以保证数据的无损迁移，但是全同步模式对于数据库的性能时最低的
异步模式：性能最高但是容易发生数据库的数据无法保证一致性，当MASTER节点在用户提交数据后down掉了Binglog日志为能发送过去或因网络问题导致不能同步则导致数据没办法获得一致性的数据
半同步模式：非MySQL原生的数据库方式，为第三方插件开发的模式但是容易发生数据库的幻读现象，当客户提交数据后本地存储节点会将数据存储但是SLAVE节点不论是带宽影响还是SLAVEdown掉了都会发生幻读现象
GTID模式：目前嘴优化的模式自动利用GTID的机制自行比对POS点Blnglog存储后GTID在全局中有唯一的GTID方便进行识别以及自动进行切换方式

总结