mysql主从复制原理

主从复制原理，简言之，就三步曲，如下：

• 主数据库有个bin-log二进制文件，纪录了所有增删改Sql语句。（binlog线程）

• 从数据库把主数据库的bin-log文件的sql语句复制过来。（io线程）

• 从数据库的relay-log重做日志文件中再执行一次这些sql语句。（Sql执行线程）
  

上图主从复制分了五个步骤进行：

步骤一：主库的更新事件(update、insert、delete)被写到binlog

步骤二：从库发起连接，连接到主库。

步骤三：此时主库创建一个binlog dump thread，把binlog的内容发送到从库。

步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log

步骤五：还会创建一个SQL线程，从relay log里面读取内容，从ExecMasterLog_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db

Mysql的应用场景

1、单master

1）冷备：
停机，直接copy物理文件，InnoDB引擎（frm文件、共享表空间文件、独立表空间文件、重做日志文件、my.cnf）。

恢复：把文件copy到对应目录。

2）热备：
Ibbackup或者XtraBackup工具，记录重做日志文件检查点的LSN，copy共享表空间文件以及独立表空间文件（不产生任何阻塞），记录copy后重做日志文件检查点的LSN，copy备份是产生的重做日志。

恢复：恢复表空间文件，应用重做日志文件。

3）温备：
mysqldump，–single-transaction参数进行事务管理保证数据一致性。备份时不能用DDL语句。恢复：直接执行文件，mysql –uroot –p <文件名.sql>

二进制半同步复制，主从服务器增量复制

恢复：mysqlbinlog

2、一主一从

性能优化的内容比较多，也是一块大主题，要从系统的服务指标作为依据采取相应的动作，多数系统要求的是3秒内完成请求，总体换算下来，数据库大概可以有1.5秒的总执行时间，能满足这个性能要求就是合理的优化方案。
之后以这样的优先级来分别整理内容：索引优化 -> 表设计优化 ->数据库配置优化 ->硬件优化

3、一主 n 从

4、横向集群

分库分表

5、纵向集群

横向集群的切分思路最终是切分子系统，而纵向集群最后遇到的最棘手的问题是扩缩容，我运维的一个系统是提前对数据做了256个切片，256切片中0_{127切片和128}255切片分别存在两个一主两从的数据库集群中，系统运维了3年多，目前还没有扩容需求。设计初衷应该是考虑得到，假设有一天数据量非常大，可以把256个切片分4大片，分别存储到4个一主两从的集群中，从而实现扩容。