主从复制就是用来建立一个或多个和主库一样的数据库,称为从库,然后可以在这两者之上进行一个读写分离,主库少写,从库多读的操作,这样就能大大缓解数据库的并发压力。
1)做数据的热备份,作为后备数据库,主数据库服务器故障后,可切换到从数据库继续工作,避免数据丢失。
2)架构的扩展。业务量越来越大,I/O访问频率过高,单机无法满足,此时做多库的存储,降低磁盘I/O访问的评率,提高单个机器的I/O性能。
3)读写分离,使数据库能支持更大的并发。在线上环境中,一般都是读多写少,那么我们可以在主库中实现写操作,然后在从库实现读操作,这样就能很好的分担压力.
1. 首先从库创建I/O线程去请求主库 的binlog
2. 然后主库创建一个binlog dump线程将数据同步到binlog文件中.
3. 然后从库I/O线程将binlog文件数据同步到自身的redo log文件中.
4. 然后从库创建一个sql线程将redo log文件里的数据同步到数据库里.
1.因为从库复制binlog文件的这个IO线程是单线程,所以如果出现网络阻塞等情况,那么主库的写操作肯定要比复制数据要快,这个时候就会导致从库复制延迟,数据不一致.
2.在从库用sql线程将redo log文件里的数据复制到数据库里的时候,可能会被对该表的操作阻塞,比如有另外的线程进行锁表的操作,那么该导入数据的sql线程就会被阻塞.此时也会导致复制延迟.
3.如果中间过程出现了宕机,可能会产生数据丢失的问题.
1.解决数据丢失,很简单,可以采用半同步复制策略.即在进行同步复制的时候,主库要求必须要有一个从库进行回应后才能确定复制成功,确保数据至少复制到了一台从机了.
2.解决复制延迟问题可以采用并行复制,这是自5.6后提出的,到5.7后得以升级传播,此后多个数据库版本出现就有多个版本的并行复制,这里截取网上一种通用说法,跟面试官说说就可以了,毕竟我们是刚出去工作的小白:
MySQL为了解决这个问题,将sql_thread演化了多个worker的形式,在slave端并行应用relay log中的事务,从而提高relay log的应用速度,减少复制延迟。
水平分库
概念:以字段为依据,按照一定策略(hash、range等),将一个库中的数据拆分到多个库中。
结果:每个库的结构都一样,拥有相同的表数量;每个库的数据都不一样,没有交集,所有库的并集是全量数据;
垂直分库
概念:以表为依据,按照业务归属不同,将不同的表拆分到不同的库中。拆分对象是表
结果:每个库的结构都不一样,比如abcd四张表,ab表放x库,cd表放y库;每个库的数据也不一样,没有交集,所有库的并集是全量数据;
水平分表
概念:以字段为依据,按照一定策略(hash、range等),将一个表中的数据拆分到多个表中。
结果:每个表的结构都一样;每个表的数据都不一样,没有交集;所有表的并集是全量数据;
垂直分表
概念:以字段为依据,按照字段的活跃性,将热点字段放在一张表,非热点字段放一张表。
结果:每个表的结构都不一样,idabcd五个字段,idab字段放x表,idcd字段放y表;都存有主键,通过主键来关联