主从复制的原理

原理：

原理：主从复制一共有三个进程，从库生成两个线程，一个I/O线程，一个SQL线程；

i/o线程去请求主库 的binlog，并将得到的binlog日志写到relay log（中继日志） 文件中；

主库会生成一个 log dump 线程，用来给从库 i/o线程传binlog；

SQL 线程，会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致;

  主从复制出现错误？

 错误一：

错误原因：从库用来连接主库的用户权限或者密码不对

解决方法：首先在主库上检查用来主从复制的用户权限，如果没有问题在检查从库使用的密码是否正确。

错误二：

错误原因：这个可能是从库的master.info文件有损坏。

解决方法：reset slave

错误三：

错误原因：可能是从库的约束比主库更多写造成的。

解决方法：

Mysql > stop slave;

Mysql > set global sql_slave_skip_counter =1 ;

Mysql > start slave;

错误四：

错误原因：slave上缺少错误中的表。

解决方法：在slave上添加上对应的表，然后start slave。

错误五：

错误原因：从库上对应的表上缺少字段。

解决方法：根据主库上表结构，在从库对应表上添加缺少的字段，然后start slave。

错误六：

错误原因：主库删除的表在从库中不存在，导致从库在遇到删除不存在表的错误时无法继续同步。

解决方法：利用slave-skip-errors参数，跳过对于的1146错误（这个参数是一个只读的，需要在配置文件中修改，并重启从库）

1、在my.cnf的[mysqld]下面添加slave_skip_errors=1146

2、重启从库 service mysq   jhl restart

3、在从库上启动同步

4、去掉my.cnf中的slave_skip_errors=1146

5、重启从库

6、启动从库复制`1

中断：

Show slave status\G；查看错误原因

1.show slave status\G,提示中继日志损坏,按以往的做法，根据提示重新指定合适的日志文件以及pos点。

2.  从MySQL5.5.X版本开始，增加了relay_log_recovery参数，这个参数的作用是：当slave从库宕机后，假如relay-log损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的relay-log，并且

重新从master上获取日志，这个参数是默认关闭的。做主从的时候没有开启这项参数。修改my.cnf，添加这两项。（skip-slave-start ，mysql服务启动跳过自动启动主从复制，以免产生新的问题）,relay_log_recovery不支持动态修改。所以修改配置文件，重启MySQL服务,启动主从复制线程

a、主从同步延迟与系统时间的关系，查看主从两台机器间系统 时间差   

c、主从同步延迟与lock锁的关系（myisam表读时会堵塞写），尽量避免使用myisam表。一个实例里面尽量减少数据库的数量。

d、主从复制发生异常而中断，过很久之后才发现复制异常。可通过查看master与slave的status估算相差的日志。如果相差太大，则可以考虑重做从库。

产生的原因：当主库的并发量比较大的时候，产生的DDL数量，超过线程所承受的范围，延时就产生了，还有可能是与slave的大型query语句产生了锁等待;

解决办法:在架构上做优化，尽量让主库的DDL快速执行，因为从库只是读取数据，不需要那么高的安全性，所以可以将sync_binlog设置为0，或者关闭binlog日志，或者是使用比主库更好的硬件设备作为slave

可以暂时存缓存里

从库不能执行大量写入（5.6是支持库的并发，5.7支持了一个库多个表的并发执行）

https://www.cnblogs.com/gomysql/p/3675429.html

MHA :原理

（1）从宕机崩溃的master保存二进制日志事件（binlog events）;

（2）识别含有最新更新的slave；

（3）应用差异的中继日志（relay log）到其他的slave；

（4）应用从master保存的二进制日志事件（binlog events）；

（5）提升一个slave为新的master；

（6）使其他的slave连接新的master进行复制；