Mysql主从复制概念

一  基本概念(面试准备)

（0）异步复制

说明：这是mysql默认的复制方式

特点：即主库执行完Commit后，在主库写入Binlog日志后即可成功返回客户端，无需等待Binlog日志传送给从库，一旦主库宕机，有可能会丢失日志(数据)

逻辑上

        MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从库上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。

技术上

        主库将事务 Binlog 事件写入到 Binlog 文件中，此时主库只会通知一下 Dump 线程发送这些新的 Binlog，然后主库就会继续处理提交操作，而此时不会保证这些 Binlog 传到任何一个从库节点上。

（1）什么是主从复制?

主从复制，是用来建立一个和主数据库(参照物)完全一样的数据库环境，称为从数据库；主数据库一般是准实时的业务数据库。

（2）主从复制的作用

等价：好处，或者说为什么要做主从复制

1、最常用做数据的热备(activeback)，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失

通俗：高可用自动故障冗余切换

2、架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储(减轻压力)，降低磁盘I/O访问的频率，提高单个机器的I/O性能。

3、读写分离，使数据库能支撑更大的并发。

备注：具体的技术选型，根据公司的业务要求！

（3）从数据库的读的延迟问题了解吗？如何解决？

        延迟的原因：主从的延迟会因为受到网络磁盘等等相关的因素影响，但其中最主要的影响是就是在master太过繁忙的写入导致slave无法有效的从relay_log中读取到最新的相关记录，这样对于数据实时性很高的业务来说，slave的数据并不是最新的有一定的延时，此时使用主从的读写分离就有点显的鸡肋了，不能做到slave上能查到最新的实时数据，大多在slave上都是做一些对实时数据要求并不是很高的一些数据查询。

补充：写操作涉及到锁的问题，不管是行锁还是表锁还是块锁，都是比较降低系统执行效率的事情！

[MySQL] 号称永久解决了复制延迟问题的并行复制，MySQL5.7

并行复制的核心理念：一个组提交的事务都是可以并行回放，因为这些事务都已进入到事务的prepare阶段，则说明事务之间没有任何冲突（否则就不可能提交）

mysql>  show global variables like 'slave_parallel_workers';# 默认是0，即单线程
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| slave_parallel_workers | 0     |
+------------------------+-------+
1 row in set (0.00 sec)

mysql> show global variables like '%slave_parallel_type%'; # 默认是多线程机制是一个线程处理一个库
+---------------------+----------+
| Variable_name       | Value    |
+---------------------+----------+
| slave_parallel_type | DATABASE |
+---------------------+----------+
1 row in set (0.00 sec)

mysql> 

说明：默认5.7主从复制的多线程是一个线程处理一个主从复制，而在绝大多数的生产环境中大多都是在一个数据库中做大量的操作的！

5.6：其并行只是基于Schema的，也就是基于库的！

5.7：MySQL 5.7中，引入了基于组提交的并行复制（Enhanced Multi-threaded Slaves），设置参数slave_parallel_workers>0并且global.slave_parallel_type＝‘LOGICAL_CLOCK’

特点：即可支持一个schema下，slave_parallel_workers个的worker线程并发执行relay log中主库提交的事务。其核心思想：一个组提交的事务都是可以并行回放（配合binary log group commit）

binlog format 是row格式（5.7默认）

相关连接

产生的原因

1)、MySQL数据库主从同步延迟原理mysql主从同步原理：主库针对写操作，顺序写binlog，从库单线程去主库顺序读”写操作的binlog”，从库取到binlog在本地原样执行（随机写），来保证主从数据逻辑上一致。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语句产生了锁等待。首要原因：数据库在业务上读写压力太大，CPU计算负荷大，网卡负荷大，硬盘随机IO太高次要原因：读写binlog带来的性能影响，网络传输延迟。