mysql主从复制系列（2）——主从复制原理概述

前言

先来谈谈Mysql集群的可行方案

MySQL Cluster 

由Mysql自己提供，优点：可用性很是高，性能很是好。每份数据至少可在不一样主机 存一份拷贝，且冗余数据拷贝实时同步。但它的维护很是复杂，存在部分Bug，目前还不 适合比较核心的线上系统，因此不推荐。

DRBD磁盘网络镜像方案 

Distributed Replicated Block Device，其实现方式是经过网络来镜像整个设备(磁盘). 它容许用户在远程机器上创建一个本地块设备的实时镜像,与心跳连接结合使用, 也可看作一种网络RAID。 

优点：软件功能强大，数据可在底层快设备级别跨物理主机镜像，且可根据性能和可 靠性要求配置不一样级别的同步。IO操做保持顺序，可知足数据库对数据一致性的苛刻要求 。但非分布式文件系统环境没法支持镜像数据同时可见，性能和可靠性二者相互矛盾，无 法适用于性能和可靠性要求都比较苛刻的环境，维护成本高于MySQL Replication。另外，DRBD也是官方推荐的可用于MySQL 高可用方案之一，因此这个你们可根据实际环境来考虑是否部署。 

MySQL Replication 

今天的主题，在实际应用场景中，MySQL Replication是使用最为普遍的一种提升系统扩展性的设计手段。众多的MySQL使用者经过 Replication功能提高系统的扩展性后，经过简单的增长价格低廉的硬件设备成倍 甚至成数量级地提升了原有系统的性能。

主从复制原理概述 

( 1 )首先, MySQL主库在事务提交时会把数据变动做为事件 Events 记录在二进制日志文件Binlog中; MySQL主库上的 sync_binlog参数控制 Binlog日志刷新到磁盘。

 ( 2 )主库推送二进制日志文件 Binlog中的事件到从库的中继日志 Relay Log, 以后从库根据中继日志 Relay Log重作数据变动操做, 经过逻辑复制以此来达到主库和从库的数据一致。

3个线程 

MySQL经过3个线程来完成主从库间的数据复制:

Binlog Dump线程跑在主库上 

I/0线程和 SQL线程跑在从库上

当在从库上启动复制时,首先建立I/0程链接主库, 主库随后建立 Binlog Dump线程读取数据库事件并发送给 I/0线程, I0线程获取到事件数据后更新到从库的中继日志 Relay Log中去,以后从库上的 SQL线程读取中继日志RelayLog中更新的数据库事件并应用。 

SHOW PROCESSLIST命令

经过 SHOW PROCESSLIST命令在主库上查看BinlogDump线程

从 BinlogDump 线程的状态能够看到, Mysql的复制是主库主动推送日志到从库去的,是属于“推”日志的方式来作同步。

经过 SHOW PROCESSLIST能够在从库上查看l/O线程和 SQL线程

l/O线程(Id=5)等待主库上的 Binlog Dump线程发送事件并更新到中继日志 RelayLog

SQL线程(Id=6)读取中继日志并应用变动到数据库

二进制日志文件 Binlog三种格式(复制方式)

Statement:基于 SQL语句级别的 Binlog,每条修改数据的 SQL都会保存到 Binlog里。 

Row:基于行级别,记录每一行数据的变化,也就是将每行数据的变化都记录到 Binlog 里面, 记录得很是详细, 可是并不记录原始 SQL; 在复制的时候, 并不会由于存储过程或触发器形成主从库数据不一致的问通, 可是记录的日志量较 Statement格式要大得多 。 

Mixed:混合Statement和Row模式,默认状况下采用 Statement模式记录, 某些状况下会切换到 Row模式 同时也对应了 MysQL复制的3种技术。

查看当前复制方式  

show variables like '%binlog%format%'; 复制代码

更改复制方式 

set global binlog_format = 'ROW'; 
set global binlog_format = 'STATEMENT'; 复制代码