Master
（1）从库执行 change master to 语句，会立即将主库信息记录到master.info中
（2）从库执行 start slave语句，会立即生成IO_T和SQL_T
（3）IO_T 读取master.info文件，获取到主库信息
（4）IO_T 连接主库，主库会立即分配一个DUMP_T,进行交互
（5）IO_T 根据master.info binlog信息，向DUMP_T请求最新的binlog
（6）主库DUMP_T,经过查询，如果发现有新的，截取并反回给从库IO_T
（7）从库IO_T会收到binlog，存储在TCP/IP缓存中,在网络底层返回ACK
（8）从库IO_T会更新master.info ,重置binlog位置点信息
（9）从库IO_T会将binlog，写入到relay-log中
（10）从库SQL_T 读取Relay-log.info 文件，获取上次执行过的位置点
（11）SQL_T按照位置点往下执行relaylog日志
（12）SQL_T执行完成后，重新更新relay-log.info
（13）relaylog定期自动清理的功能。
START SLAVE时：
主服务器上创建Binlog Dump线程。
超时断开设置：net_write_timeout（秒）
重试次数net_retry_count（10次）
从服务器I/O线程读取主服务器Binlog Dump线程发送的内容并将该数据拷贝到从服务器数据目录中的本地文件中，即中继日志。
从服务器SQL线程，是从服务器创建用于读取中继日志并执行日志中包含的更新
[mysqld]
server-id=1
# 启用二进制日志
log-bin=/data/master-bin #二进制日志文件的路径
log_bin_index =master-bin.index
binlog_do_db=witkey ##witkey是要同步的数据库的名称
binlog_ignore_db=mysql
binlog-ignore-db=information_schema # 表示不同步information_schema库
binlog-ignore-db=performance_schema
binlog-ignore-db=sys
user=mysql
character_set_server=utf8mb4
innodb_file_per_table = ON
skip_name_resolve = ON
binlog_format=mixed #row
Slave
## 初始化数据库
/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf --initialize --user=mysql --basedir=/data/mysql/mysql --datadir=/data/mysql/data --innodb_undo_tablespaces=3 --explicit_defaults_for_timestamp #初始化mysql
根据my.cnf的error.log，查看初始密码
grep 'password' /data/mysql/log/mysql-error.log
## 备份主库数据
--master-data=2 备份时刻记录master的Binlog位置和Position
--single-transaction 获取一致性快照
-R 备份存储过程和函数
--triggres 备份触发器
-A 备份所有的库
-set-gtid-purged=off 不启用gtid
# mysqldump -uroot -p'' --master-data=2 --single-transaction -R --triggers -A | gzip > /tmp/mysql_all.sql.gz
[mysqld]
server-id=2
#从库提高性能可以不开bin-log日志
#log-bin=/data/salve-bin
#或设置sync_binlog, 1、500、10000；每进行n次事务提交之后binlog写入磁盘
sync_binlog=500
#0 redo日志缓冲区中的数据每秒一次地写入日志文件中
#1 每次提交都需要把日志写入磁盘
#2 由操作系统来决定
#0、效率最高；1、最安全，但是效率最低；2、安全和效率平衡的取舍，在服务器系统挂掉的情况下会丢失数据；
innodb_flush_log_at_trx_commit = 0
character_set_server=utf8mb4
# slave需要开启中继日志
relay-log=slave-relay-bin
relay-log-index=slave-relay-bin.index
slave_parallel_workers=4 #根据实际情况决定开启多少个线程用于主从复制
slave_parallel_type=logical_clock #基于组提交的并行复制方式
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON
log-slave-updates = true
# 从库read-only 只对非super用户生效，对root用户无效
read_only=ON
# skip_slave_start,除非使用START SLAVE命令,否则从服务器不会开始复制。从服务器重启复制不自动开始
# 设置log_slave_updates,让从服务器更新记录日志,有助于在必要时把从切换成主。
# 在 MySQL 5.6 版本时，基于 GTID 的复制中 log-slave-updates 选项是必须的。但是其增大了从服务器的IO负载, 而在 MySQL 5.7 中该选项已经不是必须项。
GRANT REPLICATION SLAVE ON *.* TO 'master'@'%' identified by '123456';
FLUSH PRIVILEGES;
grant FILe on *.* to 'master'@'%';
flush tables with read lock;
unlock tables;
SHOW full PROCESSLIST；
show slave hosts;
show binary logs;
show binlog events in 'mysql-bin.000001';
change master to master_host='192.168.137.130', master_port=3306, master_user='master', master_password='123456', master_log_file='master-bin.000008', master_log_pos=106;
stop slave;
set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
start slave IO_THREAD;
start slave SQL_THREAD;
SHOW PROCESSLIST；
show slave status;
数据库UUID相同导致冲突
vim /var/lib/mysql/auto.cnf
生产场景下如何保证主库上的用户可以有写权限，从库上的用户只有读权限
排除mysql系统库的同步, 分别在主库上创建可以写的用户，在从库上创建只能读的用户
在主库上创建可以读写的用户，然后在从库中从新回收用户的写权限；
在主库和从库上创建不同的用户，然后分别授予不同的权限，使得主库只能写，从库只能读
