前言：之前在做mysql主从复制的笔记的时候可能做得比较仓促，后来看到一个视频发现还有很多细节都还没有记录清楚，今天有时间再记录一下觉得还是非常有作用的。
1.Mysql 主从复制原理
mysql 的主从复制是一个异步的复制过程（虽然一般情况下感觉是实时的），数据将从一个 mysql 数据库（我们称之为 master）复制到另一个 mysql 数据库（我们称之为 slave），在 master 与 slave 之间实现整个主从复制的过程是由三个线程参与完成的，其中有两个线程（SQL 线程和 IO 线程）在 slave 端，另外一个线程（I/O 线程）在 master 端，要实现 mysql的主从复制，首先必须打开 master 端的 binlog 记录功能，否则就无法实现，因为整个复制过程实际上就是 slave 从 master 端获取 binlog 日志，然后在 slave 上以相同顺序执行获取的binlog 日志中所记录的各种 SQL 操作.
1.2 主从复制原理图
这个图是转载过来的，觉得这个还是比较详细的
2.mysql 主从复制
2.1 准备工作
还是准备两台机器都装上mysql, 一台用于做主一台用于做从
2.2 在主服务器上操作
a.按照原理图上面我们主服务器上需要做以下操作：
a.1. 在配置文件 my.cnf 中设置server-id (这个要保证唯一性)开启binlog，我们就会在mysql安装目录下会生成以下几个文件(msyql)
a.2.在数据库中创建一个账户用来给进行主从同步
a.3.全量备份数据库并记录binlog日志点(等于是从备份这个日志点以后的我们都可以进行主从同步到从库中)
b.1 下面是实操过程先来配置my.cnf
我们可以用这条命令查看binlog状态信息：mysql -uroot -e "show variables like 'log_bin%';"
b.2 在数据库中创建同步账户
b.3 全量备份数据库
--all-databases , -A
导出全部数据库。
--databases, -B
导出几个数据库。参数后面所有名字参量都被看作数据库名。
例：mysqldump -uroot -p --databases test mysql
简单的说，就是主从复制在做全量备份的时候，这个选项可以自动帮我们锁表和识别binlog临界文件，就不需要我们锁表，再看临界文件编号，再执行CHANGE MASTER填写binglong位置信息到从库master.info文件中了，提高了从库部署效率吧。
--master-data[=#] 在备份导出的文件里追加二进制binlog文件的位置和名称
如果值等于1，就会添加一个CHANGE MASTER语句
如果值等于2，就会在CHANGE MASTER语句前添加注释
这个参数会--lock-all-tables锁表，除非你指定了--single-transaction
这种情况下，锁表只会在dump开始的时候持续一小段时间,照理说
在dump的时候，任何动作都会影响到binlog文件
dump结束之后，选项会自动关闭锁表功能--master-data选项的作用就是将二进制的信息写入到输出文件中，在这里是写入到备份的sql文件中。
我们可以查看一下这个备份的数据库里面会有这样一条语句：
2.3 在从服务器上操作
a 从原理图上看我们大概需要这几步操作：
a.1 将binlog节点之前的数据库恢复过来
a.2 CHANGE MASTER
a.3 开启同步(start slave)
a.4 查看配置是否成功(show slave status)
1. 将主库上的备份数据传送过来，并导入从库中
[root@knightlai01 ~]# scp /tmp/20181203.sql [email protected]:/tmp/
The authenticity of host '192.168.139.135 (192.168.139.135)' can't be established.
ECDSA key fingerprint is SHA256:oWZvsZbwSgQLmlEi0WFIF+R3I7UIQ0bYV1Yr6+gKNiw.
ECDSA key fingerprint is MD5:74:91:0c:c2:cc:71:31:0a:8a:cc:07:c1:7b:4b:44:0d.
Are you sure you want to continue connecting (yes/no)? ye
Please type 'yes' or 'no': yes
Warning: Permanently added '192.168.139.135' (ECDSA) to the list of known hosts.
[email protected]'s password:
20181203.sql 100% 644KB 10.5MB/s 00:00 将数据导入从库中
2.change master
3.开启同步并查看状态
查看master.info信息
查看relay-log信息
relay-bin 文件信息
总结：主从复制的过程就是主服务器上会开启一个IO线程，从服务器上开启两个线程IO线程和mysql线程。IO线程是用来通信的。主服务器上需要开启binglog配置项，当客户提交请求，在主服务器上会将过程记录在binlog中，就是我们的mysql.bin0000*这种文件中，这个文件里面会记录我们的节点位置，等一下在主从同步的时候就会用到这个节点位置。
在从服务器上会开启两个线程IO线程和mysql线程，从服务器上的IO线程用来和我们的主服务器上的IO进行通信，确定我们的节点位置和binlog日志信息，并记录一份到我们的relaylog日志中。从服务器上SQL线程会从relaylog日志中读取相关sql信息写入从库中并会记录relaylog信息，方便我们下次再查询。
3.验证主从复制
在主服务器上：mysql> drop database knightlai;
在从服务器上：
回看
[root@knightlai01 ~]# ls /data/mysql/
131.000001 131.index ib_logfile1 mysql-bin.000001 mysql-bin.index
131.000002 auto.cnf knightlai01.err mysql-bin.000002 mysql.pid
131.000003 ibdata1 localhost.localdomain.err mysql-bin.000003 performance_schema
131.000004 ib_logfile0 mysql mysql-bin.000004 test
[root@knightlai01 ~]# /usr/local/mysql/bin/mysqlbinlog /data/mysql/mysql-bin.000004
错误解决：最近在部署MySQL主从复制架构的时候，碰到了"Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work." 这个错误提示。即主从架构中使用了相同的UUID。
这个问题是因为我们克隆了虚拟机才会出现这个问题
