将改变记录到二进制日志中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
