1.原理分析
三个线程
1.实际上主从同步的原理就是基于 binlog 进行数据同步的。在主从复制过程中，会基于 3 个线程来操作， 一个主库线程，两个从库线程。
2.二进制日志转储线程（ Binlog dump thread ）是一个主库线程。当从库线程连接的时候， 主库可以将二进制日志发送给从库，当主库读取事件（Event ）的时候，会在 Binlog 上加锁，读取完成之
后，再将锁释放掉。
3.从库 I/O 线程会连接到主库，向主库发送请求更新 Binlog 。这时从库的 I/O 线程就可以读取到主库 的二进制日志转储线程发送的 Binlog 更新部分，并且拷贝到本地的中继日志 （ Relay log ）。
4.从库 SQL 线程会读取从库中的中继日志，并且执行日志中的事件，将从库中的数据与主库保持同步。
复制三步骤
步骤 1 ： Master 将写操作记录到二进制日志（ binlog ）。
步骤 2 ： Slave 将 Master 的 binary log events 拷贝到它的中继日志（ relay log ）；
步骤 3 ： Slave 重做中继日志中的事件，将改变应用到自己的数据库中。 MySQL 复制是异步的且串行化的，而且重启后从接入点开始复制。
具体操作：
1.slaves端中设置了master端的ip，用户，日志，和日志的Position，通过这些信息取得master的认证及
信息
2.master端在设定好binlog启动后会开启binlog dump的线程
3.master端的binlog dump把二进制的更新发送到slave端的
4.slave端开启两个线程，一个是I/O线程，一个是sql线程：
i/o线程用于接收master端的二进制日志，此线程会在本地打开relaylog中继日志，并且保存到本地磁盘
sql线程读取本地relog中继日志进行回放
5.什么时候我们需要多个slave？
当读取的而操作远远高与写操作时。我们采用一主多从架构
数据库外层接入负载均衡层并搭配高可用机制
2.配置****mastesr
[root@mysql1 ~]# vim /etc/my.cnf
配置完后要重新启动服务
[root@mysql1 ~]#/etc/init.d/mysqld restart
参数说明：
server-id MySQL服务ID
super_read_only=on on 表示只读 ， 默认是可写可读的
log_bin=mysql-bin # 开启bin-log日志
进入数据库配置用户权限：
[root@mysql1 ~]# mysql -uroot -p123123
##生成专门用来做复制的用户，此用户是用于slave端做认证用
mysql> CREATE USER 'repl'@'%' IDENTIFIED BY '123123';
##对这个用户进行授权，给予权限
mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%';
##查看master的状态
mysql> SHOW MASTER STATUS;
3.配置slave
[root@mysql2 ~]# vim /etc/my.cnf
配置完后要重新启动服务
[root@mysql2 ~]#/etc/init.d/mysqld restart
进入数据库配置所属master：
mysql> CHANGE MASTER TO
MASTER_HOST='172.25.254.10',
MASTER_USER='repl',MASTER_PASSWORD='123123',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=350;
启动slave服务；
mysql> start slave;
Query OK, 0 rows affected (0.01 sec)
查看服务的连接情况：
mysql> SHOW SLAVE STATUS\G;
查看到的结果：
mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.25.254.10
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 350
Relay_Log_File: mysql-node2-relay-bin.000002
Relay_Log_Pos: 320 Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 350
Relay_Log_Space: 533
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: 888d2164-4b05-11ef-a049-000c299355ea
Master_Info_File: /data/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more
updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec
查看到这两个的连接显示yes则表示连接成功。
注：
当有数据时，在创建一个slave2主机连接时，需要先锁表，确保备份后数据一致：
mysql> FLUSH TABLES WITH READ LOCK;
备份后再解锁：
mysql> UNLOCK TABLES;
#利用master节点中备份出来的lee.sql在slave2中拉平数据
[root@mysql-node3 ~]# mysql -uroot -plee -e "create database lee;"
[root@mysql-node3 ~]# mysql -uroot -p lee <lee.sql
[root@mysql-node3 ~]# mysql -uroot -plee -e "select * from lee.userlist;"
mysql: [Warning] Using a password on the command line interface can be insecure.
+----------+----------+
| username | password |
+----------+----------+
| user1 | 123 |
| user2 | 123 |
+----------+----------+
4.延迟复制
MySQL延迟复制原理是通过在从库上设置延迟时间，使得SQL线程在执行主库传来的Binlog事件前等待指定时间，以此实现从库数据相对于主库的滞后更新。这一特性在数据保护、审计、分析和特定行业合规性要求等方面具有重要价值，但同时也需注意其带来的延迟风险、管理复杂性和资源消耗问题。
工作原理
步骤如下：
主库操作与日志记录：主库接受客户端的写操作，完成事务处理并在事务提交时将数据变更记录到二进制日志（Binlog）中。
日志传输：从库的I/O线程连接主库，请求并接收主库的Binlog事件，这些事件按顺序写入到从库的中继日志（Relay Log）。
延迟等待：当新的Binlog事件到达从库后，SQL线程并不立即执行它们。相反，SQL线程会检查每个事件是否已达到设定的延迟时间。如果未达到，SQL线程会等待直到延迟时间届满。
事件重放：一旦延迟时间过去，SQL线程开始执行Relay Log中的事件，将主库的更新操作应用到从库的数据库中，从而实现数据的延迟同步。
延迟复制时用来控制sql线程的，和i/o线程无关。
（这个延迟复制不是i/o线程过段时间来复制，i/o是正常工作的。）
是日志已经保存在slave端了，那个sql要等多久进行回放。
在slave端：
mysql> STOP SLAVE SQL_THREAD;
mysql> CHANGE MASTER TO MASTER_DELAY=60; 设置的参数时间为60
mysql> START SLAVE SQL_THREAD;
mysql> SHOW SLAVE STATUS\G;
Master_Server_Id: 1
Master_UUID: db2d8c92-4dc2-11ef-b6b0-000c299355ea
Master_Info_File: /data/mysql/master.info
SQL_Delay: 60 ##延迟效果
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
测试：
在 master 中写入数据后过了延迟时间才能被查询到。