MySQL主从同步是一种成熟的体系结构，优点是：可以在从服务器上执行查询工作(常见的读取功能)，可以减轻主服务器的压力在备份过程中不影响主服务器服务；
mysql主(master )从) slave复制的原理：
1、master将数据的变更记录在二进制日志(binary log )中。 即，是配置文件log-bin
指定的文件。 这些记录称为二进制日志事件，二进制日志事件
2、slave将主二进制日志事件复制到其中继日志(relay log )中
3、从属重做中继日志事件更改反映自身的数据---再试一次
4、默认情况下一分钟同步一次
MySQL主从同步存在来自库的延迟问题，为什么会存在这样的问题呢？ 这个问题怎么解决？
1. MySQL数据库主从同步延迟原理。
2. MySQL数据库的主从同步延迟是如何发生的？
3. MySQL数据库主从同步延迟解决方案。
1. MySQL数据库主从同步延迟原理。
答：关于MySQL数据库主从同步延迟的原理，必须从MySQL的数据库主从复制原理入手。 MySQL的主从复制都是单线程操作，主库为所有DDL和DML生成binlog，binlog是顺序写入，所以效率高。 slave的Slave_IO_Running线程在主库中记录的DML和DDL io操作是随机的、顺序的、成本非常高，而且slave上的其他查询也可能发生锁定冲突因为Slave_SQL_Running也是单线程的，所以一个DDL主节点需要10分钟，然后所有DDL都将等待此DDL运行完成。 这位朋友说：“主库中的同一个DDL也需要运行10分，为什么slave要延迟？ ”。答案可以同时运行master，但不能运行Slave_SQL_Running线程。
2. MySQL数据库的主从同步延迟是如何发生的？
a )在主库的TPS并发高的情况下，如果生成的DDL数超出slave中一个sql线程所能承受的范围，则会发生延迟。 当然，也可能发生slave的大规模query语句和锁定等待。
3. MySQL数据库主从同步延迟解决方案
a )最简单的减少slave同步延迟的方法是在架构上优化，以确保主库的DDL尽可能快地运行。 另外，主库是写入，对sync_binlog=1、innodb _ flush _ log _ at _ Trx _ commit=1等数据的安全性高，但slave不是那么高的数据
mysql-5.6.3支持多线程主从复制。 原理和丁宁的相似。 dinch在表中创建多线程，而Oracle在每个数据库(方案)中创建多线程。 不同的库可以使用不同的复制线程。
sync_binlog=1
thismakesmysqlsynchronizethebinarylog’scontentstodiskeachtimeitcommitsatransaction
默认情况下，不是每次写入时binlog和硬盘都会同步。 因此，如果操作系统或计算机(而不仅仅是MySQL服务器)崩溃，binlog中的最后一条语句可能会丢失。 为此，请使用sync_binlog全局变量(其中1是最安全的值，但它是最慢的值)，以便binlog每写n次binlog就与硬盘同步。 即使sync_binlog设置为1，如果发生崩溃，表的内容和binlog的内容也可能不一致。 如果使用InnoDB表，则MySQL服务器处理COMMIT语句，将整个事务写入binlog，并将事务提交到InnoDB。 如果在两次操作之间发生崩溃，InnoDB将在重新启动时回滚事务，但它仍然存在于binlog中。 使用--InnoDB-safe-binlog选项可以提高innodb表的内容和binlog的完整性。 (注释) MySQL 5.1不需要--innodb-safe-binlog； 此选项已禁用，因为引入了对XA事务的支持。)。 此选项使每个事务的binlog(sync_binlog=1)和(默认为真) InnoDB日志与硬盘同步，如果在崩溃后重新启动，则在回滚事务后， 提供了MySQL服务器剪切从binlog回滚的inodb日志的效果，从而使binlog能够反馈InnoDB表中的准确数据等，并保持从属服务器和主服务器的同步。 不会接收回滚语句。
innodb_flush_log_at_trx_commit (这很有用)。
抱怨Innodb比MyISAM慢100倍吗？ 那么，你可能忘了调整这个值了。 默认值1是针对每个事务或
事务外的指令都需要把日志写入(flush)硬盘，这是很费时的。特别是使用电 池供电缓存(Battery backed up cache)时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统 挂了时才可能丢数据。解决之道：分布式集群
2016 年 8 月 30 号腾讯开源了 PhxSQL 产品。
PhxSQL 是由微信后台团队自主研发的一款服务高可用、数据强一致的分布式数据库服
务。该服务基于 Percona5.6 搭建，目标在于解决 MySQL 在容灾和数据一致性方面的不足，
并大幅简化了 MySQL 容灾切换的运维操作。
PhxSQL 具有服务高可用、数据强一致、高性能、运维简单、和 MySQL 完全兼容的特点。
服务高可用：PhxSQL 集群内只要多数派节点存活就能正常提供服务；出于性能的考虑，集
群会选举出一个 Master 节点负责写入操作；当 Master 失效，会自动重新选举新的 Master。
数据强一致：PhxSQL 采用多节点冗余部署，在多个节点之间采用 paxos 协议同步流水，保
证了集群内各节点数据的强一致。
下载地址：https://github.com/tencent-wechat/phxsql
主从配置需要注意的地方
1、 主 DB server 和从 DB server 数据库的版本一致。
2、 主 DB server 和从 DB server 数据库数据一致[ 这里就会可以把主的备份在从上
还原，也可以直接将主的数据目录拷贝到从的相应数据目录]。
3、 主 DB server 开启二进制日志,主 DB server 和从 DB server 的 server_id 都
必须唯一。