mysql主从同步原理

为何要作主从复制？
一、在业务复杂的系统中，有这么一个情景，有一句sql语句须要锁表，致使暂时不能使用读的服务，那么就很影响运行中的业务，使用主从复制，让主库负责写，从库负责读，这样，即便主库出现了锁表的情景，经过读从库也能够保证业务的正常运做。

二、作数据的热备

三、架构的扩展。业务量愈来愈大，I/O访问频率太高，单机没法知足，此时作多库的存储，下降磁盘I/O访问的频率，提升单个机器的I/O性能。

---

基本构建思路
–确保数据相同：从库必需要有主库上的数据
–配置主服务器：启用binlog日志，受权用户，查看当前正使用的Binlog日志（从库IO线程取SQL命令的地方）
–配置从服务器：设置server_id（标识本身的身份），指定主库信息
–测试配置： 客户端链接主库写入数据，在从库上也能查询到

mysql主从复制用途
实时灾备，用于故障切换
读写分离，提供查询服务
备份，避免影响业务

Master,记录数据更改操做
启用binglog日志
设置binlog日志格式
设置server_id

slave运行2个线程
slave_io线程：复制master主机 binlog日志文件里的sql到本机的relay-log文件里。
slave_sql线程：执行本机relay-log文件里的sql语句，重现Master的数据操做。

binlog(二进制文件)
relay-log(中继日志)

异步复制：
主库执行一次事务后，当即将结果返回给客户端，并不关心从库是否已经接收并处理

全同步复制：
当主库执行完一次事物，并全部从库都执行了该事务后才返回给客户端

半同步复制：
介于异步和全同步之间
主库在执行完一次事务后，等待至少一个从库接受到并写到中继日志中才返回客户端

---

问题及解决方法

mysql主从复制存在的问题：
主库宕机后，数据可能丢失
从库只有一个sql Thread，主库写压力大，复制极可能延时

解决方法：
半同步复制---解决数据丢失的问题
并行复制----解决从库复制延迟的问题

1. MySQL数据库主从同步延迟原理。

答：谈到MySQL数据库主从同步延迟原理，得从mysql的数据库主从复制原理提及，mysql的主从复制都是单线程的操做，主库对全部DDL和 DML产生binlog，binlog是顺序写，因此效率很高，slave的Slave_IO_Running线程到主库取日志，效率很比较高，下一步， 问题来了，slave的Slave_SQL_Running线程将主库的DDL和DML操做在slave实施。DML和DDL的IO操做是随即的，不是顺 序的，成本高不少，还可能可slave上的其余查询产生lock争用，因为Slave_SQL_Running也是单线程的，因此一个DDL卡主了，须要 执行10分钟，那么全部以后的DDL会等待这个DDL执行完才会继续执行，这就致使了延时。有朋友会问：“主库上那个相同的DDL也须要执行10分，为什 么slave会延时？”，答案是master能够并发，Slave_SQL_Running线程却不能够。

2. MySQL数据库主从同步延迟是怎么产生的。

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

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

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