MySQL数据库备份与恢复实战指南

linux下导入、导出mysql数据库命令

Mysql导出导入数据库问题。不要复制的，因为看不懂。

如果从库t表数据与主库不一致，导致复制错误，整个数据库数据量很大，重做数据库sub非常慢。
仅此表中的数据？人们普遍认为修复表的数据是不可能的，因为它涉及到每个表的不一致状态。
下面列出了从备份恢复表到从库时会遇到的问题和解决方案：

场景1

如果出现错误复制后报告、忽略错误、复制过滤等方法纠正主从复制错误。
主库数据不断更新，从库数据陷入错误状态（假设GTID为aaa:1-100）。

修复步骤：

备份主库上的表t（假设备快照GTID为aaa:1-10000）；

恢复到从库；

开始复制。

这里的问题是，复制起点是aaa:101，依赖库上表t的数据状态高于其他表。
aaaa:101-10000这些事务中只要有一个事务修改了t表的数据，就会导致复制错误，比如主键冲突、记录不存在（还有aaa:101，之前报的事务）复制错误一定是修改表t的事务）

解决方案：忽略事务aaa:101-10000次中修改表t的事务开始复印。

正确修复步骤：

1.备份主库上的表t（假设备快照GTID为aaa:1-10000）并恢复到从库；

2.设置复制过滤，过滤表t：

3.开始复制，播放到aaa:10000时停止复制（此时从库上所有表的数据状态相同且一致）；

4.清除复印过滤器并开始正常复印。

注意：这里使用mysqldump--single-transaction--master-data=2记录备份快照对应的GTID

场景2

如果报出复制错误后，通过忽略错误、过滤复制等方法修复了主从复制。
主从数据库数据不断更新。

修复步骤：

在主库上备份表t（假设备快照GTID为aaa:1-10000）；

停止从数据库复制，GTID对于aaa:1-20000；

将表t恢复到从库；

开始复制。

这里的问题是复制起点是aaa:20001，aaa:10000-20000。
这些事务不会在从数据库上重放。
从库这部分数据将会丢失。

解决方案：从备份开始到复制开始，锁定表t，保证aaa:10000-20000范围内没有事务修改表t。

修复步骤true:

对表t添加读锁；

在主库上备份表t；

停止从库复制副本，恢复表t

开始复制

解锁表t。

如果是大表，可以使用可移动表空间来备份和恢复表，以减少表锁定时间。