1.mysql主从备份基本原理
mysql支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。mysql复制基于主服务器在二进制日志中跟踪所有对数据库的更改(更新、删除等等)。因此，要进行复制，必须在主服务器上启用二进制日志。每个从服务器从主服务器接收主服务器已经记录到的二进制日志，获取日志信息更新。通过设置在Master上的binlog，使其处于打开状态；Slave通过一个I/O线程从Master上读取binlog，然后传输到Slave的中继日志中，然后使用SQL线程读取中继日志，并应用到自身数据库中，从而实现主从数据同步功能。
前提：mysql数据库主从数据库的版本最好一样，小版本编码不一样也可以，比如：5.7.20备份到5.7.11。
2.主数据库迁移
在做数据库主从备份之前，首先要确定需要备份的具体数据库，若该数据库为新建数据库，只有表结构，可导出主数据库的sql脚本，导入到从数据库中执行，使主数据库与从数据库的结构相同。
若该数据库已经存在存储信息，则需要锁定主数据库，暂时不让任何程序操作数据库，导出主数据库sql脚本，从数据库执行sql脚本，保证在做主从备份之前，主从数据库的结构，存储信息一致。也可采用Navicat Premium等数据库管理工具，直接做数据传输操作。如图：
3.windows环境下主从备份操作
<1>主数据库master配置
1.打开mysql数据库的基础配置文件，可在服务中查看mysql启用的配置文件信息，若发现在服务器中没有该配置文件，请设置服务器把隐藏的文件也展示出来。参考截图如下：
2.打开my.ini配置文件，设置主数据库的参数信息，主要设置字段为server-id,log_bin,binlog_do_db ，其他字段参考参数定义自行设置， 配置文件中相关参数定义如下：
| 参数 | 意义 |
|---|---|
| server-id | 数据库唯一ID，一组主从中此标识号不能重复。其中1 代表主数据库（源） 2代表辅数据库（目的） |
| log_bin | 开启bin-log，并指定文件目录和文件名前缀 |
| binlog_do_db | 需要同步的数据库名字，可以是多个，之间用分号分割 |
| binlog_ignore_db | 不需要同步的数据库名字 |
| max_binlog_size | 每个bin-log最大大小，当此大小等于500M时会自动生成一个新的日志文件。一条记录不会写在2个日志文件中，所以有时日志文件会超过此大小。 |
| binlog_cache_size | 日志缓存大小 |
| binlog-do-db | 需要同步的数据库名字，如果是多个，就以此格式在写一行即可。 |
| binlog-ignore-db | 不需要同步的数据库名字，如果是多个，就以此格式在写一行即可。 |
| expire_logs_day | 设置bin-log日志文件保存的天数，此参数mysql5.0以下版本不支持。 |
| binlog_format | bin-log日志文件格式，设置为MIXED可以防止主键重复。 |
3.主服务器创建允许从服务器同步数据的账户：
4.重启mysql服务，查看master状态，查看命令：show master status;
<2>从数据库slave配置
1.打开从服务器的my.ini配置，设置从数据库参数信息，设置字段信息server-id,binlog_do_db 。slave库上建议把一些重要的选项开启，例如设置为read only、relay_log_recovery、sync_master_info、sync_relay_log_info、sync_relay_log这些重要选项开启。
2.停止slave服务，指令为：stop slave;
3.配置从服务器，开启同步模式，关键参数如下：
在设置同步模式时，需要保证主从服务器所在的网络是相通的，配置的文件日志名称，索引位置与主服务器查询的信息一致。
4.启动slave服务，指令为：start slave;
5.重启mysql服务，查看从数据库同步状态，查看指令为：show slave status;当查询的Slave_IO_Running: Yes，Slave_SQL_Running: Yes时，表示同步状态正常，主从配置成功。
4.linux环境下主从备份操作
通过分析mysql主从备份的原理，它本身是基于主数据库的二进制日志备份的，所以，主从备份本身受操作系统的影响较小，在linux环境下面配置主从备份与在windows下面配置主从备份操作步骤相同，修改参数也相同。唯一不同点是linux版本数据库的配置文件是my.cnf，一般在/etc/my.cnf下面，修改主从数据的配置文件信息，重启mysql数据库服务，即可完成mysql数据库主从备份。
笔者也亲自测试过，windows版本的mysql数据库做为主数据库，linux版本的mysql数据库做为从数据库，或者调换，均可设置主从备份。
5.mysql主从备份常见错误及解决方案
笔者在初次成功配置了mysql数据库主从备份后，以为自此可以万事无忧。但未过多久，通过查询指令查看从服务器的同步状态，发现报错了，在网上寻求解决办法解决后。发现不多久，又会出现其他类型的错误。总之，感觉很棘手，也觉得主从备份不可靠，需要人经常去查看同步状态，一旦出现报错，需要及时人为的处理。这样的情况一般出现在最初做数据库同步的那几天，还有就是主服务器，或者从服务器宕机时间长了的情况。常见错误及解决方案如下：
-
[ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: ‘Client requested master to start replication from impossible position‘, Error_code: 1236
解决方案：出现1236，出现这种错误一般是主从服务器失去连接，出现了宕机的情况。常用解决办法，重新查询主服务器的状态，获取新的position位置，重新设置从服务器的同步信息。
-
Last_Errno: 1032， Last_Error: Could not execute Update_rows event on table xuanzhi.test; Can‘t find record in ‘test‘, Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event‘s master log mysql
解决方案：出现1032，表示从数据库上面缺少某一条数据记录，主数据库对这条记录又做了修改，从数据库在修改时报错。解决方案是直接用数据库管理工具，数据传输模式处理具体异常的数据表，保证主数据与从数据库对应的报错数据表结构信息一样。
-
Last_Errno: 1062，Last_Error: Could not execute Write_rows event on table xuanzhi.test; Duplicate entry ‘5‘ for key ‘PRIMARY‘, Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event‘s master log
解决方案：出现1062，表示主键冲突，及从数据库上面出现了主数据库上面没有的主键信息记录。解决方案是直接删除提示的从数据库中的异常数据，或者利用数据传输模式处理具体异常的数据表。
-
Last_Errno: 1594，Last_Errno: 1593
解决方案：中继日志错误，一般是服务器宕机引起，解决方案和出现错误1236一样。在msql 5.5以上版本，可在slave的配置文件my.cnf里要增加一个参数relay_log_recovery=1。
校验主从服务器上面的数据是否完全一致，可通过工具pt-table-checksum操作。具体操作请参考这篇博文。
原文地址：https://www.cnblogs.com/wlandwl/p/mysql.html