企业级mysql主从不一致恢复及切换

💡 主从不一致恢复：数据量相差较大时：

步骤一：主库（数据完整的）备份：

mysqldump -h127.0.0.1 -uroot -p123456 --all-databases --master-data=1 --single-transaction --max_allowed_packet=4G > all.sql

--master-data=1：这个选项在备份文件中添加 CHANGE MASTER TO 语句，这个语句包含了主库的二进制日志文件名和位置，方便在恢复备份后重新配置主从复制。
--single-transaction：这个选项确保备份操作在一个事务中完成，这可以确保备份的数据的一致性。
--max_allowed_packet=4G：这个选项指定了 mysqldump 命令允许的最大数据包大小，这里设置为 4GB，以确保大型数据库的备份也能顺利进行。
MySQL 默认的 max_allowed_packet 参数值较小，通常情况下是 4MB。当你备份的数据较大时，可能会出现单个数据包大小超过这个限制而导致备份失败的情况。
通过设置 --max_allowed_packet=4G，你扩大了允许的最大数据包大小，以确保备份过程中不会因为数据包大小限制而导致失败。

步骤一ps：为防止命令行客户端断开 后台运行脚本（sql较大）

#!/bin/bash

# 记录开始时间
echo "开始时间：$(date '+%Y-%m-%d %H:%M:%S')" >> backup.log

# 执行数据库备份命令
mysqldump -h127.0.0.1 -uroot -pfingard@1 --all-databases --master-data=1 --single-transaction --max_allowed_packet=4G > all.sql

# 记录结束时间
echo "结束时间：$(date '+%Y-%m-%d %H:%M:%S')" >> backup.log

导入新sql后发现存储过程并未导入：

单独导出一下存储过程：

mysqldump -u 用户名 -p 数据库名 --routines --no-create-info --no-data > procedures.sql

数据库a传输数据到数据库b（数据量较大 服务器传输）

两边服务器建传输用户：

useradd rsyncq
echo "Fingard@2" | passwd --stdin rsyncq
echo "rsyncq ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers

从数据库b同步数据库a的sql文件（50g）

rsync -avz user@10.185.104.123:/home/mysqlbeifen/all.sql /home/dbbeifen/

步骤二：获取主库的二进制日志文件名和位置

cat all.sql | grep "CHANGE MASTER TO MASTER_LOG_FILE"

这个命令的目的是在备份文件 all.sql 中查找包含字符串 "CHANGE MASTER TO MASTER_LOG_FILE" 的行。
这个字符串通常在使用 --master-data=1 参数进行备份时会被包含在备份文件中，它包含了主库的二进制日志文件名和位置，以便在恢复备份后重新配置主从复制。
如果在 all.sql 文件中存在这样的行，它将显示出来。如果没有显示任何内容，则意味着备份文件中没有包含这样的信息，可能是因为备份过程中没有正确设置 --master-data=1 参数。

也可以在主库show master status;

步骤三：登录从库

#停止主从同步
stop slave
#重新设置主从同步的位置
reset slave

#从库设置为读写 不然删不掉库
set global read_only=0;
#删掉从库数据库，msyql自带数据库不需要删掉（information_schema，mysql，performance_schema，sys）
drop database 库名;

#导入数据
source all.sql
#重新配置主从同步的位置,具体的master_log_file以及master_log_pos内容可以从备份文件中获取   ip是主库ip
change master to master_host='10.185.104.91',master_port=3306,master_user='root',master_password='123456',master_log_file='xxx',master_log_pos=xxx;
#启动主从同步
start slave;
#检查主从同步状态
show slave status;

#从库设置未只读
set global read_only=1;

步骤四：主从关系切换

question1：单纯的重启数据库会导致主从关系断掉么？

A:在理想情况下，重启 MySQL 数据库应该不会导致主从关系的破坏。主从关系的配置通常是持久化的，它们存储在配置文件中或者直接在数据库中。因此，重启数据库应该不会影响主从关系的配置。 但是，有几种情况可能导致主从关系出现问题： 001 配置文件更改未保存：如果在修改主从配置后，但在重启之前没有保存配置文件的更改，那么重启后可能会丢失这些更改，从而导致主从关系不正常。 002 数据不一致：如果在重启期间，主库和从库之间的数据同步出现问题，可能会导致主从关系不一致。这可能发生在重启期间的网络问题、服务器故障或其他未知问题导致的数据丢失。 003 版本不兼容：在升级 MySQL 版本或者在不同版本的 MySQL 实例之间迁移主从关系时，可能会出现主从关系破坏的问题。

 💡 综上所述，虽然理论上重启 MySQL 数据库不应该导致主从关系的破坏，但在实践中，一些因素可能导致主从关系出现问题。因此，在进行重启之前，建议确保主从关系的配置已经保存并且数据同步正常，以尽量避免出现问题。同时，在重启之后，建议立即检查主从关系并确保它们正常工作。

那如果要进行主从切换需要怎么做？ 原来的主库：A 原来的从库：B

停止复制进程：在原来的从库B上停止复制进程。

STOP SLAVE;
#设置为读写
set global read_only=0;    #1是只读，0是读写
show global variables like '%read_only%';

查看当前复制状态：确保停止了复制进程后，查看从库B当前的复制状态。

SHOW SLAVE STATUS\\G

#确保 Slave_IO_Running 和 Slave_SQL_Running 均为 No。
SHOW MASTER STATU;

#记住查出来的信息作为新从库连接现在操作这个库的信息。

重新配置从库为主库：将原来的从库重新配置为一个新的主库。这包括更新主从配置，使其指向自己。原来的主库重新配置为新的从库：

#操作原来的主库A
STOP SLAVE;

#原来的主库A更改为从库  master_log_file='mysql-bin.000002', master_log_pos=2048 这俩值在上面查出来的
change master to master_host='10.185.104.xx', master_user='slave', master_password='Hz123456', master_log_file='mysql-bin.000002', master_log_pos=2048;

#主库A操作
START SLAVE;

#检查状态
SHOW SLAVE STATUS\\G
#双yes为ok

#设置为只读
set global read_only=1;    #1是只读，0是读写
show global variables like '%read_only%';

完成以上步骤后，你应该已经成功地进行了主从切换，旧的从库现在是新的主库，而原来的主库现在是新的从库。请确保在进行切换之前做好充分的准备工作，并仔细验证切换后的主从关系以确保数据的完整性和一致性。