这里是看视频总结的，有需要的直接看视频，讲得很好狂神
简介
MySQL主从复制 是一种常见的数据库复制技术，主要用于将一个MySQL数据库中的数据（称为“主库”）同步到一个或多个数据库（称为“从库”）。通过这种方式，从库能够实时（或近实时）地跟随主库的数据变化，保证主库和从库的数据一致性。它广泛应用于负载均衡、数据备份、灾备以及提升数据库查询性能等场景。
一般是与读写分离进行配合减少单台数据库压力
原理
主从复制的底层原理是通过 二进制日志（binary log） 和 中继日志（relay log） 的机制来实现的。简而言之，主库将对数据库进行的所有修改（如 INSERT、UPDATE、DELETE 操作）记录到 二进制日志 中，从库通过读取这些日志来执行相同的操作，从而实现数据同步。
- 主库记录数据变更：每当主库执行修改数据的操作时，它会将这些操作记录到二进制日志中。
- 从库获取日志：从库的 I/O 线程会定期从主库请求最新的二进制日志（由主库的文件名和位置决定），并将其保存到本地的中继日志中。
- 从库应用日志：从库的 SQL 线程会从中继日志中读取事件并在本地执行这些操作，从而确保主库和从库的数据一致性。
实现
编写主库
编辑MySQL配置文件（my.cnf 或 my.ini） 打开主库的配置文件
打开二进制日志
> vim /etc/my.cnf
[mysqld]
## 同一局域网内注意要唯一
server-id=100
## 开启二进制日志功能，可以随便取（关键）
log-bin=mysql-bin
## 复制过滤：不需要备份的数据库，不输出（mysql库一般不同步）
binlog-ignore-db=mysql
## 为每个session 分配的内存，在事务过程中用来存储二进制日志的缓存
binlog_cache_size=1M
## 主从复制的格式（mixed,statement,row，默认格式是statement）
binlog_format=mixed编写从库
开启中断日志
> vim /etc/my.cnf
[mysqld]
## 设置server_id,注意要唯一
server-id=102
## 开启二进制日志功能，以备Slave作为其它Slave的Master时使用
log-bin=mysql-slave-bin
## relay_log配置中继日志
relay_log=edu-mysql-relay-bin
##复制过滤：不需要备份的数据库，不输出（mysql库一般不同步）
binlog-ignore-db=mysql
## 如果需要同步函数或者存储过程
log_bin_trust_function_creators=true
## 为每个session 分配的内存，在事务过程中用来存储二进制日志的缓存
binlog_cache_size=1M
## 主从复制的格式（mixed,statement,row，默认格式是statement）
binlog_format=mixed
## 跳过主从复制中遇到的所有错误或指定类型的错误，避免slave端复制中断。
## 如：1062错误是指一些主键重复，1032错误是因为主从数据库数据不一致
slave_skip_errors=1062
配置master授权slave
mysql > mysql -uroot -pmaster的密码
# 授予slave服务器可以同步master服务
mysql > grant replication slave, replication client on *.* to 'root'@'slave服务的ip' identified by 'slave服务器的密码';
mysql > flush privileges;
# 查看MySQL现在有哪些用户及对应的IP权限(可以不执行，只是一个查看)
mysql > select user,host from mysql.user;
查询binlog和位置
后续配置slave节点连接master节点时候使用
mysql > show master status;
slave关联master
mysql> change master to master_host='master服务器ip', master_user='root', master_password='master密码', master_port=3306, master_log_file='mysql-bin.000002',master_log_pos=2079;
查看状态
注意，主节点和从节点配置完都要启动数据库
mysql> show slave status\G;
问题
一般有连接不成功的，一般是主节点二进制文件名字，位置配置不对，或者密码错误，重写尝试
其他
异步复制与同步复制
MySQL 主从复制默认是 异步复制，即主库提交事务后立即返回，不等待从库的确认。主库的事务提交并不依赖于从库的执行情况，这样可以提高性能。但是，这也可能导致数据不一致的情况——即如果主库提交了事务，而从库未能及时应用相应的日志，主库与从库的数据就会不一致。
MySQL也支持 半同步复制（Semi-Synchronous Replication），在这种模式下，主库在提交事务后等待至少一个从库确认收到日志并准备好复制数据后才返回客户端。这样能够确保主从数据一致性，但可能会增加一些延迟。
复制错误和恢复
在主从复制过程中，可能会出现复制错误，例如由于从库的 SQL 线程遇到无法执行的事件或网络问题导致复制中断。常见的错误包括：
丢失的事件：如果某些事件丢失或无法获取，可能导致从库的复制停止。
SQL 错误：如果从库在执行某个操作时发生错误（如表结构不同），会导致复制失败。
这种情况下，可以通过执行 STOP SLAVE 停止复制，然后使用 START SLAVE UNTIL 指令跳过错误的事件，或者手动修复错误后再恢复复制。
从库一致性问题
如果从库出现了异常，恢复其与主库的数据一致性可以通过以下几个步骤：
检查复制状态
首先需要检查从库的复制状态，使用以下命令来检查复制进程：
SHOW SLAVE STATUS\G
注意查看以下字段：
Slave_IO_Running：如果为 No，表示从库没有获取到主库的二进制日志。
Slave_SQL_Running：如果为 No，表示从库的 SQL 线程没有执行主库的事件。
Last_Error：如果有错误，表明复制过程中发生了问题，需要根据错误信息排查原因。
从库恢复主库数据
如果发现从库和主库的数据不一致，或者复制停止了，可以采取以下步骤来恢复从库的复制。
方法一：重新启动复制进程
如果从库停止了复制进程，可以尝试重新启动复制。
停止从库的复制进程：
STOP SLAVE;
检查主库的二进制日志位置 在主库执行以下命令，查看当前主库的二进制日志文件和位置：
SHOW MASTER STATUS;
记录下返回的 File（二进制日志文件）和 Position（日志位置）。
重置从库的复制配置： 如果复制停止的原因是主库日志丢失或者位置不对，可以使用 CHANGE MASTER TO 命令来重新设置从库的复制配置：
CHANGE MASTER TOMASTER_HOST = '主库的IP或域名',MASTER_USER = '复制用户',MASTER_PASSWORD = '复制用户密码',MASTER_LOG_FILE = '主库的日志文件',MASTER_LOG_POS = 主库的日志位置;
启动复制进程：
START SLAVE;
验证复制是否恢复正常： 再次使用 SHOW SLAVE STATUS\G 命令确认 Slave_IO_Running 和 Slave_SQL_Running 都为 Yes，并且没有错误。
方法二：重新同步从库数据
如果从库数据严重不一致，恢复复制的一个更安全的方法是完全重新同步从库。这意味着从库会清除现有的数据并重新从主库同步。
停止从库的复制进程：
STOP SLAVE;
清空从库的数据（谨慎操作，确保备份数据）： 如果从库的数据与主库严重不一致，可以选择清空从库的数据，使其与主库的数据同步。可以使用 RESET SLAVE 或者手动删除数据库表。
RESET SLAVE ALL;
重新配置从库：清空数据后，可以将从库重置为主库的一个全新的备份。
可以通过 数据备份恢复 的方式，将主库的数据全量同步到从库。
可以使用 mysqldump 导出主库数据，然后将其导入到从库，或者直接通过复制（使用 rsync、scp 等工具）将主库的数据文件复制到从库。
启动从库复制： 完成备份恢复后，设置从库重新与主库连接并启动复制进程：
CHANGE MASTER TOMASTER_HOST = '主库的IP或域名',MASTER_USER = '复制用户',MASTER_PASSWORD = '复制用户密码',MASTER_LOG_FILE = '主库的日志文件',MASTER_LOG_POS = 主库的日志位置;
然后启动复制：
START SLAVE;
确认从库的复制是否恢复。
防止主从复制停滞的措施
为了避免主从复制停滞，可以采取以下几种措施：
监控复制状态：定期监控主从复制的状态，确保 Slave_IO_Running 和 Slave_SQL_Running 状态正常。可以通过自动化工具定期检查复制状态。
网络质量保障：主库和从库之间的网络稳定性很重要，避免网络问题导致复制延迟或丢失。
复制延迟监控：可以设置警报来监控复制延迟（Seconds_Behind_Master），当延迟超过一定阈值时，可以触发报警或自动处理。
考虑使用半同步复制：虽然半同步复制会增加一定的延迟，但它能确保主库在提交事务后，至少一个从库已经接收到并保存了相关日志，避免了复制数据丢失的风险。
监控复制状态（参考）
写一个java程序，定时查询数据库 Slave_IO_Running 和 Slave_SQL_Running 状态。一旦为no,就直接预警，可以通过发短信，发邮件等方式，或者在平台上发公告