mysql replication /mysql 主从复制原理

一下内容均是根据leader的培训分享整理而成

************************************我是分割线****************************************

mysql5.5 replication

大概过程:

一。首先在master 执行一个事物,提交(mysql默认设置为自动提交),

二。提交之后 写到2个文件,一个是将数据写入datafile(这个数据是结果一致,例如有个数据单元开始数据是1,中间经过2,3等变化,最后是4,那么写入最终结果4), 一个是将事物写入bin_log(binary log),确切说不一定是事物,具体分为3种,1.statement-based logging, 2.row-based loggging,3.mixed logging.

binlog 里是很多的event, binlog开头是4个空位,具体作用不详(据leader讲是event开始的标志)。4个空位后有一位表示Format Description E(FDE),以事物为单位向binlog写数据,一个事物可以包含n个event,binlog结束有xid标志。(toconfirm:xid是一个事物的结束符号还是binlog内容结束的符号?)

每一个event里都有校验位,如果网络传输出现问题可以断点续传之类的,

三。master 把 binlog文件通过一个叫dump的线程传给slave, slave 将接到的event写入一个叫Relay log(中继日志)的文件,然后根据relay log用一个叫applier的东西 做commit(写datafile, 和 binlog)

binlog 和relay log 内容不总是相同,因为可以设置eventsize,如果master上有一个事物写入到binlog后使得size 超过eventsize(可以撑大,因为binlog以事物为单位存,而非event为单位), 这样传给slave后,当relay log达到slave端的event size后就会起新文件写入后续接收到的event.

unsafe的replication, 如果事物中含有rand类的赋值是safe的,因为event记录中有rand的种子, 可是如果有now()这样的赋值就是unsafe,因为有时间差,这时候statement-based logging 就会出错,可以用mixed logging.

mysql5.5版本的replication存在的问题:

主从数据差异:对主的操作可以是多并行,可是向从写入确实将多个并行的操作记录到binlog,然后串行的发送给从, 所以从的数据在没有完全执行完binlog前跟主存在差异, 而且并行到串行执行的效率可能也会差很大。解决方式,对从的操作考虑并行,或者semisynchronize, 可是如果同时并行,主的运行效率可能要下降,因为它既要执行自己的并行操作,还要将binlog里的event并行的发给从。semisychronize是适当降低主的并发操作,等待从,但是如果从的响应过慢,严重影响主的响应,主就要继续执行自己的并发。

************************************我是分割线****************************************

mysql 5.6 replication

一。使用gtid, 而不再是bin log 的pos来标识event 。因为如果存在像 master-->slave1(pos 100)--->slave2(pos 80), master-->slave3(pos150)这样的主从结构,如果master突然down掉,slave3变成主从的话, slave2将无法分辨下一条event的位置, slave2(pos80)只是相对自己相连的slave1里的binlog而言的event pos

二。使用MTS(multiple thread slave) 以schema为单位的多线程,因为对不同schema的操作不会相互影响,所以可以并行

************************************我是分割线****************************************

GroupCommit(组提交), mysql的多个提交并成组,目的是提高写速度,binlog 和groupcommit同用会有问题

toconfirm(mysql bug 70370)

************************************我是分割线****************************************

semisynthronize 过程

半同步的意义eg:用户在主上执行了插入,从的数据还没有更新,用户的主上可以查到新数据,从上却查不到。

为了解决类似上述的问题使用semisynthronize, 执行用户的操作 commit先不要执行,写入binlog, 然后将binlog 里新加入的event dump给Slave, slave 接受好之后给主ACK, 然后主在commit。

时间: 2024-10-27 08:38:28

mysql replication /mysql 主从复制原理的相关文章

第四阶段 (七)MySQL REPLICATION(主从复制、半同步复制、复制过滤)

Linux运维 第四阶段 (七)MySQL REPLICATION(主从复制.半同步复制.复制过滤) 一.MySQL Replication相关概念: 1.复制的作用:辅助实现备份:高可用HA:异地容灾:分摊负载(scaleout):rw-spliting(mysql proxy工作在应用层). 2.master有多个CPU允许事务并行执行,但往二进制日志文件只能一条条写:slave比master要慢:master-slave默认异步方式传送. 3.半同步:仅负责最近一台slave同步成功,其它

mysql replication(主从复制)实验学习笔记

1.理论部分 1.1.mysql replication的概念: enables data from one mysql database server(the master) to be replicated to one or more mysql database servers(the slaves). 1.2.mysql replication的实现基础: Binary Log(二进制日志)是实现mysql主从复制的基础 Binary Log的概念:所有的.无论是明确的或隐含的可以引起

MySQL Replication 即主从复制

MySQL Replication主要用于MySQL的时时备份或者读写分离.在配置之前先做一下准备工作,配置两台mysql服务器,或者在一台服务器上配置两个端口也可以.流程示意图: A-->change data-->bin_log-->transfer-->B-->repl_log-->change data 一.搭建好了一个mysql,跑的是3306端口. 1.下载mysql到/usr/local/src/ wget http://mirrors.sohu.com/

mysql replication(主从复制)实验学习笔记(二)

1.理论部分 1.1.One Master-Muti Slave 工作原理: 一台到多台Slave 缺陷: I/O压力集中在Master上 1.2.M-S-S 工作原理: 1)使用一台Slave作为中继,分担Master的压力. 2)中继SLave上需要开启二级制日志,并配置log-slave-updates. 1.3.M-M 工作原理: 相互负载均衡 缺点: 破坏了事物的隔离性何数据一致性(不建议使用) 1.4.M-M-M 工作原理: 通过Monitor监控其他三台机器运行 DML发送到其中一

MySQL主从复制原理及配置过程

一.Mysql数据库的主从复制原理过程: Mysql的主从复制是一个异步的复制过程,数据将从一个Mysql数据库(master)复制到另一个Mysql数据库(slave),在Master和Slave之间实现整个主从复制的过程是由三个线程参与完成的.其中有两个线程(SQL线程和I/O线程)在Slave端,另外一个线程(I/O线程)在Master端 ,要实现Mysql的主从复制,首先必须打开Master端的binlog记录功能,否则就无法实现.因为整个复制过程实际上就是Slave从Master获取b

深度探索MySQL主从复制原理

深度探索MySQL主从复制原理 一 .概要 MySQL Replication (MySQL 主从复制) 是什么? 为什么要主从复制以及它的实现原理是什么? 1.1 MySQL 主从复制概念 MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点.MySQL 默认采用异步复制方式,这样从节点不用一直访问主服务器来更新自己的数据,数据的更新可以在远程连接上进行,从节点可以复制主数据库中的所有数据库或者特定的数据库,或者特定的表. 1.2 MySQL 主从复制主要用

浅析 MySQL Replication(本文转自网络,非本人所写)

作者:卢飞 来源:DoDBA(mysqlcode) 0.导读 本文几乎涵盖了MySQL Replication(主从复制)的大部分知识点,包括Replication原理.binlog format.复制中如何保证数据一致性.组提交.复制优化.半同步复制.多源复制. 目前很多公司中的生产环境中都使用了MySQL Replication ,也叫 MySQL 复制,搭建配置方便等很多特性让 MySQL Replication 的应用很广泛,我们曾经使用过一主拖20多个从库来分担业务压力.关于 MySQ

MySQL性能调优与架构设计——第13章 可扩展性设计之 MySQL Replication

第13章 可扩展性设计之 MySQL Replication 前言: MySQL Replication 是 MySQL 非常有特色的一个功能,他能够将一个 MySQL Server 的 Instance 中的数据完整的复制到另外一个 MySQL Server 的 Instance 中.虽然复制过程并不是实时而是异步进行的,但是由于其高效的性能设计,延时非常之少.MySQL 的Replication 功能在实际应用场景中被非常广泛的用于保证系统数据的安全性和系统可扩展设计中.本章将专门针对如何利

MySQL主从复制原理深入解析与练习

MySQL主从复制画图描述: MySQL主从复制原理上图详解: ① 用户做crud操作,写入数据库,更新结果记录到binlog中: ② 主从同步是主找从的,从库IO发起请求,主库的主进程看从库的master change中给的参数是否合法,如果合法主进程交给IO进程进行3操作,否则拒绝: ③ 主库根据master的位置点,从这个位置点的binlog日志一直到binlog最后,将其准备发送给从库: ④ 将找到的binlog日志发给从库,并且还会发送新的日志点: ⑤ 从库收到binlog日志,将其写