主从复制原理,简言之,就三步曲,如下:
-
主数据库有个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切片中0127切片和128255切片分别存在两个一主两从的数据库集群中,系统运维了3年多,目前还没有扩容需求。设计初衷应该是考虑得到,假设有一天数据量非常大,可以把256个切片分4大片,分别存储到4个一主两从的集群中,从而实现扩容。