MySQL复制特性实施原理和关键因素

标签: mysql 复制 原理 | 发表时间:2015-02-19 10:17 | 作者:AllenHU0320
出处:http://www.iteye.com

复制特性实施的核心,就是基于Master节点对数据库中各项变更的处理机制。

二进制日志在记录事件时,支持多种格式,由binlog_format参数控制:

SBL对应statement,RBL对应row,MBL对应mixed

在MySQL5.6版本中,默认的日志记录格式是基于语句(Statement),一般会手动将其改为混合模式(Mixed),日志记录格式是由binlog_format系统参数控制

默认情况下,MBR是基于语句记录事件,当遇到SBR模式记录事件,存在数据安全隐患时,自动将日志记录格式变更为基于行格式记录,也就是RBR模式

使用SBR的优点:

技术成熟

生成日志少,特别是对于大量更新及删除操作

由于能够记录下数据库做过的所有变更操作,日志可用于行为审计

使用SBR的缺点:

Master节点中产生的修改操作并不是都能通过基于语句方式完整的复制到Slave节点,对于不确定的行为在基于语句复制时,很难确保Slave节点会执行并获得正确的数据

执行INSERT…SELECT语句时需要持有更多行锁(相比RBR而言)

UPDATE时也需要持有更多行锁(相比RBR而言)

对于InnoDB引擎,INSERT语句使用AUTO_INCREMENT会阻塞其他INSERT语句

对于复杂的语句,Slave节点执行时语句必须先被评估

如果在Slave节点执行时操作失败,基于SBR格式复制会增加主从不一致的概率

使用RBR的优点:

所有修改都能被安全地复制到Slave节点

Master端执行修改操作时,仅需极少的锁持有,因此可获得更高的并发特性

Slave节点执行INSERT/UPDATE/DELETE时也仅需要持有少量锁

使用RBR的缺点:

RBR可能会产生更多的日志

不再能通过分析日志,来获取曾经执行过的语句

例子1:有一条复杂的SQL语句,在Master节点执行了一个多小时,才最终成功修改了一条记录。这时候不适宜用SBR模式,应该使用RBR模式

例子2:有条简单的SQL,在Master节点执行时,向库中插入了1000万条记录。这时候不适宜采用RBR模式,应该使用SBR模式



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [mysql 复制 原理] 推荐:

MySQL Cluster 与 MongoDB 复制集分片设计及原理

- - MySQLOPS 数据库与运维自动化技术分享
分布式数据库计算涉及到分布式事务、数据分布、数据收敛计算等等要求. 分布式数据库能实现高安全、高性能、高可用等特征,当然也带来了高成本(固定成本及运营成本),我们通过MongoDB及MySQL Cluster从实现上来分析其中的设计思路,用以抽象我们在设计数据库时,可以引用的内部方法. 首先说说关系及非关系数据库的特征.

MySQL复制特性实施原理和关键因素

- - 数据库 - ITeye博客
复制特性实施的核心,就是基于Master节点对数据库中各项变更的处理机制. 二进制日志在记录事件时,支持多种格式,由binlog_format参数控制:. SBL对应statement,RBL对应row,MBL对应mixed. 在MySQL5.6版本中,默认的日志记录格式是基于语句(Statement),一般会手动将其改为混合模式(Mixed),日志记录格式是由binlog_format系统参数控制.

mysql主从复制

- - SQL - 编程语言 - ITeye博客
从库的配置,mysql5.5不支持配置文件的配置了,问了数据库的人,用命令行指定. 修改从库的配置 #default-storage-engine = InnoDB #修改 default-storage-engine = blackhole server-id = 11215004 #新增 replicate-do-db = test log-bin = mysql-bin #新增 binlog_format = row.

MySQL主从复制配置

- - 天空极速
在实际企业应用环境当中,单台MySQL数据库是不足以满足日后业务需求的. 譬如服务器发生故障,没有备份服务器来提供服务的话,业务就得停止. 使用MySQL主从复制的好处有:. 1、采用主从服务器这种架构,稳定性得以提升. 如果主服务器发生故障,我们可以使用从服务器来提供服务;. 2、在主从服务器上分开处理用户的请求,可以提升数据处理效率;.

MySQL 5.6 测试之 Replication(主从复制)

- - MySQL 中文网 -
MySQL 5.6测试之Replication. MySQL 5.6版本相比以前新增了很多令人激动的特性,简要介绍见: 转:MySQL 5.6新特性. 性能方面已经做过测试了,详细请见: MySQL 5.6 vs MariaDB 5.5 vs Percona(5.5 & 5.6) 之TPCC性能测试.

MySQL半同步复制(Semisynchronous Replication)

- - IT技术博客大学习
MySQL5.5引入了半同步复制(Semi-synchronous Replication),以下是对于半同步复制的认知和理解:. 半同步启动需要主从两端都需要加载安装各自对应的semi模块,从库端支持半同步功能的数量至少一台;主库端当一个事务成功提交后,并不及时反馈给前端用户,该线程会被临时block,等待由从库端返回确认该条事务也同时成功写入到relay log中的receipt(回执确认),这时主库线程才返回给当前session告知操作完成,半同步复制并不关心在从库一端该事务是否都被执行并被提交完成.

[玩转MySQL Replication] 复制拓扑

- - CSDN博客数据库推荐文章
     朴实简单的才是真、那些高端洋气的复制拓扑纯属自虐.      实施复制大概会有 4 个原则:.      ① 一个主库可以有多个备库.      ② 一个备库只能有一个主库.      ③ 每个备库 Server ID全局唯一.      ④ log_slave_updates 有薪火相传之效用.

MySQL主从复制与读写分离

- - 数据库 - ITeye博客
MySQL主从复制与读写分离. MySQL主从复制(Master-Slave)与读写分离(MySQL-Proxy)实践. Mysql作为目前世界上使用最广泛的免费数据库,相信所有从事系统运维的工程师都一定接触过. 但在实际的生产环境中,由单台Mysql作为独立的数据库是完全不能满足实际需求的,无论是在安全性,高可用性以及高并发等各个方面.

MySQL数据库复制概论

- - Float_Luuu的博客
每当我们讨论一项(新的)领域技术的时候,最好的方式通常是首先抛出一些问题,这些问题大致分为三类:诶. 这项技术又是什么玩意(What)?这项技术为什么会存在. 我们已经有那么多解决方案(Method)了,我们问什么要用它(Why). 如果这项技术那么好且我们正好有场景可以用到这项技术,且能使我们的系统得到很乐观的优化,那么我们怎么用呢(How).