mysql主从复制原理详解

master将改变记录到二进制日志中binlog,slave将master的binlog拷贝到自己的中继日志中,然后执行一遍sql语句就达到同步了

一个服务器当主库,另一个或多个服务器当从库,主库会把对数据库的修改操作(新增 删除 修改)记录在binlog日志中,从库连接主库获取主库的binlog，并记录在中继日志relay-log中，然后从上次记住的位置起执行SQL语句，一旦遇到错误则停止同步

步骤:

安装相同版本mysql,

修改master配置:开启binlog,设置server-id(必须唯一,一般ip地址后3位),

修改从服务器slave:设置server-id

重启两台服务器的mysql

在主服务器上建立帐户并授权slave

查看主数据库状态

配置从数据库

启动slave同步进程并查看状态

验证主从同步

从以上mysql的Replication原理可以看出：

* 主从间的数据库不是实时同步，就算网络连接正常，也存在瞬间主从数据不一致的情况。

* 如果主从的网络断开，则从库会在网络恢复正常后，批量进行同步。

* 如果对从库进行修改数据，那么如果此时从库正在在执行主库的bin-log时，则会出现错误而停止同步，这个是很危险的操作。所以一般情况下，我们要非常小心的修改从库上的数据。

* 一个衍生的配置是双主、互为主从配置，只要双方的修改不冲突，则可以工作良好。

* 如果需要多主库的话，可以用环形配置，这样任意一个节点的修改都可以同步到所有节点

MySQL数据库主从同步延迟解决方案

产生:当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，当然还有就是可能与slave的大型query语句产生了锁等待

最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave