问题1: 同步数据 Slave_IO_Running :yes Slave_SQL_Running: no
出现问题原因:
主库存在表/数据,从库不存在,同步时从库出现异常,查询错误日志也可以查询到是执行sql失败
解决放法:
需要先停止同步 slave stop
stop slave;
set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
start slave;
第一次操作完毕之后，输入命令show slave status; ，发现还是没变，在操作了一次
SQL_SLAVE_SKIP_COUNTER:是 MySQL 复制中的一个系统变量，它用于控制从服务器（slave）在复制错误时跳过的事务数量。当从服务器遇到复制错误时，例如数据不一致或格式错误，管理员可能希望跳过某些事务，以便复制可以继续进行。
要使用 SQL_SLAVE_SKIP_COUNTER，您应该首先了解为什么复制失败，并确定跳过事务是否是一个安全的操作。在某些情况下，跳过事务可能会导致数据不一致。
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = N;
注: 一定要了解这个操作是否需要跳过,否则会导致数据不一致
问题2: ibd恢复数据时,用来恢复的ibd文件损坏/有问题导致MySQL异常停止
出现问题原因
在进行ibd文件恢复数据时.因ibd文件损坏,进行恢复时.报表空间异常.这时重新启动mysql,查询日志一直报错,并且连接不上mysql.
解决放法:
注: 因本次是用ibd文件恢复数据,并且提前已经存在数据备份.数据库主从设置,并且从库完全正常(断开主从同步)的情况下进行操作的.
0: 停止mysql
1: 在my.ini配置文件中设置innodb_force_recovery=2
[mysqld]
innodb_force_recovery=2
2: 然后启动mysql
3: drop 掉报错的表
4: 关闭mysql
5: 删除innodb_force_recovery=2配置
6: 重启启动mysql
innodb_force_recovery
innodb_force_recovery 可以接受的值范围从 0 到 6，每个值代表不同的恢复模式：
- 0（默认值）：不进行任何强制恢复操作，InnoDB 会尝试进行正常的启动和恢复过程。
- 1（SRV_FORCE_IGNORE_CORRUPTION）：允许服务器运行，即使检测到损坏的页。这可以帮助导出数据，但可能会引入更多损坏。
- 2（SRV_FORCE_NO_BACKGROUND）：防止主线程和从属线程合并插入缓冲区、更改缓冲区和重做日志。这可以帮助减少崩溃的风险，但会降低性能。
- 3（SRV_FORCE_NO_TRX_UNDO）：不执行事务回滚操作。这可以在回滚段损坏时使用，但会留下未提交的事务。
- 4（SRV_FORCE_NO_IBUF_MERGE）：防止插入缓冲区的合并操作。这有助于减少崩溃的风险，并允许更多的数据导出。
- 5（SRV_FORCE_NO_UNDO_LOG_SCAN）：不查看重做日志中的撤销信息。这有助于在撤销日志损坏时使用。
- 6（SRV_FORCE_NO_LOG_REDO）：不执行重做日志中的任何操作。这可以在重做日志损坏时使用，但可能会导致大量数据丢失。
