阅读 62

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'; 复制代码


关注下面的标签,发现更多相似文章
评论