MySQL主库已经有数据库，如何让从库同步主库数据，MySQL主从同步

1.配置主库my.cnf文件，主库配置log-bin和server-id参数，从库配置server-id，不能和主库及其他从库一样，一般不开启从库log-bin功能，
注意：配置参数后要重启生效。
log-bin=mysql-bin
server-id       = 1

登录主库检查是否开启成功，看目录下是否有logbin日志，或者登录主库的mysql通过下面的命令检查状态，等于ON。
show variables like "log_bin";

2.登录主库增加用于从库连接主库同步的账户例如：rep，并授权replication slave同步的权限。
grant replication slave on *.* to 'rep'@'192.168.1.%' identified by 'shnne123456';
flush privileges;

3.备份主库所有需要的数据库
备份单个库
mysqldump -F --single-transaction --master-data=1 --complete-insert -uroot -pshnne2011 --opt ab1 > ab1.sql
备份多个库
mysqldump -F --single-transaction --master-data=1 --complete-insert -uroot -pshnne2011 --opt --databases ab1 ab2 ab3 > all.sql

4.从库的配置只要server-id和主库不同即可，忽略掉不需要的数据库,修改配置文件后需要重启数据库才能生效。
server-id    = 2
slave-skip-errors = 1062
replicate-ignore-db=information_schema,mysql,performance_schema,test
replicate_wild_ignore_table=mysql.%
replicate_wild_ignore_table=information_schema.%
replicate_wild_ignore_table=performance_schema.%
replicate_wild_ignore_table=test.%
relay_log_recovery = ON
重启数据库，然后还原整个库，查看备份sql备份里面的pos
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.016236', MASTER_LOG_POS=114;
然后登陆从库
执行
CHANGE MASTER TO MASTER_HOST='192.168.1.101',MASTER_PORT=3306,MASTER_USER='rep',MASTER_PASSWORD='shnne123456',MASTER_LOG_FILE='mysql-bin.00001',MASTER_LOG_POS=114;
在start slave;

附：
replicate-do-db    设定需要复制的数据库
replicate-ignore-db 设定需要忽略的复制数据库
replicate-do-table  设定需要复制的表
replicate-ignore-table 设定需要忽略的复制表
replicate-wild-do-table 同replication-do-table功能一样，但是可以通配符
replicate-wild-ignore-table 同replication-ignore-table功能一样，但是可以加通配符




5.如果已经开启过主从，将备份的库拷贝到从库，登陆从库，stop slave,
如果是单个库备份，需要先创建在还原，
如果是多个库的备份，直接执行还原
然后在start slave;
查看状态并测试
show slave status\G


7.从库变主库，
stop slave io_thread 
stop slave;
reset slave all;(如果没有删除master.info，手动删除)
删除my.cnf里的修改的内容，如
server-id = 1
忽略的复制库
然后重启数据库


==============================================================================================================================================
Last_Error: Relay log read failure: Could not parse relay log event entry. 
The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), 
the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), 
a network problem, or a bug in the master's or slave's MySQL code. 
If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.

这个报错是 MySQL 主从复制中非常经典的 1594 错误，意思是“中继日志（relay log）读取失败”。
通常是因为服务器突然宕机、断电、磁盘异常或者网络波动，导致从库的中继日志文件损坏或不完整。别担心，这个问题有非常成熟的修复方案。
你可以按照以下步骤来排查和恢复：
?️ 第一步：定位断点
首先在从库执行 SHOW SLAVE STATUS\G，找到以下两个关键信息，它们代表了从库已经成功执行到的位置：
Relay_Master_Log_File：例如 mysql-bin.000123（这是主库的 binlog 文件名）
Exec_Master_Log_Pos：例如 950583017（这是在该 binlog 文件中已经执行到的位置点）
? 第二步：重新指向主库同步（核心修复步骤）
既然当前的 relay log 已经损坏无法解析，我们就跳过它，直接告诉从库：“从我上次执行完的位置开始，重新去主库拉取日志吧！”
请在从库依次执行以下 SQL 命令（注意替换为你刚才查到的实际值）：
-- 1. 停止复制进程
STOP SLAVE;

-- 2. 重新指定主库的同步起点（使用第一步获取的文件名和位置点）
CHANGE MASTER TO 
  MASTER_LOG_FILE='mysql-bin.000123', 
  MASTER_LOG_POS=950583017;

-- 3. 重新启动复制进程
START SLAVE;
执行完毕后，再次运行 SHOW SLAVE STATUS\G，观察 Slave_IO_Running 和 Slave_SQL_Running 是否都变成了 Yes，以及 Seconds_Behind_Master 是否开始正常追平。
? 补充建议与预防
自动恢复配置：为了避免以后遇到类似问题需要手动干预，强烈建议在从库的配置文件中开启 relay_log_recovery = ON。这样当从库意外重启且发现 relay log 损坏时，MySQL 会自动丢弃损坏的中继日志，并重新向主库拉取，实现自愈。
GTID 模式注意事项：如果你的数据库开启了 GTID 模式，上述的 CHANGE MASTER TO 语法可能会有所不同（通常不需要指定具体的文件和位置，GTID 会自动处理），或者在跳过事务时需要使用 SET GTID_NEXT 配合空事务的方式。
数据一致性校验：虽然这种修复方式能迅速恢复复制，但因为跳过了损坏的那一小段日志，理论上存在极小的数据不一致风险。如果业务对数据一致性要求极高，建议在恢复后找时间通过工具（如 pt-table-checksum）做一次主从数据校验。
按照上面的步骤操作，大概率就能解决你的问题啦！如果在执行过程中遇到其他报错，可以随时把新的状态发给我看看。



开启 relay_log_recovery 非常简单，但因为它是一个只读变量，不能通过 SQL 命令动态修改，必须修改 MySQL 的配置文件并重启服务才能生效。
你可以按照以下步骤来操作：
?️ 第一步：修改 MySQL 配置文件
找到你的 MySQL 配置文件（Linux 系统通常是 /etc/my.cnf 或 /etc/mysql/my.cnf），在 [mysqld] 这一栏下面添加一行配置：
[mysqld]
relay_log_recovery = ON
保存并退出文件。
? 第二步：强烈建议配合开启表存储模式（Crash Safe）
为了让 relay_log_recovery 发挥最完美的效果，强烈建议你同时确保复制元数据是保存在数据库表中，而不是文件中。这样在服务器意外宕机时，MySQL 能更准确地定位到恢复点，避免数据不一致。
如果你是 MySQL 8.0 及以上版本：默认已经是表存储模式，无需额外配置。
如果你是 MySQL 5.7 及以下版本：建议在同一个配置文件的 [mysqld] 下追加以下两行：
master_info_repository = TABLE
relay_log_info_repository = TABLE
? 第三步：重启 MySQL 服务
修改完配置文件后，需要重启 MySQL 服务让配置生效。根据你的操作系统，可以使用以下命令之一：
systemctl restart mysqld
service mysql restart
✅ 第四步：验证是否开启成功
MySQL 服务启动后，登录到从库的 MySQL 命令行，执行以下命令查看参数状态：
SHOW VARIABLES LIKE 'relay_log_recovery';
如果返回的结果中 Value 显示为 ON，就说明自动恢复功能已经成功开启了。
开启这个功能后，以后如果遇到服务器突然断电或宕机导致中继日志损坏，MySQL 会在下次启动时自动丢弃损坏的 relay log，并从主库重新拉取缺失的日志，实现“自愈”，大大减少了手动修复的麻烦！